Improving std.algorithm.find

[Andrei Alexandrescu]

On 07/19/2010 05:36 PM, Dmitry Olshansky wrote:
> On 20.07.2010 0:05, Philippe Sigaud wrote:
>> On Mon, Jul 19, 2010 at 21:23, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
>> wrote:
>>
>>
>> What I personally would like is a way to find an element in an
>> ordered
>> container (binary tree...)
>>
>>
>> Wouldn't that be a member of the binary tree?
>>
>>
>> Yes, indeed. Unless I define some cousin to range, a recursive range,
>> to iterate on any recursive container, like trees or graphs and then
>> devise algorithms on them. I played with this idea a few weeks ago but
>> went to do other things. Anyway, carry on.
>> Btw, I still plan to update some simple generic graphs and trees
>> structs to obey TotalContainer interface when it makes sense, and
>> update my graph algorithms accordingly. If I ever get somewhere, I'll
>> post something.
>>
>>
>> Aren't such scenarios better served by putting the limits
>> inside the
>> predicate? Otherwise the list of what can be done could go
>> on forever.
>>
>>
>> The problem is that, as the predicate is passed at
>> compile-time, the
>> limits must be CT-defined too. I'd like the limits to be
>> defined at
>> runtime. I run into this regularly, while using predicates in
>> std.algorithms.
>>
>>
>> I think this is a misunderstanding. All of std.algorithm works
>> with delegates:
>>
>>
>> int[] a = [ 1, 4, 2, 3 ];
>> int b = 2;
>> assert(find!((x) { return x > b; })(a) == [4, 2, 3]);
>>
>> Ah yes, but I regularly use algorithms structs as return values, like
>> this:
>>
>> auto nTimes(E, R)(E multiplier, R range)
>> {
>> return map!((ElementType!R e) { return e*multiplier;})(range);
>> }
> Try this workaround, replacing delegate with nested function, works for me:
> auto nTimes(E, R)(E multiplier, R range){
> ElementType!R fun(ElementType!R e) { return e*multiplier; }
> return map!(fun)(range);
> }
> For some reason, compiler never plays nice with map, and I believe there
> are some issues with current implementation (2.047 release ) that Andrei
> (hopefully) fixed in recent commit.

Yes, I'd discussed this with Walter on Friday and he said the semantics 
should be identical in the two cases. So we're dealing with a compiler bug.


Andrei