std.array suggestion (version 2)

[Oskar Linde]

Derek Parnell skrev:
> On Sun, 19 Mar 2006 22:25:55 +0000, Oskar Linde wrote:
> 
>> Hello,
>>
>> I've been working a bit more on my std.array suggestion in
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/35008
>> and have made some changes to the specification. 
> 
> Thanks Oskar. This is a great idea.

Thank you Derek.

>> I have some open issues:
>>
>> 1. max/min on empty arrays
>>  max/min are undefined on empty arrays. I see three options:
>>
>>  a) return something, i.e T.min/max or T.init.
>>  b) use an in contract asserting the array is non-empty
>>  c) throw EmptyArrayException
>>
>>  - a) doesn't feel very robust. b) seems to be the most D-ish.
> 
> Of course, 'in' contracts are stripped out in -release editions so one can
> never rely on them catching empty arrays.

Yes. This makes b) and c) differ quite a bit. With c), the library does 
the error checking for you, allowing you to recover by catching an 
exception. b) allows for higher performance code, but places the 
responsibility to make sure the array is non-empty on the user. b) would 
make it a programming error to pass an empty array to max/min, in the 
same league as out of bounds indexing or null pointer dereferencing. A 
release build would in the best case give you a segmentation fault and 
in the worst case return a bogus value. c) would make passing an empty 
array a well defined operation but would incur a runtime cost in release 
builds.

>> 2. Naming of in-place functions
>>  my current suggestion is doMap(), doSort(), etc. Other suggestions are
>>  mapInPlace() and inPlaceMap(), but I find them a bit to wordy.
> 
> Any name will do if its documented well enough and consistent. But maybe
> MapIt(), and SortIt()  ;-)

arr.mapIt(function int(int x) { return x*x; });
arr.sortIt();

They would work for me.

>> Here is the full list of function definitions:
> 
> Is a 'merge' routine useful? I know it could be done with a join() then
> sort(), but a merge might be able to optimize the behaviour.

Yes, it would most certainly be useful, but I am slightly hesitant to 
add it. I try to keep std.array contain only the most basic and 
generically useful functions. More specialized functions should go into 
more specialized modules. Of course, I judge usefulness by a very 
subjective measure -- mostly based on my own coding habits: I've almost 
never had the need for a merge() routine (I can remember a few cases, 
but they all needed specialized implementations) -- but by this 
reasoning, I should not have included reverse() or stableSort() either. 
If you have a different experience regarding merge(), I'm more than 
happy to add it, as I recognize it being a logical companion to sort() 
and join(). What should it's signature be? Similar to join:

T[] merge(T[][] arr, opionalOrderingPredicate)

or do you almost always merge only two arrays:

T[] merge(T[] arr1, T[] arr2, optionalOrderingPredicate);

(It would then be the only std.array function symmetric with regard to 
its first arguments.)

/Oskar