What exactly has changed with the import rules? There are now a _ton_ of deprecation messages being printed out when building phobos which are talking about static imports. For instance,

std/string.d(5692): Deprecation: module std.utf is not accessible here, perhaps add 'static import std.utf;'

The corresponding line is

    nextt = std.utf.decode(to, i);

And not only is std.utf imported at the beginning of the function, it's imported explicitly:

    import std.utf : decode;

Does this have something to do with the recent changes to try and deal with local imports not shadowing stuff? In this particular case, there is no local variable named decode, and when decode is used, its full import path is used and not just its name. Is this behavior intended? And what exactly is going on that the compiler suddenly wants lots of static imports?

- Jonathan M Davis

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Sunday, 21 February 2016 at 00:07:38 UTC, Jonathan M Davis wrote:
> What exactly has changed with the import rules? There are now a _ton_ of deprecation messages being printed out when building phobos which are talking about static imports. For instance,
>
> std/string.d(5692): Deprecation: module std.utf is not accessible here, perhaps add 'static import std.utf;'
>
> The corresponding line is
>
>     nextt = std.utf.decode(to, i);
>
> And not only is std.utf imported at the beginning of the function, it's imported explicitly:
>
>     import std.utf : decode;
>
> Does this have something to do with the recent changes to try and deal with local imports not shadowing stuff? In this particular case, there is no local variable named decode, and when decode is used, its full import path is used and not just its name. Is this behavior intended? And what exactly is going on that the compiler suddenly wants lots of static imports?
>
> - Jonathan M Davis

These happened:
https://github.com/D-Programming-Language/dmd/pull/5426 - fix Issue 313 - Fully qualified names bypass private imports

https://github.com/D-Programming-Language/dmd/pull/5445 -fix Issue 10378 - Local imports hide local symbols

I think similar cases were discussed in the comments on those pull requests.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Sunday, February 21, 2016 00:38:20 ZombineDev via dmd-internals wrote:
> These happened: https://github.com/D-Programming-Language/dmd/pull/5426 - fix Issue 313 - Fully qualified names bypass private imports
>
> https://github.com/D-Programming-Language/dmd/pull/5445 -fix Issue 10378 - Local imports hide local symbols
>
> I think similar cases were discussed in the comments on those pull requests.

Wow. All of the comments in the PRs that you guys linked to make this look like quite a mess, even if we're ultimately better off. It does seem pretty messed up to me though that you can't use a symbol's full import path when you've imported it selectively. I would have expected to still be able to do that, just not have access to any of the other symbols in the module that it's in - unless they too were selectively imported.

- Jonathan M Davis

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On Feb 21, 2016, at 2:47 AM, Jonathan M Davis via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> On Sunday, February 21, 2016 00:38:20 ZombineDev via dmd-internals wrote:
>> These happened: https://github.com/D-Programming-Language/dmd/pull/5426 - fix Issue 313 - Fully qualified names bypass private imports
>> 
>> https://github.com/D-Programming-Language/dmd/pull/5445 -fix Issue 10378 - Local imports hide local symbols
>> 
>> I think similar cases were discussed in the comments on those pull requests.
> 
> Wow. All of the comments in the PRs that you guys linked to make this look like quite a mess, even if we're ultimately better off. It does seem pretty messed up to me though that you can't use a symbol's full import path when you've imported it selectively. I would have expected to still be able to do that, just not have access to any of the other symbols in the module that it's in - unless they too were selectively imported.

The key comment in those PRs: https://github.com/D-Programming-Language/dmd/pull/5426#issuecomment-181589047

A start to fix them: https://github.com/D-Programming-Language/phobos/pull/4015

