Consider this code:

```
struct Test
{
	string to;

	void test()
	{
		import core.time;

		auto value = ["to": to]; // Error: can't have associative array of void
	}
}

void main() {}
```

In 2.068.0 compilation fails. Works in 2.065 and 2.067.1.

On Wednesday, 19 August 2015 at 21:26:34 UTC, sigod wrote:
> Consider this code:

Not a regression per se - core.time just introduced a new `to` function that is conflicting with your variable name because you imported core.time in a more local scope.

You can just do ["to": this.to] to disambiguate the name.

On Wednesday, 19 August 2015 at 21:32:17 UTC, Adam D. Ruppe wrote:
> On Wednesday, 19 August 2015 at 21:26:34 UTC, sigod wrote:
>> Consider this code:
>
> Not a regression per se - core.time just introduced a new `to` function that is conflicting with your variable name because you imported core.time in a more local scope.
>
> You can just do ["to": this.to] to disambiguate the name.

```
T to(string units, T, D)(D td)
```

But what compiler does with this function? How `void` appears in the error message?

Why does it even picks this function? `to` has required argument, apparently it can't be called without one.

On Wednesday, 19 August 2015 at 21:56:22 UTC, sigod wrote:
> ```
> T to(string units, T, D)(D td)
> ```
>
> But what compiler does with this function? How `void` appears in the error message?

There are no arguments used thus `to` is resolved as plain template symbol, not a function. Template that does not resolve to any valid entity is treated as if it had type 'void' in error messages, even if it is not technically true.

> Why does it even picks this function? `to` has required argument, apparently it can't be called without one.

When you shadow some symbol with a new declaration in more "local" scope, it gets shadow completely, not just added to overload set. No matter what arguments are used only the new symbol will get used.

And yes, this is indeed regression but of a kind unavoidable with D module system so there isn't anything that can be done here but adjusting your code, sadly.

On 08/20/2015 12:04 AM, Dicebot wrote:
> And yes, this is indeed regression but of a kind unavoidable with D
> module system so there isn't anything that can be done here but
> adjusting your code, sadly.

It's a bug.

On 08/19/2015 11:26 PM, sigod wrote:
> Consider this code:
>
> ```
> struct Test
> {
>      string to;
>
>      void test()
>      {
>          import core.time;
>
>          auto value = ["to": to]; // Error: can't have associative array
> of void
>      }
> }
>
> void main() {}
> ```
>
> In 2.068.0 compilation fails. Works in 2.065 and 2.067.1.

It's a bug in local imports. This is the ticket:
https://issues.dlang.org/show_bug.cgi?id=10378

On Wednesday, 19 August 2015 at 22:33:23 UTC, Timon Gehr wrote:
> It's a bug in local imports. This is the ticket:
> https://issues.dlang.org/show_bug.cgi?id=10378

Seems to fit into existing shadowing semantics. If this is a bug we may need a new spec.

On 08/20/2015 01:06 AM, Dicebot wrote:
> On Wednesday, 19 August 2015 at 22:33:23 UTC, Timon Gehr wrote:
>> It's a bug in local imports. This is the ticket:
>> https://issues.dlang.org/show_bug.cgi?id=10378
>
> Seems to fit into existing shadowing semantics.

There's no precedent for symbols shadowed by imports.

> If this is a bug we may need a new spec.

I believe local imports were first implemented without paying any attention to shadowing. I think the broken semantics implemented in DMD without a sufficient up-front design were then back-ported into the documentation at some point. This still happens too often. This is the JavaScript style of language design.

On Wednesday, 19 August 2015 at 23:18:04 UTC, Timon Gehr wrote:
> On 08/20/2015 01:06 AM, Dicebot wrote:
>> On Wednesday, 19 August 2015 at 22:33:23 UTC, Timon Gehr wrote:
>>> It's a bug in local imports. This is the ticket:
>>> https://issues.dlang.org/show_bug.cgi?id=10378
>>
>> Seems to fit into existing shadowing semantics.
>
> There's no precedent for symbols shadowed by imports.
>
>> If this is a bug we may need a new spec.
>
> I believe local imports were first implemented without paying any attention to shadowing. I think the broken semantics implemented in DMD without a sufficient up-front design were then back-ported into the documentation at some point. This still happens too often. This is the JavaScript style of language design.

import should NEVER shadow local symbols.