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

Agreed.

I think you bring up points that articulate well my issues with this proposal.

···

On 7 May 2016, at 10:31 AM, Greg Parker via swift-evolution <swift-evolution@swift.org> wrote:

On May 3, 2016, at 8:53 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0073: Marking closures as executing exactly once" begins now and runs through May 9. The proposal is available here:

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

"A @once parameter

It was mentioned in the discussion that the "once" behavior and @noescape look orthogonal, and the "once" behavior could be useful on closures that escape. However, it is only possible to verify that a closure has been executed exactly once if it does not escape. Because of this, "once" and @noescape are better left together."

I dislike the proposed syntax.

noescape-ness and once-ness are semantically orthogonal. The compiler's ability to verify once-ness depends on noescape and some other semantics all being present, as noted in the above quote from the proposal. The fact that the compiler is limited should not forgive the semantic transgression. Note that semantically the once-ness is the more important part for the designed usage; noescape-ness is only dragged in because of the desire to enforce once-ness at compile time. The @noescape(once) syntax is therefore backwards: the feature is not some small modification to or variation of plain @noescape.

The proposed behavior includes restrictions that are required for its designed usage but are unrelated to noescape-ness and once-ness. ("A @noescape(once) closure may only read from variables that were initialized before it was formed.") That suggests the proposed functionality should use a new higher-level name rather than being bolted on to @noescape.

--
Greg Parker gparker@apple.com Runtime Wrangler

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