Boost logo

Boost :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2025-01-06 11:43:00


On Sat, 4 Jan 2025 at 20:43, Ivan Matek via Boost <boost_at_[hidden]>
wrote:

> Hi everyone,
>
> there has been a recent proposal to add logical implication to C++ as an
> operator.
> github tracking issue <https://github.com/cplusplus/papers/issues/1641>
> P2971R2
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2971r2.pdf>
>
>
C++ standardisation seems to have jumped the shark.

> For a video description you can see this talk
> <https://youtu.be/bgyY3x8y4PE?feature=shared&t=1470> by Walter(it is only
> few minutes, not entire talk).
>
> While I agree with concerns mentioned on the issue, i.e. using a
> *precious *token
> => on rarely used functionality I do think that implementing a simple
> function helper is reasonable.
>
> Poll in issue shows that this is also likely standardization future.
> POLL: We agree with adding a function object logical_implication (tentative
> name, akin logical_and, `logical_or’).
>
> SF F N A SA
> 9 12 3 0 0
>
>
> As for if it is worthwhile to add this simple logic to boost instead of
> people just writing their own I will just say I would prefer to have
> something named in boost instead of people reinventing same thing many
> times in their projects. I have used it few times in my career, so quite
> rarely, but again that means I have used it much more often than 80+% of
> algorithms in <algorithm> header.
>
> As for location I presume best place would be Boost.Algorithm although you
> could say that Boost.Core can be a candidate because it is a basic
> operation and would benefit from shorter namespace. I would be still
> inclined against this since I have seen core/util/common become huge in
> many codebases I have worked in.
>
> I have tried to check if this already exists in Boost; all I found was an
> example in Boost.Hana.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk