Idea: Early returns and irrefutability

[dodomorandi]

Ups, I did not check . However, the version you linked is more interesting than my macro (and safe against other “into_result” methods). Maybe the only problem is that the coalesce crate is already taken .

[Centril]

It is Javascripty in the worstest way, though. ._.

At least, I don’t think of short-circuit operators as control flow, and it’s really wierd to someone who doesn’t know that break (and keywords that desugar to it) type at ! .

I’m not sure what you mean by “Javascripty”, but this is not one of those “wat” moments that arises due to ad-hoc design. foo || continue falls out of continue : ! and ! coercing to any other type which is consistent with the language overall.

Also, short-circuit operators really should be thought of as control flow and they may desugar into matches in the HIR soon.

[repax]

let stream = self.streams.get_send_mut(id) || continue;

I do like this idea, but I’m a little bit worried. Doesn’t the type of stream change somewhat surprisingly if you exclude the || continue part? It becomes an Option instead:

let stream: Option<&mut Send> = self.streams.get_send_mut(id);

Would the following syntax be clearer?

let Some(stream) = self.streams.get_send_mut(id) || continue;

[scottmcm]

Doesn’t the type of stream change somewhat surprisingly if you exclude the || continue part?

No more surprisingly than any other operator. C# has demonstrated that x ?? 0 (where x: int?) or x ?? throw or x ?? continue or whatever is completely understandable in practice.

[djc]

While I do like something more pattern-general, I think these cases could all be done with something like let stream = self.streams.get_send_mut(id) || continue; using

Maybe the Elvis operator ?: as seen in Kotlin would make more sense here instead of overloading ||? I like that it’s like an extension of the simple ? try operator (and it aligns with second-value-optional ternary operators in some other languages).

[repax]

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

[Centril]

Maybe the Elvis operator ?: as seen in Kotlin would make more sense here instead of overloading || ?

Whether this overloads anything depends on whether it’s encoded by an ad-hoc mechanism or whether it is just the combination of let p = e (as an expression typed at bool), ||, and continue.

In the latter case, the compiler would understand that p is refutable, and so bindings_of(p) might not be definitely initialized after let p = e. However, continue : ! holds so we know that if we reach beyond continue then bindings_of(p) is definitely initialized. (We’re back to the flow based logic discussed previously…)

There’s a parser issue here tho… let p = e || continue would need to be parsed as (let p = e) || continue.

[scottmcm]

Whether this overloads anything depends on

I was expecting it’d desugar to the if I mentioned in the other thread – it’d just remove || entirely the same way that ? gets removed entirely. (With a bool: Try it’d be fully compatible with existing code, too.)

[repax]

While a syntax that requires a pattern on the left hand side, i.e.

let Some(v) =

is neutral to the type of enum to be matched and can bind any of its variants:

let Ok(v) = ... || ... ;
let Err(e) = ... || ... ;
// or
let Msg::A(m) = ... || ... ;
let Msg::B(m) = ... || ... ;
let Msg::C(m) = ... || ... ;

it makes sense to optimize and streamline for ops::Try, and specifically the success path. This is what would benefit the ergonomics the most, I think. The code that is written, and read, is concise and to the point while being explicit about any error variants.

The || operator is suitable because:

1. It intuitively deals with truth values of sorts (success or failures of expectations).
2. It short-circuits on the first confirming alternative, and only lazily evaluates the rhs.

[CAD97]

Because the || already parses, I don’t know if this syntax is possible.

let <pat> = <expr> || <expr> ; already parses as let <pat> = <expr/binop (|| <expr> <expr>)> ;.

?? isn’t possible because that has meaning as ? ?. ?: has a planned meaning in ? : where the colon is for type ascription. Any new token changes decl macro behavior anyway.

I think the syntax has to use a keyword, unfortunately. (Though I’d love to be proven wrong!) <expr> ?? <expr> doesn’t have a parse currently, so I could be convinced. (<expr> ?: <expr> could definitely look like <expr> ? : <type>.)

[CAD97]

Actually, scratch that. Because || is a built-in we can do whatever the heck we want. I’m not sure how intuitive it’d be though.

[drXor]

I’m not sure what you mean by “Javascripty”,

Javascripty was wrong because it was late at night. Scott correctly corrected me to Perly; I was thinking of Javascript confounding short-circuit or and null coalescion (which is awful, they want to be separate operators).

foo || continue falls out of continue : ! and ! coercing to any other type which is consistent with the language overall.

You’re preaching to the choir here, I noted that they type at ! in my post. But, the fact that it’s an “obvious” consequence of the type system doesn’t mean it isn’t an abuse of what these things are meant for (you know, short-circuiting =P), and should be linted against. Rule of weird, etc.

Also, short-circuit operators really should be thought of as control flow and they may desugar into match es in the HIR soon.

I’m not disagreeing with this, I’m saying that doing non-local control flow with ||, as opposed to if/else or match, is going to make your reviewers upset.

Also, I’d like to note that I think that adding an Elvis operator and using ?: return is not better than if let {} else {return}. At that point, we might as well just add the C ternary because writing an if inline is too many braces…

[canndrew]

I’ve suggested this syntax before, but:

match let Ok(x) = res {
    Err(e) => something_diverging(e),
}

[Centril]

cc @comex re. this topic since I know they like let as a bool-typed expression (I’m generally in favor as well).

But, the fact that it’s an “obvious” consequence of the type system doesn’t mean it isn’t an abuse of what these things are meant for (you know, short-circuiting =P), and should be linted against. Rule of weird, etc.

I think it’s neither weird nor abuse. Tho the convention is to use if, if I read self.method() || continue; it would not be strange to me but rather readable.

[drXor]

This is subjective. I assume readers of my code are familiar with, and conform to, the Google C++ style guide; you’re from a different school of programming entirely. I don’t think this is at all worth bikeshedding.

[djc]

It was my impression so far that Rust doesn’t do coercion to bool (for example, if 0 { isn’t allowed), unlike for example in Python, and I think that fits with the general style of Rust. Similarly, || currently only appears to accept bool (that is, 1 || 3 is not allowed). It seems like a sizable departure from this style to start coercing Option or other Try types to bool.

[djc]

I’ve suggested this syntax before, but:

match let Ok(x) = res {
    Err(e) => something_diverging(e),
}

I find this pretty hard to grok. In particular, the asymmetry between the first case being outside of the block and other case(s) being in the block makes it less than obvious to me.

[Yato]

This is no better than just doing

let x = match res {
    Ok(x) => x,
    Err(e) => something_diverging(e)
};

Which is already valid. The only benefit to yours over this is a few less characters, which isn’t a sizable benefit.

[cuviper]

<expr> ?? <expr> doesn’t have a parse currently, so I could be convinced.

It does with unary/binary ambiguity, like x ?? - y

[bestouff]

What I want is the following behavior:

if let None = x {
  return expr
}
let Some(x) = x;

How about that:

fn func(x: Option<u8>) -> Option<u8> {
    let y = x? + 2;
    Some(y)
}

?