www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Inline imports redivivus

reply 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.
Jul 23
next sibling parent reply 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
Jul 23
parent reply 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.
Jul 23
parent reply 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...
Jul 24
parent 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
Jul 26
prev sibling next sibling parent reply 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.
Jul 24
parent 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!
Jul 24
prev sibling next sibling parent reply 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.
Jul 24
parent reply 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?
Jul 24
parent 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!
Jul 24
prev sibling parent reply 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
Jul 24
next sibling parent reply 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
Jul 26
next sibling parent 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).
Jul 26
prev sibling next sibling parent reply 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
Jul 26
parent reply 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.
Jul 27
next sibling parent reply 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
Jul 27
parent reply 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?
Jul 27
parent 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.
Jul 27
prev sibling parent reply 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.
Jul 27
next sibling parent 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
Jul 27
prev sibling parent 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.
Jul 27
prev sibling next sibling parent 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.
Jul 27
prev sibling parent reply 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.
Jul 31
parent reply 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.
Aug 01
parent reply 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.
Aug 01
next sibling parent 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.
Aug 01
prev sibling parent 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.
Aug 02
prev sibling parent reply 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`.
Jul 30
parent reply 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.
Jul 30
parent reply 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
Jul 31
parent 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.
Jul 31