Types as comments without changing JavaScript syntax.

[azder]

You can have it today, for not extra price and for a lot cleaner code.

Types as comments should work similar to how JSDoc doesn’t need to change the syntax of JS and how Haskell doesn’t need to mix type declaration with the definition, but adds it just before it, with good compilers if you really need it since inferencing will do most of the work.

This is comments as types

    // hello :: string => string

    const hello = name => ‘hi ‘ + name ;

You can change the comment syntax a bit, like

    //: hello = string => string

or

    // type hello = string => string

or whatever else you like.

Just keep it clean and simple please, and most importantly, out of the definitions we already have in the language. Type information can just be added besides them

[Abdelaziz18003]

Normally what you've described above can be solved with the already existing JSDoc syntax.

    /** @type {(hello: string) => string} */
    function greet(name) {
        return ‘hi ‘ + name ;
    }

    /** @type {number[]} */
    const arrayOfNumbers = [];

[GrantGryczan]

I think you may have missed the purpose of this proposal? What you're describing already exists.

This proposal isn't about adding type annotations to JavaScript; it's about not needing an extra compile step in the existing typed variations of JavaScript, and about not having to use JSDoc comments which are generally more tedious to read and write (and are thus less clean and simple).

[azder]

What you're describing already exists

... in a sad state. Can't remember when it was last updated and it still has the syntax of a JavaDoc that was there as a complement to an existing static type system.

Or, if it exists, can't it also be an argument against this entire proposal? "JSDoc exists, we don't need this proposal" kind of thing? The answer will again be "in a sad state".

Would be nice to have something more powerful, but away from the existing JS syntax. A clean separation is even easier on the eyes, less clutter in that one line where you define a function, its type and what else... annotations one day?

JSDoc are tedious because their syntax is not that good, and hasn't been updated much these last years, so it has nothing to do with them being separate from the actual function.

[azder]

Oh, I forgot

it's about not needing an extra compile step in the existing typed variations of JavaScript

What I suggested is in line with this above, you can have your single compile step read the comments AND code, right? We can add that to the language itself, be it a // comment, or a type keyword that introduces it, separate from the existing syntax.

This proposal isn't about adding type annotations to JavaScript;

Yes, it is, hence my comment about not doing it as proposed, but a bit different, like I originally posted:

similar to how JSDoc doesn’t need to change the syntax of JS and how Haskell doesn’t need to mix type declaration with the definition,

Just to be clear, I don't consider Flow or TypeScript as JavaScript. They're separeate languages, thus, there aren't "existing typed variations of JavaScript", there are only two variations: strict mode and non-strict mode.

[GrantGryczan]

Yes, it is, hence my comment about not doing it as proposed, but a bit different

I think this is the source of your confusion: When I said this proposal isn't about adding type annotations to JS, I meant this proposal's benefit isn't merely that JS gets type annotations. The proposed benefits I referred to were TS syntax not requiring a compile step, and people who prefer TS syntax over JSDoc being able to use that with less friction. Your suggested alternative seems to miss the point because it doesn't substitute a solution for these problems of friction. Instead, it substitutes the addition of type annotations, despite that JS missing type annotations isn't the underlying problem this proposal is trying to solve.

... in a sad state.

No, in an identical state. Your suggestion is just to use comments, which doesn't need a new ECMAScript proposal in order to be valid JS, because it's already valid JS. This proposal is for changing the language and its syntax. If you just want to use existing JS syntax, then you can do that today, and this proposal is not for you. As I already said, this proposal is for people who want convenient type annotations supported by their IDE while avoiding using JSDoc or adding a compile step to their JS project.

Or, if it exists, can't it also be an argument against this entire proposal?

I don't think you've made any such argument? An argument against this proposal would involve justifying that the detriment of this feature outweighs the benefits it provides, such as removing a compile step for type annotations in some situations. I'd understand if you were arguing benefits like that are outweighed, but that doesn't seem to be the case.

[ljharb]

@GrantGryczan it would still require a compile step unless the entirety of TypeScript was contained in the proposal, which isn’t the plan as i understand it.

[orta]

I think what would be likely to happen is that there would be a use "TS in JS" flag for projects using typescript checker on JS files with this proposal, the editor would ensure you are writing files which conform to the spec and like with JSDoc support new TS syntax features might take a bit of coercing to fit that space.

Overall though, I'd expect the amount of TS-in-JS files to eat into "plain 'ole .ts" files/projects to the point where most people are writing the TS-in-JS and that the lack of a compile step is a strong pull for that

