[swift-evolution] Yet another fixed-size array spitball session

Andrew Trick atrick at apple.com
Fri Jun 2 14:57:19 CDT 2017

> On Jun 2, 2017, at 2:20 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Static-Sized Arrays
> My preference would still be to build this from four separate features:
> 1. Magic tuple conformances: We already want to be able to automatically conform tuples to protocols like Equatable, Hashable, and Comparable. These can all be compiler magic; they don't have to be definable in userspace.
> 2. Conform tuples to Collection: The Element type should be the most specific common supertype of the tuple's elements. If all the elements are the same type, it would be that type. The Index and IndexDistance types should be Int.
> 3. Conform same-type tuples to MutableCollection: If all elements are the same type, you can also modify the values. (If their types vary in any way, however, it would not be safe to allow mutations, since you could assign the wrong type to an element.)
> 3. Add sugar for a tuple of N identical elements: Probably something like `4 * Int`, but opinions can vary.
> This solution avoids adding another structural type to the language or introducing non-type generic parameters. It also addresses other needs: 1 and 2 are desirable features in their own right which address other use cases in addition to this one. And it's nicely incremental, which is always a plus.
> -- 
> Brent Royal-Gordon
> Architechies

+1. Sounds great to me as long as the type system can handle it cleanly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170602/e5aa59ba/attachment.html>

More information about the swift-evolution mailing list