You could already experiment with this today, in multiple ways. The most obvious would be to add a method (e.g. .flip()) yourself, via an extension trait. You could then make an argument for why that method is not only useful but so incredibly useful it needs to have a one-character unary operator (as well as whether it fits the semantics of that operator). As a hint, such an argument would start with "a massive number of crates are using this, or contain a code pattern that would benefit from this"; that's the threshold such a proposal would need to meet, at a minimum.
You could also experiment with the syntax you propose using a macro, or a different Result type, and then use that to make a similarly compelling argument.
We almost never jump directly to "this needs short native syntax". Important steps that come before that: "does this need any native syntax", "could this be done in a library", "could this be done in a macro", "what's the most idiomatic way to write this today", "should this be done at all".
Yeah, Option::filter existed for almost two years as a third-party library before it was stabilized in std. If you think a Result::flip is useful, then you can do the same thing.
@SoniTwo library team members (myself included) have already gone on record to say what would be minimally required to make this proposal actionable. I would suggest focusing your efforts on that. Otherwise, this discussion is just chasing our tails around the maypole.
Maybe it's because I came from a background of languages with confusing operators, but personally I would find an operator much more confusing than a named method.
I'd also probably agree that the use cases put forward so far would probably be better served by you defining your own Either type, and then you can do whatever you want.
@bascule, would you perhaps tell us what those languages were and - should you feel like - share a horror story or two about operators? Might be quite interesting
Aww, I do have a soft spot for the "Perl Periodic Table of the Operators"!
On the flip side, after having coded in Python for far too long, I'd read ! in front of a Result as "not truthy" - i.e., equivalent to is_err(). Before reading this thread I wouldn't even have thought of it flipping the branches.
First of all, that's about the most useless response you could have had. But realistically? Just about every language considers negation of an integer to mean bitwise negation.
Please be constructive. Posting responses like that is inconsiderate and rude.
C and C++ have implicit conversions, and C's logical operators also have the type int, as _Bool didn't exist until C99. So it's not really possible to use the same operator for logical and bitwise "not".
With Rust's explicit conversions, there's a firm distinction between Not for bool vs. other types.
Since it's April 1st... If you like truthiness, you might like my eh crate, read like a Canadian "eh?" There's also the truthy crate that looks a little more serious.
There's also the either crate providing a generalized form of Result that's not tied to error handling.
One way to justify a new method on Result would be to demonstrate that there are lots of uses of Either that ought to be Result, but that really benefit from the flip method it provides. either also provides From and Into for Result so that you can convert between the two sum types trivially.
Might be quite interesting