Revised RFC on range design for D2

[Andrei Alexandrescu]

Yigal Chripun wrote:
> Andrei Alexandrescu wrote:
>> 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
> 
> if I understand it correctly, in C++ the type of this is encoded in the
> signature (as above) and you use obj.*pointer(..); to call the function.
> this is a possible solution (using the C++ pointer to member function).
> however, maybe we should use a more python like solution:
> the signature becomes: int function(Test, int);
> and this refers to the first argument (just like you pass the "self" in
> Python).
> 
> I think i prefer the second option more [ int function(Test, int) ] and
> it will be easier to use in C.

It's great that you are now equipped to appreciate the advantages and 
disadvantages of various tradeoffs. Maybe a reevaluation of the existing 
solution would be useful.

Andrei