

Rust RFC: Opt-in Builtin Traits - adamnemecek
http://smallcultfollowing.com/babysteps/blog/2014/02/28/rust-rfc-opt-in-builtin-traits/

======
electrograv
_> Making opt-in explicit effectively solves this problem. It is clearly
written out which traits a type is expected to fulfill, and if the type is
changed in such a way as to violate one of these traits, an error will be
reported at the impl site (or #[deriving] declaration)._

Please implement this RFC. I _really_ hope this gets in before Rust 1.0. I'm
extremely excited and looking forward to using Rust in all my hobby projects
once it stabilizes, but honestly when going through the tutorial this stood
out as the only ugly wart in an otherwise amazingly beautiful language.

~~~
pcwalton
It'd have to be 1.0 if we want to do it at all, because it's not a backwards
compatible change. (We're serious about backwards compatibility for 1.0.)

------
dbaupp
This is a rather technical post about the precise details of some "internal"
Rust semantics... Not exactly designed for a general audience.

I'd be interested to hear if people unfamiliar with Rust can make head or tail
of it. :)

~~~
andrewflnr
I can't tell what your point is. If it's that this is not appropriate for HN,
I disagree strongly. If posts relating to a specific technology were not
allowed, HN could hardly live up to its name. For myself, this was one of the
few immediately interesting things on the front page, despite having little
more than passing knowledge of Rust.

~~~
bjz_
Having contributed a small amount to Rust, I wouldn't have naturally posted
this one to HN because I though it would be of little interest to folks
outside the community, but I'm glad it has interested some people! If you are
interested in reading more posts like this, they pop up sometimes on our
subreddit: [http://www.reddit.com/r/rust/](http://www.reddit.com/r/rust/)

~~~
andrewflnr
My point is, no one bats an eye when someone posts something that's only
relevant to, say, the Python or Haskell community. Further, I bet there are a
lot of people like me who aren't really rustites, but are interested enough to
want to keep tabs on Rust's progress. Anyway, I mean no offense, only to
encourage people to be bolder in posting. :) I'll go subscribe to /r/rust now.

------
stormbrew
So I really want to work with Rust on something and get to know it better, but
as a layman of it this struck me as the wrong direction. As a potential but
not current user of the language I'd rather see these kinds of traits _always_
be implicit, because that allows for more interaction potential between
independent libraries.

But more specifically, this part of the post struck me:

    
    
        >   struct Cell<T> {
        >      priv value: T
        >   }
    
        > This is a perfectly ordinary struct, and hence the
        > compiler would conclude that cells are freezable 
        > (if T is freezable) and so forth.
    

So how does it work, in the opt-in case, if Cell should be freezable only if T
is freezable? Can you declare this kind of expectation and how complex does it
get (particularly when considering several different traits)?

~~~
chrismorgan
> _So how does it work, in the opt-in case, if Cell should be freezable only
> if T is freezable?_
    
    
        impl<T: Freeze> Freeze for Cell<T> { }
    

> _I 'd rather see these kinds of traits_ always _be implicit, because that
> allows for more interaction potential between independent libraries._

Quite the opposite: them being implicit causes trouble with interaction
between independent libraries. Because at present, a seemingly innocuous
change deep in the internals of one library can prevent its being used in
another library—for example, a POD type can have an owned type added to it,
and all of a sudden utterly independent code that depended upon its POD
behaviour will fail due to move semantics on the linear types.

~~~
stormbrew
I'm not clear on how it being implicit or explicit changes this issue. Sure,
it is a benefit for the library writer that they can be told that their
library is breaking a contract that it previously held to, but if they change
it anyway the downstream user is still shit outta luck either way.

If it's just about making sure library writers don't accidentally fail a
changed contract just make it so that they _can_ declare an explicit contract
that will cause an error if they don't meet and thus make clear the contracts
they intend to continue honoring.

This makes the error explicit for exactly the right person in the event of a
contract change: the library writer if they break without intending to and the
user of the library if they are using the library in a way that they expect to
work but were not guaranteed to by the library writer.

> impl<T: Freeze> Freeze for Cell<T> { }

I see. Is it multiple statements for multiple traits or can theybe combined
into one statement? Forgive the newbish question.

~~~
chrismorgan
It makes it clear that a contract is being broken, which, if one is following
semver, would necessitate a new major version number. As it is, an expert
could easily miss the change; making this explicit is a Very Good Thing™.

On the Cell Freeze matter: I don't understand your question. Can you clarify
what you mean?

~~~
jruderman
Do you need multiple statements if you want your type to be "Freeze if T is
Freeze", "Share if T is Share", etc?

~~~
chrismorgan
Yes, you do. But that's not arduous.

