"isDroppable" range trait for slicing to end

monarch_dodra monarchdodra at gmail.com
Thu Nov 1 03:39:00 PDT 2012


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.


More information about the Digitalmars-d mailing list