On 11/30/11 6:49 AM, Niko Matsakis wrote:
On 11/29/11 6:18 PM, Graydon Hoare wrote:
It's *very bad* in the case of copy: copies are made all over the
place and the world where copy-does-not-mean-copy is a familiar C++
nightmare I do not want to recreate. Copy constructors, move
constructors, conversion operators and assignment operators. Please
no. If someone wants to invoke custom code, make them write
custom_code() or custom.code(). At least.
I have two objections to this:
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.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
