Ecma262: typeof([]) is object

Created on 27 Aug 2017  路  15Comments  路  Source: tc39/ecma262

typeof([]) is object.

This should return array. There should be a deprecation of the current typeof and an alternative by name like typeOf to be considered.

Reason: This poses a confusion for the new devs and generally its array in other languages.

feature suggestion

Most helpful comment

typeof null being object is understood to be a bug, but its long history has made it hard to fix. on the other hand typeof [] being object is consistent with the language鈥檚 value model. With the exception of the null/function quirks, think of typeof as "what _primitive_ type is this?". Array is not a primitive type in ES, rather it鈥檚 a subclass of Object. The distinction between _types of objects_ (meaning: from what does this object inherit?) is generally done with instanceof. The prototype chain for arrays is at minimum Object > Array.

[] instanceof Array; // true
[] instanceof Object; // true

All 15 comments

I think it will not be changed, but you can use Object.prototype.toString.call:

Object.prototype.toString.call([]);
// "[object Array]"

an array is an exotic _object_ in JS. It's still in an object, and as other built-ins we can roughly say its primitive _type is an object_, but also an _instance of the Array constructor_.

JS is not really versioned in its most important environments - Browsers - so any change here would break the web as so many code already rely on this operation and the respective return.

There are other ways to verify the instance, like instanceof or Object.getPrototypeOf. The typeof is not the one to proper check for other built-in or custom Objects.

@gskachkov There are a plenty of alternatives which are unstraightforward but IMO a better alternative like typeOf should be implemented

@gskachkov: (...) a better alternative like typeOf should be implemented

why? Isn't Object.getPrototypeOf reasonable enough to identify the immediate constructor?

@leobalter Its not straight forward and typeOf is more readable.

@leobalter I understand deprecating or changing typeof breaks a lot in the web. I am just stating a more readable alternative to be provided for the future IMO.

Array.isArray is the straight forward and reliable way.

For the specific case of arrays, there is Array.isArray()

For other objects, there are the instanceof operator, the constructor property, etc.

If you want to propose yet another way to identify object type, the proper venue is the es-discuss mailing list, as stated in https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#feature-requests

@robpalme Yes Array.isArray() looks like a more direct way but is that a proper alternative when you wanna check and verify types at places? For example it's pretty straight in other languages

@claudepache Thanks for the info. Will do it.

So I think it should be deprecated or not recommended using the typeof operator because it does not make sense.

It makes perfect sense - an array is an object. The only object typeof behaves differently for is functions, because of the [[Call]] internal slot.

I'd ask a better question: why do you have an API that can accept a value that's either "an array, or not"? If you expect an array, use Array.isArray() - and throw or default if you don't get one.

What's the possible use case for where you need to use typeof to generically determine the type of something, where you care that it's an array, but you also don't care whether it's a Date, RegExp, Map, Set, Promise, Object.create(null), HTMLElement, instance of any userland constructor, or boxed primitive?

@ljharb I perfectly agree that Array.isArray() is good but when you come from other programming languages where you use typeof determine if its an array or not. It is weird when you get it as an object in javascript. I consider it as a matter of learning. I get that there is a workaround but is that the right way is my question.

It certainly is a matter of learning, but "language X isn't like language Y" isn't necessarily a flaw in either language.

If you have a use case where you think having typeof return "array" is necessary, I'd love to hear it - I've never seen one.

@ljharb As I said it is not a matter of use case, hence am not pursuing this further. I was just making a statement for the ease of usage by people. It just doesn't feel its right to have array and null having typeof as object.

For Example: https://stackoverflow.com/questions/8511281/check-if-a-value-is-an-object-in-javascript

check this discussion on how people are confused.

typeof null being object is understood to be a bug, but its long history has made it hard to fix. on the other hand typeof [] being object is consistent with the language鈥檚 value model. With the exception of the null/function quirks, think of typeof as "what _primitive_ type is this?". Array is not a primitive type in ES, rather it鈥檚 a subclass of Object. The distinction between _types of objects_ (meaning: from what does this object inherit?) is generally done with instanceof. The prototype chain for arrays is at minimum Object > Array.

[] instanceof Array; // true
[] instanceof Object; // true
Was this page helpful?
0 / 5 - 0 ratings

Related issues

AlexSHoffman picture AlexSHoffman  路  3Comments

bkardell picture bkardell  路  3Comments

ENvironmentSet picture ENvironmentSet  路  5Comments

jorendorff picture jorendorff  路  4Comments

codehag picture codehag  路  3Comments