[swift-evolution] [Proposal draft] NSError bridging

[Charlie Monroe]

I don't have experience with AVFoundation, but looking at some docs, it's still throwing NSError, just the error codes are defined there. And NSError is the Cocoa error class.

The same way NSString may be subclassed in your own app, and you can pass it to String(cocoaString:) while it's no longer technically Cocoa. The Cocoa term is IMHO vague enough and often used to express any coding in ObjC.

String(cocoaString:) probably isn't the most precise naming either, but the alternatives are worse:

- String(objectiveCString:) - NSString is not bound to ObjC
- String(NSString:) - looks a bit weird
- String(foundationString:) - probably the most precise but most confusing.


> On Jun 29, 2016, at 6:54 PM, Michael Peternell <michael.peternell at gmx.at> wrote:
> 
> Hmm, not all NSErrors are Cocoa Errors. CustomNSError is a perfectly scoped name: CustomError would be too vague, CustomCocoaError excludes errors thrown by AVFoundation. And the intent is perfectly clear without explanation. I think a CustomCocoaError would have documentation comment that says that it can be used to customize "NSError behavior". After all, a `CustomNSError` is a custom `NSError`.
> 
> -Michael
> 
>> Am 29.06.2016 um 08:45 schrieb Charlie Monroe via swift-evolution <swift-evolution at swift.org>:
>> 
>> Perhaps it could be CustomCocoaError, having the "Cocoa" part precedence in 
>> 
>> String(cocoaString: NSString)
>> 
>> 
>>> On Jun 29, 2016, at 7:31 AM, Riley Testut via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Love the proposal overall, but not sure about the CustomNSError name either. It doesn’t seem to read like a Swift protocol name.
>>> 
>>> Somewhat related, is there a reason these protocols don’t contain the “Protocol” suffix? Stands in stark contrast with the rest of the Swift protocol naming conventions (AFAIK).
>>> 
>>>> On Jun 28, 2016, at 4:33 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>>> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> Obviously, I’m in favor of this one. +1!
>>>>> 
>>>>> I think I did prefer the older name of CustomUserInfoError for the domain/code/userInfo protocol, rather than CustomNSError. This is just because I’d like to be able to do a global search through my project for “NSError” and have it turn up empty. Maybe a silly reason, I know. ;-)
>>>> 
>>>> 
>>>> I’m floating CustomNSError as the protocol name because I don’t feel that domain, core, or userInfo are fundamental to the Swift error model—they’re about exposing things specifically to NSError.
>>>> 
>>>> 	- Doug
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>