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/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
そんな意味ないでしょ
いい呼び名が見つからないからしかたなく今の名前になってる

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

Cowにmapがほしい

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

前置ならtryのままでもよかったんだろうけどね

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

後置でメソッドチェーンと相性よくなった

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

後置にするにしても普通のメソッドみたいになんらかの名前で呼び出すようにしたら
それがプログラムの流れを変える制御構文的なものであることが分かり難くなるだろうし、
後置の演算子という選択はとても良いと思う。

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

>>716
そういう点では
.awaitも記号オペレータにしてほしかったわ
良い記号さえあれば

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

>>716
後置の演算子にするのはRustの使い方なら当然だと思うが
声に出して読めない(人によって読み方がバラバラになってる)のが問題

try file.read()時代は誰でも同じように読めた
file.read()? は読めない

.awaitはオペレータを導入したとしてもawaitオペレータという呼び方でみんな同じように読めるから何の問題もない

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

file.read().await? よりも
file.read()待? でいいんじゃないかな
オペレータ記号は仮に「待」とした

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

演算子として使える記号残ってる？

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

>>713
Cowにmapってどういう仕様にするの？
どちらの場合でも統一的に具体型へ変換ならcow.as_ref()かcow.into_owned()のどちらかだろうし

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

Cow::to_mut() じゃだめ？

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

>>722
cowを変換して何かにするのではなく
cowそのままでそれ自体を統一的に書き換えるならto_mutだね

**デフォルトの名無しさん** · 2022/04/28(木) 10:44:53.84

バイナリデータを受け取るいい方法ってある？
やりたいことはGETリクエストの結果送られてくるバイナリデータをファイルに保存したい

CやJavaなら適当なchar配列（Javsはbyte）でいっぱいまで受け取ってファイルに書き出すを繰り返せばいいってわかるんだけど、似たようなことをRustでやりたい

**デフォルトの名無しさん** · 2022/04/28(木) 11:03:14.51

>>724
Rust でも同じやで。
特に違いはない。

**デフォルトの名無しさん** · 2022/04/28(木) 11:12:32.29

ありがとう
やってみる

**デフォルトの名無しさん** · 2022/04/28(木) 11:40:54.23

綺麗に抽象化したレイヤを作ろうとしたら C や Java とは違った雰囲気にはなるだろうけど、そういうのは後回しや。
綺麗だろうが汚かろうがまずはやってみたらええんや。

ところで「汚かろう」を変換したら「北中朗」と出てきた。誰やお前は。

**デフォルトの名無しさん** · 2022/04/29(金) 00:19:46.61

勉強中
Cow<T>の取りうる値は
・Cow::Borrowed(T)
・Cow::Owned(<T as ToOwned>::Owned)
とのことなので ToOwned を調べてみると
　ToOwned::Owned = Borrow<T>
つまり impl Borrow<T> for S の時に
・Cow::Borrowed(T)
・Cow::Owned(S)
となる関係だと分かった
そしてこんな状況で使えるぽい
impl Borrow<[T]> for Vec<T>
impl Borrow<str> for String
impl Borrow<CStr> for CString
impl Borrow<OsStr> for OsString
impl Borrow<Path> for PathBuf

**デフォルトの名無しさん** · 2022/04/30(土) 03:53:42.52

16進数文字列から整数への変換を標準ライブラリでやるにはどうすればよいですか？

**デフォルトの名無しさん** · 2022/04/30(土) 07:53:08.90

Cだと次のように書けるエンディアンを調べるプログラムはどう書いたらいいですか?

int x = 0x12345678;
char *p = &x;

for( int i = 0; i< sizeof(int); i++ ){
fprintf(stderr, "%X\n", *p++ );
}

CでもWarningは出ますが

**デフォルトの名無しさん** · 2022/04/30(土) 09:38:22.42

>>730
コンパイル時に判別できる
https://doc.rust-lang.org/reference/conditional-compilation.html#target_endian

**デフォルトの名無しさん** · 2022/04/30(土) 19:04:20.68

>>730
どうしても表示したいならば
直訳するとこんな感じ

use std::mem::size_of;

fn main() {
let x: i32 = 0x12345678;
let p = &x as *const i32 as *const u8;
for i in 0..(size_of::<i32>() as isize) {
eprintln!("{:x}", unsafe { *p.offset(i) });
}
}

