<div dir="ltr">The points made by Nate regarding his reasons for keeping the "NS" prefix for Foundation types resonated with me, but for slightly different reasons.<div><br></div><div>In particular, where Nate states "Prefix-less Foundation types will blur the different norms and expectations for Foundation types vs what we have in the Swift standard library" 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's codebase, it is helpful to immediately be able to tell where a particular type "comes from". Is this an instance of an object defined in this app's codebase, or is it a Foundation object? There are "different norms and expectations for Foundation types" in this direction as well. Forcing readers of the code to click through to the object type's definition (or perform a project-wide search) just to discover the type is Foundation, is wasteful.</div><div><br></div><div>Swift'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 "signature prefix" 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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br>
<br>
> I agree with most of the proposal except for "Strip the "NS" prefix from Foundation APIs”. I strongly disagree with this change for the same reasons as Nate:<br>
><br>
> - 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>
> - 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's what I'd propose. There aren'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>