What I'm trying to do is to define a trait as an API contract and use it as a marker on some types to enforce their behavior. Let's say we have this: pub trait MyContract where Self: Copy + Debug + Display + Eq + Hash {} impl MyContract for MyEnum {} This works, but it does not enforce funct…

AFAIK, the reason why traits have to be explicitly brought in scope is that nothing prevents two completely unrelated traits from providing a method with the same signature and diverging semantics, and when you do something like x.foo() the compiler has to choose or request a disambiguation. Someti…

Thanks, @HadrienG . Right, prelude technic is one way some crates get around this problem. But I'm not a big fan of it, because it hides away the naming even more than before, and is more like "copy this line and some magic will happen". Therefore, I'm hoping to avoid it.

Personally, I won't have anything more for you at the moment, but maybe someone else will. I can understand the choice of making trait methods live in isolated namespaces that have to be brought in scope, as one of the main problems with duck-typed interfaces (as in C++ templates, Python code and G…

My first thought was that traits are designed to do what you want, and you should just use them as they are designed to be used. And I still think this is your best plan with the current language, since it is how rust is designed. However, I'm wondering whether a mechanism could be added to "bundl…

[image] droundy: However, I’m wondering whether a mechanism could be added to “bundle” a few traits with a given type. Bundling in this way could only be done in the crate that defines the type itself. This would treat the methods of those crates as “in scope” for that type whenever that type …

[image] HadrienG: I can understand the choice of making trait methods live in isolated namespaces that have to be brought in scope, as one of the main problems with duck-typed interfaces (as in C++ templates, Python code and Go interfaces) is that it’s very easy to have two independently created…

Thanks, @droundy and @Ixrec , for the insights. I agree with you, and think that this could be a good addition to the language, specially along the Abstraction without overhead roadmap goal. I like to hear how @nikomatsakis feels about this. [image] droundy: My first thought was that traits are …

Well if you don't mind the redundancy you can define a foo method on the intrinsic impl as well. Just make sure it does precisely the same thing :stuck_out_tongue:

[image] behnam: I can understand the choice of making trait methods live in isolated namespaces that have to be brought in scope, as one of the main problems with duck-typed interfaces (as in C++ templates, Python code and Go interfaces) is that it’s very easy to have two independently created …

Traits as contract, without changes to call-sites

help

Nemo157 July 27, 2017, 9:38am 11

I think this could probably be covered under one current RFC: delegation of implementation. As an example I think the gist you linked may be able to implemented like this if that RFC is approved and implemented.

Topic		Replies	Views
Traits for compile-time interface checks	6	293	March 12, 2026
Crates that use the "inherent trait method" pattern	8	1987	July 19, 2019
Trait bounds limitations (generic TryFrom<T> impl). Hypothetical future impl triggers conflicting implementations error? help	12	1809	October 31, 2023
Generic traits, conflicting implementations help	18	887	November 5, 2025
Implementing rust traits without a type conflict	4	273	December 18, 2024

Traits as contract, without changes to call-sites

Related topics