Added type guard overload ReadonlyArray.prototype.every

[NaridaL]

Fixes #14963

[NaridaL]

Do the test.symbols and the test.types files not get generated if there are errors? Is there a better way of testing for errors so that those still get generated?

[NaridaL]

OK, something's not working with the inference...?

[RyanCavanaugh]

Do the test.symbols and the test.types files not get generated if there are errors?

Correct. Best practice is to have one testcase with all the error cases, and one testcase with zero errors. This is also better for future reviews since a file going from 0 to 1 errors will raise a red flag more quickly than a file going from e.g. 4 to 5.

[NaridaL]

OK, in the current state, there should be no errors. For some reason it's not working if the type parameter isn't specified explicitly. I'm not sure what the issue is.

[NaridaL]

OK, the issue was #18562, I've used a workaround, the tests pass as they should. This PR should be mergeable as it is now.

[NaridaL]

@RyanCavanaugh any comment on the current state of the PR?

[RyanCavanaugh]

@mhegazy 👍 ?

[mhegazy]

We should have a similar change in Array as well. Array and ReadonlyArray should stay in sync.

[NaridaL]

@mhegazy Does that make sense? according to the linked issue

declare const strNumArr: (string | number)[]
const strNumArr2: (string | number)[] = strNumArr
if (strNumArr.every(isString)) {
   strNumArr2.push(23)
   // strNumArr now has type string[] and contains a number
}

... although tbh you can get the same prob with a ReadonlyArray with only slightly more effort.

[NaridaL]

@mhegazy Considering my last comment, this should be mergeable as-is? Or do we want to revisit the original issue?

[shanehsu]

@NaridaL Hope this get merged soon. Relying on .filter now. 👍

[DanielRosenwasser]

I think we're just waiting on having the appropriate overload in Array for consistency

[mhegazy]

Sorry for the late reply. i do not see why we should not do that for Array. we already handle filter the same way. Array and ReadonlyArray should always stay in sync.

[NaridaL]

@mhegazy

.filter() creates a new array. .every() doesn't so including the same overload for Array could lead to issues such as the one I describe here #18372 (comment). Does that not make sense? As far as I can tell this is the same conclusion reached in the base issue. #14963

[shanehsu]

This is a language issue then. TypeScript compiler have to track every reference assignment. More static analysis-like thing. Out of our hands now I suppose.

[typescript-bot]

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.

[simonbuchan]

@mhegazy I just hit this now, would you like an updated PR with the Array variant? Should I keep the current test location, or would it make sense to put it in tests/cases/conformance/experssions/typeGuards?

I noticed tests/cases/compiler/arrayFilter.ts doesn't test the type-guardiness.