Killing equals_t

[Phil Lavoie]

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