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
