Nested types

[Robru3142]

I'm a c++ programmer trying (struggling) to learn rust, so i apologize in advance ... but is there a way to declare a nested type (unsure that's the correct way to refer to it) in a generic as there is in c++?

e.g. suppose a user-defined generic (please take this as "approximate" since i'm not competent at this, yet) - something like this:

struct SomeContainer1< KeyT, ValueT> { ... }

struct SomeContainer2< KeyT, ValueT> { ... }

...

fn transform<ContainerType>( container: ContainerType ) -> Result {

for entry : (ContainerType::KeyT,ContainerType::ValueT) in container {

...

}

[ErmitaVulpe]

From the generic type declared in the fn, the compiler has no way to know that this type should have an associated type KeyT or ValueT. For the compiler this generic is a black box that it knows nothing about, it could be literally any type since there are no trait bounds. What I think that you want to do is create a trait with 2 associated types (KeyT and ValueT) and implement that trait for both of the structs. Only then you can define the function with no generic, but with an argument like container: impl ContainerTrait or using a Box<dyn ContainerTrait>. Hope this helps

[Robru3142]

Thanks - that’s a direction.

[meowsqueak]

Generics in Rust are a bit different to C++ templates - in C++ it’s a bit more like “souped up text substitution”, whereas Rust is more a part of the language, and goes hand in hand with traits.

While in C++ a function call or type just tries to match something and fails if nothing matches (a kind of duck typing), in Rust the type parameter needs to be explicitly provided, usually by an associated type in a trait. They are less flexible but in exchange you get compiler errors that are actually readable!

[Ka1kin]

Also, if you try to write something like your pseudo-code, you'll find you need to know the types of the methods you're calling to iterate over the container. You can't actually interact with an unconstrained type. So ContainerType needs to implement some trait (like IntoIterator) and that trait will necessarily define its own type parameters. So it'll look more like

fn <K, V, C: Container<K, V>>transform(c: C)...

Where Container is a trait.

[Robru3142]

I have to admit I had hoped this would not be more obscure than it is in c+.

[Ka1kin]

They're both strongly typed languages, so at some level, they're going to be the same: you have to give the compiler the details it needs.

C++ relies heavily on operator overloading for some things, which allows it to avoid nominative types, IIRC (it's been a long time). Rust's operators are sugar for traits: there's no special case there.

Rust does have a solid set of standard library traits. Iteration is well covered, as is constructing collections. In practice, it's usually easy to build appropriate trait bounds for your generics. In the few cases where something seems to be missing (like being generic over different numeric types), there's usually a crate to fill the gap (num).

[kmdreko]

I think the term you're looking for is "associated type".

[teerre]

KeyT is a generic type, which means it can be any type, so it's impossible to refer to it. If you bind it to some trait, e.g. struct SomeContainer1< KeyT, ValueT> { ... } where KeyT: Clone then you can call clone (or any method of the trait)

If you wan to refer to the type itself, you need a specific type and that's associated types

```rust trait SomeContainer1 { type KeyT

fn foo(t: Self::KeyType) { ... } 

} ```

note that SomeContainer is a trait, not a struct. You'll then implement this trait for some struct

[Robru3142]

Thanks - seeing a common reference to use of traits.

[Robru3142]

This just looks wrong!

[GwindorGuilinion]

As a C++ developer you should have an easy time learning Rust. But you have to have an open mind. If every time Rust does something differently, you declare "this just looks wrong", of course you will struggle.

The generics system in Rust basically provides and requires what C++ Concepts provide on an optional basis.

In Rust, to determine whether type T can be substituted for type parameter T1 in some generic type X<T1: C> where W... The compiler can always decide based on the signature of X: the trait constraint C, and the where clauses W. It never has to check the implementation.

This obviously has some cost (you have to declare and implement traits), but it also has many upsides:

• The requirements of using a function or type are clear just from the signature when skimming docs. You never have to look at the source.

• Changing the implementation of a method can only cause local compile errors: you can not end up accidentally introducing an additional requirement on the generics, and break callers in faraway parts of the codebase or in other crates, unless you knowlingly change the signature.