Default values for nulls

I know I am not the only one who has had several perfectly good use-cases for default values disallowed, because the value coming in was `null`, not `undefined`. I cannot be the only one who has let bugs slip in because of failing to consider this case. So, if we can find a non-confusing and

Re: Proposal: Property Accessor Function Shorthand

At the cost of adding more code, but giving more power, perhaps what we want is something akin to Kotlin's `it` keyword: https://kotlinlang.org/docs/reference/lambdas.html?_ga=2.238822404.500195435.1575368476-1345353619.1575368476#it-implicit-name-of-a-single-parameter *it: implicit name of a

Re: Ternary operator enhancement proposal

I put forward a similar proposal a while back: https://esdiscuss.org/topic/proposal-result-forwarding-ternary-operator -- Dammit babies, you've got to be kind. On Wed, 13 Nov 2019 at 02:46, Jacob Pratt wrote: > Aside from the fact that using a non-reserved identifier

Re: Modify Promise.all() to accept an Object as a parameter

The RSVP library uses Promise.hash, which seems sensible enough that I'm surprised no-one has mentioned or suggested it here. -- Dammit babies, you've got to be kind. On Mon, 14 Oct 2019 at 09:17, Michał Wadas wrote: > Established name is Promise.properties > > On Mon,

Re: Use hashes as keys instead of toString() for values like object, function to index objects

shouldn't be in a position where people choose the worse option simply out of sugar. -- Dammit babies, you've got to be kind. On Mon, 9 Sep 2019 at 02:26, J Decker wrote: > > > On Sun, Sep 8, 2019 at 1:24 PM Michael Luder-Rosefield < > rosyatran...@gmail.com&g

Re: Use hashes as keys instead of toString() for values like object, function to index objects

I'd suggest that the best way of doing this, without breaking existing code, is to put some sugar around Maps so that they can be used in a more Object-y way. For starters, Map literal declarations and assignment could benefit from this. Suggestions for syntax welcome! On Sun, 8 Sep 2019, 12:36

Re: Optional chaining syntax but with the "mice" operator ?

This is getting very reminiscent of my 'forwarding ternary' operator (or whatever I called it) I suggested a couple of years ago. I believe you were involved in the discussion, Andrea...! ``` const val = foo() ?! (x) => x.bar.baz : someFallbackValue; ``` On Sat, 7 Sep 2019, 10:17 Andrea

Re: Optional chaining syntax but with the "mice" operator ?

Another pattern it could be useful in is with, say, nosql dbs where something might be an object or id reference: ``` const fooId = foo wrote: > Another use case that I believe will be common is the following one: > > ```js > // current state of the art > const result = dbQuery(data)?.rows ??

Re: Moving forward with function decorators

I don't see any mention of class/object shorthand methods; would these be trivial, do you think? ``` class FooClass { @dec1 @dec2 bar () { } } const fooObj = { @dec1 @dec2 bar () { } } ``` -- Dammit babies, you've got to be kind. On Wed, 4 Sep 2019 at 11:49,

Re: [Proposal] Optional chaining

Another similar thing I've used is with String interpolation; if you use a similar pattern, e.g., ``` `$[items.length} item${items.length !== 1 ? 's' : ''} in collection` ``` When you want to conditionally add either some text, or nothing at all, you are forced to use the ternary with an empty

Re: Modulo Operator %%

Is there any way we can add function/operator equivalence to the language? Perhaps some kind of 'operators' global object with symbol fields matching operator string to functions/constraints? -- Dammit babies, you've got to be kind. On Thu, 15 Aug 2019 at 08:47, Andrea

Re: Re: Proposal: Selector/Select Expression

The more I read this proposal, the more I feel the ideal solution is a preceding 'wildcard' character, to stand-in for a generic argument. If it wasn't in (widespread!) use, I'd suggest an underscore: ```const f = _.prop ``` Since it is, though, we need another one. How about a double-colon,

Re: Proposal: syntactic sugar for extracting fields from objects

