www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Fully-qualified symbol disambiguation is deprecated???

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
I'm getting deprecation messages ("Package...not accessible here, 
perhaps add static import") when simply trying to use fully-qualified 
symbol names to disambiguate a symbol. Is this really intended?
Sep 08 2016
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/08/2016 03:02 PM, Nick Sabalausky wrote:

 I'm getting deprecation messages ("Package...not accessible here,
 perhaps add static import") when simply trying to use fully-qualified
 symbol names to disambiguate a symbol. Is this really intended?


Sounds like the recent changes in 2.071:

   http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/

Ali
Sep 08 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/8/16 6:02 PM, Nick Sabalausky wrote:

 I'm getting deprecation messages ("Package...not accessible here,
 perhaps add static import") when simply trying to use fully-qualified
 symbol names to disambiguate a symbol. Is this really intended?


Yes.

It's difficult to attribute the message without context, though. And 
there are still some straggling bugs which cause this message to be 
erroneously printed.

I posted an article on this: 
http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/

-Steve
Sep 08 2016
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/8/16 6:13 PM, Steven Schveighoffer wrote:

 On 9/8/16 6:02 PM, Nick Sabalausky wrote:

 I'm getting deprecation messages ("Package...not accessible here,
 perhaps add static import") when simply trying to use fully-qualified
 symbol names to disambiguate a symbol. Is this really intended?


 Yes.


I should amend this emphatic reply to say "in certain cases". FQN is 
still supported. But many times, you aren't actually importing a symbol 
when you thought you were (and it just worked).

-Steve
Sep 08 2016
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

 On 9/8/16 6:02 PM, Nick Sabalausky wrote:

 I'm getting deprecation messages ("Package...not accessible here,
 perhaps add static import") when simply trying to use fully-qualified
 symbol names to disambiguate a symbol. Is this really intended?


 Yes.

 It's difficult to attribute the message without context, though.


Yea, unfortunately I don't have it narrowed down to a test case, atm.


 And
 there are still some straggling bugs which cause this message to be
 erroneously printed.


