Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On Jun 22, 2016, at 1:28 AM, Douglas Gregor wrote: > > On Jun 20, 2016, at 11:03 AM, Charles Srstka via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> It was deferred until after Swift 3.0. >> >> https://github.com/apple/swift-evolution/pull/331 >>

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Sent from my iPhone > On Jun 20, 2016, at 11:03 AM, Charles Srstka via swift-evolution > wrote: > > It was deferred until after Swift 3.0. > > https://github.com/apple/swift-evolution/pull/331 > > I plan to resubmit the proposal after Swift 3.0 comes out. Do you have any > improvements or

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Thanks, overlooked the proposal (or forgot about it)... will try to get some time to look it over. On Mon, Jun 20, 2016 at 11:03 AM Charles Srstka wrote: > It was deferred until after Swift 3.0. > > https://github.com/apple/swift-evolution/pull/331 > > I plan to resubmit the proposal after Swift

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

It was deferred until after Swift 3.0. https://github.com/apple/swift-evolution/pull/331 I plan to resubmit the proposal after Swift 3.0 comes out. Do you have any improvements or suggestions for it? Charles > On Jun 20, 2016, at 12:51 PM, S

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

I am curious on the disposition of this discussion / proposal pitch. Has any additional effort taken place since this email thread tampered off? On Sat, May 14, 2016 at 2:40 AM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On May 14, 2016, at 3:51 AM, Michael Peternell

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 14, 2016, at 3:51 AM, Michael Peternell > wrote: > > For interoperability, ErrorType and NSError should be toll-free-bridged, like > CFStringRef and NSString. Converting between them should be a no-op at > runtime. That would be technically infeasible without restricting ErrorType to

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> Am 14.05.2016 um 09:31 schrieb Charles Srstka via swift-evolution > : > > I don’t think Cocoa is going away for a very, very long time. Even if it did, > you’d still need some consistent way to turn an ErrorType into something > human-readable, and currently we don’t have that. NSError’s use

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 14, 2016, at 1:45 AM, Jon Shier via swift-evolution > wrote: > > Charles: > Foundation error reporting is based on NSError, nothing else. In none > of my apps have I used my own NSError’s and in the few frameworks I use or > maintain, few use NSError, and then only to avoid havi

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Charles: Foundation error reporting is based on NSError, nothing else. In none of my apps have I used my own NSError’s and in the few frameworks I use or maintain, few use NSError, and then only to avoid having to declare a custom error type, to make the API perhaps a bit more familiar t

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

On May 14, 2016, at 12:19 AM, Jon Shier via swift-evolution wrote: > > Charles: > I appreciate the attempt to minimize a current pain point and I agree > on most of your analysis of the current NSError bridging but I think your > proposal is fundamentally flawed. By forcing the core erro

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Charles: I appreciate the attempt to minimize a current pain point and I agree on most of your analysis of the current NSError bridging but I think your proposal is fundamentally flawed. By forcing the core error type to have properties from NSError, you’re essentially finalizing what al

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 6, 2016, at 10:16 PM, Charles Srstka wrote: > >> On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I formerly posted a less-fleshed-out version of this in the “Reducing >> bridging magic” thread, but I thought this might

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

I would support this - but I don’t feel like I have the experience yet to vet the proposal. I agree that the error handling is still something I feel like isn’t as smooth as it should be yet. I’ll try to take a longer look at this today. Thanks for the reminder. Best, Josh On May 9, 2016, at 1

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Anyone have any thoughts, opinions, etc. on this? I find it kind of strange that I’ve received off-list feedback from within Apple, but so far it’s been generally ignored publicly on the list. Surely I’m not the only one who cares about the lack of parity between NSError and ErrorProtocol. Char

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution > wrote: > > I formerly posted a less-fleshed-out version of this in the “Reducing > bridging magic” thread, but I thought this might warrant its own pitch. What > do you all think? > > MOTIVATION: > > Over the past couple of y

[swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

I formerly posted a less-fleshed-out version of this in the “Reducing bridging magic” thread, but I thought this might warrant its own pitch. What do you all think? MOTIVATION: Over the past couple of years, Swift has made great strides toward seamless interoperability with existing Objective-