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