Any chance to call Tango as Extended Standard Library

[Bill Baxter]

On Mon, Jan 19, 2009 at 11:54 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> 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) { ... }

It's a step backwards because with opApply we can define a default
forward iteration scheme that works like so:
   foreach(element; a) { ... }

Now you're saying that'll still work for structs, but for classes
folks will have to use some other convention like .all.  I also
presume built-ins like arrays still won't require you to use "a.all"
to do a basic forward foreach iteration.  If it will, I suppose I
could live with that.  As long as the rules are consistent and don't
make class-based  containters into second class citizens requiring
different syntax.

But there's really no technical reason why we can't have the simpler
syntax work.  As a class writer I would also find myself very tempted
to provide an opApply just to enable that simpler syntax for users,
assuming you stick to your guns and require something like .all to use
ranges.

--bb