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.

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

impl Clone for Command #22858

Closed
wants to merge 1 commit into from
Closed

Conversation

japaric
Copy link
Member

@japaric japaric commented Feb 27, 2015

dejavu

Both (unix/windows) underlying Command implementations are already Clone.

r? @alexcrichton

@alexcrichton
Copy link
Member

I actually explicitly requested that we not implement Clone for Command this time around:

We may actually want to consider removing this Clone implementation. I've thought in the past that if stdin, stdout, and stderr happen to take some form of I/O object it will likely not implement Clone.

Although we could also just say that the Clone implementation clears the input/output handles.

That being said, I'd be willing to revisit it.

@japaric
Copy link
Member Author

japaric commented Feb 27, 2015

I actually explicitly requested that we not implement Clone for Command this time around:

That'd be bad for me, because I rely on clonning Command in my benchmark library to bench an external program under different inputs: e.g.

let inputs = 0..10;
criterion.bench_prog_with_inputs("py", Command::new("python").arg("under_test.py"), inputs);

Without it, doing the same operation would be unergonomic as you'll have to repeat the Command chain several times:

// one call for each value of `$N`
criterion.bench_prog("py/$N", Command::new("python").arg("under_test.py").arg("$N"));
...
// and the user must not forget to summarize the results at the end
criterion.summarize("py");

Although we could also just say that the Clone implementation clears the input/output handles.

That sounds reasonable to me.

I'll stick to the old Command for the time being. I guess this PR needs an approved RFC? (If yes, feel free to close)

@alexcrichton
Copy link
Member

Without it, doing the same operation would be unergonomic as you'll have to repeat the Command chain several times:

Another option, however, would be taking a FnMut() -> Command instead of a Command itself (e.g. a factory vs explicitly cloneable object). I do agree though that it is less ergonomic.

I guess this PR needs an approved RFC?

That feels a bit heavy-handed for this particular aspect in my opinion. I believe @aturon is on vacation right now but I would be curious to hear his thoughts on this as well.

@bors
Copy link
Contributor

bors commented Mar 3, 2015

☔ The latest upstream changes (presumably #22882) made this pull request unmergeable. Please resolve the merge conflicts.

@aturon
Copy link
Member

aturon commented Mar 5, 2015

@alexcrichton

I believe @aturon is on vacation right now but I would be curious to hear his thoughts on this as well.

So, I'm uncomfortable with a Clone implementation that doesn't actually "fully" clone the object, e.g. by clearing out the handles. We could provide some differently-named method to make more clear what was happening, perhaps.

@japaric
Copy link
Member Author

japaric commented Mar 5, 2015

We could provide some differently-named method to make more clear what was happening, perhaps.

I'd be happy with this alternative.

@aturon
Copy link
Member

aturon commented Mar 10, 2015

@japaric Ok, I think we could probably take an #[unstable] API like that; any thoughts on a good name? The ones coming to mind for me are pretty long, e.g. clone_without_handles.

@alexcrichton
Copy link
Member

Closing due to inactivity, but feel free to reopen with @aturon's suggestion!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants