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/08(日) 09:52:04.06

うんこ等の汚い単語を使うのはいつものキチガイだから無視するのがよいかと

**デフォルトの名無しさん** · 2022/05/08(日) 10:27:16.57

>>863
知らんがなw
直貼りでインデントされてるコードなんて見当たらない

**デフォルトの名無しさん** · 2022/05/08(日) 10:40:24.72

せめて技術的な話でやりあってくれめんすｗ
煽りオンリーは時間の無駄でつよ

**デフォルトの名無しさん** · 2022/05/08(日) 11:27:48.48

貼られたソースコードはクリック一つで自分の環境やplayground等に移せるようにしている
逆にplayground等に貼られたソースコードは自動引用表示してる
どちらもほぼ同じ表示となるため両派とも自由に好みのスタイルで貼ってくれて構わない

**デフォルトの名無しさん** · 2022/05/08(日) 14:12:20.46

インデント付きで表示される5chブラウザが存在するの！？

**デフォルトの名無しさん** · 2022/05/08(日) 14:46:10.02

最近はjaneでも連続半角スペースが表示されるようになってる
かなり短いコードじゃないと見にくいが

**デフォルトの名無しさん** · 2022/05/08(日) 15:16:56.45

>>868
chmate: https://i.imgur.com/LPDyEpr.jpg
Chrome: https://i.imgur.com/JUzhSQn.jpg
てか、どんなブラウザで見てんのよ

**デフォルトの名無しさん** · 2022/05/08(日) 16:00:44.57

>>870
ウンコ・オブ・ウンコを撮るあたりはさすがオナニスト

**デフォルトの名無しさん** · 2022/05/08(日) 16:41:53.28

おまえらrustfmt使ったことないのか？
クリックで1つで呼び出せるようにしてるので
インデントが崩れていようが元が変なインデントだろうが綺麗に見やすく表示できてるぞ
他者に文句を言う前に自分で技術で解決しろ

**デフォルトの名無しさん** · 2022/05/08(日) 16:41:56.65

直貼りやインデントは置いといて
コードの中身の技術的な面で何がウンコなのかを書いてくれ

**デフォルトの名無しさん** · 2022/05/08(日) 17:33:44.38

おっしゃる通り
技術的な議論だけにしていただきたい
表示問題はrustfmt自動適用

**デフォルトの名無しさん** · 2022/05/08(日) 17:54:41.31

自動適用するuserscriptなりextensionなり作ったの？

**デフォルトの名無しさん** · 2022/05/08(日) 17:55:41.35

めんどくせーから5chでシンタックスハイライトとrustfmtとコード実行できるようにしとけ

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

各自の環境に合わせて様々な対応方法があるな
Webブラウザならブラウザ拡張でもいいしブックマークレットでもよい
専ブラは多種あり各々で可不可が違うのでノーコメント
自作ブラウザなら当然楽勝
ところでrustfmtは標準入出力かファイルだが公開ウェブサービスある？
無ければhyperで作ってローカルに動かして使う

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

その次善策としてplaygroundで貼るという手法があります

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

俺はウェブブラウザで見てるけど間にサーバを挟んでいるのでrustfmtもそこで呼び出すことにする
playgroundからのコード自動引用もやりたいが貼られたURLからrustコードを取ってくるにはどうすればいい？？

**デフォルトの名無しさん** · 2022/05/08(日) 19:52:50.48

例えば>>815ならばJSON
https://play.rust-lang.org/meta/gist/c83dbaa7166545941649bb279f2162bd

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

「独りよがりの長いコードを繰り返し直貼りするな」
「見る側がフォーマットすればいいだけ」

なんじゃこの流れ
フォーマッタは汚物浄化装置じゃないぞ

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

プログラム板でコードが貼られて困る人はいないだろうけど
どうしても欲しい人はコード表示on/offボタンを付ければ良さげ
いずれにせよ各個人の好みの問題は各個人で解決すべき

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

オナニーうんコードが問題であって直貼りが問題じゃないんですよ

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

技術面に触れないと突っ込まれそうなので、>>817についての個人的な感想ですが

Tのトレイト境界に関して、数が多くなるのは仕方の無いケースもあるが、この例では単に数が多いだけでなく、
CheckedAdd等の内部実装に踏み込んだトレイトまで指定されていて、その点が良くないと思います
例えばCheckedAddを実装していなくてもFizzBuzzできる型に対して、同じ関数を使うことができない
またCheckedAddを実装しているがより効率の良いアルゴリズムで実装できる型の場合でも、この関数では効率の悪いアルゴリズムで処理するしかない
ので>>822のようにFizzBuzzできるかどうかをtraitとして持たせ、実装詳細は各型に任せるのがよいと思います

こんなことで長文書くのも馬鹿馬鹿しいね

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

>>884
その主張は全て間違い
checked addしなければオーバーフローしてプログラムが破綻するだけ
そしてchecked addはCPUレベルではオーバーフローフラグを見てるだけなのでコストゼロ
さらにCheckedAdd traitは任意の型に実装可能

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

>>885
破綻しないよww
CheckedAddに依存する必要性全くないじゃん

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

>>884
そのFizzBuzzイテレータ>>817を
checked_add()使わずに効率的にプログラミングするのは不可能だと思います

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

>>885
Wrapping<T>を使って無限に返すイテレータを返して利用者側でtakeさせる設計でもいいよね

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

>>887
checked_addを使うか否かではなく
T: CheckedAddという強い制約の必要性について聞かれてるんだと思うよ

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

Rustにおいてchecked_add (及び同等で返し方が異なるだけのoverflowing_add) は数値を扱う上でオーバーフローを起こさせないための必須の存在
そしてchecked_addは整数型ならばadd直後のCPUのoverflowフラグを見るだけだからオーバーフローを検出するために最もコストが低く済む存在
だからその手のものを素直にコーディングすれば必ず登場
そのtrait CheckedAddを使うのは違和感なく自然に思えるが他にどんな手段があると主張している？？

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

「ゼロからその型の最大値まで一個づつたどるイテレータ」
なんてもんに固執してるあたりがまずさいしょに珍妙

順序や範囲は他の理由で決定させて十分だと思う人は
イテレータとfizzbuzzをきれいに分離して考えてる

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

>>891
その件は最初にFizzBuzzの話が出てきたときに終わっていて単なる例にすぎない
話が分かりにくいならばもっと単純な例としてフィボナッチ数列イテレータでどうかな
ご存知だと思うけど足し算するだけの数列ね

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

そうか>>817が急に脈絡なくイテレータの話にし始めたのか

>>891に完全同意
適当なイテレータ持ってきて.map(fizzbuzz)でいいね
そっちはRem+PartialEqと、0と3と5を持ってくるための制約で済む、それなら自然だと思う

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

>>891
だよな
指摘を理解しないことに驚く

**デフォルトの名無しさん** · 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
どの型に確定するのか把握しなければ使えないのだとしたら、その関数の設計が悪い。
まあ程度問題ではあるけど……。