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:
>>>>>>> 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?

I think we're better off with the current state of affairs.

Andrei