Considering alternative syntax for using value

[rbuckton]

NOTE: This suggestion has since changed from using const (expr) to using const void = expr.

Rather than introduce a second contextual keyword (i.e., value), I'm considering changing the syntax for the version that does not introduce a binding to using const (expression); using const void = expression;.

This has several benefits:

• No need for another contextual keyword (i.e., value).
• Binding-less using could be performed inline in the same statement:
  • Before:

    using const x = f();
    using value g();
    using const y = h();
    

  • After:
    using const x = f(), (g()), y = h();

    using const x = f(), void = g(), y = h();
    

using const is already a subtly different grammar than const, as using const does not permit destructuring, so having a () syntax unique to that declaration shouldn't conflict with existing syntax. The treatment of , in a using const declaration is similar to that of a normal const (or let/var), so there is no parser ambiguity with respect to , expressions.

Since void is not a legal identifier, there should be no syntactic ambiguity. In addition, the term void generally refers to something that we want to ignore, or that doesn't exist, so using void in place of a BindingIdentifier to indicate an unwanted binding isn't too far-fetched. In addition, it allow a bindingless declaration to look syntactically similar to a regular declaration:

using const x = f(),
            void = expr,
            y = h();

[fstirlitz]

Why not put using next to the binding pattern instead of before the whole declaration?

This has the benefit that one can now disambiguate between taking ownership of values obtained from destructuring and the destructured object itself (what everyone in #13 couldn’t get to agree on): e.g. const { using x, using y } = expr; vs const using { x, y } = expr;. Taking ownership anonymously then becomes expressible as const using {} = expr;, no additional syntax required.

[rbuckton]

For now we're not allowing binding patterns with using do to the aforementioned complexities. Also, using applies to the entire statement, not individual declarations, otherwise you'd have to write const using x = ..., using y = .... It could be feasible to have {} = ... work for the exact token sequence { }, but there's too much of a chance for confusion since an actual binding pattern isn't allowed and I'd venture to guess that const {} = ... isn't a very common occurrence in JS code currently.

[ljharb]

otherwise you'd have to write const using x = ..., using y = ...

that might be an improvement tho - it's much more granular and explicit. (ftr, it's already generally considered a bad style to declare more than one variable on the same keyword - ie, only ever one const per const, etc - so i'm not sure how often people will do that anyways)

[rbuckton]

Its also important that the syntactic using marker is front and center in the declaration, given that it has action-at-a-distance side effects at the end of the block. This was discussed in the February, 2020 meeting in regards to having using value expr just be an expression, and determined that the possibility of burying a using somewhere in a complex declaration would not be advisable.

[ljharb]

"front and center" could be read to mean "near the identifier" over "near the const", but fair that it was already discussed.

[waldemarhorwat]

using const x = f(), (g(a, b()), y = h(c(), d(e, f), g));

Can you spot the problem?

[rbuckton]

That would be a parse error. The syntax in #56 specifies that the "bindingless" using const declaration is AssignmentExpression, so , is not legal at the end of (g(a, b()),.

[rbuckton]

You could do ((g(a, b()), ..., but then you're pretty much opting-in to unreadable code.

[rbuckton]

Also, as @ljharb pointed out, combining is generally a poor style decision, so you will more often see this:

using const x = f();
using const (g(a, b()));
using const y = ...;

However, this doesn't necessarily mean we should forbid the convenience of chaining multiple declarations:

using const x = f(),
            (g(a, b())),
            y = ...;

[rbuckton]

I'm not opposed to alternatives to (). I used () due to how it simplifies the specification text as opposed to a separate using value expr statement. I'm not partial to using const {} = expr; because it smacks of destructuring, which we've decided not to support for using const. We could, alternatively, do something like using const void = expr, which then "looks" like a variable declaration, but obviously isn't because void cannot be an identifier.

[waldemarhorwat]

That would be a parse error. The syntax in #56 specifies that the "bindingless" using const declaration is AssignmentExpression, so , is not legal at the end of (g(a, b()),.

Where can I see the formatted syntax in #56? It's just a jumble of patch files.

[rbuckton]

Where can I see the formatted syntax in #56? It's just a jumble of patch files.

https://tc39.es/proposal-explicit-resource-management/pr/56/

Specifically this section: https://tc39.es/proposal-explicit-resource-management/pr/56/#sec-let-and-const-declarations

[rbuckton]

For the upcoming meeting I am planning to use using const void = expr instead of using const (expr), though we can bikeshed further on syntax alternatives as necessary.

[hazae41]

Why don't we replace using const x = ... by just using x = ...

This would be more compact and be more clear given that using let x = ... shouldn't exist

This would also fit well with destructuration

using x = ...
using a = ..., b = ...
using { a, b } = object
using [a, b] = array