Re: Adding logical implication to boost

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2025-01-07 01:07:27

pon., 6 sty 2025 o 19:43 Ivan Matek via Boost <boost_at_[hidden]>
napisał(a):

> On Sun, Jan 5, 2025 at 3:27 PM Traian Enache <ena.traian_at_[hidden]> wrote:
>
> > In my work, whenever I’ve had to do logical implications, I always
> > naturally used ‘!a || b’, not once has the thought of “geez, wish C++ had
> > => for logical implication” crossed my mind.
> >
>
> As I said I agree with regards to =>. In regards to boost::implies vs !a ||
> b  my belief is that it heavily depends on the person. For me (and I
> presume many others even if we are not majority) even after many years of
> programming if I saw something like
> boost::implies(student.graduaded(), student.num_active_courses() == 0)
> reads much much nicer than
> !student.graduaded() || student.num_active_courses() == 0
>
> So I am not trying to covert anybody to prefer implies function call, but I
> feel there is large number of people that would prefer a helper.
> As mentioned in the paper there is also the thing with the short circuit
> evaluation if second argument is invocable returning bool.
>

If you are only interested in a convenience function (and not the
short-circuiting properties),
this reminds me of Peter Dimov's remark about operator =>:
It already exists in C++ and is spelled operator <=.

Regards,
&rzej;

> P.S. if you do not mind sharing details about your usecases I wonder when
> did you find use for implication?.
>
>
> > Regarding the location for a logical_implication<> function, I’d advocate
> > for either Boost.Algorithm or Boost.Functional, given that the
> > std::logical_XXX<> class templates are placed in the <functional> header;
> > even if it would be a mouthful to say and type, I don’t expect it to be
> > seen very often.
> >
>
> Regarding <functional> header I do not think it fits there primarily,
> although I can imagine that is where std::logical_implication will be added
> in C++. For me they are there and exist because in C++ we can not pass
> operators to algorithms, e.g. std::accumulate(a.begin(), a.end(), 1, *),
> but this seems like a generic helper function because unlike && and || we
> have no operator for it.
> So I think it may be useful to add it in a way that enables one to pass it
> around(although I never had need to do this) but primary use is to just
> immediately invoke it yourself.
> I may be missing something, but this is my current thinking.
>
>
> On Mon, Jan 6, 2025 at 12:43 PM Richard Hodges via Boost <
> boost_at_[hidden]> wrote:
>
> > C++ standardisation seems to have jumped the shark.
> >
>
> I was just mentioning the proposal for context, so not sure this is super
> related to helper function, but I do not think this will get standardized,
> for example Walter in 2013 had swap operator :=: proposal.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>