Re: "Stupid" JSON Number Serialization Question
Sorry for lack of words. What I am talking about is a new proposal to modify `JSON.parse()`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: "Stupid" JSON Number Serialization Question
I would like to be called and interpreted like
`BigInt("465456456465465465465465464646")` when first parsing the numeric
string.
This means that all numerical values passed to the `reviver` function and
all numerical values contained in the post-analysis object are `BigInt`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: "Stupid" JSON Number Serialization Question
Is it better to be able to pass the option object as the second argument
like this?
```
let option = { number: BigInt, reviver: conversion_function }
JSON.parse( json_string, option )
```
All JSON numbers are interpreted as follows
```
option.number( number_string )
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: an operator for ignoring any exceptions
I'm sorry, I was misunderstanding and confused, and thank you to teach me. I want you to tell me why dangerous to omit `catch`. Is that because, people abuse the syntax ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: an operator for ignoring any exceptions
Mr. Wadas,
I think whether it can replace by one line helper function is not much
relationship, because `Optional Chaining`, `Throw expressions`, or many
proposals can replace so too.
In addition, there is `optional catch binding` proposal, and this idea is
less dangerous.
Rather, this idea looks natural, because `foo = try bar` is looks like `foo
= do { try { bar } }` .
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: an operator for ignoring any exceptions
I have two thinkings about risk of this idea. First, I think this syntax is almost same risk as try-catch syntax, because try-catch syntax is often used for just swallowing errors and it will be making hard to debug. Rather, this might be better because the target of syntax is partial. This is like the techniques to convert null or undefined to basic value of types we hoped. Second, how about make the debugger tells us silent errors like uncaught promise error. I think we would not mind that all silent errors appear to console, because they was supposed to be appear if unless this syntax. For above fetch example, we would want to know errors even if we want to silent it in codes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: an operator for ignoring any exceptions
I think this idea is useful in async function.
For exsample, we write codes as below, when we use fetch() in async
function.
```js
let res, text
try {
res = await fetch( url )
} catch ( err ) { console.log( 'network error' ) }
if ( ! res.ok ) console.log( 'server error' )
else text = await res.text( )
```
or
```js
let res, text
res = await fetch( url ).catch( err => null )
if ( ! res ) console.log( 'network error' )
else if ( ! res.ok ) console.log( 'server error' )
else text = await res.text( )
```
but, we can write as below if we use this proposal.
```js
let res, text
res = try await fetch( url )
if ( ! res ) console.log( 'network error' )
else if ( ! res.ok ) console.log( 'server error' )
else text = await res.text( )
```
or do we need another syntax like "await?" ?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ranges
I understand.
I hope to find a good form of literals.
Is there a fact that literals are easier to optimize in the following cases?
```
for (let i of [1 to 5]) { .. }
vs
for (let i of Array.range(1, 5)) { .. }
```
If so, it seems that we can attract vendors' interests.
2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearns...@gmail.com>:
> I think you'd be lucky to even get to that stage. Vendors aren't keen on
> any kind of backwards incompatibility in new specs and trying to get this
> to stage 4 with such a glaring one would be practically impossible.
>
> It's not just the incompatibility either. You also introduce an
> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>
> When you consider these things, it becomes clear that it's not practical
> to change the language this way for such a small benefit.
>
> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru@gmail.com>
> wrote:
>
>> Oh, I understood it.
>> It looks like serious problem, but it is may not actually.
>> If this spec change doesn't break web, we can introduce this 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: Ranges
Oh, I understood it. It looks like serious problem, but it is may not actually. If this spec change doesn't break web, we can introduce this idea? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Ranges
My idia is as follows: ``` [1..5] //-> [1,2,3,4,5] (1..5) //-> iterate 1, 2, 3, 4, 5 [1..Infinity] // -> TypeError because n > 2**32-1 (1..Infinity) // -> valid iterator ``` ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Ranges
How about this
```
for ( i of Array.range(1, 10) ) { ... }
// OR
for ( i of [1..10] ) { ... }
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
