Proposed ! https://github.com/apple/swift-evolution/pull/502
*___________________________________* *James⎥Lead Hustler* *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>* *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 August 2016 at 20:44, James Campbell <ja...@supmenow.com> wrote: > That sounds fair, the closure that function returns could trigger a > runtime warning when it detects the closure has be deallocated without > being triggered (or even mutliple times but ofc not the focus for this > proposal) > > > > *___________________________________* > > *James⎥Lead Hustler* > > *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com > <http://supmenow.com>* > > *Sup* > > *Runway East * > > *10 Finsbury Square* > > *London* > > * EC2A 1AF * > > On 16 August 2016 at 18:39, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> One alternative that comes to mind: >> >> The @escaping stuff came with a helper function, withoutActuallyEscaping, >> to deal with attribute mismatches. Perhaps we could have the same here, for >> consistency, something like withActuallyInvoking? >> >> On Tue, Aug 16, 2016 at 12:05 Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >>> Well, the callsite @required would be what I call your escape hatch :) >>> >>> Hmm, lemme think on this... >>> On Tue, Aug 16, 2016 at 11:59 James Campbell <ja...@supmenow.com> wrote: >>> >>>> It would though, look :) : >>>> >>>> Backend.run() { requiredCallback in >>>> >>>> NonAnotatedModuled({ >>>> >>>> //We send a anon closure to the module and we call the callback with a >>>> required specifier to indicate to the compiler it will be called :) >>>> @required requiredCallback() >>>> }) >>>> } >>>> >>>> This would be the same as this: >>>> >>>> >>>> Backend.run() { requiredCallback in >>>> >>>> AnotatedModuled(requiredCallback) >>>> } >>>> >>>> And this: >>>> >>>> >>>> Backend.run() { requiredCallback in >>>> >>>> @required requiredCallback() >>>> } >>>> >>>> *___________________________________* >>>> >>>> *James⎥Lead Hustler* >>>> >>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com >>>> <http://supmenow.com>* >>>> >>>> *Sup* >>>> >>>> *Runway East * >>>> >>>> *10 Finsbury Square* >>>> >>>> *London* >>>> >>>> * EC2A 1AF * >>>> >>>> On 16 August 2016 at 17:55, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>>> >>>>> Wait, doesn't work. Your anonymous closure would then be dinged for >>>>> not satisfying the requirement. Turtles all the way down. Still need an >>>>> escape hatch. >>>>> >>>>> On Tue, Aug 16, 2016 at 11:54 James Campbell <ja...@supmenow.com> >>>>> wrote: >>>>> >>>>>> I'll write up a draft proposal :) I think we have something nice :) >>>>>> >>>>>> *___________________________________* >>>>>> >>>>>> *James⎥Lead Hustler* >>>>>> >>>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com >>>>>> <http://supmenow.com>* >>>>>> >>>>>> *Sup* >>>>>> >>>>>> *Runway East * >>>>>> >>>>>> *10 Finsbury Square* >>>>>> >>>>>> *London* >>>>>> >>>>>> * EC2A 1AF * >>>>>> >>>>>> On 16 August 2016 at 17:54, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>>>>> >>>>>>> Nicer still! >>>>>>> >>>>>>> On Tue, Aug 16, 2016 at 11:53 James Campbell <ja...@supmenow.com> >>>>>>> wrote: >>>>>>> >>>>>>>> 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* >>>>>>>> >>>>>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com >>>>>>>> <http://supmenow.com>* >>>>>>>> >>>>>>>> *Sup* >>>>>>>> >>>>>>>> *Runway East * >>>>>>>> >>>>>>>> *10 Finsbury Square* >>>>>>>> >>>>>>>> *London* >>>>>>>> >>>>>>>> * EC2A 1AF * >>>>>>>> >>>>>>>> On 16 August 2016 at 17:50, Haravikk <swift-evolut...@haravikk.me> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution < >>>>>>>>> swift-evolution@swift.org> 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 < >>>>>>>>> swift-evolution@swift.org> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution