These, of course, are C++ operators that are replace with the . operator in D. But when I translate C++ code to D, sometimes these operators get left behind, and sometimes I simply reflexively type them into D code.

The error message coming out of dmd could be better. I suggest recognizing -> and :: in the lexer, and saying something like:

   "The '->' operator is not in D, did you mean '.'?"

Anyone want to do a PR for this? (Should be pretty straightforward.)

On 10/08/2015 08:41 PM, Walter Bright wrote:
> These, of course, are C++ operators that are replace with the . operator
> in D. But when I translate C++ code to D, sometimes these operators get
> left behind, and sometimes I simply reflexively type them into D code.
>
> The error message coming out of dmd could be better. I suggest
> recognizing -> and :: in the lexer, and saying something like:
>
>     "The '->' operator is not in D, did you mean '.'?"
>
> Anyone want to do a PR for this? (Should be pretty straightforward.)

Semi-relatedly, a colleague who has heard many D sales pitches from me over the years is recently "looking at Go" and liking it very much. He came to me today telling me about this awesome Go feature where you just type a dot after a pointer and the language is so great that it works! You don't need to type (*p).member. Isn't Go awesome!

I responded "yep, it's a great feature and those gostards will never admit that they took that feature from D." (There is probably earlier precedence but it felt great to say it to my friend. :) )

Ali

On Friday, 9 October 2015 at 03:41:42 UTC, Walter Bright wrote:
>
>    "The '->' operator is not in D, did you mean '.'?"
>

In the binary case, -> and <- are assignment operators in R. But I imagine you don't want to go crazy with these sorts of messages.

On Friday, 9 October 2015 at 03:41:42 UTC, Walter Bright wrote:
> These, of course, are C++ operators that are replace with the . operator in D. But when I translate C++ code to D, sometimes these operators get left behind, and sometimes I simply reflexively type them into D code.
>
> The error message coming out of dmd could be better. I suggest recognizing -> and :: in the lexer, and saying something like:
>
>    "The '->' operator is not in D, did you mean '.'?"
>
> Anyone want to do a PR for this? (Should be pretty straightforward.)

Too late to change but wouldn't it be better to have one operator for members and another for UFCS? '->' would be good for UFCS.

On Friday, 9 October 2015 at 10:03:18 UTC, ixid wrote:
> Too late to change but wouldn't it be better to have one operator for members and another for UFCS? '->' would be good for UFCS.

That would defeat the purpose of _Uniform_ Function Call Syntax. The whole point is that it uses the same syntax for member functions and free functions. In many cases, it's just for aesthetic purposes, but with templated code, it can be critical, because it allows you to effectively overload a free function with a member function (e.g. a particular range type could overload find if it had a more efficient implementation for it than the one in std.algorithm). It also makes it so that a type which doesn't have member functions can work in a template that's expecting the type to have specific member functions (e.g. arrays use free functions for the range primitives, but they're normally used as if they were member functions).

- Jonathan M Davis

On Friday, 9 October 2015 at 10:15:42 UTC, Jonathan M Davis wrote:
> That would defeat the purpose of _Uniform_ Function Call Syntax...

For some reason I'd thought it didn't work when you mixed member function calls with function calls but it seems to do so smoothly.

On Friday, 9 October 2015 at 10:42:03 UTC, ixid wrote:
> On Friday, 9 October 2015 at 10:15:42 UTC, Jonathan M Davis wrote:
>> That would defeat the purpose of _Uniform_ Function Call Syntax...
>
> For some reason I'd thought it didn't work when you mixed member function calls with function calls but it seems to do so smoothly.

It works fine in general, and if there's a conflict, it's the member function that gets called. So, if you want to guarantee that it's a particular free function that gets called, you need to not use UFCS (and possibly provide the full import path when using it). But in most cases, it's desirable for a member function to be able able to override the behavior of a free function. The main problem is when they happen to match but do completely different things.

- Jonathan M Davis

On Friday, 9 October 2015 at 04:15:42 UTC, Ali Çehreli wrote:
> Go feature where you just type a dot after a pointer and the language is so great that it works! You don't need to type (*p).member. Isn't Go awesome!
>
> I responded "yep, it's a great feature and those gostards will never admit that they took that feature from D." (There is probably earlier precedence but it felt great to say it to my friend. :) )

Just about all higher languages does this, since the reference type does not have members. Simula too.

But this unfortunately breaks down when you add smart-pointers, which makes this approach unsound since pointer-type members collide with object members.

So C++ actually got this right by requiring explicit dereferencing.

On Friday, 9 October 2015 at 12:19:55 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 9 October 2015 at 04:15:42 UTC, Ali Çehreli wrote:
>> Go feature where you just type a dot after a pointer and the language is so great that it works! You don't need to type (*p).member. Isn't Go awesome!
>>
>> I responded "yep, it's a great feature and those gostards will never admit that they took that feature from D." (There is probably earlier precedence but it felt great to say it to my friend. :) )
>
> Just about all higher languages does this, since the reference type does not have members. Simula too.
>
> But this unfortunately breaks down when you add smart-pointers, which makes this approach unsound since pointer-type members collide with object members.
>
> So C++ actually got this right by requiring explicit dereferencing.

The only case in which the C++ way is right is when there are two member functions of the same name in the pointed-to object and the smart pointer itself since you can disambiguate `ptr->get()` from `ptr.get()`.

Atila

On 10/09/2015 05:19 AM, Ola Fosheim Grøstad wrote:
> On Friday, 9 October 2015 at 04:15:42 UTC, Ali Çehreli wrote:
>> Go feature where you just type a dot after a pointer and the language
>> is so great that it works! You don't need to type (*p).member. Isn't
>> Go awesome!
>>
>> I responded "yep, it's a great feature and those gostards will never
>> admit that they took that feature from D." (There is probably earlier
>> precedence but it felt great to say it to my friend. :) )
>
> Just about all higher languages does this, since the reference type does
> not have members. Simula too.
>
> But this unfortunately breaks down when you add smart-pointers, which
> makes this approach unsound since pointer-type members collide with
> object members.

Yeah... Type properties is another example for D: .sizeof and .alignof are not propagated to the pointee and .stringof is not propagated to the type of the pointee.

Similarly, for class references, one must remember to use __traits(classInstanceSize) and std.traits.classInstanceAlignment. (Yes, I notice the inconsistency. ;) )

Ali