Any chance to call Tango as Extended Standard Library

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Bill Baxter wrote:
>> On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>>> Unless it's a class you mean?
>>> Yah, ranges are meant to have value semantics. If you have a class 
>>> container
>>> exposing ranges, define the range separately from the container itself:
>>>
>>> MyIterable collection;
>>> foreach (element; collection.all) {}
>>> foreach (element; collection.all) {}
>>
>> Add .opRange so that's not necessary?  Or allow opApply to return a 
>> range?
>> Otherwise it looks like a step backwards.
>
> Why is it a step backwards? A given container may define a number of 
> ranges. Arrays are deceivingly simple because they have one obvious way of 
> iteration, but even for them you'd have to write:
>
> int[] a;
> foreach (element; a.retro) { ... }

I have to side with the others on this.   foreach(element; collection) is so 
damned intuitive ("for each element in a collection"), it should at least 
try to call a default range function first, before trying to use collection 
as a range.  I'm for having opRange, and ditching opApply.  I don't really 
see the need for opApply (and I used a lot of forwarding opApply calls in 
dcollections, so I'll probably have to rewrite that now!).  You could also 
write cool things like (for instance in a string-indexed collection):

foreach(element; collection["a".."m"])

instead of

foreach(element; collection["a".."m"].all)

While we're on the subject of ditching, can we get rid of foreach_reverse? 
How hard is it for a range to just have a reverse property:

foreach(element; myrange.reverse)

Which simply reverses the order of traversal?  That also would moot the 
toe/last/tail/etc. debate ;)

-Steve