Re: expanding comments proposal

2016-10-20 Thread Isiah Meadows 
On Thu, Oct 20, 2016, 21:35 Isiah Meadows  wrote:

> Please, let's not add a new pragma to the language. `"use strict"` was a
> hack to enable some sanity while still remaining back-compatible, but it's
> not something we should repeat IMHO. (TC39 unanimously
>

...I sent this earlier than I intended

What I meant was that TC39 unanimously agrees that adding pragmas are a bad
idea, and several feel they're ugly.


> I would, on the other hand, strongly support dropping most of the
> restriction in section 16, third paragraph [1] and moving the remaining
> bits to Annex B, namely that conforming implementations are not allowed to
> report early errors beyond what's specified as such in the spec. (This is
> why TypeScript emits code by default even in the presence of static type
> errors. It remains a superset this way.) That would make it much easier
> to experiment with typed JavaScript at the engine level, and it would give
> much more freedom to type checkers.
>
> [1]:
> https://tc39.github.io/ecma262/#sec-error-handling-and-language-extensions
>
> On Thu, Oct 20, 2016, 13:38 Gert Cuykens  wrote:
>
> Ok, what about a "use strict comments"; solution to prevent web breaking?
>
> On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron 
> wrote:
> > Overloading comments is not likely to be accepted as a new feature;
> doing so
> > could be dramatically "web breaking".
> >
> > You may be interested in this:
> >
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
> >
> >
> > Rick
> >
> > On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens 
> wrote:
> >>
> >> Currently there are two ways to make comments `//` and `/**/` in
> >> Ecma262. I think if Ecma262 has a broader way of implementing comments
> >> it can open up the door for third party type checkers and leave the
> >> burden onto others without the need for transpiling.
> >>
> >> I am looking into how close ES20XX syntax for example compares to
> >> typescript syntax. A Ecma262 compiler doesn't need to look at the
> >> typings at all, just be smart enough to ignore typings. Is the Ecma262
> >> community willing to look at a few syntax notations that a Ecma262
> >> parser should ignore?
> >>
> >> If there is no objection at first look I am going to put in the effort
> >> to try to cover a complete syntax that extends `//` and `/**/` so
> >> others can use that to implement for example a type checker? Notice
> >> that I am not asking for type checking itself, just expanding `//` and
> >> `/**/` that makes it possible for others to do for example type
> >> checking and maintain a clean syntax look of their code.
> >>
> >> ## Example ES2015 code
> >>
> >> ```html
> >> 
> >> 
> >>
> >> 
> >>   Test
> >>   
> >>   
> >> 
> >>
> >> 
> >>   
> >> 
> >>   :host {
> >>   display: block;
> >>   box-sizing: border-box;
> >>   border: 1px solid red;
> >>   margin: 13px 0;
> >>   padding: 0 17px;
> >>   }
> >> 
> >> Test 
> >>   
> >>   
> >> class HelloWorld extends HTMLElement {
> >>   constructor() {
> >> super()
> >> const t = document.querySelector('template')
> >> const instance = t.content.cloneNode(true)
> >> const shadowRoot = this.attachShadow({ mode: 'open' })
> >> shadowRoot.appendChild(instance)
> >>   }
> >> }
> >> customElements.define('hello-world', HelloWorld)
> >>   
> >>   Hello World
> >> 
> >> 
> >> ```
> >>
> >> ## Example typescript code
> >>
> >> ```html
> >> 
> >> 
> >>
> >> 
> >>   Test
> >>   
> >>   
> >> 
> >>
> >> 
> >>   
> >> 
> >>   :host {
> >>   display: block;
> >>   box-sizing: border-box;
> >>   border: 1px solid red;
> >>   margin: 13px 0;
> >>   padding: 0 17px;
> >>   }
> >> 
> >> Test 
> >>   
> >>   
> >> class HelloWorld extends HTMLElement {
> >>   constructor() {
> >> super()
> >> const t:type1 = document.querySelector('template')
> >> const instance:type2 = t.content.cloneNode(true)
> >> const shadowRoot:type3 = this.attachShadow({ mode: 'open' })
> >> shadowRoot.appendChild(instance)
> >>   }
> >> }
> >> customElements.define('hello-world', HelloWorld)
> >>   
> >>   Hello World
> >> 
> >> 
> >> ```
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-20 Thread Isiah Meadows 
Please, let's not add a new pragma to the language. `"use strict"` was a
hack to enable some sanity while still remaining back-compatible, but it's
not something we should repeat IMHO. (TC39 unanimously

I would, on the other hand, strongly support dropping most of the
restriction in section 16, third paragraph [1] and moving the remaining
bits to Annex B, namely that conforming implementations are not allowed to
report early errors beyond what's specified as such in the spec. (This is
why TypeScript emits code by default even in the presence of static type
errors. It remains a superset this way.) That would make it much easier to
experiment with typed JavaScript at the engine level, and it would give
much more freedom to type checkers.

