Rust part14

**デフォルトの名無しさん** · 2022/02/12(土) 01:24:16.59

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

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

日本語の情報
https://rust-jp.rs/

※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/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

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

**デフォルトの名無しさん** · 2022/04/07(木) 15:06:14.55

>>612
それはどんな言語も多かれ少なかれありそう
Cのポインタもそうだしね

**デフォルトの名無しさん** · 2022/04/07(木) 18:17:40.12

>>607
クロージャの即時呼び出しは基本的に言語機能が足りない場合のワークアラウンドでしょ

**デフォルトの名無しさん** · 2022/04/07(木) 18:20:36.61

クロージャは引数と戻り値を推論してくれるからこそだね
関数でも、なんかの条件付きでもいいから推論してほしいわ

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

推論というか、型推論ね

**デフォルトの名無しさん** · 2022/04/07(木) 18:33:18.44

関数含むモジュールレベル定義の型推論はやろうと思えばできるけど
コンパイル時間への影響がでかいのと、ドキュメント的な意味で型を書いた方がわかりやすいという理由で
敢えて対応していないとどこかで読んだ気がする

とはいえ戻り値のimpl Traitは制限された形での型推論と言えるんじゃないかな

**デフォルトの名無しさん** · 2022/04/07(木) 18:34:30.25

>>614
Rustでは型指定しなくて済む利点もあるしクロージャと関数の使い分けの一種じゃないかな
もちろん今回のケースはreturn値を取る別種のブロックがあれば済むけども
それをわざわざ導入しなくてもクロージャ即時呼び出しで十分

**デフォルトの名無しさん** · 2022/04/08(金) 04:35:42.40

Rustのコンパイルの遅さは型推論とかじゃなく、cargoという非常に悪い仕組みのせい

**デフォルトの名無しさん** · 2022/04/10(日) 02:43:45.04

そんなことないよ
cargo build --timings　いいね

**デフォルトの名無しさん** · 2022/04/10(日) 11:44:22.72

Rust 1.60来てたか

**デフォルトの名無しさん** · 2022/04/12(火) 10:03:48.28

OnceCell<T> って &'static T が取れるわけじゃないんですのん？

**デフォルトの名無しさん** · 2022/04/12(火) 10:14:36.57

まちがえた
× OnceCell<T>
○ const Lazy<T>

**デフォルトの名無しさん** · 2022/04/12(火) 10:20:45.37

getでOption<&T>が取れる
初期化してなければNone

**デフォルトの名無しさん** · 2022/04/12(火) 10:26:05.90

LazyならDerefを適用させて使う
*lazyで&Tや&mut T

**デフォルトの名無しさん** · 2022/04/12(火) 10:46:54.62

https://play.rust-lang.org/?version=nightly&;mode=debug&edition=2021&gist=22ed821be70a494615ca8a661e98b78f

ごめんこういうこと
実際使ってるとき&'staticが取れないのが原因だと思ってそう書いちゃったけど違う原因かもしれないです

**デフォルトの名無しさん** · 2022/04/12(火) 11:20:51.11

それはconstではなくstaticで宣言

**デフォルトの名無しさん** · 2022/04/12(火) 11:33:29.72

プログラム開始時点での有効性を保証できないから何となくだけどコンパイラの事情で無理そう

&'staticって↓みたいな使い方もできるからLazyだとBの参照先が初期化済みか分からない
static A: u32 = 0;
static B: &'static u32 = &A;

**デフォルトの名無しさん** · 2022/04/12(火) 11:37:37.75

nightlyのstd::lazy::Lazyではなく
stableでも使えるonce_cellを使用
そのコードと同じ例がこれで動く

use once_cell::sync::Lazy;

static LAZY: Lazy<i32> = Lazy::new(|| 92);

fn main() {
let a: &'static i32 = sub();
println!("{}", *a);
}

fn sub() -> &'static i32 {
&*LAZY
}

**デフォルトの名無しさん** · 2022/04/12(火) 11:44:54.53

あーなるほど
なぜか'staticでmutableなのがstatic、immutableなのがconstと勘違いしてました
constって使用の度に式展開するやつだったんですね
temporary valueなんて無いじゃんとか無限に悩んでた

