[Pre-RFC] Elvis/coalesce + ternary operator

[ExpHP]

Wouldn’t the orphan rules prevent anybody from relying on other implementations in the first place?

I meant this can happen even within a crate. Into is such an extremely vague and general purpose trait. A lot of people use Into in their own crates for their own random reasons. Some of these people might also want to use or on an overlapping set of types.

[160R]

A distinction without a difference, if you ask me. “A tree is for decorationg a yard” and “a tree is for chopping down to get wood” are both true things, but they are true in the sense that you’re imprinting your own moral purposes onto a thing which has no fundamental purpose, – it only has behavior.

Believe me that there’s a difference between “a tree is for decorationg a yard” and “a tree is for chopping down to get wood”, and that difference is not only a moral/fundamental purpose but also a practical purpose. Because of that we cultivate a different kinds of trees instead of e.g. apples that can serve as a yard decoration, bear some fruits, and we can chop them down on requirement.

That you prefer to use a ternary rather than an if is your moral bias at work, because there is no fundamental difference in how they behave. One can open a can of paint with a screwdriver, but that doesn’t mean anything wrong has happened. Use your tools to solve your problems rather than trying to give them some higher purpose.

But what if you works as a painter and opens multiple cans of paint per day with an edgy handle of a brush? Would you search for a better tool instead?

That’s debatable. In fact, that’s why there is a debate happening right now. You can’t skip past it by just asserting it is true, you have to make a convincing argument.

And what argument could be considered as convincing?

Why would it be surprising? I mean, it would be surprising because this syntax is confusing, sure, but why would it be more surprising to use an existing suitable trait rather than a brand new redundant one? Surprise being a function of expectation, why should anybody expect a brand new syntax to introduce a new trait to do something that an existing trait already does?

Because there is a tendency that each operator in a language has it’s own trait, and we breaking it while users expect it to keep forward.

[160R]

I fail to see how it’s “imperative”. if in Rust is always an expression, so you don’t have to go all imperative and e.g. introduce a temporary variable (which is a frequent workaround in other languages).

It’s really easy to get lost in terminology here e.g. your example of null handling defines a temporary variable and assignment inside of if expression - is that imperative?

Or another example if a { b() } else { c(); } , is a this expression before semicolon imperative? Could if expression be also imperative because of it?

Again, if has all the features of a conditional expression. It’s a fully-fledged first-class expression, you can use it in any expression-like context, and it evaluates exactly one of its arms depending on its condition. There’s nothing abusive in applying it for… well, pretty much what it was designed to do.

Again, it don’t has a good and ergonomic syntax for simple use cases, and it can’t do type inference based on From trait.

[Yato]

Or another example if a { b() } else { c(); } , is a this expression before semicolon imperative? Could if expression be also imperative because of it?

if a { b() } else { c(); } has two cases

• b returns ()
  • the if evaluates to ()
• b does not return ()
  • compile time error because the two branches of the if evaluate to different types

any expression followed by a semicolon will always evaluate to ().

---

it can’t do type inference based on From trait.

On the note of type inference, it is very hard to do type inference on such a generic trait, and calling From::from can be rather expensive, so I would like for it to be visible.

[earthengine]

But what if you works as a painter and opens multiple cans of paint per day with an edgy handle of a brush? Would you search for a better tool instead?

I think Rust is not a Swiss army knife: if you are looking for a better tool that does not fit in Rust, why not just look for another tool set that have the tool you need?

For example, I believe procedure macro will let you define your own embedded DSL. You might probably write a subset of Rust with your specific language extension. If this makes you happy, so do most of us and don’t forget to let me know your new tool

[CAD97]

I fail to see the adequate motivation for either a coalesce or “the” ternary operation.

Could you explicitly spell out how a or b is better than a.or_else(|| b)/a.unwrap_or_else(b) (based on type information)? (FWIW, I was unaware about this “chaining” behavior from Kotlin’s ?:.)

Could you explicitly spell out how c && a or b is better than if c { a } else { b }? Note that Python specifically chose to use a if c else b because ternary operators are a hard sell.

Alongside this I’d like to pose a challenge that could help motivate this pre-RFC. Provide a real-enough example (at a glance it looks like it’s doing a real computation, not using dummy names) in “current rust” and “with this RFC” styles, and argue why the latter is more understandable with local reasoning to a reader than the former. The people against the RFC can then propose a “current rust” formulation that’s another way of attacking the problem, potentially better, and we can incrementally find the “best” representation both with and without this RFC for comparison.

[H2CO3]

your example of null handling defines a temporary variable and assignment inside of if expression

No, it doesn’t. I don’t know where you think that happens.

[160R]

any expression followed by a semicolon will always evaluate to () .

But expression by itself could be imperative, since it could change a state as well as it could contain other expressions that could do the same. Return type really don’t matter here.

On the note of type inference, it is very hard to do type inference on such a generic trait, and calling From::from can be rather expensive

Wouldn’t it be inlined or optimised in any different way?

[160R]

I think Rust is not a Swiss army knife: if you are looking for a better tool that does not fit in Rust, why not just look for another tool set that have the tool you need?

This is exactly what I’m trying do in this thread

For example, I believe procedure macro will let you define your own embedded DSL. You might probably write a subset of Rust with your specific language extension. If this makes you happy, so do most of us and don’t forget to let me know your new tool

I’m doubt that this tool would be better than tool I use currently

[160R]

Provide a real-enough example (at a glance it looks like it’s doing a real computation, not using dummy names) in “current rust” and “with this RFC” styles, and argue why the latter is more understandable with local reasoning to a reader than the former. The people against the RFC can then propose a “current rust” formulation that’s another way of attacking the problem, potentially better, and we can incrementally find the “best” representation both with and without this RFC for comparison.

Overall, it’s very good idea to a start more deep research and provide a better examples. That should be done early, but I’ve just assumed that not only I understand the problem and some examples and alternative proposals (different from “you can already do that with”) would arrive ITT.

So, I start searching for a real world examples.

[160R]

No, it doesn’t. I don’t know where you think that happens.

In destructuring

let Some(x) = opt

[Yato]

Return type really don’t matter here.

The return type of the function b does matter, as it makes the difference of compiling, and not compiling.

Wouldn’t it be inlined or optimised in any different way?

Who would the compiler figure out what you want? It’s not a problem of codegen, it’s figuring out what the programmer wants.

Also, the optimizer is not a magic bullet, it can’t optimize away everything, and From::from calls can also to be expensive due to allocations, for example String::from(&str) needs to perform an allocation, and therefore is expensive, and the optimizer cannot optimize that out. Finally, relying on an optimizer to get expected behavior is bad, as even slight changes have drastic, often unpredictable, effects.

[Yato]

because match / if let constructs sometimes are an overkill when dealing with nullable values

Could you please, elaborate especially on the note of if let. I think that if let construct is perfect for handling nullable values. Also we have the Try operator ?, which is useful when in functions that return Result or Option. When try blocks land, this will be even easier.

So, I don’t see the point you are trying to make.

[160R]

The return type of the function b does matter, as it makes the difference of compiling, and not compiling.

That’s right, but that’s also not subject of the discussion. My thesis is that return type of () turns a returning expression into imperative statement, since () represents void. And even if void is a value, it’s hard to say that it’s a result, since it’s useless.

Who would the compiler figure out what you want? It’s not a problem of codegen, it’s figuring out what the programmer wants.

It would know a concrete type I want.
Consider the following code:

option or Err(0);

It would be desugared:

match Or::into_option(option) {
    Some(o) => From::from(o),    
    None => Err(0),
}

And then inlined:

match option {
    Some(o) => Ok(o),    
    None => Err(0)
}

Or did you wanted to say that this couldn’t happen?

From::from calls can also to be expensive due to allocations, for example String::from(&str) needs to perform an allocation, and therefore is expensive, and the optimizer cannot optimize that out.

That’s good point. I think that some trait bound on Or type parameter would be required to deny values that allocates in from function. Or we can use another trait instead.
That requires further investigation…

Could you please, elaborate especially on the note of if let . I think that if let construct is perfect for handling nullable values. Also we have the Try operator ? , which is useful when in functions that return Result or Option . When try blocks land, this will be even easier.

Sometimes you need a more straightforward way to handle nullable values: option or value, option or next_option, option or result…

Handling nullable values in if and match expressions is less straightforward than could be with or.
Handling nullable with Option<T> combinators is less straightforward than with if and match.
Handling null as error using ? and try blocks is not straightforward at all.

[Yato]

match Or::into_option(option) {
    Some(o) => From::from(o),
    None => Err(0),
}

Minor nit, there are no From impls for Result

[Yato]

option or value

Option::unwrap_or

option or next_option

Option::or and Option::or_else

option or result …

Convert the result to an option with Result::ok and then use one of the above methods.

---

I don’t see why these are so bad.

[160R]

I don’t see why these are so bad.

Imagine that you are complete newcomer in Rust: how you would deal with all of that methods?
And from user perspective: what is the advantage of having multiple ways to do the same thing?

[skysch]

When I was a complete newcomer to Rust, I dealt with all of those methods by learning what they do and using them.

And from user perspective: what is the advantage of having multiple ways to do the same thing?

There are advantages and disadvantages to it, and it depends on what you mean by ‘same’ and ‘multiple’ and other matters of context. In general, if two peices of code do the same thing, we want them to look the same, but of course that is usually impossible to enforce and there are other considerations to take into account. For instance, if you’re chaining method calls, you probably want to keep chaining method calls. If you’re writing for loops, then you want to keep writing them.

[Ixrec]

This is becoming a bit of a semantics game. To me, unwrap_or and or_else and so on do different things, just like + and - do different things, so the status quo is not “multiple ways to do the same thing” to me. And even if this feature were added, a newcomer would still need to understand the Option and Result types and what or does with each of them, and they’ll still need to learn that Option/Result have a bunch of other methods to do various things that or won’t.

But this is all nitpicking of nitpicks of nitpicks; no one’s going to change their mind based on posts like this.

The core issue here is that there’s (apparently?) no argument for this sugar other than the fact that it is a sugar, and the bar for sugar is relatively high (as it should be). If you want to persuade people that this is more useful than the dozens of other proposed sugars that have wisely not been tossed into the language, we should probably take a step back and try to come with some compelling examples of code before/after the sugar that’s significantly easier to understand with the sugar (of course, I can’t come up with any myself, which is why I’m not a fan).

[tanriol]

Speaking about the syntax choices, && and or in the same expression look weird, IMHO. Especially if && in this context means something different from the normal short-circuiting boolean “and”.

If we’re talking about chaining conditionals, I’d prefer the syntax to be compatible to RFC 2497 (if let and while let chaining). There’s a possible future extension mentioned there for if-let-or expressions, so, in the similar vein, I’d expect the irrefutable “or chains” to look roughly like the following

let Some(x) = first_option
 || Some(x) = second_option
 || x = fallback_value;