orange @[email protected]

原因分かった！＞＜；
checkedブロックの中で掛け算するととんでもなく重い＞＜；

・・・実はnintのほうは、最適化で中身が空になってたりするのかな？＞＜

ちょっといじってみたけど、初期化とかじゃなく、マジでただの掛け算にこの時間のほぼすべてがかかってるっぽい＞＜；

・・・・・・＞＜

かなり前からC#に部分範囲型がない事を嘆く度にわりと馬鹿にされまくってたの、今こそ納得がいかない＞＜

ていうかさっきGeminiにオレンジのアイディアについて聞いたときに、
"""精緻化型（Refinement Types）
Ariane 5の例で出された「部分範囲型」を究極まで突き詰めると、Refinement Types になります。 これは、int などの基本型に $x >= 0 && x < 65536$ のような制約（述語）を付与した型です"""
ってまさにそれが出てきた＞＜

形式検証の簡易版？＞＜

オレンジがやってるのって結局のところ単なるRustの再発明なのかな？＞＜

結局のところ、Rustのエラーハンドリングみたいなのを、こまめにする(Rust)か、後で一気にまとめてする(オレンジが思いついたやつ)かくらいの違いくらいしかない？＞＜；

もしかしてそういうパターンで作れば、言語仕様上の工夫やIDEの支援すらもいらないのかな？＞＜
（でも危ない部分用の型と安全な部分用の型の見分けがつきにくい？＞＜；）

オレンジは思い付きでnullチェックを代用しだけど、まったく同じ発想で、『チェック前型とチェック後型』って発想を言語仕様に入れたら、ある時点まではエラーもありつつも投機的に計算して、ある時点で一気にチェックして『チェック後型』に明示的な型変換をする事で、そこから先は安全に使えるようにするって発想の実装をいろいろ作れて便利そうだけどどうなんだろう？＞＜

動作はあってるけどメッセージの内容がバグってるね＞＜；
（引き算してるのにメッセージが足し算のコピペのままだね＞＜；）

これは単にnullableなら未チェック、non-nullableなら範囲チェック済で安全って方式だけど、Roslynソースジェネレータを使ってnullable用の型とnon-nullable用の型で自動で名前をわけたら、もうちょっと見やすくなりそう＞＜

C# の自作部分範囲型ちゃんと動く＞＜

そもそも仕様にあわないものを作ってるんだから仕様にあうように実装するのは当然不可能という当然なあれなのかも＞＜；

オレンジが思いついた未チェック型とチェック済型で分ける事で無理やりSPARK/Adaスタイルにしようとする方式ではインクリメントを実装できない（そもそもAdaにはインクリメントが無い（危険だから））という事に気づいて、
GPT-5.2に「ラップアラウンドにするという妥協をするしかない？＞＜；」って聞いたら「絶対にインクリメントを実装するな！　あなたが作ろうとしてるものが台無しになる！」に限りなく近い説得をされた＞＜；

C#で部分範囲型を作りかけてるけど、もしちゃんと標準の数値型と混ぜて使えるようなガチなのを作ろうとすると、この記事にあるインタフェース全部実装しないといけない？＞＜；

[C#] INumber<T>の実装総覧 (分数型の実装例付き) #.NET - Qiita
https://qiita.com/YuHima03/items/20b59013d42d294b9839#checked%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

試しに、八代亜紀の日本海を流しながら見てみたら完全に日本海だった＞＜；