Added type guard overload ReadonlyArray.prototype.every

[Adrian Leonhard (NaridaL)]

Fixes #14963

[Adrian Leonhard (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?

[Adrian Leonhard (NaridaL)]

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

[Ryan Cavanaugh (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.

[Adrian Leonhard (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.

[Adrian Leonhard (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.

[Adrian Leonhard (NaridaL)]

Ryan Cavanaugh (@RyanCavanaugh) any comment on the current state of the PR?

[Ryan Cavanaugh (RyanCavanaugh)]

Mohamed Hegazy (@mhegazy) 👍 ?

[Mohamed Hegazy (mhegazy)]

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

[Adrian Leonhard (NaridaL)]

Mohamed Hegazy (@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.

[Adrian Leonhard (NaridaL)]

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

[徐鵬鈞 (shanehsu)]

Adrian Leonhard (@NaridaL) Hope this get merged soon. Relying on .filter now. 👍

[Daniel Rosenwasser (DanielRosenwasser)]

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

[Mohamed Hegazy (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.

[Adrian Leonhard (NaridaL)]

Mohamed Hegazy (@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 (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.

[Simon Buchan (simonbuchan)]

Mohamed Hegazy (@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.