on Fri May 06 2016, Kevin Ballard <[email protected]> wrote:
> On Fri, May 6, 2016, at 07:33 PM, Dave Abrahams via swift-evolution wrote: >> >> on Fri May 06 2016, Kevin Ballard <[email protected]> wrote: >> >> > On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote: >> >> > >> >> on Fri May 06 2016, Kevin Ballard <[email protected]> wrote: >> >> >> >> > On Fri, May 6, 2016, at 05:31 PM, Kevin Ballard wrote: >> >> >> On Fri, May 6, 2016, at 05:19 PM, Dave Abrahams via swift-evolution >> >> >> wrote: >> > >> >> >> > >> >> >> > on Wed May 04 2016, Chris Lattner <[email protected]> wrote: >> >> >> > >> >> >> > > Proposal link: >> >> >> > > https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md >> >> > >> >> >> > > >> >> >> > > Hello Swift Community, >> >> >> > > >> >> >> > > The review of SE-0045: "Add scan, prefix(while:), drop(while:), and >> >> >> > > unfold to the stdlib" ran from April 28...May 3, 2016. A subset of >> >> >> > > the >> >> >> > > proposal is *accepted, with modifications* for Swift 3. This >> >> >> > > proposal >> >> >> > > included four new additions to the standard library: >> >> >> > > >> >> >> > > Sequence.prefix(while:) & Sequence.drop(while:) - These are >> >> >> > > *accepted* as specified in revision 3 of the proposal. >> >> >> > >> >> >> > I know the review is over and all, but… >> >> >> > >> >> >> > Chris brought to my attention an idea that I liked, and asked me to >> >> >> > post >> >> >> > here about it. Specifically, the argument label “where:” would >> >> >> > probably >> >> >> > be better than “while:”. “While” makes it sound to me like it's >> >> >> > going >> >> >> > to take a nullary predicate and be much more active. But it's hard >> >> >> > to >> >> >> > love >> >> >> > >> >> >> > s.drop(where: { $0 > 1 }) >> >> >> > s.drop { $0 > 1 } >> >> >> > >> >> >> > because it makes it sound like a general filtering operation. >> >> >> > >> >> >> > Therefore, I'd much rather see >> >> >> > >> >> >> > s.droppingPrefix(where: {$0 > 1}) >> >> >> >> >> >> Using "where:" has a very high potential for confusion, because >> >> >> "where" makes it sound like it runs the predicate against every >> >> >> single element, whereas "while" makes it clear that it stops >> >> >> evaluating elements once the predicate returns false. Or in other >> >> >> words, `drop(where: predicate)` looks like it should be equivalent >> >> >> to `filter({ !predicate($0) })`. >> >> > >> >> > Oops, I read your message too fast and missed the fact that you >> >> > changed the function name too in the very last line. >> >> >> >> And made the exact point that you made :-) >> > >> > Indeed. My apologies, I was trying to get through my email too fast and >> > ended up skimming too much. >> > >> >> > If we switched to `droppingPrefix(where:)` then we'd need to change >> >> > `dropFirst(_:)` as well. >> >> >> >> Yes, as I noted in my response to Erica, I would like to see some more >> >> design >> >> coherence in this whole area. I think >> >> >> >> xs.dropFirst() => xs.droppingFirst() >> >> xs.dropFirst(3) => xs.droppingPrefix(ofMaxLength: 3) >> >> >> >> I'm not wedded to “dropping,” especially because it has other >> >> connotations. Dmitri, Max, and I kicked around a bunch of other >> >> possibilities, e.g. >> >> >> >> sansPrefix >> >> withoutPrefix >> > >> > If we do rename this, I'm partial to basing it off of the word "skip", >> > e.g. skippingPrefix(), since that's similar to "drop" but doesn't have >> > the connotation of possibly mutating the receiver. That said, having a >> > first argument label "ofMaxLength:" seems overly verbose. Don't forget >> > that not everybody has the benefit of Xcode code completion when >> > writing Swift code. >> >> Me, for example. It needs to be at least “maxLength,” IMO, for >> clarity. “of” clarifies that you're not talking about the maximum >> length of the result... though I suppose it could be argued that that >> misinterpretation wouldn't make any sense. > > How about "count"? `skippingFirst(count:)` is not too long and it's > reasonably descriptive. > >> >> Anyway, we can't do all of that by the seat of our pants. I personally >> >> wouldn't want to go any further than s.dropPrefix(where: ...) without a >> >> new proposal/review. >> > >> > Agreed, anything beyond that needs a full review. So back to the >> > suggestion at hand. >> > >> > I wrote up a whole long explanation for why I still think "while" is >> > the better choice, and then I thought about how this impacts >> > `prefix(...:)` instead of `drop(...:)`, and in this context "where:" >> > makes more sense. `prefix(while:)` turns "prefix" from a noun into a >> > verb, >> >> Sorta, yeah. >> >> > and the verb meaning of "prefix" is not at all what we're doing with >> > this operation. But `prefix(where:)` is still a noun and makes >> > sense. And of course if we have `prefix(where:)` then it's a bit odd >> > to have `drop(while:)`, so we'd have to go with `drop(where:)` or >> > `dropPrefix(where:)`. So I guess I've now convinced myself while >> > writing this email that "where:" is the right choice :D >> >> :D >> >> >> > That said, given that we already have `dropFirst(_:)`, maybe we should >> > go with `dropFirst(where:)` instead of `dropPrefix(where:)`? Otherwise >> > it's a bit odd to have both "dropFirst" and "dropPrefix" as >> > names. >> >> Agreed, that might make a more reasonable interim stopping point. >> >> > Admittedly, this same argument applies to the existing `drop(while:)` >> > name too, and I don't have a great explanation for that beyond the >> > fact that I had a vague idea that dropFirst(_:) might be renamed to >> > drop(first:), though that can't actually happen because having both >> > dropFirst() and drop(first:) is hugely confusing, and it doesn't make >> > sense to rename dropFirst() to drop(). >> >> Ya just lost me in those twisty turns, sorry. > > What I meant was that `drop(while:)` doesn't match the existing > `dropFirst(_:)` name either (just as `dropPrefix` wouldn't), and my > reasons for proposing `drop(while:)` instead of `dropFirst(while:)` > were not well-founded. Okay, well I'm afraid I've lost the thread a bit here. IIRC, we made some good progress toward a consensus in this discussion, though. It would be awesome if you could pull it together into a proposal or at least a summary of the current status. I think it's still reasonable to imagine cleaning this area up for Swift 3. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
