Cannot access properties of type parameter constrainted by 'any'

[andrewvarga]

I have a problem where if I use a generic function which extends from another generic type, the function parameter's type doesn't seem to be respected.

TypeScript Version:

1.8.9 (current stable)

Code

// Generic Tree structure (couldn't achieve the same with interfaces / classes)
type Tree<T> = T & {
    children?: Tree<T>[];
}

interface INode 
{
    id: number;
}

var myTree: Tree<INode> = {
    id: 1,
    children: [
        {
            id: 2
        }
    ]
};

// Compiles and works nicely:
console.log(myTree.id);
console.log(myTree.children[0].id);

class MyClass
{
    public static displayTree1<T extends Tree<any>>(tree: T)
    {
        // Compile time error "Property 'children does' not exist on type 'T'"
        console.log(tree.children);
    }

    public static displayTree2<T extends Tree<INode>>(tree: T)
    {
        // Compiles fine
        console.log(tree.children);
    }

    public static displayTree3(tree: Tree<any>)
    {
        // Compiles fine
        console.log(tree.children);
    }
}

Expected behavior:

I expect the "displayTree1" function to compile fine, T extends Tree so it can be assumed to have a 'children' property.

Actual behavior:

Compile time error: Property 'children does' not exist on type 'T'.

[DanielRosenwasser]

The problems seems to be when any shows up in the constraint of a type parameter.

Simpler repro:

function f<T extends any>(x: T) {
    // Error "Property 'children does' not exist on type 'T'"
    console.log(x.children);

    // Error: x has no call signatures 
    x();

    // But the compiler says that these are okay?
    new x();
    x[100];
    x["hello"];
}

[DanielRosenwasser]

I'm going to say this is a bug, but @RyanCavanaugh and others can weigh in.

[RyanCavanaugh]

It's behaving according to spec. x: T acquires the apparent members of any; the behavior of all property accesses / functions calls being allowed on any is a result of the language in the checking of those respective definitions.

We should probably just change that language to say "is any or a type parameter constrained to any"

[sandersn]

The fix is up at #8770