[swift-evolution] Specify type of a delegate which conforms to a protocol

[Thorsten Seitz]

> Am 11.02.2016 um 14:56 schrieb Ross O'Brien via swift-evolution <swift-evolution at swift.org>:
> 
> Apologies.
> For the sake of clarity: I had understood the term 'intersection type' to be referring to the concept in the original post of this thread - a type which conforms to one type and all of a given collection of protocols (i.e. to be a valid value of this type an instance must conform to the intersection of all of these things), and a 'union type' to conform to one option in each series of options in a type.

That is correct. No misunderstanding there as far as I can see.


> e.g. if a type is a subclass of UIViewController and conforms to UITableViewDataSource then - according to my misunderstanding - it would be an eligible value for a variable of "intersection type" all<UIViewController, UITableViewDataSource>, whereas if it conforms to either UITableViewDataSource OR UITableViewDelegate then it would be eligible for a variable of "union type" any<UIViewController, (UITableViewDataSource | UITableViewDelegate)>.

That’s exactly my understanding, too.

See http://ceylon-lang.org/documentation/tour/types/ for details of how this works in Ceylon’s type system.


> I got confused by the terminology used in the thread (it sounded good).
> 
> So, to rephrase (hopefully) more correctly:
> I think this proposal should stick with the 'all' type: a type which inherits from at most one class and conforms to all of a specified collection of protocols.

This won’t work for a tuple:

let a: A
let b: B
let t: (A, B) = (a, b)

t[i] has type A | B, as I will either get something conforming to A or to B, depending on the value of i. It would be necessary to switch on the type to do something with it, similar to unwrapping an optional (actually optionals in Ceylon are not wrappers but type unions of the given type T with the Nil type: T | Nil).
if t[i] had type A & B this would mean that I can use any method of A and any method of B which will not work

I think you meant the third case for which I don’t have a technical term: a type containing the intersection of the methods (properties …) of A and B. That is not an intersection type as the term is used in Ceylon, but the term „intersection“ is certainly confusing here.


> 'any', intersection types, union types, and Either should be a different proposal.

Either is different from union types like Craig already explained.

-Thorsten


> On Thu, Feb 11, 2016 at 1:45 PM, Craig Cruden <ccruden at novafore.com <mailto:ccruden at novafore.com>> wrote:
> 
> > On 2016-02-11, at 20:38:21, Ross O'Brien via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > I think this proposal should stick to the intersection type: a type which inherits from at most one class (multiple inheritance should definitely be a separate proposal) if it conforms to all of one or more specified protocols.
> >
> > The next issue I'd see with the union type is that it's the already proposed Either type.
> >
> > — Ross
> 
> Actually, no the union type has not been proposed.  It has been slightly talked about in the Either type discussion.  Either was a simple implementation that could do 80% of the use cases of type unions would allow (with 1% of the work :p).
> 
> Whereas, union and intersection types are basically making changes to the type system itself — is it not?
> 
> 
> 
> 
> 
> _______________________________________________
> 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/a917a73d/attachment.html>