On Wednesday, 31 October 2012 at 18:40:09 UTC, Jonathan M Davis
wrote:
On Wednesday, October 31, 2012 11:37:13 monarch_dodra wrote:
IMO, this makes a clean distinction between both "types" of
slicing. An added bonus is that (for now) it also correctly
supports finite RA ranges that don't define opDollar.
I don' think that such a distinction should be made at all. I
think that all
sliceable ranges should be required to implement opDollar. The
problem is that
it's unreasonable to require that when opDollar just got fixed,
and arguably
issue# 7177 should be implemented before it's reasonable to
require it. But
regardless, that means that creating a trait to test for
opDollar working
doesn't make sense. It would just have to be thrown away later.
PS: Do we really have to force that infinite slice to be of a
type of "take"? Does that mean we can't imagine an infinite
range
that defines it's own finite slice type?
I think that it's more valuable to make it consistent. What
would a separate
finite type even buy you? It would just be doing what take
would do. I do kind
of like the idea of just disallowing slicing without opDollar
on infinite
ranges though, in which case you'd have to use take yourself. I
don't know
what Andrei's take would be on that though.
- Jonathan M Davis
You are probably right. I think I've had my head too deep inside
algorithm implementation detail, and got my focus on the wrong
things.
Most of the theoretical ranges I'm trying to support probably
don't exist in real life anyways :/ Might as well keep things
consistent.