-Steve
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Sunday, February 21, 2016 19:08:37 Steven Schveighoffer via dmd-internals wrote:
>
> > On Feb 21, 2016, at 2:47 AM, Jonathan M Davis via dmd-internals <dmd-internals@puremagic.com> wrote:
> > Wow. All of the comments in the PRs that you guys linked to make this look
> > like quite a mess, even if we're ultimately better off. It does seem pretty
> > messed up to me though that you can't use a symbol's full import path when
> > you've imported it selectively. I would have expected to still be able to do
> > that, just not have access to any of the other symbols in the module that
> > it's in - unless they too were selectively imported.
>
> The key comment in those PRs: https://github.com/D-Programming-Language/dmd/pull/5426#issuecomment-181589047

Well, while I can see why from an implementation perspective, it makes sense to say that when you have

import foo.bar : baz;

you haven't really imported the module, so foo.bar.baz isn't legit, and you have to say baz, from a usability perspective, nobody is going to expect that foo.bar.baz suddenly is just baz and not foo.bar.baz, because you imported it with a selective imports. I think that the normal expectation is that

import foo.bar;

and

import foo.bar : baz;

are identical with regards to baz; they just don't import the rest of foo.bar. So, the new behavior is going to be confusing, and a number of folks have been pushing selective local imports as the way to do things for a while, so a lot of folks are using them, and I fully expect that there are plenty of cases where the imported symbol is then used via its full import path for clarity. The number of deprecation messages in Phobos is a great example of that.

So, from a usability standpoint, this aspect of the change definitely seems negative. Personally, it encourages me to not do selective imports if they're going to be picky about whether the full import path is used or not.

> A start to fix them: https://github.com/D-Programming-Language/phobos/pull/4015

Well, thanks for that. Given the number of deprecation messages, we definitely have a lot of code to change. But I can't help think that we shouldn't need to make the change.

- Jonathan M Davis

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Sunday, 21 February 2016 at 07:47:16 UTC, Jonathan M Davis wrote:
> On Sunday, February 21, 2016 00:38:20 ZombineDev via dmd-internals wrote:
>> These happened: https://github.com/D-Programming-Language/dmd/pull/5426 - fix Issue 313 - Fully qualified names bypass private imports
>>
>> https://github.com/D-Programming-Language/dmd/pull/5445 -fix Issue 10378 - Local imports hide local symbols
>>
>> I think similar cases were discussed in the comments on those pull requests.
>
> Wow. All of the comments in the PRs that you guys linked to make this look like quite a mess, even if we're ultimately better off. It does seem pretty messed up to me though that you can't use a symbol's full import path when you've imported it selectively. I would have expected to still be able to do that, just not have access to any of the other symbols in the module that it's in - unless they too were selectively imported.
>
> - Jonathan M Davis

From official D documentation (Selective Imports):
Specific symbols can be exclusively imported from a module and bound into the current namespace.

std.stdio.writeln("hello!"); // error, std is undefined

So they never has been intended to works with FQN



_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On Feb 22, 2016, at 7:04 AM, Jonathan M Davis via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> On Sunday, February 21, 2016 19:08:37 Steven Schveighoffer via dmd-internals wrote:
>> 
>> The key comment in those PRs: https://github.com/D-Programming-Language/dmd/pull/5426#issuecomment-181589047
> 
> Well, while I can see why from an implementation perspective, it makes sense to say that when you have
> 
> import foo.bar : baz;
> 
> you haven't really imported the module, so foo.bar.baz isn't legit, and you have to say baz, from a usability perspective, nobody is going to expect that foo.bar.baz suddenly is just baz and not foo.bar.baz, because you imported it with a selective imports.

Like the comment says, however, what if you have a local foo symbol defined? The compiler is going to complain, or silently choose one (I think with the new lookup rules, it would choose the local module’s name).

With Phobos, this isn’t strictly an issue, since we have no local symbols named std. But I could see lots of problems with other libraries.

-Steve
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 22 Feb 2016, at 13:04, Jonathan M Davis via dmd-internals wrote:
> […] nobody is going to expect
> that foo.bar.baz suddenly is just baz and not foo.bar.baz

I guess that depends heavily on what your mental model of imports is. For me, it always was the other way round – I was surprised that the fully qualified names were also in scope for selective imports, and considered it bad style to use them.

