std.array suggestion

[Oskar Linde]

Thank you for your comments.

Sean Kelly wrote:
> Oskar Linde wrote:

>> 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.
> 
> To those who are unfamiliar with ITI, it's worth noting that any
> template parameters that cannot be determined implicitly should be
> placed at the beginning of the template parameter list.  Doing so should
> allow this to be possible:
> 
> template func( Ret, Val )
> {
> Ret func( Val val ) {}
> }
> 
> int i;
> char c = func!(char)( i );
> 
> This isn't implemented yet, but I suspect it will be soon.

Yes, I see no obstacles in implementing this.

>> 
>> T min(T[] arr)
>> 
>> Returns the minimum element in arr as defined by the < operator.
> 
> min and max should probably allow a comparison predicate to be supplied
> as well.  

That is a good idea. The meaning should be the same as for the sort
predicate.

> Thus the declarations would be something like this:
> 
> T min(T[] arr, P pred = &less!(T));
> 
> I'm also hoping the above syntax will actually work, and that P will
> resolve to being a function pointer by default.

What you can do today is this:

template min(ArrTy, PredTy) {
        eltype!(ArrTy) min(ArrTy array, PredTy predicate) {
                ...
        }
}

template min(ArrTy) {
        eltype!(ArrTy) min(ArrTy array) {
                return array.min(&less!(eltype!(ArrTy)));
        }
}

>> 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.
> 
> I suggest returning size_t instead and using size_t.max in place of -1.
>   The two are basically equivalent, but using size_t offers a bit more
> range in legal array sizes as the flag value occupies the least
> significant bit rather than the most significant.

Yes. This is probably better. size_t.max is still == -1 in comparisons.

> I also almost suggested adding a "substring" find function, except that
> seems more appropriate for a std.string module.  Have you thought about
> how the two will overlap?  I'm not entirely certain how template
> overloading will work for functions defined in different modules.  In
> fact, if this is indeed a limitation them it might be prudent to put all
> such algorithms in std.array instead of splitting them between std.array
> and std.string (I just thought of this--I had been considering multiple
> modules for overloads in Ares, and I suspect this won't work).

I'm not certain, but I believe the current dmd-ifti will have problems with
splitting template functions with the same name and number of template
arguments. It would probably be best to put a generic subarray find in
std.array rather than extending the find function for just {,d,w}char[].
But while one may argue for a generic subarray find, it becomes less
certain that there should be a generic subarray replace for instance. 

>> 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[])
> 
> How do you envision the delegate version being applied?  Is it expected
> to return an element/array for a separator?

Oops, this is a copy-paste error. I have not implemented this as taking a
delegate/function. I did not see any use for that. The signature should be:

T[] join(T[][] arr, T|T[] separator);

>> ---------
>> 
>> Is there in general even any interest in adding generic functions to the
>> standard library?
> 
> Heck yes.  Many of the functions you've mentioned above were ones I was
> planning to implement.  I also like that you're using delegates as
> predicates, as it makes them far more generic than some of the hardcoded
> versions in Phobos' std.string.  I don't suppose you'd like to submit
> them to Ares as well?  Or please don't object if I end up implementing
> something quite similar :-)

I would definitely not want to exclude my implementation from Ares. Once the
function specifications are defined, the implementation is really straight
forward. I have no objections to you implementing similar functions either.
My only concern is having this functionality in some form in a D standard
library. :)

/Oskar