orange @[email protected]

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 の生存期間以上でなければならない) ので、万能ではない

たとえば

let age = read_line();
let age = age.parse::<u32>().expect("Invalid age");

みたいにすれば、あるべき型の age にしかアクセスできなくなるので、 age_str と age_int が共存するよりも望ましいと考えることができる

あと、シャドーイングをすると、たとえばこの例だと「2回目の束縛以降で、不正でありうる文字列型の URL データにアクセスできなくなる」という利点がある (URL でなく文字列として取り出したければ、明示的にそういう操作を行うべき)

たとえば

let url = "https://example.com/"; // ここで文字列
let url = Url::parse(url).expect("Invalid URL"); // ここで Url 型

みたいなシャドーイングしたい場合があって、これもまあ賛否分かれるかもしれないけど、あくまで変数の意味を扱ってロジックを書きたいならこれもアリだと思いますね