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