What's missing from Phobos for Orbit (package manager)

[Jacob Carlborg]

On 2013-02-14 13:42, Andrei Alexandrescu wrote:

> I understand. Adding functions such as the negation of empty becomes a
> judgment call.
>
> Phobos does have quite a few simple functions that could be easily
> achieved through expression composition (e.g. trim) or statement
> composition (e.g. enforce). So again it's all a matter of judgment.
>
> Walter and I don't consider the negation of empty as useful enough to
> receive a name.

Since you mention Ruby below I can say that D/Phobos could have some 
more of these convenience methods. Especially if we would like to 
consider D usable as a scripting language.

> There's been a talk (discussed on reddit) on Ruby by a prominent member
> of that community. At a point the talk addressed the awesomeness of
> "unless" (the negation of "if") - the presence of that near-useless
> device was seen as a human touch in a world of cold logic. I found the
> argument rather weak, unless we consider creating clutter and wasting
> means part of the human touch.
>
> Besides, as often happens with such constructs, there are pitfalls and
> subsequent dos and donts about "unless" that more than undo whatever
> utility and expressiveness it may have. The first two hits for
> https://www.google.com/search?q=ruby%20unless describe "unless, the
> abused ruby conditional" and "making sense of ruby's unless". Turns out
> "unless" should not be used with "else" or at the beginning of a statement.
>
> Perl also has "unless", and after years of experience the Perl Best
> Practices guide
> http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf
> curtly says: "Don’t use unless or until at all." If Perl shuns a
> keyword, that's bound to say something.

"unless" is kind of a useless keyword. I can tell you that I have used 
"any" a lot more than I have used "unless".

> D has "any" (previously an overload of "canFind") as an algorithm that
> finds whether at least one element of a range satisfies a condition,
> otherwise writable as "!r.find!(a => condition).empty". The
> convenience/mechanics/generality of the construct was enough
> justification to add the algorithm. To claim that D already has the
> negation of empty because one can write "r.any(a => true)" is, in my
> opinion, an ill-posed argument.

I just thought that we could add a default predicate to the "any" function.

-- 
/Jacob Carlborg