std.array suggestion (version 2)

[Ameer Armaly]

"Oskar Linde" <olREM at OVEnada.kth.se> wrote in message 
news:dvklqj$4cl$1 at digitaldaemon.com...
> 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. I would like to thank
> everyone that commented. I have made the following changes:
>
> - removed .sum() (belongs to std.math or similar)
> - added optional ordering predicate to .max() and .min()
> - find now returns size_t instead of ptrdiff_t
> - added .count(predicate|element)
> - in-place versions have void return type
>
> A sample implementation is available at:
> http://www.csc.kth.se/~ol/array.d
> And a brief DDoc-output (hardly readable):
> http://www.csc.kth.se/~ol/array.html
> The implementation has been focused on correctness. No code is optimized.
> (except for .doSort() where I couldn't resist). What is missing is manual
> template argument checking with error reporting via pragma(msg,...).
>
> 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
I agree with this; it makes more sense to complain if you're asked to do 
someething with nothing.
> c) throw EmptyArrayException
>
> - a) doesn't feel very robust. b) seems to be the most D-ish.
>
> 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.
>
> 3. Functions like left, right, skip, skipUntil, countUntil, etc.
> I find them either redundant or too specialized to belong in a std.array
> module. Maybe some of them fit in std.string.
>
> 4. Cut-off point between std.string and std.array.
> I have no stringent rule for this. As someone said: If it is simple enough
> and could be generically useful (as opposed to only applicable to strings)
> why not put it in std.array. That's why split and join are here. (Well 
> join
> belongs together with split, and split is just a recursive find, and find
> definitely belongs in std.array. Atleast the single element and delegate
> version of find. But separating sub-array find from element-find, with
> both having the same function name will lead to problems.) But the current
> std.string non-argument version of split on char[] defaults to split on
> whitespace (iirc), a behavior that definitely is std.string matter.
What if std.string publically imported std.array; it would make some sense 
that if we want specific "string" functions, generic array functions could 
also be included.
Perhaps the whitespace version of split could be put in std.string, calling 
the std.array version of split with the appropriate parameters.
>
> Here is the full list of function definitions:
>
> T fold(T[] arr, T init, T delegate|function combiner(T,T));
> T max(T[] arr);
> T max(T[] arr, delegate|function wrongOrder(T,T));
> T min(T[] arr);
> T min(T[] arr, delegate|function wrongOrder(T,T));
> size_t find(T[] arr, T|delegate|function d);
> size_t indexOf(T[] arr, T|delegate|function d);
> size_t count(T[], T|delegate|function d);
> T[][] split(T[] arr, T|T[]|delegate|function d);
> T[] join(T[][] arr);
> T[] join(T[][] arr, T|T[] separator);
> U[] map(T[] arr, U delegate|function f(T));
> T[] filter(T[] arr, delegate|function p(T));
> T[] sort(T[]);
> T[] sort(T[], delegate|function wrongOrder(T,T));
> T[] stableSort(T[]);
> T[] stableSort(T[], delegate|function wrongOrder(T,T));
> T[] reverse(T[]);
>
> In-place versions:
> void doMap(T[], T delegate|function f(T));
> void doSort(T[]);
> void doSort(T[], delegate|function wrongOrder(T,T));
> void doStableSort(T[]);
> void doStableSort(T[], delegate|function wrongOrder(T,T));
> void doReverse(T[]);
>
> /Oskar