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

monkyyy crazymonkyyy at gmail.com
Sat Jan 11 00:43:44 UTC 2025


On Friday, 10 January 2025 at 21:54:35 UTC, Dukc wrote:
> On Friday, 10 January 2025 at 21:21:10 UTC, monkyyy wrote:
>>
>> users code should do the easiest thing that gets the task done
>>
>> lib code should be more ambitious and Im discussing range api 
>> design of my lib code
>
> Maybe you misunderstood. I wasn't writing that users don't need 
> to care about performance. I meant that user's don't care about 
> performance _most_ of the time, but they do care about it 
> _some_ of the time. The convention is there to help users to 
> distinguish their unoptimised and optimised code from each 
> other.
>
> Since you're writing about API design, it's very much a case of 
> user code - that is, users of your library. It doesn't have 
> anything to do with how you ambitiously you optimise your 
> library, or what range API (if any) you use internally - that 
> is entirely up to you to decide and independent of the user API 
> design.
>

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.

> 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.


More information about the Digitalmars-d mailing list