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
