[swift-evolution] Explicit Protocol Conformance for Child Classes
Jacob Bandes-Storch
jtbandes at gmail.com
Sun Dec 13 16:16:39 CST 2015
How about reusing the keyword "required" for this? It's already used (and
has a similar meaning) for initializers.
I think NSSecureCoding is a good example of a use case.
On Sat, Dec 12, 2015 at 9:14 AM, Arthur Ariel Sabintsev via swift-evolution
<swift-evolution at swift.org> wrote:
> TL;DR: Force explicit protocol conformance of non-optional methods for
> child classes on an opt-in basis.
>
> Currently, a child class that inherits their parent class' protocol
> conformations are not explicitly required to override their parent classes
> implementation of a protocol. For example, a custom class,
> MyTableViewController, does not explicitly have to override the
> non-optional methods of the protocols (i.e., UITableViewDataSource,
> UITableViewDelegate) to which UITableViewController conforms.
>
> For many protocols, the superclass implementation of a protocol method may
> be enough. Therefore, this feature should off by default, and only enabled
> if the creator of the protocol requires it (for whatever reason). I suggest
> using a new `@abstract` attribute to designate if a protocol requires
> explicit conformance for children of a conforming parent class. This choice
> of naming for the attribute is along the lines of what other languages call
> an Abstract Class, which is what I'm trying to have added to Swift in this
> fairly long-winded post.
>
> @abstract protocol P: class {
> // All methods defined in here would need to be explicitly overridden
> by the conforming class's children.
> }
>
> If you want to have optional methods in your protocol, then using the
> @abstract attribute gets kind of messy, as you also have the @objc
> attribute.
>
> @abstract @objc protocol P: class {
> // All non-optional methods defined in here would need to be
> explicitly overridden by the conforming class's children.
> }
>
> Thoughts?
>
> Best,
>
> Arthur / Sabintsev.com <http://sabintsev.com/>
>
> _______________________________________________
> 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/20151213/2a9b61ca/attachment.html>
More information about the swift-evolution
mailing list