[spenserblack]

I think what would be likely to happen is that there would be a use "TS in JS" flag for projects using typescript checker

If this proposal is accepted, I wonder how all the tools in the JS ecosystem would change as a result. For example some projects may not have typescript installed as a dev dependency, using type annotations to communicate intent, but not for type checking. Other tools may be updated or then created to ensure no forbidden syntax like enum or namespace. I suppose that syntax errors would be good enough, but some may want a simple check saying "whoops, looks like you used a Typescript feature in JS" without all of the type checking.

:thinking: Also, I wonder if some typescript-eslint rules would make their way to eslint as a result.

[orta]

Any JavaScript tool like eslint would know how to skip over the code which defines types, as defining that behavior would be a part of the spec. It would allow the same tools to work for more than just TypeScript for example, as other type system can fit into the space

If you have code like namespace and enum though, which does not exist in TS-in-JS (unless added by TC39 in the future) your tools would correctly throw and you could hardcode error messaging to say that this is a TypeScript file and should really have a .ts extension

[GrantGryczan]

it would still require a compile step unless the entirety of TypeScript was contained in the proposal, which isn’t the plan as i understand it.

@ljharb I didn't mean using TS features this proposal doesn't support. For people only using supported features (which most of the features are), a compile step would be eliminated. Or, to put it differently, for people using vanilla JS (especially Node.js where there often isn't already a compile step for minification) who would benefit from type annotation, it would make introducing types to their codebase more accessible due to the reduced friction, especially for those who prefer TS syntax over JSDoc (which, judging by their popularity, is most people).

Also, I'm not sure why you're saying a compile step would necessarily be required, considering reducing the need for a compile step is brought up by the proposal itself multiple times? That's why I commented about it in the first place. To quote it (regarding two different use cases):

This proposal will reduce the need to have a build step which can make some development set-ups much simpler. Users can simply run the code they wrote.

Node.js developers in particular, have historically avoided transpilation, and are today torn between the ease of development that is brought by no transpilation, and the ease of development that languages like TypeScript bring.

[ljharb]

I don’t personally think there’s much value in making things more complex by saying that some, but not all, TS users can avoid transpiling.

[GrantGryczan]

I'm not here to argue whether there's value in it, I'm just clarifying one of the points the proposal makes since this issue doesn't seem to attempt to solve the same problems the proposal is attempting to solve, or at least attempt to solve some of the problems with a better trade-off. This issue only suggests a new format for type annotations as comments--so not something that could be a TC39 proposal since comments are already valid JS, just as JSDoc also didn't require a TC39 proposal.

[lillallol]

not something that could be a TC39 proposal since comments are already valid JS

Correct me if I am wrong, but the scope of tc39 is[link]:

Scope:

Standardization of the general purpose, cross platform, vendor-neutral programming language ECMAScript®. This includes the language syntax, semantics, and libraries and complementary technologies that support the language.

Static typing is a complementary technology that supports the EcmaScript language. A static type system needs specification to be defined, regardless of whether it reserves syntax inside native comments.

I would like the opinion of @ljharb on this one.

[GrantGryczan]

I hadn't personally seen any instance of TC39 handling anything besides ECMAScript semantics and syntax, so I was under the impression this didn't fall under its scope, but if it actually does, then that's reasonable! I thought it would be something the community would be better off handling like TypeScript, Flow, JSDoc, etc.

But either way, I still don't think this suggestion attempts to solve the same problems this proposal does. You may disregard the sentence of my previous comment about TC39's scope.

[lillallol]

But either way, I still don't think this suggestion attempts to solve the same problems this proposal does.

Be more specific please.

[GrantGryczan]

I've already argued that statement specifically in most of my previous comments, so I don't think continuing to repeat myself or participate in this conversation will really help anyone. If my first few comments didn't get my point across, it doesn't seem any further comments will (at least in a reasonable amount of time). Sorry to end the discussion abruptly.

[lillallol]

For people only using supported features (which most of the features are), a compile step would be eliminated it would make introducing types to their codebase more accessible due to the reduced friction, especially for those who prefer TS syntax over JSDoc.

Please read the tc39 meeting notes [1][2][3][4]. The context proposal has yet to provide a syntax that is working. The assumption that the context proposal will support, all or some of the already existing TS syntax, has no proof. Also there are no restrictions to the solution scope in stage 1 proposals. What the op suggests, and any other suggestion that does not need to introduce new "comments", solves the problem statement, and despite how much people do not want to admit it, this is done without the drawbacks of the context proposal. To make matters worse the problem statement is already solved without the need for any kind of tc39 proposal. Take a look for example how SvelteKit and Deno used TypeScript without the need to compile:

• SvelteKit[link]
• Deno[link]

Have you actually created projects like this? I personally have. Most people have not, and that makes them believe that we need the context proposal.

Finally this:

friction

mentioned in tc39 meeting notes, is nothing more than an artificial problem created by the intrinsic drawbacks of supersets: arbitrarily reserving syntax without tc39 approval. You simply stop using supersets, and move to complements, and the problem is solved. It is my opinion that tc39 should strive for people to stop using supersets, since this will lead to a healthier ecosystem.

In the end the fact that people seem to not really know what is going on with the context proposal, hence countless issues like this context, is because, the maintainers of the context repo do not seem to be bothered to just add links to the tc39 meeting notes in top of the README.md file.

[azder]

@GrantGryczan there is no confusion. You're proposing syntactic change to one language for the benefit of another language. TC39 should change syntax for the purpose of the EcmaScript language. That is all.

My suggestion was to evolve the ECMAScript language (or at least the practice of it) in a way that:

• doesn't require syntactic change to have benefits
• provides for separation of concerns and cleaner coding practices
• give people who like to play with static types a way to do it
• doesn't care about other languages (like TS or Flow) since they're outside the scope of EcmaScript
• maybe the comment syntax evolves in a more "modern" way (JSDoc is stuck in the "middle ages" atm)

I think @lillallol threaded the similar line with the problems of supersets, and what I consider "muddying the waters" by considering other languages as JS-but-* (better, different, etc). They aren't it, so any proposal for a complementary technology should be part of a complementary technology technical committee, and any proposal to TC39 should be about the benefit to EcmaScript, not other languages.

[spenserblack]

Take a look for example how SvelteKit and Deno used TypeScript without the need to compile:

You've used these projects a few times as examples for why you don't need Typescript or typescript-like type annotations. Have the maintainers weighed in on this proposal anywhere? Especially for SvelteKit, where they seemed most interested in removing a compile step, I wonder if they considered JSDoc to be the best, or the best currently available, and if they would have considered some of the proposed syntax of this proposal to be a better choice.

[lillallol]

You've used these projects a few times as examples

To be honest I use these projects as examples because:

• everyone knows them
• they are complex projects
• I have not uploaded my projects on github

I do not need them as a proof for what I claim. My projects are enough.

Have the maintainers weighed in on this proposal anywhere?

As far as I know, no. Why are you making this question? That is a strange question. It seems to me, like a question that would come from someone who have not used TypeScript the way these projects do. Have you actually used TypeScript like these projects do? There is no going back when you are appropriately exposed to this way. It is simply better.

for why you don't need Typescript or typescript-like type annotations.

Lets be clear here. TypeScript type checking is needed. I would never use JSDoc on its own without TypeScript. I personally use TypeScript in all of my projects regardless the size. I just do not use TypeScript as a superset. I write strictly all types in .ts files and import-type-annotate variables in .js files with this /**@type {import("./path/to/file.js").IMyType}*/.

if they would have considered some of the proposed syntax of this proposal to be a better choice.

Native supersets are currently not working. There is no working syntax provided by the context proposal, hence it makes no sense to ask them whether they have considered it, since we might end up with a completely different syntax from the current one.

For the case a working syntax is found that is accepted by all of the tc39 members (when? next year? next decade?), then all the pros and cons should be considered. For example it makes no sense to just compare syntax when breaking changes (like nothing of TypeScript is valid syntax) are introduced to all supersets + and the JS parser becomes slower regardless of the usage of the new syntax.

[spenserblack]

@lillallol TBH I'm not going to do much back and forth and respond to each piece, as I feel like anything further would bloat the comments without adding much value.

But to respond to you asking why I was curious about the opinion of those projects' maintainers:

I assumed you were using those projects as proof that your arguments are valid. With that assumption, it seemed to me that the opinion of maintainers of these large, popular projects would be valuable, and that the continued usage of them as proof would be unfairly putting words in their mouths.

Also, your success with using declarations and importing them with JSDoc comments in private projects might be proof enough to you, but I'm sure you can understand why it might not be convincing to me or others you've debated with.

You are correct that I haven't used types in this way. But for smaller projects, I have actually considered dropping TS and writing JS with declaration files, because, as I've said in a few other places, I'm more interested in using types to communicate intent than to be strictly asserted. So perhaps I will someday. This may not be the most compelling reason, but I do find a TS-like (or Python-like) type annotation to be the easiest way to write intended types, hence my interest in this proposal.

[lillallol]

but I'm sure you can understand why it might not be convincing to me or others you've debated with.

I do not understand. Be more specific please.

[egasimus]

There is no going back when you are appropriately exposed to this way. It is simply better.

Hard disagree about the "simply better" part. Am "appropriately exposed" to TypeScript. It sucks and is user-hostile. Fight me.

The "no going back"... jury's still out on this one. Either there is a going back (to JavaScript as a scripting language, without bundlers, preprocessors, compilers being a mandatory part of the toolchain), or, thanks to WASM, there's a going to a different language :shrug:

[msadeqhe]

You can have it today, for not extra price and for a lot cleaner code.

Types as comments should work similar to how JSDoc doesn’t need to change the syntax of JS and how Haskell doesn’t need to mix type declaration with the definition, but adds it just before it, with good compilers if you really need it since inferencing will do most of the work.

JavaScript always had interface and implements keywords, that means every language has to evolve someday, and JavaScript had this goal from the ground up.

[azder]

every language has to evolve someday, and JavaScript had this goal from the ground up

That's not in question.

The thing is, how? There are many questions connected to it:

• by copying verbatim what has been piled up over time by inertia and sedimentation in other languages?
• how long would one have wait for it to be implemented and supported before it's useful for many?
• what does it mean if you standardize one syntax and leave it difficult for other type systems to be added later?

With comments, you can have flexibility and freedom to extend with different solutions without spending years disussing it in a technical comitee that has to be concerned that what you add to the standard is hard to remove least you break the Web.

Otherwise, here is one version that doesn't require you to re-invent syntax so you will be able to shoehorn it in every place imaginable:

• reusing existing type systems, not re-inventing the wheel, allowing for expansion

  
  // blocks of interfaces can have identifying tokens in order to support multiple syntaxes and versions

interface ('TypeScript','5.2.2') {

type add = (a: number, b: number) => number;
type Sub = (a: number, b: number) => number;

declare function plus <T extends number|string>(a:T,b:T): string;

}

interface ('Flow','0.217.0') {

type add = (a: number, b: number) => number;
type Sub = (a: number, b: number) => number;

declare function plus<T:number|string>(a: T, b:T): string;

}

- importing from other files, instead of keeping all in one place, for optimization

// the file itself can have the identfying tokens interface "./local/interface/definitions/file.ijs";

// or add them inline interface ('TypeScript','4','d.ts') from "./local/interface/definitions/file.v4.d.ts"; interface ('TypeScript','5') from "./local/interface/definitions/file.v5.tjs"; interface ('Flow') from "./local/interface/definitions/file.fjs";

// same identifier as declared in the above types const add = (a, b) => a + b;

- and now the "shoehorn" part, how much of the following is too much?  

// forcing the type manually const sub interface Sub = (a, b) => a - b;

// but limited syntax to only the type identifier after the keyword, like const plus interface Plus = (a,b) => a + b;

// nothing extra? // could it be specific to one or two type systems/checkers, and limiting the rest? const plus interface Plus = (a,b) => a + b; // is generics here too much?

// allowed only in const, let, var syntax i.e. const identifier interface Type = ...

// but not in expressions and definitions like the following? const result = someFunction( a interface Type );

// when does it become too intrusive? function otherFunction(a,b) interface OtherFunction { return a + b; }

This last block (the shoehorned part) is contrary to the separation of concerns I would like to have and to think will be useful as to allow more freedom for newer and better ways to express and check the types

[egasimus]

@azder This kind of dovetails with a thought I had when discussing namespace with @unional on #167. Maybe the package keyword would be a good fit for the first couple of examples?

Even in combination: interface package, export interface package. These have a certain pronunciability to them as well.

Example (not with types but it would work the same):

If currently you can do:

// impl.js
export function foo (a, b) { return a + b }
export const bar = 1

// index.js
import * as Impl from './impl.js'
import * as assert from 'node:assert'

assert(Impl instanceof Module) // import "returns" Module

export function fooBar (baz) {
  return Impl.foo(Impl.bar, baz)
}

The package keyword could make it writable as single file:

import * as assert from 'node:assert'

assert(Impl instanceof Module) // hoisting like functions

export function fooBar (baz) {
  return Impl.foo(Impl.bar, baz)
}

// create Module in place, automaticalyl enclosing a namespace
package Impl {
  // parent scope is not visible here
  export function foo (a, b) { return a + b }
  export const bar = 1
}

This would do native namespacing for both types and values.

And then it could also be used to denote code that is governed by an external compiler, e.g.

import * as assert from 'node:assert'

assert(Impl instanceof Module)

export function fooBar (baz) {
  return Impl.foo(Impl.BAR, baz)
}

package Impl {
  export const BAR = 1
  export function foo (a, b) { return a + b }
}

export interface package ("typescript@5.2.2") {
  export function fooBar (baz: number)
}

[unional]

if (!(Impl instanceof Module))

This scares me 🤣. The result of import * as Impl should always be that case and needing to do any check at runtime will be very problematic.

Not sure about the rest of the discussion, need to read through. 🌷

[egasimus]

This scares me 🤣. The result of import * as Impl should always be that case and needing to do any check at runtime will be very problematic.

It's just a hacky assertion. I've updated the example to clarify the intent.

I'd be scared if I saw it in production code, too - would mean someone's been bitten by a bundler malfunction, something I prefer to only theorize about 🤣

[trusktr]

I missed this one. I also added a more examples of types inside regular comments here:

• 192

[azder]

Even in combination: interface package, export interface package. These have a certain pronunciability to them as well.

I don't like this. I only touched it with one word - sedimentation coupled with inertia, but didn't expand on it.

Let me try to explain my reasoning. Starting with a bit of pseudo-history (people might correct me on some of it).

A lot of the syntax in JS comes all the way down from C, but as early stardard like C89 had about 32 keywords, that syntax was being picked up by C++, Java, JS, C#, TS etc and more keywords had been added to now have C# with 77 non-contextual ones and something like 46 context sensitive ones. And that's only by count, not talking about combinations and permutations of what it means one to be before or after another like in C++ with having constant pointer and pointer to a constant (this is especially interesting since sometimes we explain JS const to people in terms of C++). And then there are keyphrases, like foreach which is two words, not one...

So, JS has tried to look forward with reserving some words as keywords, has added new ones which are context sensitive, but it's still a bit more conservative in that regard (it has to because you can't remove stuff after added). It's like, whenever there is a difficult compiler problem, some of it is being offloaded to the coders, let them put annotation, new context sensitive keywords and even static types for displaying nice IDE suggestions.

