<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Seems my mail got lost, so I'd like to add my voice to the concerns about removing the NS prefix expressed by Nate, David and others. As them I am strongly against dropping the NS prefix for types that are not Vey Swift-like meaning especially types which should be Swift value types (like an URL should be) but aren't.</div><div><br></div><div>I haven't followed the general discussion about this proposal closely except for this issue, so I won't say much about the rest of this proposal except that it did seem fine when glancing over the discussion.</div><div><br></div><div>-Thorsten </div><div><br>Am 05.02.2016 um 13:14 schrieb David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">I’d like to voice my opinion before is too late and reiterate what Nate said. Although I’m not going to add much, because Nate already said it all better than I could.</div><div class=""><br class=""></div><div class=""><div class=""><b class="">• What is your evaluation of the proposal?</b><br class=""></div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">- 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.</div><div class="">- 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…)</div><div class=""><br class=""></div><div class=""><b class="">• Is the problem being addressed significant enough to warrant a change to Swift?</b><br class=""></div><div class=""><br class=""></div><div class="">I don’t necessarily think that the problem being addressed is that significant, but the change is appreciated (except for the NS prefix). To be honest, I would have preferred more design and development effort to go towards enhancing the Swift language itself, or the emergence of a real Swift foundation framework.</div><div class=""><br class=""></div><div class=""><b class="">• Does this proposal fit well with the feel and direction of Swift?</b><br class=""></div><div class=""><br class=""></div><div class="">It does.</div><div class=""><br class=""></div><div class=""><b class="">• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b><br class=""></div><div class=""><br class=""></div><div class="">Nothing to say here.</div><div class=""><br class=""></div><div class=""><b class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b></div></div><div class=""><br class=""></div><div class="">I have kept up with the discussion since the start and have tried to keep an open mind about everybody’s opinion.</div><div class=""><br class=""></div><div class="">David.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 01 Feb 2016, at 22:10, Nate Cook via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is a concurring opinion with Drew's review, agreeing that we should reconsider removing the "NS" prefix but providing my own reasons. The proposal as a whole is exciting and far-reaching, but this particular change is misguided. My objections are:</div><div class=""><br class=""></div><div class=""><b class="">1) The change will elide the different semantic expectations for Foundation and Swift standard library types.</b></div><div class=""><br class=""></div><div class="">Prefix-less Foundation types will blur the different norms and expectations for Foundation types vs what we have in the Swift standard library, particularly in regards to value vs reference semantics of collection types. </div><div class=""><br class=""></div><div class="">The Swift standard library defines Array, Set, and Dictionary as collection types with value semantics that operate quite differently from their peers in Foundation. This change will introduce OrderedSet, CountedSet, HashTable, MapTable, and others, all of which use reference semantics and therefore don't provide the same set of guarantees about ownership and immutability.</div><div class=""><br class=""></div><div class="">As an example, the seemingly similar Set and CountedSet types produce different results from nearly identical code. Swift's Set type has value semantics, so changes to a copy don't affect the original Set instance:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span><span style="" class=""> simpleSet = </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Set</span><span style="" class="">([</span>"one"<span style="" class="">, </span>"two"<span style="" class="">, </span>"three"<span style="" class="">])</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> copiedSimpleSet = <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">simpleSet</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class="">copiedSimpleSet<span style="" class="">.</span><span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">remove</span><span style="" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"one"</span><span style="" class="">)</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class="">copiedSimpleSet<span style="" class="">.</span><span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">contains</span><span style="" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"one"</span><span style="" class="">) </span><span style="font-variant-ligatures: no-common-ligatures; color: #008400" class="">// false</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">simpleSet</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">contains</span>(<span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"one"</span>) <span style="font-variant-ligatures: no-common-ligatures; color: #008400" class="">// true</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures; color: #008400" class=""><br class=""></span></div><div class="">CountedSet (née NSCountedSet), on the other hand, uses reference semantics, so changes to a copy of an instance. This is true whether the copy is an explicit one made via assignment or the implicit copy made when calling a function with CountedSet as a parameter. This example shows how nearly code nearly identical to the above produces very different results:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span><span style="" class=""> countedSet = </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">CountedSet</span><span style="" class="">(array: [</span>"one"<span style="" class="">, </span>"two"<span style="" class="">,</span><span style="" class=""> </span>"three"<span style="" class="">])</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> copiedCountedSet = <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">countedSet</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class="">copiedCountedSet<span style="" class="">.</span><span style="font-variant-ligatures: no-common-ligatures; color: #31595d" class="">remove</span><span style="" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"one"</span><span style="" class="">)</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class="">copiedCountedSet<span style="" class="">.</span><span style="font-variant-ligatures: no-common-ligatures; color: #31595d" class="">contains</span><span style="" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"one"</span><span style="" class="">) </span><span style="font-variant-ligatures: no-common-ligatures; color: #008400" class="">// false</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class="">countedSet<span style="" class="">.</span><span style="font-variant-ligatures: no-common-ligatures; color: #31595d" class="">contains</span><span style="" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"one"</span><span style="" class="">) </span><span style="font-variant-ligatures: no-common-ligatures; color: #008400" class="">// false!</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures; color: #008400" class=""><br class=""></span></div><div class="">Collections constructed from immutable/mutable class clusters (like OrderedSet and MutableOrderedSet) pose the same problems, since you may be using a mutable instance of the "immutable" collection. We clearly are already dealing with this difference today, but eliminating the "NS" prefix implies that Foundation types are on the same level as the standard library. This makes the confusion more pronounced and significantly increases both the learning curve of the Swift & Foundation APIs and the risk of errors when using different collection types.</div><div class=""><br class=""></div><div class=""><b class="">2) The change may stifle the development of more Swift-oriented APIs.</b></div><div class=""><br class=""></div><div class="">Foundation types were developed in and for a language that uses reference semantics and subclassing, rather than value semantics and a protocol-oriented approach. The designs therefore use and reinforce norms that relate better to Objective-C than to Swift—class clusters of non-final, immutable types with mutable subclasses, immutable types with separate but related mutable counterparts, etc.</div><div class=""><br class=""></div><div class="">A Swift-native CountedSet (and other collections) would surely have value semantics built in. What about other types—do the new Calendar/Date/DateComponents types look like the system that we would design from the ground up in Swift? How about URL and URLComponents? Dropping the "NS" prefix would make it more difficult to gradually expand the standard library to encompass bridging versions of these and other common types.</div><div class=""><br class=""></div><div class=""><div class=""><b class="">3) The change will make it harder to find information about the revised APIs.</b></div></div><div class=""><b class=""><br class=""></b></div><div class="">Excellent search-ability is an unintended benefit of the "NS" prefix, and can be understood as a way that these types avoid collisions in the vast namespace-less sea of Internet search results. Searching for help with URL and Calendar will be much more difficult than their NS'ed counterparts.</div><div class=""><br class=""></div><div class="">Especially given the challenges that this proposal will pose for code sourced from tutorials, blog posts, Stack Overflow answers, etc., keeping at least the class names as sign posts seems valuable.</div><div class=""><br class=""></div><div class=""><div class=""><b class="">4) We'll still be using prefixes after the change.</b></div><div class=""><b class=""><br class=""></b></div></div><div class="">While the removal of "NS" is far-reaching, prefixes will still be a common occurrence in code written in Swift. UIKit and AppKit, along with all the various frameworks, will still retain their prefixes, so removing prefixes in the case of Foundation types will be more the exception than the norm. As such, any benefit of the removal would be mitigated by the continued use of prefixes for the rest of the first-party types we rely on.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In sum, the change would make the language and its APIs more confusing and more difficult to use today, would make it more difficult to migrate to modern designs in the future, and would ultimately provide a very minor benefit. I encourage the Swift core team to reconsider the "Strip the "NS" prefix from Foundation APIs" portion of the proposal.</div><div class=""><br class=""></div><div class="">Nate</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 30, 2016, at 5:01 PM, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I am in favor of this proposal on balance, and I leave the bulk of this to people who interop with Objective-C more often than I do.<div class=""><br class=""></div><div class="">I would like to confine my remarks to one corner where I think we are making a very serious mistake.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">The removal of the "NS" prefix for the Foundation module (or other specifically identified modules) is a mechanical translation for all global symbols defined within that module that can be performed in the Clang importer. </blockquote></div><div class=""><br class=""></div><div class="">As I understand it (and I am no Cocoa historian) the NS prefix was originally introduced because Objective-C lacks namespacing.</div><div class=""><br class=""></div><div class="">The thinking seems to be that since Swift has proper namespacing, this historicism is no longer necessary. I find this argument very flimsy.</div><div class=""><br class=""></div><div class="">Of course Swift has stronger namespacing if one's frame of reference is Objective-C or C. But for those of us coming from other language backgrounds, namespacing means something much stronger than Swift's concept of it. I don't mean to suggest that Swift's design is wrong exactly (less is sometimes more), but I do mean to say that if we propose to undo a decision that worked for several decades and break every Swift project in existence on the theory that Swift's namespacing is strong enough we had better be right.</div><div class=""><br class=""></div><div class="">For those unfamiliar, I will explain some of the namespacing tools Swift lacks relative to other languages. First, many languages have a "hierarchical" namespace system, where one can say</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">import Foundation.Net.URL</div><div class="">let s = Session(...)</div></blockquote><div class=""><br class=""></div>instead of for example<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">import Foundation</div><div class="">let s = NSURLSession(...)</div></blockquote><br class=""><div class=""><div class="">Some form of this is used in Rust, Python, and C#, as far as I know. I believe Swift has some counterfeit version of this, as the book mentions you can import a "<a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/import-declaration" class="">submodule</a>", but I do not know what that is, do not know how to make one, have never seen anyone use one, the book suggests it goes only 2 levels deep, and perhaps as a consequences of some of these problems nobody thought of using this for Foundation.</div><div class=""><br class=""></div><div class="">A closely related difference is the use of so-called "selective" imports, where we import only a single symbol (or a list of explicitly-identified symbols) into the scope. We might express this as</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class="">from Foundation.Net.URL import Session, HTTP //import two classes only</div></div></div><div class=""><div class=""><div class="">let s = Session(...)</div></div></div></blockquote><div class=""><br class=""></div>Again I think Swift technically supports some way to avoid importing a whole gigantic namespace like Foundation, but I am not aware of any actual uses of this feature, and certainly the convention is not to write code this way. Meanwhile, let's check in with the Python community, who standardized the following guidance on these "wildcard" imports as part of their language evolution process:<div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Wildcard imports ( from <module> import * ) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools. There is one defensible use case for a wildcard import...</blockquote><div class=""><div class=""><br class=""></div><div class="">When a language has a robust namespacing system, which we do not, there are many follow-on consequences. One is that an import statement is much more of a scalpel than a bludgeon; each import statement only introduces a handful of new names (even if it is a so-called "wildcard" import that grabs all children of some namespace, most of those children are themselves namespaces), unlike importing Foundation which contains thousands of direct child types that are injected into the local scope.</div><div class=""><br class=""></div><div class="">Another consequence is that class names become quite short, shadow each other, and nobody bats an eye. I searched the C# standard library for "Session", and found some 12 classes with that name:</div><div class=""><br class=""></div><div class=""><span id="cid:58295AFC-47F3-4871-AC10-B7BCD03E7980@austin.rr.com" class=""><Screen Shot 2016-01-30 at 3.44.23 PM.png></span></div><div class=""><br class=""></div><div class="">These "standard library" classes not only potentially shadow programmer-defined types, <b class="">they also shadow each other</b>. But because the C# language has a robust namespacing system, the chances of there being more than one thing called "Session" in scope in your program (or for that matter, when developing the standard library itself) is quite small, so it's a non-issue.</div><div class=""><br class=""></div><div class="">Now we return to the question of dropping the NS prefix, which will rename thousands of classes in a typical program that has `import Foundation`, in a way that potentially (let's be honest. More like "probably") shadows one or more programmer-defined classes. Our review criteria is:</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class="">Is the problem being addressed significant enough to warrant a change to Swift?</blockquote></div></div><div class=""><br class=""></div><div class="">No, the elimination of 2 characters is not significant enough of a problem to break all Swift programs, let alone to introduce literally thousands of new opportunities for shadowing.</div><div class=""><br class=""></div><div class="">To its credit, the proposal acknowledges this, and offers a concession:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Note that this removal can create conflicts with the standard library. For example, NSString and NSArray will become String and Array, respectively, and Foundation's versions will shadow the standard library's versions. In cases where the Swift 3 names of standard library entities conflict with prefix-stripped Foundation entities, we retain the NS prefix. These Foundation entities are: NSArray, NSDictionary, NSInteger, NSRange, NSSet, and NSString.</blockquote><br class=""></div><div class="">But of course this needlessly draws a distinction between NSString et al and the "normal" Foundation types, and what's more it draws that distinction based on the present composition of the Swift standard library and the present composition of Foundation. But we have already decided not to guarantee the source compatibility of the standard library, so what happens when that composition changes? Will we then go back and tweak which classes get NS prefixed to them again?</div><div class=""><br class=""></div><div class="">In my view, if Swift's namespacing is not good enough to let us drop the NS in NSString it is not good enough to drop any prefix. If we believe that a programmer will struggle to distinguish between Swift String and Foundation String then we should expect them to struggle for any two classes in any two frameworks, and this is special pleading on the part of Foundation. C#'s libraries declare *<b class="">twelve</b>* different `Session`s and nobody bats an eye, but we have two types share a name and everybody loses their minds? Our namespacing is not good enough to kill the prefix, period.</div><div class=""><br class=""></div><div class="">We should either drop these prefixes or we should not; because the claimed motivation–that we have "good enough" namespacing in the language now–is either true or it is not. This proposal admits that it is not, and tries to drop the prefixes anyway. I believe that is a mistake.</div><div class=""><br class=""></div><div class="">I certainly support the goal of eliminating these prefixes, they are ugly, they need to be killed, and namespacing is the right solution. But we must not jump out of the plane until we are very sure our parachute is in order. In Swift 3 it is not.</div><div class=""><br class=""></div><div class="">I do think the bulk of the proposal is fine, and I apologize for using quite stark language for such a small paragraph in an otherwise reasonable proposal, but I think the problem buried in here is quite serious and is being overlooked.</div><div class=""><br class=""></div><div class="">Drew</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 22, 2016, at 3:02 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">Hello Swift community,</p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">The review of SE-0005"Better Translation of Objective-C APIs Into Swift" begins now and runs through January 31, 2016. The proposal is available here:</p><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); background-color: rgb(255, 255, 255);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><font color="#777777" face="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol" size="3" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md</a></font></div></blockquote><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at</p><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; color: rgb(119, 119, 119); border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:</p><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); background-color: rgb(255, 255, 255);" class=""><p style="color: rgb(119, 119, 119); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box; margin-top: 0px; margin-bottom: 16px;" class="">Proposal link:</p><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><font color="#777777" face="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol" size="3" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md</a></font></div></blockquote><p style="color: rgb(119, 119, 119); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box; margin-top: 0px; margin-bottom: 16px;" class="">Reply text</p><blockquote style="color: rgb(119, 119, 119); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box; margin: 0px; padding: 0px 15px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class="">Other replies</div></blockquote></blockquote><h5 style="box-sizing: border-box; margin-top: 1em; margin-bottom: 16px; line-height: 1.4; font-size: 1em; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; background-color: rgb(255, 255, 255);" class=""><a id="user-content-what-goes-into-a-review-1" class="anchor" href="https://github.com/apple/swift-evolution#what-goes-into-a-review-1" aria-hidden="true" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none; display: inline-block; padding-right: 2px; margin-left: -18px; line-height: 1.1;"><span aria-hidden="true" class="octicon octicon-link" style="box-sizing: border-box; font-weight: normal; font-size: 16px; line-height: 1; font-family: octicons; display: inline-block; text-rendering: auto; -webkit-font-smoothing: antialiased; -webkit-user-select: none; vertical-align: middle; visibility: hidden;"></span></a>What goes into a review?</h5><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:</p><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class="">What is your evaluation of the proposal?</li><li style="box-sizing: border-box;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</li><li style="box-sizing: border-box;" class="">Does this proposal fit well with the feel and direction of Swift?</li><li style="box-sizing: border-box;" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li><li style="box-sizing: border-box;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">More information about the Swift evolution process is available at</p><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; color: rgb(119, 119, 119); border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/process.md" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none;" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></div></blockquote><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">Thank you,</p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">-Doug Gregor</p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">Review Manager</p></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>