Abstraction without overhead: traits in Rust

Post by jahewson » Mon, May 11, 2015, 9:41 PM UTC

MichaelGG wrote: post #39

GolDDranks wrote: post #25

Earlier quoted context omitted.

> Traits are somewhat between an interface and a mixin: an interface is made only of method signatures, while a trait includes also the full method definitions, on the other side mixins include method definitions, but they can also carry state through attributes while traits usually don't. Rust's traits may specify just a method signature and force the implementor of the trait to implement the method, but they may sp…

Java's interfaces are getting default implementations now, aren't they?

Post by [deleted] » Mon, May 11, 2015, 9:43 PM UTC

ajross wrote: post #43

steveklabnik wrote: post #40

Earlier quoted context omitted.

I guess we'll have to agree to disagree here. I think what you consider 'pretentious jargon' really depends on what kinds of languages you've used and the way you think about them. I think calling enums unions would have been a very big mistake, as they would mislead C programmers. Even you say that they're 'quite close', but they're not the same thing.

I, uh, don't really follow that logic. A Rust enum isn't even "quite close" to a C enum, yet you used a colliding term. Surely a C programmer who would have been mislead about the fact that a union type is runtime-tagged and checked is going to be very misled that an "enum" has no numeric value and can contain variable state at runtime.

Post by lambda » Mon, May 11, 2015, 9:55 PM UTC

ajross wrote: post #43

steveklabnik wrote: post #40

Earlier quoted context omitted.

I guess we'll have to agree to disagree here. I think what you consider 'pretentious jargon' really depends on what kinds of languages you've used and the way you think about them. I think calling enums unions would have been a very big mistake, as they would mislead C programmers. Even you say that they're 'quite close', but they're not the same thing.

I, uh, don't really follow that logic. A Rust enum isn't even "quite close" to a C enum, yet you used a colliding term. Surely a C programmer who would have been mislead about the fact that a union type is runtime-tagged and checked is going to be very misled that an "enum" has no numeric value and can contain variable state at runtime.

  enum Foo {
      Bar,
      Baz,
      Quux,
      Zot = -1
  }
  
  fn main() {
      println!("{} {} {} {}", Foo::Bar as i32, Foo::Baz as i32, Foo::Quux as i32, Foo::Zot as i32);
  }

Post by kzrdude » Mon, May 11, 2015, 10:04 PM UTC

pcwalton wrote: post #26

EugeneOZ wrote: post #23

Earlier quoted context omitted.

So in Rust traits can include full methods bodies, not only signatures?

Yes. The feature has been proposed for Java too: "defender methods". Originally I resisted them on the grounds of not being necessary, but they're used all over now. Being able to supply a default implementation is extremely useful.

Post by adrusi » Mon, May 11, 2015, 10:08 PM UTC

MichaelGG wrote: post #38

haberman wrote: post #5

Great article. The main bit of new information for me was that while Rust supports dynamic dispatch, its implementation has a noticeable difference from C++. In C++, the vtable pointer is in the object itself. In Rust, it's stored inside what is essentially a "fat pointer." Pointers to traits ("trait objects") are actually two pointers: the pointer to the vtable and the pointer to the actual object. This seems to hav…

Does it have to be 16 bytes? I could imagine code opting in to compressed pointers (with alignment/heap restrictions). And you'd only need enough vtable bits to cover all unique types right? But imagining is easier than implementing of course. It would require recompiling all code to use the same pointer style, but whenever unwind-free Rust exists, we'll already need different compilation options for everything anywa…