Two PRs landed in the runup to beta that, sadly, somewhat silently change the semantics of existing methods:
The order of arguments to ptr::copy and related methods was reversed, making them consistent with the order of IO APIs.
The splitn function n argument’s meaning changed to the number of returned items, rather than the number of splits.
If you’re upgrading to beta, you should audit uses of these APIs.
The copy change causes a compile-time error since the two arguments have a different type (*const T v.s. *mut T), so it’s impossible to miss, which is good.
I’m more worried about splitn. I think we should try harder than this not to make breaking changes that break silently. This should have been accompanied with a change to the name or signature, which is perhaps still worth doing.f
Uh, I just realized the copy change can also break silently because a *mut T argument can silently coerce to *const T.
FWIW this was only allowed to happen due to being pre-beta. It was perhaps the wrong call, but in any case we have no intent to make this kind of change once the stability system is in effect.
(That includes, IMO, changes to unstable APIs; in the future we should take pains to cause visible breakage when we want to revamp a not-yet-stable API)
Last time I tried to change a stable API, the patch didn’t land without an RFC. What makes this different?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.