<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><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 class=""><blockquote type="cite" class=""><div class="">On 23 Jun 2016, at 3:19 PM, Brent Royal-Gordon 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">As previously <strike class="">threatened</strike> mentioned, I've written a draft proposal to fix a number of naming issues with APIs operating on the beginning and end of Sequences and Collections:</div><div class=""><br class=""></div><div class="">• Inconsistent use of `prefix`/`suffix` vs. `first`/`last`</div><div class="">• Confusing naming of `drop` methods</div><div class="">• Ambiguous naming of `index(of:/where:)` and `drop(while:)`</div><div class="">• `prefix(upTo:)`, `prefix(through:)`, and `suffix(from:)` shouldn't be part of this family at all</div><div class=""><br class=""></div><div class="">To fix this, I propose:</div><div class=""><br class=""></div><div class="">• Renaming all methods which operate on more than one element at the beginning/end to use "prefix" or "suffix", not "first" or "last"</div></div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">Just want to point out that `prefix` and `suffix` may introduce ambiguity, as they are also imperative verbs. For example, `S.prefix(1)` can be inferred as prefixing `1` to the sequence, instead of retrieving the prefix of the sequence.</div><div class=""><br class=""></div><div class="">IMO `skip`, as an alternative listed in the proposal, would convey the intention better and clearer, and it has roots in the sequence-like constructs of reactive programming libraries (e.g. RxSwift and ReactiveCocoa).</div></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">• Renaming `index(of:/where:)` to `earliestIndex(…)` and `first(where:)` to `earliest(where:)`</div><div class="">• Renaming the `drop` methods to use `removing`</div><div class="">• Redesigning `prefix(upTo:)`, `prefix(through:)` and `suffix(from:)` as subscripts with "partial" ranges, like `people[..<idx]` or perhaps `people[nil..<idx]`.</div><div class=""><div class=""><br class=""></div></div><div class="">Since that last point requires significant redesign, including the introduction of new types, I have also included an alternative design which uses `people[to: idx]` instead.</div><div class=""><br class=""></div><div class="">This proposal does not seek to add new functionality; it merely renames or (in the case of the "aggressive" subscript option) redesigns existing functionality. I do, however, discuss (without making many judgements about their wisdom) how these changes might affect the naming of functionality we might add in future versions of Swift.</div><div class=""><br class=""></div><div class="">I would mainly like feedback on the two most open questions left in this proposal:</div><div class=""><br class=""></div><div class="">• The choice of `removing` to replace `drop`</div><div class="">• The decision about whether to use `people[..<idx]`, `people[nil..<idx]`, or `people[to: idx]`.</div><div class=""><br class=""></div><div class="">But I'd also like comments on the rest of the proposal, and on whether I should split the prefix(upTo:/through:)/suffix(from:) changes into a separate proposal from the rest.</div><div class=""><br class=""></div><div class="">I suspect this will cause a firestorm of bikeshedding, so please try to keep your suggestions grounded. Don't just suggest a name; articulate why it's a better choice than what we already have or what this proposal suggests. Only you can prevent our first *three*-hundred-message bikeshedding thread.</div><div class=""><br class=""></div><div class="">Thanks for your attention!</div><div class=""><br class=""></div><div class="">(P.S. The proposal below includes several huge tables which may cause some mail clients to become very pouty and refuse to eat their supper. You may want to read the proposal at <<a href="https://gist.github.com/brentdax/024d26c2b68b88323989540c06261430" class="">https://gist.github.com/brentdax/024d26c2b68b88323989540c06261430</a>> instead.)</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""></div><br class=""></div>_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></body></html>