Inline imports redivivus
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
>>> 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.
>> 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] API is not the answer :D Perhaps
something like a first-class `Symbol` type.
More information about the Digitalmars-d