We could require optional methods which would return T to instead return OptionalResult<T> which is essentially an enum with values 'unimplemented' and 'implemented(T)', i.e. essentially the same as Optional but as a separate type to avoid confusion when the real result would be 'T?'.
Default implementations would answer 'unimplemented'. This would require the caller to handle the unimplemented default case explicitly. -Thorsten > Am 22.04.2016 um 02:58 schrieb David Waite via swift-evolution > <[email protected]>: > > >>> 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 >> 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 > > _______________________________________________ > 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
