"isDroppable" range trait for slicing to end

monarch_dodra monarchdodra at gmail.com
Mon Oct 29 23:53:41 PDT 2012


On Monday, 29 October 2012 at 19:20:34 UTC, Dmitry Olshansky 
wrote:
>> **Extract a slice, but with the explicit notion you *won't* get
>> back-assignability "auto myNewSlice = r.extractSlice(0, 10);"
>>
> Another primitive or is that UFCS in the work?

That's just UFCS, not another primitive.

> Now when to use it? I'd hate to see everything turning from
> a[x..y]
> to
> a.extractSlice(x, y)
> in generic code. Just because a lot of code doesn't need a 
> slice to have the exact same type.
> (I'm just following the simple rule of generic programming: if 
> you don't require something - avoid using it)

Yes, that's a good point.

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

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

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 seems like a simple but efficient solution. Thoughts?

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

I'd rather have a global function in range.d, that would provide 
the implementation for any infinite range that provides 
has[Limited]EndSlicing.




More information about the Digitalmars-d mailing list