Full closures for D

Nathan Reed nathaniel.reed at gmail.com
Wed Nov 7 13:07:55 PST 2007


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.

> It just happens that type inference 
> hasn't historically been a big part of C/C++.  But D makes a number of 
> moves in the direction of more ML-like type inference.  It's just not 
> all the way there.  Deducing function return types would be a next 
> logical step.

The only cases I'm aware of where D does any kind of type inference is 
in assigning `auto' variables (which is trivial, since the type-checker 
generates a type for the expression on the rhs anyway), and in template 
argument deduction / IFTI (which C++ has too).  If there are other cases 
I'd love to hear about them.

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.

Thanks,
Nathan Reed



More information about the Digitalmars-d mailing list