|
|
Log in / Subscribe / Register

Why this code is actually a regression.

Why this code is actually a regression.

Posted Sep 8, 2026 17:04 UTC (Tue) by matthias (subscriber, #94967)
Parent article: Stabilizing Rust's never type

// No type specified.
foo()?;

I really wondered, why this code was a regression. And without the question mark, it would have always been an error, as the compiler would not be able to infer a type. However the question mark is syntactic sugar for

match foo() {
  Ok(v) => v
  Err(e) => return e.into()
}

Here, the compiler can infer a type. The error branch has the type ! which is changed to Infallible. As both branches need to have the same type, the compiler tries to find a type that is compatible with both branches. In most code, this would simply be the type of the Ok branch. But in this special case, the Ok branch has unspecified generic type T. And this is where the fallback type comes into play. In rust editions prior to 2024, this was the unit type (), which implements Default. So there is no problem. Since Edition 2024 and with rust 1.99 also for all older editions, this fallback will become !, which does not implement Default and we get a compile error.

This seems to be the only possibility of triggering a regression. We need to have two branches, where one is divergent (has type !) and the other has an unspecified generic type that cannot be inferred by other means and where it makes a difference whether we infer () or !. Seems to be quite a corner case.


to post comments

Why this code is actually a regression.

Posted Sep 13, 2026 9:30 UTC (Sun) by koflerdavid (subscriber, #176408) [Link]

That's correct, and if I read the article correctly rustc should have for a long time already raised a warning for such code.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds