Hey Chris, thanks so much for the feedback! > This is an additive proposal, thus out of scope for Swift 3.
For sure! Definitely didn’t expect this to land pre-3.0 :) > Beyond that, as someone down thread mentioned, the major thing missing here is a strong motivation for *why* we should do this. I should’ve added more color to the motivation. The idea for this proposal sparked from a conversation w/ Joe Groff <https://twitter.com/jasdev/status/751875707375120385> <https://twitter.com/jasdev/status/751875707375120385> https://twitter.com/jasdev/status/751875707375120385 <https://twitter.com/jasdev/status/751875816896786432> https://twitter.com/jasdev/status/751875816896786432 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 https://gist.github.com/Jasdev/9baeb146381cd2ba511125ab8b0e88a0 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<T, SomeOtherError>` 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`). Hope this adds some clarity! On Mon, Jul 11, 2016 at 6:43 PM Chris Lattner <[email protected]> wrote: > > On Jul 11, 2016, at 3:39 PM, Chris Lattner via swift-evolution < > [email protected]> wrote: > > > On Jul 10, 2016, at 1:33 PM, Jasdev Singh via swift-evolution < > [email protected]> wrote: > > Hey Swift Evolution! > > Drafted up a small proposal that harmonizes the use of static functions > and static function properties in appropriate protocol conformance > scenarios: > > > https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/XXXX-static-func-and-static-var-func-protocol-conformance.md > > Would love any feedback or edge cases I may have missed! > > > This is an additive proposal, thus out of scope for Swift 3. > > 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. > > > I meant: "but adding redundant ways to say the same thing is not a > motivation.” > > -Chris > > -- @jasdev
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
