Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The traits section seems to be more a problem of the author seeing object and classes instead. Calling them traits and not classes should have been enough, IMO, to dispel that, but it is a common mistake so fair enough. You should think of them, as the compiler devs do, as Prolog code interpreted at compile time.

Traits are sets. “Impl” means a type, or any type described by the constraints, is in that set.

    trait A {}
    struct S;
    impl A for S {} // S is in A
    impl<T> A for Vec<T> where T: A {} // Vecs of A are also in A
Type constraints are a way to use those sets to specify which types are allowed in which places. The compiler then tries to prove that the types you do use are in fact in the sets you say they have to be in.

That’s it.



On reflection I think they were referring to both traits and trait objects instead (“Call tables”). I don’t know what more you can ask for than the Rust Book’s entry on trait objects. Not sure how you get “immature language” from this page:

https://doc.rust-lang.org/book/ch17-02-trait-objects.html


Trait objects are kind of a pain and there are some improvements that could be made there.

Here's a random example: if you want a trait object with more than one trait, that only works today if one of the two is an auto trait: https://play.rust-lang.org/?version=stable&mode=debug&editio...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: