<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I'm not familiar with all of the discussions in other threads relating to this issue that some are here, so forgive me if I'm running over old ground.</div><div><br></div><div>Looking back at the original use case that David B. posted my first instinct was that this is a case that would best be solved by adding a compiler warning/error based on any function signature that matches a protocol signature but differs in the types.</div><div><br></div><div>My opinion is that naming a function that is so similar to a protocol function but clearly has a different signature is a bad idea and at least should be a warning. If Swift wants to be opinionated about it, it could become an error.</div><div><br></div><div>But looking at Vladimir's response, one thing that caught my interest was the idea of an 'implements' keyword. I think it might be a good addition to the language because it a) avoids this whole class of programming mistakes and, more importantly, b) strengthens the 'intention' of the programmer implementing the protocol, similarly to the way 'override' works for inherited functions.</div><div><br></div><div>One of the things I really like about Swift is that in many cases it requires programmers to explicitly state their intent when writing code (i.e. override). I think Vladimir's suggestion could do the same for protocols and should be considered. </div><div><br><div>Sent from my iPhone</div></div><div><br>On Sep 16, 2016, at 6:28 PM, David Beck via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Yeah, I figured it had probably come up before since I don’t follow evolution that closely, but it is, in my opinion and experience, Swift’s last pitfall. So many other pitfalls from ObjC and other languages have been solved with Swift, including this exact one (when it comes to subclassing). If we are going to say that it is a big enough problem to solve with a language feature for subclasses, it really seems like it would make sense to solve it for protocol conformance.</div><div class=""><br class=""></div>
> On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution<<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>(<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>)>wrote:<br class="">> > <br class="">> > We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.<br class="">> Numerous solutions to your objection have been proposed; you always simply dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. You can have this and support retroactive modeling; you just might need to have a separate syntax for retroactive conformances. You keep bringing that up as a hard-and-fast objection, but you know what? Maybe retroactive conformancesshouldhave a separate syntax, because they’re not saying the same thing! One is saying "here are some methods that will make this type conform to this protocol”, where the other is saying “this type already has the methods that conform to this protocol somewhere.” These are not the same thing, and it might be confusing to see a conformance declaration and assume it’s the former when it’s actually the latter, and then have trouble finding the conformances. Maybe it would actually make your code clearer if retroactive conformances were required to declare “this method exists somewhere else already.” Maybe you could even command-click on it and jump to the actual declaration. Anything would be better than the current situation, because:<br class="">> <br class="">> The reason this keeps coming up is because it’s a real problem. I myself have started taking up the practice of always using copy-and-paste to declare conformances to protocols, because otherwise the chances of mistyping something and having the bug not manifest itself until runtime is simply too high. This is not a “linter” problem; this affects basic functionality and makes protocols, honestly, really dangerous to use. For a language that bills itself as “protocol-oriented”, it’s really quite damning that its protocol support is this brittle and fragile compared to its support for traditional inheritance. I’ve been bitten by this enough times by now to somewhat regret the decision to go with a protocol-based design. This is a real shame because conceptually, the idea of Swift’s protocol-based design is really cool.<br class="">> <br class="">> Charles<br class="">> <br class="">> <br class="">> <br class="">><span class="Apple-converted-space"> </span>
<br class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; border-spacing: 0px;"><div class=""><br class="Apple-interchange-newline"><b style="font-size: 18px;" class="">David Beck</b></div><div style="font-weight: normal;" class=""><a href="http://davidbeck.co" class="">http://davidbeck.co</a></div><div style="font-weight: normal;" class=""><a href="http://twitter.com/davbeck" class="">http://twitter.com/davbeck</a></div><div style="font-weight: normal;" class=""><a href="http://facebook.com/davbeck" class="">http://facebook.com/davbeck</a></div></span></div>
</div>
<br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>