> Personally, it encourages me to not do selective imports if
> they're going to be picky about whether the full import path is used or not.

If you are going to use the fully qualified names anyway there is no benefit to selective imports. Just use a static import instead.

 — David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Monday, February 22, 2016 09:59:31 Steven Schveighoffer via dmd-internals wrote:
>
> > On Feb 22, 2016, at 7:04 AM, Jonathan M Davis via dmd-internals <dmd-internals@puremagic.com> wrote:
> >
> > On Sunday, February 21, 2016 19:08:37 Steven Schveighoffer via dmd-internals wrote:
> >>
> >> The key comment in those PRs: https://github.com/D-Programming-Language/dmd/pull/5426#issuecomment-181589047
> >
> > Well, while I can see why from an implementation perspective, it makes sense to say that when you have
> >
> > import foo.bar : baz;
> >
> > you haven't really imported the module, so foo.bar.baz isn't legit, and you have to say baz, from a usability perspective, nobody is going to expect that foo.bar.baz suddenly is just baz and not foo.bar.baz, because you imported it with a selective imports.
>
> Like the comment says, however, what if you have a local foo symbol defined? The compiler is going to complain, or silently choose one (I think with the new lookup rules, it would choose the local module’s name).
>
> With Phobos, this isn’t strictly an issue, since we have no local symbols named std. But I could see lots of problems with other libraries.

In that case, using static imports makes sense. They're there to avoid name conflicts when importing a module. But having a symbol be usable and yet not being able to use its FQN is just plain weird. Given what was said about the compiler implementation, I can understand why it would end up that way, but it's very unintuitive, and personally, it makes it so that I'm not particularly interested in using selective imports. I would not have expected a symbol to ever lose its FQN. It's not like it changes where it was declared based on how it was imported, much as the compiler implementation likes to act that way sometimes.

- Jonathan M Davis


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

It has been always error to use selective import with FQN. TDPL and
documentation says that. And it makes sense from my POV
Dne 22. 2. 2016 16:58 napsal uživatel "Jonathan M Davis via dmd-internals" <
dmd-internals@puremagic.com>:

> On Monday, February 22, 2016 09:59:31 Steven Schveighoffer via dmd-internals wrote:
> >
> > > On Feb 22, 2016, at 7:04 AM, Jonathan M Davis via dmd-internals <
> dmd-internals@puremagic.com> wrote:
> > >
> > > On Sunday, February 21, 2016 19:08:37 Steven Schveighoffer via
> dmd-internals wrote:
> > >>
> > >> The key comment in those PRs:
> https://github.com/D-Programming-Language/dmd/pull/5426#issuecomment-181589047
> > >
> > > Well, while I can see why from an implementation perspective, it makes
> sense
> > > to say that when you have
> > >
> > > import foo.bar : baz;
> > >
> > > you haven't really imported the module, so foo.bar.baz isn't legit,
> and you
> > > have to say baz, from a usability perspective, nobody is going to
> expect
> > > that foo.bar.baz suddenly is just baz and not foo.bar.baz, because you imported it with a selective imports.
> >
> > Like the comment says, however, what if you have a local foo symbol
> defined? The compiler is going to complain, or silently choose one (I think with the new lookup rules, it would choose the local module’s name).
> >
> > With Phobos, this isn’t strictly an issue, since we have no local
> symbols named std. But I could see lots of problems with other libraries.
>
> In that case, using static imports makes sense. They're there to avoid name
> conflicts when importing a module. But having a symbol be usable and yet
> not
> being able to use its FQN is just plain weird. Given what was said about
> the
> compiler implementation, I can understand why it would end up that way, but
> it's very unintuitive, and personally, it makes it so that I'm not
> particularly interested in using selective imports. I would not have
> expected a symbol to ever lose its FQN. It's not like it changes where it
> was declared based on how it was imported, much as the compiler
> implementation likes to act that way sometimes.
>
> - Jonathan M Davis
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals