How about "auto" parameters?

[foobar]

KennyTM~ Wrote:

> On Jun 7, 11 20:11, foobar wrote:
> > I agree with Ary above and would also like to add that in the ML family of languages all the variables are also default auto typed:
> > E.g.:
> > fun add a b = a + b
> >
> > 'add' would have the type ('a, 'a) ->  'a and the type inference engine will also infer that 'a must provide the + operator.
> > I feel that this is more natural than having a dedicated function template syntax.
> > Better yet, instead of auto parameters, just make parameter types optional (as in ML) and let the compiler generate the template.
> >
> 
> I don't think HM type inference (ML, Haskell) support implicit cast, 
> i.e. you can't write { int a; double b; a + b; } anymore.

As I've answered to Andrei, this is a good thing(tm) - it's a feature.
I don't know if it has anything to do with the HM algorithm itself, but it is one of ML core principals. ML is strictly typed unlike C (glorified assembly).

> 
> > foo(a, b) { return a + b; } // will be lowered to:
> > T foo(T) (T a, T b) { return a + b; }
> >
> > Types are already inferred for delegate literals so why not extend this to regular functions too?
> >
> 
> There is no type inference in delegate literal as powerful as HM, it's 
> just "I call this function with parameters 'int' and 'float', so 
> instantiate a new function with 'int' and 'float'." Also, type inference 
> only work in template parameters
> 
>      struct F(alias f) {
>        ...
>      }
>      alias F!((a,b){return a+b;}) G;
> 
> but not regular delegate literals
> 
>      auto c = (a,b){return a+b;};
>      /* Error: undefined identifier a, b */