On Fri, Jan 27, 2017 at 6:55 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote:
> > On 27 Jan 2017, at 22:25, Slava Pestov <spes...@apple.com> wrote: > > > On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> 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). > > 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). > What's the use case for this source-breaking change? Is `CollectionOfOne<T>` deficient in some way? > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution