Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/

**デフォルトの名無しさん** · 2024/07/12(金) 17:11:30.65

>>780
サンキュー

>>781
そのあたり全然勉強してない
「相互に参照し合うあうメモリは持てません。それを制限してあまりあるメリットを提供します。どうしてもやりたい人のために別口を用意しました」
という事実が重要

**デフォルトの名無しさん** · 2024/07/12(金) 20:20:08.14

Rust製コードエディター「Zed」がLinuxにようやく対応
Windowsサポートにも期待

ttps://forest.watch.impress.co.jp/docs/news/1607906.html

**デフォルトの名無しさん** · 2024/07/12(金) 20:23:46.34

個人利用は無償～JetBrainsがRust向けIDE「RustRover」を一般公開
メモリ安全性を保障したプログラミング言語「Rust」の開発に特化した統合開発環境

ttps://forest.watch.impress.co.jp/docs/news/1607747.html

**デフォルトの名無しさん** · 2024/07/12(金) 20:46:42.78

別口を用意するとは？
RustらしくないRustを用意することかな

もし日本語らしくない日本語が何か成果を出したら
日本語らしさを学習したAIに都合が悪い

**デフォルトの名無しさん** · 2024/07/12(金) 21:35:52.40

>>784
慣れの問題なんだろうけど
vscodeがいい…

**デフォルトの名無しさん** · 2024/07/12(金) 22:05:28.85

>>785
参照カウンタ等がその別口
逆に聞くけど全てを参照カウンタで書かないのはなぜ？

**デフォルトの名無しさん** · 2024/07/12(金) 22:12:50.70

>>781
RcやBoxは分かりやすいけどStringやVecも動的確保だよね、ということに気付いてない人もいるかも？

Rustが良いのはムーブが基本なおかげで意図せぬメモリコピーが起きないこと
所有権を他に渡す (ある構造体から別の構造体にか、あるコンテナから別のコンテナにとか移動する) 際にコストが発生しない
C++は逆で明示的に move しないと意図せぬコピーが起こる

**デフォルトの名無しさん** · 2024/07/12(金) 22:30:09.43

>>787
強制されてないから
嫌なら使わなければいい

**デフォルトの名無しさん** · 2024/07/12(金) 22:37:23.69

電気電子板の人が、Rustの特集やってるインターフェース誌を買って読んだけどわからんかったって言ってたよ

**デフォルトの名無しさん** · 2024/07/12(金) 22:52:07.26

>>789
俺はそんなことしないよ
全てを参照カウンタなんて使わずに書かない理由を探る

**デフォルトの名無しさん** · 2024/07/12(金) 23:03:04.47

>>787
C++で常にshared_ptrを使うと遅い
参照カウンタを利用しがちなSwiftやNimは遅い

**デフォルトの名無しさん** · 2024/07/12(金) 23:08:24.73

参照カウンタ自体は全然新しくない
Rustがそれを無くせない理由が知りたい

**デフォルトの名無しさん** · 2024/07/12(金) 23:24:14.35

複数の所有者がいる場合に参照カウンタが有効なのは分かる
難しいのは循環参照
参照カウンタで何が書け、何しか書くべきでないか

**デフォルトの名無しさん** · 2024/07/12(金) 23:48:00.71

>>793
メモリ安全性を提供するため
オブジェクトを共有するのに「所有権は1人だけが持ち、他はそれを参照する」仕組みだと、すでに実体が消えてるオブジェクトを参照する問題が起こり得る
Rustでは、そのようなオブジェクトは参照カウンター付き (RcやArc) にするか、ライフタイムにより「寿命の短いものが寿命の長いものを参照している」ことを示さない限りコンパイルが通らないようにすることで安全性を保証している

逆にC++は参照カウンターなしでも共有できるけど正しく実装しないとメモリ関連のバグを引き起こす
この手のバグはセキュリティの問題になり得る問題を特定しにくい等の厄介さがあるから、Rustはそれをコンパイル時にできる限り防ぐという考え

**デフォルトの名無しさん** · 2024/07/12(金) 23:56:48.21

同一スレッド内の別タスクと共有する時にRcを使う
別スレッドや別スレッドになりうる別タスクと共有する時にArcを使う

