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

[Andrei Alexandrescu]

On 2/14/13 6:58 AM, Jacob Carlborg wrote:
> On 2013-02-14 10:46, Walter Bright wrote:
>
>> I don't understand why one would go around the horn to just check for
>> !empty.
>
> I've tried to explain, it shows what the intention is.
>
> Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty"
> I like to use "str.any".
>
> It's not a big deal but I would need to change quite a lot of code if
> "str.any" isn't allowed.

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.

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.

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.


Andrei