Revised RFC on range design for D2
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Wed Oct 1 06:35:20 PDT 2008
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
More information about the Digitalmars-d-announce
mailing list