[swift-evolution] [Pitch] Move @noescape

Félix Cloutier felixcca at yahoo.ca
Thu Mar 3 16:12:17 CST 2016


Is @autoclosure type information? To me, it feels more like a parameter attribute, so I'm happy to have it on the parameter name side.

Félix

> Le 3 mars 2016 à 17:01:41, Chris Lattner via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Chris Eidhof noticed an emergent result of removing our currying syntax: it broke some useful code using @noescape, because we only allowed it on parameter declarations, not on general things-of-function-type.  This meant that manually curried code like this:
> 
> func curriedFlatMap<A, B>(x: [A]) -> (@noescape A -> [B]) -> [B] {
>    return { f in
>        x.flatMap(f)
>    }
> }
> 
> Was rejected.  Fixing this was straight-forward (https://github.com/apple/swift/commit/c3c6beac72bc0368030f06d52c46b6444fc48dbd), but required @noescape being allowed on arbitrary function types.  Now that we have that, these two declarations are equivalent:
> 
> 	func f(@noescape fn : () -> ()) {}
> 	func f(fn : @noescape () -> ()) {}
> 
> I propose that we remove the former syntax, migrating code to the later form.  This leads to better consistency between our declarations and types, and follows the precedent of inout.  @autoclosure should also probably move as well.
> 
> Thoughts?
> 
> -Chris
> _______________________________________________
> 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/20160303/31d58223/attachment.html>


More information about the swift-evolution mailing list