Inline imports redivivus

[Zach Tollen]

Thanks for your reply!

On Friday, 11 March 2022 at 13:01:43 UTC, Ali Çehreli wrote:
> On 3/10/22 22:48, Zach Tollen wrote:
> > ::std.datetime:SysTime          // if we put the `::` first
> it becomes
> > viable
> >                                  // it's a different version
> of the `$`
> >
>
> Perhaps a second meaning for ..? And is : really necessary? So, 
> would the following work?
>
>   ..std.datetime.Systime

If you used `..` here you would always have to add whitespace in 
an ordinary call chain, to avoid ambiguous lexing, so it's not 
good:
```d
{
    x = normal.call.chain;
    x = dotdot.call. ..modname:chain; // space necessary to avoid 
lexing as `...`
}
```

As far as not wanting to use `:` the issue is also ambiguity. In 
DIP1005, written a few years ago by Andrei Alexandrescu, this 
exact question was addressed [1]. Quote:
```d
void process(import.std.stdio.File input);
struct Buffered(Range) if (import.std.range.isInputRange!Range)
{
     ...
}
```
"Such an option has an ambiguity problem shown by Timon Gehr: is 
import.std.range.isInputRange looking up symbol isInputRange in 
module/package std.range, or the symbol range.isInputRange (e.g. 
a struct member) in module/package std?"

> - Single dot already means "this module".
> - Two dots may mean "outside of this module".

If we can find a starting token (other than `$`) which allows the 
construct to seem familiar and which has no other problems, I'm 
all for it. `::` has been suggested. I believe also `:` would 
work:
```d
auto x = :std.datetime:Systime;
```
Technically, `:` would not cause grammatical ambiguity. But I 
don't think it's visually distinct enough, and the error messages 
you get if you don't type it correctly would be confused with the 
compiler's other error messages for `:` syntaxes.

At minimum, `$` as in `$fully.qualified:symbol` announces its 
presence boldly, as if to challenge the language designer to come 
up with a better use of the `$` token. :-)

> Going off topic and without knowing whether this topic has 
> already been brought up, should inline imports automatically be 
> made available to the callers of functions? Arbitrarily using 
> the $ syntax:
>
> module my.module;
>
> void foo($bar:SomeSymbol a) {
> }
>
> Since 'foo' is public to the users of my.module, should we 
> expect the users be able to call 'foo' without importing 
> SomeSymbol separately themselves?

I would say no. As a one-use import, it doesn't spread its import 
anywhere but to itself. But the caller can just call using 
`foo($bar:SomeSymbol(value))` if they don't feel like importing 
the module either.

> And the next question may be what if SomeSymbol is accessible 
> to my.module but not to my users (e.g. if it's 'package'). So, 
> if it should automatically be imported for the users, should 
> SomeSymbol automatically be raised to 'public' status for the 
> users of 'foo'?

Again, no. If a function parameter requires a privately defined 
structure, then that function is not meant to be called by things 
which don't have access to that structure.

Inline imports are semantically no different from symbols which 
had their modules imported separately. I'm pretty sure issues of 
privacy won't be affected by this.

- Zach

[1] 
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1005.md#syntactic-alternatives