Revised RFC on range design for D2

[Simen Kjaeraas]

On Wed, 01 Oct 2008 07:58:20 +0200, Benji Smith <dlanguage at benjismith.net>  
wrote:

> Bill Baxter wrote:
>> On Tue, Sep 30, 2008 at 3:36 AM, Steven Schveighoffer
>> <schveiguy at yahoo.com> wrote:
>>>> There is no ambiguity either case. You evaluate Stdout.newline. The
>>>> evaluation yields a value of some type. Then you evaluate formatln  
>>>> against
>>>> that value.
>>> OK, then tell me what this does:
>>>
>>> x.y.z();
>>>
>>> Is y a property/field of x or a function call with no args?  I see a  
>>> benefit
>>> to being able to understand a line of code without requiring lots of  
>>> extra
>>> context.  I have to do less lookups of the source of a function or  
>>> property.
>>  The problem with this argument is that unless you disallow properties
>> altogether, you still won't know whether y is actually a field or a
>> call to a property method without looking it up.
>>  --bb
>
> One thing that I've found especially annoying about the current  
> implementation is this:
>
>    x.y = 3; // Working code
>    x.y += 3; // Broken, if x.y is actually a function
>    x.y = x.y + 3; // Ugly work-around
>
> I've been bitten by this at least a dozen different times. Having a real  
> property syntax would eliminate cases like that.
>
> --benji

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.

-- 
Simen