Skip to content

Add cloned and stable keywords #124

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

Closed
wants to merge 4 commits into from
Closed

Add cloned and stable keywords #124

wants to merge 4 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Jun 16, 2014

tommit added 3 commits April 24, 2014 13:18
Add two keywords in order to enable the C++ like implicit move-optimizations and make traits more expressive.
@ghost
Copy link
Author

ghost commented Jun 16, 2014

I guess this is a counter-proposal to this RFC #118

@pcwalton
Copy link
Contributor

-1, I'm opposed to any implicit clones in the language.

@ghost
Copy link
Author

ghost commented Jun 17, 2014

@pcwalton (Almost) the whole point of this proposal is to reduce unnecessary cloning in straightforward code. So, if this proposal increases unnecessary cloning, then it clearly doesn't make any sense. I'd like to see an example that would demonstrate such regression.

@thestinger
Copy link

Two whole keywords for this is a whole lot of complexity. It would be an extra barrier for anyone learning the language.

@Valloric
Copy link

Agreed with @pcwalton, experience with C++ has taught us that implicit copies are a bad idea.

Also agreed with @thestinger that two keywords for this is a large complexity cost without a commensurate benefit.

@ghost
Copy link
Author

ghost commented Jun 18, 2014

@Valloric C++98 taught us that making unnecessary copies is bad. Then C++11 fixed all that with rvalue references. Rust for the most part doesn't have the C++98 problem with unnecessary copies, but it does have this one issue (which C++11 fixed also by the way) with them which this proposal is trying to fix. I think not fixing the issue is worse than having to introduce two new keywords.

Although, I should add that the C++11 fix for this issue isn't nearly as elegant, because there's no "move if it's the last use" static analysis stuff, but rather, you have to explicitly say std::move(x) to get this effect if x is an lvalue.

@Valloric
Copy link

Then C++11 fixed all that with rvalue references.

That's more than a bit generous, and I say that as a fan of rvalue references.

In C++11, the correct way to pass a large object to a function that needs a copy of it internally is by-value. So Foo Frobulate(Foo f) {} and then the caller should do the following:

{
  auto x = Foo{...};
  auto frobbed_x = Frobulate(std::move(x));
}

So the caller needs to remember to call std::move; if they forget, they get a possibly expensive copy. And no, that copy is never going away automatically through compiler optimizations because the standard mandates that the destructor of x is called after the Frobulate line. Even if the user doesn't forget to call std::move, they still need to remember to not use x after the std::move + Frobulate call since x is now in a "valid but undefined" state (as per the standard) which is a polite way of saying "you better not use x you damn fool."

So we have Yet Another way to shoot ourselves in the foot.

I'm not saying there was a better way of doing this given the need for backwards compatibility (I don't think there was) and rvalue references really are a godsend, but "C++11 fixed all that" is a bit much.

@ghost
Copy link
Author

ghost commented Jun 18, 2014

@Valloric I was merely trying to give a more fair and balanced assessment of what C++ has done than your proclamation that "experience with C++ has taught us that implicit copies are a bad idea".

@sellibitze
Copy link

I like the spirit of the proposal. But IMHO it has some problems. One example is that it completly ignores the use of traits as "interfaces" for runtime dispatch. The disconnect between the trait's function signatures (with "stable") and their implementation variants (with cloned or &T) seems hard to consolidate.

@ghost
Copy link
Author

ghost commented Jun 19, 2014

@sellibitze Very good point. That didn't occur to me. I don't see any way around that problem either.

To me all this seems to hint (and this is just for future reference) that you shouldn't combine interfaces (that are used for runtime polymorphism) and concepts (using the term freely here) into this one thing (Rust traits). Interfaces require exact function signatures, while concepts are a higher level view of a thing and not necessarily defined on the level of exact function signatures.

@brson
Copy link
Contributor

brson commented Jul 10, 2014

Closing. It's a principle design goal of Rust to avoid invoking operations implicitly, especially copy constructors. Thank you.

@brson brson closed this Jul 10, 2014
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.

6 participants