Re: Why is no line break is needed in ArrowFunction?

Why not remove Headless Arrow Functions from ExpressionStatement like FunctionExpression and ObjectLiteral. then statement like: var a = i => 1 will be var a = i => 1; instead of var a = i; => 1; BTW why Statement[return] exists? or why there is no Statment[break] or Statement[continue]?

Destructuring: Add early errors for empty patterns?

Hi all, In playing with destructuring, it seems like there are some syntax gotchas that really should trigger some sort of error and instead fail silently. For instance: ``` let {} = foo; ``` This line does absolutely nothing and is most likely an error on the developer's part. However, this is

Re: Destructuring: Add early errors for empty patterns?

Just noticed Allen filed this: https://github.com/tc39/ecma262/issues/97 On Wed, Oct 21, 2015 at 11:25 AM, Herby Vojčík wrote: > IMO this is ok, if the pattern is empty, nothing is extracted and > assigned. I see it similar to using = in expressions: it is probably an > error,

Re: Decorators for functions

One thing that seems to be missing from this thread is acknowledgement that decorators are not just simple function wrappers. They take a property descriptor as an argument, and they can return a new property descriptor - which allows an object or "class" to have its shape determined at creation

Re: Decorators for functions

I agree with Andrea, basically nothing after es3 is a "must have", if we apply the same argument. I see a lot possibilities of decorator, I think it would be great if it can be used on any lvalue, or even statements. some of the application I can think of: ``` //static type checking

Re: Why is no line break is needed in ArrowFunction?

Although, sadly,: `` function * foo () { } ``` is completely valid - although I also agree with Brian, and think both "yield*" and "function*" are one unit, and should be visually grouped as such. On Wed, Oct 21, 2015 at 1:39 PM, Brian Terlson wrote: > Sure,

RE: Why is no line break is needed in ArrowFunction?

Sure, this works for syntax questions. Today no expression can start with =>, but there is the headless arrows proposal[1] which might add one. IIRC we wanted to be future compatible. I’m not sure what the motivation for [no LT here] in yield * was, but I support it on the grounds that

Re: Decorators for functions

last time I say this: ```js (function () {'use strict'; class A {} console.log(A); } ()); ``` That is `function A` in Firefox nightly, and for some reason `function class A` in Chrome but it would be `function A` in every other browser. There is no way to distinguish between function A

Re: Decorators for functions

Why stop at ES3? Point is this literally saves you two parens in exchange for one @ and a peculiar logical insertion after the = for the use cases discussed. Let's please collectively remember and acknowledge that this exists in Python because *they have no function literal syntax*. We do. On

Re: Why is no line break is needed in ArrowFunction?

On 10/21/2015 00:27, Eric Suen wrote: Try to write a parser for es6, is this the right place for question about syntax? There is no expression or statement start with =>, same goes to yield [no LineTerminator here] * AssignmentExpression ? yield [no LineTerminator here] *

Re: Decorators for functions

Or just use call constructor: class F { #decorator call constructor() { ... } } Rick On Tue, Oct 20, 2015 at 9:19 AM Matthew Robb wrote: > Why not just do: > > ``` > const {myFunc} = { > @someDecorator; > myFunc() { > > } > }; > ``` > > > - Matthew Robb > > On

Re: Destructuring: Add early errors for empty patterns?

IMO this is ok, if the pattern is empty, nothing is extracted and assigned. I see it similar to using = in expressions: it is probably an error, jshint/IDEs should issue a warning, but I would not make an _error_ out of it (think for example cross-compilers who can produce dynamic destucturing

Re: Destructuring: Add early errors for empty patterns?

On 21 October 2015 at 20:19, Standards Zakas wrote: > In playing with destructuring, it seems like there are some syntax gotchas > that really should trigger some sort of error and instead fail silently. For > instance: > > ``` > let {} = foo; > ``` > > This line does

Re: Re: Decorators for functions

Alex, ``` const fibonacci = memoize(function(n) {...}); ``` this is actually a very good example that why we should let decorator do the job. Regardless the name ```memoize``` or memorize, whatever, How can you tell if fibonacci is a function, a list, or just a number? That is why we should

Why is no line break is needed in ArrowFunction?

Try to write a parser for es6, is this the right place for question about syntax? There is no expression or statement start with =>, same goes to yield [no LineTerminator here] * AssignmentExpression ? Spket IDE - Development Tool for RIA.

Re: Decorators for functions

Again, everything can be defined in a similar way, actually granting those function cannot posibly be declared or redefined differently, being constants. ```js const { assert, log, add } = { @conditional(DEBUG) assert(condition, message = "assertion failed.") { if (!condition)