[1]:
https://tc39.github.io/ecma262/#sec-error-handling-and-language-extensions

On Thu, Oct 20, 2016, 13:38 Gert Cuykens  wrote:

Ok, what about a "use strict comments"; solution to prevent web breaking?

On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron 
wrote:
> Overloading comments is not likely to be accepted as a new feature; doing
so
> could be dramatically "web breaking".
>
> You may be interested in this:
>
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
>
>
> Rick
>
> On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens 
wrote:
>>
>> Currently there are two ways to make comments `//` and `/**/` in
>> Ecma262. I think if Ecma262 has a broader way of implementing comments
>> it can open up the door for third party type checkers and leave the
>> burden onto others without the need for transpiling.
>>
>> I am looking into how close ES20XX syntax for example compares to
>> typescript syntax. A Ecma262 compiler doesn't need to look at the
>> typings at all, just be smart enough to ignore typings. Is the Ecma262
>> community willing to look at a few syntax notations that a Ecma262
>> parser should ignore?
>>
>> If there is no objection at first look I am going to put in the effort
>> to try to cover a complete syntax that extends `//` and `/**/` so
>> others can use that to implement for example a type checker? Notice
>> that I am not asking for type checking itself, just expanding `//` and
>> `/**/` that makes it possible for others to do for example type
>> checking and maintain a clean syntax look of their code.
>>
>> ## Example ES2015 code
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> class HelloWorld extends HTMLElement {
>>   constructor() {
>> super()
>> const t = document.querySelector('template')
>> const instance = t.content.cloneNode(true)
>> const shadowRoot = this.attachShadow({ mode: 'open' })
>> shadowRoot.appendChild(instance)
>>   }
>> }
>> customElements.define('hello-world', HelloWorld)
>>   
>>   Hello World
>> 
>> 
>> ```
>>
>> ## Example typescript code
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> class HelloWorld extends HTMLElement {
>>   constructor() {
>> super()
>> const t:type1 = document.querySelector('template')
>> const instance:type2 = t.content.cloneNode(true)
>> const shadowRoot:type3 = this.attachShadow({ mode: 'open' })
>> shadowRoot.appendChild(instance)
>>   }
>> }
>> customElements.define('hello-world', HelloWorld)
>>   
>>   Hello World
>> 
>> 
>> ```
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Alternative way to achieve cancelable promise

2016-10-20 Thread Kagami Rosylight 
Hi Bergi:

>You're not the only one who is unsatisfied with the current proposal :-) Also 
>have a look at

Great! I’m yet to read them but I definitely will soon to discuss more.

>Promises are result values that can be passed to multiple consumers, and not 
>every consumer should be allowed to cancel the computation. So by default, 
>promises must not be cancellable.

My current updated proposal allows cancellation only for promises created by 
`Promise.cancelable()` call. In this case, simple `return 
Promise.resolve(cancelablePromise)` will disallow cancellation for other 
consumers. But yes, this may be an opt-out rather than opt-in for APIs 
returning cancelable promises.

>I don't see the major difference between these "chain" objects and "tokens" 
>from the other proposals. Can you expand on that, please?

“Chain”s do not need to be passed manually. A chain will store cancelable 
promises and will `[@@cancel]()` them after cancellation request. Each promise 
will have its own chain which will again propagate cancellations.

>You should never pass an async function to the new Promise constructor, have a 
>look here. Fortunately, the code in your actual proposal seems more reasonable 
>here.

I agree that the constructor approach is not good and would break easily. Thus, 
my updated proposal now uses `Promise.cancelable(async (chain) => {})` rather 
than the constructor itself.

>If I understood correctly, your chain keyword could be used like await? What 
>is the difference between them?

`await` will not be automatically canceled when `chain` will:

```
cancelable function saya() {
  // This is theoretically cancelable but user somehow want it to be ‘atomic’.
  await cancelableSubWork();
  chain.throwIfCanceled();
}
```

Sincerely,
Kagami Sascha Rosylight
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-20 Thread Gert Cuykens 
Ok, what about a "use strict comments"; solution to prevent web breaking?

On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron  wrote:
> Overloading comments is not likely to be accepted as a new feature; doing so
> could be dramatically "web breaking".
>
> You may be interested in this:
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
>
>
> Rick
>
> On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens  wrote:
>>
>> Currently there are two ways to make comments `//` and `/**/` in
>> Ecma262. I think if Ecma262 has a broader way of implementing comments
>> it can open up the door for third party type checkers and leave the
>> burden onto others without the need for transpiling.
>>
>> I am looking into how close ES20XX syntax for example compares to
>> typescript syntax. A Ecma262 compiler doesn't need to look at the
>> typings at all, just be smart enough to ignore typings. Is the Ecma262
>> community willing to look at a few syntax notations that a Ecma262
>> parser should ignore?
>>
>> If there is no objection at first look I am going to put in the effort
>> to try to cover a complete syntax that extends `//` and `/**/` so
>> others can use that to implement for example a type checker? Notice
>> that I am not asking for type checking itself, just expanding `//` and
>> `/**/` that makes it possible for others to do for example type
>> checking and maintain a clean syntax look of their code.
>>
>> ## Example ES2015 code
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> class HelloWorld extends HTMLElement {
>>   constructor() {
>> super()
>> const t = document.querySelector('template')
>> const instance = t.content.cloneNode(true)
>> const shadowRoot = this.attachShadow({ mode: 'open' })
>> shadowRoot.appendChild(instance)
>>   }
>> }
>> customElements.define('hello-world', HelloWorld)
>>   
>>   Hello World
>> 
>> 
>> ```
>>
>> ## Example typescript code
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> class HelloWorld extends HTMLElement {
>>   constructor() {
>> super()
>> const t:type1 = document.querySelector('template')
>> const instance:type2 = t.content.cloneNode(true)
>> const shadowRoot:type3 = this.attachShadow({ mode: 'open' })
>> shadowRoot.appendChild(instance)
>>   }
>> }
>> customElements.define('hello-world', HelloWorld)
>>   
>>   Hello World
>> 
>> 
>> ```
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-20 Thread Rick Waldron 
Overloading comments is not likely to be accepted as a new feature; doing
so could be dramatically "web breaking".

You may be interested in this:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types


Rick

On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens  wrote:

> Currently there are two ways to make comments `//` and `/**/` in
> Ecma262. I think if Ecma262 has a broader way of implementing comments
> it can open up the door for third party type checkers and leave the
> burden onto others without the need for transpiling.
>
> I am looking into how close ES20XX syntax for example compares to
> typescript syntax. A Ecma262 compiler doesn't need to look at the
> typings at all, just be smart enough to ignore typings. Is the Ecma262
> community willing to look at a few syntax notations that a Ecma262
> parser should ignore?
>
> If there is no objection at first look I am going to put in the effort
> to try to cover a complete syntax that extends `//` and `/**/` so
> others can use that to implement for example a type checker? Notice
> that I am not asking for type checking itself, just expanding `//` and
> `/**/` that makes it possible for others to do for example type
> checking and maintain a clean syntax look of their code.
>
> ## Example ES2015 code
>
> ```html
> 
> 
>
> 
>   Test
>   
>   
> 
>
> 
>   
> 
>   :host {
>   display: block;
>   box-sizing: border-box;
>   border: 1px solid red;
>   margin: 13px 0;
>   padding: 0 17px;
>   }
> 
> Test 
>   
>   
> class HelloWorld extends HTMLElement {
>   constructor() {
> super()
> const t = document.querySelector('template')
> const instance = t.content.cloneNode(true)
> const shadowRoot = this.attachShadow({ mode: 'open' })
> shadowRoot.appendChild(instance)
>   }
> }
> customElements.define('hello-world', HelloWorld)
>   
>   Hello World
> 
> 
> ```
>
> ## Example typescript code
>
> ```html
> 
> 
>
> 
>   Test
>   
>   
> 
>
> 
>   
> 
>   :host {
>   display: block;
>   box-sizing: border-box;
>   border: 1px solid red;
>   margin: 13px 0;
>   padding: 0 17px;
>   }
> 
> Test 
>   
>   
> class HelloWorld extends HTMLElement {
>   constructor() {
> super()
> const t:type1 = document.querySelector('template')
> const instance:type2 = t.content.cloneNode(true)
> const shadowRoot:type3 = this.attachShadow({ mode: 'open' })
> shadowRoot.appendChild(instance)
>   }
> }
> customElements.define('hello-world', HelloWorld)
>   
>   Hello World
> 
> 
> ```
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

expanding comments proposal

2016-10-20 Thread Gert Cuykens 
Currently there are two ways to make comments `//` and `/**/` in
Ecma262. I think if Ecma262 has a broader way of implementing comments
it can open up the door for third party type checkers and leave the
burden onto others without the need for transpiling.

I am looking into how close ES20XX syntax for example compares to
typescript syntax. A Ecma262 compiler doesn't need to look at the
typings at all, just be smart enough to ignore typings. Is the Ecma262
community willing to look at a few syntax notations that a Ecma262
parser should ignore?

If there is no objection at first look I am going to put in the effort
to try to cover a complete syntax that extends `//` and `/**/` so
others can use that to implement for example a type checker? Notice
that I am not asking for type checking itself, just expanding `//` and
`/**/` that makes it possible for others to do for example type
checking and maintain a clean syntax look of their code.

## Example ES2015 code

```html




  Test
  
  



  

  :host {
  display: block;
  box-sizing: border-box;
  border: 1px solid red;
  margin: 13px 0;
  padding: 0 17px;
  }

Test 
  
  
class HelloWorld extends HTMLElement {
  constructor() {
super()
const t = document.querySelector('template')
const instance = t.content.cloneNode(true)
const shadowRoot = this.attachShadow({ mode: 'open' })
shadowRoot.appendChild(instance)
  }
}
customElements.define('hello-world', HelloWorld)
  
  Hello World


```

## Example typescript code

```html




  Test
  
  



  

  :host {
  display: block;
  box-sizing: border-box;
  border: 1px solid red;
  margin: 13px 0;
  padding: 0 17px;
  }

Test 
  
  
class HelloWorld extends HTMLElement {
  constructor() {
super()
const t:type1 = document.querySelector('template')
const instance:type2 = t.content.cloneNode(true)
const shadowRoot:type3 = this.attachShadow({ mode: 'open' })
shadowRoot.appendChild(instance)
  }
}
customElements.define('hello-world', HelloWorld)
  
  Hello World


```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Power operator, why does -2**3 throws?

