| 07:33 | <Rob Palmer> | 🇯🇵🇯🇵🇯🇵 Reminder 🇯🇵🇯🇵🇯🇵
|
| 08:00 | <nicolo-ribaudo> |
|
| 16:54 | <nicolo-ribaudo> | I'm preparing slides for https://github.com/nicolo-ribaudo/ecma262/pull/4, and I'm wondering if it would be better to go through the proposal process or as a needs-consensus normative PR. Does anyone have opinions? |
| 16:55 | <ljharb> | i think we'd need a plenary discussion at least before deciding on that; i think "needs consensus" would only be if the semantics and motivation are so compelling and uncontroversial that we're all confident there's basically nothing else normative to discuss |
| 16:56 | <nicolo-ribaudo> | Ok, I can end the slides asking "stage 1/2 or normative PR?" |
| 16:58 | <Michael Ficarra> | definitely stage process from me |
| 18:21 | <littledan> | We considered this capability for optional chaining way back when, and decided we didn't have strong enough use cases (though contrary arguments were made IIRC). |
| 18:22 | <littledan> | I agree that this deserves to be treated as a staged feature |
| 18:23 | <nicolo-ribaudo> | We considered this capability for optional chaining way back when, and decided we didn't have strong enough use cases (though contrary arguments were made IIRC). |
| 18:25 | <littledan> | Yeah I'm glad you're bringing this up |
| 18:25 | <littledan> | I support the proposal personally |
| 18:25 | <Lea Verou> | Great to see work in that direction, huge +1! From an author perspective, there is no obvious mental model that explains why optional chaining doesn't work for assignment. Entirely anecdotal but as an author myself, I stumble on this on the regular and still cannot internalize the restriction. Looking at the proposal, at least 1-5 seems to match expectaitons. |
| 18:26 | <littledan> | It'd be interesting to go through all the other cases that were excluded; IIRC there are like 8 separate things |
| 18:27 | <littledan> | (Last time it was discussed, I wasn't quite convinced that we should include absolutely everything out of consistency, but I also don't see huge downsides to including more cases.) |
| 18:27 | <nicolo-ribaudo> | Listed at https://github.com/nicolo-ribaudo/ecma262/pull/4 :) |
| 18:28 | <littledan> | This analysis was particularly persuasive to me, in making the past decisions: https://github.com/tc39/proposal-optional-chaining/issues/17 |
| 18:28 | <littledan> | Heh sorry for not reviewing all of this yet |
| 18:31 | <littledan> | so, for example, are we comfortable continuing to omit new x?.()? |
| 18:31 | <littledan> | (I am) |
| 18:32 | <nicolo-ribaudo> | I personally never found a case where I needed it |
| 18:32 | <littledan> | I personally never found a case where I needed it |
| 18:34 | <littledan> | in particular, if we want to design around considering generalizing "there is no obvious mental model that explains why optional chaining doesn't work for assignment." |
| 18:35 | <littledan> | e.g., maybe we want to support x?.y++--that one stands out as useful, even if I like your reason for omitting it |
| 18:35 | <Lea Verou> | I personally never found a case where I needed it |
| 18:35 | <littledan> | (sorry for putting words in your mouth there) |
| 18:55 | <bakkot> | peetk: you should probably remove the bit from your slide about promise = Promise.withResolvers(); that API shape is not going to happen and there's not much point bringing it to committee to get rejected |
| 23:39 | <Chris de Almeida> | https://doodle.com/meeting/participate/id/boyykLYe @room looking to convene TG3 next week. please complete the above doodle. keeping it short for now (30m slot), and this doodle isn't meant for recurring cadence. rough agenda:
|