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