2021-08-01 [20:47:37.0468] Domenic: tracking that specifically at https://github.com/tc39/ecmarkup/issues/116, though it's not my highest priority 2021-08-02 2021-08-03 2021-08-04 [11:52:56.0139] help with https://github.com/mdn/content/issues/7593 would be much welcome [11:53:27.0800] * help with https://github.com/mdn/content/issues/7592 would be much welcome [11:54:34.0062] …even if just a comment added to this issue (short of a patch/PR) [11:55:30.0002] ES doesn't define ServiceWorker. [11:57:10.0755] Though there might be people here who could help anyway. [11:58:16.0779] jmdyck: sorry yeah I initially pasted in the wrong URL — the right one is actually https://github.com/mdn/content/issues/7592 [11:59:04.0440] Ah! I didn't notice the change. [11:59:46.0046] sideshowbarker: commented [12:00:30.0693] shu: do you know if there is an existing bug for v8 failing to throw on `new BigInt64Array( new Int32Array(0) )` [12:00:43.0432] it does (correctly) when `s/0/1/` [12:01:01.0982] I guess I'll just open one and let it get triaged [12:02:47.0634] no idea, the list of TA-related historical issues that're technically non-compliant with ecma262 is large and forboding, and mostly not worth the risk to try to fix [12:03:18.0307] though BigInt64Array is a new type... [12:05:04.0845] yeah, this is specifically an error which should happen when converting to (or from) one of the new Big* arrays, not a historical thing [12:11:22.0143] yeah, file it and assign it to me [12:13:00.0975] lol I get a 500 when trying to open an issue [12:13:06.0337] where do I file bugs in the bugtracker [12:14:26.0782] it... wfm? [12:14:53.0011] worked this time: https://bugs.chromium.org/p/v8/issues/detail?id=12052 [12:15:11.0926] I can't assign to you because I still don't have a Chromium account [12:30:03.0779] wait what is [[ContentType]] [12:30:19.0158] it's just to distinguish bigint or not bigint? [12:30:28.0809] yup [12:31:18.0009] hm, would've been clearer to encode that directly by casing on the element type rather than a field named [[ContentType]] [12:39:56.0799] possibly even in an AO? [12:40:00.0165] PRs welcome :P [12:47:14.0045] origin story: https://github.com/tc39/ecma262/pull/1515#discussion_r305633166 2021-08-05 [16:18:38.0882] it appears the Temporal.Duration polyfill and spec are out of alignment on the case `new Temporal.Duration().toString({ fractionalSecondDigits: 2})` [16:18:42.0913] * it appears the Temporal.Duration polyfill and spec are out of alignment on the case `new Temporal.Duration().toString({ fractionalSecondDigits: 2 })` [16:21:00.0603] * it appears the Temporal.Duration polyfill and spec are out of alignment on the case `new Temporal.Duration().toString({ fractionalSecondDigits: 2 })` (_where 2 can be anything between 1 and 9_) [16:37:14.0320] (in particular, step 13 of https://tc39.es/proposal-temporal/#sec-temporal-temporaldurationtostring is super unambiguous) [16:39:24.0834] that looks like a spec bug. probably we missed that case when adding fractionalSecondDigits. if you file an issue for it, I'll try and include it in the presentation for August TC39 plenary [16:48:19.0897] ah okay 2021-08-06 [17:02:55.0763] https://github.com/tc39/proposal-temporal/issues/1697 [11:01:25.0023] Does anyone know of any way to view the most popular NPM packages that depend on a specific NPM package, other than downloading a Gzemnid dataset? (npmjs.com can sort packages by popularity in its name search, and it can list the dependees of a specific package, but it can’t do both at the same time.) [11:08:58.0116] (Use case: Trying to find maximally impactful real-world examples of a library’s usage in the wild.) [11:09:33.0621] * (Use case: Trying to find maximally impactful real-world examples of a library’s usage in the wild, while writing a proposal explainer.) [11:11:48.0316] Also, I might be confused, but has https://gzemnid.nodejs.org/datasets/ not been updated since 2019? [13:14:11.0512] Hacker News is linking to a new IETF for UUID formats: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format [13:30:50.0686] Looks pretty neat! UUID v6 perhaps? [13:31:18.0696] (in the meantime, I still find 99% of UUID usages in the wild being v4) [13:31:30.0934] * (in the meantime, I still find 95% or more of UUID usages in the wild being v4) [13:38:23.0588] is "the integral part of _x_", where _x_ is a mathematical value, valid ecma262-speak? [13:39:47.0310] the only instance I can find in the current text is in the prose description of Math.trunc [13:40:28.0283] similarly, there are no references to "the fractional part of _x_" [15:11:50.0544] ptomato: I think you'd be better off using floor(x) and (x modulo 1), assuming that the semantics for x<0 are what you want. [15:13:24.0213] If they're *not* what you want, then you might have to define it, rather than just saying "the integral/fractional part". [15:19:35.0674] they are not, which is how I landed on this question [15:19:51.0777] I've currently got something like "Let _y_ be the mathematical value whose sign is the sign of _x_ and whose magnitude is _x_ modulo 1" [15:20:07.0261] for the fractional part [15:20:29.0598] which is a mouthful! [15:22:36.0854] I don't even think it' [15:22:41.0973] * I don't even think it's what you want. [15:23:37.0676] e.g. -3.1 modulo 1 is 0.9, so you'd be saying that the fractional part of -3.1 is -0.9 [15:25:47.0448] ah. the magnitude should be abs(_x_) modulo 1, then [15:49:25.0251] Alternately, "Let y be the mathematical value resulting from x - the integral part of x", or however exactly you spec-ese that. 2021-08-07 2021-08-08 [23:32:33.0510] shu: you may be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=1724618 in the context of proposal-rm-builtin-subclassing [23:47:58.0455] and also https://github.com/chakra-core/ChakraCore/issues/6736, https://github.com/Moddable-OpenSource/moddable/issues/680, and https://github.com/oracle/graaljs/issues/488 2021-08-09 [13:14:22.0162] yulia: I pushed up a handful of minor editorial tweaks to the TLA PR (see https://github.com/tc39/ecma262/pull/2408/commits; my first one was "adopt 545-style structured headers for new AOs", which you can ignore) - can you take a look over those when you get a chance? I think editors are all happy with it now, otherwise [13:14:42.0975] No rush though; I'll keep it rebased 2021-08-10 [00:47:02.0081] sure i will look today [02:04:25.0078] matrix spaces seem to be getting more stable. should we assign a stable alias to the TC39 space and start publicizing the link? [03:10:52.0216] bakkot: i read through everything, I think it looks good [03:11:08.0040] I have one question: is there a guidance I can follow on return values? https://github.com/tc39/ecma262/pull/2408/commits/b3e00d294a4fb150197bad80f236815a3de5608c [03:25:03.0095] this is also adjusted according to anba's comments https://github.com/tc39/ecma262/pull/2267 [09:25:00.0038] yulia: on returns, the guidance is basically, 1) if the return value isn't going to be consumed, use `Return.` rather than `Return *undefined*`, and conversely, and 2) don't bother with `Return.` as the final step in an AO (unless it would otherwise be empty). [09:25:46.0935] we're not 100% consistent with this right now, but we're close, and I'll fix it up in https://github.com/tc39/ecma262/pull/2429 and https://github.com/tc39/ecma262/pull/2397 once TLA is in [10:36:39.0539] bakkot: thanks, and yes, that is dumb [12:03:52.0230] Thoughts on whether web APIs should use JS SyntaxError for parsing problems? (Specific API is https://github.com/WICG/urlpattern/.) I see the ES spec uses it for BigInt and JSON.parse, in addition to actual syntax errors. [12:57:26.0490] SyntaxError seems like a reasonable choice to me [12:58:39.0565] JS also uses it for RegExp, which seems like the nearest cousin here [13:08:34.0769] as a bonus, it makes it marginally less awkward to move it into the JS spec if there is ever reason to do so [13:13:55.0897] Sigh [13:19:38.0215] I am mostly thinking of that in the context of moving structured clone, which it sounded like you were interested in doing [13:19:49.0335] and which will be marginally awkward because of the error type differences [13:19:54.0991] only very marginally, though 2021-08-11 [02:01:05.0019] moving structured clone sounds like a great idea [02:51:26.0999] > <@yulia:mozilla.org> moving structured clone sounds like a great idea I like this idea too. Others opposed it historically, e.g., Mark has expressed opposition recently. I think it would be a complicated negotiation. [08:47:25.0421] I mainly just want to stop being on the hook for updating structured clone with new error types/builtins [08:47:42.0994] Like temporal objects are just not going to be structured cloneable I guess because I don't have the time to work on that [08:47:57.0826] An alternative would be if structured clone was explicitly remembered as a stage 3 cross-cutting concern criteria [09:00:16.0747] Domenic: I don't think you are on the hook for structured clone for Temporal objects? it was identified as a concern and there is a pull request for it: https://github.com/tc39/proposal-temporal/issues/548 / https://github.com/whatwg/html/pull/6284 [09:01:05.0019] https://github.com/Jack-Works/proposal-serializer [09:01:16.0558] does anyone interested? [09:01:44.0782] this is my try on the bringing user-extensible structured clone in to the language [09:03:03.0428] > <@pchimento:igalia.com> Domenic: I don't think you are on the hook for structured clone for Temporal objects? it was identified as a concern and there is a pull request for it: https://github.com/tc39/proposal-temporal/issues/548 / https://github.com/whatwg/html/pull/6284 Oh wow, somehow I totally missed that! Sorry, that's my bad. I was assuming the unfortunate precedent set by AggregateError/error.cause would carry over for temporal, but you did the right thing. [09:07:00.0121] we haven't written the PR for Record and Tuple structured clone, but it's definitely on our todo list https://github.com/tc39/proposal-record-tuple/issues/45 [09:08:48.0396] Being friendly to contributors is a great way to encourage more involvement and avoid maintainer burnout [09:11:35.0459] > <@domenicdenicola:matrix.org> Oh wow, somehow I totally missed that! Sorry, that's my bad. I was assuming the unfortunate precedent set by AggregateError/error.cause would carry over for temporal, but you did the right thing. I don't think there's any particular precedent here; TC39 delegates have been doing a lot of the HTML integration work for recent proposals. [09:13:26.0940] We're talking about the process for host integration in TC39 proposals at https://github.com/tc39/Reflector/issues/375 (sorry, delegates/IEs only) [09:31:15.0605] > I like this idea too. Others opposed it historically, e.g., Mark has expressed opposition recently. I think it would be a complicated negotiation. shu suggested we might move the algorithm without exposing it directly in 262, at least initially, so it would _just_ be a matter of making it the 262 editors' responsibility to handle ongoing maintenance for the JS parts of it; my hope was that this would alleviate Mark's concerns [09:45:11.0005] yes, the high order bit is to decouple any normative changes to JS wrt structured clone [10:20:42.0640] Aww https://github.com/tc39/notes/blob/master/meetings/2020-06/june-4.md#generic-comparison is sad, I didn't realize the spaceship operator worked so poorly in JavaScript. I really like it as a unifying concept. 2021-08-12 [21:34:38.0215] yeah that was a bummer :-( [07:40:20.0312] Do we still have a chance to resurface it with array-equality? [07:41:49.0170] I think there are lots of chances to resurface the spaceship operator, array comparison, etc. For me, the symbol-based protocol which was disconnected from how < etc work was what I didn't like so much, not the spaceship operator itself. [07:42:28.0646] anyway yes we agreed on Stage 1 for a proposal for array equality tests [10:25:11.0060] oh hey, someone actually using Atomics! https://jlongster.com/future-sql-web [10:56:01.0732] 🥲 [10:56:37.0261] "The real magic is the Atomics.wait API. It’s a beautiful thing." i don't know if i'd call futexes beautiful personally [11:55:10.0014] keep in mind this is the opinion of someone who has just implemented sqlite _on top of_ indexdb [13:23:53.0734] I'm back! Also I still hate @@species [13:26:12.0461] did a brute force replace of globals to see what node is leaking and can't think of a clean way to not have @@species leak out a mutable vector when calling some builtins [13:27:21.0008] so, if anyone knows how to safely act like Array.prototype.concat but not call @@species without subclassing Array or mutating the receiver that would be nice [13:52:17.0072] proxy the receiver instead of mutating it :P [14:40:01.0552] bradleymeck: can you clarify the question? Array.prototype.concat requires getting @@species only when the receiver was initialized by ArrayCreate and getting its constructor returns an Object that is not a cross-realm %Array% intrinsic, but it _requires_ getting @@species in those cases so "act like Array.prototype.concat" would be violated by skipping it. 2021-08-13 [04:01:18.0379] I don't remember why I removed extending null from the March agenda but perhaps I can bring it to August. [06:58:20.0253] New proposal for extending `Math` methods to handle BigInts. https://github.com/js-choi/proposal-bigint-math, https://jschoi.org/21/es-bigint-math/ [06:58:27.0132] Might present at next meeting for Stage 1. Stuck on a couple of questions. [07:00:09.0309] 1. Should there be any methods that would return Numbers from BigInts, like `Math.sin`? (Trigonometric functions would have to return Numbers, although hyperbolic functions would not.) 2. Should `round`, `floor`, etc. take BigInts, acting as identity functions? 3. Are there any real-use cases for hyperbolic functions on BigInts? [07:00:43.0170] * 1. Should there be any methods that would return Numbers from BigInts, like `Math.sin`? (Trigonometric functions would have to return Numbers, although hyperbolic functions would not.) Answer is currently no. 2. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 3. Are there any real-use cases for hyperbolic functions on BigInts? Answer is currently don’t know but they’re specified anyway. [07:05:12.0009] * 1. Should there be any methods that would return Numbers from BigInts, like `Math.sin`? (Trigonometric functions would have to return Numbers, although hyperbolic functions would not.) Answer is currently no. 2. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 3. Are there any real-use cases for hyperbolic/root/logarithm/irrational functions on BigInts? Answer is currently don’t know but they’re specified anyway. 4. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. [07:05:33.0814] ljharb: You mentioned a few months ago you were interested in such a proposal. [07:09:02.0869] * 1. Should there be any methods that would have to return Numbers from BigInts, like `Math.sin`, which ranges within ±1? (Trigonometric functions would have to return Numbers, although hyperbolic functions would not.) Answer is currently no. 2. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 3. Are there any real-use cases for hyperbolic/root/logarithm/irrational functions on BigInts? Answer is currently don’t know but they’re specified anyway. 4. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. [07:13:26.0763] * 1. Should there be any methods that would have to return Numbers from BigInts, like `Math.sin`, which ranges within ±1? (Trigonometric functions would have to return Numbers, although hyperbolic functions would not.) Answer is currently no. 2. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 3. Are there any real-use cases for hyperbolic/root/logarithm/irrational functions on BigInts? Answer is currently don’t know but they’re specified anyway. 4. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. 5. What should the variadic `Math.hypot`, `max`, and `min` return when given no BigInt arguments? (Answer: We make new `big` versions of each of them, and we make `bigHypot` return `0`, and `bigMax`/`bigMin` throw a TypeError. [07:13:28.0292] Richard Gibson: yup, basically want a bunch of intrinsics methods that act like @@species is never anything except what the intrinsic they are directly on the prototype of [07:13:32.0218] * 1. Should there be any methods that would have to return Numbers from BigInts, like `Math.sin`, which ranges within ±1? (Trigonometric functions would have to return Numbers, although hyperbolic functions would not.) Answer is currently no. 2. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 3. Are there any real-use cases for hyperbolic/root/logarithm/irrational functions on BigInts? Answer is currently don’t know but they’re specified anyway. 4. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. 5. What should the variadic `Math.hypot`, `max`, and `min` return when given no BigInt arguments? Answer: We make new `big` versions of each of them, and we make `bigHypot` return `0`, and `bigMax`/`bigMin` throw a TypeError. [07:49:44.0518] * 1. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 2. Are there any real-use cases for hyperbolic/root/logarithm/irrational functions on BigInts? Answer is currently don’t know but they’re specified anyway. 3. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. 4. Should trigonometric functions, which generally have small domains and ranges, return Numbers when given BigInts? Answer is currently no. 5. What should the variadic `Math.hypot`, `max`, and `min` return when given no BigInt arguments? Answer: We make new `big` versions of each of them, and we make `bigHypot` return `0`, and `bigMax`/`bigMin` throw a TypeError. [07:51:11.0523] * 1. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 2. Are there any real-use cases for hyperbolic/root/logarithm functions on BigInts? Answer is currently “don’t know” but they’re specified anyway. 3. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. 4. Should trigonometric functions, which generally have small domains and ranges, return Numbers when given BigInts? Answer is currently no. 5. What should the variadic `Math.hypot`, `max`, and `min` return when given no BigInt arguments? Answer: We make new `big` versions of each of them, and we make `bigHypot` return `0`, and `bigMax`/`bigMin` throw a TypeError. [07:52:42.0098] * 1. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 2. Are there any real-use cases for hyperbolic/root/logarithm functions on BigInts? Answer is currently “don’t know” but they’re specified anyway. 3. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. 4. Should trigonometric functions, which generally have small domains and ranges, return Numbers when given BigInts? Answer is currently no, we are not currently extending the trigonometric functions. 5. What should the variadic `Math.hypot`, `max`, and `min` return when given no BigInt arguments? Answer: We make new `big` versions of each of them, and we make `bigHypot` return `0`, and `bigMax`/`bigMin` throw a TypeError. [07:53:20.0619] * 1. Should `round`, `floor`, etc. take BigInts, acting as identity functions? Answer is currently no. 2. Are there any real-use cases for hyperbolic/root/logarithm functions on BigInts? Answer is currently “don’t know” but they’re specified anyway. 3. If we do extend hyperbolic/root/logarithm/irrational functions to accept BigInts, then should they return BigInts, and if so, how should they be rounded? Answer is currently yes and “it’s ‘implementation-approximated’”. 4. Should trigonometric functions, which generally have small domains and ranges, return Numbers when given BigInts? Answer is no, and because of this we are not currently extending the trigonometric functions. 5. What should the variadic `Math.hypot`, `max`, and `min` return when given no BigInt arguments? Answer: We make new `big` versions of each of them, and we make `bigHypot` return `0`, and `bigMax`/`bigMin` throw a TypeError. [08:18:10.0240] @jschoi my answers are yes, don’t know, sounds good, probably reasonable, and I’d prefer not making new versions if possible [08:23:21.0684] > <@ljharb:matrix.org> @jschoi my answers are yes, don’t know, sounds good, probably reasonable, and I’d prefer not making new versions if possible What I’m concerned about is `Math.max(0n, 1n)` and `Math.max()` returning different things, which might cause bugs if that breaks programmer intuition. [08:23:30.0780] > <@ljharb:matrix.org> @jschoi my answers are yes, don’t know, sounds good, probably reasonable, and I’d prefer not making new versions if possible * What I’m concerned about is `Math.max(0n, 1n)` and `Math.max()` returning different types, which might cause bugs if that breaks programmer intuition. [08:23:58.0277] Likewise with `Math.hypot(arrayOfBigIntsButItIsActuallyEmpty)` returning `+0` the Number. [08:24:15.0687] * Likewise with `Math.hypot(...arrayOfBigIntsButItIsActuallyEmpty)` returning `+0` the Number. [08:25:01.0208] This probably would cause the same sort of implicit Number/BigInt type mixing that the original design was trying to avoid. [08:25:29.0901] * Regarding the last question—What I’m concerned about is `Math.max(0n, 1n)` and `Math.max()` returning different types, which might cause bugs if that breaks programmer intuition. [08:28:57.0418] * Regarding the last question—What I’m concerned about is `Math.max(0n, 1n)` and `Math.max()` returning different types `1n` and `+Infinity`, which might cause bugs if that type switching breaks programmer intuition with arrays of BigInts. [08:36:33.0596] * Likewise with `Math.hypot(...arrayOfBigIntsThatMightActuallyBeEmpty)` returning `+0` the Number. [08:36:41.0128] * Likewise with `Math.hypot(...arrayOfBigIntsThatMightActuallyBeEmpty)` returning `+0` the Number whenever it is empty. [08:37:04.0943] * Likewise with `Math.hypot(...arrayOfBigIntsThatMightActuallyBeEmpty)` returning `+0` the Number instead of a BigInt whenever the array is empty. [08:37:55.0300] * This probably would cause the same sort of implicit Number/BigInt type mixing that the original design was trying to avoid. Hence `bigHypot` etc. [08:38:19.0126] * This probably would cause the same sort of implicit Number/BigInt type mixing that the original design was trying to avoid. Hence `bigHypot` and `bigMax`. [08:39:23.0231] I’m much more convinced by the second case than the first [08:40:28.0736] Yeah, basically the second case. [08:41:05.0766] * Yeah, basically the second case. It applies to all three variadic functions. [10:30:42.0279] bradleymeck: so, this? ``` concat = function() { const receiverSpreadableValue = this[nativeIsConcatSpreadable]; const isReceiverSpreadable = receiverSpreadableValue !== undefined ? !!receiverSpreadableValue : nativeIsArray(this); const substituteReceiver = isReceiverSpreadable ? { [nativeIsConcatSpreadable]: true, __proto__: this } : { [nativeIsConcatSpreadable]: true, length: 1, 0: this }; return applyNativeConcat(substituteReceiver, arguments)} ``` [10:30:53.0635] * bradleymeck: so, this? ``` concat = function() { const receiverSpreadableValue = this[nativeIsConcatSpreadable]; const isReceiverSpreadable = receiverSpreadableValue !== undefined ? !!receiverSpreadableValue : nativeIsArray(this); const substituteReceiver = isReceiverSpreadable ? { [nativeIsConcatSpreadable]: true, __proto__: this } : { [nativeIsConcatSpreadable]: true, length: 1, 0: this }; return applyNativeConcat(substituteReceiver, arguments); }; ``` [11:03:27.0482] Richard Gibson: yup but not slow XD that is the problem [11:04:28.0136] quit moving the goalposts! 😝 [11:13:49.0073] hah [15:13:40.0934] I suspect it would be faster if it also deviated from Array.prototype.concat by ignoring the receiver, but I don't know if that works for your use case: ``` const noSpecies = { [nativeIsConcatSpreadable]: true, length: 0 }; concat = function(/*...items*/) { return appyNativeConcat(noSpecies, arguments); }; ``` 2021-08-14 2021-08-15 [14:05:25.0363] oo, lots of merges 2021-08-16 [19:41:42.0647] exciting times [10:40:13.0472] is it a normative change to turn ! into ?, if the ! assertion was incorrect? [10:40:53.0514] I believe so -- it changes the behavior of the spec, even if it is wrong and unimplementedd [10:40:56.0537] * I believe so -- it changes the behavior of the spec, even if it is wrong and unimplemented [10:41:19.0102] thanks! [10:45:32.0848] incorrect assertions are editorial errors, because the spec was incoherent [10:45:40.0352] now, some of them could've been implemented wrong and we need to think harder [10:45:52.0643] but if nobody implemented it wrong, fixing assertions don't need consensus imo [10:46:55.0701] this one is in Temporal, so I'm not sure in how far it's been implemented wrong [10:47:15.0880] Frank (who I don't think is in this channel?) caught it, presumably in the process of implementing it for v8 [10:49:06.0109] In case people have opinions on SyntaxError vs. TypeError for URLPattern, I'm currently leaning TypeError to match URL instead of SyntaxError to match RegExp. https://github.com/WICG/urlpattern/issues/74 [10:52:24.0702] is it fair to say that fixing something unimplementable as written, is an editorial change, while fixing something that's implementable as written, even if nonsensical, is normative? [10:54:22.0338] I think I have a mostly accurate understanding, but doing this as a first-timer it would be helpful if there was a clear dividing line [11:27:16.0838] (I guess, something something observability, in addition to the above) [11:29:57.0427] ptomato: if it's implementable as written I wouldn't call it nonsensical, but yes, that's the usual rule we follow [11:32:34.0592] (but if there's an assertion which is violated, obviously it isn't implementable) [11:37:38.0119] I mean, from an implementor perspective I could see changing "? Operation(...)" to "! Operation(...)" means you have to change an implementation of, roughly, `bool ok = operation(...); assert(ok);` to `if (!operation(...)) return failure();` [11:38:31.0006] I'm saying I personally would regard "it's implementable but you have an `assert` which is violated" as "it is not implementable". [12:07:17.0528] my bar of "implemented wrong" is slightly different, i meant more like "different impls implemented it differently" [12:07:34.0777] if an implementation copied the incoherent assert and is crashing debug builds, i don't really consider that an issue [15:50:39.0013] Temporal is also an interesting case of normativity since nobody's even allowed to ship it, but there's still a huge spec to battle-harden prior to landing [15:52:32.0058] so "implementedness" still implies an investment of labor, but is totally separated from usual concerns of web reality 2021-08-17 [22:31:46.0799] new “help wanted” MDN issue https://github.com/mdn/content/issues/7995 2021-08-18 [18:25:39.0147] someone might help if it was a wiki [23:38:12.0930] devsnek: https://github.com/mdn/content/edit/main/files/en-us/web/javascript/reference/functions/get/index.md [23:42:25.0430] The source can be edited there directly — and that source is in Markdown, so it’s now functionally the equivalent of a wiki editing experience. Or better, really. And from there it’s literally one button push to submit the update contented. [23:44:51.0800] And yeah of course the big difference is, rather than that button push making the change immediately go live in the production site, it creates a PR and requires the content to then be scrutinized for technical accuracy and proofreading. [23:49:06.0874] But that’s a feature, not a deficiency. The previous wiki system, while it made things easier for contributors with a very high level of JS domain knowledge to get their changes directly into MDN without anybody standing in their way — it also made things easy for contributors without very good JS domain knowledge to get a lot of suboptimal and outright-wrong changes directly into MDN without anybody standing in their way. [23:53:29.0075] And so now we’re somewhat left with a big ongoing opportunity cost of contributors needing to spend time correcting problems in content that made its way in with zero review back in the wiki days — time those contributors could maybe be spending instead on things like writing new content for newer JS features that are so far undocumented or (under-documented) in MDN [23:53:37.0645] ``` [23:53:52.0498] * ``` // end sermon ``` [23:55:19.0000] * But that’s a feature, not a deficiency. The previous wiki system, while it made things easier for contributors with a very high level of JS domain knowledge to get their changes directly into MDN without anybody standing in their way — it also made things easy for contributors without very good JS domain knowledge to get a lot of suboptimal and outright-wrong changes directly into MDN without anybody standing in their way. [23:55:37.0032] * But that’s a feature, not a deficiency. The previous wiki system, while it made things easier for contributors with a very high level of JS domain knowledge to get their changes directly into MDN without anybody standing in their way — it also made things easy for contributors _without_ very good JS domain knowledge to get a lot of suboptimal and outright-wrong changes directly into MDN without anybody standing in their way. [23:56:18.0219] * And so now we’re somewhat left with a big ongoing opportunity cost of contributors needing to spend time correcting problems in content that made its way in with zero review back in the wiki days — time those contributors could maybe be spending instead on things like writing new content for newer JS features that, so far, are undocumented or (under-documented) in MDN [00:16:55.0301] The MDN team did a really amazing job with the migration, plus github is a workflow most developers are familiar with already [00:51:35.0767] Does anyone recall how this stalled? https://github.com/tc39/proposal-setmap-offrom [00:53:34.0566] * Does anyone recall how / why this stalled? https://github.com/tc39/proposal-setmap-offrom (pinging bakkot as he most likely knows) [08:30:09.0307] > <@yulia:mozilla.org> Does anyone recall how / why this stalled? https://github.com/tc39/proposal-setmap-offrom (pinging bakkot as he most likely knows) I recall it stalling because people thought it wasn't well-motivated. Array.of/from exist because the Array constructor sucks. The Set and Map constructors are good already and adding Set.of(x, y)/Set.from(iterable) as a duplicate of new Set([x, y])/new Set(iterable) was not wanted. [08:31:20.0796] yulia: last i saw on this kind of stuff was from leobalter I believe, there was a lack of agreement on need (isn't there always) / concerns about expanding API area without usage demands [08:31:47.0619] so... pretty close to what any Set/Map thing seems to face [08:34:51.0177] I am still fond of it; I'm more likely to bring it back if we get consensus on the extent to which we intend to support subclassing builtins (relevant because, does `(class extends Set { add(x){ } }).of('element')` invoke the subclass's `add` method?) [08:36:13.0706] Given that people were only lukewarm on the proposal, I didn't really want to deal with the fight about subclassing again for this proposal's sake [08:38:09.0324] if it helps, Symbol.species once again was a way to get a bug bounty [08:38:22.0350] I'm quite skeptical on this whole subclassing builtins, but I've said that before [09:59:37.0220] > <@domenicdenicola:matrix.org> I recall it stalling because people thought it wasn't well-motivated. Array.of/from exist because the Array constructor sucks. The Set and Map constructors are good already and adding Set.of(x, y)/Set.from(iterable) as a duplicate of new Set([x, y])/new Set(iterable) was not wanted. this captures well the feedback received and I'm yet to build a better explainer, unfortunately with no cycles to prioritize this work so far. bradleymeck yulia bakkot it's up for grabs if anyone wants to champion it, otherwise I hope I can eventually find someone from my org who wants to do it. 2021-08-19 [10:37:06.0569] what do we call the object that results from parsing a script? [10:37:47.0936] parsing an HTML document produces a DOM tree, parsing a CSS stylesheet produces a CSSOM structure [10:39:44.0019] sideshowbarker: "Parse Node" [10:40:50.0449] OK — thanks [10:40:50.0982] though there is a wrapper for Script/Module : https://tc39.es/ecma262/#sec-script-records [10:40:58.0013] /me looks [10:41:10.0429] the records are just some info attached to the parse results [12:02:22.0988] is there anything currently in JS that will cause all of the digits of a base-10 integer > 10^21 to be printed? [12:03:53.0021] Temporal is assuming this ability but... [12:04:50.0241] * is there anything currently in JS that will cause all of the digits of a base-10 integer > 10^21 to be printed? (_I don't care what the digits *are*, just that we don't get scientific notation_) [12:04:59.0814] * is there anything currently in JS that will cause all of the digits of a base-10 integer > 10^21 to be printed? (_I don't care what the digits **are**, just that we don't get scientific notation_) [12:10:06.0160] rkirsling: yes, `BigInt(1e300).toString()` [12:18:00.0299] hmm but that won't work with a number value [12:19:56.0306] I mean specifically: for the value `999999999999999999999`, I get some string of nothing but digits [12:21:21.0016] well, `999999999999999999999 > Number.MAX_SAFE_INTEGER` [12:21:56.0069] so `BigInt(999999999999999999999).toString() === '1000000000000000000000'`, but you did say that you didn't care what the digits are 😅 [12:28:09.0002] yeah I mean `P1+e21Y` is not a valid duration string so we have to print something [12:29:13.0557] these unbounded values are a huge pain [12:31:38.0036] there's some discussion on that: https://github.com/tc39/proposal-temporal/issues/24#issuecomment-589980538 [12:31:48.0046] ahh I see, the polyfill does do what you said: https://github.com/tc39/proposal-temporal/blob/main/polyfill/lib/ecmascript.mjs#L1881-L1884 2021-08-20 [11:33:35.0432] https://matrix.to/#/!AGetWbsMpFPdSgUrbs:matrix.org/$c8W55mBKJlWR-JTCOgOngiktRLErO9m5eXUlwKfcSyE [11:33:54.0749] * https://matrix.to/#/!AGetWbsMpFPdSgUrbs:matrix.org/$c8W55mBKJlWR-JTCOgOngiktRLErO9m5eXUlwKfcSyE > Does JS define the order of iteration for the declaratively defined properties on prototypes? I also have been thinking about this recently... [12:11:38.0511] lol, the heterogeneity is almost perfect ``` $ eshost -se 'Reflect.ownKeys(Array).map(k => String(k))' | grep '^#' #### ChakraCore #### engine262, Moddable XS #### GraalJS #### Hermes #### JavaScriptCore #### SpiderMonkey #### V8 $ eshost -se 'Reflect.ownKeys(Array.prototype).map(k => String(k))' | grep '^#' #### ChakraCore #### engine262 #### GraalJS #### Hermes #### JavaScriptCore #### Moddable XS #### SpiderMonkey #### V8 ``` [12:35:50.0698] it does not, and is probably not worth trying to enforce [12:45:36.0580] unique form of art https://gc.gy/97193732.png 2021-08-21 [20:18:11.0736] we seem to be pretty over the 2-day time limit this time, if anyone think they can squeeze their items down into a smaller timeslot [01:10:07.0300] Hi I have a syntax question [01:10:25.0589] Does `super()` only valid in class constructors? [01:11:01.0498] And does `new.target` isn't possible to be a generator (async or not) function? [01:27:37.0910] Does anybody understand what https://github.com/mdn/content/issues/8118 is asking? [05:42:06.0117] Does Array.from treat it as an ArrayLike first or an iterable first? If you provide it an object that's both, which does it use to convert? [05:42:24.0752] That's my guess, anyway [09:27:25.0214] Jack Works: `super()` is indeed only valid in class constructors (with the caveat that `super()` also works in nested arrows in a class constructor, as in `(class extends Object { constructor(){ () => super() } })`) [09:27:30.0461] but `new.target` is legal in generators [09:33:00.0246] > <@bakkot:matrix.org> but `new.target` is legal in generators It's legal but generator function cannot be the third parameter of Reflect.construct [10:10:21.0018] you can't construct a shorthand method either, and it's legal there too [10:10:25.0327] ¯\_(ツ)_/¯ [13:49:20.0812] iirc it's legal in shorthand methods tho because the plan (at the time) was to have [[HomeObject]] be alterable, and have `super` point to that [13:49:45.0979] i don't remember anyone talking about standalone generator functions in that context [14:11:21.0266] ah, by "it" I meant `new.target`, not `super()` [14:11:44.0229] `new.target` wouldn't have anything to do with [[HomeObject]] 2021-08-22 [19:00:09.0193] I was working on do expression yesterday, and I need to special handle "arguments" "new.taeget" "super()" "super.*" "super.*()" [19:01:19.0482] I can use Arrow function when the do expression does not contain Yield (when will we have arrow version of generator function?) [19:02:30.0140] And if it contains Yield, it must be a +Yield context, meanwhile super() must be illegal and `new.target` must not be any meaningful value [19:03:38.0696] `Reflect.construct(Function, [], function*(){})` throws error so I think `new.target` must be empty inside generator function [19:04:24.0304] > <@jackworks:matrix.org> And if it contains Yield, it must be a +Yield context, meanwhile super() must be illegal and `new.target` must not be any meaningful value Therefore I think it's safe to skip the handling of super() and new.target 2021-08-23 [20:20:12.0874] jmdyck: my attempt to fix PrepareForTailCall by just avoiding the problem entirely: https://github.com/tc39/ecma262/pull/2495 [20:21:48.0255] unfortunately I just missed the cutoff to add it to the agenda for the upcoming meeting, so it'll have to wait for October for consensus [21:17:32.0049] actually maybe people haven't done their reviews yet; I'll give it a shot [10:35:45.0025] (the cutoff only applies to proposals) [10:40:01.0763] Lots of delegates like to have time to review everything which is for consensus ahead of time [10:41:02.0768] good timing bakkot ;) we reviewed it [10:41:48.0894] but yeah, if its big and complicated its nice to have it on friday [10:42:12.0302] that said i also posted iterater helpers late (today) as an update so people know its actively worked on [10:42:16.0928] * that said i also posted iterator helpers late (today) as an update so people know its actively worked on [10:47:17.0767] for sure, my concern is less "is it formally after the deadline" and more "is it early enough that people will get a chance to look at it" [11:23:01.0813] another reminder that we are way oversubscribed this meeting anyhow [12:37:02.0427] somehow I don't think I would've gotten away with dropping http://ptomato.name/talks/tc39-2021-08/ on the agenda next Monday, even though it's not a proposal, so I've been interpreting the deadline as an expected courtesy even if it's not formally required 2021-08-24 [22:35:06.0991] this is a very fun writeup of a CVE in chrome which happened as a consequence of a change to TypedArrays in the spec: https://tiszka.com/blog/CVE_2021_21225.html [22:36:25.0248] also serves as a good concrete example of Symbol.species causing bad things to happen [07:25:55.0420] yes, that was a "i'm in this picture and i don't like it" situation [08:12:52.0796] Looking at https://github.com/tc39/proposal-pattern-matching/issues/168#issuecomment-814216217, I’m wondering: Is it a goal to forever avoid the Bad Keywords (`eval`, `with`, `switch`) in new syntax? That is, is it a committee invariant that those three keywords not be used in any new syntax going forward? [08:42:32.0660] well, eval isn't a keyword [08:42:58.0174] and i've seen ideas float around that want to co-opt `with` for more useful purposes, it's a nice keyword [08:43:14.0956] so it's not an invariant from my perspective [09:04:06.0481] Yeah, I mean Bad Words in general, I guess, heh. An example for `eval`: https://github.com/tc39/proposal-do-expressions/issues/53#issuecomment-771789167 [09:04:44.0338] I suppose I haven’t seen anything about this with `with` yet; I had assumed it was in a similar situation to `switch` etc. [09:06:39.0863] * I suppose I haven’t seen anything about this with `with` yet; I had assumed it was in a similar situation to `switch` etc. I don’t remember seeing any proposals actually using `with`. [09:14:45.0075] * Looking at https://github.com/tc39/proposal-pattern-matching/issues/168#issuecomment-814216217, I’m wondering: Is it a goal to forever avoid the Bad Keywords (`eval`, `with`, `switch`) in new syntax? That is, is it a committee invariant that those three words not be used in any new syntax going forward? [09:23:39.0488] If `with` is going to be treated differently from `switch` (in that new syntax may use `with` but not `switch`), it might be good to make explicit how their situations are different. After all, they’re similarly discouraged (already discouraged for `with` and discouraged in the future for `switch` whenever `match` is standardized). I suppose that `switch` and `match` have somewhat similar purposes, while no future syntax is going to have a similar purpose to `with`…so there might be less risk of confusion between `with`’s current dynamic binding and any future syntax that reuses `with`, compared to `switch` and `match`. [09:24:48.0464] * If `with` is going to be treated differently from `switch` (in that new syntax may use `with` but not `switch`), it might be good to make explicit how their situations are different. After all, they’re similarly discouraged (already discouraged for `with` and discouraged in the future for `switch` whenever `match` is standardized). I suppose that `switch` and `match` have somewhat similar purposes, while no future syntax is going to have a similar purpose to `with`…so there might be less risk of confusion between `with`’s current dynamic binding and any future syntax that reuses `with` for a completely different purpose, compared to `switch` and `match`. [09:26:30.0685] * If `with` is going to be treated differently from `switch` (in that new syntax may use `with` but not `switch`), it might be good to make explicit how their situations are different. After all, they’re similarly discouraged (already discouraged for `with` and discouraged in the future for `switch` whenever `match` is standardized). I suppose that `switch` and `match` have somewhat similar purposes, while no future syntax is going to have a similar purpose to `with`…so there might be less risk of confusion between `with`’s current dynamic binding and any future syntax that reuses `with` for a completely different purpose, compared to `switch` and `match`. And so, if a future syntax somehow reused `switch` for a purpose completely different from pattern matching, then perhaps that too might be acceptable…though I cannot think of any such possible purpose for `switch`. [09:27:24.0688] * If `with` is going to be treated differently from `switch` (in that new syntax may use `with` but not `switch`), it might be good to make explicit how their situations are different. After all, they’re similarly discouraged (already discouraged for `with` and discouraged in the future for `switch` whenever `match` is standardized). I suppose that `switch` and `match` have somewhat similar purposes, while no future syntax is going to have a similar purpose to `with`’s current and deprecated dynamic binding…so there might be less risk of confusion between `with`’s current purpose and any future syntax that reuses `with` for a completely different purpose, compared to `switch` and `match`. And so, if a future syntax somehow reused `switch` for a purpose completely different from pattern matching, then perhaps that too might be acceptable…though I cannot think of any such possible purpose for `switch`. [09:27:51.0540] * If `with` is going to be treated differently from `switch` (in that new syntax may use `with` but not `switch`), it might be good to make explicit how their situations are different. After all, they’re similarly discouraged (already discouraged for `with` and discouraged in the future for `switch` whenever `match` is standardized). I suppose that `switch` and `match` have somewhat similar purposes, while no future syntax is going to have a similar purpose to `with`’s current purpose (dynamic binding)…so there might be less risk of confusion between `with`’s current purpose and any future syntax that reuses `with` for a completely different purpose, compared to `switch` and `match`. And so, if a future syntax somehow reused `switch` for a purpose completely different from pattern matching, then perhaps that too might be acceptable…though I cannot think of any such possible purpose for `switch`. [09:28:35.0669] * If `with` is going to be treated differently from `switch` (in that new syntax may use `with` but not `switch`), it might be good to make explicit how their situations are different. After all, they’re similarly discouraged (already discouraged for `with` and discouraged in the future for `switch` whenever `match` is standardized; see https://github.com/tc39/proposal-pattern-matching/issues/168#issuecomment-707404650). I suppose that `switch` and `match` have somewhat similar purposes, while no future syntax is going to have a similar purpose to `with`’s current purpose (dynamic binding)…so there might be less risk of confusion between `with`’s current purpose and any future syntax that reuses `with` for a completely different purpose, compared to `switch` and `match`. And so, if a future syntax somehow reused `switch` for a purpose completely different from pattern matching, then perhaps that too might be acceptable…though I cannot think of any such possible purpose for `switch`. [09:29:01.0844] * If `with` is going to be treated differently from `switch` (in that new syntax may use `with` but not `switch`), it might be good to make explicit how their situations are different. After all, they’re similarly discouraged (already discouraged for `with` and discouraged in the future for `switch` whenever `match` is standardized; see https://github.com/tc39/proposal-pattern-matching/issues/168#issuecomment-707404650). I suppose that `switch` and `match` have somewhat similar purposes, while no future syntax is going to have a purpose at all similar to `with`’s current purpose (dynamic binding)…so there might be less risk of confusion between `with`’s current purpose and any future syntax that reuses `with` for a completely different purpose, compared to `switch` and `match`. And so, if a future syntax somehow reused `switch` for a purpose completely different from pattern matching, then perhaps that too might be acceptable…though I cannot think of any such possible purpose for `switch`. [10:11:21.0975] jschoi: `with` has been discouraged for a long time, and can't be used in ESM or classes, so it's unlikely its use will cause confusion, especially since people will likely google `match with` and get to the right place. overlapping `match` and `switch`, however, will be quite confusing [10:11:33.0045] we could certainly use a different spelling than "with" if that's a concern tho [10:12:04.0681] iow, the goal is not "avoid bad keywords", it's "avoid switch, specifically, because it is the Bad Thing this exact proposal is trying to obviate" 2021-08-25 2021-08-26 2021-08-27 [21:15:21.0425] > <@bakkot:matrix.org> this is a very fun writeup of a CVE in chrome which happened as a consequence of a change to TypedArrays in the spec: https://tiszka.com/blog/CVE_2021_21225.html How’d you find this write up? [22:06:30.0488] Justin Ridgewell: a friend linked me to https://twitter.com/erikcorry/status/1427755338196033553 [22:06:35.0312] no idea how he came across it [08:51:21.0540] it went around the V8 internal chat when the writeup first came up [11:10:36.0815] The decorator spec currently seems to allow whitespace/comments between `@` and its following expression. Is this on purpose? https://arai-a.github.io/ecma262-compare/history/PR/2417/8015d41b2167373c17e1f50dd7da0d257b408680/index.html#prod-Decorator [11:11:57.0349] TabAtkins and I are exploring a new [contiguous] annotation that would disallow any discarded tokens (whitespace, comments) at its position. We would also use it for the Hack pipe operator’s topic token. [11:12:32.0204] It seems like such a [contiguous] annotation perhaps ought to be between `@` and DecoratorMemberExpression/DecoratorCallExpression too. [11:12:50.0165] It would be consistent with `@init:` too, which is currently a single token. [11:13:28.0053] * It would be consistent with `@init:` too, which is currently a single token and which does not allow discarded tokens between `@` and `init:`. [11:14:25.0014] * It seems like such a [contiguous] annotation perhaps ought to be between `@` and its following expression, too. [11:14:35.0735] * It would also be more consistent with `@init:`, which is currently a single token and which does not allow discarded tokens between `@` and `init:`. [11:15:00.0413] * TabAtkins and I are exploring a new [contiguous] annotation that, similarly to [no LineTerminator here] would disallow any discarded tokens (whitespace, comments) at its position. We would also use it for the Hack pipe operator’s topic token. [11:15:04.0305] * TabAtkins and I are exploring a new [contiguous] annotation that, similarly to [no LineTerminator here], would disallow any discarded tokens (whitespace, comments) at its position. We would also use it for the Hack pipe operator’s topic token. [11:15:45.0514] * TabAtkins and I are exploring a new [contiguous] annotation that, similarly to [no LineTerminator here], would disallow any discarded tokens (whitespace, comments) at its position. We would also use it for the Hack pipe operator’s topic token (https://github.com/js-choi/proposal-hack-pipes/issues/13#issuecomment-907380621). [11:16:24.0330] Anyways, allowing `@ foo function f () { }` seems like it might be an oversight. [11:16:37.0333] * Anyways, allowing `@ foo class C () { }` seems like it might be an oversight. [11:17:38.0769] * Anyways, allowing `@ foo class C () { }` or `@ foo class C () { }` seems like it might be an oversight. [11:17:45.0676] * Anyways, allowing `@ foo class C () { }` or `@[line terminator]foo class C () { }` seems like it might be an oversight. [11:19:49.0614] Whether `@init:` is a single token is unclear: I don't think the proposal modifies the lexical grammar to recognize `@` at all, let alone `@init:`. [11:23:33.0065] (e.g., `@` doesn't appear in OtherPunctuator) [11:25:55.0157] * Anyways, allowing `@ foo class C { }` or `@[line terminator]foo class C { }` seems like it might be an oversight. 2021-08-28 [08:21:30.0181] it makes no sense to me to have whitespace directly after an @ - they can always do @( if they want the expression on a new line, so it seems nice to prohibit it 2021-08-29 [08:39:34.0287] Yeah, it seems like the kind of thing where the @ is "clearly" part of the identifier, and it's just parsing oddities that make that not technically true. (Unlike in, say, CSS, where the tokenizer specially recognizes @foo as a single token.) 2021-08-30 2021-08-31 [19:22:23.0128] So `-9 >>> 2` returns `1073741821` rather than `-9` [19:22:52.0487] I’m trying to find where in the current spec that behavior is defined [19:23:50.0068] * So `-9 >>> 0` returns `1073741821` rather than `-9` [19:25:00.0267] that is, `-9 >>> 0` — bitwise logical right shift, by zero bits to the right [19:25:24.0091] https://tc39.es/ecma262/#sec-numeric-types-number-unsignedRightShift [19:25:38.0400] /me looks [19:26:55.0085] jmdyck: thanks (dunno now why I wasn’t able to find that) [19:27:23.0221] so now I’m trying to understand how this is different from what other runtimes do [19:27:44.0164] for example, in java `-9 >>> 2` is `-9` [19:28:57.0169] and intuitively, if no zeroes are being shifted in from the left, then the most-significant bit of that number is still `1` [19:30:25.0531] so there’s some other magic that causes the JavaScript runtime to consider the value returned to not be the a two’s-complement representation [19:32:09.0536] ah, I guess that’s just because the operation requires treating the left-hand value as unsigned [19:32:22.0357] 1073741821 is what I get for `-9 >>> 2`, not `-9 >>> 0` [19:33:04.0158] jmdyck: yeah, sorry I originally mistyped it, but then edited it to correct that [19:33:28.0847] ah no, I didn’t correct that part [19:33:42.0177] `-9 >>> 0` is 4294967287, i.e. 2^32 - 9, i.e. ToUint32(-9) [19:33:55.0039] * So `-9 >>> 0` returns `4294967287` rather than `-9` [19:34:43.0350] sorry — thanks, yeah, I get the same (and fixed now also in my original message) [19:36:15.0040] anyway, I see now that this is because in JavaScript, the left-hand side of the operation gets handled as an unsigned — whereas in Java, the left-hand side gets handled as signed [19:36:25.0321] * anyway, I see now that this is because in JavaScript, the left-hand side of the operation gets handled as unsigned — whereas in Java, the left-hand side gets handled as signed [19:38:49.0073] so the ES spec is clear on this — it’s just not very discoverable [19:39:18.0593] I had expected to find that info at https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-unsigned-right-shift-operator [19:40:04.0176] but there’s no link from there to https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-numeric-types-number-unsignedRightShift (where the real information is) [19:40:46.0148] The thing is, there's 2 numeric types, so it can't just link to the Number-specific semantics. [19:41:08.0692] aha [19:41:38.0691] OK yeah I can understand how it would lead to that [19:42:41.0727] You can click on EvaluateStringOrNumericBinaryExpression and then ApplyStringOrNumericBinaryOperator and then the little table in step 8 tells you to apply T::unsignedRightShift [19:42:59.0546] but again, it can't just link to Number::unsignedRightShift [19:43:02.0345] OK [19:43:17.0331] right [19:43:49.0344] well I’m updating MDN so I’ll get the additional links into MDN for it at least [19:44:13.0558] conceivably there could be 2 more columns, giving Number-specific and BigInt-specific links for each numeric method [19:44:39.0152] yeah that might be more helpful [19:48:05.0493] Or at least a Note that linked you to 6.1.6.1 for Number, 6.1.6.2 for BigInt. [19:49:17.0180] yeah [03:37:07.0641] Heads up that I will need to be out for the first hour today [08:16:50.0827] im here now [08:19:48.0987] Aki: when is the fixed layout object currently scheduled? [08:20:10.0423] today afternoon, tomorrow morning, or tomorrow afternoon? [08:20:16.0622] shu: tomorrow afternoon [08:20:23.0501] thanks [09:08:18.0795] @rbuckton Does Typescript keep a changelog for the changes between the Beta and Regular release? [09:08:54.0955] Hmmm. Ron isn't in this channel... [09:19:34.0518] rbuckton: 👆 [09:59:50.0676] the release notes come out for beta and RC [10:00:11.0541] https://devblogs.microsoft.com/typescript/announcing-typescript-4-4-beta https://devblogs.microsoft.com/typescript/announcing-typescript-4-4-rc https://devblogs.microsoft.com/typescript/announcing-typescript-4-4 [10:00:56.0635] or are you asking about what the differences are between a pre-release and a stable? [10:06:34.0736] Yes, the differences between the 3 blog posts [10:06:53.0005] I end up reading the Beta when it comes out, then you post the RC and Stable, and I have no idea if anything is changed [10:15:58.0984] I unsubscribed from the TypeScript blog RSS feed precisely because it was so repetitive [10:20:05.0523] Yeah, sorry 😅 We're typically feature-complete on the language side by beta, but often editor features & optimizations are the differences. Big difference this past time was `static {}` blocks were implemented in the beta, but didn't make it into that post [10:20:11.0627] * Yeah, sorry 😅 We're typically feature-complete on the language side by beta, but often editor features & optimizations are the differences. Big difference this past time was `static {}` blocks were implemented in the beta, but didn't make it into the release post [10:22:12.0973] I'll consider including a "changes since the ______" in the future if it's not too much trouble [10:26:15.0976] > <@jridgewell:matrix.org> @rbuckton Does Typescript keep a changelog for the changes between the Beta and Regular release? I'm not sure. The primary changelog is between major releases, though we do publish a blog post containing what is in the beta/RC release [10:26:44.0394] We don't usually add new things once it hits beta, and very rarely do we roll back a feature in Beta [10:28:07.0318] Thanks!