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...

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.

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...

Afaik, enumeration order should be generally interoperable now.  I think the only real problem is order of numeric keys relative to non-numeric?

> 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.

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...

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.

Good point. In that case maybe dictionary<EventListener> is better syntax.

(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 };

In http://fetch.spec.whatwg.org/#headers-class 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?

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.

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 http://heycam.github.io/webidl/#es-union 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....)

The other thing we need is unrestricted dictionaries with some preset members for web animation. Sam Weinig dubbed these half-open dictionaries in https://bugs.webkit.org/show_bug.cgi?id=158509#c14.

Strawman elaborate syntax:

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

Shorthand:

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).

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?

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 http://heycam.github.io/webidl/#es-union, in order to prefer non-string types over strings. I can certainly do without it, but it does seem possible.

And note that the obvious way of doing half-open dictionaries doesn't match the processing model the web animations spec defines right now.

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.

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.

For everyone following along at home, https://github.com/heycam/webidl/pull/180 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.

Fixed by https://github.com/heycam/webidl/commit/1814384