I'm pretty sure I've hit one of those :( Can't be certain though until I 
examine my specific case further.
Sep 08 2016
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/08/2016 06:22 PM, Nick Sabalausky wrote:

 On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

 And
 there are still some straggling bugs which cause this message to be
 erroneously printed.


 I'm pretty sure I've hit one of those :( Can't be certain though until I
 examine my specific case further.


Oh, although the whole "selective imports don't import the FQN" is a big 
surprise to me. I think at least some of the messages I hit were from 
that. (Can't say I'm a big fan of that particular one, but meh, whatever...)
Sep 08 2016
next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, September 08, 2016 18:26:40 Nick Sabalausky via Digitalmars-d-
learn wrote:

 On 09/08/2016 06:22 PM, Nick Sabalausky wrote:

 On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

 And
 there are still some straggling bugs which cause this message to be
 erroneously printed.


 I'm pretty sure I've hit one of those :( Can't be certain though until I
 examine my specific case further.


 Oh, although the whole "selective imports don't import the FQN" is a big
 surprise to me. I think at least some of the messages I hit were from
 that. (Can't say I'm a big fan of that particular one, but meh, whatever...)


Yeah. I _really_ don't like that part, but unfortunately, we're stuck with
it.

- Jonathan M Davis
Sep 08 2016
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/8/16 6:26 PM, Nick Sabalausky wrote:

 On 09/08/2016 06:22 PM, Nick Sabalausky wrote:

 On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

 And
 there are still some straggling bugs which cause this message to be
 erroneously printed.


 I'm pretty sure I've hit one of those :( Can't be certain though until I
 examine my specific case further.


 Oh, although the whole "selective imports don't import the FQN" is a big
 surprise to me. I think at least some of the messages I hit were from
 that. (Can't say I'm a big fan of that particular one, but meh,
 whatever...)


That is probably a more controversial issue. But I can see why it was done.

What I do agree with is that if you import x.y: z, then you shouldn't be 
able to use FQN x.y.foo.

-Steve
Sep 09 2016
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/08/2016 03:22 PM, Nick Sabalausky wrote:

 On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

 On 9/8/16 6:02 PM, Nick Sabalausky wrote:

 I'm getting deprecation messages ("Package...not accessible here,
 perhaps add static import") when simply trying to use fully-qualified
 symbol names to disambiguate a symbol. Is this really intended?


 Yes.

 It's difficult to attribute the message without context, though.


 Yea, unfortunately I don't have it narrowed down to a test case, atm.


 And
 there are still some straggling bugs which cause this message to be
 erroneously printed.


 I'm pretty sure I've hit one of those :( Can't be certain though until I
 examine my specific case further.


Do you have __traits(allMembers) and __traits(getMember) in your code? 
There is this bug (fix of which caused other trouble and controversy :) ):

   https://issues.dlang.org/show_bug.cgi?id=15907

Ali
Sep 08 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/08/2016 06:22 PM, Nick Sabalausky wrote:

 On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

 On 9/8/16 6:02 PM, Nick Sabalausky wrote:

 I'm getting deprecation messages ("Package...not accessible here,
 perhaps add static import") when simply trying to use fully-qualified
 symbol names to disambiguate a symbol. Is this really intended?


 Yes.

 It's difficult to attribute the message without context, though.


 Yea, unfortunately I don't have it narrowed down to a test case, atm.


 And
 there are still some straggling bugs which cause this message to be
 erroneously printed.


 I'm pretty sure I've hit one of those :( Can't be certain though until I
 examine my specific case further.


Turns out I didn't hit one of those bugs, but one of the problems I was 
hitting was the old problem where package.d completely fucks any and all 
attempts at using a FQN. Worked around with local selective renamed imports.

FQN used to be a real killer feature of D: To deal with name collisions, 
you could *ALWAYS* replace a visible symbol with it's FQN and it would 
*just work*. But now with package.d, UFCS, and 2.071's selective import 
behavior, that benefit's pretty much been shot to hell.
Sep 09 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/9/16 11:32 AM, Nick Sabalausky wrote:

 On 09/08/2016 06:22 PM, Nick Sabalausky wrote:

 On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

 On 9/8/16 6:02 PM, Nick Sabalausky wrote:

 I'm getting deprecation messages ("Package...not accessible here,
 perhaps add static import") when simply trying to use fully-qualified
 symbol names to disambiguate a symbol. Is this really intended?


 Yes.

 It's difficult to attribute the message without context, though.


 Yea, unfortunately I don't have it narrowed down to a test case, atm.


 And
 there are still some straggling bugs which cause this message to be
 erroneously printed.


 I'm pretty sure I've hit one of those :( Can't be certain though until I
 examine my specific case further.


 Turns out I didn't hit one of those bugs, but one of the problems I was
 hitting was the old problem where package.d completely fucks any and all
 attempts at using a FQN. Worked around with local selective renamed
 imports.


Is this a bugzilla issue?


 FQN used to be a real killer feature of D: To deal with name collisions,
 you could *ALWAYS* replace a visible symbol with it's FQN and it would
 *just work*. But now with package.d, UFCS, and 2.071's selective import
 behavior, that benefit's pretty much been shot to hell.


FQN is in the eye of the importer. It's up to the charter of the import 
to define how another module's symbols are imported. FQN can be one way 
to deal with collisions. There are other options too.

One thing I would like to see is a single-line replacement for the 
original behavior of selective imports. Right now, you have to do 2 lines:

import a.b: c, d;
static import a.b;

One grammar that is currently disallowed (i.e. available) is:

static import a.b: c, d;

-Steve
Sep 12 2016
prev sibling parent reply pineapple <meapineapple gmail.com> writes:
On Thursday, 8 September 2016 at 22:13:26 UTC, Steven 
Schveighoffer wrote:

 I posted an article on this: 
 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/

 -Steve


Regarding that article:


 Another import-related bug fix is to prevent unintentional 
 hijacking of symbols inside a scoped import. Such imports are 
 not at module level, and import inside a function or other 
 scope.


I've actually never been able to get imports to work if I place 
them inside a function. They'll work fine compiling that single 
module which has the import-in-a-function, but as soon as I 
import that module from somewhere else I'll hit compile errors. 
Is this a known bug or am I just uniquely screwed?
Sep 09 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/9/16 5:38 AM, pineapple wrote:

 On Thursday, 8 September 2016 at 22:13:26 UTC, Steven Schveighoffer wrote:

 I posted an article on this:
 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


 Regarding that article:


 Another import-related bug fix is to prevent unintentional hijacking
 of symbols inside a scoped import. Such imports are not at module
 level, and import inside a function or other scope.


 I've actually never been able to get imports to work if I place them
 inside a function. They'll work fine compiling that single module which
 has the import-in-a-function, but as soon as I import that module from
 somewhere else I'll hit compile errors. Is this a known bug or am I just
 uniquely screwed?


Can you demonstrate the issue? I have never heard of this. imports 
should work when done inside a function.

-Steve
Sep 09 2016
parent reply pineapple <meapineapple gmail.com> writes:
On Friday, 9 September 2016 at 11:54:42 UTC, Steven Schveighoffer 
wrote:

 Can you demonstrate the issue? I have never heard of this. 
 imports should work when done inside a function.

 -Steve


Tried and failed to reproduce with a simple example, but any time 
I've tried doing it in the code I'm working on I get Symbol 
Undefined errors which I had to fix by moving imports out of 
struct/class methods.
Sep 09 2016
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/09/2016 12:35 PM, pineapple wrote:

 On Friday, 9 September 2016 at 11:54:42 UTC, Steven Schveighoffer wrote:

 Can you demonstrate the issue? I have never heard of this. imports
 should work when done inside a function.

 -Steve


 Tried and failed to reproduce with a simple example, but any time I've
 tried doing it in the code I'm working on I get Symbol Undefined errors
 which I had to fix by moving imports out of struct/class methods.


Are those maybe linker errors you're getting? It sounds like maybe the 
build system you're using, rather than the compiler, for some reason is 
rudimentary and isn't using the compiler itself to find dependencies. 
What build tool are you using?
Sep 09 2016