std.xml should just go

[Andrei Alexandrescu]

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.

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


Andrei