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.
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. -Thorsten > Am 04.04.2016 um 00:13 schrieb Chris Lattner via swift-evolution > <[email protected]>: > > >>> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
