Revised RFC on range design for D2

[Yigal Chripun]

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.
so if a delegate contains two pointers (function pointer and context
pointer) I'd take the first with & and the other with a property of the
delegate as a possible syntax.
a delegate should have both a ptr and a context properties.
this can be used for example when calling C code.

just like you can have a D array and call a C function with
C_func(array.ptr, array.length);

C_function_which_calls_d_delegate(dg.ptr, dg.context);
OR
C_function_which_calls_d_delegate(&dg, dg.context);

in D code you'd probably use the delegate form more often than the
function pointer, at least for regular application coding stuff.