5 ms·

I was wondering why and it looks like a new trait implementation in std made a type placeholder ambiguous in older versions of time? time was caught in a cra

by nequo 2y ago

I was wondering why and it looks like a new trait implementation in std made a type placeholder ambiguous in older versions of time? time was caught in a crater run when a new trait implementation was added to the standard library. While it is a breaking change, it is considered acceptable breakage because the alternative is never adding any trait implementations or methods. https://github.com/time-rs/time/issues/681#issuecomment-2143130755 https://github.com/time-rs/time/issues/681#issuecomment-2143...

comex 2y ago
I wish rustc had a way to 'pin' the output of type inference, in the same way that Cargo.lock pins the versions of dependencies. That way, old code would continue to compile based on what the types were originally inferred as, even if the code retroactively became ambiguous. This wouldn't be a perfect solution. Due to conditional compilation, any given variable in the source code might not exist on certain platforms, or it might even have a different type depending on the platform or configuration. So the question of "what type does this variable have" doesn't always have a single answer to record in a lockfile. And macros make things even harder. But even as an imperfect solution, I think it still has the potential to avert most real-world cases of breakage caused by Rust upgrades (and even dependency upgrades). As a bonus, the same mechanism could potentially also be used to detect breaking API changes.
- estebank 2y ago
  I think the closest to what you're asking for is to build with a contemporary rustc version (have a rust-toolchain.toml in your repo). This isn't a satisfactory answer, but it is an available option nonetheless.
- mtndew4brkfst 2y ago
  I wish rustc had a way to 'pin' the output of type inference Would that not be "take the outcome of said type inference, write it into the LHS as a type declaration or into the RHS as a generic parameter", aka make the inferred type permanently declared? We're not totally powerless for addressing the practical implication here, and I don't know how we could have stable yet still implicit type inference across compiler versions unless that type inference logic never changed ever again.

by nequo 2y ago

comex 2y ago

I wish rustc had a way to 'pin' the output of type inference, in the same way that Cargo.lock pins the versions of dependencies. That way, old code would continue to compile based on what the types were originally inferred as, even if the code retroactively became ambiguous. This wouldn't be a perfect solution. Due to conditional compilation, any given variable in the source code might not exist on certain platforms, or it might even have a different type depending on the platform or configuration. So the question of "what type does this variable have" doesn't always have a single answer to record in a lockfile. And macros make things even harder. But even as an imperfect solution, I think it still has the potential to avert most real-world cases of breakage caused by Rust upgrades (and even dependency upgrades). As a bonus, the same mechanism could potentially also be used to detect breaking API changes.

estebank 2y ago
I think the closest to what you're asking for is to build with a contemporary rustc version (have a rust-toolchain.toml in your repo). This isn't a satisfactory answer, but it is an available option nonetheless.
mtndew4brkfst 2y ago
I wish rustc had a way to 'pin' the output of type inference Would that not be "take the outcome of said type inference, write it into the LHS as a type declaration or into the RHS as a generic parameter", aka make the inferred type permanently declared? We're not totally powerless for addressing the practical implication here, and I don't know how we could have stable yet still implicit type inference across compiler versions unless that type inference logic never changed ever again.