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

殺されりゃ良かったのに

**785** · 2022/05/05(木) 15:13:48.30

https://ideone.com/G4kYRi
enumで持つ整数の型を固定しないようにした
最初からこうすべきだった

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

カルビーが12月から全社員を対象にした副業制度を導入。
多様な働き方のさらなる進化を目指す

カルビー「何でもテレワーク」工場視察からゆるい勉強会まで

建設業界の常識を覆す“攻め”の働き方改革【週休３日制】を４月からトライアル導入
残業大幅減でも利益は昨対比２倍に上昇！

労働時間すべて社外勤務OK。トラック業界の“先駆者”が新制度

日野、「副業」許可制度を新設　“経験”広げて本業に生かす

ダイハツが副業容認を本格検討、その狙いと新しい働き方とは？

ダイドーグループ、「副業・副業受け入れ制度」を導入

Afterコロナ時代を生き抜くべく、ダイドードリンコが「自社人材の副業」と
「他社からの副業人材の受入れ」を開始

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

ふと思ったんだがそろそろブラウザ上でIDE提供増えないのかなあ

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

>>789
i32とありジェネリックになりきってないぞ

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

ジェネリック数値型ガイジ

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

>>792
必要に応じて実装してもらえればいいかな？
impl FizzBuzz for f32 {
fn fizzbuzz(&self) -> FizzBuzzResult<&Self> {
match (self % 3.0, self % 5.0) {
(0.0, 0.0) => FizzBuzzResult::FizzBuzz,
(0.0, _) => FizzBuzzResult::Fizz,
(_, 0.0) => FizzBuzzResult::Buzz,
_ => FizzBuzzResult::Num(self),
}
}
}
fn main() {
for n in 1..101 {
println!("{}", (n as f32).fizzbuzz())
}
}
正直言うとfn fizzbuzz<T>(n: T) -> FizzBuzzResult<T>
みたいな関数を書けないかと思って先に試してみたけど
中でリテラル使って計算してるのが祟って書けなかった

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

>>794
実装コードが異なる型は別実装でいい
しかし今回は同じ実装コードだろ
そういう時はジェネリックに書くのがRust

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

>>795
stdだとマクロ使ってるケースが多い気がするが

**デフォルトの名無しさん** · 2022/05/06(金) 00:00:07.68

>>796
一般的にジェネリックにするためのトレイト境界となるパーツのトレイトは個別に型列挙してimplする必要がある
そこではマクロが有用
パーツとなるトレイトを利用してプログラミングすれば列挙の必要性がない

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

パターンに定数を使うことは可能です。

fn baz(x : usize) -> usize {
const ZERO : usize = 0;
match x {
ZERO => 1,
_ => 2
}
}

しかしトレイト内の定数で型が確定しない状況ではそれがパターンに使える定数なのかどうかわかりません。
(のでエラーになります。)

trait foo {
const ZERO: Self;
fn bar(&self) -> usize {
match self {
Self::ZERO => 1, // エラーになる
_ => 2
}
}
}

このとき Self がパターンに現れることが出来る型であるという制限を付けることは可能ですか？

(>>794 の定数だけ impl すればメソッド自体は共通化できるかなと思って試みたけどこれをどうにもできなくて困った)

**デフォルトの名無しさん** · 2022/05/06(金) 01:50:09.59

そういう場合はif使いなさい

**デフォルトの名無しさん** · 2022/05/06(金) 06:31:06.34

>>798
その問題もTraitの関数でconstを返せないため現状では無理
だからmatchパターンでは使えないがifガードでなら使える
　
>>789のうちimpl FizzBuzzだけ以下に変更

use std::ops::Rem;
impl<T> FizzBuzz for T where T: Copy + From<u8> + PartialEq + Rem<Output=T> {
fn fizzbuzz(&self) -> FizzBuzzResult<&Self> {
let zero = T::from(0);
match (*self % T::from(3), *self % T::from(5)) {
(x, y) if x == zero && y == zero => FizzBuzzResult::FizzBuzz,
(x, _) if x == zero => FizzBuzzResult::Fizz,
(_, y) if y == zero => FizzBuzzResult::Buzz,
_ => FizzBuzzResult::Num(self),
}
}
}

これでu128でもf64でも動く

