[swift-evolution] Notes from Swift core team 2016-04-20 design discussion

David Waite david at alkaline-solutions.com
Thu Apr 21 19:58:49 CDT 2016

> On Apr 21, 2016, at 9:58 AM, Alex Martini via swift-evolution <swift-evolution at swift.org> wrote:

> What to do about optional requirements

> http://thread.gmane.org/gmane.comp.lang.swift.evolution/14046 <http://thread.gmane.org/gmane.comp.lang.swift.evolution/14046>
> Rename it to make it clearly an Objective-C interop feature. We could also forbid you actually spelling it in Swift code. That doesn’t work well because it breaks your ability to write code in Swift that has Objective-C clients — those clients won’t get the default implementation from the extensions like you would use with Swift clients instead of creating optional requirements.
> Modeling optional requirements as a function of optional type such as ((A, B) -> C)? doesn’t work well. For example, properties can have optional type and they can be optional requirements, so you would end up having to deal with a lot of extra complexity due to double-optionals and likely want better code completion so you could type it all out.
> You force the default implementation to be visible from all callers, and you do the dispatch at the call site. The only advantage of this is that it takes optional requirements out of the language entirely. If you wanted to implement the (somewhat common) pattern of checking whether a type implements an optional requirement, you would have to use a respondsToSelector check.
Calling an optional method on a delegate protocol and using the result to judge whether you should have some default behavior to me does seem a bit flimsy in retrospect (I originally proposed things like importing optional methods with throws and having an unimplemented method error raised by default, etc). You aren’t really trying to judge that the behavior ‘currently’ is the default, but that there is no behavior defined thus you can reliably *always* use the default.

To that end, you need some way to detect static features of a type at runtime. Today we have respondsToSelector for objc types, and checking for conformance to different protocols.

I don’t think supporting optional protocols in swift could work unless there was also a respondsToSelector equivalent for native swift types.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160421/74aaff26/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160421/74aaff26/attachment.sig>

More information about the swift-evolution mailing list