+1 ** Is the problem being addressed significant enough to warrant a change to Swift?
Yes. ** Does this proposal fit well with the feel and direction of Swift? Yes, very much so. ** If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? Python’s tuples are equatable and comparable the same way. This feels natural and useful. Rust is another example, and so is Haskell. I’m also very used to lexical ordering of tuples from my studies of mathematics, especially in the computer science branch. The proposal fails to implement full conformance to Equatable and Comparable (and Hashable), but it’s a nice short-term scratch for an annoying itch. ** How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I read the thread and deeply considered the objections for an hour or so while shopping for groceries. ** What is your evaluation of the proposal? Equatable is a no-brainer. Even Wikipedia provides the definition of tuple equality, so that’s clearly OK, I think. Tuples emphatically aren’t the same as vectors, so I think having them sortable with lexical ordering is fine, and it is very convenient. (I would go so far as to say the same of Arrays.) Tuple is something of a glue type — I use it when defining a named type would feel too verbose. As such, it is very useful to provide tuples with sensible semantics that make them usable in more places. I can also recall several instances where not having an ordering on tuples has inconvenienced me while writing Swift code. Having to spell out the comparator for the lexical order is a pain, and it is easy to get it wrong. It is a shame we cannot yet go the full way and have tuples conform to Equatable, Comparable and Hashable when their components do. The proposal presents a weaker form of this that does not allow the use of tuples as e.g. keys in a Dictionary or an ordered map type, although I often want to use tuples in these places. But at least it allows for easy sorting of arrays containing tuples, which is a step in the right direction. There is precedent in stdlib today in the form of Optional’s < overload, which is arguably too surprising (especially with string searching APIs returning Optional<Int>s). However, I don’t see a case when the tuple variant could be confusing like that. The proposal doesn’t mention the nullary tuple, but I think () should also be comparable with itself. (And Void should naturally conform to Comparable/Hashable when that becomes possible.) -- Károly _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
