Creating a Sub-view of a non - RA (hasSlicing) range.

[monarch_dodra]

On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu 
wrote:
> Yes. But now you're moving the goalposts because many of your 
> arguments referred to SList.
I'm sorry, that's not what I meant to do. The goal post was not 
moved, rather misplaced to begin with. Using SList for making my 
point was not the best choice of containers. I'd hae used a 
"DList" like container if I had one.


On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu 
wrote:
> Correct. take() and takeExactly() work under the assumption 
> there's no surreptitious change in the structure of the range 
> underneath. I think that's a reasonable decision.
Most of the time yes. But for certain "partitioning" algorithms, 
those that _cut_ a range into several subranges (for example 
"findSplit"), such "surreptitious" change should (IMO) be 
expected and supported.


On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu 
wrote:
> Which is as it should be. How would you otherwise take the 
> first n elements of a given doubly-linked list in constant time?
Constanst time, I don't know. I'm still looking for a way to do 
it in o(N) ;)


On Saturday, 30 June 2012 at 23:51:42 UTC, Andrei Alexandrescu 
wrote:
> It's all about what it takes to reach a certain point. You are 
> sensing something indeed, but take() is not it. The problem is 
> there's no simple way to count 5 starting from the left side of 
> a doubly-linked list, stop there, and then create a range from 
> the beginning of the list and that mid point. In C++, that's 
> trivial because range ends are separate.
>
>> ----
>> I came to D after reading your talk on ranges, and I really 
>> liked (and
>> am still enjoying) the concept. However, with C++, when you 
>> iterate over
>> [First, Last), you are also creating a two new ranges: [First, 
>> Current)
>> & [Current, Last). D doesn't provide that, it only provides a 
>> way to
>> shrink the current range and create [Current, Last).
>
> Yes, that's a good way of putting it.
>
>> Using range, you don't get [First, Current). At best, you only 
>> get
>> a)A forward range only
>> b)A fixed size range
>> c)A range of another type
>
> We could extend the range interface for specific ranges to 
> allow for such. However, there hasn't been a strong need so far.
>
>
> Andrei

Thanks again for your replies. I'm really enjoying using D and 
ranges, and I get that nothing is "free", and this issue is one 
of the by products of moving from iterators-pairs to more 
powerful, but restrictive, ranges.

I get the "no sense in making things more complicated if there is 
not a strong need", but at the same time, I've always felt that a 
language's algorithm facility should always we imaculate. Further 
more, it really feels as if the interface is just one concept shy 
of being able to make something like this work...

Something like...
"inverseRangeBegin(R big, R small)": Creates a range that begins 
where big starts, and ends where small starts. R must be at least 
bidirectional. small must be included inside big.

 From an implementation point of view, I think any container, and 
even arrays, can do it. I pretty sure this is compeltly feasable. 
Just off the top of my head. I'm sure there are brighter thinkers 
out there that have put more thought into it.