AnyProtocol proposal

Hello,

I have been thinking about a case that is missing completely from swift.

We have the AnyObject type to represent an Object of any type.
I recently run upon a situation where i needed a type to represent any Protocol. A AnyProtocol Type would be useful for my case.

Example:

I have a generic class that needs to receive a protocol type. The code without the AnyProtocol is the following:

public class MulticastDelegate<T> {

  private var delegates = NSHashTable.weakObjectsHashTable()

  public init() {}

  public func addDelegate(delegate: T) {

    guard delegate is AnyObject else { return }

    delegates.addObject((delegate as! AnyObject))

  }
}

This code needs to “trust” that T is a protocol and also make sure T is an Object.

Example using AnyProtocol, if it existed:
public class MulticastDelegate<T:AnyProtocol> {

  private var delegates = NSHashTable.weakObjectsHashTable()

  public init() {}

  public func addDelegate(delegate: T) {

    delegates.addObject(delegate)

  }
}

Note that the protocol must be a class protocol. This could also be achieved with a where clause or AnyClassProtocol variant.

This example is also available on github: GitHub - jonasman/MulticastDelegate: An elegant multicast delegate written in swift

To extend my proposal, there might be cases where AnyStruct and AnyEnum would be usefull. I have no examples for these cases, but i believe someone might have it.
What are your thoughts, should I open a PR proposal?

João Nunes

What are the advantages of using AnyProtocol over a simple `class` constraint? To my mind, If you're already using Any or AnyObject in an interface, it seems comfortable enough with dynamic dispatch that knowing the underlying representation of the thing you've got won't do you much good.

In your specific class, my thinking is a delegate need not be a protocol only if an Object presents just a good a target for a message.

~Robert Widmann

2016/02/11 9:08、João Nunes via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

Hello,

I have been thinking about a case that is missing completely from swift.

We have the AnyObject type to represent an Object of any type.

I recently run upon a situation where i needed a type to represent any Protocol. A AnyProtocol Type would be useful for my case.

Example:

I have a generic class that needs to receive a protocol type. The code without the AnyProtocol is the following:

public class MulticastDelegate<T> {

  private var delegates = NSHashTable.weakObjectsHashTable()

  public init() {}

  public func addDelegate(delegate: T) {

    guard delegate is AnyObject else { return }

    delegates.addObject((delegate as! AnyObject))

  }

}

This code needs to “trust” that T is a protocol and also make sure T is an Object.

Example using AnyProtocol, if it existed:

public class MulticastDelegate<T:AnyProtocol> {

  private var delegates = NSHashTable.weakObjectsHashTable()

  public init() {}

  public func addDelegate(delegate: T) {

    delegates.addObject(delegate)

  }

}

Note that the protocol must be a class protocol. This could also be achieved with a where clause or AnyClassProtocol variant.

This example is also available on github: GitHub - jonasman/MulticastDelegate: An elegant multicast delegate written in swift

To extend my proposal, there might be cases where AnyStruct and AnyEnum would be usefull. I have no examples for these cases, but i believe someone might have it.

What are your thoughts, should I open a PR proposal?

João Nunes

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

In the example given. How would you restrict the generic type to a protocol without the use of AnyProtocol ?

Joao

···

Sent from my iPhone

On 11 Feb 2016, at 16:53, Developer <devteam.codafi@gmail.com> wrote:

What are the advantages of using AnyProtocol over a simple `class` constraint? To my mind, If you're already using Any or AnyObject in an interface, it seems comfortable enough with dynamic dispatch that knowing the underlying representation of the thing you've got won't do you much good.

In your specific class, my thinking is a delegate need not be a protocol only if an Object presents just a good a target for a message.

~Robert Widmann

2016/02/11 9:08、João Nunes via swift-evolution <swift-evolution@swift.org> のメッセージ:

Hello,

I have been thinking about a case that is missing completely from swift.

We have the AnyObject type to represent an Object of any type.

I recently run upon a situation where i needed a type to represent any Protocol. A AnyProtocol Type would be useful for my case.

Example:

I have a generic class that needs to receive a protocol type. The code without the AnyProtocol is the following:

public class MulticastDelegate<T> {

  private var delegates = NSHashTable.weakObjectsHashTable()

  public init() {}

