読者です 読者をやめる 読者になる 読者になる

強い非保証

前回はプログラミング言語の挙動は何によって保証されるかということを取り上げた。 保証していないが現時点で実際そう実装されているということがあてにされてしまう場合が頻出すると追認する形で仕様になってしまう場合も少なくないのだが、保証しないという状態を更に強調した事例を思い出した。

プログラミング言語 Gomap (連想配列) である。 Go の mapイテレーションの順序は最初から保証はされていなかったが、データの数が小さい場合には一定の順序になっていて、それに依存するコードが結構あったらしいのである。 そこで Go は乱数を使ってまで毎回順序を出鱈目にするように変更された。

Go 1.3 Release Notes - The Go Programming Language

保証しないという強い意思を感じる。 保証していない挙動に依存している場合に問題が顕現しやすいようにするということを私は好ましく感じている。 プログラムの汎用的な部品を書くときには「こう動くべきだ」という想定の他に動いてはいけない場合についての配慮が必要だということは常々思っていて、何度かそのことを記事にしてきた。

問題があるなら早めに判明すべきで、早めに判明しやすい設計は良い設計だと思う。

Document ID: 3895e4797a586a74f9ae676af458279b