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

Yes, exactly.
BTW, yesterday I found bug in Vibe.d, see:
https://github.com/rejectedsoftware/vibe.d/issues/406

Reduced example:

void main()
{
	int i;
	i = i;
}

The line `i = i;` does nothing, but compiler doesn't give a error. Why?!

Note that `i;` line gives the error:
Error: var has no effect in expression (i)

On Tuesday, 26 November 2013 at 08:23:15 UTC, bearophile wrote:
> That is named "relying on hand-managed name conventions for something that could be the job of the compiler type system".

Sure. It'd have been nice if the language was designed to avoid these types of problems from the beginning (though a language feature/syntax rules to learn dedicated to a problem that is easily solved with a naming convention would be debatable). But it wasn't and it'd break too much code for a minuscule gain and there exists a reasonable workaround (that also is commonly used everywhere else for this same problem in most other languages). Changing this now would be horrifically bad and the benefit of such a change is effectively nothing.

On Tuesday, 26 November 2013 at 08:33:58 UTC, Chris Cain wrote:
> On Tuesday, 26 November 2013 at 08:23:15 UTC, bearophile wrote:
>> That is named "relying on hand-managed name conventions for something that could be the job of the compiler type system".
>
> Sure. It'd have been nice if the language was designed to avoid these types of problems from the beginning (though a language feature/syntax rules to learn dedicated to a problem that is easily solved with a naming convention would be debatable). But it wasn't and it'd break too much code for a minuscule gain and there exists a reasonable workaround (that also is commonly used everywhere else for this same problem in most other languages). Changing this now would be horrifically bad and the benefit of such a change is effectively nothing.

Yes, but D/Phobos depreciates/removes a lot of different things.
For example, we can use only warning (maybe only with special
compiler flag like `-property`).

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

http://i.imgur.com/H838hA9.jpg

Chris Cain:

> Sure. It'd have been nice if the language was designed to avoid these types of problems from the beginning (though a language feature/syntax rules to learn dedicated to a problem that is easily solved with a naming convention would be debatable). But it wasn't and it'd break too much code for a minuscule gain and there exists a reasonable workaround (that also is commonly used everywhere else for this same problem in most other languages). Changing this now would be horrifically bad and the benefit of such a change is effectively nothing.

This discussion is becoming more interesting, thank you :-)

If it's a convention "commonly used everywhere" then it sounds like something important.

And replacing name conventions with compiler-enforced features is one of the main purposes of any type system. Because it makes the convention safer and tidier.

Regarding the code breaking, probably there are acceptable deprecation paths, that make the such change gradual enough. regarding the gain being minuscule, experiments should be used to verify this.


Andrei has written elsewhere in this thread:

>As I wrote in TDPL, it's a bad idea to add a global somewhere and break a bunch of code that has nothing to do with it.<

Global (or module-level in D, often thread-local) variables are sometimes useful, but a D programmer should minimize their number. 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. If you add a local variable that shadows a global variable and you receive a shadowing error, you choose a different name for the local variable. This avoid using the "g_" prefix.

Bye,
bearophile

deadalnix:

> http://i.imgur.com/H838hA9.jpg

AH ah, thank you :-) Eventually the official lint will need to ship inside the main D distributions.

While a lint is useful for some purposes (like verifying the D code doesn't have logically wrong indentations), there are some things that are probably better addressed in the language.

Bye,
bearophile

On Tuesday, 26 November 2013 at 09:25:56 UTC, bearophile wrote:
> While a lint is useful for some purposes (like verifying the D code doesn't have logically wrong indentations), there are some things that are probably better addressed in the language.

So, we have a few suggestions in this thread like:
1) disable shadowing class members
2) disable shadowing global variables
3) enforce using `.` before global variables

What our next step? Shall we add Bugzilla issue or something else?

On Tuesday, 26 November 2013 at 10:43:57 UTC, ilya-stromberg wrote:
> On Tuesday, 26 November 2013 at 09:25:56 UTC, bearophile wrote:
>> While a lint is useful for some purposes (like verifying the D code doesn't have logically wrong indentations), there are some things that are probably better addressed in the language.
>
> So, we have a few suggestions in this thread like:
> 1) disable shadowing class members
> 2) disable shadowing global variables
> 3) enforce using `.` before global variables
>
> What our next step? Shall we add Bugzilla issue or something else?

Let us vote. I am against 1 .. 3

On 11/26/13 1:22 AM, bearophile wrote:
> Andrei has written elsewhere in this thread:
>> As I wrote in TDPL, it's a bad idea to add a global somewhere and
>> break a bunch of code that has nothing to do with it.<
>
> Global (or module-level in D, often thread-local) variables are
> sometimes useful, but a D programmer should minimize their number. 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. If you add a local variable that
> shadows a global variable and you receive a shadowing error, you choose
> a different name for the local variable. This avoid using the "g_" prefix.

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

It's safe to end this discussion. Doing absolutely nothing has a lot going for it in this case.


Thanks,

Andrei

On 11/26/13 2:43 AM, ilya-stromberg wrote:
> On Tuesday, 26 November 2013 at 09:25:56 UTC, bearophile wrote:
>> While a lint is useful for some purposes (like verifying the D code
>> doesn't have logically wrong indentations), there are some things that
>> are probably better addressed in the language.
>
> So, we have a few suggestions in this thread like:
> 1) disable shadowing class members
> 2) disable shadowing global variables
> 3) enforce using `.` before global variables
>
> What our next step? Shall we add Bugzilla issue or something else?

Maybe (2) has something going for it, but (1) and (3) are definite no-nos. The win of (2) itself is yet to be quantified and the breakage is large. So my suggestion is we choose:

4) Do absolutely nothing and move on.


Thanks,

Andrei