Revised RFC on range design for D2

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm at gmail.com> 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
>> 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.

An experience anecdote - when I wrote Loki I went for the convention 
that if a type template argument only accepts built-in types it should 
be written "class T", otherwise it should be written "typename T". The 
convention was a failure: lack of compiler enforcement meant that "bugs" 
would be in there without being noticed (and readers would subsequently 
complain about inconsistencies), at times it was even unclear whether a 
template would accept certain built-in types or not and there was no way 
to check that, etc. A similar fate could happen for that convention. It 
could be nice, yes, but it could also become a nuisance ("was I expected 
to put parens here, or not? Hell, nobody seems to care anyway, at least 
this version of the library.").


Andrei