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: 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. -Terence Bandoian On 3/22/2018 11:20 AM, Michael J. Ryan wrote: Nobody is wishing away anything with a linter. The linter can only enforce a choice not

Re: Operator for Currying

While I love currying in many languages, I have some reservations about it being generally useful enough in JS to be worth adding syntax for. 1. Currying isn't friendly with variadic functions (that is, optional arguments) - you can't tell when the function has consumed "enough" arguments to

Re: Allow Object Destructoring when assigning

> Le 22 mars 2018 à 20:51, Sebastian Malton a écrit : > > Currently object destructoring is only allowed during variable declaration, > however it would be useful, and seems rather odd from a usage standpoint, > that it cannot be done during assignment. > > Example:

Re: Allow Object Destructoring when assigning

It's not easy to parse for similar reasons async arrow functions are a bitch to parse, but it appears possible (it'd force a shift instead of a reduce, and it'd reinterpret the RHS unambiguously as a pattern) with a `[no LineTerminator here]` before the `=` token. - Isiah Meadows

Allow Object Destructoring when assigning

Currently object destructoring is only allowed during variable declaration, however it would be useful, and seems rather odd from a usage standpoint, that it cannot be done during assignment. Example:This is a allowed:```const { a } = b;```But this is not:```let a;if (...) {    { a } = b.c;}```

Update of "JSON Canonicalization"

https://github.com/cyberphone/json-canonicalization#json-canonicalization I have taken just about all input expressed on this list (thanx guys!) and added it to the specification. That doesn't mean the the spec has changed scope, it is rather the design decisions (rationale) that have been

Re: Proposal: if variable initialization

Probably true, more so than the `if (var ...)`/etc. (which can't be as easily desugared). My `else` variant desugars more to something that is also easily simulated, and it's a less common case: ```js let foo = bar else return baz; // Desugared let _tmp = bar; if (tmp == null) return baz; let

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: Re: Function composition vs pipeline

Nobody is wishing away anything with a linter. The linter can only enforce a choice not to use a given language feature. In any case, I feel this syntax is very valuable, fairly obvious in use, and similar to use in other languages. Pipeline/composition are important features, touched on by

Re: Proposal: if variable initialization

On Thu, Mar 22, 2018 at 3:50 AM, Isiah Meadows wrote: > > I do have one other related thing I'd like to see: add a `let foo = > expr() else { ... }` variant, with a line terminator restriction > before the `else` so it can't be confused with an `else` within an > `if`. >

Re: Proposal: if variable initialization

I agree, the `switch` statement was not on my radar and I don't see that need, it's the scoped `if` constructs that would make code cleaner. On Thu, Mar 22, 2018 at 8:50 AM, Isiah Meadows wrote: > > I get the nagging feeling someone is eventually going to complain that >

Re: Proposal: if variable initialization

I get the nagging feeling someone is eventually going to complain that this feature is unnecessary and smells too much like `let` blocks: - Relevant thread: https://esdiscuss.org/topic/revive-let-blocks - How it ended:

Re: Proposal: if variable initialization

Not just let-scopes, but the introduction of `async/await` also welcomes the introduction of if-scoped variables. if (const data = await collection.find({}).toArray(); data.length > 10) { console.log(data); } else if (data.length > 0) { console.log(data); } else {

Re: Yank Named and Assigned Functions

On Wed, Mar 21, 2018 at 9:54 PM, Sebastian Malton wrote: > > ... it is not yanked. Nor is the name exposed. My suggestion is that it is. That would be a massively breaking change. Not going to happen. :-) Consider: ```js function foo(bar) { console.log(typeof bar);