<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 8, 2016, at 9:24 AM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">```</div><div class=""><div style="font-size:13px" class="">struct InconsistentChannel {}</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">extension InconsistentChannel: Channel {</div><div style="font-size:13px" class=""> func receive() -> NSData { ... } // OK</div><div style="font-size:13px" class=""> func recieve() -> NSData { ... } // Warning: Declaration in conformance extension doesn't satisfy any requirements from 'Channel'</div><div style="font-size:13px" class=""> func doSomething() -> NSData? { ... } // Warning</div><div style="font-size:13px" class="">}</div></div><div class="">```</div><div class=""><br class=""></div>Would/Could the warning be silenced if `doSomething()` is called by one of the methods that do satisfy requirements? (I know that it is possible, is it reasonable?)</div></div></blockquote><div><br class=""></div><div>That's an interesting idea. It seems reasonable to me.</div><div><br class=""></div><div>-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">TJ<br class=""><div class=""><br class=""></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 8, 2016 at 11:34 AM, Tim Schmelter via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">If we adopt the "one extension per conformance" model, would the compiler then warn us if we include, say, helper functions that exist only to aid in that conformance (and would therefore be appropriate to include in the extension)? Wouldn't that lead to polluting the main type with those helper methods?<div class=""><br class=""></div><div class="">--T</div><div class=""><div class="h5"><div class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Mar 4, 2016 at 3:38 AM, Haravikk via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I like the idea of encouraging "one extension per conformance", though I’d maybe adjust it to simply “add conformance through extension”, as sometimes it makes sense for a single extension to add conformance to multiple protocols at a time, for example an extension to add conformance to CustomDebugStringConvertible and CustomStringConvertible as a single item. I’m not sure if you intended to prevent that, but I think it should still be possible to allow multiple protocols with the same basic concept that conformance must be exact.</div><div class=""><br class=""></div><div class="">Regarding keyword usage for implementations, I’d say that we should have the override keyword at least on methods that shadow default implementations provided for protocol methods, as this should make things clearer. It could also help to tidy up documentation as currently default implementations that have been shadowed still show up in many places, even though they’re no longer strictly relevant.</div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On 4 Mar 2016, at 00:08, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div style="word-wrap:break-word" class="">Under the umbrella of completing generics, I think we should make room for improving our diagnostics around protocol extensions. They're a well-received feature, but they introduce a lot of surprising behavior, and introduce opportunity for subtle bugs. We didn't have time to put much diagnostic work in last year, but now that users have had time to work with the feature, we have evidence of some of the more surprising and problematic behavior. Among the most common things we've seen reported:<div class=""><br class=""></div><div class="">A) When a protocol requirement has an extension implementation requirement available, we'll silently ignore when a conforming type attempts to conform to the protocol but misses, by type or spelling:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="">protocol Channel {</div><div class=""> func receive() -> NSData</div><div class="">}</div><div class="">extension Channel {</div><div class=""> func receive() -> NSData { return NSData() }</div><div class="">}</div><div class=""><br class=""></div><div class="">// Silently fails to replace the default implementation:</div><div class="">struct ClumsyChannel: Channel {</div><div class=""> // Wrong spelling</div><div class=""> func recieve() -> NSData { return NSData(bytes: "oops", length: 4) }</div><div class=""> // Wrong return type</div><div class=""> func receive() -> [UInt8] { return Array("whoopsie".utf8) }</div><div class=""> // Wrong throwiness</div><div class=""> func receive() throws -> NSData { throw "doh" }</div><div class="">}</div><div class=""><br class=""></div></blockquote>B) Protocol requirements aren't real class members, and can't be overridden by subclasses unless the base class satisfies the requirement with one of its own methods rather than with a protocol extension method, but we silently allow subclasses to shadow:<div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="">class BaseChannel: Channel { } // gets default imp from extension</div><div class=""><br class=""></div><div class="">class SubChannel: BaseChannel {</div><div class=""> // Doesn't 'override' protocol requirement; silently shadows it</div><div class=""> func receive() -> NSData { return NSData(bytes: "oof", length: 3) }</div><div class="">}</div><div class=""><br class=""></div></blockquote>C) Similarly, protocol extension methods aren't protocol requirements, so extension methods that don't match a requirement can't be specialized in a way available to generic code, but we silently allow concrete type implementations to shadow:<div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="">extension Channel {</div><div class=""> func receiveAsString() -> String {</div><div class=""> return String(data: receive(), encoding: NSUTF8Encoding)</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">struct StringyChannel {</div><div class=""> func receive() -> NSData { return NSData(bytes: "data", 4) }</div><div class=""> // Does not affect generic code calling receiveAsString</div><div class=""> func receiveAsString() -> String { return "string" }</div><div class="">}</div><div class=""><br class=""></div><div class="">func foo<T: Channel>(chan: T) {</div><div class=""> print(chan.receiveAsString())</div><div class="">}</div><div class=""><br class=""></div><div class="">foo(StringyChannel()) // Prints "data"</div><div class=""><br class=""></div></blockquote>(B) and (C) could be mitigated by shadowing warnings, and we've also floated ideas for making them behave as intended, by implicitly forwarding protocol requirements into class methods to address (B) and/or introducing dynamic dispatch for protocol extensions to address (C). (A) is a bit trickier, since with overloading it's tricky to divine whether a declaration was really intended to match another one with a different type in isolation. We've discussed a couple approaches to this problem:<div class=""><br class=""></div><div class="">- Adopting an explicit 'implements' modifier, in the spirit of 'override', to mark a declaration as being intended to fulfill a requirement. This adds boilerplate we'd like to avoid, and also interferes with retroactive modeling.</div><div class="">- Encourage "one extension per conformance" style, where each protocol conformance's requirements are defined in a dedicated extension. We can then warn about any declarations in an extension that don't satisfy a requirement:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="">struct InconsistentChannel {}</div><div class=""><br class=""></div><div class="">extension InconsistentChannel: Channel {</div><div class=""> func receive() -> NSData { ... } // OK</div><div class=""> func recieve() -> NSData { ... } // Warning: Declaration in conformance extension doesn't satisfy any requirements from 'Channel'</div><div class=""> func receive() -> NSData? { ... } // Warning</div><div class="">}</div><div class=""><br class=""></div></blockquote>There are likely others too. It'd be great if we could give users better guidance about this feature.<div class=""><br class=""></div><div class="">-Joe</div></div></div></div><span class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class=""></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div></div></div></div>
<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="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<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=""></div></blockquote></div><br class=""></body></html>