std.array suggestion

[Oskar Linde]

John C wrote:
> "Oskar Linde" <oskar.lindeREM at OVEgmail.com> wrote in message 
> news:dup4fr$2c0b$3 at digitaldaemon.com...
>> With the corresponding inplace versions:
>>
>> T[] doSort(T[]);
>> T[] doStableSort(T[]);
>> T[] doSort(T[], delegate|function wrongOrder(T,T));
>> T[] doReverse(T[]);
>>
> 
> My only reservation would be the decision to prefix these functions with 
> "do". It's tautological and doesn't express anything about them being 
> in-place versions. I suggest just calling them sortInPlace/inPlaceSort (or 
> even sortInSitu or inSituSort). 

I have not been giving much thought to the naming of the in-place 
versions. I briefly considered sortInPlace and inPlaceSort, but they 
appeared too unwieldy. "do" was meant to signal the side-effect by 
implying that the function "does" something, rather than just being a 
definition of a mapping of values onto other values. (A void return type 
would help too.) If I were a native English speaker, I might have felt 
differently about the "do" prefix though.

The general idea is to make the default (short) form not have 
side-effects. (Which I believe reduces surprises). Otherwise, I guess 
you could have named the non-in-place versions sorted() filtered() 
mapped() reversed() etc.

Before trying to justify the naming, I would need to justify the 
decision to make non-in-place versions the default. This is really a 
philosophical question, but I think the most important thing is to be 
consistent throughout the library. This choice seems to go hand in hand 
with the Phobos philosophy of using copy-on-write as often as possible. 
There are also plenty of functions that behave like this: 
std.string.tolower, toupper, capitalize, capwords, ljustify and replace 
to name a few. On the other hand, we have the in-place .sort and 
.reverse that behaves contrary to this.

I'm not really set on any naming and appreciate all suggestions.

/Oskar