Update question about types

[nicolo-ribaudo]

The committee is actively exploring "parsing types to just throw them away", so saying that it will never happen is misleading.

[ljharb]

That’s not a type system, though.

[nicolo-ribaudo]

"Parsing type signatures, even just to throw them away when the console is closed" (which is currently included in this answer) is not a type system either

[ljharb]

Totally agree. That's why the language won't ever have a type system - it just might have no-op type syntax space.

[littledan]

I support either merging this PR or deleting the question. It is important that this FAQ doesn’t take sides in an ongoing debate. I agree with the new answer and disagree with the old one. If Jordan disagrees with the new one, I suppose deletion might be the way to go. I really hope we can come up with a neutral, agreeable way to characterize situations like this, though, since it makes the FAQ more useful.

[ljharb]

I don’t disagree with the PR, except that “no” remains the correct answer.

[nicolo-ribaudo]

Would adding "No." at the beginning of the sentence satisfy both? i.e. JS is not getting a type system, but there is the types annotations proposal.

[littledan]

I think "No" leaves things confusing. Let's just leave this question out of the initial pass of the FAQ, and then we can work on adding text on this topic later.

[ljharb]

That's also fine, but I'm not sure why a correct answer with elaboration after it would be confusing.

[bakkot]

I like the wording @nicolo-ribaudo suggests above (with the leading "No"). I'm not sure how that leaves things confusing, but maybe it would help to make reference to the proposal in that first sentence?

No, although someday there may be syntax for writing out types which would be completely ignored by the runtime (but which could be checked by other tools).

[michaelficarra]

I don't like it as much as the original answer, but I have no problem with this.

[ctcpip]

may be pedantic, but JS does have a type system. should the question be something more along the lines of "will JS ever support static|strong typing"?

[michaelficarra]

@ctcpip Using that definition of a type system, there is no language (with more than one term) that doesn't "have a type system", making it meaningless. Let's not go down that rabbit hole. I support merging this PR as-is.

[ctcpip]

@michaelficarra either of the suggestions from Jordan or myself seem like improvements to me; I don't think there's any rabbit hole to go down

[sirisian]

No. Types that help the developer (such as those in TypeScript) are not the same types that would help the engine, so a built-in type-checking experience will always provide inferior guarantees compared to what the JavaScript ecosystem is used to.

That would make more sense for a question like:

Will JavaScript ever be identical to or evolve into TypeScript?

Which is actually a common question when people first learn about TypeScript as they read the phrase "TypeScript is a superset of JavaScript." I'd probably include wording like that. "While TypeScript is a superset of JavaScript, ..." and then explain the issues with that direction. (The Type Annotations FAQ has a few of them).

I'd then add the second question:

Will JavaScript ever get a run-time static type system?

This answer would then explain specifically why implementing "types that would help the engine" will not be included.

As someone that's followed this discussion for decades, it generally boils down to:

• The parsing complexity currently is too demanding for low-end devices when parsing large web applications.
• Implementation complexity is too high for engines. (I can't remember if this is related to mixing dynamic and static requiring a lot of run-time checks and potential code-paths).
• Trying to add a full type system to JavaScript would be an enormous multi-year effort that would likely never reach consensus. (Taken from the Type Annotations FAQ). Additionally modifying any implemented syntax for all these systems can never break the web meaning the syntax must also be compatible with any future changes. A daunting task.
• Even if it's optional, static typing could lead to conventions where developers type everything which is contentious.

This might be biased on my part as I maintain a long-term proposal on this topic, but I've been content with those kind of answers. There's probably more that can be included, but simply showing it's not viable for the present future is sufficient.

[ljharb]

@sirisian that would be incorrect, as in no way is TS a superset of JS.

[bakkot]

... TS is definitely a superset of JS? Every syntactically valid JS program is a syntactically valid TS program.

"TS programs with no type errors" is not a superset of JS programs, but that's a different claim.

[sirisian]

He might have meant my link was broken. The text was right, but I linked to subset by accident. Meant to link to: https://en.wikipedia.org/wiki/TypeScript which was where that quote is from.

[nicolo-ribaudo]

TS is definitely a superset of JS? Every syntactically valid JS program is a syntactically valid TS program.

let a = b < c > (d)

Has completely different parsing and runtime semantics in JS and TS

[bakkot]

Sorry, yes, modulo the edge case with generics. I didn't think that's what @ljharb meant, but maybe?

[ljharb]

Yes, that’s what i meant - that edge case means it’s not a syntactic superset.

[bakkot]

OK, well, I think describing it as "almost" a syntactic superset would convey the relevant information equally well, if we wanted to go down that route.

[ljharb]

I don’t want to go down that route; i think the current state of the PR is ideal.

[bakkot]

This LGTM. @nicolo-ribaudo @littledan does this work for you, or do you want the qualification I suggested above?

[ctcpip]

I like the additional text bakkot suggested, but good as is too.

[littledan]

I continue to think that starting the answer with "No" is confusing. I also disagree with the implication in the first sentence: the reason that a type system would be inferior is because we're not capable of making the sorts of evolving ad-hoc decisions that TS is, not because of engines, though it is true that the types wouldn't be useful for engines.

[michaelficarra]

@littledan Do you have a concrete suggestion we could move forward with, then?

[jridgewell]

I continue to think that starting the answer with "No" is confusing.

I agree.

[jridgewell]

Suggested change

No. Types that help the developer (such as those in TypeScript) are not the same types that would help the engine, so a built-in type-checking experience will always provide inferior guarantees compared to what the JavaScript ecosystem is used to. The [type annotations](https://github.com/tc39/proposal-type-annotations) proposal is exploring parsing types with no runtime type-checking, which would be left to other tools.

Not a _full_ type system. Types that help the developer (such as those in TypeScript) are not the same types that would help the engine, so a built-in type-checking experience will always provide inferior guarantees compared to what the TypeScript ecosystem is used to. The [type annotations](https://github.com/tc39/proposal-type-annotations) proposal is exploring parsing types without enforcing them, leaving other tools to perform static and/or runtime checking.

[michaelficarra]

WFM

[ctcpip]

to be consistent with the question, suggestion:

- _full_ type system
+ _full_ static type system

also can we generalize the language around statically typed supersets (Iinb4 'TS is not a superset') so we don't appear to be favoring any particular one?

[michaelficarra]

I don't think it's "favoring any particular one" to use TypeScript as an example of what developers expect from a type system. Generalising the language would just make it less clear to the kind of reader we're targeting here.

[ctcpip]

i completely agree with you on the first point, but it could give people the wrong impression. I think this is one reason why the annotations proposal uses language like "TypeScript, Flow, and other static typing supersets of JavaScript".

[ctcpip]

More importantly, @littledan what do you think about the suggested change here?

[ljharb]

It's not correct - it won't have any kind of static type system. That you can achieve one with external tools doesn't change that JavaScript will never have a static type system.

In other words, "No", full stop, is the only correct answer to this question.

[ctcpip]

hmm, yeah, you could argue Not a _full_ type system implies it could get some sort of static type system. and that's not what type annotations would be introducing