stray thought: we've long said that the ratio of readers to writers of code is high, so we should prioritize code being easy to understand over code being easy to write. LLMs make that dramatically more true: for a lot of code the ratio is now literally infinite, i.e., there is no one who wrote it, and just people who are reading it. so it is more important than ever that code be easy to understand.

this is to say, I am increasingly convinced that if (let x = ...) { } else { x } should be an early error, so that this code cannot be written, and thus the only cases that any reader of code will ever encounter are completely unambiguous.

Doesn't this mean the AI's naive assumption is the most natural? I see this and assume the x is available within both.

I think what's increasingly confusing is only using's scope. Just ban it. If you want to auto dispose, do it within the if body. if (let x = …) { using _ = x; … } else { x }.

Why would it ever refer to an outer scope when there's a inner scope that defines it?

I think that applies whether you're reading or writing.

In the U.S., it is legally defined as 2,150.42 cubic inches or roughly 1.25 cubic feet (about 35.24 liters)
the U.K. bushel is slightly larger, defined as 2,219.36 cubic inches (about 36.38 liters)

Representative sample of the issue: Express.js/path-to-regex (8.6k stars on github) removing regex support entirely, due to ReDoS:

For version 8, I've removed regex features. I know this is a huge pain for users of the library and apologize in advance.

side note, there's a slightly easier way to export module-scoped access to private fields than what was in the slide (but still I'd prefer private declarations)

let myField;
class MyClass {
  #myField;
  // ...
  static #exportedMyField(instance) {
    return instance.#myField;
  }
  static {
    myField = MyClass.#exportedMyField;
  }
}

> s = Symbol()
Symbol()
> m = {}
{}
> Object.defineProperty(m, s, { value: 1, enumerable: false })
{}
> Object.getOwnPropertySymbols(m)
[ Symbol() ]
> Object.getOwnPropertyDescriptor(m, s)
{ value: 1, writable: false, enumerable: false, configurable: false }
> m[Object.getOwnPropertySymbols(m)[0]]
1

What I was going to say, in case it triggers any useful ideas:

Similar concerns as eemeli . Without this being first-class there are too many open questions about how these behave. E.g. Object.assign(), Object.defineProperty(), exports etc.

But the motivation seems clear, many authors already use symbols that way and the fact that they are exposed via getOwnPropertySymbols() is a surprise to some. But like eemeli , I do wonder if we need a whole new primitive for this however.

First, is lexical scope actually part of the requirements? Or just the ability to assign properties that are not visible to the outside unless explicitly shared, essentially like a more ergonomic version of the weakmap pattern?

Seeing the slides my mental model was that this looks a lot like symbols with
(a) more ergonomic syntax, that
(b) cannot be accessed via the usual ways of accessing symbols

I wonder if it would be expressed in those terms, then it becomes predictable and the semantics fall directly out of that. Exports work, etc.
With a new descriptor, it could be completely decoupled from syntax and even be applied to string properties too. Then #foo is only syntactic sugar to create and register such symbols that automatically have the right descriptor (just like symbols are automatically enumerable: false)

really? how would we catch

private #foo
class NotFoo {}
f = new NotFoo()
f.#foo

I think it'd be weird to have this:

private #x
class A { static #x }
class B { static #x }

Where the visibility of A.#x and B.#x are both affected by the private declaration. It would be much clearer if the visibility of A.#x and B.#x were defined separately, with syntax immediately adjacent to their definitions as class fields.

So maybe this?

class A { static outer #x }
class B { static outer #x }

If this is an error

private #x;
class A { #x; [#x]; }

then it's not a big stretch to my mind for

private #x;
class A { #x; }

to also be an error. In which case, why do we need another keyword, just use #x as-is to refer to the outer scope. (admittedly, this is a bit of a straw man, since I don't think the first block should be an error, and I'd rather get more clarity on what exactly the scoping and shadowing rules are)

In particular

private #x;
{ private #x; }

Is this allowed? It seems equivalent to

class Outer {
  #x;
  static { class Inner { #x; } }
}

which is definitely allowed currently.

The double initialization error already exists:

class Base {
    constructor(o) {
        return o;
    }
}
class Sub extends Base {
    #x;
    constructor(o, v) {
        super(o);
        this.#x = v;
    }
}
const o = {};
new Sub(o, 1);
new Sub(o, 2);

VM433:7 Uncaught TypeError: Cannot initialize #x twice on the same object
    at <instance_members_initializer> (<anonymous>:7:5)
    at new Sub (<anonymous>:9:9)
    at <anonymous>:15:1
<instance_members_initializer> @ VM433:7
Sub @ VM433:9
(anonymous) @ VM433:15

specifically I am proposing

class A {
  #x = 1;
  static factory() {
    return { [#x]: 1 }; // makes objects which are not instances of A but have `#x` anyway
 }
}

next time I come back it will look like

private #x
class A {
  with #x = 1
}

or something, instead of trying to re-use computed member access syntax

and of course similarly for objects

private #x;
function factory() {
  return { with #x: 1 };
}