This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20158 - Unrestricted typed dictionary
Summary: Unrestricted typed dictionary
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on: 16491
  Show dependency treegraph
Reported: 2012-11-29 14:54 UTC by Anne
Modified: 2016-10-17 15:40 UTC (History)
7 users (show)

See Also:


Description Anne 2012-11-29 14:54:32 UTC
For constructing URLQuery it would be nice to allow an object whose keys are strings and values are either strings or a string sequence, with no restrictions on what the keys have to be and such.
Comment 1 Boris Zbarsky 2012-11-29 16:09:33 UTC
How would you define such a thing interoperably?

Having explicit names for keys in dictionaries means that the IDL author also defines an explicit order on the keys.  But if you allow arbitrary names, what's the key order?  Note that key order matters when getters with side-effects are involved...
Comment 2 Tab Atkins Jr. 2012-11-29 17:30:37 UTC
Key order matters in general for this use-case, too, since the object gets translated into a series of set() calls on the URLQuery object, which maintains ordering internally.
Comment 3 Boris Zbarsky 2012-11-29 17:33:36 UTC
One option is to just say that key order is determined by the passed-in object and define that in the ES binding this is enumeration order.  Of course enumeration order on objects is not actually the same across UAs, and if you have the temerity to use numeric keys (including "2" and whatnot) you can't control their enumeration order at all in some ES impls and in the ES6 spec...
Comment 4 Tab Atkins Jr. 2012-11-29 17:38:02 UTC
Afaik, enumeration order should be generally interoperable now.  I think the only real problem is order of numeric keys relative to non-numeric?
Comment 5 Boris Zbarsky 2012-11-29 17:40:26 UTC
> Afaik, enumeration order should be generally interoperable now. 

It's interoperable for keys that don't look like numbers. There's pretty much no interop for the ones that do.  It's not just numeric vs non-numeric; the order of the numeric keys is different in different implementations, and sometimes within a given implementation for different objects.
Comment 6 Anne 2013-01-04 22:51:19 UTC
So URLQuery wants a dictionary that's a collection of string->string. Bug 16491 wants a dictionary that's a collection of string->callback.

Syntax proposal:

unrestricted dictionary { DOMString EventListener };

Using enumeration order and hoping that at some point ES will define that works for me...
Comment 7 Boris Zbarsky 2013-01-05 01:21:13 UTC
Are there ever use cases that want keys other than strings?  If not, it seems like all that's needed is a type for the value.
Comment 8 Anne 2013-01-05 11:57:20 UTC
Good point. In that case maybe dictionary<EventListener> is better syntax.
Comment 9 Robin Berjon 2013-01-07 09:58:31 UTC
(In reply to comment #8)
> Good point. In that case maybe dictionary<EventListener> is better syntax.

I tend to agree. But if ever there is a need for non-string keys, your initial syntax would need a separator to disambiguate:

  unrestricted dictionary { long long long };
Comment 10 Anne 2014-06-16 16:06:19 UTC
In I went with OpenEndedDictionary<ByteString> but I can definitely migrate to the syntax from comment 8.

I briefly discussed constrained keys with bz. It seems keys would mostly be DOMString, but FormData, URLSearchParams, and Headers all have usage for constrained keys. The first two want ScalarValueString, the last wants ByteString. We could do that in prose, but maybe we should allow the three string types at least?
Comment 11 Jeffrey Yasskin 2016-09-27 16:33:16 UTC
Web Bluetooth wants keys of type unsigned short in one case, and (unsigned long or <complicated constrained DOMString>) in the other. If we can do something that handles numeric keys and unions of a numeric and a string type, it would be awesome, but Web Bluetooth can also handle the key conversions in prose.
Comment 12 Boris Zbarsky 2016-09-27 16:41:54 UTC
You want your key conversions in prose anyway, I'd think.  If IDL were doing the conversion for you, then an unsigned short key, faced with this input:

  { hello: "I am here" }

would produce a key of 0, whereas I'm fairly sure your desired behavior is to skip this key altogether.

Oh, and the (unsigned long or DOMString) case would also not work as you expect, because the value would start off as a string in ES land, and will pick string over unsigned long given a String-typed input (but will coerce to the unsigned long if the union has no string types in it and the input is a String....)
Comment 13 Anne 2016-09-27 16:43:35 UTC
The other thing we need is unrestricted dictionaries with some preset members for web animation. Sam Weinig dubbed these half-open dictionaries in

Strawman elaborate syntax:

open dictionary<keytype, valuetype> DictionaryName {
  memberType member;


open dictionary<valuetype> DictionaryName;

would be short for

open dictionary<DOMString, valuetype> DictionaryName;

which is short for

open dictionary<DOMString, valuetype> DictionaryName {};

We could maybe leave out the open keyword and just rely the <> syntax to indicate this. Either seems fine.

keytype should probably be restricted to string and numeric types (or just string types).
Comment 14 Boris Zbarsky 2016-09-27 16:57:30 UTC
Or we could just do web animation in prose and not try to shoehorn it into here.  Unless we think others will want that sort of thing too?
Comment 15 Jeffrey Yasskin 2016-09-27 17:00:10 UTC
If we have numeric keys, would it make sense to support [EnforceRange]?

In order to have union keys, we'd have to use a different algorithm from, in order to prefer non-string types over strings. I can certainly do without it, but it does seem possible.
Comment 16 Boris Zbarsky 2016-09-27 17:01:32 UTC
And note that the obvious way of doing half-open dictionaries doesn't match the processing model the web animations spec defines right now.
Comment 17 Anne 2016-09-27 18:01:32 UTC
Fixing [EnforceRange] is bug 28834. I think the easiest thing to do here is to only deal with the three types of string keys (we have a couple of use cases for each) and leave other types of keys to prose. At least until the numeric key thing becomes more common.
Comment 18 Jeffrey Yasskin 2016-09-28 21:55:31 UTC
It works for me to not have numeric keys for now.

Looking at Anne's syntax, it doesn't let me have a field of open-dictionary type without also giving that type a name. Do y'all want that restriction?

If we initially don't need to support half-open dictionaries for web animation, and 2-token types give other people the same willies they give me, how about "dictionary<keytype, valuetype>", with the first argument defaulting to DOMString? I'm nervous about defaulting initial arguments, but it looks clear in this case.

I haven't looked into parsing this. Will re-using "dictionary" as a type instead of a type introducer cause problems? If it will, then OpenDictionary<key, value> could work.

In the future, if we want to add half-open dictionaries, would:

dictionary BasePropertyIndexedKeyframe : dictionary<(DOMString or sequence<DOMString>)> {
    DOMString          easing = "linear";
    CompositeOperation composite;

make people happy? We'd have to write an explicit rule to override "The identifier of a dictionary member must not be the same as that of another dictionary member defined on the dictionary or on that dictionary’s inherited dictionaries."

If nobody objects, I'll send WebIDL a patch to add this.
Comment 19 Anne 2016-10-13 06:35:48 UTC
For everyone following along at home, has a patch for this that is close to being finished. If you have any particular requirements, now would be a good time to air them.
Comment 20 Tobie Langel 2016-10-17 15:40:58 UTC
Fixed by