fix: Typescript -> TypeScript (tc39#235)

meetings/2023-01/feb-01.md

@@ -500,7 +500,7 @@ Presenter: Daniel Rosenwasser (DRR)
 - [issue](https://github.com/tc39/proposal-decorators/issues/69)
 - [slides](https://github.com/DanielRosenwasser/tc39-2023-01/blob/main/Decorator%20and%20export%20Ordering.pdf)
 
-DRR: So hi everyone. I’m Dan. I’m presenting with RBN. We’re both from Microsoft and work on the Typescript team and want to talk about an issue with decorator ordering today. So for some background, decorators are a proposal that have gone back to 2015 at this point. You know, in 2015, TypeScript implemented and shipped an early version of decorators behind a flag called experimental decorators. Now, decorators reached Stage 3 recently and TypeScript 5.0 beta immaterial implements decorators as per the Stage 3 spec. The plan is to make that default; however, old style decorators or the experimenter decorators that we shipped are still available under that flag. And so the plan is to ship the full version of TypeScript 5.0 stable in March. However, that will come after the March plenary. Now, TypeScript’s early version of the decorator syntax differs slightly from the current proposals. We would like to help the users transition to the standard. Now, the style that TypeScript originally shipped is what I call decorators first. The decorators come before the export keyword if you’re exporting a class. However, the current standard specifies that the export keyword comes first, then the decorators, then the class that you’re exporting. Now, why the change between when TypeScript originally implemented it when it was originally suggested and now? It was discussed extensively and there were many differing opinions. One major justification was, well, if you ensure that the export keyword comes after the decorators, before the decorators, then there’s this theoretical distinction that you can make where semantically there’s like a difference between decorating what is exported versus what is the local. And in the future, you could have decorators that come before the export but in the five years that that issue has been opened, no one has really suggested like a practical use case for doing that at all. So on top of that, we just think that that’s a pretty big foot gun. For example, take this for example right here we have a class call called foo and imagine that the decorator does something to the exported version of foo but locally every reference to foo in this module refers to the local. That seems like it would be a pretty big foot gun where every new foo actually creates a local, the local version. But whatever people refer to outside of this module actually refers to the decorator thing. We think this would not be something we even want to pursue. We think it would be a big usability problem, that people would commonly mix this up because they would just be tempted maybe esthetically and end up with bad behavior as a result of this. So between those, we also have witnessed that there’s not really a lot of positive feedback on the change since then. In discussing the matter with many existing framework authors using TypeScript decorators most framework authors actually preferred the style where decorators came before the export keyword which is what we shipped. But it seems like we just have not wanted to revisit this because no one wants to deadlock the proposal, people just want to ship something. And, you know, there is something to be said about the fact that there is an existing community of people using a JavaScript variant called TypeScript and shipped with its own flavour of decorators for eight years and the style that has been changed – that we’ve changed to within the proposal which is brought up five years ago, never got any hand from our side. No one ever said, well, the current direction seems to be export before decorator. We would greatly prefer that. That’s never really happened on the issue tracker except for maybe one person who was trying to use the battle transform and just wanted their tools to work together. So where are we? Our team would not support any sort of future where there’s a semantic distinction between export followed by decorators and decorators followed by export, for the foot gun reasons that we mentioned. However, if we want to allow both, that’s something we’re open to. But we’re coming here today to ask whether or not we can just make a change overall from the current place where we are at. So we don’t believe there’s a future for semantics based on order which I what I just mentioned. We already have a large community of users in TypeScript who have been using this feature for about eight years now. We would prefer not to have to force them to do a syntaxic upgrade because you can write decorators that permit being called by both the old and new styles. And then anecdotally, what we heard from library authors and users is they prefer the old ordering. So we have two options that we would like to suggest to the committee today. The first option is that we revert the ordering, where decorators are placed before the export keyword. That’s our preference. It would be ideal, it would mean that existing decorators users in TypeScript would not have to do this sort of syntactic upgrade and update all use sites and something that accommodates both styles if you believe that it is purely a stylistic choice is that decorators can be placed before or after the export key keyword and maybe there’s some sort of restriction about exclusive ordering or something like that. That is something we’re open to, but we would greatly prefer option 1. So I’m wondering, what are the thoughts that we have here today?
+DRR: So hi everyone. I’m Dan. I’m presenting with RBN. We’re both from Microsoft and work on the TypeScript team and want to talk about an issue with decorator ordering today. So for some background, decorators are a proposal that have gone back to 2015 at this point. You know, in 2015, TypeScript implemented and shipped an early version of decorators behind a flag called experimental decorators. Now, decorators reached Stage 3 recently and TypeScript 5.0 beta immaterial implements decorators as per the Stage 3 spec. The plan is to make that default; however, old style decorators or the experimenter decorators that we shipped are still available under that flag. And so the plan is to ship the full version of TypeScript 5.0 stable in March. However, that will come after the March plenary. Now, TypeScript’s early version of the decorator syntax differs slightly from the current proposals. We would like to help the users transition to the standard. Now, the style that TypeScript originally shipped is what I call decorators first. The decorators come before the export keyword if you’re exporting a class. However, the current standard specifies that the export keyword comes first, then the decorators, then the class that you’re exporting. Now, why the change between when TypeScript originally implemented it when it was originally suggested and now? It was discussed extensively and there were many differing opinions. One major justification was, well, if you ensure that the export keyword comes after the decorators, before the decorators, then there’s this theoretical distinction that you can make where semantically there’s like a difference between decorating what is exported versus what is the local. And in the future, you could have decorators that come before the export but in the five years that that issue has been opened, no one has really suggested like a practical use case for doing that at all. So on top of that, we just think that that’s a pretty big foot gun. For example, take this for example right here we have a class call called foo and imagine that the decorator does something to the exported version of foo but locally every reference to foo in this module refers to the local. That seems like it would be a pretty big foot gun where every new foo actually creates a local, the local version. But whatever people refer to outside of this module actually refers to the decorator thing. We think this would not be something we even want to pursue. We think it would be a big usability problem, that people would commonly mix this up because they would just be tempted maybe esthetically and end up with bad behavior as a result of this. So between those, we also have witnessed that there’s not really a lot of positive feedback on the change since then. In discussing the matter with many existing framework authors using TypeScript decorators most framework authors actually preferred the style where decorators came before the export keyword which is what we shipped. But it seems like we just have not wanted to revisit this because no one wants to deadlock the proposal, people just want to ship something. And, you know, there is something to be said about the fact that there is an existing community of people using a JavaScript variant called TypeScript and shipped with its own flavour of decorators for eight years and the style that has been changed – that we’ve changed to within the proposal which is brought up five years ago, never got any hand from our side. No one ever said, well, the current direction seems to be export before decorator. We would greatly prefer that. That’s never really happened on the issue tracker except for maybe one person who was trying to use the battle transform and just wanted their tools to work together. So where are we? Our team would not support any sort of future where there’s a semantic distinction between export followed by decorators and decorators followed by export, for the foot gun reasons that we mentioned. However, if we want to allow both, that’s something we’re open to. But we’re coming here today to ask whether or not we can just make a change overall from the current place where we are at. So we don’t believe there’s a future for semantics based on order which I what I just mentioned. We already have a large community of users in TypeScript who have been using this feature for about eight years now. We would prefer not to have to force them to do a syntaxic upgrade because you can write decorators that permit being called by both the old and new styles. And then anecdotally, what we heard from library authors and users is they prefer the old ordering. So we have two options that we would like to suggest to the committee today. The first option is that we revert the ordering, where decorators are placed before the export keyword. That’s our preference. It would be ideal, it would mean that existing decorators users in TypeScript would not have to do this sort of syntactic upgrade and update all use sites and something that accommodates both styles if you believe that it is purely a stylistic choice is that decorators can be placed before or after the export key keyword and maybe there’s some sort of restriction about exclusive ordering or something like that. That is something we’re open to, but we would greatly prefer option 1. So I’m wondering, what are the thoughts that we have here today?
 
 RBN: I think it would help - there’s a clarifying question on the queue.