Restore MRSV to 1.63

[a1phyr]

No description provided.

[clarfonthey]

Is it really necessary to make the code less readable just so we can keep using a version that was released three years ago, because the one three years ago minus three months is too new?

[cuviper]

Opinions may vary, but I don't see how this is less readable. Having .cast_mut().cast() reveals very little information.
(IMO .cast_mut() is only better when you aren't intending to change the type.)

[clarfonthey]

I mean, that's fair, although my point still stands: I don't think that MSRV alone is justification for this change. Readability is debatable, but that isn't related at all to MSRV.

[Amanieu]

I would personally like to bump MSRV all the way up to 1.85 so that we can use the 2024 edition which has the MSRV-aware Cargo resolver enabled. And then never have to worry about MSRV ever again since older Cargo will just resolve to an older release of the crate.

[cuviper]

we can use the 2024 edition which has the MSRV-aware Cargo resolver enabled.

AIUI this is based on the edition of the root crate/workspace, not any given dependency, but yes once the minimum is 1.85 they might as well update their edition too. They can also set package.resolver = "3" starting in 1.84.

[a1phyr]

I think that rust 1.63 was chosen because it was the version of Debian Stable, but now that a new Debian version is out, changing it is probably OK. I usually don't push for freezing MRSV for years, I just needed that for indexmap and this was a simple change. As indexmap ended up allowing both versions, feel free to close this PR if you don't it desirable;

[Amanieu]

The latest debian stable is on Rust 1.85. @cuviper do you think it would be reasonable to bump MSRV all the way to that?

[cuviper]

No, e.g. RHEL only has 1.84.1 right now, but it will get an upgrade around November.

[Amanieu]

Given that indexmap has bumped its MSRV, this isn't needed any more?

[a1phyr]

I don't think so