Revised RFC on range design for D2

[Bruno Medeiros]

Don wrote:
> 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.

What exactly are you trying to discard? Just the
   typedef void foo(int);
syntax? Or any typedef of a function type? Like
   void func(int);
   typedef typeof(func) foo;
?

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