> On Feb 22, 2016, at 10:56 AM, Jonathan M Davis <newsgroup.d@jmdavisprog.com> wrote:
> 
> 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.

I think you misunderstood the problem. If you have a local foo declared, then the FQN doesn’t help (as it starts with foo), you need to use a different name that doesn’t conflict, requiring either a renamed import, or using the leaf symbol name.

-Steve

On 22 Feb 2016, at 16:56, Jonathan M Davis via dmd-internals wrote:
> 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.

I wouldn't say it's weird at all. Selective imports conceptually act like an alias for the symbol in your local scope. Accordingly, the FQN of the symbol is "where that alias is":

---
module test;
import std.stdio : writeln;
void main() { test.writeln("foo"); }
---

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

On 22 Feb 2016, at 22:20, Brad Roberts via dmd-internals wrote:
> While I can understand and work with that definition, it's never been the way I've thought of selective import.  I always thought of them as exactly like regular imports with a filter applied. IE, import this module, but just this set of symbols instead of all of them.

I haven't followed the other recent changes all too closely, but I'm under the the impression that they always behaved differently regarding overload/conflict resolution, and still do so right now. For example, `import a; import b : foo; foo();` would work even if `a` also contained `foo()`, while there would normally be a conflict without the selective import.

This is not to say that I'm particularly fond of that difference, though. I'm just pointing out that what you mention has not been a good working model for how selective imports work for quite a long while now – the mismatch is not just a consequence of the latest changes.

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

On 2/22/16 1:40 PM, David Nadlinger via dmd-internals wrote:
> On 22 Feb 2016, at 22:20, Brad Roberts via dmd-internals wrote:
>> While I can understand and work with that definition, it's never been the way I've thought of
>> selective import.  I always thought of them as exactly like regular imports with a filter applied.
>> IE, import this module, but just this set of symbols instead of all of them.
>
> I haven't followed the other recent changes all too closely, but I'm under the the impression that
> they always behaved differently regarding overload/conflict resolution, and still do so right now.
> For example, `import a; import b : foo; foo();` would work even if `a` also contained `foo()`, while
> there would normally be a conflict without the selective import.
>
> This is not to say that I'm particularly fond of that difference, though. I'm just pointing out that
> what you mention has not been a good working model for how selective imports work for quite a long
> while now – the mismatch is not just a consequence of the latest changes.
>
>   — David

