Revised RFC on range design for D2

[Yigal Chripun]

Andrei Alexandrescu Wrote:
>
> There are a few principles at work here that I consider universal, plus 
> some others that I consider a matter of preference. One principle that I 
> consider universal is that a language should minimize the number of 
> syntactic constructs that are semantically and/or pragmatically 
> meaningless. Another that I also consider universal is that the more 
> frequently-used constructs should be given syntactic priority over the 
> less-used constructs, particularly when the latter are also at risk of 
> breaking the first principle.
> 
> C's handling of function names royally breaks both of these principles. 
> It makes
> 
> func;
> 
> a valid syntactic construct with inoperant semantics and consequently 
> useless pragmatics. Moreover,
> 
> a = func;
> gunc(func);
> 
> both have valid syntax and semantics, but the pragmatics are the 
> infrequently-used manipulations of function addresses in higher-order 
> programming, something C is not quite adept at to start with. (So that 
> makes the state of affairs all the more ironic.)
> 
> C++ builds on that irony by making
> 
> obj.func;
> b = obj.func;
> gunc(obj.func);
> 
> still syntactically valid but one order of magnitude less useful because 
> they traffic in references to member functions, a contraption that is 
> defined sufficiently bad and inefficient to be useless in practice, and 
> also of a type with a syntax I'd be glad to remove from my memory. (How 
> many here _do_ know that type's syntax and have the scars to prove it?)
> 
> So thinking of function call syntax has quite a few deep underpinnings. 
> We shouldn't confuse habit acquired from C and C++ with some fundamental 
> truth or just a matter of preference that can't be decided on an 
> objective basis.
> 
> One issue with today's function call syntax in D is that people can 
> write code that is of dubious expressiveness:
> 
> writeln = 3;
> 
> Properties would solve this problem by confining assignment syntax to 
> themselves only.
> 
> 
> Andrei

I didn't mean to suggest we need to have pointer-to-member-function as in c++.
I totally agree about all the problems you point out in C/C++ and I don't want to
import all of those problems to D. 
you talk about how C is not quite adept at infrequently-used manipulations of 
function addresses in higher-order programming but this is I think not relevant to D
since D has better facilities (delegates) and the use of those will be more frequent 
since D tries to incorporate more FP (pure functions, etc)
also, there is the problem you stated above with allowing "writeln = 3;"

what would you think about the following scheme:

1. requiring parens to represent function invocation
2. using explicit property syntax similar to my previous post
3. the function name would be consistent with other identifiers and functions could be
    treated just like any other object.
    -  func.something; // refers to a property of the function itself.
    -  func();  // calling func
    -  func.something(); // calling method of func. 
4.  function names represent delegates instead of function pointers, 
     just like D arrays are "fat" structs and not pointers. 
5. plain old C function pointers can be implicitly cast to delegates. 
6. func.ptr will return the C style function pointer (just like with arrays).