Haskell-Style Type Annotations

[David-Kunz]

One can add type annotations in a separate line, similar to how Haskell is doing it.

Consider this example:

/// (string, string) string
function concatenate(param1, param2) { 
  return param1 + param2
}

It also works for destructured objects:

/// ({ number, number }) number
function foo({ a, b }) {
  return a + b
}

// or for the whole object
/// (myType) number
function foo({ a, b }) {
  return a + b
}

Advantages:

• Since these are plain comments, no changes to the JavaScript engines are needed
• The function signature remains concise and untouched
• Type annotations can be easily added to existing functions, e.g.

   /// (string, number) number
   const myFunction = functionFromLibrary

Disadvantages:

• Type systems might wrongfully recognise already existing comments as type hints
• Parameters need to be in sync (important when switching parameter positions)

Would something like that also be an option?

Note: I used triple slashes to indicate type-hint lines as opposed to normal comments.

[orta]

I think this would be feasible with today's syntax space:

type ({ number, number }) number 
function foo({ a, b }) {
  return a + b
}

Should safely fit.

[mindinsomnia]

I like this idea of using actual comments instead of adding new syntax. This would make the addition far easier, with no additional syntax needed for the language, and all the existing code bundling tools would continue to operate as expected. Code could run in browsers as old as Internet Explorer without transpiling and still benefit from static type checking in IDEs.

Seems like a vastly better solution to me.

[bradharms]

Why would we want to invent an additional standard for embedding type information inside of comments when JSDoc has already been in wide circulation for years?

[simonbuchan]

@orta Not as the current grammar describes it, which currently requires "type" Identifier "=" Type ";" (unless it changed) - but with a more general syntax you have ambiguity - how does the parser know when the type finishes and function starts? It's possible - and I want to support - more general syntax, but I don't know if I could get this general a syntax supported.

If desired, and with some trickery, type (...) => foo could work, while not breaking const foo = (): (foo, bar) => ... (e.g. a lambda returning a tuple or something), and requiring const foo = (): ((...) => foo) => ... (a lambda returning a function returning a foo). As you can see though, this gets pretty gnarly, and I haven't tried to figure out how I want to approach lambda syntax really yet.

[David-Kunz]

@mindinsomnia

Why would we want to invent an additional standard for embedding type information inside of comments when JSDoc has already been in wide circulation for years?

JSDoc is primarily used for documentation (including type information), using it only for type information is tedious to write and read and better approaches are needed.

I think the main point of this issue is to separate type definitions from the actual (untouched) function implementation. It doesn't necessarily be in a comment, I also like @orta's suggestion as it would enable syntax highlighting and remove the ambiguity regarding normal comments (though it would require changes in the JavaScript engines).

[intercaetera]

This imo is actually a much better idea than the TS style reminiscent of C and Java. One does not need to pollute the implementation of a function with information about its arguments' data types, which is fairly annoying when you are dealing with a lot of small functions.

The only thing I would suggest here would be replacing the whitespace for return with something more explicit, like :: (like in Elixir), -> (like in Haskell and Erlang) or => (like the JS lambda).

/// (number, number) => number
const add = (a, b) => a + b

The thing is, this probably doesn't need any additional browser support since it's already just a comment.

[VitorLuizC]

What about adding -> as supported tokens for types? It would be awesome for Hindley-Milner type systems and similar ones.

[orta]

@orta Not as the current grammar describes it,

Makes sense, then this same kind of thing could work 👍🏻

type foo =  (number, number) => number
function foo({ a, b }) {
  return a + b
}

That said, folks who want to see this form of type system in comments, you can build this today! Give it a shot. (You could even transpile to TypeScript if you wanted to get started quickly )

[VitorLuizC]

@orta Not as the current grammar describes it,

Makes sense, then this same kind of thing could work 👍🏻

type foo =  (number, number) => number
function foo({ a, b }) {
  return a + b
}

That said, folks who want to see this form of the type system in comments, you can build this today! Give it a shot. (You could even transpile to TypeScript if you wanted to get started quickly )

I think this is pretty far from Haskell-Style or anything close to Hindled-Milner type notation.

// I've added ";" at the end of the declarations.

const sum :: Number -> Number -> Number;
const sum = (a, b) => a + b;

// Using type aliases
type Sum = Number -> Number -> Number;

const sum :: Sum = (a, b) => a + b;

Maybe the proposal is too much TypeScript and doesn't allow the community to try other type notations.

[David-Kunz]

I wouldn't do it exactly like Haskell because JavaScript's functions are not automatically curried, therefore the additional arrows seem out of place.

[dpchamps]

Maybe the proposal is too much TypeScript and doesn't allow the community to try other type notations.

The single-colon type annotation syntax proposed is hardly specific to TypeScript. Scala, Rust, Flow, F#, Swift, Typed Racket all come to mind. I'm sure there are more.

However, even with the grammar of this proposal in its infancy something very close to what you're suggesting is possible

type Sum = (Number -> Number -> Number)
const sum :(: Sum) = (a, b) => a+b

// given function overloads eventually make it into the spec 
//  (which I'd be surprised if they were taken off the table)
function sum(a, b): (Number -> Number -> Number)
const sum = (a, b) => a + b

Of course, the parenthesis are totally unacceptable -- I know that there are discussions right now about introducing a more permissive grammar to preclude the need for the "escape-hatch" bracketed type. But as it stands I don't think that the proposal is aimed at necessarily excluding the community from trying other type notations.

The type-system agnostic goal I think drives these principles: static typesystems with both Haskell-Style and TypeScript-Style type annotations should be able to coexist.

[VitorLuizC]

@David-Kunz, you're right. Maybe something like (Number, Number) -> Number would be OK, considering that we still don't have tuples in JavaScript ([Number, Number] would be our "tuples" in this notation). But it's off-topic.

---

@dpchamps

