Any chance to call Tango as Extended Standard Library

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Jan 19 08:15:25 PST 2009


Steven Schveighoffer wrote:
> "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)

Ok, I understand.

> 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 ;)

I wish that debate went away. But eliminating toe and retreat would 
require requiring .reverse as a primitive for *all* ranges, which is 
wasteful and repetitive. Instead, a better design is to have ranges 
(those that can) offer toe and retreat primitives such that a generic 
function retro offers backward iteration for any range. In addition, 
certain algorithms (such as the one that reverses a range in place) need 
to manipulate the same range from two ends. Implementing them using 
.reverse and a second range would be more difficult.

Andrei



More information about the Digitalmars-d mailing list