Re: Adding logical implication to boost

From: Traian Enache (ena.traian_at_[hidden])
Date: 2025-01-05 14:27:20

While I haven’t been up to date with recent proposals, I share the same
concerns about using a precious token for such a small issue. 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.

 In addition, I believe an ‘=>’ token would do better as a part of pattern
matching in the future (again, I haven’t really been up to date with recent
proposals, so I’m not aware of any work on pattern matching), although the
boost mailing list is not the best place to vent about this.

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.

On Sat, 4 Jan 2025 at 21: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>
>
> 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
>