The "type" type dream

[Michel Fortin]

On 2008-11-25 17:31:02 -0500, Robert Fraser <fraserofthenight at gmail.com> said:

> Static type inference + OO = disaster.
> 
> Say a module consists of this:
> class A { void add(int    o); }
> class B { void add(string o); }
> f(x, y) { x.add(y); }
> 
> What are the types of x and y in f? The only correct answer is that 
> there are two versions of f:
> void f(A x, int    y) { x.add(y); }
> void f(B x, string y) { x.add(y); }
> 
> This may not have been intended by the programmer (if there are 30 
> classes with an "add" method, many which are totally unrelated, it's 
> very likely the programmer didn't intend to create overloads for every 
> single one). If the programmer did intend a sort of "compile-time duck 
> typing", this will propogate to every caller of f.
> 
> The big problem, however is efficiency. Every method name is bound to 
> many possible classes, each of which must be considered. These 
> possibilities explode up the type graph, a Cartesian product of all 
> possible arguments being created at each function declaration. This 
> means that literally thousands of versions of a function might need to 
> be created for any non-trivial function (some of this can be turned 
> into branches or broken down into multiple functions). It's simply not 
> a scalable solution.

Hum, isn't static type inference is already possible in D using 
templates? And yes, templates can lead to code bloat.

I think that with static type inference we would have a good starting 
ground to obsolete template functions. Take this function (invented 
syntax):

	void f(auto x, auto y) { x.add(y); }

which would be the same as this template (current D syntax):

	void f(X, Y)(X x, Y y) { x.add(y); }

Surprisingly, it's the same number of character. The first is easier to 
read and understand though.

Obviously, that's a function you couldn't export for the same reasons 
you can't export templates.


> The last problem: every class must be known at the time of compiling 
> one module, which is a killer for complete TI in D, anyways.

The way it works in D is that a template is converted to code when 
compiling the module that use  and instanciate it. All types used need 
to be accessible when compiling the module that uses and instanciate 
the template. It's mostly the same with C++, and it seems to scale well 
enough.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/