> On 27 Jan 2017, at 22:25, Slava Pestov <[email protected]> wrote: > > >> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> So, 2 quick points: >> >> 1) I have often wanted a shorthand for expressing long tuples; I definitely >> think that’s something worth bike-shedding, e.g. - (String * 4, Int32 * 4) >> or something > > Why not define a struct, or a tuple consisting of two arrays?
Because I want a fixed-length guarantee; ([String], [Int]) could have any number of Strings or Ints. It’s just a shorthand for defining long or complex tuples; we currently import C arrays as massive tuples which can be basically impossible to read. > >> 2) Having a special non-growing array type which is called “array” and >> separate from Array<T> is not such a good idea IMO. I would rather allow >> tuples to conform to protocols (see: >> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types >> >> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types>). >> >> If tuples could conform to protocols, we could say “any tuple of homogenous >> elements is a Collection”. There would be benefits for the standard library, >> too - EmptyCollection<T> would disappear, replaced with the empty tuple (), > > This sounds too clever. Yeah… the cleverness is one of things I like about it. We get to remove these canned conformances and reduce the stdlib surface area while gaining an efficient way to express a fixed-size Collection. It would come with all kinds of supplementary benefits, such as iterating and mapping the elements of a tuple. > >> as would CollectionOfOne<T>, to be replaced by a single-element tuple (T). > > For what it’s worth, Swift doesn’t have single-element tuples. (T) is just > sugar for the type T itself. Would it be unreasonable to separate those, so that (T) is separate from T instead of being a synonym for it? There is some awkwardness with tuples due to legacy designs. Perhaps this would help clean it up a little (or perhaps make it worse, who knows?) For source compatibility, we could allow an implicit conversion; in the same way that a T can be implicitly “promoted" to an Optional<T>, it could be implicitly “promoted” to a single-element tuple of T (and vice-versa). > >> We would also be able to remove our limited-arity == overloads in favour of >> actual, honest-to-goodness Equatable conformance. > > I like this idea though. > >> >> - Karl >> >> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types>_______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