**デフォルトの名無しさん** · 2022/04/30(土) 22:34:14.48

原則としてはエンディアンに依存しない形で書いて入出力のときだけ from_le とか to_le とかで処理するのが良い作法だとは思うけどね……。

**デフォルトの名無しさん** · 2022/04/30(土) 23:10:52.66

>>729
仕様がわからないからジェネリックにOption<T>で返すとしてこうなるのかな
stdにCheckedAddとCheckedShlがないから自作するところを略してnum::から借りた

use num::traits::{CheckedAdd, CheckedShl};

fn parse_hex<T>(s: &str) -> Option<T>
where T: From<u8> + CheckedShl + CheckedAdd
{
s.bytes()
.try_fold(T::from(0), |acc, b|
acc
.checked_shl(4)?
.checked_add(&T::from(byte_to_hex(b)?))
)
}

fn byte_to_hex(b: u8) -> Option<u8> {
if b'0' <= b && b <= b'9' {
Some(b - b'0')
} else if b'A' <= b && b <= b'F' {
Some(b - b'A' + 10)
} else if b'a' <= b && b <= b'f' {
Some(b - b'a' + 10)
} else {
None
}
}

fn main() {
assert_eq!(Some(65535), parse_hex::<u16>("ffff"));
}

**デフォルトの名無しさん** · 2022/04/30(土) 23:19:42.84

そんなことせんでもfrom_str_radixがあるでよ

https://doc.rust-lang.org/std/primitive.i64.html#method.from_str_radix

**デフォルトの名無しさん** · 2022/05/01(日) 09:25:29.21

>>734
がんばりすぎw

**デフォルトの名無しさん** · 2022/05/01(日) 13:20:24.87

>>734 これ標準ライブラリにあるで
use std::usize;
fn main() {
let z = usize::from_str_radix("ffff", 16).unwrap();
assert_eq!(z, 65535);
}

**デフォルトの名無しさん** · 2022/05/01(日) 18:53:34.40

現状のstr::parse()とstr::FromStr traitのコードは以下のようになっているが
fn parse<F: FromStr>(&self) -> Result<F, F::Err> {
FromStr::from_str(self)
}
trait FromStr {
type Err;
fn from_str(s: &str) -> Result<Self, Self::Err>;
}

このFromStrをAddなどと同様にOutput指定付きにしておけば良かったのではないか？
trait FromStr<Output = Self> {
type Err;
fn from_str(s: &str) -> Result<Output, Self::Err>;
}

そうすると以下のようにOutputをSelf以外でimplできるようになるから
impl<T, const N: usize> FromStr<Output = T> for Radix<T, N> { ... }
現在ある>>737のfrom_str_radix()が使えないu128出力などにも拡張できて
"ffffffffffffffff".parse::<Radix<u128, 16>>()
と使えるようになるから中途半端なfrom_str_radix()を廃止してparse()に統一できる

**デフォルトの名無しさん** · 2022/05/01(日) 20:49:11.67

u128でもfrom_str_radix使えるのはさておき
便利そうだけどそんなtraitにFromStrという名前が付くのは違和感あるなあ

**デフォルトの名無しさん** · 2022/05/01(日) 21:11:45.93

>>739
え？
例えば&strからIPv4やIPv6アドレスへの変換ですらRust標準ライブラリはFromStrを使ってるよ

**デフォルトの名無しさん** · 2022/05/01(日) 21:14:33.66

>>740
FromStrなのにSelf以外の型に変換されるのが違和感あるということでは

**デフォルトの名無しさん** · 2022/05/01(日) 21:15:48.33

T::from_str が T (Result<T, E>) 以外の型を返す関数なのは違和感あるでしょってことが言いたかった

**デフォルトの名無しさん** · 2022/05/01(日) 21:41:43.18

Radix<u128, 16>::from_str が Radix<u128, 16> を返してもいいだろうけど
中身はu128しかないのだから FromStr<Output = u128> で u128 を返せると便利、って話だよね
XXX::from_str の XXX 部分は文字列をどう解釈するかの指定
だから通常は Output = XXX と同一になるけど、そこを指定できると互換性を保ったまま利便性を向上できるという話だよね

**デフォルトの名無しさん** · 2022/05/01(日) 22:19:59.78

提案自体は分かるけど T from str と読めるメソッドが T 以外の何者かを返すのは不適切な命名では？
別のtraitでやるべきだと思う

