> On Apr 21, 2016, at 9:58 AM, Alex Martini via swift-evolution > <[email protected]> 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. -DW
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
