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

Ross O'Brien narrativium+swift at gmail.com
Wed Feb 10 07:59:09 CST 2016


I agree with everything Brent just said.
My question would then be: how does this extend?

Continuing the example:
'typealias ViewControllerTableViewDataSource = all<UIViewController,
UITableViewDataSource>'

It should then be possible to have a subtype of this which also conforms to
UITableViewDelegate.
So, given the above, this would work:
'typealias ViewControllerTableViewPackage = all<UIViewController,
UITableViewDataSource, UITableViewDelegate>'.
Would this also work?
'typealias ViewControllerTableViewPackage =
all<ViewControllerTableViewDataSource, UITableViewDelegate>'
Assuming someone defined this typealias: 'typealias TableViewPackage =
protocol<UITableViewDataSource, UITableViewDelegate>', would the above also
be equivalent to this?:
'typealias ViewControllerTableViewPackage = all<UIViewController,
TableViewPackage>'

The TableViewPackage protocol, defined above, is considered by Swift to be
a 'non-nominal type'. Thus this is illegal:
'extension TableViewPackage'
(I don't know why. Perhaps a type conforming to the separate protocols has
to opt-in to the combination?)

However, we can have the following:
'extension UITableViewDelegate where Self : UITableViewDataSource'
'extension UITableViewDelegate where Self : UIViewController'
'extension UITableViewDelegate where Self : UIViewController, Self :
UITableViewDataSource'

Similarly we can't currently have this:
'extension UIViewController where Self : UITableViewDataSource,
UITableViewDelegate'
because UIViewController is not a generic type (and this is part of the
original complaint).

It would be nice to be able to write this out as: 'extension
all<UIViewController, UITableViewDataSource, UITableViewDelegate>', even if
it's just syntactic sugar for 'extension UITableViewDelegate where Self :
UIViewController, Self : UITableViewDataSource'.

-- Ross


On Wed, Feb 10, 2016 at 1:44 PM, Maximilian Hünenberger <
swift-evolution at swift.org> wrote:

> In the thread "Partially constrained protocols" we have discussed a
> similar approach using where clauses:
>
>         protocol<MyProtocol where Self: UIViewController>
>
> - Maximilian
>
> Am 10.02.2016 um 14:00 schrieb Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org>:
>
> >> 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>
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> 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/20160210/3088ef14/attachment.html>


More information about the swift-evolution mailing list