Skip to content

try bikeshed: What type should be annotated? #154127

Open

Description

@scottmcm

(Sub-issue of #149488. Related to future work from rust-lang/rfcs#3721.)

As currently implemented on nightly, if you want to convert a bunch of stuff to a particular error, you use something like

try bikeshed Result<_, io::Error> { … }

That might sometimes be useful if we actually want to write the ok type, but often it seems like it's just _, because of course the body of the block ends up having specified that type anyway.

In terms of the try_trait_v2 model, however, it would in a sense make more sense to residual type. That doesn't have the "extra" type of the ok part, since it's arguably not the point.

But in the implementations of the traits that doesn't really make much sense, because writing out the residual type isn't actually any easier:

try bikeshed Result<!, io::Error> { … }

But maybe introducing a something like a family type would work? (Could use that instead of "residual" in the naming too.)

If that became a common thing to use and name, we could do something like

try bikeshed anyhow::Family { … }

Though that's not necessarily any different from type Family = Result<!, anyhow::Result>;.

We could also imagine taking something that's not a complete type, like have try bikeshed anyhow::Result taking a type constructor instead, though I think that's currently unprecedented in Rust so might be too weird.

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Mar 20, 2026
  2. added
    F-try_blocks`#![feature(try_blocks)]`
    T-langRelevant to the language team
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Mar 20, 2026
  3. added
    C-discussionCategory: Discussion or questions that doesn't represent real issues.
    on Mar 21, 2026
  4. joshtriplett commented on Mar 25, 2026

    @joshtriplett
    Member

    Initial vibe: trying to name something shorter than the overall type seems awkwardly different from anything else in the language, and limits what we can do with this construct.

    I suspect, in practice, that people might end up writing helper macros to use in place of heterogeneous try. For instance, eyretry! { } in place of try bikeshed eyre::Result<_>.

  5. yaahc commented on Mar 31, 2026

    @yaahc
    Member

    for the eyre example at least we recently added a default for the T param on our Result alias so presumably eyre users would simply write try bikeshed eyre::Result { once that change is released.

    Beyond that, my feeling is that simply using type itself as currently implemented is fine actually. It's not that many extra characters to write and as eyre already demonstrates its quite simple to add an alias that lets you remove that small extra bit of boiler plate if it's bothering you.

  6. added a commit that references this issue on Apr 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-discussionCategory: Discussion or questions that doesn't represent real issues.F-try_blocks`#![feature(try_blocks)]`T-langRelevant to the language team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions