新しいものを表示
orange さんがブースト

あとは「URL として正しいことが既に確約されている」という、特徴というか情報を型に持たせているという意識がある

スレッドを表示
orange さんがブースト

私は「Url 型の値として存在させる」こと自体が「URL として不正でないものとして扱っている」と見做しているので、その辺りか

壊れていても壊れていなくても後始末はしないといけないので、壊れてるって状態もあるモデル(という普段オレンジが物事を考える時に使う発想)が、ちょうどそれにぴったりかも的なアレかも><
(なので、逆に「状態なんてバグの原因にしかならない」って発想から見たら、状態なのでバグの原因かも><)

基本的にはURLとして不正な文字列を内部に持つUrlは存在しない方がいいかも>< なので不正ではないかのように扱おうとした瞬間に例外をはいてほしいんけど、
ただし!><;宣言や、コンストラクタを呼ぶ場面だけは例外出されて後始末の流れがぐちゃぐちゃになるのがいやなので、そんな変な事に><;

orange さんがブースト

1. String → Url
2. Url に対してなんらかの操作 (たとえば path を得るなど)

のどちらでエラーが出るかという話はわかるんですが、 URL として壊れた文字列の扱いについての言及がよくわからない

オレンジ的にはURLはURLであって(さっきの例に限って言うのであれば)文字列ではなくて、不正な文字列から作られたurlは、urlを作りたかったけど失敗してぶっ壊れたもので、文字列は明示的にrawな文字列として取り出す場合以外では、例えば文字列型にキャスト出来るのであれば、その時にも例外を出してほしいかも><;

orange さんがブースト

たとえば「文字列を URL にしたい」が失敗したとき出てくるのは「URL にしたかったけどできなかった『文字列』」であるわけで、であればこれは Url 型で表現できなくても文字列型として表現できるわけで、「正しい状態しか表現できない」というのはそういう程度の話です

スレッドを表示
orange さんがブースト

「正常でない」にも複数種類あるわけで、いわゆる異常系と正常系みたいな話になるけど……

返す時に例外だしてもよくない?><(もちろんエラーはなるべく早く出したいので、チェックは明示的に(><;)早くやるべきだけど、忘れてたら返す時に最後の砦として的な><)

orange さんがブースト

「壊れているかもしれない値を生で返すな」というお気持ちですね

スレッドを表示
orange さんがブースト

std::sync::PoisonError - Rust
doc.rust-lang.org/stable/std/s

mutex を持ったスレッドが解放しないまま死んだ場合、 mutex で管理されている値が不正状態になっている場合があるので、それを表現するために PoisonError<T> でラップされている

スレッドを表示

正常ではない状態は、究極に無くせない的な><(検出可能か別としても)

オレンジの物事の発想が「世の中は全て、機能と状態の集合で出来ている!><」って発想で、その延長で、ある型のものの状態にも「正常である状態」と「正常ではない状態」があるかも><って発想で、物事を考えてるかも・・・><

orange さんがブースト

不正な値でありうるか否かというのも、 Result とか Option とかによって型で表現されてほしい

orange さんがブースト

panic が実質そんな感じの挙動だけど、まあ panic は panic するために使うものであって、復帰はできるけどそういう仕組みは常用されるものではない

スレッドを表示
orange さんがブースト
orange さんがブースト
orange さんがブースト

同時に、戻り値型が Result であることで、「必ずしも構築できるとは限らない」という表明にもなっている

スレッドを表示
orange さんがブースト

そこで、例外でなく Result (Haskell なら Either) などを使うことで、正常値と異常値を値として扱えるようにすることで、コードを整理できるわけです

orange さんがブースト
古いものを表示
:realtek:

思考の /dev/null