ありがとうございます

**デフォルトの名無しさん** · 2022/04/12(火) 11:47:13.23

>>630
constはコンパイル時点で定まる定数

**デフォルトの名無しさん** · 2022/04/13(水) 09:59:43.40

こんな事も分からない触ってるだけで偉いと勘違いするゴミ言語

**デフォルトの名無しさん** · 2022/04/15(金) 00:23:00.39

>>613
プログラムのポインタ（メモリアドレスを参照するもの）は
ポインタのメタファだから元のポインタを知ってれば理解できるが、
substructural type systemはtype systemの一種でtype systemは
型理論を元にした体系的な理屈だから理屈が理解できなきゃ理解できないから全く別の話。

>>612の言う「慣れでどうにかなるもんではない」っていうのはつまり、
わかった気になってなんとなくで書いてるやつはまだ理解してないって話でしょ。

**デフォルトの名無しさん** · 2022/04/15(金) 00:36:10.15

ソフトウエアを書くにはカテゴリー論から勉強しろということかな？

**デフォルトの名無しさん** · 2022/04/15(金) 00:46:18.85

名言もらいました
ポインタはポインタのメタファ

**デフォルトの名無しさん** · 2022/04/15(金) 00:56:52.75

>「慣れでどうにかなるもんではない」っていうのはつまり、
>わかった気になってなんとなくで書いてるやつはまだ理解してないって話でしょ。

全然違う。
型システムより先に文章を理解する訓練をした方がいいぞ。

**デフォルトの名無しさん** · 2022/04/15(金) 01:20:52.56

>>612
他の言語と同様にRustもそんな難しいことしていないから大丈夫
論理とメタ的な考え、例えば高階やジェネリクス等、ができる普通の人ならばRustの理解は容易い

**デフォルトの名無しさん** · 2022/04/15(金) 08:25:31.44

>>637
さすがにそれを「普通の人」というのは無謀。

**デフォルトの名無しさん** · 2022/04/15(金) 08:41:02.84

100点オジサンや複製オジサンみたいな自分は理解してるつもりの勘違いさんが一番迷惑

**デフォルトの名無しさん** · 2022/04/15(金) 08:59:01.96

>>638
普通のプログラマーなら他の言語でクロージャ(ラムダ等)くらいはさすがに使ったことあるから高階は大丈夫なはず
ジェネリクスもスクリプト言語などの動的型付け言語なら計らずともそのままジェネリックな関数となってる

そこでRustでのみ必要となる概念はそのジェネリックな関数内を安全な操作とするためのトレイト境界の指定
これはコンパイラがエラーとして教えてくれるため指定を忘れることがない
だから普通のプログラマーなら大丈夫じゃないかな

**デフォルトの名無しさん** · 2022/04/15(金) 10:17:08.40

相変わらず複製おじさんは不勉強でキツイな
「普通の人」は他の言語でジェネリック使ったことあるからこんな恥ずかしい長文を書かない

**デフォルトの名無しさん** · 2022/04/15(金) 10:53:34.01

そうでなくRustではtrait境界が足りなければコンパイルエラーで指摘されるからスクリプト言語から来た人でも困らないって話やろ

**デフォルトの名無しさん** · 2022/04/15(金) 11:18:53.45

そんなことよりこのエラーの意味を教えてくれ

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=21cdaa3e90ffdd6a5ef2e06302afe03b

**デフォルトの名無しさん** · 2022/04/15(金) 11:41:06.84

>>641
Rust特有の話については触れたくないんだろ
理解してないから

**デフォルトの名無しさん** · 2022/04/15(金) 12:09:57.32

おじさん使いの人はいつもそうだよな

**デフォルトの名無しさん** · 2022/04/15(金) 12:26:07.26

>>640
「クロージャ(ラムダ等)くらいはさすがに使ったことある」からといって「論理とメタ的な考え……ができる」ではないことは論理的に明らか。
全然論理的な考えができていない>640自身が反証になっているね。

**デフォルトの名無しさん** · 2022/04/15(金) 12:58:35.38

>>643
lifetime mismatchのエラーが分かりにくければ、lifetimeを省略せずに明記して確認すればいい

**デフォルトの名無しさん** · 2022/04/15(金) 13:07:01.81

あと#![feature(nll)]でビルドしても分かるはず

**デフォルトの名無しさん** · 2022/04/15(金) 13:08:53.72

>>646
むしろ論理とメタわからんプログラマーは言語関係なく向いてないっす

**デフォルトの名無しさん** · 2022/04/15(金) 13:30:54.07

理解の程度を0か1で考える人は底辺プログラマーに向いてる

**デフォルトの名無しさん** · 2022/04/15(金) 14:19:47.21

所有権でよくわからないって言えばさあ
fn asdf() -> &str{
let s = "jkl";
s
}
みたいにした時に、関数を抜ける際にstrのライフタイムが尽きちゃう訳じゃない
でも逆になぜ&strしかないのに、どうして関数を抜けるところまでstrのライフタイムが持つのか？そこら辺がよくわからねえな
&strを通じてstrを所有できているのであれば、&strをリターンできても良いような気もするのに・・・・どうなってんの？

**デフォルトの名無しさん** · 2022/04/15(金) 15:21:50.13

>>651
fn asdf() -> &str
は
fn asdf<'a>() ->&'a str
のようにlifetimeを省略した記法なんだけど、
この 'a は引数にも現れないし何の寿命に対応するか分からないからエラーになっちゃう

今回の文字列リテラルみたいにプログラム開始から終了まで存在するデータへの参照なら、
プログラム開始から終了までを意味する 'static を使うことはできる
fn asdf() -> &'static str

また以下のように引数に参照が登場する場合は、
戻り値の寿命は暗黙的に引数と同じだと見なされる
fn asdf(a: &str) -> &str
は
fn asdf<'a>(a: &'a str) -> &'a str
となるということ

この辺の仕組みは lifetime elision でググると情報出てくるよ

**デフォルトの名無しさん** · 2022/04/15(金) 15:35:47.27

>>647
>>648
両方やってみて結局こうなったがまだよく分からん

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=aafabd8057a50f537f9ff410c03461d2

yが借用中にもかかわらずdropされたというふうに読めるけど、f(&mut y)が終わった時点で借用も終わってるから問題無いのでは？
でも試しにこの後yをどうこうするコード付け足してみると、どうも借用しっぱなしになってるっぽいエラーばっかり出るのよな

**デフォルトの名無しさん** · 2022/04/15(金) 16:44:22.79

>>651
&’static strが返されてるからだよ
リテラルはstatic扱いだと思っておけばいい

>>652
fn asdf<'a>() ->&'a strと書いても’>>651のケースはエラーにならないよ

**デフォルトの名無しさん** · 2022/04/15(金) 17:24:32.32

>>654
エラーにならないのか
その場合 'a は何に推論されるの？

**デフォルトの名無しさん** · 2022/04/15(金) 17:51:47.56

>>648
これさらにわかりやすくなるね

**デフォルトの名無しさん** · 2022/04/15(金) 19:50:10.79

ありがとう！
なんかちょっとズレたエラーメッセージだなと思っても、省略・推論されているなんて夢にも思わなかったから意味がわんなかったぜ！

**デフォルトの名無しさん** · 2022/04/16(土) 15:01:46.93

Rustって参照をベクターに持てる？

**デフォルトの名無しさん** · 2022/04/16(土) 15:58:22.55

>>658
もてるよ
https://ideone.com/ZMCl2R
fn main() {
let a = 1;
let b = 2;
let v = vec![&a, &b, &a, &b];
println!("{:?}", &v);
}

**デフォルトの名無しさん** · 2022/04/16(土) 17:14:58.83

>>659
サンクス

**デフォルトの名無しさん** · 2022/04/20(水) 18:37:23.24

Rust 入門者です。
全く実用的な意味はなく練習として符号無し整数を桁ごとに返すイテレータというものを考えていたのですが
同じ制約を重複して書くことになってしまい不格好な気がします。
https://ideone.com/qOmnhW
ベテランが華麗に書いたらどんな風になりますでしょうか。
それとも Rust ではこれで良いものなのでしょうか。

