On 11/24/13 11:17 AM, bearophile wrote:
> Walter Bright:
>
>> Shadowing globals is definitely a bad idea. Shadowing members, it's
>> debatable.
>
> So are you saying D here should give an error for the shadowing of the
> module-level x?

I think he meant "shadowing locals". 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.

Andrei

On Sunday, November 24, 2013 18:38:19 Ary Borenszweig wrote:
> On 11/24/13 11:18 AM, ilya-stromberg wrote:
> > On Sunday, 24 November 2013 at 14:12:18 UTC, Maxim Fomin wrote:
> >> void* ptr;
> >> if(ptr)
> >> 
> >> was a shortcut for 'if(ptr != NULL)' probably since C was created.
> > 
> > Small code change:
> > 
> > import std.stdio;
> > 
> > class Foo
> > {
> > }
> > 
> > void main()
> > {
> > 
> >      Foo f;
> > 
> >      if(f == null)
> >      {
> > 
> >          writeln("f is true");
> > 
> >      }
> > 
> >      if(f != null)
> >      {
> > 
> >          writeln("f is false");
> > 
> >      }
> > 
> > }
> > 
> > DMD output:
> > 
> > Error: use 'is' instead of '==' when comparing with null Error: use '!is' instead of '!=' when comparing with null
> 
> Ugh, if the compiler disallows comparison of reference with "==" and "!=" and tells you to use "is" and "!is", can't compiler just allow you to write "==" and understand it as "is"? What's the big deal?

Likely because using == indicates a misunderstanding of what == does and how null works.  Conceptually, == and is are two very different operations, and they shouldn't be mixed up. Also, using == null incurs some extra overhead, because it ends up calling opEquals.

- Jonathan M Davis

On Sunday, November 24, 2013 15:16:37 bearophile wrote:
> Maxim Fomin:
> > This is neither bug not a terribale feature.
> 
> I think the implicit question of ilya-stromberg was: how much bug-prone is this language feature?

Not at all, and most people coming from C/C++ would likely be annoyed to not have it. And a prime place that it's used where using is woludn't work is with the in operator. e.g.

if(auto ptr = key in myAA) {...}

Granted, that's a pointer rather than a class reference, but it's essentially the same issue. And I see no reason to have pointers and references act differently in this regard.

- Jonathan M Davis

On Sunday, 24 November 2013 at 23:31:38 UTC, Andrei Alexandrescu wrote:
> On 11/24/13 11:17 AM, bearophile wrote:
>> Walter Bright:
>>
>>> Shadowing globals is definitely a bad idea. Shadowing members, it's
>>> debatable.
>>
>> So are you saying D here should give an error for the shadowing of the
>> module-level x?
>
> I think he meant "shadowing locals". 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.

Yes, but D allows to use it. And in few cases global variable can be useful.
For example, we can have thread-local variable for database connection that used almost everywhere.

On 11/24/13 6:48 PM, ilya-stromberg wrote:
> On Sunday, 24 November 2013 at 23:31:38 UTC, Andrei Alexandrescu wrote:
>> On 11/24/13 11:17 AM, bearophile wrote:
>>> Walter Bright:
>>>
>>>> Shadowing globals is definitely a bad idea. Shadowing members, it's
>>>> debatable.
>>>
>>> So are you saying D here should give an error for the shadowing of the
>>> module-level x?
>>
>> I think he meant "shadowing locals". 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.
>
> Yes, but D allows to use it. And in few cases global variable can be
> useful.
> For example, we can have thread-local variable for database connection
> that used almost everywhere.

I agree. What I'm saying is it's not good to make shadowing a global an error. It puts the onus in the wrong place.

Andrei

On 11/24/2013 7:49 AM, Maxim Fomin wrote:
> Yes, it is confusing. It is especially confusing in an unstable language with
> absent adequate spec. For example, I can learn C namespace rules, but in D case
> it is useless. Unfortunately what is right in cases like above depends on what
> Walter & Andrei think so we stuck with their opinions on the subject.

In what way are D namespace rules unclear? Please file bugzilla reports for any such, and mark them with the keyword 'spec'.


