was Mark asking, "is it important to have this capability outside of pattern matching"?

So it always returns an array, or false on no match?

In loose mode only

lol what is loose mode

although it would break my future dream proposal where functions can return references

Ron has a refs proposal

Is Pattern Matching doesn’t advance, can we get if (Foo(x) = y) support?

Since it's an expression, and an expression could be nested anywhere for any purpose, I'm not sure how likely that is. I certainly hope pattern matching advances because it has a solution for this.

I'm pretty sure I hated the export v from "mod" proposal but I can't remember ljharb

ljharb: Is it worth distinguishing between “withdrawn” (actively withdrawn by the champions) proposals and “inactive” or “stale” (removed because champions are inactive) proposals?

actually i guess thats * as x from

This is supported now

oh yeah it's just short for export { default as v } from "mod" which we already have, right?

() =*> (yield 0) is incredible actually

() =*> (yield 0) is incredible actually

=*> is such a strange looking sigil

Proposals that were withdrawn due to inactivity can always be revived later, right?

the formal process is, someone brings it up in plenary, and we agree

who is doing TC39 watching and interpreting what we do and speculating conclusions from them? is it a few thinkfluencers?

(there are 94 stage 1 proposals)

I’m late to realize that this could be spelled Error.throw(message) and be inherited down the constructor prototype chain. I had assumed Error.throw or Error.raise implied code like Error.throw(new SpecificError(message))

I’m late to realize that this could be spelled Error.throw(message) and be inherited down the constructor prototype chain. I had assumed Error.throw or Error.raise implied code like Error.throw(new SpecificError(message))

since stacks aren't in the spec, there's no way we can mandate the latter afaik. even with tail calls i'm not sure how we mandate that?

bakkot: how complex is the lookahead restriction to implement?

can someone say more why the extra stack frame is a problem?

I've not kept up with the history of X expressions for various X. They are all being pursued because they have some use, but would it be better to investigate some form of expression blocks as Java is doing in various contexts?

the helper function thing is prior to the question of precise syntax, and we have had that discussion

performance? also making it apparent that the code below it is unreachable?

yes some of us would like that very much 😄 https://github.com/tc39/proposal-do-expressions

how is it a performance problem?

indeed a function that's just x => { throw x; } will have the right stack trace iff x is an error object. if it's not one, it won't have a trace, but engines may still report the helper function as the throw site and not the helper function's call site as the throw site.

node, in particular, has magic "show the throw site" behavior

a very small one? I'm not convinced this is a significant issue but it seemed that people were claiming that.

i wasn't being flippant. what is "that"? i don't actually know

at any rate i don't think a helper function that does nothing but throws its argument holds its weight to add to the language - syntax for this would (whether the benefits justify syntax is a separate topic)

what about an Error.prototype.throw?

what about an Error.prototype.throw?

I would want us to still investigate whether this can be written without lookahead, and then once we know that it can indeed be expressed with "normal" grammar write the spec in the way that is editorially preferred

can we fit tail calls into 8 minutes

throw.something() or keyword.throw() should strongly be considered as one of the possible designs.

IMO, if we going to have syntax, I would rather have (throw ex) than throw.something(ex). There is no benefit to a meta-method here, and if we were going to use meta-properties related to exceptions I'd strongly prefer catch.foo over throw.foo.

rbuckton: Is the desire to have TS recognize throws within expressions during static analysis a primary reason for wanting throw expressions in the first place?

We had that discussion in both the July and September 2023 plenaries, and the sentiment I heard was that throw would be valuable even in the presence of do {}.

yes... what's wrong with that? it's a simple feature

like instead of @app.route('/') function index(){} it would be const index = app.route('/', function (){})

you can add more decorators. @app.route('/') @authorized @originCheck @rateLimit(...) function index() {}

my feedback to parameter decorators previously was "we should maybe do function decorators first". If we reject this, we should go back and consider parameter decorators IMO.

its just taking a very popular pattern from other languages

i would really like to have function decorators. i don't care about any other decorators

I have trouble understanding this negativity

have JS programmers never seen HoFs?

