`drop` not `opSlice` should be in the range api

[Dukc]

On Saturday, 11 January 2025 at 00:43:44 UTC, monkyyy wrote:
>
> Its also bad that users may need to spam .array to get 
> something that may otherwise work.
>
> There isnt really a bench mark (even if there should be, Im 
> extermely anti the upstream plan of "we will talk out apis and 
> the best design will appear out of thin air", demos, test runs, 
> etc.) but ideally you want some set of leet code problems you 
> want to solve in <5 function calls each and youd cross 
> reference some prosposed functions limilment sets of problems 
> nicely. Slicing is 4 operations at once (drop(int) 
> drop(opdollar+i), dropback(i),dropback(opdollar-i)) if it 
> breaks one that cant be a "random access range" anymore, and 
> opps geuss a techinically unnessery but extra work and 
> knowlegde check on the user before it works.

Sorry, this is written so carelessly that I'm not sure what you 
mean. My best guess is you're opining that insisting on 
performance guarantees of random access ranges is not worth it 
because the slicing operator has just too much expressive power.

If you're designing your own range API anyway, it's a reasonable 
choice IMO. Just don't do it for Phobos range APIs if you happen 
to implement any.

>
>> Note, I wrote this assuming you meant _user-facing_ range API. 
>> If you meant an internal API, I'll have to write another reply.
>
> is there a difference? I private nothing, users should be able 
> to slot in custom algorithms call to then call my data 
> structures, to impalement their data structures in a big mess 
> of whatever happens happens.

Even without `private`, libraries usually do make a distinction 
between functions that are intended for the user and functions 
that are intended only/mainly for the library itself. For user 
functions, there is effort made by the library maintainer to not 
break the API between versions, for internal functions there is 
not.

Now, you don't _have_ to distinguish between those, but if you 
don't you'll have hard time offering any real stability between 
library releases. On the other hand, nothing wrong with an 
unstable library, especially if it's still in alpha stages. Maybe 
you want to leave drawing the distinction for later in which case 
there's no difference, and my last post applies.