2016-10-20 Thread Claude Pache 

The existence of traps in the language is not an argument for adding other ones.
On the contrary, we must learn from previous problematic design decisions, in 
order not to repeat the same errors.

Also, the language feeling more quirky is less a severe issue than the language 
inducing to produce more bugs.

—Claude


> Le 20 oct. 2016 à 08:27, medikoo  a écrit :
> 
> ES is already not free from such cases, e.g. `!'property' in object` will
> also not resolve as most will expect.

> 
> I understand and agree that case is ambigous and is problematic. It just
> feels very controversial to me that it was decided that this case will be
> handled differently than others that share exactly same problem.
> 
> For those who are not aware of all such quirks/inconsistences it leaves
> feeling that language is unpredictable in its behaviors.
> 
> On 10/18/2016 01:05 AM, medikoo wrote:
>> There are many other cases when with no parens involved, people have
>> different expectations on the outcome.
>> If expression looks ambigous the actual result always depends on operators
>> precedence, it's how language worked for years, and I don't remember any
>> big
>> problems due to that.
>> 
>> 
>> Jordan Harband wrote
>>> It's quite simple (as has already been stated): some people expect `-x **
>>> y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`.
>>> 
>>> The early SyntaxError ensures that nobody is confused - programmers will
>>> immediately add parens to disambiguate.
>>> 
>>> Avoiding a potential footgun for the next 50 years, at the insignificant
>>> cost of adding two characters so that it parses seems like a very cheap
>>> price to pay.
>>> 
>>> On Tue, Oct 18, 2016 at 12:20 AM, medikoo 
>>> medikoo+mozilla.org@
>>> 
>>> wrote:
>>> 
 I must say throwing here, instead of relying on math dictated operators
 precedence looks really bad.
 It's very surprising to those well experienced with the language, and
 totally inconsistent with how operators worked so far (there is no
 previous
 case where one will throw for similar reason).
 
 Also argument that it's inconsistent with Math.pow(-2, 2), is total miss
 in
 my eyes.
 I believe to most programmers `Math.pow(-2, 2)`, translates to
 `(-2)**(2)`
 and not to `-2**2`,
 same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
 c)**(2)` and not to `a ? b : c**2`
 
 
 
 
 --
 View this message in context: http://mozilla.6506.n7.nabble.
 com/Power-operator-why-does-2-3-throws-tp359609p359731.html
 Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
 Nabble.com.
 ___
 es-discuss mailing list
 
>>> es-discuss@
 https://mail.mozilla.org/listinfo/es-discuss
 
>>> ___
>>> es-discuss mailing list
>>> es-discuss@
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359733.html
>> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
>> Nabble.com.
>> ___
>> es-discuss mailing list
>> es-discuss@
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> ___
> es-discuss mailing list
> es-discuss@
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359853.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at 
> Nabble.com.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Power operator, why does -2**3 throws?

2016-10-20 Thread Kevin Smith 
It's a committee-compromise grammar hack.

On 3:52AM, Thu, Oct 20, 2016 medikoo 
wrote:

