Skip to content
New issue

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

Array.prototype.concat definition improvement #25716

Closed

Conversation

Ghabriel
Copy link

@Ghabriel Ghabriel commented Jul 17, 2018

Fixes #19535.

The compiler found some strange compatibility issues with the proposed solution by @mhegazy, as noted here. The alternative solution I used seems to work equally well.

Notable baseline change: the testcase at tests/cases/conformance/es6/spread/iteratorSpreadInArray6.ts no longer has errors... and IMO that's correct since Array.prototype.concat is a lot more flexible now.

@msftclas
Copy link

msftclas commented Jul 17, 2018

CLA assistant check
All CLA requirements met.

src/lib/es5.d.ts Outdated
* Combines two or more arrays.
* @param items Additional items to add to the end of array1.
*/
concat<U>(...items: (ConcatArray<U> | ConcatArray<T>)[]): (T | U)[];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first you do not need the first overload with this change. this one covers it already. second, we intentionally did not add this overload to avoid heterogeneous array creation. we think most ppl think of concat as maintaining the type of the correct array and adding elements of a different type is expected to be an error.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the unnecessary overload: indeed, I'll remove it. Regarding the heterogeneous array creation: the problem with not adding this overload is that it can lead to unintended heterogeneous array creation, as shown in the original issue. I don't agree that "most people think of concat as maintaining the type of the array", since it creates a new array. People with this kind of "false expectation" will likely get an error when they try to use the created array, so I don't see it as a problem...

@RyanCavanaugh
Copy link
Member

@Ghabriel can you resolve the merge conflicts please? We'd like to run this against our real world code suite and see the impact and then decide whether this is a good change in terms of possible breaks. Thanks!

@RyanCavanaugh RyanCavanaugh added this to the TypeScript 3.2 milestone Sep 17, 2018
@Ghabriel
Copy link
Author

Ghabriel commented Oct 4, 2018

Sorry for the long wait... I've fixed the merge conflicts but got some CI issues. I'll see if I can fix them this weekend.

@Ghabriel
Copy link
Author

Ghabriel commented Oct 6, 2018

@RyanCavanaugh I've fixed all merge conflicts. Sorry for the delay!

@RyanCavanaugh
Copy link
Member

@typescript-bot test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Oct 8, 2018

Heya @RyanCavanaugh, I've started to run the extended test suite on this PR at 410b5cd. You can monitor the build here. It should now contribute to this PR's status checks.

@RyanCavanaugh
Copy link
Member

@typescript-bot test this again

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 25, 2019

Heya @RyanCavanaugh, I've started to run the extended test suite on this PR at 410b5cd. You can monitor the build here. It should now contribute to this PR's status checks.

@RyanCavanaugh RyanCavanaugh self-assigned this Jan 25, 2019
@andersk
Copy link
Contributor

andersk commented Jan 26, 2019

This fails to disallow

const a: number[][] = [[1]].concat([[2]], [3])
// → [[1], [2], 3]

(Personally, I think we should remove that other overload concat(...items: (T | ConcatArray<T>)[]): T[]. Yeah it happens to run in JavaScript—if T is not itself an array type as in the above example. But we disallow 10 > "9" even though it happens to run in JavaScript, because it’s confusing; you should have written 10 > +"9" if that’s what you meant. We should similarly disallow [1].concat([2], 3) because you should have written [1].concat([2], [3]).)

@RyanCavanaugh
Copy link
Member

This turns out to have some fairly gnarly breaks in RWC. We'd prefer to leave as-is for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Soundness issue with Array.prototype.concat and arrays of arrays
7 participants