TC39 General on 2022-02-14

01:34	<sachag>	hi again! State of JS survey guy here :) I just wanted to say I'm putting the finishing touches to this year's report, it should be available very soon
01:34	<sachag>	maybe once it's out we can do the call we discussed so you guys can give me some feedback for next year's edition?
01:58	<sachag>	here's an early preview (still working on the "JS" logo, that's why it says "CSS"): https://2021.stateofjs.com/en-US/
01:58	<sachag>	password: `js`
08:34	<sideshowbarker>	looking at https://github.com/mdn/content/issues/12643
08:35	<sideshowbarker>	in the code in that issue description, I’d have expected `const newCopy = { ...foundBananas }` does a shallow copy — and so, that `newCopy.quantity = 30` would also change the `quantity` property in `foundBananas`
08:36	<sideshowbarker>	…but it doesn’t change `foundBananas`; `foundBananas.quantity` is still `0`. Why?
08:41	<pokute>	For original bug, returning a copy would be pretty useless for `find` in most cases when I think about it. That way you wouldn't ever be able to use find to modify an entry in the original array.
08:44	<pokute>	in the code in that issue description, I’d have expected `const newCopy = { ...foundBananas }` does a shallow copy — and so, that `newCopy.quantity = 30` would also change the `quantity` property in `foundBananas` `const newCopy = { ...foundBananas }` indeed does a shallow copy. The code is practically the same as `const newCopy = { name: foundBananas.name, quantity: foundBananas.quantity, }`. You can see in the latter case where changing the value would not change the original.
08:51	<sideshowbarker>	so for being daft, but I guess I still don’t understand how using spread syntax here is different from `Object.assign()`
08:51	<sideshowbarker>	clearly I’m just looking at it wrong
08:53	<pokute>	so for being daft, but I guess I still don’t understand how using spread syntax here is different from `Object.assign()` Is it different?
08:54	<sideshowbarker>	`const newCopy = Object.assign(foundBananas); newCopy.quantity = 30; console.log(foundBananas.quantity); // 30`
08:58	<pokute>	For JS help, there are better places.
09:00	<pokute>	(The deleted conversation was just fixing a misunderstanding on JS behavior)
10:40	<Jessidhia>	Is there anything different about lists than sequences which makes it better on lists? What’s the distinction between a list and sequence? Is that distinction clear in most languages, or is it more distinct in C#? think of a Sequence as any abstract iterable, while a List has a defined memory layout
11:14	<sideshowbarker>	That would seem to suggest that a List is a subclass of an (abstract) Sequence — but the “Is there anything different about lists than sequences which makes it better on lists?” language that Eric Lippert uses in https://ericlippert.com/2009/05/18/foreach-vs-foreach/ seems to imply that they’re somehow two more-distinct things (in C#, I guess). But maybe I’m reading too much into it.
11:17	<sideshowbarker>	When I see “sequence” for me what comes to mind is C++, where there’s no Sequence as such in the language — nothing formally called that — but just the term “sequence” is used in C++ documentation to distinguish the `vector`/`array`/`list` containers from the associative containers.
11:19	<sideshowbarker>	And whereas in documentation for Java and Python (the main other languages I’m familiar with), there’s no set of things in the language that are typically referred to as “sequence” things.
11:20	<sideshowbarker>	Anyway, I suppose this is probably not very on-topic here. If so, apologies for the noise.
13:11	<Jack Works>	is there any discussion about weak import? 🤔
13:18	<pokute>	is there any discussion about weak import? 🤔 * --await-- import(); ?
13:20	<jmdyck>	sideshowbarker: The documentation for Python does have things referred to as "sequences": https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
23:03	<ljharb>	Jack Works: what would be the use case
23:03	<shu>	context: https://github.com/tc39/proposal-resizablearraybuffer/issues/91
23:04	<ljharb>	i think of it like `.slice()` (which would be the first one, i guess?)
23:04	<ljharb>	but that also means that i'd expect the return value to be the same kind of thing as the receiver - meaning, if the receiver is length-tracking i'd expect the subarray to be
23:05	<shu>	`.slice()` always creates a new TA entirely, with its own buffer
23:05	<shu>	`.subarray()` does not
23:05	<ljharb>	sure, i know it's a bit different :-) but i think of it in similar terms
23:05	<shu>	so the question doesn't apply to `.slice()`
23:05	<shu>	well, i mean the similarity doesn't make sense to me, since the "length tracking or not" really only makes sense if it's the same underlying buffer
23:05	<ljharb>	i'd still expect the newly created thing to be "the same" as the original one as far as various characteristics go
23:06	<ljharb>	i def see how it's not a clear answer - not sure if the poll helps answer it tho.
23:07	<shu>	"the same" is too imprecise to give me a sense here
23:07	<shu>	in the first option, if `ta` is length-tracking, i would not expect `ta.subarray(begin, ta.length - 1)` to create a length-tracking TA
23:08	<shu>	because i am explicitly asking for a subarray with a begin and an end, i.e. a fixed-length
23:10	<shu>	so the question is, if i omit the second `end` argument, do you think of it like if you gave an explicit `end` argument of the current last index of the TA (i.e. fixed-length), or do you think of it like you're creating a new TA of the same underlying buffer with no set end (i.e. length-tracking)?
23:11	<shu>	since resizable TAs don't exist today, the two views are semantically equivalent today
23:13	<TabAtkins>	google isn't helping me - what does "length-tracking" mean?
23:14	<shu>	see here: https://github.com/tc39/proposal-resizablearraybuffer#modifications-to-typedarray
23:17	<TabAtkins>	aha, so if the subarray is length-tracking, it means it inherits the "indefinite end" quality of the parent buffer?
23:18	<shu>	of the parent TA, not the parent buffer, but otherwise yep
23:19	<shu>	"resizable or not" is a quality of the parent buffer, and "indefinite end" is a quality of the original TA
23:23	<TabAtkins>	Right, right.
23:23	<shu>	ljharb: as for the slice question, the consensus currently is that `slice()` always create a new, non-resizable/non-growable ArrayBuffer
23:23	<shu>	so if you maximize for consistency with that, then i think you get that `subarray()` does not inherit the length-tracking-ness
23:24	<TabAtkins>	I think I like the latter behavior, since subarray is a view on the parent TA's buffer rather than a new buffer.
23:25	<shu>	it is technically possible that we change `slice(begin)` to also make a new resizable buffer, but i think that's strictly undesirable
23:26	<shu>	since most of the time you're probably taking slices for, well, a smaller portion of the buffer. if you make a new resizable buffer, you end up wasting virtual memory for no reason for the common use case
23:26	<shu>	TabAtkins: yeah, i can see that
23:27	<TabAtkins>	("latter" meaning "the second poll option", not to any pair of behaviors mentioned hence)