Vision for the D language - stabilizing complexity?

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 12 04:19:51 PDT 2016


On 7/12/2016 3:55 AM, Shachar Shemesh wrote:
> On 12/07/16 13:25, Walter Bright wrote:
>> On 7/12/2016 12:35 AM, Shachar Shemesh wrote:
>>> UFCS: Anywhere you can do "func(a)" you can also do "a.func()" and vice
>>> versa.
>>>
>>> Operator ->: Not needed, as we know this is a pointer to a struct. We
>>> automatically dereference with the dot operator.
>>>
>>> struct A {
>>>      void method() {}
>>> }
>>>
>>> void main() {
>>>      A* a;
>>>
>>>      a.method(); // Okay
>>>      method(a);  // Not okay
>>> }
>>
>> I'm afraid I don't know what you're driving at with those examples.
>>
>
> It is a single example. It shows that when UCFS and the lack of operator
> -> try to play together, the result is no longer as simple and elegant
> as one tries to sell them. It was given as a response to Andrei's
> request for examples of cross-features interference causing complexity.

I assumed you were talking about UB or unsafe behavior. Thanks for the 
clarification.

As to the specific case here, the spec doesn't say "vice versa":

"A free function can be called with a syntax that looks as if the 
function were a member function of its first parameter type."

http://dlang.org/spec/function.html#pseudo-member

Not the other way.


More information about the Digitalmars-d mailing list