what do you expect to be returned when you return a value not wrapped in a promise?Nothing that's a type error, it should throw a runtime exception just like all type errors in javascript, and it will show up in the debugger for the programmer to fix.
The ambiguity is actually the auto unwrapping of promises for subsequent then calls but I've yet to see a case where it's a problem (it's actually what makes the API clean looking when used).
I'm not sure I quite understand what you're referring to, but I think you mean the fact that you can chain then calls
Promise.resolve(5)
.then(x => Promise.resolve(x + 5))
.then(x => Promise.resolve(x + 5))
.then(x => {
// x == 15
});
This is totally sound behavior. The simplified signature of `.then()` is
then :: Promise a -> (a -> Promise b) -> Promise b
This makes `.then()` the `bind` function for the Promise monad. As a refresher for people who don't think about monads much:
(>>=) :: Monad m => m a -> (a -> m b) -> m b
While on this tangent, I'll note that `Promise.resolve()` is the `return` function for the promise monad:
return :: Monad m => a -> m a
Promise.resolve :: a -> Promise a
For your last snippet, I don't see an array so I don't know what ordering you want to preserveIt's a contrived example demonstrating how switching based on whether the return value is a promise can make hard to detect bugs. It's hard to come up with a short example for this because strange values turning up where they don't belong is a property of large, dynamically typed systems. So yes, the example doesn't use all the best practices.