<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Since we’re moving this to a new thread, I’ll copy forward the design guidance that Chris Lattner gave us.</div><div class=""><br class=""></div><div class="">Chris wrote a wealth of far-ranging thoughts on Swift’s design philosophy. I wrote:</div><div class=""><br class=""><div class=""><div class=""><blockquote type="cite" class="" style="font-family: HelveticaNeue;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">I’ll copy and paste what Chris wrote into a “Swift philosophy” checklist for Brent’s proposal, and for any others working toward these goals. Chris, please correct me if I’m putting words in your mouth!</div><div class=""><div class=""><ul class=""><li class="">Provide a <b class="">programmer model</b> that:</li><ul class=""><li class="">is high level</li><li class="">is expressive and clean</li><li class="">is dynamic by default</li><li class="">doesn’t require a programmer to think about the fact that a static compiler is able to transparently provide great performance</li></ul></ul><ul class=""><li class="">Provide a <b class="">performance model</b> that:</li><ul class=""><li class="">is predictable</li><li class="">makes the dynamic parts of the language optimizable by a static compiler in many common cases</li><li class="">does not requiring profiling or other dynamic information</li><li class="">does not require JIT compilation</li></ul></ul></div></div></div></div></blockquote></div></div><div class="">And Chris wrote:</div><div class=""><br class=""></div><blockquote type="cite" class="">Yes, this is a good summary.<br class=""></blockquote><br class=""></div><div class="">I think that guidance from Chris could help focus this discussion.</div><div class=""><br class=""></div><div class="">I’d also like to hear more thoughts on Kevin’s proposal from a broader range of people.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class="">On Jan 4, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Didn't we already have a very long discussion about all of this?<br class=""></blockquote><br class="">We did, which ended with you and I clearly in fundamental disagreement, while others appeared to think it was a good idea. I'm now putting forth a more specific version of that proposal, one that I think is almost ready for review.<br class=""><br class=""><blockquote type="cite" class="">It's confusing, it's overloading the term `final` in a way that doesn't seem to make sense (`final` means you can't subclass or override, but there's nothing in this proposal that affects either subclassing _or_ method overriding)<br class=""></blockquote><br class="">`final` is currently restricted to the context of a class, yes. But I think it's a clean extension of the concept to use it to mark protocol extension methods that can't be overridden. Hence why I provide this re-definition of the meaning of `final`:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>`final` declares that subtypes of this type must use this specific implementation of the member, and cannot substitute their own specialized implementation. Attempting to do so causes an error.<br class=""><br class="">(Technically it's true that no protocol extension member can be overridden. But the distinction between defaulted protocol members and protocol extension members is very subtle—they are both written in protocol extensions and look identical unless you go back to the protocol definition to check what's there—and I think it needs to be called out in the text of the code.)<br class=""><br class=""><blockquote type="cite" class="">and it means protocol extensions that you aren't even aware of from other modules can cause your otherwise-legal type to start throwing errors.<br class=""></blockquote><br class=""><br class="">You can only get a conflict from something that's visible to your code. For instance, an `internal` protocol extension in another module can't cause a conflict—only public APIs can cause conflicts through imports. And it's important that they do, because it's hard to know that you didn't think the conflicting member was a defaulted protocol requirement you could override.<br class=""><br class=""><blockquote type="cite" class="">Making this kind of change only makes any sense at all if you assume that, every single time someone implements a method that happens to look the same as a method provided by a protocol extension, they're trying to override that protocol extension method. But since protocol extension methods cannot be overridden (merely shadowed), that assumption doesn't make a lot of sense.<br class=""></blockquote><br class="">I realize that this doesn't confuse you, but it seems to confuse everyone else. The core team seems to think so too, because they consider the lack of a warning about it to be a bug that can be fixed without going through the evolution process. (And I believe there's a thread currently in swift-dev where someone is working on that warning.)<br class=""><br class=""><blockquote type="cite" class="">and I think forcing people to brand their legitimate functions with a negative-sounding term "incoherent" is also basically subtly punishing people. I mean, who wants to write code that is publicly branded as being "incoherent" code?<br class=""></blockquote><br class=""><br class="">"Incoherent" is a very opinionated keyword. But I think it's also a descriptive one, which captures in a single word why you may not want to use it. I'm open to alternatives, including less judgmental alternatives.<br class=""><br class=""><blockquote type="cite" class="">Also, even after reading this proposal, it's still not obvious to me how the @incoherent attribute works. The rest is a little confusing, but this attribute is very confusing all by itself.<br class=""></blockquote><br class="">`@incoherent` basically says "I know what I'm doing, so don't emit errors about conflicts between these two types; just give me the Swift 2.1 behavior". I'm not sure why you think the current behavior is not confusing, but `@incoherent`'s behavior is very confusing.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class=""></body></html>