Full closures for D

[Bill Baxter]

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.

Ok, you probably know better than me, then.  You just seemed to be 
equating better type inference with scripting languages in your previous 
post.

>> 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.

I was thinking of the type deduction in foreach which deduces the type 
from signatures of opApply functions.  I suppose that's pretty similar 
to IFTI.  But it doesn't really matter.  My main point was that D could 
do more than it does now.  That would still hold even if it did 
absolutely no inference of any kind.

> 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.

Sure I can believe it's different.  But that doesn't mean it wouldn't be 
a good addition to the language.   Just make the compiler generate 
errors on ambiguities.

Also you gave the example:
   void some_func ( int delegate (int) dg );
   void some_func ( string delegate (string) dg );
   // Which some_func is being called here?
   some_func({ return $0; });

But you don't need $0 to create an ambiguity.
   void some_func ( long x);
   void some_func ( uint x);
   some_func(4);
also gives you errors about ambiguity.  So your example would too.

Ambiguity isn't a killer as long as a) it's possible to recognize the 
ambiguity when it appears, and b) there's a significant number 
practically useful examples that aren't ambiguous.

The killer is probably just how difficult it would be to implement 
without wrecking anything.

--bb