Allow ReturnTypes to have extended attributes associated with them

[samweinig]

It is not currently possible to directly specify extended attributes for an operation's return type. One could work around this by using a typedef (e.g. typedef [Clamp] long Clamped; Clamped foo(); ), but it feels like an oversight that you can't do it directly.

[bzbarsky]

What would that even mean? I guess that could be meaningful for a callback or callback interface, but not for a normal interface, right?

Is this a followup for #286 ?

@domenic

[domenic]

Yeah, this is a follow-up. In #286 you said "ReturnType definitely shouldn't have attributes" but it's not clear exactly why. I guess because no conversion is applied in that direction, for non-callbacks.

However, consider the case of the planned [AllowShared]. It seems weird to have Uint8Array foo() operation returning a SharedArrayBuffer-backed Uint8Array. Shouldn't you instead have written [AllowShared] Uint8Array foo()?

(The multiple natures of types in Web IDL---documentation vs. conversion helper---strike again.)

[samweinig]

Admittedly my example is contrived, and I agree, for the current set of extended attributes that apply to types, this is unnecessary. But as @domenic notes, for future extended attributes may make sense. So making the grammar work now seems worthwhile.

[bzbarsky]

In #286 you said "ReturnType definitely shouldn't have attributes" but it's not clear exactly why.

Because then the grammar would be ambiguous with attributes on the operation itself and become unparseable.

You can have attributes on the operation that get forwarded to the return type, sort of like the setup we have for dictionary members. That would be a reasonable thing to do.

[domenic]

Ah, right, that makes sense, and helps me understand what we could do. Do you have thoughts on the [AllowShared] case? Does it convince you we should do that?

[bzbarsky]

Doing that seems fine to me. Doing the [Clamp] thing for callback return values seems like a good idea too, fwiw.

[samweinig]

The more I think about this, the more I worry this syntax for type annotations is going to lead to a lot of confusion for spec authors and implementors. The distinction between needing to write:

void functionName([A] optional [B] long argument);

vs.

void functionName([A, B] long argument);

just because the optional is there, and understanding that B will apply to the type, while A applies to the argument itself, is all a bit hard (this is also true for dictionary members, where 'required' can split things, and now, for return types, where 'static' would presumably split things, I may have left another one out).

In the interest of covering the bases, were other syntaxes for type extended attributes considered? I can think of some mediocre ideas, that I admittedly have not fully considered in the face of the current grammar. Like, moving type extended attributes after the type.

void functionName([A] long [B] argument);

Or using a different delineator, perhaps repurposing the existing '<' & '>' if it is thought these would never be needed, or willing to have funky syntax for sequences / promises / records.

void functionName([A] long<B\> argument);

Or maybe braces?

void functionName([A] long{B} argument);

[domenic]

I can't say we considered anything else. I think it'd be pretty confusing to depart from the typical extended-attributes-go-in-square-brackets-before-the-thing-they-modify pattern. But it would indeed help avoid the need to "flow through" certain extended attributes from e.g. non-required dictionary members to their types. I'd be open to changing it if we really think it's compelling.

I agree remembering to do the right thing is a bit hard, but I'm hopeful that with proper validation tooling spec authors and implementers will get it right.

[annevk]

Is this still a problem?

[domenic]

I believe so.