Revised RFC on range design for D2

[Andrei Alexandrescu]

0ffh wrote:
> 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.

No, that decision didn't make sense regardless of classes and functions. 
The problem in C is that the name of a function - the simplest thing to 
type - is also the least useful. If I remember correctly, initially it 
actually did not mean anything, so you could not do anything to it. Then 
a rule was added to make the function name AUTOMATICALLY become a 
function pointer (I mean implicitly add a "&"!). But not always! (Bonus 
points: under what circumstances?) Did anyone even know that? And this 
is C - a simple language!

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

I like C, but there are some things that were simply wrongly designed 
(definition syntax, malloc, and (lack of) array design also come to mind).


Andrei