Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
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のasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part11
https://mevius.5ch.net/test/read.cgi/tech/1623857052/

**デフォルトの名無しさん** · 2021/09/11(土) 22:08:56.74

>>368
どうすれば良くなると思う？

**デフォルトの名無しさん** · 2021/09/11(土) 22:10:09.25

>>370
専用フォントを開発

**デフォルトの名無しさん** · 2021/09/11(土) 23:22:27.41

Javaより読みにくいとはさすがに思わんけど、
ジェネリクスが<>囲いなところとか、
そもそも中かっこ＋セミコロンってのもどうなんだ、とか
Haskell並にとは言わんがもうちょっとかっこ少なくかけないのか、とか
思うところはいろいろとある

**デフォルトの名無しさん** · 2021/09/11(土) 23:44:46.13

>>372
ジェネリクスが<>囲いなところ、ってメジャーなプログラミング言語のほとんどがそうだよね？

**デフォルトの名無しさん** · 2021/09/11(土) 23:48:51.34

>>373
その通りだけどあんまり筋がよくないことでもちらほらごく一部の界隈で話題になってるような

**デフォルトの名無しさん** · 2021/09/12(日) 00:05:19.01

変にRubyの影響受けてる部分は変えて欲しいなあ

**デフォルトの名無しさん** · 2021/09/12(日) 00:20:02.96

>>374
コンパイラ実装の問題なら承知した上で敢えて <> 採用してる
曖昧性の問題は turbofish で解決するなどコンパイラ実装を複雑にしない範囲で慣例的な記法に近づけている

>>375
Rubyの影響ってクロージャの記法のことかな？

**デフォルトの名無しさん** · 2021/09/12(日) 00:39:47.78

それはSmalltalkじゃないの？

**デフォルトの名無しさん** · 2021/09/12(日) 00:49:53.96

https://doc.rust-lang.org/reference/influences.html
ここによるとクロージャの記法はRuby由来

**デフォルトの名無しさん** · 2021/09/12(日) 01:31:54.94

クロージャの記法は各言語で様々だから大して気にならないけど
こう書きたいのに書けないのが悲しい

fn make_counter_closure(init: i32) -> impl FnMut() -> i32 {
　let mut counter = init;
　move || counter--
}

この件はRustやRubyだけでなくPythonやScalaやSwiftなどでも同じで
Swiftでは昔は出来たのに後から削除されたようだから最近はそういう傾向なの？

**デフォルトの名無しさん** · 2021/09/12(日) 01:35:25.37

>>378
RubyのクロージャがSmalltalk由来だからどうなんだろ

**デフォルトの名無しさん** · 2021/09/12(日) 07:25:17.64

>>379
++と―はバグの温床だからそういう傾向
Swiftから削除されたのもRustでrejectされてるのも同じ理由

**デフォルトの名無しさん** · 2021/09/12(日) 08:11:23.50

だッさw

**デフォルトの名無しさん** · 2021/09/12(日) 10:53:10.17

>>380
起源をたどればそうかもしれないけどRustが直接的に影響を受けたのはRuby

**デフォルトの名無しさん** · 2021/09/12(日) 12:43:40.70

ベストなジェネリクスの書き方ってなんだよ
Scalaみたいなのがいいの？

**デフォルトの名無しさん** · 2021/09/12(日) 14:11:08.78

Scalaみたいに[]にするのもアリだけど配列がちょっとアレになるからさすがに避けたい気がする
D言語みたいに、例えば定義時には
struct(T) Foo { foo: T }
impl(T) Foo {
fn(T) new(foo: T) { Self { foo } }
}
みたいな感じにして、使用時には
let bar = Foo!i64::new(42);
って感じにするとか・・・？
実際に書いてみるとこれはこれで微妙な気もするが

**デフォルトの名無しさん** · 2021/09/12(日) 14:19:29.99

>>379
そこは
{ let result = counter; counter -= 1; result }
または
{ counter -= 1; counter + 1 }
になるの？

**デフォルトの名無しさん** · 2021/09/12(日) 15:54:09.04

move || { counter-=1; counter }では？？？

**デフォルトの名無しさん** · 2021/09/12(日) 15:59:39.60

>>387
それは後置デクリメントになっていない

