TC39 General
2024-01-22
plaintext logs
prev next
source on github
13:56
<littledan>
yeah I guess I'm probably over-indexing on the operator syntax of void in my skepticism of void. "lost" is a good characterization. But still, _ has recognition from other languages.
14:29
<Jan Olaf Martin>
yeah I guess I'm probably over-indexing on the operator syntax of void in my skepticism of void. "lost" is a good characterization. But still, _ has recognition from other languages.
I'm not sure if the recognition from other languages outweighs the established use(s) of _ in the JS ecosystem. I assume most JS devs would associate it with "bag of utility functions", not necessarily with "unused".
15:06
<littledan>
Yeah, that's fair. At least the _ is locally unambiguous/compatible
15:06
<littledan>
really, void for this purpose is even somehow more apt than void for C, isn't it
15:10
<Kris Kowal>
Use of _ I’ve encountered is not as a black hole (void) but as a readable reference to the last thing bound.
15:11
<littledan>
oh yeah I guess overloading both of those in the same thing is weird
16:09
<snek>
I feel like _ is off the table since it's already a valid identifier
16:12
<littledan>
the idea is to stay with its current semantics wherever valid, and just introduce a TDZ or syntax error (for usage, not definition) when bound in an invalid duplicate way (eg strict mode parameters)
17:32
<ljharb>
i don’t think moving towards scala’s “21 different meanings for _” would be an improvement
17:47
<littledan>
OK I'm convinced. So who's bringing the void proposal to committee?
17:47
<littledan>
We can do it separately from pattern matching, right? it'd just compose well
17:48
<bakkot>

So who's bringing the void proposal to committee

per https://github.com/tc39/agendas/blob/main/2024/02.md, rbuckton

17:50
<bakkot>
I also like the "ignore a parameter to a callback" use case
17:50
<rbuckton>
I would prefer _, but picked void due to concern's like ljharb's. At the very least, void in this sense has a similar semantic meaning. A void expression discards a result, while a void binding discards the binding.
17:51
<littledan>
I would prefer _, but picked void due to concern's like ljharb's. At the very least, void in this sense has a similar semantic meaning. A void expression discards a result, while a void binding discards the binding.
yeah, the complexity is that extractors/pattern matching may introduce expressions in the LHS
17:51
<rbuckton>
Callback parameters, excluding things from ..., explicit Elision (i.e., const [a, void] = iter vs const [a, , ] = iter due to trailing ,), all seem good to me :)
17:52
<rbuckton>
I plan to handle void vs void expression in things like destructuring via a cover grammar.
17:52
<bakkot>
yeah void instead of holes in array destructuring is a definite improvement also
17:52
<rbuckton>
So this is designed to dovetail with pattern matching and extractors, which are specifically called out in the explainer.
17:54
<rbuckton>
I'm debating on void for explicit elision in array literals as well, since [0, ,] and [a, void 0] are subtly different.
17:56
<rbuckton>
var ar1 = [0, , ];
var ar2 = [0, void 0];
ar1.length; // 2;
ar2.length; // 2;
ar1[1]; // undefined
ar2[1]; // undefined
1 in ar1; // false <---
1 in ar2; // true
17:57
<bakkot>
I suspect you can just update the existing cover grammar; it already has to deal with stuff like [ { m(){} } ] being legal only in expression position and [{ a = 0 }] only being legal in binding/assignment target position
17:57
<rbuckton>
I suspect you can just update the existing cover grammar; it already has to deal with stuff like [ { m(){} } ] being legal only in expression position and [{ a = 0 }] only being legal in binding/assignment target position
I have a rough outline of that in the explainer under the Grammar heading.
17:59
<bakkot>
ah, nice
18:03
<bakkot>
I'm debating on void for explicit elision in array literals as well, since [0, ,] and [a, void 0] are subtly different.
my answer to this would be no: no one should be writing array holes on purpose, so we shouldn't provide new syntax to help them
18:03
<bakkot>
I'm not dead set against it, I just don't want it
18:37
<rbuckton>
I agree that no one should write them on purpose, but people can and do. I would only consider supporting it if full parity for explicit Elision is necessary for advancement. i.e., if to have [a, void, b] = [1, , 3] I must also have [1, void, 3], then I believe the void in [1, void, 3] must be equivalent to [1, , 3], else it is not truly an in-place replacement for Elision.
18:38
<rbuckton>
But I'm fine with not having it if there isn't a hard requirement for it from other delegates.
19:15
<littledan>
yes, I agree that we shouldn't make void in certain expression context another way to say void 0.
19:15
<littledan>
that seems complicated and unmotivated
19:16
<bakkot>
if I have understood correctly the idea would be an elision (i.e. a hole), not undefined; those are different
19:31
<littledan>
yes, so I agree with Ron that it shouldn't do undefined. This seems to be a sort of strawperson that no one is arguing for.
19:31
<littledan>
but having another way to type holes also seems not so motivated