|
|
|
|
|
by tialaramex
36 days ago
|
|
I agree but more common than "Now allowed in const context" is "This new type/method/free function is now stabilized" e.g. in 1.95 they stabilized a bunch of "Atomic update" methods such as: AtomicPtr::update which is a nicer way to write one of those "Get the pointer, do some stuff to calculate a new value from the old one, then try to swap its old value for the new one, if the pointer changed meanwhile repeat each time with the changed value until we succeed" stanzas some low-level people will have written a hundred times. This library feature does all that boring boilerplate for you, you just write that "calculate a new value" code as a lambda (or function, Rust doesn't mind) and you're done. That's the sort of feature where if it didn't exist when you wrote your code, you go "That's nice" and move on, no change needed, but now that it does exist you might use it in future software you write. If you have a team writing Rust it probably makes sense to have somebody read these changelogs, but that's about it. |
|
I don't understand at all how someone could plausibly argue that this is a problem in this context. At absolute most, you could argue against some of the downstream effects of the rapid release cycle (like how it reinforces the small standard library size; more surface area means potentially more bugs, and putting out an extra release to fix them when there are already releases so frequently is a hard sell, so it makes sense to keep things slim), but the article doesn't have anywhere close to that level of nuance in addressing the issue, so I'm skeptical that this is even something they've considered.