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

Normative: Array Constructor #1331

Closed
zfrisch opened this issue Oct 15, 2018 · 6 comments
Closed

Normative: Array Constructor #1331

zfrisch opened this issue Oct 15, 2018 · 6 comments
Labels

Comments

@zfrisch
Copy link

zfrisch commented Oct 15, 2018

There is nothing inherently wrong with the Array Constructor, however, I am curious as to what the rationale is behind only allocating the memory and storing the reference ? It seems like an arbitrary choice ( as far as I know ) to not immediately populate the entirety of the Array with undefined - as that is, the majority of the time in my experience, the intention of the Developer, and a consistent pattern in ECMAScript in general when it comes to variables. This would allow for seamless and immediate use of the functional Array methods ( map, filter, reduce, etc.. ) and would overall improve the Developer experience.

As an example of how array works currently:
Array(10); // (10)[ empty x 10 ]
Array(10).map((_,i)=>i); // (10)[ empty x 10 ]

and the workarounds that are most often used:
[...Array(10)]; // (10)[undefined x 10]
[...Array(10)].map((_,i)=>i); // (10) [0,1,2, ... 9]

Array(10).fill(undefined); // (10)[undefined x 10]
Array(10).fill(undefined).map((_,i)=>i*2); // (10)[0,2,4, ... ,18]

Although I classified this under normative - If there wasn't an integral reason for this choice of a simple allocation and reference instead of a populated Array, it seems to me that changing the Array Constructor to accomodate undefined intead of empty wouldn't lead to any breaking of prior code, and only serve to benefit code concision and clarity.

Keep in mind this suggestion may stem from a place of unknown ignorance. I'm not nearly as well-versed in the underlying schematics of ECMAScript as I would like to be, but all the same, I haven't seen another topic devoted to it.

Thanks!

@tabatkins
Copy link

I don't know the reasoning, but this has been the behavior for literally decades, and so very likely can't be changed at this point due to web-compat.

@zfrisch
Copy link
Author

zfrisch commented Oct 15, 2018

I don't know the reasoning, but this has been the behavior for literally decades, and so very likely can't be changed at this point due to web-compat.

Oh, I can definitely see that being a thing - but I just find it to be so unusual, and with the ramped up development of the specification( the last few years especially ) I thought it was worth bringing to the table as an adjustment. From an outside-in perspective I personally don't know of any issues with the change, after all if Array(10) was changed to populate undefined, all the workarounds I believe would still continue to be valid though superfluous, and I doubt there would be a noticeable performance hit.

From an internal perspective I can definitely see that it might be difficult or impossible to change, or there might just be a good reason for the current setup, but it does seem like an improvement if it is possible, especially with the functionality added from es6 onwards.

@ljharb
Copy link
Member

ljharb commented Apr 28, 2019

The change would definitely break code, as there is code that relies on Array(n) producing sparse arrays. Array.from({ length: n }), however, will produce a dense one.

It would be interesting to hear the historical rationale from @BrendanEich, or from browser implementors, but I hope it's OK if i close this :-)

@ljharb ljharb closed this as completed Apr 28, 2019
@zfrisch
Copy link
Author

zfrisch commented May 19, 2019 via email

@ljharb
Copy link
Member

ljharb commented May 19, 2019

https://remysharp.com/2018/06/26/an-adventure-in-sparse-arrays seems like a useful article on the subject.

@zfrisch
Copy link
Author

zfrisch commented May 19, 2019 via email

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

No branches or pull requests

3 participants