I think that tidies it up a lot, that would make it stick out a lot for me especially when dealing with iOS's app delegate callbacks.
*___________________________________* *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:29, Xiaodi Wu <[email protected]> wrote: > 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
