[swift-evolution] [Proposal] Make optional protocol methods first class citizens
dgregor at apple.com
Mon Apr 4 11:23:53 CDT 2016
> On Apr 3, 2016, at 10:21 PM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> As the problem seems to be to eliminate having to write the extension with all its duplication, I'd prefer a more general solution instead of introducing the notion of an "optional" function: just make it possible to write default implementations inline in a protocol definition.
I think we can consider it as a given that, at some point, we’ll be able to write default implementations inline in the protocol definition. It’s not there now because we never got around to implementing it.
> Documenting the optionality can be done in the doc comment, maybe with a new documentation keyword "default". Having "optional" in the code has no additional value over a comment because the method is not optional in the Obj-C sense and the proposal requires a default value. Therefore the presence of "optional" has essentially no effect at all and is better moved into a comment.
I tend to agree. ‘optional’ and the ‘= value’ syntax are fairly heavyweight language mechanisms for what is effectively documentation.
> Am 04.04.2016 um 00:13 schrieb Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov <andrey at tarantsov.com <mailto:andrey at tarantsov.com>> wrote:
>>>> Protocol requirements with default (no-op) implementations already satisfy that design goal, no?
>>> Chris, as we've discussed in a thread that I think got forked from this one:
>>> Yes, they do technically, but it would be nice to both:
>>> 1) make it an obvious documented part of the signature, possibly including the default return value
>>> 2) possibly make it less verbose by getting rid of the explicitly spelled out protocol extension
>> Right, but “more is worse” when it comes to language design. Having a "more general" facility that greatly overlaps with a “more narrow” facility always makes us question whether it is worth the complexity to have both.
>> 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>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution