RE: Extended attributes vs. new types

I've started working on this. One question in the nitty-gritty so far...

> But what we could do is have a TypeWithAttributes which is defined as
> "ExtendedAttributeList Type"  We could use TypeWithAttributes in almost all
> places where an ES-to-IDL conversion would be involved, except where a
> grammar production that can be preceded by ExtendedAttributeList can start
> with Type.  Looking through the grammar really quickly, the things that
> involve ES-to-IDL conversions and can start with Type would be
> OptionalOrRequiredArgument and DictionaryMember.  For those we could
> specify that certain extended attributes specified on the argument or
> dictionary member get propagated to its type instead.  In other places we'd
> use TypeWithAttributes instead of Type.

It seems the simplest thing to do is to just remove the ExtendedAttributesList that precedes such productions. You'd still be able to annotate the types with extended attributes, but not the arguments or dictionary members themselves.

As you noted below only [Clamp], [EnforceRange], and [TreatNullAs] apply to arguments or dictionary members. So as long as we allow those on the Type production, we can remove ExtendedAttributeList on arguments and dictionary members, I believe.

>
> (... snip ...)
> 
> > (Unless we banned extended attributes on parameters entirely? Are only
> > these type-applicable extended attributes currently used on
> > parameters?)
> 
> The extended attributes that currently apply to operation arguments are:
> [Clamp], [EnforceRange], [TreatNullAs].  The first two of those also apply to
> dictionary members, but [TreatNullAs] does not (though there's no obvious
> reason it can't).

Received on Wednesday, 25 January 2017 22:20:48 UTC