I think we just need a "use semicolons" parser switch that turns off ASI honestly.

i doubt anything that even tacitly encourages omission of semicolons will achieve consensus :-)

i'd not consider the state things are today to be immutable -- e.g., don't assume ContinuationPreservedEmbedderData and its current performance characteristics to be like, unchanging facts of the world forever and forever

yeah that's why it hasn't merged yet

i'd not consider the state things are today to be immutable -- e.g., don't assume ContinuationPreservedEmbedderData and its current performance characteristics to be like, unchanging facts of the world forever and forever

It's more like an existence proof that this technique isn't way too slow--I would've assumed the opposite before this had shipped.

yeah that's why it hasn't merged yet

ContinuationPreservedEmbedderData

Still not understand what is it 🤣

every variadic function makes TS team sweat...

i'd not consider the state things are today to be immutable -- e.g., don't assume ContinuationPreservedEmbedderData and its current performance characteristics to be like, unchanging facts of the world forever and forever

Justin Ridgewell: i just want to make the point that that argument is not strictly true, since V8 retains the optionality to become unhappy with the performance CPED as it stands today

Justin Ridgewell: i am responding to the argument that's repeatedly been put forth that this will not have performance problems because CPED exists in V8

I am confident that our process will produce a great solution here

petition to add iter as an alias for symbol.iterator on all built-in iterators

i don't think "i don't have an iterable" is a problem in practice

I have literally never seen that pattern in any code not written by you

also flat is problematic in ways that concat is not, wrt handling of non-iterable values

I remember the original draft don't allow prototype on shared struct values, now it's allowed but just omitted when transfer? Is my understanding correct?

i'd expect them to be an underlying implementation detail of some higher level thing

Not quite. If you want thread-local behavior, you must explicitly opt in and supply that behavior in each thread.

typescript certainly can't handle [].concat() at all, it's been a long standing open issue on the repo. that doesn't mean it's bad, it's just another gap in TS's ability to describe JS.

having behavior is. attaching it is just a style choice. functions can live separate from the data they affect.

https://github.com/microsoft/TypeScript/issues/47351 is the issue presumably

There is a lot of complexity to this. Attaching behavior is very important.

me hearing "just an ephemeron" just now felt like like most people probably feel hearing "just a monoid object in the category of endofunctors on C"

I don't understand this. Why is throwing on non-iterables bad?

I've been experimenting with this in TypeScript. I absolutely cannot use it efficiently without the ability to attach behavior, unless I use Proxy or completely duplicate our AST as regular objects for the public API.

i don't understand why x.foo() and foo(x) are meaningfully different in terms of capabilities

If you are writing a project from scratch, sure. If you are adapting an existing project, it might not be feasible.

I've been experimenting with this in TypeScript. I absolutely cannot use it efficiently without the ability to attach behavior, unless I use Proxy or completely duplicate our AST as regular objects for the public API.

i don't understand why x.foo() and foo(x) are meaningfully different in terms of capabilities

that's not a need, that's just difficulty adapting to a different style.

yeah just use a string

what global registry mistake? registered symbols are super useful

i think a great example is Symbol.for('nodejs.util.inspect')

same with global symbols

There have been several attempts to use the origin trial, which is currently data only, to adopt shared structs in existing projects. The feedback has been the same: Without the ability to attach behavior, shared structs require a complete rewrite of the project, including the public API, which is a burden that we would rather not enforce on the project maintainers, nor their consumers. That makes the feature unusable for projects that would sorely benefit from the capability.

what is the difference between thing = wrap(struct) and Object.setPrototypeOf(struct, ...)?

you want the entire AST to be shared structs?

Rust macros are magic ✨

if we just have shared functions of some form, we don't need the prototype hacks

infinitely nested iterators just don't exist at all, period

if they don't exist, then .flat(Infinity) is not at problem

The issue with using module blocks is that it means the worker has no access to the struct declarations until after they are received from the originating thread, which complicates startup.

How does source location work with eval?

How does source location work with eval?

Every eval call generates a new source location

the easiest would just be requiring the registration to use a very qualified name

We have also considered that. I suggested it as a mechanism to address the bundling issue.

We have also considered that. I suggested it as a mechanism to address the bundling issue.

yeah, exactly like symbols

yeah if you have main_thread.js and worker_thread.js, its kind of required i think

ye the ultimate key in the agent would be the name + the shape

yeah that's another thing, if you use fast dev mode (eval) your project will break lol

we can just revive domenic's proposal

it solves sharable code, not other things

Isn't that proposal essentially what module expressions/module blocks is?

mpsc is "single consumer" so in most cases it is a move operation (reuses the same memory)

I mean, the downside of this all is polymorphic usage sites, right?

So just bundle split?

this all feels like non-problems

chrome could just strip TS types in the console

repl goal needs

• sloppy by default
• supports redeclarable static import
• supports redeclarable let/const
• supports type stripping
• top level await
• ???

i... don't think i can ship that

msaboff: total strawman, but could your concern be mitigated by also standardizing the semantics of these type annotations, even if JS engines do not enforce these?

the queue is so full

No. There is nothing I see an implementation using TA's.

The impact is quite high, if we follow this route, we are effectively defining the grammar for types for JavaScript once and for all.

i mean if we have token soup we aren't defining any grammar for types

So what do you expect an implementation doing with TA's besides throwing them away?

So what do you expect an implementation doing with TA's besides throwing them away?

which is a pretty permanent thing to do when there isn't even a type system existing that can accurately describe the entire language.

A runtime implementation should do nothing other than to throw them away.

because I thought the answer was an obvious "yes" but maybe it's actually "no" and we're just demarcating a section to be ignored by an engine's parser?

I am with you, I have the same feeling, that finding a type system, that can actually define all of JavaScript's types might be difficult. Although there surely would be some kind of any wouldn't it? :)

it's the second thing definitely

So I think you agree with the comment I made that started this thread.

is the goal that in 10 years every TS user will write only the subset of TS which is legal ES?

Ok, let me rephrase the original strawman then:

• You do not like that a specific tool or set of tools is picked as the "blessed" syntax, I assume (please tell me if I am wrong) because we (TC39) as the body standardising the grammar, do not have control over how tools interpret this syntax, effectively delegating a large amount of syntax semantics to a different body (TypeScript / flow / whoever we "bless")
• I am suggesting this may be mitigated by moving the semantics that a static checker should interpret the syntax with into the scope of TC39, possibly into ECMA262. This way TC39 keeps this control
• Runtime implementations of ECMA262 will totally ignore these type annotations. The semantics, if we define them, would only be enforced by other ahead of time static analysis tools

Luca, I was only making the last point in my comment here.
I do have other concerns related to the first two points you list.

you do typechecks at devtime

Ok, thank you - I'd be interested to learn more about your reasoning for not liking that a specific tool or set of tools is picked as the "blessed" syntax, as that may help find alternative solutions

I don't like that TC39, an open standard, is blessing possibly one syntax when there are several other possible syntax options.

node could choose to strip types? but also, esbuild --watch is like

Well, browsers can strip types too

by slowing down parsing for everyone

Would it also slow down parsing for code not using type annotations?

we look at prior art, but not literally pick existing syntax

The advantage of "token soup" is that typed languages can continue to innovate within that space without requiring advancing a proposal through TC39 for what is otherwise just a comment.

The advantage of "token soup" is that typed languages can continue to innovate within that space without requiring advancing a proposal through TC39 for what is otherwise just a comment.

I wonder if there is some perf goal we could aim at. Such as "no cover grammar needed unless there is a token clearly introducing a type context"

but it would not let them do stuff like satisfies, etc

Again, these arguments generally would argue against Python's type annotations as well.

"runtime benefit" in my sentence is anything from engines using the type annotations to make code faster to simple string reflection

there are very few things in this space that wouldn't benefit from going through tc39

So what should an implementation do if the type is violated while processing? Throw?

Python also isn't shipped to me over the network every time I want to run it?

Mehhhhh the reflection barely matters if at all.

The advantage of "token soup" is that typed languages can continue to innovate within that space without requiring advancing a proposal through TC39 for what is otherwise just a comment.

i think one of the main challenges is how you can lexically indicate what the syntax is equivalent to - ie React.createElement, h, etc

yeah it would have to be pojo

i got bad news for you if you think JS is directly executed by the metal

one of the stated goals tho is "unfork the ecosystem"; "unfork" means 0 fork, not "less forked"

is bloomberg going to get rid of tools?

i am a little bit disappointed that we didn't get to discuss topics around in-browser devtools more

(i say that as a non-devtools representative)

bradley and i talking to v8 about devtools improvements in node is where the "repl goal" stuff came from

so let me try to summarize my thoughts:

• I agree there is would be some benefit for at least some projects, including both beginners and complex projects

• I am not convinced that in fact most people will be able to skip the build step: this proposal does not cover all of TS as-is, and definitely won't cover JSX

• and this proposal will constrain the growth of TS, e.g. no new satisfies-like keywords, which TS has wanted to add lots of historically

• the thing where you want to copy-paste code from your editor to the browser console is very real, but could be solved just in the browser console

• the grammar in this proposal is massive, which will be a lot of work (and runtime cost) to implement, reason about, and maintain

• given all that, the costs do not seem worth the benefits, to me.

what if the binast was s expressions, and it had 4 primitive types and a small memory buffer, and used a harvard architecture...

decmath${price} + ${tax}

we should just have primitive decimals, this makes no sense

it's pretty important to focus on this part now, i think

Then we wouldn't have ES262.

(it was more fun before editing, because the ES262 spec is statically typed 😛)

IIRC there are still concerns about using IEEE 754 at all

so let me try to summarize my thoughts:

• I agree there is would be some benefit for at least some projects, including both beginners and complex projects

• I am not convinced that in fact most people will be able to skip the build step: this proposal does not cover all of TS as-is, and definitely won't cover JSX

• and this proposal will constrain the growth of TS, e.g. no new satisfies-like keywords, which TS has wanted to add lots of historically

