2020-09-02 [12:50:44.0000] huh, interesting that neither V8 nor SM currently pass this: https://test262.report/browse/built-ins/ArrayBuffer/prototype/byteLength/detached-buffer.js [12:51:21.0000] rkirsling: do they support $DETACHBUFFER? [12:54:56.0000] seems like they do [12:56:31.0000] they pass, e.g., https://test262.report/browse/built-ins/DataView/prototype/getUint8/detached-buffer.js [12:58:01.0000] rkirsling: https://source.chromium.org/chromium/chromium/src/+/master:v8/src/builtins/builtins-arraybuffer.cc;l=114?q=ArrayBufferByteLength [12:58:07.0000] there's a TODO to throw a typeerror :D [12:58:44.0000] hah [12:58:50.0000] very simple change [12:59:30.0000] tbh those should all be moved to torque [13:06:26.0000] there are years-old nonconformances in the TA/AB code in V8 [13:06:49.0000] it is unclear what the value is to cover those corners now [13:06:59.0000] i might rewrite a bunch of that in torque [13:07:06.0000] and cover them while i'm at it [13:08:15.0000] shu: I mean I can't decide priorities for anybody but I thought spec conformance was its own reward [13:08:18.0000] to be clear, the open question isn't difficulty of changing the code, but determining web compat [13:08:31.0000] given these are 4-year old bugs that may have been depended upon [13:08:32.0000] https://bugs.chromium.org/p/v8/issues/detail?id=4895&q=&can=3 [13:08:54.0000] the "unclear what the value is" means unclear what the value is in doing the research on web compat for these corners [13:09:02.0000] ohh fascinating [13:09:34.0000] yeah it is a bit interesting if we've been conforming to something other than the spec for so long [13:09:50.0000] that's been inheritance chain there from littledan to sathya to me :P [13:10:05.0000] err, there's been an* [13:10:29.0000] what does it return in browsers [13:10:30.0000] 0? [13:10:56.0000] think so, let me check [13:10:57.0000] like right now I got confused because I noticed that checking buffer.byteLength on the underlying ArrayBuffer of WebAssembly.Memory *doesn't* throw in other browsers after calling memory.grow(1) [13:12:02.0000] so like, even in wasm space people could well be checking whether byteLength is 0, just like our tests were [13:12:19.0000] I wonder if I should jettison that part of my patch [13:12:34.0000] sounds like the thing to do here is change the spec [13:12:38.0000] yeah [13:12:39.0000] i think it's 0 [13:12:48.0000] ah the wonders of js [13:12:52.0000] devsnek: yeah, that's what i'd lean to, would like to hear moz and apple's opinions [13:13:07.0000] i wonder what led to the error being left out on byteLength getter [13:13:10.0000] across browsers [13:13:36.0000] i was just pinged today by anne and domenic on https://github.com/tc39/ecma262/issues/678 [13:14:08.0000] > Considering that Edge has been shipping throwing on detached typed arrays, I plan on changing Firefox to also throw. [13:14:16.0000] the good 'ol days [13:14:25.0000] https://esdiscuss.org/topic/arraybuffer-neutering offers some history [13:14:48.0000] the throwing behavior was made strict when ecma262 took over speccing ABs from khronos, but stuff had shipped [13:15:14.0000] and as with things go, this probably was pretty low priority during the ES6 days [13:15:14.0000] TIL they were part of khronos [13:15:21.0000] when there was a general scramble to catch up on feature implementation [13:15:22.0000] and here we are [13:15:41.0000] hmmmm [13:15:56.0000] now we know where the "equiv c type" table came from [13:16:04.0000] I have to run to a doctor's appt but yeah this is sounding like a potential topic for the next meeting [13:17:40.0000] the lesson for me here is mainly that the ES6 model of throwing a large featureset over the wall to implementers had many bad consequences in long-tail interop [13:17:49.0000] +1000 [13:17:51.0000] (though it traded it arguably for more cohesion) [13:20:24.0000] gonna take some time off, toodles [13:45:32.0000] is there really no simple way of doing [[OwnPropertyKeys]] and keep the interleaved Symbol/string ordering?? [13:45:52.0000] i'm stuck doing a really weird for...in loop [13:46:48.0000] bradleymeck: wdym? [13:47:11.0000] devsnek: I'm implementing a userland https://tc39.es/ecma262/#sec-copydataproperties [13:47:26.0000] if there is interoperability between engines on this TypedArray behavior, I'd prefer to change the spec than to risk compatibility [13:47:32.0000] i mean what is "interleaved Symbol/string ordering" [13:49:50.0000] devsnek: ...{[Symbol.toStringTag]: ()=>'_', inTheMiddle:true, [Symbol.toPrimitive]: () => 0} , needs to define `inTheMiddle` between the symbols [13:49:59.0000] littledan: yeah the reality seems very predictable even without hard data here [13:50:22.0000] er *numerical data, I mean [13:50:25.0000] bradleymeck: that's not how ordinary objects work though [13:50:50.0000] rkirsling: I feel like the data we'd need to make this decision would just be, checking the behavior in all engines [13:51:01.0000] which I guess there are test262 tests for, so maybe we can even just find it on that dashboard... [13:51:01.0000] they always enumerate their own keys with symbols last [13:51:19.0000] littledan: https://test262.report/browse/built-ins/ArrayBuffer/prototype/byteLength/detached-buffer.js [13:51:33.0000] ah, well ... now thats confusing [13:51:59.0000] devsnek: wow [13:53:46.0000] devsnek: thats only going through OrdinaryOwnPropertyKeys it seems [13:53:52.0000] which spread... doesn't? [13:54:27.0000] /me stares [13:55:52.0000] devsnek: yea it looks like object spread doesn't follow that [13:56:24.0000] wait no... its just indirect [13:57:42.0000] but it isn't true still for non-ordinary objects so... back to for...in [13:58:32.0000] i mean `Reflect.ownKeys` will return whatever the object gives it [14:01:05.0000] aha, forgot about that [14:01:48.0000] tyty [14:29:07.0000] for-in doesn't hit symbols anyway 2020-09-03 [14:49:13.0000] have we ever had a function length change in a new edition? [14:59:00.0000] bradleymeck: definitely [15:00:01.0000] ljharb: do we know if it has ever decremented? [15:00:24.0000] bradleymeck: pretty sure definitely it has [15:00:34.0000] let me check [15:03:02.0000] bradleymeck: https://github.com/tc39/ecma262/pull/1131#issuecomment-374591660 had DataView.length as 1 in the spec but 3 in a number of impls, we kept it at 1. that's not exactly what you asked for tho [15:03:23.0000] (meaning, it's definitely decremented in *engines*) [15:03:36.0000] i've filed a few bugs over the years as well with incorrect length values on various methods, some were too high and some too low [15:05:08.0000] bradleymeck: i'm not finding any other examples post-ES6, so maybe it hasn't happened in the spec itself before [15:05:37.0000] bradleymeck: i'd think we should be able to change function lengths as needed tho, in either direction, modulo web compat [15:09:48.0000] Yea, I'm asking because map.get changes might want that for split upsert methods [15:14:20.0000] blocks tho https://gc.gy/66876146.png [15:40:43.0000] shu: do you mean indexed access for typed arrays in particular? [15:41:02.0000] (ArrayBuffers alone are just ordinary in this regard, right?) [15:41:48.0000] either way I agree with you wrt the audit [15:43:09.0000] the DataView spec is evidently fine so it'd just be a matter of typed arrays in particular, which I've yet to examine precisely (but intend to) [15:48:22.0000] bradleymeck: Map get has a length of 1, why do you envision that decrementing? [15:53:50.0000] I imagine it becoming 2, decrement was curiousity [15:54:26.0000] ah k [15:54:43.0000] it'd only become two tho if the second arg was required [16:01:20.0000] bradleymeck: i added arbitrary module namespaces to engine262, seems to be all working [16:37:51.0000] rkirsling: yes i mean for TAs backed by detached ABs in particular, yes [16:38:17.0000] rkirsling: spec says detachedTypedArray[i] throws, implementations don't [16:38:37.0000] why don't impls throw there? [16:39:07.0000] shu: yeah I think I've got the situation understood correctly now, just added a reply comment [16:41:28.0000] ljharb: they never did, spec added it when tc39 took it over from khronos, we never reflected the changes and now it might be too late [16:41:30.0000] is my understanding [16:42:03.0000] like, the same reason why there are other places where impls don't throw [16:42:55.0000] ok so there's no good reason not to throw [16:43:03.0000] it's just that it may not be web compat, or worth seeing if it is? [16:44:34.0000] yeah like I think it's clear enough that throwing in ArrayBuffer#byteLength won't be web compatible, and so hopefully that same understanding extends to has/get/set for typed arrays too [16:44:55.0000] (because the reasoning is the same) [16:45:05.0000] ah, there's evidence it wouldn't be? [16:45:47.0000] edge had correct throwing [16:45:55.0000] but then edge stopped existing [16:46:05.0000] sure but doesn't that suggest it was web compatible? [16:46:16.0000] ChakraCore doesn't though? [16:47:44.0000] ljharb: seems like maybe edge didn't have all the specced behavior, but supposing that were the case, given that edge's adoption of chromium was for in no small part for more compat, i wouldn't infer that it is web compatible from that data point [16:48:29.0000] I'm a bit confused about what Edge exactly did, because there's an amazing degree of behavioral consistency here [16:49:25.0000] shu: um, citation for "for more compat"? [16:49:56.0000] shu: i mean like, the implication wasn't "edge is bad and chromium is good", it was "it's easier/cheaper to just adopt chromium", which implies it's not a data point here [16:50:12.0000] https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/#a11y-skip-link-content:~:text=desktop%20to%20create%20better%20web%20compatibility [16:50:28.0000] `a11y-skip-link-content` is a new one [16:51:42.0000] shu: i think it's a stretch to say that "anything edge did differently from chromium was thus web incompatible" [16:51:53.0000] i didn't say that [16:52:16.0000] you said "doesn't that suggest it was web compatible", which i took "that" to mean "edge had correct throwing" [16:52:21.0000] ohh [16:52:35.0000] ok yeah, i was saying that *if* edge had correct throwing, that seems to imply it didn't break websites [16:52:48.0000] i don't know that they had correct throwing ofc :-) [16:52:52.0000] and i'm saying, even if it did, for all i know it still might have [16:53:05.0000] since as a product, their public messaging called out better compat as a reason to switch engines? [16:53:56.0000] oh I see, so Ch shipped throwing behavior, SM was going to follow suit but then aborted upon realizing the danger, and then Ch must have stepped back at some point too [16:55:11.0000] shu: again i think it's a stretch to infer anything about this case from that blog post [16:55:26.0000] you are still misunderstanding what i'm saying [16:55:35.0000] ok [16:55:42.0000] *you* are saying you infer web compat from edge having correct behavior [16:55:56.0000] i am saying i wouldn't infer web compat in any direction from edge's behavior [16:56:06.0000] right, unless a bug report about a broken website were to have come in after the chromium decision was made [16:56:34.0000] but i suppose either way, new websites could now be relying on the behavior, post-chromedge [16:56:46.0000] it sounds like they were relying on it before, given ff's choice [16:56:55.0000] this is a 4-year old thing [16:58:08.0000] i'm clearly missing context here :-) if FF had a nontheoretical concern then that seems convincing [16:58:57.0000] Tom didn't state it in this thread but Anne implied it: https://github.com/tc39/ecma262/issues/678#issuecomment-452699242 [16:59:22.0000] I can probably find the Ch commit where they rolled back 2020-09-04 [17:01:28.0000] I mean I guess the last few comments here are concrete: https://bugzilla.mozilla.org/show_bug.cgi?id=1079853#c8 [17:02:55.0000] all signs point to this having been decided 6 years ago and we somehow dropped the ball on the spec side [17:04:00.0000] fair enough [17:08:18.0000] meh, this isn't the right thing but it's similar enough: https://github.com/microsoft/ChakraCore/commit/c5ce362139f998347ed0f99a3cd6431fdd7c9451 [17:11:56.0000] whoa does chakra have unlimited column length [17:12:09.0000] unlimited column length? [17:12:26.0000] oh you mean that copyright comment? lol [17:13:09.0000] i was looking at the old L2611 [17:13:15.0000] that is a very long line [17:13:56.0000] hmm true [12:28:43.0000] I don't think the non-throwing behavior is something we have decided, but I think we have significant evidence to motivate the change, so I'm glad this is being brought up. [13:42:50.0000] lol @ d8 [13:42:53.0000] `--always-promote-young-mc (always promote young objects during mark-compact)` [13:42:59.0000] I see what you did there [13:44:23.0000] more seriously though, I don't know how to execute these %-functions [13:46:44.0000] like `%Object%()`? [13:46:57.0000] or `%Object` or whatever, i forget what v8 uses [13:47:07.0000] there's a --native-syntax or something [13:47:31.0000] --allow-natives-syntax, I see [13:47:40.0000] I would not have been able to find that myself [13:47:47.0000] thanks [13:48:02.0000] (%ArrayBufferDetach is the reason, fwiw) [13:48:10.0000] %CreatePrivateSymbol though [14:25:44.0000] interestingly JSC passes a few tests that it shouldn't, if it were totally consistent about IntegerIndexedElement{Get,Set} [14:57:22.0000] ljharb: yeah I wondered about the 0 too [16:03:32.0000] if you do `return Reflect.apply(...)` does that invoke PrepareForTailCall twice and pop too many contexts? 2020-09-05 [08:27:28.0000] How do we define `RelationalExpression`? [08:28:02.0000] like in the spec? https://snek.dev/ecma262-multipage/sec-ecmascript-language-expressions.html#prod-RelationalExpression [08:29:16.0000] say: `RelationalExpression:RelationalExpression in ShiftExpression` if you were to explain it, how do we define what a `RelationalExpression` is and what a `ShiftExpression` is? [08:30:28.0000] A relational expression is a relational expression followed by the "in" keyword followed by a shift expression [08:32:33.0000] hah hah, yes, it means all the expressions? [08:33:21.0000] like how do we define what a "relational expression" and a "shift expression" is? [08:33:28.0000] i'm not sure what you're asking [08:34:11.0000] What types of expressions are not RelationalExpression? [08:35:22.0000] an equality expression is not a relational expression [08:35:25.0000] for example [08:37:49.0000] nods, getting some clarity now [08:40:30.0000] And `ShiftExpression[Yield, Await]: AdditiveExpression[?Yield, ?Await]` [08:43:30.0000] `RelationalExpression in ShiftExpression` can be treated like `LHS in RHS`? [08:44:35.0000] `in` is a binary operator, right? [08:44:56.0000] so 1 in [1,2,3]; here is `1` a `RelationalExpression`? [08:45:19.0000] [Sorry, finding it hard to formulate the question] [08:46:04.0000] >n "a" == "a" in {} [08:46:20.0000] (ignore) [08:46:21.0000] howdoi: you could say that `1` is a relational expression, yes [08:48:22.0000] howdoi: https://gc.gy/67025900.png [08:49:56.0000] devsnek: nice :) [09:06:48.0000] devsnek: I am not find engine262 in astexplorer! [09:07:09.0000] howdoi: oh that's just a local clone of the repo [09:07:17.0000] i haven't PR'd it yet [09:07:27.0000] there are still some problems with it [09:07:41.0000] guessed, so, nice! because others aren't showing it as a relational expression [09:08:21.0000] yeah most ASTs just call that "left" and "right" [09:08:38.0000] engine262's ast would be hell for general use [09:11:13.0000] hah hah, true 2020-09-06 [00:02:09.0000] Is there any helper in spec get access to current realm? Like it can call GetRealm() or something from anywhere to get access [00:04:26.0000] bendtherules: you say "the current Realm Record", which gets autolinked to https://tc39.es/ecma262/#current-realm [00:05:29.0000] Interesting, thanks 2020-09-07 [09:33:52.0000] littledan: the latest decorator proposal looks pretty good [09:34:18.0000] i guess the reason we didn't go with it in the first place is all the features it doesn't have that static decorators have? [09:34:21.0000] oh my g-d, devsnek is saying this about a proposal that I worked on?!?!?! [09:34:27.0000] what's going on? [09:34:30.0000] lol [09:35:07.0000] well, it took me personally a long time to come to understand that this is what field decorators should do, nothing more, nothing less. that was kinda the hard case tbh [09:35:41.0000] i need to review it more in depth but the whole "they're just functions" thing is very appealing [09:35:41.0000] (it's weird that it took me so long since a lot of different people were saying that explicitly for a while) [09:39:10.0000] littledan: is the proposal adding Symbol.metadata [09:39:33.0000] devsnek: Yes, but there's no particular behavior attached to Symbol.metadata [09:39:42.0000] yeah no i like it [09:40:02.0000] it would be fun if ts had a mode to emit type info in metadata [09:42:50.0000] yeah... it's hard since types don't really have a runtime representation [09:43:11.0000] should we have syntax in JS to indicate types that would have runtime reification??? [09:43:19.0000] indeed, decorators that use type metadata is a big gap in this proposal [09:43:41.0000] but I feel like that can only really be filled by type systems. So, those type systems can emit extra data to Symbol.metadata, maybe [09:43:56.0000] i used a python library once [09:44:15.0000] it took advantage of python's type annotations being runtime reflectable [09:44:29.0000] to dynamically generate string parsers [09:44:31.0000] it was very slick [09:44:45.0000] yeah, I mean this is commonly used with TS, it has a mode for this [09:45:25.0000] i wish ts would take rtti more seriously :( [09:45:34.0000] rbuckton: ^ [09:46:09.0000] I feel like TC39 would be the right place to do a proposal for runtime type stuff, and it'd look a bit different from TypeScript. Mark and Waldemar did a "guards" proposal some years ago; maybe that could be a good basis [09:47:10.0000] i feel like any attempt to standardize a type syntax will fail [09:47:34.0000] https://web.archive.org/web/20141214075910/http://wiki.ecmascript.org/doku.php?id=strawman:guards [09:47:50.0000] this proposal used :: so it's unambiguous/non-overlapping with TypeScript [09:48:24.0000] I like how we have the division between TS doing checking statically and TC39 doing runtime semantics. If we can maintain that, I'll be happy [09:48:54.0000] the statement "any attempt to standardize ___ will fail" is true most of the time :) [09:49:41.0000] guards look interesting [09:53:02.0000] > i wish ts would take rtti more seriously [09:53:06.0000] I wish TS would take compile-time type information more seriously [09:55:10.0000] lmao [11:42:08.0000] littledan: is `@()` allowed in the simplified proposal? one section says it is and one section says it is not [11:42:18.0000] err, it is allowed [11:42:18.0000] well `@(expression)` [11:42:24.0000] which section says it isn't [11:42:27.0000] > Forms like @foo.bar or @(foo) are no longer permitted, as decorators are not JavaScript expressions. [11:42:28.0000] right, @() is an error :) [11:42:35.0000] oops! [11:42:45.0000] I should've fixed that before distributing broadly... [11:42:46.0000] thanks [11:43:12.0000] so `@x` and `@x.y` are allowed but for random exprs you have to do `@x(expr)` [11:43:51.0000] hm i guess i have to add class fields to engine262 if i want to play with this [12:25:19.0000] we really need to deduplicate all the various function and method evaluation stuff [13:06:35.0000] hmmm when `ObjectLiteral` grammar is used in a proposal, it links to the annex b definition instead of the main definition [13:35:05.0000] hm, yup, later biblio entries take precedence, looks like, and the annex B definition of `ObjectLiteral` is later than the main one [13:35:19.0000] also the biblio file is super stale because it isn't automatically kept up to date [13:41:44.0000] devsnek is there an existing proposal with this behavior that I can link in the issue I'm opening? [14:20:41.0000] Bakkot I was just prototyping something locally [14:20:47.0000] gotcha 2020-09-08 [20:40:31.0000] Bakkot: doesn't there need to be rule for the TRV of HexDigits :: HexDigits NumericLiteralSeparator HexDigit ? [20:42:03.0000] jmdyck I don't think so? TRV is used for template literal parts, and TRV for HexDigits is used specifically for the CodePoint production, which passes `~Sep` to HexDigits [20:42:36.0000] and the `HexDigits :: HexDigits NumericLiteralSeparator HexDigit` production is guarded on `+Sep`, so it cannot be used in that context [20:44:32.0000] sounds plausible. [20:46:40.0000] tx [06:11:13.0000] > 9:25 PM <• devsnek> we really need to deduplicate all the various function and method evaluation stuff [06:11:13.0000] I would be so happy if that happens 2020-09-09 [15:21:38.0000] anyone know of anything that would immediately shut down a proposal to add hashing apis? [15:27:39.0000] devsnek: https://github.com/sebmarkbage/ecmascript-shallow-equal ? [15:28:51.0000] ljharb: the goal is being able to build efficient collection types 2020-09-10 [13:19:55.0000] /msg ChanServ flags #tc39 septs delegate [13:19:59.0000] lol [14:18:28.0000] MylesBorins: how much do you like irc now, Myles? :) [14:19:25.0000] I have always simply accepted in [14:19:26.0000] never was love story [14:51:23.0000] There is no way to get a permalink to a sub-section right? say the last section of `12.10.3` [14:51:56.0000] maybe I can use Scroll To Text Fragment for now [14:57:26.0000] howdoi: easiest would be using the nested summary on the left [14:57:49.0000] like, click on 12.10.3 and it's quick faster to find 12.10 or 12 [14:59:16.0000] leobalter: yes, but I want a link to say, the `in` operator mentioned in `12.10.3` [15:46:39.0000] That will presumably become more important if #1950 goes through. 2020-09-11 [17:47:35.0000] jmdyck: michael ficarra and I just did a bunch of work on 2007 [17:47:54.0000] incorporated the commits from your 2007_ed branch, rebased on master, and then did a few more things [17:48:15.0000] hopefully all the uses of ToInteger are correct now [17:48:26.0000] we still need to rectify Date, which we'll do next Thursday [17:48:45.0000] how close is it to shipping, do you think? [17:49:40.0000] really hoping we'll have it ready by the meeting on the 20th, so that we can confirm we've identified all the places that plenary's input is required [17:50:04.0000] so far that list is Date stuff and this one we just discovered: https://github.com/tc39/ecma262/issues/2170 [17:50:26.0000] if we can get it ready by the meeting and get consensus on those issues at the meeting I'm going to push really hard to land it immediately after [17:50:38.0000] since it is a massive rebase [17:51:17.0000] oh we also incorporated the math algorithms one (2122), figuring it would land before 2007 [17:51:42.0000] that one [17:51:50.0000] that one's still changing, though [17:54:16.0000] a little bit, yes [17:54:20.0000] but only a little bit [17:54:27.0000] hoping we can get it in in the next couple of days [17:56:50.0000] good thing i got my 2122 review in then [17:58:52.0000] Are there many calls to ToInteger where infinity makes sense? [17:59:25.0000] almost all of them [17:59:41.0000] they tend to immediately bound above and below, in some manner [18:00:35.0000] I had something different in mind for "makes sense" [18:01:15.0000] can you rephrase, then? [18:01:19.0000] hm [18:02:31.0000] maybe: if ToInteger, rather than returning infinity, returned a large integer, would the resulting behavior be visibly different? [18:04:23.0000] well, it would need to be an integer larger than any other integer, which is kind of what infinity is for [18:04:36.0000] but mostly no, with a couple of exceptions in typed arrays / atomics [12:25:25.0000] shu: also note that byteLength/length for %TypedArray% already return 0 [12:25:37.0000] it's just ArrayBuffer#byteLength that's being relaxed [12:26:08.0000] rkirsling: ah indeed, oops, let me adjust the test [12:26:35.0000] (now, it's interesting that there's alignment between spec and reality to have DataView throw a lot, but this is exactly the kind of thing that we could choose to deal with at a later time if we wanted) [12:50:47.0000] rkirsling: oops got distracted, ArrayBuffer#byteLength definitely is web reality for all engines right now as well [13:04:55.0000] yup! [13:05:35.0000] that was the bit that started it all, 'cause I realized I shouldn't fix it [13:06:04.0000] I hadn't looked into typed arrays in particular until after talking with you, hehe [14:19:27.0000] it's really interesting to me that typed arrays can have arbitrary properties just as long as the key isn't a stringified float [14:20:35.0000] I wonder if it's meant to be less confusing somehow? but it's really kind of moreso, since x[1.1] is clearly not an ordered index [14:36:48.0000] can they? [14:37:37.0000] i don't think they can have "1.1" as an own property [14:38:40.0000] yeah that's what I mean [14:39:43.0000] `ta['1-1'] = 3` does something and `ta['1.1'] = 3` does not [14:44:47.0000] ah, i misread [14:44:59.0000] i no longer remember the original motivation [14:45:12.0000] but it is the source of the extra confusion of what happens when TAs are on the prototype that i talked about last year [14:45:16.0000] the one at salesforce [14:50:55.0000] oh yeah I had forgotten about that [14:52:34.0000] shu: did that result in a PR? [14:53:51.0000] that dropped off my radar and i haven’t gotten back to it yet, alas [15:07:38.0000] help appreciated ;) [15:10:47.0000] hehehe one step at a time [15:11:26.0000] this sure is a bumpy area of the spec 😅 [16:13:56.0000] you, too, can become an arraybuffer abyss gazer! [16:15:02.0000] heheheh 2020-09-12 [16:26:38.0000] littledan: out of historical interest, the november 2008 ("Kona") draft of ES3.1 had Decimal in it [16:26:47.0000] link to the PDF: https://web.archive.org/web/20160323172025/wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:tc39-es31-draft07nov08.pdf 2020-09-13 [17:51:01.0000] Bakkot: were you planning to PR the removal of overloads? If not, i would. [17:52:21.0000] (though really i should probably be looking at 2007 again) [18:00:24.0000] jmdyck I wasn't planning on prioritizing it, no [18:00:31.0000] if you make a PR I'll review it [18:00:46.0000] k [08:17:30.0000] ljharb: Math.max is conflicted about # of args: first para says zero or more, second para says at least two. [08:18:30.0000] then the first para is wrong, it’s length is 2 and signature agrees [08:20:26.0000] hm, but the former text says "If no arguments are given, the result is *-∞*." [08:21:55.0000] goes back to when Math.max was introduced in ES6. [08:22:45.0000] test262/test/built-ins/Math/max/S15.8.2.11_A1.js tests for it [08:24:51.0000] also a couple tests for Math.max with a single arg. [08:26:38.0000] Ditto Math.min, of course. [08:30:20.0000] Sorry, not ES6. [08:31:45.0000] Math.max/min go back to ES1, but they took exactly 2 args until ES3 [08:32:24.0000] since ES3, there's been an "if no arguments" bullet. [08:32:58.0000] i think in cases like this we should do [08:33:07.0000] In ES3, the heading for max was "15.8.2.11 max([value1[,value2[,...]]])", similarly for min. [08:33:11.0000] `Math.max ( ... args )` and "The length of Math.max is 2" [08:34:37.0000] ES5 had all the [], but they're not in ES6 headings: "20.2.2.24 Math.max ( value1, value2 , …values )" [08:39:12.0000] ljharb: would you like me to make a PR? [08:41:43.0000] the full-bracketing disappeared between draft 22 and 23 of ES6. [08:51:54.0000] Do we still not have an archive for wiki.ecmascript.org? [09:04:51.0000] Didn [09:06:14.0000] I didn't find anything in the bugzilla archive that would explain the loss of full-bracketing. There aren't any margin notes at that point in the 'notes' version of draft 23. [09:09:59.0000] i think it’s better to avoid length overrides [09:10:35.0000] i think it's better to avoid "[value1[,value2[,...]]]" [09:11:00.0000] in that case they’re all optional and I’d agree [09:11:06.0000] i don’t think your signature suggestion is better. [10:08:39.0000] presumably it's impossible to avoid a "length override", because that would require the heading to have 2 "normal" parameters, which misleads the reader. [10:09:17.0000] s/impossible/misleading/ [10:12:43.0000] I'm assuming "length override" = "explicitly specifying a length because it's different from what you'd infer from the heading" [10:16:35.0000] jmdyck: yes [10:16:54.0000] there's a number of methods like this, where we really use varargs but the first N args are explicit [10:18:53.0000] what do you mean by "really use varargs"? [10:27:57.0000] like Math.max - iow, the way they operate is as if the signature is `( ...args )` but they still have a required minimum number of args [10:30:36.0000] but Math.max *doesn't* have a required minimum number of args [10:32:39.0000] yeah, it doesn't even assume the first two to `undefined` [11:31:24.0000] I still don't get built in modules [11:31:35.0000] like given existing patterns with globals they just seem strictly worse [11:31:42.0000] that is my feeling also [11:31:55.0000] if js had started with them, I'd be a fan [11:32:23.0000] IIRC domenic came to the same conclusion after champion stuff in that space for years [11:32:51.0000] https://github.com/w3ctag/design-reviews/issues/421#issuecomment-561705979 [11:32:56.0000] *after championing [11:33:07.0000] yeah his post in the reflector was pretty clear about it [11:33:37.0000] that said, I do understand the motivation [11:33:55.0000] ya they sound very nice [11:34:00.0000] but just given that we have scripts [11:35:30.0000] hmmmm [11:35:55.0000] given TLA, I wonder if we might just start having globals for stdlib stuff where you have to await the global to get the actual functionality [11:36:04.0000] with TLA in modules that's not bad [11:36:25.0000] and then you can polyfill asynchronously without needing import maps [11:36:35.0000] sounds bad [11:36:36.0000] sorry, await a property on a global object [11:36:46.0000] what's bad about it? [11:36:58.0000] having to await a global [11:37:04.0000] wait do you mean like [11:37:12.0000] `await GoodMap` [11:37:22.0000] or `await X.doY()` [11:37:38.0000] I'd probably phrase it as `await goodMap()` or something [11:38:23.0000] `await std.GoodMap()`, I dunno [11:40:04.0000] it's weird to me that async is needed [11:40:19.0000] I agree it's less nice [11:40:33.0000] but it's necessary to meet other design goals [11:40:39.0000] so there's a tradeoff [11:41:04.0000] it is possible the answer is, this is sufficiently unnice that it is not worth achieving those goals [11:41:14.0000] but I am inclined to the other side of that [11:41:52.0000] the not-niceness is mostly paid by developers, whereas the other goals (async, as-needed polyfills) are paid by every user [11:43:03.0000] we should come up with feature codes for each thing added [11:43:08.0000] and that can be sent by browsets [11:43:11.0000] browsers, even [12:30:03.0000] https://github.com/tc39/ecma262/pull/2174 [12:31:11.0000] (since we were talking about it here) [13:09:54.0000] jmdyck: hm, that's true. in that case maybe the length override makes more sense 2020-09-14 [17:34:57.0000] what if, instead of builtin modules, we just added a new `ES` global and stuck everything on that [10:04:16.0000] ljharb: I can squash 2174 if you want it squashed. [10:06:27.0000]