**デフォルトの名無しさん** · 2024/07/13(土) 00:02:12.31

親子関係のようなオブジェクト間で相互参照するならWeakを使う
これはRcやArcから作るもので、「メインの所有者とそれを弱参照する共有相手」の関係になる
Weak側は相手がまだ存在することを確認できないと参照できないというもの

**デフォルトの名無しさん** · 2024/07/13(土) 00:46:50.81

Rust の所有権システムは機械的に静的検証が可能なように設計されている。
しかし Rust のルールでの機械的静的検証で安全だと確信できないが実際には安全というケースは
ごく普通にあり、その内の典型的なものは実行時のチェックで補えるようにライブラリが整備されている。

**デフォルトの名無しさん** · 2024/07/13(土) 02:23:43.98

>>787
全てをRcで扱って渡すときはRcをclone()して渡せばライフタイムを気にしなくて済むが
参照カウンタとその増減のオーバーヘッドだけでなく
書き換えたいなら内部可変性を持ちそのオーバーヘッドも加わるとともに
スタック上で済むときも必ずヒープ利用となるオーバーヘッドもある

**デフォルトの名無しさん** · 2024/07/13(土) 08:49:12.36

zennとかqiitaとかのrust記事みてると
活発に描いてた人は2019-2022くらいで
その後更新されてないのが多い
みんな試しただけで使ってないのか

**デフォルトの名無しさん** · 2024/07/13(土) 08:51:48.91

>>784
いくつものバージョンのrustやそのバージョン用のcratesを
それぞれ独立に管理して切り替えて使える統合環境なら嬉しいな
venvみたいな

**デフォルトの名無しさん** · 2024/07/13(土) 08:54:10.60

>>788
>Rustが良いのはムーブが基本なおかげで意図せぬメモリコピーが起きない

doubt

**デフォルトの名無しさん** · 2024/07/13(土) 08:56:33.88

>>790
特集のRustは知らんけど
特集じゃなかったときのインターフェースで紹介されたRustは
(インターフェース誌の読者に多いであろう)C言語利用者に判り易く説明されていた
そういうスタンスだからC知らん人にはきついのかも

**デフォルトの名無しさん** · 2024/07/13(土) 08:58:41.51

>>793
無くせない訳じゃなくて
参照カウンタを使わない描き方は今でも充分過ぎるほど可能
特に純粋な関数型言語を使ったことのある人は後者の方が得意だろう

**デフォルトの名無しさん** · 2024/07/13(土) 09:03:05.94

ムーブは管理上の概念で、低レイヤではコピーしてる。
Rust のムーブはカスタマイズの余地なくコピーする (最適化で消えることはある) が C++ のムーブはカスタマイズの余地 (ムーブコンストラクタの定義) があるので効率の面から考えると Rust のほうがよいとは言えない。

**デフォルトの名無しさん** · 2024/07/13(土) 09:29:23.45

>>801
venvはないわー
cargoやrustupだけでずっと簡単に管理できる
IDEをそれらをGUIから活用するだけ

**デフォルトの名無しさん** · 2024/07/13(土) 09:38:04.64

コマンドプロンプトを無くせない理由を考え続けているそこのあなた
まあいいじゃんそういうの

**デフォルトの名無しさん** · 2024/07/13(土) 09:38:06.14

>>800
当時記事書いてた一人だけど、日本語書籍も増えたしいまさら書くことないんだよね
アドベントカレンダーがあるならネタ考えるか、くらい
自分はまだRust使ってるし、当時記事書いてた人たちもRust使ってるベンチャーとかに転職してて、だいたいみんな書いてるんじゃないかな

**デフォルトの名無しさん** · 2024/07/13(土) 10:09:47.61

Rustはカンファレンスとか見てても最近は成熟したからなのか特に目新しいものはない気がする

**デフォルトの名無しさん** · 2024/07/13(土) 10:11:38.51

vscodeにできてjetbrains製ideにできないことってある？
正直jetbrainsのヤツのほうがvscodeより使いやすい

**デフォルトの名無しさん** · 2024/07/13(土) 10:27:13.13

JetBrains製品は金払ってまで使うほどVSCodeより優れてるわけでないだけで良いIDEではある
VSCodeを何故使うかは商用利用無料だからに尽きるんだわ