**デフォルトの名無しさん** · 2022/05/06(金) 11:54:43.12

でもそれi8では動かないだろ

**デフォルトの名無しさん** · 2022/05/06(金) 12:16:10.95

ざんね～ん
f64はStepを実装していないので(1.0)..=(100.0)できませ～ん
いっけね！

**デフォルトの名無しさん** · 2022/05/06(金) 12:52:49.36

>>802
え？
>>794のas f64方式で動きましたけど

**デフォルトの名無しさん** · 2022/05/06(金) 13:38:51.38

impl XXX for T で where にだらだら制約書くやつは変に制約強くなりがちだから実装の共通化が目的ならマクロ使った方が良い
実装の共通化のために継承を使うようなもので、目的に対して不適切な手段を使っているように思う

**デフォルトの名無しさん** · 2022/05/06(金) 14:08:08.87

パラノイアみたいにジェネリックジェネリック言う割にはそこだけ{integer}なのは気にしないんだ

FizzBuzzなんて>>781でいいんだよ
もっと意味のある仕事をしようぜ

**デフォルトの名無しさん** · 2022/05/06(金) 14:14:00.63

ジェネリックにするのも時間の無駄だが
traitにするのがそもそもガイキチ

>>781は無限ビジーループで論外
最低限でも関数の入出力は考えろ

**デフォルトの名無しさん** · 2022/05/06(金) 14:15:08.65

マクロ使うしかないんだけど、マクロの部分はエディタのサポートがちょっと弱くなるのが残念だよね

**デフォルトの名無しさん** · 2022/05/06(金) 18:19:49.06

FizzBuzz を過剰にジェネリックにする意味はないが、
ここではジェネリック化の手法を色々知るというのがトピックで FizzBuzz はただの例だよ。

**794** · 2022/05/06(金) 18:53:54.80

>>797
> トレイト境界となるパーツのトレイトは個別に型列挙してimplする必要がある

もしよかったら具体的にどういうことか教えてちょ
不勉強すぎてまったくついていけない

>>798
> 定数だけ impl すればメソッド自体は共通化できるかな

定数だけimplするとは？

>>800
（´･∀･`）ﾍｰ
勉強になりました
Fromってそうやって使うんやね

>>804
みんながどうやらマクロで解決してるらしいのは流れみて分かったが
具体的にはさっぱり分からんのでツライところ
おまえらって詳しくてスゴイわ

**デフォルトの名無しさん** · 2022/05/06(金) 19:10:43.41

>>809
> 定数だけimplするとは？

実際には動作しないけどコードで言えばこんなのを考えてた。
https://ideone.com/vSnAET

**デフォルトの名無しさん** · 2022/05/06(金) 19:18:41.78

>>810
なるほど
言わんとする意味はバッチリ分かりました
みんな色々考えるんだなｗ

**デフォルトの名無しさん** · 2022/05/06(金) 19:23:32.30

>>809
マクロでtraitを実装するためには以下みたいなマクロを書けば良い
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=15c040ac82d2d655a7b75492c17bc73f

マクロ定義の方法などは rust macro でググるといろいろ情報出てくるかと

**デフォルトの名無しさん** · 2022/05/06(金) 21:26:29.85

>>810
RemのOutput型を指定すればちゃんとE0158エラーになるよ

**デフォルトの名無しさん** · 2022/05/06(金) 22:25:22.98

>>812
> マクロでtraitを実装する

（´･∀･`）ﾍｰ
imple X for Yまるごとマクロの中に来るんやね
Rustのマクロについては調べたこと無かったけど
やっぱやりたいことはできるようになってそうで安心
ありがとうございました

**デフォルトの名無しさん** · 2022/05/06(金) 22:43:10.27

ジェネリックにしつつpattern match使いたいなら
(0, 0)じゃなくて(true, true)でmatchすればいいと思う
https://play.rust-lang.org/?edition=2021&gist=c83dbaa7166545941649bb279f2162bd

**デフォルトの名無しさん** · 2022/05/06(金) 23:24:33.89

>>815
それいいな。
先にゼロと比較してから true にマッチさせる部分よりもゼロを作るテクニックのほうが面白いと思った。

**デフォルトの名無しさん** · 2022/05/06(金) 23:27:51.66

>>801
i8で動かない原因はFromを使っているためなのでTryFromを使えばi8でも動く

