[swift-evolution] [Proposal] Foundation Swift Encoders

[Zach Waldowski]

> On Mar 16, 2017, at 4:18 PM, Itai Ferber <iferber at apple.com> wrote:
> 
> Foundation’s common currency type for errors is unequivocally NSError, and we’re not looking to change that as part of this proposal.
> 
Not in Swift, where it’s unequivocally Error, and errors thrown from Foundation bridge to CocoaError. Types that conform to Error can have custom bridges both to and from NSError. I didn’t suggest breaking up Foundation’s error types as part of this proposal, merely that while all this new code is being written, it’s a little backwards to tack on new home-brewed error codes to NSCocoaErrorDomain that don’t even exist in Objective-C.
> Reusing errors from the Cocoa domain has always been a reasonable choice for 3rd-party developers, and we’d like to keep doing this.
> 
> We are looking to improve the experience of throwing such errors (with some trivial extensions) by allowing you to do something like throw CocoaError.error(.coderInvalidValue). (Of course, don’t quote me on the exact syntax, as this is totally subject to change.)
> This is pretty simple, and nets you free user-facing localization.
> 
But, again, none of the three advantages mentioned here are exclusive to errors vended through NSError.

Zach Waldowski
zach at waldowski.me
> On 15 Mar 2017, at 22:46, Zach Waldowski wrote:
> 
> 
> Just a little one that came up with when thinking over the companion proposal… see inline.
> 
>> On Mar 15, 2017, at 6:43 PM, Itai Ferber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Foundation-Provided Errors
>> 
>> Along with providing the above encoders and decoders, we would like to promote the use of a common set of error codes and messages across all new encoders and decoders. A common vocabulary of expected errors allows end-users to write code agnostic about the specific encoder/decoder implementation they are working with, whether first-party or third-party:
>> 
>> extension CocoaError.Code {
>>     public static var coderInvalidValue: CocoaError.Code
>>     public static var coderTypeMismatch: CocoaError.Code
>>     public static var coderReadCorrupt: CocoaError.Code
>>     public static var coderValueNotFound: CocoaError.Code
>> }
> 
> I find all the reasons compelling, but I don’t with the overall choice. A common vocabulary, side table info, and localization can be achieved with a dedicated error type for coders. I understand ABI (sorta) concerns are involved here, that older Foundations will continue to return the same NSError codes. However, it's never felt appropriate to create my own error instances with NSCocoaErrorDomain, and this feels very similar to that. What are our options here?
> 
> Zach Waldowski
> zach at waldowski.me <mailto:zach at waldowski.me>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170316/2981c3c7/attachment.html>