最近の検索
検索オプション
その文脈で言うなら私は真逆の立場かなぁ
何かしらのコンパイラを書いてみたい気持ちはあり、言語の素朴さと実用性のバランスをとると当然 C は候補に上がってくる。
で、当然憎き UB をどうするか考えることになるわけだけど、そもそも実用的に/原理的に検出が困難な場合も多い UB をどうするか考えるとき、警告出せそうにないなら「最も素朴な動作」にしようかというのは当然考える。
なんだけど、これって「言語として与えられていない保証を追加で与え、本来 portable でないプログラムをあたかもそうであるかのように見せるコンパイラ本位な振舞なのではないか」と思うのよ
The Harmful Consequences of the Robustness Principle
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-05.html
これのことを思い出したりもするけど、「未定義動作がそれらしく動くコンパイラ」が増えることは、つまり「本来は保証されていないのにそう動くことへの人々の期待を強める (さらには気付く機会も奪う)」ということだと思っていて、これはエコシステム全体を長期的に見たときの害がかなり大きいし、将来の規格策定の邪魔にもなると思う
たとえば hash map で実行ごとに順番が安定すると必ずそれを期待する人が出てくるからプロセスや hash map のインスタンスごとに乱数を使わせて順番をランダムにするみたいな話もそうなんだけど、むしろ「期待してはいけない挙動は積極的に壊れる」ことこそ親切なのではないかなと。で、そのうえ高速化に使えるなら一石二鳥よね
そしてそもそも検査でどうにかなりそうなものは近年 sanitizer で吸収していく流れなので (UBSan, TSan, ASan, etc.)、そういう意味でも「“明らかな” 未定義動作に気付けないのは開発者の怠慢」「“明らかでない” 未定義動作はそもそも気付くことが困難なのだからできるだけいろいろな場面でその存在を認識できる方が良い」という二方面作戦で行くのは悪くない話かもしれないと。