I wonder if we can be a little more elegant: - no need for an optional message: if the compiler is going to force you the implementor to call something, it really doesn't matter why--you just call it; any additional explanation can be given in doc comments
- at the implementation site, you the implementor would have to parrot @required in the declaration; that in itself wins some clarity (the implementor has to know it's required) - instead of allowing any assignment or reference of the callback to satisfy the requirement, either require actual invocation in the body, or allow the callback to be called/assigned/whatever with an extra attribute @invoked (or whatever the preferred bikeshed) MyModule(@invoked end) // or live dangerously: // _ = @invoked end On Tue, Aug 16, 2016 at 09:54 James Campbell <[email protected]> wrote: > > I think as long as the end callback is referenced in some way that would > still be better than what we have now, if you pass it into your own code > but then continue on to not call it then I think it would be fair for the > compiler to let you shoot yourself in the foot in that case. > > Calling end more than once is another case which isn't covered by this > proposal. > > so this: > > run() { end in > > } > > would have an error: > > but > > run() end in { > MyModule(end) > } > > would not since we have at least referenced it. > > > *___________________________________* > > *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 15:49, Xiaodi Wu <[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. >>> >>> *___________________________________* >>> >>> *James* >>> >>> *[email protected] <[email protected]>⎥supmenow.com >>> <http://supmenow.com>* >>> >>> *Sup* >>> >>> *Runway East * >>> >>> *10 Finsbury Square* >>> >>> *London* >>> >>> * EC2A 1AF * >>> _______________________________________________ >>> 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
