Re: Object.safeAssign

Can you explain or support your assertion of "increased prevalence"? On Fri, May 1, 2020, 05:51 Mike Sherov wrote: > Given the increased prevalence of prototype pollution vulnerabilities in > many popular javascript libraries, is it time to reconsider the fact that > Object.assign allows for

Re: Conditional assign operator

What I've long wanted is an assignment operator which evaluates to the pre-assignment value of the LHS. You know, sort of like `a++` evaluates to the pre-incremented value of `a`. We could call this this "post-assignment" operator. Has anyone ever proposed that? ``` let a = 1; console.log(a =^=

Re: [Proposal] Optional spreading

Wouldn't simply making array spreading ignore nullish values be backward compatible? Unless one imagines that people are depending on this being an error somehow. On Sat, Feb 15, 2020 at 10:05 AM Jordan Harband wrote: > Since object spread already ignores nullish values, a syntax change would >

Re: Proposal: Property Accessor Function Shorthand

is familiar as > something's id from CSS selectors. > > > > We could also extend it to represent multiple parameters: # is also > aliased as #0, the 2nd parameter is #1, etc. > > > > Further, dynamic properties would work too: `const fooProducts = > products.filter(#

Re: Proposal: Property Accessor Function Shorthand

This is a great proposal which I hope can attract the support of the powers that be. The arrival of optional chaining seems to indicate a renewed interest in optimizing the way properties are accessed--which after all is a big part of what JS does for a living. Using `.a` to denote a function to

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

I don't understand how this would work. ``` for (const thing of things concurrency 5) { const result = await thing(); console.log(result); // <== what is `result` here, if the call to thing() hasn't completed? } ``` Also, it's intellectually unsatisfying that I can't specify concurrency for

Re: Proposal: `String.prototype.codePointCount`

Consider a language such as Kannada, spoken in sourthern India, and the 25th most widely spoken language in the world, with 60M speakers. "Characters" in the written language are represented in Unicode as elements (sometimes called "letters") which are then composed at the rendering level to

Re: Removing the space in `a+ +b`?

Personally I would reserve the `a ++ b` pattern for some future semantics for an infix version of the `++` operator, if anyone ever comes up with one. On Fri, Jun 28, 2019 at 12:37 PM guest271314 wrote: > > But more importantly, there is no point into searching for a solution > unless there is

Re: Re: Proposal: Selector/Select Expression

If the intent is to find the first entry with a truthy value for the `requestFrame` property, then the proposal is `array.find(.requestFrame)`. If the "wildcard" syntax is used, then it would be `array.find(?.requestFrame)`. On Thu, Jun 27, 2019 at 5:30 PM guest271314 wrote: > How can the

Re: Re: Proposal: Selector/Select Expression

Not exactly, since the optional chaining operator is `?.` with no space in between. On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia wrote: > Also, without a leading token, a selector expr with the optional chaining > operator inside a ternary operator would be ambiguous. > > ``` > > const

Re: Proposal: Selector/Select Expression

aultReturn) > } > } > > const getEmail = propDriller(['user', 0, "email'], defaultReturn) > > ``` > > > I'd have no objection to this whastsoever (and the above could be used as > a polyfill). But again, this is something that I think is a bit of a > niche use cas

Re: Proposal: Selector/Select Expression

Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors. Whether some codebase uses the new ```.prop``` syntax, or ```R.pick``` (from Ramda), or ```pluck("p")```. from RxJS, or some third-party or

Re: Proposal: Selector/Select Expression

Let me correct one thing. This proposal has nothing to do with ```|>```. > What I meant to say is that the two proposals are not interdependent or related, but since ```.p``` is to be a function retrieving the value of property ```p```, it can be used like any other function in a pipline, and

Re: Proposal: Selector/Select Expression

> In any event, re-read the proposal. Am certainly not opposed to the JavaScript language being capable of golf by default. Is the gist of the proposal to substitute ```|>```, and or ```.``` at ```const getEmail = .contacts.email;``` as the first character after ```=``` for `=>`, meaning the

Re: Proposal: Selector/Select Expression

is bound to recognize or adhere to any such > subjective and arbitrary criteria. > > What specific definition of "reliable" is being used, and what are the > cases that demonstrates using destructing assignment is not "reliable"? > > On Sat, Jun 22, 2019 at 6:50 PM B

Re: Proposal: Selector/Select Expression

On Sat, Jun 22, 2019 at 10:59 AM guest271314 wrote: > Does not destructuring assignment provide a means to achieve the > requirement? > If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

Re: Re: Proposal: Selector/Select Expression

Personally, I'm a huge fan of this proposal. It would integrate into the language the extremely frequent idiom of defining a pick/pluck like function. There is ample prior art in the form of Ramda's pick function .as well as `pluck` in RxJS. In fact, this exact

Re: Proposal: syntactic sugar for extracting fields from objects

On Fri, May 31, 2019 at 2:08 AM Cyril Auburtin wrote: > After thinking about it, the dot-notation is maybe confusing, because > > ```js > obj.{a} > ``` > looks like > ```js > obj.a > ``` > But the results are totally different > They are intended to look alike. The results are not "totally

Re: Proposal: syntactic sugar for extracting fields from objects

ity). > > IMHO just a `pick` function in the standard library would suffice most > of the problems that the syntax is trying to solve. Maybe something > like `Object.pick` or `Object.pickKeys` or > `Object.smooshIntoObjectTheValuesOf` > > Em qui, 30 de mai de 2019 às 15:43, Bob Mye

Re: Proposal: syntactic sugar for extracting fields from objects

> > On Thu, May 30, 2019, 14:24 Bob Myers wrote: > >> I don't know what "community" means, other than a bunch of people >> subscribing to this ML, and I can't imagine how one would define, or >> achieve, or identify, a "consensus" of that co

Re: Proposal: syntactic sugar for extracting fields from objects

I don't know what "community" means, other than a bunch of people subscribing to this ML, and I can't imagine how one would define, or achieve, or identify, a "consensus" of that community, or why or how the community would vote on anything, or what such the results of such a vote would mean. The

Re: Proposal: syntactic sugar for extracting fields from objects

notation (`{...{}}`). On Wed, May 29, 2019 at 11:27 AM Григорий Карелин wrote: > Well, I guess it might work too. > > I personally like more verbose constructions, with keywords instead of > dots, asterisks, etc :) > > On Wed, 29 May 2019 at 21:03, Bob Myers wrote: > >> On We

Re: Proposal: syntactic sugar for extracting fields from objects

On Wed, May 29, 2019 at 10:28 AM Григорий Карелин wrote: > Hi Cyril, > With the syntax you propose what would be the way to to this: > ``` > const source = {foo: 1, bar: 2}; > const result = {foo: source.foo, bar: source.bar, buzz: 3} > ``` > ? > As already mentioned earlier in this thread:

Re: Proposal: syntactic sugar for extracting fields from objects

> > ``` > let obj = {otherData: "other data"}; > ({firstName:obj.firstName, lastName:obj.lastName} = user.profile); > ``` > I don't understand this. > Alternatively there are various approaches which can be used to get only > specific properties from an abject and set those properties and

Proposal: syntactic sugar for extracting fields from objects

Similar proposals have been out there for years. For whatever reason, none have gotten traction. Under one proposal, your scenario would be ``` const obj ={...user_profile.{firstName, lastName}, otherData: 'other data'}; ``` https://github.com/rtm/js-pick-notation Bob -- Forwarded

Indexing HTML Attributes and Unique Indexes (Randy Buchholz)

Sounds like a job for decorators. `lit-element` provides something very close to at least part of what you seem to want (the getters and setters that is, not the indexing or "distinct" functionality). Bob -- Forwarded message -- > From: Randy Buchholz > To:

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal) (guest271314)

There is already a very well thought out list, although to my knowledge it has never been officially blessed, at https://esdiscuss.org/topic/ranges. Quoting: It seems odd that after all these years of discussions and meta-discussions about ES feature proposals, some people are still saying

Re: strawman proposal for base4 and base 32 integer literals

Why not used a tagged template literal, as in ``` base32`123EFG` ``` Bob On Mon, Oct 8, 2018 at 1:05 PM kdex wrote: > Sorry, but I highly doubt that it's worth reserving syntax for two bases > for > which even the author suggests their lesser usefulness. > > This is best kept in user-space.

return =

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 used all those years ago allowed an assignment to the function name to pre-specify a return value,

Fwd: Boolean equivalent to pre-increment and post-icnrement

In the stupid idea of the day department, for some reason I have felt the urge more than once in recent months for an operator which would invert the value of a boolean variable while evaluating to its pre-inversion value. For example: ```js if (bool!!) console.log("used to be true"); ``` The

Re: __line_number__ and __filename__

What does line number, or filename for that matter, mean when a file has gone through one or more transpilation and/or minification passes? Is the notion that the first processor that touches the file would substitute those values? Bob On Fri, Aug 24, 2018 at 11:34 PM Claude Pache wrote: > >

Re: !Re: proposal: Object Members

> `private`, `protected`, `class`, and a few other such keywords have all been part of ES since long be for the TC39 board got their hands on it. They hadn't been implemented, but they were all a very real part of ES. Whoa. Is that just misinformed or intentionally misleading? They have never

Re: [proposal] Object.pick

@Mikkel, My impression is that one can summarize the attitude of people on this mailing list and those involved in the language design process toward property picking as somewhere between "I don't care enough to worry about it" and "it doesn't belong in the language". To put it a different way,

Re: Promise capability support

evealing constructor pattern", one of which is by the person that invented it. Bob On Thu, Jul 26, 2018 at 3:13 AM Jordan Harband wrote: > It allows you to reveal things, selectively, just as the revealing module > pattern does. > > (separately, the measure of "caught on

Re: Promise capability support

t;revealing module" pattern is obsolete anyways, but it functions on > the same principle - using closures to reveal only explicit things instead > of everything. > > On Wed, Jul 25, 2018 at 10:01 AM, Bob Myers wrote: > >> Yes, I've encountered this "revealing construct

Re: Promise capability support

Yes, I've encountered this "revealing constructor" terminology and find it confusing. I hope it doesn't catch on. A lot of people are likely to try to associate it with the "revealing module" pattern, with which it actually has nothing in common. It's a strange term because this pattern, if one

Re: Promise capability support

I've used this pattern exactly twice in the large-scale app I'm working on now. One of those I was able to eliminate after I thought harder about the problem. The other I eventually replaced with the following kind of pattern: ``` function createPromise(resolver, rejector) { return new

Re: Ranges

It seems odd that after all these years of discussions and meta-discussions about ES feature proposals, some people are still saying things like: * there really needs to be * I'd really like * I'd love to have often without addressing a single one of the relevant questions: 1) *Is it sugar?* Is

Re: Shape objects

The engines already do these optimizations. On Sat, Jun 16, 2018 at 1:27 PM Cyril Auburtin wrote: > I wish JS had Shape objects, which would not only ease performance > optimization for the benefit of JS engines ( > https://youtu.be/5nmpokoRaZI?t=871), but also helps for validation, like > an

Re: Adding support for enums

You could wait three years for enums in JS, or you could just start using a statically typed flavor of JS which has had them for years. On Sun, Jun 10, 2018 at 2:51 AM Doug Wade wrote: > Hello friends! > > I had a bug the other day on my team. We use redux to > manage

Re: Overload str.replace to take a Map?

I'm not a huge fan of this idea, but just as a reference point, here is a routine to convert a string to using smart quotes: ```js // Change straight quotes to curly and double hyphens to em-dashes etc. export function smarten(a: string) { if (!a) return a; a =

Re: Proposal: Add a global Infinitesimal property

TC39 or from > non-members who have registered via Ecma International,", for one, but in > practice, inclusion into the proposals repo requires involvement > (championing or otherwise) from a TC39 member. > > On Sat, May 12, 2018 at 10:24 AM, Bob Myers <r...@gol.com> wr

Re: Proposal: Add a global Infinitesimal property

> https://tc39.github.io/process-document/ This document says that there are no entrance criteria for Stage 0. In practice, however, when I attempted to add a proposal to the phase 0 list, via a PR to https://github.com/tc39/proposals/blob/master/stage-0-proposals.md, it was rejected based on the

Re: Re: Proposal: Conditional `catch` in Promises

What do you mean by "approach TypeScript"? Do you mean propose this feature to the TS team? TS is not about new language features (with a few exceptions). It's about typing. They're quite careful about not forking the language. > Not sure if that supports typed errors No, it doesn't. Bob On

Re: from ... import proposal

You can review the archives to see related/similar proposals/discussions, such as https://esdiscuss.org/topic/from-foo-import-foo. Bob On Wed, Apr 18, 2018 at 3:51 AM, devlato wrote: > Hello, > > sorry, I'm a newbie here, so maybe it's a wrong list. > What do you think about

Re: Re: from './foo' import './foo';

You're seriously underestimating how smart IDEs are or can be. Some IDEs are already suggesting the entire import statement when a symbol is used, based on what's in other modules, package.json, etc. There's no reason why an IDE can't auto-suggest the import name based on undefined symbols in the

Improved syntax for observable mapping and subscribing

Could someone jog my memory about proposals for better syntax for observable mapping and subscribing, if any? I'm getting really tired of writing ``` foo$.pipe(map(bar => mapper(bar))) ``` I would much prefer to write something along the lines of ``` stream function fooMapper(foo$) { while

Re: Function composition vs pipeline

> The point is that there is an unavoidable cost to the developer when features are added to the language. My apologies if that wasn't clear. You don't really need to argue that there is an unavoidable cost to new features. Few would disagree. And this cost is already taken into account in

Re: Expanding Object Shorthand

> Can anybody name the pitfalls or point to where they have been mentioned (if any have been)? The pitfalls have been mentioned in various responses on related threads over the last year or two. I will take a stab at summarizing them, with my response/comments to each. Apologies in advance if I

Re: Expanding Object Shorthand

I'm glad to see we are continuing to discuss this. It demonstrates some degree of interest in the community for this feature, some degree of need. With regard to Tab Adkins Jr.'s post: > You can just write: ``` var d = { a, b, c: e.c }; ``` Yes, we know that, of course. You could also

Re: Destructuring into object

I presume you've read the historical threads on this topic, which go back several years. Bob On Mon, Feb 26, 2018 at 11:04 AM, Alexander Shvets wrote: > # The Problem > > ES6 destructuring syntax isn't very readable and useful, especially for > assigning to properties of

Re: Suggestion: Destructuring object initializer.

matter, property spread syntax offers NEW optimization opportunities to the engines.]] Bob On Wed, Feb 14, 2018 at 2:37 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Wed, Feb 14, 2018 at 6:25 AM, Bob Myers <r...@gol.com> wrote: > > Actually, I did understand w

Re: Suggestion: Destructuring object initializer.

Actually, I did understand what he said. I didn't respond because it was obviously wrong. For example, I did a quick test comparing `[1, 2]` and `new Array(1, 2)` and found that performance was identical, in spite of the claimed inefficiency supposedly introduced by the need to look up `Array`.

Re: Suggestion: Destructuring object initializer.

); > // copies propertieslet b = { set x(v) { throw v }, ...{x: 0} }; > > > > On Tue, Feb 13, 2018 at 10:12 PM, Bob Myers <r...@gol.com> wrote: > >> Thanks for engaging. >> >> This entire little sub-thread, and my question about what nuance I was >&

Re: Suggestion: Destructuring object initializer.

ymbol for customizing object spread, but > it was ultimately rejected for reasons I can't remember). Also, the > optimizations would be much less speculative (you could perform them at the > baseline level for object spread with some effort, unlike with > `Object.assign`). > > On Tue, Feb 13, 201

Re: Suggestion: Destructuring object initializer.

Cool. I don't claim to fully understand this, but as I read your issue, it seems the optimization could/would apply to either spread properties OR `Object.assign` case. If that's true, then there's nothing specially optimizable about spread properties, in which case that particular point would NOT

Re: Suggestion: Destructuring object initializer.

Thanks for reading my post down to the part that caught your attention. Concerning this: > engines can optimize for objects that are not referenced elsewhere by not actually copying them, something harder to do with `Object.assign`.\* I'm intrigued; please elaborate. I had thought that `{...a,

Re: Suggestion: Destructuring object initializer.

> write a Babel plugin As far as I know, the plugin architecture to Babylon, Babel's parser, is not open, and the parser cannot be extended. What is open to regular people is the ability to write Babel plugins to analyze or transform the AST. The only alternative for new syntax at the moment