The single-colon type annotation syntax proposed is hardly specific to TypeScript. Scala, Rust, Flow, F#, Swift, Typed Racket all come to mind. I'm sure there are more.

I don't think so. Besides TypeScript, all those languages add more syntax than this proposal aims to allow in the type spaces.

However, even with the grammar of this proposal in its infancy something very close to what you're suggesting is possible

type Sum = (Number -> Number -> Number)
const sum :(: Sum) = (a, b) => a+b

// given function overloads eventually make it into the spec 
//  (which I'd be surprised if they were taken off the table)
function sum(a, b): (Number -> Number -> Number)
const sum = (a, b) => a + b

Of course, the parenthesis are totally unacceptable -- I know that there are discussions right now about introducing a more permissive grammar to preclude the need for the "escape-hatch" bracketed type. But as it stands I don't think that the proposal is aimed at necessarily excluding the community from trying other type notations.

The type-system agnostic goal I think drives these principles: static typesystems with both Haskell-Style and TypeScript-Style type annotations should be able to coexist.

I didn't think about using parenthesis to enclose different syntaxes. It would be a pretty nice solution for enabling other type notations. Thanks.

[theScottyJam]

Regarding the idea of placing this all in special comments, keep in mind other features that type-systems tend to offer, that don't fit well into single-line comments, like: interfaces, making a class implement an interface, type assertions (e.g. as some-type), generics, specifying the type of a variable declaration or class property, etc.

[simonbuchan]

By the way, if you want a HM type system, and not just vaguely Haskell like syntax, you can just use Flow. It's a HM inferred type system implemented for the runtime types actually available.

If you want the syntax too, use Elm.

[VitorLuizC]

By the way, if you want a HM type system, and not just vaguely Haskell like syntax, you can just use Flow. It's a HM inferred type system implemented for the runtime types actually available.

If you want the syntax too, use Elm.

@simonbuchan, I want to type check my code without a build step.

[simonbuchan]

@VitorLuizC then I have good news for you too

[dpchamps]

I don't think so. Besides TypeScript, all those languages add more syntax than this proposal aims to allow in the type spaces.

I'm not sure what you mean, I just meant specifically wrt the single colon type annotation (vs ::).

But also,

I didn't think about using parenthesis to enclose different syntaxes. It would be a pretty nice solution for enabling other type notations. Thanks.

I would like to see the grammar in a state where the parens / brackets weren't required at all. I believe @simonbuchan is working on an alternative to drive the proposal closer to that desired state. That way this proposal would allow for some wider superset of type systems (i.e. the "added syntax)

[simonbuchan]

@dpchamps to be clear, it's more like trying to provide a realistic upper bound (what is the biggest syntax space that could even in theory be accepted), compared to the current tentative grammar, which reads to me like a conservative lower bound (what is the smallest syntax space that meets the needs of a developer). Having both gives the committee a much easier job.

Honestly, the main issue is just figuring out if the plan I have is completely broken or not, which means learning a whole bunch about ASI and contextual parsing in JavaScript, and trying to figure out how to handle the wacky stuff people will try to do, like () => T is a perfectly reasonable bare type... unless you are in the _ in (arg): _ => body. Handling all those sorts of cases gets messy, and I don't want to show up with a list of 100 exceptions.

[dpchamps]

what is the biggest syntax space that could even in theory be accepted

This is a really concise way of describing what I've been trying to capture 🙌

If you are interested in collaborating on this I'd be happy to.

[David-Kunz]

@theScottyJam

keep in mind other features that type-systems tend to offer, that don't fit well into single-line comments, like: interfaces, making a class implement an interface, type assertions (e.g. as some-type), generics, specifying the type of a variable declaration or class property, etc.

Good point! I would say the syntax to define interfaces, importing type definitions etc. is not problematic because it doesn't need to modify JavaScript code.

/// import type { MyType } from "./otherFile";

/// interface SomeType {
///    inner: MyType;
/// }

/// (SomeType) Integer
function foo(x) {
  return x.inner.y
}

It's a bit more interesting if it touches JavaScript code, for example when manually specifying the generic type parameter.
A solution could look like that:

/// <T> (T) T
function addOne(x) {
  return x + 1
}

/// <number>
addOne(4)

No turbo-fish syntax needed here.

The this type might also be specified, maybe at the beginning of the signature:

/// number (string) string
function foo(x) {
  // `this` must be of type number, `x` is a string
  return 'foo'
}

Here, there's no need to introduce the additional this parameter.
If we also want to be able to omit the parenthesis, we can also put the this type in brackets:

// if this shall be possible:

/// string string
function foo(x) {
  return x
}

// then we need to distinguish `this`:

/// [number] string string
function bar(x) {
  // `this` is of type number
  return x
}

// or we could also use the `=>` syntax, introduced in another comment:

/// number string => string
function baz(y) {
  // `this` is of type number
  return x
}

It's also possible to specify types of variables:

/// string
const x = 'foo'

It makes sense to put it in the same line:

const x = 'foo' /// string

And also class members:

class Foo {
  x  /// string
  /// (string)
  constructor(x) {
    this.x = x
  }
}

Type casting should also feel quite natural:

const foo = { x: 9 } /// MyOriginalType

if (foo.x === 9) {
  const bar = foo /// MyOtherType
}

What I like here is that it's obvious what's evaluated during runtime and what's ignored (comments). No JavaScript code is modified, so people who dislike types can just concentrate on the code.

[simonbuchan]

So, to be clear, what are you suggesting? That some comments are ignored, and other comments are also ignored? Nobody is stopping you from building a type system based on this right now.

[David-Kunz]

@simonbuchan ,
I just wanted to show a way to have the same functionality as TypeScript (minus code-generation features like enums) without needing to make changes to the JavaScript engines.

So the question "Do we need to modify the JavaScript engines to support concise type annotations?" can be answered with "No, if an alternative syntax is used.".

