Revised RFC on range design for D2

[Yigal Chripun]

Andrei Alexandrescu wrote:
> 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

my main issue was with the syntax. and I still think it's inconsistent.
the only drawback I see with my suggestion is the need to implement this
additional feature with method pointers.

it adds consistency for the common case (delegates) without limiting any
of the current uses.

What other cons do you see for my suggestion besides the difficulty to
implement?