[Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

If we are discussing naming changes to reduce, here's my personal opinion:

* When I first encountered it, I understood exactly what it did because I knew
that term of art. If it was named sequence, I would have been
confused.

Nobody's proposing to rename reduce to sequence, FWIW.

···

on Thu May 05 2016, David Hart <swift-evolution@swift.org> wrote:

* If we are discussing name changes, I'd personally vote to change it
to fold. It is the other term of art used for it, and it makes unfold
work.

David

On 05 May 2016, at 22:39, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote:

        On May 5, 2016, at 1:03 PM, Erica Sadun <erica@ericasadun.com> wrote:

        On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote:

            Proposal link:
            https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

            Sequence.prefix(while:) & Sequence.drop(while:) - These are
            *accepted* as specified in revision 3 of the proposal.

        I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/
        `drop` pairs that linguistically matched.Nonetheless I'm gratified these
        are hopping into the language. That said, I'm going to put on my
        painters cap to consider selecting some exterior latex for the feature I
        was most looking forward to in this proposal:

        Core team writes:

            unfold(_:applying:) - This addition is *rejected* by the core team
            as written, but deserves more discussion in the community, and
            potentially could be the subject of a future proposal. The core team
            felt that the utility of this operation is high enough to be worth
            including in the standard library, but could not find an acceptable
            name for it. “unfold” is problematic, despite its precedence in
            other language, because Swift calls the corresponding operation
            “reduce” and not “fold”. No one could get excited about “unreduce”.
            “iterate” was also considered, but a noun is more appropriate than
            an verb in this case. Given the lack of a good name, the core team
            preferred to reject to let the community discuss it more.

        A few thoughts:

        * I'm not sure why a noun is more appropriate than a verb. Reduce isn't
        a noun, prefix isn't a noun, drop isn't a noun.

    I’m not a naming guru, but my understanding is that ‘reduce’ was picked
    because it was term of art (like map), which is what allowed the misuse of a
    verb.

    One idea that came out of the core team discussion was something like:

    sequence(from: 0) { $0 += 42 }

    Since it returns a sequence.

    -Chris

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

I don't know if it's considered too late at this point to rename 'reduce', but
I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. 'Fold'
is just as obvious a name as 'reduce', IMO (actually I even prefer
it).

It's not, IMO. “Reduce” was chosen deliberately over “fold” because we
think it is more in “common currency” among programmers, in no small
part to the notice that MapReduce has gotten.

···

on Fri May 06 2016, Cole Campbell <swift-evolution@swift.org> wrote:

I think changing it now with other source-breaking changes is better
than moving forward with 'reduce' and a corresponding function with a
confusing name. Fold/unfold would fit in beautifully with the
prefix/suffix pairings already in the standard library.

Cole

On May 6, 2016, at 1:29 AM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote:

    If we are discussing naming changes to reduce, here's my personal opinion:

    * When I first encountered it, I understood exactly what it did because I
    knew that term of art. If it was named sequence, I would have been confused.
    * If we are discussing name changes, I'd personally vote to change it to
    fold. It is the other term of art used for it, and it makes unfold work.

    David

    On 05 May 2016, at 22:39, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote:

            On May 5, 2016, at 1:03 PM, Erica Sadun <erica@ericasadun.com> > wrote:

            On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote:

                Proposal link:
                https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

                Sequence.prefix(while:) & Sequence.drop(while:) - These are
                *accepted* as specified in revision 3 of the proposal.

            I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/
            `drop` pairs that linguistically matched.Nonetheless I'm gratified
            these are hopping into the language. That said, I'm going to put on
            my painters cap to consider selecting some exterior latex for the
            feature I was most looking forward to in this proposal:

            Core team writes:

                unfold(_:applying:) - This addition is *rejected* by the core
                team as written, but deserves more discussion in the community,
                and potentially could be the subject of a future proposal. The
                core team felt that the utility of this operation is high enough
                to be worth including in the standard library, but could not
                find an acceptable name for it. “unfold” is problematic, despite
                its precedence in other language, because Swift calls the
                corresponding operation “reduce” and not “fold”. No one could
                get excited about “unreduce”. “iterate” was also considered, but
                a noun is more appropriate than an verb in this case. Given the
                lack of a good name, the core team preferred to reject to let
                the community discuss it more.

            A few thoughts:

            * I'm not sure why a noun is more appropriate than a verb. Reduce
            isn't a noun, prefix isn't a noun, drop isn't a noun.

        I’m not a naming guru, but my understanding is that ‘reduce’ was picked
        because it was term of art (like map), which is what allowed the misuse
        of a verb.

        One idea that came out of the core team discussion was something like:

        sequence(from: 0) { $0 += 42 }

        Since it returns a sequence.

        -Chris

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org
        https://lists.swift.org/mailman/listinfo/swift-evolution

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

Oops, I read your message too fast and missed the fact that you changed the function name too in the very last line.

If we switched to `droppingPrefix(where:)` then we'd need to change `dropFirst(_:)` as well.

-Kevin

···

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 <swift-evolution@swift.org> 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) })`.

Chris, as many people seem to be currently in favour of renaming reduce to fold to support unfold, should be write a proposal, or can the modification be accepted with less formality?

···

On 06 May 2016, at 15:11, Matthew Johnson <matthew@anandabits.com> wrote:

Sent from my iPad

On May 6, 2016, at 1:29 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

If we are discussing naming changes to reduce, here's my personal opinion:

* When I first encountered it, I understood exactly what it did because I knew that term of art. If it was named sequence, I would have been confused.
* If we are discussing name changes, I'd personally vote to change it to fold. It is the other term of art used for it, and it makes unfold work.

I have always preferred fold to reduce myself. If it solves a naming issue it might be worth making this change.

David

On 05 May 2016, at 22:39, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 5, 2016, at 1:03 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* as specified in revision 3 of the proposal.

I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/`drop` pairs that linguistically matched.Nonetheless I'm gratified these are hopping into the language. That said, I'm going to put on my painters cap to consider selecting some exterior latex for the feature I was most looking forward to in this proposal:

Core team writes:

unfold(_:applying:) - This addition is *rejected* by the core team as written, but deserves more discussion in the community, and potentially could be the subject of a future proposal. The core team felt that the utility of this operation is high enough to be worth including in the standard library, but could not find an acceptable name for it. “unfold” is problematic, despite its precedence in other language, because Swift calls the corresponding operation “reduce” and not “fold”. No one could get excited about “unreduce”. “iterate” was also considered, but a noun is more appropriate than an verb in this case. Given the lack of a good name, the core team preferred to reject to let the community discuss it more.

A few thoughts:

* I'm not sure why a noun is more appropriate than a verb. Reduce isn't a noun, prefix isn't a noun, drop isn't a noun.

I’m not a naming guru, but my understanding is that ‘reduce’ was picked because it was term of art (like map), which is what allowed the misuse of a verb.

One idea that came out of the core team discussion was something like:

   sequence(from: 0) { $0 += 42 }

Since it returns a sequence.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

   Proposal link:
   https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

   Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* as
   specified in revision 3 of the proposal.

I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/`drop` pairs
that linguistically matched.

I think building an API family around “prefix” and “suffix” that covers
this and other functionality is a great idea, and would make a great
proposal**

This whole area needs some design love. Among other things,

    s.prefix(4)

should be

    s.prefix(ofMaxLength: 4)

** though we haven't been able to completely eliminate the moral
equivalent of “drop” from the “dropWhile” function, whatever it's
eventually called, in any of our experiments

I'm sure that Kevin or I or some other proposalista could put together a quick fast-track rename request for

* suffix(n) -> Self.SubSequence // requires `n >= 0`, `n <= count`
* suffix(maxLength: n) -> Self.SubSequence // requires `n >= 0`
* suffix(while: predicate) -> Self.SubSequence
* prefix(n) -> Self.SubSequence
* prefix(maxLength: n) -> Self.SubSequence
* prefix(while: predicate) -> Self.SubSequence

Nonetheless I'm gratified these are hopping into the language. That

said, I'm going to put on my painters cap to consider selecting some
exterior latex for the feature I was most looking forward to in this
proposal:

Core team writes:

   unfold(_:applying:) - This addition is *rejected* by the core team as
   written, but deserves more discussion in the community, and potentially
   could be the subject of a future proposal. The core team felt that the
   utility of this operation is high enough to be worth including in the
   standard library, but could not find an acceptable name for it. “unfold” is
   problematic, despite its precedence in other language, because Swift calls
   the corresponding operation “reduce” and not “fold”. No one could get
   excited about “unreduce”. “iterate” was also considered, but a noun is more
   appropriate than an verb in this case. Given the lack of a good name, the
   core team preferred to reject to let the community discuss it more.

A few thoughts:

* I'm not sure why a noun is more appropriate than a verb. Reduce isn't a noun,
prefix isn't a noun, drop isn't a noun.

Can't let that one go by; prefix is definitely a noun :-)

I knew you'd point that out. It's not a noun when it's wearing its "I AM VERBING" t-shirt.

That aside, the prevailing sentiment is to rename reduce to `fold` and partner it with `unfold`.
(I personally prefer Chris's `sequence` because I think it better reflects how more Swift users will
use it (never for;;get; never sur;;render). But I recognize that terms of art have a strength of
momentum and familiarity.)

-- E

···

On May 6, 2016, at 6:27 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Thu May 05 2016, Erica Sadun <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote:

A random sampling of functions that generate non-Array sequences and their corresponding sequence type:

* Sequence.flatten() -> FlattenSequence
* Sequence.joined() -> JoinedSequence
* LazySequenceProtocol.map() -> LazyMapSequence
* LazySequenceProtocol.filter() -> LazyFilterSequence

-Kevin Ballard

···

On Fri, May 6, 2016, at 02:23 PM, Dave Abrahams via swift-evolution wrote:

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:

> One idea that came out of the core team discussion was something like:
>
> sequence(from: 0) { $0 += 42 }
>
> Since it returns a sequence.
>
> It just occurred to me that, if we follow existing naming conventions, this
> function would end up returning a value of type SequenceSequence :grin:.

Why do you think so?

We would *definitely* have to have a full review period to rename “reduce”. We specifically considered whether to go with “reduce” or “fold”, and chose reduce.

-Chris

···

On May 6, 2016, at 8:54 AM, David Hart <david@hartbit.com> wrote:

Chris, as many people seem to be currently in favour of renaming reduce to fold to support unfold, should be write a proposal, or can the modification be accepted with less formality?

>
>
> > 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 :-)

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

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.

···

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote:

--
Dave

Just giving credit where it’s due, but I believe that DaveA suggested ‘sequence’, I only propagated it. :-)

-Chris

···

On May 6, 2016, at 6:00 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

That aside, the prevailing sentiment is to rename reduce to `fold` and partner it with `unfold`.
(I personally prefer Chris's `sequence` because I think it better reflects how more Swift users will

        Proposal link:
        https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

        Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted*
        as
        specified in revision 3 of the proposal.

        I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/
        `drop` pairs
        that linguistically matched.

    I think building an API family around “prefix” and “suffix” that covers
    this and other functionality is a great idea, and would make a great
    proposal**

    This whole area needs some design love. Among other things,

    s.prefix(4)

    should be

    s.prefix(ofMaxLength: 4)

    ** though we haven't been able to completely eliminate the moral
    equivalent of “drop” from the “dropWhile” function, whatever it's
    eventually called, in any of our experiments

I'm sure that Kevin or I or some other proposalista could put together a quick
fast-track rename request for

* suffix(n) -> Self.SubSequence // requires `n >= 0`, `n <= count`
* suffix(maxLength: n) -> Self.SubSequence // requires `n >= 0`
* suffix(while: predicate) -> Self.SubSequence
* prefix(n) -> Self.SubSequence
* prefix(maxLength: n) -> Self.SubSequence
* prefix(while: predicate) -> Self.SubSequence

Not *too* quick, please. This area needs some thought and attention. :-)

    Nonetheless I'm gratified these are hopping into the language. That

    said, I'm going to put on my painters cap to consider selecting some
        exterior latex for the feature I was most looking forward to in this
        proposal:

        Core team writes:

        unfold(_:applying:) - This addition is *rejected* by the core team as
        written, but deserves more discussion in the community, and potentially
        could be the subject of a future proposal. The core team felt that the
        utility of this operation is high enough to be worth including in the
        standard library, but could not find an acceptable name for it. “unfold”
        is
        problematic, despite its precedence in other language, because Swift
        calls
        the corresponding operation “reduce” and not “fold”. No one could get
        excited about “unreduce”. “iterate” was also considered, but a noun is
        more
        appropriate than an verb in this case. Given the lack of a good name,
        the
        core team preferred to reject to let the community discuss it more.

        A few thoughts:

        * I'm not sure why a noun is more appropriate than a verb. Reduce isn't
        a noun,
        prefix isn't a noun, drop isn't a noun.

    Can't let that one go by; prefix is definitely a noun :-)

I knew you'd point that out. It's not a noun when it's wearing its "I AM
VERBING" t-shirt.

It only ever wears SHIRTFRONT+IN... - Did you enter it correctly?

That aside, the prevailing sentiment is to rename reduce to `fold` and partner
it with `unfold`.
(I personally prefer Chris's `sequence` because I think it better reflects how
more Swift users will
use it (never for;;get; never sur;;render).

That's not “unfold,” FWIW.

···

on Fri May 06 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On May 6, 2016, at 6:27 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote:
    on Thu May 05 2016, Erica Sadun > <swift-evolution@swift.org> wrote:
        On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote:

But I recognize that terms of art have a strength of momentum and
familiarity.)

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

I don't know if it's considered too late at this point to rename 'reduce', but
I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. 'Fold'
is just as obvious a name as 'reduce', IMO (actually I even prefer
it).

It's not, IMO. “Reduce” was chosen deliberately over “fold” because we
think it is more in “common currency” among programmers, in no small
part to the notice that MapReduce has gotten.

I was guessing this was the rationale. But if it’s not too late and “fold” solves the “unfold” naming problem maybe we that balances out the equation.

Which name do you think best communicates the essence of the operation? IMO “fold” does a much better job of this.

···

On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri May 06 2016, Cole Campbell <swift-evolution@swift.org> wrote:

I think changing it now with other source-breaking changes is better
than moving forward with 'reduce' and a corresponding function with a
confusing name. Fold/unfold would fit in beautifully with the
prefix/suffix pairings already in the standard library.

Cole

On May 6, 2016, at 1:29 AM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote:

   If we are discussing naming changes to reduce, here's my personal opinion:

   * When I first encountered it, I understood exactly what it did because I
   knew that term of art. If it was named sequence, I would have been confused.
   * If we are discussing name changes, I'd personally vote to change it to
   fold. It is the other term of art used for it, and it makes unfold work.

   David

   On 05 May 2016, at 22:39, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote:

           On May 5, 2016, at 1:03 PM, Erica Sadun <erica@ericasadun.com> >> wrote:

           On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote:

               Proposal link:
               https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

               Sequence.prefix(while:) & Sequence.drop(while:) - These are
               *accepted* as specified in revision 3 of the proposal.

           I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/
           `drop` pairs that linguistically matched.Nonetheless I'm gratified
           these are hopping into the language. That said, I'm going to put on
           my painters cap to consider selecting some exterior latex for the
           feature I was most looking forward to in this proposal:

           Core team writes:

               unfold(_:applying:) - This addition is *rejected* by the core
               team as written, but deserves more discussion in the community,
               and potentially could be the subject of a future proposal. The
               core team felt that the utility of this operation is high enough
               to be worth including in the standard library, but could not
               find an acceptable name for it. “unfold” is problematic, despite
               its precedence in other language, because Swift calls the
               corresponding operation “reduce” and not “fold”. No one could
               get excited about “unreduce”. “iterate” was also considered, but
               a noun is more appropriate than an verb in this case. Given the
               lack of a good name, the core team preferred to reject to let
               the community discuss it more.

           A few thoughts:

           * I'm not sure why a noun is more appropriate than a verb. Reduce
           isn't a noun, prefix isn't a noun, drop isn't a noun.

       I’m not a naming guru, but my understanding is that ‘reduce’ was picked
       because it was term of art (like map), which is what allowed the misuse
       of a verb.

       One idea that came out of the core team discussion was something like:

       sequence(from: 0) { $0 += 42 }

       Since it returns a sequence.

       -Chris

       _______________________________________________
       swift-evolution mailing list
       swift-evolution@swift.org
       https://lists.swift.org/mailman/listinfo/swift-evolution

   _______________________________________________
   swift-evolution mailing list
   swift-evolution@swift.org
   https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Oh! I get it.

···

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:

On Fri, May 6, 2016, at 02:23 PM, Dave Abrahams via swift-evolution wrote:

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:

> One idea that came out of the core team discussion was something like:
>
> sequence(from: 0) { $0 += 42 }
>
> Since it returns a sequence.
>
> It just occurred to me that, if we follow existing naming conventions, this
> function would end up returning a value of type SequenceSequence :grin:.

Why do you think so?

A random sampling of functions that generate non-Array sequences and their corresponding sequence type:

* Sequence.flatten() -> FlattenSequence
* Sequence.joined() -> JoinedSequence
* LazySequenceProtocol.map() -> LazyMapSequence
* LazySequenceProtocol.filter() -> LazyFilterSequence

--
Dave

I don't know if it's considered too late at this point to rename 'reduce', but
I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. 'Fold'
is just as obvious a name as 'reduce', IMO (actually I even prefer
it).

It's not, IMO. “Reduce” was chosen deliberately over “fold” because we
think it is more in “common currency” among programmers, in no small
part to the notice that MapReduce has gotten.

I was guessing this was the rationale. But if it’s not too late and
“fold” solves the “unfold” naming problem maybe we that balances out
the equation.

Personally, I'm not confident “unfold” would be considered to meet the
utility bar, even if we changed the name of “reduce,” FWIW.

Which name do you think best communicates the essence of the
operation? IMO “fold” does a much better job of this.

Personally I think “accumulate” does that better than either name, but
it doesn't matter. What matters, IMO, is what more people will be
familiar with.

···

on Fri May 06 2016, Matthew Johnson <swift-evolution@swift.org> wrote:

On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri May 06 2016, Cole Campbell <swift-evolution@swift.org> wrote:

I think changing it now with other source-breaking changes is better
than moving forward with 'reduce' and a corresponding function with a
confusing name. Fold/unfold would fit in beautifully with the
prefix/suffix pairings already in the standard library.

Cole

On May 6, 2016, at 1:29 AM, David Hart via swift-evolution >>> <swift-evolution@swift.org> wrote:

   If we are discussing naming changes to reduce, here's my personal opinion:

   * When I first encountered it, I understood exactly what it did because I
   knew that term of art. If it was named sequence, I would have been confused.
   * If we are discussing name changes, I'd personally vote to change it to
   fold. It is the other term of art used for it, and it makes unfold work.

   David

   On 05 May 2016, at 22:39, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org> wrote:

           On May 5, 2016, at 1:03 PM, Erica Sadun <erica@ericasadun.com> >>> wrote:

           On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org> wrote:

               Proposal link:
               https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

               Sequence.prefix(while:) & Sequence.drop(while:) - These are
               *accepted* as specified in revision 3 of the proposal.

           I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/
           `drop` pairs that linguistically matched.Nonetheless I'm gratified
           these are hopping into the language. That said, I'm going to put on
           my painters cap to consider selecting some exterior latex for the
           feature I was most looking forward to in this proposal:

           Core team writes:

               unfold(_:applying:) - This addition is *rejected* by the core
               team as written, but deserves more discussion in the community,
               and potentially could be the subject of a future proposal. The
               core team felt that the utility of this operation is high enough
               to be worth including in the standard library, but could not
               find an acceptable name for it. “unfold” is problematic, despite
               its precedence in other language, because Swift calls the
               corresponding operation “reduce” and not “fold”. No one could
               get excited about “unreduce”. “iterate” was also considered, but
               a noun is more appropriate than an verb in this case. Given the
               lack of a good name, the core team preferred to reject to let
               the community discuss it more.

           A few thoughts:

           * I'm not sure why a noun is more appropriate than a verb. Reduce
           isn't a noun, prefix isn't a noun, drop isn't a noun.

       I’m not a naming guru, but my understanding is that ‘reduce’ was picked
       because it was term of art (like map), which is what allowed the misuse
       of a verb.

       One idea that came out of the core team discussion was something like:

       sequence(from: 0) { $0 += 42 }

       Since it returns a sequence.

       -Chris

       _______________________________________________
       swift-evolution mailing list
       swift-evolution@swift.org
       https://lists.swift.org/mailman/listinfo/swift-evolution

   _______________________________________________
   swift-evolution mailing list
   swift-evolution@swift.org
   https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

>> >
>> >
>> > > 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.

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, 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

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. 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().

-Kevin Ballard

···

On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote:

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote:

As I said to Chris in an off-list email, unfold() was actually the function that I was the most excited about in the proposal, because it allows for a very elegant solution to a variety of looping needs, especially now that we've gotten rid of the C-style for loops. One example of its use is something like

  // Iterate over self.view and all its ancestor views.
  for view in unfold(self.view, applying: { $0.superview }) {
      // ...
  }

In fact, just today I hit this exact issue and wished I had unfold(). This same pattern works for any case where an object has a property of the same type and you want to walk the entire chain, such as UIViewController.presentingViewController, or NSError.userInfo[NSUnderlyingErrorKey].

It also integrates very nicely with the other sequence methods, including drop(while:) and prefix(while:). For example:

  // Iterate over someView and all its ancestors, stopping at self.view
  for view in unfold(someView, applying: { $0.superview }).prefix(while: { $0 !== self.view }) {
      // ...
  }

Incidentally, I tried writing up an example of using the stateful version to reimplement zip(), but it ended up being a good argument in favor of the suggestion someone (maybe you?) had for turning the state into an inout parameter.

-Kevin Ballard

···

On Fri, May 6, 2016, at 06:15 PM, Dave Abrahams via swift-evolution wrote:

on Fri May 06 2016, Matthew Johnson <swift-evolution@swift.org> wrote:

>> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
>>
>>
>> on Fri May 06 2016, Cole Campbell <swift-evolution@swift.org> wrote:
>>
>>> I don't know if it's considered too late at this point to rename 'reduce', but
>>> I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. 'Fold'
>>> is just as obvious a name as 'reduce', IMO (actually I even prefer
>>> it).
>>
>> It's not, IMO. “Reduce” was chosen deliberately over “fold” because we
>> think it is more in “common currency” among programmers, in no small
>> part to the notice that MapReduce has gotten.
>
> I was guessing this was the rationale. But if it’s not too late and
> “fold” solves the “unfold” naming problem maybe we that balances out
> the equation.

Personally, I'm not confident “unfold” would be considered to meet the
utility bar, even if we changed the name of “reduce,” FWIW.

I don't know if it's considered too late at this point to rename 'reduce', but
I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. 'Fold'
is just as obvious a name as 'reduce', IMO (actually I even prefer
it).

It's not, IMO. “Reduce” was chosen deliberately over “fold” because we
think it is more in “common currency” among programmers, in no small
part to the notice that MapReduce has gotten.

I was guessing this was the rationale. But if it’s not too late and
“fold” solves the “unfold” naming problem maybe we that balances out
the equation.

Personally, I'm not confident “unfold” would be considered to meet the
utility bar, even if we changed the name of “reduce,” FWIW.

Which name do you think best communicates the essence of the
operation? IMO “fold” does a much better job of this.

Personally I think “accumulate” does that better than either name, but
it doesn't matter. What matters, IMO, is what more people will be
familiar with.

Fair enough.

FWIW, the reason I like fold is that it helps me to visualize the process mentally.

···

On May 6, 2016, at 8:15 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri May 06 2016, Matthew Johnson <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri May 06 2016, Cole Campbell <swift-evolution@swift.org> wrote:

I think changing it now with other source-breaking changes is better
than moving forward with 'reduce' and a corresponding function with a
confusing name. Fold/unfold would fit in beautifully with the
prefix/suffix pairings already in the standard library.

Cole

On May 6, 2016, at 1:29 AM, David Hart via swift-evolution >>>> <swift-evolution@swift.org> wrote:

  If we are discussing naming changes to reduce, here's my personal opinion:

  * When I first encountered it, I understood exactly what it did because I
  knew that term of art. If it was named sequence, I would have been confused.
  * If we are discussing name changes, I'd personally vote to change it to
  fold. It is the other term of art used for it, and it makes unfold work.

  David

  On 05 May 2016, at 22:39, Chris Lattner via swift-evolution >>>> <swift-evolution@swift.org> wrote:

          On May 5, 2016, at 1:03 PM, Erica Sadun <erica@ericasadun.com> >>>> wrote:

          On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution >>>> <swift-evolution@swift.org> wrote:

              Proposal link:
              https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

              Sequence.prefix(while:) & Sequence.drop(while:) - These are
              *accepted* as specified in revision 3 of the proposal.

          I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/
          `drop` pairs that linguistically matched.Nonetheless I'm gratified
          these are hopping into the language. That said, I'm going to put on
          my painters cap to consider selecting some exterior latex for the
          feature I was most looking forward to in this proposal:

          Core team writes:

              unfold(_:applying:) - This addition is *rejected* by the core
              team as written, but deserves more discussion in the community,
              and potentially could be the subject of a future proposal. The
              core team felt that the utility of this operation is high enough
              to be worth including in the standard library, but could not
              find an acceptable name for it. “unfold” is problematic, despite
              its precedence in other language, because Swift calls the
              corresponding operation “reduce” and not “fold”. No one could
              get excited about “unreduce”. “iterate” was also considered, but
              a noun is more appropriate than an verb in this case. Given the
              lack of a good name, the core team preferred to reject to let
              the community discuss it more.

          A few thoughts:

          * I'm not sure why a noun is more appropriate than a verb. Reduce
          isn't a noun, prefix isn't a noun, drop isn't a noun.

      I’m not a naming guru, but my understanding is that ‘reduce’ was picked
      because it was term of art (like map), which is what allowed the misuse
      of a verb.

      One idea that came out of the core team discussion was something like:

      sequence(from: 0) { $0 += 42 }

      Since it returns a sequence.

      -Chris

      _______________________________________________
      swift-evolution mailing list
      swift-evolution@swift.org
      https://lists.swift.org/mailman/listinfo/swift-evolution

  _______________________________________________
  swift-evolution mailing list
  swift-evolution@swift.org
  https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Thanks for the credit, but I think it goes to Joe Groff. He's been
suggesting we do the same thing for reduce().

···

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:

As I said to Chris in an off-list email, unfold() was actually the
function that I was the most excited about in the proposal, because it
allows for a very elegant solution to a variety of looping needs,
especially now that we've gotten rid of the C-style for loops. One
example of its use is something like

  // Iterate over self.view and all its ancestor views.
  for view in unfold(self.view, applying: { $0.superview }) {
      // ...
  }

In fact, just today I hit this exact issue and wished I had
unfold(). This same pattern works for any case where an object has a
property of the same type and you want to walk the entire chain, such
as UIViewController.presentingViewController, or
NSError.userInfo[NSUnderlyingErrorKey].

It also integrates very nicely with the other sequence methods,
including drop(while:) and prefix(while:). For example:

  // Iterate over someView and all its ancestors, stopping at
self.view
  for view in unfold(someView, applying: { $0.superview
}).prefix(while: { $0 !== self.view }) {
      // ...
  }

Incidentally, I tried writing up an example of using the stateful
version to reimplement zip(), but it ended up being a good argument in
favor of the suggestion someone (maybe you?) had for turning the state
into an inout parameter.

--
Dave

>> >
>> >
>> > > 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.

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.

···

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:

On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote:

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote:

--
Dave

>>
>>
>
>> >> >
>> >> >
>> >> > > 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.

-Kevin Ballard

···

On Fri, May 6, 2016, at 07:33 PM, Dave Abrahams via swift-evolution wrote:

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:
> On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote:
>> on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote:

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.

···

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:

On Fri, May 6, 2016, at 07:33 PM, Dave Abrahams via swift-evolution wrote:

on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> wrote:

> On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote:
>>

>> on Fri May 06 2016, Kevin Ballard <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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.

--
Dave