Why any! with map! is not working here

[Jonathan M Davis]

On Thursday, June 6, 2019 10:21:39 PM MDT rnd via Digitalmars-d-learn wrote:
> On Thursday, 6 June 2019 at 21:32:11 UTC, Jonathan M Davis wrote:
> > If any is not given a predicate, it defaults to just checking
> > whether the element itself is true (requiring that the element
> > be bool), which is why Marco's suggestion works, but it's a
> > rather odd way to write the code and will be less efficient
> > unless the optimizer manages to optimize away the extra work
> > involved with having map.
> >
> > However, in general, with D, you're not going to find that
> > there is only one way to do things. There are going to tend to
> > be many different approaches to solve the same problem. D code
> > is often simple because of the powerful language constructs and
> > standard library, but it makes no attempt to make it so that
> > there's only one way to do things - especially when you start
> > combining stuff to do whatever it is you're trying to do.
> >
> > - Jonathan M Davis
>
> Maybe one of these methods can be made 'official' or 'idiomatic':

If you're looking for the language or library to tell you exactly how you
should be doing things, then you've come to the wrong language. There are
approaches that are more idiomatic than others (e.g. range-based solutions
are usually favored), but D is purposefully designed to be multi-paradigm,
and there are going to be very different approaches to a problem where each
approach is equally viable or where one approach is better in some
situations, whereas another is better in others. And once we're dealing with
combining functions to get a job done, it would actually be very difficult
to try to claim that a particular combination of them is the correct way.
Which functions make sense is going to depend on the task, and it's
naturally going to be possible to combine functions in different ways to get
the same result.

> > any!pred(ss);
> > ss.any!pred();
> > ss.any!pred;
>
> This will reduce learning burden on beginners.

We're not going to make requirements over that sort of thing any more than
we're going to require that all D code use a particular bracing style. D
provides the tools needed to get stuff done, but for the most part, it
doesn't try to tell you how to use them. There are some best practices for
how to go about things in D, but that's not usually about stuff like coding
style, and it really covers a fairly small number of the decisions that a D
programmer has to make. The closest that you're going to get on coding style
is the official style guide ( https://dlang.org/dstyle.html ), and aside
from some Phobos-specific requirements at the bottom, it's mostly just about
how you name public symbols so that there's some consistency when using
other people's libraries.

For best practices, you're going to get things like "use ranges" and "make
your imports local." You're not going to be told how to format your code or
which set of functions you should be using to solve a particular problem.

- Jonathan M Davis