[swift-evolution] [Proposal draft] NSError bridging

Douglas Gregor dgregor at apple.com
Wed Jun 29 01:13:04 CDT 2016


> On Jun 28, 2016, at 10:31 PM, Riley Testut <rileytestut at gmail.com> 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).

Protocols don’t always have the suffix “Protocol”; it’s used when there might be confusion. The API Design Guidelines have this to say about protocols:

Protocols that describe what something is should read as nouns (e.g. Collection).

Protocols that describe a capability should be named using the suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

I think all of the names in the proposal fit into that first bullet.

	- Doug

> 
>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/1e9d77e0/attachment.html>


More information about the swift-evolution mailing list