Requirements for Slicing Ranges

[Jonathan M Davis]

On Monday, September 2, 2024 10:03:27 AM MDT monkyyy via Digitalmars-d wrote:
> I think slicing should probably be cut from that main api, Id
> argue its the hardest to get correct of any of the functions
> while its the most fragile in meta programming in my experiments
>
> Instead there should be a collection of implict range functions
> given special treatment(std.range.interface, object.d, somewhere
> new for ranges)
>
> ---
>
> ```d
> auto tail(R)(R r){
>    r.pop;
>    return r;
> }
> ```
> It would suck to implement tail everywhere, so tail should not be
> in the main api; but often you need to make a poped dup. If tail
> doesnt exist, several range algorithms will need 3 extra lines of
> code repeated several time, if its in the main api, every
> algorthim will need to impliment a `auto tail()=>r.tail;` busy
> work as a specail treatment floating function it is 3 lines,
> users dont need to implement anything and it will reduce
> complexity and clarity of several algorithms(consider zip.pop
> being implimented with static map)
>
> likewise `sliceable` should be a floating function and it wraps
> ranges and adds opSlice, implements the meta programming of
> detecting if its implementable *once*, instead of the each and
> every algorthim needing to juggle the complexity of opDollar
> existing or not, infinite or finite, error behavoir etc.

As things stand, slicing finite ranges (and infinite ranges when using $)
always results in the original type - just like it does when slicing dynamic
arrays. I don't think that we want to lose that property of slicing just to
avoid making it so that someone has to implement opSlice to get slicing. And
if you're already implementing indexing, I don't think that it's
particularly onerous to have to implement slicing as well.

Maybe we could provide code to mix in which would make it easier, but ranges
are supposed to be an abstraction for dynamic arrays / slices (with ranges
in lower categories having fewer capabilities), and making slices have a
different type breaks that abstraction. Obviously, the abstraction isn't
perfect as things stand, but in general, we want code that's written to work
with dynamic arrays to be able to work with random-access ranges with as few
changes as possible (preferably with no changes outside of the function
signature).

Also, it's going to make algorithm code simpler if it doesn't have to worry
about whether random-access ranges have slicing. As it is, we already have
too many range-related traits that algorithms potentially have to branch on,
and I expect that simplifying that buys us more than trying to make it so
that someone who wants to implement a random-access range doesn't have to
implement slicing.

- Jonathan M Davis