On Tuesday, 27 July 2021 at 12:34:58 UTC, Daniel N wrote:
> On Tuesday, 27 July 2021 at 09:20:25 UTC, Petar Kirov
>>> module(std.datetime).SysTime
>>
>> That's the best suggestion so far.
>
> 1) std.datetime::SysTime
> 2) module(std.datetime).SysTime
>
> From a human readability perspective I like option (1) the best, however from a compiler perspective, you cannot tell that LHS is a module until it sees the final ::(or some other operator), that might not be optimal.
>
> Overall, I also think option 2 is the most realistic compromise.

There's one other interesting tradeoff to consider...

// This will not even stat the file, just inform the compiler that it's a module.
lazy import std.datetime;

// This is now unambigous - no need for special syntax
std.datetime.SysTime

On 27.07.21 14:34, Daniel N wrote:
> 
> 1) std.datetime::SysTime
> 2) module(std.datetime).SysTime
> 
>  From a human readability perspective I like option (1) the best, however from a compiler perspective, you cannot tell that LHS is a module until it sees the final ::(or some other operator), that might not be optimal.

I don't think it is very important if the parser knows this early or not.

On Friday, 30 July 2021 at 14:28:41 UTC, Paul Backus wrote:
> On Friday, 30 July 2021 at 14:23:18 UTC, Ogi wrote:
>> On Saturday, 24 July 2021 at 19:52:37 UTC, qxi wrote:
>>> std.datetime::SysTime
>>
>> Why not `std.datetime:SysTime`? This would be consistent with the selective import syntax: `import std.datetime : SysTime`.
>
> A single colon is already used for `goto` labels, so `foo:bar;` could be either (a) the statement `bar;` with the label `foo:`, or (b) the statement `foo:bar;`, where `foo` is a module and `bar` is a symbol in that module.

I guess, one could use a leading dot to disambiguate...

.foo:bar; // not a label
std.datetime:SysTime; // already contains a dot, no need to disambiguate

+ D already supports leading dot
+ no need to add new tokens/operators
+ consistent with selective import syntax

On 31/07/2021 8:46 PM, Daniel N wrote:
> + D already supports leading dot

And that's a problem. Now things get more complicated and not where you want it to be.

On Monday, 26 July 2021 at 12:55:54 UTC, Andrei Alexandrescu wrote:
>> import[std.datetime].SysTime
>> import{std.datetime}.SysTime
>> import std.datetime..SysTime
>> import std.datetime::SysTime
>> std.datetime::SysTime
>
> import:std.datetime.SysTime

(import std.datetime).SysTime

In an expression, import currently can only appear followed by '(', so there is no ambiguity.

On Sunday, 1 August 2021 at 04:15:33 UTC, Vladimir Panteleev wrote:
>
> (import std.datetime).SysTime
>
> In an expression, import currently can only appear followed by '(', so there is no ambiguity.

Very elegant; I like it.

On Sunday, 1 August 2021 at 13:30:55 UTC, Paul Backus wrote:
> On Sunday, 1 August 2021 at 04:15:33 UTC, Vladimir Panteleev wrote:
>>
>> (import std.datetime).SysTime
>>
>> In an expression, import currently can only appear followed by '(', so there is no ambiguity.
>
> Very elegant; I like it.

It looks reasonable when it appears as a simple statement, but as soon as it's in an expression... it doesn't compose as well.

it will result in ubiquitous double parens.
if ((import std.datetime).SysTime > deadline)
-> **

Compare with one of the other competing suggestions
if (module(std.datetime).SysTime > deadline)

The design of D helped alot to cut down the amount of parens... if you are not convinced, consider how much UFCS and single argument templates helped human readability.

On Sunday, 1 August 2021 at 16:03:05 UTC, Daniel N wrote:
>
> It looks reasonable when it appears as a simple statement, but as soon as it's in an expression... it doesn't compose as well.
>
> it will result in ubiquitous double parens.
> if ((import std.datetime).SysTime > deadline)
> -> **
>
> Compare with one of the other competing suggestions
> if (module(std.datetime).SysTime > deadline)
>
> The design of D helped alot to cut down the amount of parens... if you are not convinced, consider how much UFCS and single argument templates helped human readability.

Actually, both examples have the same number of parentheses. :) But I take your point—the first version forces you to look ahead to figure out what the second opening paren is for, whereas in the second version you have the `module` keyword telling you in advance what to expect.