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

[Stanislav Blinov via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 04:07:22 UTC, Andrew Edwards wrote:
> On Thursday, 8 June 2017 at 03:40:08 UTC, Jonathan M Davis

>> sort() returns a SortedRange so that other algorithms can 
>> know...
>
> 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".

Earns you nothing? How about not performing an allocation and 
copy?

> 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

"Something to that effect" is exactly this:

aa.keys.sort().release;

No need to import anything but std.algorithm : sort.

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

A crucial point of any good design is to *not rob the caller of 
useful information*. sort() follows that philosophy. If you don't 
need the extra information, you're free to get rid of it. The 
other way around that you seem to be proposing would require 
having a ton of overloads for sort() for any imaginable use case.