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 > <[email protected]> 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 >> <[email protected]> wrote: >> >> >>> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution >>> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
