Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
May 14, 2012 Killing equals_t | ||||
---|---|---|---|---|
| ||||
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 14, 2012 Re: Killing equals_t | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 14, 2012 Re: Killing equals_t | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | 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 14, 2012 Re: Killing equals_t | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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
|
May 14, 2012 Re: Killing equals_t | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 14, 2012 Re: Killing equals_t | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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. |
December 23, 2012 Re: Killing equals_t | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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
|
December 23, 2012 Re: Killing equals_t | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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
|
Copyright © 1999-2021 by the D Language Foundation