www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Killing equals_t

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
Hi,

Would anyone be terribly angry if equals_t was deprecated and later 
removed? I sent a patch a while back to add a compare_t type for 
consistency, but the consensus ended up being that it'd be better to get 
rid of equals_t.

-- 
- Alex
May 13 2012
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 14 May 2012 at 00:53:20 UTC, Alex Rønne Petersen 
wrote:
 Hi,

 Would anyone be terribly angry if equals_t was deprecated and 
 later removed? I sent a patch a while back to add a compare_t 
 type for consistency, but the consensus ended up being that 
 it'd be better to get rid of equals_t.
I don't have an opinion about either, but just to point this out: Equality is NOT the same thing as a comparison returning zero. (Consider complex numbers.)
May 13 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 14-05-2012 02:56, Mehrdad wrote:
 On Monday, 14 May 2012 at 00:53:20 UTC, Alex Rønne Petersen wrote:
 Hi,

 Would anyone be terribly angry if equals_t was deprecated and later
 removed? I sent a patch a while back to add a compare_t type for
 consistency, but the consensus ended up being that it'd be better to
 get rid of equals_t.
I don't have an opinion about either, but just to point this out: Equality is NOT the same thing as a comparison returning zero. (Consider complex numbers.)
I know that, but not sure what it has to do with this... -- - Alex
May 13 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, May 14, 2012 02:53:20 Alex R=C3=B8nne Petersen wrote:
 Hi,
=20
 Would anyone be terribly angry if equals_t was deprecated and later
 removed? I sent a patch a while back to add a compare_t type for
 consistency, but the consensus ended up being that it'd be better to =
get
 rid of equals_t.
I definitely think that it should be killed. It's ludicrous for a funct= ion=20 whose result is boolean to ever return anything other than bool. If it = wer=20 returning something which was _convertible_ to bool but had other uses = (e.g.=20 in), then that would be different, but that's not the case with opEqual= s at=20 all. equals_t is not mentioned in TDPL (rather, TDPL specifically lists opEq= uals as=20 returning bool), and I see _zero_ value in having bool at this point. A= s I=20 understand it, it was created purely for transitional purposes (since D= 1 made=20 the mistake of having opEquals return int), and I really don't think th= at=20 that's necessary or particularly helpful at this point. - Jonathan M Davis
May 13 2012
next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 14 May 2012 at 02:35:11 UTC, Jonathan M Davis wrote:
 equals_t is not mentioned in TDPL (rather, TDPL specifically 
 lists opEquals as returning bool), and I see _zero_ value in 
 having bool at this point. As I understand it, it was created 
 purely for transitional purposes (since D1 made the mistake of 
 having opEquals return int), and I really don't think that 
 that's necessary or particularly helpful at this point.
Curious, I don't remember it anywhere at all. Then again I didn't do much in D1 either..
May 13 2012
prev sibling next sibling parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Monday, 14 May 2012 at 02:35:11 UTC, Jonathan M Davis wrote:
 On Monday, May 14, 2012 02:53:20 Alex Rønne Petersen wrote:
 Hi,
 
 Would anyone be terribly angry if equals_t was deprecated and 
 later
 removed? I sent a patch a while back to add a compare_t type 
 for
 consistency, but the consensus ended up being that it'd be 
 better to get
 rid of equals_t.
I definitely think that it should be killed. It's ludicrous for a function whose result is boolean to ever return anything other than bool. If it wer returning something which was _convertible_ to bool but had other uses (e.g. in), then that would be different, but that's not the case with opEquals at all. equals_t is not mentioned in TDPL (rather, TDPL specifically lists opEquals as returning bool), and I see _zero_ value in having bool at this point. As I understand it, it was created purely for transitional purposes (since D1 made the mistake of having opEquals return int), and I really don't think that that's necessary or particularly helpful at this point. - Jonathan M Davis
Well said. I was just scoping through the documentation of the Object class to investigate a statement someone made and I found that opEquals returned equals_t. Wanting to make sure I understood why, I started looking for a definition of equals_t and I ended up here, reading this thread. I don't see why someone would like to treat the result as a value other than a simple bool. But I do understand the need for transition. My vote is kill it, and make it painless :). Phil
Dec 23 2012
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 (since D1 made the mistake of having opEquals return int),
I think it wasn't a mistake, more like a design choice. In some cases (especially when there is no inlining) computing and returning an int is more efficient than converting to bool. In practice I think the increase in performance is not significant with modern compilers, and I prefer the clarity of a bool result. Bye, bearophile
Dec 23 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, May 14, 2012 at 02:53:20AM +0200, Alex Rønne Petersen wrote:
 Hi,
 
 Would anyone be terribly angry if equals_t was deprecated and later
 removed? I sent a patch a while back to add a compare_t type for
 consistency, but the consensus ended up being that it'd be better to
 get rid of equals_t.
[...] I vote to get rid of it. We should just stick with bool. T -- Obviously, some things aren't very obvious.
May 13 2012