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
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