std.xml should just go

[Steven Schveighoffer]

On Fri, 11 Feb 2011 19:06:48 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 2/11/11 8:31 AM, Bruno Medeiros wrote:
>> On 04/02/2011 16:14, Eric Poggel wrote:
>>> On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:
>>>> At this point there is no turning back from ranges, unless we come  
>>>> about
>>>> with an even better idea (I discussed one with Walter but we're not
>>>> pursuing it yet).
>>>
>>> Care to elaborate on the new idea? Or at least a quick summary so we're
>>> not all left wondering?
>>
>> That comment left me curious as well...
>
> The discussed idea went as follows.
>
> Currently we have r.front and r.back for accessing the first and last  
> element, and r[n] for an arbitrary element.
>
> Plus, r[n] is extremely flexible (opIndex, opIndexAssign,  
> opIndexOpAssign... awesome level of control... just perfect). So then I  
> thought, how about unifying everything?
>
> Imagine we gave up on r.front and r.back. Poof. They disappeared. Now we  
> define two entities "first" and last" such that r[first] and r[last]  
> refer the first and last elements in the range. Now we have the situ:
>
> - Input and forward ranges statically allow only r[first]
>
> - Bidirectional ranges allow r[first] and r[last]
>
> - Random-access ranges allow r[first], r[last], and r[n] for integrals n
>
> Now we have a unified way of referring to elements in ranges. Walter's  
> excellent follow-up is that the compiler could use lowering such that  
> you don't even need to use first and last. You'd just use r[0] and r[$ -  
> 1] and the compiler would take care of handling these special cases.

er... I don't like this.  0 does not necessarily mean first element.  A  
map has arbitrary keys.

That is, even though it potentially could be unambiguous (the compiler  
could ensure that it is indeed a range type before allowing the conversion  
of 0 to first), there would be confusion where [0] *didn't* mean first  
element.

>
> Advantages: unified syntax, increased flexibility with opIndexAssign and  
> opIndexOpAssign. Disadvantages: breaks all range-oriented code out there.

opIndexOpAssign is really the only improvement.  I think code-wise, things  
would get uglier.  For example, in a bidirectional range, front() and  
back() do not simply translate to some index that can be applied to  
another function.  However, in random-access ranges, front() can simply be  
defined as opIndex.  So for, random-access ranges, code gets shorter, but  
not necessarily simpler (slightly less boilerplate) but bidirectional  
ranges get much uglier (static ifs and the like).

But I agree the opIndexOpAssign is a missing piece for front and back.

But let's think about something else -- you want first and last, but front  
and back also work.  What if we continued to use front and back, kept the  
current functions, but treated r[front] and r[back] as you say?  Then,  
you'd have some rule for r[front] like:

1. if front() is defined, translates to r.front()
2. if opIndex is defined, translates to r.opIndex[0], although I would  
prefer some symbol other than 0, because I'd like to use it on a custom  
map type to mean "front element".

And then all existing ranges still work, with the new syntax, and you can  
keep the clear separation of functions for when it makes sense.

-Steve