Don't get me wrong, yes, compiler simplicity is also important, but I always try to err to simplicity for people reading and writing code than compilers (which can be improved faster and perform some menial tasks in a far more superior manner).

This is the reason why I tried to use only one keyword interface, even tough I might have used implements (also reserved by JS) in that third shoehorn block and why I first and foremost am for using comments //: for extensibility, but also a syntax like interface( '', '', '') can be semantically extensible even though you'd only need to change the JS syntax once.

In a sense, interface() is an annotation, or JS version of the <script /> tag

[azder]

@unional @egasimus on

I'd be scared if I saw it in production code

I was considering some use case that I don't know is viable, but having the ability to

interface ('TypeScript','4','d.ts') from "./local/interface/definitions/file.v4.d.ts";
interface ('TypeScript','5') from "./local/interface/definitions/file.v5.tjs";
interface ('Flow') from "./local/interface/definitions/file.fjs";

or better yet, we can leverage existing syntax:

import ts4 from './local/interface/definitions/file.v4.d.ts' assert { types:  ['TypeScript','4','d.ts']  };
import ts5 from './local/interface/definitions/file.v4.d.ts' assert { types:  ['TypeScript','5']  };
import flw from './local/interface/definitions/file.v4.d.ts' assert { types:  ['Flow']  };

