逆ですね。どちらも付けなかった場合の挙動は、overrideです。

6:15 PM

↑のコードで、Derived.foo に @_nonoverride をつけると、2行目の出力が foo2 に変わる。

6:21 PM

When a protocol restates a requirement from its inherited protocol, track that as an override the same way we do with overrides in classes.

プロトコル要求を再定義したとき、クラスのオーバライドと同じ仕組みで紐付けられる。

Such overrides are recorded in the AST but are omitted from the witness table itself.

このオーバライドはASTとして記録されているがwitness talbeでは消える。

This makes restating protocol requirements in inheriting protocols ABI-neutral,

継承先プロトコルでの再定義がABIに影響を与えない(netutral)ので

so we can restate protocol requirements to influence associated type inference without baking those decisions into the ABI.

これらの決定をABIに焼き込むことなしに、associated type推論を促すために、プロトコル要求の再定義をすることができる。

6:22 PM

ここまでは意味がまあわかる、associated type推論はずっと壊れがちだったから、これをうまく動かすために、継承先protocolでメソッドを再定義するという技があって、たとえ再定義してもオーバライド判定によりテーブルに影響はないからABI上の副作用はないと。

6:24 PM

As part of this, introduce tools that allow us to audit all of the restated protocol requirements within the standard library, via a warning new warning flag (-warn-implicit-overrides) to warn about such requirements, as well as an appropriate suppression mechanism (override to treat it as an override, @_nonoverride to give it a new witness table entry).

で、このオーバーライドがちゃんと効いてることをチェックできるように、ちゃんとマーキングした上で、マーキングなしでオーバライドしてたら通知する警告を作ったよと・・・そこもわかる。 (edited)

6:26 PM

Only those restated requirements that are meant to have a semantic effect,

再定義した要求において意味上の影響を意図しているものだけは

like BidirectionalCollection.index(_:offsetBy:),

たとえば BidirectionalCollection.indexなど

should use @_nonoverride,

は、nonoverrideを付けたほうが良い

because it commits us to having that entry in the witness table forever.

なぜならテーブルエントリを永遠に保持することを約束してくれるから。 (edited)

6:27 PM

言ってることはわかるけどやっぱりBidirectionalCollectionでそれをやりたい根本的な理由がわからないな。

6:28 PM

しかもこれ、2018年9月の話なんですよね。何年も気づかなかった。。