[swift-evolution] Modify optional method semantics for swift

[Matthew Johnson]

Sent from my iPad

> On May 9, 2016, at 5:53 PM, Rod Brown <rodney.brown6 at icloud.com> wrote:
> 
> Response inline
> 
> 
>> On 10 May 2016, at 8:28 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>> 
>> 
>>> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> The problem then becomes how do we model such optimizations in Swift. Default methods, while useful for plenty of cases, don't work with this system as there is no runtime check to see if the object actually implements that method. The optimizations don't just check the existence for a default value - they actually lead to different code paths.
>>> 
>>> Can this be done? Absolutely. Either by segregating the protocols as you mentioned, or by adding some other way to cue the optimized sizing path. That said, it's certainly not as clean as the Objective-C design.
>> 
>> Clean is in the eye of the beholder.  I definitely don’t think the Objective-C design feels right in Swift.  
>> 
>> There have been times where I implemented delegates where the row height strategy was decided at initialization time.  In Objective-C I was able to do this by implementing respondsToSelector.  That feels a bit dirty, but it works.  In pure Swift there is no way to do that at all.  
>> 
>> Swift allows a delegate protocol design to take a position on whether the initialization-time decision is supported or is a code smell that should be disallowed.  The approach of segregated protocols disallows it.  Alternative mechanisms such as a boolean getter allow for it.
> 
> I agree with this completely. By clean I was referring to the fact it's more concise, not that it's a good fit for the language. I don't think we should adopt this feature in Swift without seriously considering the implications because the nature of Swift's protocols is very different to that of Obj-C. I suspect there are better ways to model this behavior without breaking the philosophical underpinnings of Swift Protocols.
> 
>>> 
>>> In general, I think default implementations fix a lot of the simpler cases surrounding optional methods and actually simplify other implementations (no runtime checks!). But they don't solve the real value proposition that the fully dynamic Objective-C design provided in this feature.
>>> 
>>> Do I support default implementations on protocols as a concept? Definitely. But I don't think we should kid ourselves that this solves anything apart from the simpler cases.
>> 
>> I agree with this.  I think we should study the more complex cases and establish guidelines around idiomatic patterns for them in Swift.  This may even result in proposals for language enhancements to support the idioms we want to see in Swift.  But I’m glad to see “optional requirements” going away.
>> 
>> -Matthew
> 
> I don't think they're going away at this time, so much as we are clarifying what is already the case: they are an Obj-C only feature, and aren't supported in Swift standalone. They make sense and will continue to make sense in an Obj-C world, but they're not a foundational element of Swift.

Agree.  I said going away with an indefinite, likely long time frame in mind.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160509/2fc6fb44/attachment.html>