one might use a ServiceWorker and WebWorker to not just add compile time checks and erasure, but also load time and run time checks. But this last part might be off topic.

The idea is to have the ability to import different files and syntaxes as opposed to changing the JS syntax to support yet another embeddded language (tag soup) for typing similar to how RegExp is being used for matching.

[azder]

@trusktr please note, I don't use //: as a way to say a) "this next variable is of type..." or b) "this preceding argument is of type..." but as an escape sequence like //** is.

It's only meant to signal your pre-processor that it's not a regular comment, but something your DSL can work with. So basically //: A = string is a stand in for type A = string as found in Flow or TS.

Which is why in this example https://github.com/tc39/proposal-type-annotations/issues/192#issuecomment-1732170252 I used //:~ to denote the use case similar to a)

[theScottyJam]

Just to clarify intent, when you have something like this:

interface ('TypeScript','5.2.2') {

    type add = (a: number, b: number) => number;
    type Sub = (a: number, b: number) => number;

    declare function plus <T extends number|string>(a:T,b:T): string;
}

How exactly is this being parsed?

Is the type-system tag ('TypeScript','5.2.2') being ignored like it was a comment? This is just metadata for the type checker to pick up and use?

What about the body of the interface. Is this behaving:

1. Like a token soup, where everything inside still gets tokenized using JavaScript's tokenizer, but then everything gets ignored (including matching curly brackets found inside)?
2. Like a block comment, except with perhaps minimal bracket matching so you have have nested curly brackets getting ignored?

