Revised RFC on range design for D2

[Don]

Andrei Alexandrescu wrote:
> Don wrote:
>> Andrei Alexandrescu wrote:
>>> Sergey Gromov wrote:
>>>> In article <gbjihf$2803$1 at digitalmars.com>, 
>>>> frank at youknow.what.todo.interNETz says...
>>>>> Andrei Alexandrescu wrote:
>>>>>> Steven Schveighoffer wrote:
>>>>>>> You are assuming that the C language decision to require 
>>>>>>> parentheses for all functions was a design mistake.  I would 
>>>>>>> argue that the design was on purpose and correctly served that 
>>>>>>> purpose.  The purpose was to remove ambiguity when faced with 
>>>>>>> understanding code without all the context.
>>>>>> I have stated my assumption and its basis. What is the basis of 
>>>>>> yours?
>>>>> Yum. I think the problem is that when C was designed, K&R didn't 
>>>>> consider
>>>>> the use of classes with properties using getter and setter methods.
>>>>> Therefore, it made sense to have the naked function name denote the
>>>>> function pointer, and make braces following an identifier the mark 
>>>>> of a
>>>>> function call. I initially had some trouble accepting the explicit 
>>>>> & in D
>>>>> to get the function pointer myself.
>>>>> I wouldn't go so far as to call that property of C a design mistake in
>>>>> light of the actual intensions of K&R. But I definitely would defend
>>>>> the choice of a language designer to change that feature in light of
>>>>> more modern programming paradigms.
>>>>
>>>> Functions in D are first-class values.  It's awkward that a 
>>>> first-class value cannot be accessed by its identifier.
>>>
>>> I agree. But then use of functions for invocation dwarfs use of
>>> functions as first-class values, so I think requiring & for the latter
>>> is a sensible engineering decision.
>>
>>
>> By the way, D supports declarations of function type (not function 
>> pointer), though it's not documented in the spec. They always struck 
>> me as a really odd feature in C, and they're pretty confusing for 
>> newbies:
>>
>> typedef void Func(int);
>>
>> Then you get oddities
>>
>> Func * f = &foo; // OK.
>>
>> Func f = foo; // You might expect this to work, but it makes no sense.
>>
>> This is a case where you do not intuitively expect "foo" (with no &) 
>> to be a function pointer. You might as well make it a function 
>> invocation.
>>
>> It's pretty interesting to fool around with these fellas in an is() 
>> expression.
> 
> Heh. That is eerily similar to the way C handles it - here's an example:
> 
> // this is C
> typedef void foo(int);
> 
> int main()
> {
>     foo bar;
>     foo baz;
>     bar = baz;
> }
> 
> The typedef goes through. The definitions of bar and baz go through (and 
> are simply equivalent to an extern declaration!!!) The assignment won't 
> go through because, bar is not an lvalue.

Is there a use case for this? I've only ever found it to be a nuisance, 
or a curiosity at best. It seems like a great bit of C baggage to discard.