Clarify Motivation

[dfabulich]

At the March plenary session, this language from @DanielRosenwasser persuaded the TC39 committee to advance the proposal. We should clarify the motivation here.

[lillallol]

That is not true. Have you actually read the meeting notes?

[dfabulich]

@romulocintra Thanks for approving this PR! Are you waiting for more approvals before merging it? (How many approvals? Anyone in particular?)

[ctcpip]

That is not true. Have you actually read the meeting notes?

@lillallol yes, it's true, as detailed here: #166 (comment)

[lillallol]

@ctcpip

From the meeting notes:

Can somebody just clearly, what is the expanded scope or problem statement? Is
that the one that was flashed up in the slides or has there been
RPR: The one on the slides and we will also consider runtime effects and simpler
syntaxes.
KG: And we'll consider changes that also require changes to TypeScript. That it's not
just JS is necessarily going to try to move in the direction of the forks, but rather that
we might try to find some common ground that both places can move towards and
meet there.
WH: Yeah, the clarification that was important to me was that much simpler syntaxes
are also in scope and any compatibility with any fork is not a prerequisite.

From the PR:

This proposal formalizes an ergonomic syntax space for comments

How are these comments when:

we will also consider runtime effects

?

I think this line (which exists in the context PR, but not in #166 comment):

This proposal formalizes an ergonomic syntax space for comments, to integrate the needs of type-checked forks of JavaScript.

should be removed from the context PR.

[ctcpip]

@lillallol, the line you are referencing was in the slide deck that was presented, which is also referenced in #166 (comment)

[lillallol]

My bad for not being thorough with my responses.

@lillallol, the line you are referencing was in the slide deck that was presented, which is also referenced in #166 (comment)

Yes indeed, it is in the slide deck but also in the second tc39 meeting notes. You do not include the line in your comment, although the links you give, do.

The PR author is talking about what convinced the tc39 committee to give stage 1:

At the March plenary session, this language from @DanielRosenwasser persuaded the TC39 committee to advance the proposal. We should clarify the motivation here.

Stating that this:

The strong demand for ergonomic type annotation syntax has led to forks of JavaScript with custom syntax. This has introduced developer friction and means widely-used JavaScript forks have trouble coordinating with TC39 and must risk syntax conflicts. This proposal formalizes an ergonomic syntax space for comments, to integrate the needs of type-checked forks of JavaScript.

is what convinced the tc39 committee to give stage 1 is misleading, since that implies that the tc39 accepted a restricted solution space, which is not how tc39 works (link):

Stage 1 only means the committee wants to keep discussing the problem space; it simply does not imply that it is, or is not, based on erasable types or runtime effects or literally any other semantics, because that's not how the TC39 process works.

In fact, it was explicitly clarified that the solution space is not restricted to types that have no runtime semantics, despite that, by default, getting stage 1 does not restrict the solution space.

So the line that restricts the solution space should be removed from the PR.

[ctcpip]

@lillallol - I see your point. Ultimately, the acceptance criteria for stage 2 is the spec text. Whether the line you mention will end up accurately describing that spec or not remains to be seen. Nonetheless, the champions determine the proposal content, whether and how they want to restrict the solution space, and so on. Seeing as though they presented that text at plenary and they got consensus for stage 1 directly after presenting it, it's reasonable to update the proposal to reflect that.