[swift-evolution] Required Callback

[James Campbell]

Proposed ! https://github.com/apple/swift-evolution/pull/502

*___________________________________*

*James⎥Lead Hustler*

*james at supmenow.com <james at 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 <james at 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*
>
> *james at supmenow.com <james at 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.wu at 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.wu at 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 <james at 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*
>>>>
>>>> *james at supmenow.com <james at 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.wu at 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 <james at supmenow.com>
>>>>> wrote:
>>>>>
>>>>>> I'll write up a draft proposal :) I think we have something nice :)
>>>>>>
>>>>>> *___________________________________*
>>>>>>
>>>>>> *James⎥Lead Hustler*
>>>>>>
>>>>>> *james at supmenow.com <james at 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.wu at gmail.com> wrote:
>>>>>>
>>>>>>> Nicer still!
>>>>>>>
>>>>>>> On Tue, Aug 16, 2016 at 11:53 James Campbell <james at 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*
>>>>>>>>
>>>>>>>> *james at supmenow.com <james at 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-evolution at haravikk.me>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution <
>>>>>>>>> swift-evolution at 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 at 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).
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160816/e93f8339/attachment.html>