Match properties as member variables

[comco]

On Sunday, 15 December 2013 at 23:38:57 UTC, comco wrote:
> On Sunday, 15 December 2013 at 23:13:39 UTC, Jakob Ovrum wrote:
>> On Friday, 13 December 2013 at 12:01:28 UTC, comco wrote:
>>> From client perspective, properties look like member 
>>> variables.
>>> With (auto) ref, a generic function can catch a member 
>>> variable and read it and update it:
>>>
>>> void swap(T)(ref T a, ref T b) {...}
>>>
>>> The client can use swap with member variables.
>>> But he can't use this swap with class properties - they're 
>>> special.
>>>
>>> Since the properties "look like" member variables, I think it 
>>> is a valid use-case for us to want to be able to write 
>>> generic code that can handle properties passed as arguments 
>>> in the same way as member variables passed as arguments.
>>>
>>> Can you write version of swap, which works also with 
>>> properties and/or combination of properties and references?
>>
>> The issue is that reference parameters expect lvalue 
>> arguments, while property functions that return by value 
>> result in rvalues. It's the same reason you can't do `swap(1, 
>> 2)` - the literals `1` and `2` are rvalues.
>>
>> You can make your property getters result in lvalues by 
>> returning by reference. The syntax mirrors that of reference 
>> parameters:
>>
>> ---
>> struct S
>> {
>>    private int _i;
>>
>>    ref int i() @property
>>    {
>>        return _i;
>>    }
>> }
>>
>> void main()
>> {
>>    S s1, s2;
>>
>>    s1.i = 1;
>>    s2.i = 2;
>>
>>    import std.algorithm : swap;
>>    swap(s1.i, s2.i);
>>
>>    assert(s1.i == 2);
>>    assert(s2.i == 1);
>> }
>> ---
> I know why it doesn't work with the language as it is. This is 
> more like a language design question. The problem is at another 
> level - "linguistic" level - the properties are introduced in 
> the language as a convenience - Java goes well without them - 
> with the purpose of making methods "look like" member 
> variables. The ref property will work with swap, but the 
> general case of a getter + a setter of the same property will 
> not work, because we have two methods, which, in combination, 
> from the outside world, need to look like member variables. But 
> today, the properties mimic variable behavior only in the 
> simple cases (they can't be "passed by ref" as variables do). 
> So the point is that at a higher conceptual level, properties 
> are only partially supported as a client-transparent 
> alternative to member variables.
I'm not saying that 'ref'-s are bad; I'm just saying that we lack 
the syntactic ability to write a function, which accepts a 
"property" - a read-write enabled entity, supporting a particular 
type, which in disguise calls the corresponding getter/setter 
methods.