> On Apr 3, 2016, at 10:21 PM, Thorsten Seitz via swift-evolution
> <swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>>:
>
>>
>>> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov <and...@tarantsov.com
>>> <mailto:and...@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@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
