Implication Operator for C++ :: Walter E. Brown

Presented at Core C++ Meetup, Oct 2023.

Walter Brown's paper P2971R1 proposes to introduce operator=＞, the implication operator, into the C++ core language. This talk will present a brief overview of the proposal (first publicly described at Core C++ '22), including the operator's specification and examples of its applicability to current C++ code.

**Dr. Walter E. Brown** has been a computer programmer for almost 60 years, and a C++ programmer for more than 40 years. He joined the C++ standards effort in 2000, and has since written circa 175 proposal papers. Walter is also a well-known speaker at C++ conferences, covering a wide range of topics, from the fundamentals of computing to the latest developments of C++.

[llothar]

I'm waiting for it so long. I loved to use it when i programmed in Eiffel. It is so usefull when you write lots of "assert" statements (as anyone should).

[PartyMusic]

If there are 2^4 different truth tables, which other simple operators are we "missing" and being forced to make complex multioperational predicates from?

[Takyodor]

"!p || q" is just a single character longer than "p => q", and (in my opinion) just as readable. Sorry, but I don't buy the "professional toolbox" argument, I want the exact amount of tools I need to be as efficient as possible, too many similar/duplicate tools just add extra weight to carry around. I respect the well presented and thought out arguments and effort put into this though.

[nerdrage]

I'd save the arrow operator => for short syntax lambdas, so that we can use ranges and pipe operators more effectively, making things like "std::views::filter(x=>x>2)" vs "std::views::filter([](const auto& x) { return x > 2; }). In my mind, this is more useful and saves much more typing than the implication operator.

[ericedlund]

Ada doesn't have implication, but it has nice if expressions which achieve the same thing. You can say "if condition1 then condition2" and if conition1 is false, the expression evaluates to true.

[rysw]

Seems like little to no benefit to add an esoteric feature that just tempts people into writing inscrutable expressions. In the example given it is a much better idea to leave it as a conditional with three branches.

If you really like the idea, you can just define and use a macro.

[alexcwagner]

That second example at 11:30 could still be simplified to
(x.has_value() == y.has_value()) && (!x.has_value() || *x==*y)
so it doesn't really beg for an implication operator any more than any other (!p || q) does, and the short-circuit evaluation doesn't seem any different, i.e., it won't dereference x or y until we know that it can. I guess it might be slightly more intuitive with (x.has_value() => *x==*y), though.

I'm not entirely against the idea. Maybe if implication is added, it'll turn out to be one of those things I never thought I was missing until it was there, and then I could never imagine life without it. Sort of like my wife.

[Caellyan]

The language and std library should only provide the most basic tools necessary to write a program because it's not feasible to expect developers to dedicate their entire lives to learning a single language (which C++ already kind of does). Adding a new core language features that provide no new functionality just complicates the implementations and surface area for bugs and weird interactions to pop up. It's also less readable than a simple ternary operator.