Code fails noImplicitAny check under 1.1.0.0

[paf31]

This code used to compile without error under 1.0:

module M {

        export interface T<A> {
            get(): A;
        }

        export function ap<A, B>(f: T<(a: A) => B>, x: T<A>): T<B> {
            return {
                get: () => f.get()(x.get())
            };
        }

        export function map<A, B>(f: (a: A) => B, x: T<A>): T<B> {
            return {
                get: () => f(x.get())
            };
        }

        var x: T<number> = {
            get: () => 0
        };

        var test = ap(ap(map((a: number) => (b: number) => (c: number) => {
                return { a: a, b: b, c: c };
            }, x), x), x);
}

However, under 1.1, I get the following error:

(23,37): error TS7024: Function implicitly has return type 'any' because it does not have a return type annotation and is referenced directly or indirectly in one of its return expressions.

I don't see any reason why any subexpression of test should have an inferred type of any.

[mhegazy]

This is relates to #641 though it is slightly different.

In 1.0 we used to suppress contextual type propagation for return expression if there are any type annotation on a parameter. so in (c:number) => {} we ignored the contextual type for the return value because c was annotated. in 1.1 we changed that to only do it if you have an explicit return type annotation. the result is that the compiler will try to figure out the contextual type, as the complier is inferring the type for map, that would lead to a cycle, and to break it, the return type will be any.

Note, that this used to happen before in 1.0 as well, but silently. we have added the noImplicitAny reporting for this to give the user some insight in how the compiler is reasoning about the input.

adding an explicit annotation would resolve the issue, also c

var f = (a: number) => (b: number) =>  (c: number) => {
    return { a: a, b: b, c: c };
};
var test = ap(ap(map(f, x), x), x);

another one that would do the trick, but I would not recommend as it is subtle, is using parens around (c:number) => {}, to stop the flow of contextual type.

var test = ap(ap(map((a: number) => (b: number) =>  ((c: number) => {
    return { a: a, b: b, c: c };
}), x), x), x);

[paf31]

Thanks for the explanation. I would say though that any type system bug which can be fixed by reparenthesizing subexpressions should not be "by design" :)

[mhegazy]

I do not believe it is a bug. it is a result of the current design. we have two options, either go into an infinite recursion trying to figure out the type of return statement, or break the loop with some value (any). The parenthesis, is a result of another design decision not to propagate contextual type through expressions, and allowing the user to opt-out of contextual type if they so choose.

[paf31]

Where can I find documentation on "contextual types"?

[RyanCavanaugh]

Section 4.19 of the spec

[zpdDG4gta8XKpMCd]

is this by design too?

function apply<a, r>(value: a, map: (value: a) => r): r {
    return map(value);
}
function id<a>(value: a) : a { return value; }
var yay = apply(() => ({ x: 0 }), id); // () => any <--- ????


// at the same time

var huh = () => ({ x: 0 }) // () => { x: number } <-- i am all right

// then

function always<a>(value: a): () => a { return () => value; }

var ugh = apply(always({ x: 0 }), id); // () => { x: number } <-- look, i fixed it!

// all this just doesn't make any sense

god, if anything please fix the inference first

[RyanCavanaugh]

I will let Fred Brooks know that developer time is completely fungible and that it would be plausible to take the intern off his summer project to redesign how generic type inference works.

[paf31]

I will let Fred Brooks know that developer time is completely fungible and that it would be plausible to take the intern off his summer project to redesign how generic type inference works.

What is this in response to?

[RyanCavanaugh]

Aleksey's comment that we should change this instead of doing abstract

[zpdDG4gta8XKpMCd]

sarcasm, i has it too

seriously, why do new controversial OOP features take precedence over not
working inference let alone anything that supports coding in functional
style?
On Jun 28, 2015 6:20 PM, "Ryan Cavanaugh" notifications@github.com wrote:

Aleksey's comment that we should change this instead of doing abstract

—
Reply to this email directly or view it on GitHub
#833 (comment)
.

[RyanCavanaugh]

It's not a matter of precedence.

Choosing not to do abstract will not a) make fixing this any easier or b) free up any resources that are capable of fixing this problem.