This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Now we have http://dom.spec.whatwg.org/#futures we should introduce friendly IDL syntax for them. In particular, the result of a Future should appear in the IDL without hacks. E.g. Future<Blob> toBlob();
I think it would be good to add the type of the error object in addition of the type of the succes object. Maybe this could have a default value in which case it would not be needed? http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0095.html
It's with a smile of happiness in my face that I noticed the following this morning [1] interface SubtleCrypto { // ... Promise<any> generateKey(AlgorithmIdentifier algorithm, bool extractable = false, KeyUsage[] keyUsages = []); // ... } IMO the most complete version should be "Promise<resultT, errorT>" where both the result and error type can be specified. Sweetened versions: * Promise<resultT> => Promise<resultT, Error> * Promise => Promise<any, Error> (not sure whether that should be Error or DOMError) Thoughts? [1] http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130625/#dfn-SubtleCrypto
Error does not work. Sometimes we forward exceptions to reject.
(In reply to comment #3) > Error does not work. Sometimes we forward exceptions to reject. Hmm... Does that means success and errors are asymmetrical? Is that a desired property?
I don't think it's necessary for reject to have a consistent type. It's for debugging.
Although I plan to make Error and DOMException the names of real types and not just exceptions, I'm not sure how useful it is to identify the rejection type and to type check it. So for the moment I don't coerce it (well, I convert it to "any" which is the "don't do anything really" conversion from JS to IDL values). https://github.com/heycam/webidl/commit/61403d1705384ed4bb9e15fd4dda319b96faf08a