Re: Return value of forEach

[Naveen Chawla]

I've quite frequently required an `each` that returns the array, since I do
sequential transformations that involve forEach, map, filter, sort etc.

I would not overload `each` with any early termination, I would probably
have an `Array.prototype.takeWhile` method for that (which returns a new
array taking elements while the return value of the predicate is truthy).



On Tue, 25 Jul 2017 at 04:09 Tab Atkins Jr.  wrote:

> On Mon, Jul 24, 2017 at 3:31 PM, T.J. Crowder
>  wrote:
> > On Mon, Jul 24, 2017 at 9:58 PM, Tab Atkins Jr. 
> > 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

Re: Re: Add an easier method for slicing and stepping strings and arrays

[Jordan Harband]

Array slice already allows negative indexes. `arr.slice(-1)[0]` works fine
for a quick and dirty "last item".

On Mon, Jul 24, 2017 at 3:19 PM, Tab Atkins Jr. 
wrote:

> On Sun, Jul 23, 2017 at 12:36 AM, Darien Valentine
>  wrote:
> > Here are some related threads from the past:
> >
> > https://esdiscuss.org/topic/negative-indices-for-arrays
> > https://esdiscuss.org/topic/array-slice-syntax
> > https://esdiscuss.org/topic/javascript-language-feature-idea
> >
> > I think I’ve seen it mentioned a few other times too.
> >
> > The `arr[-1]` syntax is a non-starter I’m afraid, cause it’s just
> property
> > access. An array can already have a property with the key "-1".
> >
> > Personally I’d find it weird for slicing to be singled out for special
> > syntax. It’s just a method. However I’d agree that it’s quite awkward to
> do
> > things like `arr[arr.length - 1]` or `arr.slice().pop()` etc to access
> from
> > the right. I think in one of those threads someone proposed a method like
> > `Array.prototype.nth()` which would accept negative indices, though this
> > creates an odd asymmetry since (presumably) we would not want to use -0
> for
> > the last index.
>
> Yeah, -1 is the last index; it just does one round of "underflow"
> basically.
>
> > In general I think the functionality you’re describing could be useful
> but
> > that it could be served better by adding methods rather than syntax.
>
> Agreed. Slicing via Array#slice() can likely be extended to allow
> negative indexes, and even a third argument for steps to match Python
> (yay for the -1 step value, to get a slice in reverse!).  Adding an
> nth() that just takes a single positive or negative index would be
> nice.  That we still have to do `arr[arr.length -1]` is barbaric. ^_^
>
> (Only downside of negative indexes is that, when using it on
> iterators, you have to consume the entire iterator before you can
> return the desired value.)
>
> ~TJ
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Return value of forEach

[Tab Atkins Jr.]

On Mon, Jul 24, 2017 at 3:31 PM, T.J. Crowder
 wrote:
> On Mon, Jul 24, 2017 at 9:58 PM, Tab Atkins Jr. 
> 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

Re: Return value of forEach

[T.J. Crowder]

On Mon, Jul 24, 2017 at 9:58 PM, Tab Atkins Jr. 
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.

-- T.J. (er, the other one) Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Add an easier method for slicing and stepping strings and arrays

[Tab Atkins Jr.]

On Sun, Jul 23, 2017 at 12:36 AM, Darien Valentine
 wrote:
> Here are some related threads from the past:
>
> https://esdiscuss.org/topic/negative-indices-for-arrays
> https://esdiscuss.org/topic/array-slice-syntax
> https://esdiscuss.org/topic/javascript-language-feature-idea
>
> I think I’ve seen it mentioned a few other times too.
>
> The `arr[-1]` syntax is a non-starter I’m afraid, cause it’s just property
> access. An array can already have a property with the key "-1".
>
> Personally I’d find it weird for slicing to be singled out for special
> syntax. It’s just a method. However I’d agree that it’s quite awkward to do
> things like `arr[arr.length - 1]` or `arr.slice().pop()` etc to access from
> the right. I think in one of those threads someone proposed a method like
> `Array.prototype.nth()` which would accept negative indices, though this
> creates an odd asymmetry since (presumably) we would not want to use -0 for
> the last index.

Yeah, -1 is the last index; it just does one round of "underflow" basically.

> In general I think the functionality you’re describing could be useful but
> that it could be served better by adding methods rather than syntax.

Agreed. Slicing via Array#slice() can likely be extended to allow
negative indexes, and even a third argument for steps to match Python
(yay for the -1 step value, to get a slice in reverse!).  Adding an
nth() that just takes a single positive or negative index would be
nice.  That we still have to do `arr[arr.length -1]` is barbaric. ^_^

(Only downside of negative indexes is that, when using it on
iterators, you have to consume the entire iterator before you can
return the desired value.)

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Return value of forEach

[Tab Atkins Jr.]

On Sun, Jul 23, 2017 at 6:53 AM, Naveen Chawla  wrote:
> Does anybody have any opinion on a new Array.prototype.each method that does
> the same as forEach but returns the array, thereby allowing chaining with
> sort, map, filter etc., while also preserving backwards compatibility?

In general, functions returning undefined are *often* safe to switch
to returning a more useful value; this is one of the recommended
patterns for upgrading DOM code that uses callbacks to using promises
instead.  We should pursue that first.  ^_^

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Florian Bösch]

On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband  wrote:

> There's lots of other threads on why no new modes are likely to ever be
> introduced.
>

And here we see the language evolution committee in its natural habitat
setting itself the impossible goal to support everything every introduced,
still introduce new things, and do it all without versioning, forever. In a
thousand or a million or a billion years, JS will still be JS as it was set
into stone in the late 20th century.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Boris Zbarsky]

On 7/23/17 1:19 AM, Alexander Craggs wrote:

I also feel that it is *impossible* for vendors to add such changes to
make error messages more useful because in the JavaScript syntax
specified ten years ago "await" didn't exist and it would just be an
unexpected string.


Just to be clear, the "unexpected string" in your testcase is the "hi", 
not the await keyword.  Safari's error message, which I cited earlier in 
this thread, makes this much more clear than Chrome's.



We would have to add some new detection feature for
this newer flavour to allow better messages.


Again, no; see Firefox behavior here.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Boris Zbarsky]

On 7/23/17 12:30 AM, Alexander Craggs wrote:

Say we create such versioning, it would allow us to improve the language
so much more than we're currently able to, we'd no longer have to stick
with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }

Uncaught SyntaxError: Unexpected string


In Chrome, that's what you get.  In Firefox, you get:

  SyntaxError: await is only valid in async functions

which is about what you're asking for.  In Safari, you get:

  SyntaxError: Unexpected string literal "hi". Expected ';' after 
variable declaration.


which is a moderately more informative version of the Chrome error message.

In any case, it's quite clear that a JS engine _can_ report the "right" 
error here; Firefox does so.  Engines that don't do that should just 
start doing it, and this should not involve any spec changes.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Naveen Chawla]

Don't break the web.

Those who don't like old features just don't need to use them.

Applications that do use them would break!

If reducing the available feature set would increase performance then a
declaration to the browser to ignore deprecated features should be enough
to get this optimization, but only for this reason.

But do we even know that there is any performance gain for doing so?

I'm not bothered about browser code complexity to support old features - I
don't see that code anyway. I don't know to what extent other javascript
developers are bothered about it either.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss