<div dir="ltr">The points made by Nate regarding his reasons for keeping the &quot;NS&quot; prefix for Foundation types resonated with me, but for slightly different reasons.<div><br></div><div>In particular, where Nate states &quot;Prefix-less Foundation types will blur the different norms and expectations for Foundation types vs what we have in the Swift standard library&quot; contrasting Foundation and the Swift standard library, this is very similar to my concern for being able to differentiate between Foundation and app-specific custom types.</div><div><br></div><div>When working with an app&#39;s codebase, it is helpful to immediately be able to tell where a particular type &quot;comes from&quot;. Is this an instance of an object defined in this app&#39;s codebase, or is it a Foundation object? There are &quot;different norms and expectations for Foundation types&quot; in this direction as well. Forcing readers of the code to click through to the object type&#39;s definition (or perform a project-wide search) just to discover the type is Foundation, is wasteful.</div><div><br></div><div>Swift&#39;s namespacing removes the technical requirement to prefix types as became the norm in Objective-C. But there remain understandability requirements that we should maintain.</div><div><br></div><div>Broadening the topic of prefixes beyond Foundation, it would be helpful to keep the convention of prefixing types that are designed to be used as part of a library, and leaving app-specific (or end-user-developer) types unprefixed if desired. </div><div><br></div><div>Personally I am enjoying the safety of not having to prefix custom types in my apps. But if I was writing a third-party library, I would want to use a &quot;signature prefix&quot; on my types. Similarly, the NS prefix should remain on Apple-supplied Foundation types. </div><div><br></div><div>This prefix-for-library-types convention would make it easier to quickly grasp where a particular piece of functionality in a codebase is coming from, so we can apply norms and expectations regarding the source.</div><div><br></div><div>Removing the NS prefix from Foundation types has large code understandability/readability costs with little to no benefit for app developers.<br></div><div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> <br>Regards,<br>----<br>Erwin Mazariegos<br>Austin, TX<br></div></div>
<br><div class="gmail_quote">On Fri, Feb 5, 2016 at 10:54 AM, Michel Fortin via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 5 févr. 2016 à 7:14, David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; a écrit :<br>
<br>
&gt; I agree with most of the proposal except for &quot;Strip the &quot;NS&quot; prefix from Foundation APIs”. I strongly disagree with this change for the same reasons as Nate:<br>
&gt;<br>
&gt; - This change will make Foundation types look Swift native enough to confuse some users between the stdlib’s value semantics and Foundation’s reference semantics.<br>
&gt; - The change will complicate the creation of a Swift native foundation that uses the power of Swift to provide true value semantics to types that need them (URL, Data, CountedSet, etc…)<br>
<br>
But there are also many classes that make perfect sense in Swift as a class: URLSession, Formatter, UndoManager, UserDefaults, XMLParser, Stream, NotificationCenter, RunLoop, etc. What we could do is decide now which Foundation classes should stay classes and which should become structs. Remove the NS prefix from the former, keep it for the later.<br>
<br>
Eventually, classes such as NSCountedSet and NSIndexSet will have a proper struct wrapper that will claim the non-prefixed name. But there is no urgency in making those wrappers ready for Swift 3 because the class remains available.<br>
<br>
Anyway, that&#39;s what I&#39;d propose. There aren&#39;t that many classes in Foundation; cases like this can be sorted out manually.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Michel Fortin<br>
<a href="https://michelf.ca" rel="noreferrer" target="_blank">https://michelf.ca</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</font></span></blockquote></div><br></div>