**デフォルトの名無しさん** · 2022/04/20(水) 19:13:19.89

>>661
traitの方の制約はいらないよ

**デフォルトの名無しさん** · 2022/04/20(水) 22:38:14.51

>>662
ありがとうございます。
たしかにこのコードではトレイト Digits にスーパートレイトを付ける必要はないですね。

想定を後出しにして誠に申し訳ないのですが、これはライブラリ (クレート) としてまとめようとしているつもりでした。
ここに書かれていない未知の型にトレイト Digits を実装することがあり得るという意味です。

問題になるのは、 Digits のスーパートレイトを消してしまうとどんな型でも Digits の実装自体は出来てしまうということです。

// ↓ Digits にスーパートレイトを付けなければこう書くこと自体は出来てしまう。この段階でエラーになって欲しい。
struct Foo {}
impl Digits for Foo {}

そしてメソッド digits を呼出すところでエラーになります。

let bar = Foo {};
for x in bar.digits() { // ← ここでエラーになる
println!("{}", x);
}

逆に言えば digits を呼出さなければエラーになりません。
どうせ使えないことがわかっているならトレイトの impl の段階でエラーであって然るべきだという判断が
重複する制約を書いた意図です。
メソッドがイテレータを返すなんていうのはよくあることだと思うので、
いちいち重複したことを書かかなくて済むような何かがあるんじゃないか……という想像から質問した次第です。

**デフォルトの名無しさん** · 2022/04/20(水) 23:00:49.13

>>663
そういう前提ならばこんな感じで impl の方の制約を T: Digits に変えるのはどうじゃろ
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=6bd0ab54e4cbd88ca2a0502f9e74315d

あと T::Error: std::fmt::Debug についてはどの trait の associated type に対する制約か分かり辛いから
<T as std::convert::TryInto<u8>>::Error: std::fmt::Debug,
としても良いかもね

**デフォルトの名無しさん** · 2022/04/21(木) 00:02:58.32

>>664
ありがとうございます。
なんてこった！こんな単純なことでよかったとは……。

**デフォルトの名無しさん** · 2022/04/21(木) 13:57:26.69

数値にメソッドを生やすメリットが思いつかないからこれだけでいいんじゃない？

fn digits<T>(n: T) -> impl Iterator<Item=T>
where T: Clone + PartialEq + From<u8> + std::ops::DivAssign + std::ops::Rem<Output=T>
{
itertools::unfold(n, |n| (*n != T::from(0)).then(|| {
let rem = n.clone() % T::from(10);
*n /= T::from(10);
rem
}))
}

fn main() {
let foo: i64 = 9165731750932755204;
for x in digits(foo) {
println!("{x}");
}
}

**デフォルトの名無しさん** · 2022/04/21(木) 14:14:33.93

実用上は関数で十分だろうけど、Rustって整数のプリミティブ型にもたくさんメソッドあるし、
メソッドを生やすのが流儀なのかな、って俺も思ってたけどどうなんやろ？

**663** · 2022/04/21(木) 14:30:15.62

>>667
過剰にトレイトを作るなというのはドキュメントのどこかに書いてあったような気がする。

**デフォルトの名無しさん** · 2022/04/21(木) 22:20:02.87

>>666の関数をメソッド化しようとしたら
traitやimplの中では関数はimpl Iteratorを返せないと怒られた
この制限は将来緩和される可能性ある？
implでなく返す型を具体化したらコンパイル通って動いた
traitとimplでwhereのところが冗長な気がするけど両方とも外せない？

trait Digits<T> {
fn digits(self) -> itertools::Unfold<T, fn(&mut T) -> Option<T>>
where T: Clone + PartialEq + From<u8> + std::ops::DivAssign + std::ops::Rem<Output=T>;
}
impl<T> Digits<T> for T {
fn digits(self: T) -> itertools::Unfold<T, fn(&mut T) -> Option<T>>
where T: Clone + PartialEq + From<u8> + std::ops::DivAssign + std::ops::Rem<Output=T>,
{
itertools::unfold(self, |n| (*n != T::from(0)).then(|| {
let rem = n.clone() % T::from(10);
*n /= T::from(10);
rem
}))
}
}

