3 ms·

It's backwards compatible because the old behavior was to simply make long evaluations an error every time. The new system gives you the option to allow a long

• SkiFire13 3y ago
  I think OP is looking at backward compatibility with respect to libraries. For example today I make a library that does a lot of computations in `const` functions and it works with rust 1.72.0; tomorrow I slightly change function by splitting a statement into two, and now suddently the evaluation becomes too long and my dependents don't compile anymore. Though to be honest this problem existed even before rust 1.72.0 and likely can't be solved while preventing infinite computations.
  • Hirrolot 3y ago
    Exactly. The point is that most Rust libraries use semantic versioning, which actually forces you to determine if the change you've made to your library is backwards-compatible or not. I think it's a good practice but it's unclear to me how it should be applied to `const` functions.
  • mirashii 3y ago
    > it works with rust 1.72.0; tomorrow I slightly change function by splitting a statement into two, and now suddently the evaluation becomes too long and my dependents don't compile anymore. Just to be clear, this was the case before the new changes in 1.72. They already had that limit, and code could break in exactly that way. There were two problems with that beyond the simple backwards compatibility break. One is that there was no opt out, so if you broke you were kinda hosed at the library level. The second is that the limit was relatively low and so it was very possible to hit it. Now if you end up running too long and the compiler fails, you’ve at least got an opt out, and the limit before failure is much higher.