Rust traits for developer friendly libraries

http://benashford.github.io/blog/2015/05/24/rust-traits-for-developer-friendly-libraries/

by nercury • 11 years ago

102 44 11 years ago

benashford.github.io

jblow7• 11 years ago

This way of doing things sure sounds like it has massive performance implications.

Those are very lightweight abstractions as the compiler will generate optimized code for each variant separately. That's the entire point of Rust Trait abstractions.

jblow7• 11 years ago

I am talking about the actual conversion of an unowned object to an owned object, which as nearly as I can tell involves copying the object? Implicitly? All the time?

nightpool• 11 years ago

As another commenter implies, trait methods are statically dispatched, so there's no indirection, and very little runtime overhead[0]

[0] I'm not that great at Rust, so if there's some hidden cost to this beyond just the conversion methods themselves, someone please correct me.

Tyr42• 11 years ago

There are two ways of being polymorphic over traits in Rust, using static dispatch or boxed traits.

Static Dispatch is very analogous to C++ templates (with the as of yet not included in the standard "Concepts" as Traits), so you get a copy of the function specialized for each type. (We get nicer error messages than templates in C++ because we require you to declare up front what methods you are expecting the type to have at function definition time instead of checking at specialization time that everything is defined.) There is no runtime cost to using a statically dispatched trait over a hand specialized version of the function.

The other method, boxed traits, is very similar to vtables. It has some runtime overhead, since the size of the time is not known, you must have a pointer to it (hence "boxed"). I think Rust currently uses fat pointers for this, that is a pair of pointers, one to the object, and the other to the vtable, since you can add new instances to types in other crates, so it'd be tricky to have a complete vtable for all methods of all the traits the type implements in one place.

ndarilek• 11 years ago

I've been using Scala for years and have been eying Rust for a while. Nice to see lots of the things I like from Scala carry over. In particular this seems like a less magical version of Scala implicits, which seem incredibly cool at first until you realize that a particular library or framework implements implicits for everything, and tracking down the source for a given function involves guessing the signature or chasing down an implicit implicit conversion chain that gets you to one.

One thing I'm not sure about though, the article talks about implementing the Into trait, then quickly segues over to From. When would I use Into, when From, and do they both lead to the same end (I.e. a function that takes Into<Whatever>?) I've looked at the docs for each, and maybe I just haven't had enough coffee yet but the distinction isn't too clear.

steveklabnik7• 11 years ago

When would I use Into, when From

The standard library contains this code:

    // From implies Into
    #[stable(feature = "rust1", since = "1.0.0")]
    impl<T, U> Into<U> for T where U: From<T> {
        fn into(self) -> U {
            U::from(self)
        }
    }

So, you basically only ever implement From, and you get the equivalent Into for free.

More specifically, you would usually use `Into` to bound a generic function:

    fn is_hello<T: Into<Vec<u8>>>(s: T) {
        let bytes = b"hello".to_vec();
        assert_eq!(bytes, s.into());
    }
    
    let s = "hello".to_string();
    is_hello(s);

Whereas you'd use From to perform a conversion:

    let string = "hello".to_string();
    let other_string = String::from("hello");
    
    assert_eq!(string, other_string);

These APIs are pretty new; they landed _right_ before beta happened. We used to have FromFoo traits, and this generic system replaced them.

rbalicki• 11 years ago

Thank you! This is the best explanation I've been able to find for how to use From, instead of Into.

One thing that's useful about From is that you can implement From<SomePublicStruct> for YourPrivateStruct, but the compiler complains about Into<YourPrivateStruct> for SomePublicStruct.

SomePublicStruct could be (i32, i32) and YourPrivateStruct could be MyPoint, for example.

Making YourPrivateStruct public (with pub struct) fixes things, but that's not always what you want.

jimmyhmiller• 11 years ago

Maybe a bit off topic.

I've always heard that traits in rust are basically just type classes in haskell. But I'm not quite sure how you would implement this trait as a typeclass.

Specifically, from what I'm seeing here is that if you just implement From you've also now implemented Into. Is there an analog in haskell? I also can't figure out how to specify a type class that is parametrized the way into is.

Can anyone help by shedding some light on how you might go about this in haskell? Or where traits in rust differ from typeclasses in haskell?

jdub2• 11 years ago

Hmm. Can you...

  impl From<T> for GeoBox

... outside the module/crate in which GeoBox is defined (as suggested at the end)?

benashford• 11 years ago

Yes, as long as the implementation is in the same module/crate as the T.

It's only where both the left and right-hand side are in external crates that would be a problem.

jdub2• 11 years ago

Epic, thanks!

untothebreach• 11 years ago

Yep, that is an advantage rust traits have over, say, java interfaces. (Though I hear java 8 is going to be able to do this as well)

twic• 11 years ago

Java 8 is out now and doesn't have this. I'm not aware of anything like this being on the cards for Java 9. Could you tell us more about what you heard?

novocaine• 11 years ago

I still have the scars from libraries implementing implicit conversions in c++.

The question is - for people reading the code at the call site, how easy is it to grep for what's actually happening?

I guess this rust trait at least hangs off the geobox class, but I think I might prefer the explicit ctor for non write-only code.

steveklabnik7• 11 years ago

Coherence helps with this: you can only implement a trait for a type if you've defined either the trait or the type. So a third party library can't impl From<MyType> for YourType`, for example.

In general, I find Rust pretty grep-able, though I'm a bit biased.

Rust traits for developer friendly libraries

Related Stories