On Tuesday, 23 April 2013 at 04:48:05 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote:
>> It has nothing to do with the standard library.
>> It should do whatever operator == does.
>
> Sounds slow. We really need a way for you to choose to have it your way and the way it is now.
>
> Oh, there's opEquals. Now we can both be happy. :)

For fast bitwise comparison there's the "is" operator.
The "==" operator should be "slow".
See also http://d.puremagic.com/issues/show_bug.cgi?id=3789

On Tuesday, 23 April 2013 at 04:56:13 UTC, kenji hara wrote:
> 2013/4/23 Mehrdad <wfunction@hotmail.com>
>
>> On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
>>
>>>
>>> This is mostly expected behavior. During compilation value identities are
>>> not guaranteed.
>>> Because compile time evaluation is always done after constant folding, and
>>> constant folding would fold "x".idup to "x", then S("x") == S("x") is
>>>
>>> evaluated to true.
>>>
>>> Kenji Hara
>>>
>>
>> I'm not saying the 'true' is broken, I'm saying the 'false' is broken.
>>
>>
>> And don't miss this one, which contradicts the behavior above
>> http://forum.dlang.org/thread/**uqkslzjnosrsnyqnhzes@forum.**
>> dlang.org?page=2#post-**zdmtaeycpomrhjdeanlw:40forum.**dlang.org<http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes@forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org>
>>
>
> Ah, OK. Surely that is a compiler bug which still not fixed.


Well, I think the float behavior is correct and the string example is broken, but that wasn't my point anyway.

The point was that it's still broken.

On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:
> For fast bitwise comparison there's the "is" operator.
> The "==" operator should be "slow".
> See also http://d.puremagic.com/issues/show_bug.cgi?id=3789

Well okay. The docs will have to be updated for this issue if it's "fixed".

For instance:
http://dlang.org/ctod.html#structcmp

In any case, I stand by that if you have a particular definition of behavior, you should provide it instead of expecting it to "just work." But I suppose using "is" is more appropriate for this type of behavior. But calling it "broken" is a bit too strong.

On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
> In any case, I stand by that if you have a particular definition of behavior, you should provide it instead of expecting it to "just work." But I suppose using "is" is more appropriate for this type of behavior. But calling it "broken" is a bit too strong.

Actually, I'm going to strengthen this a bit more. I'd _still_ think it's a good idea to keep structs the way they are. I expect (as I think many would) structs to be very bare metal. Very little auto-magic should touch them because they are used so often for low-level tasks and you really ought to be very precise when you're defining them and their behavior. In that context, "==" being the same as "is" makes sense from my perspective and I wouldn't expect anything else unless I explicitly told it otherwise.

If you want some of that type of automatic "just works" behavior, you're probably using structs as more higher level concepts. Maybe consider using a tuple instead?


import std.stdio, std.typecons;
void main() { writeln(tuple("a") == tuple("a".idup)); }


Outputs:
true

And it's shorter and simpler than the struct example.

On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
> I suppose using "is" is more appropriate for this type of behavior.


If when you see a == b you think,
	Hey, that's equivalent to (a.d is b.d)
I suppose that when you see (a is b) you think,
	Hey, that's equivalent to a.d == b.d
?


> But calling it "broken" is a bit too strong.


If it doesn't make sense, it's broken.


Implementing == as 'is' by default doesn't make sense when there is already an 'is' operator that could do the same, hence it's broken.

On Tuesday, 23 April 2013 at 05:16:35 UTC, Chris Cain wrote:
> Actually, I'm going to strengthen this a bit more. I'd _still_ think it's a good idea to keep structs the way they are. I expect (as I think many would) structs to be very bare metal. Very little auto-magic should touch them because they are used so often for low-level tasks and you really ought to be very precise when you're defining them and their behavior. In that context, "==" being the same as "is" makes sense from my perspective and I wouldn't expect anything else unless I explicitly told it otherwise.

I don't feel strongly about which path is right. But (as Mehrdad has shown) the current behaviour is not consistent either way: strings are compared bitwise, floats are compared logically.

On Tuesday, 23 April 2013 at 05:28:54 UTC, Mehrdad wrote:
> If when you see a == b you think,
> 	Hey, that's equivalent to (a.d is b.d)
> I suppose that when you see (a is b) you think,
> 	Hey, that's equivalent to a.d == b.d
> ?

Incorrect. When I see a == b, I don't think anything. Thanks to encapsulation, typeof(a) and typeof(b) gets to decide what "==" means. If they happen to be structs, then if the author defined opEquals, then that's what it means. Otherwise, it's just a simple bitwise comparison (or should be).

> If it doesn't make sense, it's broken.
>
>
> Implementing == as 'is' by default doesn't make sense when there is already an 'is' operator that could do the same, hence it's broken.

It doesn't make sense to _you_. It's a purely subjective matter. And considering I've explained the way to think about it so it should be cleared up now. It's a minor stumbling block at best.

Define opEquals and everything will work how you want. Very simple solution to a problem you seem to be blowing out of proportion. My very first post fixed your bug.

Is there something stopping you from defining opEquals for the behavior you want?

On Tuesday, 23 April 2013 at 05:48:08 UTC, Chris Cain wrote:
> Incorrect. When I see a == b, I don't think anything.

I stand corrected I guess. I'll stop thinking as well.


> It doesn't make sense to _you_.


Okay sure, have fun watching people use languages that make more sense to them than D I guess.


> Is there something stopping you from defining opEquals for the behavior you want?

yes, unnecessary waste of time/effort

On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:
> I stand corrected I guess. I'll stop thinking as well.
> ...
> Okay sure, have fun watching people use languages that make more sense to them than D I guess.

*sigh*

I really wish you'd be more cooperative in this conversation. I certainly don't want to drive anyone away from D. I really don't understand why someone would say "If you don't do what I want, I'm leaving!" expecting to get their way, though.

I'm trying to explain to you what's going on so that you can understand what is happening so that it will "make sense to you."

> yes, unnecessary waste of time/effort

Maybe use a tuple or Tuple instead then? Even easier and less time consuming than defining a struct.

On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
>> ...
>>
>>
>> Nope, still broken.
>
> The behavior isn't too surprising to me. Your code is buggy.

You want to explain why the code is bugguy.