More bugs...

[Mehrdad]

I guess the problem is with type deduction, but the trouble is that half the 
reason why type deduction is useful is in the case of lambdas. They become 
effectively useless if you have to type out their entire signature, since 
you could then just make them a separate function (or just use a mixin 
instead, to create a closure... which I've done before).

This isn't really an 'enhancement', since the error message is clearly a 
bug. So I filed them both as bugs.

http://d.puremagic.com/issues/show_bug.cgi?id=8009
http://d.puremagic.com/issues/show_bug.cgi?id=8010

The other bug I was referring to was something along the lines of the 
compiler telling me, "I can't really handle closures as template parameters 
very well (something about 'local variable' or whatever), so I'll just give 
you an obscure error every now and then".
It only happened when it was inside another function, and some conditions 
were satisfied. (I don't remember the exact message, but when I searched it, 
I saw it had been already reported before...)


Oh and thanks for the alternative, it's a good workaround to know. :)

The trouble is that while it solves the bug I posted, it's still not solving 
my (actual) problem.
The actual problem was that I wanted to do something along the lines of:

private import std.range;
auto filter(R, F)(R r, F f) { /*return a filtered range*/ }
void main() { [1, 2, 3].filter(x => x < 3); }

but I resorted to 'delegates' because this didn't work.
However, when I did so, I decided to use a delegate anyway, while using 
'scope' on the delegate and its parameter to avoid a heap allocation, but 
that didn't work either...
so I just filed the bug report with a case that had less type inference. But 
the trouble is that the caller needing to say "delegate" is *already* too 
much typing, so the rest don't really help. :\


On 05/01/2012 04:02 AM, Mehrdad wrote:
> Wha..?!
>
> I can't believe delegates work so poorly in D...

It is not the delegates, it is the type deduction algorithm for implicit
function template instantiation. The issue is that the parameters do not
cross-talk, which means R is not known during matching: How to detect
the argument type from bool delegate(ElementType!R) alone if R is not
known? The obvious solution would be to use an actual inference
algorithm that uses information that can be gained from other parameters
as well as information already known from the current parameter.

You might want to file an enhancement request, because this exact thing
seems to trip up many programmers. (i.e. it would be a lot more
intuitive and convenient if it worked.)


> they're practically
> unusable unless you're passing them as template parameters (which brings
> on its own set of bugs)...

I haven't encountered those so far.

>
> Seems like every time I try to escape a bug somehow, another one pops up 
> :(
>

The situation is improving. Furthermore, there is a very large subset of
the language that is already very usable.

Another way to make your code compile:

private import std.range;
void filter(R,S)(R, bool delegate(S)) if(is(S==ElementType!R)){ }
void main() { [1, 2, 3].filter((int x) { return x < 3; }); }