> On May 2, 2016, at 4:15 PM, Chris Lattner <[email protected]> wrote: > >> >> On May 2, 2016, at 2:48 PM, Erica Sadun <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>>> NSError bridging can also be extracted from the runtime, and the same >>>> functionality exposed as a factory initializer on NSError: >>>> >>> >>> I think that this proposal is overall really great, but what does it do to >>> the “catch let x as NSError” pattern? What is the replacement? If the >>> result is ugly, we may have to subset out NSError out of this pass, and >>> handle it specifically with improvements to the error bridging story. >> >> Grant me the serenity to accept the `NSError` I cannot change and the >> courage to change the bridging conversions I should. Grant me the wisdom to >> know the difference between a partial solution that offers a cleaner more >> predictable interface set now and a full solution that cannot be achieved in >> a reasonable timeframe. > > I’m not sure what you’re saying. > > -Chris
It's a message of support, riffing on the famous Serenity Prayer (https://en.wikipedia.org/wiki/Serenity_Prayer <https://en.wikipedia.org/wiki/Serenity_Prayer>), agreeing with you and saying that partial implementation of a good idea (limiting bridging conversions between value types and a subset of Cocoa classes) is to be preferred to a full implementation of an idea that requires extraordinary effort for one special case (NSError). -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
