We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ConcatArray
NB this issue is distinct from (but related to) #100. That issue is about the return type, this is about the parameter type.
Concatenating a mutable array to another array is currently flagged by no-unsafe-mutable-readonly-assignment:
no-unsafe-mutable-readonly-assignment
const arr: Array<string> = [""]; const foo: Array<string> = arr.concat(arr); // Flagged by no-unsafe-mutable-readonly-assignment
This is strictly correct, because concat takes a ConcatArray type that has readonly length and number index properties:
concat
interface ConcatArray<T> { readonly length: number; readonly [n: number]: T; join(separator?: string): string; slice(start?: number, end?: number): T[]; }
Even though this is correct (at least strictly speaking) it's not useful, because it cannot lead to surprising mutation in any readonly values.
We should treat this as a special case and ignore it in the no-unsafe-mutable-readonly-assignment rule.
Bonus points: are there any other methods (especially on the array type) that we should ignore for the same reason?
The text was updated successfully, but these errors were encountered:
No branches or pull requests
NB this issue is distinct from (but related to) #100. That issue is about the return type, this is about the parameter type.
Concatenating a mutable array to another array is currently flagged by
no-unsafe-mutable-readonly-assignment
:This is strictly correct, because
concat
takes aConcatArray
type that has readonly length and number index properties:Even though this is correct (at least strictly speaking) it's not useful, because it cannot lead to surprising mutation in any readonly values.
We should treat this as a special case and ignore it in the
no-unsafe-mutable-readonly-assignment
rule.Bonus points: are there any other methods (especially on the array type) that we should ignore for the same reason?
The text was updated successfully, but these errors were encountered: