On 11-11-30 12:36 PM, Niko Matsakis wrote:
I have been thinking over my own objections and I realize I was
mistaken. I still think we should avoid implicit copies, but we do have
to be very careful with allowing people to modify the copy mechanism,
for two reasons
- copy must have a certain minimal meaning for reasoning about unique
pointers to be sound;
- given a user-defined type where copying ought to be customized, it
would be unfortunate if failing to import the proper implementation gave
you the wrong copy.
To put this another way, I think allowing users to extend the language
to cover undefined operations is generally fine. For example, if copying
were not permitted unless the user defined it, that would be one thing.
But if there is a default behavior, then letting the user override that
behavior—particularly via scoped implementations—is probably not a good
idea.
Agreed. Relative to your example, I'd be totally fine with a "cloneable"
iface (to reuse the java terminology) that does a deep, type-specific
copy, on types that choose to implement that. Hashtbl.clone() is fine.
I also agree that careful design consideration for minimizing implicit
or accidental copies is important. It's definitely good to keep in mind,
and a fair bit of the existing machinery tends in this direction already.
I just don't want to go injecting custom code paths into the meaning of
initialization, assignment, moving, argument-passing, and similar
"primitives". Remove too many primitives and the user has no solid
ground to stand on.
Thanks for giving this further thought! I felt like I came off quite a
bit more harsh yesterday than I wanted to, am sorry for the reactionary
tone.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
