Revised RFC on range design for D2

[Simen Kjaeraas]

On Thu, 02 Oct 2008 03:38:51 +0200, Simen Kjaeraas  
<simen.kjaras at gmail.com> wrote:

> On Wed, 01 Oct 2008 15:28:36 +0200, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Simen Kjaeraas wrote:
>>>  It seems we will soon get reference return values, in which case this  
>>> would
>>> no longer be a problem. I have also written a property template that  
>>> enables
>>> things such as that, but it would also benefit immensely from reference
>>> return values.
>>
>> Not quite. Sorry, I woke up all negative this morning :o).
>>
>> Consider the .length property for built-in arrays. Better yet, consider  
>> you implement your own array and want to define a .length property.
>>
>> You don't want it to return a reference! You want to have control over  
>> the assignment so that you execute the actual array change.
>>
>> What I'd proposed to Walter for a long time is to allow a.b @= c to  
>> work if a.b = a.b @ c works. I'm sure people around here will find  
>> reasons to dislike that :o).
>>
>>
>> Andrei
>
> Ah, of course. So that leaves us with the property template. I've got a
> fairly nice implementation running, but I dislike the syntax.
>
> class foo
> {
>    int _bar;
>    myStruct _baz;
>
>    mixin property!(_bar, properties.readwrite, barChanged) bar; // This  
> is ugly.
>    mixin property!(_baz, properties.read) baz;
>
>    void barChanged(int value)
>    {
>      //...
>    }
> }
>
> This supports all manners of operator overloading at the moment.
>

Though now that I look at it again (it's been a few months since last I  
worked on it), I see problems with more complex properties. Ah, more for  
me to code, then. :p

-- 
Simen