I understand and acknowledge that.  However, in my cases (which I admit aren't terribly significant) it's worked out correctly.

What I'm trying to say is how I've expected them to work.  I really don't think tacking on a filter list should be changing the semantics.  A lot of the time I start off with just "import foo" and then later trim that down to "import foo : sym1, sym2, etc" based on what I ended up using.  IMHO, that change should be _trivially_ correct.  And it's actually not given the current (and past) definition.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Monday, February 22, 2016 14:27:28 Brad Roberts via dmd-internals wrote:
> On 2/22/16 1:40 PM, David Nadlinger via dmd-internals wrote:
> > On 22 Feb 2016, at 22:20, Brad Roberts via dmd-internals wrote:
> >> While I can understand and work with that definition, it's never been the way I've thought of selective import.  I always thought of them as exactly like regular imports with a filter applied. IE, import this module, but just this set of symbols instead of all of them.
> >
> > I haven't followed the other recent changes all too closely, but I'm under the the impression that they always behaved differently regarding overload/conflict resolution, and still do so right now. For example, `import a; import b : foo; foo();` would work even if `a` also contained `foo()`, while there would normally be a conflict without the selective import.
> >
> > This is not to say that I'm particularly fond of that difference, though. I'm just pointing out that what you mention has not been a good working model for how selective imports work for quite a long while now – the mismatch is not just a consequence of the latest changes.
> >
> >   — David
>
> I understand and acknowledge that.  However, in my cases (which I admit aren't terribly significant) it's worked out correctly.
>
> What I'm trying to say is how I've expected them to work.  I really don't think tacking on a filter list should be changing the semantics.  A lot of the time I start off with just "import foo" and then later trim that down to "import foo : sym1, sym2, etc" based on what I ended up using.  IMHO, that change should be _trivially_ correct.  And it's actually not given the current (and past) definition.

Yeah. Your understanding and usage matches how I've always thought about them and to some extent at least how they've worked (though the implementation has occasionally had some wonkiness to it that hasn't made it quite that smooth).

But particularly given the implentation, the namespacing of imports gets a bit weird. What I would have normally expected would be that an import makes it so that you can use all of the symbols that it imports in the current scope - either with just their name or their FQN, and if there's a conflict, you're forced to use their FQN. Selective imports then just restrict which symbols get imported from a module (but don't change the semantics otherwise), and static imports are used for those cases where there would be too many symbol conflicts between two or more modules, and you need to force FQN to make it work cleanly. None of that way of thinking about really involves merging namespaces or anything like that. The implementation, on the other hand, seems to be merging lists of symbols together as if they were all in the same module when you import them, and that makes for a very different way for them to function - one that I don't find intuitive at all.

- Jonathan M Davis


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

On Monday, February 22, 2016 12:54:42 Daniel Kozak via dmd-internals wrote:
> 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

Well, if that's the spec, that's the spec (and even if it weren't, if it's what Walter wanted, he could update the spec), but it's totally unintuitive IMHO - and not very user friendly either.

- Jonathan M Davis

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

On Monday, February 22, 2016 12:09:34 Steven Schveighoffer via dmd-internals wrote:
> I think you misunderstood the problem. If you have a local foo declared, then the FQN doesn’t help (as it starts with foo), you need to use a different name that doesn’t conflict, requiring either a renamed import, or using the leaf symbol name.

Well, if you have a conflict like that, I would expect the local symbol to win, and then you use a renamed import to get around the naming conflict. It doesn't require that selective imports not work with FQN. As long as selective imports don't work with FQN, they basically become renaming imports. Like Brad discussed elsewhere in the thread, I've always thought that selective imports just filtered out which symbols got imported and didn't do any renaming. As it is, their job seems overloaded. But clearly, the way imports are implemented really doesn't match how either Brad or I think of them. And IMHO, the way that they are implemented makes it way more confusing than it should be for the user, though I doubt that it's likely we're going to change Walter's mind without a really convincing argument, which is usually very hard to do - especially if his way of looking at the problem is completely different from yours.

- Jonathan M Davis


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

On Tue, Feb 23, 2016 at 9:27 AM, Brad Roberts via dmd-internals <dmd-internals@puremagic.com> wrote:
>
> What I'm trying to say is how I've expected them to work.  I really don't think tacking on a filter list should be changing the semantics.  A lot of the time I start off with just "import foo" and then later trim that down to "import foo : sym1, sym2, etc" based on what I ended up using.  IMHO, that change should be _trivially_ correct.  And it's actually not given the current (and past) definition.
>

This is exactly how I always wanted them to work (and in most cases it's close enough).  I have known they didn't work this way for a fairly long time.

Walter has pointed out many times that D imports work via a simple and
consistent model.  The downside seems to be that it's a model that few
expect...
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 2/22/16 4:36 PM, Daniel Murphy wrote:
> On Tue, Feb 23, 2016 at 9:27 AM, Brad Roberts via dmd-internals
> <dmd-internals@puremagic.com> wrote:
>>
>> What I'm trying to say is how I've expected them to work.  I really don't
>> think tacking on a filter list should be changing the semantics.  A lot of
>> the time I start off with just "import foo" and then later trim that down to
>> "import foo : sym1, sym2, etc" based on what I ended up using.  IMHO, that
>> change should be _trivially_ correct.  And it's actually not given the
>> current (and past) definition.
>>
>
> This is exactly how I always wanted them to work (and in most cases
> it's close enough).  I have known they didn't work this way for a
> fairly long time.
>
> Walter has pointed out many times that D imports work via a simple and
> consistent model.  The downside seems to be that it's a model that few
> expect...

Most of those discussions have been about the look up rules, not the import rules.  They're two distinct operations, where obviously the import rules affect the results of look up.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On Feb 22, 2016, at 6:11 PM, Jonathan M Davis via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> 
> But particularly given the implentation, the namespacing of imports gets a bit weird. What I would have normally expected would be that an import makes it so that you can use all of the symbols that it imports in the current scope - either with just their name or their FQN, and if there's a conflict, you're forced to use their FQN. Selective imports then just restrict which symbols get imported from a module (but don't change the semantics otherwise), and static imports are used for those cases where there would be too many symbol conflicts between two or more modules, and you need to force FQN to make it work cleanly. None of that way of thinking about really involves merging namespaces or anything like that. The implementation, on the other hand, seems to be merging lists of symbols together as if they were all in the same module when you import them, and that makes for a very different way for them to function - one that I don't find intuitive at all.

This exact behavior can be had like this:

static import foo;
import foo: symbol1;

Now symbol1 is mapped to foo.symbol1, and you can also use any FQN from foo.

Note that at the moment selective imports cannot be combined with static, this is an error:

static import foo: symbol1;

We could potentially allow this to be the combination of the above. Note that we currently allow this:

import f = foo : symbol1;

which effectively does the same thing, but renames foo to f for FQN.

I never thought I’d learn so much about D’s import system...

-Steve