After reading this:
http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/

I thought, does D have the same "problem", and according to:
http://dlang.org/statement.html#WithStatement

No, it doesn't.  D detects local variable shadowing and produces an error.  But, then I thought does that apply to global variables as well?  Turns out, no it doesn't.

// [withd.d]
import std.stdio;

int global;

struct S
{
  int global;
  int local;
}

void main()
{
  int local;
  S s;

  with(s)
  {
    local = 3;  // withd.d(18): Error: with symbol withd.S.local is shadowing local symbol withd.main.local
    global = 5;
  }

  writefln("local = %d", local);
  writefln("global = %d", global);

  writefln("s.local = %d", s.local);
  writefln("s.global = %d", s.global);
}

The above (if you comment out the line producing the expected error) compiles and runs.  It updates s.global at least.  The risk is fairly small, I guess, that someone will mis-type a member name, and hit a global with that mis-typed name, but it's possible.  And in that case it would compile and then do something unexpected.

Should I raise a bug for this?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Friday, 2 November 2012 at 12:04:28 UTC, Regan Heath wrote:
> Should I raise a bug for this?

This one is ok I think because D normally lets locals shadow globals silently - if you had

int g;

void main() {
   int g;
}

that's ok normally so it isn't specific to with. This is a good thing because it means adding a variable elsewhere won't annoyingly break your functions.

You could argue that doing it on structs is a little harder to keep track of than regular locals, but, meh.

On 11/2/12 8:03 AM, Regan Heath wrote:
> After reading this:
> http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/
>
> I thought, does D have the same "problem", and according to:
> http://dlang.org/statement.html#WithStatement
>
> No, it doesn't. D detects local variable shadowing and produces an
> error.

It took quite some fighting to get that implemented. I vaguely recall we didn't figure that issue until I tried to explain "with" in TDPL. Or it had been already discussed in the forum? Anyhow, it made "with" quite cool.

> But, then I thought does that apply to global variables as well?
> Turns out, no it doesn't.
[snip]
> Should I raise a bug for this?

I personally think we're in good shape here, but an argument could be made either way.


Andrei

Adam D. Ruppe:

> D normally lets locals shadow globals silently - if you had
>
> int g;
>
> void main() {
>    int g;
> }
>
> that's ok normally so it isn't specific to with. This is a good thing because it means adding a variable elsewhere won't annoyingly break your functions.
>
> You could argue that doing it on structs is a little harder to keep track of than regular locals, but, meh.

I try to minimize (possibly to zero) the number of global variables/constants, but I have had some troubles caused by silent shadowing of global names by local names in functions.
Having global variables with the same name of local variables is sometimes a source for troubles, so I try to keep their name distinct. But I'd like D to spot such duplications (shadowing of a global) for me.

Bye,
bearophile

On 02/11/2012 14:13, bearophile wrote:
> Adam D. Ruppe:
>
>> D normally lets locals shadow globals silently - if you had
>>
>> int g;
>>
>> void main() {
>>    int g;
>> }
>>
>> that's ok normally so it isn't specific to with. This is a good thing
>> because it means adding a variable elsewhere won't annoyingly break
>> your functions.
>>
>> You could argue that doing it on structs is a little harder to keep
>> track of than regular locals, but, meh.
>
> I try to minimize (possibly to zero) the number of global
> variables/constants, but I have had some troubles caused by silent
> shadowing of global names by local names in functions.
> Having global variables with the same name of local variables is
> sometimes a source for troubles, so I try to keep their name distinct.
> But I'd like D to spot such duplications (shadowing of a global) for me.
>
> Bye,
> bearophile

When talking about global variables are we talking about module scope variables?
As I see the module as the most primary data encapsulation in D, I often use module scope variables (in combo with static import).
I didn't know you could shadow globals and in my situation it sounds bug prone.

Faux Amis:

> When talking about global variables are we talking about module scope variables?

Right, in D with "global scope" I meant "module scope".


> As I see the module as the most primary data encapsulation in D, I often use module scope variables (in combo with static import).

In my opinion that's a bad practice in D.


> I didn't know you could shadow globals and in my situation it sounds bug prone.

It's not terrible, I am able to write code. But I think it doesn't help.

Bye,
bearophile

On 02/11/2012 20:19, bearophile wrote:
> Faux Amis:
>
>> When talking about global variables are we talking about module scope
>> variables?
>
> Right, in D with "global scope" I meant "module scope".
>
>
>> As I see the module as the most primary data encapsulation in D, I
>> often use module scope variables (in combo with static import).
>
> In my opinion that's a bad practice in D.

Care to elaborate on that?

>
>
>> I didn't know you could shadow globals and in my situation it sounds
>> bug prone.
>
> It's not terrible, I am able to write code. But I think it doesn't help.
>
> Bye,
> bearophile

Faux Amis:

> Care to elaborate on that?

They share most of the problems of global variables. While not evil, it's better to avoid module-level mutables. This makes the code more testable, simpler to understand, less bug prone, and makes functions more usable for other purposes. In D there the attribute "pure" is present also to enforce such better coding style.

Bye,
bearophile

On Saturday, 3 November 2012 at 20:29:14 UTC, bearophile wrote:
> Faux Amis:
>
>> Care to elaborate on that?
>
> They share most of the problems of global variables. While not evil, it's better to avoid module-level mutables. This makes the code more testable, simpler to understand, less bug prone, and makes functions more usable for other purposes. In D there the attribute "pure" is present also to enforce such better coding style.

 Let's not forget that since global variables are 'per thread' that the issues involving them lessen and are less evil than before.

On 03/11/2012 21:29, bearophile wrote:
> Faux Amis:
>
>> Care to elaborate on that?
>
> They share most of the problems of global variables. While not evil,
> it's better to avoid module-level mutables. This makes the code more
> testable, simpler to understand, less bug prone, and makes functions
> more usable for other purposes. In D there the attribute "pure" is
> present also to enforce such better coding style.
>
> Bye,
> bearophile

I failed to mention that I am mostly talking about private module scope variables. I don't see how private module scoped vars make for less testable, readable or more bug prone code.