<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Wouldn't rule 3b "<span style="background-color: rgba(255, 255, 255, 0);">unless the preposition would break a very tight association </span><span style="background-color: rgba(255, 255, 255, 0);">between </span><span style="background-color: rgba(255, 255, 255, 0);">parameters" apply, resulting in</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">a.tracksWith(mediaType: b, composer: c)</span></font></div></div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></font></div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">This would not be applicable to the unary variant, though...</span></font></div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></font></div><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">-Thorsten </span></font></div><div><br>Am 11.02.2016 um 11:33 schrieb Radosław Pietruszewski 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=""><blockquote type="cite" class="">Hi everybody,<br class=""><br class="">Having looked at some examples, the API guidelines working group members<br class="">that were present this morning agreed we really want prepositions inside<br class="">the parentheses of method calls.</blockquote><br class=""></div><div class="">I find that… surprising.</div><div class=""><br class=""></div><div class="">Between these two (sorry to repeat the same example again):</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func trackWith(trackID trackID: CMPersistentTrackID) -> AVAssetTrack?</div><div class="">func track(withTrackID trackID: CMPersistentTrackID) -> AVAssetTrack?</div><div class=""><br class=""></div></blockquote>#1 seems nicer and clearer to me. Having “with” as the first word glued to a parameter label looks bizarre to my eyes:<div class=""><br class=""></div><div class="">As far as I understand it, the whole reason to keep “with” etc in many APIs was to make cases like this one clearer. Because “track” as a name doesn’t tell you much. Someone said that having the method name end with “With” creates a sense of suspense, and to me that was precisely what was a good thing about it. It’s not just “track”, it’s a “track with” — ooh, here come the criteria for the track! Having removed “with” from the name itself, we lose, IMHO, the clarity this word was supposed to bring in initializer/getter/finder-like methods. And we still keep the word later inside the parens, but to my eyes it no longer helps clarity, just exists as a vacuous, needless word.</div><div class=""><br class=""></div><div class="">Another reason I don’t like this, say we have:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.tracks(withMediaType: b, composer: c)</div><div class=""><br class=""></div><div class="">This no longer looks symmetrical across the parameters. First parameter has label “with”, second doesn’t. The previous version:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.tracksWith(mediaType: b, composer: c)</div><div class=""><br class=""></div><div class="">Didn’t have that problem.</div><div class=""><br class=""></div><div class="">I fear that people will take that as a signal that they should make the whole method, including parameter labels, sound like an English sentence and will start applying needless words like “and”:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.tracks(withMediaType: b, andComposer: c)</div><div class=""><br class=""></div><div class="">To avoid this weird-looking construct where the first parameter has a starting preposition, and other parameters don’t. Again:<br class=""><div class=""><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.tracksWith(mediaType: b, composer: c)</div><div class=""><br class=""></div><div class="">Doesn’t have this problem, because while the method name part ends with “With”, the parameters are consistently just nouns.</div><div class=""><br class=""></div><div class="">So -1 from me on this. Moving prepositions inside parens look like a step back from the Part DEUX Proposal.</div><div class=""><br class=""></div><div class="">Would you mind elaborating on the working group's rationale for moving prepositions inside parens?<br class=""><div class=""><br class=""></div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 09 Feb 2016, at 20:18, Dave Abrahams 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=""><div class=""><br class="">Hi everybody,<br class=""><br class="">Having looked at some examples, the API guidelines working group members<br class="">that were present this morning agreed we really want prepositions inside<br class="">the parentheses of method calls.<br class=""><br class="">Here are some results for the importer; we're still tuning some of the<br class="">heuristics but overall we feel very good about the preposition<br class="">placement:<br class=""><br class=""> <a href="https://github.com/apple/swift-3-api-guidelines-review/commit/da7e512cf75688e6da148dd2a8b27ae9efcb8821?diff=split" class="">https://github.com/apple/swift-3-api-guidelines-review/commit/da7e512cf75688e6da148dd2a8b27ae9efcb8821?diff=split</a><br class=""><br class="">Note that this is not final wording, but here are the guidelines we're<br class="">working with for first argument labels:<br class=""><br class="">A. Try to form a grammatical phrase including the first argument and<br class=""> describing the primary semantics at the call site.<br class=""><br class="">B. The first argument gets a label when and only when:<br class=""><br class=""> 1. It does not form part of a grammatical phrase describing the<br class=""> primary semantics. For example,<br class=""> ```<br class=""> x.dismiss(animated: y)<br class=""> ```<br class=""> [more examples needed]<br class=""> Note that parameters with defaults never describe the primary<br class=""> semantics. so are always labeled.<br class=""> ```<br class=""> func invert(options options: SomeOptionSet = []) // yes<br class=""> func invert(_ options: SomeOptionSet = []) // no<br class=""> ```<br class=""><br class=""> 2. The method is a factory method; such calls should mirror<br class=""> initializers, with no preposition. For example,<br class=""> ```<br class=""> let x = UIColor(red: r, green: g, blue: b)<br class=""> let y = monitor.makeColor(red: r, green: g, blue: b)<br class=""> ```<br class=""><br class=""> 3. It is part of a prepositional phrase<br class=""><br class=""> a. The label normally starts with the preposition. <br class=""> For example, <br class=""> ```<br class=""> x.move(from: a, to: b)<br class=""> x.loadValues(forKeys: ["fox", "box", "lox"])<br class=""> ```<br class=""> b. ...unless the preposition would break a very tight association<br class=""> between parameters:<br class=""> ```<br class=""> x.moveTo(x: a, y: b)<br class=""> ```<br class=""> [encourage grouping parameters into higher-level concepts,<br class=""> e.g. Point, in these cases]<br class=""><br class=""><br class=""><br class="">Feedback most welcome, of course.<br class="">-- <br class="">-Dave<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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></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>