<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 8, 2016 at 5:23 AM, Dave Abrahams 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"><span class=""><br>
on Mon Feb 08 2016, Thorsten Seitz <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> I agree that positioning the preposition depending on whether a<br>
> default value is present is unfortunate, but I don't agree that it<br>
> would complicate the rules significantly as it just adds a very simple<br>
> special case for one rule.<br>
<br>
</span>Heh, but then people will really demand a special case for move(from: a,<br>
to: b)<br>
<span class=""><br>
<br>
> Is the problem that it complicates API evolvement significant enough<br>
> to outweigh the advantage of this rule?<br>
<br>
</span>That's one problem. I think we should also be concerned about rules<br>
that create a feeling of non-uniformity and un-predictability across<br>
code. For example, you don't want to see something like this:<br>
<br>
removeAllBricks(having: .CrackleGlazeFinish)<br>
<br>
removeAllBeamsHaving(.RottenWood)<br>
<span class=""><br></span></blockquote><div><br></div><div>I just thought of another point in favor of prepositions going inside parentheses: verbs that take an optional indirect object, expressed as an overload.</div><div><br></div><div>protocol Message {</div><div> // Stores the whole message</div><div> func store(toCoreDataEntity tableName: String)</div><div> func store(toUserDefaults key: String)</div><div><br></div><div> // Stores only a single field within the message</div><div> func store(field: String, toCoreDataEntity tableName: String)</div><div> func store(field: String, toUserDefaults key: String)</div><div>}</div><div><br></div><div>protocol RenderLayer {</div><div> // Moves the whole layer</div><div> func move(toDOMElement element: DOMElement, edge: Edge)</div><div><br></div><div> // Moves an element within the render layer</div><div> func move(elementWithID id: String, toDOMElement element, edge: Edge)</div><div> func move(element element: DOMElement, toDOMElement element, edge: Edge)</div><div>}</div><div><br></div><div>With preposition-inside-parentheses, there's a nice symmetry between these API calls:</div><div><br></div><div>move(toDOMElement: table, edge: .Bottom) // Whole layer</div><div>move(elementWithID: "#nav", toDOMElement: table, edge: .Bottom) // Just one element</div><div><br></div><div>With preposition-outside-parentheses, they become pretty awkward:</div><div><br></div><div>moveTo(DOMElement: table, edge: .Bottom)</div><div>move(elementWithID: "#nav", toDOMElement: table, edge: .Bottom) // Why different base name?</div><div>moveTo(DOMElement: table, edge: .Bottom, elementWithID: "#nav") // What's getting moved?</div><div>moveTo(DOMElement: table, edge: .Bottom, onlyTheElementWithID: "#nav") // Works, but wordy</div><div><br></div><div>None of this is what I'd consider a deal-breaker, and I know the review period has ended, but if a decision hasn't been made yet and you're on the fence, please consider. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Closure arguments with default values won't profit from it if written<br>
> as trailing closure, of course.<br>
><br>
> No good idea how to remedy that (trailing argument label?? probably not).<br>
<br>
</span>I think that's a whole 'nother bag o' worms, and, yes, some language<br>
syntax might be needed. IOW, the issue goes beyond mere guidelines.<br>
<div class="HOEnZb"><div class="h5"><br>
> -Thorsten<br>
><br>
> Am 08. Februar 2016 um 12:47 schrieb Matthew Judge via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
><br>
> Agree that basing the preposition location on whether there is a default value is<br>
> unfortunate. The problem is "Zone" is not redundant/needless when calling it with the<br>
> default value.<br>
><br>
> copyWith()<br>
><br>
> If I were asking "what zone?" Ok it's the default zone, but I'm just asking "with what?"<br>
><br>
> On Feb 7, 2016, at 10:48, Dave Abrahams via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> on Sat Feb 06 2016, Douglas Gregor <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Feb 6, 2016, at 10:08 PM, Dave Abrahams via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> on Sat Feb 06 2016, Thorsten Seitz<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> So the preposition should move into the argument label if the argument is<br>
> optional?<br>
><br>
> copy(withZone: zone = nil)<br>
><br>
> That's a good idea.<br>
><br>
> It seems unfortunate that the placement of the preposition should<br>
><br>
> change depending on whether there is a default argument or not,<br>
><br>
> especially since it is reasonable to imagine that an API evolves to<br>
><br>
> gain a default argument later on.<br>
><br>
> You're right; it would complicate the rules significantly, too.<br>
><br>
> - Doug<br>
><br>
> -Thorsten<br>
><br>
> Am 06.02.2016 um 14:45 schrieb Matthew Judge via swift-evolution<br>
><br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
><br>
> Very first method<br>
><br>
> copyWith(zone: Zone = nil)<br>
><br>
> can be called as<br>
><br>
> copyWith()<br>
><br>
> I'm assuming this is still something we don't want right?<br>
><br>
> On Feb 6, 2016, at 02:16, Douglas Gregor via swift-evolution<br>
><br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Feb 5, 2016, at 1:32 PM, Dave Abrahams via swift-evolution<br>
><br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
> wrote:<br>
><br>
> Given all the awesome feedback I've gotten on this thread, I<br>
> went back<br>
><br>
> to the drawing board and came up with something new; I think<br>
> this one<br>
><br>
> works. The previously-stated goals still apply:<br>
><br>
> [snip goals]<br>
><br>
> P.S. Doug is presently working on generating new importer<br>
> results, based<br>
><br>
> on these guidelines, for your perusal. They should be ready<br>
> soon.<br>
><br>
> Here’s a link:<br>
><br>
> <a href="https://github.com/apple/swift-3-api-guidelines-review/pull/10/files" rel="noreferrer" target="_blank">https://github.com/apple/swift-3-api-guidelines-review/pull/10/files</a><br>
><br>
> Feedback welcome!<br>
><br>
> - Doug<br>
><br>
> _______________________________________________<br>
><br>
> swift-evolution mailing list<br>
><br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
><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>
><br>
> _______________________________________________<br>
><br>
> swift-evolution mailing list<br>
><br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
><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>
><br>
> _______________________________________________<br>
><br>
> swift-evolution mailing list<br>
><br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
><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>
><br>
> --<br>
><br>
> -Dave<br>
><br>
> _______________________________________________<br>
><br>
> swift-evolution mailing list<br>
><br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
><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>
><br>
> _______________________________________________<br>
><br>
> swift-evolution mailing list<br>
><br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
><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>
><br>
> --<br>
><br>
> -Dave<br>
><br>
> _______________________________________________<br>
><br>
> swift-evolution mailing list<br>
><br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
><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>
><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>
><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>
<br>
--<br>
-Dave<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>
</div></div></blockquote></div><br></div></div>