The only advantage to support TypeScript-like type annotations is to eliminate the need to transpile TypeScript code to JavaScript in some cases (e.g. when no enums are used).

[simonbuchan]

But again, ... what are you suggesting? Because this doesn't exist, and TC39 and runtime implementers don't need to do anything to support this. So someone needs to write the comment parser, type-checker, etc., and this convince all the thousands to millions of Typescript users out there that they should re-write their code to use this comment syntax instead.

Or, TC39 could add a page or two of grammar to the spec, implementers could add a few hundred lines to their parsers, and a huge chunk of code written in Javascript super-setting languages suddenly become valid Javascript. That path seems both more plausible and a nicer result. And it doesn't stop you from building this at all.

[David-Kunz]

@simonbuchan

a huge chunk of code written in Javascript super-setting languages suddenly become valid Javascript

I think we can call 'JavaScript super-setting languages' just 'TypeScript', there's hardly any other one out there.
And it's questionable if most TypeScript code would be valid JavaScript.

The motivation of this proposal relies on the fact that it's cumbersome/restrictive to write JSDoc comments, which is true, but that shouldn't be the real reason, there are (in theory) better ways using plain comments.

JSDoc comments are typically more verbose. On top of this, JSDoc comments only provide a subset of the feature set supported in TypeScript, in part because it's difficult to provide expressive syntax within JSDoc comments.
...
For these reasons, the goal of this proposal is to allow a very large subset of TypeScript syntax to appear as-is in JavaScript source files, interpreted as comments.

[orta]

JSX aside, I think the only popular omitted feature there is Enums - and since as const was added to TypeScript it's been very easy to migrate to a version of that in JS. I woudn't be suprised if most TypeScript codebases could be codeshifted to fit the constraints of this proposal.

[simonbuchan]

This isn't a (purely, at least) rhetorical question: who are you talking to when you say this syntax should be used? Are you saying someone should invent a new language, are you saying that Typescript should implement a new type syntax that fits in comments?

Because, as I linked above, you can write Flow in the just about most ideal, simple, comment syntax possible, just bracket arbitrary syntax in /*:: and */ and it will be interpreted by Flow as if the brackets weren't present, but it's ignored by Javascript (obviously). And a short-hand /*: and */ for /*:: : and */ to make parameter, variable, etc, annotations succinct.

Speaking purely as a Typescript user, I would be perfectly happy for that to be added to tsc, but it would not be as nice as having this proposal, if given the choice, since it would basically remove the need for .ts files at all. I remain unconvinced that I would bother with a completely different syntax to be added to Typescript, depending on if I want to use a transpile step or not, like it seems you're proposing.

[David-Kunz]

I see @orta , I didn't know of as const and enums were my biggest concern, thanks for clarifying.

[simonbuchan]

FWIW, I basically never touch enum unless I actually need an id/string <=> number mapping

[David-Kunz]

@simonbuchan , I think the original proposal is fine if it's the main goal to support (a subset of) TypeScript as valid JavaScript, but I would remove the JSDoc reason in the motivation.

I'd rather see changes in TypeScript itself than in JavaScript engines, because it can be solved, at least theoretically. If TypeScript would additionally allow this comment-style syntax, apart from JSDoc, that would be ideal. I would certainly use it in my (JavaScript) code base.

I dislike the Flow syntax, you need a lot of /* and */ which is really cumbersome to read/write.

[David-Kunz]

they will find the method that is closer to JS without types, easier to read.

With my proposal, the implementation is the same as in JS. So it's equally easy to read. If people don't want to read type annotations, they can just skip the line, that's not possible in TypeScript.

compared to what? Under, or not the best practices? The least verbose way, is the bad practices way.

Compared to all your JSDoc examples. JSDoc is just too verbose if you only want to add type information.

Which of the method we discuss does that? JSDoc does not do that.

Yes, JSDoc doesn't do that. But TypeScript does.

So your argument is that my proposal is not needed because JSDoc is perfectly suited for that. I disagree and up until now you couldn't provide a single example supporting your case (except when storing the type definition in different files, which one doesn't always want to do). And you don't always have a single type/want to create a single type for the whole signature.

[simonbuchan]

Ok lets stick to the best practices (separation of intend and implementation)

Disagree. Strongly. Best practice is to get the intent and implementation as close as possible, so you can compare them.

The majority of people write JS and not TS or haskell,

The majority of people write Java or C. The majority don't give a flying fig about what's ideal, they just pick the thing that's given to them first. By tremendous effort, JS has been brought from one of the worst languages in common use to one of the best. This, here, is the process by which they happens, so complaining here that "everyone uses JS, so that way is better" is more than a bit silly.

That is valid for any method we suggest.

Except yours, which does need the types in a separate file. That sounds insufferable. Maybe it's not, to be fair, but your examples so far at hardly compelling. They look better than pure jsdoc, so there's a case to use it in exceptional situations now, but it's clearly worse than either comment parsing or native type syntax space.

[lillallol]

@simonbuchan

Best practice is to get the intent and implementation as close as possible

I have to say that I also disagree with you. Close enough for the types to get hard coded with the source? You can hover over the /**@type {import("./some/path").IMyType}*/ and see the type. You want to edit the type? Ctrl+click on it and you are on its definition. How is that not as close as possible?

Also why people have to hard code .js files with a certain type system? Isn't that a bad practice? /**@type {import("./some/path").IMyType}*/ does not include an extension, so it can be used as a universal way to enable static type checking with the same .js file for TS, Flow, etc.

so you can compare them.

This is the job for the linter? Or I guess I do not understand what you mean? Care to elaborate?

The majority of people write Java or C

Yes, if you take what I said out of context.

The majority don't give a flying fig about what's ideal

Yeah, they are hype/resume/promotion driven.

so complaining

I doubt I have complained about something. Can you be more clear on the complain part?

