On Mon, Jul 24, 2017 at 11:39 PM, Tab Atkins Jr. <[email protected]> wrote:
> Yeah, thus the "often". ^_^ :-) > It's been done a few times in DOM land iirc. Nothing's coming to mind, but I haven't watched DOM as closely as JS. It'd be interesting to know what was done, when. > 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. Not necessarily, you could be testing for any falsy value, etc. Yes, it's rare, but it's not limited to Promises either. People seem obsessed with avoiding having multiple statements if they can get away with one, even with code that makes no semantic sense; I've seen this kind of return from methods many times: ```js if (someCondition) return somethingKnownNotToHaveAReturnValue(); ``` ...where `somethingKnownNotToHaveAReturnValue` is frequently `console.log` or `alert` or even `someArray.forEach`. Changing the return value of `forEach` would change the return value of code doing this with `forEach`. (I confess a small part of me *wants* to break that code. But it's a small part, and I'm not proud of it. :-) ) Concise arrow functions have made it even more common by making it more hidden; the promise `then` handler was meant just as an example of a concise arrow function doing this. For my part, I think `forEach` is too deeply entrenched with its current return value to get a new one. But "thinking" is just that; proper research would need to be done. -- T.J. Crowder _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
