More question marks

language design
1

Hello, help me to prepare proposal. I think about comething like this:

loop {
    let a = exp?continue;
    let b = expr?break;
    let c = expr?{ continue }; // block, not a closure, allow flow control
    let d = expr?|e|{ return Err(e) };  // default ? behavior
}
2

Note that the first 3 examples can be currently written as let Ok(a) = expr else { continue };

The last example would be ambiguous with bitwise or operations.

6 Likes
3

The general grammar principle here is that you cannot make a single token be both a binary operator and a postfix operator (without also introducing some mandatory parentheses); if you do, then it becomes ambiguous whether the next token is a binary operator or a prefix operator.

2 Likes
4

Hm, it can easily become token

<?continue>
<?break>
<?{>
<?>.<expr>
5

You'r right, thanx. So .. i need slightly more practice to rember it =) but what is good solution for

let Ok(v) = fallible() else { /* i want error here. */ }

?

6

What you have here is a solution.

The first thing you should write for a proposal is not a solution, but a problem statement. What's the thing that you're having trouble doing today that you wish was better? What do you have to do today? What's suboptimal about those ways?

The biggest hurdle you have is in convincing people that there's a problem worth solving. Concentrate on that, not whatever syntax you have in mind right now.

18 Likes
7

match is always an option:

match fallible() {
    Ok(v) => v,
    Err(e) => {
        //use `e` here
    }
}

That said, I have seen people mention a desire for postfix match, either of the form

fallible().match {
    Ok(v) => v,
    Err(e) => {
        //use `e` here
    }
}

or let else match

let Ok(v) = fallible() else match {
    Err(e) => {
        //use `e` here
    }
}
4 Likes
9

Thanx! Coool!

let Ok(v) = fallible() else match {
    Err(e) => {
        //use `e` here
    }
}

Where i can vote for this?

1 Like