Revised RFC on range design for D2

[Andrei Alexandrescu]

Yigal Chripun wrote:
> Andrei Alexandrescu wrote:
>> Yigal Chripun wrote:
>>> Andrei Alexandrescu wrote:
>>>> Yigal Chripun wrote:
>>>>> Benji Smith wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> I stated two principles of language design. They could be true or
>>>>>>> false. They are up there for debate. They are subjective, because
>>>>>>> aside from some basics, language design is subjective.
>>>>>>>
>>>>>>> The principles are:
>>>>>>>
>>>>>>> 1) A language should minimize the number of syntactic constructs that
>>>>>>> are semantically and/or pragmatically meaningless.
>>>>>>>
>>>>>>> 2) 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.
>>>>>> I'd like to propose another principle of language design:
>>>>>>
>>>>>> 3) Consistency -- The expression of a semantic construct should always
>>>>>> use the same syntax. Likewise, multiple uses of the same syntactic
>>>>>> constructs should always result in the same semantics.
>>>>>>
>>>>>> Based on that principle, I'd argue that function-calling should either
>>>>>> always use parentheses, or it should never use parentheses.
>>>>>>
>>>>>> Requiring parentheses for some function calls, but not for others
>>>>>> violates the principle of consistency.
>>>>>>
>>>>>> In my prioritization of language-design principles, consistency is
>>>>>> more
>>>>>> important then syntactic economy.
>>>>>>
>>>>>> Based on those principles, I believe that the parentheses should be
>>>>>> mandatory for all function calls.
>>>>>>
>>>>>> --benji
>>>>> I was about to post a very similar post (it's still in my drafts
>>>>> folder)
>>>>> besides fully agreeing with the above, I'll add the following:
>>>>> operator & in D is not consistent.
>>>>>
>>>>> int x;
>>>>> auto y = &x; // y is int* (i.e pointer to int)
>>>>>
>>>>> int func(int);
>>>>> auto f = &func; // consistent with the above:
>>>>> // f's type is - int function(int); i.e function pointer.
>>>>>
>>>>> let's try a class:
>>>>> class Test {
>>>>>   int x;
>>>>>   int func(int);
>>>>> }
>>>>>
>>>>> auto test = new Test();
>>>>> auto y = &test.x; // consistent with the above
>>>>> auto g = &test.func; // this is inconsistent!
>>>>> in the above g is a delegate which is not a function pointer.
>>>>> just as int* is different from int[]. you wouldn't expect to get an
>>>>> int[] in the above, would you?
>>>>>
>>>>> a more consistent approach would be to have:
>>>>> - func and obj.method to be treated as delegates, of course for
>>>>> function
>>>>> pointers there should be an implicit cast to delegate.
>>>>> - &func and &obj.method would be strictly function pointers.
>>>>> - using parentheses is mandatory for function calls.
>>>> A delegate /is/ a function pointer, more precisely, a pointer to
>>>> function packed with a pointer to a value.
>>>>
>>>> This also seems to reveal a lack of understanding of how class methods
>>>> work. What function would you make &obj.method point to?
>>>>
>>>>
>>>> Andrei
>>> I understand a delegate as a struct of two pointers as you said so
>>> yourself, above. an int[] != int* and so does a delegate != [C like]
>>> function pointer.
>>>
>>> I'd make &obj.method to be the function pointer stored in the delegate.
>> What is the signature of that function?
>>
>> Andrei
>>
> 
> say we have:
> class Test {
>   int method(int);
> }
> 
> auto obj = new Test();
> auto fPtr = &obj.method;
> 
> type of fPtr would be: int function(int); or in C syntax: int (*)(int);

That doesn't stay glued. What is "this" inside the function?

> are you asking because of C++ pointer-to-member-function types?
> in C++: int (Test::*)(int); ?
> 
> You know C++ much better than most of us here (certainly better than
> me), in your experience, is that distinction useful?

C++ pointers to member functions aren't that well designed. But at least 
they work :o|.


Andrei