use std::convert::TryFrom;
use std::ops::Rem;
use num::CheckedAdd;

fn fizzbuzz<T>() -> impl Iterator<Item=FizzBuzzResult<T>>
where T: Copy + PartialEq + CheckedAdd + Rem<Output=T> + TryFrom<usize>,
{
let [zero, one, three, five] = [0, 1, 3, 5]
.map(|n| T::try_from(n).ok().unwrap());
itertools::unfold(zero, move |n|
n.checked_add(&one).map(|new| {
*n = new;
match (new % three, new % five) {
(x, y) if x == zero && y == zero => FizzBuzzResult::FizzBuzz,
(x, _) if x == zero => FizzBuzzResult::Fizz,
(_, y) if y == zero => FizzBuzzResult::Buzz,
_ => FizzBuzzResult::Num(new),
}
})
)
}

fn main() {
for f in fizzbuzz::<i8>() {
println!("{f}");
}
}

ちゃんとi8の上限127で停止

**デフォルトの名無しさん** · 2022/05/07(土) 00:46:09.52

やるじゃん
なぜかマクロを嫌うならそれでいいね

**デフォルトの名無しさん** · 2022/05/07(土) 01:43:00.17

>>818
すいません
マクロで>>817を実装可能なのですか？

**デフォルトの名無しさん** · 2022/05/07(土) 02:27:17.25

どっちがいいかどうかはともかくとして、817が使ったであろうnum-traitsのcrateのCheckedAddもマクロで実装されてるよん
こういうのはマクロになりがち

**デフォルトの名無しさん** · 2022/05/07(土) 03:15:28.92

どちらも正しい
・基本的な性質のTraitは型を列挙してimplする　→マクロになる
・それら以外のTraitは基本Traitを組み合わせる　→Trait境界の列挙となる

**デフォルトの名無しさん** · 2022/05/07(土) 03:24:48.03

>>819
>>817 ではイテレータになってたから全然同じじゃないけど、こういうのを言いたかった
マクロを使うことでTrait境界を要求しない実装ってこっちゃね

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

**デフォルトの名無しさん** · 2022/05/07(土) 03:48:53.73

>>822
ところで>>817のイテレータはマクロでできる？

**デフォルトの名無しさん** · 2022/05/07(土) 05:13:50.57

>>823
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=af4aee4ee627c2163d78714f82976a8f

今日の学び: RangeFromからnext()し続けるとオーバーフローでpanic!する

**デフォルトの名無しさん** · 2022/05/07(土) 08:35:04.90

現状はジェネリックじゃ実現できない事が多々あるから性能面を重視するならマクロになる
数値系は特に

**デフォルトの名無しさん** · 2022/05/07(土) 10:48:47.74

型パズルオナニストきついなぁ
長いコードをレスに直接貼りたがる性癖どうにかならんの？

**デフォルトの名無しさん** · 2022/05/07(土) 11:34:33.57

型パズルとか言ってるやつ
トレイト境界を理解できていないのか

**デフォルトの名無しさん** · 2022/05/07(土) 12:04:47.91

>>825
マクロとtraitで性能が変わりうるのってどういう時？
traitだと回りくどい記述になりがちということ？

**デフォルトの名無しさん** · 2022/05/07(土) 12:16:47.05

>>828
BigIntは参照で渡したいけどプリミティブ数値型は値で渡したい
traitだと値か参照かどっちかにしかできない、とかじゃねーの知らんけど

**デフォルトの名無しさん** · 2022/05/07(土) 13:05:53.65

>>827
トレイト境界を理解できないやつがいると思っちゃうところが相当ヤバいんですけど
さすオナ

**デフォルトの名無しさん** · 2022/05/07(土) 14:47:11.23

>>829
そういうときは Cow を使うもんじゃねーの
しらんけど

**デフォルトの名無しさん** · 2022/05/07(土) 16:45:29.23

>>828
const

**デフォルトの名無しさん** · 2022/05/07(土) 16:47:29.20

マクロとトレイトじゃなく
マクロとジェネリックの比較

**デフォルトの名無しさん** · 2022/05/07(土) 17:58:20.41

>>826
Rustに限った話じゃないけど、playground系で貼らないのは自己顕示欲の率直なあらわれだと思う