On Sun, Jun 5, 2011 at 11:10 PM, Patrick Walton <[email protected]> wrote:
> On 6/5/11 11:00 PM, Rob Arnold wrote: > >> I am sad to see anonymous records go since I use them frequently in my >> ML and JavaScript programs where giving a type a name doesn't make sense >> (perhaps if there's no type inference at function boundaries this >> doesn't matter). Tuples obviously make sense in the vector example you >> gave (which is what I usually point to as a use case for anonymous >> records) but tuples don't handle the cases where the type changes over >> time (specifically dropping fields). Also sometimes it's just awkward to >> give a name to a type; this is one my frustrations with C-like languages. >> > > Oh, I actually think anonymous records are a perfect fit for fully > type-inferred languages like ML. I miss SML's anonymous records a lot in > OCaml. It's just that in practice, every Rust record gets a name via a > typedef, since they spill across function boundaries so often and we have to > annotate function signatures. > You can write record types directly in function signatures, right? That is, can anonymous records can be used across function boundaries? I think there's good value in not having to name the type. > Your point about dropping fields is interesting; in what kinds of > situations have you wanted to drop record fields? Often it's due to refactoring. The offending field is moved up or down in the abstraction hierarchy or enclosed in a closure. Now that I've had more sleep, I also think that tuples aren't quite a good general replacement because you lose some documentation (the field name) when converting from records to tuples. Knowing what x[1] is is much harder than x.texture. This I definitely encountered in ML all the time when reading students' compilers (particularly things like the register allocation and other messy algorithmic stuff). -Rob
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
