Revised RFC on range design for D2

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> Steven Schveighoffer wrote:
>>> "Andrei Alexandrescu" wrote
>>>> Steven Schveighoffer wrote:
>>>>> "Andrei Alexandrescu" wrote
>>>>>> Steven Schveighoffer wrote:
>>>>>>> "Andrei Alexandrescu" wrote
>>>>>>>>> P.S. If src.next() is too lengthy, why not just adopt ++src?
>>>>>>>> Because people (in wake of the recently introduced array operations) 
>>>>>>>> may legitimately expect that to mean "increment all elements of 
>>>>>>>> src".
>>>>>>> So in one case, you believe people's assumptions aren't important, 
>>>>>>> i.e. an assumption that .next without parens will not change anything 
>>>>>>> on the object, yet in another case you believe people's assumptions 
>>>>>>> are the main argument. This doesn't sound consistent.
>>>>>> Of course it is. One expectation has to do with operational 
>>>>>> consistency (albeit a tad far-fetched), the other has to do with being 
>>>>>> used to a mistaken decision in the C language design.
>>>>> 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.
>>> Forgive me, but I must have missed it.  I saw only your assumption (or 
>>> supposition) that the C designers made a mistake.
>> My post on 25 Sep 2008 17:58:52 -0500 mentions:
>>
>> "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."
> 
> Hidden in this statement is that you consider () to be semantically 
> meaningless.  I see it not as meaningless, but a distinction between what 
> the symbol is supposed to represent.  A property should represent a value. 
> A function should represent an action.

Sheesh, do I really need to spoonfeed all of this? First I mentioned the 
principles I quoted above. Then I clearly explained how C's handling of 
function names breaks these principle, with examples. Please refer to 
that post. There is nothing hidden my statement.

> I'll also note that your basis/proof is not any more proof than mine ;)  You 
> just made statements about what you believe, as did I.

The note is wrong. I provide the principles as basis. Then I provide 
proof using that basis. If you want to invalidate that, you need to 
invalidate my basis, i.e., the principles of language design I am 
invoking. You are of course free to do that since principles of 
programming language design are to large extent a subjective matter.

>>>> What is the basis of yours?
>>> I don't have any actual proof that they did this on purpose, I wasn't 
>>> working at Bell labs when C was invented, in fact, I don't even think I 
>>> was born ;)
>>>
>>> But it makes logical sense, and still does.  If you want to call a 
>>> function, you have to use parentheses.  If you want to access the 
>>> function address, no parentheses.
>> This is no logic. Your proof is just stating the conclusion. It's a 
>> logical fallacy called proof by assertion.
> 
> Sorry, change my statement to 'But it makes sense and still does'.  And I 
> never said it was a proof.  It's a statement of my reasons behind believing 
> the () decision was on purpose.

The decision was on purpose, I am sure it wasn't an oversight. It was a 
poor decision because it breaks the aforementioned principles.

>>> It follows other design decisions they made:
>>>
>>> pointers:  Access what it's pointing to, use ->, get address it's 
>>> pointing to, use symbol alone.
>> This is wrong too. If you use symbol alone, you are not getting its 
>> address. You are referring the pointer, which is an address. It would have 
>> been consistent with other design decisions if referring a variable alone 
>> would take its address.
> 
> Not really.  A function symbol by itself is the address of the function.  A 
> pointer symbol by itself is the address of the data it points to.  It's the 
> same.  I don't think you understood the detail that I stated, 'get address 
> it's pointing to', not 'get address of the pointer'.

I understood very well. Your point is off by a mile, and getting only 
farther. Please understand how you are making an elementary mistake.

Consider:

int x;

Then if I only use "x", I am getting x's value (an lvalue in fact), not 
its address. Now consider:

int * x;

Then if I only use "x", I am getting x's value, which is the address of 
an int.

In neither case is it possible for x and &x to mean the same thing. For 
functions some really weird stuff happens:

// this is C
#include <assert.h>
void foo() {}

int main()
{
     void (*p1)() = foo;
     void (*p2)() = &foo;
     assert(p1 == p2);
}

So in fact accessing the name of the function and applying the 
address-of operator to it yield the same thing. That does not happen to 
pointers and anything else. Accessing any other symbol yields its value, 
not its address. I hope that clarifies things.

Before anyone will point that out, I'll hurry to mention C does have one 
other instance in which a symbol "decays" to an address: names f 
fixed-sized arrays decay to the address of their first element. Still 
for them the address-of operator is not idempotent, and the decision to 
allow said decaying has good justification given by subtyping.


Andrei