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

[Xiaodi Wu]

On Fri, Jan 27, 2017 at 6:55 PM, Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> 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/20170127/37ce0c90/attachment.html>