Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

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

※次スレは原則>>980が立てること

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

**デフォルトの名無しさん** · 2021/12/06(月) 17:09:45.91

>>248
型パラメータは Option のパラメータなので順当に考えれば Option::<i32>::None と書くべきだし実際にそれで通るんだけども、
歴史的経緯でバリアントにも付けられるようになってる。

短く書けるから習慣的にはバリアントに型を付けるほうが多いかな……？

**デフォルトの名無しさん** · 2021/12/06(月) 17:31:38.25

>>250
なるほど直積集合かぁ
同じくyのイテレータとxはCloneを要求してますね
fn cartesian_product<J>(self, other: J) -> Producfgt<Self, J::IntoIter>
where
　Self: Sized,
　Self::Item: Clone,
　J: IntoIterator,
　J::IntoIter: Clone,

**デフォルトの名無しさん** · 2021/12/06(月) 20:06:32.13

>>249
> Ok::<(),std::io::Error>(())とか

正直見たことなかったです

>>252
> 歴史的経緯でバリアントにも付けられるようになってる。

（´･∀･`）ﾍｰ
そういうわけなんですね

**デフォルトの名無しさん** · 2021/12/06(月) 21:47:08.33

>>254
例えばlet x = spawn(async { ... });して裏で何か処理をやらせといた結果を
後でもしエラーが出ていたら進めちゃいけないタイミングでx.await?;で確認するわけだけど
spawnが返す型をxに律儀に記述するのは面倒なのでそこは略すとして
asyncブロック内で?とOk(())だけ書くとコンパイラが文句を言うので仕方なく記載

**デフォルトの名無しさん** · 2021/12/06(月) 22:11:44.75

なるほど勉強になりました

**デフォルトの名無しさん** · 2021/12/07(火) 21:26:04.18

12次元までならiproduct!が使える
use itertools::iproduct;
let r = iproduct!(1..100, 1..100).find(|(x, y)| x * y > 1234);
let r = (|| {
　for (x, y) in iproduct!(1..100, 1..100) {
　　if x * y > 1234 {
　　　return Some((x, y));
　　}
　}
　return None;
})();

**デフォルトの名無しさん** · 2021/12/08(水) 14:18:48.01

ARM版のWindowsでRustのコードを書くのってめんどくさいな
生のWindowsで使用する場合、VisualStudioに付属するx86用のリンカーが非推奨警告を無視すれば使えたものの、次期バージョンからx64専用になってしまうっぽい
一方、仮想環境等+VSCodeでは、RustAnalyzer等が機能せず苦労する・・・・
持ち運び用にケチってMacを買わなかったのが大問題だった、なんかいい方法ないのかな？そもそもARM Windowsで動くリンカーってVisualStudio付属のものしかないのかな？
ケチったって言ってもよくよく考えてみると大して金が浮いてもないし、変なもん買っちまった

**デフォルトの名無しさん** · 2021/12/08(水) 14:36:22.94

>>258
i686ターゲットのバイナリをバイナリ変換で動かしてるってこと？
aarch64-windowsターゲットとARM用のリンカ使えばネイティブのARMバイナリできるんじゃないかと思うけど

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

バイナリバイナリルルルルルー。

**デフォルトの名無しさん** · 2021/12/08(水) 21:25:01.32

rustはどんどん新しい機能が追加されていくのはいいけど、
後方互換性を気にして過去に追加された「間違った」機能を削除するという
思い切ったこともやって欲しいな

これまでの言語は後方互換性にとらわれて滅茶苦茶になってるから

**デフォルトの名無しさん** · 2021/12/08(水) 21:29:04.83

>>261
C++かな？

**デフォルトの名無しさん** · 2021/12/08(水) 21:44:15.05

>>261
editionでは物足りない？

**デフォルトの名無しさん** · 2021/12/08(水) 21:50:49.56

実際2021editionではレンジパターンの ... が削除されて ..= に一本化された

**デフォルトの名無しさん** · 2021/12/09(木) 08:53:14.94

>>258
今どきDocker使うのはデフォだから何の問題もない、因みにRustAnalyzerも使える
使えないのは、復数のプロジェクトが見える状態にしてるから
今どき復数ウィンドウ立ち上げても何の問題もない、ルートフォルダを固有にしたら解決
つまり、調査不足が原因

**デフォルトの名無しさん** · 2021/12/09(木) 10:59:17.60

ARM は安物のイメージがある。
WSL2, Linux, Docker, VSCode とか使えるのかな？

Mac も、M1 に変わったから

**デフォルトの名無しさん** · 2021/12/09(木) 11:10:00.09

原理的には ARM のほうがインテル系 (もはや AMD 系と呼ぶべきか) よりも高速化できる可能性があるとは言われている。
今以上に回路を細かくするのは無理というところまできてしまっているのでアーキテクチャのほうで見直しが必要なんだが
インテル系は互換性が足かせになってしまっていてあまり思い切ったことが出来ない。

現時点はインテル系向けにチューニングされたソフトウェア資産が多いから上手くいっているけど将来もそうとは限らない。

**デフォルトの名無しさん** · 2021/12/09(木) 11:45:18.26

>>267
スレチだけどその話の出展あったら教えてほしい

**デフォルトの名無しさん** · 2021/12/09(木) 14:22:31.39

CISCRISCの話じゃなくてメモリモデルの話ならそうかなって思う
今のx64って実質中身RISCって聞いたことあるし
Rustで言うとx64では全部SeqCstとして扱われるみたいな話

**デフォルトの名無しさん** · 2021/12/09(木) 17:42:03.96

リソースの話だけなら命令デコーダーとか？
x86_64は拡張や互換性とか可変長命令だったりで無駄にトランジスタ消費するのが電力性能比的に足かせみたいな

**デフォルトの名無しさん** · 2021/12/09(木) 20:39:08.00

今どきのプロセッサだと分岐予測器やキャッシュが支配的でデコーダなんて誤差だと思う
あと可変長は命令側の帯域やキャッシュ効率が良くなるという面もあってRISC系でも採用してることが多い
結局両者とも長年の改善で似たようなとこに落ち着いてるわけで、ISAが違うからどうこうみたいな話は結構眉唾

**デフォルトの名無しさん** · 2021/12/11(土) 19:08:58.23

こういうことをしたいのですがコンパイルエラーとなってしまいます
const DEFAULT_NAME: &str = "namae";
let arg1: Option<String> = std::env::args().nth(1);
let name: &str = arg1.map_or(DEFAULT_NAME, |s| s.as_str());
どう直せばよいでしょうか？

**デフォルトの名無しさん** · 2021/12/11(土) 19:10:55.89

namaeじゃなくてnameな
aが余計
この程度の英語のスペル書けないとかプログラミング向いていないしやめた方がいいよ

**デフォルトの名無しさん** · 2021/12/11(土) 19:21:25.94

自演ボケか？

**デフォルトの名無しさん** · 2021/12/11(土) 19:35:01.57

>>272
そのままだとarg1が消費されてなくなるのに参照だけ残ることになるからエラー
Stringで受ければいいよ
let name: String = arg1.unwrap_or(DEFAULT_NAME.to_string());

**デフォルトの名無しさん** · 2021/12/11(土) 20:19:05.99

>>273
すげーな。してはいけないレビューの典型例じゃねーか。
すげーな

**デフォルトの名無しさん** · 2021/12/11(土) 20:24:40.06

いやネタでしょ

**デフォルトの名無しさん** · 2021/12/11(土) 20:29:51.18

>>275
これだとarg1がSomeの時もto_string()が呼び出されて無駄なヒープアロケーションが走るのでunwrap_or_elseにすべき

**デフォルトの名無しさん** · 2021/12/11(土) 22:35:07.46

みなさんありがとうございます
Stringにする方法は無事にこれで動きました
let name: String = arg1.unwrap_or_else(|| DEFAULT_NAME.to_string());
元の質問>>272のように&strにする方法は無いのでしょうか？
もし可能ならばto_string()のヒープアロケーションを減らせるかなという質問です

**デフォルトの名無しさん** · 2021/12/11(土) 22:59:59.99

>>279
Cowかな
let name: Cow<str> = arg1.map_or(Cow::Borrowed(DEFAULT_NAME), |s| Cow::Owned(s));

**デフォルトの名無しさん** · 2021/12/11(土) 23:20:49.43

場合によってはこれでもいいのかな？
let name: &str = &arg1.as_ref().map_or(DEFAULT_NAME, |s| s.as_str());

**デフォルトの名無しさん** · 2021/12/11(土) 23:54:40.62

>>281
それでもよいけど正解はシンプルなこれ
let name: &str = if let Some(ref arg1) = arg1 { arg1 } else { DEFAULT_NAME };
まずarg1を消費しないようにrefで受ける
2代目のarg1は&Stringなので自動的に&strへderefされる

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

1.40からas_derefっつうのがあるんだってさ
let name = arg1.as_deref().unwrap_or(DEFAULT_NAME);

でもコマンドライン引数の場合は消費しないメリットがほぼ無いのでCowのほうがいいかな

**デフォルトの名無しさん** · 2021/12/12(日) 04:28:54.46

どの型で統一すべきかは
(1) その後に加工伸長などするならString　(arg1をここで&strに統一するのは無駄)
(2) 参照するのみなら&str　(DEFAULT_NAMEをここでto_stringするのは無駄)
(3) その後に判明する条件次第で両ケースありうるならCow　(ただし常にCow利用はCowコストが無駄)
って感じ？

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

おそらくその通りだけど、CLIツールの初回一回だけのアロケーションにそこまでこだわるのがそもそも無駄って気もする
ループ内とかでもなければ雑にString作っちゃっていいかもね

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

んだ

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

>>285
今回のケースはそうだね
ただしヒープ割り当てをなるべく避ける様々な手法を把握しているか否かは色んな局面で効いてくるから
今回6通りも動くコード例が示されたことは多様に対応可能な柔軟性の良さかな
気にしなくても書けるし気にすれば効率を上げることができる点で

**デフォルトの名無しさん** · 2021/12/12(日) 18:38:25.33

>>284
Cowと&strに揃える場合の一番の違いはライフタイム管理
Stringを&strにするとライフタイム管理がつきまとうから
すぐ使いきる場合以外はCowに比べてメンテナンスしにくいコードになる

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

文字列についてはStringにするかCow<str>にするか迷うくらいならinternしちゃうのも手かと
どのライブラリが定番なのかよく知らないけど

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

>>281
> let name: &str = &arg1.as_ref().map_or(DEFAULT_NAME, |s| s.as_str());

それarg1の前の&は不要でこれで動く
let name: &str = arg1.as_ref().map_or(DEFAULT_NAME, |s| s.as_str());

さらにas_str()使うより短く書けて&**sで&strになる
let name: &str = arg1.as_ref().map_or(DEFAULT_NAME, |s| &**s);

さらに&Stringのsのままでもderefされるため大丈夫
let name: &str = arg1.as_ref().map_or(DEFAULT_NAME, |s| s);

クロージャが何もしてないからといって無くしてしまうとderefが効かず型不一致コンパイルエラー
× let name: &str = arg1.as_ref().unwrap_or(DEFAULT_NAME);

そこで明示的にderefしてやればよい
let name: &str = arg1.as_deref().unwrap_or(DEFAULT_NAME);

**デフォルトの名無しさん** · 2021/12/13(月) 21:23:25.03

ken okabeのqiitaの記事がまた炎上してるよ
mod_poppoにボコボコにされてる

**デフォルトの名無しさん** · 2021/12/13(月) 22:30:34.09

あれ、Qiitaには垢バンされて投稿できないんじゃなかった？

**デフォルトの名無しさん** · 2021/12/13(月) 23:00:30.90

ググってもよくわからないのですが、どういった方なんですか？

**デフォルトの名無しさん** · 2021/12/13(月) 23:30:17.26

盛大な時間の無駄になるだけなので調べてはいけない

**デフォルトの名無しさん** · 2021/12/13(月) 23:59:51.20

>>291
poppoとかいうやつも多様な定義や多様な解釈が存在している中で不要なイチャモンばかりだな
さらに冒頭のこれも

> JavaScriptで演算子オーバーロードを実現しようとするのは筋が悪い

たまたま例としてJavaScriptを用いているだけなのにそれすら理解できていない
okabeは使用言語と無関係に成り立つ話をしてるだろ

> reduceは二項演算ではなく三項演算として捉えるべき

これも些細なことであって例えばRustなら
fold()は『入力列・初期値・演算関数』の三項演算だけど
reduce()は『入力列・(初期値は入力列の先頭なので無指定)・演算関数』の二項演算

とはいえokabeの方もイテレータすら扱っていないからイマイチ

**デフォルトの名無しさん** · 2021/12/14(火) 00:07:08.47

Rust関係ねーだろ
二度とその名前を口に出すな

**デフォルトの名無しさん** · 2021/12/14(火) 10:41:11.49

P2P方式の2D対戦ゲームを作りたいと考えています。
おすすめのゲームエンジンやライブラリはございますか？

**デフォルトの名無しさん** · 2021/12/14(火) 11:46:02.04

>>297
あくまでゲームを作ることが目的なんだったら普通にUnityとかでいいんじゃない？
どうしてもRust使いたいならサーバー側で使えばいい

**デフォルトの名無しさん** · 2021/12/14(火) 12:45:44.37

>>298
個人的にRustが好きなので技術向上のためにもRustで作りたいと考えています。
現在はAmethystとlibp2pを用いて開発しようと考えているのですが、如何せん知識が浅くこれで目的のものが作れるのか分かりません。
是非先人の知恵をお貸しください。
Rustでの開発にロミオとジュリエットの恋ほどの壁があるという場合は、大人しくC++かUnityで作成します・・・

**デフォルトの名無しさん** · 2021/12/14(火) 13:10:49.68

そんだけの情報ではなんともいえん。

見通しが立たないものを試行錯誤で作る場合には
モジュールではなくレイヤで分割したほうがいいという考え方がある。
要するに機能不足でもバグだらけでもコードが整理されてなくてもいいからとにかく「動くもの」を作って
その上に足りないものをどんどん足していくという方法論だ。

よくわかってないなら小さいもので色々やってみて知識を積み重ねるべきで、
よくわからんまま目的に向かって邁進してもあんまり技術向上にはならんよ。

**デフォルトの名無しさん** · 2021/12/14(火) 13:22:32.10

>>300
ありがとうございます
色々試してみます

**デフォルトの名無しさん** · 2021/12/14(火) 13:53:41.90

>>299
Amethystは開発中止になったから今からやるのは微妙かも
gamedev.rsに今アクティブなエンジンやゲームがスクショ付きで載ってるから
そこからイメージにあうものを探すといいかもしれない

**デフォルトの名無しさん** · 2021/12/14(火) 15:30:19.02

>>302
そうだったんですね・・・
時間は掛かるかもしれませんが、色んなものを試して自分に合う物を探すことにします

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

技術を高める目的なら windows-rs や wgpu-rs みたいな一段下から積み上げるのも楽しいよ。

ゲーム作る道のりは遠くなるけど、画面に三角形出したり、キーの入力受け付けたりするだけで達成感が出てくる。

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

https://forest-watch-impress-co-jp.cdn.ampproject.org/c/s/forest.watch.impress.co.jp/docs/serial/yajiuma/1374/986/amp.index.html
エディタ自体はvscodeに勝つの難しそうだがGPUIとやらが定番GUIフレームワークにならないか期待

**デフォルトの名無しさん** · 2021/12/17(金) 16:39:33.05

既出だったらすいません
前から疑問だったのですが、出力におけるprint!マクロのような入力用マクロが標準ライブラリに用意されていない理由ってなんですか？

**デフォルトの名無しさん** · 2021/12/17(金) 18:11:01.90

>>297
1対多で、broadcast するチャットルームのバックエンドなら、
Ruby on Rails 6 のAction Cable(WebSocket)が基本

JavaScript は、React, Phaser とか

【Rails】（送信時のリロード無し！）Action CableでSlack風チャットアプリを作成、2019/12
https://www.youtube.com/watch?v=o6PuxDr8Meg

**デフォルトの名無しさん** · 2021/12/17(金) 18:36:09.20

>>306
この辺読んで
https://github.com/rust-lang/rust/pull/75435
https://github.com/rust-lang/rfcs/pull/3196

**デフォルトの名無しさん** · 2021/12/17(金) 23:52:56.58

>>308
熟読させていただきました。
私としてはたった数十行のコードであること且つ他のほとんどの言語に存在しているものなのであっても良いのかなと思ったのですが、Rustの基本理念を考えると慎重になる理由も理解出来ました。
Rustの経験が浅い私目線ではあまり腑に落ちませんでしたが、皆さんはどう考えていますか？

**デフォルトの名無しさん** · 2021/12/18(土) 15:05:52.37

熟読はしてないけど、外部ライブラリで簡単に実現可能であるなら
直感的には、本体メンテナの苦労を増やすほど価値があると思えないし別にいらんかな

こういうIOとかCLIプロンプトらへんの機能ってどうしても好みが分かれるというか、
ユースケースによって必要な機能がかなり違ってきちゃうと思うし

**デフォルトの名無しさん** · 2021/12/18(土) 20:46:47.80

C++のiostreamが失敗作だから慎重になるのもわかる笑

**デフォルトの名無しさん** · 2021/12/18(土) 23:17:58.09

>>306
C言語でのprintf相当はあるのにscanf相当がstdにないのはなぜか？ですね
逆になぜprintf相当がRustの標準ライブラリにあるのか？を考えてみると

(1) 読み書きの非対称性
人間が読むためにプログラムが書くことはエラー表示を含めて利用必須かつ頻出
一方で人間が書いたものをプログラムが読むことはレア
ファイルや通信相手への読み書きは各プロトコル/各API/シリアライズ等で対象外

(2) コンパイラサポート
print!やformat!等は頻出するので効率面からコンパイラサポートが効率的
実際にそれらが利用しているformat_args!はコンパイラ内蔵マクロ

(3) 標準ライブラリ採用
外部ライブラリで実現可能なものは採用しないが基本
今回はコンパイラ内蔵マクロだから採用

つまり出力は頻度と効率化で採用がクリアされたけど
入力は外部ライブラリで十分かなと

**デフォルトの名無しさん** · 2021/12/19(日) 02:25:28.05

しかし競プロでみんなproconioとかいう謎の専用ライブラリ使ってるの見た目悪すぎて笑える

**デフォルトの名無しさん** · 2021/12/19(日) 04:21:35.56

競プロ全然知らないけどstdinに入力数値がくるからか

| 入力は以下の形式で標準入力から数値が与えられる。
| a b c d e
| 積が奇数なら Odd と、偶数なら Even と出力せよ。

標準ライブラリだけ使うと毎回こんなの書くのは面倒だもんな

| use std::io::{stdin, BufRead, BufReader};
| println!("{}", if BufReader::new(stdin()).lines().next().unwrap().unwrap().split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0) { "Even" } else { "Odd" });

>>313
そのproconioを使うとこうなるようだ

| proconio::input! { v: [isize; 5] }
| println!("{}", if v.into_iter().any(|n| n & 1 == 0) { "Even" } else { "Odd" });

**デフォルトの名無しさん** · 2021/12/19(日) 06:54:36.03

>>314
ワンライナー大好きかよ

**デフォルトの名無しさん** · 2021/12/19(日) 07:00:31.55

>>315
マルチラインだと標準ライブラリだけでもわかりやすくなる？

**デフォルトの名無しさん** · 2021/12/19(日) 08:28:47.39

>>316
あいやごめん。proconioのところはどうあがいてもプロコン専用のproconioが一番見やすいよ。それ用に特化されたライブラリだし
俺が大好きかよって言ったのは
println!("{}", if v.into_iter().any(|n| n & 1 == 0) { "Even" } else { "Odd" });
の部分

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

どの言語でも三項演算子(相当)はワンライナーで書くんじゃね？

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

見た目汚いなw

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

これでいいかね？
println!("{}", if v.into_iter().any(|n| n & 1 == 0) {
　"Even"
} else {
　"Odd"
});

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

俺ならこんな感じかなあ
俺は頭悪いから、途中結果に一つ一つ名前つけないとわかんなくなっちゃうわ
まあワンライナー見た時に「グエー」って思っただけだからごめん。「大好きかよ」とかいっておいてなんだけどあんま気にしないで

use proconio::input;

fn main() {
input!(v: [usize; 5]);
let is_even = v.iter().any(|x| x % 2 == 0);
let result = if is_even {
"Even"
} else {
"Odd"
};
println!("{}", result);
}

**デフォルトの名無しさん** · 2021/12/19(日) 10:13:36.41

>>321
なるほど
じゃあ最初の標準ライブラリのみはどのように分けるのかな
println!("{}", if BufReader::new(stdin()).lines().next().unwrap().unwrap().split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0) { "Even" } else { "Odd" });

**デフォルトの名無しさん** · 2021/12/19(日) 10:17:01.07

>>322
proconio使うｗ
Rustで競プロするにはIOごときに専用ライブラリ使うことになってなんかなあって思うけど、そう思いながら使う

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

>>315
ワンライナーやクロージャでまとめて書くと所有権やライフタイムの問題が出にくいんだよ
他の言語と違ってRustで適切に分割して読みやすく書くのは初心者には難しい

**デフォルトの名無しさん** · 2021/12/19(日) 13:44:27.43

わけわからんくてビビってたらよく見るとPythonスレじゃなかった

**デフォルトの名無しさん** · 2021/12/19(日) 15:04:40.83

rustfmt使うでしょ普通

**デフォルトの名無しさん** · 2021/12/19(日) 21:36:12.89

>>326
println全体が改行されてしまった

println!(
　"{}",
　if BufReader::new(stdin())
　　.lines()
　　.next()
　　.unwrap()
　　.unwrap()
　　.split(' ')
　　.any(|s| s.parse::<isize>().unwrap() & 1 == 0)
　{
　　"Even"
　} else {
　　"Odd"
　}
);

一方で分割するとこうなった

let cond = BufReader::new(stdin())
　.lines()
　.next()
　.unwrap()
　.unwrap()
　.split(' ')
　.any(|s| s.parse::<isize>().unwrap() & 1 == 0);
println!("{}", if cond { "Even" } else { "Odd" });

if式自体はワンライナーーで正解とrustfmtはおっしゃってる

**デフォルトの名無しさん** · 2021/12/19(日) 21:50:26.03

ワンライナー云々はフォーマットの話ではないやろ

**デフォルトの名無しさん** · 2021/12/19(日) 22:05:50.34

例えば>>321がif式を5行に分割しているが
それもrustfmtにより1行に修正された

Rust標準ライブラリのソースでもワンライナー
bool.rs: if self { Some(t) } else { None }
result.rs: let n = if self.inner.is_some() { 1 } else { 0 };
time.rs: let prefix = if f.sign_plus() { "+" } else { "" };

>>328
では何の話かね？

**デフォルトの名無しさん** · 2021/12/19(日) 22:37:44.04

構造と書式を区別できんのはヤバイで

**デフォルトの名無しさん** · 2021/12/19(日) 23:10:30.41

心底どうでもいい。
保守性に貢献するどころかマイナスになるようなクソプライドコードの導入すんなよ。

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

また性懲りもなくコードべたべた書いてんのか

**デフォルトの名無しさん** · 2021/12/19(日) 23:21:45.51

rustfmtだから書式の話やで

**デフォルトの名無しさん** · 2021/12/19(日) 23:25:17.24

区別できなかったからrustfmtを持ち出したんやろ
どこに改行入れるべきかって話だと思ったんだろなww

**デフォルトの名無しさん** · 2021/12/19(日) 23:41:46.15

rustfmtを持ち出したのは俺じゃないぜ
あと今回のケースならここは分割するよな
let reader = BufReader::new(stdin());
let line = reader.lines().next().unwrap().unwrap();
let is_even = line.split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0);

**デフォルトの名無しさん** · 2021/12/19(日) 23:48:52.91

汚コード

**デフォルトの名無しさん** · 2021/12/19(日) 23:59:56.43

問題文が>>314でこうなってるから
>> | 入力は以下の形式で標準入力から数値が与えられる。
>> | a b c d e

if let [a, b, c, d, e] = line
　.splitn(5, ' ')
　.map(|s| s.parse::<isize>().unwrap())
　.collect::<ArrayVec<_, 5>>()[..] {

あとこれでいい
let is_even = a & b & c & d & e & 1 == 0;

**デフォルトの名無しさん** · 2021/12/20(月) 05:23:59.31

そういえばいつの間にか
let variable = 3;
println!("{variable}");
みたいな書き方が出来るんだけどこれ前からだっけ？

**デフォルトの名無しさん** · 2021/12/20(月) 05:50:08.07

>>338
それはまだnightlyだけですよ
来月の1.58からstableになって使えるようになる予定

**デフォルトの名無しさん** · 2021/12/20(月) 11:31:40.46

>>335
構造化の基本を学びましょう

**デフォルトの名無しさん** · 2021/12/20(月) 18:38:24.90

どちらのコードも正解

**デフォルトの名無しさん** · 2021/12/20(月) 18:57:17.41

コードに「間違い」はあっても「正解」はない

**デフォルトの名無しさん** · 2021/12/20(月) 19:04:29.92

間違っているコードは出ていないような
問題視してる人は具体的に何を問題にしているの？

**デフォルトの名無しさん** · 2021/12/20(月) 20:55:59.37

アスぺ思考はこれだから

**デフォルトの名無しさん** · 2021/12/21(火) 11:25:19.41

https://doc.rust-jp.rs/book-ja/ch18-03-pattern-syntax.html#%E3%83%9E%E3%83%83%E3%83%81%E3%82%AC%E3%83%BC%E3%83%89%E3%81%A7%E8%BF%BD%E5%8A%A0%E3%81%AE%E6%9D%A1%E4%BB%B6%E5%BC%8F
ここの最後のところに

パターンと関わるマッチガードの優先度は、以下のように振る舞います:
(4 | 5 | 6) if y => ...
以下のようにではありません:
4 | 5 | (6 if y) => ...

とあるんですが、後者のようになってほしい場合は4|5と6 if yを別々に書くしか無いですか？

**デフォルトの名無しさん** · 2021/12/21(火) 11:56:47.99

>>345
ガード構文がこう「『Pattern』 if 『Expression』」なのでそうなりますね

**デフォルトの名無しさん** · 2021/12/22(水) 20:44:35.79

sixtyfpsってどう？

**デフォルトの名無しさん** · 2021/12/22(水) 22:58:00.27

> しかし競プロでみんなproconioとかいう謎の専用ライブラリ使ってるの見た目悪すぎて笑える
いや、ほぼ公認のクレートなんだが・・・
謎の専用ライブラリとかいってる時点で、お察しか？

あと、見た目悪いってどういうことなんかね
includeしたら見た目悪すぎなわけ？

**デフォルトの名無しさん** · 2021/12/22(水) 23:53:48.10

Rust bookの以下の記述について質問です

https://doc.rust-jp.rs/book-ja/ch19-05-advanced-functions-and-closures.html#クロージャを返却する
> 以下のコードは、クロージャを直接返そうとしていますが、コンパイルできません:
>
> fn returns_closure() -> Fn(i32) -> i32 {
> |x| x + 1
> }
> コンパイラには、クロージャを格納するのに必要なスペースがどれくらいかわからないのです。
> この問題の解決策は先ほど見かけました。
>
> fn returns_closure() -> Box<Fn(i32) -> i32> {
> Box::new(|x| x + 1)
> }

とBox化しなさいと書かれているのですが
以下のようにimplを付けるとBoxを使わなくてもコンパイルが通り動きました

fn make_closure_add1() -> impl Fn(i32) -> i32 {
|x| x + 1
}

このimpl付加は暗に自動的にBox化されているということなのでしょうか？

**デフォルトの名無しさん** · 2021/12/23(木) 00:23:38.98

ここを読む
https://doc.rust-lang.org/book/ch19-05-advanced-functions-and-closures.html#returning-closures

**デフォルトの名無しさん** · 2021/12/23(木) 07:21:11.33

>>348
そりゃあcratesio に上がったものは空っぽでもゴミでも全部公認だわなｗ

**デフォルトの名無しさん** · 2021/12/23(木) 15:17:54.33

>>342
逆だ、コードは常に「正解」で動いていて「間違い」ない。

あんたの書いたバグもコンピューターにとっては一部の隙もなく正解であり、書かれたその通りに動き、無慈悲である。
同じ目的で、多数、あるいは二人の人が書いたコードで違いが出るのは「表現の違い」であり「間違い」と決めつける
のは人間の主観や嗜好でしかなく、仮にコードへ正誤を求めるなら明確に表現できていなればならず、矛盾が生じる