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

殺されりゃ良かったのに

**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 でググるといろいろ情報出てくるかと