On 2013-02-05 07:13, Jonathan M Davis wrote:
One of the main purposes generally given for having properties is so that you can make them public variables when you don't need them to do anything but get and set the member variable, but you can still make it a function later when you need to add other stuff to it (such as checking the value that it's being set to). One of the primary reasons for making a property function act like a variable is precisely so that you can switch between variables and functions when refactoring without breaking code.Also, being able to mark variables as @property would save us a lot of boilerplate. Instead, it's incredibly common to do stuff like struct S { @property int prop() @safe const pure nothrow { return _prop; } @property int prop(int value) @safe pure { return _prop = value; } private int _prop; } That's a lot of extra code just to buy some encapsulation. If we could do struct S { @property int prop; } we could really reduce the amount of boilerplate code surrounding member variables. Even if putting @property on a variable simply lowered to the property functions rather than it still be a variable, it would be a big help. But without either that or marking variables with @property so that you can't do anything to them that you can't do to a property function, we lose the ability to make a property a variable when the getters and setters are unnecessary, and that means that we're stuck with a lot of extra boilerplate.
BTW, if it does get lowered to methods, do we want to be able to access the instance variable directly? I think it's good to be able to bypass the setter/getter sometimes internally. Alternatively there could be a __traits to access the instance variable.
-- /Jacob Carlborg
