HE Shi-Jun

> it just wouldn’t change anything. At least it wouldn't allow such broken feature go to spec and may give a signal that other vendors might choose not land it.

`coerce` seems not very friendly to non-English speakers. I'd prefer `toXXX` or `mapXXX` if possible.

@ljharb As my knowledge "coerce" is not a common word in simple english (assume

@ljharb Yes it may be a pretty well-known concept, but it doesn't mean the programmers have to know the English word "coercion" for this concept. I can only tell what...

The other factor, the concept of "coerce" may be not as clear as we thought. See ["What is the difference between casting and coercing?" on stackoverflow](https://stackoverflow.com/questions/8857763/what-is-the-difference-between-casting-and-coercing). The top ranked answer...

I feel `toXXX` is like `coerce` and `asXXX` is like `cast`, so I'm not sure how `asXXX` is better than `toXXX`. > The names toKey / toValue might be confusing...

Ok, I understand your concern now, but I doubt changing name from `toValue` to `asValue` or `coerceValue` could really solve it (or even worse: they may think it as `coerceValueForCompare`...

> I think that data is actually "part" of the `{ ... }` `if` without `{}` : ```js if (let data = foo.data) process(data) else console.log(`data is falsy: ${data}`) ```...

@waldemarhorwat ~~I think python has issues of `for...else` feature (https://mail.python.org/pipermail/python-ideas/2009-October/006155.html) and I very doubt it could be success in JS. And~~ I don't think C++ consistency should have very high...

I like the idea generally, but there is an issue, `o = {[key]: v}` correspond to `o[key] = v`, so if we have `o = {[key1, key2]: v}`, it should...