**デフォルトの名無しさん** · 2024/07/13(土) 10:59:18.93

>>767 >>768
>traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため
>supertrait/subtraitの場合に例えばある構造体についてそのインスタンスはどちらも同一になるから
どちらも同じ勘違いをしてるよ
よく読もうね

What is wanted here is something like the following substitution property:
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,
the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T

**デフォルトの名無しさん** · 2024/07/13(土) 11:00:31.54

仮にfleetが商用無料になるなら喜んでvscodeを捨てるけど金にがめついjetbrainsが商用無料で配るなんてありえない話
javaやkotlinならともかくrustなら商用無料のvscodeで十分

**デフォルトの名無しさん** · 2024/07/13(土) 11:14:27.08

>>812
そこでRustの場合はTがトレイトでSが構造体などの各型で
「impl T for S 」とS型にトレイトTを実装して
「let o1: S = ...」がS型の値(＝オブジェクト)になる
『object o1 of type S』　←存在する
『object o2 of type T』　←存在しない
したがってRustのトレイトはLSPとなんら関係がない

**デフォルトの名無しさん** · 2024/07/13(土) 11:36:15.00

よく分からんけど
fn do_somethg(x: impl T)
にS型のオブジェクトoを渡すなら、do_somethingにとって o is T が成り立つんじゃない？
この関数は渡された o が S1 なのか S2 なのかは認識しないのだし

**デフォルトの名無しさん** · 2024/07/13(土) 11:44:56.49

>>815
fn foo(x: impl T)は単相化されて
fn foo(x: S1)と
fn foo(x: S2)の二つの関数になるんだよ
いずれにしてもxはS1の値かS2の値であって
Tの値は存在しないね

**デフォルトの名無しさん** · 2024/07/13(土) 11:50:56.55

>>813
さすがフリーライダー。
相手に対する敬意が毛ほども無い。

**デフォルトの名無しさん** · 2024/07/13(土) 11:54:54.91

それはコンパイルのされ方の話であって意味の上での問題ではない気がする
Box<dyn T> なら動的ディスパッチされるわけだし
let x: T = ... のような変数を作れないという意味ならその通りだけど、それはオブジェクト指向言語におけるインターフェースでも同じでは
(それともインターフェースに対してLSPは成り立たない？)

**デフォルトの名無しさん** · 2024/07/13(土) 12:02:36.42

>>812,814,816
なんで毎回飛んでレスするの？

**デフォルトの名無しさん** · 2024/07/13(土) 12:09:19.16

前も貼ったけどRustはこういうニーズを背負ってる

オブジェクト指向を学ばなかった話
https://qiita.com/adaiimps/items/e04ae03371435aeffe87

C++、ObjectiveC、JavaだったのがRust、LLVM、ELFになって、あーやっぱこっちの方が面白いねと、
好きも嫌いもなく色んな言語を学びまくってる人はLLVMは学ばないのかなと

**デフォルトの名無しさん** · 2024/07/13(土) 12:15:08.95

>>818
LSPでは「o1 of type S」と「o2 of type T」の二つのobjectの挙動を比較してるのよ
「o2」が存在しないと挙動の差を論じられないですよ

**デフォルトの名無しさん** · 2024/07/13(土) 12:31:19.55

rust始めたけどtokioまわりの非同期処理が難しい…

**デフォルトの名無しさん** · 2024/07/13(土) 12:34:40.11

置換原則に沿うかどうかは具体的な実装を検証しないとわからないし、大抵の場合に機械的に検証することは出来ない。
型をサブタイプの関係にするのは原則に沿う「ことにする」という表明になることはあるが、原則に沿うことの保証にはならんのだ。

**デフォルトの名無しさん** · 2024/07/13(土) 12:40:54.94

>>821
>>812 を字義通りに解釈するならそうだけど、その文章はC#やJavaが登場する前の1988年のもので、現在のオブジェクト指向にそのまま適用して良いのか？と思う
インターフェースでない、実体のあるクラスの継承関係についてしか言えなくなるし

現在だとリスコフの置換原則は抽象インターフェースも含んで説明される方が多いように思う
「クラスを継承する際のみに適用できるルール」のように説明されてるのは、少なくとも自分は見たことがない

