<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Response inline<br><br></div><div><br>On 10 May 2016, at 8:28 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="auto" class=""><div class=""><br></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>Clean is in the eye of the beholder. I definitely don’t think the Objective-C design feels right in Swift. </div><div><br></div></div></div></blockquote><blockquote type="cite"><div><div><div>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. </div><div><br class=""></div><div>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.</div></div></div></blockquote><div><br></div>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.<div><div><div><br></div><div><blockquote type="cite"><div><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>-Matthew</div></div></div></blockquote><br></div></div></div><div>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.</div></body></html>