You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
typeA={x: number};typeB=A&{y: number};constfoo=(a: A): asserts a is B=>{if((aasB).y!==0)throwTypeError();returnundefined;};exportconstmain=()=>{consta: A={x: 1};// TypeError: Assertions require every name in the call target to be declared with an explicit type annotation.(2775)foo(a);};
π Actual behavior
It looks like they goal of #45952 was for assertion predicates to work for arrow functions, but this only handles the JSDoc case, which I assume TS treats as equivalent to directly annotating the entire function at once, i.e.:
constfoo: (a: A)=> asserts a is B=(a)=>{};
For functions with more named parameters, this annotation style quickly becomes unwieldy. There is no semantic difference between this annotation or the style from the repro:
constfoo=(a: A): asserts a is B=>{};
Is it possible to identify a top-level arrow function like this assigned to a const variable with annotated parameters and return as having an "explicit type," which was defined as the standard for being able to use an assertion predicate like this in @ahejlsberg's initial PR (#32695)?
This style is increasingly common, and I think many developers (my self included) simply write a function like this, see it doesn't work, then choose not to use the feature, not knowing something like moving the annotation to the variable itself could have an effect.
π Expected behavior
(see above)
Additional information about the issue
No response
The text was updated successfully, but these errors were encountered:
Unfortunately, it is indeed a design limitation that foo must be explicitly annotated. Annotating the arrow function itself isn't enough - the compiler doesn't know the type of foo until type inference kicks in, which happens after the control flow graph is computed.
@fatcerberus Do you know if there's a mechanism for this to be special-cased? It seems like it would be relatively simple to detect a top-level arrow function declaration.
π Search Terms
arrow function, assertion, predicate, 2775
π Version & Regression Information
β― Playground Link
https://tsplay.dev/w8QLpN
π» Code
π Actual behavior
It looks like they goal of #45952 was for assertion predicates to work for arrow functions, but this only handles the JSDoc case, which I assume TS treats as equivalent to directly annotating the entire function at once, i.e.:
For functions with more named parameters, this annotation style quickly becomes unwieldy. There is no semantic difference between this annotation or the style from the repro:
Is it possible to identify a top-level arrow function like this assigned to a const variable with annotated parameters and return as having an "explicit type," which was defined as the standard for being able to use an assertion predicate like this in @ahejlsberg's initial PR (#32695)?
This style is increasingly common, and I think many developers (my self included) simply write a function like this, see it doesn't work, then choose not to use the feature, not knowing something like moving the annotation to the variable itself could have an effect.
π Expected behavior
(see above)
Additional information about the issue
No response
The text was updated successfully, but these errors were encountered: