Right now this works:

``D
struct Std
{
  public import std.stdio;
}

void main()
{
  Std.writeln("Nice!");
}
```

I want to use it as an import hygiene idiom but not entirely sure if this behavior can be relied upon (or it is just a side effect of imports being implemented as aliases currently).

On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
> Right now this works:
>
> ``D
> struct Std
> {
>   public import std.stdio;
> }
>
> void main()
> {
>   Std.writeln("Nice!");
> }
> ```
>
> I want to use it as an import hygiene idiom but not entirely sure if this behavior can be relied upon (or it is just a side effect of imports being implemented as aliases currently).

Well, that's pretty much why splitting up a module and putting public imports in its package.d file doesn't break any of the cases where someone types out the full import path when referring to something from that module/package. But I doubt that anyone considered that that would have this effect when you have a scoped import. In fact, to be honest, it never occurred to me that it would be legal to have a scoped, public import. I think that you just hit a weird result of how allowing imports to be put everywhere ended up working.

I confess that I don't particularly like that this is legal (and I think that public imports tend to get a bit hinky because of the fact that they create aliases), and I'm not quite sure how you could use it form "import hygiene," but I also don't see how this could work any other way if scoped, public imports are allowed.

- Jonathan M Davis

On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
> Right now this works:
>
> ``D
> struct Std
> {
>   public import std.stdio;
> }
>
> void main()
> {
>   Std.writeln("Nice!");
> }
> ```
>
> I want to use it as an import hygiene idiom but not entirely sure if this behavior can be relied upon (or it is just a side effect of imports being implemented as aliases currently).

And we're back to namespaces : )

On 08/13/2015 03:42 PM, Jonathan M Davis wrote:
> On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
>> Right now this works:
>>
>> ``D
>> struct Std
>> {
>>   public import std.stdio;
>> }
>>
>> void main()
>> {
>>   Std.writeln("Nice!");
>> }
>> ```
>>
>> I want to use it as an import hygiene idiom but not entirely sure if
>> this behavior can be relied upon (or it is just a side effect of
>> imports being implemented as aliases currently).
>
> Well, that's pretty much why splitting up a module and putting public
> imports in its package.d file doesn't break any of the cases where
> someone types out the full import path when referring to something from
> that module/package. But I doubt that anyone considered that that would
> have this effect when you have a scoped import. In fact, to be honest,
> it never occurred to me that it would be legal to have a scoped, public
> import. I think that you just hit a weird result of how allowing imports
> to be put everywhere ended up working.
>
> I confess that I don't particularly like that this is legal (and I think
> that public imports tend to get a bit hinky because of the fact that
> they create aliases), and I'm not quite sure how you could use it form
> "import hygiene,"

It has nothing to do with the import being public. This works:

---
struct Std{
    import std.stdio;
}
void main(){
    Std.writeln("Nice!");
}
---

(It also works if main and Std are defined in different modules.)

> but I also don't see how this could work any other way
> if scoped, public imports are allowed.
>...

Easy. Just treat aggregate scopes and module scopes differently. (They are treated differently even now: all imports are 'public' in aggregate scopes, but not at module scope.) I think this shouldn't be done though.

In any case, I guess we agree that this idiom should work for public imports, but not for non-public ones (so the current behaviour with non-public imports is accepts-invalid, but Dicebot's code should be fine)?

On 13-Aug-2015 16:56, Timon Gehr wrote:
[snip]
> It has nothing to do with the import being public. This works:
>
> ---
> struct Std{
>      import std.stdio;
> }
> void main(){
>      Std.writeln("Nice!");
> }
> ---
>
> (It also works if main and Std are defined in different modules.)
>
>> but I also don't see how this could work any other way
>> if scoped, public imports are allowed.
>> ...
>
> Easy. Just treat aggregate scopes and module scopes differently. (They
> are treated differently even now: all imports are 'public' in aggregate
> scopes, but not at module scope.) I think this shouldn't be done though.
>
> In any case, I guess we agree that this idiom should work for public
> imports, but not for non-public ones (so the current behaviour with
> non-public imports is accepts-invalid, but Dicebot's code should be fine)?

Agreed, public import case looks legitimate.

-- 
Dmitry Olshansky

As long as imports are not hygienic, this trick is useful. I didn't find it useful in a language with hygienic imports (C#).

On Thursday, 13 August 2015 at 13:44:50 UTC, rsw0x wrote:
> And we're back to namespaces : )

Not really.

This is namespace:

-----
module a;

struct Something
{
  static void foo() {}
}

module b;

import a;

void main() { Something.foo(); }
-----

This is import hygiene:

-----
module a;

void foo() { }

module b;

struct Something
{
    public import a;
}

void main() { Something.foo(); }
-----

Without that you risk breaking the code each time you add new symbol to a library - D module system is completely broken in that regard.

On Thursday, 13 August 2015 at 13:56:24 UTC, Timon Gehr wrote:
> It has nothing to do with the import being public. This works:
>
> ---
> struct Std{
>     import std.stdio;
> }
> void main(){
>     Std.writeln("Nice!");
> }
> ---
>
> (It also works if main and Std are defined in different modules.)

Ah, I thought alias injection is only done for public ones. Same question applies though :)

> In any case, I guess we agree that this idiom should work for public imports, but not for non-public ones (so the current behaviour with non-public imports is accepts-invalid, but Dicebot's code should be fine)?

I am very curious to learn "official" answer :)

On Thursday, 13 August 2015 at 13:42:42 UTC, Jonathan M Davis wrote:
> I confess that I don't particularly like that this is legal (and I think that public imports tend to get a bit hinky because of the fact that they create aliases), and I'm not quite sure how you could use it form "import hygiene," but I also don't see how this could work any other way if scoped, public imports are allowed.

It won't work if you define importing as adding module to internal scope symbol lookup table, without actually adding imported symbols to scope.

On 08/13/2015 05:29 PM, Dicebot wrote:
> On Thursday, 13 August 2015 at 13:44:50 UTC, rsw0x wrote:
>> And we're back to namespaces : )
>
> Not really.
>
> This is namespace:
>
> -----
> module a;
>
> struct Something
> {
>    static void foo() {}
> }
>
> module b;
>
> import a;
>
> void main() { Something.foo(); }
> -----
>
> This is import hygiene:
>
> -----
> module a;
>
> void foo() { }
>
> module b;
>
> struct Something
> {
>      public import a;
> }
>
> void main() { Something.foo(); }
> -----
>
> Without that you risk breaking the code each time you add new symbol to
> a library -

You know about static imports, right?

> D module system is completely broken in that regard.

What's the alternative?