• Andrei Alexandrescu (9/9) Jul 23 2021 Mathias Lang just told me the bug preventing inline imports from working...
• Steven Schveighoffer (5/17) Jul 23 2021 No comments on the inline-import mechanism. I'm not too concerned with
• user1234 (5/23) Jul 23 2021 It's possible to make the difference during semantic. If the
• Andrei Alexandrescu (2/27) Jul 24 2021 Yah but that'd be awfully confusing...
• Petar Kirov [ZombineDev] (10/40) Jul 26 2021 I agree it could be confusing. That said I would really prefer if
• Andrei Alexandrescu (3/15) Jul 24 2021 Per our coding standards I renamed `_import` to `import_` although I
• Daniel N (9/11) Jul 24 2021 FWIW, I would prefer impmod or virtually any symbol without
• rikki cattermole (8/8) Jul 24 2021 Following on from BeerConf.
• Adam D Ruppe (3/8) Jul 24 2021 yeah like what's the module in there? what about something like
• rikki cattermole (3/13) Jul 24 2021 It would certainly be an interesting set of changes to make that happen
• qxi (7/16) Jul 24 2021 import[std.datetime].SysTime
• Andrei Alexandrescu (2/21) Jul 26 2021 import:std.datetime.SysTime
• qxi (15/37) Jul 26 2021 Problem with 'import:std.datetime.SysTime' is that we cant tell
• ag0aep6g (3/11) Jul 26 2021 module(std.datetime).SysTime
• Petar Kirov [ZombineDev] (2/13) Jul 27 2021 That's the best suggestion so far.
• ShadoLight (5/11) Jul 27 2021 I agree. But how about, for the sake of consistency (but at the
• deadalnix (2/14) Jul 27 2021 How is that more consistent?
• ShadoLight (4/21) Jul 27 2021 Oh s**t, you are right; I've forgotten that this was for only for
• Daniel N (9/23) Jul 27 2021 1) std.datetime::SysTime
• Daniel N (7/18) Jul 27 2021 There's one other interesting tradeoff to consider...
• Timon Gehr (2/10) Jul 27 2021 I don't think it is very important if the parser knows this early or not...
• Zach Tollen (5/19) Mar 05 2022 No one suggested:
• max haughton (5/25) Mar 05 2022 `import.identifier` may be grammatically unambiguous but is
• Zach Tollen (5/15) Mar 05 2022 I agree, except that syntax highlighters could easily make this
• Kagamin (5/11) Jul 27 2021 import.std.datetime.SysTime
• Vladimir Panteleev (5/11) Jul 31 2021 (import std.datetime).SysTime
• Paul Backus (3/6) Aug 01 2021 Very elegant; I like it.
• Daniel N (11/19) Aug 01 2021 It looks reasonable when it appears as a simple statement, but as
• Paul Backus (6/16) Aug 01 2021 Actually, both examples have the same number of parentheses. :)
• Atila Neves (2/17) Aug 02 2021 Hmm. This could show up in template constraints.
• Ogi (3/4) Jul 30 2021 Why not `std.datetime:SysTime`? This would be consistent with the
• Paul Backus (5/9) Jul 30 2021 A single colon is already used for `goto` labels, so `foo:bar;`
• Daniel N (8/18) Jul 31 2021 I guess, one could use a leading dot to disambiguate...
• rikki cattermole (3/4) Jul 31 2021 And that's a problem. Now things get more complicated and not where you
• Temtaime (5/14) Mar 06 2022 What an ugly approach.
• Zach Tollen (3/6) Mar 06 2022 You should note this thread is 7 months old. I brought it back

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Mathias Lang just told me the bug preventing inline imports from working 
has been fixed, so I reopened this:

https://github.com/dlang/druntime/pull/1756

I think it's a very useful facility, more clearly so for large projects, 
and deserves a fair shake of the stick.

If it works well in practice, a future language proposal could take 
`_import!"std.datetime".SysTime` to the simpler and better 
`import(std.datetime).SysTime`. Using it as a library facility seems 
like a good step.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 7/23/21 9:55 AM, Andrei Alexandrescu wrote:
 Mathias Lang just told me the bug preventing inline imports from working 
 has been fixed, so I reopened this:
 
 https://github.com/dlang/druntime/pull/1756
 
 I think it's a very useful facility, more clearly so for large projects, 
 and deserves a fair shake of the stick.
 
 If it works well in practice, a future language proposal could take 
 `_import!"std.datetime".SysTime` to the simpler and better 
 `import(std.datetime).SysTime`. Using it as a library facility seems 
 like a good step.