Re: Suggestion: Destructuring object initializer.

Thank you for your comments. The proposed picking syntax has gone through several iterations. Way back when, we had ``` o # {a, b} ``` for picking properties `a` and `b` from `o`, resulting in `{a: o.a, b: o.b}`. That, however, would of course eat a precious symbol. So a later version replaced

Re: Suggestion: Destructuring object initializer.

. If it really is that > important to you then put together a solid proposal, write a Babel plugin > and then try to find a champion for it. > > On Thu, 8 Feb 2018 at 14:05 Bob Myers <r...@gol.com> wrote: > >> It does make one stop and wonder why the group will endlessly ente

Re: Suggestion: Destructuring object initializer.

as much to the language at as little cost as many other features such as spread properties. Bob On Thu, Feb 8, 2018 at 4:15 PM, Bob Myers <r...@gol.com> wrote: > This extremely useful feature, which is sometimes called "picking", has > been discussed extensively on the g

Re: Suggestion: Destructuring object initializer.

This extremely useful feature, which is sometimes called "picking", has been discussed extensively on the group, but the "thought leaders" (?) who apparently have the ability to kill a feature by saying "I don't really think it's that important" have failed to get excited about it, although it

Re: Proposal: named and bound deconstructions

> Destructuring made it possible to flatten 3-5 lines to 1, along with the ability to provide defaults. Yet, as an aside, this "principle" of "flattening" being a sufficient or at least necessary condition for syntax proposals, is itself not applied consistently, as seen in the "rejection" (if

Re: async/await -> await/async: a simpler, less error-prone async syntax

It might be useful to consider the `ControlFlow` notion used in writing selenium tests. All the steps in a test routine, which appear synchronous, actually implicitly introduce the equivalent of promise/then structures. They took this approach because almost all such integration tests are

Re: A way to prevent properties to be added to an object if they are null or undefined.

The usual idiom is ``` Object.assign({}, couldBeNull && {couldBeNull}) ``` taking advantage of the fact that `Object.assign` skips over non-object parameters. I don't understand your proposed ``` let ret = {...({couldBeNull} : {})} ``` and it seems to be syntactically wrong, but if you want

Re: Definition mixins

gt; wrote: > On Sat, Nov 18, 2017 at 7:53 PM, Bob Myers <r...@gol.com> wrote: > >> I'm a JS programmer with more decades of experience than I care to >> mention, and follow developments in language design closely. Frankly, I >> don't understand what you are trying to ac

Re: Definition mixins

I'm a JS programmer with more decades of experience than I care to mention, and follow developments in language design closely. Frankly, I don't understand what you are trying to accomplish or why support for it needs to be in the language. I strongly doubt I'm the only one. Rather than spending

Re: Definition mixins

You should review the TypeScript approach to mixins: https://www. typescriptlang.org/docs/handbook/mixins.html. But more generally, mixins are a very specific, opinionated OO design pattern. They are probably misused more often than not. If you think that big class hierarchies were brittle and

Re: Shorthand for "function" keyword

Obviously we should use 퓕 or something like that. I'm sure it's been proposed, although I can't find it at the moment. Yes, I know all the reasons why that's a bad idea. But come on. Are you worried about typing more characters? Use an IDE with auto-complete, or snippets. Are you worried about

Re: Array.prototype.remove(item)

you're still in the portion of the array before the first element to be removed. On Fri, Nov 10, 2017 at 5:39 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Fri, Nov 10, 2017 at 11:41 AM, Bob Myers <r...@gol.com> wrote: > > > > What's wrong with this?

Re: Array.prototype.remove(item)

What's wrong with this? ```js function removeFromArray(array, pred) { let changed = false; let j = 0; for (elt of array) { if (pred(elt)) changed = true; else array[j++] = elt; } array.length = j; return changed; } ``` Bob On Fri, Nov 10, 2017 at 4:08 PM, Isiah Meadows

Re: Question of the Day: What about all this asynchrony?

I'm confused. You don't have time to read "The General Theory of Reactivity", yet (1) you have time to write this long, rambling email about your kids, and (2) expect people on this mailing list to spend their valuable time reading it? Please stay on topic for the list. Bob On Tue, Nov 7, 2017

Re: How it feels to learn JavaScript in 2016

If you don't like those features or the associated tooling, then don't use them. Meanwhile, other people will be using them to build reliable, well-engineered, large-scale, performant applications. Bob On Fri, Oct 27, 2017 at 10:57 AM, kai zhu wrote: > tc39 is partly to

Re: Extend Object Dereferencing

If your intent is to say ``` const a = {b: e.b, c: e.c, d: e.d}; ``` then the reception to such functionality (often referred to as "picking") on this list has been decidedly lukewarm, although I remain mystified why, since IMHO it is a common use case and syntactically straightforward. FWIW the

Re: Extend Object Dereferencing

Don't you just mean the following: ``` const {abc, xyz, qnc: {awj}} = obj; ``` On Wed, Oct 25, 2017 at 12:22 AM, Sebastian Malton wrote: > This could also be extended to help with cleansing objects. > > const abc = {cde, def, efg} = obj; > > Would create an object abc

Re: Consider date formatting

There are third-party libraries which are so widely-used as to be defacto standards. Bob On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel < michael.krie...@actifsource.com> wrote: > I would like to suggest to take up date formatting into the standard. > Either as optional format parameter on

Re: Proposal: result-forwarding ternary operator

Could you please clarify how the system would know that some random expression in the middle of something like this for/if construct should be treated as a sort of "return"? I can understand that the **last** expression in a block would be the return value, but how would it know that `x.foo` was

Re: Make comma at the end of line optional

Personally, I am annoyed by the extra typing required for spaces. I propose that we have a new kind of ASI: *automatic SPACE insertion.* For instance, you could then write ```js functionfoobar(){return42;} ```js On Wed, Sep 13, 2017 at 11:25 PM, Naveen Chawla

Re: Make comma at the end of line optional

Yes, ASI has been such a great success, let's extend it to commas. On Tue, Sep 12, 2017 at 8:00 PM, Алексей wrote: > Hi all > > Now we have a great syntax improvement that allows us to put comma at the > end of arguments lists, object and array definitions. So in multiline >

Picking (deconstructing) properties into object literals

Extending the ways we can construct object literals has been a sort of theme in JS language design recently, with shorthand object notation in ES6, and now spread properties. The motivations include conciseness and readability. With destructuring assignment, the community decided it made sense to

Re: Object.seal, read references, and code reliability

> by immediately pointing out the error. This does **not** "immediately point out the error". It would "point out the error" (by raising an exception) only f and when the code path involving the mistyped property name were actually followed. The thrown error might be swallowed in some contexts,

Re: RE: Object.seal, read references, and code reliability

; > On Mon, Aug 14, 2017 at 10:21 PM, Bob Myers <r...@gol.com> wrote: > >> > How could the compiler possibly know whether abc exists on foo? >> >> Sorry for not being clearer. >> It would know by means of appropriate type declarations/assertions. >>

Re: RE: Object.seal, read references, and code reliability

+1 781 684 2294 • m: +1 315 527 4764 • w: > http://www.rocketsoftware.com/ > > From: Bob Myers [mailto:r...@gol.com] > Sent: Monday, August 14, 2017 11:55 PM > To: Alex Kodat <ako...@rocketsoftware.com> > Cc: Jerry Schulteis <jdschult...@acm.org>; es-discuss@mozilla.org > Subj

Re: RE: Object.seal, read references, and code reliability

Is there some reason this is not just a compile-time type check? Bob On Tue, Aug 15, 2017 at 4:16 AM, Alex Kodat wrote: > Agree, lock’s not a good name. That was just a dumb name because I was too > lazy to think of something better. Other names that come to mind

Re: Removal of language features

Some comments on various posts in this thread: 1. Asia has more than four billion people. Can we please avoid making generalizations about the level of competence of engineering managers in that region to make risk/benefit trade-offs? 2. I don't understand the TC39 process, but I am guessing

Re: Removal of language features

Let me weigh in as an Angular programmer. Angular does not "encourage use of non-standard and/or unstable language features". It encourages (indeed for all practical purposes mandates) the use of TypeScript, which like it or not is a perfectly well-defined language. The TypeScript designers walk

Re: Array.prototype.tap

```js Object.defineProperty(Array.prototype, 'tap', { value: function(fn) { fn(this); return this;} }); ``` On Mon, Jul 17, 2017 at 12:15 AM, Logan Smyth wrote: > You could always hack it and use the third argument :D > > ``` > var tap = f => (v, i, arr) => { > if (i

A twist on functional operatorsr

The proposal to write `arr.reduce((+))`, with `(+)` as an alternative to `(a, b) => a + b` is admirably concise, but syntactically challenging. I propose an alternative which is slightly less compact, but hopefully more implementable and general. The idea is a new form of function we'll call a

Re: Roman numeral support in Number type

Can we also support Maya numbers ? [image: Inline image 1] They apparently do have a zero, the shell glyph which looks like [image: Inline image 2]. Newlines matter; each new line is multiplied by 20. Inexplicably, these glyphs do not yet seem to be

Declaration types inside destructuring declarations

Totally minor, but ``` const {a, b} = o; b = 1; ``` Complains that `b` is `const` and can't be assigned. ``` let {a, b} = o; b = 1; ``` Now lint complains that `a` is never modified, and ought to be `const`. So I would like to write: ``` const {a, let b} = o; b = 1; or alternatively

Re: Allowing object field name shorthand

On Thu, Jun 22, 2017 at 10:23 PM, Sebastian Malton wrote: > In my opinion the notation of {"n.b": 1} should equate to {n.b: 1} so that > object field retrieval is consistent. That's a hugely breaking change. ___ es-discuss

Re: Object Extract Method Suggestion

This has been discussed at length. You can search the archives for "picking" or "pick notation" or "destructuring into objects". There are several proposals. No one seemed too interested, although to me it's a mystery why, since it would be one of the more useful language features I can think of,

Re: Question ... perhaps a proposal: extract from object to object

This has been discussed ad nauseum, in this thread and elsewhere. Some people call this "picking", or "deconstructing into objects". There seems to be little appetite for taking it up, in spite of it being (IMHO) a very

Re: Array Comprehensions

On Tue, Feb 7, 2017 at 6:58 PM, David Bruant wrote: > At the very least, the proposal will be listed in the stage 0 proposals > list [3]. My understanding is that a champion is required even to become stage 0. ___ es-discuss

Re: Short Comparing proposal

If you're worried about short-circuiting, then ``` [() => a, () => b].some(x => c === x()) ``` On Sat, Feb 4, 2017 at 12:29 AM, T.J. Crowder <tj.crowder@farsightsoftware. com> wrote: > On Fri, Feb 3, 2017 at 6:51 PM, Bob Myers <r...@gol.com> wrote: > >&g

Re: Short Comparing proposal

If you're worried about short-circuiting, then ``` [() => a, () => b].some(x => c === x()) ``` On Sat, Feb 4, 2017 at 12:29 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Fri, Feb 3, 2017 at 6:51 PM, Bob Myers <r...@gol.com> wrote: > >&g

Re: Short Comparing proposal

I'm puzzled about what's wrong with the good old `[a, b].some(x => x === object.property.secondProp)`. If you insist on sugarizing this (but why?), then it could be `[a, b].some(=== object.property.secondProp)`, or even `[a, b].||(=== object.property.secondProp)`. But again, why? If you really

Re: Destructuring object outside of var declaration

I thought it was ``` ({x, y} = obj); ``` On Sun, Nov 13, 2016 at 11:58 PM, Thaddee Tyl wrote: > On Tue, Sep 17, 2013 at 4:27 PM, Brendan Eich wrote: > >> Nathan Wall > >> September 17, 2013 10:06 AM > >> I'm wondering

Re: Another statement expression-related proposal

Just a random thought, but would `{= =}` work for expression blocks? ```js // plain block const foo = {= let a = 1; a =}; assert.equal(foo, 1) // if-else let cond = false const bar = {= if (cond) "hi" else "bye" =}; assert.equal(bar, "bye") // try-catch let e = new Error() const error = {= try

Re: expanding comments proposal

Perhaps you could clarify your proposal, because I for one don't get it. Are you talking about some new, additional commenting/pragma mechanism? Are you talking about some kind of extension to existing comments, like triple slashes? You say new pragmas are a bad idea--yet isn't that what your

  1   2   >