Full closures for D

[Nathan Reed]

Simas wrote:
> Nathan Reed Wrote:
>> Of course, in this case it's "easy enough to infer".  However, function 
>> bodies can be arbitrarily complicated, meaning you will need a full type 
>> inference engine for this to work in the general case.
> 
> Not really. The compiler knows what the return-type is.

Not in all cases.

// What's the type of dg here?
auto dg = { return $0; }

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; });

You can't depend on the environment in which the delegate is defined 
giving you any information about what the delegate's type should be. 
It's only a happy accident that in the particular example with 'map' 
posted above, the second parameter to map() tells you what the type T is 
and therefore what the delegate's type should be.  So, in the general 
case, you *will* need a full type inference engine to descend into the 
body of the delegate, examine the expressions in which parameters 
appear, and infer their types (e.g.: base ~ $0 where base is 
const(char)[] and ~ is an operation that works on two arrays of the same 
type, hence $0 is also const(char)[]).  And in some cases even that's 
not enough - the identity delegate I used above, { return $0; }, cannot 
reasonably be assigned *any* delegate type, since its parameter and 
return could be any type at all.

I'm sorry, this idea is just fundamentally not compatible with D's type 
system.  True, the language *could be* modified in such a way as to make 
this work.  But that is way too far of a departure from D's C/C++ roots. 
  It is not a scripting language.

> On "http://www.digitalmars.com/d/" D is defined as "Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python."
> 
> Well, somebody may say perl isn't modern. But in Ruby and Python this is also possible. So, why is this wrong? Only why this is not C-style? 
> 

Ruby, Python, and Perl are all dynamically typed languages, and they owe 
a good deal of their "programmer productivity" to that.  D wants to be 
progammer-productive too, but D is committed to being *statically* 
type-safe as much as possible.  So D will bring in only those features 
of modern dynamic languages that are compatible with strong, static typing.

Thanks,
Nathan Reed