Range documentation

[Jonathan M Davis]

On Sunday, March 24, 2013 14:47:21 Dmitry Olshansky wrote:
> 24-Mar-2013 14:40, Jonathan M Davis пишет:
> > On Sunday, March 24, 2013 14:01:00 Dmitry Olshansky wrote:
> >> 24-Mar-2013 08:42, Jonathan M Davis пишет:
> >>> On Sunday, March 24, 2013 14:31:44 Manu wrote:
> >>>> So what's the difference between save() and opSlice() though? They
> >>>> appear
> >>>> to be identical regardless... is save() redundant?
> >>> 
> >>> Like I said, opSlice with no arguments is the function used on
> >>> containers
> >>> to get a range for that container. It's never defined on ranges, and
> >>> even
> >>> if someone were to define it on one of their ranges, it wouldn't be used
> >>> except in code they wrote which used. save is the function which is used
> >>> to copy a range, and it's required for a range to be considered a
> >>> forward
> >>> range. Theoretically, opSlice with no arguments could have been reused
> >>> for that, but it wasn't.
> >> 
> >> There is no problem in random access range that has opSlice() to return
> >> itself. In fact, I'd expect it to always be range[0..$].
> > 
> > Of course, a range could implement the overload of opSlice without
> > parameters, but it's not part of the standard range API, so you can't
> > rely on it working for any type of range, and no range-based functions
> > will used it, or if they do, they won't be compatible with normal ranges.
> 
> Seems along the same lines as opDollar i.e. an addition that was
> overlooked and now hard to fit into requirements (because that'll break
> code).

Yeah, though implementing opSlice without any arguments wouldn't be 
particularly useful IMHO. Presumably, it would be the same as save, in which 
case, all you're doing is saving two characters. Maybe it should have been 
used instead of save, but it's far too late for that now.

- Jonathan M Davis