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 > <[email protected]> wrote: > > >> On May 3, 2016, at 8:53 PM, Chris Lattner via swift-evolution >> <[email protected]> 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 [email protected] Runtime Wrangler > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