**デフォルトの名無しさん** · 2021/09/12(日) 16:29:00.55

後置であるということをそもそも認識できていなかった、やっべえ

**デフォルトの名無しさん** · 2021/09/12(日) 16:37:25.63

まさにバグの温床となりうることが示されたな

**デフォルトの名無しさん** · 2021/09/12(日) 16:48:32.00

>>385
初期Rustは [] だったけどまさに配列と被るからと言う理由で <> にした
C++と親和性のある構文を目指しているので <> 以外は採用されにくいと思う

**デフォルトの名無しさん** · 2021/09/12(日) 22:21:50.69

>>387
見ろ！Rustがゴミのようだ！

**デフォルトの名無しさん** · 2021/09/13(月) 00:58:36.15

型変数を明示しなきゃならないのは汎用プログラミング言語の欠点だよな

**デフォルトの名無しさん** · 2021/09/13(月) 01:54:16.68

何言ってんだこのバカ

**デフォルトの名無しさん** · 2021/09/13(月) 11:03:41.66

let mut counter = init + 1;
move || { counter -= 1; counter }

これが普通だと思うのは俺だけか？

**デフォルトの名無しさん** · 2021/09/13(月) 16:07:27.15

>>395
Rubyだと普通にそういう書き方するから特に違和感はないな

**デフォルトの名無しさん** · 2021/09/14(火) 21:41:07.14

配列がusizeだけなのを何とかして欲しい
i32 as usizeとかいちいち面倒

**デフォルトの名無しさん** · 2021/09/14(火) 21:52:21.64

>>397
普通に開発していればむしろusizeという別の型になってるおかげでミスなどに気付けて助かったことある人多いと思う
i32と別になっていることは非常に重要

**デフォルトの名無しさん** · 2021/09/14(火) 23:13:54.76

usizeだとうっかりマイナスにしちゃって死ぬことがある
デバッグビルドならぱにくって気づくけど、
テストすり抜けちゃうとやばい

**デフォルトの名無しさん** · 2021/09/14(火) 23:25:50.44

i32は流石にどうかと思うけど
グリッドの4-隣接とか8-隣接をforで回すときに中心からの差分で表現したくて、
isizeとusizeでガチャガチャ変換したときはちょっとウザいなーとは思った

**デフォルトの名無しさん** · 2021/09/14(火) 23:35:48.81

impl From<u16> for usize はあるのに u32 はないのが面倒
usize のサイズがプラットフォーム依存なのは分かるけど毎回 trt_from().unwap() したくない

**デフォルトの名無しさん** · 2021/09/15(水) 06:35:42.54

Rustの難しさってある程度マスターしたあとは納得の難しさなんですか？

面倒だなー。でも（メモリ安全のためには）しょうがないか～、みたいな

**デフォルトの名無しさん** · 2021/09/15(水) 07:06:01.76

バカ矯正用補助輪付言語の難しさ

**デフォルトの名無しさん** · 2021/09/15(水) 07:55:49.68

補助輪なし言語でバグなしプログラム作れたらどこに行っても採用されると思うよ

**デフォルトの名無しさん** · 2021/09/15(水) 08:36:21.78

>>401
asでいけないっけ

**デフォルトの名無しさん** · 2021/09/15(水) 09:04:47.19

>>405
asでも良いけどreleaseだとオーバーフローチェックしてくれないから心許ない
constの文脈だとunwrap使えないからas使わざるを得ないけど

**デフォルトの名無しさん** · 2021/09/15(水) 09:15:01.47

オーバーフローの懸念がある文脈ならtry_fromはしょうがないのでは
usizeがu32以上のプラットフォームだけ想定するならasでいいように思えちゃうんだけど

**デフォルトの名無しさん** · 2021/09/15(水) 09:44:19.90

asを使うとu32から別の型に変更したときに修正漏れのリスクがあるのが気になってしまう
まあfrom相当のユーティリティ関数自分で用意すれば良いか

**デフォルトの名無しさん** · 2021/09/15(水) 15:12:38.68

>>398
じゃあunsafe時には許可して欲しい

**デフォルトの名無しさん** · 2021/09/15(水) 15:24:13.77

暗黙の型変換が増えるのはやだよ

**デフォルトの名無しさん** · 2021/09/15(水) 20:24:30.93

緩く簡単に書きたい人向けの言語じゃないよね全体的に

**デフォルトの名無しさん** · 2021/09/15(水) 21:01:30.58

それはそう
緩く簡単に書けるせいで起きていた全てのバグを撲滅したい、的な執念を感じる

**デフォルトの名無しさん** · 2021/09/15(水) 21:30:37.23

IntelliJ Rust pluginの新バージョン、関数とかの補完を機械学習でやるんだってさ
すごいね
試してないけど

**デフォルトの名無しさん** · 2021/09/16(木) 00:03:22.08

誰も見ていなければ海や川でも裸で泳ぐCちゃんと
温泉の女湯でも深夜一人で水着で入るRustちゃん

**デフォルトの名無しさん** · 2021/09/16(木) 00:56:52.16

エラーハンドリング可能な形ですっきりしたルールを定義できるならやればいいんだけど
現実にそういう上手い方法がないなら煩雑でも変換の手順を書くしかない。

**デフォルトの名無しさん** · 2021/09/16(木) 01:12:36.12

低レイヤーいじる言語のエラー処理内容の粒度はそれこそプログラムごとに違うとしか言いようがない。
だから仕方ない。

**デフォルトの名無しさん** · 2021/09/16(木) 05:10:39.16

>>414
泳いでるのをDQNに見つかって乱暴されるCちゃん
そもそもDQNに覗かれるような温泉には入らないRustちゃん

**デフォルトの名無しさん** · 2021/09/16(木) 05:50:12.68

おっきしてきた

**デフォルトの名無しさん** · 2021/09/16(木) 06:27:10.25

椎ちゃんの方逝くわw

**デフォルトの名無しさん** · 2021/09/16(木) 18:55:26.69

as usize祭り絶賛開催中

unsafe fn calc(a_index: isize, b_index: isize) -> isize {
　if a_index == a.len() as isize { return 0; };
　let mut res: isize = 0;
　for i in b_index..b.len() as isize {
　　if a[a_index as usize] == b[b_index as usize] {
　　　res = res.max(calc(a_index + 1, b_index + 1) + 1);
　　}
　}
　res
}

**デフォルトの名無しさん** · 2021/09/16(木) 19:34:21.47

>>420
関数に定義されていない変数が使われまくり
forループの中に変動変数がなく毎回同じ実行
キチガイのコードを読むべきでなかった

**デフォルトの名無しさん** · 2021/09/16(木) 19:36:15.88

unsafeだしな

そして、その指摘にas usizeを擁護（容認）する意見は皆無だっていう

**デフォルトの名無しさん** · 2021/09/16(木) 19:38:22.07

あと祭り発生中の実況だったので稼働するコードではなく、

if a[a_index as usize] == b[i as usize] {
}

と修正した

**デフォルトの名無しさん** · 2021/09/16(木) 20:03:32.03

なんでunsafeなのかもわからないしなんでusizeじゃなくてisizeを受け取るのかもわからん

**デフォルトの名無しさん** · 2021/09/16(木) 20:06:54.23

ああ、aとbグローバル変数なんかこれ？

**デフォルトの名無しさん** · 2021/09/16(木) 20:47:15.02

引数がマイナスになることもあるので条件判断の必要からisizeなんだよね
もしusizeを引数にするとしても、引数に渡すところでisize as usizeになるので、やっぱりusize祭りが大発生

お祭りワッショイワッショイ

**デフォルトの名無しさん** · 2021/09/16(木) 21:30:12.52

引数がマイナスになるならチェックしないと範囲外アクセスするだろ馬鹿か？

**デフォルトの名無しさん** · 2021/09/16(木) 22:25:53.04

今どきIndex使って回すとか化石脳かよ

**デフォルトの名無しさん** · 2021/09/16(木) 22:48:14.07

ボロクソワロタ

**デフォルトの名無しさん** · 2021/09/16(木) 23:11:45.54

>>425
グローバル変数を使うのはありえないな
staticは使ってもモジュール内に閉じ込める
どの言語でも常識

**デフォルトの名無しさん** · 2021/09/17(金) 01:14:24.53

グローバル変数小文字にしたら警告出なかったっけ

**デフォルトの名無しさん** · 2021/09/17(金) 03:56:57.86

