the authors' copy of the soon-to-be RFC 9557 🎉

https://www.rfc-editor.org/authors/rfc9557.html

for (using is of and [not/a+"/g]; b++; [/"/g, 5])

sent a file.

the instance would still be sealed ofc

correlating every class is way too much overhead.

the wrapper class could be defined lexically inside the shared struct, or you could just define method syntax directly inside the shared struct definition and the semantics would be that shared struct methods are copied

this is a sidebar but it would be nice if we could structuredClone symbols in a coherent way (i.e., such that if you send the same one over twice, you get the same value)

this is a sidebar but it would be nice if we could structuredClone symbols in a coherent way (i.e., such that if you send the same one over twice, you get the same value)

I've been told that this would be too troublesome to implement

you can do it in userland if you patch postMessage / the message event / structuredClone and stash symbols in a weakmap

littledan: Maybe doesn't matter, but I prefer the term ConcurrentMap to SharedMap. Just because a map is shareable does not mean it can be used concurrently by multiple threads. A true concurrent map uses lock-free CAS mechanisms to allow for concurrent reads and writes.

I've been told that this would be too troublesome to implement

you can do it in userland if you patch postMessage / the message event / structuredClone and stash symbols in a weakmap

SharedStructs are in someways finite (and eternal), due to source text location ?

How is it so much more troublesome that sharing an instance of shared struct SharedSymbol {} ?

keith_miller: I have previously advocated for a manual correlation over postMessage, but apparently the DX of that is not acceptable, and prevents some use cases that I don't fully understand

I'd really like to see these use cases enumerated, because it seems to me like explicit handshaking in which e.g. a reference to the shared struct is exchanged constitutes a more comprehensible and robust pattern

let ready = false;
onmessage = evt => {
  if (!ready) {
    ready = true;
    correlate(localStructDef, evt.data);
    return;
  }

  assert(Object.getPrototypeOf(evt.data) === localStructDef.prototype);
  …use evt.data as an instance of the shared struct…
}

There's only a small handful of bundlers in common use, and they're all maintained by specific individuals who you can talk to, so I don't want to design a feature on the assumption that bundlers will not be writing careful handling

Private state can only maintain its privacy if you can ensure the same encapsulation exists in both realms.

Wouldn't they be different types? With different private names?

ryzokuken / Chris de Almeida : Will we have time for the extractor continuation?

unfortunately Ron wants to add Symbol.dispose to existing things, which do not follow any naming convention

It's too bad that this proposal doesn't give strong enough guarantees to let us use it for AsyncContext

I'm not sure I understand why adding strict enforcement will bifurcate the ecosystem. resource management doesn't exist currently; code wanting to use resource management needs to port, so why would strict enforcement be a burden that hinders adoption?

why is it not sufficient?

I think it means, if some transpilers/browsers ship the initial using semantics, and others ship the later semantics, then it's harder to start shipping APIs using strict enforcement (since it's not enough to check whether the syntax exists, you also have to check that users are updated)

that's the breaks of stage 3 though?

you can just call enter and not call dispose, so you'd have unbalanced use of the stack

Calling enter is an explicit action the user takes. They are opting out of strict enforcement, and thus must ensure they do the work themselves.

We agree that if a user does this, their code is buggy. I don't think that's in discussion. But some use cases need something stricter

Without a compiler or type system, I'm not sure something stricter is entirely feasible in JS.

you can just call enter and not call dispose, so you'd have unbalanced use of the stack

We agree that if a user does this, their code is buggy. I don't think that's in discussion. But some use cases need something stricter

I mean, I'm trying to understand how bad the burden of mandatory enforcement would be? I expect the vast majority of the potential future users of this feature have not ported their code yet (or written it, for that matter)

Do we want to allow that to effectively pollute the caller's scope, switching the current context at their function from under their feet? That's something the current AsyncContext proposal explicitly avoids doing

are we conflating two separate things? I don't think "true strict enforcement" necessarily means a mandatory [Symbol.enter]

A magical mechanism doesn't work with DisposableStack and wouldn't allow user-defined resource management building blocks.

Agree, mandatory use of enter is necessary.

Mandatory enforcement is a concern for API bifurcation. In general I don't believe mandatory enforcement is necessary, API producers should be able to opt-in or opt-out of enforcement, as should API consumers.

I think I need more context.

i'd expect there to see

let Foo(
  long extractor pattern
) = RHS

Did Extractors advance to Stage 2? I wasn't clear if all blocking concerns were withdrawn.

I wish we required you to start your arrow functions with a ^ or something

backslash surely

It sounded like the cover grammar complexity might not be blocking, but the NLT issue is still a concern.

