----
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/ehywdvmcmgyawgzfp...@forum.dlang.org