I tried to see if I could do this in a single destructuring step, but here is what happened: ``` var user = { profile: { firstName: 'Bob', lastName: 'Ruffward', x: 'hi' } } var obj = { ...({firstName, lastName} = user.profile), otherData: 'otherData' } ``` So... what happened? (I'm sure you all

Re: Swift style syntax

I've always been partial to operators merely being functions with infix/whatever sugar; having operators without there being a corresponding function seems deeply weird. -- Dammit babies, you've got to be kind. On Tue, 7 May 2019 at 05:58, Ates Goral wrote: > This topic

Re: Swift style syntax

-- Dammit babies, you've got to be kind. On Tue, 7 May 2019 at 05:58, Ates Goral wrote: > This topic has been discussed a long time ago and has stalled on > discussions of a standard library. > > Coming back to the idea of adding some basic math operations directly > on

Re: Proposal For A New Alternative Keyword To “this” For Classes

I'm getting deja vu again On Tue, 19 Mar 2019 at 14:31 Isiah Meadows wrote: > UX workflows aren't all of JS. Classes exist for many more reasons than > that, and 99% of my classes are for abstracting non-trivial business logic > and ensuring *those* are easily testable, not directly UI/UX. > >

Re: Proposal For A New Alternative Keyword To “this” For Classes

How about binding `this` to a variable in the constructor? The following syntax throws an error due to `this` being a reserved word, so won't break any existing code: ``` class Foo { constructor (this: self, /* normal args */) { // ... } } ``` I can see arguments against that as it

Re: Proposal: Chainable do sugar

It's OK, you can say the m-word here. Monad. See? Nothing bad wi-- -TRANSMISSION LOST On Fri, 18 Jan 2019 at 11:03 Paul Gray wrote: > Hello friends! > > I’d love to discuss the potential for syntax sugar around a popular fp > pattern, *chainables*! > > I’ve written up a document here >

Re: String identity template tag

Why not String.tag or .tagged? While we're at it, is there any good reason not to have something like this: ``` String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys) // apologies

Re: Proposal for faster this assignments in constructor functions

Michael Luder-Rosefield wrote: > > ```js > this.{} = {par1, par2, par3}; > ``` > > Of course, that could be expressed as ```this = { ...this, par1, par2, > par3 }```, but that's still a bit verbose. > > I already know this is going to get dismissed for changing the w

Re: Proposal for faster this assignments in constructor functions

> ```js this.{} = {par1, par2, par3}; ``` Of course, that could be expressed as ```this = { ...this, par1, par2, par3 }```, but that's still a bit verbose. I already know this is going to get dismissed for changing the way the `+` operator works, but it strikes me that a better way of expressing

Re: Numeric Array prototypes

> Math.min() method doesn't work on Arrays right out of the box. No, but rest parameters work: Math.min(...arr) is fine, and works with Sets too. On Wed, 21 Nov 2018 at 14:08 Isiah Meadows wrote: > Not sure these belong in the standard library itself. I could see max and > min being there

Re: await enhancement proposal: Wrap Array return values with Promise.all

Would it be possible to extend `await` such that you could `await.all()`? If not, one minor thing that might help cut down the noise (if it works with native Promises without this-binding; I've done it with RSVP): ``` const { all } = Promise; await all(/* */); ``` On Sun, 23 Sep 2018, 02:53

Re: const {resolve} = Promise; // fails

At this point I can't ignore how much overlap there is between this and the this-binding operator proposal https://github.com/tc39/proposal-bind-operator ``` const resolve = ::Promise.resolve; // takes and binds ``` As someone who often extracts functions with deconstruction, I'd love for there

Re: const {resolve} = Promise; // fails

I'd reinforce this with the fact that this works for RSVP.js https://github.com/tildeio/rsvp.js/, and so the current behaviour is a potential breaking point if code is being converted to use native Promises. On Thu, 19 Jul 2018 at 12:56 Andrea Giammarchi wrote: > As quickly discussed on

Re: Feature proposal

This array view thing is very close to what I had in mind, and seems to suggest to a lot of interesting possibilities. What strikes me as the two most significant are: - again, 'reversed' is just one alternative iteration order through, though almost certainly the most useful - others I

Re: Feature proposal

Is strikes me that every single Array method that takes an iteratee function (signature (value, index, array)) should be able to iterate through the array in reverse, in a standardised way. At the moment, we have: - every - filter - find - findIndex - forEach - indexOf /

Re: [Proposal] ignoreCase method

Would it not be simpler to simply change the signature from `function(value, arrayOfStrings)` to `function(...values)`? I'd also suggest that a better, more general purpose formulation of comparing a string against multiple values might be to use #match. Something like: ``` const checkString =

Array#flat is coming to ES; would you like like some sugar with that?

Apologies 'if' this is a terrible idea, but since I have just encountered a situation where this sugar would actually be useful I'm absolutely going to suggest it. Extend the ... syntax to allow for flattening deconstructed arrays. _Literally_ extend it: array === ...(array.flat()) // i.e.

Re: Proposal: Phase-Invariant Einno Soliton Templates

I've been suspecting along similar lines, but was reticent to make any outright accusations. On Mon, 21 May 2018, 00:41 Sanford Whiteman, < swhitemanlistens-softw...@figureone.com> wrote: > > I personally would prefer that these proposals are specified in terms > > of *what's actually being

Re: Proposal: Phase-Invariant Einno Soliton Templates

At this point I fully expect Abdul to describe the Norse, Greek and Hindu pantheons in terms of turbulence physics and give a few pseudocode JS snippets indicating that they can also be used to handle REST requests. And all in 3 short sentences. On Sun, 20 May 2018 at 02:49 kdex

Re: Re: Proposal: Pilot-Wave -based execution flow

can I be the first to say: what On Sat, 12 May 2018, 16:31 Abdul Shabazz, wrote: > A velocity vector can also be added to detect the presence of malware, > which in turn can effect the mass. If the mass at any point is changed, > then the pipeline is dropped. > -- >

Re: Proposal: Implicit variables

Could you suggest an example? On Wed, 9 May 2018 at 14:50 Abdul Shabazz wrote: > Allow javascript to facilitate implicit variables by way of an advanced > built-in reasoning engine or theorem prover. Thereby, allowing javascript > to become a more powerful semantics

Re: Accessing (n)th key from an object

I've found myself using that pattern, actually. Say you have multiple variables and want to pass one of them on to a function, which wants to know the value (of course) of that variable but also some kind of name to know which one was passed on. The easiest way to do this in one pass at the stage

Re: WHO CAN HELP ME TO UNSUBSCRIBE THIS EMAIL

Can anyone put together a strawman proposal for unsubscribing from this email? I suggest using `!@` as the operator. On Fri, 20 Apr 2018 at 04:59 Felipe Nascimento de Moura < felipenmo...@gmail.com> wrote: > well, access the link: > https://mail.mozilla.org/listinfo/es-discuss > > then look for

Allow arrow functions with conventional 'function' declarations

You're probably asking what on Earth the point of this is, and I'll tell you: _hoisting_. My preferred ES5 code style was always to declare functions after their use: ``` doSomething1(); doSomething2(); function doSomething1 () { // ... } function doSomething2 () { // ... } It keeps

Re: Proposal: if variable initialization

That strikes me as territory the 'do expression' proposal https://github.com/tc39/proposal-do-expressions is more fitted for: const x = do { if (c) expr; else { ... } }; What I'd like for this proposal is something that works consistently and obviously for all blocks with a parenthesised

Re: Promise finally

Whenever you chain a promise with a then/finally, you're basically letting the runtime look at the callbacks at some arbitrary point in the future, no? So despite being written in a defined order, they will be run in whatever order eventuates. On Fri, 23 Feb 2018 at 14:24 Raul-Sebastian Mihăilă

Re: try/catch/else

Well, since promise.then(/**blah**/).catch(/**blah**/) is already a thing, why not stick with that? try { // blah } then(val) { // blah } catch { // blah } finally { // blah } I added `val` to the then since we might want to pass something from `try` to it, just as promises do. Best way to