Revised RFC on range design for D2

[Don]

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.

> Besides, it's more efficient to use them as alias parameters, so why not
> encourage that too. And aliases do not need a "&" :o).

Indeed.