Code:
static import std.signals;

class A {
    mixin std.signals.Signal!();
}

When I try to compile it, there is a lot of confusing messages about errors in
std/signals.d
If I remove "static" from the first line, all works ok.

Vladimir Bezhenar wrote:
> Code:
> static import std.signals;
> 
> class A {
>     mixin std.signals.Signal!();
> }
> 
> When I try to compile it, there is a lot of confusing messages about errors in
> std/signals.d
> If I remove "static" from the first line, all works ok.

I don't know if Walter would call that "a bug"; it's consistent with the specs but IMHO it's a bug. (If it's caused by what I think it is ..)

you're instantiating that template in this file, so the declarations in that template are "copied over" to your file, i.e. the scope where the mixin happens; but these declaration have dependencies, and these dependencies are not available in your file because your import is static.

I'm not sure if that makes any sense at all.

example:
a.d:
----------
struct A { .. }

template M()
{
   A a; //this declaration depends on the declaration of struct A
}

----------

b.d:
---------
static import a;

mixin a.M!(); //problem, struct A cannot be found from this scope (because the import is static)
------------

Hasan Aljudy wrote:
> 
> 
> Vladimir Bezhenar wrote:
>> Code:
>> static import std.signals;
>>
>> class A {
>>     mixin std.signals.Signal!();
>> }
>>
>> When I try to compile it, there is a lot of confusing messages about errors in
>> std/signals.d
>> If I remove "static" from the first line, all works ok.
> 
> I don't know if Walter would call that "a bug"; it's consistent with the specs but IMHO it's a bug. (If it's caused by what I think it is ..)
> 
> you're instantiating that template in this file, so the declarations in that template are "copied over" to your file, i.e. the scope where the mixin happens; but these declaration have dependencies, and these dependencies are not available in your file because your import is static.
> 
> I'm not sure if that makes any sense at all.
> 
> example:
> a.d:
> ----------
> struct A { .. }
> 
> template M()
> {
>    A a; //this declaration depends on the declaration of struct A
> }
> 
> ----------
> 
> b.d:
> ---------
> static import a;
> 
> mixin a.M!(); //problem, struct A cannot be found from this scope (because the import is static)
> ------------

I'm sure you are most likely correct that this is the problem he was experiencing.  In fact, I think I suggested before that the imports within std.signals should themselves most likely be static.  Would've prevented this problem, especially if they were public static.  :)

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> Hasan Aljudy wrote:
>>
>>
>> Vladimir Bezhenar wrote:
>>> Code:
>>> static import std.signals;
>>>
>>> class A {
>>>     mixin std.signals.Signal!();
>>> }
>>>
>>> When I try to compile it, there is a lot of confusing messages about errors in
>>> std/signals.d
>>> If I remove "static" from the first line, all works ok.
>>
>> I don't know if Walter would call that "a bug"; it's consistent with the specs but IMHO it's a bug. (If it's caused by what I think it is ..)
>>
>> you're instantiating that template in this file, so the declarations in that template are "copied over" to your file, i.e. the scope where the mixin happens; but these declaration have dependencies, and these dependencies are not available in your file because your import is static.
>>
>> I'm not sure if that makes any sense at all.
>>
>> example:
>> a.d:
>> ----------
>> struct A { .. }
>>
>> template M()
>> {
>>    A a; //this declaration depends on the declaration of struct A
>> }
>>
>> ----------
>>
>> b.d:
>> ---------
>> static import a;
>>
>> mixin a.M!(); //problem, struct A cannot be found from this scope (because the import is static)
>> ------------
> 
> I'm sure you are most likely correct that this is the problem he was experiencing.  In fact, I think I suggested before that the imports within std.signals should themselves most likely be static.  Would've prevented this problem, especially if they were public static.  :)
> 
> -- Chris Nicholson-Sauls

But I think that wouldn't work if someone was to do something like:

import sslot = std.signal : Sig = Signal;

Vladimir Bezhenar wrote:
> Code:
> static import std.signals;
> 
> class A {
>     mixin std.signals.Signal!();
> }
> 
> When I try to compile it, there is a lot of confusing messages about errors in
> std/signals.d
> If I remove "static" from the first line, all works ok.

I filed this as a bug a while back, which Walter declared 'invalid'. This is 'works as designed' behavior.  I've just resubmitted it as an enhancement request though, as per his suggestion, so if you have something to add about this issue, add it there.

closed bug:  http://d.puremagic.com/issues/show_bug.cgi?id=506
open enhancment: http://d.puremagic.com/issues/show_bug.cgi?id=625


--bb

Hasan Aljudy wrote:
> 
> 
> Chris Nicholson-Sauls wrote:
>> Hasan Aljudy wrote:
>>>
>>>
>>> Vladimir Bezhenar wrote:
>>>> Code:
>>>> static import std.signals;
>>>>
>>>> class A {
>>>>     mixin std.signals.Signal!();
>>>> }
>>>>
>>>> When I try to compile it, there is a lot of confusing messages about errors in
>>>> std/signals.d
>>>> If I remove "static" from the first line, all works ok.
>>>
>>> I don't know if Walter would call that "a bug"; it's consistent with the specs but IMHO it's a bug. (If it's caused by what I think it is ..)
>>>
>>> you're instantiating that template in this file, so the declarations in that template are "copied over" to your file, i.e. the scope where the mixin happens; but these declaration have dependencies, and these dependencies are not available in your file because your import is static.
>>>
>>> I'm not sure if that makes any sense at all.
>>>
>>> example:
>>> a.d:
>>> ----------
>>> struct A { .. }
>>>
>>> template M()
>>> {
>>>    A a; //this declaration depends on the declaration of struct A
>>> }
>>>
>>> ----------
>>>
>>> b.d:
>>> ---------
>>> static import a;
>>>
>>> mixin a.M!(); //problem, struct A cannot be found from this scope (because the import is static)
>>> ------------
>>
>> I'm sure you are most likely correct that this is the problem he was experiencing.  In fact, I think I suggested before that the imports within std.signals should themselves most likely be static.  Would've prevented this problem, especially if they were public static.  :)
>>
>> -- Chris Nicholson-Sauls
> 
> But I think that wouldn't work if someone was to do something like:
> 
> import sslot = std.signal : Sig = Signal;

As long as the code that is barfing on symbols with the static import scenario doesn't itself make any referance to std.signal.Signal it should work fine... but admittedly, I haven't tested this myself...

-- Chris Nicholson-Sauls