This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think the text around [NewObject] did not consider promise. Sometimes we always want to return the same promise, but sometimes it should always be a new one. If we want consistent annotation with [NewObject] / [SameObject], we should address this somehow. If I'm indeed correct we should probably also get http://www.w3.org/2001/tag/doc/promises-guide updated once this is fixed. For now, Fetch uses [NewObject] and Promise so you can see how it would look there. See bug 27507 comment 10 where Arkadiusz brought this my attention.
I think restricting [NewObject] to only things that return interface types is just wrong. 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. If no one gets to this before I get back from vacation in January, I'll fix webidl accordingly. > For now, Fetch uses [NewObject] Yes, please!
Does [NewObject] Promise<Foo> getMeAFoo(); mean that the Promise instance returned is always a new one, or that once the Promise resolves, that it resolves to an object that was newly created? Do we need new syntax to better describe the two alternatives?
It means the Promise instance returned is always a new one. Its fulfillment value might be the same as before. We could add more syntax to talk about the fulfillment value, I suppose... This quickly gets complicated. It's comparable to asking about this case: [NewObject] Element createElement(DOMString tagname); whether the various properties of the Element returned are newly created or preexisting (and the answer is that it depends; the .childNodes will be a never-before-seen object but the .ownerDocument will be the document you called createElement on). The only real difference is that in the Promise case there is a preferred internal slot we're talking about: the fulfillment value. But I think describing how it's filled in via prose is pretty reasonable...
createElement() returns a class instance and I think with my internal slots proposal we could define how that works. Promises however have no such way forward so they might indeed need some way to define this if we want to stop doing that in prose.
Let's roll this into https://github.com/heycam/webidl/issues/71