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

           Summary: opEquals should return bool
           Product: D
           Version: 1.028
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: larsivar@igesund.net


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.


-- 

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





------- Comment #1 from gide@nwawudu.com  2008-04-14 05:45 -------
> ..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.


-- 

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





------- Comment #2 from larsivar@igesund.net  2008-04-14 05:54 -------
(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.


-- 

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





------- Comment #3 from terranium@yandex.ru  2008-05-22 07:33 -------
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.


-- 

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


matti.niemenmaa+dbugzilla@iki.fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |All
            Version|1.028                       |0.163




------- Comment #4 from matti.niemenmaa+dbugzilla@iki.fi  2008-05-26 09:50 -------
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?


-- 

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





------- Comment #5 from brunodomedeiros+bugz@gmail.com  2008-06-10 10:59 -------
(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


-- 

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


gide@nwawudu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




------- Comment #6 from gide@nwawudu.com  2008-09-03 08:08 -------


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


-- 

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


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com




------- Comment #7 from smjg@iname.com  2008-09-03 09:02 -------
(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


-- 

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





------- Comment #8 from spam@extrawurst.org  2008-09-03 09:41 -------
this is already fixed since 2.016


-- 

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





------- Comment #9 from terranium@yandex.ru  2008-09-10 09:40 -------
(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.


--