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

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.

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.

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?

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