but as long as we say that extractors are only an identifier followed by a no-newline (, then i think the problem's solved?

It sounded like the cover grammar complexity might not be blocking, but the NLT issue is still a concern.

(parenthesized assignment LHS's are gross also)

@shu oh, it hasn't been merged because CI is failing due to you not adding them in the correct order

i'm confused, isn't the parity supposed to autoupdate with the counter?

but 2 isn't odd

I'm confused is this some mechanism where at closure time we detect the captured variable is a Signal?

what about signals that aren't unconditionally read in the computation?

Their changes don't matter until the condition that made them unread changes?

I don't understand how we would know that parity doesn't need to be updated in general

I'm not sufficiently familiar with signals usages, but I'm wondering if there would be ways to implement this auto tracking without making this internal contextual state observable

Seems like this could be done with weakly held pub/sub events rather than a global variable.

this sounds like perfect incubation call material

Could there be a registry for each batch of signals that's not an hidden global value? Not sure if that would be possible or cause other problems?

This is large enough they need a dedicated group call

if you create the computed by providing all the signals it cares about explicitly, then you wouldn't need any global state, i think?

This ruins a good amount of the ergonomics of this feature

It’s all on the Signal

but if the ergonomics are only achievable with weird unenforceable caveats like "you must evaluate all signals unconditionally, in the callback" - like react has for hooks, i'm not sure it's worth striving for them (i dont think that's the case, to be clear)

I’m confused by the global state discussion, there shouldn’t be any.

but if the ergonomics are only achievable with weird unenforceable caveats like "you must evaluate all signals unconditionally, in the callback" - like react has for hooks, i'm not sure it's worth striving for them (i dont think that's the case, to be clear)

From what I understand it's used for auto-tracking and preventing notify footguns

i'd love to hear how a computed callback of one.get() ? two.get() : three.get() can deterministically track all three signals

i'd love to hear how a computed callback of one.get() ? two.get() : three.get() can deterministically track all three signals

i'd love to hear how a computed callback of one.get() ? two.get() : three.get() can deterministically track all three signals

But the state is stored on the Signal itself

ok, so the list of tracked signals potentially shifts over time?

ok, so the list of tracked signals potentially shifts over time?

but it's ambient during signal computation, which is currently exposed to any user code running during that time

It’s the same as an AsyncContxt.Variable.run() internally in a computed() call

wouldn't the Computed strongly hold the signal in its closure?

My concern is how a Computed interacts with a weakly held Signal. Does it then strongly hold the Signal? that seems leaky.

Not quite, there are APIs that effectively expose the acVar.get() value

ok, so the list of tracked signals potentially shifts over time?

though, a weakRef is kind of a scary thing to use in a signal - it's a thing whose state can change which is not being read via a Signal

Internally the Signal can access the ambient Computed context’s var, but that’s not exposed?

it appears we lost the transcriptionist

See things like currentComputed() and notify guards

So what can a Signal hold? How do we stop people putting something whose values can change unexpectedly?

So what can a Signal hold? How do we stop people putting something whose values can change unexpectedly?

I have a very mild concern over the name Signal. It could be conflated with AbortSignal. Many years ago it was indicated that WHATWG planned to eventually make more things called Signal that likely weren't this.

I have a very mild concern over the name Signal. It could be conflated with AbortSignal. Many years ago it was indicated that WHATWG planned to eventually make more things called Signal that likely weren't this.

it appears we lost the transcriptionist

whisper transcript (linked on reflector) is still going

I find it interesting that signals are gaining so much popularity right now, given that knockout existed

whisper transcript (linked on reflector) is still going

(not suggesting that as a name, "dependency" has an overloaded meaning in JS already)

PropagatedValue and PropagatingCalculation?

Yeah, but it is an omnipresent term in userland today, and always meaning something similar to this. A different term would be more confusing I think

If we had a native event mechanism, would we need Watcher?

I think the important part of Watcher, vs events, is that is that signals are designed to be lossy. If you were to write to a signal multiple times, we'd only really care that the signal is dirty and when we get around to scheduling an update from the watcher we get the latest value. The intermediate signal state values wouldn't be important as we only "pull" the latest value when we're interested in it, vs being notified everytime a signal changes.

however... it implies that the watcher is forever, no?

What bothers me about "why not use an event" is that it implies a bunch of noise around the usage pattern when a much tinier pattern actually works. This is probably also why we keep getting more of these things.

Does that characterize your position correctly?

`Watcher` is in someways like `FinalizationRegistry`, where its core purpose is to be notified. So taking a single callback as a constructor argument maybe does fit this pattern well. As opposed to EventEmitters which are fan out to a changing N

`Watcher` is in someways like `FinalizationRegistry`, where its core purpose is to be notified. So taking a single callback as a constructor argument maybe does fit this pattern well. As opposed to EventEmitters which are fan out to a changing N observers 

Side question: How much of the Signals proposal is actually Signal/Computed vs Watcher? In other words, is Watcher the building block that both Signal and Computed are built on?

No, it's not

The Watcher is more like a Sink than an Emitter. And has a different set of responsibilities 

This is a fair point. I have to think more about my concerns and whether I might still consider them blocking for stage 2. Either way, I still think it is unfortunate that we might have this and yet still be missing events.

Maybe it is, but Signals, Observables, Promises, and Events all belong to a similar category of observation mechanisms, even if they fill out different quadrants.

I'm pretty open to filling out the table. Some formal-ish observations: Signals facilitate discrete updates, are pull-based, and have a lot in common with the incremental computation academic space

Can setting a signal trigger a UI update? If so, it's also push based.

You can call this a "push" but it's not really what people mean when they talk about "push-pull" models

To the runtime, & is more like a syntactic transformation, so the signals example ends up treated as something roughly like this:

const ref_mut_counter = new Signal.State(0);
ref_mut_counter.value; // 0
ref_mut_counter.value++;
ref_mut_counter.value; // 1

const ref_cnst_parity = new Signal.Computed(() => ref_mut_counter.value % 2 ? "odd" : "even");

I had to suddenly switch back to work-work -- sorry for disappearing mid-convo :)

That's pretty much how Svelte 5 works with signals. We don't actually expose Signal objects, instead they're hidden away by the compiler.

let counter = $state(0):

counter++;
console.log(counter); // 2