Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
sfackler opened this issue Feb 28, 2015 · 6 comments · Fixed by #23866
Closed

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

sfackler opened this issue Feb 28, 2015 · 6 comments · Fixed by #23866
Assignees
@alexcrichton
Labels
I-needs-decision Issue: In need of a decision.
Milestone
1.0 beta

Comments

@sfackler
Copy link
Member

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

cc @aturon
@sfackler
Copy link
Member Author

Nominating for backcompat-libs, needs-decision

@alexcrichton
Copy link
Member

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

@pnkfelix
Copy link
Member

pnkfelix commented Mar 5, 2015

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

@pnkfelix pnkfelix added this to the 1.0 beta milestone Mar 5, 2015
@pnkfelix pnkfelix added I-needs-decision Issue: In need of a decision. and removed I-nominated labels Mar 5, 2015
@alexcrichton
Copy link
Member

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!

@pnkfelix pnkfelix reopened this Mar 26, 2015
@alexcrichton alexcrichton self-assigned this Mar 26, 2015
@bluss
Copy link
Member

bluss commented Mar 27, 2015

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

@alexcrichton
Copy link
Member

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.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 30, 2015
@alexcrichton
std: Standardize (input, output) param orderings
acd48a2 
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 rust-lang#22890
[breaking-change]
@alexcrichton alexcrichton mentioned this issue Mar 30, 2015
Merged
Manishearth added a commit to Manishearth/rust that referenced this issue Mar 31, 2015
@Manishearth
Rollup merge of rust-lang#23866 - alexcrichton:switch-some-orders, r=…
5793804 
…aturon

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 rust-lang#22890
[breaking-change]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alexcrichton alexcrichton

Labels
I-needs-decision Issue: In need of a decision.
Projects
None yet
Milestone
1.0 beta
Development

Successfully merging a pull request may close this issue.

std: Standardize (input, output) param orderings alexcrichton/rust
4 participants
@alexcrichton @pnkfelix @sfackler @bluss