[swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Douglas Gregor]

> 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.

	- Doug

> 
> -Thorsten 
> 
> 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.
>> 
>> -Chris
>> 
>> _______________________________________________
>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

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