View mode: basic / threaded / horizontal-split · Log in · Help
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
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
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
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
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
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
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
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
Top | Discussion index | About this forum | D home