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

davesweeris at mac.com davesweeris at mac.com
Tue Feb 9 16:47:29 CST 2016


> On Feb 9, 2016, at 14:42, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Feb 9, 2016, at 13:52, Dave via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Feb 9, 2016, at 12:57, Chris Lattner <clattner at apple.com <mailto: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.
> 
> Types aren't just bags of operations, which means that taking the intersection of arbitrary types isn't meaningful. Similarly, generics aren't templates to be instantiated, meaning that there has to be a run-time representation of a "value of intersection type".
> 
> The constructs that carries the right meaning in Swift are protocols, and in theory you could intersect the protocols of the various types. In practice, though, the current model doesn't have a good way to actually do this, since not all protocols can be used as types of values, and finding the protocol-intersection of N types is a needless amount of extra work for the compiler anyway.
> 
> Jordan
Ah, it’s a non-starter then… Or at the very least *much* more difficult than I’d thought. Thank you :-)

- Dave Sweeris

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


More information about the swift-evolution mailing list