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.

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

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.

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.

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?

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!

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

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!