Inline imports redivivus

Petar Petar
Mon Jul 26 10:38:44 UTC 2021

On Saturday, 24 July 2021 at 17:52:03 UTC, Andrei Alexandrescu 
> 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:
>>>> 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.


More information about the Digitalmars-d mailing list