"isDroppable" range trait for slicing to end

[Dmitry Olshansky]

10/30/2012 6:53 AM, monarch_dodra пишет:
> On Monday, 29 October 2012 at 19:20:34 UTC, Dmitry Olshansky wrote:
>>> Note that this "extractSlice" notion would save a bit of functionality
>>> for immutable ranges which *would* have slicing, but since they don't
>>> support assign, don't actually verify hasSlicing...
>>
>> immutable ranges is purely a theoretical notion. (immutable elements
>> are on the contrary are ubiquitous)
>
> Not *that* theoretical when you think about it. ascii's "digits" etc are
> all immutable ranges. They are a bad example, because they are strings
> (ergo un-sliceable), but as a rule of thumb, any global container can be
> saved as an immutable range.
> For example, I could define "first 10
> integers" as an immutable range. That range would be slice-able, but
> would not verify "hasSlicing".
>
You do make a common mistake of confusing a container and a range over 
it. Ranges are means of iteration, they are mutable by the very 
definition - every time you call popFront/popBack iteration state *changes*.

So you can't pop first item of "first 10 integers". It's an immutable 
entity that you can't manipulate.

In that sense slicing such an entity (container) is the way of 
extracting a _mutable_ range from it. Yet numbers it cycles through are 
immutable.

> --------
> The way I see it, maybe a beter solution would be a refinement of:
>
> *hasSlicing:
> **r = r[0 .. 1]; MUST work (so infinite is out)
> *hasEndSlicing
> **r = r[1 .. $]; Must work (intended for infinite, or to verify opDollor)
>

I suggest to stop there. In other words introduce hasEndSlicing (awful 
name) and check self-assignabliity of both.

> To which we could add "limited" variants: "hasLimitedSlicing" and
> "hasLimitedEndSlicing", which would *just* mean we can extract a slice,
> but not necessarily re-assign it.

This repeats the same argument of extractSlice albeit differently.

> This seems like a simple but efficient solution. Thoughts?

It's not simple. I suggest we drop the no self-assignable slicing 
altogether.

I claim that *if* you can't self assign a slice of a range it basically 
means that you are slicing something that is not meant to be a range but 
rather a container (adapter etc.).

> --------
> The issue that I still have with slicing (between to indexes) infinite
> ranges is that even on an implementation stand point, it makes little
> sense. There is little other way to implement it other than "return
> this[i .. $].takeExactly(j - i);" In which case, it would make little
> sense to require it as a primitive.
>
Yup like I told:
- Infinite range just plain can't support slicing on 2 indexes (they 
have limited slicing, or one side slicing not full slicing)

It's just I suggested to exclude opSlice(x,y) from primitives unlike in 
my first post where I didn't think of solving self-assigning problem.

> I'd rather have a global function in range.d, that would provide the
> implementation for any infinite range that provides has[Limited]EndSlicing.
>
Maybe though the utility of such a helper is limited (pun intended).


-- 
Dmitry Olshansky