[swift-evolution] Checking in; more thoughts on arrays and variadic generics

[Karl Wagner]

> On 27 Jan 2017, at 22:25, Slava Pestov <spestov at apple.com> wrote:
> 
> 
>> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 <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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170128/f6c51b46/attachment.html>