[Pre-RFC] Elvis/coalesce + ternary operator

[ExpHP]

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?

Adding new meaning to existing trait impls is scary.

Adding new language meaning to existing trait impls of a library trait is terrifying.

I care basically zero for this proposal, which is why I haven’t said much; but it is unfathomable that it should be backed by anything other than brand new traits in core::ops.

[H2CO3]

Nope, that snippet defines:

1. Imperative if statement
2. Temorary let binding assignment
3. A non exhaustive pattern matching

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

I don’t see how the pattern match is non-exhaustive either (Option can only be Some or None), or even if it is (and by that you mean that the None case is not explicit), why that is a problem, since it works correctly anyway.

In this sense Rust is not very better: it don’t provides a usual ternary, and we must abuse if to achieve our goals

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.

[skysch]

I get that, but this is a breaking syntax change already. No existing code uses or like this, and nobody would be really be introducing it without knowing it is sugar for Into<Option>. (In other words, this wouldn’t be a new meaning for Into<Option>. It is just a new way to call it.)

[ExpHP]

What I mean is, what of all the existing impls of Into<Option<T>> in the world?

What if some of them are things that should not have the behavior provided by this feature?

What if some of them overlap with impls that people would want to write for this feature?

[skysch]

That could pose problems in theory, but in practice I don’t see it being a problem. It is probably more of a problem that it wouldn’t live in std::ops as it should.

What if some of them overlap with impls that people would want to write for this feature?

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

[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