std: Standardize (input, output) param orderings

[alexcrichton]

This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).

The affected functions are:

• ptr::copy
• ptr::copy_nonoverlapping
• slice::bytes::copy_memory
• intrinsics::copy
• intrinsics::copy_nonoverlapping

Closes #22890
[breaking-change]

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @aturon

[petrochenkov]

It may be an off-topic, but I always wanted to ask - why copy and copy_nonoverlapping are in ptr and not in mem?
mem::copy - copy memory, totally understandable and resembles memcpy
ptr::copy - what? copy pointer?

[alexcrichton]

APIs that are centered around raw pointers go in std::ptr currently while those dealing with references go in std::mem (in general). Also, the _memory suffix from ptr::copy_memory was recently dropped as there's probably not much you're copying with pointers other than the memory itself.

[aturon]

@bors: r+ acd48a2

[mahkoh]

Thanks for causing segfaults all over my code with this change that was obviously not in need of an RFC because it was submitted by @alexcrichton himself. This is what one has to expect from #[stable] Rust.

[Stebalien]

IIRC, stable isn't really stable until 1.0 (or maybe beta?). As is, we're still in alpha. From the blog post:

Our promise is that, if you are using the stable release of Rust, you will never dread upgrading to the next release.

[mahkoh]

Yeah, who gives a beep about undetectable changes that are guaranteed to introduce memory unsafety all over the place downstream.

[Stebalien]

Other people silently breaking your code is really annoying but please remain civil; this is not lkml. You're using an unstable alpha language and Alex made that change to prevent future confusion (users generally expect copy to be from-to).

[mahkoh]

Other people silently breaking your code is really annoying

You're conflating breaking with introducing undefined behavior that cannot be detected without manually auditing every place copy is used. Most people won't even notice that copy has been changed and won't understand why they get segfaults or how to find the source of the problem.

this is not lkml

I don't read lkml but you're making it sound like a swell place.

(users generally expect copy to be from-to)

Nonsense.

[comex]

It's too late now, but I guarantee this will confuse a large number of people coming from C and expecting a memcpy replacement. Though I suppose that bridge is already crossed by std::ptr::copy taking an element count rather than byte count - I made the error of assuming the latter when I first used (the old name of) that function.

[blaenk]

Regarding the confusion, I honestly think that if people blindly write code expecting it to be the same as in some other language then that's on them. If it were named the same then yeah I would agree that could be misleading.

[sinistersnare]

(not trying to be vitriolic)

Was this ever discussed in an RFC? This seems like something that would have happened in one of the stabilization RFCs, and I stopped subscribing to rustc dev a couple months ago (mailbox was becoming too fat)

[pcwalton]

@aturon @alexcrichton Whoa, this was not the right call. I'm with the others. If i had known about this, I would be completely opposed.

[pcwalton]

I think this should be reverted. Submitted #24142 to revert it.

[aochagavia]

@alexcrichton what about mem::replace? It still has output, input order. Should I open a PR to fix it?