Re: [swift-evolution] Required Callback

Most of the cases I can think of for @required are for clean up mechanisms triggered by the closure and as such would only need to be called once. So in theory @once may be able to cover this case, in a sense I guess you could argue @once is just a subset of @required it would check it is exactly

Re: [swift-evolution] Required Callback

In this case the @required callback is something *all* implementations should use for the mentioned reasons (memory leaks etc) just to clarify :). *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsb

Re: [swift-evolution] Required Callback

> On Aug 16, 2016, at 12:44 PM, James Campbell via swift-evolution > 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

Re: [swift-evolution] Required Callback

> On 17 Aug 2016, at 02:49, Boris Wang via swift-evolution > wrote: > > Why the callback is special ? > > The compiler should has a warning for unused parameters of function. > > I think this is enough. More works should be leaved for a lint tool. Actually I think that that kind of warning s

Re: [swift-evolution] Required Callback

​Thats true, my only concern with that is if the user disables that warning.​ *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 17 August 2016 at 02:49, Bori

Re: [swift-evolution] Required Callback

Why the callback is special ? The compiler should has a warning for unused parameters of function. I think this is enough. More works should be leaved for a lint tool. James Campbell via swift-evolution 于2016年8月17日 周三06:39写道： > ​I'm not sure about that last question, I guess someone who knows

Re: [swift-evolution] Required Callback

​I'm not sure about that last question, I guess someone who knows more about it than me could answer.​ *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 A

Re: [swift-evolution] Required Callback

@noescape is a hint that the callback will only be called once and allows compiler to optimise, we may or may not be able to combine @required functionality into that but it looks like it was rejected for now. @required is a compiler hint / sanity check to enforce that the callback is actually cal

Re: [swift-evolution] Required Callback

What are the differences between and ? application(_:handleEventsForBackgroundURLSession:completionHandler:) has an @escaping `completionHandler`, so can @r

Re: [swift-evolution] Required Callback

Proposed ! https://github.com/apple/swift-evolution/pull/502 *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 August 2016 at 20:44, James Campbell wrote

Re: [swift-evolution] Required Callback

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

Re: [swift-evolution] Required Callback

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 wrote: > Well, the c

Re: [swift-evolution] Required Callback

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 wrote: > It would though, look :) : > > Backend.run() { requiredCallback in > > NonAnotatedModuled({ > > //We send a anon closure to the module and we

Re: [swift-evolution] Required Callback

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: Bac

Re: [swift-evolution] Required Callback

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 wrote: > I'll write up a draft proposal :) I think we have something nice :) > > *

Re: [swift-evolution] Required Callback

I'll write up a draft proposal :) I think we have something nice :) *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 August 2016 at 17:54, Xiaodi Wu wro

Re: [swift-evolution] Required Callback

Nicer still! On Tue, Aug 16, 2016 at 11:53 James Campbell 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. > > *___

Re: [swift-evolution] Required Callback

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 ⎥supmenow.com

Re: [swift-evolution] Required Callback

Nice! Still need an escape hatch for when that other function isn't annotated though, for those situations when you *know* it's always going to be called and that you should never call it twice. On Tue, Aug 16, 2016 at 11:50 Haravikk wrote: > > On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolut

Re: [swift-evolution] Required Callback

> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution > 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 i

Re: [swift-evolution] Required Callback

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* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square*

Re: [swift-evolution] Required Callback

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 im

Re: [swift-evolution] Required Callback

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

Re: [swift-evolution] Required Callback

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` twi

[swift-evolution] Required Callback

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