[Pre-Pre-RFC] Reviving Refutable Let [Runoff]

language design
49

We hit 50 responses to the poll, so here’s a mini-analysis of the results so far and a runoff poll for those interested.

2018-02-07

  • “Stick to the status quo” got exactly half of the votes so far. This seems interesting to me, but also means that the idea of a refutable let has some significant support. In hindsight maybe I shouldn’t have included the option, so that half of the respondees could voice which alternative they’d like if we introduce one.
  • let ... else took half of the remaining vote (including preceded by <keyword>). This seems by far to be the crowd favorite, even with the grammar ambiguity. If it weren’t for the ambiguity, this would be the obvious choice.
  • 12% of the vote went to <keyword> let (including else let). Upon further consideration, I think that unless in this position could be contextual and only require single-token lookahead; $:ident let is never currently legal code.

So that said, here are the two syntaxes I’d like to runoff:

let ... else match

let Ok(x) = make_x() else match {
    Err(e) => {
        log!(e);
        bail!(e);
    }
}
do_something_with(x);

(Requires special-casing an if expression to always greedily consume the else, rather than a fully unambiguous grammar.)

unless let ... match

unless let Ok(x) = make_x() match {
    Err(e) => {
        log!(e);
        bail!(e);
    }
}
do_something_with(x);

(Requires a new contextual keyword or using else here which is human-ambiguous.)

  • let ... else
  • unless let

0 voters

I’d also like to guage opinion on one other factor before finalizing RFC draft for initial discussion:

  • Make the match part optional, infer _ => for the diverging block
  • The match part should always be required, just type _ => if you don’t care about the value

0 voters