Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※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/

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

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

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/20(金) 22:19:18.10

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

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/
Rust Performance Book
https://nnethercote.github.io/perf-book/

**sage** · 2024/09/21(土) 06:46:43.45

>>1
O2

**デフォルトの名無しさん** · 2024/09/21(土) 10:38:37.60

アンチの人はRustスレの邪魔をせずに
こちらへどうぞ

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

**デフォルトの名無しさん** · 2024/09/21(土) 11:45:15.28

変な質問かもしれないけどRustでもUMLのクラス図みたいなものって有効？
必要なケースとしては、プログラムの設計を他者と共有する必要があり、かつ相手は時間をとってコードを詳細に読むわけでなないという場合

今どきUMLという感じかもしれないけど、社内の他のプロジェクトではUMLを (常にではなく、必要に応じて時々) 使っている
Rustのプロジェクトでもこれを求められた場合にどう対応すれば良いのか
型同士の関係 (1対多などの数量関係や呼び出し関係) を説明するくらいはできるけど、継承などオブジェクト指向を意識したところがあるから、Rustのコードの設計を説明するのに必ずしも向かない気もする
こういう、設計を共有するのってみんなどうしてる？

**デフォルトの名無しさん** · 2024/09/21(土) 12:11:46.71

>>6
トレイトをインターフェイスとみなせば (わかりやすいかどうかは置いといて) 一応は成立すると思う。
だけどそういう図を見るくらいなら cargo doc を読んでいくほうがわかりやすいんじゃないかなぁ。
UML が有用なのはシーケンス図とか、抽象度の高い用途のほうでしょ。

**デフォルトの名無しさん** · 2024/09/21(土) 12:37:38.28

開発者が相手ならCargo docは有効だと思う
だけど、説明したいのは構造体やメソッドの使い方じゃなくて、ドメイン側のロジックが適切な型として表現されてるか、それに抜け漏れがないかといった点
それを視覚的に示せるということでクラス図を例に出した
相手はRustのコードに直接触れるわけではないけど、ドメイン側の知識を持ってて、そういう観点からのレビューをしたいという場面

書いてて思ったけど、Rustのenumで表現されてる型がやや表現しづらい？
OOPだとICommandのようなインタフェースを継承させてたけど、その代わりにenum Command にしてるケース
UMLに合うようにRust側のコードをトレイトを使って書き直すのも本末転倒な感じがする

**デフォルトの名無しさん** · 2024/09/21(土) 12:53:36.90

>>8
プログラムとしての合理性とドメイン側のロジックがそれほど一致しないのは普通のことなのでそういう形でレビューする事例は全然聞いたことないな。
特に専門的でプログラマの理解が追っつかないレベルだとドメイン側のロジックに忠実にやるしかないのだろうけど……。

**デフォルトの名無しさん** · 2024/09/21(土) 13:19:40.34

経験的にRustの構造体はデータベース設計のER図が合いそう
ライフタイムの関係で
・構造体のDrop≒レコードのdelete
・参照≒行ロック
みたいなイメージがしやすくて実装とのギャップを減らせると思う
enumはER図だとsubtypeに相当する

**デフォルトの名無しさん** · 2024/09/21(土) 13:46:07.48

テンプレートメタプログラミングに対応してないなら、C++ですら使えないと思う

**デフォルトの名無しさん** · 2024/09/21(土) 14:16:16.53

メタコードでも最終的に具現化されるから大丈夫でしょ
メタの部分はメタのままモデル化しとけばいい

**デフォルトの名無しさん** · 2024/09/21(土) 15:26:24.58

>>6
自分も相手もUMLに慣れてるのならUML使えばいいと思う
リバースエンジニアリングで図を書くのでなければ別に困らない

>>8
>Rustのenumで表現されてる型がやや表現しづらい？
<<enum>>や<<enumeration>>のマーカーをつけるだけ

**デフォルトの名無しさん** · 2024/09/21(土) 16:07:13.97

VS CODEとrust-anlayzerでrustを書いてるんだけど、
if文を1行でこう書きたいんだけど、自動整形で改行されちゃうんだけど、↓を許容する設定の仕方知っている人いたら教えて～
if 1 == 1 { true } else { false }

**デフォルトの名無しさん** · 2024/09/21(土) 16:47:05.18

rustfmtを使って整形しているのならば
#[rustfmt::skip]

**デフォルトの名無しさん** · 2024/09/21(土) 16:52:58.13

(if 1 == 1 { true } else { false })
let foo = if 1 == 1 { true } else { false };
みたいにカッコで囲むかletで値を受けるならrustfmtのsingle_line_if_else_max_widthが効きそうだけど
裸のifだと設定では無理かも

#[rustfmt::skip]
if 1 == 1 { true } else { false };
でskipするしかない

rustfmtの設定はrustfmt.toml（Cargo.tomlと同じ場所）で
single_line_if_else_max_width = 80
とか書けばいい
参考：github.com/rust-lang/rustfmt/blob/master/Configurations.md

**デフォルトの名無しさん** · 2024/09/21(土) 17:16:34.53

設計図と実物のギャップに比べたら改行がちょっと多い程度の差は
人体に無害だ
だが科学的に無害だとしても人の機嫌を損ねることは許されない

**デフォルトの名無しさん** · 2024/09/21(土) 18:16:59.29

>>14
短絡評価込みだとこれと同一になるはず。
1==1 && true || false;

この形でも長くなりすぎると改行されちゃうけどね。

**デフォルトの名無しさん** · 2024/09/21(土) 18:24:23.07

>>18
それ結果がboolのとき限定だし流石に……

(1 == 1).then(|| true).unwrap_or_else(|| false)

うーん、ないな

**デフォルトの名無しさん** · 2024/09/21(土) 19:05:43.59

boolならif else必要ないやろ

**デフォルトの名無しさん** · 2024/09/21(土) 19:52:13.10

trueのときの値，falseのときの値って意味で書いてんじゃねえかな

**デフォルトの名無しさん** · 2024/09/21(土) 20:44:43.28

>>15
>>16
ありがとう。やっぱり無理かー
InteliJ Ideaではできたのにな。RustRoverはまだ発展途上だし
Zedに期待したいけど、どこまでできるのか

>>21
そういうことです。とはいえbool限定で別の1行書き方があるとしても↓の書き方を1行に整形してほしいということで

> if 1 == 1 { true } else { false }

**デフォルトの名無しさん** · 2024/09/21(土) 22:18:19.38

>>9
それを一致させるように努力するのが本来のDDDよ
それを放棄したプロジェクトはいわゆる軽量DDDというアンチパターン

**デフォルトの名無しさん** · 2024/09/21(土) 22:31:50.56

>>21
マジかよ
そんな書き方したらあかんやろw