std.array suggestion

[Oskar Linde]

Ameer Armaly wrote:
> "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

Upon rereading, I realized that the inplace versions should be void 
functions - not returning an array.

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

Yes, I agree. I would like to know if all pairs of empty parentheses 
after functions are supposed to be redundant or if calls without 
parentheses should be reserved to property like methods. Considering the 
current .sort and .reverse semantics, I guess the former is the case and 
DMD not allowing calls without parentheses for implicit array methods is 
an unintentional omission.

/Oskar