On 11-11-29 04:10 PM, David Herman wrote:
The same argument can be made against user-defined functions.
Absolutely. I think making a language is, in many ways, a process of
figuring out which parts are "worth" making user-definable -- because
some must be, or users expect them -- and which parts are better left as
"fixed" structure users can rely on when they read other people's code.
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`).
People will import foo::* and by doing so change the meaning of
otherwise-obvious code that interacts with type foo.
It's *somewhat bad* in the case of send: the surprise might be that
nothing gets sent, or something is sent multiple times, or there are
side effects you didn't expect. It's clearer what's going on if sending
is sending and conversion functions or other pre/post-send operations
are separate functions.
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.
In C++ the argument is "we want custom code to look like built-in code",
and have access to all the same sorts of magic. I want the opposite of
that. I want custom code to *look* like it's doing custom things, so
that the absence of custom-looking-operations can be safely skimmed by a
reader with better ways to spend their day.
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.
Mental model, yes. This is the argument in favour. I can see this, if it
fits. But it might be a "typeclass" that's defined by the compiler and
can't be touched by the user.
Customization model, I'm much less keen on.
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.
Ok. We'll have to arm-wrestle on the first point when the time comes :)
The second remains to be seen. I'm hopeful though!
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.
I suppose that's a way of looking at it. I'm generally arguing that I
want send to send and copy to copy. That the value of an author being
able to "transparently" change the meaning of those operations is less
than the value of a reader being able to rely on fixed meanings for them.
I guess as you say the cognitive load goes down if you can eliminate
"kind" in favour of "typeclass that is automatically defined for all
tycons and also cannot be redefined for user types". I'd be tentatively
ok with that if the typeclass thing works out.
Same for ord and eq, IMO. And all the other operators.
If we absolutely cannot agree on whether these should be overridable, I
will at least go implement a #[no(custom_operators)] pragma to accompany
#[no(gc)]. For every user who wants expanded flexibility there are many
who just want to fix their bugs and go home at 5.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
