はい＞＜；
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ていうか、オレンジは型推論も嫌ってるし、もっと言うとAdaみたいに「単純な型をそのまま使うな！！！ 型を作れ！！！ 型チェック！！！」って発想好きだけど、Ada使った事無いから実際にはそうしてない＞＜；
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
オレンジはこの前こんなの書いた＞＜；
https://mstdn.nere9.help/@orange_in_space/99699800406680801
では実行時にしかエラーでないので
https://mstdn.nere9.help/@orange_in_space/99699817745326661
明示的な型変換の宣言で契約プログラミングでどうにかする方式＞＜；
strong typedef する場合、「開発者の視点ではある型は制約を満たす値しか持てない」ことを保証しますが、その制約チェックは実行時に(コンストラクタ内などで暗黙に)行われるケースが多いです
オレンジがこの前「どうにかC# で、部分範囲型っぽいこと出来ないのかな？＞＜；」って書いたコードにそっくりっぽさが・・・＞＜
これっぽい？＞＜
本の虫: C++1yに提案されている不透明エイリアス(opaque alias) https://cpplover.blogspot.jp/2013/09/c1yopaque-alias.html
或いは C++ や Rust では strong typedef (opaque typedef) という技法があり、これを使うことで実質的にそういった型は定義可能です
このアカウントは、notestockで公開設定になっていません。
それ極めると refinement data type (篩型)になると思うんですが、型推論で SMT ソルバなどが必要になるので……
部分範囲型なら、nullが入らないどころか例えば2～42までの整数を表す型とか、曜日列挙型の部分範囲型として平日型を作るとかできるけど、それって入ってきちゃ駄目な値を型の段階で排除してるという面ではnull非許容な型と同じだよね・・・？＞＜
裏返して考えると、AdaとかPascalでの部分範囲型が、他の言語にほとんど採用されないのって逆にわけがわからなくなるかも・・・＞＜（範囲を決めた型を作る事で型チェックでどうにかする仕組みって、null非許容の型でどうにかしようって発想と似てるどころかさらに先をいってる発想だと思うんだけど＞＜）
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/error-handling.html
まだ読みかけだけど、確かに便利そう＞＜；
あと、"小休止：アンラップは悪ではない" の所の "パニックがプログラムのバグの兆候となるとき。" の記述が、
オレンジが書いた "むしろエラーの更なる先延ばしにしてるコードになるんじゃないのかなって気が＞＜" に相当する場面？＞＜
"// `haystack`（干し草の山）からUnicode文字 `n"（以下略）の所のコード、型がわかりにくい・・・＞＜
.? みたいな演算子は、フィールド参照にしか使えなくてロジックを繋げられないので、そこで if が必要になってしまうのがしょーもないという
null か否かの確認は、続くロジックと合成可能な形で与えることで自然に記述できる、という話もあって、 Rust でのコンビネータはそれを支援しますし、あるいは Haskell の >>= なども (Maybe や Either については)そういう使い方になるかと
これの最初の例、Adaとかだと「部分範囲型を使え！！ ていうか型作れ！！！」ってなるやつだ・・・＞＜； -- https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/error-handling.html
エラーハンドリング - https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/error-handling.html
ちょっと古いですが、これ読めば Rust での望ましいエラーの扱いはだいたいわかります
今まで「（nullやその代わりの準備出来てるかどうかの）チェックしないといけないようなコードは最小にせよ（最小にした上でどうしても残る部分はチェックする仕組みを活用して安全に）」って話だと思ってた＞＜；
・・・という事は、
"（null安全がむしろnullとnullチェックを多用せよって話だとしたら別だけど＞＜）"
って話っぽい・・・？＞＜
https://mstdn.nere9.help/@orange_in_space/99732854684419177
「これの返り値の型は、チェックが必要なやつだぜ！！！」って使う人に教える仕組み・・・？＞＜（言い換えるとそうじゃないやつを「これはいちいちチェックしなくてもだいじょうぶだよ！」って表現するためのもの・・・？＞＜）
Rust の Option と Result と ? 演算子は非常によくできているので参考になります(あるべき姿のひとつという感じ)
nullableなものでnullチェックしてないとコンパイル時にエラー出すのはまずわかる＞＜（正しいと思う） でも、それでnullを避けて出来上がるコードって、むしろエラーの更なる先延ばしにしてるコードになるんじゃないのかなって気が＞＜ ちょっと違うけど、空catchを多用してるみたいなコードになるんじゃないのかなって・・・＞＜（null安全がむしろnullとnullチェックを多用せよって話だとしたら別だけど＞＜）
このアカウントは、notestockで公開設定になっていません。
null安全の話で微妙にわからない点は、null許容型にnullを入れてる状態って、多くの場合「準備できてないです！＞＜；」って表現の為に使われてると思うんだけど、そういうコードからnullを排除しても結局『「準備できているか？」のチェックが必要』 かつ 『怠ると実行時にエラー出しちゃう』点は変わらない気がするんだけど・・・＞＜
愛生会病院、埼玉東部にあるので、行ったことはないけど目の前通った事は何回もある・・・＞＜
