3 ms·

This is still a pretty astounding breakage possibility let alone that it actually broke. Such inference seems inherently brittle and inevitably will break. Th

This is still a pretty astounding breakage possibility let alone that it actually broke. Such inference seems inherently brittle and inevitably will break. This sort of thing certainly does Rust no favours with regards to adoption. Typically this is solved by recording a "minimum" version supported by the dependency (e.g. in the dependency) and then accommodating by behaving differently. For example, by gating the change as an opt-in to a newer version. Instead everyone is forced to trip over this. What a disaster.

steveklabnik 2y ago
> Such inference seems inherently brittle and inevitably will break. This is just one data point, but again, in 80 releases, I can't remember the last one that did this to me. Obviously that's not a universal experience, as one of your siblings seems to run into it more than me. > Typically this is solved by recording a "minimum" version supported by the dependency The issue is the opposite. The dependency needs to be updated to fix the issue, not held back. > What a disaster. From "wait why did my CI pass yesterday but fail today" to pushing a commit with the fix, it was like ten minutes. Five of that was realizing that the breakage was because of a new Rust release. This happens so rarely to me that I didn't even think of it at first. Alternatively, don't update to the latest Rust. If the Rust version was pinned, this bug wouldn't manifest either.
- xyzzy_plugh 2y ago
  The fact that you can just `cargo update` is besides the point. The standard library should never make a breaking change that breaks running code. Why is this the exception? If the problem is that it wouldn't be possible to add new traits, then solve that by gating access to new traits on a minimum version. It seems like the change should have been made as part of a new edition. This PR seems relevant: https://github.com/rust-lang/std-dev-guide/pull/66 https://github.com/rust-lang/std-dev-guide/pull/66 edit: I can't help but feel like we're moving the goal posts here. "Just don't update Rust" was the sort of response you'd encounter with nightly when nightly was basically required to do anything serious, but this is stable. There is even an accommodation for such changes! Why wasn't it used? This all just reeks of laziness and disregard for users.
  - steveklabnik 2y ago
    > The standard library should never make a breaking change that breaks running code. Why is this the exception? It is an exception because it is a very minor breakage that is trivial to fix. Sometimes this is worth it. Sometimes it is not. I guess they made the call that it was worth it. As a user who was affected, I don't mind that this happened. > If the problem is that it wouldn't be possible to add new traits, then solve that by gating access to new traits on a minimum version. The issue here is rustc being updated. If the new trait was only available on the new version, the same thing would have happened. I'm not sure this suggestion would fix things. > This all just reeks of laziness and disregard for users. I have many criticisms of the Rust project these days, but I truly believe you are blowing this far out of proportion.
    - xyzzy_plugh 2y ago
      I hate to drag Go into this but I can't help but compare what happened here to the attitude here: https://github.com/golang/go/discussions/55092 https://github.com/golang/go/discussions/55092 My initial impression was that this is boiling the ocean but there's substantial foresight. If I'm blowing this out of proportion then the bar is already too close to the ground for my liking. This is solvable. I don't remember the last time a tool chain update broke my build. It's one thing if it's a bug fix. But for practically everyone to have to update? If 100,000 developers have to trip over this, say, then with your 10 minute estimate that equates to a million minutes, nearly 8 years at 40-hour weeks. This appears to be a problem totally worth solving.
    - hulitu 2y ago
      > It is an exception because it is a very minor breakage that is trivial to fix. Or so it seems. But who cares about quality ? /s
  - joshka 2y ago
    > This PR seems relevant... It's not. The change doesn't have anything to do with the prelude. It was a new conversion was added, where existing code made an assumption that there was only one possible conversion that satisfied an inferred type. (In fact when that code was written it was superfluous as the conversion was actually converting from one type to the same type). That code was removed in https://github.com/time-rs/time/pull/671 https://github.com/time-rs/time/pull/671 The only code that is strongly broken by this is code that doesn't update its dependencies more regularly than its compiler... locking your deps but refusing to do so with your toolchain is just plain weird IMHO.

steveklabnik 2y ago

> Such inference seems inherently brittle and inevitably will break. This is just one data point, but again, in 80 releases, I can't remember the last one that did this to me. Obviously that's not a universal experience, as one of your siblings seems to run into it more than me. > Typically this is solved by recording a "minimum" version supported by the dependency The issue is the opposite. The dependency needs to be updated to fix the issue, not held back. > What a disaster. From "wait why did my CI pass yesterday but fail today" to pushing a commit with the fix, it was like ten minutes. Five of that was realizing that the breakage was because of a new Rust release. This happens so rarely to me that I didn't even think of it at first. Alternatively, don't update to the latest Rust. If the Rust version was pinned, this bug wouldn't manifest either.

xyzzy_plugh 2y ago
The fact that you can just `cargo update` is besides the point. The standard library should never make a breaking change that breaks running code. Why is this the exception? If the problem is that it wouldn't be possible to add new traits, then solve that by gating access to new traits on a minimum version. It seems like the change should have been made as part of a new edition. This PR seems relevant: https://github.com/rust-lang/std-dev-guide/pull/66 https://github.com/rust-lang/std-dev-guide/pull/66 edit: I can't help but feel like we're moving the goal posts here. "Just don't update Rust" was the sort of response you'd encounter with nightly when nightly was basically required to do anything serious, but this is stable. There is even an accommodation for such changes! Why wasn't it used? This all just reeks of laziness and disregard for users.
- steveklabnik 2y ago
  > The standard library should never make a breaking change that breaks running code. Why is this the exception? It is an exception because it is a very minor breakage that is trivial to fix. Sometimes this is worth it. Sometimes it is not. I guess they made the call that it was worth it. As a user who was affected, I don't mind that this happened. > If the problem is that it wouldn't be possible to add new traits, then solve that by gating access to new traits on a minimum version. The issue here is rustc being updated. If the new trait was only available on the new version, the same thing would have happened. I'm not sure this suggestion would fix things. > This all just reeks of laziness and disregard for users. I have many criticisms of the Rust project these days, but I truly believe you are blowing this far out of proportion.
  - xyzzy_plugh 2y ago
    I hate to drag Go into this but I can't help but compare what happened here to the attitude here: https://github.com/golang/go/discussions/55092 https://github.com/golang/go/discussions/55092 My initial impression was that this is boiling the ocean but there's substantial foresight. If I'm blowing this out of proportion then the bar is already too close to the ground for my liking. This is solvable. I don't remember the last time a tool chain update broke my build. It's one thing if it's a bug fix. But for practically everyone to have to update? If 100,000 developers have to trip over this, say, then with your 10 minute estimate that equates to a million minutes, nearly 8 years at 40-hour weeks. This appears to be a problem totally worth solving.
  - hulitu 2y ago
    > It is an exception because it is a very minor breakage that is trivial to fix. Or so it seems. But who cares about quality ? /s
- joshka 2y ago
  > This PR seems relevant... It's not. The change doesn't have anything to do with the prelude. It was a new conversion was added, where existing code made an assumption that there was only one possible conversion that satisfied an inferred type. (In fact when that code was written it was superfluous as the conversion was actually converting from one type to the same type). That code was removed in https://github.com/time-rs/time/pull/671 https://github.com/time-rs/time/pull/671 The only code that is strongly broken by this is code that doesn't update its dependencies more regularly than its compiler... locking your deps but refusing to do so with your toolchain is just plain weird IMHO.