Missing completion list for single-statement lambda functions

[NoelAbrahams]

Hi,

VS: 2013 Update 4 RC
TS: 1.3

The completion list should be made available for the first case below:

interface Foo {
    bar:string;
    humbug: number;
}

var foo = (): Foo => ({
     b // No completion list

});

var fooToo = function():Foo {

    return {
        b // Okay: has completion list
    };
}

var fooThree = ():Foo => {

    return {
        b // Okay: has completion list
    };
}

[DanielRosenwasser]

If the object literal is wrapped in parentheses, doesn't that mean that we elide contextual typing? I don't think this is a bug.

[DanielRosenwasser]

From 4.19 in the spec:

The rules above require expressions be of the exact syntactic forms specified in order to be processed as contextually typed constructs. For example, given the declaration of the variable 'f' above, the assignment

f = s => s.toLowerCase();

causes the function expression to be contextually typed, inferring the String primitive type for 's'. However, simply enclosing the construct in parentheses

f = (s => s.toLowerCase());

causes the function expression to be processed without a contextual type, now inferring 's' and the result of the function to be of type Any as no type annotations are present.

[danquirk]

Correct, in the first example you're writing a lambda with no curlies for the lambda body so we're interpreting the expression as the return value. But since your return value is parenthesized we don't contextually type it. If you remove the parentheses then the curlies become part of the lambda and you have to explicitly write the return statement which then is contextually typed. If you were to parenthesize that you'd see similar behavior, ex:

var fooToo = function (): Foo {
    return ({
        b // no completion here since parenthesized expressions aren't contextually typed
    });
}

This is a good example of how this is all confusing though and doesn't really add any obvious value to the language, see #920