On Tuesday, 26 November 2013 at 08:23:15 UTC, bearophile wrote:
> Chris Cain:
>
>> If you really want to know when something is global when you use it then use g prepended before your global names. That's what a lot of people do to avoid this type of issue.
>
> That is named "relying on hand-managed name conventions for something that could be the job of the compiler type system".
>
> Bye,
> bearophile

Alternatively, one can start (enforce) using dot operator before module scope objects :)

On Tuesday, 26 November 2013 at 16:27:27 UTC, Andrei Alexandrescu wrote:
> The win of (2) itself is yet to be quantified and the breakage is large.

Excuse me, did you mean "disable shadowing global variables" or "disable shadowing class members"?

If I understand everything correctly, Walter said that "Shadowing members, it's debatable". His main objection was about initializing variables in constructor, but we can add syntax sugar for this case.

See also:
http://forum.dlang.org/post/l6tg7n$2i7s$1@digitalmars.com
http://forum.dlang.org/post/l6tjdq$2kvc$1@digitalmars.com
http://d.puremagic.com/issues/show_bug.cgi?id=9801

Andrei Alexandrescu:

> The problem is "you" who added the global and "you" whose code is broken may be in fact two different people.

When you have code written by another person, and you add a global variable that causes shadowing errors elsewhere, you choose another variable name. What problems is this going to cause?

Bye,
bearophile

On 11/26/13 8:52 AM, ilya-stromberg wrote:
> On Tuesday, 26 November 2013 at 16:27:27 UTC, Andrei Alexandrescu wrote:
>> The win of (2) itself is yet to be quantified and the breakage is large.
>
> Excuse me, did you mean "disable shadowing global variables" or "disable
> shadowing class members"?

The latter.

> If I understand everything correctly, Walter said that "Shadowing
> members, it's debatable". His main objection was about initializing
> variables in constructor, but we can add syntax sugar for this case.
>
> See also:
> http://forum.dlang.org/post/l6tg7n$2i7s$1@digitalmars.com
> http://forum.dlang.org/post/l6tjdq$2kvc$1@digitalmars.com
> http://d.puremagic.com/issues/show_bug.cgi?id=9801

I think Walter agrees that we can't disallow shadowing globals. Adding additional sugar is pretty much the kiss of death for the entire notion of disallowing shadowing of members.


Andrei

On 11/26/13 9:10 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> The problem is "you" who added the global and "you" whose code is
>> broken may be in fact two different people.
>
> When you have code written by another person, and you add a global
> variable that causes shadowing errors elsewhere, you choose another
> variable name. What problems is this going to cause?

Someone else adds a global to the code they wrote, with which you build. Aren't you working in a team?

Andrei

On Tuesday, 26 November 2013 at 17:11:38 UTC, Andrei Alexandrescu wrote:
> On 11/26/13 8:52 AM, ilya-stromberg wrote:
>> On Tuesday, 26 November 2013 at 16:27:27 UTC, Andrei Alexandrescu wrote:
>>> The win of (2) itself is yet to be quantified and the breakage is large.
>>
>> Excuse me, did you mean "disable shadowing global variables" or "disable
>> shadowing class members"?
>
> The latter.

Thanks for explanation.
I was confused because number (2) is "disable shadowing global variables" and you wrote that don't want to have it. Thank you for explanation because I can't interpret your opinion as I want.

>> If I understand everything correctly, Walter said that "Shadowing
>> members, it's debatable". His main objection was about initializing
>> variables in constructor, but we can add syntax sugar for this case.
>>
>> See also:
>> http://forum.dlang.org/post/l6tg7n$2i7s$1@digitalmars.com
>> http://forum.dlang.org/post/l6tjdq$2kvc$1@digitalmars.com
>> http://d.puremagic.com/issues/show_bug.cgi?id=9801
>
> I think Walter agrees that we can't disallow shadowing globals. Adding additional sugar is pretty much the kiss of death for the entire notion of disallowing shadowing of members.

Excuse me, I didn't understand you.
The main idea:
1) disable shadowing class members
2) add additional syntax sugar for initializing variables in constructor as was suggested in #9801

It looks like that solves problem. Is it impossible?

As alternative solution, we can allow shadowing members only for function parameters or, maybe, only for constructor. Walter agreed that it's possible, "but at the cost of D becoming more of a mass of special cases that nobody can remember".
http://forum.dlang.org/post/l6tjdq$2kvc$1@digitalmars.com

