On Nov 29, 2011, at 3:51 PM, Graydon Hoare wrote: > On 11-11-29 03:43 PM, David Herman wrote: >> On Nov 29, 2011, at 3:11 PM, Graydon Hoare wrote: >> >>> On 11-11-29 12:00 PM, Niko Matsakis wrote: >>> >>>> I like that this allows the user to customize how types can be copied, >>>> logged, and sent. >>> >>> I don't. It's in conflict with predictability and the guarantees the >>> language is trying to make for its users' mental models. >> >> I don't see any evidence of this claim. These are still totally statically >> predictable, and not only that, the client can control which implementations >> they want to use by means of scope. > > "Customize" and "predictable" are, in general, opposites. If custom code > might be invoked as part of an operation, the reader has to go read the > custom code to figure out what it does.
The same argument can be made against user-defined functions. But in practice, you don't have to read code you invoke to understand it, because the writer of the code provides a high-level description of what it does. Overloaded methods similarly invoke user-defined functions. This *theoretically* means that, in general, the definer of the overloaded implementation could do anything, but just like other functions, in practice they should write programs that obey the general contract of the overloaded operation. And the nice thing about this design is that clients only get the overloadings they explicitly ask for (by bringing them into scope via `import`). So you don't get silent changes to the meaning of operations -- this makes a big difference for predictability and client-side control. Crucially, it also decreases the amount of magic in the language by making things like `send` into part of a single, uniform notion of a type bound. This is a really big win for the mental model. > I have the exact same objection to operator overloading and several other > dimensions along which extensibility may be offered. I think too much > extensibility is not a good thing. I think operator overloading is important; I don't think it's too much extensibility. But I think typeclasses and method overloading are even more important. Maybe you're not arguing against typeclasses and bounded types, but just that `send` and `copy` should be fixed typeclasses that can't be user-instantiated. That at least preserves the uniformity of concept of type bounds. But I think the restriction adds complexity and hurts expressiveness (in particular, that you can't define new sendable data abstractions) for not enough gain. Dave _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
