[swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

[Jonathan Hull]

I would be in favor of some sugar allowing optional methods eventually.  I am kind of waiting to see how the reflection API shakes out.

I know there was some sort of argument on the list before about it being bad design to have optional methods, but I still really like it as a pattern.  In swift, I tend to use optional callback closures instead of delegate methods to achieve the same pattern of enabling or disabling some feature based on whether it is there or not.  For example, last week I wrote some code that lets me quickly build a table to edit data structures. When editing an array, there is an optional ‘moveCallback’ closure.  If it is there, then the rows of the table can be reordered in the UI, and if it isn’t the UI doesn’t show the reordering handles. Same with ‘deleteCallback' and whether there is UI to delete a row from the array.

I think that basing behavior based on what is possible (or not possible) due to the availability of methods is very intuitive. (But then I have been programming ObjC for almost 20 years, so that may be influencing my thinking. It probably seems strange to those coming from less dynamic languages.)

Thanks,
Jon

> On Mar 28, 2017, at 12:37 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Theoretically speaking optional could potentially become some language sugar right?
> 
> protocol P {
>     // Variable with label
>     var foo(a:) : ((Int) -> Void)? { get }
>      
>     // more sugared version
>     var foo: ((a: Int) -> Void)? { get }
> }
> 
> extension P {
>     // (1)
>     var foo: ((a: Int) -> Void)? { return nil }
> }
> 
> // Everything from above with even more sugar
> protocol P {
>     // default implementation (1) is inferred
>     optional func foo(a: Int)
> }
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170329/d0ad652d/attachment.html>