[Rejected] SE-0073: Marking closures as executing exactly once


(Chris Lattner) #1

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md

Hello Swift Community,

The review of SE-0073: "Marking closures as executing exactly once" ran from May 3…9, 2016. The proposal is *rejected* for Swift 3.

The feedback on the proposal was generally positive both from the community and core team. That said, it is being rejected for Swift 3 two reasons:

1) The surface level syntax of @noescape needs to be reconsidered. At the minimum, we need to rename @noescape to @nonescaping for consistency with our previously agreed attribute naming scheme. However, it is also work discussing whether @nonescaping should be the default: if so, the attribute should actually become @escaping, and the functionality proposed in SE-0073 would be named @once.

2) Separate from the surface level issues, the implementation underlying this work has some significant challenges that are doable but would require major engineering work. Specifically, the definite initialization pass needs to “codegen” booleans in some cases for conditional initialization/overwrite cases, and these state values would have to be added to closure capture lists. This would require enough engineering work that it seems unlikely that it would happen in the Swift 3 timeframe, and beyond that this could theoretically be subsumed into a more general system that allowed control-flow-like functions to have closures that break/continue/throw/return out of their enclosing function, or a general macro system.

Overall, everyone desires the ability to produce more control-flow like functions, but Swift 3 isn’t in a place where it can make sense to tackle this work.

Many thanks to Félix Cloutier and Gwendal Roué for driving this discussion and writing a great proposal. I hope that this topic comes back up for discussion in a future release.

-Chris Lattner
Review Manager


#2

Many thanks to the review team for their interest in the proposal!

Gwendal Roué

···

Le 12 mai 2016 à 00:44, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md

Hello Swift Community,

The review of SE-0073: "Marking closures as executing exactly once" ran from May 3…9, 2016. The proposal is *rejected* for Swift 3.

The feedback on the proposal was generally positive both from the community and core team. That said, it is being rejected for Swift 3 two reasons:

1) The surface level syntax of @noescape needs to be reconsidered. At the minimum, we need to rename @noescape to @nonescaping for consistency with our previously agreed attribute naming scheme. However, it is also work discussing whether @nonescaping should be the default: if so, the attribute should actually become @escaping, and the functionality proposed in SE-0073 would be named @once.

2) Separate from the surface level issues, the implementation underlying this work has some significant challenges that are doable but would require major engineering work. Specifically, the definite initialization pass needs to “codegen” booleans in some cases for conditional initialization/overwrite cases, and these state values would have to be added to closure capture lists. This would require enough engineering work that it seems unlikely that it would happen in the Swift 3 timeframe, and beyond that this could theoretically be subsumed into a more general system that allowed control-flow-like functions to have closures that break/continue/throw/return out of their enclosing function, or a general macro system.

Overall, everyone desires the ability to produce more control-flow like functions, but Swift 3 isn’t in a place where it can make sense to tackle this work.

Many thanks to Félix Cloutier and Gwendal Roué for driving this discussion and writing a great proposal. I hope that this topic comes back up for discussion in a future release.

-Chris Lattner
Review Manager

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