On Saturday, January 05, 2013 21:39:13 d coder wrote:
> 1. std.string is exposing "count" (and some other functions) from std.algorithm. I think this should be a bug since count is not listed as a method in the std.string documentation.

It's not a bug. It was added as a public import in std.string as part of the transition process for moving some functions between modules (I believe that count _used_ to be a function in std.string), and it _would_ have been removed already except that when it came time to remove it, Andrei didn't want to for fear of breaking code. So, it may or may not end up being removed at some point.

> 2. Now the function from std.algorithm that becomes visible, shadows the local argument count. Is this expected behavior? If not, has it already been reported as a bug? At the minimum I expect better error message here.

_That_ is definitely a bug. Symbols local to a module are supposed to have precedence over imported symbols, so there shouldn't be any symbol conflicts when using a symbol local to a module, and local variables have precedence over module-level symbols, so it's definitely broken if a local import causes conflicts with a local variable. I have no idea if it's been reported though. You'd have to search bugzilla:

http://d.puremagic.com/issues

- Jonathan M Davis

On Sunday, 6 January 2013 at 00:49:06 UTC, Jonathan M Davis wrote:
>
>> 2. Now the function from std.algorithm that becomes visible, shadows the
>> local argument count. Is this expected behavior? If not, has it already
>> been reported as a bug? At the minimum I expect better error message here.
>
> _That_ is definitely a bug. Symbols local to a module are supposed to have
> precedence over imported symbols, so there shouldn't be any symbol conflicts
> when using a symbol local to a module, and local variables have precedence
> over module-level symbols, so it's definitely broken if a local import causes
> conflicts with a local variable. I have no idea if it's been reported though.
> You'd have to search bugzilla:
>
> http://d.puremagic.com/issues
>
> - Jonathan M Davis

There is no shadowing, if the import statement is outside the function

void main() {                   // 1
 foo(4);                       // 2
}                               // 3
import std.string;               // 4
void foo(int count) {           // 5
             // 6
 format("%s", count);          // 7
}

This means that the local variable still has precedence over the imported one. However, if it is inside the function the imported variable is treated as local, as in "last one in closes the door"?

On Sunday, January 06, 2013 15:15:42 Chris wrote:
> This means that the local variable still has precedence over the imported one. However, if it is inside the function the imported variable is treated as local, as in "last one in closes the door"?

Which is wrong behavior. Local variables should _never_ be shadowed. It's not ever legal anymore to shadow a local variable with another local variable in a larger scope within the function. The only difference between an import outside of a function and one inside is that the symbols should only be imported for the duration of the function. There should be _zero_ other effects on any other language features (be they variable shadowing, symbol collisions, UFCS, etc.). This is definitely a bug. I know that one has already been reported for UFCS, so we already have reported bugs like this, though we probably haven't found them all (and I have no idea whether this particular one has been reported yet).

- Jonathan M Davis