Sound wrong to me

[lifaon74]

I'm a big user of typescript and I'm not convinced at all by this proposal:

1. Types require a lot of new syntax which evolves contently, and require hundred of developers to maintain/develop. And a lot of experimental features, something that should not be integrated into the TC39 pipeline... (ts specs: https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md)
2. Type transpilers add more than just types. Typescript add enum, class private, public, protected, build to different target, etc...
3. If transpilers exist and work perfectly, why re-inventing the wheel ? Basically this proposal looks like: let's put typescript directly into the TC39. When everybody can already install and use ts in 10s...

It start with a good idea: "everybody should be able to use types". But in reality, it's already the case... (except its not native, but the transpilers add far more than just types...).

PS: I really encourage people to use typed js with a good IDE which helps A LOT debugging, maintaining, avoid a lot of errors, and provide powerful auto-completion. But I would not see this natively in JS.

[obedm503]

I think the idea of this proposal is to standardize type syntax. similar to how python has types but the interpreter just ignores them https://docs.python.org/3/library/typing.html

given that flow and ts already share very similar type syntax (constname:TypeName= new TypeName()) a standard might make sense

[keyvan-m-sadeghi]

Sounds perfectly reasonable to me!

JavaScript already ships with types! Few people notice: String, Boolean, Number, Promise, etc.

@lifaon74 TC39 is all about JavaScript standards, if we are talking about the possibilities outside JavaScript, it's off topic in TC39 IMHO.

@obedm503 Precisely! There is no need for JavaScript to reinvent the wheel, take clues from how Python does it, stand on the shoulders of giants!

@samuelgoto I think creating a bridge to fill the gap is genius engineering, well done 🎉
I do however think that there is another missing piece in this puzzle, like Python, JavaScript needs a global Type object that other global types inherit from.

REPL examples:

const obj = 1.42;
Type.fromInstance(obj)
// Number()

Just musing, though one can then even have a union type and other TypeScript goodies:

new Type(Number | Promise)
// UnionType(Number, Promise)

[obedm503]

@keyvan-m-sadeghi
what do you mean by

JavaScript needs a global Type object that other global types inherit from

everything in JS aready inherits from Object by default. Maybe I'm missing something here

[keyvan-m-sadeghi]

@obedm503
JavaScript doesn't have an equivalent of type() in Python. I was trying to describe the same effect with the Type global that I made up. We have the typeof operator, though due to being an old design, it evaluates to a string:

typeof 1.42
// "number"

typeof new Promise(resolve => {})
// "object"

In fact, now that you brought it to my attention, Object might be a more ergonomic candidate for implementing a python type() analogous mechanism (from a JavaScript developer's point of view, since we are already familiar with the likes of Object.assign). Here's how it'd look:

Object.type(1.42)
// Number()

Object.type(new Promise(resolve => {}))
// Promise()

The difference here is that an Object.type call returns the actual type, instead of a string.

By acknowledging that JavaScript already has types, we can proceed to type annotations:

function aFunction(aNumber: Number, unknown: Object): Promise {
    // function body
}

[lifaon74]

@keyvan-m-sadeghi

JavaScript already ships with types! Few people notice: String, Boolean, Number, Promise, etc

Wow, wow, wow, Number, String or Promise are not types ! They are functions/classes which allow to create instances or cast a type to another. Moreover using new Number() to create a number is a bad practice, but using it to cast a value to a number is fine (const value = Number(stringValue)). To detect a primitive type, typeofshould be used, and to detect if a variable is an instance of a class instanceof is used for (or compare constructor directly if you don't want a super class).

Notice than 1 instanceof Number evals to false, so Object.type(1.42) => Number() lacks of sense.
⚠️ A "number" is not a "Number"
You may know python's type, but all of this is possible in js. The syntax is just different.

---

What i'm pointing in my top first argument, is that types for javascript are far far more complicated than you could imagine due to the versatility of javascript, no spec sheet would be able to cover it a the first round, probably hundreds will be needed. Typescript add an huge amount of improvements for each of its releases which appends frequently. Integrating types at the level of TC39, would be really longer and error/regression prone. Some types are pretty hardcore, as an example: Array.flatMap (due to its type's recursivity)

[keyvan-m-sadeghi]

@lifaon74
It's arrogant that you assume others are not aware of how to do simple things in JavaScript. No worries though, I personally like arrogance! (So long as it doesn't become ignorance)

Now that we're at it, give this a try:

typeof (new Number(2) + new Number(3))

You have decided to call it a bad practice, it's perfectly valid JavaScript.

Historically, JavaScript incrementally integrated concepts like classes, generators and Promises. Along the way TC39 invented things like Symbol.iterator and whatnot. TC39 is still well capable of inventing new stuff. To incrementally integrate a mechanism like Python's type(), TC39 can invent things like Symbol.type and assign it even to a function such as Promise.

instanceof operator can coexist alongside something like Object.type, you can then decide to do things the old way or the new way. Just like you can decide to implement a class by prototype or the class keyword (which again, TC39 has invented).

note Substitute "standardized" for "invented" , since that's what's really happened

---

About your note on hardcore types, you are absolutely right. Even Promise<T> is a hardcore type. That's why I think the solution proposed by @samuelgoto is genius. JavaScript built-in types can only go so far, competition in types is well ahead just like you mentioned. However, something along the line of Object.type might go a long way for many simple use cases. For complex ones, this proposal is my personal favorite (as a library author who needs to accommodate both TypeScript and JavaScript).

[lifaon74]

@keyvan-m-sadeghi
I wasn't trying to be arrogant, just pointing out some strangeness, because you din't do the distinction between "number" and "Number", even if I assume you knew it. (new Number(2) + new Number(3)) evals to 5 because every operation will try to cast an object to a primitive (here though .valueOf()) so we may rewrite it like this (new Number(2).valueOf() /*2*/ + new Number(3).valueOf() /*3*/ ) as "evaluated" by the browser.

Now, if Object.type(1.42) => Number what about : Object.type(new Number(1.42)) => ???
Moreover, it is a bad practice, because the environment use under the hood int/float for numbers and objects for Number which require a cast for each operations... something extremely bad for performances. Valid code doesn't mean good code.

BUT maybe you wanted to express something different, something not currently in the definition of this proposal (as i understand it). In this case, don't hesitate to create a new issue, this one is not intended to discuss about Object.type, but to point the hardness of such a proposal where typescript for example do it just right.