> ES is already not free from such cases, e.g. `!'property' in object` will
> also not resolve as most will expect.
>
> I understand and agree that case is ambigous and is problematic. It just
> feels very controversial to me that it was decided that this case will be
> handled differently than others that share exactly same problem.
>
> For those who are not aware of all such quirks/inconsistences it leaves
> feeling that language is unpredictable in its behaviors.
>
> On 10/18/2016 01:05 AM, medikoo wrote:
> > There are many other cases when with no parens involved, people have
> > different expectations on the outcome.
> > If expression looks ambigous the actual result always depends on
> operators
> > precedence, it's how language worked for years, and I don't remember any
> > big
> > problems due to that.
> >
> >
> > Jordan Harband wrote
> >> It's quite simple (as has already been stated): some people expect `-x
> **
> >> y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`.
> >>
> >> The early SyntaxError ensures that nobody is confused - programmers will
> >> immediately add parens to disambiguate.
> >>
> >> Avoiding a potential footgun for the next 50 years, at the insignificant
> >> cost of adding two characters so that it parses seems like a very cheap
> >> price to pay.
> >>
> >> On Tue, Oct 18, 2016 at 12:20 AM, medikoo 
> >> medikoo+mozilla.org@
> >> 
> >> wrote:
> >>
> >>> I must say throwing here, instead of relying on math dictated operators
> >>> precedence looks really bad.
> >>> It's very surprising to those well experienced with the language, and
> >>> totally inconsistent with how operators worked so far (there is no
> >>> previous
> >>> case where one will throw for similar reason).
> >>>
> >>> Also argument that it's inconsistent with Math.pow(-2, 2), is total
> miss
> >>> in
> >>> my eyes.
> >>> I believe to most programmers `Math.pow(-2, 2)`, translates to
> >>> `(-2)**(2)`
> >>> and not to `-2**2`,
> >>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
> >>> c)**(2)` and not to `a ? b : c**2`
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context: http://mozilla.6506.n7.nabble.
> >>> com/Power-operator-why-does-2-3-throws-tp359609p359731.html
> >>> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> >>> Nabble.com.
> >>> ___
> >>> es-discuss mailing list
> >>>
> >> es-discuss@
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359733.html
> > Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> > Nabble.com.
> > ___
> > es-discuss mailing list
> > es-discuss@
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
> --
> View this message in context:
> http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359853.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> Nabble.com.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Power operator, why does -2**3 throws?

2016-10-20 Thread medikoo 
ES is already not free from such cases, e.g. `!'property' in object` will
also not resolve as most will expect.

I understand and agree that case is ambigous and is problematic. It just
feels very controversial to me that it was decided that this case will be
handled differently than others that share exactly same problem.

For those who are not aware of all such quirks/inconsistences it leaves
feeling that language is unpredictable in its behaviors.

On 10/18/2016 01:05 AM, medikoo wrote:
> There are many other cases when with no parens involved, people have
> different expectations on the outcome.
> If expression looks ambigous the actual result always depends on operators
> precedence, it's how language worked for years, and I don't remember any
> big
> problems due to that.
>
>
> Jordan Harband wrote
>> It's quite simple (as has already been stated): some people expect `-x **
>> y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`.
>>
>> The early SyntaxError ensures that nobody is confused - programmers will
>> immediately add parens to disambiguate.
>>
>> Avoiding a potential footgun for the next 50 years, at the insignificant
>> cost of adding two characters so that it parses seems like a very cheap
>> price to pay.
>>
>> On Tue, Oct 18, 2016 at 12:20 AM, medikoo 
>> medikoo+mozilla.org@
>> 
>> wrote:
>>
>>> I must say throwing here, instead of relying on math dictated operators
>>> precedence looks really bad.
>>> It's very surprising to those well experienced with the language, and
>>> totally inconsistent with how operators worked so far (there is no
>>> previous
>>> case where one will throw for similar reason).
>>>
>>> Also argument that it's inconsistent with Math.pow(-2, 2), is total miss
>>> in
>>> my eyes.
>>> I believe to most programmers `Math.pow(-2, 2)`, translates to
>>> `(-2)**(2)`
>>> and not to `-2**2`,
>>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
>>> c)**(2)` and not to `a ? b : c**2`
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://mozilla.6506.n7.nabble.
>>> com/Power-operator-why-does-2-3-throws-tp359609p359731.html
>>> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
>>> Nabble.com.
>>> ___
>>> es-discuss mailing list
>>>
>> es-discuss@
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> View this message in context:
> http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359733.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> Nabble.com.
> ___
> es-discuss mailing list
> es-discuss@
> https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@
https://mail.mozilla.org/listinfo/es-discuss





--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Power-operator-why-does-2-3-throws-tp359609p359853.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at 
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss