05:33
<Meghan Denny>
is there a google calendar with all the meeting times?
15:51
<TabAtkins>
there is a calendar entry, yes - it's in the TC39 Events calendar
16:31
<ljharb>
(also i'm happy to add individual delegates' emails to the event, if you want it to automatically populate in your calendar - i always put mine on there)
19:56
<Nano Miratus>

hello...this might be a weird question but here we go:
was there ever a proposal for a "conditional equality operator"? what i mean is an operator for this pattern:

const fn = (value) => {
  return value === "foo" ? "foo" : "bar";
}

which could also be written like this:

const fn = (value) => {
  return value === "foo" ? value : "bar";
}

but my theoretical operator should achieve the same logic while avoiding repetition of either value or "foo", so something like this: value ==? "foo" : "bar"

i also couldn't find any example of such an operator in any other programming language, which really surprised me, but maybe i'm stupid and an operator like this doesn't work or doesn't make any sense

really curious if anybody here might have a take on this

20:02
<bakkot>
I don't think I've seen a proposal for this. I think it's simply too specialized to be worth having special syntax for.
20:03
<Nano Miratus>
this theoretical operator can be compared to nullish coalescing, it's very similar but just with a custom value instead of null nullish coalescing is defined as: a ?? b if a !== null then return a, else return b my operator a ==? c : b if a !== c then return a, else return b
20:05
<Nano Miratus>
hm, okay...i'm still surprised that i couldn't find something like this in any other language though...i get that it might be too specific and that it might seem not worth it, but something like this could simplify code where the "foo" from above isn't just "foo" but some long/dynamic thing
20:06
<bakkot>
There are many many patterns that are somewhat similar to this; once you start adding syntax for things at this level of "already easy to write" + "not all that common" there's no obvious limit to how many such bits of syntax you'd add
20:07
<bakkot>
null is special because it is so often used to represent a missing value, and nullish coalescing therefore represents the act of providing a default for a missing value, which is (I would guess) at least an order of magnitude more common than this pattern
20:08
<bakkot>
all language design involves considering these tradeoffs, of examining how common is / how hard it is to currently write, and picking a threshold; some languages set the threshold lower, but they all have to set it somewhere
20:08
<bakkot>
though some languages do allow you to define your own syntax; it would not surprise me to find that someone has made such an operator in userland in, say, Scala