Promises may reasonably resolve with `undefined` so I don't see good reason to special-case it.
I remain of the opinion that this is a simple type issue. You can't just take a function returning number and change it to return array-of-number and expect things to work, without refactoring the call sites. Alex On Wednesday, 5 August 2015, Tom Van Cutsem <[email protected]> wrote: > 2015-07-27 5:42 GMT+02:00 Dean Landolt <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>: > >> >> On Sun, Jul 26, 2015 at 8:07 AM, Benjamin Gruenbaum <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> > Out of curiosity, can you give an example of the Not Good parts? ISTM >>> the await prefix is more of an explicit cast than an implicit conversation, >>> and other than the very small timing gap in how throws are handled I >>> pointed out a few days ago, I can't think of any situations where a throw >>> would make more sense than casting values to promises. >>> >>> Sure, lots of such cases exist today with promises and are easy to >>> reproduce >>> >>> ```js >>> async function foo { >>> let result = await bar; // instead of bar(); >>> let result2 = await callbackFn(); // await on function that was not >>> "promisified yet", that is, it takes a callback >>> let result3 = await [p1, p2, p3]; // people might expect a >>> Promise.all on an array, but this doesn't actually wait for anything. >>> } >>> ``` >>> >> >> The first example is a basic type error, not at all specific to promises >> or async programming -- it could be made any number of ways. If you want to >> call it a footgun, that's fine -- but ISTM the only real solution is "use >> TypeScript" (or some analog). >> >> I don't see how the last example could possibly exist today as it >> reflects a hypothetical user's misunderstanding of `async/await` syntax >> specifically. Perhaps there's a case to be made that there's a footgun here >> (though I'd disagree), but it's beside the point of this thread. >> > > I recently found out that a popular async cflow library for node based on > generators, co <https://github.com/tj/co> does allow one to "await" > (yield) an array, with the semantics that Benjamin alluded to (Promise.all > synchronization). At least it indicates that this is not a totally > unrealistic expectation on behalf of users. Personally I think > automatically Promise.all'ing arrays is a bit too implicit, but I can > understand why people find it appealing. > > >> But the second example, `await callbackFn()`, seems reasonable. I still >> think it would be a shame to punt on otherwise elegant ergonomics just due >> to this, but I buy that there's at least some benefit now. >> > > Speaking from experience with a programming language I was involved with > called AmbientTalk, which has JS-style Promises, we did run into this issue > and we had a pragmatic way of solving it. Translated into the context of > this discussion, what we specified is that `await undefined` would raise a > runtime error, while `await any-non-promise-value` would coerce the > non-promise value into a resolved promise and await that promise instead. > > At first sight, it might feel awkward for `await` to special-case > `undefined`, but given that it is JS's implicit return value, I suspect it > would catch a lot of errors of the type Benjamin described above. It's a > pragmatic way of dodging the footgun without completely breaking the > symmetry between await and Promise.resolve. > > Cheers, > Tom >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
