Jump to page: 1 2
Thread overview
[Issue 4535] std.range could have a takeWhile!pred(range) function
Jul 10
RazvanN
Jul 11
RazvanN
Jul 11
greenify
Jul 12
RazvanN
October 14, 2016
https://issues.dlang.org/show_bug.cgi?id=4535

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |bootcamp
           Assignee|andrei@erdani.com           |nobody@puremagic.com

--
July 10
https://issues.dlang.org/show_bug.cgi?id=4535

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |razvan.nitu1305@gmail.com
         Resolution|---                         |INVALID

--
July 11
https://issues.dlang.org/show_bug.cgi?id=4535

timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #5 from timon.gehr@gmx.ch ---
This enhancement requests is not "INVALID".

--
July 11
https://issues.dlang.org/show_bug.cgi?id=4535

--- Comment #6 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(In reply to timon.gehr from comment #5)
> This enhancement requests is not "INVALID".

Closing it as "won't fix" would be more appropriate. We already have until, which does what takeWhile would do - it just has an arguably worse name. Is there something about until that does not fulfill what takeWhile would do? While I don't think that it existed when this issue was opened, there is now an overload for until that does not take a sentinel and AFAIK does exactly what takeWhile would do.

--
July 11
https://issues.dlang.org/show_bug.cgi?id=4535

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--
July 11
https://issues.dlang.org/show_bug.cgi?id=4535

timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #7 from timon.gehr@gmx.ch ---
(In reply to Jonathan M Davis from comment #6)
> (In reply to timon.gehr from comment #5)
> > This enhancement requests is not "INVALID".
> 
> Closing it as "won't fix" would be more appropriate.

Perhaps. There is nothing about the suggestion that is "invalid" though.

> We already have until,
> which does what takeWhile would do - it just has an arguably worse name. Is
> there something about until that does not fulfill what takeWhile would do?

In many (most?) circumstances it is just silly to have to specify a condition to detect the first element that you do /not/ want included in your range. There is a reason 'filter' keeps the elements for which the predicate evaluates to 'true' and not those for which it evaluates to 'false'.

> While I don't think that it existed when this issue was opened, there is now an overload for until that does not take a sentinel and AFAIK does exactly what takeWhile would do.

I guess one way to use it is to create one's own takeWhile function.

--
July 11
https://issues.dlang.org/show_bug.cgi?id=4535

greenify <greeenify@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greeenify@gmail.com

--
July 11
https://issues.dlang.org/show_bug.cgi?id=4535

--- Comment #8 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(In reply to timon.gehr from comment #7)
> (In reply to Jonathan M Davis from comment #6)
> > We already have until,
> > which does what takeWhile would do - it just has an arguably worse name. Is
> > there something about until that does not fulfill what takeWhile would do?
> 
> In many (most?) circumstances it is just silly to have to specify a condition to detect the first element that you do /not/ want included in your range. There is a reason 'filter' keeps the elements for which the predicate evaluates to 'true' and not those for which it evaluates to 'false'.

True, in may circumstances, having to negate your predicate is annoying, but when I tried to get takeWhile and dropWhile added on that basis several years ago, Andrei vetoed it, because it was trivial to just negate the predicate, and he's right. It may be a bit annoying, but it is trivial.

There's still some value in takeWhile on the basis of user friendliness if you have a predicate that would need to be negated to be used with until, and some folks do go looking for takeWhile and fail to find until (though until's docs do now mention that it's essentially takeWhile), but we do generally try to avoid adding extremely simple functions to Phobos, and if takeWhile or dropWhile were added, they would almost certainly be added as simple wrappers around until and find respectively.

So, unless someone can convince Andrei that having to negate the predicate is onerous enough to merit adding the opposite functions and/or the negated versions are more common than what we have, I think that it's pretty clear that neither takeWhile nor dropWhile are going to be added, because we already have the functionality that they provide, even if it does require that you sometimes negate your predicate.

--
July 12
https://issues.dlang.org/show_bug.cgi?id=4535

--- Comment #9 from timon.gehr@gmx.ch ---
(In reply to Jonathan M Davis from comment #8)
> (In reply to timon.gehr from comment #7)
> > (In reply to Jonathan M Davis from comment #6)
> > > We already have until,
> > > which does what takeWhile would do - it just has an arguably worse name. Is
> > > there something about until that does not fulfill what takeWhile would do?
> > 
> > In many (most?) circumstances it is just silly to have to specify a condition to detect the first element that you do /not/ want included in your range. There is a reason 'filter' keeps the elements for which the predicate evaluates to 'true' and not those for which it evaluates to 'false'.
> 
> True, in may circumstances, having to negate your predicate is annoying, but
> when I tried to get takeWhile and dropWhile added on that basis several
> years ago, Andrei vetoed it, because it was trivial to just negate the
> predicate, and he's right. It may be a bit annoying, but it is trivial.
> ...

I'm not using Phobos in order to get annoyed by trivialities, and neither are
the people who will need to read my code.
It is not inadvisable to not condone double-negation in text for which we want
to avoid that it does not fail to be hard to digest.


> There's still some value in takeWhile on the basis of user friendliness if
> you have a predicate that would need to be negated to be used with until,
> and some folks do go looking for takeWhile and fail to find until (though
> until's docs do now mention that it's essentially takeWhile), but we do
> generally try to avoid adding extremely simple functions to Phobos, and if
> takeWhile or dropWhile were added, they would almost certainly be added as
> simple wrappers around until and find respectively.
> ...

User friendliness, reader friendliness, name standardization.

> So, unless someone can convince Andrei that having to negate the predicate is onerous enough to merit adding the opposite functions and/or the negated versions are more common than what we have,

It is controversial that takeWhile is more commonly useful that until?

> I think that it's pretty clear
> that neither takeWhile nor dropWhile are going to be added, because we
> already have the functionality that they provide, even if it does require
> that you sometimes negate your predicate.

It is wrong to think in terms of "functionality" for combiners used in a
functional program.
Every additional negation makes a one-liner harder to understand even if it
inconveniences its construction in a minor (but still, unnecesssary) way.

--
July 12
https://issues.dlang.org/show_bug.cgi?id=4535

--- Comment #10 from RazvanN <razvan.nitu1305@gmail.com> ---
PR : https://github.com/dlang/phobos/pull/5563

We should either close this or work on the PR.

--
« First   ‹ Prev
1 2