[swift-evolution] Required Callback

[James Campbell]

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/57638394/attachment.html>