[swift-evolution] Notes from Swift core team 2016-04-20 design discussion
tseitz42 at icloud.com
Fri Apr 22 11:01:07 CDT 2016
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.
> Am 22.04.2016 um 02:58 schrieb David Waite via swift-evolution <swift-evolution at swift.org>:
>>> 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
>> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution