Bug 1989 – opEquals should return bool

This has been requested many times on the NG (and I apologize if a bugzilla entry exists, I could not find it), but has been brushed off with bogus and/or outdated reasoning. Instead the int return cause confusion and problems, for instance in template code using bool returning predicates where opEquals won't work although doing the semantically same thing.

> ..but has been brushed off with bogus and/or outdated reasoning. opEquals returning bool makes sense, performance was given as the reason for not changing things. See, http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html.

(In reply to comment #1) > > ..but has been brushed off with bogus and/or outdated reasoning. > > opEquals returning bool makes sense, performance was given as the reason for > not changing things. > See, http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html. > This was discussed in the main newsgroup at a later date, and it was shown there that the performance reasoning was outdated. Unfortunately I don't have the link handy.

here's the link: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF :) int areEqual(int op1, int op2) { return op1-op2; } mov eax, [ebp+8] sub eax, [ebp+12] ; now eax contains 0 if they're equal, this is not what we want. ; negate it setz al ; 3 bytes, 1 cycle and eax, 1 ; 3 bytes, 1 cycle ret 8 using bool: mov eax, [ebp+8] cmp eax, [ebp+12] sete al ; 3 bytes, 1 cycle ret 8 I can't see efficiency of int used instead of bool.

Here's a post which further ridicules the performance argument: http://yarchive.net/comp/fastest_int.html A quote from the summary: 'the bottom line of all of this, is that "fastest" is a very slippery metric, and no one should ever expect that any one size is uniformly faster, because it hardly ever is'. I set the version to 0.163 based on Issue 288, although maybe this should just be considered a duplicate of it?

(In reply to comment #2) > (In reply to comment #1) > > > ..but has been brushed off with bogus and/or outdated reasoning. > > > > opEquals returning bool makes sense, performance was given as the reason for > > not changing things. > > See, http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html. > > > This was discussed in the main newsgroup at a later date, and it was shown > there that the performance reasoning was outdated. Unfortunately I don't have > the link handy. Lol, the NG thread where the performance argument was debunked is that very same one Gide posted ;), see this post: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html#N8005

*** This bug has been marked as a duplicate of 288 ***

(In reply to comment #2) > This was discussed in the main newsgroup at a later date, and it was shown > there that the performance reasoning was outdated. Unfortunately I don't have > the link handy. Was there any "performance reasoning" for this particular case that was even valid in the first place? (In reply to comment #3) > int areEqual(int op1, int op2) > { return op1-op2; } Uh, that doesn't even work. Try it for yourself and see. Yet more reasons that opEquals should return bool: http://tinyurl.com/6p93a9

this is already fixed since 2.016

(In reply to comment #7) > > int areEqual(int op1, int op2) > > { return op1-op2; } > > Uh, that doesn't even work. Try it for yourself and see. > Uh, yeah :) negation was reflected in the assembly code.