I'm a Rust newbie with TypeScript background and I guess I'm trying to recreate something that would only work in TS, but I'm still curious what is the Rust way to achieve this.
Generic type parameters T: OrderType and A: Asset are tagged with the error expected trait, found enum. not a trait, and my guess is that I'm missing something fundamental here, but unfortunately I'm unable to find a satisfactory solution to my problem. All I really want is to bind generic type parameter by enum somehow, so that I have structs of specific types
I don't understand what you mean by "bind generic type parameter by enum". An enum is a type, and a generic parameter is also a type. A generic type parameter can be bounded by a trait, which results in the compiler requiring that all concrete types substituted for it implement that trait. The type itself may still be anything (that is the point of generics); it doesn't make sense to specify a concrete type as a bound for a generic type parameter.
I know some TypeScript too, but I have no idea what TS pattern this is supposed to replicate. How do you want to use this? What effect do you want it to have?
Sorry, my terminology is still wonky. Here's what I'm trying to replicate: TS playground. If I understand you correctly, the only way to constrain a generic type parameter is with a trait, and generics themselves can be any type whatsoever, which is my fundamental misunderstanding of Rust. What I'm trying to do is to have two 'substructs' of Order and three 'substructs' of Engine, but without inheritance, if this makes sense
Strictly speaking, yes, at this stage there's no point in differentiating between Engine's with different assets and Order's with transaction direction, but I just want to make my code future-proof in case I want to implement asset or order type specific behavior (which may never come up, of course) and somehow make it more explicit, but maybe I'm still wrong on this one, since explicitness may add nothing, I will still need to pattern-match against all cases possible
The point is: OrderType, Sell, and Buy are all different types. OrderType has actual information content, so it lets you choose dynamically, while Sell and Buy are marker types with no information content (they are unit types), but they can ensure that Sell and Buy orders are never contained in the same data structure.
What I think you wanted is, given an order of dynamic type (Order<OrderType>), group them into separate statically-typed containers (with element types Order<Sell> and Order<Buy>). My solution does that by matching on the type and then changing the marker type of the Order based on the runtime value of the dynamic OrderType, nothing more.