Revised RFC on range design for D2

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Oct 1 07:08:47 PDT 2008


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



More information about the Digitalmars-d-announce mailing list