"everyone uses JS, so that way is better" is more than a bit silly.

Are you referring to:

When dealing with subjective arguments, then what satisfies the majorities, wins.

?

If we have A and B and they are equal under objective comparison, but the overwhelming majority is used to A, then why go for B? What is silly about that?

Except yours, which does need the types in a separate file.

Well strictly speaking since I talk about imports then yes, you are right. Although it is currently possible to write :

/**@type {(a : number, b : string) => void}*/

I consider that a bad practice.

That sounds insufferable. Maybe it's not, to be fair, but your examples so far at hardly compelling. They look better than pure jsdoc, so there's a case to use it in exceptional situations now, but it's clearly worse than either comment parsing or native type syntax space.

As far as I understand, regarding the native type syntax, an objective comparison between the two methods, shows superiority of the method I suggest ( even when compared to ts compile to js , you can read more here ). I am open for criticism on that one. The way you reason sounds like someone who has never tried the way I suggest so that begs the question: Have you ever tried what I suggest? Can you please do an objective comparison between the two methods like I did in the link I provided you, so that I can understand you?

I was planning to answer to you regardless of you commenting to me, to be honest, because I saw a lot of stuff that you said with which I disagree with. Just for clarification do not take future comments towards you as ill indent from my side.

[dfabulich]

@lillallol We discussed your proposal in #134, and that issue was closed. Your comments here are off the topic of @David-Kunz's proposal, and while I understand it must be frustrating that #134 was closed, that's no excuse for hijacking this one.

As for why #134 was closed, it has to do with your insistence that an objective comparison shows that your method is superior, and that TypeScript, Flow, and Hegel were all a complete mistake, fueled by "resume/hype/promotion driven development."

We're not having that argument here in #119, and if you keep trying to re-argue your point in other issues, I think it's unlikely that you'll be able to contribute helpfully on this repository.

Instead of what you're doing, I suggest that you take your advocacy to microsoft/TypeScript#48650, and specifically that you file a PR to implement your proposal in TypeScript's JSDoc-based processor.

If your proposal is objectively superior, then the TypeScript team will happily merge it, and, even if they don't, you'll be able to fork TypeScript and convince most TypeScript developers to switch to your thing. Then, next year, the State of JS proposal won't list "types" as the top request for JS, because most developers will be happy to just use your thing.

And if that doesn't happen, maybe you'll come to accept that you're out of touch with what developers are asking for.

[simonbuchan]

I was halfway through a thousand line reply, but yeah, @dfabulich is right, not worth the bits arguing with a brick wall.

[dfabulich]

I'm not a repo admin; I can't reopen your issue. (But, if I were a repo admin, I wouldn't reopen your issue, because you keep characterizing TS as nothing but a "mistake" and "hype," and falsely insisting that you've objectively proved your point.)

If TS's existing JSDoc syntax is sufficient for your needs—if you aren't even proposing improvements to it, like @David-Kunz is—then I think it makes sense for you to just use TS's JSDoc syntax and advocate elsewhere to abandon .ts files in favor of JSDoc. Maybe you can reach out to developers of popular TS repos and persuade them to switch. https://github.com/trending/typescript?since=monthly

