SemVer Compatibility & migrating off an impl Trait in function return position

[fuzzypixelz]

If I have a public function or method which uses an impl Trait in return position:

pub fn foo() -> impl Trait {
  todo!()
}

What is the SemVer policy regarding migrating off impl Trait to a concrete type Bar that implements Trait?

pub fn foo() -> Bar {}

impl Trait for Bar {
  // omitted
}

The purpose of this would be defining additional methods on Bar. I suspect it ought to be a minor change but maybe I'm missing something.

[ehuss]

Unfortunately I don't have a definitive answer for you. There are a few potential concerns:

• A user may be downcasting, which wouldn't work with a concrete type. I personally don't think this should be considered a breaking change. See Determine if types behind trait objects affect stability api-guidelines#96 for more discussion.
• The trait object may be capturing generics that may not be obvious. 1.82 added explicit control over this, and the 2024 edition will be changing the default (see https://blog.rust-lang.org/2024/09/05/impl-trait-capture-rules.html). I'm not certain exactly how that could be a breaking change, but would need some consideration.

I'm going to close in favor of #8736 since this is already on the list. Since there may be dozens (hundreds?) of semver rules, I'm trying to avoid opening separate issues for each one at this time.

You may want to ask this question on the users forum. Another venue for discussion might be cargo semver-checks which provides a programmatic checking for semver compatibility.