new DIP5: Properties 2

[Benji Smith]

Andrei Alexandrescu wrote:
> Benji Smith wrote:
>> 3) The existence of "magical" identifiers complicates the language 
>> design. Because the rules that apply to those magical identifiers is 
>> different than the rules applying to non-magical identifiers.
> 
> Well I agree with some of your points but this is factually incorrect. 
> There's nothing special about opXxx identifiers. The compiler simply 
> rewrites certain operations into regular calls to those operators. 
> That's all. I happen to find that very elegant, and in fact I'd want D 
> to rely more often on simple rewrites instead of sophisticated special 
> casing.
> 
> Andrei

I should have been more clear. I understand the rewriting part of the 
proposal. What I was referring to was the fact that an opGet_x 
identifier would shadow the declaration of a variable named "x", making 
it impossible, within the type itself, to directly reference the 
variable itself. So, in this case...

    class MyClass {

       private int x;
       public int opGet_x() {
         return x;
       }

    }

...either the compiler would issue an error (my preference) or the 
private field would take precedence (within the class) in any name 
resolution logic. From outside the class, there would be no problem.

Also related, is this case:

    class MyClass {

       public int x;
       public int opGet_x();

    }

I assume the compiler would have to throw an error. Eventually, people 
would learn to give their fields different names than their properties 
(probably with an underscore prefix or something).

Anyhow, in both cases, I'd consider these to be changes to the 
language's identifier semantics. They're not *huge* changes, but the 
introduction of those magical rewriting rules is still something a 
programmer would have to be aware of. And those are the reasons I'd 
rather shy away from magical name-rewriting mechanisms. (NOTE: I have no 
problem with the implementation of the other operator overloading names. 
They work exactly as expected.)

--benji