orange @[email protected]

想定していない状態が発生したということは、プログラムを書くときに開発者が置いた前提と実世界が食い違っていたということで、それって既に「間違った前提で書いたコードが見掛け上正しく動いてるだけ」ですよ

なんで既に仕様通りに動いていないプログラムを見て「や、でも終了処理とリソース解放だけはちゃんと行われているはずだ！」と信用できるんですか……

「正常ですという顔をして裏では発狂していて、ユーザの想定しない悪行を為している」とか絶対許さないマンですよ私は！

なんだよ根本から噛み合ってねえじゃねえか！！！w

それ、まさしく私が許したくない状態ですが……

で、「一部の (意味ある) 値の参照が許されなくなったけど続行してね！」というのは通常不可能なので、文脈そのものを破棄するというデフォルトは合理的でもあるわけです。
そうしないオプションが提供されているとしても、デフォルトでは文脈の破棄になるのは妥当。

「文脈を巻き込まず一部のデータだけパージすればええやん」というのはまあ理屈の上では正しいんですが、実用性は微妙だと思うんですよね。
そもそもプログラムが動作するうえで、ふつう参照する値の全てには意味があるので (意味のない参照なら消せよとなる)。
「一部の値は参照すら許されない状態になったけど続行してね！」とかかなり過酷で不自然な状況で、これを正しく実装するのって通常のエラー処理どころではないコストがかかりますよ

必ずしもそれだけの問題ではなく、たとえばポインタと型情報であるとか、配列とインデックスであるとか、そういう「組み合わせてはじめて整合性が定義される」ようなものはよくある (というか整合性はそもそも複数のデータの集合について規定されるのが普通) ので、インデックスの計算でトチって配列を変更しなかったとか、インデックスは正しく算出できたけど配列の作成でトチったとか、そういう状況ではやっぱり「汚染」は伝播している

で、デフォルトで汚染されていると想定する連鎖が最終的にどこまで広がるかというと実行の文脈全体なので、だからこそ「起きえないことが起きたら文脈を破棄しろ」という話になっている

や、まあ特定のスナップショットについては当然これは可能なんですけど、改変される可能性のあるプログラムについてこのようにブラックリスト形式で汚染を排除していくのはデザインとして正しくないと感じます。
特定の汚染が特定の場所に伝播しないという保証があるなら、安全側に倒してデフォルトで汚染されていると想定するべき。

はい、適切に分割してください。

ただ、その「汚染範囲を小さくする」を誰が行うかの話で、「この変数は、こことここと、この部分に影響してます！」とかいうオプトインな列挙方式でうまく汚染を隔離できると思うなよという思想の話ですね

それでも、「起きえないことが起きた」ときプログラムは最善の努力として「自分が悪影響を及ぼした範囲を更地にすることで『うっかり汚染された領域に踏み込む』ことを阻止する」責任があると考えているけど

不整合や仕様外動作に汚染された領域を破棄する手段として通常は文脈の破棄しか用意されていないという話と、仕様外動作を仕様に含んでいるかのように振る舞うことは根本的におかしいというデザインの話が混ざっていたか