Andrei Alexandrescu Wrote: > Might be because (a) we aren't getting our priorities right, (b) we > ascribe more to properties than what the compiler really makes of them. > > At the end of the day, a property is a notational convenience. Instead > of writing: > > obj.set_xyz(5); > int a = obj.get_xyz(); > > properties allow us to write: > > obj.xyz = 5; > int a = obj.xyz; > > Just to be 100% clear, I agree that the convenience is great. But I > don't know why the hell I need to learn a whole different syntax for > *defining* such things, when the compiler itself doesn't give a damn - > it just blindly rewrites the latter into something like the former.
May be namespace states your complaints. It doesn't add a whole new syntax, only kinda one extra level of indirection, naturally reusing existing feature of operator overloading, and I think it should look natural to compiler too: it's the same as operator overloading, compiler already does it. And calling properties is only one aspect of the problem. The other is declaration. You heard it: implicit backing storage, default trivial implementation, type consistency. We don't have problems with calling properties. In fact complaints about current design originates from problems with property declaration: the problem is compiler doesn't know what is a function and what is a property.
