Idea: trait methods with un-overridable implementations

language design
1

Often traits contain extension methods which are not intended to be overwritten. Overriding their implementation may result in correctness bugs. Additionally, accounting for potential overrides may complicate API evolution.

I think something like #[non_overridable] could be a useful addition to the language:

trait Foo {
    fn foo(&self);

    #[non_overridable]
    fn foo_twice(&self) {
        self.foo();
        self.foo();
    }
}

Such methods could also be excluded from vtables, thus potentially reducing their size (i.e. implementation of the extension methods can be reused across trait implementors).

We can achieve a similar result with extension traits, but I think the attribute would be a cleaner and more ergonomic solution.

What do you think?

4 Likes
2

Sealing is another approach.

A first-class way to have final methods would be nicer. It should be made forward-compatible with specialization.

1 Like
3
9 Likes
4

Good to see that there is already an RFC for that!

Though it would be nice to mention whether dyn-compatible final methods will be or not part of generated vtables since it has implications for optimizing performance vs binary size. (I haven't read the RFC discussion yet)

1 Like
5

They don't need to be, right?

6

Yes. It's explicitly mentioned in the RFC:

A final fn never prevents a trait from having dyn-compatibility; the trait can remain dyn-compatible as long as all non-final methods support dyn-compatibility. This also means that a final fn can always be called on a dyn Trait, even if the same method as a non-final fn would not have been dyn-compatible.

7

"Always"? Surely not for Self: Sized methods... but I could see this working to use final on generic methods that would have had a "fake" Self: Sized requirement before just to release it from dyn-compatiblity. Being generic also implies that they're not accessed through the vtable.

1 Like
8

I had that thought too, but either the final fn is also declared Self: Sized, meaning it’s not available on dyn for that reason, or it’s not, meaning it can’t call the non-dyn-compatible requirements anyway.

9

I guess I could use an example, because I'm not sure what this "always... even if ..." statement is allowing that you couldn't do before.

1 Like
10

Yeah, good point, I think the very last sentence is incorrect as written.

11

I'm not sure what is the difference with the standalone functions:

trait Foo {
    fn foo(&self);
}

fn foo_twice(foo: &impl Foo) {
    foo.foo();
    foo.foo();
}
2 Likes
12

That doesn't let users call thing.foo_twice().

13

How would that work when the method accesses an associated method/constant of Self or its TypeId?

1 Like
14

Surely there are other benefits, besides minor sugar, for a new feature?

Personally I can't think of any. Any trait bound and function call which is used by a final method can just as well be replicated on a free function. Final methods also are explicitly exempt from the normal dynamic dispatch and implementation override rules that normal trait methods have. Any trait method which calls a final method can just as well call a corresponding free function.

One potential benefit could be forbidding further specialization. E.g. a specialized trait implementation could declare some method definition as final, forbidding further specialization. But specialization itself is very unstable, and it's unclear whether such a feature could be compatible with it (normally, specialization is allowed/disallowed at the level of type & trait signatures and bounds, and the definitions of methods don't play a part in it).

2 Likes
15

It would be a generic method that's generic on Self: Trait. It's just that the generic implementation would be common to all types that implement it so that no additional viable entry would be needed.

16

To be explicit about something that took me a little bit to figure out: this will need to use the vtable, but it will have the same code for any implementer (assuming no inlining or other optimizations that interfere with it) such that it doesn't need its own entry in the same way a fn foo(foo: &impl Trait) doesn't need a vtable entry.

17

How's that supposed to work? You still need monomorphised instances, because types have different sizes, different ABI conventions based on that. A single function can't have one prologue that can handle every possible argument type.

18

(Edit: This doesn't work in a subtle case crafted by @SkiFire13 in his response below.)

Yes, exactly, you would have monomorphized instances. That doesn't require a vtable entry, though, same as what @JarredAllen said in his reply.

In case I'm overlooking something or perhaps am misunderstanding the concern, here's a concrete example:

trait Foo {
  fn bar(&self);
  final fn baz(&self) {
    // ...
  }
}

is functionally equivalent to

trait Foo {
  fn bar(&self);
}

fn baz<T: Foo + ?Sized>(t: &T) {
  // ...
}

Here, baz can call Foo methods, and since there's exactly one code implementation of baz, Foo methods can call that baz implementation. And monomorphization can do its magic to make that work for the given type. This should also work fine for trait objects due to the ?Sized on baz.

The only advantage I can see for defining it as a final trait method is that when you import trait Foo somewhere, you also import the baz method rather than having to import it separately. But functionally, I don't see a difference, unless I've misunderstood something. I'd appreciate any corrections.

1 Like
19

Here's an example of observable difference between the two implementations by using TypeId/type_name:

trait Foo: 'static {
  /*final*/ fn baz(&self) {
    println!("{}", std::any::type_name::<Self>());
  }
}

fn baz<T: Foo + ?Sized>(t: &T) {
    println!("{}", std::any::type_name::<T>());
}

impl Foo for () {}

fn test(t: &dyn Foo) {
    t.baz();
    baz(t);
}

fn main() {
    test(&());
}

The .baz() method prints () because it's being monomorphized for () and inserted into the vtable, while the baz function call prints dyn playground::Foo because it's being monomorphized for the trait object type.

2 Likes
20

Wow, excellent example! You're right! baz would need to be in the vtable for this!