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

[Thorsten Seitz]

Ceylon has intersection and union types and uses the union type for tuples which is a better fit than the intersection type IMO.

How tuples work in Ceylon and how they are used to represent function parameter lists is explained in more detail here: http://ceylon-lang.org/blog/2013/01/21/abstracting-over-functions/

It's definitely worth a read as Ceylon makes tremendous use of union and intersection types IMO.

-Thorsten 

> Am 09.02.2016 um 23:47 schrieb Dave via swift-evolution <swift-evolution at swift.org>:
> 
> 
>>> 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> wrote:
>>>> 
>>>> 
>>>> 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 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
> 
> _______________________________________________
> 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/20160211/1ce1d424/attachment.html>