Allow decorators to apply type guards to arguments of the method/function they decorate

[Barely-Awake]

Bug Report

🔎 Search Terms

decorators, type guards

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about decorators

⏯ Playground Link

Playground link with relevant code

💻 Code

class LogPerson {
    @isNamePresent
    log(person: Person) {
        // person.name is guaranteed to be a string due to @isNamePresent decorator, yet error is still thrown
        thisNeedsPersonName(person.name)
    }
}

interface Person {
    name: string | undefined
}

function isNamePresent(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        const originalFunction = descriptor.value;
        descriptor.value = function () {
            const person = arguments[0];

            if (person.name === null || person.name === undefined)
                return console.log("Person doesn't have a name");
            
            return originalFunction.apply(this, arguments);
        }
}

function thisNeedsPersonName(name: string) {
    console.log(`name is ${name}`)
}

🙁 Actual behavior

TypeScript throws the error Type 'undefined' is not assignable to type 'string'. when person.name is used as a parameter to a method guarded by the @isNamePresent decorator

🙂 Expected behavior

TypeScript should see the decorator's type guard show the person.name field as only being a string, not string | undefined.
This could be too closely related to function calls not resetting narrowing, in which case, just close this issue. Though I do think it is different enough where it might be possible to be fixed.

[MartinJohns]

Duplicate of #4881. Decorators do not provide the ability to change type information.

Last I read is that the TypeScript will first focus on decorator support (the current implementation is experimental and based on a deprecated proposal), and only then they'll consider looking at mutating types via decorators.

[fatcerberus]

This doesn't look like #4881 - the intention doesn't seem to be to change the contract of the class, but rather to add a type check to the implementation. So this is more equivalent to calling throwIfPersonHasNoName(person) and expecting TypeScript to automatically know person.name can't be undefined afterwards.

[Barely-Awake]

So this is more equivalent to calling throwIfPersonHasNoName(person) and expecting TypeScript to automatically know person.name can't be undefined afterwards

Yea, exactly. The way I think it might be able to be done is by basically combining the @isNamePresent function with the method below the decorator / the method it is decorating (In my example that'd be log) and then using that to figure out if any types have been narrowed by the decorator.

Not sure if it's possible, but I think it'd be a really nice thing to have implemented if it is possible.