[swift-evolution] Required Callback

[James Campbell]

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*

*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:29, Xiaodi Wu <xiaodi.wu at gmail.com> 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 <james at supmenow.com> 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*
>>
>> *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 15:49, Xiaodi Wu <xiaodi.wu at gmail.com> 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.
>>>>
>>>> *___________________________________*
>>>>
>>>> *James*
>>>>
>>>> *james at supmenow.com <james at supmenow.com>⎥supmenow.com
>>>> <http://supmenow.com>*
>>>>
>>>> *Sup*
>>>>
>>>> *Runway East *
>>>>
>>>> *10 Finsbury Square*
>>>>
>>>> *London*
>>>>
>>>> * EC2A 1AF *
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160816/116b9950/attachment.html>