• the thing where you want to copy-paste code from your editor to the browser console is very real, but could be solved just in the browser console

• the grammar in this proposal is massive, which will be a lot of work (and runtime cost) to implement, reason about, and maintain

• given all that, the costs do not seem worth the benefits, to me.

so I worry that a lot of people are experience "compiling with typescript is painful" and assuming that types-as-comments will fix their problems, when those are in fact different problems

I mean the idea that types annotations is the panacea

Decimal("1.2") is so obnoxious vs 1.2m

How do you feel about syntax for decimals but not primitives? Like regexs

Jack Works: I mean, it doesn't need to be. We can define it to not require the new. ^_^

1.2m !== 1.2m will trip everyone up forever

1.2m !== 1.2m clearly just make valueOf throw, can't do it then.

1.2m !== 1.2m clearly just make valueOf throw, can't do it then.

I was just half-jokingly saying that having the equality test throw would avoid people accidentally relying on it being always-false.

Making === throw has the same perf impact as making it work properly: you have in both cases exactly one more branch

consider https://en.cppreference.com/w/cpp/language/noexcept_spec

ah, I don't know for sure. I expect that many of the random developers who are excited about the proposal are excited because they think it will fix their problems, but their problems are in fact other things like ESM or whatever..

try ts-node, ts-node can configured to skip type checking and even use swc for transpile

Also saying use deno and tsnode is basically making the argument that the expected DX is for the JS environment to strip / ignore types. I'm just asking for that behavior to be standardized

sffc: PLEASE, I beg you, read https://speleotrove.com/decimal/decifaq4.html#signif

(imo the reason bigint doesn't get used is because it doesn't interop cleanly with Number, which is a mistake Decimal needn't repeat)

number → decimal at least, even if not the other way

2.6m?

dminor: did adding bigint slow down every JS program?

sffc: So you're expecting that new Decimal("1.0") and new Decimal("1.0000") would produce the same results when participating in any arithmetic expression?

Adding a new primitive meanings adding a new branch for dynamic dispatch based upon type, so it will slow things down, I can't say whether it was a measurable difference for BigInt or not, but adding a primitive has the potential to slow down existing programs, not just things that use the new primitive.

sure. but this concern wasn't brought up for BigInt, so how is Decimal any different?

the implicit conversion would have to go number -> mathematical value -> decimal

2.6m? or whatever number 1.3 actually is, converted to decimal, added to 1.3m

we definitely use mathematical values all over the spec

I assume there's something corresponding to that within engines

re: string.prototype.decimalAdd()

this sounds like coloring strings in some way? especially for typescript, you'd have to have some sort of colored string to make this not suck

What would be the proposed representation of such an intermediate mathematical value? Number and Decimal have different significant digits and exponent ranges. Number is inexact for decimal values. If we had such an exact mathematical value, we'd use that for Number.

if this proposal means TS makes it easier to color strings, I'm all for it!

if this proposal means TS makes it easier to color strings, I'm all for it!

so I think a big disconnect here is the purported benefit is node users, but the cost is imposed on browser vendors and users of webpages

Our programs should be able to run on a multitude of environments, including browsers and non node/deno based "server" environments. That's the benefit of standardizing this in the language.

I'll go back to my argument, why do browsers not require that code they execute be in the form of binary AST.

i mean mathieu's and msaboff's questions

i fail to see how "an infinite iterator of empty tuples" is a logical option but k

i don't like the idea of being forced to wrap multiple iterators in an iterator just to zip them, which is why i want varargs or an object

i don't understand what zipWith means, i should have paid better attention i'm sorry

do you also not like the idea of being forced to wrap multiple promises in an iterable just to await all of them?

Iterator.zipWith(Math.max, a, b, c)

the thing you asked for was the varargs version, which is not like an object literal

I think it's easiest to understand zip as transposing an array of arrays, fwiw.

I think it's easiest to understand zip as transposing an array of arrays, fwiw.

i don't understand what this does

in this case there is no intermediate array tho, because of iterator helpers? it's not like Array.from

it just lets you skip making an intermediate array for results and instead immediately passes them to a function

I wonder how about using methods like it1.zip(it2).zip(it3) instead of function like Rust does.

it just lets you skip making an intermediate array for results and instead immediately passes them to a function

Yeah this sounds useful but is zip the right name, or map? maybe zip should just take the iterators, and not a function, and you use map if you have a function

so it may not be worth having a new method solely to allow you to skip some intermediate objects...

sure but variadic map is probably also ergonomically motivated (just it'd be a weird name for zip itself)

either way as long as prototype.zip exists and does the normal thing i'm fine

like "use this value to fill out the shorter one"

kwargs

why does the bytecode not rewrite itself into a direct lookup once it observes that the slot is initialized

why does the bytecode not rewrite itself into a direct lookup once it observes that the slot is initialized

danielrosenwasser: re: "we assume the runtime will catch it" - does that mean your type analysis treats let and var differently?

is it difficult to figure out that a variable is not referenced inside a closure, and also not referenced prior to the declaration?