On Thursday, 7 May 2015 at 13:38:23 UTC, Andrea Fontana wrote:
> Because it is a more generic operation and you can work on a lazy range.
> Anyway, to sort and to do uniq it isn't the fastest way.
>
> Or maybe I just didn't understand what you really need. :)

Thanks. These are good ideas in general. I'm curious to why
something like merge isn't already in Phobos. The most similar
existing range in Phobos is probably

http://dlang.org/phobos/std_range.html#roundRobin

I believe MergeRange will be bi-directional right?

Further, I believe minElement and maxElement at

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L215

should have a CT-specialization in the case when input is a
SortedRange. In that case minElement should return front and
maxElement should return back, right?

On Thursday, 7 May 2015 at 21:53:24 UTC, Per Nordlöw wrote:
> On Thursday, 7 May 2015 at 13:38:23 UTC, Andrea Fontana wrote:
>> Because it is a more generic operation and you can work on a lazy range.
>> Anyway, to sort and to do uniq it isn't the fastest way.
>>
>> Or maybe I just didn't understand what you really need. :)
>
> Thanks. These are good ideas in general. I'm curious to why
> something like merge isn't already in Phobos. The most similar
> existing range in Phobos is probably
>
> http://dlang.org/phobos/std_range.html#roundRobin
>
> I believe MergeRange will be bi-directional right?
>
> Further, I believe minElement and maxElement at
>
> https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L215
>
> should have a CT-specialization in the case when input is a
> SortedRange. In that case minElement should return front and
> maxElement should return back, right?

Name could be misleading. This is a sortedrange: [4,3,2,1,0]. In your case minElement is 4, maxElement is 0 :) On ranges with more complex elements sort order can be even less obvious. I think first and back it's ok!

On Friday, 8 May 2015 at 08:27:19 UTC, Andrea Fontana wrote:
> Name could be misleading. This is a sortedrange: [4,3,2,1,0]. In your case minElement is 4, maxElement is 0 :) On ranges with more complex elements sort order can be even less obvious. I think first and back it's ok!

Ok. I guess you mean front and back right?

On Friday, 8 May 2015 at 09:23:42 UTC, Per Nordlöw wrote:
> On Friday, 8 May 2015 at 08:27:19 UTC, Andrea Fontana wrote:
>> Name could be misleading. This is a sortedrange: [4,3,2,1,0]. In your case minElement is 4, maxElement is 0 :) On ranges with more complex elements sort order can be even less obvious. I think first and back it's ok!
>
> Ok. I guess you mean front and back right?

ahah :) You're right!

On Thursday, 7 May 2015 at 21:53:24 UTC, Per Nordlöw wrote:
> Thanks. These are good ideas in general. I'm curious to why
> something like merge isn't already in Phobos. The most similar
> existing range in Phobos is probably

So I implemented a first working version of merge() by reusing roundRobin(). Working version at:

https://github.com/nordlow/justd/blob/master/range_ex.d#L599

Destroy!

On Monday, 11 May 2015 at 07:05:30 UTC, Per Nordlöw wrote:
> So I implemented a first working version of merge() by reusing roundRobin(). Working version at:
>
> https://github.com/nordlow/justd/blob/master/range_ex.d#L599
>
> Destroy!

I guess we should support bi-directional access through back() and popBack() aswell right?

On Monday, 11 May 2015 at 07:12:05 UTC, Per Nordlöw wrote:
> I guess we should support bi-directional access through back() and popBack() aswell right?

Does this mean that we need to statically check whether the SortedRanges support Bidirectional access or not? Or is a SortedRange by convention always random-access?

On Monday, 11 May 2015 at 07:12:05 UTC, Per Nordlöw wrote:
> I guess we should support bi-directional access through back() and popBack() aswell right?

I believe I have BidirectionalRange support aswell now at

https://github.com/nordlow/justd/blob/master/range_ex.d#L597