I also want to see a better way.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
The default alternative is "neither" - I think something as fundamental as
type annotations would need to have intuitive and conflict-free syntax, and
absolutely would have a way to work cross-realm with both objects and
primitives, to both distinguish between them and to allow both (in the case
Or enable both versions at the same time?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
So now for every type annotation, someone has to add `&& undefined`? That
seems like a lot of confusing boilerplate to have to add.
On Sun, Jun 3, 2018 at 10:39 PM, YU HengChun wrote:
> This is easy to solve, we change the word. But the code will be longer.
>
> The original:
>
> ```js
>
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:
&&
There's the separate issue that "void" in no way connotes types, so that
word wouldn't likely be acceptable, because it has no relevant meaning.
On Sun, Jun 3, 2018 at 10:27 PM, YU HengChun wrote:
> You mean this...
>
> The original:
>
> ```js
> function f(x) {
> return typeof x !== 'string'
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';
}
```
`function f(x = void String) { return typeof x !== 'string' || typeof x ===
'undefined'; } assert(f(3))` is code that might stop working properly if
`void String` changes from being `undefined` to literally anything else.
2018-06-03 22:01 GMT-07:00 YU HengChun :
> Strictly speaking, the behavior
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
What about existing code that might use `void` in a way that's confused
with your static type proposal? Suddenly it would start behaving
differently.
On Sun, Jun 3, 2018 at 8:32 PM, YU HengChun wrote:
> > A separate question is, how would String cover strings across realms,
> considering that
> 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
To clarify from above; it's almost certainly not going to be web compatible
to change how `void` works in expressions, so if another alternative isn't
viable, then it's kind of a nonstarter.
A separate question is, how would `String` cover strings across realms,
considering that `'abc' instanceof
> ```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) {
// ...
}
```
___
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.
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
How this this syntax more useful than one derived from TS/Flow, like `x: Foo`?
-
Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com
On Sun, Jun 3, 2018 at 11:48 AM, YU HengChun wrote:
> Update
>
>
> ## Compatibility
>
> For safety, it may be a good idea to use it with default values.
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
我的英文水平太 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
19 matches
Mail list logo
