On 11/24/2013 10:52 AM, ilya-stromberg wrote:
> We can allow shadowing members only for function parameters or, maybe, only for
> constructor.

We could, but at the cost of D becoming more of a mass of special cases that nobody can remember.

On Sunday, 24 November 2013 at 19:18:18 UTC, Walter Bright wrote:
> On 11/24/2013 10:52 AM, ilya-stromberg wrote:
>> We can allow shadowing members only for function parameters or, maybe, only for
>> constructor.
>
> We could, but at the cost of D becoming more of a mass of special cases that nobody can remember.

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=9801
Short description: disallow shadowing members, but provide special syntax for constructors like this:

struct S {
    int m;
    this(this.m) { }
}
Should be the same as your example above.

Other languages like Scala, CoffeeScript and TypeScript support a related but different syntax. So, not only I had problems with shadowing members.

On 11/24/2013 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?
>
>
> struct Foo { int x; }
> int x;
> void main() {
>      Foo f;
>      with (f) {
>          x++;
>      }
> }

I meant "bad" as in bad, not as in "good" :-)


>  From my experience that's quite bug-prone:
> http://d.puremagic.com/issues/show_bug.cgi?id=3878

I posted an objection there :-)

On Sunday, 24 November 2013 at 19:59:51 UTC, Walter Bright wrote:
> On 11/24/2013 11:17 AM, bearophile wrote:
>> From my experience that's quite bug-prone:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3878
>
> I posted an objection there :-)

But we can provide a syntax sugar for this case as was suggested in #9801.

On Sunday, 24 November 2013 at 14:12:18 UTC, Maxim Fomin wrote:
> On Sunday, 24 November 2013 at 14:02:43 UTC, ilya-stromberg wrote:
>> On Sunday, 24 November 2013 at 13:57:22 UTC, Maxim Fomin wrote:
>>> This is neither bug not a terribale feature. Have you coded in C?
>>
>> Yes, only a little. I like D because it dissallow most of dangerous abbilities. We already have `is` operator for pointer comparison. Class doesn't provide cast to bool. So, why it's allowed?
>
> void* ptr;
> if(ptr)
>
> was a shortcut for 'if(ptr != NULL)' probably since C was created.
>

No, it is a comparaison with 0. If NULL is 0 on all modern architectures I know of, this wasn't always the case.

> There is no problem with classes or pointers convertion to booleans in condition statements, it is not a dangerous ability. Is operator is not restricted to pointer comparison, you can use it to bitwise compare any objects.


I'd like to know why this feature is dangerous as well.

On Sunday, 24 November 2013 at 14:24:09 UTC, ilya-stromberg wrote:
> On Sunday, 24 November 2013 at 14:17:50 UTC, Dicebot wrote:
>> Not exactly. It is all about "if" condition. AFAIK, D defines that condition `if(X)` get re-written to `if(cast(bool)X)` before semantic pass. So it is kind of implicit explicit conversion :)
>
> Not exactly.
>

Your say no, but you then confirm. Please reread Dicebot's post.

> Code:
>
> bool b = f;
>
> DMD output:
>
> Error: cannot implicitly convert expression (f) of type Foo to bool
>
>
> But code:
>
> bool b = !f;
>
> compiles.

On Sunday, 24 November 2013 at 20:38:29 UTC, deadalnix wrote:
> On Sunday, 24 November 2013 at 14:12:18 UTC, Maxim Fomin wrote:
>> On Sunday, 24 November 2013 at 14:02:43 UTC, ilya-stromberg wrote:
>>> On Sunday, 24 November 2013 at 13:57:22 UTC, Maxim Fomin wrote:
>>>> This is neither bug not a terribale feature. Have you coded in C?
>>>
>>> Yes, only a little. I like D because it dissallow most of dangerous abbilities. We already have `is` operator for pointer comparison. Class doesn't provide cast to bool. So, why it's allowed?
>>
>> void* ptr;
>> if(ptr)
>>
>> was a shortcut for 'if(ptr != NULL)' probably since C was created.
>>
>
> No, it is a comparaison with 0. If NULL is 0 on all modern architectures I know of, this wasn't always the case.
>

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?

On Sunday, 24 November 2013 at 20:38:29 UTC, deadalnix wrote:
> I'd like to know why this feature is dangerous as well.

The root of the issue is identifier shadowing, see:
http://forum.dlang.org/post/hvxvllyafxnyvjooxhjh@forum.dlang.org

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

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?