? patterns

[devyn]

I've written a lot of code like this for libraries that use Iterators where the Item is a Result:

for line_r in stdin.lock().lines() {
    let line = line_r?;

    // do something with line
}

I think it would be awesome if we could just relocate the ? to the pattern, like this:

for line? in stdin.lock().lines() {
    // do something with line
}

[burdges]

You can do this using while let already, so you should be asking for for let which seemingly does not appear in the while let RFC.

[burdges]

Oh you actually want an ? type error to propagate if that part does not unwrap. That makes sense. I'd still think you'd need an actual pattern match first, meaning for let.

[eddyb]

@burdges What do you mean? for takes a pattern, e.g. for &(a, b) in slice_of_pairs is valid.

[burdges]

I see, for needs an irrefutable pattern, which this pat? proposal is. There is no need for for let as just sugar for let _iter = ..; while let Some(pat) = _iter.next() { .. }.

[devyn]

Yeah, exactly, I think it would make sense just as a general pattern too:

let foo? = bar();

would be allowed to be equivalent to:

let foo = bar()?;

[mgattozzi]

That seems a bit confusing. It makes it seem like the ? in let foo? is part of the identifier here. I think it would make more sense to have it like this in your original example:

for line in stdin.lock().lines()? { // Where each new item has the question mark operator work on it
    // do something with line
}

[jD91mZM2]

Doing ? at the end like in @mgattozzi probably isn't a good idea, since that's currently how you would unwrap the return value from lines() - not each item.

[mgattozzi]

Right. I wasn't clear, I should have said an iterator after in with a question mark would do the unwrapping of the value returned while iterated through. lines by itself doesn't return a result so this wouldn't work as is today anyways.

[eddyb]

The only syntax I could see being added, that's not in the pattern, is for x in? xs.

[jD91mZM2]

for? x? in? xs??!?!?!?!

EDIT: Actually, that isn't an absolutely horrible idea. Maybe we could have like for line in stdin.lock().lines()?!... But yeah, probably not.

[burdges]

I think it should extend pattern matching in general, not be special syntax for for.

Ideas around coroutines, futures, etc. could perhaps be used to generalize for to support early return, so maybe :

for line in stdin.lock().lines().as_future() { .. } 

I despise that idea though because if for loops can return early then a crate changing a type could wreak havoc in the logic of its users. I guess that's why folks are discussing for? .. in? .. etc.

As an aside, I'd write the original code to avoid introducing another name. I might insert context not allowed by From<io:Result> too. It looks more reasonable then :

for line in stdin.lock().lines() {
    let line = line.map_err( |e| MyError::LineBarfed("context",e) )?;
    ...

I'm dubious about incorporating map_err like that :

let e = |e| MyError::LineBarfed("context",e);
for (line?e) in stdin.lock().lines() { ...

[Stebalien]

Previous discussion: https://internals.rust-lang.org/t/pre-rfc-allow-in-patterns/4772

[nixpulvis]

I'm still biased against the addition of the ? operator in general... That said I'd strongly avoid putting it near the identifier, seeing as it would read more like "this thing IS an option" instead of "this thing unwraps an option".

[joshtriplett]

I've wanted something like this for a while, and I'd like to see some reasonable syntax for it.