Option 1 is similar to what the proposal currently does in some places, and it means this:

// Valid
// The inner curly brackets match up and get ignored.
// The `{` inside the string is not treated as an inner curly bracket
// since we have enough context to understand that that's
// supposed to be thought of as a string.
interface ('TypeScript','5.2.2') {
  type ObjType = {
    readonly value: '{'
  };
}

// Invalid
// there's not a closing quote to match the opening quote
// Not all languages things of single quotes as strings,
// e.g. the ML family of languages allow you to put
// one single quote next to a type name.
interface ('TypeScript','5.2.2') {
  type ObjType = {
    readonly value: 'a
  }
}

Option 2:

// Invalid
// There are more opening brackets than
// closing brackets, so it's going to try
// to parse whatever comes after this
// as part of the comment as well.
interface ('TypeScript','5.2.2') {
  type ObjType = {
    readonly value: '{'
  };
}

// Valid
// Since we're night trying to tokenize the contents,
// we can invent new uses for single quotes and what-not
// beyond "a single quote is a string".
interface ('TypeScript','5.2.2') {
  type ObjType = {
    readonly value: 'a
  }
}

[azder]

@theScottyJam First, the very simlpe short answers:

0. How exactly is it being parsed? It isn't, ideally.
1. Where everything inside... Is maybe just being ignored by JS
2. Matching the {} makes sense, except it should not be a JS error, so possibly handled like ASI

