> Per a conversation with Brendan, it occurred to us that the main > problem > may be the ugliness of the access syntax; x._0 doesn't read too > nicely. My opinion is that we should bring back tuples but that the standard way to access the elements should be destructuring let. There are a bunch of little cases where it is nice to not need to name your fields. My biggest example is when you want to use an if or a case as an expression that returns multiple values. I don't really care about ugliness of direct tuple field access; you generally shouldn't be doing it!
> We could do x[0] perhaps (with typeck ensuring that what's inside > brackets is a constant), or x#0 per Standard ML, or even special case > ".fst" and ".snd" for the first couple of elements... Standard ML does "#1 x". It's even uglier than what rust does since you probably need to parenthesize it. It's also very rarely used. #n is a function that can be used in a first class manner, and in my experience it is essentially only used when it is being passed to a higher-order function. (For example, "map #1 xs" to build up a list of the first elements of each tuple in a list of tuples.) When you want to access the elements directly, you do a let binding. I'd be perfectly happy with reintroducing lambdas and not having any way to access them other than let binding (although this is probably a minority viewpoint). In my experience, wanting to access tuple elements without let binding them out is usually a pretty good sign that you should be using a record instead. (Haskell doesn't provide any way to pull the nth element out of an arbitrary tuple other than pattern matching, although it does provide "fst" and "snd" functions in the Prelude that work on pairs.) -sully _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
