For me it’s also that the bot is slower than the stenographer. For me to be of any use taking notes I have to add a 5-10 second delay to my audio. Which further means I can’t interact with what is happening.

the accidental use case would need to be from someone's disposal callback, so it'd only come up if you did using x = {[Symbol.dispose]() { /* variable which is closed over that is also a using binding */ } };

moving it back into tdz is super weird

I would be opposed to a timebox extension to discuss things we are not even considering at the moment

those languages don't create closures nearly as often

what is the new tdz, i missed it

well, IMO this error should be given to you by the file implementation

for example { using x = y(); myArray.forEach(() => thingWith(x) }) } this is valid

it would be nice if it did but I don't see why we want the language to do that for you?

there are two competing mental models here: 1) using being about single-use, and 2) using being about registering functions to call on lexical scope exit

function f() { let x = 3; return () => x; }; f()(); is 3 == why would "using x" be different? I'm missing something somewhere. Is KG saying "x" should become undefined after its dispose is called?

function f() { let x = 3; return () => x; }; f()(); is 3 == why would "using x" be different? I'm missing something somewhere. Is KG saying "x" should become undefined after its dispose is called?

i'm really not sure when i would want to use this without the tdz

This is a naive question:. Would it not be possible to throw on capturing the using binding instead of a TDZ?

you can only using a revocable proxy, and disposal revokes it :-p

The discussion we had is that we would like to see more evidence as to why try/finally is not adequate to solve these use cases

The discussion we had is that we would like to see more evidence as to why try/finally is not adequate to solve these use cases

it kind of seems like something that'd be web compatible to disallow, since it'd be unlikely someone ships that code

The discussion we had is that we would like to see more evidence as to why try/finally is not adequate to solve these use cases

so here's a use case where i don't want tdz: recursive mutexes. to be sure, it's expressible even in the case of a TDZ via additional aliasing but that is not something i want to type.

my intuition here is that the usual extreme badness about closing over stack-lifetimed variables is memory safety, which is not the footgun here. so my expectation is that most objects would throw at runtime in some way after being disposed of anyways, instead, for example, accessing random memory. if TDZ throws a runtime error, i expect that to be net the same effect, except with extra implementation burden (at least the investigative portion, if not also the implementation complexity portion)

Could we have an example of reusing so I can understand it more easy? thank u!

so in those case you aren't... reusing the binding

As far as binding reuse, the example is not much different than the example in your issue:

{
  using x = foo();
  cache.set(x.url, data);
  ...
  setTimeout(() => cache.delete(x.url), 100);
}

that seems like it is a mistake - you're using x after it's been disposed. it seems like the language should prevent you from doing that.

Not if x.url isn't related to the memory/native resource/etc. that x is holding.

it is this proposal mechanically via an object method?

it is no more mutable than const is.

so here's a use case where i don't want tdz: recursive mutexes. to be sure, it's expressible even in the case of a TDZ via additional aliasing but that is not something i want to type.

my intuition here is that the usual extreme badness about closing over stack-lifetimed variables is memory safety, which is not the footgun here. so my expectation is that most objects would throw at runtime in some way after being disposed of anyways, instead, for example, accessing random memory. if TDZ throws a runtime error, i expect that to be net the same effect, except with extra implementation burden (at least the investigative portion, if not also the implementation complexity portion)

wouldn't this be using mutex.lock() not using mutex?

again, i contend, the existing intuition that we need TDZ and the footgun is bad is because RAII is mostly used in languages in conjunction with stack-lifetimed bindings, so memory safety becomes an issue

but why is that a reason to run code associated with a particular binding?

because JS is OO and i also prefer to associate state with my code instead of making new closures, since chances are it's already structured with objects with state?

static analysis can't solve this unless it gets a lot better

scala is not a language I would hold up as an example of a mature and cohesive programming language

yeah I just thought it was funny to introduce the feature by talking about scala and then say the goal is cohesiveness

Kris Kowal: are you saying JS is a language for short kings

wait who says calls can't be the target of an assignment?

HE Shi-Jun: depends on the reference returned by the call

I can't write an ECMAScript function that returns such a reference but there can be host-provided built-ins that do

I can't write an ECMAScript function that returns such a reference but there can be host-provided built-ins that do

I think this has caused miscommunication in the past; maybe we need other ways to refer to this

someone mentioned the epic

tc39 hats for note takers

if Object.freeze(), does that mean it can't be do brand check?

there isn't, i think jordan is saying boxed primitives are important from his experience, so even if this isn't a boxed primitive, he wants the provenance to be programmatically discoverable

how have i never noticed that == fails on null proto objects

The ecmarkup lint capabilities are getting quite nice, maybe one day it will be a full language server!