Full closures for D

[David B. Held]

Nathan Reed wrote:
> Bill Baxter wrote:
>> More sophisticated type inference is certainly possible with a strong 
>> static typing.  When you trigger an ambiguous case like the ones you 
>> show above, the compiler should just tell you "cannot deduce type of 
>> ___ in expression ___".  Maybe with a few possible valid deductions to 
>> point out the ambiguity.  That's what the strong statically typed 
>> language ML does (and variants like OCaml).
> 
> I'm familiar with ML; in fact, I use it extensively.  I never claimed 
> this couldn't be done, I just think it's too big of a departure from D's 
> C/C++ roots.

Guess what?  Deducing argument types is no harder than choosing the 
correct return type for min(T, U) (which is why Andrei posed it as a 
challenge some time ago...it's a hard problem which nicely illustrates 
the difficulties of type inference in an example so small anyone can 
understand it).  Saying that D can't do this level of type inference is 
equivalent to saying that you can't write a proper implementation of 
min() in D, which is awfully defeatist, IMO.  I think we should *strive* 
to get a good implementation of min(), and upon doing so, would have 
sufficient type deduction machinery to implement these lambdas.

> [...]
> Anyway, deducing function *return* types would indeed be not much 
> different from deducing types for `auto' variables, but deducing 
> function *argument* types is another beast altogether - as I've tried to 
> demonstrate above.

It's a different problem, granted; but I don't see it as fundamentally 
harder.  Ambiguity errors are a straw man.  The hard stuff is when you 
have to do things like unification of types that people expect to work 
together, but have problematic subtleties (like int/uint).

Dave