Revised RFC on range design for D2

[Andrei Alexandrescu]

Andrei Alexandrescu wrote:
> How about this. Maybe if we attacked this annoyance in particular, that 
> would be a large bang for the buck without a landslide change in the 
> compiler. We only need some way to inform the compiler, "yes, it's ok to 
> call a.b(c) as a.b = c". Ideas?

I actually did have something in mind when I wrote this, just didn't 
want to bias anyone.

My thinking is that the syntax "a.b = c" in lieu of a.b(c) for a 
function a.b(T x) should be allowed if and only if there also exists a 
function a.b() that returns a value of type T.

Example:

struct S1
{
     void prop(int x);
}

S1 s1;
s1 = x; // error, prop is not a property

struct S2
{
     void prop(int x);
     int prop();
}

S2 s2;
s2.prop = 42; // fine, prop is a property because it also has a getter

This solution does not require any syntactic addition. Its drawback is 
that it makes it hard to define write-only properties. Are they important?


Andrei