re: waldemar's point, I agree that more general async dataflow would be great, and is something we should explore, though I think I'd still want this proposal for simple case

In TS I'd just do two-token lookahead in +Await

and await using without a binding list is unaffected?

is there anything we need to do to get Decimal on the overflow, or will it be taken care of?

ljharb: I made some slides just for mark, if we have time tomorrow, PTAL: https://docs.google.com/presentation/d/1s1IZSo24JpMsI_NponP8vvIKUazld62lcleKF976Ppc/edit?usp=sharing

note the changes would need to be more substantive for dealing with v-mode, which has a wider set of reserved punctuators and semantics for doubled punctuators (https://github.com/tc39/proposal-regexp-v-flag#how-is-the-v-flag-different-from-the-u-flag and https://arai-a.github.io/ecma262-compare/snapshot.html?pr=2418#prod-ClassSetCharacter )

If there's a chance we want RegExp.escape to always remain stable, it may be worth going over the RegExp syntax investigation I did at https://rbuckton.github.io/regexp-features/features/ to ensure we're future-proof against other syntax we may choose to adopt later. Though, I admit that's not a completely exhaustive list.

For example, we may never do recursive matching, but it still might be a good idea to escape & (used in (?&name) for recursive named capture group matching, and (?(R&name)A|B) in conditionals to test for recursion of a group).

the list of reserved punctuators already includes #, so it would be escaped also, which would cover x-mode line comments too, thankfully

I'm kinda tempted to just say it escapes every ascii punctuator except _, since I've listed I think all of them except the two quotes and backtick at this point

PCRE also uses `, ', ", and % for callouts.

re: future constraints, this does mean that we're committing that backslash + punctuator is only ever going to mean the punctuator, but that is I think a good limit to impose

Sorry, by "no" do you mean "no one uses backslash + punctuator to mean anything other than the punctuator"?

chairs, am i still up first today? if so i'll be about 2-3 mins late

wait, at what stage is shared structs?

Maybe this is just me, but the name "isolate" shouldn't necessarily guide the direction of the language /s

at stage 1 the proposal name should describe the problem, and "shared structs" seems like a solution to me

You could make the assigment assign the SAB backing store into the shared struct, and then make the property access on the SAB create the JS object on demand - but that sounds slow and ugly and likely difficult to integrate

the inability of SAB to point to JS values (with cycle collection) is a fundamental limitation. This is why I like how shared structs do not include the ability to be backed by SABs--it would be a completely different thing.

it would probably be helpful to look into the experience in Node.js, where this feature has long existed without such support in yield. Has this led to bugs? We should be able to find out.

No one uses yield so it doesn't come up

shouldn't this show up in generators all the time?

dumb question: there is no chance that "context" will be confused with the decorators context? Asking because I just heard context so many times and got reminded that it can be kind of meaningless because it can mean anything. Totally not a blocking concern but wondering if anyone else had the same thought

dumb question: there is no chance that "context" will be confused with the decorators context? Asking because I just heard context so many times and got reminded that it can be kind of meaningless because it can mean anything. Totally not a blocking concern but wondering if anyone else had the same thought

I would be OK with a yield.nocontext or something I guess

I would be OK with a yield.nocontext or something I guess

A number of languages with an AsyncContext-like mechanism also have some mechanism of explicitly affecting async flow control.

The thing is, an AsyncContext instance is more like a single variable

That's the problem. In the cases I'm concerned with, the generator is provided by the user to a third party library. You want the library to handle the complexities involved with async context flow control, not the author of the genrator. You want them to not be concerned about choosing which yield variant to use.

so, "the generator is provided by the user to a third party library" seems like exactly the case where we want yield to preserve state. taking the example from the readme:

  libraryTakingAnIterator(context.run('id', function* () {
    log('starting');

    yield 0;

    // if the library `await`s before resuming, we've lost our id
    log('done');
  }));

Maybe we should say that any library which consumes iterators in this way needs to juggle contexts properly? but on the other hand it's not clear to me how that's even possible here - how would the library ensure that the second half of the generator runs in the correct context?

Hmm. that example feels odd to me, since execution for the generator doesn't actually start until you call .next(). That said, I'm fine if context propagates over yield if we have a mechanism to affect async flow control.

Andreu Botella: in blink as well? any benchmarks in mind?

i.e. assume this API exists. what does code using it look like, concretely, that would run if it were in the language

littledan: it can't be just "welcome", i'm asking how andreu plans to "see performance"?

but that thing is set by the embedder in a very bounded way, in a way that V8 folks aren't 100% happy with anyway

Yeah it'd be great to have a name brainstorm here (in an issue, not during plenary). https://github.com/tc39/proposal-async-context/issues

so, "the generator is provided by the user to a third party library" seems like exactly the case where we want yield to preserve state. taking the example from the readme:

  libraryTakingAnIterator(context.run('id', function* () {
    log('starting');

    yield 0;

    // if the library `await`s before resuming, we've lost our id
    log('done');
  }));

Maybe we should say that any library which consumes iterators in this way needs to juggle contexts properly? but on the other hand it's not clear to me how that's even possible here - how would the library ensure that the second half of the generator runs in the correct context?

We don't have notes of current topic?

It's lunch, not an official presentation

shu: Chengzhong Wu and me are going to prototype a V8 implementation to see performance and integration with task attribution

I may be a minute or two late getting back. My dogs need a bio break and don't care about the plenary schedule.

my hope goes with you

Worth also noting is that node is already eating performance with usage of AsyncLocalStorage, my apps are losing native async/await performance due to my need to polyfill

the hard line is "no speedometer regressions"

does anyone have a link to these slides?

that abseil thing exactly characterizes where the interop argument falls down when you tug on the chain

v8's position is there is no good reason, and certainly not on the web

it's "where you think you should be using nanoseconds, you are fooling yourself with the extra precision, with very few exceptions"

yes, and we don't have consensus on it anyways

except where law/regulations say they must be passed around... it's not about philosophy, but about preventing foot guns when moving values from one system to another through js

first of all, postgres is ms precision?

no, everything now uses ns

hm https://www.postgresql.org/docs/current/datatype-datetime.html

there is an extension that allows up to 9

justingrant: thanks for doing this! Literally just starting the 2023a firedrill right now... :D

how do people feel about parameter decorators

something i do want is the ability to mark constructor arguments as automatically stored in a public, or private, field. but that could be done potentially with a class decorator, i suppose

how do people feel about parameter decorators

how do people feel about parameter decorators

Could that class decorator know the name of those constructor parameters?

how do people feel about parameter decorators

They are very commonly used in code I have touched over the last few years. I think the code would have been significantly more complicated without them.

parameter decorators, or something else in this space, are definitely part of the program of, "how do we find a standard, unified way to solve all of the problems that people are widely doing through language extensions"

as a general philosophy i do not want more and more metaprogramming needing to be supported at runtime

It seems if we have class decorators, people eventually would ask for "decorate everything".

I am explicitly opposed to solving all of the problems that people are doing through language extensions

I have the exact opposite experience

NestJS has some very nice usages, fore example the @Param decorator in route handlers: https://docs.nestjs.com/controllers

@Get(':id')
findOne(@Param('id') id: string): string {
  return `This action returns a #${id} cat`;
}

