www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Scoped import bug?

reply "Mike Linford" <mike.linford gmail.com> writes:
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 08 2013
parent reply "Kenji Hara" <k.hara.pg gmail.com> writes:
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
parent reply "Mike Linford" <mike.linford gmail.com> writes:
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 09 2013
parent "Kenji Hara" <k.hara.pg gmail.com> writes:
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
May 09 2013