# Idea: trait methods with un-overridable implementations **URL:** \ **Category:** language design\ **Created:** [January 7, 2026, 9:26pm UTC](https://internals.rust-lang.org/t/idea-trait-methods-with-un-overridable-implementations/23906 "2026-01-07T21:26:16Z")\ **Posts on this page:** 1\ **Showing post:** 23
**Author:** ![quinedot](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/quinedot/32/7294_2.png) [@quinedot](https://internals.rust-lang.org/u/quinedot)\ **Post date:** [January 9, 2026, 12:08am UTC](https://internals.rust-lang.org/t/idea-trait-methods-with-un-overridable-implementations/23906/23 "2026-01-09T00:08:37Z")
The `type_name` example is related to [#57893;](https://github.com/rust-lang/rust/issues/57893) namely, always preferring the user defined method in cases of overlap breaks invocations of `.type_id()` on `dyn Any` (preferring the built-in implementation in that case is load bearing). Which is considered unfortunate as preferring the user implementation is the best fix from a soundness perspective, as I understand it.\[1\] Whatever ends up happening to fix that bug will probably involve weird exceptions no matter what. [The new trait solver already prefers the user implementation in more cases.](https://github.com/rust-lang/rust/pull/141347) If `final fn` is _always_ not in the vtable, it would basically act like preferring the user implementation. Corollary: `Any::type_id` could not be a `final fn`. * * * 1. [See this example of preferring the built-in implementation causing unsoundness.](https://github.com/rust-lang/rust/issues/57893#issuecomment-2860064425) --- _[View the full topic](https://internals.rust-lang.org/t/idea-trait-methods-with-un-overridable-implementations/23906)._