tc39
Naming conflict with WebIDL's record<K, V>
WebIDL has had record types for a number of years now—see 2.13.28. Record types — record<K, V> for the definition—and it's pretty confusing that the Record type in your proposal is so different from it. The web platform should be consistent in its use of the term.
This is related to, but distinct from, issues #82 and #96.
See also heycam/webidl#881.
I don't think we should constrain the naming of runtime types based on purely editorial names in a specification; if it's confusing, and Record is the best name for this proposal, then it might be advisable at that time for WebIDL to rename its record type.
Thanks for raising this, @hober . It's important that we think these interactions through.
In #96, there seems to be agreement among the TC39 delegates who commented that, while it would be a lot of work, it may be the best tradeoff to rename the ECMA262-internal "record" concept to something else, especially since it's not available to JS code.
Do you think such a similar tradeoff would be viable in WebIDL terminology as well, to be open to changing the name of WebIDL records, given that, from a JS developer's perspective, WebIDL records might be considered "just objects"? I'm encouraged by other transitions in WebIDL notation that have successfully landed over the past few years.
Do you think such a similar tradeoff would be viable in WebIDL terminology as well, to be open to changing the name of WebIDL records[?]
Maybe. That's why I filed heycam/webidl#881 too.
We are going to try to solve this issue before stage 3, that means either finding out if we can change WebIDL terminology or finding another name for this proposal (see #116). Additionally we just opened a TAG review for that proposal and mentioned that concern there: https://github.com/w3ctag/design-reviews/issues/518
Per #82 we are going to keep Record & Tuple. We intend to disambiguate in the ECMA262 spec by explicitly referring to "Record Primitive" as we discussed in https://github.com/tc39/proposal-record-tuple/issues/96#issuecomment-1178772411. Do you think something similar could be done in WebIDL?
I think a better bet for both specs is to change their Record concept to something else, since Record alone will now mean the primitive in every other JS context.
While I think it would be great for Web IDL to change the type name, it may be worth noting that Web IDL already has the potential to confuse people about things like this many times over if, for example, a reader expects Promise<T> values to be Promises (they’re PromiseCapabilities) or Web IDL’s ArrayBuffer type to be 1:1 with values that would pass ES ArrayBuffer’s brand checks (it can be a superset or a subset of them depending on its annotations). String types aren’t primitive in Web IDL; the bigint Web IDL type isn’t numeric; etc. Not saying it shouldn’t be updated, but it probably shouldn’t be blocking...
I agree, when opening https://github.com/whatwg/webidl/pull/1184 (that I need to finish working on the feedback...), we figured that there is not a major ambiguity between WebIDL Records and ECMAScript Records, at least as long as we contain ECMAScript Records in the ECMAScript interaction section...
It has been moved to a Stage 4 concern for the time being as it should still be solved down the line...
Since spec authors are always the bottom run of the priority of constituencies, spec names conflicting with runtime names must never be a blocking conflict, in HTML (i presume, lest they violate their own priorities) or JS.