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
