On Thu, Oct 25, 2012 at 06:34:32PM -0700, Ellery Newcomer wrote:
> On 10/24/2012 01:16 PM, Mehrdad wrote:
> >On Wednesday, 24 October 2012 at 20:03:44 UTC, H. S. Teoh wrote:
> >>What's wrong with RedBlackTree? You can just do something like:
> >>
> >>    RedBlackTree!(RedBlackTree!MySet) setOfSets;
> >
> >The last time I checked two RedBlackTrees for equality, they seemed to have reference semantics...
> >
> 
> Dang.
> 
> import std.container;
> import std.stdio;
> 
> void main() {
>     auto a = make!(RedBlackTree!int)(1,2,3,4);
>     auto b = make!(RedBlackTree!int)(1,2,3,4);
>     writeln(a == b);
> }
> 
> prints
> 
> false
> 
> 
> Explanation: RedBlackTree doesn't override opEquals. Either file an enhancement request or use equal(a[], b[]), depending on whether opEquals *should* have reference semantics.

Hmph. This is what I don't like about the built-in ==. Its semantics are inconsistent once you leave the realm of ints and floats and other numerical types. I think this one is worthy of a bug report.


> Actually, it shouldn't, since that would differ from array/string opEquals semantics.

Yeah, Jonathan is right, "==" should *always* do a deep compare, and leave "is" to do a shallow compare. Anything else is inconsistent, and leads to all kinds of pathological bugs.


T

-- 
Любишь кататься - люби и саночки возить.

On 10/25/2012 09:19 PM, H. S. Teoh wrote:
>
> Hmph. This is what I don't like about the built-in ==. Its semantics are
> inconsistent once you leave the realm of ints and floats and other
> numerical types. I think this one is worthy of a bug report.
>

Well, if nobody else is going to take it

http://d.puremagic.com/issues/show_bug.cgi?id=8896

Le 25/10/2012 03:35, Jonathan M Davis a écrit :
> On Wednesday, October 24, 2012 21:01:11 Andrei Alexandrescu wrote:
>> OK let's stop this. There's a bug that needs fixing, is all.
>
> And as bad as things may be now, they're _way_ better than they were a couple
> of years ago (or even a year ago). The situation isn't perfect, but it's
> constantly improving. It's becoming rarer and rarer for programmers to run
> into compiler bugs.

Is this a joke ? That is true that many bug get solved, but I encounter compiler bugs almost on a daily basis, and a lot of workaround are present in my codebase.

I'm ready to heard that I run into more bugs due to my coding style or whatever, but I have hard time to understand how running into compiler bugs can be rarer and rarer.

You can actually write plenty of programmers now without
> running into any, whereas before, you'd run into them all the time.
>
> - Jonathan M Davis

Le 25/10/2012 04:12, Jonathan M Davis a écrit :
> On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
>> The default compare for structs is a bit compare of the contents.
>
> Which definitely seems inherently broken. Doing that only works if the struct
> only contains integral types, character types, or bool. Nothing else will
> compare properly that way. It really needs to work like arrays do (or are
> supposed to anyway) and compare each member according to == and only fallback
> to an outright bitwise compare when it knows that the results would be
> identical (i.e. because all of the members are integral types, character
> types, bool, or other structs which hold only integral types, character types,
> or bool - be it directly or in other structs that they hold). Bitwise comparison
> is the is operator's job, not ==.
>
> - Jonathan M Davis

That will broke code.

But That is the way to go IMO. D needs to evolve to make things more consistent in general.

Still not doable without a proper versionning scheme.

On Friday, October 26, 2012 19:46:16 deadalnix wrote:
> Le 25/10/2012 04:12, Jonathan M Davis a écrit :
> > On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
> >> The default compare for structs is a bit compare of the contents.
> > 
> > Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way. It really needs to work like arrays do (or are supposed to anyway) and compare each member according to == and only fallback to an outright bitwise compare when it knows that the results would be identical (i.e. because all of the members are integral types, character types, bool, or other structs which hold only integral types, character types, or bool - be it directly or in other structs that they hold). Bitwise comparison is the is operator's job, not ==.
> > 
> > - Jonathan M Davis
> 
> That will broke code.
> 
> But That is the way to go IMO. D needs to evolve to make things more consistent in general.
> 
> Still not doable without a proper versionning scheme.

