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?

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

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

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

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.

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...)

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

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

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?

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