On Mon, Jul 24, 2017 at 3:31 PM, T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: > On Mon, Jul 24, 2017 at 9:58 PM, Tab Atkins Jr. <jackalm...@gmail.com> > wrote: >> In general, functions returning undefined are *often* safe to switch >> to returning a more useful value > > I think we'd struggle to prove it could be done safely. For instance, we'd > have to differentiate between all the places that did something like this: > > ```js > someDataPromise().then(data => data.forEach(entry => console.log(entry))); > ``` > > ...that *do* and *do not* rely on the fact that promise resolves with > `undefined`. (The above does not.) > > Hopefully, ones that do are few and far between. But webscale is massive, > "few and far between" can be an unacceptably high number. > > If there were an appetite for `Array.prototype.each`, I'd like to address > not just the return value but other issues with `Array.prototype.forEach` as > well (like step value, per-iteration updates of the index, stopping early > [using `some` or `every` is sometimes perfect, other times semantically > misleading]). I have some thoughts on doing that while retaining runtime > efficiency for the common case and code simplicity. But I doubt the appetite > is there.
Yeah, thus the "often". ^_^ It's been done a few times in DOM land iirc. Relying on a promise to resolve to undefined is probably quite rare; it would mean that you're explicitly testing for undefined on the far end. Much more likely, in situations like that, is just ignoring the resolution value, in which case switching it to an Array is fine. ~TJ _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
