[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz]

I think an important point is that `all<>` should NOT be restricted to having only one reference or value type!

Ceylon does not have any restrictions like that. You can form the type intersection of String and Integer for example, which are both classes in Ceylon and because Ceylon like Swift only knows single inheritance between classes, the result is simply `Nothing` (the bottom type which has no elements). So there is no need to forbid this explicitly, because the types work out just fine.

Furthermore you can form type intersections between reference types which inherit from each other. The resulting intersection type is valid and is just equal to the more specific type. And of course you can form type intersections of a reference or value type with itself (i.e. all<SomeClass, SomeClass>).

Why should that be useful you may ask?

This generality is important when using intersection types with generics: let’s consider the type of a function forming the intersection of two sets with different element types:

func union<T, U>(a: Set<T>, b: Set<U>) -> Set<all<T, U>> { … }


Requiring all<T,U> to have at most one reference or value type (which must be at first position) would impose some unnecessary restrictions:

Given the following:

protocol Named {}
class Person : Named {}
class Employee : Person {}

let people: Set<Person>
let otherPeople: Set<Person>
let employees: Set<Employee>
let namedOnes: Set<Named>

// unnecessary restriction:
let x1 = union(namedOnes, people)  // not allowed, because result type contains all<Named, Person> 

// the restriction would require us to write:
let x2 = union(people, namedOnes)  // ok, result type would be Set<all<Person, Named>> which would be simplified by the compiler to Set<Named> (Ceylon does this!)

// unnecessary restriction:
let x3 = union(people, employees)   // not allowed, because result type would contain all<Person, Employee> with two reference types

// unnecessary restriction
let x4 = union(people, otherPeople)   // not allowed, because result type contains all<Person, Person> with two reference types

IMO these should all be allowed (and are possible in Ceylon). 
The result type of x1 would be Set<all<Named, Person>> which would be simplified by the compiler to Set<Named>.
The result type of x2 would be Set<all<Person, Named>> which would be simplified by the compiler to Set<Named>.
The result type of x3 would be Set<all<Person, Employee>> which would be simplified by the compiler to Set<Employee>.
The result type of x4 would be Set<all<Person, Person>> which would be simplified by the compiler to Set<Person>.

-Thorsten



> Am 14.05.2016 um 01:50 schrieb Adrian Zubarev via swift-evolution <swift-evolution at swift.org>:
> 
> If anyone is interested, I started a draft proposal with detailed design here: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-merging-types-with-protocols.md <https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-merging-types-with-protocols.md>
> 
> I didn’t post it here, because it is a bit huge and could lose its markdown formats. `all<>` is always bold, because this is what we are interested in, but I provided all possible combinations if the other formats would exists (at least all combinations I could think of, anything else is derived from these). 
> 
> `class<>` etc. can be seen as a future direction (I would say), otherwise this would easily become out of scope for Swift 3. (I will  move `class<>` etc. from detailed design to future direction later.)
> 
> I’d love to hear your feedback and strong arguments for the motivation part I could include into this proposal.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Mai 2016 bei 23:16:20, Vladimir.S (svabox at gmail.com <mailto:svabox at gmail.com>) schrieb:
> 
>> You asked for any example, I give it to you ;-) 
>> (as I said, it is syntactical, just to show that such struct<> can be used  
>> to test some struct for conforming to protocol, that was not conformed at  
>> writing time) 
>> Probably we can invent useful examples for this struct<> - but I don't  
>> believe it will be introduced in Swift ;-) 
>> 
>> On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote: 
>> > Can we really do that? I mean, I thought about that myself but I came to 
>> > the conclusion that this scenario is like: I was to lazy to couple this 
>> > structs to my library protocols, will you do that for me? 
> _______________________________________________
> 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/20160514/8a50a44d/attachment.html>