-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Conversation
Add two keywords in order to enable the C++ like implicit move-optimizations and make traits more expressive.
I guess this is a counter-proposal to this RFC #118 |
-1, I'm opposed to any implicit clones in the language. |
@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. |
Two whole keywords for this is a whole lot of complexity. It would be an extra barrier for anyone learning the language. |
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. |
@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 |
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 {
auto x = Foo{...};
auto frobbed_x = Frobulate(std::move(x));
} So the caller needs to remember to call 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. |
@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". |
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. |
@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. |
Closing. It's a principle design goal of Rust to avoid invoking operations implicitly, especially copy constructors. Thank you. |
Rendered view