そもそもusizeで受け取って呼び出し側でケアすべきやろ

**デフォルトの名無しさん** · 2021/09/17(金) 13:27:45.55

>>412
経験的に、縛れば縛るほど最終的にはラクできるようなのを皆知ってると思う
ラクに書けるような言語は一見いいのだが
人間が生まれ持って自堕落であるのを伴って
最終的には苦しみをもたらすことになるコードを書いてしまう

**デフォルトの名無しさん** · 2021/09/17(金) 15:13:45.88

>>420も煽りのつもりで普段書いてないrustを
イキって書いたんだろうけど
煽り返された上にクソコードが掲示板に一生残るのは辛いよなあ

**デフォルトの名無しさん** · 2021/09/17(金) 15:20:07.79

3歩あるけば忘れるからヘーキヘーキ

**デフォルトの名無しさん** · 2021/09/17(金) 16:32:00.60

いきなり unsafe fn とか書いてるあたり普段からrust書いるが競プロとかでついた変な癖を引きずってる人だと思う
余計悪いが

**デフォルトの名無しさん** · 2021/09/17(金) 17:02:49.25

>>420
これって何するコードなの？

**デフォルトの名無しさん** · 2021/09/17(金) 18:51:16.87

>>437
ゴミカスコード力を披露するコードだよ
Rustどうこう言うやつはこのレベルが多い

**デフォルトの名無しさん** · 2021/09/17(金) 20:36:20.90

usize祭り絶賛発生中

while !next_pos.is_empty() {
　let mut tmp_next_pos: Vec<(i32, i32)> = Vec::new();
　for &(n_yr, n_xc) in &next_pos {
　　map[n_yr as usize][n_xc as usize] = 2;

　　for (a_yr, a_xc) in around(n_yr, n_xc) {
　　　if a_yr >= 0 && a_yr < m_yr + 2 && a_xc >= 0 && a_xc < m_xc + 2 {
　　　　if map[a_yr as usize][a_xc as usize] == 0 {
　　　　　map[a_yr as usize][a_xc as usize] = 2;
　　　　　tmp_next_pos.push((a_yr, a_xc))
　　　　}
　　　　if map[a_yr as usize][a_xc as usize] == 1 {
　　　　　total += 1;
　　　　}
　　　}
　　}
　}
　next_pos = tmp_next_pos;
}

**デフォルトの名無しさん** · 2021/09/17(金) 21:04:31.14

>>439
しつこいなw

**デフォルトの名無しさん** · 2021/09/17(金) 21:09:35.15

isize ってどういう時に使います？
添字は基本的に usize しか使いませんし符号付き整数が欲しくなったらi32かi64で大体事足りるのでいまいち使い所が分かってません

**デフォルトの名無しさん** · 2021/09/17(金) 21:43:47.45

添え字に使う値を算出する途中計算で負数が必要になったら isize が妥当という場合もある。

**デフォルトの名無しさん** · 2021/09/17(金) 21:44:59.72

can isize and usize be different in rust?
Can isize and usize be different? Both of them can be used for memory size, index, offset.
Since usize is used for arrays why don't we just have usize
I am new to Rust so this might be a basic question.

・usize cannot be negative and is generally used for memory addresses, positions, indices, lengths (or sizes!).
・isize can be negative, and is generally used for offsets to addresses, positions, indices, or lengths.

https://stackoverflow.com/questions/55506647/can-isize-and-usize-be-different-in-rust
意識高い系がウンコードを量産し罵倒するクソスレ

**デフォルトの名無しさん** · 2021/09/17(金) 21:45:51.61

そして、その結果、as usize祭りにもなる場合もある

**デフォルトの名無しさん** · 2021/09/17(金) 21:51:17.48

>>432
経験的に縛れば縛るほど脱法行為が横行する。

**デフォルトの名無しさん** · 2021/09/17(金) 22:20:51.81

RustlingsをReplitで動かして学習したいのですが、これってrustlingsコマンドはどうやって動かすのですか？
https://github.com/rust-lang/rustlings
公式サイトが用意しているReplitの環境で学習をやりたいのです

よろしくお願いします

**デフォルトの名無しさん** · 2021/09/17(金) 23:24:24.54

