I guess that would make sense and you could wrap the callback up in a anon-closure if the module hadn't adpated the @required property so you get both compatibility, safety and clarity.
*___________________________________* *James⎥Lead Hustler* *[email protected] <[email protected]>⎥supmenow.com <http://supmenow.com>* *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 August 2016 at 17:50, Haravikk <[email protected]> wrote: > > On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > I can see the use case, but it'd be annoying (or, impossible) to work > around if I intend to call `end` by passing it to a helper function in > another (let's say, precompiled) module. There's no way for the compiler to > inspect that `end` is always called by that other module, and if calling > `end` twice causes bad things to happen, I'm totally out of luck. You'd > need a companion annotation to pass along the requirement to the callee, or > some sort of force-unrequire, but the latter can't have teeth (i.e. can't > enforce at runtime) if the closure is escaping. > On Tue, Aug 16, 2016 at 08:39 James Campbell via swift-evolution < > [email protected]> wrote: > >> It would be handy if a callback could be marked as required with an >> optional descriptive message i.e >> >> class BackgroundTask { >> func run(end: @required("You must call end otherwise iOS will penalise >> your app for being a bad citizen") () -> Void) >> } >> >> That was the developer can comunicate the bad things that can happen if >> this callback isn't called such as iOS peanlizing them for not ending a >> background task or perhaps memory leaks caused by clean up code unable to >> be triggered. >> > > Could this not just behave in the same way as @noescape, in which case you > can pass the closure on to other functions so long as they also have the > @noescape attribute? In this case passing it as a parameter to another > method with the @required attribute would be equivalent to calling it > directly (since you know the other method must eventually call it). >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
