Skip to content
New issue

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

#

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

Already on GitHub? # 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]
# for free to join this conversation on GitHub. Already have an account? # 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