2020-03 の TC39 meeting
まとめ
決まったこと
Web compatibility issues / Needs Consensus PRs
ECMA-402 の仕様で各ビルトインクラスの toLocalString を実装が拡張してはいけないと定められているが BigInt#toLocalString が忘れ去られていたため、一つ一つ列挙するのを辞めて toLocalString メソッドは一律で拡張してはいけないことを明記する話。コンセンサスが得られた。
"𝒜" を表すために文字列リテラルでは以下の記法が使える。
"𝒜"
"\ud835\udc9c"
"\u{1d49c}"
一方で正規表現リテラルだと u フラグを付けると扱うことが出来るが、付けない場合 /\u{1d49c}/ が扱えない。それをどうするか。
code: (js)
/\u{1d49c}/u.test("𝒜"); // true
/\u{1d49c}/.test("𝒜"); // false
/\u{1d49c}/.test("u{1d49c}"); // true
コンセンサスが得られて、フラグがない場合にも対応することになった。
/\ud835\udc9c/ will be made legal
/\ud835\udc9c/u remains legal
/\u{1d49c}/ will be made legal
/\u{1d49c}/u remains legal
/𝒜/ and /𝒜/u will remain legal
Atomics のスタティックメソッドは概ね SharedArrayBuffer だけではなく ArrayBuffer にも使うことが出来るが、Atomics.{wait, notify} だけ考慮されていないおかしな仕様になっているのを修正する話。コンセンサスが得られた。
Spectre 脆弱性によってデスクトップ Chrome のみ SharedArrayBuffer がデフォルトで使える状態が続いている。これは Site Isolation によるもので、他のブラウザが簡単に扱えるものではない。
ところでブラウザ間では Cross-Origin Opener Policy と Cross-Origin Embedder Policy によって SharedArrayBuffer を使うことが出来る範囲を指定し、その中では使えるようにしようという話が進んでいる。このためには ECMAScript 側の仕様では SharedArrayBuffer をオプショナル扱いにする必要がある。コンセンサスが得られた。
このあたりの議論については Jxck さんのブログ記事が詳しい。
Add support for 'OptionalChain'.PrivateIdentifier in class features proposals (slides) | Caio Lima クラスの Private Identifier を伴うアクセスにも Optional Chain を使えるようにする話。
code: (js)
class C {
static method(o) {
return o?.c.#f;
}
}
コンセンサスが得られた。
Stage 4 (ES2020)
すべてのモダンブラウザに実装されている状態ということで、無事 Stage 4 になった 🎉
Stage 3
FinalizationGroup が FinalizationRegistry に変更された。またブラウザのプロセスが落ちたり、タブを閉じられたりなどの際にはコールバックが実行されなくてもいいということになった。
また HTML の仕様の各スレッドでどのように動作するか議論することになった。
Atomics.waitAsync が同期的に例外を投げるようになっているが、Async Functions 内では非同期にしてはどうかという提案。コンセンサスが得られた。返す type としては以下の通りらしい。
code: (ts)
{async: false, value: "not-equal" | "timed-out" } | { async: true, value: Promise<"ok" | "timed-out"> }
無事 Stage 3 になった。
Stage 2
Temporal Update (slides) | Jason Williams, Philipp Dunkel, Ujjwal Sharma 前回に引き続き ISO 以外のカレンダーのサポートについて話された。そしてロードマップが公開された。
https://gyazo.com/6da5ea9451c88eb401e3bea364988c3b
どうやら Static Decorators は3度目の正直にならなかったみたいなので、新たな Decorators が提案された。今度はプロパティの Read/Write をトラップするらしい。詳しくは issue で話されている。 code: (js)
class C {
@decorator foo;
}
// ↓
class C {
get foo() { /* … */ }
set foo(v) { /* … */ }
}
ユースケースをもう一度考え直してリスタートするとのこと。
ついでに自分の記事も更新した。
Stage 1
TypedArray に stride を入れる提案。Graphic Team による見解から size のない stride はそれほど使われることがないため第四引数に新たに追加する形になっている。
今のままだと例えば WebGL の頂点データを構造体として保持する場合に offset の指定がうまくいかない問題があったり、構造体のプロパティごとに TypedArray を用意するのが面倒くさいことが指摘されている(issues)。十分な機能をまだ有していないといえる。 また TypedArray は多くの仕様の根幹となっているため実装する作業量が多く、それに担うほどのモチベーションがあるのかという指摘もされた。
今のところ DataView と Proxy を使った polyfill が用意されている。
めちゃくちゃ境遇が自分が polyfill を書いて推している Float16Array に似ていると思った。
ユースケースのフォームを設置し、アンケートを取っているとのこと。
BigInt とのかみあいや、Decimal128 にするか BigDecimal にするか。そして Operator Overload や Extended Numeric Literal の提案と関係していることなどが共有された。
シンタックスとして #[ a: 1 ] にするか [| a: 1 |] にするかの議論があったが、どうやら前者になりそう?
新しく Stage 0 RefCollection という提案を考えていて、ミュータブルなオブジェクトを突っ込めるようにする話があがっている。
code: (js)
const rc = new RefCollection();
type: "button",
props: #{ onClick: rc.ref(() => alert("clicked!")) }, ref: rc.ref(document.getElementById("my-button")),
};
rc.deref(vdomButton.props.onClick)();
また Stage 0 Deep Path Properties in Record Literals としてリテラルを拡張する話もあがっている。
code: (js)
const rec = #{ a.b.c: 123 }; assert(rec === #{ a: #{ b: #{ c: 123 }}}); Babel にはシンタックスの PR がマージされていて、この提案のリポジトリにある Babel Plugins を使うと試すことが出来る。
簡単に Range の Iterator を作れる提案。地味に嬉しい。
code: (js)
for (const i of BigInt.range(0n, 43n)) {
console.log(i); // 0n to 42n
}
// With iterator helper proposal
Number.range(0, Infinity)
.take(1000)
.filter((x) => !(x % 3))
.toArray();
function* even() {
for (const i of Number.range(0, Infinity)) {
if (i % 2 === 0) yield i;
}
}
Stage 1 になった。
Intl.NumberFormat に更に追加する提案。範囲の対応や、精度、単位のスケールなどもろもろが盛り込まれている。Stage 1 になった。
Private Fields でもプロパティを持っているかどうかを判定できるようにするやつ。
in を使った提案。
code: (js)
class C {
static isC(obj) {
}
}
try を使った提案。
code: (js)
class C {
static isC(obj) {
return try obj.#brand;
}
}
Stage 1 になった。
SES の提案から Compartment クラスの仕様がスプリットされて Stage 1 になった。
Stage 0
前回議題に出たが、函数が this を要求しているかどうかを調べられる Reflect なメソッド Function.isThisArgumentExpected(func: Function) が欲しいという提案。これによってフレームワークやライブラリ、ディベロッパーツールなどで this に起因するエラーを見つけることが出来る。
code: (js)
forEach(f, thisArg) {
const a = this._array;
if (Function.isThisArgumentExpected(f)) {
if (thisArg == null) { throw new Error('expect this argument'); }
a.forEach(f, thisArg);
} else {
if (thisArg != null) { throw new Error('not expect this argument'); }
a.forEach(f);
}
}
いっそのこと過去に提案に上がった Reflect.is{Callable, Construct} と合わせて、それらのディスクリプタを取得できる API でもよいのではという話ある。
code: (js)
Function.reflect(f);
// => {
// canApply: boolean,
// canConstruct: boolean,
// thisArgumentExpected: boolean|null,
// }
Stage 1 にはならず、引き続き議論することになった。
Stage 3 hashbang syntax についてもっと寛容的なシンタックスにする提案。もともと
code: (js)
if (typeof window === "object") {
console.log("browser env");
} else {
console.log("node env");
}
とすることでブラウザ環境でも Node.js 環境でも実行できる仕様であるが、ブラウザのインラインスクリプトの場合に先頭にあらゆる空白を許さない仕様となっているので
code: (html)
<script>#!/usr/bin/env node
console.log("ok");
</script>
のように記述しないとシンタックスエラーになる。
Remaining queue:
1. the context (an inline include, eg) is required information when authoring test.js Jordan Harband
2. I'm in favor of tolerating initial whitespace. But not other places Mark S. Miller (@Agoric )
3. why should we cater to simplistic/brittle code transform tools? Jordan Harband
4. Should not do this Waldemar Horwat
5. We should not set a precedent that simple concatenation preserves semantics Shu-yu Guo (@google)
6. Are there examples in other languages that don't use # for comments, but ignore hashbangs? Philip Chimento
7. There's already some precedent with sourceURL and sourceMappingURL, which only have an effect once Devin Rousso
8. Hashbang starting with a space is not a valid hashbang on Linux (and probably other UNIX systems) Matheus Marchini (@Netflix)
9. Even simple ASCIIfiers need to understand JS semantics Justin Ridgewell (@google -> @ampproject )
その他
ECMAScript の仕様を作っている人たち向けに素早く仕様のチェックをするために JavaScript で作られた実装環境。
Process: require public repo for stage 1 (issues) (PR) | Jordan Harband Stage 1 のものは必ずリポジトリを作ることになった。
総括
import.meta が無事 Stage 4 になり、Logical Assignment が Stage 3 になった一方で、Stage 2 Decorators がまた根本から仕様を変えようとしていて気が気でない。新しい提案としては {Number, BigInt}.range がミッシングピースだったので Stage 1 になってよかったと思う。