SIMD values are not objects and probably shouldn't have internal slots

[ajklein]

See http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-language-types-symbol-type for how ES2015 gets around this restriction for Symbols. The key bit is:

"Each Symbol value immutably holds an associated value called [[Description]] that is either undefined or a String value."

Not sure if this is the best way to word it, but it seems like SIMD and Symbols should do the same thing.

[bterlson]

I guess to be consistent, primitive things with symbols should have that verbage (and also refer via the phrase "var's [[slot]] value" as opposed to "var.[[slot]]". Although I don't quite understand why this is necessary - slots are not an actual thing so nothing that I'm aware of prevents us from saying that primitives get slots too. @allenwb thoughts?

[allenwb]

@bterison It's mostly a matter of separation of concerns within the specification. "Internal slots" are defined 6.1.7.2 as something that is specific to the Object type so saying that some non-object value, such as a Symbol or SIMD value also had "internal slots" would be confusing. To clean that up,, the definition of "Internal slot" would have to me moved out of 6.1.7, probably into 6.1. I don't think that is really worth the necessary spec refactoring.

However, it don't see a problem with using var.[[Description]], etc. Just need to add a sentence saying that what that means.

BTW, upcoming "private state" for classes proposal builds upon concept of "internal slots", so it's probably a good idea to not conflate them with the internal components parts of value types.

[littledan]

OK, so I'll add a note to the draft spec where I introduce SIMD values (in section 6) to mention that they also have a couple internal slots, with that notation. When it's integrated into the main spec, we can decide whether that is promoted to 6.1 or left as is. Does this sound good?

As for private state: What if we just say, all JS values (primitives and objects) can have internal slots, but users can only define their own internal slots on their own classes?

[allenwb]

@littledan I don't think you should refer to them as "internal slots". "internal slots" should only be used with objects.

I think it's fine that you say that a SIMD value is a Record as you do in clause 5 of your proposal. But http://www.ecma-international.org/ecma-262/6.0/#sec-list-and-record-specification-type says that a Record is an aggregation of "named fields". So you should refer to [[SIMDTypeDescriptor]] and [[SIMDElements]], as well as the elements of the type descriptor as "fields" rather than "internal slots".

[littledan]

OK, sounds good.

[littledan]

They have fields now.