with either function or param decorators it'd make it much easier for me to have proper runtime argument validation that's palatable to lots of JS devs

have JS programmers never seen HoFs?

you decorate declarations, and you put data through a pipeline

how are those... different things

Thank you!

i don't understand why you would want to write route(authorized(originCheck(rateLimited(5, 1, function index() {}))))

function index() {} |> rateLimited(5, 1, ^^) |> originCheck(^^) |> authorized(^^) |> route(^^) 🥹

It's hard for me to understand the strength of this opposition. Shouldn't we have skipped class decorators with these arguments? this is really the same thing as those.

and people would do that because they don't want to type c(b(a(() => {}))) ?

and people would do that because they don't want to type c(b(a(() => {}))) ?

i've heard this assertion a few times, both here and in other arguments. how do i actually get a better handle on the size of the dev population that feels this way?

if the order is the same then what's the understandability issue with a(b(c(...))) ?

I like that JS decorators are programmatic, can step through what they are doing 

Maybe I’ve been red pilled by writing a lot of Go, but sometimes you should pave EVERY cow path

Do you mean to say shouldn't?

What other JS library makes use of decorators? Stencil is the only one I can think of

lit-element, MobX, Aurelia, ....

i've heard this assertion a few times, both here and in other arguments. how do i actually get a better handle on the size of the dev population that feels this way?

Are you asking if "syntax matters" or whether "function decorators" are needed? Regarding the latter, I have encountered some inquiries from colleagues and other developers as to why there are class decorators but no function decorators.

decorating object literals is particularly nice because you can define enumerability/writability/configurability inline in a way you can't rn

decorating object literals is particularly nice because you can define enumerability/writability/configurability inline in a way you can't rn

That sounds like a different problem that we could solve with no net new concepts or syntax

i'm not sure how; engines would insist on syntax so they could statically know the shape of the object

I don't see how decorators would provide a solution to this either

The current trascriptioner injects newlines everywhere and worse, they capitalize every word at the beginning of the line

We passed this feedback to the transcription service yesterday. I will relay it again. Can you say which time period it applies to? (They swap people around)

I think the autocapitalization is done by google docs though, so the only problem is the newlines

I’m probably alone in this, but do we really need Google Docs, wouldn’t a plain text format be more accessible and machine process able?

(fwiw the "decorators before export" decision explicitly acknowledged that export decorators could never happen, is what i recall)

I think it's hilarious that Discord added markdown headings; basically just allows you to shout stuff

I thought decorators are after export now

we were ordered to by the CTO

It seems every chat client does that now, just support inline markdown and tables!

tables don't work well on mobile

part of it was the transcriptionists' software and part of it was docs, i had thought the capitalization was fixed

heh i do not work in that part of google

all i've heard are anecdotes like yours ("i know some people who want it") or assertions ("developers want this"). i'm saying that is not enough signal for me to make a judgment

the newlines from the current transcriptionist are really going to be annoying to fix in post

I understand that it should be approached with caution. However, given the size and diversity of the community, in reality, no one can assert how many of the 20 million JS developers worldwide want a specific feature. Even if there are some surveys, we can't even be sure if what developers understand aligns with what the committee might actually do. This is indeed a difficult problem, and I don't know how to solve it; I hope someone on the committee does.

the language is already not good

right, no one can assert. surveys is maybe the best we have

