Constrain object literal without losing the keys and values

[Ciantic]

Simple example:

var out: {[name: string] : number} = { a: 5, b: 10 };
out.a // Is not valid

It would be nice if we could retain the keys and values, but still constrain the object literal. For backwards compatibility it probably can't be introduced in above syntax, but perhaps new syntax is required like var out: Object<string, number> or something.

Here is a longer use case, where it is important to retain the keys and values:

interface Field<T> {
    clean(input: T): T
}

class CharField implements Field<string> {
    clean(input: string) {
        return "Yup";
    }
}

class NumberField implements Field<number> {
    clean(input: number) {
        return 123;
    }
}

class ObjectField<A, T extends { [name: string]: Field<any> }> implements Field<A> {
    fields : T
    constructor(fields : T) {
        this.fields = fields;
    }

    clean(input: A) {
        return <A>{}
    }
}

var person = new ObjectField({
    id: new NumberField(),
    name: new CharField()
});

person.fields.id // Is not valid at the moment

It does work if I remove the constrain, and modify it to this:

class ObjectField<A, T> implements Field<A> {
    fields : T
    constructor(fields : T) {
        this.fields = fields;
    }

    clean(input: A) {
        return <A>{}
    }
}


person.fields.id // Is valid and checks as NumberField!

But now I loose the constraint on the T, which in this case should say that right hand side of T is Field.

As a bonus, If one looks at the ObjectField really hard, it is difficult to use it without this: #3448 implemented also.

[DanielRosenwasser]

Why not add properties to the type of interest?

var out: {[name: string] : number; a: number; b: number} = { a: 5, b: 10 };
out.a // is now valid

[Ciantic]

@DanielRosenwasser check out the full use case at the bottom:

var person = new ObjectField({
    id: new NumberField(),
    name: new CharField()
});

person.fields.id // Is not valid at the moment

Where should I shovel those, write them all again in generic?

Edit and the example above is pretty one, I could come up a schema that is ~30 lines of CharFields, nested ObjectFields and NumberFields.

[JsonFreeman]

The issue is that we do not take the apparent type of the contextually type when we do inferential typing. Believe it or not, the following bug stems from the same issue:

function foo<T extends (p: string) => number>(x: T): T {
    return undefined;
}

foo(x => x.len); // No error