Match properties as member variables

[comco]

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.