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
