Remove complex and imaginary types?

[Yigal Chripun]

naryl wrote:
> On Fri, 11 Jan 2008 04:03:46 +0300, bearophile 
> <bearophileHUGS at lycos.com> wrote:
> 
>> naryl:
>>> Why don't we remove or at least shorten foreach_reverse too?
>>
>> Removing: -1. It's actually useful (I'd like to see more iteration 
>> constructs, not less).
>>
>> Shortening: it's long, so maybe yes, if you/someons find(s) something 
>> better. Do you have some suggestions?
>>
>> Bye,
>> bearophile
> 
> Let me quote Regan Heath:
> 
> In article <opsmol1osx23k2f5 ally>, Regan Heath says...
>> Does the term "foreach" imply any direction forward or backward? To me it
>> doesn't. I realise it's used in other languages, the same as in D, so it
>> has a commonly understood meaning.
>>
>> I think the options are:
>>
>> - leave foreach, invent a backwards term i.e. foreach_r.
>> - invent new terms, one for forward, one for backward.
>> - add the ability to specify the 'step' in foreach
>> Regan
> 
> I agree with Regan. foreach don't need to imply any direction. Compiler 
> must be able to parallelize it. For iteration constructs with implied 
> direction my favourite is:
> 
> foreach(forward)
> foreach(reverse)
> foreach(forward, firstEvenThenOdd)
> etc
> 
> -- 
> naryl

IMHO both foreach_reverse *and* foreach are ugly hacks and should be 
removed in D2.
let me quote a related post:

 > Sorry, to use the web interface to the newsgroup..
 >
 > This is an old (1993), but I hope related, discussion:
 >
 > Iterators: Signs of Weakness in Object-Oriented Languages
 > http://home.pipeline.com/~hbaker1/Iterator.html
 >
 > - Paul

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