Revised RFC on range design for D2

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> No. It does NOT seem and is NOT even remotely consistent with C pointers 
>> because x is not the same thing as &x for all symbols in C except 
>> functions. Please work through this with books and test programs and all, 
>> until you fully understand it. It is important.
> 
> You are completely misunderstanding the scope of what I'm saying.  I'll just 
> leave it at that.

You said something wrong. I understood what you said, I understood in 
what way it was wrong, and then I explained to you why it was wrong. How 
did I completely misunderstood the scope of what you are saying? In what 
way are pointers to functions consistent with other pointers in C, 
because in the way you mentioned, they aren't?

>>> Bottom line, I'm not defending the way C takes addresses of functions, 
>>> but I think the requirement C has to use parentheses to call functions 
>>> helps to clarify the intentions of the function author, and makes the 
>>> code clearer.
>> I agree, and I'd agree even more if you replaced "think" with "believe".
> 
> 
> Think and believe to me both mean 'This is true in my mind'.  If you find 
> one to be more appealing, so be it.

Thinking evokes process. Someone starts from a belief A, does some 
thinking, and reaches B. Then A is a belief and B is a thought resulting 
from that belief. (Euclidean axioms -> thinking -> sum of angles in a 
triangle is 180.) A philosopher 
(http://en.wikipedia.org/wiki/Constantin_Noica) wrote a book on logic 
that clarifies this relationship beautifully. His thesis is that logic 
essentially does not bring anything new, it's just a rehash of the 
beliefs stated in the axioms. To him logic was in a sense "conservation" 
because it only shuffled facts, not discovering new ones.

I _believe_ a language should obey the principles 1 and 2 (economy of 
syntax and giving syntactic priority to frequent use cases). Based on 
that belief, I _think_ D should drop the trailing parens.

I agree that somebody could _believe_ in some other principles that 
replace or override mine and then _think_ that keeping trailing parens 
is a good thing. Sergey did just that by showing us some very good 
examples when absence of trailing parens leads to ambiguity. Then there 
is room for meaningful discussion.

It is also possible that somebody simply _believes_ the trailing parens 
should be kept because they make code clearer to them. That's fair too, 
as long as there is understanding that that belief comes to a certain 
extent at odds with principles 1 and 2 (which anyone is free to simply 
not believe).

The only place that needs work is when the connection between belief and 
thought is unclear, or when the belief is simply wrong.


Andrei