Rust part23
>>99
対処の必要があるものはその通り
しかし実害がないと皆が判断して対処優先度低いまま9年間が経過したが実害がな起きていない
そんな状況のものを杞憂したり揚げ足取りでRustを叩いてる連中がゴミ 事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな >>101
これが矮小化と言うやつか
7割がバグ潰しを「最優先」と回答している事実
直したくても直せないまま何年も経過、unsafe無しでメモリ安全ではない(事実)、Rustの不健全仕様(事実)
(unsound=不健全は数学用語、要は矛盾があるという事)
幸運にもRustが使われなさ過ぎで実害がないように見える(または報告がないだけ)
(良心的に考えてRustが広く使われてない内に)バグ潰しをしとけ、がユーザーの9割の意見(中優先含めて)
週明けのテック記事はどう書くのかな
良い所だけ抜き出してビューが取れるハイプ期間は弱まったと思う
それと飛ばし過ぎるといなくなるorz アンチもMozillaが変なことやってるだけで
firefoxに導入できるわけがない一般人が
使えるようになるのは妄想とか
言ってた頃に比べると細かい実装の穴を
ネチネチやるまでになって大変だなあ >>103
根本的なことを理解できてないようなので一点だけ
unsafeがプログラム全体に散らばっている他の言語に対して
Rustはunsafeを局所的に閉じ込めて安全なインタフェイスを公開しそれを使ってプログラミングする言語
よく使われる基本機能は標準ライブラリとしてunsafeを閉じ込めてあるが
必要なら自作を含めてunsafeを閉じ込めたライブラリを使ってよい
他の言語と比べてunsafeを局所的に閉じ込めた部分のみ注視すればよいことがRustのメリット >>105
unsafeに閉じ込められなかった事実を提示されてるんだが何言ってるんだ？ Rustコンパイラにバグがあるのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。 unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは
もちろん呼び出される側の安全性ではない
呼び出す側だけが検査される
しかも検査が完璧かどうかは実装依存
じゃあ言語仕様により保証されるのは何か
言語仕様は、あとは検査が通るか通らないかを確かめればよいというところまで仕様を確定しなければならない プログラム全体がunsafeなC/C++は使いたくない
未定義な動作も多すぎる >>109
Rust関係無しに基本的なことを理解できてないようだけど
掛ける情けも無し 反論できないときは関連するワードを含むRustの宣伝文句をぶつける
いつもの流れです 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」
https://news.mynavi.jp/techplus/article/20240222-2889545/ >>105,109
詐欺師みたいな偽者だな、Rust不信の種まきするのやめろ
>>112
分かっていれば支離滅裂文章なんだけど騙されるのは学生位だろうか >>前スレ992
Derefは演算子
・そのためstd::ops::Derefにある (変換std::convert::AsRefと対照的)
・演算子*によりderefされる
・&**へとcoerceされる Derefの名前の由来は*演算子（dereference：参照解決）だろうけど
機能は&**へのcoerceを前提にしてて結果的にrefのままだからややこしいな
現状だとInnerRefの方がしっくりくる 意味的にはFollowRefの方が自然かな
まあ*演算子で使われるtraitだからDerefでいいんだけど 【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1708865670/l50
ボイス・トォ・スカるしている者も攻撃を受けるようになりました >>115
>・&**へとcoerceされる
これDeref Coercionのこと言ってる？ だとしたら&**に限定する意味がわからない
あと前スレ992で重要なのは&T→TはDerefの役割ではないというところね
>>116,117
スマートポインタのdereferenceのために存在するTraitだから
InnerRefやFollowRefよりDerefのほうがずっと自然だと思う
*演算子の振る舞いとは別にcoercionの振る舞いは理解しなければいけない
そういう点でも「Derefは演算子」という捉え方は良くないよ Rustて、演算子と関数を(意味論的に)区別していたっけ？
中間記法によるややこしい結合順の違いがあるぐらいで、構文解析後は等価だから、あんまりこだわっても仕方が無い気が。
中間記法の演算子は人間の算数の記法に配慮しているだけの悪習でしか無いから、積極的に差異をつけないほうが良い気がするけど。 Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。 +に対するAdd, &=に対するBitAndAssignと同じ位置づけで
(*T)に対するDerefがstd::opsに入ってるイメージだけど
(*T）自体は
let x: Box<String> = Box::new(String::from("foo"));
let y: String = *x;
みたいに参照先の値を取り出す使い方ができてむしろそっちが本来の意味なのに
それができないtrait DerefがDerefを名乗ってるのが微妙だと思った >>121
サンクス。
「演算子」じゃなくて「 * (参照外し演算)」ということね。 >>116
*を明示的に付けるとdereferenceされるからDeref
&**によるcoerceは何も付けずに適用される
そのため参照から参照へ型が変わるだけで参照のままとなる
>>119
Derefはoperatorなのでstd::opsにある
Derefでも&T→Tと実装されている
Derefによるcoerceは&**となる 関数と同じでは困るものといえば && || が有名だけど = が一番やばい
初期化とか代入とかコピーとか移動とか >>125
=はパターンマッチング
マッチングした時にCopy実装があればコピーされる
以上で極めてシンプル Rustにおける = は心の中でバインド演算子って呼んでるわ >>124
>Derefはoperatorなのでstd::opsにある
https://doc.rust-lang.org/std/ops/index.html
ここ見ればわかると思うけど各Traitの説明に”The ~ operator”と書いてるものがoperator
Derefは”Used for immutable dereferencing operations, like *v.”とあるようにDerefそのものはoperatorではない
>Derefでも&T→Tと実装されている
Deref<Target=T> for &Tの実装が提供されてるのは別の役割のため
その実装が実行されて&T→Tになっているのではない
Box<T>→Tなんかも正確に言えば&Box<T>→&T
>Derefによるcoerceは&**となる
全然わからない
何か一つくらい根拠を提示してくださいな Derefによるcoerceは&**となるのが全然わからないって本気なのかな？
「corece後の参照」= &**「corece前の参照」
となるのがDerefによるcoerceだよ >>129
＞「corece後の参照」= &**「corece前の参照」
実験コード書いて一通り確認してみたら
たしかにそうなった 上の一連の流れ見てるだけでRustしんどそうに見える >>129
なるほどそういう風に捉えてるのか
ちょっと独特だね
それはcoercionの動きというよりderefのシグニチャを
内部的にderefを使ってる*演算子で再定義しようとしてるので
循環が気持ち悪いけど一つの見方として頭の隅にしまっておく
ちなみにThe Bookにある一つの例ではderef coercionがなければ*が余計に必要と説明されてる
https://doc.rust-lang.org/book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods
それに&**とは必ずしも等価じゃないからDeref Coercionを説明するのにはあまり勧められないかな
let x = "Hello".to_string();
let y = Box::new(x);
let z = &**y; //zは&strになる
let z:&str = y; //これはcoerceしないのでコンパイルエラー こんな議論が発生する時点でかなりややこしくて面倒な言語がであることは認めざるを得ない そんなことよりDerefの定義の中で参照外ししている↓が無限ループにならない理由でも調べてみたほうが面白いよ
https://doc.rust-lang.org/src/alloc/boxed.rs.html#1927 >>135
それが&T→TはDerefの役割ではないという話 rustは使い勝手のために暗黙にokにした構文が逆にわかりづらさを生んでる。 >>137
まあそれは他の言語も歩んできた道だから……
良いとは言わんけどなくてもめんどいんだよな。 >>136
*selfはそれでいいけど、**selfはそれじゃ説明付かんぞ >>139
&T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ？
Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・ >>133
まず基本を理解しよう
deref coreceは必ず参照から参照へのみ起きる
Box自体は当然deref coreceされない
その例だと
let b = Box::new("Hello".to_string());
まずc0は単なるBox参照
let c0: &Box<String> = &b;
このc1とc2がderef corece
let c1: &String = &b;
let c2: &str = &b;
そのc1とc2を明示的に書くとこうなる
let c1: &String = &**(&b);
let c2: &str = &**(&**(&b));
この暗黙に適用される&**がderef corece
この自動適用のおかげでstrのメソッドが使える
assert!(b.starts_with("He"));
フルに書くとこうでもちろん対象はbではなく&b
assert!(str::starts_with(&b, "He"));
この&bが前述の通り自動的に&**(&**(&b))となり&str型へcoreceされている >>141
圧縮アーカイブならzipクレート
圧縮ならlibflateクレートなど >>133
＞ coercion
横から素人がすまん、これ何て読めばいいの？ Rustもちょっと前の熱狂はなくなってしまった感じ
入込数が減ってると思う まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは >>144
発音[US] kouə́ːrʒən ｜ [UK] kouə́ːʃən
カナ[US]コウアァジョン、[UK]コウアーション
参考：https://eow.alc.co.jp/search?q=coercion
自分はコアジョン派 Tのスマートポインタの参照 -> Tの参照
文字の配列の参照 -> 文字のスライス
一連の流れを見るとみんなポインタに熱狂している >>150
そこはポインタと参照の根本的な違いを理解しできるかどうかかな
「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが
「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ
したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる
だからスマートポインタの参照を渡すことになる
一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない
しかし参照＝ポインタではなく参照は抽象的なものなのだ Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。
C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、
参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。 その橋渡し役がDeref coercion
&Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが
Box<T>→TのDerefがあるため
&Box<T>→&TとDeref coercionが適用できる
静的にコンパイル時点で行われるため実行時コストはかからない >>142
この辺り最初理解するまで訳分からんかったな
理解すると大したことはないのだが >>142
>deref coreceは必ず参照から参照へのみ起きる
&**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね
それは別にいいんだけど書いてる内容を見る限り
Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく
実際に&**が適用されると思ってるみたいに感じるね
だとしたらそれは完全な間違い
derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ
Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね Derefは*
Deref coercionは&**
前者は明示が必要な点が違い
x: &Box<T> とすると
*x: Box<T> (by Deref &T→T)
**x: T (by Deref Box<T>→T)
&**x: &T (xのDeref coercion結果)
x: &Vec<T> とすると
*x: Vec<T> (by Deref &T→T)
**x: [T] (by Deref Vec<T>→[T])
&**x: &[T] (xのDeref coercion結果)
x: &String とすると
*x: String (by Deref &T→T)
**x: str (by Deref String→str)
&**x: &str (xのDeref coercion結果) >>157
とりあえずDerefの定義が
pub trait Deref {
type Target: ?Sized;
// Required method
fn deref(&self) -> &Self::Target;
}
（https://doc.rust-lang.org/std/ops/trait.Deref.html）
でderef()の戻り値には自動的に&がつくから
*x: Box<T>
*x: Vec<T>
*x: String
はDeref traitと関係ないことを抑えておこう
そこに（by Deref…）を書かれると話がおかしくなる
*Tができることの一部をDeref traitではできない
正確な表現かは分からないけどDerefは&の向こう側でしか*を適用できない こうだろ
x: &Box<T> とすると
*x: Box<T> (by Dereference)
**x: T (by Deref Box<T>→T)
&**x: &T (xのDeref coercion結果)
x: &Vec<T> とすると
*x: Vec<T> (by Dereference)
**x: [T] (by Deref Vec<T>→[T])
&**x: &[T] (xのDeref coercion結果)
x: &String とすると
*x: String (by Dereference)
**x: str (by Deref String→str)
&**x: &str (xのDeref coercion結果) なんかゲシュタルト崩壊してきたんだがｗ
関係ないけど微積のdxとかdyを思い出してしまった C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ Deref coercion &**のうち
右側の*は参照に対する参照外しで
左側の*はDerefで定義(実装)されてるものなのね let s = String::from("xyz");
let x: &str = &s;
let x: &str = &&s;
let x: &str = &&&s;
これ全てコンパイル通ってderef coercionされるから
『by Deref &T→T』も適用されていると思うぞ >>163
&&T→&Tのことを&T→Tとは書かないわな
前者の用途にDeref for &Tは存在してる >>156
演算の名前はdereference
derefはDerefトレイトに定義してあるメソッドの名前
>>157
>Derefは*
違う
Derefはトレイト
*はdereference operator
>Deref coercionは&**
違う
Deref Coercionとはcoercionが行われる場合に「&Tを&<T as Deref>::Target」にcoerceすること
Deref Coercionと*などの演算子は全く別の独立したものとして扱われている
それぞれの処理の一部で必要に応じてDerefに定義されたderefメソッドを活用してるというだけ
片方がもう片方に依存してたりもしない
Deref Coercionの処理の一部として呼び出されるderefメソッドを
演算子で擬似的に再定義しようとすれば&**になるというの話はかろうじて理解できるが
前述のように定義が循環してるだけでなく再定義する価値を見いだせない >>164
&&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない？ >>164
Deref coercionの定義を理解しよう
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
&String→&str (by Deref String→str)
&Vec<T>→&[T] (by Deref Vec<T>→[T])
&Box<T>→&T (by Deref Box<T>→&T)
&&T→&T (by Deref &T→T)
これらはすべてDeref coercion >>165
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
U＝*T
↓ &Tから出発すると
U＝**(&T)
↓ 両辺の参照をとると
&U＝&**(&T)
つまり
Deref coercionとは&**の自動適用のこと *xが左辺値なら代入、*xが右辺値なら複製とかいう演算に
ビルトインderefみたいな名前をつけるのが間違っている >>170
mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない
左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない 判りにくい仕組みだけどこれから開発が進むと
文法変えたりするのかな？ これほど分かりやすくて便利な明確な仕組みはない
他の言語と比較すれば明らか 他の言語でこれより良いものが存在しないね
RustのDeref
・自動適用されプログラマーの負担を軽減し利便性も良い
・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能
・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作 >>172
Pythonが分かりやすいのは知ってるけど
RustとPythonは両極端だから文法を微調整してもしょうがない
文法を変える必要があるのは両極端を否定する言語だけだ Derefなのに&が消えてない（小並感）
背景を理解しないと引っかかりやすいRustの七不思議候補 この仕組みがベストであるという主張は3種類ある
一つは馬鹿な信者が言ってるだけという可能性
一つは本当にこの仕組みがベストである可能性
最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性
このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる
馬鹿な反論が返ってきたら馬鹿な信者
合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない
意見を翻されたら素直な馬鹿 この仕組みがない方が良いということ？
下手で全部書くべきと？ RustのDerefとそのcoercion枠組みの利点
・プログラマーの負担が減る
・コードが見やすくなる
・枠組みはDerefトレイト利用で明白かつ汎用的になっている
・自分で作った型にも実装して作動させることができる
・静的に解決しているためミスしてもコンパイル時にわかる
・実行時に付加的な動作がなく高速に実行される
これらの利点を上回る方法があるならば知りたい
既存の言語でも新規の方法でも >>179
>下手で全部書くべきと？
どこかの方言？ >>178
いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。 Rustの方式の利点は>>180に挙げられているから
もしRustより良い言語が存在するならば
その方式およびRustの利点を上回る利点を挙げればいいんじゃね？ 検証可能とはコンパイラが無謬であることではない
ここが難しい
コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること
これが検証可能 単に理解できないから難癖つけてるだけだよねこの人
自分の主張も一切ないし 誰かの難癖を自分が思い付いたかのように言ってるだけで
何一つまともな批判はない 全く相手にすべき人間ではないと判断する
よって今後無視する >>184
それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき
その際他の道具との比較も必須ではない 技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂 Rustの方式の利点は>>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？ >>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう 物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな >>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど 
