<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 28, 2016, at 10:31 PM, Riley Testut <<a href="mailto:rileytestut@gmail.com" class="">rileytestut@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Love the proposal overall, but not sure about the CustomNSError name either. It doesn’t seem to read like a Swift protocol name.<br class=""><br class="">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).<br class=""></div></div></blockquote><div><br class=""></div><div>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:</div><div><br class=""></div><div><ul style="box-sizing: border-box; margin: 1em 0px; padding: 0px 0px 0px 40px; list-style-position: initial; list-style-image: initial; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; font-size: 18px;" class=""><li style="box-sizing: border-box; margin: 0px; padding: 0px;" class=""><p id="protocols-describing-what-is-should-read-as-nouns" style="box-sizing: border-box; margin: 0px 0px 1.5em; padding: 0px;" class=""><strong style="box-sizing: border-box;" class="">Protocols that describe <em style="box-sizing: border-box;" class="">what something is</em> should read as nouns</strong> (e.g. <code class="highlighter-rouge" style="box-sizing: border-box; font-size: 14px; white-space: nowrap; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif; color: rgb(0, 0, 0); padding: 3px 8px; border: 1px solid rgb(229, 229, 229); background-color: rgb(247, 247, 247);">Collection</code>).</p></li><li style="box-sizing: border-box; margin: 0px; padding: 0px;" class=""><p id="protocols-describing-capability-should-use-suffixes" style="box-sizing: border-box; margin: 0px 0px 1.5em; padding: 0px;" class=""><strong style="box-sizing: border-box;" class="">Protocols that describe a <em style="box-sizing: border-box;" class="">capability</em> should be named using the suffixes <code class="highlighter-rouge" style="box-sizing: border-box; font-size: 1em; font-weight: normal; white-space: pre-line; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif;">able</code>, <code class="highlighter-rouge" style="box-sizing: border-box; font-size: 1em; font-weight: normal; white-space: pre-line; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif;">ible</code>, or <code class="highlighter-rouge" style="box-sizing: border-box; font-size: 1em; font-weight: normal; white-space: pre-line; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif;">ing</code></strong> (e.g. <code class="highlighter-rouge" style="box-sizing: border-box; font-size: 14px; white-space: nowrap; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif; color: rgb(0, 0, 0); padding: 3px 8px; border: 1px solid rgb(229, 229, 229); background-color: rgb(247, 247, 247);">Equatable</code>, <code class="highlighter-rouge" style="box-sizing: border-box; font-size: 14px; white-space: nowrap; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif; color: rgb(0, 0, 0); padding: 3px 8px; border: 1px solid rgb(229, 229, 229); background-color: rgb(247, 247, 247);">ProgressReporting</code>).</p></li></ul><div class="">I think all of the names in the proposal fit into that first bullet.</div></div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jun 28, 2016, at 4:33 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Obviously, I’m in favor of this one. +1!<br class=""><br class="">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. ;-)<br class=""></blockquote><br class=""><br class="">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.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></body></html>