[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

davesweeris at mac.com davesweeris at mac.com
Tue Feb 9 15:52:24 CST 2016

> On Feb 9, 2016, at 12:57, Chris Lattner <clattner at apple.com> wrote:
> On Feb 9, 2016, at 11:33 AM, davesweeris at mac.com <mailto:davesweeris at mac.com> wrote:
>>> This would solve the fixed size array use-case, be much easier to implement, and not have surprising performance issues promoting things to Any.  It is also consistent with the fact that we don’t infer the type of [Int(), Float()] to [Any].
>>> -Chris
>> (Sorry to go so far back… I started replying to this on probably the 29th and somehow forgot about it.)
>> Out of curiosity, why would the subscript of non-homogeneous tuple have to return an "Any”? If we declare this:
>> let grohl = (0, “foo”, “fighters”, 0.0)
>> Why couldn’t subscript (and $0 in map, for that matter) return a type that’s the “intersection” of Int, String, and Double?
> Swift has no such intersection type.  The closes analogs we have are Any (or if you allow boxing, NSObject/NSValue).

I know. My round-about point was that, if my assumption about how that part of the compiler works is correct, it wouldn’t be hard to add the functionality. At least from the point of view of how to check if the code is correct. Admittedly, I was only thinking in terms of how one would go about extending map() to tuples. I haven’t considered the implications of allowing the “intersection” to be assigned to a variable or returned from a function, or what the syntax could/should be for interacting with such a type outside of the closure passed to map().

If it isn’t out of scope or just a non-starter, I’d like to explore the idea here (or in a different thread). Seems like it could make tuples in general, and specifically generic tuples, a lot more powerful.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160209/6e88b50f/attachment.html>

More information about the swift-evolution mailing list