[swift-evolution] Type information containing multiple additional protocols

[Jacob Bandes-Storch]

I think this is a very useful feature of Obj-C that I've missed several
times while writing Swift code.

However, calling it "TheClass<Protocol1, Protocol2>" directly conflicts
with the syntax for specifying generic type parameters.

If we use "protocol<TheClass, Protocol1, Protocol2>" for this case, then
`protocol` stops making sense. Maybe the keyword `class` could be allowed
instead, like "class<TheClass, Protocol1, Protocol2>".

Or, it might work to omit the keyword entirely, leaving only the angle
brackets:

class C {
    weak var delegate: <UIViewController, UICollectionViewDelegate>?
}

if let task = object as? <NSManagedObject, Task> {
    task.coreDataRelatedFunction()
    task.taskRelatedFunction()
}

Jacob Bandes-Storch

On Fri, Dec 4, 2015 at 3:07 PM, Daniel Muhra <daniel.muhra at gmail.com> wrote:

> Currently it doesn’t seem possible to define a property or variable of a
> specific class that also implements one or more protocols.
> Take as an example the following definition from Objective C:
>
> NSManagedObject<NSCoding, Task>* someObject;
>
> To my knowledge, currently it is only possible to define multiple
> protocols only:
>
> var object : protocol<NSCoding, Task>
>
> However, given the first example, sometimes it is not possible to restrict
> to protocols only. This becomes especially cumbersome, if you would need to
> cast down to such a construct within a single method and perform several
> steps which would require all those type information:
>
> func doSomething(object: AnyObject) {
>     if let managedObject = object as? NSManagedObject {
>         // Do core data related stuff
>     }
>
>
>     if let task = object as? Task {
>         // Do task related stuff
>     }
> }
>
> In this case you now have managedObject and task though you operate on the
> same object. Also it is not (easily) possible to interleave actions of
> those two.
>
> My first idea here would be to introduce an Objective C like style of type
> naming. This also has the benefit, that it is perfectly clear, whether a
> type name refers to a class or a protocol (without first having to check
> it).
> The downside, of course, is that protocol type variables would become
> something like Any<MyProtocol>
>
> Any other ideas are welcome, but the initial problem still stands and
> should be addressed.
>
> _______________________________________________
> 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/20151204/9d522b94/attachment.html>