Revised RFC on range design for D2

[Bruno Medeiros]

Andrei Alexandrescu wrote:
> 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.
> 

In what way does that convention/style go against facilitating generic code?

> 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.").
> 

Uh, of course, and that's why we want this convention to be enforced by 
the language, and not be merely a convention.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D