Revised RFC on range design for D2

[Andrei Alexandrescu]

Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Bruno Medeiros wrote:
>>> Andrei Alexandrescu wrote:
>>>> Bill Baxter wrote:
>>>>> On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm at gmail.com>
>>>>> wrote:
>>>>>> I think the distinction of with and without () is pretty 
>>>>>> stylistic, because the same argument can even be applied to
>>>>>> operator overloading (does a=b means pointing the variable
>>>>>> a to b, or calling a.opAssign(b)?)
>>>>>> 
>>>>>> For me, I would use () if the function do modify the object
>>>>>> itself.
>>>>> 
>>>>> I think the counter-argument to what I just said is that if
>>>>> properties had to be declared explicitly then at least we
>>>>> would know that .y is either a field or else something the
>>>>> designer *intended* to behave like a property.  Which does
>>>>> tell us something.  It most likely means that it's not an
>>>>> extremely heavy-weight operation, just a lightweight accessor
>>>>> with maybe a little logic on top.  That could be wrong, but 
>>>>> in that case it's the class designer's fault for misleading
>>>>> us.
>>>> 
>>>> So the logic is:
>>>> 
>>>> "A field can be accessed with a.b, but not with a.b().
>>>> Therefore if someone writes a.b, it may be a field or code, but
>>>> it someone writes a.b() it will always be code. Given that a
>>>> field is cheap and code ranges from cheap to expensive, good
>>>> style is to have a.b always refer to cheap stuff, and a.b()
>>>> always refer to not-expected-to-be-cheap stuff."
>>>> 
>>>> I agree with that logic. It makes for a nice convention. (That
>>>>  convention is already broken by the built-in dup and sort, but
>>>> let past mistakes be past mistakes.) My response to that is
>>>> that concerns of keeping the language simple and of
>>>> facilitating generic code are counterarguments that should be
>>>> weighed in as well.
>>>> 
>>> 
>>> In what way does that convention/style go against facilitating 
>>> generic code?
>> 
>> A generic function writing obj.symbol cannot work across objects
>> that implement symbol as a computed property vs. a field.
>> 
>> 
>> Andrei
> 
> I'm not following. If 'obj.symbol' is syntactically available and is
>  valid code, shouldn't the generic function work ok regardless of
> whether 'symbol' is a computed property or a field?

What I meant is very simple. Generic code benefits from unified syntax.
Going with one convention across the board would make generic code
simpler. Going with the convention that expensive stuff is with "()" and 
cheap stuff is without "()" differentiates usage.

> I mean, what is even the difference from the status quo?

The discussion was about how things should behave in the future. If you 
ask me, I can live with the status quo save for the writeln = 3 which 
could become a poster child of belittling D.


Andrei