So, syntax sugar in #9801 looks like better solution.

On 11/26/2013 1:22 AM, bearophile wrote:
> If you add a global
> variable, and the compiler gives you several name shadowing errors elsewhere,
> you choose a different name for the global variable, you don't break the code.

That's going to work out not so great for anyone developing a 3rd party library.

On 11/26/13 9:39 AM, ilya-stromberg wrote:
> On Tuesday, 26 November 2013 at 17:11:38 UTC, Andrei Alexandrescu wrote:
>> On 11/26/13 8:52 AM, ilya-stromberg wrote:
>>> On Tuesday, 26 November 2013 at 16:27:27 UTC, Andrei Alexandrescu wrote:
>>>> The win of (2) itself is yet to be quantified and the breakage is
>>>> large.
>>>
>>> Excuse me, did you mean "disable shadowing global variables" or "disable
>>> shadowing class members"?
>>
>> The latter.
>
> Thanks for explanation.
> I was confused because number (2) is "disable shadowing global
> variables" and you wrote that don't want to have it. Thank you for
> explanation because I can't interpret your opinion as I want.

Apologies for writing the wrong number.

>>> If I understand everything correctly, Walter said that "Shadowing
>>> members, it's debatable". His main objection was about initializing
>>> variables in constructor, but we can add syntax sugar for this case.
>>>
>>> See also:
>>> http://forum.dlang.org/post/l6tg7n$2i7s$1@digitalmars.com
>>> http://forum.dlang.org/post/l6tjdq$2kvc$1@digitalmars.com
>>> http://d.puremagic.com/issues/show_bug.cgi?id=9801
>>
>> I think Walter agrees that we can't disallow shadowing globals. Adding
>> additional sugar is pretty much the kiss of death for the entire
>> notion of disallowing shadowing of members.
>
> Excuse me, I didn't understand you.
> The main idea:
> 1) disable shadowing class members
> 2) add additional syntax sugar for initializing variables in constructor
> as was suggested in #9801
>
> It looks like that solves problem. Is it impossible?

It is possible to the extent a lot of things are. But at this point:

(a) It's unclear whether a problem even exist, and if it does, what is its magnitude.

(b) There has been no convincing refutation of the alternative of doing nothing ("if we do nothing about this, ..."). In fact doing nothing is _very_ attractive from multiple angles (no work, no bugs, no regressions, no breakage, no surprise).

> As alternative solution, we can allow shadowing members only for
> function parameters or, maybe, only for constructor. Walter agreed that
> it's possible, "but at the cost of D becoming more of a mass of special
> cases that nobody can remember".
> http://forum.dlang.org/post/l6tjdq$2kvc$1@digitalmars.com
>
> So, syntax sugar in #9801 looks like better solution.

That sugar is already liable of causing cancer of the semicolon. And adding a feature that is predicated on adding sugar? Kiss of death.

Just drop this. Ten people come, on their first day using D, with eleven new ideas that shuffle things around a bit at the cost of breaking everybody's code.


Thanks,

Andrei

On 11/26/2013 9:39 AM, ilya-stromberg wrote:
> So, syntax sugar in #9801 looks like better solution.

I agree with Andrei. The current situation is the best solution.

On Tuesday, 26 November 2013 at 17:52:27 UTC, Andrei Alexandrescu wrote:
> On 11/26/13 9:39 AM, ilya-stromberg wrote:
> That sugar is already liable of causing cancer of the semicolon. And adding a feature that is predicated on adding sugar? Kiss of death.

Thanks for explanation. I really don't understand what's a problem with #9801, but believe you that it's bad idea.
Maybe you can find another solution, I don't know.
BTW, it will be great to have static code analyzer, maybe with a custom rules and, maybe built-in into compiler. We already have built-in profiler.

> Just drop this. Ten people come, on their first day using D, with eleven new ideas that shuffle things around a bit at the cost of breaking everybody's code.

I think I use D about 1-2 years. I knew about it when your book TDPL wasn't published and GDC was broken, it was 2009-2010 as I remember. So, it's definitely not a my first day using D.

I just found bug that can be catched via compiler and decide to write about it because, theoretically, we can improve this. Sorry for incomprehension.