**デフォルトの名無しさん** · 2024/07/13(土) 12:44:05.69

お前らずっと同じ話をループさせてんな😅

**デフォルトの名無しさん** · 2024/07/13(土) 12:51:22.30

>>824
親(基底)と子(派生)の挙動の差で満たすべき条件をLSPは挙げてるよね
少なくとも親にも挙動(実装)が存在しないとLSPを満たしているかどうか言及できないと思う

**デフォルトの名無しさん** · 2024/07/13(土) 13:43:19.43

>>825
好き嫌いの感覚に素直に従えば面白味のないループはすぐ止まりそうなのに

**デフォルトの名無しさん** · 2024/07/13(土) 13:52:54.97

PartialOrd: PartialEqは
PartialEq（等価判定）を持つ型にPartialOrd（半順序判定）を追加するときに
a.partial_cmp(b) == Some(Ordering::Equal)
と
a.eq(b) （⇔ a == b）
が同じになることを期待してる

この場合の置換の対象は型のインスタンスではなく使われる型の関数だから
LSPをインスタンスの置換に限定するか処理の置換にまで拡張するかで結論が変わる

PartialOrdの追加はPartialEqを使ってる既存のコードに影響しないから
技術的にはLSPと無関係ともいえるし
PartialOrdとPartialEqの等価判定の互換性は概念的にLSPの対象とも考えられる

**デフォルトの名無しさん** · 2024/07/13(土) 14:35:50.27

つまりRustのトレイトは
LSPの原義に従うと対象外となり
拡張して考えるとLSPを常に満たす
ことになるわけか

**デフォルトの名無しさん** · 2024/07/13(土) 15:25:32.20

>>829
意味の上で考えるとしても「常に」は満たさないかと

struct MyString(String);
impl Clone for MyString {
　fn clone(&self) -> Self {
　　Self("元の文字列と関係ない文字列".to_string())
　}
}

のようにすれば、そのトレイトが期待する動作に反した型は作れるわけで
引数や戻り値のシグニチャの同一性だけに注目するならtraitに違反することはできないけど、それなら継承やインタフェースでも同じで、「LSPに違反してはならない」という原則はそもそも意味がない (常に違反できないから) ってことになるし

**デフォルトの名無しさん** · 2024/07/13(土) 15:38:58.70

>>830
それLSPのどの項目に違反してる？
LSPは振る舞いに関する形式的なものなのでそのような意味論にまでは踏み込んでいないよ

**デフォルトの名無しさん** · 2024/07/13(土) 15:50:29.46

>>831
例えば
fn test_clone(x: impl Clone + PartialEq) {
　assert!(x.clone(), x);
}
はClone および PartialEq トレイトの振る舞いに依存したコードだけど、この振る舞いに反した型は作れるよね
トレイトは事後要件 (x.clone() == x) を定義できないし、そもそも Clone はそれを担保していないと主張することはできるけど、それならLPSって何のためにあるんだ？ってなるし

**デフォルトの名無しさん** · 2024/07/13(土) 15:54:23.34

「内在論理」に踏み込めば争いを解決できる説のようなものか
逆効果なのでは？

**デフォルトの名無しさん** · 2024/07/13(土) 15:55:51.56

訂正
>>832 のアサート行は assert!(x.clone(), x) でなく assert!(x.clone() == x)

**デフォルトの名無しさん** · 2024/07/13(土) 15:57:24.24

>>831
不変条件を弱められないルールだろう。
不変条件はシグネチャや定義域で表現できないものも含めた振る舞いの仕様全てのことで、挙動が (仕様に照らして) 望ましくなければ原則を満たさないと言える。

**デフォルトの名無しさん** · 2024/07/13(土) 16:03:55.44

829でPartialEq/PartialOrdを例に出したのは
この２つのtraitがsuper/subの関係にあるからで
Cloneとその実装型の関係とは別だよ
PartialEqとPartialOrdの等価判定についてのLSPを考えてる

PartialOrd: PartialEqとする以上
PartialOrdの比較はPartialEqの等価条件を保存すべき←LSP?
みたいな

**デフォルトの名無しさん** · 2024/07/13(土) 16:10:18.20

