[swift-evolution] [Discussion] Type for matching a closure

[Haravikk]

I’m a +1 for being able to detect them, a protocol would also be useful for defining methods and such on them in future.

I’m curious why you’re hoping to deny functions in your example though; there’s nothing you can really do with T without testing/casting it, in which case a default case or branch will allow functions to either fall through or throw some kind of unknown type error, e.g-

func something<T>(x:T) -> String {
    switch (x) {
        case is Int32:
            return "Int32"
        case is AnyObject:
            return "AnyObject"
        default:
            fatalError("Unexpected type")
    }
}

But yeah, either way, being able to specifically detect or require functions/closures would be nice.

> On 31 May 2016, at 11:12, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
> 
> AFAIK there isn't currently a way of matching if an Any instance is a closure:
> 
> func something<T>(x: T) -> String {
>     /// is x a function? We want to support Any (Int, Int32, Float, Double,
>     ///  AnyObject, ...), but disallow functions.
>     ...
> }
> 
> let myClosure = { print("Hello") }
> something(myClosure) // Don't allow this.
> 
> 
> I propose adding a protocol Function - all closures would conform to it. See the code on 
> 
> https://gist.github.com/charlieMonroe/655f2b5e25cc0b4ba06c0ddafa41c73b <https://gist.github.com/charlieMonroe/655f2b5e25cc0b4ba06c0ddafa41c73b>
> 
> which outlines the API and possible usage of it:
> 
> - Allowing to match a function from an Any instance.
> - Inspect the function object - arguments, captured values, return type. This may help debugging retain cycles by printing the catputred variables - you will be able to see `self` within these.
> - Invocation - creating something as NSInvocation, since you'd be able to call the function with a list of arguments.
> - This could also become a basis for some RPC in Swift.
> 
> I know this is partially something for the Reflection discussion going on here as well as something for the existentials, but since it kind of overlapses both discussions, I thought creating a new thread would perhaps be beneficial.
> 
> Charlie
> 
> _______________________________________________
> 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/20160531/c8922da4/attachment-0001.html>