Remove complex and imaginary types?

[Pragma]

Yigal Chripun Wrote:

> I think the solution should be a more general approach:
> a) use the functional approach with mapping and filter functions. 
> According to the article in the quote such an implementation requires
> full closures which D 2.x has.
> this could be implemented in a library.
> so with that approach I could use the ruby way of:
> ---
> collection.each BlockOfCode
> 
> or in D:
> 
> collection.each ((item a) {...code...});
> 
> or with free functions:
> 
> map(item[], (item a) {...code...});
> ---
> b) for iterations where order is important, maybe implement generators 
> (also mentioned in the above article).
> 
> just my 2 cents.
> 
> --Yigal
> 
My $0.02:

IMO, were D conceived as a functional language, or one that was far more FP oriented, this probably would have been included early on.  True closures are going to open up a *lot* of possibilities.

However, D is much more procedural in it's grammar to make the outright removal of foreach() a good idea; I think it's kind of part of D's heritage and DNA to an extent.  Comfort, familiarity and ease-of-use with foreach() trumps normalizing the language in favor of a more general construct.  

Also D has a foreach() construct that is hands-down better than what Java has, so why throw it away?

That said, you're right about the library approach.  I'd love to use that in my code when/if the opportunity presents itself.  Python's map() has spoiled me so.