"isDroppable" range trait for slicing to end

[monarch_dodra]

----
On Tuesday, 30 October 2012 at 17:49:20 UTC, Dmitry Olshansky
wrote:
> 10/30/2012 6:53 AM, monarch_dodra пишет:
>> 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.

Yes, that is quite true. Although in this case, the slice is both
container and range.

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

Well, in my mind, the argument was the opposite, it would mean
you'd be able to write r[i..j] simply (as opposed to
r.extractSlice(i, j)).

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

That *would* make things simpler. I guess that's a good way of
seeing it.

----
On Wednesday, 31 October 2012 at 04:53:00 UTC, Jonathan M Davis
wrote:
>
> As already pointed out, this is solved by opDollar. We don't 
> have a trait for
> it, but it can be tested for easily enough by doing something 
> like
> typeof(is(r[0 .. $])) or __traits(compiles, r[0 .. $]). We may 
> still want to
> create a trait for it though (e.g. hasOpDollar).

In my defense, I started thinking about this back when opDollar
didn't work at all.

> However, if we take advantage of opDollar, then I think we can 
> solve the
> problem that way. By using opDollar when slicing an infinite 
> range, you should
> be able to keep the original range type. That being the case, I 
> don't think
> that isDroppable is really necessary.

Yes, in that context, that would also work (but had not thought
of this).

BTW: Once you are done, maybe you could present here what it
means exactly to be slice-able? AFAIK, your current proposal
allows for infinite ranges to verify "hasSlicing", if they can be
sliced between [a ... b], whereas Dmitry seems to think that
should not be so. At all.

----
Well in conclusion, sorry to have brought a crappy solution :/ I
guess we had something simple all along...

----
Whilst were on the subject of opDollar, and how it can solve all
of our problems, could one of you two maybe answer the questions
in this thread?
http://forum.dlang.org/thread/ehywdvmcmgyawgzfpytn@forum.dlang.org