[swift-evolution] Default implementation for protocols

Maximilian Hünenberger m.huenenberger at me.com
Sun Jan 31 14:53:00 CST 2016


See inline

> Am 31.01.2016 um 01:48 schrieb Howard Lovatt via swift-evolution <swift-evolution at swift.org>:
> 
> Proposal
> =======
> Allow protocols to define a default implementation, e.g.:
> 
>   protocol Complex {
>     default var re: Double = 0
>     default var im: Double = 0
>     var mag: Double { return sqrt(re * re + im * im) }
>     // ...
>   }

Shouldn't there be a "default" before "var mag: Double ..."?

> 
> Which gets translated to:
> 
>   protocol Complex {
>     var re: Double { get,  set }
>     var im: Double { get, set }
>     var mag: Double { get }
>     // ...
>   }
> 
>   extension Complex {
>     var mag: Double { return sqrt(re * re + im * im) }
>     // ...
>   }
> 
>   struct _DefaultComplex: Complex { // Some private name
>     var re: Double = 0
>     var im: Double = 0
>     // ...
>   }
> 
> In use:
> 
>   let complex = Complex()
> 
> Gets translated into:
> 
>   let complex = _DefaultComplex()
> 
> 
> Motivation
> ========
>   1. You often have a default implementation for a protocol, much like a function argument might have a default value. Therefore this proposal adds convenience by saving boilerplate.
>   2. It is difficult to name a protocol if there is a natural default implementation. For example the natural name for the protocol that all integral types inherited from is Integer, but that is also the natural name for the default implementation. This tension between protocol and default implementation name leads to strange naming conventions like IntegerType for the protocol; we already know it is a type (it is a protocol after all!). This is just a form of Hungarian notation; most people find Hungarian obfuscates the code rather than clarifying.
> 
> 
> Details
> =====
>   1. Change protocols so that protocol methods are dynamically dispatched, when overridden in an extension.

That should probably be a separate proposal to make the current one more incremental.

>   2. Change protocols so that all implementations and overrides of a protocol method require the override keyword.

I would definitely love to see something like an override keyword. Although there could be confusion with method overrides in classes. Currently I'm fine with "override".

>   3. Allow protocols to directly specify an implementation as well as via an extension, also see point 1 and note dynamic dispatch.

I like the separation between "required signatures" and default implementations. The protocol body shouldn't be cluttered with implementations. Extensions also group default implementations for different type constraints.

>   4. Allow via the default keyword protocols to define properties (including stored), initialisers, and functions that are part of the default implementation of the protocol but not the protocol itself.

I'm skeptical about stored properties in protocols (multiple inheritance => diamond problem).

A "default" keyword would definitely help to distinguish between properties/methods with default implementations and the ones without them.

>   5. In the case of a default stored property the 

... ? :)

>   6. Allow the protocol name to be used to call the initialiser and in such cases use the default implementation.
> 

What will happen if not all requirements are fulfilled by default implementations? Also consider multiple inheritance.
Should there be an "init" which takes the remaining properties?

This reminds me of the "memberwise init" proposal...


Best regards
- Maximilian

> 
> -- 
>   -- Howard.
> 
> _______________________________________________
> 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/20160131/36c2e3ae/attachment.html>


More information about the swift-evolution mailing list