Re: es-discuss Digest, Vol 140, Issue 26

> When replying, please edit your Subject line so it is more specific than "Re: Contents of es-discuss digest..." I have no idea which proposal you're talking about. On Thu, Nov 8, 2018, 08:18 Dan Aprahamian Is there a good way to get involved in the development of this proposal? > > On Thu,

Re: JSON.parse should be simple and idiot-proof

this is one tweet in a list that we want to sort by the "follower > ratio" of their creators: > > let creatorPopularity = tweet.user.followers_count / > tweet.user.friends_count; > > // (without parse-as-BigInt) → 0.65625 > > // (with parse-as-BigInt)→ 0n > >

Re: JSON.parse should be simple and idiot-proof

He was recommending a single parameter for "parse ints as bigints", not changing the default behavior. On Sun, Oct 21, 2018, 09:58 Richard Gibson wrote: > First, note that reviver functions *do* manipulate the result after it's > parsed. Second, "parse ints as bigints" is too big a

Re: strawman proposal for base4 and base 32 integer literals

You don't have nearly enough discussion of use cases. Without that, especially since `parseInt(str, radix)` already exists, this is unlikely to go anywhere. Also, your base32 system is inconsistent with how `parseInt(str, 32)` currently behaves, which further decreases the likelihood of it being

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

So are you saying that `return promise` and `return await promise` should have identical behavior in the context of an async function? Wouldn't that be a breaking change? And isn't it trivially solvable with a linter rule? On Sun, Sep 9, 2018, 13:29 Isiah Meadows wrote: > I know this requires

Re: Promise.finally not really final

function(iterable) { > // let allResolved = false; > let resolvedLength = iterable.length; > let promiseValues = []; > return new Promise((resolve, reject) => { > iterable.map( > promise => promise instanceof Promise ? > promise : Promise.resolve(pro

Re: Promise.finally not really final

) > On Fri, Sep 7, 2018 at 9:35 PM Peter Jaszkowiak > wrote: > > > > No, it doesn't make any sense. > > > > Do you not see the impossibility of this? If you have a promise `a`: > > > > You call `b = a.then(one).finally(done)` > > > > `b`

Re: Promise.finally not really final

;catch->finally with a callback but without a callback. Does > it make sense? > On Fri, Sep 7, 2018 at 9:24 PM Peter Jaszkowiak > wrote: > > > > There are plenty of ways of doing what you need without changing the > behavior of finally. Are you suggesting that calling finally make

Re: Promise.finally not really final

There are plenty of ways of doing what you need without changing the behavior of finally. Are you suggesting that calling finally make it so any other then or catch call just not execute? And are you also suggesting that this should climb up the chain of promises? On Fri, Sep 7, 2018, 13:16 Jon

Re: Enhancement of RegExp replacement

issue if we support this kind of feature. > > > > 在 2018年9月7日，下午10:13，Peter Jaszkowiak 写道： > > You do know that all capture groups are passed to the function, right? You > can write your second example like this, even though the capture groups are > totally useless: > > `

Re: Enhancement of RegExp replacement

You do know that all capture groups are passed to the function, right? You can write your second example like this, even though the capture groups are totally useless: ``` input.replace( /your (\w+) from (\w+)/g, (whole, a, b) => 'your book from amazon' ); ``` On Fri, Sep 7, 2018, 07:23 sion

Re: return =

Wow that's fanatically disgusting. Please no. On Mon, Sep 3, 2018, 12:27 Bob Myers wrote: > To continue the "stupid idea of the day" series, I have often felt the > need to indicate a return value other than as part of a `return` statement. > > Perhaps this is my BASIC background--the dialect I

Re: __line_number__ and __filename__

Did nobody see my email? There is already a mechanism in the works for exposing this kind of metadata: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta https://github.com/tc39/proposal-import-meta/blob/master/README.md On Fri, Aug 24, 2018, 07:56 Aaron

Re: __line_number__ and __filename__

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta On Thu, Aug 23, 2018, 16:57 Aaron Gray wrote: > I wondering what people think about the idea of proposing being able to > get the line number and filename of executing code in the code ? Maybe with >

Re: Question: HTTPS everywhere...problem

All of those are browser, not ES, apis. On Sat, Aug 4, 2018, 16:47 Zachary Yaro wrote: > I am not sure off the top of my head which officially require it in the > spec, but I know a lot of more recent APIs, including service worker, push > notifications, and geolocation, require HTTPS in some

Re: Re: [proposal] Persistent variables in functions/methods

This is just syntactic sugar for existing functionality. It is only useful for a single use case, one which is generally rare anyways, and easily accomplished when necessary. It provides like to no benefit in clarity, concision, or flexibility over existing solutions. It adds another way of

Re: [Proposal] Array.prototype.includes should evaluate object.toString and/or object.valueOf when determining a match

If you want to check properties or methods of an array of objects, you can use `Array.prototype.some`. On Wed, Jun 20, 2018, 12:27 Mike Simon wrote: > [Proposal] Array.prototype.includes should evaluate object.toString > and/or object.valueOf when determining a match > > The problem: > > If I

Re: Set functions

There is already a proposal for this. On Tue, Apr 10, 2018, 10:00 Mark Miller wrote: > Yes, please do! > > > On Tue, Apr 10, 2018 at 8:45 AM, Sebastian Malton > wrote: > >> I know that this has been brought up before but nothing seems to have >> come

Re: Array.prototype.repeat

I'm guessing this would be an appropriate polyfill: ``` Array.prototype.repeat = function repeat(count) { let output = this; while (--count) { output = output.concat(this); } return output; }; ``` On Sun, Mar 25, 2018 at 12:27 PM, Cyril Auburtin wrote: >

Re: Re: Explainer/Spec: Smart pipelines

> To clarify: The way that bare style and topic style are distinguished are not by the absence/presence of a topic reference. Bare style has a simple and strict syntax: any identifiers, separated by `.`s, optionally preceded by `new` or `await`. So `x['hello']` would not be valid? Seems pretty

Re: Function composition vs pipeline

ying to solve. but now that you're a bigger-fish with > bigger-picture integration i/o issues, doesn't this look alot like > technical-debt that no one will have a clue how to debug once a month > or two has passed? > > -kai > > On 3/11/18, Peter Jaszkowiak <p.jasz...@gmail.com&g

Re: Function composition vs pipeline

ulti arg and no-arg functions would still use `()`, and single arg > >> functions may or may not use `|>` depending on whether or not they may > >> prospectively use a pipeline. The composition operator doesn't supersede > >> the > >> `()` syntax in an

Re: Explainer/Spec: Smart pipelines

It looks like this is different to the existing pipeline proposal in essentially only one way, in that it includes the `#` token (or lexical topic as you call it). I like that the proposal addresses `await` and other unary operators by default since it supports any expression on the right-hand

Re: Proposal: then operator for easier promise manipulation

This operator doesn't make any sense to me. It has to know not only the immediate expression to its left and/or right like normal operators. It's **absolutely** not a unary operator, as it has to have information about every outer operator. It's almost an inverted operator in that sense. If

Re: Proposal: then operator for easier promise manipulation

