[swift-evolution] @noescape loop hole

[Jordan Rose]

That’s not really a loophole, because nothing unsafe can happen because of it. It’s just a missing feature. Personally I think the added complexity from allowing non-parameter closures to be marked non-escaping makes it not worth the effort.

Jordan


> On Aug 25, 2016, at 23:58, Fabian Ehrentraud via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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