never-returning branches should not be considered when determining whether a property is initialized in a constructor

[ssalbdivad]

🔎 Search Terms

constructor, initialization, initialized, 2564, never, throw, error

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://tsplay.dev/w6Q9yW

💻 Code

const throwParseError = (def: unknown): never => {
    throw new Error(`${def} is not a valid definition`)
}

class Foo {
    // Property 'bar' has no initializer and is not definitely assigned in the constructor.(2564)
    bar: string

    constructor(def: string | null) {
        if (def === null) {
            // this return pattern is useful for narrowing
            // if you remove `return` here, the initialization error goes away
            // but the assignment to bar is then an error
            return throwParseError(null)
        }
        this.bar = def
    }
}

🙁 Actual behavior

TypeScript reports that Property 'bar' has no initializer and is not definitely assigned in the constructor.(2564)

🙂 Expected behavior

TypeScript should identify that in every viable branch of the constructor, bar is assigned.

Additional information about the issue

No response

[MartinJohns]

Make your function a never returning function and drop the return keyword and it works as you expect.

Your lack of annotation for throwParseError means it's not analyzed for control flow. TypeScript does not consider your return throw..() as a throwing operation, just as an early returning constructor, so the property remains uninitialized.

[ssalbdivad]

Martin Johns (@MartinJohns) Thanks, I was a bit hasty creating the repro here and have updated it to include never as an explicit return for the function.

However, this is is an issue I've run into for a long time (Mateusz Burzyński (@Andarist) finally convinced me to create it 😅) and if you don't return, you lose narrowing. Another option would be to narrow bar without having to return, but since TS doesn't do that in general I assume it would be a bigger problem for CFA.

[nmain]

It seems to work as expected when Martin Johns (@MartinJohns) 's suggested changes are made:

const throwParseError: (_: unknown) => never = (def: unknown): never => {
    throw new Error(`${def} is not a valid definition`)
}

class Foo {
    // Property 'bar' has no initializer and is not definitely assigned in the constructor.(2564)
    bar: string

    constructor(def: string | null) {
        if (def === null) {
            // this return pattern is useful for narrowing
            // if you remove `return` here, the initialization error goes away
            // but the assignment to bar is then an error
            throwParseError(null)
        }
        this.bar = def
    }
}

https://www.typescriptlang.org/play?ts=5.4.0-dev.20231110#code/MYewdgzgLgBFAWAnEB3ACgQ0RApgUUWUQC4YAKAfVIFcwBrMVMAShgF4A+GMHANx0TtyAExwAzGvUYoWpHv0GcYAbwBQMDXCSpuOFDAJEyAAwAky0WIC+MAJYRuIWBhi8MAG1vCYl22FtQtuDGzKpWqqrA7hgQDgBiICAq6poA9KkwaMgADgJQAJ4wAOQARlhFMPAxjnb+gR62AF4CMBhg3vaOsL51OO6FMRC2AOY8HWBaODCgkFCI1MBQIIgAdGQATACsAGwALKGaMGUkMNCIfsMRhzNnC0uIZJakZxcwAD7c1O7urGqHh7YxCJxOw2GxPt9fil-v90lpOogcFBqIgJtkMFAoAIJp1qLgxF8YGJltwsMgUBdoTC0hlATB8iBqDBEQBbED8GDGRHI1HGSoCHAAGkmtQCtgajQxQQmAiIMGGIBwDgwKAw+Sp1JgcJK1FgCCmgxGYBZODAeqSxzsDn1EzaMFlyw11IQ5Mw2HwhGWZDAXx+To04U1CHsK0t4MsVPC4SAA

[MartinJohns]

if you don't return, you lose narrowing

This is not the case when you use a never returning function and call it accordingly. Because of the return keyword it's not analyzed as an assertion function.

[ssalbdivad]

Nicholai Main (@nmain) Interesting that if you annotate throwParseError directly instead of its return, it works. Suppose it makes sense based on some other issues with the way CFA handles arrow functions.

However, in this case as in other cases (e.g. using an arrow function in an asserts predicate), there should be a way to treat it as equivalent to a top-level function in terms of its signature inference if the return is explicitly annotated.

[ssalbdivad]

Martin Johns (@MartinJohns) TS should be able to identify this as a never-returning function:

const throwParseError = (def: unknown): never => {
    throw new Error(`${def} is not a valid definition`)
}

[MartinJohns]

TS should be able to identify this as a never-returning function:

There is an open issue about this that I just don't have at hand right now. Will edit the comment when I found it.

[ssalbdivad]

Based on Nicholai Main (@nmain)'s workaround, it seems like this is likely a duplicate of the issue I logged for resolving the signature of an arrow function at this stage:

#56147

Martin Johns (@MartinJohns) this is probably what you mean

I will leave this open for now but fine with me if the team confirms it's the same underlying issue and wants to track it there.

[MartinJohns]

I think I'm thinking of another issue that I can't seem to find on mobile right now, but that issue you linked works as well. :-D

[ssalbdivad]

I think the main problem with these is that unless you know about this nuance of when TypeScript resolves arrow function signatures and how it can use them, you'd never think to explicitly annotate the variable as a workaround (in addition to the syntax being much clunkier).

Even having logged that other issue, it didn't occur to me until I saw Nicholai Main (@nmain)'s repro that it was related, especially since in this case there is no explicit asserts predicate.

[MartinJohns]

I found this which is highly related to your last comment: #36067

I think it should be added to the FAQ.

[ssalbdivad]

Martin Johns (@MartinJohns) Thank you, it's great to know that exists!

Documentation would be nice, but IMO in this case it should just be fixed. This is a lot less messy than most CFA scenarios in TS. Just check if a variable is an arrow function with an annotated return, and if so treat it like a normal function declaration in terms of signature resolution.

[RyanCavanaugh]

Just check if a variable is an arrow function with an annotated return

We discussed this option and decided that the inconsistency of some objects needing an explicit type annotation and some not felt more like a bug than the existing behavior

[ssalbdivad]

Ryan Cavanaugh (@RyanCavanaugh) Can you give an example of these objects?

It seems like a top-level arrow function is such a common case, and it's clearly analogous to the annotated form like const throwParseError: (def: unknown) => never = .... Even syntactically it looks the same.

I also do feel like regularly there are cases where explicit returns are required (e.g. for recursive functions) and while there may be cases where TS ideally could infer them, I don't consider those bugs. I don't consider this exactly a bug either, but I do feel like it is hard to deny handling that case explicitly would result in an overall better experience for most TS devs.

[RyanCavanaugh]

const obj = {
  blah: (): never => { throw null }
}

// Why not controlflowed? Seems like a bug!
obj.blah();