.sort vs sort(): std.algorithm not up to the task?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, June 08, 2017 04:07:22 Andrew Edwards via Digitalmars-d-learn 
wrote:
> On Thursday, 8 June 2017 at 03:40:08 UTC, Jonathan M Davis wrote:
> > On Thursday, June 08, 2017 03:15:11 Andrew Edwards via
> >
> > Digitalmars-d-learn wrote:
> >> I completely understand the differences between ranges and
> >> arrays... the thing is, I wasn't working with ranges but
> >> arrays instead. If sort understands a string or array as a
> >> sort of range, then given one of those entities, it should
> >> manipulate it internally and return it in it's original
> >> flavor. Given an array, return an array unless specifically
> >> told to do otherwise.
> >
> > sort() returns a SortedRange so that other algorithms can know
> > that the range is sorted and take advantage of that. If sort()
> > returned the original range type, it would be detrimental for
> > other algorithms. But you can just use the array directly again
> > after calling sort or call release() on the SortedRange to get
> > the array out of it.
> >
> > - Jonathan M Davis
>
> Yes, I understand that. Again, using "std.range: release" earns
> me nothing more than I already get from "std.array: array" or if
> you prefer "std.range: array". I can understand if sort returns
> Range by default but can be instructed to return the original
> representation.

release is a member of SortedRange. You don't have to import it separately.
You have it automatically by virtue of the fact that sort returns a
SortedRange. And unlike calling array, it doesn't copy the entire range or
allocate.

>       aa.keys.sort!returnOriginalRepresentation; // or something
> to that effect
>
> But it doesn't, it decides what i'm gonna get like it or not. But
> the fact, a lot of times I just want to work with the underlying
> data after the operation is performed. And it should be noted
> that this applies to Ranges in general not just sort.

It's just life with ranges that you're usually going to end up with a new
type when you call a range-based functions. Most of them can't even do what
they're supposed to do without returning a new type, and that type often is
not same level of range as the original (e.g. filter returns a new range,
and it's only a forward range even if the original is a random-access range,
and it can't do otherwise given that it's lazy). Pretty much the only way
for ranges in general to return the same type would be if you were only
dealing with dynamic arrays, and you were willing to have the range-based
function not only be non-lazy, but you were also willing to have it
allocate. And if you're going that route, you might as well just have
functions operating on dynamic arrays instead of ranges. As it stands, we
have functions that return lazy ranges so that they're efficient, and if you
want a dynamic array back, you call array on the result. Sure, if you're
looking to only operate on dynamic arrays, then that can be a bit annoying,
but overall, it leads to much more efficient code, and a lot of code works
just fine without to call array having to worry about whether dynamic arrays
are involved at all.

It's true that sort could work with returning the original type and without
allocating (unlike a function like filter), but having it return SortedRange
is beneficial overall, and calling release to get the original out is as
short as passing a template argument like you're suggesting. Also, you can
simply call sort on a separate line and continue to use the array without
worrying about sort's return value. So, while I can understand that you'd
like sort to just return the array in this case, it's so simple to work
around it that this really doesn't seem like it should be a big deal.

The reality of the matter is that if you're going to be annoyed about
range-based functions returning new types, you're going to be annoyed a lot
when dealing with range-based functions.

- Jonathan M Davis