<div dir="ltr">Yikes, not only is the email too big for some mail clients, it's too big for the mailing list. Resending with proposal snipped.<div><div><br><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 23, 2016 at 1:24 PM, David Hart 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"><div style="word-wrap:break-word"><div>Most of your proposal look great to me! Comments inline:</div><br><div><blockquote type="cite"><div>On 23 Jun 2016, at 09:19, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div>As previously <strike>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><br></div><div>• Inconsistent use of `prefix`/`suffix` vs. `first`/`last`</div><div>• Confusing naming of `drop` methods</div><div>• Ambiguous naming of `index(of:/where:)` and `drop(while:)`</div><div>• `prefix(upTo:)`, `prefix(through:)`, and `suffix(from:)` shouldn't be part of this family at all</div><div><br></div><div>To fix this, I propose:</div><div><br></div><div>• 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></div></blockquote><div>Looking at the first column in your table, I think the current API focuses correctly on the number of elements returned (and consequently, the return type) rather than the number of elements interrogated. "First" and "last" on their own suggest very strongly that you get back either zero elements or one element (thus, an optional would be the appropriate return type), whereas "prefix" and "suffix" suggest 0 to all elements might be returned (thus, an array or collection would be the appropriate return type). Currently, the API adheres to that expectation as far as your "get" column is concerned, and IMO the most consistent approach would be to whip the remaining columns in line.</div><div><br></div><div>To me, `first(where:)` is unambiguous and doubly distinguished from `prefix(while:)`--even when the argument label is dropped in trailing closure syntax, it is clear that `first` gives you at most one, and by contradistinction `prefix` gives you at most all. I'm not sure that "earliest" is an improvement, since you're introducing another word and breaking the parallels here. So on reflection, I'm satisfied that first, prefix, last, suffix all have their place in the API. Of course, I think you could make a case for an across-the-board renaming of "first" to "earliest" and "last" to "latest"--in fact, there could be an argument that given 0-based indices the word "first" is an unfortunate choice in any case.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div>• Renaming `index(of:/where:)` to `earliestIndex(…)` and `first(where:)` to `earliest(where:)`</div><div>• Renaming the `drop` methods to use `removing`</div></div></div></blockquote><div><br></div><div>+! Everything above, I strongly agree with!</div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div>• Redesigning `prefix(upTo:)`, `prefix(through:)` and `suffix(from:)` as subscripts with "partial" ranges, like `people[..<idx]` or perhaps `people[nil..<idx]`.</div></div></div></blockquote><div><br></div><div>I’m not a fan of the subscript solutions. They both introduce new types which seems very heavyweight for such a small use case. I’d vote for keeping the current functions.</div></div></div></blockquote><div><br></div><div>Ditto, not a fan of a subscript solution here. It is true that `suffix(from:)` seems weird at first, but it is literally nonsensical to interpret the single argument any other way, partly because of the mandatory argument label but mostly because a "suffix" that doesn't go to the end isn't a suffix.</div><div><br></div><div>(Personally, though, I always thought `upTo` was an ineffective attempt to clarify the distinction with `through`, since either you were familiar with `stride(from:to:by:)` and `stride(from:through:by:)` or you weren't, and if you weren't `upTo` is just as opaque as `to`.) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div>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><br></div><div>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><br></div><div>I would mainly like feedback on the two most open questions left in this proposal:</div><div><br></div><div>• The choice of `removing` to replace `drop`</div></div></div></blockquote><div><br></div><div>Yep, heavily agree with you on `removing`.</div></div></div></blockquote><div><br></div><div>I think `removing` is an improvement. That said, your proposal raises a good point that the return type goes against expectations for an `ed/ing` counterpart. If you're looking for an alternative name, there's a pretty good one at the top of your very nice table: `excluding`. It's a commonly used English word, conveys exactly what's going on, and isn't scary and verb-sounding like `drop`.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div>• The decision about whether to use `people[..<idx]`, `people[nil..<idx]`, or `people[to: idx]`.</div></div></div></blockquote><div><br></div><div>None of the above, as stated previously :)</div></div></div></blockquote><div><br></div><div>Yeah, not so much of a fan here either :/</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div>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><br></div><div>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><br></div><div>Thanks for your attention!</div><div><br></div><div>(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" target="_blank">https://gist.github.com/brentdax/024d26c2b68b88323989540c06261430</a>> instead.)</div></div></div></blockquote></div></div></blockquote></div><br></div></div>
</div><br></div></div></div>