<div dir="ltr">Although this works, it seems like a bit of a violation of say-what-you-mean and dont-repeat-yourself to me. You have to write the name of each function twice, and you are defining a shorthand object literal just for the sake of unpacking it.<div><br></div><div>If we must have syntax for this, I'd propose hijacking @ to mean general paren-free invocation, using the same precedence rules as Coffee:<span></span></div><div><br></div><div>```js</div><div>const fibonacci = memoize(function(n) {...});</div><div>const fibonacci = @memoize function(n) {...};<br>const fib100 = @fibonacci 100;</div><div>@window.alert "If this syntax works for functions, why not let it work for anything?";</div><div>```</div><div><br></div><div>But I must ask - why *exactly* do people have a problem with the extra brackets again? Is it really just because we don't have good paredit or other tree-based editing for JS yet? (Or do we?)</div><div><br>On Wednesday, 21 October 2015, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Again, everything can be defined in a similar way, actually granting those function  cannot posibly be declared or redefined differently, being constants.<div><br></div><div>```js</div><div><div><br></div><div>const {</div><div>  assert,</div><div>  log,</div><div>  add</div><div>} = {</div><div>  @conditional(DEBUG)</div><div>  assert(condition, message = "assertion failed.") {</div><div>    if (!condition) throw new Error(message);</div><div>  }</div><div><br></div><div>  @conditional(TRACE)</div><div>  log(message) {</div><div>    return target => function () {</div><div>       console.log(message);</div><div>       return target.apply(this, arguments);</div><div>    };</div><div>  }</div><div><br></div><div>  @metadata("design:paramtypes", () => [Number, Number])</div><div>  @metadata("design:returntype", () => Number)</div><div>  function add(a, b) { </div><div>    return a + b;</div><div>  }</div><div><br></div><div>};</div></div><div>```</div><div><br></div><div>Beside that, that gist is completely unreadable to my eyes, I guess it would take some time to be maintained as well if that was production code.</div><div><br></div><div>The work around fixes all that, it keeps portability of the current proposal, and it ensure log will always be that log and nothing else in that very same scope +  strawberry on  top, less writing and always named functions.</div><div><br></div><div>How cool is that?</div><div><br></div><div>Best Regards</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 8:26 PM, Ron Buckton <span dir="ltr"><<a>Ron.Buckton@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I can think of numerous examples of how decorators could apply to functions, and I’ve added them to a
<a href="https://gist.github.com/rbuckton/37e944f7986e6833949e" target="_blank">gist</a> [1] for easier consumption. It’s true that simple decorators for functions can work as simply as function calls, but this becomes a bit unwieldy if you need to compose multiple decorators
 on a single function.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Consider a scenario combining decorators providing runtime type information as an annotation with one that adds runtime type checking. With decorators this might
 be:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```js<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">@paramtypes(() => [Number, Number])<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">@returntype(() => Number)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">@checked<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">function add(x, y) { return x + y }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">If I just use function expressions, this is feasible if a bit awkward:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```js<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">const add =
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">    paramtypes(() => [Number, Number])(<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">        returntype(() => Number)(<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">            checked(<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">                function (x, y) { return x + y; })))<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It feels a bit developer-hostile to have to rebalance parentheses if you want to add a decorator, and there are ASI hazards if you misplace an opening paren.
 Also, you can no longer infer the function name “add” from the const binding.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Using `::` isn’t a great replacement either, as there are many hazards such as:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```js<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">// The following means “call `decorator` with `this` bound to the function object”.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">// Also, it becomes impossible to infer the function name “a” from the let binding.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">let a = function() { }::decorator(x)
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">let b = function() { }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">::some.decorator(x) // ASI hazard as `::` can be either prefix or infix.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">One of the initial drivers for decorators was class methods, as there’s no expression context immediately inside the class body in which you can use either of
 the above scenarios. This necessitated a declarative form for decorators to allow these scenarios to exist. Having parity across class methods, classes, and functions (of all kinds) presents a more consistent story to developers. The upswing in decorator use
 in both TypeScript and Babel has been very positive, with libraries like Angular leveraging decorators heavily in their codebase. Since we introduced decorators into TypeScript, we’ve had a fair bit of feedback requesting support for function decorators.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I do think function decorators should wait until the Class/Property decorators proposal advances further along the standards track. Axel’s initial concerns/questions
 around hoisting are valid and there isn’t a clear consensus on the semantics for functions. That said, I’ve been mostly in the camp of introducing TDZ for function declarations that have decorators. Decorators are a new syntactic form and we have the opportunity
 to communicate this caveat with the development community by the time the feature lands. It seems easy enough to explain that:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```js<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">@decorator<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">function func() { }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Is the equivalent of:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```js<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">let func = @decorator function() { }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Introducing TDZ allows to generally warn early as part of the static semantics, so developers won’t fall into a well with respect to adding a decorator to a function
 and not being able to quickly understand how that change affects the behavior of their code.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I’m not certain what the current plan of record is, but the best approach may be:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Advance and get consensus on the Class/Property decorators proposal<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Draft a separate proposal for decorators on function expressions, generator function expressions, and arrows<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>3.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Draft a separate proposal for decorators on function declarations<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Steps 1 and 2 above shouldn’t be significantly difficult and don’t necessarily introduce any major new semantics outside of the decorators themselves. Step 3
 covers a thornier issue as it not only introduces the new semantics of decorators but also introduces side-effects due to hoisting.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Ron<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[1]
<a href="https://gist.github.com/rbuckton/37e944f7986e6833949e" target="_blank">https://gist.github.com/rbuckton/37e944f7986e6833949e</a>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> es-discuss [mailto:<a>es-discuss-bounces@mozilla.org</a>]
<b>On Behalf Of </b>Andrea Giammarchi<br>
<b>Sent:</b> Tuesday, October 20, 2015 3:34 AM<br>
<b>To:</b> Axel Rauschmayer <<a>rauschma@icloud.com</a>><br>
<b>Cc:</b> es-discuss mailing list <<a>es-discuss@mozilla.org</a>><br>
<b>Subject:</b> Re: Decorators for functions<u></u><u></u></span></p><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">You haven't provided a single use-case example, like how are you going to decorate a function or why.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">IMO if implemented it will be incompatible with non ES6 code unable to distinguish between classes and functions unless fully transpiled, making decorators less portable.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">One thing I like about current state is that you can use decorators even in ES5 browsers [1]<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Just my 2 cents, Regards<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">[1] as shown in the second example of the universal mixin module
<a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fWebReflection%2funiversal-mixin%23universal-mixin-&data=01%7c01%7cron.buckton%40microsoft.com%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=T1q%2bKVVIyc%2bNxSyG9Ri%2bmNAMPqq3p6Ydofoe1WQrg5U%3d" target="_blank">
https://github.com/WebReflection/universal-mixin#universal-mixin-</a> <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Oct 20, 2015 at 10:30 AM, Axel Rauschmayer <<a>rauschma@icloud.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fwycats%2fjavascript-decorators%2fblob%2fmaster%2fREADME.md&data=01%7c01%7cron.buckton%40microsoft.com%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2fTFCt8Rrkx6pTvFLkcl8xfV5EKny35QpLPVTmm0aV8%3d" target="_blank">https://github.com/wycats/javascript-decorators/blob/master/README.md</a><br>
<br>
The decorator proposal does not include decorators for functions, because it isn’t clear how to make them work in the face of hoisting.<br>
<br>
However, it would be great to have them. I see two possible solutions:<br>
<br>
– A decorator on a function declaration prevents hoisting.<br>
<br>
– Enable decorators for function expressions, arrow functions and generator function expressions.<br>
<br>
Does either one of those make sense?<br>
<span style="color:rgb(136,136,136)"><br>
<span>Axel</span><br>
<br>
<span>--</span><br>
<span>Dr. Axel Rauschmayer</span><br>
<span><a>axel@rauschma.de</a></span><br>
<span><a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2frauschma.de&data=01%7c01%7cron.buckton%40microsoft.com%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Vclw%2fyI29j4WqkHWjTgaZtoL12pnJNCWYBJK4wTYVA0%3d" target="_blank">rauschma.de</a></span><br>
<br>
<br>
<br>
<span>_______________________________________________</span><br>
<span>es-discuss mailing list</span><br>
<span><a>es-discuss@mozilla.org</a></span><br>
<span><a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss&data=01%7c01%7cron.buckton%40microsoft.com%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7t2BTGHrR322y2keuKyyEhgwUSIOCCN3vzv9CbXzdn8%3d" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a></span></span><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>
</blockquote></div>
</div>