GeezerVison

I've hoped that this solution would make it work (somehow through CFA) for at least the in variant:

function f5(obj: Record<string, string>, prop: string) {
    if (obj[prop]) {
        obj[prop]; // actual: string | undefined; expected: string
    }
    if (prop in obj) {
        obj[prop]; // actual: string | undefined; expected: string
    }
}

Is this kind of analysis supported for any kind of patterns today?

obj[prop] where prop isn’t a hardcoded literal can’t be narrowed in any way to my knowledge. There are many, many issues attesting to that if you go looking, and it’s considered to be by design.

Ye, I've figured out as much - although I wonder how hard a limitation that is.

Everything gets duped to #10530 which is kind of misleading since that issue was originally about bracketed access with a literal key (which has since been fixed), but the picture that develops after enough hunting is that it’s a performance sinkhole. See e.g. #25109 (comment)

Mateusz Burzyński (@Andarist) It works when prop is declared as a const with a singleton literal type, e.g. const prop = "foo", but no support beyond that. We could conceivably support non-singleton-literal-type const variables, but it isn't trivial.

There are many, many issues attesting to that if you go looking, and it’s considered to be by design.

I understand that this seems difficult to implement and we might never get this feature, but I'm having a hard time understanding how this could be "by design". What I mean is, this seems like fairly straight forward JS and as far as I understand TypeScript's design goals, we really should be able to support (type correctly) this kind of code. I really am sympathetic to the fact that it might not be feasible to do in the current implementation, I'm just challenging the idea that we want it to be this way.

“By design” = ”intentional decision made during the design process”. Some such decisions are known compromises. I don’t use the phrase to imply it’s what the user wants, because nobody can even define that except for the individual users themselves, and the team can’t go around asking every single user before they’re allowed to label things “working as intended”. 😉

Sure there always needs to be compromises made in the design of the language, but this isn't that. This seems to be a limitation of the current implementation (an implementation detail if you will), not some inherent limitation in the design of the language itself.

I mean, the implementation is still part of the design of the TypeScript compiler in particular. Obviously a language wouldn't be intentionally designed that way in isolation, but that's a moot point since there's no TypeScript language specification. There used to be a formal spec a long time ago, but nowadays the implementation is the specification, and that's an entirely pragmatic design process. If the implementation is designed a certain way, in practice that means the language is too.

...at least until someone gets fed up with the limitations and makes an alternative implementation. 😅

wow, how does this one work if hasOwnProperty's signature is "just":

hasOwnProperty(v: PropertyKey): boolean;

what kind of sorcery is going on here? :D does this method have some special support in the compiler itself?

does this method have some special support in the compiler itself?

It does indeed.

I’m going to assume that feature was implemented early on since nowadays feature requests to special-case built-in methods (like Object.assign) get rejected if the special case can’t be represented in the method signature.

For reference, I found the code related to hasOwnProperty here