Typescript: Request: Nested comment parsing

[00ff0000red]

Forwarning: this has absolutely nothing to do with the typing system that TypeScript offers, but suggests that TS offer something that JavaScript doesn't.

Search Terms

comments, nested comments

Suggestion

As TypeScript is a typed superset of JavaScript, TS should offer a better language overall that JavaScript.
I am not suggesting that TS outputts more JavaScript, but rather the opposite: output the same amount of code, with potentially less comments.

As a comment doesn't properly classify as "code," TypeScript should be able to modify them, to a certain degree at least.

Almost the entire family of C languages lack the capability to parse multi-line comments if they are nested. Ex: C, C++, Java, C#, JavaScript, ... etc. Then there are the outliers, such as Rust, that properly parse them.

I am requesting that TypeScript parse multi-line comments and somehow change the comment syntax, remove the comment, or otherwise create valid JavaScript from a nested comment, making for a language that is slightly even better than it already is.

This is a small, ease-of-life improvement that does not change require outputting code that is executed at runtime (or at all), does not introduce a new syntax, and does not break previous TypeScript or JavaScript, as nested multi-line comments cause a parser error to be thrown in any proper implementation of an ECMAScript runtime, thus making this backwards compatible.

Use Cases

Commenting on stuff that already contains comments.

Examples

Example: a team of programmers is working together on a web app. One of the members had come around to fix and replace some of the older code from the beginning of the project. They decide to wrap a few classes and functions that seemed to be no longer needed. Later, another member comes along, and realizes that the surrounding scope was also no-longer-needed, yet unbeknownst to him/her, their comment conflicted with the other one. They now have to find the end of the comment and modify it somehow to allow the continuation of the outer comment.

I alone cannot determine a safe example of the output of an expression such as below:

/*
Outer comment
/*
Inner comment
*/
Outer comment
*/

declare const hello: "Hello, world!";
console.log( hello );

Except that the code should output a statement calling console.log with an argument of a potentially undefined variable named hello.
Ideally the comments would be preserved, possibly by just eliminating the inner comment, and leaving behind only the text, or changing the comment syntax to no longer output a comment. Example output:

"use strict";
/*
Outer comment
/ *
Inner comment
* /
Outer comment
*/

console.log( hello );

(Surely this ^ formatting can be done in a systematic fashion?)

Checklist

My suggestion meets these guidelines:

• [ ✓ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [ ✓ ] This wouldn't change the runtime behavior of existing JavaScript code
• [ ✓ ] This could be implemented without emitting different JS based on the types of the expressions
• [ ✓ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [ ✘ ] This feature would agree with the rest of TypeScript's Design Goals.

[tadhgmister]

They will almost certainly tell you to suggest this to core javascript and does not belong as a typescript feature.

[RyanCavanaugh]

This is outside of the scope of TS and would also result in some JS parsing very semantically differently, both of which are no-gos.

[00ff0000red]

This is outside of the scope of TS and would also result in some JS parsing very semantically differently, both of which are no-gos.

Okay okay, it may be slightly out of scope of TS, yet it the parsing difference wouldn't be that major, and no current code would be parsed differently, as no current code can do this.

Well, guess it's onto either making my own language or setting up a proposal for ECMAScript... I'll start with the latter.

[RyanCavanaugh]

no current code would be parsed differently, as no current code can do this.

const a = 
/*
 nest 1

 /* nest 2 */ "*/";

[00ff0000red]

const a = 
/*
 nest 1

 /* nest 2 */ "*/";

I swore I had thought this through, to a certain degree at least, but I hadn't thought about stray unmatched /* sequences in a multi-line comment. Well, looks like I was wrong, and this would in fact be a breaking change, ha, guess I'll retreat back or Rust or something.
Thank you for that example though, I might've actually attempted creating a proposal to the language later today if I hadn't realized that.