The following should not cause JS to throw an error, but JS could backtrack and pick the final } as the token for the closing of the interface block.

interface ('TypeScript','5.2.2') {
 // whatever valid or invalid here as determined by the type checking DSL parser
}

In a happy scenario, JS would be ignorant of anything inside the block, skip it, not parse it at all, which is why I mostly prefer using comments, so as to not be changing the language syntax, and especially semantics.

The original comment with that specific syntax was more like a spur of the moment exploration. Further down I've reconsidered, maybe re-using the existing import-from-assert syntax is good enough to get things going, at least peacemeal.

import ts4 from './local/interface/definitions/file.v4.d.ts' assert { types:  ['TypeScript','4','d.ts']  };

The extra tokens are supposed to serve whichever parser is dealing with whichever DSL is being imported. As I've imagined someone might figure out how to use ServiceWorker and WebWorker to provide load time and run time checks, maybe by the environment (like Node) or with a 3rd party parser sent by the server or a browser plugin...

This way people can have all the extra semantics they need, but also not baking it into JS, thus leaving the language as a common denominator for different type checking DSL's without JS being expanded.

And if serving files in this manner is a good start, maybe there will be a possibility of using a reserved keyword. At the very least, comments like //: pre-lined instead of inlined, could be used to test the practicality of next steps. I would imagine the workers can catch those as well from the JS file itself, provided a bundler is smart enough to not erase //: comments or mangle only the identifiers as to cause a mismatch with the type declaration.

[trusktr]

@trusktr please note, I don't use //: as a way to say a) "this next variable is of type..." or b) "this preceding argument is of type..." but as an escape sequence like //** is.

It's only meant to signal your pre-processor that it's not a regular comment, but something your DSL can work with. So basically //: A = string is a stand in for type A = string as found in Flow or TS.

Which is why in this example #192 (comment) I used //:~ to denote the use case similar to a)

For sure. Yeah in my examples I was using it as a type for the thing the comment is associated with, rather than definitions. It needs bike shedding

[azder]

the thing the comment is associated with

And that's precisely what I want to avoid. That makes these kind of comments context sensitive and forces (as in soft power) or enables (as in abusive, not empowering) people to mix declaration and implementation in the same place.

[eldoy]

If we could just agree on a format, then all editors can support this. Typescript needs to die asap.