  public func addDelegate(delegate: T) {

    guard delegate is AnyObject else { return }

    delegates.addObject((delegate as! AnyObject))

  }

}

This code needs to “trust” that T is a protocol and also make sure T is an Object.

Example using AnyProtocol, if it existed:

public class MulticastDelegate<T:AnyProtocol> {

  private var delegates = NSHashTable.weakObjectsHashTable()

  public init() {}

  public func addDelegate(delegate: T) {

    delegates.addObject(delegate)

  }

}

Note that the protocol must be a class protocol. This could also be achieved with a where clause or AnyClassProtocol variant.

This example is also available on github: GitHub - jonasman/MulticastDelegate: An elegant multicast delegate written in swift

To extend my proposal, there might be cases where AnyStruct and AnyEnum would be usefull. I have no examples for these cases, but i believe someone might have it.

What are your thoughts, should I open a PR proposal?

João Nunes

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

But what would you gain from restricting to just protocols? What could go wrong if someone passed in a class?

-Sune

···

On 17 Feb 2016, at 18:59, João Nunes via swift-evolution <swift-evolution@swift.org> wrote:

In the example given. How would you restrict the generic type to a protocol without the use of AnyProtocol ?

1 Like

The code is for a delegate. Thus it needs a protocol not a class.

If you use a class and not a protocol, your delegate wont be able to subclass any other class to implement the "protocol" because it is a class.

The same applies if the uitableview delegate was declared as a class. You couldn't subclass a viewcontroller and still conform to the tableview delegate protocol.

Joao

···

Sent from my iPhone

On 17 Feb 2016, at 21:12, Sune Foldager <cyano@me.com> wrote:

On 17 Feb 2016, at 18:59, João Nunes via swift-evolution <swift-evolution@swift.org> wrote:

In the example given. How would you restrict the generic type to a protocol without the use of AnyProtocol ?

But what would you gain from restricting to just protocols? What could go wrong if someone passed in a class?

-Sune

So if I understand, the goal is to restrict safe/functional behavior when it doesn’t align with the intentions of how an API was intended to be used?

-DW

···

On Feb 17, 2016, at 12:37 PM, João Nunes via swift-evolution <swift-evolution@swift.org> wrote:

The code is for a delegate. Thus it needs a protocol not a class.

If you use a class and not a protocol, your delegate wont be able to subclass any other class to implement the "protocol" because it is a class.

The same applies if the uitableview delegate was declared as a class. You couldn't subclass a viewcontroller and still conform to the tableview delegate protocol.

Joao

Sent from my iPhone

On 17 Feb 2016, at 21:12, Sune Foldager <cyano@me.com <mailto:cyano@me.com>> wrote:

On 17 Feb 2016, at 18:59, João Nunes via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

In the example given. How would you restrict the generic type to a protocol without the use of AnyProtocol ?

But what would you gain from restricting to just protocols? What could go wrong if someone passed in a class?

-Sune

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I didn’t get you 100%.
But If you are saying that the programmer is providing the API then yes.

João

···

On 17 Feb 2016, at 23:00, David Waite <david@alkaline-solutions.com> wrote:

So if I understand, the goal is to restrict safe/functional behavior when it doesn’t align with the intentions of how an API was intended to be used?

-DW

On Feb 17, 2016, at 12:37 PM, João Nunes via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The code is for a delegate. Thus it needs a protocol not a class.

If you use a class and not a protocol, your delegate wont be able to subclass any other class to implement the "protocol" because it is a class.

The same applies if the uitableview delegate was declared as a class. You couldn't subclass a viewcontroller and still conform to the tableview delegate protocol.

Joao

Sent from my iPhone

On 17 Feb 2016, at 21:12, Sune Foldager <cyano@me.com <mailto:cyano@me.com>> wrote:

On 17 Feb 2016, at 18:59, João Nunes via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

In the example given. How would you restrict the generic type to a protocol without the use of AnyProtocol ?

But what would you gain from restricting to just protocols? What could go wrong if someone passed in a class?

-Sune

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Not sure if similar ideas have been proposed later, but this would be quite a bit more useful now that we have macros.

We’ve been trying to encourage people to summarize and link to old threads from new threads rather than just posting in the old thread. I’m going to close this thread now; please feel free to start a new thread.