whatwg
[SameObject]/[NewObject] on Promise-type attributes should be allowed
Because Promise<T> types are reference types, the [SameObject] extended attribute should be permitted for use with them. In the current spec, they are forbidden by the restriction:
The [SameObject] extended attribute MUST NOT be used on anything other than a read only attribute whose type is an interface type or object.
(Unless Promise<T> is to be understood as an interface type.)
Sounds reasonable. What about linking it to http://heycam.github.io/webidl/#dfn-object-type and then adding promise types to that definition?
[NewObject] has the same issue; see https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605
I believe [SameObject] should also be applicable to union of interface types; the Service Worker spec certainly assumes that to be true.
In https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605#c1 @bzbarsky notes that this should not just be extended to promise types, but also
It should be allowed if the return value is any object type. Specifically, any interface type, "object", a promise, an Error, a DOMException, any buffer source type, or a union of types on which [NewObject] is allowed.
Seems the spec is clear that promise getters can't use [SameObject] and can use [NewObject]. I've filed a separate issue #1077 for non-promise objects since those aren't covered by the title of this issue. Seems that covers everything and this issue could be closed now.
I do have one related thought though:
Should promise getters be required to use [NewObject]? IIUC that's the behavior, and having [NewObject] would document the behavior much more clearly.
Should promise getters be required to use [NewObject]?
Was this meant to say [SameObject]? [NewObject] is only defined for operations and I assumed this was because that behavior is very problematic in practice for attributes. Neither is permitted by a Promise<T> attribute.
Although there is at least one existing quirk where this doesn't hold (valueAsDate), attribute getters that cause SameValue(foo.bar, foo.bar) to always be false (i.e., with no other code in between) tend to break JS expectations, sometimes catastrophically (e.g. the old Angular diffing algorithm).
"Can use [NewObject]" isn't true for any attribute currently, regardless of its type. [SameObject] does work with attributes but specifically forbids Promise<T> types. AFAIK it's for "fully permanent" values, i.e. never changing regardless of application state, not just never changing across consecutive accesses.
Was this meant to say [SameObject]? [NewObject] is only defined for operations and I assumed this was because that behavior is very problematic in practice for attributes. Neither is permitted by a Promise attribute.
No, I meant [NewObject]. (The title of the issue made me think attributes could have [NewObject].) I guess my understanding was overly simplified if even Promise typed attributes can indeed return the same Promise object multiple times. And it makes sense that they can.
In that case I think this issue can be closed as obsolete since it sounds like there are no outstanding changes to be made, wrt the title/original topic of this issue. #1077 tracks the issue about unions/objects/etc that was previously raised as a tangent of this issue.
Both of these extended attributes are a bit odd in that they are "pure" annotations describing high level API behavior. They have no corresponding effects in any Web IDL algorithms. They seemingly don't meet Web IDL's own definition for what an extended attribute is because they don't control behaviors that are specific to particular language bindings. That definition is likely just outdated, but like ... if you have found any of this confusing, you're right :)
they don't control behaviors that are specific to particular language bindings.
They actually can, though not in obvious ways. For example, in some JITs they inform things like common subexpression elimination behavior.
That makes sense. The distinction I meant to highlight was that they describe universal properties of the operation/attribute behavior itself. Contrast e.g. PutForwards, which is defined only in terms of ES binding behavior, where any other binding (unless given its own rules for interpretting that EA) just sees a readonly attribute.