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

[Andrew Edwards via Digitalmars-d-learn]

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.

      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.