Re: Fully-qualified symbol disambiguation is deprecated???
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
Re: Fully-qualified symbol disambiguation is deprecated???
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?
Re: Fully-qualified symbol disambiguation is deprecated???
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.
Re: Fully-qualified symbol disambiguation is deprecated???
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.
Re: Fully-qualified symbol disambiguation is deprecated???
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
Re: Fully-qualified symbol disambiguation is deprecated???
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
Re: Fully-qualified symbol disambiguation is deprecated???
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?
Re: Fully-qualified symbol disambiguation is deprecated???
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
Re: Fully-qualified symbol disambiguation is deprecated???
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
Re: Fully-qualified symbol disambiguation is deprecated???
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...)
Re: Fully-qualified symbol disambiguation is deprecated???
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.
Re: Fully-qualified symbol disambiguation is deprecated???
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
Re: Fully-qualified symbol disambiguation is deprecated???
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
Re: Fully-qualified symbol disambiguation is deprecated???
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
