Re: "Stupid" JSON Number Serialization Question

2018-05-19 Thread Hikaru Nakashima
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

2018-05-19 Thread Hikaru Nakashima
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`.

Re: "Stupid" JSON Number Serialization Question

2018-05-19 Thread Hikaru Nakashima
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 ) ```

Re: an operator for ignoring any exceptions

2017-08-13 Thread Hikaru Nakashima
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

Re: an operator for ignoring any exceptions

2017-08-12 Thread Hikaru Nakashima
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

Re: an operator for ignoring any exceptions

2017-08-11 Thread Hikaru Nakashima
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

Re: an operator for ignoring any exceptions

2017-08-11 Thread Hikaru Nakashima
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 =

Re: Ranges

2016-12-14 Thread Hikaru Nakashima
ractical > 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. &g

Re: Ranges

2016-12-13 Thread Hikaru Nakashima
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

2016-12-13 Thread Hikaru Nakashima
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

Re: Ranges

2016-11-03 Thread Hikaru Nakashima
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