Re: [Future] reject() value type

Le 08/05/2013 18:52, Domenic Denicola a écrit :
> I think the less constraining approach is reasonable, although I question whether you'd need much extra beyond just a general agreement that all DOM specs use DOMError as their rejection reason. Stated another way, I think if you implemented the `Future<TValue, TReason>` idea, all DOM specs would just end up doing `Future<TValue, DOMError>`, which seems kind of pointless.
Future<T> can be a shorthand for Future<T, DOMError>. The 2-param 
genericity can make sense if others define their API through WebIDL.

For a bit more context, the Future<T, DOMError> notation emerged of 
thinking about what types could be used as a .reject argument because 
how the value is used in the .catch depends on what type it is. And this 
kind of thing is usually part of the documentation; explaining the 
contract of a method. So this WebIDL notation is just a way to make 
explicit that the possibility is offered to people writing JS API. 
Whether it's encouraged or a good practice is a different topic, but 
there is no strong reason to fully prevent it I believe.

David