> On Apr 15, 2016, at 5:24 PM, Brent Royal-Gordon <[email protected]>
> wrote:
>
>> That’s the other part of my argument: if it is true that Swift code only
>> needs to conform to ObjC protocols with optional requirements, but Swift
>> code does not need to invoke optional requirements of ObjC protocols except
>> very rarely, then it’s okay for calling-an-optional-requirement not to be
>> part of the Swift language.
>
> How much of a complication is the `methodName?` behavior?
It’s a semi-complicated path through the type checker, but it’s not awful to
maintain. There’s a bit of a “fix it or remove it” issue here, because it
doesn’t work for settable properties, even though there are very few such
things.
> If you're confident that `optional` is the wrong choice for protocols
> designed in the future, perhaps you could just make it impossible to declare
> a new optional requirement in Swift, but leave the calling behavior as-is?
Sure, we can make it arbitrarily hard to use. For example, calling it
@objc_optional or similar would reinforce that it’s an Objective-C
compatibility feature rather than an intended Swift feature.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
