std::slice::bytes::copy_memory and std::io::copy take their arguments in different orders

[sfackler]

std::slice::bytes::copy_memory takes the destination first (like memcpy does), while std::io::copy takes the source first.

cc @aturon

[sfackler]

Nominating for backcompat-libs, needs-decision

[alexcrichton]

Other APIs to consider are std::fs::{copy, rename} as well (which currently agree with io::copy and disagree with bytes::copy_memory)

[pnkfelix]

P-backcompat-libs, 1.0 beta, I-needs-decision.

[alexcrichton]

Well and then on the other hand ptr::copy and ptr::copy_nonoverlapping agree with slice::bytes. So now we have stable functions on both sides of the fence!

[bluss]

Those functions that are basically memmove and memcpy wrappers, shouldn't they just stick to that argument order?

[alexcrichton]

We tend follow general C principles in terms of the overall API of a function (e.g. roughly matching inputs and outputs), but we don't always strive for exact compliance with C APIs with respect to aspects such as argument order. A "rustic" design and a consistent standard library come paramount after selecting the right set of inputs/outputs for us.