Revised RFC on range design for D2

[Andrei Alexandrescu]

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.


Andrei