// constraints `?O` but not `?E` because error conversion:
let x: Result<?O, ?E> = try { x? };
// is this required to be an option?
let x = try { Some(3_i32)? }; // still not enough because the option-ness is lost.
Random idea:
try { x? }doesn’t do error-conversion.
This won’t work if you use ? multiple times in one try block, on different errors.
try: Foo { x? }does error-conversion
niko: ok wrapping was an open question?
josh: we now seem to have consensus; see #70941 above
niko: main remaining problem: cannot always infer whole type of try block from its contents alone.
scott: two halves to this: error-half, and result-ness half.
josh: error-half: what happens in course of function, ? gets applied to same error type twice, e.g. try { x? }?
josh: other half, result-ness: it would be sad if we had to explicitly annotate the output of a try { … } as being a Result when that is going to be the common case
cramertj: I had thought we were going to require you to annotate the type?
scott: not clear that is required
niko: regardless of what we do with Try trait, it seems clear that it would be useful to be able to annotate the type
josh: yes, capabiilty is good. Just sad if it is required in the common use-case.
niko: having an explicit type(at least for the expected error?) up front at the top of the block can be useful for readability
cramertj: consider example from Poll where try block type differs from the types that you apply ? to within the try block
niko: can you provide elaboration on this example?
(felix doesn’t see where this was provided, if it was… oh, see below…)
shifted gears to wishlist
(scott elaborates on wishlist items… )
scott: top two bullets, in essence, are saying that the Ok type is an associated type of the Try trait, and that should remain the case; i.e. it should be predictable from the overall resulting type.
scott: third bullet …(summarizing outcome of much conversation) … want something nicer for inference
cramertj: output type of a try block that uses ? on a poll of result could be either a Poll<Result<…>> or a Result<…>; you cannot infer the resulting type solely from the expression fed into ? in this case, and that is stable behavior today.
(felix spends time trying to digest ongoing discussion)
niko: key point: This(fn some_func below) works today.
Agenda (in order of priority)
Try blocks
let x: _ = try { foo};// constraints `?O` but not `?E` because error conversion:let x: Result<?O, ?E> = try { x? };
// is this required to be an option?let x = try { Some(3_i32)? }; // still not enough because the option-ness is lost.