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

[Dukc]

On Wednesday, 8 January 2025 at 21:59:04 UTC, monkyyy wrote:
> Getting opSlice to act correctly with a linked list a 
> `[0..$-1]` call just requires 3 op overloads and in theory 
> *every* bidirectional algorithm is optionally doubly linked 
> list; its allot of complexity for what benefit?

The problem here is not implementation complexity. You are right 
it would be pretty trivial to implement.

The problem is the execution time of the slicing operation. The 
convention is that if the run time (or memory use, if it is 
significant) grows faster than the logarithm of the range size as 
it increases, then the range should not provide a slicing 
operation. With a linked list, the execution time increases 
linearly with the amount of elements to be dropped, meaning it 
shouldn't have a slice operation as per convention. Unless I'm 
mistaken, this particular convention is inherited from C++ 
Standard Template Library.

The user can still use `drop` and `take`/`takeExactly` when 
there's no issue with linear execution time, and it'll work with 
any forward range.