DI is the canonical example of hidden magic ime

more generally this all strikes me as optimizing for the author

??? isn't this sort of a core goal of programming language design? Like, if it's at the expense of the end user (e.g., for performance), then that's bad, but all else being equal, we do want to optimize for the author?

imo we want to optimize for the person reading/maintaining the code after the author produces it

that's a far more frequent and important audience.

counterpoint: that's often the same audience

and?

JS also is in a position where a ton of people come to it from different languages, and they write lots of code that matches the idioms of their source langs that does NOT match JS idiom

I do have to admit that, with decorators evaluated at class evaluation time, they are sort of a better fit than extractors/pattern matching evaluated each time the function runs.

validation checks i 100% agree - that's not the same thing as the extensive metaprogramming demonstrated in the preso

maybe all the Daniels were confused

the function returned by the decorator does run each time, so a bit like a cached extractor

sidebar: this is I think way too much detail for a stage 1 presentation

sidebar: this is I think way too much detail for a stage 1 presentation

sidebar: this is I think way too much detail for a stage 1 presentation

but if not show many use cases people will refuse it because of no enough use cases??

naive question: can you "just like" parse the parameters of the toString()'d original method in a method decorator, and... use that?

Does anyone else get a strong "corporate java project" vibe from the code?

I mean I think DI is a very divisive programming technique? but IMO we should separate "this proposal would enable X footgun" and "this proposal would enable X programming technique that I don't like"

but I don't want people to use that technique in JS and would actively oppose features which enabled it (though, of course, that ship has sailed)

I'd say there are frameworks heavily based on that, and also frameworks for the same purpose not using this at all. You probably won't get happy working in a team that loves using these techniques, but that team would find ways of doing so either way - so why not make it easier for them? It will not eradicate the option of working without these features.

the "that technique" in the bit you quoted was "constructing code at runtime and evaluating it"

but I don't want people to use that technique in JS and would actively oppose features which enabled it (though, of course, that ship has sailed)

that would be extremely weird

something i do want is the ability to mark constructor arguments as automatically stored in a public, or private, field. but that could be done potentially with a class decorator, i suppose

Ashley Claymore: I would love if calling Promise.all({ foo: bar }) just worked like MM suggests

I agree, yes the ship has sailed. I would accept JS never have decorators, but if we already have class decorators, it's wrong to me to not having function decorators, param decorators, etc.

Oh it was closed, could champion reopen that ?

to be fair to Ron, this is 9 years coming; this is very thought out even if we are having a hard time processing it all at once.

Decorators are ultimately about targeted/declarative meta-programming. Without them we'd have no way to ergonomically metaprogram over class fields (and before accessor no way at all). Is it not in scope to metaprogram in a similar way over parameters?

I think bakkot's point is also spot on. Java has an overuse of classes for everything, and this is shoehorning a bunch into functionality into classes because we want it to be class method param decorators

i don't even like DSLs!

I haven't really seen this in 8 years of this feature in TS. It may happen, but certainly not frequently.

tagged template literals sailed too!

what do you mean by metaprogramming? those constructs you listed are not metaprogramming

I've had other proposals fail to advance explicitly because of a lack of sufficient real world examples, so I may have overcorrected a bit...

if you are reflecting data as data, i don't consider that metaprogramming

I guess in that there is no way to do this in C++?

struct S {
  int a;
  int b;
};
S* s = new S();
const char *fieldname = "a";
s->[fieldname] = 5;

although, now that I think of it, you can do it in C++ with offsetof and/or template parameters

and to evaluate the manipulated new data as code

this isn't part of the proposals though, right?

justinfagnani: e.g. the proposal in its current form exposes the names of parameters, which thus far are purely code rather than data except in terms of f.p.toString

i don't think it's reasonable to consider strings code?

I guess in that there is no way to do this in C++?

struct S {
  int a;
  int b;
};
S* s = new S();
const char *fieldname = "a";
s->[fieldname] = 5;