Re: [heycam/webidl] Allow extended attributes to apply to types (#286)

No problem on the delay.

> One question I do have up front: what is the behavior you're actually aiming for with the patches applied.

(Yes, the commit message needs work.)

The basic idea is that the three extended attributes [Clamp], [ExtendRange], and [TreatNullAs] can now only be used on types, instead of in their previous positions as annotations on method arguments, attributes, and dictionary members. And they should only be usable in positions where they affect conversions from ES to Web IDL. (Hmm, now that I put it that way, maybe we should grammatically disallow them on non-readonly attributes.)

This adds the new concept of "types annotated with extended attributes". That is, `[Clamp] long` is a new type, consisting of `long` "annotated with" `[Clamp]`.

In the spec, we say that the sections on the types like `long` also govern versions generated by extended attributes, and then the algorithm for converting ES to `long` says "if the type is annotated with [Clamp]".

I couldn't really find a formal model for "is annotated with"; it's used elsewhere without any real precision. (E.g., there is no set of annotations on a given grammar production or construct that we consult. I guess this is what leads to problems like "what happens if you specify `[SecureContext]` on a mixin or partial interface?") Maybe I could achieve something more precise by studying the nullable types more.

> Will take some thought to check whether expressing interactions like "not both [Clamp] and [EnforceRange]" works right in that setup.

This again hinges on the "annotated with" concept. We just say "a type cannot be annotated by both [Clamp] and [EnforceRange]". If we are comfortable with leaving the definition of "annotated with" vague, we're good to go, but are we? For example, it's not exactly clear how "annotated with" propagates through typedefs. Again maybe I can study how nullable propagates through typedefs.

> That's fine, I think. ReturnType definitely shouldn't have attributes. Then again, ReturnType is already separate from Type, so we don't really care about this part.

What I meant is, I could have just changed Type, except then ReturnType would inherit the changes, and we don't want that. So that's where there are distinct grammar productions.

> There are other places where types probably shouldn't have attributes (at least not the attributes we're defining). For example, callback argument types, right?

Good catch, thanks. Will fix.

> I'm not sure what you mean. Your grammar has "ExtendedAttributeList UnionType Null" as a possible thing for TypeWithAttributes, right?

Oh, oops. I guess I meant I didn't allow specifying annotations on individual types inside a union, e.g. `(Node or [Clamp] long)`. Probably I should...

> Hmm. So we could support the old syntax, in theory, for attributes. As you note, it would be complicated.
>
> In practice, TreatNullAs is ony used in a few specs: HTML, CSSOM, DOM. Updating them would not be a huge deal. I see ~40 places in Gecko's IDL using this annotation, which is not so bad to just update en-masse.

This is the same issue as https://lists.w3.org/Archives/Public/public-script-coord/2017JanMar/0009.html, correct?

And yeah, I think we should bite the bullet. En-masse update for TreatNullAs, Clamp, and EnforceRange.

>> Can we nuke that part of the spec?
>
> I think so. I see no consumers in Gecko either, and we really shouldn't add new ones, imo.

Great. Maybe I'll do that as a separate PR first.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/286#issuecomment-275309628