Reinterpret a type parameter constrained to any as an upper bound constraint

[Wesley Wigham (weswigham)]

Fixes#29509

Note, that we have a test that asserts that a type parameter explicitly extending any behaves like any when accessing its members (which IMO is strange). This would be a break to that behavior.

[Ryan Cavanaugh (RyanCavanaugh)]

TypeScript Bot (@typescript-bot) test this

[TypeScript Bot (typescript-bot)]

Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the extended test suite on this PR at 570c756. You can monitor the build here. It should now contribute to this PR's status checks.

[Ryan Cavanaugh (RyanCavanaugh)]

Also run on DT

[Wesley Wigham (weswigham)]

TypeScript Bot (@typescript-bot) run dt

[TypeScript Bot (typescript-bot)]

Heya Wesley Wigham (@weswigham), I've started to run the Definitely Typed test suite on this PR at 7c13b70. You can monitor the build here. It should now contribute to this PR's status checks.

[Wesley Wigham (weswigham)]

Updated the test that needed changing to a constraint that actually typechecks, and looked at DT - failures are in ramda (and are also failing in master due to the recent function generic inference changes) and in a package callec victory - the diff in victory appears unrelated and already fixed, given that a local dtslint on it run doesn't show any errors.

So this seems pretty good - if anything, like the tests I just changed, it's going to identify places we were silently allowing unsafe operations.

[Ryan Cavanaugh (RyanCavanaugh)]

Wesley Wigham (@weswigham) let's merge for 3.5

[Nathan Shively-Sanders (sandersn)]

Wesley Wigham (@weswigham) this sounds like it's ready to go, right?

[Wesley Wigham (weswigham)]

Probably. The change itself is small, so barring merge conflicts, should still be OK.

[Nathan Shively-Sanders (sandersn)]

After a merge from master: toString is now available on type parameters that extend any. That's the only difference I can see.

[Nathan Shively-Sanders (sandersn)]

Let's wait until Ryan Cavanaugh (@RyanCavanaugh) is back to merge this.

[Nathan Shively-Sanders (sandersn)]

I talked to Ryan Cavanaugh (@RyanCavanaugh) about this just now, so I'm going to merge it.

[Nathan Shively-Sanders (sandersn)]

Wesley Wigham (@weswigham) this causes a failure in DT on wordpress__block-editor-tests.tsx. Can you try to fix it? It looks like the offending signature is this:

declarefunctionwithColorContext<ProvidedPropsextendsPartial<withColorContext.Props>,OwnPropsextendsany,TextendsComponentType<ProvidedProps&OwnProps>>(component: T):
TextendsComponentType<infer U> ? ComponentType<Omit<U,'colors'|'disableCustomColors'|'hasColorsToChoose'>&Omit<ProvidedProps,'hasColorsToChoose'>> :
never;

Previously the second type argument was inferred OwnProps=any; now it's OwnProps=unknown (as expected).

If there's a mechanical fix to update existing code, it'd worthwhile to have that in the release notes for 3.9.

[Wesley Wigham (weswigham)]

If there's a mechanical fix to update existing code, it'd worthwhile to have that in the release notes for 3.9.

Write an Extract everywhere we now (correctly) flag as a type error, `(or, better yet, write types that actually check out without contortions). It's the typesystem equivalent of a typecast, but it's much more explicit.

eg,

typeGetClass<Textendsany>=T["class"];// could betypeGetClass<T>=Extract<T,{class: any}>["class"];

obviously, you can replace Extract with a helper that provides a more reasonable default on failure than never for your given situation, too.

this causes a failure in DT on wordpress__block-editor-tests.tsx. Can you try to fix it? It looks like the offending signature is this:

What's broken about it? the signature itself has nothing wrong as far as I can tell, so you're talking about a specific usage, right?

[Wesley Wigham (weswigham)]

What's broken about it?

If the answer is "we now infer unknown instead of any at use sites because we never make inferences", adding an = any default will silence the error and change the default only back to any. But I'd still consider an any-defaulting inference questionable, myself. You probably shouldn't have type parameters you can never infer...

[Nathan Shively-Sanders (sandersn)]

Yes, line 142 of the tests. Probably = any to silence the error is good enough really.