[swift-evolution] @noescape loop hole

[Félix Cloutier]

You might know already, but you can write f2 { n } instead of f2(c: { n }).

I checked my code and found that this isn't a problem over here. Inertia is the only thing that guides my opinion here, I think that I could be swayed one way or the other rather easily.

Félix

> Le 25 août 2016 à 23:58:28, Fabian Ehrentraud via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> The implemented change for closures being @noescape by default is awesome, but an important case was missed. When the closure is stored into a local variable, there currently is no way to make that variable non-escaping.
> 
> 
> class A {
> 	
> 	let n: Int = 1
> 	var cp: (() -> Int)?
> 	
> 	func f1() {
> 		// when directly constructing a new closure in the function call, the compiler knows it will be non-escaping, and no explicit `self` is needed in the closure...
> 		f2(c: { n })
> 		
> 		// ... but when storing the closure in an intermediate variable, it is not assumed as non-escaping, and explicit `self` is needed, and also we cannot prevent that it can be stored in some escaping way
> 		let c: () -> Int = {
> 			// the closure variable would need to know if it is escaping or not, as this has impact on whether the user needs to think about problems with strong capture semantics
> 			return self.n
> 		}
> 		f2(c: c)
> 		
> 		// this should actually not be allowed, unless the closure c is marked as @escaping
> 		cp = c
> 	}
> 	
> 	func f2(c: () -> Int) -> Int {
> 		return c()
> 	}
> 	
> }
> 
> 
> Is this rather a bug in the implementation of SE-0103, or a new feature request?
> 
> 
> best,
> Fabian
> _______________________________________________
> 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/20160826/5c19f3b8/attachment.html>