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
