<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 Jul 10, 2016, at 1:33 PM, Jasdev Singh 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="">Hey Swift Evolution!</div><div class=""><br class=""></div>Drafted up a small proposal that harmonizes the use of static functions and static function properties in appropriate protocol conformance scenarios:<div class=""><br class=""></div><div class=""><a href="https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/XXXX-static-func-and-static-var-func-protocol-conformance.md" class="">https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/XXXX-static-func-and-static-var-func-protocol-conformance.md</a><br class=""></div><div class=""><br class=""></div><div class="">Would love any feedback or edge cases I may have missed!</div></div></div></blockquote><br class=""></div><div>This is an additive proposal, thus out of scope for Swift 3.</div><div><br class=""></div><div>Beyond that, as someone downthread mentioned, the major thing missing here is a strong motivation for *why* we should do this. You say only "we see that the protocol requirements and conformances are actually equivalent and should both be valid.” but adding redundant ways to say the same thing motivation.</div><div><br class=""></div><div>-Chris</div></body></html>