<div dir="ltr"><div>Hey Chris, thanks so much for the feedback!</div><div><br></div>&gt; This is an additive proposal, thus out of scope for Swift 3.<div><br></div><div>For sure! Definitely didn’t expect this to land pre-3.0 :)</div><div><br></div><div>&gt; Beyond that, as someone down thread mentioned, the major thing missing here is a strong motivation for *why* we should do this.</div><div><br></div><div>I should’ve added more color to the motivation. The idea for this proposal sparked from a conversation w/ Joe Groff</div><div><br></div><div><a href="https://twitter.com/jasdev/status/751875707375120385"></a><a href="https://twitter.com/jasdev/status/751875707375120385"></a><a href="https://twitter.com/jasdev/status/751875707375120385">https://twitter.com/jasdev/status/751875707375120385</a><br></div><div><a href="https://twitter.com/jasdev/status/751875816896786432"></a><a href="https://twitter.com/jasdev/status/751875816896786432">https://twitter.com/jasdev/status/751875816896786432</a><br></div><div><br></div><div>I was attempting to use rdar://19091028 as a way to create protocol that can be shared across enums to guarantee the presence of a specific case. For example, imagine we wanted a series of enumerations that could wrap an `NSError` like so <a href="https://gist.github.com/Jasdev/9baeb146381cd2ba511125ab8b0e88a0">https://gist.github.com/Jasdev/9baeb146381cd2ba511125ab8b0e88a0</a></div><div><br></div><div>This could be helpful when returning a `Result` from a function that has an intermediary step that could throw an `NSError`. With such an ability, we could keep the functions return type to be `Result&lt;T, SomeOtherError&gt;` for some `T` (and `SomeOtherError` from the gist mentioned before) w/o having to make the returned error less specific (i.e. a plain `NSError`).</div><div><br></div><div>Hope this adds some clarity!</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 11, 2016 at 6:43 PM Chris Lattner &lt;<a href="mailto:clattner@apple.com">clattner@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 11, 2016, at 3:39 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 10, 2016, at 1:33 PM, Jasdev Singh via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr"><div>Hey Swift Evolution!</div><div><br></div>Drafted up a small proposal that harmonizes the use of static functions and static function properties in appropriate protocol conformance scenarios:<div><br></div><div><a href="https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/XXXX-static-func-and-static-var-func-protocol-conformance.md" target="_blank">https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/XXXX-static-func-and-static-var-func-protocol-conformance.md</a><br></div><div><br></div><div>Would love any feedback or edge cases I may have missed!</div></div></div></blockquote><br></div><div>This is an additive proposal, thus out of scope for Swift 3.</div><div><br></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 &quot;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></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>I meant: &quot;but adding redundant ways to say the same thing is not a motivation.”</div></div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div><br></div></blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">@jasdev</div></div>