TDPL clearly states that each of the struct's members are supposed to be checked for equality (see section 7.1.5.2, p. 258 - 259). It's outright a bug for structs to be checked for equality with a bitwise comparison when the bitwise comparison does not do exactly what == would have done had each and every member variable been compared with ==. And as with all bugs, fixing it could break code which depends on the buggy behavior. But given the nature of this bug, I seriously question that much of anyone thought that the == on structs was supposed to do anything other than what TDPL states that it should and that pretty much no one was expecting it to do a bitwise comparison. So, if anything, this will _fix_ far more code than it breaks.

- Jonathan M Davis

On Sat, Oct 27, 2012 at 07:52:37PM -0700, Jonathan M Davis wrote: [...]
> TDPL clearly states that each of the struct's members are supposed to be checked for equality (see section 7.1.5.2, p. 258 - 259). It's outright a bug for structs to be checked for equality with a bitwise comparison when the bitwise comparison does not do exactly what == would have done had each and every member variable been compared with ==. And as with all bugs, fixing it could break code which depends on the buggy behavior. But given the nature of this bug, I seriously question that much of anyone thought that the == on structs was supposed to do anything other than what TDPL states that it should and that pretty much no one was expecting it to do a bitwise comparison. So, if anything, this will _fix_ far more code than it breaks.
[...]

+1.

I have to say I was surprised to find out about this after I started using D; after first reading TDPL, I had the impression that it was supposed to do the "right thing" (and the right thing being == on each field, which I assumed the compiler would optimize into a bitwise compare where possible).

Let's fix this.


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.

On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
> He who does not appreciate the beauty of language is not worthy to bemoan its flaws.

That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;)

- Jonathan M Davis

Jonathan M Davis wrote:
> On Friday, October 26, 2012 19:46:16 deadalnix wrote:
> > Le 25/10/2012 04:12, Jonathan M Davis a écrit :
> > > On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
> > >> The default compare for structs is a bit compare of the contents.
> > > 
> > > Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way. It really needs to work like arrays do (or are supposed to anyway) and compare each member according to == and only fallback to an outright bitwise compare when it knows that the results would be identical (i.e. because all of the members are integral types, character types, bool, or other structs which hold only integral types, character types, or bool - be it directly or in other structs that they hold). Bitwise comparison is the is operator's job, not ==.
> > > 
> > > - Jonathan M Davis
> > 
> > That will broke code.
> > 
> > But That is the way to go IMO. D needs to evolve to make things more consistent in general.
> > 
> > Still not doable without a proper versionning scheme.
> 
> TDPL clearly states that each of the struct's members are supposed to be checked for equality (see section 7.1.5.2, p. 258 - 259). It's outright a bug for structs to be checked for equality with a bitwise comparison when the bitwise comparison does not do exactly what == would have done had each and every member variable been compared with ==. And as with all bugs, fixing it could break code which depends on the buggy behavior. But given the nature of this bug, I seriously question that much of anyone thought that the == on structs was supposed to do anything other than what TDPL states that it should and that pretty much no one was expecting it to do a bitwise comparison. So, if anything, this will _fix_ far more code than it breaks.

I was looking for that section. 3789 is clearly a bug and should be
fixed as soon as possible.
Votes indicate how important a bug should be. But duplicates are also a
good indicator. This bug has six duplicates.

Jens

On 2012-10-26 19:46, deadalnix wrote:

> That will broke code.
>
> But That is the way to go IMO. D needs to evolve to make things more
> consistent in general.
>
> Still not doable without a proper versionning scheme.

Fixing bugs can always break code and I don't think any version scheme can help here. But what a version scheme can help with is when changing the API. When you add a new function, that won't break any code. Removing a function will break code.

-- 
/Jacob Carlborg

On Sat, Oct 27, 2012 at 10:42:21PM -0700, Jonathan M Davis wrote:
> On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
> > He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
> 
> That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;)
[...]

Wait, are you saying that D is one big flaw? ;-)


T

-- 
Ph.D. = Permanent head Damage