Revised RFC on range design for D2

[Simen Kjaeraas]

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.

-- 
Simen