| 00:21 | <jschoi> | sideshowbarker: Does MDN document the autoboxing of primitives anywhere? I’m writing up beginner documentation that mentions that the x.p = 2 in x = 3; x.p = 2 doesn’t actually assign anything, and I’d like to be able to link to somewhere that explains, “The 3 gets autoboxed into a Number object that then gets discarded.” |
| 00:25 | <bakkot> | it's probably worth having such documentation, but in real life people should use strict mode so that x.p = 2 is an error and they don't have to think about it |
| 00:25 | <Ashley Claymore> | I don’t think auto boxing happens for a set operation |
| 00:26 | <jschoi> | I don’t think auto boxing happens for a set operation |
| 00:27 | <bakkot> | it does; see GetValue step 4.a: https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-getvalue |
| 00:28 | <jschoi> | I’m writing beginner documentation about obj.prop = val that mentions this idiosyncrasy and says, “Don’t do this,” but maybe I should just avoid mentioning it at all for now. MDN doesn’t talk about primitives in its tutorial until its “Advanced” level. |
| 00:28 | <bakkot> | or I guess PutValue 5.a., rather: https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-putvalue |
| 00:28 | <bakkot> | PutValue is invoked in step 1.e. of the evaluation semantics for assignment: https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-assignment-operators-runtime-semantics-evaluation |
| 00:29 | <Ashley Claymore> | "".prop = 1 // throwsObject("").prop = 1 OK |
| 00:29 | <bakkot> | Ashley Claymore: only in strict mode! |
| 00:30 | <bakkot> | jschoi: I would encourage telling beginners to only ever write or think about strict mode code, and to avoid telling them things which are only relevant to sloppy mode |
| 00:30 | <Ashley Claymore> | Right, if set returns false it only throws in strict. |
| 00:30 | <Ashley Claymore> | What I mean is you get a different behaviour between auto-box and explicit box |
| 00:31 | <Ashley Claymore> | the auto-box acts like it’s non-extensible, but the actual box is extensible |
| 00:33 | <bakkot> | it's... actually weirder than that |
| 00:34 | <jugglinmike> | Can ECMA262 have a tagline? |
| 00:35 | <bakkot> | 'use strict'; Object.defineProperty(Number.prototype, 'x', { set: () => { console.log(this) } }); (3).x = 2; // works! |
| 00:36 | <bakkot> | it's not that the auto-box acts like it's non-extensible, it's that in strict mode the [[Set]] sees the target as the primitive, rather than as the box, which is observable with setters |
| 00:36 | <Mathieu Hofman> | In sloppy mode this gets converted to object, so PutValue operates on the boxed version, and ToObject simply returns the already boxed valueIn strict mode, the value stays a primitive, ToObject boxes it, so set is given the primitive as receiver, which it checks, and throws |
| 00:37 | <jschoi> | Can ECMA262 have a tagline? |
| 00:37 | <Mathieu Hofman> | Reflect.set(Object(3), 'x', 2, 3) vs tmp = Object(3); Reflect.set(tmp, 'x', 2, tmp) |
| 00:39 | <Ashley Claymore> | Thanks, nice explanation! |
| 00:40 | <Mathieu Hofman> | I was very confused the other day where the different throwing happened in strict mode, so I had just looked it up |
| 00:49 | <shu> | Can ECMA262 have a tagline? |
| 00:50 | <jugglinmike> | lol |
| 00:51 | <jugglinmike> | I was thinking of bakkot 's comment, "it's... actually weirder than that", but these are good, too |
| 00:51 | <shu> | relatedly my favorite margarine tagline remains "Memories of Butter", but "Memories of JavaScript" doesn't work as well here |
| 00:54 | <jugglinmike> | "Memories of Restraint" |
| 00:56 | <shu> | dang |
| 00:58 | <sideshowbarker> | sideshowbarker: Does MDN document the autoboxing of primitives anywhere? I’m writing up beginner documentation that mentions that the |
| 00:59 | <jschoi> | Thanks. Maybe we can work on that later. I’m about to put in a big pull request on the tutorial section on assignment right now. |
| 01:01 | <jschoi> | https://github.com/mdn/content/pull/10648 |
| 01:01 | <jschoi> | Some of you here might remember a person (and their probable sock puppet) persistently raising somewhat confused points about “evaluation order” in JavaScript a couple of months ago, on the pipe-operator repository and also MDN’s repository…Hopefully this will prevent further confusion for any coming newcomers. |
| 01:02 | <jschoi> | (I was inspired by devsnek’s changes in response to that in mdn/content#9243.) |
| 01:09 | <bakkot> | Can ECMA262 have a tagline? |
| 01:14 | <jugglinmike> | Oooh, so somber |
| 01:50 | <devsnek> | yikes |
| 10:48 | <Jack Works> | I wouldn’t envy anyone given the task to write a complete formal specification for TypeScript, even if it’s all defined in terms of transforms to ECMAScript. |
| 14:25 | <devsnek> | if we just removed isConcatSpreadable would anyone notice |
| 15:41 | <jmdyck> | Is it possible/allowed for an object to be the global object of two different realms? The line in the spec that would appear to answer this isn't entirely clear. |
| 15:49 | <jmdyck> | There's the question of which intrinsics (i.e., from what realm) its properties would point to. |
| 15:49 | <sideshowbarker> | https://github.com/mdn/content/pull/10648 |
| 15:53 | <jmdyck> | And it's unclear what effect SetDefaultGlobalBindings would have, if any. (It would depend on how the object's [[DefineOwnProperty]] method is defined.) |
| 15:54 | <jmdyck> | It seems like the spec didn't anticipate the possibility, but hasn't actually disallowed it. |
| 16:00 | <jmdyck> | E.g., I don't think there's an Assert that would fail. |
| 16:48 | <jmdyck> | So each realm would have its own set of intrinsics, but in at least one, the global object's properties wouldn't point to the realm's well-known intrinsics. That'd be pretty weird, right? |
| 16:51 | <Mathieu Hofman> | Right, but I believe nothing prevents a host or first run code to modify the global in a similar way. It wouldn't be the same object, but all the properties could be copied from another realm. |
| 16:52 | <Mathieu Hofman> | Jest actually has a bad problem of copying some of the intrinsics from the incubator realm to the test realms it creates, which causes a ton of issues. |
| 16:57 | <jmdyck> | SetDefaultGlobalBindings is certainly trying to make a realm's global object's properties point to the realm's intrinsics. You're saying it's allowed for a host to 'get around' that? |
| 16:58 | <jmdyck> | (E.g., by making an exotic global object with a [[DefineOwnProperty]] that spurns SetDefaultGlobalBindings attempts.) |
| 17:00 | <Mathieu Hofman> | I'm saying since the host controls the global object, the only thing we can do is add new constraints on what a host is allowed to do with the global object. |
| 17:02 | <Mathieu Hofman> | There are other cases of constraints we'd like to add, such as the host cannot add any non configurable properties. |
| 17:03 | <jmdyck> | In that case, do you think we should add a constraint that the host can't use an object as the global object of multiple realms? |
| 17:09 | <Mathieu Hofman> | Possibly. I haven't really thought about it. Maybe it could say something about what the global object's exotic operations are allowed to do, then we can add assertions in the setup phase |
| 17:10 | <jmdyck> | Now I'm wondering if a [[DefineOwnProperty]] that thwarts SetDefaultGlobalBindings could satisfy the object invariants. |