【新提案】通过一个新操作符来获取js标准内置对象实例类型

[aliarmo]

现状

目前我们获取js标准内置对象实例类型的方式有多种，比如 typeof，instance of，Object.prototype.toString

1. typeof 方式直接获取
   缺点在于对数组、null和对象类型傻傻的分不清楚，返回的值都是object
2. instance of 方式判断
   缺点在于对基本数据类型不能判断准确，如 2 instanceof Number 是false
3. Object.prototype.toString 方式提取
   有些也不能提取出来，如 Promise，Map，Set的实例类型

因此，如果有一个新的操作符，如命名为 datatypeof，能提取出所有js标准内置对象实例类型就好了，因为我们是获取标准内置对象实例的类型，所以 在标准内置对象中没法实例化的就被排除了，如 属性、函数属性、Math。js标准内置对象请看：点我

例子：
`
datatypeof 123 === 'number'
datatypeof "foo" === 'string'
datatypeof true === 'boolean'
datatypeof undefined === 'undefined'
datatypeof 1n === 'bigint'
datatypeof Symbol(123) === 'symbol'

datatypeof null === 'null'

datatypeof {}=== 'object'

datatypeof /foo/ === 'regexp'
datatypeof new Date() === 'date'
datatypeof new Promise()==='promise'
等等
`

[septs]

我认为大概率会被驳回

1. 除了 undefined / null 属于特例
2. 其他的类型判断取 Symbol.toStringTag 即可

倒不如吧 idea 变更为获取 Symbol.toStringTag 的一种 shorthand

e.g:

Symbol.getStringTag(....)

[LongTengDao]

遇到Proxy时，是穿透，还是返回proxy？

[septs]

Proxy 的设计初衷就是不希望被区分出来

[ljharb]

That's not really the intention of Proxy; the intention of Proxy is only to use it in combination with a membranes library, and in that scenario it should be possible inside the membrane to have a Proxy be indistinguishable.

In the absence of a membrane, a Proxy to a builtin, or to any class that relies on identity (using private fields, or using a closed-over WeakMap/WeakRef) is quite distinguishable as being one.

[LongTengDao]

另外是不是应该大写，否则无法区分new Number(123)和123

[septs]

逻辑上来说不应该区分两者

[ljharb]

new Number(123) is an object; the only thing that makes it special is that it has the internal slots of a Number.

If it's going to reveal the presence of internal slots, Symbol.toStringTag isn't appropriate, nor is anything that can be faked (in either direction).

[LongTengDao]

逻辑上来说不应该区分两者

要做就做彻底，不然一个补丁接一个补丁，语法进化没完没了了……那还不如用库了。毕竟是新增语法，肯定要收益足够大、效果足够彻底或许才有通过的一线生机吧。

[ljharb]

Logically, we must be able to distinguish internal slots, because that's how builtins work. Number.prototype.valueOf.call(x) will throw unless x has the internal slots of a Number, thus, we need a robust way to detect whether x has those slots.

There's no value in doing any other kind of detection.

[hax]

我记得之前会议上有讨论过 builtin 的 brand 问题，但是具体内容得翻翻会议纪要。