**デフォルトの名無しさん** · 2022/05/01(日) 22:44:03.61

>>741
そういうこと
不用意に複雑にするのはよろしくないし、stdにある必要も無いと思う
どうしてもやりたければ↓みたいに自分で実装できるし、
もっと複雑になってきたら適切なパーサライブラリでも使用するのがいいだろう
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f450a3bdf5eab0f1849b4945aede582f

**デフォルトの名無しさん** · 2022/05/01(日) 23:00:56.52

ところでこれ書いてて気づいたけど i8::from_str_radix("80", 16) とかは PosOverflow になるんですね
16 だからできそうな気がするだけで、考えてみればそうかという感じだけど

**デフォルトの名無しさん** · 2022/05/01(日) 23:26:05.49

>>746
自作でもそのへんのエラーを返したい時あるけど
ParseIntErrorのnewが無い、かつ、kindがprivateなため返せなくて困ったことがある

**デフォルトの名無しさん** · 2022/05/02(月) 02:54:31.42

>>738 u128にもあるけど...
https://doc.rust-lang.org/std/primitive.u128.html#method.from_str_radix

**デフォルトの名無しさん** · 2022/05/02(月) 15:22:57.69

cargo が粗悪

ｽｸﾞにリソースを喰らい尽くす特級禍呪怨霊

**デフォルトの名無しさん** · 2022/05/02(月) 15:33:08.28

>>749
メモリかCPUが足りないなら -j オプションつけるか
.cargo/config.toml の jobs 設定したら良いのでは
https://doc.rust-lang.org/cargo/reference/config.html

**デフォルトの名無しさん** · 2022/05/02(月) 18:47:44.24

どちらも参照で構造体のオプションをそのメンバーのオプションにするもっと短い表記ないのかな
struct1.map(|struct1| struct1.member2)

**デフォルトの名無しさん** · 2022/05/02(月) 22:42:33.85

どちらも参照とは？

**デフォルトの名無しさん** · 2022/05/02(月) 23:24:08.49

メンバーを参照で返すならば
&struct1.member2 と＆が必要
元のOptionのstruct1はもし参照が外側ならば
struct1.as_ref() で内側の参照にしておくことが必要

**デフォルトの名無しさん** · 2022/05/03(火) 01:23:35.68

struct1.map(|struct1| &struct1.member2)
長くていいなら
struct1.and_then(|struct1| Some(&struct1.member2))

**デフォルトの名無しさん** · 2022/05/03(火) 02:02:53.67

すごく曖昧な日本語だけど普通に読むなら
構造体のオプションも、そのメンバーのオプションも、どちらも参照という意味じゃないの？

struct Foo<‘a> {
　bar: &’a Option<Bar>
}

↑こういう構造体を&Option<Foo>の形で受け取って内包する&Option<Bar>で返したいという話
知らんけど

**デフォルトの名無しさん** · 2022/05/03(火) 02:47:01.44

これならstruct1が1回しか出てこなくて短い
(|| Some(&struct1?.member2))()

**デフォルトの名無しさん** · 2022/05/03(火) 08:20:59.49

>>755
Option<&T>をOption<&U>にしたいだけやろ
>>751のでやりたいこと出来てるんだろうから

**デフォルトの名無しさん** · 2022/05/03(火) 09:09:45.26

そういうことか
だとmapするのが一番シンプル
$0やitのようなクロージャ用の暗黙的変数はないから明示的に渡すのは必須
struct1.map(|x| x.member2)

**デフォルトの名無しさん** · 2022/05/03(火) 10:14:43.19

正解はこれ
try {&struct1?.member2}

**デフォルトの名無しさん** · 2022/05/03(火) 12:00:16.10

>>758
多段(メンバーのメンバー)を考えるとmapは見辛いし長い
なのでtryブロックもしくはstableならクロージャで？オペレータが良い

**デフォルトの名無しさん** · 2022/05/03(火) 14:05:10.50

複オジ式の無駄打ちクロージャは真似したらダメだぞ

**デフォルトの名無しさん** · 2022/05/03(火) 15:24:00.08

>>760
tryブロックはまだしもクロージャの即時実行は意図を曖昧にするだけだから極力避けたほうがいいと思う
多段で長くなるような処理なら関数化して型を明記しておいたほうが後で楽
クロージャは型推論と外部変数のキャプチャで最初は楽できるんだけどね

