Looking for RFC coauthors on "named impls"

language design
2

This could be “sugar” for this:

trait Monoid<T> { .. {

struct Sum;
struct Product;

impl Monoid<Sum> for usize { .. }
impl Monoid<Product> for usize { .. }

In which case, it is sound, but - in my opinion - hard to justify as sugar when you can just do it with type parameters.

In contrast, if you are allowed to create named impls for traits which have not explicitly opted into having named impls, that is decidedly unsound. The common explanation for this is the “Hash table problem” - HashMap assumes that <usize as Hash> will resolve to the same impl in every context. If it doesn’t our HashMap is unsound.

That is to say that coherence is an invariant that unsafe code is allowed to assume. Given the same set of input types, a trait instantiation will always resolve to the same impl. If a “name” is just another input parameter, then that’s fine, but again, not more expressive than what exists today.

You could search “named impls” on this forum and find previous discussions.

7 Likes