| 02:31 | <Richard Gibson> | sure, but in the same sense as flatMap itself is .reduce((out, ...args) => out.concat(mapper(...args)), []) |
| 09:48 | <Andreu Botella (he/they)> | Hi! I just noticed that Atomics.multiply() isn't a thing. Is that because for all other operations you don't need to know whether the type is signed or unsigned but for multiplication you do? |
| 18:19 | <Domenic> | What objects in 262 use option bags? |
| 18:19 | <Domenic> | I am investigating whether error.cause's HasProperty + Get pattern is standard or unusual |
| 18:22 | <bakkot> | 262 itself does not tend to use object bags much, though that's changing. 402 uses them more and just does Get, IIRC |
| 18:22 | <bakkot> | I think we are in generally in favor of just doing Get; I argued for error.cause to be a special case because, unusually, undefined is a value one might reasonably want to use |
| 18:23 | <bakkot> | In cases where undefined is not an expected value there's no particularly reason to do a Has check first |
| 18:23 | <Domenic> | Hmm |
| 18:23 | <Domenic> | I do not like distinguishing between undefined and not-present in the options bag |
| 18:23 | <Domenic> | As well as on the object itself |
| 18:24 | <Domenic> | I feel like if you really want to split hairs there you should use error.cause === undefined vs. error.cause === null, instead of testing 'cause' in error |
| 18:24 | <bakkot> | The problem is that the error values are generally being handed to you, not a thing you are creating yourself: that is, you are writing catch (e) { throw new Error('message, { cause: e }) without testing the value of e |
| 18:26 | <Domenic> | Sure |
| 18:27 | <Domenic> | But I don't understand why that means it's important that 'cause' in new Error('message') is false whereas 'cause' in new Error('message', { cause: undefined }) is true. |
| 18:28 | <bakkot> | Ah, this was on the assumption that there would not be a cause property if you didn't pass the options bag at all |
| 18:28 | <bakkot> | that is, I think it's important that 'cause' in new Error('message', { cause: undefined }), since you are explicitly asking to create an error with a cause |
| 18:29 | <bakkot> | I don't know if I have an opinion about whether 'cause' in new Error('message') should also be true |
| 18:30 | <bakkot> | but I do think 'cause' in new Error('message') should match 'cause' in new Error('message', {}) |
| 18:30 | <Domenic> | My opinion is it should also be true |
| 18:30 | <Domenic> | I.e. we should not branch behavior on {} vs. { cause: undefined } |
| 18:31 | <Domenic> | Filed https://github.com/tc39/proposal-error-cause/issues/35 |
| 18:36 | <bakkot> | Mind, it's already stage 3, so I don't know how much appetite there will be for this sort of change |
| 18:56 | <shu> | it's also already shipping |
| 18:56 | <shu> | well, almost, coming up in chrome 93 |
| 19:01 | <justingrant> |
Temporal uses options bags in almost every method that takes parameters. If we're using them incorrectly or inconsistently, let us know! |
| 19:18 | <Domenic> | My intent was for this to be "implementer feedback" as we work to spec/implement structured clone for it |
| 19:25 | <shu> | i was chatting with marja on the V8 team about just this the other day, on whether we should unify option bag handling to be Get for Error cause |
| 19:26 | <shu> | my conclusion was that "just a Get" should be the default behavior for option bags, but once in a while a specific use case arises that requires special casing with a Has, like Error cause has with wanting to capture undefined/falsy values, which can be thrown |
| 19:26 | <shu> | wait, is that what's being discussed here, i might've skimmed it too fast |
| 19:42 | <Domenic> | Pretty much yeah. I just think we shouldn't distinguish because { cause: undefined } and {} |
| 19:49 | <justingrant> | From a documentation standpoint, does { cause: null } mean "I am filling cause but I don't know what the cause was" as opposed to { cause: undefined } which means "I didn't fill in a cause"? |
| 19:57 | <shu> | are you asking about the status quo or domenic's suggestion? |
| 19:57 | <shu> | the status quo is cause, if present at all, is honored, since you can throw undefined; and maybe you want to capture that in the cause |
| 20:27 | <Richard Gibson> | it seems hostile to future options for new Error(message, {}) to create a cause property that would not be present on the result of new Error(message) |
| 20:29 | <justingrant> | Got it. TIL that throw undefined was a thing. 🤷♂️ Just when I thought I knew all the weird parts of ECMAScript, it turns out there's always something weirder! |
| 20:39 | <bakkot> | Richard Gibson: I believe the proposal is for new Error(message) to also have a cause property |
| 20:40 | <bakkot> | per https://github.com/tc39/proposal-error-cause/issues/35 + https://github.com/tc39/proposal-error-cause/issues/36 |
| 21:03 | <Domenic> | Indeed, the idea is that, like everywhere is that I'm aware of in the ES spec ecosystem and web platform, omitting the options object is treated the same as the empty options object which is treated the same as the options object with a bunch of undefineds for each option. |
| 21:06 | <bakkot> | Are there any other options bags for which undefined is a value one might end up explicitly supplying as the value of some option? |
| 21:06 | <bakkot> | none in ES including 402, afaik |
| 21:08 | <justingrant> | None in Temporal, AFAIK |
| 23:02 | <littledan> | WebIDL dictionaries make it impossible to tell the difference |