**デフォルトの名無しさん** · 2022/05/03(火) 16:33:58.30

十文字かそこらで終わるレベルならクロージャでも別に悪くはないと思うけどね。
多少の無駄は最適化で消えてなくなるだろうし。

ただ、そう思っていると後からごちゃごちゃ処理が増えてわけわからんようになるのが世の常というものなんや……。

**デフォルトの名無しさん** · 2022/05/03(火) 16:54:12.49

多段になった時にクロージャだと「?」を重ねてすぐ書けたのですが
クロージャではなくmapを使う場合はどのように書けばいいのでしょうか？

fn main() {
struct S<'a> { o: Option<&'a str> }

let s1 = Some(S { o: Some("abc") });
let s2 = Some(S { o: Some("pq") });
let s3 = Some(S { o: None });
let s4 = None;

for s in &[s1, s2, s3, s4] {
let s = s.as_ref();
let a = (|| s?.o?.get(2..=2))();
println!("{a:?}"); // Some("c"), None, None, None
}
}

このクロージャで動いている例で教えてください

**デフォルトの名無しさん** · 2022/05/03(火) 17:13:47.14

>>764
それはmapじゃなくてand_thenする
let a = s.and_then(|s| s.o?.get(2..=2));

**デフォルトの名無しさん** · 2022/05/03(火) 17:16:17.82

>>765
それ？とクロージャ使ってるやん

**デフォルトの名無しさん** · 2022/05/03(火) 17:27:23.29

それは良いクロージャ

**デフォルトの名無しさん** · 2022/05/03(火) 17:31:47.54

>>765
同じこと(構造体の有無)をしてるのに
さっきはmapで今回はand_thenかよ
一貫性がなくわかりにくくなってるぞ

**デフォルトの名無しさん** · 2022/05/03(火) 17:39:05.78

ここまで見てきて感想

// 一貫性もあり分かりやすいクロージャ
let a = (|| s?.o)()
let a = (|| s?.o?.get(2..=2))();

// 一貫性もなく分かりにくいクロージャ＋α
let a = s.map(|s| s.o);
let a = s.and_then(|s| s.o?.get(2..=2));

**デフォルトの名無しさん** · 2022/05/03(火) 17:47:34.89

どうでもいい
nightly使ってろ

**デフォルトの名無しさん** · 2022/05/03(火) 18:47:46.49

複オジがバカにされて暴れてるw

**デフォルトの名無しさん** · 2022/05/03(火) 19:05:25.07

このand_then方式が何故わかりにくくなっているかというと
let a = s.and_then(|s| s.o?.get(2..=2));
先頭のsだけを特別扱いしていることが原因

例えばこのように先頭を無条件に真となるようにすると
let a = Some(true).and_then(|_| s?.o?.get(2..=2));
その後のs?もo?も同じ扱いになり常に一貫した表記となる

上記から無駄な部分を省いてしまうと
let a = (|| s?.o?.get(2..=2))();
結局クロージャのみとなる
つまり最初の部分だけ特別扱いをやめたことで表記が一貫した

**デフォルトの名無しさん** · 2022/05/03(火) 19:50:20.80

>>762
それは視野が狭すぎる
クロージャ類の即時実行は他のプログラミング言語でも普通に使われる
特にRustではインライン展開されて付加コスト無し
そのため様々なcrateでクロージャの即時実行が使われている
標準ライブラリ内部では先行してtryブロックが有効となったためそちらへ移行した
つまりクロージャの即時実行で書いておけばtryブロックがstableとなった時に移行しやすいメリットもある

**デフォルトの名無しさん** · 2022/05/03(火) 22:36:42.91

複オジがmapとflatMapを理解してないだけだな

**デフォルトの名無しさん** · 2022/05/03(火) 23:10:41.13

標準ライブラリ内では今はtryに移行しているけど多用されているな。
激しいのだと"?"が6個も出てくる。

https://doc.rust-lang.org/src/core/iter/adapters/flatten.rs.html#322
> let upper = try { fhi?.checked_add(bhi?)?.checked_add(fixed_size.checked_mul(upper?)?)? };

これもstableでは (|| fhi?.checked_add(bhi?)?.checked_add(fixed_size.checked_mul(upper?)?))(); で動く。
したがってstableではクロージャーを即時実行する形で書き、
いずれtry_blockがstableになったらそのまま置き換えがベストな方法。

