Fully-qualified symbol disambiguation is deprecated???

[Steven Schveighoffer via Digitalmars-d-learn]

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