# Special-casing type inference of ? operator

**URL:** <https://internals.rust-lang.org/t/special-casing-type-inference-of-operator/15075>\
**Category:** language design\
**Created:** [July 25, 2021, 12:34pm UTC](https://internals.rust-lang.org/t/special-casing-type-inference-of-operator/15075 "2021-07-25T12:34:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [July 25, 2021, 12:34pm UTC](https://internals.rust-lang.org/t/special-casing-type-inference-of-operator/15075/1 "2021-07-25T12:34:42Z")

</div>

Type ambiguity caused by implied `From` in `Try` is quite annoying:

```rust
vec!["1", "2"].into_iter().map(|s| {
    let x: u32 = s.parse()?;
    Ok(x + 1)
});

```

> cannot infer type of error for `?` operator

This comes up quite often in fallible iterators as well as `async {}` blocks, and I need to write ugly syntax like `Ok::<_, Error>()`.

Would it be terrible to let the compiler assume no error conversion in such case, as if `From` wasn't used in the `?` desugaring? Perhaps the blanket `impl From<T> for T` could be tagged as a magic preferred default in case of ambiguities.

---

<div class="post-metadata">

**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\
**Post date:** [July 25, 2021, 12:47pm UTC](https://internals.rust-lang.org/t/special-casing-type-inference-of-operator/15075/2 "2021-07-25T12:47:42Z")

</div>

[Resolving `Ok`-wrapping for `try` blocks · Issue #70941 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/70941#issuecomment-612167041) is relevant here. The

> Address issues with type inference ( `try { expr? }?` currently requires an explicit type annotation somewhere).

Unresolved problem is exactly the same issue I think.

EDIT: originally meat to link [https://github.com/rust-lang/rust/issues/31436](https://github.com/rust-lang/rust/issues/31436)

---

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [July 25, 2021, 7:24pm UTC](https://internals.rust-lang.org/t/special-casing-type-inference-of-operator/15075/3 "2021-07-25T19:24:13Z")

</div>

> [@kornel](#):
>
> Would it be terrible to let the compiler assume no error conversion in such case

My not-written-into-an-RFC-yet vision for that would be for normal `try` blocks to stop this, as sketched in [https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-try](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-try).

So you could write that as

```rust
vec!["1", "2"].into_iter().map(|s| try {
    let x: u32 = s.parse()?;
    x + 1
});

```

and it would just work.

Note also that with the new desugaring (as of RFC 3058) the `From` is `Result`-specific, so this problem doesn't exist for `Option` -- and if the traits stabilize, it could allow using new result-like types that would have the conversion as an extra opt-in step instead of always.

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [October 23, 2021, 7:24pm UTC](https://internals.rust-lang.org/t/special-casing-type-inference-of-operator/15075/4 "2021-10-23T19:24:32Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.