On Jun 6, 2011, at 10:08 AM, Rob Arnold wrote: > IMHO, you only get a benefit in not having to name the type if the record > type appears exactly once. Otherwise you're scattering the record type > definition throughout the code, making it harder to e.g. add new fields if > you need to. This is why, in practice, every record in the standard library > and rustc has a typedef. > > If you get type-inferred lambdas then does this case become more common?
Would hate for us to paint into a nominal-only corner short-term, then evolve longer-term in ways that reduced the pressure for nominal-only records. > If you want the self-documenting aspect of records, then, well, use records > :) In fact, having to give each record a name arguably improves their > self-documenting nature. > > I want to avoid the case of coming up with awkward names for these types > which are local to a particular module or function. This is one pain point. The other is the flip side of "scattering the record type definition throughout the code": having to depend on the one true name. If someone does "add new fields" then in large codebases, depending on how the record is used, structural types do not require all clients to be updated. (At least not in structurally typed systems I've seen -- sorry if I'm missing something deep that restricts Rust's structural types in the long term.) That's the beauty of structural types -- programming in the large without as much brittle nominal version locking. I'm told the CLR went structural after an early and way too brittle nominal assembly typing scheme. /be
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
