Can we use _ (underscore) instead of void?

[rbuckton]

An overwhelming majority of programming languages with a "Discard"-like concept use _ as the discard marker, including C#, F#, Python, Rust, Go, and now Java, so there has been some interest in whether it might be possible to pursue _ in ECMAScript as well.

The Problem

In ECMAScript _ is a legal identifier which makes it difficult to reserve for this purpose without potentially "breaking the web". Popular packages like underscore and lodash are frequently referenced using _, including in the package documentation:

Documentation for _.each() in Underscore.js

There is regular pushback against repurposing any identifier in ES as a result of these concerns, so it is unlikely we can follow any kind of deprecation path for _ as did, for example, Java in its implementation.

Allow Duplicate Names: A Possible Solution?

As I have briefly discussed in both the April and June 2024 plenary sessions, there is a potential path forward to use _ for discards, though not without some limitations. One way in which we could enable this behavior is to make a change to the semantics for duplicate lexical bindings. Today, we have a static semantics rule that results in an early error if you declare a lexical binding with the same name as another lexical binding in the same block scope, or the same name as a "var" declared name in the same "var" scope, as well as a rule to produce an early error if you duplicate a parameter name in a strict function parameter list:

let _, _; // SyntaxError: Identifier '_' has already been declared

var _;
{
  let _; // SyntaxError: Identifier '_' has already been declared
}

"use strict";
function f(_, _) { // SyntaxError: Duplicate parameter name not allowed in this context
}

Since these are already errors, there is no code that currently executes successfully in these conditions, and it's unlikely that any code has a dependency on this behavior. As a result, we could relax this restriction and allow lexical bindings to be duplicated, but have such duplication poison the binding name in the current lexical environment:

let _, _; // ok
console.log(_); // SyntaxError: Identifier '_' cannot be referenced in this context

What about underscore/lodash?

Rather than restrict this to _, we can enforce these rules for all identifiers. This means that you could use __ or ___ or foo or any other variable name you want as a discard without shadowing an outer _ declaration.

What about typeof?

Since typeof is intended to work even for undeclared variables, it is expected that

let _, _;
console.log(typeof _);

would print "undefined" just as it would if _ were not declared.

What about shadowing?

While typeof might treat _ in let _, _ as if it were not declared, we are still creating a poisoned binding in the current environment, which means that _ remains poisoned in nested scopes. However, a redeclaration in a nested scope would shadow the poisoned binding:

let _, _;
{
  let _ = "foo";
  console.log(_); // prints "foo"
}

Advantages

This approach has several advantages:

• No single identifier is treated uniquely within the specification as this would apply to all identifiers.
• No need to use the void keyword.
• No need to change existing code to use discards.
• No special syntax or prologue directive to enable this behavior.

Disadvantages

Unfortunately, this is not a complete solution as there are several disadvantages over void:

• Cannot be used as a discard in an AssignmentPattern
• Cannot be used as-is in pattern matching
• A single _ at the top level of a Script becomes a global

Cannot be used as a discard in an AssignmentPattern

Any IdentifierReference in an AssignmentPattern must still be a valid assignment target. Since _ is still treated as a regular identifier, an assignment pattern like { x: _, y: _, ...z } = obj would still attempt to write to an identifier named _. Rather than acting as a discard, that would either (a) overwrite an existing variable named _, (b) introduce a new global variable (in non-strict code), or (c) throw due to a missing declaration (in strict code).

Since that is very context-dependent, it is inherently unsafe to ignore the error in (c), so we cannot loosen this restriction like we could for lexical bindings.

Cannot be used as-is in pattern matching

In pattern matching an identifier that is not property name must be an IdentifierReference. As a result, a pattern like

when { x: _, y: _ }

would actually be matching the values of the x and y properties to whatever the value of _ is, so we would not be able to use _ as-is as a discard.

Instead, we would have to leverage let patterns as proposed by the pattern matching proposal, e.g.,

when { x: let _, y: let _ }

, which is far less ideal.

A single _ at the top level of a Script becomes a global

The purpose of a discard is to evaluate but not bind, however the following introduces a global _ variable:

<!DOCTYPE html>
<html>
<head>
<script>
    let { x: _, ...obj } = { x: 1, y: 2 };
</script>
<script>
    console.log(_);
</script>
</head>
</html>

Users might mistakenly assume that _ was actually a discard when in fact it introduced a global variable that is visible to all code running on the page. This can be mitigated by forcibly poisoning the declaration via, e.g., let _, _;, but that is not going to be obvious to most developers.

[ljharb]

It's an existing invariant that typeof can't ever generate an error; that's why typeof NonExistentGlobal === 'undefined' has always been a safe check. That must not ever change.

[rbuckton]

It's an existing invariant that typeof can't ever generate an error; that's why typeof NonExistentGlobal === 'undefined' has always been a safe check. That must not ever change.

That is a fair point. typeof should work and probably treat the poisoned declaration as if it were merely missing. I'll make a note in the OP and update my examples.

[rbuckton]

It's an existing invariant that typeof can't ever generate an error; that's why typeof NonExistentGlobal === 'undefined' has always been a safe check. That must not ever change.

I'll make a note in the OP and update my examples.

Updated. See the sections marked "What about typeof?" and "What about shadowing?", above.

[michaelficarra]

@rbuckton I don't see what I consider to be the main benefit of void listed here. _ is a refactoring hazard. There exists today many large files that refer to a library as _ throughout. When working in that file, if someone wants to introduce a function wrapper around some of the code that uses a discard binding, references to _ within that code will now be overridden. void doesn't have this inconsistent behaviour. So even if we allow duplicate _ bindings, we still need to have void for discard in circumstances like these. I'm not a fan of having both, but I also think it's unacceptable to have just _.

[rbuckton]

This is covered by the proposal in the OP. I am not restricting this to _. Any identifier could be used as a discard, so the refactoring hazard is minimal. A linter or checker could easily detect a duplicate _ (or other ID) and warn you if you've shadowed a nested reference.

[michaelficarra]

Yes and in my example you could also rename the inner _ references to an alias that was captured outside the scope. But that has significantly more complicated semantics than void just always meaning discard.

[rbuckton]

Yes and in my example you could also rename the inner _ references to an alias that was captured outside the scope. But that has significantly more complicated semantics than void just always meaning discard.

I would argue it has roughly the same semantics as renaming any variable in JS has. It does not introduce a new hazard.

[rbuckton]

After some discussion with the Pattern Matching champions and further consideration on my part, the plan I intend to propose in the October plenary session is to continue with void as the primary mechanism for discards. void covers all use cases, while the duplicate identifiers mechanism cannot be used reliably in AssignmentPattern and has the possibility of introducing unintended global variables in a Script.

However, I do plan to discuss the possibility of introducing the duplicate identifiers mechanism as an optional alternative in addition to void, either as part of this proposal or as a follow-on proposal.

[hax]

cannot be used reliably in AssignmentPattern

Personally I don't think it's a big problem, it seems developers rarely use AssignmentPattern (because syntax ({x: _} = ...); is inconvenient).

Since that is very context-dependent, it is inherently unsafe to ignore the error in (c), so we cannot loosen this restriction like we could for lexical bindings.

Could you say more about this? Why we can't make a special case for _? Performance issue?