<div dir="ltr">And likewise! I hope we can continue to work together to make Swift more dynamic, expressive, and useful in the months and years going forward :).<div><br></div><div>Best,</div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 10:33 AM, Goffredo Marocchi <span dir="ltr"><<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>Thank you for the long reply, I do agree that I could have been more constructive and what I said could have been more on point with the thread at hand and better argued. I do like a complete and well written rebuttal, chance for me to learn from it :). <br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 5:14 PM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Aug 3, 2017 at 8:13 AM, Goffredo Marocchi <span dir="ltr"><<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Because what is the current idiomatic Swift of today may not be the Swift of tomorrow if people are allowed to keep shaping it as it gets used in the real world. Ideas can be imported from other languages and today's ideas and philosophy are not dogmas.</div></div></div></blockquote><div><br></div></span><div>The problem I see with your email is that it does not contribute anything to the discussion.</div><div><br></div><div>- We _know_ Swift has an expressivity problem compared to Objective-C, many people have made this point loud and clear.</div><div>- There are no useful concrete proposals or suggestions of design directions expressed in this email besides the rehashing of a point that has been made ad nauseaum on these lists, especially in places more appropriate for it (e.g. in proposal reviews that involved strengthening the type system).</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Swift does value expressiveness, see the use of argument labels which is
perhaps more pervasive than it was in Objective-C (even more before the
change in argument labels that hit closures and callbacks).</div></div></div></blockquote><div><br></div></span><div>Here is the crux of my disagreement with your email.</div><div><br></div><div>Method naming conventions and static typing can be adjusted nearly independently of one another, and bringing up the latter in a discussion about the former is _not helpful_.</div><div><br></div><div>You could remove Swift's type system tomorrow and still improve how methods are named. In fact, Swift's current naming conventions are quite suited for a dynamic language. You could also strengthen Swift's type system and improve method naming conventions. The two do not march in lockstep. "Expressiveness" is a huge, vague, and wide-reaching topic. Claiming that static typing is an expressiveness concern and therefore that complaining about it in a thread that deals with an almost completely unrelated feature strikes me as disingenuous. Help me out here.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div> </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div> </div><div><br></div>I do not want to add noise to useful discussions so please do not assume the worst in my statements, but I also do not think that the idea of "if you do not like <a>, go back to your <insert expletive> country" has merit or is helpful to the evolution of the language.<br></div></div></blockquote><div><br></div></span><div>Please.</div><div><br></div><div>The issue at hand is not "go back to your country", it is "use the right tool for the job at hand".</div><div><br></div><div>Engineering, like every field of human endeavor, has political elements, but it is not itself a fundamentally political endeavor. This gross anthropomorphization is beneath both you and I, and is better avoided for the happiness of all.</div><div><br></div><div>As for contributing to the evolution of the language, your post is not the first of its quality, specific form, and sentiment that I've seen on the list, but only the first that I've been moved to respond to. So if I can steer future discussion in a more productive direction, I will consider this email chain to be a net positive, even if I have to send out quite a few more of these emails in reply :).</div><div> </div><div>With the utmost respect,</div><div>Austin</div><div><div class="m_-1587874679186290360h5"><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><div class="m_-1587874679186290360m_2496032212908584109HOEnZb"><div class="m_-1587874679186290360m_2496032212908584109h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 3:16 PM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">If you want to use Objective-C you're free to use Objective-C, or more generally any of the wonderful languages that choose a different tradeoff regarding convenience over expressiveness. Otherwise, I'm not really sure what productive forward movement bringing up complaints about a fundamental philosophical underpinning of Swift that's not realistically going to change is supposed to achieve. As was mentioned in a message earlier this week, swift-evolution is a list to discuss making changes to the Swift language, not a list for ranting about things in Swift you don't like but cannot change.<div><br></div><div>Regards,</div><div>Austin</div><div><div class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697h5"><div><br></div><div><div><blockquote type="cite"><div>On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-interchange-newline">Sent from my iPhone</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div><blockquote type="cite"><div>On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div dir="auto">Brent had a draft proposal to revise the names of collection methods to improve the situation here. There is room for improvement.</div></div></div></div></blockquote><br></div><div>It didn't change `remove(at:)`, though. (Well, it might have affected its return value or something, I don't remember.) It mostly addressed the `dropLast()`, `prefix(_:)` etc. calls.</div><div><br></div><div>To respond to the original post:</div><div><br></div><div>Some of the APIs you cite are not very well named, but I think your diagnosis is incorrect and so your prescription isn't going to help.</div><div><br></div><div><div style="font-family:HelveticaNeue"></div><blockquote type="cite"><div style="font-family:HelveticaNeue">The reason for this is, whenever a preposition is used in English, it almost always takes a dyadic form, relating a subject to the preposition's object. The two most common dyadic formats are:</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue"><b><subject> [<preposition> <object of preposition>]</b></div><div style="font-family:HelveticaNeue"><The boy> [<with> <the dog>] crossed the street. </div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue"><b>[<preposition> <</b><b> object of preposition</b><b>>] <subject></b></div><div style="font-family:HelveticaNeue">[<In> <space>], <no one> can hear you scream.</div><div style="font-family:HelveticaNeue">[<On> <the Moon>] are <many craters>.</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">Now, in Objective C through Swift 1 and 2, prepositions' dyadic nature were generally respected in method signatures. However, Swift 3's migration of the preposition inside the parentheses also seems to have been accompanied by the stripping away of either the subject, the prepositional object, or both—according to no discernible pattern. For example: </div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">(1) CloudKit:</div><div style="font-family:HelveticaNeue"><br></div><blockquote style="font-family:HelveticaNeue;margin:0px 0px 0px 40px;border:none;padding:0px"><div>old: myCKDatabase.fetchRecordW<wbr>ithID(recordID)</div><div>new: myCKDatabase.fetch(withRecordI<wbr>D: recordID)</div><div><b>(subject "Record" got removed)</b></div></blockquote><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">(2) String:</div><div style="font-family:HelveticaNeue"><br></div><blockquote style="font-family:HelveticaNeue;margin:0px 0px 0px 40px;border:none;padding:0px"><div>old: myString.capitalizedStringWith<wbr>Locale(_: myLocale)</div><div>new: myString.capitalized(with: myLocale)</div><div><b>(subject "String" and prep. object "Locale" both got removed)</b></div></blockquote><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">(3) Dictionary:</div><div style="font-family:HelveticaNeue"><br></div><blockquote style="font-family:HelveticaNeue;margin:0px 0px 0px 40px;border:none;padding:0px"><div>old: myDict.removeAtIndex(myIndex)</div><div>new: myDict.remove(at: myIndex)</div><div><b>(subject "element" already missing from both; prep. object "Index" got removed)</b></div></blockquote><div style="font-family:HelveticaNeue"></div></blockquote><div><br></div><div>The thing is, the subjects and prepositional objects *are* present in all of these—they are the parameters and targets of the calls. </div><div><br></div><div>In your own example, you say "In space, no one can hear you scream", not "In location space, group-of-people no one can hear you scream". So why is it a problem that we say "myString, capitalized with myLocale" instead of "myString, string capitalized with locale myLocale"? These are redundancies that we would never tolerate in natural language; I don't see why you think code should be different.</div><br><blockquote type="cite"><div style="font-family:HelveticaNeue">(4) Date:</div><div style="font-family:HelveticaNeue"><br></div><blockquote style="font-family:HelveticaNeue;margin:0px 0px 0px 40px;border:none;padding:0px"><div>old: myDate.timeIntervalSinceDate(m<wbr>yDate)</div><div>new: myDate.timeIntervalSince(date: myDate)</div><div><b>(subject "timeInterval" and object "Date" both still present; but oddly, preposition "since" got left outside of the parentheses)</b></div></blockquote></blockquote><div><br></div><div>This is actually inaccurate—the parameter to `timeIntervalSince(_:)` is unlabeled, so it's:</div><div><br></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>new: myDate.timeIntervalSince(myDat<wbr>e)</div><br><blockquote type="cite"><font face="HelveticaNeue">(5) Array:</font><div><font face="HelveticaNeue"><br></font></div><div><font face="HelveticaNeue"><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span> old: myArray.forEach({ thing in code})</font></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="HelveticaNeue">new: myArray.forEach() { thing in //code }</font></div></blockquote><div><font face="HelveticaNeue"> <b>(preposition “for” is outside of the parentheses)</b><br></font></div></blockquote><div></div><div><font face="HelveticaNeue"><b><br></b></font></div></div><div>Yes, because the preposition does not apply to the parameter—it applies to the operation as a whole. I'll have more to say on this in a moment.</div><div><br></div><div><blockquote type="cite"><span style="font-family:HelveticaNeue">The inconsistency between the examples is shown in the bold text of each example, but lets go over why this matters. It matters because any language is easier to learn the more consistently it sticks to its own rules.</span></blockquote></div><div><br></div><div>This is true, but you aren't just proposing sticking more closely to our existing standards—you're proposing *changing* our standards. And I don't think the changes you propose are an improvement. In fact, I'd say each of these examples is worse:</div><div><br></div><div><div style="font-family:HelveticaNeue"></div><blockquote type="cite"><div style="font-family:HelveticaNeue">(1) myCKDatabase.fetchRecord(withR<wbr>ecordID:)</div></blockquote><div><br></div><div>"Fetch record with record ID"? I mean, you could at least remove the `Record` before `ID`. What other ID do you suppose it would be?</div><div><br></div><div>I *can* see the case for going back to `fetchRecord` instead of just `fetch`, though. On the other hand, I do think that, if you know it's a database, the most obvious thing for `fetch` to be fetching is a record from that database. It's not a dog—it won't be fetching a stick.</div><br><blockquote type="cite"><div style="font-family:HelveticaNeue">(2) myString.stringCapitalized(wit<wbr>hLocale:)</div></blockquote><div><br></div><div>Let's translate this to an actual use site, which is what we care about.</div><div><br></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>func tableView(_: UITableView, titleForHeaderInSection section: Int) -> String? {</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>return sections[section].title.string<wbr>Capitalized(withLocale: .current)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div><br></div><div>What is `string` contributing here? We already know it's a "title", which sounds a lot like a string. If you asked for a "capitalized" string, what else would you get back if not another string?</div><div><br></div><div>The locale parameter is a little more tricky. You're right that `(with: .current)` is vague, but I can imagine plenty of call sites where `with` wouldn't be:</div><div><br></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>title.capitalized(with: german)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>title.capitalized(with: docLocale)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>title.capitalized(with: otherUser.locale)</div><div><br></div><div>Something at the call site needs to imply this is a locale, and there's nothing in `(with: .current)` that does so. This is arguably just a style issue, though: even though the language allows you to say `(with: .current)`, you really ought to say `(with: Locale.current)` to be clearer. Or perhaps the problem is with the name `current`—it ought to be `currentLocale` (even though that's redundant when you write it out as `Locale.currentLocale`), or it should use some location-ish terminology like `home` or `native`.</div><div><br></div><div>(Actually, I think there might be a new guideline there: Variable and property names should at least hint at the type of the value they contain. Names like `current` or `shared` or `default` are too vague, and should usually be paired with a word that implies the type.)</div><div><br></div><div>It might also help to change the `with` preposition to `in`, which would at least imply that the parameter is related to some kind of location.</div><div><br></div><div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>title.capitalized(in: german)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>title.capitalized(in: docLocal<wbr>e)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>title.capitalized(in: otherUser.locale)</div><div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>title.capitalized(in: .current)<span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>// Still not great, but better</div></div><div><br></div></div><blockquote type="cite"><div style="font-family:HelveticaNeue">(3) myDictionary.elementRemoved(at<wbr>Index:)</div></blockquote><div><br></div><div>This naming is exactly backwards, and is a perfect example of why we *don't* want rigid consistency:</div><div><br></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>1. It emphasizes the element being returned, while making the "Removed" operation an afterthought, even though the removal is the main thing you want to happen and the element is returned as an afterthought.</div><div><br></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>2. It mentions the "Index", even though there is no other plausible thing that could be labeled "at". (The only other plausible parameters to a `remove` method are an element, an array of elements, a predicate, or a range of indices. Of those four, only the range of indices could possibly make sense with "at", but that ambiguity is a harmless overloading.)</div><div><br></div><div>Again, think about a use site:</div><div><br></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>func tableView(_: UITableView, commit edit: UITableViewCellEditingSt<wbr>yle, forRowAt indexPath: IndexPath) {</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>assert(edit == .delete)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>sections[indexPath.section].ro<wbr>ws.<span style="font-family:HelveticaNeue">elementRemoved</span>(atIndex: indexPath.row)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>// vs.</div><div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>sections[indexPath.section].ro<wbr>ws.<span style="font-family:HelveticaNeue">remove</span>(at: indexPath.row)</div></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div><br></div><div>In context, `elementRemoved` obscures the purpose of the line, and there is no ambiguity about what `at` means. The current name is *far* better.</div><br><blockquote type="cite"><div style="font-family:HelveticaNeue">(4) myDate.timeInterval(sinceDate:<wbr>)</div></blockquote><div><br></div><div>I have a hard time thinking of a call site where `sinceDate` would be an improvement over `since`; the preposition already *strongly* implies a temporal aspect to the parameter.</div><div><br></div><div>If we remove `Date`, then in isolation I kind of like this change. The problem arrives when you step out of isolation and think about the other methods in its family. It would be strange to have `myDate.timeInterval(since: otherDate)`, but `myDate.timeIntervalSinceNow()<wbr>`.</div><div><br></div><div>One solution would be to add `now`, `referenceDate`, and `unixEpoch` (or `utc1970`) as static properties on `Date`. Then you could have just the one `timeInterval(since:)` method:</div><div><br></div><div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>myDate.timeInterval(since: otherDate)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>myDate.timeInterval(since: .now)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>myDate.timeInterval(since: .referenceDate)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>myDate.timeInterval(since: .unixEpoch)</div><div><br></div><div>Another solution would be to add a `-` operator that takes two `Date`s and returns a `TimeInterval`, sidestepping the wording issue entirely.</div></div><div><br></div><blockquote type="cite"><div style="font-family:HelveticaNeue">(5) myArray.each(inClosure: ) </div></blockquote><div><br></div><div>I don't get this name at all. This operation is completely imperative and side-effectful, but there's no verb? How is it "in" the closure? Why "closure" when you can pass a function, and in fact you probably will *only* see this label if you're passing a function?</div><div><br></div></div><div>I do think there's a problem with `forEach(_:)`—it ought to be `forEach(do:)`. This is much like `DispatchQueue.async(execute:)<wbr>` or the `withoutActuallyEscaping(_:do:<wbr>)` function in the standard library. When you pass a function parameter, and the call's primary purpose is to run that parameter, it's often best to attach the verb to that parameter instead of putting it in the base name. Of course, the complication there is that the verb doesn't actually get written if you use trailing closure syntax, but the curlies sort of fill that role. Kind of.</div><div><br></div><div><div style="font-family:HelveticaNeue"><blockquote type="cite">Although I do understand removing "string" from the latter was to reduce redundancy in function/method declarations, we only make one declaration, yet we make many calls. So increasing ambiguity in calls does not seem like a good trade-off for decreased boilerplate in declarations. More often than not it's calls that we're reading, not the declarations—unless of course the call was ambiguous and we had to read the declaration to make sense out of it. So perhaps we might question if increased ambiguity is an overall good thing. </blockquote></div><div><br></div><div>I think you misunderstand the current Guidelines' goals. The Guidelines are not trying to reduce redundancy at declaration sites—they're trying to reduce redundancy at *call sites*. The idea is that, if the variable names for the method's target and parameters imply something about the types they contain, those names along with the prepositions will imply the purpose of each parameter, and therefore the call. The types are just a more formal version of that check.</div><div><br></div><div>That's why the very first paragraph of the API Design Guidelines <<a href="https://swift.org/documentation/api-design-guidelines/" target="_blank">https://swift.org/documentati<wbr>on/api-design-guidelines/</a>> says:</div><div><br></div><div><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Clarity at the point of use is your most important goal. Entities such as methods and properties are declared only once but used repeatedly. Design APIs to make those uses clear and concise. When evaluating a design, reading a declaration is seldom sufficient; always examine a use case to make sure it looks clear in context.<br></blockquote></blockquote></blockquote><br></div></div><div>So the tradeoff is not between *declaration redundancy* and call site clarity—it is between *call site redundancy* and call site ambiguity. Because their parameters are unlabeled, most languages have severe call site ambiguity problems. Objective-C has a pretty serious call site redundancy problem. Swift's design is trying to hit the baby bear "just right" point.</div><div><br></div><div>It is quite possible that, in some areas, we have swung too far back towards ambiguity. But I don't think `elementRemoved(atIndex:)` is going to fix that.</div><div><br></div><div><div style="font-family:HelveticaNeue"></div></div><blockquote type="cite"><div><div style="font-family:HelveticaNeue">However this removal of explicit contextual cues from the method signature harms readability, since now, the compiler will let people write code like:</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">{ return $0.fetch(withRecordID:$1) }</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">Clearly, the onus is now on the developer not to use cryptic, short variable names or NO variable names. However, spend much time on GitHub or in CocoaPods and you will see an increasing number of codebases where that's exactly what they do, especially in closures.</div><div style="font-family:HelveticaNeue"></div></div></blockquote><div><br></div><div>What I think you're missing with this example—and in fact with all of your closure-based examples—is that closures don't exist in isolation; they're in some larger context. (Otherwise, they won't compile.) For instance, the above closure might be in a line like:</div><div><br></div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>return zip(databases, recordIDs)</div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>.map <span style="font-family:HelveticaNeue">{ return $0.fetch(withRecordID:$1) }</span></div><div><br></div><div>Read in the context of its line, the meanings of $0 and $1 are fairly clear.</div><br><blockquote type="cite"><div><div style="font-family:HelveticaNeue">Another problem is that the compiler doesn't care if you write:</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">{ ambiguousName in</div><div style="font-family:HelveticaNeue">let myRecordID = ambiguousName.fetch(withReco<wbr>rdID:myID) </div><div style="font-family:HelveticaNeue">return myRecordID }</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">This is highly problematic because someone reading this code will have no reason to expect the type of "myRecordID" not to be CKRecordID. (In fact, it's CKRecord.)</div></div></blockquote><div><br></div><div>Again, in the larger context, this line will end up generating a `[CKRecord]` array instead of a `[CKRecordID]` array, which is probably going to cause a type mismatch once you try to actually use the alleged record IDs. (But as I said earlier, I can see the case for using `fetchRecord(withID:)` or `fetchRecord(with:)` instead of `fetch(withRecordID:)`.)</div><div><br></div><div>Ambiguous names can hide bugs in their ambiguity, but verbose names can also hide bugs in the sheer mass of code they generate. The difference is, developers can manage the ambiguity in their code by naming variables well, but they can't manage verbosity if verbose names are imposed on them.</div></div><div><br></div><div><div style="font-family:HelveticaNeue"></div></div><blockquote type="cite"><div><div style="font-family:HelveticaNeue">We also have examples like: </div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">{ return $0.draw(with:$1) }</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">What is $0? What is $1? This is a real Apple API, BTW.</div></div></blockquote><div><br></div><div></div><div>Again, the context of the closure would tell you, but part of the problem here is that they held onto an Objective-C preposition which was poorly chosen. If the line were `<span style="font-family:HelveticaNeue">$0.draw(in:$1)`, you would know that `$1` specified an area of the screen and `$0` was something that could be drawn, which frankly is all you really *need* to know to understand what this line does.</span></div><div><span style="font-family:HelveticaNeue"><br></span></div><blockquote type="cite"><div><div style="font-family:HelveticaNeue">{array, key in </div><div style="font-family:HelveticaNeue">let number = array.remove(at:key)</div><div style="font-family:HelveticaNeue">return number }</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">This will compile and run even though number will be a tuple key-value pair, array will be a dict, and key will be an index type! This may seem like a ridiculous example, but I have literally seen things like this.</div></div></blockquote><div></div><div><br></div><div>Where have you seen something like this? `array` would have to be passed `inout` for this to work at all.</div><div><br></div><div>Nevertheless, how would more verbose names help with this problem? This is every bit as incorrect, and the compiler will still accept it:</div><div><br></div><div><div style="font-family:HelveticaNeue"><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>{array, key in </div><div style="font-family:HelveticaNeue"><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>let number = array.elementRemoved(atIndex:k<wbr>ey)</div><div style="font-family:HelveticaNeue"><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-tab-span" style="white-space:pre-wrap"> </span>return number }</div></div><div><div style="font-family:HelveticaNeue"><br></div></div><div style="font-family:HelveticaNeue">Are you thinking that they'll notice that `atIndex` is not `atKey`? There is already a much stronger safeguard against that: `Dictionary.Index` and `Dictionary.Key` are different, totally incompatible types. Every mechanism I can think of to get a `Dictionary.Index` has "index" or "indices" in its name, so you could only make this mistake if you confused dictionary indices with dictionary keys, in which case `atIndex:` would not stand out to you either.</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue">Ultimately, unless the compiler actually understands identifiers, it's just not going to be able to catch mistakes like calling a dictionary an "array", or many of the other problems you describe here. But the type system can and often does flag these kinds of problems pretty close to the source.</div><div style="font-family:HelveticaNeue"><br></div><div style="font-family:HelveticaNeue"><blockquote type="cite">Orphaning method signatures by stripping useful return type and argument type information wouldn't be so bad if variables were all named descriptively, but that is a strangely optimistic hope for a language that's as paranoid about safety that it was specifically designed to prevent many categories of common mistakes.</blockquote></div><div><br></div><div>Personally, I think of Swift's approach to safety as similar to Reagan's "trust, but verify". Our naming conventions trust the programmer to write code with clear names; our picky type system verifies that the code is plausible. We don't force the programmer to explain herself to us until we notice that something doesn't seem right.</div><div><br></div><div>The bottom line is, a language can't force you to write clear and correct code, but it has many tools it can use to encourage it. Swift chooses not to use the "heavily redundant names" tool because its cost to good code is too high. We instead rely more on other tools, like strong typing, value types, and definite initialization, to encourage high-quality code at a lower cost.</div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">More verbose rather than heavily redundant names tool, but what have we lost by being reliant on strongish static typing and value types? Would Cocoa/ UIKit be so nice to use if rewritten fully in idiomatic non @objc Swift (compared to working with UI on C++ platforms)? What would it tell us?</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Sorry for the rant... do not take static typing laying down j/k ;). (still quite in “love” with the opt-in security that annotations and clang warnings bring in Objective-C rather than the opt-out freedom model some other languages have)</div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div><span class="m_-1587874679186290360m_2496032212908584109m_-9107923823895178697m_-1530881620398979283Apple-style-span" style="border-collapse:separate;font-variant-ligatures:normal;font-variant-east-asian:normal;line-height:normal;border-spacing:0px"><div><div style="font-size:12px">-- </div><div style="font-size:12px">Brent Royal-Gordon</div><div style="font-size:12px">Architechies</div></div></span></div><br></div></blockquote><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a></span><br></div></blockquote><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">______________________________<wbr>_________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">swift-evolution mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>