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/

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

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

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

次スレ https://mevius.5ch.net/test/read.cgi/tech/1652347700/

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

梅丸

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

梅錦

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

梅初め

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

梅おろし

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/13(金) 16:08:29.00

>>1000 なら長門は俺の嫁

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 90日 14時間 44分 13秒