On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
> ?!??!

I'm confused by why you might be confused by this. opEquals by default is simply a bit-level value check.

"x" and "x".idup are two different things.

"x" might be:
  ptr = 0xDEADBEEF
  length = 1

and "x".idup might be:
  ptr = 0xDEADBEEE
  length = 1

Clearly they are not equal. If you have a particular definition that isn't the same as the the bit-level basic equality, you have a method of defining it.

For why the compiler treats them the same... well, it simply doesn't create a new place for "x".idup. Simple optimization that doesn't matter unless you're comparing their identity.

On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
>> ?!??!
>
> I'm confused by why you might be confused by this. opEquals by default is simply a bit-level value check.


Yeah, hence it's broken.

On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:
> Yeah, hence it's broken.

Um... I don't see the problem. Do you expect the compiler to treat strings/arrays special and look up the equal method in the standard library? Wouldn't that confuse you when it doesn't apply to your structures? Furthermore, requiring the compiler to know about the standard library doesn't sound broken to you?

On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
>> ?!??!
>
> opEquals by default is simply a bit-level value check.



In fact, it's _doubly_ broken...

	import std.stdio;
	struct S { float d; }
	void main()
	{
	    writeln(+0.0);
	    writeln(-0.0);
	    writeln(S(+0.0) == S(-0.0));
	}


Output:
	0
	-0
	true

On Tuesday, 23 April 2013 at 04:37:12 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:
>> Yeah, hence it's broken.
>
> Um... I don't see the problem. Do you expect the compiler to treat strings/arrays special and look up the equal method in the standard library? Wouldn't that confuse you when it doesn't apply to your structures? Furthermore, requiring the compiler to know about the standard library doesn't sound broken to you?



It has nothing to do with the standard library.
It should do whatever operator == does.

2013/4/23 Mehrdad <wfunction@hotmail.com>

> On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
>
>> I started a project a month ago, and for the moment my feeling is just: D can already be used as it.
>>
>
> Input:
>         import std.stdio;
>         struct S { string a; }
>         pragma(msg,           S("x") == S("x".idup));
>         void main() { writeln(S("x") == S("x".idup)); }
>
> Output:
>         true
>         false
>
> Nope, still broken.
>

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

On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
> 2013/4/23 Mehrdad <wfunction@hotmail.com>
>
>> On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
>>
>>> I started a project a month ago, and for the moment my feeling is just:
>>> D can already be used as it.
>>>
>>
>> Input:
>>         import std.stdio;
>>         struct S { string a; }
>>         pragma(msg,           S("x") == S("x".idup));
>>         void main() { writeln(S("x") == S("x".idup)); }
>>
>> Output:
>>         true
>>         false
>>
>> Nope, still broken.
>>
>
> 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

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. :)

In floating point value comparison, +0.0 is equal to -0.0.

    auto x = +0.0;
    auto y = -0.0;
    assert(x == y);

Kenji Hara


2013/4/23 Mehrdad <wfunction@hotmail.com>

> On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
>
>> On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
>>
>>> ?!??!
>>>
>>
>> opEquals by default is simply a bit-level value check.
>>
>
>
>
> In fact, it's _doubly_ broken...
>
>         import std.stdio;
>         struct S { float d; }
>         void main()
>         {
>             writeln(+0.0);
>             writeln(-0.0);
>             writeln(S(+0.0) == S(-0.0));
>         }
>
>
> Output:
>         0
>         -0
>         true
>

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.

Kenji Hara