Why not just use async/await then? Seems like if you were to replace `then` with `await` in your top example it would work exactly as you want (as long as it's in an async function). On Sat, Mar 3, 2018 at 1:06 AM, Bryant Petersen wrote: > I've put the details here:

Re: Function composition vs pipeline

I'd like to point out the partial application operator: https://github.com/tc39/proposal-partial-application Sounds like the combination of pipeline + partial application would result in what is essentially the same as function composition operator: ``` const h = ? |> f |> g; ``` Which results

Re: For-has-in loop

You could use Object.keys, Object.entries, or Object.values on the right side of `of` instead. On Feb 19, 2018 11:50, "Sebastian Malton" wrote: > I would like to propose that the following be valid since it is a very > common use case. > > ``` > for (const field has in

Re: Re: withBreak blocks

What kind of argument is that? ESlint isn't a JavaScript runtime, it is fully configurable, and I don't see how it's at all relevant. On Feb 17, 2018 14:52, "sagiv ben giat" wrote: > > Can you provide a clear use case that can't (or shouldn't) be covered > by what

Re: withBreak blocks

Also, you can just use `return` if you're in a function: ``` const doWork = () => { // try catch omitted for brevity const response = fetchData(); if (response.error) { log(response.message); return; } if (!response.data) { log("No data"); return; } if

Re: Proposal to add keyword "nowait"

This certainly doesn't sound backwards compatible. Also, this is something that type checking systems (like typescript and flow) are very good at catching. On Feb 11, 2018 22:41, "Александр Ефремов" wrote: > Sometimes when create the async functions forget to add await and

Re: Proposal: Map#assign

Isn't there a proposal for `Map#setAll`? That would fulfill the other use case. On Jan 18, 2018 12:24, "Oriol _" wrote: > > I believe there's a very simple way to do this today: new Map([...mapA, > ...mapB, ...mapC]). > > But this only works if you want to create a

Re: Do-Expressions Proposal Stalled?

In the issues for the proposal people are discussing making most statements capable of being used as expressions. Then the value of `do` is less important, but still necessary for some things: ``` const thing = if (cond) { a; } else { b; }; ``` Then you only need `do` to introduce a new block

Do-Expressions Proposal Stalled?

https://github.com/tc39/proposal-do-expressions It appears that the do-expressions proposal, which has a high amount of interest, is currently inactive. There haven't been any contributions from @dherman since September. This concerns me because the proposal is a hugely simplifying feature,

Re: Identifying pure (or "pure within a scope") JavaScript functions?

Seems like you're asking for a check for if the function is a closure. If it maintains references to variables outside the scope of the function. So would an `isClosure` function work for at least a little of what you want? On Dec 7, 2017 11:11, "Alex Vincent" wrote: > OK,

Re: Array.prototype.mapOn method

...@gmail.com> wrote: Can you elaborate? `mapOn` will apply the map only if the item passes the condition, `flatMap` has a different use case. I'm referring to this flatMap implementation: https://gist.github.com/ samgiles/762ee337dff48623e729 Cheers! Ahmad Bamieh, On Fri, Oct 27, 2017 a

RE: Compiled JS

Compiling JS into an intermediate representation like the JVM or LLVM isn't really possible because JavaScript is a dynamic language. That's my understanding anyways. The binary AST is as close as we can get. On Oct 24, 2017 23:43, "doodad-js Admin" wrote: > No WASM/AST

Re: Shorter syntax for arrow function assignment

It needs to offer more than two characters, and no confusing confliction with shorthand method syntax. On Oct 24, 2017 10:48, "kai zhu" wrote: > -1 > this fails styleguide sanity-check. > > we currently have 3 common styles of declaring functions: > 1. foo = function ()

Re: Re: Filtered Promise#catch

If you're going to distinguish between "ergonomic" and "easy" in the context of JavaScript development, you're going to have to define what you think the difference is. For something that should, imo, be used in almost every case that `catch` is used, I don't think that it just being ergonomic to

Re: Re: Filtered Promise#catch

True, it's a fairly trivial thing, but so is `Array.prototype.includes`. I can give a hundred other examples. There is a reason that so many people use underscore, ramda, lodash, etc: the "standard library" in Javascript is incomplete. We should aim to provide as many of these helpful utilities

Filtered Promise#catch

Excuse me if this has been discussed previously, I did try to find existing discussions. Bluebird has very useful functionality in `Promise.prototype.catch`, which allows for filtering certain error types. Here is an example: ```js database.get('user:Bob') .catch(UserNotFoundError, (err) => {

Re: Re: New Set methods - again

> its `forEach` method does call its callback with indices. This is incorrect. Both the `value` and `key` arguments are equal for Sets, equal to the current element in the Set. >From a different reply which I mistakenly forget to CC esdiscuss > True, Sets are technically ordered by insertion

Re: Re: New Set methods - again

Fri, Jul 28, 2017 at 6:57 PM, Peter Jaszkowiak <p.jasz...@gmail.com> > wrote: > >> > Out of curiosity, what is the rationale behind the choices for which >> non-set-specific, currently-array-only methods to implement? >> >> One rational is that these

Re: Re: New Set methods - again

> Out of curiosity, what is the rationale behind the choices for which non-set-specific, currently-array-only methods to implement? One rational is that these are also not Array-specific functions either, and serve as much if not more use with sets than with Arrays. I my experience, one of the