Re: [boost] [atomic] (op)_and_test naming

Subject: Re: [boost] [atomic] (op)_and_test naming
From: Rob Stewart (rstewart_at_[hidden])
Date: 2018-01-26 00:23:31

On January 25, 2018 6:59:52 PM EST, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> Frank Mori Hess wrote:
> 
> > I haven't been following this specific discussion closely, but in
> general, 
> > I wish designers put a higher value on consistency than on trying to
> guess 
> > what the audience's expectations are.  Consistency leads to tools
> whose 
> > behavior can be reasoned about and competence with can be achieved. 
> > Guessing what the people want leads to incomprehensible black boxes
> that 
> > the user pokes at, hoping it will guess what they want it to do.
> 
> The specific situation under discussion is as follows:
> 
> 1. Andrey has provided a function x.sub_and_test(v) which returns true
> when  the result is zero.
> 2. Gavin argues that it should return true when the result is not
> zero.
> 3. I say that the function should be x.sub_and_test_if_zero(v) which
> returns  true when the result is zero.
> 
> In (1), Andrey has provided the function as it is not because this is
> his  guess of what people want, but because true on zero feels more
> natural as 
> it's much more common to test for zero than to test for nonzero after 
> subtraction. (Not so after a bitwise operation, admittedly.)

I don't have the OP handy, but I thought Andrey said it was because that matched the expression he created the function to replace.

> In (2), Gavin argues for true on nonzero not because this is what
> people want, but because of consistency.
> 
> In (3), I suggest the rename not because this is what people want, but
> because I want to remove the ambiguity and the need to guess. 

I argue that consistency with the other functions is enough to solve this problem since any user of the library must learn its conventions. The rest of the functions are bound to confuse a subset of users, but the greater confusion comes from the function in question testing for a different but value than the rest.

To follow your approach would, I contend, require renaming the other functions in a similar manner. I'm not against that idea, but it is a bigger change.

--
Rob
(Sent from my portable computation device.)