Thread overview
Scoped import bug?
May 09, 2013
Mike Linford
May 09, 2013
Kenji Hara
May 09, 2013
Mike Linford
May 10, 2013
Kenji Hara
May 09, 2013
I'm not sure whether or not I've encountered a bug or whether my understanding of scoped imports is just faulty.

blah.d:

  1 module blah;
  2
  3 version(A)
  4 {
  5    import std.range;
  6 }
  7
  8 struct Blah(R)
  9 {
 10    version(B)
 11    {
 12       import std.range;
 13    }
 14    static assert(isInputRange!R);
 15
 16    void blah(R r)
 17    {
 18       version(C)
 19       {
 20          assert(r.front == 'h');
 21       }
 22    }
 23 }
 24
 25 void main()
 26 {
 27    Blah!string blah;
 28    blah.blah("hello");
 29 }

Results:
rdmd -version=A -version=C blah
Compiles fine. Module-level import works for the static assert on line 14 and the runtime assert on line 20

rdmd -version=B blah
Compiles fine! Struct-level import works for the static assert on line 14

rdmd -version=B -version=C blah
Fails to compile. I get the following error messages:
blah.d(20): Error: no property 'front' for type 'string'
blah.d(27): Error: template instance blah.Blah!(string) error instantiating

So it appears that when my import is at the struct level like line 12 I'm able to use the static assert but *not* the runtime assert. Why cant the function Blah.blah() find the array implementation of front?
May 09, 2013
On Thursday, 9 May 2013 at 05:01:15 UTC, Mike Linford wrote:
> I'm not sure whether or not I've encountered a bug or whether my understanding of scoped imports is just faulty.
>
> blah.d:
>
>   1 module blah;
>   2
>   3 version(A)
>   4 {
>   5    import std.range;
>   6 }
>   7
>   8 struct Blah(R)
>   9 {
>  10    version(B)
>  11    {
>  12       import std.range;
>  13    }
>  14    static assert(isInputRange!R);
>  15
>  16    void blah(R r)
>  17    {
>  18       version(C)
>  19       {
>  20          assert(r.front == 'h');
>  21       }
>  22    }
>  23 }
>  24
>  25 void main()
>  26 {
>  27    Blah!string blah;
>  28    blah.blah("hello");
>  29 }
>
> Results:
> rdmd -version=A -version=C blah
> Compiles fine. Module-level import works for the static assert on line 14 and the runtime assert on line 20
>
> rdmd -version=B blah
> Compiles fine! Struct-level import works for the static assert on line 14
>
> rdmd -version=B -version=C blah
> Fails to compile. I get the following error messages:
> blah.d(20): Error: no property 'front' for type 'string'
> blah.d(27): Error: template instance blah.Blah!(string) error instantiating
>
> So it appears that when my import is at the struct level like line 12 I'm able to use the static assert but *not* the runtime assert. Why cant the function Blah.blah() find the array implementation of front?

This is a known UFCS name look-up issue.
In 2.063dev, the bug is fixed. Please wait the release.

Kenji Hara
May 09, 2013
On Thursday, 9 May 2013 at 09:52:12 UTC, Kenji Hara wrote:
> On Thursday, 9 May 2013 at 05:01:15 UTC, Mike Linford wrote:
>> I'm not sure whether or not I've encountered a bug or whether my understanding of scoped imports is just faulty.
>>
>> blah.d:
>>
>>  1 module blah;
>>  2
>>  3 version(A)
>>  4 {
>>  5    import std.range;
>>  6 }
>>  7
>>  8 struct Blah(R)
>>  9 {
>> 10    version(B)
>> 11    {
>> 12       import std.range;
>> 13    }
>> 14    static assert(isInputRange!R);
>> 15
>> 16    void blah(R r)
>> 17    {
>> 18       version(C)
>> 19       {
>> 20          assert(r.front == 'h');
>> 21       }
>> 22    }
>> 23 }
>> 24
>> 25 void main()
>> 26 {
>> 27    Blah!string blah;
>> 28    blah.blah("hello");
>> 29 }
>>
>> Results:
>> rdmd -version=A -version=C blah
>> Compiles fine. Module-level import works for the static assert on line 14 and the runtime assert on line 20
>>
>> rdmd -version=B blah
>> Compiles fine! Struct-level import works for the static assert on line 14
>>
>> rdmd -version=B -version=C blah
>> Fails to compile. I get the following error messages:
>> blah.d(20): Error: no property 'front' for type 'string'
>> blah.d(27): Error: template instance blah.Blah!(string) error instantiating
>>
>> So it appears that when my import is at the struct level like line 12 I'm able to use the static assert but *not* the runtime assert. Why cant the function Blah.blah() find the array implementation of front?
>
> This is a known UFCS name look-up issue.
> In 2.063dev, the bug is fixed. Please wait the release.
>
> Kenji Hara

Thank you for the explanation. Was this the issue? http://d.puremagic.com/issues/show_bug.cgi?id=6185
May 10, 2013
On Thursday, 9 May 2013 at 18:25:39 UTC, Mike Linford wrote:
> On Thursday, 9 May 2013 at 09:52:12 UTC, Kenji Hara wrote:
>> On Thursday, 9 May 2013 at 05:01:15 UTC, Mike Linford wrote:
>>> I'm not sure whether or not I've encountered a bug or whether my understanding of scoped imports is just faulty.
>>>
>>> blah.d:
>>>
>>> 1 module blah;
>>> 2
>>> 3 version(A)
>>> 4 {
>>> 5    import std.range;
>>> 6 }
>>> 7
>>> 8 struct Blah(R)
>>> 9 {
>>> 10    version(B)
>>> 11    {
>>> 12       import std.range;
>>> 13    }
>>> 14    static assert(isInputRange!R);
>>> 15
>>> 16    void blah(R r)
>>> 17    {
>>> 18       version(C)
>>> 19       {
>>> 20          assert(r.front == 'h');
>>> 21       }
>>> 22    }
>>> 23 }
>>> 24
>>> 25 void main()
>>> 26 {
>>> 27    Blah!string blah;
>>> 28    blah.blah("hello");
>>> 29 }
>>>
>>> Results:
>>> rdmd -version=A -version=C blah
>>> Compiles fine. Module-level import works for the static assert on line 14 and the runtime assert on line 20
>>>
>>> rdmd -version=B blah
>>> Compiles fine! Struct-level import works for the static assert on line 14
>>>
>>> rdmd -version=B -version=C blah
>>> Fails to compile. I get the following error messages:
>>> blah.d(20): Error: no property 'front' for type 'string'
>>> blah.d(27): Error: template instance blah.Blah!(string) error instantiating
>>>
>>> So it appears that when my import is at the struct level like line 12 I'm able to use the static assert but *not* the runtime assert. Why cant the function Blah.blah() find the array implementation of front?
>>
>> This is a known UFCS name look-up issue.
>> In 2.063dev, the bug is fixed. Please wait the release.
>>
>> Kenji Hara
>
> Thank you for the explanation. Was this the issue? http://d.puremagic.com/issues/show_bug.cgi?id=6185

Yes, that's right!

Kenji Hara