masking of module-level functions with local imports

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 15 08:07:37 PDT 2015


On 10/15/15 10:31 AM, Jonathan M Davis wrote:
> On Thursday, 15 October 2015 at 14:13:34 UTC, Steven Schveighoffer wrote:
>> Nobody else finds this to be an issue? Should we just close bugs like
>> 15179 with "sorry, please import everything you need local or global,
>> too bad the phobos/druntime changes broke your code"?
>
> It's an issue, but I confess that I kind of gave up on local imports
> working correctly when they refused to make UFCS work with local imports

Huh? UFCS works with local imports.

void main()
{
    import std.conv: to;
    import std.stdio: writeln;
    1.to!string.writeln; // works
}

> (though IIRC, that was specifically Kenji and not Walter - I don't know
> where Walter sits on it). I really don't think that local imports should
> be any different from imports at the module level except for the fact
> that they don't affect stuff at outer scopes, but I gather that the
> implementation doesn't jive well with that, and that's led to refusals
> to make imports work the same at all levels when various issues like
> this have come up.

Do you have links to these refusals? I didn't know this was considered 
and rejected.

> That being said, D's module system does tend to have issues when adding
> symbols to druntime, Phobos, or any library that someone else might use.
> So, on some level, we're always going to have this problem, but we can
> and should do better with that then we do (e.g. making it so that
> private symbols never conflict with anything when the module that
> they're in is imported).

Any time we duplicate any symbol name between 2 modules, we can cause 
regressions. If we don't fix this, either we never name any symbol the 
same thing in 2 modules, or we simply close as invalid any bug that 
depends on using local vs. global imports.

I'm OK with the latter, the former is likely impossible. But some 
official position should be taken here.

And the requirement to import the module you are currently in, just 
smells. A lot.

-Steve


More information about the Digitalmars-d mailing list