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

Thorsten Seitz tseitz42 at icloud.com
Thu Feb 11 02:39:31 CST 2016


Jordan, I'm not sure if I understood you correctly, do you mean to use  

    all<A, B> for intersection types (Ceylon's A & B), i.e. a type conforming to all listed types 
    any<A, B> for union types  (Ceylon's A | B), i.e. a type conforming to any of the listed types

That would be fine, too, I think, while a bit heavier than Ceylon's syntax (though I seem to remember from another thread that there was a problem with using Ceylon's syntax in Swift, though the reason escapes me at the moment).

-Thorsten 

> Am 10.02.2016 um 18:26 schrieb Jordan Rose via swift-evolution <swift-evolution at swift.org>:
> 
> 
>>> On Feb 10, 2016, at 5:00 , Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> So, I definitely think there is room for improvement hereā€¦ how about recycling the inheritance syntax?
>>> 
>>> let controller: (UIViewController, UITableViewDatasource)
>> 
>> This declares a tuple containing a UIViewController and a UITableViewDataSource.
>> 
>>> I added the braces because it would be really when you add the question mark for an optional value; an alternative for this case would be
>>> 
>>> let controller: Optional<UIViewController, UITableViewDatasource>
>> 
>> This attempts to declare an optional with two generic types, which doesn't work because Optional only has one type parameter. (But other types, like Dictionary, *do* take two type parameters.)
>> 
>> Swift does already have a syntax for declaring that a type must conform to two (or more!) protocols:
>> 
>>    let controller: protocol<UITableViewDataSource, UITableViewDelegate>
>> 
>> I think this could probably be extended to support one class type as well, perhaps with a new name:
>> 
>>    let controller: all<UIViewController, UITableViewDataSource>
> 
> We've been calling it "any" or "Any" (as in "any instance that is-a UIViewController and is-a UITableViewDataSource"), but I think this is the direction we've been talking about over here.
> 
> (Not that syntax bikeshedding can't still be useful.)
> 
> Jordan
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


More information about the swift-evolution mailing list