update notes to remove moderation comment

Author: ctcpip

meetings/2023-03/mar-22.md

@@ -1043,8 +1043,6 @@ Presenter: Asumu Takikawa (ATA)
 [proposal](https://github.com/tc39/proposal-type-annotations/)
 [slides](https://docs.google.com/presentation/d/1OraKn6TUdmtug-lkgijq-43Xou_1lB1_DJ54x6ssnRY/edit)
 
-JRL: We do want to start with announcing how this is going to be moderated, though. So essentially, I imagine this is going to be rather contentious. We’re going to have a lot of topics popping up. I’m going to be moderating the queue so topics that are similar can get moved together so we can have that discussion quickly and move on to the next topic. Is anyone opposed to that happening?
-
 ATA: Thanks. Yeah, so my name is Asumu. I work at Igalia and I am presenting with DRR and other people who have helped out with this presentation that’s listed below. We’re here to give an update on the proposal, not asking for stage advancement. The primary topic will be addressing feedback that was brought up before. First I’ll go over the proposal context and history. The type annotations proposal got to stage 1 in March of 2022. And just to recap, the motivations for the proposal are static types are widely used in the JavaScript community these days and most can’t be directly run by web engines. So we’d like to improve the ergonomics of using types by allowing engines to process typed JavaScript code. So we can summarize this with main goal of unifying JavaScript with typed scripts. This is another slide showing static types is still popular. This is from state of JS survey a couple months ago that shows that static types is still one of the top requested features. The last time this was brought up to committee, there was this initial presentation focusing on erased semantics for the types so the type would be ignored by engines, just parsed. We heard some feedback that we should also investigate run-time type checking, so the types would have run-time checking. So this will be main topic of the presentation after we give updates. I want to emphasize that we would like to focus the discussion on this topic. So if people with keep that in mind for the discussion, that would be great.
 
 ATA: And so that’s the brief history and summary. We’ll talk a little bit about things we’ve been working on for the initial proposal. There was a tentative grammar for the types and text that was included in the proposal repo and you can see a link for that below. I’ve put a screenshot in that. You’re not expected to be able to read that, just to show it’s a thing. The goal was to accommodate existing type syntaxes and in existing types in TypeScript, Flow, etc. while leaving room for forward compatibility. I just want to go through some examples to show a bit about this. Before the examples, recently we’ve been also working on refining this proposal, so we’re identifying how to extend the tentative grammar to meet the types that are in the tentative systems that are listed there. We’ve been putting forward a syntax comparison table that we plan to add and that’s linked at the bottom there. Some tentative conclusions we reached are that the current grammar supports a lot of the constructs we looked at actually but there are a few cases where we would need to expand the syntax and I’ll give some examples.