3 ms·

I'm not familiar with Rust's rfc / implementation / go stable flow, but I'm curious how f32::clamp took so many years to go stable

vlang1dot0 6y ago
Looks like the two main issues were: 1. Some crates in the ecosystem have "extension traits" that add the same method to `f32`. Adding this into std will cause conflicts with those methods so users will need to disambiguate or remove their use of those extension traits. (This is allowed breakage under the stability guidelines) 2. Should this use this two arguments or a range (`x.clamp(1.0, 5.0)` or `x.clamp(1.0..5.0)`)? I think part of the reason this took so long was that by having widely used crates like `numtools` in the ecosystem that provided this functionality, it took a lot of the pressure off having this in std/core.
steveklabnik 6y ago
You can read the relevant history here: https://github.com/rust-lang/rust/issues/44095 https://github.com/rust-lang/rust/issues/44095 Short summary: First delay was ecosystem breakage; many people had defined their own functions with the same name. We're allowed to make these changes but tend to try not not unnecessarily break people. It then sat for about a year. The original author was a bit tired from all of the work to get to that point, and reasonably let it sit. There was then a small discussion about taking individual parameters vs ranges. Six months after that, it finally actually landed, thanks to some other changes that would help mitigate the breakage. It then sat for a while, until the libs team proposed merging. That brought up a lot of the previous design questions, which some people thought weren't resolved to their satisfaction. It then finally got stabilized in October of last year, and then it had to wait for the release trains. So, TL;DR: a surprising amount of details for such a small feature, which can lead to burnout, along with not enough people wanting to push it over the line.
- slmjkdbtl 6y ago
  Thanks for the reply Steve! Have been enjoying your works / content :D.

vlang1dot0 6y ago

Looks like the two main issues were: 1. Some crates in the ecosystem have "extension traits" that add the same method to `f32`. Adding this into std will cause conflicts with those methods so users will need to disambiguate or remove their use of those extension traits. (This is allowed breakage under the stability guidelines) 2. Should this use this two arguments or a range (`x.clamp(1.0, 5.0)` or `x.clamp(1.0..5.0)`)? I think part of the reason this took so long was that by having widely used crates like `numtools` in the ecosystem that provided this functionality, it took a lot of the pressure off having this in std/core.

steveklabnik 6y ago

You can read the relevant history here: https://github.com/rust-lang/rust/issues/44095 https://github.com/rust-lang/rust/issues/44095 Short summary: First delay was ecosystem breakage; many people had defined their own functions with the same name. We're allowed to make these changes but tend to try not not unnecessarily break people. It then sat for about a year. The original author was a bit tired from all of the work to get to that point, and reasonably let it sit. There was then a small discussion about taking individual parameters vs ranges. Six months after that, it finally actually landed, thanks to some other changes that would help mitigate the breakage. It then sat for a while, until the libs team proposed merging. That brought up a lot of the previous design questions, which some people thought weren't resolved to their satisfaction. It then finally got stabilized in October of last year, and then it had to wait for the release trains. So, TL;DR: a surprising amount of details for such a small feature, which can lead to burnout, along with not enough people wanting to push it over the line.

slmjkdbtl 6y ago
Thanks for the reply Steve! Have been enjoying your works / content :D.