Bumping this since we ran into a situation with a leaked any in our own compiler. Minimal example:

function forEach<T, U>(array: T[], callback: (element: T, index: number) => U): U {
    if (array) {
        for (let i = 0, len = array.length; i < len; i++) {
            let result = callback(array[i], i);
            if (result) {
                return result;
            }
        }
    }
    return undefined;
}


forEach([1, 2, 3, 4], () => { 
    // do stuff
    if (blah) {
        // bam! accidental any
        return undefined;
    }
});

We need an implementation proposal for this one.

What if we just did this:

• Don't widen when you type a function body
• When you widen a type, and it's a function type, you widen the return type
• When you resolveName and it's a function expression or function declaration, you widen its type

I've arrived here via #7220. Would appreciate some guidance on whether the following is expected behaviour or not (playground):

interface G<K, R> {
    (v: K): R;
}

function F<T>(v: T): T {
    return v;
}

interface A {
    __Type: "A";
}

interface B {
    __Type: "B";
}

let a: A;
let b: B;

a = b; // OK: error as expected, B is not assignable to A
b = a; // OK: error as expected, A is not assignable to B

let x: G<A, B> = F;  // How is this possible?

It's the final assignment I cannot understand... because the compiler does not complain.

During assignment checking, type parameters are replaced with any. So the effective signature of F here is (a: any) => any

@myitcv See #138

Time to take this back up since it's affecting a lot of people writing reducers

export interface Demo {
    items?: () => { demo?: string };
}

export const dd: Demo = {
    items: (): ReturnType<Required<Demo>['items']> => ({ demo: '1', str: 'error' }),
};

Playground

We've noticed the same issue after some of the reducers returned garbage. Big surprise.

function reducer(state: IState, action: IAction): IState {
  switch (action.type) {
    case 'FOOL_TYPESCRIPT':
      return {
        ...state,
        ...{ ANY_NON_EXISTING_FIELD_GETS_SWALLOWED_WITH_NO_ERROR: "BOOM" },
      };

    default:
      return state;
  }
}

This problem affects any factory function that is intended to create a specific type. (From the form of #12632 )

interface OnlyThis {
  field: number
}
type FactoryFunc = () => OnlyThis
function makeOnly(ctor: FactoryFunc) { }

const test = makeOnly(()=> ({
  field: 123,
  extra: 456, // expected to fail, but does not.
}))

There's no way to prevent makeOnly from accepting a function returning an object with excess fields. It will detect missing fields, but not excess fields. Thus the user of makeOnly will no know that their values are being ignored.

@mortoray yes, this is my main issue with this. Currently, the only workaround is to explicitly type the arrow func, which kinda defeats the purpose:

const test = makeOnly((): OnlyThis => ({
  field: 123,
  extra: 456, // error
}))

Here is another minimal example of the problem:

const getFoo2: () => Foo =  {
	foo: {
		bar: number
	}
}  => ({
	foo: {
		bar: 1,
		buz: 2, // Doesnt throw an excessive property error
	}
})

The weird thing is, its not like the function is untyped. Changing the name of foo, or adding an excessive property to the main return object, works as expected. It only fails on the nested object.

I believe my StackOverflow question relates to this issue: https://stackoverflow.com/questions/63258306/how-to-force-typescript-excess-property-check-on-function-return-value

Hey everyone, I opened #40311 a couple of days ago which I think should fix most of the issues that have brought people here. If you'd like to give it a try, we have a build available over at #40311 (comment).

Hey @DanielRosenwasser, what's the status of your pull request? I suppose I don't have to list any reasons for wanting this feature (there are many discussions), so I'm only curious if there's been any progress recently