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:
>>>>>> 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.
-- Yigal