>>446
ReplitのRustのバージョンが古くて(1.44）ビルド失敗するっぽい
見た感じローカルでやるのとそんな変わらん気がするから、
こだわりないならローカルでやるのが吉
この環境ビルドむっちゃくちゃ遅いし

**デフォルトの名無しさん** · 2021/09/17(金) 23:26:48.18

>>439
なぜそんなに下手なの？
配列のインデックスを取り出して配列をアクセスしてるだけなら
そのインデックスは最初からusize型にしておくだけてしょ

**デフォルトの名無しさん** · 2021/09/17(金) 23:34:57.92

>>445
脱法行為もなにも>>420のコードで負のindex渡されたらおかしくなるやんけ

**デフォルトの名無しさん** · 2021/09/17(金) 23:57:58.10

とはいえasﾅﾝﾄｶが一部のシチュエーションでめんどくさくなることはある（主に競プロ）

let (h, w) = (100usize, 100usize); // 多くの箇所ではusizeとして扱っている
let grid = vec![vec![0; w]; h]; // 横幅w 縦幅h 左上のマスの座標(0,0)のgrid

// 省略（なんかいろいろやる）

let (x, y) = some_func(); // 着目対象となるgridのマスの位置を(usize, usize)で取得

// (x, y)の上下左右のマスを対象になにかやる
for &(dx, dy) = &[(1i32, 0i32), (-1, 0), (0, 1), (0, -1)] {
let (x2, y2) = (x as i32 + dx, y as i32 + dy);
if x2 < 0 || x2 >= w as i32 || y2 < 0 || y2 >= h as i32 {
continue; // x2,y2がgridからはみ出してたら処理飛ばす
}
let (x2, y2) = (x2 as usize, y2 as usize); // できるだけusizeで処理したいので
// 省略（x2, y2を使っていろいろやる）
}

上下左右調べたいときに負の値が出てくるのがめんどくさい

一応workaroundはあって、for以下をこうする手がある
!0が2の補数的には-1として扱えるのでオーバーフローOKな足し算をする

for &(dx, dy) = &[(1usize, 0usize), (!0, 0), (0, 1), (0, !0)] {
let (x2, y2) = (x.wrapping_add(dx), y.wrapping_add(dy));
if x2 >= w || y2 >= h {
continue; // x2,y2がgridからはみ出してたら処理飛ばす
}
// 省略（x2, y2を使っていろいろやる）
}

**デフォルトの名無しさん** · 2021/09/18(土) 00:02:40.07

競技プログラミングは
正しいプログラミングスタイルから離れていく悪です
競技プログラミングスタイルな人と一緒に開発したい人は存在しないでしょう

**デフォルトの名無しさん** · 2021/09/18(土) 00:04:38.74

正当なスタイルが分かった上で競技としての割り切り方も分かっているなら問題ないんだけど、
競技から学ぶと変な癖が付きやすいというのは私も感じるなぁ。

**デフォルトの名無しさん** · 2021/09/18(土) 00:15:51.96

>>441
off_tとかptrdiff_tの代わり
例えば <*const T>::offset なんかはisizeを引数に取る

**デフォルトの名無しさん** · 2021/09/18(土) 00:21:57.18

>>450
自分はだいたい座標やwidth/heightはi32で扱って
indexへの変換処理を関数に抽出してそこでusizeに変えてる
一次元配列に二次元データ入れるときも自然に書ける

**デフォルトの名無しさん** · 2021/09/18(土) 01:57:08.86

type off_t = i64;(64bitOS)だからisizeを使うという発想は分かる。
でも厳密にはRustにNonZeroなどがある以上は、"本来は"実装されたfnが正常に動作する数値範囲があり
プリミティブ型で数値範囲を再定義し型定義出来ると便利だけど…、Type Aliasがあるのに無いのが辛い。
別言語の例
type Natural = range[0 .. high(int)]
type RegisteredPort = range[1024..49151, int]
type SomeSignedInt = int | int8 | int16 | int32 | int64
反対だ、コンパイルが遅くなるだけだという意見も絶対に認めない！もあるが、上記のNonZeroなどを見ると
将来的には実装されるのではなかろうか、いやヌルポインタ最適化のためのNonZeroだから入らないのでは？
という意見も分かるが…
またas演算子でキャストは安全だという話だが、符号付きから符号無しへの変換は、当然、どういう結果に
なるかを知っているべきだが、基本的な事をすっ飛ばす人も多いし、負を許容するoffsetが明確かどうかは
コードをすべて追わないと分からない場合が多い。なおこれが出来ると、コード中のキャスト変換が減るので
動作も早くなると思われるし、fnにした時の引数チェックも行わなくても良い状況が期待できる。
現実的に今のバージョンならindexもoffsetもisizeで作り、負を許容できない所にチェックを入れるだけで
as usizeは使わなくて良い箇所なら使わない。

**デフォルトの名無しさん** · 2021/09/18(土) 09:35:47.96

>>450
let mut test = 100_usize;
アンダースコア使うと読みやすいぞ。おぬぬめ

**デフォルトの名無しさん** · 2021/09/18(土) 11:21:13.85

winitのmasterでstdwebのサポートが切られてweb_sysに一本化されていた
stdwebってオワコンになりつつあるのかな？

**デフォルトの名無しさん** · 2021/09/18(土) 17:05:43.72

>>455
NonZeroはOptionとかのサイズ最適化やポインタの値がnullでないことを示すのが主目的なので
汎用的な範囲を組み込み型で示すのはちょっと違うかと
必要ならnewtypeパターンで自分で作ればよい

**デフォルトの名無しさん** · 2021/09/18(土) 17:29:18.29

配列がusizeなのはpythonなんかのa[-1]の最後尾アクセスを見てると、なぜそんな言語仕様にしたのかと
off_tなんかを見ると不思議に思う。いずれも Index bounds checkが掛るのに。符号無し64bitの巨大な
配列が欲しかったから？でもi128とかあるし

**デフォルトの名無しさん** · 2021/09/18(土) 17:47:44.01

インデックスiが実行時に決まるとき
配列のアクセスを内部的には *(p + i) にしたかったからじゃないかな
マイナスのとき～っていう分岐をそこに入れずに最速でアクセスしたかったと

**デフォルトの名無しさん** · 2021/09/18(土) 18:02:33.71

>>459
>符号無し64bitの巨大な配列が欲しかったから？
配列にマイナスの値は使わないんだから、そのぶんMAXの数を増やしたほうが
オーバーフローしにくいから安全だろってことらしい

でもどうせi32 as usizeとかi64 as usizeするから意味ないんですけどね！

**デフォルトの名無しさん** · 2021/09/19(日) 12:46:43.77

>>451
ほんそれ
めっちゃ判る

**デフォルトの名無しさん** · 2021/09/19(日) 12:55:45.99

>>459
32bit環境だとisizeにするとbyte配列が2GBくらいしか扱えないからじゃないのかね
ついでに一応16bit環境もサポートしてるみたいだし

**デフォルトの名無しさん** · 2021/09/19(日) 15:08:42.28

競プロの書き方を仕事でするわけないだろ
何言ってるんだ

**デフォルトの名無しさん** · 2021/09/19(日) 22:06:10.71

してるバカがいるから言ってんだよバカ。

**デフォルトの名無しさん** · 2021/09/19(日) 22:13:07.84

矯正してやれ

**デフォルトの名無しさん** · 2021/09/19(日) 22:58:17.41

アホか
競プロと仕事、書いてる時間がどっちが長いと思ってる
競プロは趣味　仕事で書いてるほうが圧倒的に長い
競プロでの書き方が仕事に引きずられることがあっても逆はない

そういうヤツがいるとか嘘をついてまで、
競プロに難癖つける理由がまったく理解できんわ

**デフォルトの名無しさん** · 2021/09/19(日) 23:07:40.22

お前が競プロスタイルで仕事するかどうかの話じゃないし、競プロに難癖つけてもいない

**デフォルトの名無しさん** · 2021/09/19(日) 23:52:05.14

競プロRustスレを専用に立てて分離するのがベストな解決かな。
大多数を占める普通のRustプログラミングをする人たちにとっては役に立たない、特殊な競プロのコーティング方法が書かれても、批判議論に陥りがちでお互いにメリットないと思うのです。

**デフォルトの名無しさん** · 2021/09/19(日) 23:53:50.32

難癖つけてるだろ

> 競技プログラミングは
> 正しいプログラミングスタイルから離れていく悪です

からの流れだからな