> On Sep 13, 2017, at 12:00 PM, Tab Atkins Jr. wrote:
>
> I believe Bob was engaging in reductio ad absurdum, Isiah. ^_^
or reductio ad FORTRAN
___
es-discuss mailing list
es-discuss@mozilla.org
Thank you for good summary. If this discussion would appears in future than
your mail is a great link to starts from
2017-09-13 22:08 GMT+03:00 Jeremy Martin :
> *> What am I missing?*
>
> Nothing with respect to function arguments, AFAICT.
>
> But to beat the
On 9/13/17 1:55 PM, Naveen Chawla wrote:
`x` `[y]` would be invalid syntax, right?
Wrong.
What am I missing?
This is exactly why automatic X insertion with complicated rules is a
bad idea for all values of X. ;)
-Boris
___
es-discuss mailing
Within the context of an array or object definition I could see
implementing automatic commas between elements but not outside; think
the thread is straying a little from the original post (const isn't
available in either context). But only between completed
expressions/function definitions.
If something requires so much special casing just to work, it's
fundamentally broken and best avoided altogether. Sloppy mode is
fundamentally broken. `eval` is fundamentally broken. TC39 people have
already generally accepted this as truth. Could we avoid adding more broken
features to the
*> What am I missing?*
Nothing with respect to function arguments, AFAICT.
But to beat the dead-cognitive-overhead horse again, the rules around ACI
(Automatic Comma Insertion) appear to require too many exceptions. We've
already covered:
- ACI doesn't apply at all between variable
Oh okay. Granted, that's not always a safe assumption on this list,
though...
(It's actually a bit of a refreshing surprise when people present
well-researched proposals here, to be honest.)
On Wed, Sep 13, 2017, 15:00 Tab Atkins Jr. wrote:
> I believe Bob was engaging in
I believe Bob was engaging in reductio ad absurdum, Isiah. ^_^
On Wed, Sep 13, 2017 at 11:51 AM, Isiah Meadows wrote:
> What about...
>
> - variable (var)
>
> - donuts (do)
>
> - forest (for)
>
> - awaiter (await, module-specific)
>
> - async
What about...
- variable (var)
- donuts (do)
- forest (for)
- awaiter (await, module-specific)
- async (https://github.com/caolan/async)
- className (class)
- letters (let)
- constants (const)
Fun fact: all of these are valid, and many of them are relatively common.
Please consider the
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
`x` `[y]` would be invalid syntax, right?
So
```js
x
[y]
```
would automatically insert a comma in the case of a function call arguments
list, right?
That's exactly what would be desired. What am I missing?
On Wed, 13 Sep 2017 at 20:52 Boris Zbarsky wrote:
> On 9/13/17 9:57
On 9/13/17 9:57 AM, Naveen Chawla wrote:
By this behaviour (a modification to the initial "complete statement
produces comma" version of this proposal), everything would work
perfectly, no?
If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
behavior that makes any code
On Wed, Sep 13, 2017 at 3:52 PM, Aluan Haddad wrote:
>
> ...given the countless hours already wasted debating semicolon
> usage, and with the inherent complexity that this would add to
> tools like transpilers and minifiers, this would seem to add
> negative value.
^^ this.
Yes, this is the reason why I didn't mention the variable declaration in
initial proposal - it is 100% valid syntax in current implementation (and
100% relative error in strict mode)
But the design problems of ASI are incomparable with a special case of get
and set
2017-09-13 17:55 GMT+03:00
Quick side note regarding multiple variable declarations: both versions of
this proposal (OP's newline-based proposal and the ASI-inspired version)
result in code breakage:
```
const
x = 5
y = 6
z = 7
```
Under existing ASI rules, this is currently equivalent to:
```
const x = 5;
// y
I can see an argument for this by analogy with class syntax but I for one
would immediately go looking for a linter which raised errors for these
omitted commas.
Furthermore, given the countless hours already wasted debating semicolon
usage, and with the inherent complexity that this would add to
I can see the argument for this by analogy with class syntax but
On Sep 13, 2017 10:32 AM, wrote:
Send es-discuss mailing list submissions to
es-discuss@mozilla.org
To subscribe or unsubscribe via the World Wide Web, visit
> Maybe you mean "will behave more or less as if (except more efficiently)"?
no, I meant: it will transpiled into something using private WeakMaps.
I don't have any interest in talk nanoseconds for something unrelated to
the topic though.
Best Regards
On Wed, Sep 13, 2017 at 1:54 PM, Alex
I'm not really familiar with ASI but they key factor mentioned in this
discussion is this (by Claude Pache):
*A implicit semicolon is not added when a declaration would be complete,
but when the next token would produce a syntax error. *
By this behaviour (a modification to the initial "complete
Nit: `_` is a very valid identifier. (Consider Underscore/Lodash)
On Wed, Sep 13, 2017, 09:32 Alex Kodat wrote:
> Also, FWIW, since we’re talking about nanoseconds of performance, here, I
> think slightly better than:
>
> return this.#random || (this.#random =
Also, FWIW, since we’re talking about nanoseconds of performance, here, I
think slightly better than:
return this.#random || (this.#random = Math.random());
Is
return (this.#random === undefined) ? this.#random = Math.random() :
this.#random;
This is because in the former, the
*> Can someone remind me of the problem doing it this way, if any? (I'm not
sure it has been mentioned yet)*
The problem is in how this proposal has currently been structured:
*> [...] if line is a complete statement and next line is not an operator
than consider it as complete argument (field,
On 9/13/17 9:05 AM, Naveen Chawla wrote:
Can someone remind me of the problem doing it this way, if any?
You mean apart from all the existing footguns ASI has?
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
Very interesting point. Is there another way to get this optional comma
proposal through while being backwards compatible? I really like the idea.
If it worked like ASI, then surely it would allow the multi-line `get`
case?:
```js
{
get
x() //valid syntax after "get", so no comma
I can assure you that will likely never happen, because it's a pretty
obvious identifier to use in more generic or high-context scenarios.
(Think: `get(foo, bar)`, and I've done that plenty of times.)
On Wed, Sep 13, 2017, 03:05 Naveen Chawla wrote:
> Can't `get` be
What do you mean by “will be transpiled through”? My understanding of the
private property proposal is that private properties will be in fixed slots
(inaccessible outside the class) in the object so there would be no WeakMap.
Maybe you mean "will behave more or less as if (except more
> The properties already existed, so defineProperty shouldn't modify the
order IIUC
well, nope. the property existed in the prototype, not in the object.
anyway, I guess private properties, that are a possible solution, will be
transpiled through a WeakMap so that most likely anything discussed
Can't `get` be relegated to a reserved/keyword, like `let`, `yield` and
`await` were? Just curious about that kind of process & decision?...
On Wed, 13 Sep 2017 at 05:25 Matthew Robb wrote:
> Okay what would be the cons to allowing semi colons in place of commas in
>
28 matches
Mail list logo