> (I think emitting at least warning would be good)

I don't think there should be errors for shadowing globals for very good reasons, warnings are a generally bad solution to language issues, and changing the way scoping rules work would be the very definition of instability.

On Sunday, 24 November 2013 at 21:13:12 UTC, deadalnix wrote:
> On Sunday, 24 November 2013 at 21:00:53 UTC, Maxim Fomin wrote:
>> It is comparison with NULL and zero (I though it is obvious that the code snippet is written in C), because NULL is always zero by definition ("an integer constant expression with the value 0, or such an expression casted to void*"). If this is not the case, then implementation is broken. Which of them you are talking about?
>
> http://c-faq.com/null/machexamp.html

You confused runtime bit pattern and zero integer constant. NULL is always zero integer constant (probably casted to void*) by definition.

http://c-faq.com/null/varieties.html

if(ptr) is as good as if(ptr != 0) or if(ptr != NULL) regardless of null bit pattern

"The internal (or run-time) representation of a null pointer, which may or may not be all-bits-0 and which may be different for different pointer types. The actual values should be of concern only to compiler writers. Authors of C programs never see them, since they use..The null pointer constant, which is a constant integer 0 "

On Monday, 25 November 2013 at 03:12:03 UTC, Andrei Alexandrescu
wrote:
> On 11/24/13 6:48 PM, ilya-stromberg wrote:
>> On Sunday, 24 November 2013 at 23:31:38 UTC, Andrei Alexandrescu wrote:
>>> On 11/24/13 11:17 AM, bearophile wrote:
>>>> Walter Bright:
>>>>
>>>>> Shadowing globals is definitely a bad idea. Shadowing members, it's
>>>>> debatable.
>>>>
>>>> So are you saying D here should give an error for the shadowing of the
>>>> module-level x?
>>>
>>> I think he meant "shadowing locals". 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.
>>
>> Yes, but D allows to use it. And in few cases global variable can be
>> useful.
>> For example, we can have thread-local variable for database connection
>> that used almost everywhere.
>
> I agree. What I'm saying is it's not good to make shadowing a global an error. It puts the onus in the wrong place.
>
> Andrei

Would it be possible to introduce a global scope of sorts that
had to be explicitly referenced when one wanted to define or use
a global variable. I haven't thought of how this might interface
with other D features, but something along the lines of:

@global int my_gobal_var; //Gets added to global scope.

//Then any globals would have to be referenced as:
global.my_global_var = 7;

Makes for a bit of extra typing, and would mess with any module
named 'global', but it might work?

On 11/24/13 8:27 PM, Craig Dillabaugh wrote:
> Would it be possible to introduce a global scope of sorts that
> had to be explicitly referenced when one wanted to define or use
> a global variable. I haven't thought of how this might interface
> with other D features, but something along the lines of:
>
> @global int my_gobal_var; //Gets added to global scope.
>
> //Then any globals would have to be referenced as:
> global.my_global_var = 7;
>
> Makes for a bit of extra typing, and would mess with any module
> named 'global', but it might work?

To put it bluntly, many things are possible but it seems the best is to do nothing here. We're in good shape.

Andrei

On Monday, 25 November 2013 at 04:35:10 UTC, Andrei Alexandrescu wrote:
> On 11/24/13 8:27 PM, Craig Dillabaugh wrote:
>> Would it be possible to introduce a global scope of sorts that
>> had to be explicitly referenced when one wanted to define or use
>> a global variable. I haven't thought of how this might interface
>> with other D features, but something along the lines of:
>>
>> @global int my_gobal_var; //Gets added to global scope.
>>
>> //Then any globals would have to be referenced as:
>> global.my_global_var = 7;
>>
>> Makes for a bit of extra typing, and would mess with any module
>> named 'global', but it might work?
>
> To put it bluntly, many things are possible but it seems the best is to do nothing here. We're in good shape.

I personally like Craig Dillabaugh's sugestion. But we can use `.` operator for this because it alredy used for call global functions and, probably, should break nothing. Like this:

int my_gobal_var;

.my_global_var = 7;

Is it possible?