Add the symbol type

[domenic]

Fixes part of https://www.w3.org/Bugs/Public/show_bug.cgi?id=27553. Fixes #301.

This will be necessary for whatwg/dom#469, as feedback in whatwg/dom#208 has been that we should restrict the type of the group to either a string or a symbol.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27553 also contains speculative stuff about interfaces declaring their own symbols which is not included here.

---

Preview | Diff

[annevk]

Should static Symbol objects also be exposed on instances or should we fix/change that behavior for Symbol objects?

[domenic]

Oh, hmm, I forgot people could start declaring constants of a type the moment we added the type. Interesting. I guess this solves more of https://www.w3.org/Bugs/Public/show_bug.cgi?id=27553 than I thought.

Yes, let me add that.

[domenic]

Wait, no, you cannot declare constant symbols yet. Since there is no way of representing a constant symbol value in Web IDL. So we are safe for now, and can expand to add that functionality later when needed.

[annevk]

Oh right, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27553#c4 declares a static and that won't have that issue. Okay.

[tobie]

This LGTM.

It does allow editors to add

interface Foo {
  static Symbol bar;
};

I imagine the purpose of Foo.bar would be limited to similar use cases as Symbol.iterator (i.e. a hook to get hold of a symbol), no?

If so, should we add some constraints as to how this can be used in practice? E.g. add to the static attribute section something along the lines of: Static attributes of type {{Symbol}} must be [=readonly=] and their value must always reference the same symbol.

[domenic]

It does allow editors to add

No it doesn't. It would have to be an attribute or readonly attribute. Which is indeed unusual, but I don't think it's something we should have special rules for.

If we want to allow Foo.bar for similar purposes as Symbol.iterator, we'll need a lot more work, as we won't want those to be getters---we'll want them to be data properties.

[tobie]

No it doesn't. It would have to be an attribute or readonly attribute. Which is indeed unusual, but I don't think it's something we should have special rules for.

Yeah, that's what I meant. Sorry for the sloppy WebIDL snippet.

If we want to allow Foo.bar for similar purposes as Symbol.iterator, we'll need a lot more work, as we won't want those to be getters---we'll want them to be data properties.

Oh… I hadn't thought about this.

So I guess we're good, then?

[domenic]

Probably, although I'm unsure if we should merge this until we have implementer support on whatwg/dom#469...

[tobie]

Well, it does solve #301 which needs fixing anyway and doesn't have a simpler fix afaik, no? If that's right, then we should go ahead and merge.

[domenic]

Good point, yeah.

[bzbarsky]

@domenic So I'm a little confused about this change. The grammar allows writing something like this:

void foo((symbol or long) arg);

but the processing model for unions (and overload resolution) seems to not know about symbols? I thought the idea was to only allow them to be passed via any, but it looks like syntax got added for them?

[domenic]

Yeah, it looks like an oversight.

The idea was to add actual syntax for them in support of whatwg/dom#469. But, that PR is stalled on implementer interest, so this hasn't seen any real use in the wild. As you can see from the above, we mostly merged it because it fixed #301.

Do you think we should fix up the oversights and add union and overload processing for symbols, or walk things back and remove the parts of this patch that aren't necessary for solving #301?

[bzbarsky]

No strong opinions either way.