As I mentioned, surveys can't ensure a consistent understanding either. My personal approach is to understand why people need it. In the case of function decorators, my impression is that as soon as developers have used class/method decorators, they almost inevitably end up asking why there aren't function decorators (currently, I tell them it's because hoisting is an unresolved issue).

bakkot: this. I’m really worried about where we could go. ES today is basically the Raku to the JS of 9 years ago’s Perl 4

javascript is so tiny right now, i just cannot bring myself to worry about it having too much stuff

hax (HE Shi-Jun): being new , I’ve always wondered what our principle is in adding a feature or syntax. Is it just corpus analysis/paving the most heavily trafficked cow paths? Or is there another set of principles that guides the language design. If there is, I’ve never seen it.

We live in a world where 70% of active websites are written in IE6 compliant JQuery or similar, but where most modern software is written in a wildly different ESNext

It’s tough, but I can definitely understand a Go program written 2009, and might write that same code today

I also have same feeling from beginning. I have to say, it's very shocked that Dan said TC39 do not have roadmap in one meeting I attended.

TC39 is a politico-technical miracle, the miracle being cooperation between a bunch of mutually competing organizations and stakeholders, each with their own vision, without a strong center of power like a BDFL. The one roadmap, as far as I know, is to Not Break the Web and to improve interoperability between existing implementations.
I wonder if we could come to a consensus on overall vision for future language features. I suspect that it’s not possible.

something something prisoner's dilemma

shu: no because the patterns change. I have coworkers who don’t recognize var, or using the function keyword

Or understand prototypal inheritance, because we hid it behind classes which don’t really exist

snek: you mean because they have a book? we have books

"best-attempt solutions are imperfect" is not an argument for "anecdotes and assertions are sufficient"

look at rust

Sorry everyone, I didn’t mean to start an existential discussion. Just trying to kind of understand our mandate and our process

I’m imagining a world with:
• The JavaScript Programming Language, a book by TC39
• The JavaScriptonomicon: The Dark Arts of Unsafe JavaScript, a book by TC39
• JavaScript by Example, a book by TC39
• JavaScriptlings, a course for beginners by TC39

over the years it has evolved to "stewardship of JS", but i don't think that's actually the core mandate

a rather controversial figure in committee actually wrote a whole set of books that went quite deep into the language and released them on the internet

You don't know js?

Who decides what the core mandate actually is?

Continued and stronger collaboration between TC39 and MDN is indeed high-impact and low-hanging fruit. Probably the biggest method of general community documentation and outreach.

I wonder what it'll take for the committee to make an official effort in this direction

lol @ ljharb

Let MF be your hero and be the process change you want to be

why are you singling out Michael Ficarra /s

ljharb: so now we require payment to advance stages?

I feel very strongly that we should not do parameter decorators regardless of the outcome of this discussion

all syntax needs to be learned by all learners of the language, so that's a high cost

As stated elsewhere, that cost is already paid with decorators in general. IMO, its a higher cost to only be able to apply decorators inconsistently.

From a logical point of view, there are many languages with similar capabilities. C# has attributes, Java has annotations, Python has decorators, C++ has templates

Probably should be in a thread anyway

As stated elsewhere, that cost is already paid with decorators in general. IMO, its a higher cost to only be able to apply decorators inconsistently.

bakkot: oh, element handles them fine (I think 😬)

I found the array ellision discussion confusing. Is anyone actually proposing that we enable [1, void, 2] in expression position?

what does that mean in the RHS

in the RHS of an array literal it would mean elision, yes

"we can support it or not, i weakly suggest we do for consistency, and if we do, it must mean a hole"

nicolo-ribaudo: i've stated many times that repurposing a valid identifier should always be a nonstarter, fwiw (re _)

x |> f(it)

void is the same weight as a identifier in my editor

void is the same weight as a identifier in my editor

sent an image.

having trouble understanding this. all keywords look like idents but behave very differently? is the argument you eyeball them both the same and that's okay?

it's discarding something

i gotta say i'm not excited to find out if _ is compatible

i gotta say i'm not excited to find out if _ is compatible

I think it can be done without changing semantics of any currently legal program

do minifiers not emit _ as an identifier

What I propose is only to relax some errors. Declaring to _ twice would become always valid, but in case where it currently throws than you still wouldn't be able to read it

do minifiers not emit _ as an identifier

Completely disagree. The reason function foo(_) {} is so nice is because it disappears.

then no longer sgtm! sounds like special case proliferation in many parts of the frontend

sent an image.

It would be in the parser only, but also we could instead go with "last declaration wins" semantics that sloppy var ahs

But I'm not confused whether _ is something I care about, vs void looking exactly like a binding name.

jschoi it doesn't show you in the lobby

you had to learn the convention of _ being something to ignore tho

const index =
(route
(authorized
(originCheck
(rateLimited(5, 1)
(function (...) {
  / body
})))))

just use ( for decorators instead of @ :)