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 */