No comments on the inline-import mechanism. I'm not too concerned with 
the problem it solves (I'm OK adding imports when needed).

Just FYI, `import(somefilenamestring)` already is taken.

-Steve

user1234 <user1234 12.de> writes:

On Friday, 23 July 2021 at 18:57:08 UTC, Steven Schveighoffer 
wrote:
 On 7/23/21 9:55 AM, Andrei Alexandrescu wrote:
 Mathias Lang just told me the bug preventing inline imports 
 from working has been fixed, so I reopened this:
 
 https://github.com/dlang/druntime/pull/1756
 
 I think it's a very useful facility, more clearly so for large 
 projects, and deserves a fair shake of the stick.
 
 If it works well in practice, a future language proposal could 
 take `_import!"std.datetime".SysTime` to the simpler and 
 better `import(std.datetime).SysTime`. Using it as a library 
 facility seems like a good step.

 No comments on the inline-import mechanism. I'm not too 
 concerned with the problem it solves (I'm OK adding imports 
 when needed).

 Just FYI, `import(somefilenamestring)` already is taken.

 -Steve

It's possible to make the difference during semantic. If the 
expression between parens gives a StringExp -> ImportExpression, 
if that gives a ModuleDeclaration -> the new inline import.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/23/21 5:15 PM, user1234 wrote:
 On Friday, 23 July 2021 at 18:57:08 UTC, Steven Schveighoffer wrote:
 On 7/23/21 9:55 AM, Andrei Alexandrescu wrote:
 Mathias Lang just told me the bug preventing inline imports from 
 working has been fixed, so I reopened this:

 https://github.com/dlang/druntime/pull/1756

 I think it's a very useful facility, more clearly so for large 
 projects, and deserves a fair shake of the stick.

 If it works well in practice, a future language proposal could take 
 `_import!"std.datetime".SysTime` to the simpler and better 
 `import(std.datetime).SysTime`. Using it as a library facility seems 
 like a good step.

 No comments on the inline-import mechanism. I'm not too concerned with 
 the problem it solves (I'm OK adding imports when needed).

 Just FYI, `import(somefilenamestring)` already is taken.

 -Steve

 
 It's possible to make the difference during semantic. If the expression 
 between parens gives a StringExp -> ImportExpression, if that gives a 
 ModuleDeclaration -> the new inline import.

Yah but that'd be awfully confusing...

Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:

On Saturday, 24 July 2021 at 17:52:03 UTC, Andrei Alexandrescu 
wrote:
 On 7/23/21 5:15 PM, user1234 wrote:
 On Friday, 23 July 2021 at 18:57:08 UTC, Steven Schveighoffer 
 wrote:
 On 7/23/21 9:55 AM, Andrei Alexandrescu wrote:
 Mathias Lang just told me the bug preventing inline imports 
 from working has been fixed, so I reopened this:

 https://github.com/dlang/druntime/pull/1756

 I think it's a very useful facility, more clearly so for 
 large projects, and deserves a fair shake of the stick.

 If it works well in practice, a future language proposal 
 could take `_import!"std.datetime".SysTime` to the simpler 
 and better `import(std.datetime).SysTime`. Using it as a 
 library facility seems like a good step.

 No comments on the inline-import mechanism. I'm not too 
 concerned with the problem it solves (I'm OK adding imports 
 when needed).

 Just FYI, `import(somefilenamestring)` already is taken.

 -Steve

 
 It's possible to make the difference during semantic. If the 
 expression between parens gives a StringExp -> 
 ImportExpression, if that gives a ModuleDeclaration -> the new 
 inline import.

 Yah but that'd be awfully confusing...

I agree it could be confusing. That said I would really prefer if 
whatever we choose is an expression, as expressions are much 
easier to manipulate than statements via meta-programming - think 
of what you can put in an `AliasSeq`.
Even better, if can just use ranges to manipulate import lists. 
And no, [stringly typed][1] API is not the answer :D Perhaps 
something like a first-class `Symbol` type.

[1]: http://wiki.c2.com/?StringlyTyped

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/23/21 9:55 AM, Andrei Alexandrescu wrote:
 Mathias Lang just told me the bug preventing inline imports from working 
 has been fixed, so I reopened this:
 
 https://github.com/dlang/druntime/pull/1756
 
 I think it's a very useful facility, more clearly so for large projects, 
 and deserves a fair shake of the stick.
 
 If it works well in practice, a future language proposal could take 
 `_import!"std.datetime".SysTime` to the simpler and better 
 `import(std.datetime).SysTime`. Using it as a library facility seems 
 like a good step.

Per our coding standards I renamed `_import` to `import_` although I 
find the latter awfully bizarre.

Daniel N <no public.email> writes:

On Saturday, 24 July 2021 at 18:13:32 UTC, Andrei Alexandrescu 
wrote:
 Per our coding standards I renamed `_import` to `import_` 
 although I find the latter awfully bizarre.

FWIW, I would prefer impmod or virtually any symbol without 
underscore, even though I generally try to avoid abbreviations in 
public symbols, it is not unheard of, ex AliasSeq, so I think 
it's the lesser of two evils in this case.

However, I'm happy as long as this feature finally works out of 
the box!

Thanks for driving this!

rikki cattermole <rikki cattermole.co.nz> writes:

Following on from BeerConf.

What I am seeing in both options of import_ and _import identifiers, is 
that its a little hard to guess that this should be a valid way to 
import a module for a specific symbol access.

Instead enabling of using the identifier list directly i.e.

std.stdio.writeln("foo");

Without an explicit import to get it in scope, and yes I know this has 
some ramifications with module loading and symbol resolution in general.

Adam D Ruppe <destructionator gmail.com> writes:

On Saturday, 24 July 2021 at 18:20:32 UTC, rikki cattermole wrote:
 Instead enabling of using the identifier list directly i.e.

 std.stdio.writeln("foo");

 Without an explicit import to get it in scope, and yes I know 
 this has some ramifications with module loading and symbol 
 resolution in general.

yeah like what's the module in there? what about something like 
arsd.minigui.menu.label, what would be the module there?

rikki cattermole <rikki cattermole.co.nz> writes:

On 25/07/2021 6:54 AM, Adam D Ruppe wrote:
 On Saturday, 24 July 2021 at 18:20:32 UTC, rikki cattermole wrote:
 Instead enabling of using the identifier list directly i.e.

 std.stdio.writeln("foo");

 Without an explicit import to get it in scope, and yes I know this has 
 some ramifications with module loading and symbol resolution in general.

 
 yeah like what's the module in there? what about something like 
 arsd.minigui.menu.label, what would be the module there?

It would certainly be an interesting set of changes to make that happen 
for sure!

qxi <qxi.urt gmail.com> writes:

On Friday, 23 July 2021 at 13:55:34 UTC, Andrei Alexandrescu 
wrote:
 Mathias Lang just told me the bug preventing inline imports 
 from working has been fixed, so I reopened this:

 https://github.com/dlang/druntime/pull/1756

 I think it's a very useful facility, more clearly so for large 
 projects, and deserves a fair shake of the stick.

 If it works well in practice, a future language proposal could 
 take `_import!"std.datetime".SysTime` to the simpler and better 
 `import(std.datetime).SysTime`. Using it as a library facility 
 seems like a good step.

import[std.datetime].SysTime
import{std.datetime}.SysTime
import std.datetime..SysTime
import std.datetime::SysTime
std.datetime::SysTime

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/24/21 3:52 PM, qxi wrote:
 On Friday, 23 July 2021 at 13:55:34 UTC, Andrei Alexandrescu wrote:
 Mathias Lang just told me the bug preventing inline imports from 
 working has been fixed, so I reopened this:

 https://github.com/dlang/druntime/pull/1756

 I think it's a very useful facility, more clearly so for large 
 projects, and deserves a fair shake of the stick.

 If it works well in practice, a future language proposal could take 
 `_import!"std.datetime".SysTime` to the simpler and better 
 `import(std.datetime).SysTime`. Using it as a library facility seems 
 like a good step.

 
 import[std.datetime].SysTime
 import{std.datetime}.SysTime
 import std.datetime..SysTime
 import std.datetime::SysTime
 std.datetime::SysTime

import:std.datetime.SysTime

qxi <qxi.urt gmail.com> writes:

On Monday, 26 July 2021 at 12:55:54 UTC, Andrei Alexandrescu 
wrote:
 On 7/24/21 3:52 PM, qxi wrote:
 On Friday, 23 July 2021 at 13:55:34 UTC, Andrei Alexandrescu 
 wrote:
 Mathias Lang just told me the bug preventing inline imports 
 from working has been fixed, so I reopened this:

 https://github.com/dlang/druntime/pull/1756

 I think it's a very useful facility, more clearly so for 
 large projects, and deserves a fair shake of the stick.

 If it works well in practice, a future language proposal 
 could take `_import!"std.datetime".SysTime` to the simpler 
 and better `import(std.datetime).SysTime`. Using it as a 
 library facility seems like a good step.

 
 import[std.datetime].SysTime
 import{std.datetime}.SysTime
 import std.datetime..SysTime
 import std.datetime::SysTime
 std.datetime::SysTime

 import:std.datetime.SysTime

Problem with 'import:std.datetime.SysTime' is that we cant tell 
which identifier is imported symbol (unless we assume that the 
last identifier is an imported symbol),
for example 'import:A.B.C' we dont know we import symbol 'B' from 
module 'A' or symbol 'C' from module 'A.B', with may both exists.

Examples that dont work:

import:Module.Struct.StaticFunction(arguments)
import:Module.AliasToTplInst.SomeType

I know it is possible to write 
'(import:Module.Struct).StaticFunction(arguments)' but that dont 
look right (at least for me), and in my examples using brackets 
or tokens is to easier distinguish module name from imported 
symbol (in all cases).

ag0aep6g <anonymous example.com> writes:

On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

[...]
 import[std.datetime].SysTime
 import{std.datetime}.SysTime
 import std.datetime..SysTime
 import std.datetime::SysTime
 std.datetime::SysTime

 
 import:std.datetime.SysTime

module(std.datetime).SysTime

Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:

On Tuesday, 27 July 2021 at 05:07:32 UTC, ag0aep6g wrote:
 On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

 [...]
 import[std.datetime].SysTime
 import{std.datetime}.SysTime
 import std.datetime..SysTime
 import std.datetime::SysTime
 std.datetime::SysTime

 
 import:std.datetime.SysTime

 module(std.datetime).SysTime

That's the best suggestion so far.

ShadoLight <ettienne.gilbert gmail.com> writes:

On Tuesday, 27 July 2021 at 09:20:25 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Tuesday, 27 July 2021 at 05:07:32 UTC, ag0aep6g wrote:
 On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

 [...]


 module(std.datetime).SysTime

 That's the best suggestion so far.

I agree. But how about, for the sake of consistency (but at the 
cost of some verbosity):

import module(std.datetime).SysTime

deadalnix <deadalnix gmail.com> writes:

On Tuesday, 27 July 2021 at 09:48:03 UTC, ShadoLight wrote:
 On Tuesday, 27 July 2021 at 09:20:25 UTC, Petar Kirov 
 [ZombineDev] wrote:
 On Tuesday, 27 July 2021 at 05:07:32 UTC, ag0aep6g wrote:
 On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

 [...]


 module(std.datetime).SysTime

 That's the best suggestion so far.

 I agree. But how about, for the sake of consistency (but at the 
 cost of some verbosity):

 import module(std.datetime).SysTime

How is that more consistent?

ShadoLight <ettienne.gilbert gmail.com> writes:

On Tuesday, 27 July 2021 at 10:55:48 UTC, deadalnix wrote:
 On Tuesday, 27 July 2021 at 09:48:03 UTC, ShadoLight wrote:
 On Tuesday, 27 July 2021 at 09:20:25 UTC, Petar Kirov 
 [ZombineDev] wrote:
 On Tuesday, 27 July 2021 at 05:07:32 UTC, ag0aep6g wrote:
 On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

 [...]


 module(std.datetime).SysTime

 That's the best suggestion so far.

 I agree. But how about, for the sake of consistency (but at 
 the cost of some verbosity):

 import module(std.datetime).SysTime

 How is that more consistent?

Oh s**t, you are right; I've forgotten that this was for only for 
inline declarations... ok, scratch that idea. Adding 'import' 
would not only _not be_ consistent, but will look really weird.

Daniel N <no public.email> writes:

On Tuesday, 27 July 2021 at 09:20:25 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Tuesday, 27 July 2021 at 05:07:32 UTC, ag0aep6g wrote:
 On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

 [...]
 import[std.datetime].SysTime
 import{std.datetime}.SysTime
 import std.datetime..SysTime
 import std.datetime::SysTime
 std.datetime::SysTime

 
 import:std.datetime.SysTime

 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.

Daniel N <no public.email> writes:

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

Timon Gehr <timon.gehr gmx.ch> writes:

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.

Zach Tollen <zach mystic.yeah> writes:

On Tuesday, 27 July 2021 at 09:20:25 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Tuesday, 27 July 2021 at 05:07:32 UTC, ag0aep6g wrote:
 On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

 [...]
 import[std.datetime].SysTime
 import{std.datetime}.SysTime
 import std.datetime..SysTime
 import std.datetime::SysTime
 std.datetime::SysTime

 
 import:std.datetime.SysTime

 module(std.datetime).SysTime

 That's the best suggestion so far.

No one suggested:

import.std.datetime:SysTime

Seems concise and grammatically unambiguous.

max haughton <maxhaton gmail.com> writes:

On Sunday, 6 March 2022 at 05:21:12 UTC, Zach Tollen wrote:
 On Tuesday, 27 July 2021 at 09:20:25 UTC, Petar Kirov 
 [ZombineDev] wrote:
 On Tuesday, 27 July 2021 at 05:07:32 UTC, ag0aep6g wrote:
 On 26.07.21 14:55, Andrei Alexandrescu wrote:
 On 7/24/21 3:52 PM, qxi wrote:

 [...]
 import[std.datetime].SysTime
 import{std.datetime}.SysTime
 import std.datetime..SysTime
 import std.datetime::SysTime
 std.datetime::SysTime

 
 import:std.datetime.SysTime

 module(std.datetime).SysTime

 That's the best suggestion so far.

 No one suggested:

 import.std.datetime:SysTime

 Seems concise and grammatically unambiguous.

`import.identifier` may be grammatically unambiguous but is 
potentially the opposite of that for the humans.

Visual noise is underrated - *code* should be concise but syntax 
should be loud.

Zach Tollen <zach mystic.yeah> writes:

On Sunday, 6 March 2022 at 06:06:59 UTC, max haughton wrote:
 On Sunday, 6 March 2022 at 05:21:12 UTC, Zach Tollen wrote:
 No one suggested:

 import.std.datetime:SysTime

 Seems concise and grammatically unambiguous.

 `import.identifier` may be grammatically unambiguous but is 
 potentially the opposite of that for the humans.

 Visual noise is underrated - *code* should be concise but 
 syntax should be loud.

I agree, except that syntax highlighters could easily make this 
particular syntax loud with distinctive colorings. Even without 
any training they would already be highlighting 'import'. But 
it's a valid point.

Kagamin <spam here.lot> writes:

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

Not sure if it needs to provide access to deeply nested symbols. 
In that case you can just formulate module lookup rules.

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

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.

Paul Backus <snarwin gmail.com> writes:

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.

Daniel N <no public.email> writes:

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.

Paul Backus <snarwin gmail.com> writes:

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.

Atila Neves <atila.neves gmail.com> writes:

On Sunday, 1 August 2021 at 16:03:05 UTC, Daniel N wrote:
 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)
 -> **

Hmm. This could show up in template constraints.

Ogi <ogion.art gmail.com> writes:

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`.

Paul Backus <snarwin gmail.com> writes:

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.

Daniel N <no public.email> writes:

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

rikki cattermole <rikki cattermole.co.nz> writes:

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.

Temtaime <temtaime gmail.com> writes:

On Friday, 23 July 2021 at 13:55:34 UTC, Andrei Alexandrescu 
wrote:
 Mathias Lang just told me the bug preventing inline imports 
 from working has been fixed, so I reopened this:

 https://github.com/dlang/druntime/pull/1756

 I think it's a very useful facility, more clearly so for large 
 projects, and deserves a fair shake of the stick.

 If it works well in practice, a future language proposal could 
 take `_import!"std.datetime".SysTime` to the simpler and better 
 `import(std.datetime).SysTime`. Using it as a library facility 
 seems like a good step.

What an ugly approach.
When one invents "import std;" others have tendance using import 
per every symbol.

Zach Tollen <zach mystic.yeah> writes:

On Sunday, 6 March 2022 at 19:44:07 UTC, Temtaime wrote:
 What an ugly approach.
 When one invents "import std;" others have tendance using 
 import per every symbol.

You should note this thread is 7 months old. I brought it back 
because I thought it should get more attention.