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

[Ross O'Brien]

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 immediate problem I see with a union type is using it. If I'm
understanding it right, this would let me define a union type of
any<UITextView, UITextField>, to a variable 'textControl'. I might then be
able to set 'textControl.text' to a value, regardless of whether it's
actually a UITextView or UITextField. But the correct way to do this would
be to create a protocol (say) 'HasTextProperty', extend UITextView and
UITextField to conform to HasTextProperty, and use that. The intersection
type would even let us extend the type safety of 'textControl' to
'all<UIView, HasTextProperty>'.

The next issue I'd see with the union type is that it's the already
proposed Either type.

-- Ross


On Thu, Feb 11, 2016 at 1:10 PM, Maximilian Hünenberger <
m.huenenberger at me.com> wrote:

> I don't see union and intersection types either in the "goals list" or in
> the "non-goals list". Either way it should be a separate proposal.
>
> - Maximilian
>
> Am 11.02.2016 um 09:29 schrieb Thorsten Seitz <tseitz42 at icloud.com>:
>
> Ceylon uses & for intersection types (and | for union types) which I find
> quite intuitive, meaning a type which conforms to this AND that
> protocol/type (OR in the case of unions).
>
> It works like expected, i.e.
> A & B & A == A & B
>
> or
> typealias A = B & C
> A & C == B & C
> A & D == B & C & D
>
> class A<T> {
>         var x: T & B
> }
>
> var a: A<C>
> a.x has type C & B
>
> var b: A<B>
> b.x has type B
>
> etc.
>
> -Thorsten
>
>
> Am 10.02.2016 um 14:59 schrieb Ross O'Brien via swift-evolution <
> swift-evolution at swift.org>:
>
> 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
>>
>
> _______________________________________________
> 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/558f2d86/attachment.html>