Re: Why Number(symbol) crashes?

[Allen Wirfs-Brock]

> On Oct 14, 2016, at 11:02 AM, Claude Pache  wrote:
> 
> 
>> Le 11 oct. 2016 à 11:07, medikoo  a écrit :
>> 
>> I was searching the archived but wasn't able to find the answer.
>> 
>> What's the reasoning behind having Number(symbol) crash instead of returning
>> NaN (as it's in case all other non-coercible values?). It feels not
>> consistent.
>> 
>> If someone can point me to some discussion that provided the reasoning I'd
>> be grateful
>> 
> 
> I believe that the reason of the inconsistency is more an accident of history 
> in the development of ES6 than a well-reasoned design decision. Here is my 
> understanding:

No this was an intentional design decision. There is no  obvious or natural 
Number value corresponding to symbol values. Rather than inventing some 
arbitrary conversion rule (for example producing NaN) TC39 choose to throw an 
exception for such conversions as they are a clear manifestation of some sort 
of program bug.

Note that the coercion rules for the original JS primitive types were created 
at a time when JavaScript did not have an exception handling mechanism and 
hence all operations were required to produce some value. Throwing exceptions 
for unreasonable Symbol coercions is intentionally inconsistent with the 
handling of the original primitive coercions and is intended to set a new 
precedent  that will be applied to any other new primitive types that might be 
added to ES in the future.

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

User-defined literals

[kdex]

I haven't seen this discussed on ESDiscuss before. For those not 
familiar with user-defined literals: Essentially, they allow certain 
literals (e.g. 123.45, "hello") to produce a user-defined object by 
marking the literal with a user-defined suffix.


They were introduced in C++11 [1], and I'm not sure if any other 
language has implemented them.They were also discussed on Python-ideas [2].


Some potential use cases:

- Since ES2015, built-ins are subclassable, so you could use a literal 
to call custom constructors (e.g. for custom string objects)

- Units (e.g. `100m + 2cm`)
- Numbers may be specified in arbitrary bases (e.g. `124_9 === 
Number.parseInt(124, 9)`)
- Complex numbers, quaternions, … (you could make these even nicer with 
operator overloading)


Any opinions?


— kdex

[1] http://en.cppreference.com/w/cpp/language/user_literal
[2] https://mail.python.org/pipermail/python-ideas/2015-June/033871.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why Number(symbol) crashes?

[Claude Pache]

> Le 11 oct. 2016 à 11:07, medikoo  a écrit :
> 
> I was searching the archived but wasn't able to find the answer.
> 
> What's the reasoning behind having Number(symbol) crash instead of returning
> NaN (as it's in case all other non-coercible values?). It feels not
> consistent.
> 
> If someone can point me to some discussion that provided the reasoning I'd
> be grateful
> 

I believe that the reason of the inconsistency is more an accident of history 
in the development of ES6 than a well-reasoned design decision. Here is my 
understanding:

* At one point of time in the development of ES6, /implicit/ conversion from 
symbol to string or number was made forbidden. This is a behaviour that was 
discussed and decided, in order to prevent silent bugs in computed properties 
in situations where a string was previously implicitely expected.

```js
var key = Symbol()
foo[‘key + ‘-suffix’] // TypeError: can’t convert symbol to string
foo[‘key + ‘42] // TypeError: can’t convert symbol to number
```

* However, /explicit/ conversion from symbol to string (using `String(…)` or 
`.toString()`) has been kept as allowed. This is a more debatable decision 
(with pros and cons). On the other hand, I don’t recall any discussion about 
making explicit conversion from symbol to number different from the implicit 
one, nor anyone complaining that it remained the only primitive type to which 
symbol could not be *explicitly* coerced.

—Claude


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

Re: Try/Catch always needed for await?

[Andrea Giammarchi]

Just one thought:

> Of course, in the top-level invocation it might be a good idea to use a
`catch`

after years of engine developers advocating "avoid try/catch as much as
possible because it de-opts and slow down code and JIT and you name it",
above suggestion doesn't really look like an "of course".

Using a proper `.catch()` within the async returned promise is probably the
best approach.

Best Regards

On Fri, Oct 14, 2016 at 4:25 PM, Alan Johnson  wrote:

> To perhaps clarify this point a bit, it is *very important* to `.catch()`
> and react appropriately at the ends of promise chains. If synchronous code
> fails for an unexpected reason, a visible crash will definitely happen.
> This is not the case for promises, because there’s no way for the runtime
> to know whether that promise is just some middle step in the chain, in
> which case you’d want to propagate rejection, rather than throw a
> synchronous exception. Having unexpected errors be silently swallowed is
> definitely a problematic property of promises, which you have to guard
> against.
>
> It probably would be possible for the runtime to report crashes of
> promises that have no registered `.then()`. The only problem is, it’s
> totally possible the programmer is going to attach a `.then()` or
> `.catch()` later on to a promise that has already failed. Some promise
> libraries offer a `.done()` that has the semantics of “crash if this
> promise rejects”. But arguably, this should be the normal behavior, with an
> opt-out instead, so that it is assumed that you want rejected promises
> without any `.then()`s to throw synchronous exceptions. Something like a
> `.noFail()` could opt out
>
> On Oct 14, 2016, at 09:30, Bergi  wrote:
>
> Jordan Rome schrieb:
>
> My apologies if this has already been discussed but what is the "preferred"
> pattern for using await ? Since await, which runs on promises, will now
> throw if the promise is rejected (preventing execution of code after the
> await and killing the process in Node), is it neccesary to always be
> wrapping await in try/catch?
>
>
> No. Just like in synchronous code, you only wrap a part of your code in
> try-catch if you actually want to *handle* an exception.
>
> If you don't handle it, it will bubble as usual and reject the promise
> returned by the `async function`. Let the caller deal with the exceptions
> you can't handle - just like always.
> Of course, in the top-level invocation it might be a good idea to use a
> `catch` (or the `.catch()` method) to catch any exceptions and log them to
> whereever you want if you don't want to get an unhandled rejection, but
> those are usually exceptions you *don't expect* so you might not need to
> deal with them at all.
>
> - Bergi
> ___
> 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: Try/Catch always needed for await?

[Alan Johnson]

To perhaps clarify this point a bit, it is very important to `.catch()` and 
react appropriately at the ends of promise chains. If synchronous code fails 
for an unexpected reason, a visible crash will definitely happen. This is not 
the case for promises, because there’s no way for the runtime to know whether 
that promise is just some middle step in the chain, in which case you’d want to 
propagate rejection, rather than throw a synchronous exception. Having 
unexpected errors be silently swallowed is definitely a problematic property of 
promises, which you have to guard against.

It probably would be possible for the runtime to report crashes of promises 
that have no registered `.then()`. The only problem is, it’s totally possible 
the programmer is going to attach a `.then()` or `.catch()` later on to a 
promise that has already failed. Some promise libraries offer a `.done()` that 
has the semantics of “crash if this promise rejects”. But arguably, this should 
be the normal behavior, with an opt-out instead, so that it is assumed that you 
want rejected promises without any `.then()`s to throw synchronous exceptions. 
Something like a `.noFail()` could opt out

> On Oct 14, 2016, at 09:30, Bergi  wrote:
> 
> Jordan Rome schrieb:
>> My apologies if this has already been discussed but what is the "preferred"
>> pattern for using await ? Since await, which runs on promises, will now
>> throw if the promise is rejected (preventing execution of code after the
>> await and killing the process in Node), is it neccesary to always be
>> wrapping await in try/catch?
> 
> No. Just like in synchronous code, you only wrap a part of your code in 
> try-catch if you actually want to *handle* an exception.
> 
> If you don't handle it, it will bubble as usual and reject the promise 
> returned by the `async function`. Let the caller deal with the exceptions you 
> can't handle - just like always.
> Of course, in the top-level invocation it might be a good idea to use a 
> `catch` (or the `.catch()` method) to catch any exceptions and log them to 
> whereever you want if you don't want to get an unhandled rejection, but those 
> are usually exceptions you *don't expect* so you might not need to deal with 
> them at all.
> 
> - Bergi
> ___
> 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?

[Claude Pache]

> Le 14 oct. 2016 à 16:52, Rick Waldron  a écrit :
> 
> Python is also inconsistent: 
> 
> >>> pow(-2, 2)
> 4
> >>> -2 ** 2
> -4
> >>>

This is not inconsistency, but that follows from operator precedence rules 
(those used in mathematics, not in C).

In the same vein, you have `pow(1+1, 2) == 4` but `1+1 ** 2 == 2`, because the 
latter is interpreted as `1+(1 ** 2)`.

—Claude

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

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

[Rick Waldron]

Here's some more specific notes:

On Fri, Oct 14, 2016 at 7:31 AM Cyril Auburtin 
wrote:

> I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
> like `-(2**3)`
>

Math.pow(-2, 3) === -8
Math.pow(-2, 2) === 4

To get -4: -Math.pow(-2, 2)


> Firefox gives a clearer error then Chrome with:
> > SyntaxError: unparenthesized unary expression can't appear on the
> left-hand side of '**'
>

That's correct.

>
> Is there a reason for this restriction? Python does it `-2**3` fine
>

Python is also inconsistent:

>>> pow(-2, 2)
4
>>> -2 ** 2
-4
>>>

Whereas, JavaScript is very consistent:

$ js
js> -(2 ** 2)
-4
js> -Math.pow(2, 2)
-4
js> (-2) ** 2
4
js> Math.pow(-2, 2)
4
js>



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

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

[Rick Waldron]

On Fri, Oct 14, 2016 at 7:31 AM Cyril Auburtin 
wrote:

> I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
> like `-(2**3)`
>

This was discussed extensively during the design process and determined
that requiring user code to be explicit about its intention was the only
sane design.

-
https://github.com/rwaldron/tc39-notes/blob/master/es7/2015-09/sept-23.md#exponentiation-operator
-
https://github.com/rwaldron/tc39-notes/blob/master/es7/2015-09/sept-24.md#exponentiation-operator


Rick


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

Re: Making Object Literals a sub-class of Object

[Rick Waldron]

On Fri, Oct 14, 2016 at 9:05 AM Brian Ninni  wrote:

> I did a quick search and didn't find any recent mentions of this topic.
>
> On more than one occasion I've had to determine whether something was a
> plain old Object, or some other class. This involves checking that the
> given object was NOT an instanceof any other acceptable class.
>
> Array, RegExp, Function, and Class Literals all already create an Object
> sub-class, so why not Object Literals?
>

Terminology clarification: "Object literal" refers to the syntactic grammar
definition.



> It doesn't have to operate any differently than a standard Object does
> (though it allows room for deviation in the future), just have a different
> constructor so it can easily be determined whether it is a literal or not.
>
> This would break code that uses `obj.constructor === Object`, but that
> code is not always reliable since the 'constructor' property can be
> overwritten without any side-effects anyway.
>
> Are there any other major reasons why this is a bad idea?
>


Objects created by `new Object()`, `Object()`, `let/const/var o = {}` are
functionally equivalent*—changing the runtime semantics of only the
syntactic form would be a web-breaking change.

* Follow:
- https://tc39.github.io/ecma262/#sec-object-value
- https://tc39.github.io/ecma262/#sec-ordinarycreatefromconstructor
-
https://tc39.github.io/ecma262/#sec-object-initializer-runtime-semantics-evaluation


Rick

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

Re: Making Object Literals a sub-class of Object

[Oriol Bugzilla]

Object literals (object initializers) are just a convenient way to create a new 
ordinary object which (initially) inherits from `Object.prototype`, and 
populate it with some properties.

I don't think you should be able to distinguish them from similar objects not 
created using object initializers, e.g. `new Object()`.

As already said, you can use `Object.getPrototypeOf(obj) === Object.prototype` 
to check if `obj` inherits from `Object.prototype`.

But be aware that object literals can return object with a modified prototype:

```js
var obj = {__proto__: Array.prototype};
Object.getPrototypeOf(obj) === Object.prototype; // false, but was created 
using object literal!
```

And the condition may hold for objects not created using object literals, e.g.

```js
var obj = new Object();
Object.getPrototypeOf(obj) === Object.prototype; // true, but was not created 
using object literal!
```

Maybe you consider `new Object()` to be an object literal, so the above would 
be OK.

But there can also be non-ordinary objects whose prototype is 
`Object.prototype`:

```js
var obj = Object.setPrototypeOf([], Object.prototype);
Object.getPrototypeOf(obj) === Object.prototype; // true, but it's an array!
```

Maybe what would be more interesting is having a way to check if an object is 
ordinary.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Making Object Literals a sub-class of Object

[Brian Ninni]

>
> `({}).toString.call(o);`


This does work for all Native class, but still returns "[object Object] "
for user created classes

`Object.getPrototypeOf({}) === Object.prototype // true`


Did not know of that method.  Seems like a roundabout way, but it works.

`Object.prototype.isPrototypeOf(o)`


Doesn't seem to differentiate between Literals and non-Literals.

Guylian's solution solves my main issue, so definitely not worth breaking a
lot of code for.

I can see the possibility of someone wanting to extend the prototype for
Object Literals only, and not all Objects, but that can also be
accomplished by making a new class.  So again, not a great reason for
breaking code.

Thanks for the responses

On Fri, Oct 14, 2016 at 9:24 AM, Bergi  wrote:

> Brian Ninni wrote:
>
> On more than one occasion I've had to determine whether something was a
>> plain old Object, or some other class. This involves checking that the
>> given object was NOT an instanceof any other acceptable class.
>>
>
> `Object.prototype.isPrototypeOf(o)` should do that (if you don't care
> about other realms).
>
> Array, RegExp, Function, and Class Literals all already create an Object
>> sub-class, so why not Object Literals?
>>
>
> Because Object-objects are just Objects and not anything special that
> would need a subclass with specific methods.
>
> Are there any other major reasons why this is a bad idea?
>>
>
> As you already said, it would break a great lot of code.
>
> - Bergi
>
> ___
> 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: Making Object Literals a sub-class of Object

[Bergi]

I wrote:

Brian Ninni wrote:


On more than one occasion I've had to determine whether something was a
plain old Object, or some other class. This involves checking that the
given object was NOT an instanceof any other acceptable class.


`Object.prototype.isPrototypeOf(o)` should do that (if you don't care
about other realms).


Ooops, `Object.getPrototypeOf(o) === Object.prototype` is what I meant.

- Bergi

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

Re: Try/Catch always needed for await?

[Bergi]

Jordan Rome schrieb:

My apologies if this has already been discussed but what is the "preferred"
pattern for using await ? Since await, which runs on promises, will now
throw if the promise is rejected (preventing execution of code after the
await and killing the process in Node), is it neccesary to always be
wrapping await in try/catch?


No. Just like in synchronous code, you only wrap a part of your code in 
try-catch if you actually want to *handle* an exception.


If you don't handle it, it will bubble as usual and reject the promise 
returned by the `async function`. Let the caller deal with the 
exceptions you can't handle - just like always.
Of course, in the top-level invocation it might be a good idea to use a 
`catch` (or the `.catch()` method) to catch any exceptions and log them 
to whereever you want if you don't want to get an unhandled rejection, 
but those are usually exceptions you *don't expect* so you might not 
need to deal with them at all.


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

Re: Making Object Literals a sub-class of Object

[Bergi]

Brian Ninni wrote:


On more than one occasion I've had to determine whether something was a
plain old Object, or some other class. This involves checking that the
given object was NOT an instanceof any other acceptable class.


`Object.prototype.isPrototypeOf(o)` should do that (if you don't care 
about other realms).



Array, RegExp, Function, and Class Literals all already create an Object
sub-class, so why not Object Literals?


Because Object-objects are just Objects and not anything special that 
would need a subclass with specific methods.



Are there any other major reasons why this is a bad idea?


As you already said, it would break a great lot of code.

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

Re: Making Object Literals a sub-class of Object

[Guylian Cox]

If you want to check that your variable is a plain old object and not some
other class, you can use

`Object.getPrototypeOf(x) === Object.prototype`

`Object.getPrototypeOf({}) === Object.prototype // true`

`Object.getPrototypeOf(new Map()) === Object.prototype // false`

Le ven. 14 oct. 2016 à 15:05, Brian Ninni  a écrit :

> I did a quick search and didn't find any recent mentions of this topic.
>
> On more than one occasion I've had to determine whether something was a
> plain old Object, or some other class. This involves checking that the
> given object was NOT an instanceof any other acceptable class.
>
> Array, RegExp, Function, and Class Literals all already create an Object
> sub-class, so why not Object Literals?
>
> It doesn't have to operate any differently than a standard Object does
> (though it allows room for deviation in the future), just have a different
> constructor so it can easily be determined whether it is a literal or not.
>
> This would break code that uses `obj.constructor === Object`, but that
> code is not always reliable since the 'constructor' property can be
> overwritten without any side-effects anyway.
>
> Are there any other major reasons why this is a bad idea?
> ___
> 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: Making Object Literals a sub-class of Object

[Petter Envall]

2016-10-14 15:05 GMT+02:00 Brian Ninni :

> I did a quick search and didn't find any recent mentions of this topic.
>
> On more than one occasion I've had to determine whether something was a
> plain old Object, or some other class. This involves checking that the
> given object was NOT an instanceof any other acceptable class.
>

Does not ```({}).toString.call(o);```work for that?


> Array, RegExp, Function, and Class Literals all already create an Object
> sub-class, so why not Object Literals?
>
> It doesn't have to operate any differently than a standard Object does
> (though it allows room for deviation in the future), just have a different
> constructor so it can easily be determined whether it is a literal or not.
>
> This would break code that uses `obj.constructor === Object`, but that
> code is not always reliable since the 'constructor' property can be
> overwritten without any side-effects anyway.
>
> Are there any other major reasons why this is a bad idea?
>
> ___
> 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

Making Object Literals a sub-class of Object

[Brian Ninni]

I did a quick search and didn't find any recent mentions of this topic.

On more than one occasion I've had to determine whether something was a
plain old Object, or some other class. This involves checking that the
given object was NOT an instanceof any other acceptable class.

Array, RegExp, Function, and Class Literals all already create an Object
sub-class, so why not Object Literals?

It doesn't have to operate any differently than a standard Object does
(though it allows room for deviation in the future), just have a different
constructor so it can easily be determined whether it is a literal or not.

This would break code that uses `obj.constructor === Object`, but that code
is not always reliable since the 'constructor' property can be overwritten
without any side-effects anyway.

Are there any other major reasons why this is a bad idea?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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

[Cyril Auburtin]

I was testing something https://caub.github.io/misc/calculator, and I
didn't see how it would be a problem to have the precedence of ** higher
than unaries.

But at least I'm happy something like (2).pow(3) wasn't chosen.

Thanks anyway and sorry for discussing something already frozen in spec
anyway

2016-10-14 14:33 GMT+02:00 Cyril Auburtin :

> Ah, ok, a bit sad because all more scientific languages, and python too,
> all math books, all will use `-e^3` for meaning `-(e^3)` (^ or **), because
> it's just `-exp(3)` or `-pow(E, 3)`
>
> and `(-1)^n` otherwise, when we want to take the signs with.
>
> If you wanted to avoid any confusion you could have forbidden `2**2**3`
> too because it's not obvious it's right associative
>
> But ok, thanks for the explanation.
>
>
> 2016-10-14 14:05 GMT+02:00 Bergi :
>
>> Cyril Auburtin schrieb:
>>
>>> I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
>>> like `-(2**3)`
>>>
>>
>> You would, others would not. -2 ** 2 clearly should return 4, shouldn't
>> it?
>>
>> Is there a reason for this restriction? Python does it `-2**3` fine
>>>
>>
>> Because of the ambiguity it has been decided to make it a syntax error if
>> the two operators are used together. If you want `-(2**3)`, you have to
>> write it like that, and if you want `(-2)**3` you have to write it
>> explicitly as well.
>> See https://esdiscuss.org/topic/exponentiation-operator-precedence for
>> the full discussion.
>>
>> - Bergi
>>
>> ___
>> 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?

[Cyril Auburtin]

Ah, ok, a bit sad because all more scientific languages, and python too,
all math books, all will use `-e^3` for meaning `-(e^3)` (^ or **), because
it's just `-exp(3)` or `-pow(E, 3)`

and `(-1)^n` otherwise, when we want to take the signs with.

If you wanted to avoid any confusion you could have forbidden `2**2**3` too
because it's not obvious it's right associative

But ok, thanks for the explanation.

2016-10-14 14:05 GMT+02:00 Bergi :

> Cyril Auburtin schrieb:
>
>> I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
>> like `-(2**3)`
>>
>
> You would, others would not. -2 ** 2 clearly should return 4, shouldn't it?
>
> Is there a reason for this restriction? Python does it `-2**3` fine
>>
>
> Because of the ambiguity it has been decided to make it a syntax error if
> the two operators are used together. If you want `-(2**3)`, you have to
> write it like that, and if you want `(-2)**3` you have to write it
> explicitly as well.
> See https://esdiscuss.org/topic/exponentiation-operator-precedence for
> the full discussion.
>
> - Bergi
>
> ___
> 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?

[Bergi]

Cyril Auburtin schrieb:

I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
like `-(2**3)`


You would, others would not. -2 ** 2 clearly should return 4, shouldn't it?


Is there a reason for this restriction? Python does it `-2**3` fine


Because of the ambiguity it has been decided to make it a syntax error 
if the two operators are used together. If you want `-(2**3)`, you have 
to write it like that, and if you want `(-2)**3` you have to write it 
explicitly as well.
See https://esdiscuss.org/topic/exponentiation-operator-precedence for 
the full discussion.


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

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

[Cyril Auburtin]

What does it change if it handles floats?

I just checked
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence

unary + is 16, while exponentiation is 15, so the opposite order that I
thought

2016-10-14 13:37 GMT+02:00 J Decker :

> probably because it's floating point native not integer like you'd think,
> so -2.0001 ** 3 is hard?
>
> On Fri, Oct 14, 2016 at 4:30 AM, Cyril Auburtin 
> wrote:
>
>> I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
>> like `-(2**3)`
>>
>> Firefox gives a clearer error then Chrome with:
>> > SyntaxError: unparenthesized unary expression can't appear on the
>> left-hand side of '**'
>>
>> Is there a reason for this restriction? Python does it `-2**3` fine
>>
>> ___
>> 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?

[J Decker]

probably because it's floating point native not integer like you'd think,
so -2.0001 ** 3 is hard?

On Fri, Oct 14, 2016 at 4:30 AM, Cyril Auburtin 
wrote:

> I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
> like `-(2**3)`
>
> Firefox gives a clearer error then Chrome with:
> > SyntaxError: unparenthesized unary expression can't appear on the
> left-hand side of '**'
>
> Is there a reason for this restriction? Python does it `-2**3` fine
>
> ___
> 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

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

[Cyril Auburtin]

I would expect `-2**3` to return -8, or `-2**2 == -4`, since it should be
like `-(2**3)`

Firefox gives a clearer error then Chrome with:
> SyntaxError: unparenthesized unary expression can't appear on the
left-hand side of '**'

Is there a reason for this restriction? Python does it `-2**3` fine
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss