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/05/09(月) 12:41:02.29

>>892
？
なんかごめん

**デフォルトの名無しさん** · 2022/05/09(月) 12:53:11.04

>>894
経験の違いじゃない？

関心事の分離を意識できないのは使い捨て感覚ででしかコードを書いたことのないからだと思う

組織で開発してたり長く維持する製品コードを書いた経験があればトイプログラムでも関数の責務くらいは意識して書くから

**デフォルトの名無しさん** · 2022/05/09(月) 13:06:31.44

フィボナッチ数列イテレータでも同じだろう

fn fibonacci<T>() -> impl Iterator<Item=T>
where T: Clone + TryFrom<usize> + num::CheckedAdd,
{
let [zero, one] = [0, 1].map(|n| T::try_from(n).ok().unwrap());
itertools::unfold((zero, one), |(m, n)|
m.checked_add(&*n).map(|f| {
*m = n.clone();
*n = f.clone();
f
})
)
}

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

**デフォルトの名無しさん** · 2022/05/09(月) 13:21:30.58

checked_add否定派のコードも見てみたい

**デフォルトの名無しさん** · 2022/05/09(月) 13:55:40.18

フィボナッチとFizzBuzzを同一視する時点でw

**デフォルトの名無しさん** · 2022/05/09(月) 14:10:19.70

FizzBuzzの判定処理には Checked は不要
Overflowしないような列挙をするイテレータを実装する Checked が必要

という話だが、 >>817 でこういうイテレータの機能が突然持ち込まれたせいで、みんなが混乱したんやぞ

**デフォルトの名無しさん** · 2022/05/09(月) 14:13:22.16

>Overflowしないような列挙をするイテレータを実装する Checked が必要

「なら」が抜けてた
Overflowしないような列挙をするイテレータを実装するなら Checked が必要

**デフォルトの名無しさん** · 2022/05/09(月) 14:16:50.30

一方で>>884氏や>>886氏はFizzBuzzイテレータにまでCheckedAddが不要と主張している
もちろんこの主張は間違い

**デフォルトの名無しさん** · 2022/05/09(月) 15:21:48.58

FizzBuzzイテレータw
さすが複製おじさんww

**デフォルトの名無しさん** · 2022/05/09(月) 15:30:51.28

>>884 >>896
その分離方式でも同じ結果となる
上限チェックのところでchecked_addが必要

**デフォルトの名無しさん** · 2022/05/09(月) 15:47:05.40

>>903
確かに強弁の感じが所有権の複製と人と同じっぽいな
もしそうなら議論は難しそう

**デフォルトの名無しさん** · 2022/05/09(月) 15:48:28.09

プリミティブの整数型なら>>824みたいに0..=<T>::MAXでもいいし、
ジェネリックにやりたいなら0..=<T as num::Bounded>::max_value()もある

つーか自分が唯一の正解みたいなこと平気で言うそういうとこやぞ

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

範囲とか順序とかはまた別の関心事だもんな
元々はせいぜい整数のfizzbuzz表現であって

>>906
そうそう
そういう感じよね

**デフォルトの名無しさん** · 2022/05/09(月) 15:58:11.58

>>906
それは失敗パターンかな
<T>::MAXはTが自作の型の時に定義できない

**デフォルトの名無しさん** · 2022/05/09(月) 16:07:00.72

脊髄反射しすぎww
こりゃ真性だな

**デフォルトの名無しさん** · 2022/05/09(月) 16:12:12.41

イテレータを返したいならイテレータアダプタとして実装すればいいだけ
FizzBuzzはイテレータのソースにすべきものじゃない

**デフォルトの名無しさん** · 2022/05/09(月) 16:30:09.21

>>906
checked_addの代わりにMAXやmax_valueを使うのは良くないです
checked_addは足し算の時に自動的に発生するオーバーフローを利用するため比較演算が発生しませんが
MAXやmax_valueはその値と比較する演算が余分に発生します
checked_addを使いましょう

**デフォルトの名無しさん** · 2022/05/09(月) 17:00:00.27

>>896
何か腑に落ちたわ
多少なりともチーム開発の経験があれば
独りよがりなコードをドヤ顔でペタペタ貼り付けたりしないもんな

**デフォルトの名無しさん** · 2022/05/09(月) 17:08:18.20

簡単に差分やマージできる環境と5chスレを比べても無意味じゃないか

**デフォルトの名無しさん** · 2022/05/09(月) 17:21:09.62

チーム開発をやっててもオレオレエンジニアっているからね
マウンティング・強弁・逆ギレはメンタリティの問題でもある

「オレが書いたコード、すごいだろ！」
https://xtech.nikkei.com/atcl/nxt/column/18/00205/032300028/

**デフォルトの名無しさん** · 2022/05/09(月) 18:06:15.99

>>911
何を言っとるんじゃい
外から渡せばいいじゃんって話をしてるのわかってる？

fizzbuzzは100からのカウントダウンでやったって別にいいんだぞ

traitやenum使う前に関数の入出力考えなよ

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

普通に考えたらこんなイテレータはstd::ops::Rangeとかで十分だし、しかもより高機能だから、自分で実装しなくていいよな
イテレータの勉強をしてるならともかくとして

**デフォルトの名無しさん** · 2022/05/09(月) 18:29:52.00

>>906
その<T as num::Bounded>::max_value()も一つの手であるが意外に致命的な欠陥がある
例えばBigIntなどの最大値がない型に対してBounded traitを実装できない
そして実際にBigIntではimplされていないため使えない

一方で<T as num::CheckedAdd>::checked_add()も同種の問題が起きないのか、だが
例えば最大値が存在しないBigIntでもCheckedAddはimplされている
オーバーフローが発生しないためNoneを返す必要がなく常にSomeを返す形となっている
つまり自分で作った型の場合であってもCheckedAddならば柔軟に対応できる

したがってRustで無限となりうる数列を扱う時はCheckedAddを使用することが好ましい

**デフォルトの名無しさん** · 2022/05/09(月) 18:41:12.79

impl FizzBuzz for T
vs
impl FizzBuzz for u8, u16, ...
の話だと思ってたんだが話が発散しすぎ

**デフォルトの名無しさん** · 2022/05/09(月) 18:50:22.63

>>915
>>918
FizzBuzzは単なる話の出発点の例の一つに過ぎなくて既に皆はもっと一般的な話をしているようにみえる
皆もFizzBuzz限定の話なんかに興味はなくて一般的な話に興味があるからではないかな

**デフォルトの名無しさん** · 2022/05/09(月) 18:57:03.49

>>917
0からの列挙を型だけから導出できないといけない理由は何なのさ

**デフォルトの名無しさん** · 2022/05/09(月) 19:14:23.35

>>920
各型には上限値(とその有無)がありメモリサイズとトレードオフだからそこは気を使うよ
Rustではrelease modeだとC/C++と全く同じでオーバーフローしてもpanicは発生せずに数値がラップしうる
例えばi32で2147483647に1を足すと普通の足し算の＋つまりadd()だと結果は-2147483648となる
これは数値計算だけでなく単なるカウンター利用に至るまで深刻な結果を招きうる
そのため足し算ならばchecked_add()等を必要に応じて使い分けることになる

**デフォルトの名無しさん** · 2022/05/09(月) 19:36:35.23

>>919
impl Foo for T where クソ長制約
vs
impl Foo for 具体的な型
という話なら多少興味もってもらえるだろうか

impl Foo for T は基本的に避けるべきだと思う

**デフォルトの名無しさん** · 2022/05/09(月) 19:43:08.06

>>922
Rust標準ライブラリでも他のクレートでもimpl Xxx for Tは山のようにある
それを避けるべきとの主張は全く意味不明

**デフォルトの名無しさん** · 2022/05/09(月) 19:44:30.54

>>918
> impl FizzBuzz for u8, u16, ...

これもう構文として取り込んだらいいのにな
impl_fizzbuzz(u8, u16, ...)
こういうのを書く文化をいっそ言語の構文に格上げして

**デフォルトの名無しさん** · 2022/05/09(月) 19:48:38.14

>>923
impl Foo for T where 制約多数って例えばどのtraitの実装？

**デフォルトの名無しさん** · 2022/05/09(月) 19:48:56.84

>>924
そういう型別impl列挙は主に基本的なTraitにおいて行われており
それらを組み合わせてTrait境界とする上位のTraitでは列挙せずfor Tで済むようにRustは上手く設計されている

**デフォルトの名無しさん** · 2022/05/09(月) 19:52:40.17

>>800では対応できていたはずのf64が>>817でCheckedAdd追加したせいで対応できなくなってるよとか指摘すればいいの？

**デフォルトの名無しさん** · 2022/05/09(月) 19:58:12.86

>>926
上位のtraitって例えばどういうもの？
それは本当にtraitにすべきものなの？
traitにすることでどういうメリットがあるの？

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

おまえらの議論が唐突すぎてよくわからない
今日の議論の発端となった今朝の書き込み>>884と元コード>>817及びそれ以降のレスには
impl … for Tなんて話は全く出てきていないぞ
ちなみにコードは以下のようになっている

> fn fizzbuzz<T>() -> impl Iterator<Item=FizzBuzzResult<T>>
> where T: Copy + PartialEq + CheckedAdd + Rem<Output=T> + TryFrom<usize>,
> {

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

たぶんだけど>>922 >>924の話は
そのfn fizzbuzz<T>() where T: Boo + Foo + Wooとトレイト境界ジェネリックにしているのを禁止して
各々fn fizzbuzz_i8()、、、fn fizzbuzz_u128()を用意すべきという主張なんじゃないか

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

>>929
>>800,804の話題を掘り起こしてしまった

**924** · 2022/05/09(月) 20:43:01.63

>>930
言葉足らずでスマソ>>924で言いたかったことは

macro_rules! impl_foo {略} // 中でimpl Foo for
impl_foo!(u8, u16, ...);
今はマクロ使って↑こうなりがちなものを
いつか言語として↓こうなったらなぁという話
impl Foo for u8, u16, ... {略}

お分かりのとおり非常にしょうもない些細な話ｗ

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

>>931
その>>800のコードは特に問題が無いのではないか
強いて言えばその後に出たいくつかの改善案を反映して

impl<T> FizzBuzz for T
where T: Clone + PartialEq + TryFrom<usize> + Rem<Output=T>
{
fn fizzbuzz(&self) -> FizzBuzzResult<&Self> {
let [zero, three, five] = [0, 3, 5]
.map(|n| T::try_from(n).ok().unwrap());
match (self.clone() % three == zero.clone(), self.clone() % five == zero) {
(true, true) => FizzBuzzResult::FizzBuzz,
(true, _) => FizzBuzzResult::Fizz,
(_, true) => FizzBuzzResult::Buzz,
_ => FizzBuzzResult::Num(self),
}
}
}

こんな感じ？

**デフォルトの名無しさん** · 2022/05/09(月) 21:07:24.73

>>919
だからこそ>>817がウンコードだと言われてるのに
わかんないかなぁ

**デフォルトの名無しさん** · 2022/05/09(月) 21:41:03.35

>>922
これはそうだな
impl Foo for Tはstdに入れるくらいのよっぽど汎用的なものでもなければ避けるべき

**デフォルトの名無しさん** · 2022/05/09(月) 21:43:33.82

>>933
それtraitにする意味ある？

>>935
FooExt もありだと思うが where T: Foo と制約はシンプルであるべき

**デフォルトの名無しさん** · 2022/05/09(月) 21:56:18.26

>>936
確かにextension traitは有りだな

**デフォルトの名無しさん** · 2022/05/09(月) 21:56:24.70

impl<T> _ for T where T: ... 形式のことを blanket implementation って言うんですね
cargo doc で型のページの下の方に出てくるのは知ってたけど、正確な定義は今知った

**デフォルトの名無しさん** · 2022/05/09(月) 22:01:11.13

>>936
元々の質問がi32など各整数にメソッドを増やしたいとの質問だったようだ
それで>>789からずっと
trait FizzBuzz {
fn fizzbuzz(&self) -> FizzBuzzResult<&Self>;
}
となっていてそれを前提に皆が話をしてる

ちなみにコードがスレへ貼られていないと検索しても出て来ずに不便だとわかったｗ

**デフォルトの名無しさん** · 2022/05/09(月) 22:24:12.66

>>939
>>804-806辺りで皆から指摘されてますやん

**デフォルトの名無しさん** · 2022/05/09(月) 22:53:43.92

>>940
そいつらは例えばイテレータメソッドを増やしたことすらない初心者かもな
Rustでメソッドを増やすにはトレイト定義が必須で欠かせない

**デフォルトの名無しさん** · 2022/05/09(月) 23:21:10.68

そもそもメソッド増やす必要ありましたか？
仮に方法だけ質問されたとしても、「やめとけ」と答えるのも回答のひとつですよ

**デフォルトの名無しさん** · 2022/05/09(月) 23:26:29.65

な、複オジ相手にしても時間の無駄だっただろ？
いい加減学習しようぜ

**デフォルトの名無しさん** · 2022/05/09(月) 23:40:12.42

>>942
メソッドを増やすべき状況は多々あります
既に出ているイテレータメソッド等もその一例です
そして今回のFizzBuzzはあくまでも例ということですからFizzBuzz自体をメソッドにするべきか否かの議論はどうでもよく無意味でしょう
メソッド化を実現できること自体の方が本質にみえます

**デフォルトの名無しさん** · 2022/05/09(月) 23:41:19.52

>>942
最初の質問者 (>>781) はまだ Rust の基礎を学んでいる途中なのだというのが前提にある。
FizzBuzz についての質問であったとしても別に FizzBuzz を書きたいわけではなかろう。
Rust を学ぶ題材として試しに FizzBuzz を取り上げてるだけだ。
だから「FizzBuzz では」やめとけというだけでは回答として不十分。
「『必要であれば』書き方はこんな感じだよ」という形で話を膨らませるのはごく普通の対応に思える。
Rust 自体に習熟してないのにその上での設計の良し悪しなんてこの段階で論じるようなことでもない。

**デフォルトの名無しさん** · 2022/05/09(月) 23:47:14.99

>>942の人は単なる反抗期なんじゃね
書き込みを見ると何でも反対してる
それでいてCheckedAddを使わずにMAXを使え！など提案が的外れ

**デフォルトの名無しさん** · 2022/05/09(月) 23:52:57.66

>>943
すみませんでした
しばらくROMります

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

>>941,944,946
これが複オジ論法
技術的な議論は無理

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

>>933
zeroのclone()は不要
他はOK
それならBigIntでも動作する

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

ひっさつ！おなにーうんこーど！

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

避けるべきというアンチパターンが出来ている時点で欠陥言語、 where T: Fooなどと書けるがRustは決してシンプルじゃない

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

Rustの目標はシステムプログラミング言語だから、C/C++に比べてマシならおーけー

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

>>951
避けるべきと言ってる人の独りよがり
根拠も示さず個人的に毛嫌いしてるだけ

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

　　　　 ,―彡 ⌒ ミ―､
　　　〈　〈|　´ん`　|〉　〉
　　　　＼　ヽ＿／／
　　　　　/　　　　　 /みんなで
　　　　 /　　　　　 /ホモセックス

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

反対！君とうんこ！君は代案コードを出さない(出せない)から無視しとけ

**デフォルトの名無しさん** · 2022/05/10(火) 11:45:10.69

>>948
あーなんか既視感あるとおもったら菅話法だw

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

>>933
Rustはそうやってシンプルに安全に多型に対応できるところがいいよな

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

>>945
なるほどこれがオナニー指向の思考回路か

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

C言語でプログラミング入門した口だけどRustみたいな関数型言語わからなくて困ってる
例えばOCamlみたいな型推論前提で書かれているコードはどの変数がなんの型になるのかわからなくてつらい思いしている
関数型言語のプログラマはみんな自分で型を推論しながらプログラミングしてるんですか？

**デフォルトの名無しさん** · 2022/05/10(火) 15:01:20.61

>>959
むしろ型推論してくれるからプログラマーは楽
ただしどこかで歯止めがある方が安全安心確実だからRustでは関数の入出力のみ明示する
それも例えば>>929の返り値のように型そのものではなく抽象的にトレイト名で記述も可能

もしある値(式)の型を知りたかったらプログラムで表示も可能だけど一番簡単なのは
let a: i32 = 値;
とデタラメな型名i32を宣言してやるとコンパイラがエラーとして正しい型名を教えてくれる

**デフォルトの名無しさん** · 2022/05/10(火) 15:32:07.15

基本的にはIDEに型を教えてもらってたけど、慣れてくると自分でどんどん型がわかるようになる

**デフォルトの名無しさん** · 2022/05/10(火) 15:58:41.10

>>959
VSCode+rust-analyzerなら変数の型やメソッドチェーンの途中の型が全部出るよ

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/10(火) 16:07:49.23

>>959
どの型に確定するのか把握しなければ使えないのだとしたら、その関数の設計が悪い。
まあ程度問題ではあるけど……。

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

>>960,962,963
ほーんなるほど
今ocaml勉強しているんだけど
if式のthen節とelse節の式の型は両方一致するとか、
match式においてもすべての分岐の式の型は一致するといかいったことを把握していってるわ
それ取っ掛かりにして関数全体の型把握するようにしたい
あと分岐の片方でラムダ抽象置いて束縛変数導入したらばもう一方の分岐ではconst関数に第一引数適用したの置いて分岐全体の型を合わせるとかいうテクニックとかも他人のソースから学んだンゴ
でも他の言語に比べてocamlのソースはなかなか転がっていない印象を受けるんごねえ
あとSKIコンビネータとかの型も式から推測するのもややこしくて難しいンゴねえ

**デフォルトの名無しさん** · 2022/05/10(火) 20:54:08.50

rust-analyzerっていえばさ
俺のVSCodeをYoutuberのと見比べると、構文間違えなどのアンダーラインが出現・消滅するタイミングが違うんだよね
Youtuberらのがリアルタイムで線が引かれているのに対して、俺のは保存しないと線が引かれたり消えたりしない・・・・しかも、俺の手元ではMacでもWindowsでも一緒の症状・・・・
誰かエスパーさんいたら解決策を教えて！！！

**デフォルトの名無しさん** · 2022/05/10(火) 22:51:55.81

>>959
Rustは関数型言語じゃないぞ

**デフォルトの名無しさん** · 2022/05/11(水) 14:05:19.94

これはやばい
https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal.html

**デフォルトの名無しさん** · 2022/05/11(水) 14:18:05.95

ヤバすぎでしょ

**デフォルトの名無しさん** · 2022/05/11(水) 14:38:17.66

Rustの弱い所を突かれたね

**デフォルトの名無しさん** · 2022/05/11(水) 15:16:16.22

>>965
俺もだわ
地味に困るんだよな

**デフォルトの名無しさん** · 2022/05/11(水) 16:13:08.26

>>965
自動セーブにする必要があるとかじゃないの？

**デフォルトの名無しさん** · 2022/05/11(水) 16:47:09.56

>>967
審査無しでユーザーが好きに登録できるパッケージマネージャにはよくありがちなことだな
パスワードが盗まれて正当なパッケージが置き換えられたわけじゃないからまだまし
Firefoxの拡張の中には第三者が権利を正当な形で引き継いだその後の更新でマルウェア化しているものがあるって報告があるくらいだし

**デフォルトの名無しさん** · 2022/05/11(水) 21:53:53.62

Rustで書くと依存crateが100オーバーになるのも珍しくないから
アプリ開発者がリリース単位で常時全部チェックするのは手間がかかりすぎる

全チェックじゃなければcargo crevとかで閾値決めとくとかしかないよね

**デフォルトの名無しさん** · 2022/05/11(水) 21:55:30.33

>>972
マルウェアというよりアクセス履歴を収集するようになったってやつでしょ

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

>>824
ホントだ
127の次でpanicした
(1_i8..).for_each(|n| print!("{n} "));
release modeではpanicではなく127の次が-128になって永久循環

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

適当に作れば溢れる前に止まる

fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: Clone + TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold((start, true), move |(n, is_first)| {
if *is_first {
*is_first = false;
Some(n.clone())
} else {
n.checked_add(&one)
.map(|new| {
*n = new.clone();
new
})
}
})
}

fn main() {
countup(1_i8).for_each(|n| print!("{n} "));
}

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

>>975
1_i8..=i8::MAXにすればいいだけ
型のMAX値までRangeFromでイテレートするなんて処理は現実のプログラムでは必要ないから

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

>>977
それは数値型にしか使えないので>>976かな

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

>>976は悪いお手本が盛り沢山
真似しちゃダメだぞ

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

Rangeをpanicしないように扱う方法ないの？
CheckedRangeみたいなやつとか

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

>>979
どのへんが問題？

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

>>978
じゃcharでやってみたら？

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

>>980
Rangeはオーバーフローしないよね？
RangeFromでオーバーフローして困るなら上限を指定しないと

スレ立てもヨロ

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

>>982
もっと厳しそうなStringで>>976をやってみた
Zの個数で数を表すZ

#[derive(Debug,Clone)]
struct Z(String);
impl std::fmt::Display for Z {
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
write!(f, "{}", self.0)
}
}
impl From<usize> for Z {
fn from(n: usize) -> Self {
Z("Z".repeat(n))
}
}
impl std::ops::Add for Z {
type Output = Self;
fn add(self, rhs: Self) -> Self {
Z(self.0.clone() + &(rhs.0))
}
}
impl num::CheckedAdd for Z {
fn checked_add(&self, rhs: &Self) -> Option<Self> {
Some(Z(self.0.clone() + &(rhs.0)))
}
}
fn main() {
countup(Z::from(1)).for_each(|n| println!("{n}"));
}

ちゃんと動作してZの数が増えて行くんだな

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

>>984
それは独自の型であってStringではないよ
上限までイテレートするのに上限が無い型を実装して何がしたいのかわからないが
countup(Z::from(usize::MAX))とかで確認した？

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

>>985
Rustのorphan ruleを知らないのかよ
独自の型に対してしか既存traitを実装できない規則なのでそこは独自の型で正しい

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

>>986
全くもって間違ってるよ
アプローチが間違ってるから>>976や>>984みたいなものしかできない

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

>>984
“Z”を繰り返したいだけなら
(1..100).map(|n| “Z”.repeat(n))でいいのに
新しい型を作って4つも5つもトレイト実装することに何かメリットあるの？

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

>>988
抽象的な考えが出来ない人なのかな
そういうのはあくまでも例であってZを表示したいわけではないことくらい分かるでしょ

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

>>976
上限のある型を作ってトレイト境界を満たしてやるとちゃんと上限で止まるんだな

#[derive(Debug,Clone)]
struct FiveBits(usize);
impl FiveBits {
fn make(n: usize) -> Option<FiveBits> {
(n >> 5 == 0).then(|| FiveBits(n))
}
}
impl TryFrom<usize> for FiveBits {
type Error = &'static str;
fn try_from(n: usize) -> Result<Self, Self::Error> {
FiveBits::make(n).ok_or("overflow")
}
}
impl std::ops::Add for FiveBits {
type Output = Self;
fn add(self, rhs: Self) -> Self {
FiveBits::make(self.0 + rhs.0).unwrap()
}
}
impl num::CheckedAdd for FiveBits {
fn checked_add(&self, rhs: &Self) -> Option<Self> {
FiveBits::make(self.0 + rhs.0)
}
}
impl std::fmt::Display for FiveBits {
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
write!(f, "{}", self.0)
}
}

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

>>980
Rangeは上限ありだから大丈夫
RangeFromならば>>976みたいなのでいいんじゃない？

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

>>985
それは君が思い込みで勘違いをしている
>>976のイテレータを見るとchecked_addが使われているため
その型に上限が有れば上限で止まるから君の言うとおり
しかしその型に上限が無ければ(リソースの有る限り)無限に進むことになる

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

>>789
> fn fizzbuzz(&self) -> FizzBuzzResult<&Self> {

その関数を使わせてもらってイテレータにしようと思ったら
参照を返しているために非Copy型に対して上手くいかなくて手詰まってしまった

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

まーた汚部屋になってきたなー