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/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<_>>();

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

クロージャにキャプチャさせれば既存ベクタへ格納も追加もできる
let mut v = Vec::new();
iter.fold((), |_, t| v.push(t));
しかしこれではfold使ってる意味がなくこれと一緒　
iter.for_each(|t| v.push(t));

もちろん正解は既存Vecへ追加なら
v.extend(iter);
新規にVecへ収集なら
let v = iter.collect::<Vec<_>>();

**デフォルトの名無しさん** · 2024/07/16(火) 23:25:36.51

Foo::from_iter(iter)でもいいね
例えばVec::from_iter(iter)
特にIntoIteratorな時にinto_iter()を省けて見やすいよ

**デフォルトの名無しさん** · 2024/07/17(水) 18:51:22.39

イテレータをcollectしたい場合と
イテレータではないIntoIteratorを別の構造体に変換したい場合とは文脈が違うでしょ

from_iterを直接呼ぶのは基本的に後者
前者の場合にターボフィッシュ書かなくてもいいという理由で
from_iterを直接呼ぶのはidiomaticではない

**デフォルトの名無しさん** · 2024/07/17(水) 21:48:43.22

前者のケースでfrom_iterを直接呼んでても分かるから別にいいよ
自分で書くときはcollect使うけど

**デフォルトの名無しさん** · 2024/07/17(水) 23:54:54.61

これは短い方がいい
let x = HashMap::<_, _>::from_iter(vec);
let x = vec.into_iter().collect::<HashMap::<_, _>>();

**デフォルトの名無しさん** · 2024/07/17(水) 23:55:29.92

これはほぼ長さ変わらないからどちらがわかりやすいか
let x = HashMap::<_, _>::from_iter(iter);
let x = iter.collect::<HashMap::<_, _>>();

**デフォルトの名無しさん** · 2024/07/18(木) 01:10:31.87

どちらも一度変数で受ける形になるので型アノテーションが必要なら
let x: HashMap<_, _> のように基本的には左辺に書く

HashMapなら型パラメータ部分も推論に頼らず
明示的に書くことのほうが多いかもしれない

イテレータをcollectしたい場合というのは
イテレータのメソッドチェーンで各種処理をしてから
最終的にcollectする形になることが多いから
from_iterの直呼びじゃなくcollectが好まれる

**デフォルトの名無しさん** · 2024/07/18(木) 02:40:28.19

ところでchronoって、しょっちゅうAPIが変わるし
やたら冗長な書き方になるし結構クソじゃない？

**デフォルトの名無しさん** · 2024/07/18(木) 12:05:40.95

書き方が気に入らないならtime-rsを試してみたら？

**デフォルトの名無しさん** · 2024/07/18(木) 21:07:48.37

なるほど

trait Iterator {
　type Item;
　
　fn collect<B: FromIterator<Self::Item>>(self) -> B
　where
　　Self: Sized,
　{
　　FromIterator::from_iter(self)
　}
}

**デフォルトの名無しさん** · 2024/07/18(木) 23:31:33.62

代数的データ型ってなんかすごいけど知名度がモナドより低いな

**デフォルトの名無しさん** · 2024/07/19(金) 02:03:52.09

>>890
使ってみたけど、time-rsいいね
いつのまにかダウンロード数でchronoを上回る競合があったとは知らんかった
タイムゾーンの扱いがやや簡略化されてるけど、夏時間のない日本人的には問題ない
月を直接intで指定できないのが英語仕様やな……ってちょっと気になる

**デフォルトの名無しさん** · 2024/07/19(金) 03:51:08.70

>>891
この各収納先への移譲と両側のトレイト境界が汎用化の肝
trait FromIterator<A>: Sized {
　fn from_iter<T: IntoIterator<Item = A>>(iter: T) -> Self;
}

**デフォルトの名無しさん** · 2024/07/19(金) 06:06:24.35

Rustはジェネリックとトレイト境界と抽象的なデフォルト実装のおかげで
安全で利便性の高いコードの汎用共通化に成功していますね

**デフォルトの名無しさん** · 2024/07/19(金) 23:21:36.34

cloud strike のはテロルやね

**デフォルトの名無しさん** · 2024/07/19(金) 23:30:11.35

>>886
let x; HashMap::<_, _> = vec.try_into()?;

>>889
＋１

**デフォルトの名無しさん** · 2024/07/19(金) 23:52:20.75

>>897
エラーとなりますた

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

>>896
ウィルスバスター以来の快挙やね

**デフォルトの名無しさん** · 2024/07/20(土) 14:16:49.05

>>898
; が : の間違いかな

>>899
暴落予想
note.com/asset_n_ichi/n/nceaa6f318b1e

**デフォルトの名無しさん** · 2024/07/20(土) 23:38:20.92

>>897
HashMapとVecにTryFromが実装されていないから無理
FromIteratorが実装されているのでそれを使う

**デフォルトの名無しさん** · 2024/07/21(日) 01:48:23.56

★┷┓
┃D┃
┃D┃
┃K┃
┃で┃
┃も┃
┃r┃
┃u┃
┃s┃
┃t┃
┃が┃
┃使┃
┃え┃
┃ま┃
┃す┃
┃よ┃
┃う┃
┃に┃
┗━★

**デフォルトの名無しさん** · 2024/07/21(日) 09:43:03.00

>>901
こういうのが「Rustは学習コストが高い」って言われる原因なんだろうな
答えを知ってる人は判ってても答えを知らない人は判らない
答えを調べるのにコストがかかりすぎる

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

とあるライブラリに変な癖があるという話は
どの言語でもあるからそういう話ではないだろ

**デフォルトの名無しさん** · 2024/07/21(日) 10:29:10.85

イテレータ使ったことない

**デフォルトの名無しさん** · 2024/07/21(日) 10:35:28.58

>>903
Rustはその点シンプルでクセもなく覚えやすい

基本的に複数の要素ならFromIterator
VecでもHashMapでも何でもいける
複数のcharやstrなどからString作成もいける
複数のstrやStringやPathなどからPathBuf作成もいける

Fromは基本的に単独要素や配列(＝静的固定長)から他へ変換

**デフォルトの名無しさん** · 2024/07/21(日) 11:03:59.33

>>903
>>897のはコンパイルエラーの内容が読めればすぐわかる
エラーの内容が読める程度の基礎力は最初に勉強して身につける必要がある
そもそもtry_intoでどういうケースならエラーにして欲しいのか考えればおかしいことに気付く

サードパーティライブラリの学習コストは他の言語に比べると顕著に高いが
基本的な言語機能や標準ライブラリは言うほど高くない
JavaやC#あたりと比べるとむしろ学習コスト低いんじゃないかと思う

**デフォルトの名無しさん** · 2024/07/21(日) 11:04:04.35

>>903
それくらいchatGPTで教えてもらえるだろ

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

>>908
俺もそう思って試してみたけど駄目だね
エラーの簡単な原因とcollect使えみたいな代替案は出してくるけど
根本的な理解につながる答えを返せないだけでなくいろいろと間違った情報を返してくる

**デフォルトの名無しさん** · 2024/07/21(日) 11:48:09.12

from_iter(array)で済むのに
なぜ配列からHashMapへのFromがあるのか理由はおそらく
配列からmoveするinto_iter()が数年前までなかったためだと思う
今は配列を含めて要素が複数なら→イテレータ利用→FromIteratorと覚えればよいかと

**デフォルトの名無しさん** · 2024/07/21(日) 11:54:05.33

そもそもイテレーターとコンテナの概念を勘違いしてる可能性ありそう
別種のコンテナ同士の変換は (特別な対応がない限り) 直接的には無理で、イテレーターを介して中身の要素を走査すれば渡せるということ

みかん箱を冷蔵庫に変換することはできないけど、箱の中のみかんを1つずつ取り出して、それを冷蔵庫型に纏める (collect) ことはできるような感じ

**デフォルトの名無しさん** · 2024/07/21(日) 12:08:53.38

今回は >>910 さんをベストアンサーとさせて頂きます
みなさんご協力ありがとうございました

**デフォルトの名無しさん** · 2024/07/21(日) 12:17:32.86

>>911
それは単に抽象度の違いであって勘違いでも何でもない

**デフォルトの名無しさん** · 2024/07/21(日) 12:17:32.92

>>911
勘違いはしてない

use std::collections::HashMap;
use std::iter::FromIterator;

fn main() {
let u = vec![("hoge", 1), ("fuga", 2)];
let x: HashMap::<_, _> = u.into_iter().collect();
println!("{:?}", x);
let v = vec![("hoge", 1), ("fuga", 2)];
let y = HashMap::<_, _>::from_iter(v); // use std::iter::FromIterator
println!("{:?}", y);
let w = [("hoge", 1), ("fuga", 2)]; // array
let z = HashMap::<_, _>::from(w);
println!("{:?}", z);
}

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

なぜ Vec から HashMap は from が使えないのか？
の問いに GPT は答えてくれない

**デフォルトの名無しさん** · 2024/07/21(日) 12:29:53.31

>>910
順番が逆
arrayにIntoIteratorが実装された方が先で
From array for HashMapのほうが後

**デフォルトの名無しさん** · 2024/07/21(日) 12:32:17.29

>>915
そこはFromのimplがないからと答えてくれる
coherenceの制約を先回りして答えてくれるかどうかは質問次第

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

>>916
ありがと
調べたらその順だね
そうなるとFrom<配列>だけを特別に用意した理由は配列が基本型だからだろうか
HashMap::from(array)のコードを見ると
HashMap::from_iter(array)とFromIteratorの実装を呼び出すだけなので

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

MapやSetのリテラルがないけどリテラルに近い感覚で初期化したい場合の代替策として用意されたのがFromの実装

**デフォルトの名無しさん** · 2024/07/21(日) 16:20:17.13

_iterの5文字が節約できるメリットだけか

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

>>920
タイプアノテーションの要不要があるのでもっと節約できるよ

**デフォルトの名無しさん** · 2024/07/21(日) 16:43:19.24

>>921
不要になる例を出して

**デフォルトの名無しさん** · 2024/07/21(日) 17:05:45.63

FromがあるとIntoが使えるからHashMap返すときとか引数で渡すときに
HashMap::from([..])
の代わりに
[..].into()
で書ける

型を明記するletだと大差ないかも
let map: HashMap<K, V> = [..].into();
let map = HashMap::<K, V>::from([..]);

**デフォルトの名無しさん** · 2024/07/21(日) 17:22:33.98

>>923
そこでタイプアノテーションが不要になる例はないよな
関数の引数型か返り型に書いている

into()と書ける件も
collect()と書けるから
FromIteratorに対してFromもあるメリットは3文字節約できるだけか

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

dyn traits以外にinto使うなよ。変換するんだから

let s = "Hello, world!";
let string = Into::<String>::into(s);

じゃなくて

let s = "Hello, world!";
let string = String::form(s);

だろ。

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

は？

**デフォルトの名無しさん** · 2024/07/21(日) 22:10:59.79

>>922
use std::collections::HashMap;

fn main() {
let xs = [(1, "a"), (2, "b"), (3, "c")];
let map = HashMap::from(xs);
println!("{:?}", map);
}

**デフォルトの名無しさん** · 2024/07/21(日) 22:23:54.17

>>927
HashMap::from_iter(xs)で十分じゃね

**デフォルトの名無しさん** · 2024/07/21(日) 22:30:45.10

>>928
error[E0283]: type annotations needed for `HashMap<i32, &str, _>`
--> src/main.rs:5:9
|
5 | let map = HashMap::from_iter(xs);
| ^^^ ------- type must be known at this point
|

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

配列からのFromは機能が制限されている
struct HashMap<K, V, S = RandomState> { ... }
impl<K: Eq + Hash, V, S: BuildHasher + Default> FromIterator<(K, V)> for HashMap<K, V, S> { ... }
impl<K: Eq + Hash, V, const N: usize> From<[(K, V); N]> for HashMap<K, V, RandomState> { ... }

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

つまりFromは重いデフォルトハッシャーに固定されてしまっている
FromIteratorを使えば自由に速いものを利用できる
let xxx = HashMap::<_, _, FxHash>::from_iter(array);