masking of module-level functions with local imports

[Jonathan M Davis via Digitalmars-d]

On Thursday, 15 October 2015 at 15:07:37 UTC, Steven 
Schveighoffer wrote:
> 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
> }

Then that changed at some point, or my memory sucks right now. I 
recall there being a bug on it that was closed by Kenji, because 
supporting it caused other problems. So, if that works now, then 
there's hope.

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

This specific issue may not have been, but it seems like every 
time I read a bug related to issues with local imports, local 
imports end up being treated as special for whatever combination 
of reasons. But given the fact that I was wrong about the UFCS 
issue, either my memory on this is suspect at the moment, or they 
changed how they were treating issues like this. Regardless, this 
issue is just plain ugly, and ideally, we really would get the 
situation fixed.

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

That stinks to high heaven.

- Jonathan M Davis