July 17, 2017
https://issues.dlang.org/show_bug.cgi?id=4535

Andrei Alexandrescu <andrei@erdani.com> changed:

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

--- Comment #11 from Andrei Alexandrescu <andrei@erdani.com> ---
I don't think it's wise to add HOFs of which predicates just negate that of other HOFs. I'm convinced that any programmer can be reasonably expected to figure negation out without problems, otherwise we're liable to experiments a la Perl/Ruby "unless" as a negation of "if". My understanding is that the usefulness of such is still a matter of debate and style differences within the respective communities.

I'll close this, please reopen if there are qualitatively new arguments.

--
July 14, 2019
https://issues.dlang.org/show_bug.cgi?id=4535

KnightMare <black80@bk.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |black80@bk.ru
         Resolution|WONTFIX                     |---

--- Comment #12 from KnightMare <black80@bk.ru> ---
(In reply to Andrei Alexandrescu from comment #11)
> I don't think it's wise to add HOFs of which predicates just negate that of other HOFs. I'm convinced that any programmer can be reasonably expected to figure negation out without problems, otherwise we're liable to experiments a la Perl/Ruby "unless" as a negation of "if". My understanding is that the usefulness of such is still a matter of debate and style differences within the respective communities.
> 
> I'll close this, please reopen if there are qualitatively new arguments.

1)
word "until" is doubt word for me (I am non English native)
when I hear "until noon" I am in doubt cuz it means "they will care something
before noon" or "when noon will come then they take care of it"

2)
until accepts sentinel that don't needed for explicit predicate in most time

3)
with explicit predicate that accepts 2 args it adds another doubt about arg
order: what 1st arg - element or sentinel?

for example I want sequence of fibonacci numbers less than 100
fibs.until!((a,b) => !(a<b))( 100 ).each!writeln;
//           ^ element is 1st or 2nd? lets go to look docs
//                      ^     ^   when I have explicit predicate why I need
sentinel as arg at all? I can put it as literal to predicate
//                     ^ condition is negate of my wish. yes I can negate
condition for IF/FOR/WHILE cases but with doubts for UNTIL its make me crazy. I
should write some test in REPL just to make sure that I am not failed with such
simple condition. why that?

totally its too complicated for such simple thing:
fibs.takeWhile!(e => e<100).each!writeln;
or even shorter
fibs.takeWhile!"e<100".each!writeln;

and we have already take, takeOne, takeNone, takeExactly. why do not just to add this one to set of same named algos?

so please add takeWhile/skipWhile algos to library cuz its clear and shorter
and without_unnecessary_negate (haha?) and without_unclear (haha again?) args
order

===========================

another thing that I want to tell on the example of next comment

> Jonathan M Davis
> 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.

well, last sentence is wrong: "until" jast boomboom brains instead "takeWhile". see my arguments above.

imo u have some preset that makes you decide that only one name should exists
for things that somehow likely. well, turn around, u can see cars, people,
things they are all same but they are all are different.
its not a sin to have aliases for likely things or functions. people comes to D
from other langs, they fill more comfort with names to which they are
accustomed. and takeWhile and skipWhile is most useful names to enumerate
elements for true predicate. (python, .net...)
when u try find method like for such task i am sure u will type "dlang take
while" not "dlang until" cuz "until" is any f*king blog word. what u expect to
find with it?
if u like "until" then use it, but please don't prohibit things that more
comfortable to others.
and "until" and "takeWhile" and "skipWhile" and "drop" can coexists in one
library if u free your brain from some inexplicable preset.
just add aliases with right predicates to most useful algos and links such
aliases to each other in documentation when they are 100% same. "until" and
"takeWhile" is not same for 100% probably only for -60% (minus for negate
condition)

PS "skip" is more clear/pure name for "drop" cuz we are skipping element not droping it to somewhere (another range or ground floor) maybe for English native is same thing, but I dont know 100 meanings for one simple word.

PS2 "until" is still useful for non literal sentinel or with default implicit predicate

--
July 14, 2019
https://issues.dlang.org/show_bug.cgi?id=4535

--- Comment #13 from KnightMare <black80@bk.ru> ---
(In reply to KnightMare from comment #12)

my version of wrapping "until" to "takeWhile":
auto takeWhile( alias F, R )( R r ) {
    struct NR {
        bool isEmpty = false;
        this( bool e ) { isEmpty = e; }

        bool empty() { return isEmpty; }
        auto front() { return r.front; }
        void popFront() {
            if (isEmpty) return;
            r.popFront;
            isEmpty = isEmpty || !F( r.front);
        }
    }
    return NR( r.empty );
}

I was hinted at IRC channel that it can be simpler:
> auto takeWhile( alias pred, A...)( A a) { return until!( not!pred)( a); }

and no string version yet like .takeWhile!"n<7".

do u see that how many code for not familiar users with metaprogramming in D?
u should understand that most of programmers don't know every aspect in D, they
try to use same things that they are used before same way as before, they have
some expectations, they want more clearness without new strong headache that
exists in learning of non-trivail programming language.
so, adding known aliases and simpler versions of algos to Phobos u make simpler
life for other non-meta-gurus.

imo nobody will search "until" for enumerating ranges when they are look at 4 "take..." and don't see "take with predicate".. yes, they have some thoughts that should exists something with predicate - it is so expected.. but it new research for nothing when they are researching cure for cancer for example.

--
August 31, 2022
https://issues.dlang.org/show_bug.cgi?id=4535

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

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

--- Comment #14 from RazvanN <razvan.nitu1305@gmail.com> ---
This has been discussed a number of times and the conclusion is that this won't be "fixed". Anyone that is not satisfied with until can trivially implement a takeWhile wrapper.

--
August 31, 2022
https://issues.dlang.org/show_bug.cgi?id=4535

--- Comment #15 from timon.gehr@gmx.ch ---
I am not satisfied with the proposed workaround, because this function should obviously be standardized. Please don't suggest that I should be "satisfied" or that my concern is "trivial". It's not respectful. Thanks.

--
1 2
Next ›   Last »