TC39 General on 2023-06-13

01:16	<ljharb>	tbh i'd say that if the catch is in a separate file from the finally, then the finally file probably shouldn't be assuming the promise is handled - iow, the author of one file shouldn't assume knowledge of the code in another one
11:05	<matlokam>	Hey! I have a random question: was the idea of `Array.prototype.clear()` ever struck down in TC39? I've had repeated experiences of `array.length = 0` not being trusted by developers, despite being the best way to do clear an array, so I was thinking if a `.clear()` proposal would have a future
11:06	<matlokam>	Just coming from Python, Java, C#, Rust, or almost any language, you expect `.clear()`
11:07	<nicolo-ribaudo>	Why would `.clear` be trusted more? Btw, you can also use `arr.splice(0, arr.length)`
11:08	<matlokam>	It seems sketchy, despite being valid, which is just an odd developer experience
11:11	<matlokam>	It felt much more like regular JS in 2014, but JS has improved so much in terms of the developer experience since ES6, that now it just feels out of place :D
11:14	<matlokam>	For instance, of course `.indexOf() > -1` was and still is completely valid – nonetheless `.includes()` is the clear way of doing the same since it was added ES2016
11:16	<voidhedron>	Not to mention the edge-case where you have non-array-index extra properties in an array instance, which will not be cleared by `array.length = 0;`
11:16	<ptomato>	would those be cleared by a `.clear()` method though?
11:17	<voidhedron>	Imo they should
11:17	<ptomato>	I can think of arguments in either direction
11:18	<voidhedron>	Well argument in favor of it is, if you don't want the behavior of clearing non-indexes, you can just resort back to the original length method
11:19	<voidhedron>	Thinking about it further, we could also take this further and invert it
11:20	<Andreu Botella>	`Map.prototype.clear` doesn't remove properties on the map object -- is array different because the indices are actual properties in the object?
11:20	<voidhedron>	While to Array there is the distinction between indexes and properties, from an Object perspective, both are just properties, so what if instead clear() was added as an Object method?
11:20	<voidhedron>	and it would just generically work on arrays
11:21	<voidhedron>	`Map.prototype.clear` doesn't remove properties on the map object -- is array different because the indices are actual properties in the object? That was my thinking at first there yes
11:26	<matlokam>	Hmm, non-index properties on arrays seems like a niche use case outside of well-defined bounds of behavior
11:26	<matlokam>	I would stick to Map-like semantics of just emptying the collection
11:28	<matlokam>	That's up for further discussion though I suppose
11:28	<matlokam>	Well, do y'all know if the method makes sense as a proposal, or is there a reason why the idea is dead in the water?
11:28	<voidhedron>	My idea now is that, since arrays don't need a special method to access their internal values due to being just regular object properties, we should just make a generic object clear() method, which just works generically on arrays by extension
11:30	<voidhedron>	So it is less niche and actually implements a new ability (clearing objects without manual looping of deletions) that was not previously possible unlike just clearing arrays with `.length = 0`
11:31	<matlokam>	Well, if it clears non-indexes, then why wouldn't it also delete `.length`? 😅 That's a tricky bit
11:32	<voidhedron>	It can be defined like so: `Object.clear(obj)` = Delete all own, enumerable properties of `obj` `.length` is non-enumerable, so it would be preserved.
11:32	<matlokam>	I think the semantics would be clearer language-wide if `.clear()` always meant – clear collection. And `Object` is not necessarily the way of implementing a collection, given it's the building block for everything (e.g. if you want a mapping, well, `Map` is often the best option)
11:34	<voidhedron>	`Map` is often too verbose and unnecessary for quick mapping needs
11:35	<voidhedron>	In terms of data structures Map and Object are essentially the same, so saying Objects aren't collections is a bit illogical imo
11:36	<voidhedron>	Map is just Object with fancier methods to manage it, no reason Object couldn't get some for itself
11:37	<voidhedron>	Although I did just realize .clear() in Object prototype would indeed be prone to a lot of conflicts and confusion so it'd be probably best as a static method
11:37	<voidhedron>	`Object.clear(arr)`
11:37	<Andreu Botella>	you'd also have to figure out what to do for own vs inherited properties
11:37	<Andreu Botella>	are you deleting non-enumerable properties as well?
11:37	<voidhedron>	It can be defined like so: `Object.prototype.clear()` = Delete all own, enumerable properties of `this` `.length` is non-enumerable, so it would be preserved. ^
11:38	<voidhedron>	Just own enumerable props, anything else would break prototypes and other things
11:39	<voidhedron>	it'd be a shallow clear, which follows suit with pretty much every other iterative operation in JS with the notable recent exception of the long awaited `structuredClone`
11:39	<voidhedron>	so JS devs are already used to these kinds of operations being shallow I'd say
14:54	<Chris de Almeida>	`arr.splice(0)`
14:55	<Chris de Almeida>	so you're adding `arr.clear()` to accomplish `arr.splice(0)`. does that seem worthwhile?
15:40	<matlokam>	I would say the answer is exactly the same as with adding `.includes()`
16:27	<Chris de Almeida>	point taken. there were some additional considerations for includes that don't apply here. in any case, I'm not against convenience methods, though I'm not convinced in this particular case that splice or length leave much to be desired
16:27	<Chris de Almeida>	it's worth noting that additional methods on `Array.prototype` will face resistance in committee
16:27	<Justin Ridgewell>	(I haven't read the full thread, lots of messages since I last checked) A few delegates said in the last meeting they're reluctant to add new methods to `Array.prototype` due to web compatibility issues we always have
16:29	<Chris de Almeida>	`Array.prototype.group` was changed in the last meeting to use static methods on Map and Object instead
16:29	<Justin Ridgewell>	https://github.com/tc39/notes/blob/main/meetings/2023-05/may-16.md#arrayprototypegroup-rename-for-web-compatibility
16:29	<Chris de Almeida>	ref 1: https://github.com/tc39/notes/blob/d2a0097ec28f18d221118577086e20f78c33b504/meetings/2023-05/may-16.md#speakers-summary-of-key-points-4 ref 2: https://github.com/tc39/notes/blob/d2a0097ec28f18d221118577086e20f78c33b504/meetings/2023-05/may-18.md#speakers-summary-of-key-points-3
16:37	<bakkot>	generally speaking, I think "some developers feel that the syntax for doing a thing is sketchy" is not a good enough reason to add a new stdlib method
16:38	<bakkot>	`.length = 0` is not obscure or difficult to understand for readers, so I don't see much reason to add a `.clear` to arrays
16:53	<ljharb>	matlokam: i wouldn't want to add any new mutating methods to Array, personally. if you want an empty array, `[]` is right there :-)
17:05	<annevk>	I think assigning to `length` is at least somewhat obscure. For most collections `length` doesn't have a setter. Having parity with other collections makes sense to me.
17:07	<bakkot>	for most collections you can't use syntax to read from it either
17:20	<Chris de Almeida>	generally not prohibitive, but this won't work with `const`, so not always an option
17:53	<annevk>	Right, there was a conscious decision to not carry that forward. I don't think that disqualifies adopting more modern APIs for the older collection type though.
18:08	<bakkot>	I generally see APIs as being worse than syntax, though
18:08	<bakkot>	Like I'd prefer people not write `array.at(5)` even though that's more consistent with what you'd do with a Map
18:08	<bakkot>	similarly I'd prefer people not write `array.clear()` even though that's more consistent with what you'd do with a Map
18:09	<bakkot>	I don't think it's really a matter of what's "more modern". Arrays are just a more foundational type and so have somewhat different affordances
21:39	<littledan>	I agree that writing to `length` is somewhat obscure and so it wouldn't be bad to have a duplicate API around it. But also I don't understand why this method would be important/useful enough to be worth the high cost of adding Array methods.
21:48	<voidhedron>	Another reason I think making it a generic Object static method would be more worthwhile and easier to get going
21:49	<voidhedron>	It wouldn't go anywhere near Array but still be able to serve the task desired at hand, while also having other possible use-cases with non-arrays
21:50	<littledan>	idk, I think it's generally not a good idea to encourage folks to treat Arrays like general objects API-wise (I think this doesn't match most JS developers' intuition)
21:53	<bakkot>	I also don't want to encourage people to clear properties from objects
21:53	<bakkot>	there are cases where that is the right thing but they are few and far between
21:53	<voidhedron>	idk, I think it's generally not a good idea to encourage folks to treat Arrays like general objects API-wise (I think this doesn't match most JS developers' intuition) That's a fair point, and I kind of agree I suppose, but on the other hand there is plenty of existing stuff in the language that does that already, so i dunno it would just be 1 more to the pile
21:57	<voidhedron>	I also don't want to encourage people to clear properties from objects Well I suppose it could be `Array.clear` (static method) instead then, with a strict isArray check on the argument, I do would like that more as well personally, it just seems that it'd be harder to get it accepted due to being connected to `Array`
21:59	<bakkot>	Yeah and then my answer is, that is not worth having, vs just writing `arr.length = 0`
22:00	<littledan>	Yeah I think, if we decide this kind of manipulation is important to support more intuitively, `Array.clear` is a good place to put it.
22:35	<shu>	is the proposed semantics of clearing actually `delete`
22:35	<shu>	if so please no
23:09	<matlokam>	Really interesting points around here
23:48	<matlokam>	So to condense the point, in my view there are a few arguments for adding `Array.prototype.clear()` as stdlib sugar for `.length = 0`: The base case for it is just that it would be the "one obvious way" of performing a common operation – emptying an array. Obvious in terms of the developer experience as well as performance, which is not quite the case for any of the solutions JS developers have today (and usually have to learn from StackOverflow): `= []` for one requires usage of `var`/`let`; not in-place, which can be seen at a glance, so immediately not ideal performance-wise `.length = 0` is just not the way this works in any mainstream other language, this trips developers up `.splice(0)` works quite sensibly, but the semantics of splicing are a bit different, so this again isn't the obvious way of doing this Coming from most other mainstream languages (e.g. Java, C#, C++, Python, Rust, Kotlin), you just use `.clear()` to empty an array (aka vector/list). The convention is basic to the core. In terms of the cost of adding Array methods, JS has come a long way since ES2015 and the new annual release process. There's really good precedent: `Array.prototype.find()` in ES2015 (just sugar over a `for` loop), `Array.prototype.includes()` in ES2016 (sugar over `.indexOf()`, which itself is sugar over a `for` loop) or this year: `Array.prototype.toSorted()` (sugar over `.slice().sort()`, again all coming down to iteration). All really good quality-of-life improvements, and rather comparable to `Array.prototype.clear()` both in terms of implementation complexity (low on the scale) and utility (fulfilling a specific but universal use case)