DIP23 draft: Fixing properties redux

[Dmitry Olshansky]

On 02/05/2013 12:34 PM, Jacob Carlborg wrote:
> 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.

I like the general idea. But to access variable one can still use 
tupleof, so there should be a guarantee that the hidden field layout is 
the same as if it was declared as variable.