(If you're objectively right, then surely some of them will agree with your argument and switch. If none of them do, then I invite you to reconsider whether your argument is objectively right, or just focused on different values.)

[lillallol]

@dfabulich

I'm not a repo admin;

Then why do you act like one? More specifically how do you know the reason behind my issue being closed?

Since you are not an admin then there is no need for my last comment to exist (do not search for it since I deleted it).

I wouldn't reopen your issue

Nobody asked for that.

I can't reopen your issue

Nobody asked for that.

while I understand it must be frustrating that #134 was closed

nobody claimed that it is frustrating

As for why #134 was closed

nobody asked for why it was closed

that's no excuse for hijacking this one.

We're not having that argument here in #119, and if you keep trying to re-argue your point in other issues, I think it's unlikely that you'll be able to contribute helpfully on this repository.

There is no such thing as hijacking happening here from my part. In fact the hijacking is happening from your part because you actually do no understand what we are talking about here.

Are you really considering what TS can already achieve right now as hijacking argument to this issue?

Instead of what you're doing, I suggest that you take your advocacy to microsoft/TypeScript#48650, and specifically that you file a PR to implement your proposal in TypeScript's JSDoc-based processor.

You really do not understand that what I suggest is already possible with native TS? Maybe that explains your whole behavior.

because you keep characterizing TS as nothing but a "mistake" and "hype," and falsely insisting that you've objectively proved your point.

Your comments here are off the topic of @David-Kunz's proposal

Why are you people so disrespectful towards others? Do you even read and comprehend what I have written in my comments? I feel like we are doing cycles. The only comments that are off topic are yours. They address nothing of the initial issue. I suggest you to delete them. You did enough harm to the flow of the conversation already.

If TS's existing JSDoc syntax is sufficient for your needs—if you aren't even proposing improvements to it, like @David-Kunz is—

Man, are you here to muddy the waters or try to provoke a reaction out of me?

The op of this issue does not do that. The op suggest nothing that has to do with JSDoc. Did you even read the comments?

and advocate elsewhere to abandon .ts files in favor of JSDoc. Maybe you can reach out to developers of popular TS repos and persuade them to switch. https://github.com/trending/typescript?since=monthly

so you suggest to reach to popular ts repos and not to a tc39 proposal that has to do with static type checking in JS?

If none of them do, then I invite you to reconsider whether your argument is objectively right, or just focused on different values.

well for grown up people this happens with a grown up discussions with cons and pros. Can you do that? Or you will begin the argument ad populum (i.e. hype argument) again (a common behavior of people who cannot think out of the box)?

[lillallol]

@simonbuchan

I was halfway through a thousand line reply, but yeah, @dfabulich is right, not worth the bits arguing with a brick wall.

I will ignore the arbitrary labeling of brick of wall that is based on false grounds (like i did when you stated that I complain) and I will kindly remind you that I am looking forward to continue our interesting discussion. Anywhere. Anytime.

The strawman argument that our discussion is of topic is not valid since what I suggest is valid native TS that works already, and the op of this issue has yet to demonstrate objective pros of his proposal when compared to the former.

[lillallol]

With my proposal, the implementation is the same as in JS.

Sorry I do not understand what you mean. Care to elaborate what you mean by that?

JSDoc is just too verbose if you only want to add type information.

It is definitely more verbose from what you suggest, indeed. Does that justify creating a new type system though? Especially given the fact that the overwhelming majority is used to TS syntax? Why not proposing this /**@type {}*/ to become this //: but also keep the TS syntax? How is your proposal superior to that?

Yes, JSDoc doesn't do that. But TypeScript does.

You mean that the annotation here : export const : IMyType = () => {} obfuscates the implementation?

[David-Kunz]

Sorry I do not understand what you mean. Care to elaborate what you mean by that?

Everything outside the comments is the same as in JS. So if you're not interested in types, you can just ignore the comments.

Does that justify creating a new type system though?

Not a new type system, just a new way to link the types to your functions/variables.

[lillallol]

Not a new type system, just a new way to link the types to your functions/variables.

So as far as I understand:

1. I use /**@type {}*/ but you would like that to be //:
2. I use /**@type {import("some/path").ISomeType}*/ but you would like that to be //: import type {ISomeType} from "some/path"
3. I will (rarely) use /**@typedef {}*/ but you would like that to be //:
4. (edit :) we are both suggesting to use TS
5. I consider the practice of putting all abstractions in .ts files and never in .js, a good practice but you disagree with that

Did I miss any other difference?

[David-Kunz]

I consider the practice of putting all abstractions in .ts files and never in .js, a good practice but you disagree with that

Yes, and it should be easy to define custom types next to the function, that's too verbose in JSDoc.

[lillallol]

Fine. Now we have to convince the people that are making this proposal that the way we advocate for is superior to what they suggest. We have to be objective and not subjective. Can you create a list with cold comparison facts?

[theScottyJam]

@lillallol - I don't feel like you've clearly explained why you feel it's better practice to keep your types in a separate file (though I only did a quick skim). Could you elaborate on what pros you feel come out of this?

[lillallol]

@theScottyJam

(though I only did a quick skim)

I do not think it is you making a quick skim. I think it is me not making myself clear to the rest of the people (including me).

I have been through the dependency injection book (despite only knowing JS and not C#). The separation of intend and implementation leads to loose coupling which actually leads to flexibility and hence maintainability.

But enough with the fancy jargon. It makes me sound like I just spew no sense without really understanding what I am saying. Let me give you (and also to myself) an example:

//index.js 
/**@type {import("./types").IStringsStringStrings} */
const stringsStringStrings = (p1, p2, p3, p4 = "test") => {
    // some stuff
}

You can clearly see the imported type has no file extension here. That means it could be from TS, Flow, etc.

1. I feel that this is making the migration (manually or not) of projects from one type system to another, less complex
2. Also for the developers that deal with ATS and such stuff, It is easier to deal with files that contain only types rather than files that contain both concretions and abstractions.
3. I think there is a reduced need for type bundling like this since all the types are already in a single file (e.g. I find my self trying to convert mobx to a single .js file with esm and a single .d.ts file for intelisense)
4. This, sooner or later will lead you to the following self explanatory file structure that contain all the types:

• publicApi.ts (it should not depend on the privateApi, read more here)
• privateApi.ts
• sharedPrivateApi.ts
• testTypes.ts

which makes both the life of the developer and the consumer easier, by:

1. reducing the need for a documentation generation library or at least making it easier for the documentation to be automatically generated,
2. making the project easier to reason with by not having the need to have a large amount of files open (e.g. centralized public api in a single file)

I have to admit though that separation of intent and implementation is a bad practice when creating utility like functions that have 0 dependencies, that you want to easily copy paste around your projects. For example lodash like libraries.

I am pretty sure that there are some thing that I have not though about, that maybe belong to both cons and pros. I am open for criticism.

[giltayar]

@lillallol while separating types and code into separate files is worth considering, let's please have this issue/discussion be about what it was initially: Haskell-Style Type Annotations, which are, AFAIK, declared inline in the code.

If you'd like to discuss a separate proposal about separating types and code, please open an issue dedicated to that.

This issue needs to be about inline Haskell annotations, while your new issue could be about out of line information.

[lillallol]

@giltayar
Is criticizing what the op initially suggested and thoroughly explaining ourselves not allowed? Because this is what the whole discussion you are referring to is about.

Since we would like to keep the issue explicitly about Haskell-Style Type Annotations, does actually mentioning TS and how I (subjectively) believe it is better to what is suggested here, is out of topic?

[giltayar]

Is criticizing what the op initially suggested and thoroughly explaining ourselves not allowed?

I would prefer that this issue be about positive suggestions for the annotations, and have the discussion about the negative aspects be in your new issue.

Since we would like to keep the issue explicitly about Haskell-Style Type Annotations, does actually mentioning TS and how I (subjectively) believe it is better to what is suggested here, is out of topic?

Not out of topic, but definitely adding a bit too much noise, which I prefer be delegated to another issue, and leave this issue to exploring the idea in a more positive way.

[theScottyJam]

I think the issue isn't positivity/negativity. Criticism should always be welcome and even encoraged on a particular issue. I think the actual problem is that the general topic of this criticism isn't specific to this issue, rather, it applies to a wide range of issues, which is why it's good to have a dedicated issue for it. This would let us link specific topics like this one to this general criticism.

I've done this sort of thing at other times - broke off sub-issues to discuss some criticism that could apply to a large number of topics.

You did initially try to create an issue for this. IMO it was closed a bit prematurely, but maybe that really was because it was getting heated (that's at least my guess as well, can't think of any other reason for it to be closed that early. As a community, we need to learn to keep our cool if we're going to have constructive conversations). Perhaps an appeal could be made to re-open the other issue, if we think we can discuss it without loosing our heads.

This does sound like an interesting conversation to pursue. But, I don't really know if there's an appropriate place for it anymore.

(And sorry @giltayar - I'm certainly also at fault for continuing the conversation here)

[simonbuchan]

Given that the actual suggestion was "close this proposal, give up and go home, you can already do much better" there wasn't much more to discuss.

This issue might, despite the name, be along a similar vein of "you don't need to change the language, just use comments", but it doesn't actually exist already in the sense of the tires getting checked, so there's at least something to discuss, and it isn't already addressed by the proposal.

I do still have a problem with the implication that there's therefore no value in a native type syntax, but at least @David-Kunz isn't being extremely antisocial and argumentative, so it's a pretty minor problem.

[theScottyJam]

Given that the actual suggestion was "close this proposal, give up and go home, you can already do much better" there wasn't much more to discuss.

True, but there's something to be said for "Maybe we just need to educate people on the tools already there". If it's really true that separating types from code is universally better, then maybe the best solution for this proposal really would be for TypeScript to start pushing this style of coding instead, using it on their docs, etc, and stop trying so hard at extending the language.

Now, I don't actually agree that the separation of types from code is better, but I also don't feel that this type of argument is inherently invalid.

However, I do think the argument got wrapped in a lot of unnecessary garbage, hopefully most of which was unintentional. I just looked over that thread again, and it wasn't as heated as I remembered, perhaps I was mixing memories from other conversations, or maybe I was just mis-remembering. Still, there was a fair amount of stuff in there that really didn't need to be in there.

---

The right way to convince someone of something is to try and come down to their level, see what they see, then respectfully pave a path up to where you're standing. If they stumble along the way, then you stop and analyze what they're stumbling over. Sometimes you have to be patient with them, and try and discuss what feels like the same thing multiple times from different angles until you're on the same page. Because other people have a different set of priorities, it's not often that you'd be able to fully convince the other party of your belief, but at least you can both understand each other and understand why each person draws the conclusion that they do. This sort of debating can help you gain a deeper understanding of your own beliefs as well, and can sometimes cause you to shift your own beliefs in one direction or another. And, occasionally you'll be able to successfully convince the other party of your belief, or at least arrive at a compromise.

That is an example of a healthy debate. The other thread did not exhibit this sort of healthy attitude. And, now I guess I'm mostly talking to @lillallol, but here are some places where things went sour:

• The whole monkey-banana analogy, while interesting, is really just a form of dismissing other people's arguments. In other words, you're happy to give your side of the argument, but you're unwilling to listen to people's concerns (because, like the analogy states, the opposing concerns are not real ones). You're never going to convince anyone of anything like this, plus, it doesn't feel nice when your concerns are being ignored. So instead of saying "Climb the ladder man, enjoy the bananas.", you yourself have to climb down the latter and walk with us back up.
• Actually, the whole opening post is full of this type of thing. Phrases like "Hype[...] driven development", or "[The TypeScript team] [does] not want to admit their mistakes." or "[it is] clear from what I have said before that they are objectively wrong" all work together to send a very clear and nasty message: I've seen the light, come and join me. Don't bother trying to argue, your arguments are invalid, because they're just baseless hype, or a coverup of not wanting to admit you're wrong, or shows you didn't read clearly what I stated because I objectively proved I'm right and you're wrong. Just drop your useless arguments and join me in the true light.

See the problem?

This culminated with "I am honestly not gonna repeat the arguments that I have already written". In a healthy discussion, you sometimes have to re-explain yourself in different ways in order for things to click. And, sometimes you have to ask additional probing questions to try and figure out what the opposing party's real concern is. Instead, you were satisfied that your previous explanation was good enough, and felt that people should clearly understand what you were expressing by just reading it. Since the opposing party saw that you clearly weren't willing to put forth the effort to understand their concerns and help them understand you, and that you had felt that your previous posts should be sufficient to convince anyone, the reply to your comment was "Ok, thanks for your feedback on the proposal", then it was closed. And, why wouldn't it be closed? You clearly expressed that opposing arguments were baseless and that you had clearly expressed everything that needed to be expressed, so what else could have been discussed?

Now, I mean all of this in the nicest way I can. I hope @lillallol was just trying to put forth a strong argument, and that all of this stuff I pointed out above was mostly unintentional. I really don't mean for any of this to sound rude, and sorry if it does. We all make mistakes when debating, I've previously said things I'm not too proud of as well, where I realized I was a bit unintentionally closed-off to the opposing view and caused what would have been a great conversation to get shut down.

So, I personally would love to have a conversation around this topic. Even if I don't get convinced, I still feel I'd learn a thing or two about this programming style being presented. However, we can't have any of this sort of thing happening for such a conversation to be fruitful.

[mindinsomnia]

This issue might, despite the name, be along a similar vein of "you don't need to change the language, just use comments", but it doesn't actually exist already in the sense of the tires getting checked, so there's at least something to discuss, and it isn't already addressed by the proposal.

Does actually raise a very good question though.

It's true, comments for the purpose of type checking aren't currently being used for static type checking for JS code. Instead TypeScript, an entirely different and JS incompatible extension of the JS language is being used instead.

The real question is, why? Why was JS extended into a new language to do type checking instead of just implementing a comments based syntax for marking types of values, and using that instead?

In theory, a comments based system (and I mean comments as in // and /* style comments), would not require a transpiler, and thus 'typed JS code' through comments could exist. The same code could be run through minifiers that produce typeless code for the browser, or the browser could just ignore the comments using the existing syntax for comments. This sounds better in theory, or at least simpler, and could have been done years ago.

So why wasn't it? Why did some turn to TS instead?

This is a genuine question.

A portion of the JS world wanted type checking clearly.
Why wasn't a comments based solution developed instead of TS?

Was it because comments are more awkward to use for marking types?
Was it because no one realised that was a valid solution at the time?
Was it because simply no one created that comments based solution, and because it didn't exist, no one could use it?

Why does a comment based solution still not exist?

Is it because no one is bothering to create it because TS exists?
Is it because comments are more awkward to use?

[giltayar]

My 2 cents: a comments based solution was developed. 3 times: Google Closure, Flow comments, and TS JSDoc Typings. And yet people migrate to TS/Flow.

Why? My pet theory is that because people want types to be part of the language, and not something separate. And if they're in comments, then, well, they feel separate. And they have a point: We all tend to look at examples involving function signatures where there's not a lot of difference between commenting the signature and having it inline (I actually prefer it out of line at the top of the function!). But there's a lot of "in expression" syntax that is very difficult (and ugly) to put as comments. Things like casting (x as number vs /**@type {number}*/(x)*/, and Func<number[]>(4) (which has no JSDoc equivalent!).

So for me the answer to why people didn't like types in comments is part psychological ("we want types to be part of the language!") and part pragmatic ("for 'in expression' typings, comments just don't cut it").

[mindinsomnia]

So for me the answer to why people didn't like types in comments is part psychological ("we want types to be part of the language!") and part pragmatic ("for 'in expression' typings, comments just don't cut it").

I think you're right, I do see why from the perspective of someone who wants typing in their code, that TS's style of syntax is probably the best way to go about it, because that's what typing is like in all the other languages which are strongly typed. It more closely resembles something like Java or C# or C than using JSDoc style comments.

But, in my opinion, that leads us to a road block, because there are people who definitely don't want typing to be part of JS, even as optional 'comments' that don't do anything by default unless run through a static type checker.

That seems like a conflict with no resolution other than for one side to get their way, and the other side to be very unhappy.

And I do believe this is a conflict. It'd be all well and good to say 'Well if you don't want types on your code, then just don't put types on your code', but that's not really a solution.

Few developers are lucky enough to only be required to look at their own code and no one else's, so anything that's part of JS, is something that all JS developers will have to deal with, whether they want to or not. So having types in JS, even as optional 'comments', does impact all JS developers, even those who would prefer JS to not have such syntax.

Right now at least, by having something like TS as a kind of 'parallel' language to JS, at least it's optional in the sense that you can choose from the outset, "We're using JS" or "We're using TS" and everyone is on the same page. You can even tell from the file extension (.js/.ts) alone what you're dealing with.

So to me, this seems like a conflict with no middle ground.

[simonbuchan]

Few developers are lucky enough to only be required to look at their own code and no one else's, so anything that's part of JS, is something that all JS developers will have to deal with, whether they want to or not. So having types in JS, even as optional 'comments', does impact all JS developers, even those who would prefer JS to not have such syntax.

Eh. I see this sort of issue raised against literally everything proposed for anything, but I never find it very compelling. For example I hate code that uses const foo = () => { some long body }; instead of function foo() { some long body }, or making a file per class, and a class per file, like it's Java. But reading code someone else wrote is part of the job, you have to accept that other developers can make different choices to you, and you don't get to make them write code like you prefer. Even if it really is terrible.

On the bright side for you, at least this proposal would mean the people who want to use inline types could be using standardized inline types that you don't need to get specialized tooling to deal with, while at the moment they near certainly would be using Typescript, with all the same downsides of a bunch of types you don't want to see but also all the technical downsides listed in the proposal.

There are complaints that are similar and are pretty compelling to me in theory, though, which might be interesting to compare:

• It lets you write code that looks correct, but isn't
• It makes it easier to write bad code (performance, security, etc.)
• It just looks ugly (as always, but I'll emphasize, in comparison to equivalently functional alternatives)
• It adds too much to learn, or complexity to manage, for the value provided

For me, the proposal passes these sorts of questions quite handily, but that's hardly surprising when I've been a heavy typescript user for years. But it seems that a large and growing minority of javascript users agree enough to deal with getting typescript working in their projects, certainly far more documented support than for (checks recently merged proposals...) ergonomic brand checks (#foo in obj) or WeakRef. (No shade, those are definitely critically useful in specific cases), so the "developers wouldn't want to see this new thing" argument feels pretty weak.

[lillallol]

@giltayar

a comments based solution was developed. 3 times: Google Closure, Flow comments, and TS JSDoc Typings. And yet people migrate to TS/Flow.

Coffescript, Flow, and many other static type checkers did not catch up, so... TS will not catch up? I hope that you understand that your reasoning is flawed.

As I already mentioned in my original issue, people follow hypes, and hypes are defined by the influencers. If something is not hyped by an influencer at an appropriate time and for an appropriate interval it will simple not become a thing, even if it is objectively better than the current thing.

Do you really believe that TS would have been a thing if it was created and promoted by a no one like me?

And please lets refrain from argumentum ad poppulum.

people want

a job, and if compiling ts to js creates a good resume because corporations demand it then they will go for it and not investigate further. The overwhelming majority does not bother to get into the trouble of what we are doing here. And I am not saying that to bash them. I am just saying that it makes no sense to consider the argument:

people want types to be part of the language,

as valid, since the overwhelming majority has not been properly exposed (or even not exposed at all) to the what I suggest.

Even people who should have been exposed to such things have not been actually exposed. More specifically:

• @giltayar [1][2] i.e. the person owning the repo
• @ljharb [3][4] i.e. a tc39 member

I am currently creating client side MVC framework from scratch, and when I migrated my code base from ts compile to js to the method of static type checking I suggest, the DX skyrocketed. The node_modules folder lost its bloat because many npm packages were redundant. Suddenly many config files were not needed. And I could just simple write an index .html with a script type module, using an http server (why would the browsers not easily allow me use esm without an http-server is a topic for another discussion). And I had the same static type checking as before. All that with a neglected method of static type checking that is barely supported by TS. Same thing happening with my DIC library, and the testing library I created from scratch, and the library which automates scrapping dom elements in batch to outlined pdfs (which by the way uses my DIC and I have absolutely no problem with static typing).

How in any way :

JSDoc with TS lacks a ton of the features that native TS has
JSDoc is inadequate right now

then?

If anything can be achieved via a bunch of functions and singletons, then we have to question were does the method I suggest fails on typing these? I really can not see a spot, but I am genuinely open to that. But then again how does a type import via a comment fail? How JSDoc is inadequate on that? Maybe people can help here by suggesting holes that are intrinsic and not just a matter of support.

classes? Do not ask me how to type them. For me they exist only for extending HTMLElement. Anything more than that should be considered a bad practice. People are beginning to realize that classes are not ergonomic[5]. It is sad to see tc39 proposals trying to make JS look like java, with all the disadvantages associated (is there actually any advantage?). We have to reserve keywords and add new syntax for something that is already achievable with functions and singletons? Why? To confuse people and fragment the ecosystem once more?

---

Func<number[]>(4)

Why would you create such a function in the first place? Why does this function has a non inferred type parameter? What is the whole point of enabling passing manually type parameters to functions in TS other than leading to confusing ts2322 errors? How someone using JS is going to deal with that function? Why are you creating code that disregards the majority of the developers i.e. people who use JS and not TS? You can create a more community inclusive example by Func<T extends unkonw[]>(a : number , b : T), even if b is only useful for inferring a type (the minifier might tree shake it anyway). Like this you will make JS peoples life easier.

If TS enables us to extract a type function out of function signatures that have type parameters then my method still works.
So in the end with are dealing with:

• TS enabling bad practices via questionable design decisions
• TS having missing features (extract a type function out of function signatures that have type parameters)

In that aspect there is nothing intrinsically lacking in the way of static type checking I suggest. In fact this is another example of how writing concretion in TS can promote bad practices (among the many other disadvantages I mentioned in my initial issue).

x as number

Again I have the same arguments as the previous example you posted. Why don't you do that :

if (typeof x !== "number") throw Error("received x that is not number");

By the way you suggested : /**@type {number}*/. I am not going to lie. I did not know that this was possible (or maybe it is not?). But then again. Why would I need to know that? Is it really a need to type expressions when we can type statements?

---

Maybe one day you people will grasp the fact that we did it wrong all along and we all (yes me included) fell for it. You will accept the truth by reinventing the wheel and rediscovering that separation of intend and implementation is labeled as a good practice for valid reasons (maybe even before we were born). @simonbuchan a lot of the problems you are discussing in various issues of this repo are the direct result of the violation of this best practice/principle. Mixing abstractions and concretions (i.e. ts files with concretions, what the op of the context issue suggests, what this proposal suggest) is a bad practice, and leads to a myriad of problems already mentioned in my original issue.

I hope that until that day comes, the JS ecosystem will not be fragmented once more.

If you people want to do something good about the JS ecosystem, abandon the proposal of this repo and request from TS to discontinue tsc as a compiler (ts -> js) and promote and hype the best practices. This requires deleting code from the TS library... not writing, because the way of static type checking I suggest is already enabled by TS. If you disagree with that then give objective, hype and bias free, reasons for that, in a list like I have done in my initial issue.

@theScottyJam Any kind of argument that frames me as someone that is brick of wall, toxic, provocative, antisocial, hijacker of issues, complainer, and hence not worth discussing with me is a strawman argument and experimentally proven wrong by simply reading my comments/responces.

[simonbuchan]

@lillallol I'm curious, have you tried Vite? Next? Any of the modern-web.dev stuff? Heck, Create React App? There's plenty of options with absolutely excellent DX that also just automatically roll typescript in, no extra effort. Even just running tsc --watch is pretty decent DX for that matter.

But basically, the problem is that you're continually an arrogant elitist hipster jerk, saying that everything everyone else likes is bad and they are fools blinded by hype and/or marketing.

Your claims that popular languages are bad is especially baffling as that got brought up by you because you were claiming JavaScript being more popular than Typescript is evidence that types are bad (unless it's the very particular way that you use them)

Please: I don't care about your opinion, it's bad. Go write blog posts somewhere I can ignore them, and stop spamming this repo.

[benjamingr]

This discussion has deteriorated and unfortunately repo owners haven't been able to catch it in time.

Personal attacks on people, assuming people are interacting in bad faith etc will not be tolerated.

Kind reminder that this repo has a code of conduct and so does TC39 https://tc39.es/code-of-conduct/ . Interaction in TC39 spaces is done either in accordance to the code of conduct and in a professional manner or not at all.

I'm going to go ahead and lock this thread. Apologies to @David-Kunz (although my understanding is that the use case is addressed already).

If anyone feels strongly feel free to email Gil explaining why it and he can reverse it.

---

As a side note to the people who haven't been dealing with platform/language/framework design for several years at this point: it's OK not to know stuff, people involved want you and more people to get involved. Your opinions (all of them) do matter, and the people working on proposals generally do care about them and listen.

The tremendous amount of feedback this is getting is because of both a genuine interest by the community in the proposal and a genuine willingness by parties involved in this initiative to engage (note how this repo already has 5 times as many issues as proposals like fromAsync)

That said: please be respectful when you give feedback on the proposal. Please never assume bad faith and do ask for clarifications, reading material and history on the topic. You don't know what background or level of expertise the person engaging with you has and how they can contribute (it's OK to ask!) - don't assume stuff about people that never helps. There is a very good chance that if you're new at this there is some reading you'd want to do before getting involved.