> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution > <[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? > 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. > 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. > 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