>>836
確かにそちらの例は二つのトレイトがsuperとsubの関係だからLSPを満たしてるけど
>>830の例はLSPとは関係ないな

**デフォルトの名無しさん** · 2024/07/13(土) 17:43:27.19

>>831
意味でなく形式に拘るなら「事後要件を弱めてはいけない」などのルールは、要件がプログラム等の形式で表現されない限りLSPの評価の土台にすら上がらないってことにならない？

Cloneトレイトは公式のドキュメントに

// Required method
fn clone(&self) -> Self;
Returns a copy of the value.

とあって、exampleでは実際に assert_eq を使って説明しているので、この説明を元にCloneトレイトを実装する型の妥当性を判断して良いように思う
これでもまだ「それは意味論上のものでしかない」というなら、逆にそれをクリアしてクラス間の振る舞いを示している現実的な例を教えてくれ

**デフォルトの名無しさん** · 2024/07/13(土) 22:57:22.69

>>838
それは単純な例だから上手くいってるように思い込めるんじゃないかな
例えばclassの場合はもっと複雑な例になってもsuperclassのコードと挙動が実際にあり
それとsubclassの挙動や(必要なら)コードと照らし合わせて判定できるよ

しかしtraitにはそれがないからドキュメントや付加assertなど一段上のメタ情報を用いなければ何も進めることができない
したがってLSPの枠組みと似てる面はあっても別物

**デフォルトの名無しさん** · 2024/07/14(日) 04:00:15.58

知らんけど
JavaとかC#の世界でも、interfaceが実装者に要求する条件を実装者が実際には満たさない、って場合にLSP違反って言われるの？
ならRustのtraitでも同じこと言ってよさそうだけど、多分言わんよな

**デフォルトの名無しさん** · 2024/07/14(日) 05:23:41.72

継承なしのカプセル化だけなら普通のC言語でもできるし、再コンパイルの問題（変更を加えたファイルだけを再コンパイルすればいいという原則の破れ）も発生しない
それがそのままライブラリやオブジェクトの単位になったんじゃないの

**デフォルトの名無しさん** · 2024/07/14(日) 06:49:30.82

文系：xとは未知のもの
厨房：いや未知のものはyやろ
理系：未知のものはfですdf/dx=g(f)を解きます

**デフォルトの名無しさん** · 2024/07/14(日) 07:37:29.94

>>841
Rustのtraitにはクラスのような継承はないけど、抽象的なコードを継承できるよ

**デフォルトの名無しさん** · 2024/07/14(日) 07:37:59.13

例えばIteratorのtraitにはこのようにfoldメソッドのコードがあって

fn fold<B, F>(mut self, init: B, mut f: F) -> B
where
　Self: Sized,
　F: FnMut(B, Self::Item) -> B,
{
　let mut accum = init;
　while let Some(x) = self.next() {
　　accum = f(accum, x);
　}
　accum
}

**デフォルトの名無しさん** · 2024/07/14(日) 07:39:51.02

未知のIteratorであっても重複コードを書くことなく自動的にこのfoldメソッドが使える

**デフォルトの名無しさん** · 2024/07/14(日) 07:40:10.97

クラスのメソッド継承との決定的な違いは、このコードにメンバー変数は一切登場せず、つまりいかなる構成の型からも独立した抽象的なコードであること

**デフォルトの名無しさん** · 2024/07/14(日) 09:23:36.10

fold って next とどうちがうん

**デフォルトの名無しさん** · 2024/07/14(日) 10:13:20.02

>>847
nextはイテレーターを一つ進めるもの、foldやreduceはイテレーターに対して畳み込みを行うもの
例えば「配列内の全ての数値を足し合わせる」とか「全ての数値を掛け算する」「配列内の文字列を全て連結する」いった操作を行うものだよ

この類のものは他の言語でも使われるし、簡潔なコードを書けるようになるから知っておくと良いよ
配列等のコンテナに対して一般に map, filter, reduce と呼ばれる操作があって、そのうちreduceは「要素を畳み込んで1つの値にする」もの
畳み込む方法を関数で渡すもので、概念的には [1, 2, 3].reduce(add) や [1, 2, 3].reduce(multiply) のような形になる
渡す関数は関数のほかクロージャ (言語によってはラムダ式とも) も使える
こんな感じに抽象化するとfor文を使わなくて済むし、何をやってるかが明確になる

**デフォルトの名無しさん** · 2024/07/14(日) 10:32:15.39

言語によって呼び名や使い分けが微妙に異なるけど
Rustでは2種類をこう呼び分けています
foldは初期値を別途指定する万能型の畳み込み
reduceは初期値が最初の要素となる畳み込み

**デフォルトの名無しさん** · 2024/07/14(日) 10:33:24.33

そして万能型のfoldを呼び出す形で
このような特定の型の構造に依存しない抽象的なコードが
trait Iteratorに用意されているため使えます

fn reduce<F>(mut self, f: F) -> Option<Self::Item>
where
　Self: Sized,
　F: FnMut(Self::Item, Self::Item) -> Self::Item,
{
　let first = self.next()?;
　Some(self.fold(first, f))
}

**デフォルトの名無しさん** · 2024/07/14(日) 11:05:51.89

なぜ二種類あるのか？というと
長さ0だと最初の要素すらないため
reduceはOption型が返る特徴があります

例えば和を求める場合でも
長さ0だったらNoneになってほしいならば
reduce(|sum, n: i32| sum + n)

長さ0なら和が0となってほしいならば
fold(0, |sum, n: i32| sum + n)

と使い分けることができます
ちなみに後者はsum()メソッドが用意されています

**デフォルトの名無しさん** · 2024/07/14(日) 11:33:51.37

ごめんなさい
>>851で型指定「: i32」の部分は不要です
Iteratorの要素の型に必ず定まります
空配列[]から始めると型指定がどこにもないため横着してそこで指定しちゃったという顛末でした

**デフォルトの名無しさん** · 2024/07/14(日) 12:47:51.97

>>822
tokio 自体は難しくないけど
cargo test と組み合わせると難しくなる罠

**デフォルトの名無しさん** · 2024/07/14(日) 12:50:40.22

>>848
map も reduce も filter も知ってるけど(pythonとかから)
fold は知らんかった㌧楠

**デフォルトの名無しさん** · 2024/07/14(日) 12:54:55.73

>>850
python の reduce は初期値を [0] にするのも任意に設定するのも
同じ reduce という名前でいけるのが
Rust だと reduce と fold で使い分ける必要があるということね
Rust が面倒だと言うことは理解した

**デフォルトの名無しさん** · 2024/07/14(日) 13:21:58.79

>>855
そういうことではないよ
RustではOption型やResult型でエラーや異常値を含めて正しい状況を値として得られるんだよ
例えば長さ0で初期値なしの時に
Pythonだとエラーだよね
Rustは常に値として返してくれて今回はOption<Self::Item>型

**デフォルトの名無しさん** · 2024/07/14(日) 14:06:11.77

>>854
ML 系とか LISP 系の言語ではだいたい reduce や fold は用意されてるね。
ものによっては右側 (シーケンスの終端) から畳み込むとかのバリエーションもある。

**デフォルトの名無しさん** · 2024/07/14(日) 14:15:44.82

Rustならrev().fold(...)だね

**デフォルトの名無しさん** · 2024/07/14(日) 15:28:53.80

テンプレートが出てきたあたりからC++の勉強をやめたのだけど
これは「型を引数に取ってインスタンス化する」ということでおｋ？
それがトレイトをまたいだ場合、いつどこで誰が何してるか分からなくなる
ファイルをまたぐインライン関数みたいにソースレベルでなされること？

**デフォルトの名無しさん** · 2024/07/14(日) 16:59:00.63

>>840
JavaとかC#の世界でも、interfaceが実装者に要求する条件を実装者が実際には満たさない、って場合にLSP違反って言われるの？
言われるよ
リスコフ本人が書いたJavaの本にも書いてある

**デフォルトの名無しさん** · 2024/07/14(日) 17:32:49.60

>>839
>ドキュメントや付加assertなど一段上のメタ情報を用いなければ何も進めることができない
一段上のメタ情報であるspecificaitonを使いなさいというのがリスコフの教え
それがBehavioral SubtypingってものでLSPが伝えようとしてる原則だよ

**デフォルトの名無しさん** · 2024/07/14(日) 20:15:07.35

ああ、なんだ
クレート＝ELFファイルだと思ってたけど違うのね

**デフォルトの名無しさん** · 2024/07/14(日) 23:33:04.31

もちろんクレートはコンパイルしてELFに出来得る

警備員[Lv.12] · 2024/07/15(月) 00:49:06.25

そうかCOFFあかんか。
AIXとかはどうするんだろう？

**デフォルトの名無しさん** · 2024/07/15(月) 01:06:24.34

LLVMのバックエンドにCOFFもあるよ

**デフォルトの名無しさん** · 2024/07/15(月) 01:09:28.33

LLVMの役割
ELFもCOFFもXCOFFもいける

**デフォルトの名無しさん** · 2024/07/15(月) 01:55:53.37

>>860-861
なるほどね、本当に特定の言語処理系の型システムの実装が云々というところからは離れたところにある概念なんだ
あえて関連付けるなら、型システムの部分型付け関係がbehavioral subtypingにもなるように定義すべきであると
上位型が具体型であるために暗黙の条件が多数想定される状況では特にLSPを意識すべきだが、それに限定される概念ではないと

**デフォルトの名無しさん** · 2024/07/15(月) 02:35:13.63

supertypeの実装がない場合は
LSPの不変条件・事前条件・事後条件などsubtypeの実装と比較しようがなく
LSPの対象になりようがないよね

**デフォルトの名無しさん** · 2024/07/15(月) 03:42:20.85

docs.rs の左上のRマーク
今話題のRen4のマークに似てるね

**デフォルトの名無しさん** · 2024/07/15(月) 09:46:03.12

コレクションしないんだから狭義には参照カウンタはGCとは言えない。
広義には含めてやってもいいが。

**デフォルトの名無しさん** · 2024/07/15(月) 11:20:28.28

ライブラリは.rlibまたは.rmetaで、これもELFやCOFFとは別物
ふむ

警備員[Lv.1][新芽] · 2024/07/15(月) 11:29:04.89

たしかにRマークってRustから周りのやつ外したような感じじゃん

**デフォルトの名無しさん** · 2024/07/15(月) 11:58:24.83

Ren4のRマークはsans-serifのゴシック体だからRustのロゴとは全然違うだろ
本人のやる気、こだわりのなさをフォントで表現してるんだから
RustのRと一緒にしたら双方に失礼

**デフォルトの名無しさん** · 2024/07/15(月) 13:14:40.10

単に好みの問題だけど
ウィルスっぽくて気持ち悪い
好きじゃない

**デフォルトの名無しさん** · 2024/07/15(月) 14:14:44.43

>>874
元々サビ菌がモチーフやからしゃーない

**デフォルトの名無しさん** · 2024/07/15(月) 18:49:44.14

独裁者にも見た目がダサい奴がよくいるけど言っても無駄だ
デザインの力とは全然違う別の力でねじ伏せてくる

**デフォルトの名無しさん** · 2024/07/15(月) 19:16:07.61

ダサいという指摘に理由を説明しても、ダサいことは変わらないんだよな
言語がダサければ信者もダサい
うだうだ言いながらダサい服着てそう

**デフォルトの名無しさん** · 2024/07/15(月) 22:03:42.65

イテレータ要素をヒープに格納するにはこれでいいんか
.fold(Vec::new(), |mut v, t| { v.push(t); v })

**デフォルトの名無しさん** · 2024/07/15(月) 22:12:32.29

またイテレータの話してる

**デフォルトの名無しさん** · 2024/07/15(月) 22:50:12.36

>>878
collectしろや

**デフォルトの名無しさん** · 2024/07/15(月) 23:25:29.58

>>878
分かって書いてるかもだけど一応
let v = (0..10).collect::<Vec<i32>>();
コンテナにまとめるならこんな感じに collect を使う
例えば文字を走査するイテレーターをStringにcollectするようなことも可

型パラメーターは推論が効くのでそれに任せても良い
左辺に情報があるならcollectの型パラメーターはいらない
let v: Vec<i32> = (0..10).collect();
要素の型が分かるなら、右辺のコンテナの中身は_で推論させても良い
let v = (0i32..10).collect::<Vec<_>>();