4 ms·

Yeah, makes sense. I'm fortunate that my use-case doesn't have to worry about that In general, coming from TypeScript I'd like to see a lot more "duck" types i

Yeah, makes sense. I'm fortunate that my use-case doesn't have to worry about that In general, coming from TypeScript I'd like to see a lot more "duck" types in Rust that describe shapes the compiler already knows how to deal with, just placing additional constraints on what the user can do with them. Individual enum variants, but also subsets of a given enum (where the representation can still just be the same as the full enum) Along similar lines, I'd really really like "anonymous structs" (basically tuples with named members). That seems especially low-hanging since tuples already exist; it's almost just sugar I think there's a lot you could do here that would fit really neatly into Rust's existing type system, but like in the RFC above I assume it's just a matter of devs not having time to implement it all

zozbot234 4y ago
The problem then is what should happen if you define two "anonymous structs" that share some members (name and type). Most users want these to be seamlessly extensible, which amounts to full row types as seen in OCaml.
- brundolf 4y ago
  It would be nice if subset-structs worked like they do in TypeScript, but I would still be totally happy if they had to be an exact match. Subset matching would probably be the 80% complexity for the 20% benefit Now... a neat compromise could be something like this fn foo<T: { bar: i32 }>(my_struct: T) { } foo({ bar: 12, stuff: "abc" }) That would fit a lot more smoothly into Rust's type system than the automatic subset-matching would, but even then, I'd be content without it. The most basic version of anonymous structs is hardly more than sugar over tuples, it just seems like such an easy win