<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I tend to agree with Paul and Charles' concerns here. I think it's still missing Erica's point about some paramaters being more tightly coupled to each other than to the base name. That's sort of addressed with this:<div class=""><br class=""></div><div class=""><blockquote type="cite" style="font-family: Monaco; font-size: 11px;" class=""> a.moveTo(x: 300, y: 400) // "a, move to 300" is a sentence <br class=""> // but doesn't describe the primary <br class=""> // semantics, which are to move in both<br class=""> // x and y. Thus, x gets a label.<br class=""></blockquote><br class=""></div><div class="">but I think "describing the primary semantics of the call" could be more explicit. Even just the word "fully [describing]" would help. Given that, "a.tracksHavingMediaType(.WaxCylinder, genre: .Jazz)" would be incorrect, because you can't ignore the "genre" part when describing the call. 'tracks(mediaType:genre:)' or 'tracksMatching(mediaType:genre:)' would both be fine, though the former includes a new convention that plural noun basenames mean filtered fetches.</div><div class=""><br class=""></div><div class="">Then the next problem is that the first version of the library may only have one form, and "tracksMatching(mediaType:)" would seem redundant, so it's just "tracksMatching(_:)". Then the two-argument form is added later, and suddenly they're not quite symmetrical. On second thought, maybe that's okay as long as they have the same base name.</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>