fn main() {
let foo: i64 = 9165731750932755204;
for x in foo.digits() {
println!("{x}");
}
}

**デフォルトの名無しさん** · 2022/04/22(金) 09:19:03.80

rfc2071かな

**デフォルトの名無しさん** · 2022/04/22(金) 09:42:40.77

>>670
こんな記述もできるようになるわけね
let displayable: impl Display = "Hello, world!";
const MY_CLOSURE: impl Fn(i32) -> i32 = |x| x + 1;
let x: impl Iterator<Item = i32> = (0..100).map(|x| x * 3).filter(|x| x % 5);

**デフォルトの名無しさん** · 2022/04/22(金) 11:24:39.82

>>669
traitとimplのfnの型制約なくしてimplの制約にするのはどう？
Tに対する制約は実装に依るものなのでimplが課してるものとみなした方が自然な気がする

**デフォルトの名無しさん** · 2022/04/22(金) 11:28:58.18

>>672
具体的にはどんなコードになるのですか？

**デフォルトの名無しさん** · 2022/04/22(金) 11:29:43.00

>>669
>>672 の意図はこんな感じ。返り値も associated type にして実装に委ねられるようにした。
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=1dfdb310cd07023a69acca6cbba434ed

**デフォルトの名無しさん** · 2022/04/22(金) 12:09:33.52

>>674
where制約宣言の場所をメソッドfnからimplへ移動させることで結果的にtrait側で制約する必要がなくなるわけか

**661** · 2022/04/22(金) 13:12:07.76

>>674
元々の想定では符号付きの場合を型の制約で排除したいと考えていました。
トレイトが実装されているかどうかだけでは必要な性質を満たしているかどうか判定しきれないと考えて
個別に実装する必要があるという判断をした次第です。
個々に人が判断するのではなく制約で包括的に判定するとしたら std::ops::Neg を実装して「いない」という条件を付ける
必要が出てくるかと思いますが、今の Rust だとそういう制約は付けられないですよね？

**デフォルトの名無しさん** · 2022/04/22(金) 14:11:21.60

>>676
そこは汎用的に空のtrait Unsignedを空のimplで用意して使う
自分で用意してもいいが既にあるnum::Unsignedをトレイト境界に加えるだけで希望を叶えられる

**デフォルトの名無しさん** · 2022/04/24(日) 14:55:18.07

>>675
trait宣言でtrait境界制約しないメリットは他にもある
例えば文字列(例 "57261")に対するdigits()をimplできるようになってこの場合は別のtrait境界をimpl側で書くことになる

ただし別問題として現状ではまだ安定化していない2つの機能サポート待ち
1つ目はimpl Traitのspecializationでfor Tが既にあるところへfor Stringやfor &strできるようにするため
もう1つはGATs (general associated types)でイテレータで参照返しできるようにするため

**デフォルトの名無しさん** · 2022/04/25(月) 18:30:29.96

String の配列でパターンマッチしたいと考えていますが、
こういう書き方をすると String と &str を比較しているとして型が合いません。

fn main() {
let foo = [String::from("bar")];
let baz = match foo { ["bar"] => 1, _ => 2 };
}

かといって書けるパターンは制限があるので↓こう書くことも出来ません。

fn main() {
let foo = [String::from("bar")];
let baz = match foo { [String::from("bar")] => 1, _ => 2};
}

ガードを付けるかスライスの配列を作るかくらいしか方法はないですかね？

fn main() {
let foo = [String::from("bar")];
let baz = match foo { [ref x] if x =="bar" => 1, _ => 2 };
}

fn main() {
let foo = [String::from("bar")];
let bar = &foo.iter().map(|ref str|&str[..]).collect::<Vec<_>>()[..];
let baz = match bar { ["bar"] => 1, _ => 2 };
}

**デフォルトの名無しさん** · 2022/04/25(月) 19:55:08.99

>>679
配列は長さ固定
長さが異なれば別の型となる
マッチングは全て同じ型でなければならない

つまり長さ1の配列パターンがあるならば全て長さ1の配列
つまり配列としてマッチングする必要がない
実際には長い配列で先頭だけマッチングしているとしてもfoo[0].as_str()でよい

おそらく例として簡略化して書いたのだろうがもう少し具体化した方がアドバイスを受けやすい

**デフォルトの名無しさん** · 2022/04/25(月) 23:28:44.10

配列を使わずにスライスを使えば可変長マッチングができる

**デフォルトの名無しさん** · 2022/04/26(火) 02:22:33.26

問題はそこじゃなくて &[String] をパターンマッチする方法がないってことだよね

**デフォルトの名無しさん** · 2022/04/26(火) 02:43:40.86

Stringのままだと、文字列のマッチはガードでやるしかなそうだし、
その場合なら &str にしてからマッチしたほうが良さそうだね

**デフォルトの名無しさん** · 2022/04/26(火) 13:29:24.27

変換するならばヒープ使わずに配列mapかな
match foo.map(String::as_str) はちょっと惜しかった

**デフォルトの名無しさん** · 2022/04/26(火) 14:28:08.93

配列mapだと元のStringがdropされるから&str作れないのでは

**デフォルトの名無しさん** · 2022/04/26(火) 15:51:55.40

配列mapは別の配列となる
元は消えないのでdropはされない

**デフォルトの名無しさん** · 2022/04/26(火) 16:05:15.07

別の配列になるけど
mapがなぜかselfを要求する
つまりStringの配列に対して何もできない
Stringの長さの配列すら生成不可能
Copy実装型の配列に対してしかmapを使えないのではないか

**679** · 2022/04/26(火) 16:52:48.66

>>687
map が要求する self ってのはイテレータのことですよ。
配列の所有権が移ったりはしませんよ。

**デフォルトの名無しさん** · 2022/04/26(火) 16:57:38.42

>>688
配列mapはイテレータとは無関係

**679** · 2022/04/26(火) 17:05:45.05

>>689
失礼しました。
同名のものが配列にもあるんですね。

**デフォルトの名無しさん** · 2022/04/26(火) 17:08:44.26

>>687
長さの配列は元のStringへの参照を保持するわけではないから生成可能
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=1389138f28b6679332ad660d8920ea5e

元のStringがconsumeされるのでStringへの参照を持つようなデータへの変換はできない
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=f358e19998b508fe1955ea5274a7daf5

元の配列がdropされて良いならCopyな型に対してしか使えないということはないよ
例えば構造体の一部フィールドだけ変更するみたいな用途にも使える

**デフォルトの名無しさん** · 2022/04/26(火) 17:13:18.82

each_ref()を使えばできるよ

**デフォルトの名無しさん** · 2022/04/26(火) 17:20:49.70

&strの配列に変換してから比較すると変換時と比較時とで2周するのと
比較対象がconst相当じゃないとだめなのでguardのほうがベターなケースが多いと思う

**デフォルトの名無しさん** · 2022/04/26(火) 17:38:44.61

配列mapは新たな配列を作る
つまり配列map自体が元の配列をdropするわけではない
Copyを実装していない型の時はmoveとなるため結果として元の配列がdropされる
Copyを実装している型の時はmoveが起きないため元の配列もそのまま使える

// Copyを実装していない型の場合
#[derive(Debug)]
struct XM(i32);
let a1 = [XM(1), XM(2), XM(3)];
let a2 = a1.map(|XM(n)| n);
println!("{a2:?}");
// println!("{a1:?}"); // エラーとなる

// Copyを実装している型の場合
#[derive(Debug,Clone,Copy)]
struct XC(i32);
let a1 = [XC(1), XC(2), XC(3)];
let a2 = a1.map(|XC(n)| n);
println!("{a2:?}");
println!("{a1:?}"); // エラーとならず元の配列も残っている

**デフォルトの名無しさん** · 2022/04/26(火) 18:27:08.74

意味不明な解説だな
「array::mapはselfを要求する」の一言で済む話だろ

**デフォルトの名無しさん** · 2022/04/26(火) 18:33:28.01

配列mapは
Stringの配列を&strの配列に変換できないけど
&Stringの配列を&strの配列に変換できるよ
つまり
Stringの配列を&Stringの配列に変換できればよくてそれがeach_ref()

**デフォルトの名無しさん** · 2022/04/26(火) 19:46:56.99

each_ref()はまだstableじゃないので
Stringを&strにしておく方法でヒープ(Vec)を使わないならこうかな
let x: [String; 3] = ["foo".into(), "bar".into(), "baz".into()];
let y: ArrayVec<&str, 3> = x.iter().map(|s| &**s).collect();
let z = match &y[..] { ["foo", ..] => 1, _ => 2 };

**デフォルトの名無しさん** · 2022/04/26(火) 21:05:30.47

こういう何がしたいのか分かりにくいだけのコードは勘弁して欲しいな

**デフォルトの名無しさん** · 2022/04/26(火) 21:13:08.58

iter→map→collectだけのコードが分かりにくい、って初心者でも言わないだろｗ
3行目の数値1と2は謎だが>>679の質問者のコードそのままだな

**デフォルトの名無しさん** · 2022/04/26(火) 21:47:45.37

mapの中身は(|s| s.as_str())にしたいな
初心者だけど&**sはちょっと分かりにくい

**デフォルトの名無しさん** · 2022/04/26(火) 21:55:49.66

そういう視点ならば
match &y[..] のところも
match y.as_slice() にする？

**デフォルトの名無しさん** · 2022/04/26(火) 23:09:05.06

そこまでしてやるメリットが全くない
matchでやるならマッチガード一択

**デフォルトの名無しさん** · 2022/04/26(火) 23:34:34.80

>>700
sが&Stringだから
*sがStringになって
**sがstrになって【Derefによって】
&**sが&strになる
というのを知った時は衝撃的でした

**デフォルトの名無しさん** · 2022/04/27(水) 04:56:28.33

うーんRustのコンパイルエラーは素晴らしいな

**デフォルトの名無しさん** · 2022/04/27(水) 06:27:18.74

rustのジェネリックでSystemCみたいなのって書ける?
C#だと無理っぽいんだけど

**デフォルトの名無しさん** · 2022/04/27(水) 10:03:29.93

定数パラメータなら最近サポートされた

#[derive(Debug)]
struct Matrix<const N: usize>([[f32; N]; N]);

impl<const N: usize> Matrix<N> {
fn identity() -> Self {
let mut m = Self([[0.0; N]; N]);
for i in 0..N {
m.0[i][i] = 1.0;
}
m
}
}
fn main() {
let identity: Matrix<3> = Matrix::identity();
println!("{:?}", identity);
}

ちなみに
struct Matrix<const N: usize>([f32; N*N]);
はできなかった

**デフォルトの名無しさん** · 2022/04/27(水) 11:10:01.91

演算子 ? のことを個人的にトライ演算子と呼んでいたんですが、
公式には単に「operator ?」としか書いていないみたいですね。
口頭で言うときにはどういう言い方で呼びます？

**デフォルトの名無しさん** · 2022/04/27(水) 11:16:36.97

https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-question-mark-operator
一応公式はquestion mark operatorとのこと
日本語で口頭だと、はてな演算子って言っちゃうかな

**デフォルトの名無しさん** · 2022/04/27(水) 11:26:22.90

>>708
他は機能で名前が付いているのにそれだけ字面を元にした名前なんですね。

**デフォルトの名無しさん** · 2022/04/27(水) 11:32:02.01

try-catchが将来入ることを考えると、 ? の役割は try と言うより throw 相当と考えた方が良いのかな

**デフォルトの名無しさん** · 2022/04/27(水) 11:42:11.93

>>709
question markそのものにYes/Noの2択を突きつける意味があるからだろうな

**デフォルトの名無しさん** · 2022/04/27(水) 12:31:18.25

>>711
そんな意味ないでしょ
いい呼び名が見つからないからしかたなく今の名前になってる