Requirements for Slicing Ranges

[monkyyy]

On Tuesday, 3 September 2024 at 00:54:32 UTC, Jonathan M Davis 
wrote:
> 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

> *As things stand*
> *just*

As thing stands, I bet that the 50ish algorthims that should work 
correctly with slicing, dont handle the complexitys of all 
infinite, opDollar, nested ranges, with coherent error behavior 
in d2 and its had the 10 years and 100+ whatever contributors. I 
dont think is possible to get it correct with the old api; it 
always feels like a crapshoot if array like ranges work.I dont 
know why anyone would sign up to recreate anything resembling d2.

My experiments had more ambitious plans for slicing, but it very 
quickly broke down.

You should make a proof of concept algorithms lib with lets say 
20 algorithms 10 of which are suppose to work with slicing; can 
you juggle all the complexity with the requirements, are you 
sure? It will only get worse with scaling it up to 100 people, 
real world use cases, changing requirements, and feature requests 
as you attempt to reach for 150-200 algorithms in d3.

 From my prospective your generating a very very **very** long 
wishlist on pure math theory that will not survive contact with d 
as a buggy compiler and templates that merely pretends to be 
context-free; instead of implementing and feeling it out what the 
compiler actually is; redoing the foundational pieces to be 
simple and strong as possible.