> In c the callers isn’t choosing typically. The author of some library or api decides this for you.

Tbf this applies to Rust too. If the author writes

   fn foo(bar: Box<dyn BarTrait>)

they have forced the caller into dynamic dispatch.

Had they written

   fn foo(bar: impl BarTrait)

the choice would've remained open to the caller

▲ nicoburns 16 hours ago | parent [-]

Right, but almost all APIs in Rust use something like

    fn foo(bar: impl BarTrait)

and AFAIK it isn't possible to write that in C (though C++ does allow this kind of thing).

▲

bfrog 14 hours ago | parent | next [-]

C++ you either use templates or classes and virtuals. In either case the caller doesn't get to decide.

	▲	Seattle3503 3 hours ago \| parent [-]
		Interesting, there isn't some way to have a template that is polymorphic over virtuals?

▲

bsaul 14 hours ago | parent | prev [-]

how do apis typically manage to actually « use » the « bar » of your example, such as storing it somewhere, without enforcing some kind of constraints ?

▲

steveklabnik 14 hours ago | parent | next [-]

"BarTrait" is the constraint.

This is monomorphized for every type you pass in, in short.

▲

Maxatar 11 hours ago | parent | prev [-]

If you need to store the value then you have no choice but to take in a dyn trait.

▲

steveklabnik 11 hours ago | parent | next [-]

Depending on exactly what you mean, this isn't correct. This syntax is the same as <T: BarTrait>, and you can store that T in any other generic struct that's parametrized by BarTrait, for example.

	▲	marcosdumay 7 hours ago \| parent [-]
		> you can store that T in any other generic struct that's parametrized by BarTrait, for example Not really. You can store it on any struct that specializes to the same type of the value you received. If you get a pre-built struct from somewhere and try to store it there, your code won't compile.

▲

tcfhgj 11 hours ago | parent | prev [-]

sure about that?

the struct in which it is stored, could be generic as well

	▲	Maxatar 10 hours ago \| parent [-]
		I'm addressing the intent of the original question. No one would ask this question in the case where the struct is generic over a type parameter bounded by the trait, since such a design can only store a homogeneous collection of values of a single concrete type implementing the trait; the question doesn't even make sense in that situation. The question only arises for a struct that must store a heterogeneous collection of values with different concrete types implementing the trait, in which case a trait object (dyn Trait) is required.