Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
我的英文水平太 low, 辅助机器翻译, 看双语版吧. __O_O__ To avoid misunderstanding caused by machine translation, I use bilingual. > is already valid syntax in ECMAScript, and you can't change its semantics > willy-nilly 首先, 这个提案要求更改语义才能实现静态类型. 如果这是绝对不允许的, 那这个提案应该被拒绝. First of all, This proposal requires

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
ps: Accidentally, the email just sent was sent to isiah. This is a copy TS/Flow is better about static type constraints. If the syntax of TS/Flow can enter the proposal, I will not submit this proposal. The only benefits of this grammar are: Even if the proposal cannot be passed, it will

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
Update ## Compatibility For safety, it may be a good idea to use it with default values. ```js let isUndefined = void Number, // Static type constraint does not take effect isNumberUndefined = void(Number)|undefined; // Static type constraint take effect ``` ## Pending I'm not

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
Consider the significance of this proposal from another perspective: 1. It is a native ECMAScript 1. It can be regarded as an enhanced version of asm.js 1. It has always existed, but it has been neglected and has not been fully utilized. 1. The cost is much lighter than adding a new grammar 1.

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
> ```js > function CustomNumber(x = void([Number, mod.BigNumber]) || 42) { > // ... > } > ``` > > which is arguably awkward. Easy, change the word well. ```js function CustomNumber(x = typeof([Number, mod.BigNumber]) && 42) { // ... } ``` ___

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
You mean this... The original: ```js function f(x) { return typeof x !== 'string' || typeof x === 'undefined'; } ``` The proposal: ```js function f(x = void String) { void Boolean; // The complete code should be like this return typeof x !== 'string' || typeof x === 'undefined'; } ```

Re: Re: Proposal static type constraints features

2018-06-04 Thread YU HengChun
I also want to see a better way. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
> A separate question is, how would String cover strings across realms, > considering that 'abc' instanceof String already returns false even in the > same realm? There is no such way in the proposal. 提案中没有这样的写法. The real purpose of the expression in void is not the operation. It is

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
Or enable both versions at the same time? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
The typeof version does have this problem. So, how to choose? Maintain the original semantics of the word? Or define new semantics for void? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
Strictly speaking, the behavior is different. However, can you provide me with a real, conflicting example? Or you give me an example, I write a version of the proposal, you can test whether it is really harmful. If it is finally proved that the semantics are different, but it is indeed

Re: Re: Proposal static type constraints features

2018-06-03 Thread YU HengChun
This is easy to solve, we change the word. But the code will be longer. The original: ```js function f(x) { return typeof x !== 'string' || typeof x === 'undefined'; } ``` The proposal: typeof version ```js function f(x = typeof(String) && undefined ) { // Attention can not be omitted: &&