**デフォルトの名無しさん** · 2022/05/03(火) 23:19:39.02

tryっていつ安定版に入るの？

**デフォルトの名無しさん** · 2022/05/03(火) 23:49:23.79

tryはクロージャ代用で困っていないが
GATsとimpl specializationを早く安定化して欲しい

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

try blockが解決しようとしてる問題を理解すればIIFEの何が問題なのかも分かる

**デフォルトの名無しさん** · 2022/05/04(水) 19:39:53.08

Rustで出来るだけダサいプログラム書いてみて

**デフォルトの名無しさん** · 2022/05/04(水) 20:57:45.43

>>779
fn main() {
let mut i = 0;
while i < 10 {
print!("{}", i);
i += 1;
}
}

**デフォルトの名無しさん** · 2022/05/04(水) 21:42:20.03

Rustの練習でFizzBuzzを書いてみたのですがもっと速くできますか？

fn main() {
let mut n = 1;
loop {
if n % 15 == 0 {
println!("FizzBuzz");
} else if n % 5 == 0 {
println!("Buzz");
} else if n % 3 == 0 {
println!("Fizz");
} else {
println!("{n}");
}
n = n + 1;
}
}

**デフォルトの名無しさん** · 2022/05/04(水) 23:33:28.78

>>776
型を指定する方法が未解決なのでいつになるかは不明
年単位で先の話になると思っておいたほうがいい

**デフォルトの名無しさん** · 2022/05/05(木) 00:18:26.00

FizzBuzzは単純すぎて実行時の剰余算とその分岐を避けるくらいしか改善できないんじゃないか
あとはマジックナンバーを避けて更にRustっぽく書くとこうかな
const FIZZ: usize = 3;
const BUZZ: usize = 5;
const FIZZ_BUZZ: usize = FIZZ * BUZZ;
fn main() {
(0..FIZZ_BUZZ)
.cycle()
.enumerate()
.skip(1)
.for_each(|(n, i)| match TABLE[i] {
Some(s) => println!("{s}"),
None => println!("{n}"),
})
}

type Table = [Option<&'static str>; FIZZ_BUZZ];
const TABLE: Table = make_table();
const fn make_table() -> Table {
let mut table = [None; FIZZ_BUZZ];
let mut i = 0;
while i < FIZZ_BUZZ {
table[i] = match i {
i if i % FIZZ_BUZZ == 0 => Some("FizzBuzz"),
i if i % BUZZ == 0 => Some("Buzz"),
i if i % FIZZ == 0 => Some("Fizz"),
_ => None,
};
i = i + 1;
}
table
}

**デフォルトの名無しさん** · 2022/05/05(木) 05:24:26.06

ダサい例として挙げられていたwhileによるカウントアップが使われているけど
const_forはまだまだ先が長そうね
そのためにはIterator
そのためにはimpl Trait

**デフォルトの名無しさん** · 2022/05/05(木) 08:21:51.44

>>781
https://ideone.com/QkAorv
速くはできてないと思うけど
ifじゃなくてmatchを使った例
fn main() {
for n in 1..101 {
match (n % 3, n % 5) {
(0, 0) => println!("fizzbuzz"),
(0, _) => println!("fizz"),
(_, 0) => println!("buzz"),
_ => println!("{}", n),
}
}
for n in 1..101 {
println!("{}", n.fizzbuzz())
}
}
あと下の例はenumとtraitを使ってみた
enumとtraitのほうはrustっぽく使えてるかどうか自信なし

**デフォルトの名無しさん** · 2022/05/05(木) 09:45:30.02

forってかなり高度な構文だよなと改めて思う
constで使えるようになるのはかなり先になりそうだな...

**デフォルトの名無しさん** · 2022/05/05(木) 09:49:51.56

C++ の constexpr でも for が使えるようになるまでちょっとかかったもんな。

**デフォルトの名無しさん** · 2022/05/05(木) 12:45:23.13

在日ちょんこに尻尾振ってついて行って
レイプされたバカ女の数々
https://uploader.cc/s/9d11h2w9wvh4ju43jicl5t80kyyk4buz8anyyinyvh3tpystxk8mmmj9lejo1rer.mp4

殺されりゃ良かったのに