<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 9, 2016, at 11:50 AM, Jacob Bandes-Storch 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 dir="ltr" class="">I think I like this direction in general. It feels more natural to have the preposition in the label than outside the parenthesis (and it's worth keeping the preposition because it improves clarity in most cases).<div class=""><br class=""></div><div class="">Here are some strange examples which need tweaking:</div><div class=""><br class=""></div><div class=""><div class=""> + func accountType(withAccountTypeIdentifier typeIdentifier: String!) -> ACAccountType!</div></div><div class=""><br class=""></div><div class="">Probably should just be "withIdentifier”.</div></div></div></blockquote><div><br class=""></div><div>Interesting! I’ll have to think about this; it might just be a special case. I haven’t seen this issue come up before.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class=""> + func comparePositionInDecodeOrderWithPosition(of cursor: AVSampleCursor) -> ComparisonResult</div></div><div class=""><br class=""></div><div class="">I would suggest comparePositionInDecodeOrder(withPositionOf cursor: AVSampleCursor). Tricky because there are two prepositions.</div></div></div></blockquote><div><br class=""></div>Yeah. Our current heuristics produce:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func comparePositionInDecodeOrder(positionOf cursor: AVSampleCursor) -> ComparisonResult</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class=""> func componentsPassingTest(testHandler: (AVAudioUnitComponent, UnsafeMutablePointer<ObjCBool>) -> Bool) -> [AVAudioUnitComponent]</div><div class=""> - func componentsMatching(desc: AudioComponentDescription) -> [AVAudioUnitComponent]</div><div class=""> + func components(matching desc: AudioComponentDescription) -> [AVAudioUnitComponent]</div></div><div class=""><br class=""></div><div class="">Should "passingTest" become the first label?</div></div></div></blockquote><div><br class=""></div>Yes, thanks!</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-3-api-guidelines-review/commit/ba288337414c998fa358312e22c9b2660dd334e4" class="">https://github.com/apple/swift-3-api-guidelines-review/commit/ba288337414c998fa358312e22c9b2660dd334e4</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""> - class func exportPresetsCompatibleWith(asset: AVAsset) -> [String]</div><div class=""> + class func exportPresetsCompatible(withAsset asset: AVAsset) -> [String]</div></div><div class=""><br class=""></div><div class="">This is not an improvement. I'd suggest exportPresets(compatibleWith asset: AVAsset), but that doesn't really fit under the current rules. Maybe a special case for [noun][adjective][preposition]?<br class=""></div></div></div></blockquote><div><br class=""></div><div>I did it in a different way, here:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-3-api-guidelines-review/commit/fd70e0e4fa026843ab6570d1b2d46a4cbfd13974" class="">https://github.com/apple/swift-3-api-guidelines-review/commit/fd70e0e4fa026843ab6570d1b2d46a4cbfd13974</a></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class=""> - func compatibleTrackFor(compositionTrack: AVCompositionTrack) -> AVAssetTrack?</div><div class=""> + func compatibleTrack(forCompositionTrack compositionTrack: AVCompositionTrack) -> AVAssetTrack?</div></div><div class=""><br class=""></div><div class="">Does this indicate that some other suffix-matching rules are no longer being applied? I'd have expected compatibleTrack(for compositionTrack: AVCompositionTrack). I also see other examples like renewCredentials(forAccount account: ACAccount, …).</div></div></div></blockquote><div><br class=""></div>There was a ban on leaving “vacuous” argument labels like “for” or “with”, but it doesn’t make sense now. Addressed in</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-3-api-guidelines-review/commit/aaec8d0fe9cf82cd6f4088721cf8968a6ac69164" class="">https://github.com/apple/swift-3-api-guidelines-review/commit/aaec8d0fe9cf82cd6f4088721cf8968a6ac69164</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class=""> func createSampleBufferFor(request: AVSampleBufferRequest) -> CMSampleBuffer</div></div><div class=""><br class=""></div><div class="">Why wasn't this changed?</div></div></div></blockquote><div><br class=""></div><div>Similar issue to the rule above. It’s fixed now to </div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func createSampleBuffer(for request: AVSampleBufferRequest) -> CMSampleBuffer</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class=""> - class func typeOf(property property: String!) -> ABPropertyType</div><div class=""> + class func type(ofProperty property: String!) -> ABPropertyType</div></div><div class=""><br class=""></div><div class="">I don't really like either of these. Maybe we need special rules for "of” ?</div></div></div></blockquote><div><br class=""></div><div>Handled in the subsequent discussion ;)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">If anyone else is worried about special cases, I just looked this up: there's a clang __attribute__((swift_name("x"))), or NS_SWIFT_NAME(x), which can be used to expose Obj-C methods to Swift with particular custom names.</div></div></div></blockquote><br class=""></div><div>Yes, generalizing the swift_name attribute to allow arbitrary renaming is one of specified steps to implementing SE-0005, so we can deal with special cases and bad translations.</div><div><br class=""></div><div>Thanks!</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div></body></html>