orange @[email protected]

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

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

C++ も (iostream 辺りは歴史的事情か例外のパフォーマンスの事情かアレな感じだけど)、基本的に「不正な状態のオブジェクトを作らず、 ctor で例外を投げろ」という感じになっているし、「正しいものしか存在できない」という感じの世界を作りたさが感じられる

理想的には型チェックが通った時点で、表明されていたあらゆる制約が満たされていることを確認したいわけで、「URL として妥当であるか」というのは「Url 型のオブジェクトとして存在できるか」と一致してほしい

Url 型のオブジェクトが出現したその瞬間から死ぬまで、ずっと Url は URL として valid な値しか持てないでほしい (型を妥当な値の集合として考えれば) ので、 new からの url.Check() で例外を飛ばすのは、ちょっと型の意味が弱すぎるかなぁという気持ちがしますね

C でもブロックを明示すれば同じことはできるので、よーするに Rust ではブロックを暗黙に作ってくれるというだけのようなもの (あと Rust ではブロックも式であり値に評価されるので、この解釈とは相性が良い)

let foo = 1;
let foo = "foo";
bar(foo);

というのは、実際には

{
let foo = 1;
{
let foo = "foo";
{
bar(foo);
}
}
}

のようなことをやっているわけで、 shadow された変数が消えるわけでもないし破棄されるわけでもないし上書きされるわけでもない、あくまで shadow されて「名前で」参照できなくなるだけ

あと Rust の shadowing は redeclaration ではないと思います

ちょっとこの記事は……

monad の do 記法を以て再宣言可能とするのは大嘘では？？？？

ただ、この方式だと lifetime あたりの問題があって、たとえば

let name = read_line(); // 所有権ありの文字列
let name = name.trim(); // 旧 name の一部を borrow しているスライス

みたいなことができない (旧 name の生存期間が新 name の生存期間以上でなければならない) ので、万能ではない