std.array suggestion

[Ameer Armaly]

"Oskar Linde" <oskar.lindeREM at OVEgmail.com> wrote in message 
news:dup4fr$2c0b$3 at digitaldaemon.com...
> Hello,
>
> With the new IFTI support I have been looking at ways of upgrading the 
> standard library with new and more generic functions. What follows is my 
> suggestions for functions to be added to std.array. I have implemented all 
> of them and the current (0.149) limited IFTI-support is enough to support 
> them. That being said, I wish to hold off making a source code submission 
> until a) I get review comments on the suggested function prototypes and b) 
> it is more clear how far D is taking IFTI support (meaning possibly neater 
> implementation).
>
> All functions are designed to be used both as free function and as 
> implicit array methods. Except for the inplace versions, no functions 
> modifies the array.
>
> The prototype notation is my own. a|b means two alternative types. T is 
> the generic element type. T[] is the array.
>
> -----------
>
> T fold(T[] arr, T init, T delegate|function combiner(T,T));
>
> Generic array recursion function. combiner is called recursively:
> return combiner(init,fold(arr[1..$],arr[0],combiner));
> (The actual implementation will of course call the combiner iteratively)
>
>
> T max(T[] arr)
>
> Returns the maximum element in arr as defined by the > operator.
>
>
> T min(T[] arr)
>
> Returns the minimum element in arr as defined by the < operator.
>
>
> T sum(T[] arr)
>
> Returns the sum of the element in arr as defined by the + operator.
>
>
> ptrdiff_t find(T[] arr, T|delegate|function d);
>
> Returns the index of the first occurence of d or the first true predicate 
> d applied to the elements in order. Returns -1 when no element is found.
>
>
> size_t indexOf(T[] arr, T|delegate|function d);
>
> Like find, but throws on missing element.
>
>
> T[][] split(T[] arr, T|T[]|delegate|function d);
>
> Split the array arr using a predicate/element/subarray d.
> (obsoletes std.string.split that only works for char[])
>
>
> T[] join(T[][] arr, T|T[]|delegate|function separator);
>
> Join the elements array arr using separator.
> (obsoletes std.string.join that only works for char[])
>
>
> T[] join(T[][] arr);
>
> Join the array T[][] without separator.
>
>
> U[] map(T[] arr, U delegate|function f(T));
>
> Map the elements of arr over function f, returning an array of the 
> results.
>
>
> T[] filter(T[] arr, delegate|function p(T));
>
> Filters arr over the predicate p, returning array of elements of arr where 
> the predicate is true.
>
>
> Possible inplace version of map:
>
> T[] doMap(T[], T delegate|function f(T));
>
> ---------
>
> I would also prefer those over the language built in .sort .reverse:
>
> T[] sort(T[]);
> T[] stableSort(T[]);
> T[] sort(T[], delegate|function wrongOrder(T,T));
> T[] reverse(T[]);
>
>
> With the corresponding inplace versions:
>
> T[] doSort(T[]);
> T[] doStableSort(T[]);
> T[] doSort(T[], delegate|function wrongOrder(T,T));
> T[] doReverse(T[]);
>
> ---------
>
> Is there in general even any interest in adding generic functions to the 
> standard library?
>
> Regards,
>
> Oskar
I like it.  It would be especially cool if we could get rid of the necessary 
() after each call when using property syntax, thus making truely plugable 
properties.