java is using _ for void bindings: https://openjdk.org/jeps/456

I very much prefer we use _, I think refactoring hazards are pretty simple to fix since it's a lexically scoped name.

I don't think the average JS app developer is using void 0 so I would say any JS devs who have an association with void as a keyword would be thinking of it as a return type

_ is a perfectly reasonable thing to use in a language where it's not a valid identifier, to be clear - precisely because it's short and connotes "nothing"

I would want it to poison all uses anywhere in the scope. so you could write

const { _ } = whatever;
console.log(_)

and

const { _ } = whatever;
const { x: _ } = foo;

but not

const { _ } = whatever;
console.log(_)
const { x: _ } = foo;

Also note that already today adding the third line here makes the code an error, it's not something new

＿ should be safe

How is _ safe in a page that uses underscore.js?

so there are a variety of ways this could work. the simplest backwards-compatible way would be, no changes to any current programs, but it becomes legal to re-declare _ in the same scope; if you do, any references to _ within that scope are an error (possibly at parse time).

＿ should be safe

Man you really gotta make it obvious when you're doing unicode shenanigans (U+ff3f FULLWIDTH LOW LINE, not ASCII underscore) ^_^

Honest question: would it be better to change the binding rules for an existing (and widely used) identifier, or using a new piece of syntax for this that only works in strict mode? Is there any precedent for the latter?

that's a matter of opinion, but given that the former would allow us to be consistent what ~every other language does, it seems like the better option by far

Even in strict mode, * (or other operators) don't work in using declarations

Damn you’re right. Is there any symbol that would work?

I've also proposed using ~ as part of partial application since one of the other concerns was the need for a token to opt-in to the behavior, so foo~(1, ?, 2) as a partial application of foo that supplies the first and third argument with a placeholder for the 2nd argument.

This example showed me maybe partial application is a bad idea in JS, as much as I love it in FP languages

We've already run out of concise syntax. One of the blockers for pipeline has been picking a topic token.

This was discussed in the last plenary.

On the papp/pipeline side, I still think F# pipes and papp would have been far more likely to get to stage 2 as they were general purpose capabilities that dovetailed. F#'s style biggest drawbacks were how to handle yield and await, and a push to allow you to do general operations against the topic (i.e., x |> _ + _). For F#-style await was solvable, and I don't think yield was all that important (i.e., you could still write (yield x |> F) |> G). I also think the overwhelming majority case for pipelining was writing expressions in arrow functions, not immediately on the right side of the pipe:

// most likely use
ar |> filter(?, x => x > 1)
   |> map(?, x => x * 2)

I just don't see y = x |> _ + _ as all that valuable, especially since you can already use , for that today with no new syntax.

var _;
y = (_ = x,
    _ = _ + _);

You have not encountered enough point free F# people 😂

I don't think using the same token for discard and papp is a good idea. In the pattern matching space, I've been considering how partial application could allow you to supply arguments to a custom matcher:

match (x) {
  when NodeMatcher~(SyntaxKind.Identifier, ?)({ let pos, let end }): ...;
}

as a way to synthesize an extractor in-place as opposed to

const identifierMatcher = _ => NodeMatcher(SyntaxKind.Identifier, _);
match x {
  when identifierMatcher({ let pos, let end }): ... ;
}

There was a tremendous amount of very vocal frustration in the RxJS community that pipeline did not use F# style.

I don't think using the same token for discard and papp is a good idea. In the pattern matching space, I've been considering how partial application could allow you to supply arguments to a custom matcher:

match (x) {
  when NodeMatcher~(SyntaxKind.Identifier, ?)({ let pos, let end }): ...;
}

as a way to synthesize an extractor in-place as opposed to

const identifierMatcher = _ => NodeMatcher(SyntaxKind.Identifier, _);
match x {
  when identifierMatcher({ let pos, let end }): ... ;
}

It's still very popular and heavily used in React projects. Rx's Observable has already been a proposal to TC39 (which stalled), and is now a proposal in WHATWG

That would have been const identifierMatcher = NodeMatcher(SyntaxKind.Identifier, ?)

No, I don't believe it is.

Give me a standard library before Observables. I'm actually going to start saying that in reference to every new API at this point

Discarding things in JS is either through void (as a syntactic feature of the language), or through _ (on its own or as a prefix, by convention).