Revised RFC on range design for D2

Yigal Chripun yigal100 at gmail.com
Wed Oct 1 07:21:43 PDT 2008


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);
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?


More information about the Digitalmars-d-announce mailing list