Rust part20

**デフォルトの名無しさん** · 2023/03/03(金) 00:45:28.73

公式
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 part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

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

**デフォルトの名無しさん** · 2023/03/03(金) 01:05:27.64

**デフォルトの名無しさん** · 2023/03/03(金) 01:09:18.66

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

**デフォルトの名無しさん** · 2023/03/03(金) 02:38:11.23

>>2,3
それ追加すんなって
公式見ないで質問するようなやつが増えるだけから

**デフォルトの名無しさん** · 2023/03/03(金) 04:50:59.80

>>4
マクロとデザインパターン以外は全て公式とその日本語版じゃね？

**デフォルトの名無しさん** · 2023/03/03(金) 06:29:29.67

質問はChatGPTにどうぞ

ってやればいいか

**デフォルトの名無しさん** · 2023/03/03(金) 10:06:00.63

>>4
ゴミ日本語訳に誘導したくて仕方がない関係者だろな

**デフォルトの名無しさん** · 2023/03/03(金) 11:36:41.01

>>7
複製オジが関係者なのか！！
だとしたらあの日本語品質は納得
近寄ったらダメなやつだな

**デフォルトの名無しさん** · 2023/03/03(金) 11:57:20.14

日本語訳は2年近く前のThe Bookをもとにしてるにも関わらず
約1年前の1.58時点のThe Bookをもとにしてるかのようにミスリードしてるのが悪質
倫理観が欠如してるとしか思えない

**デフォルトの名無しさん** · 2023/03/03(金) 21:55:56.58

あちゃーまじかー
技術スキルも日本語能力もないやつにやらせんなよ

**デフォルトの名無しさん** · 2023/03/03(金) 21:59:35.11

Rust公式でもJP公式でも他の有志翻訳ページでも
もし本当にヤバいミスがあるなら正しい情報をそれぞれに出すのがいいんじゃないか
それで直らないなら新たなサイトを作るとか新たな言語を作るしかない
これらでない言いがかりをつけるだけの荒らし行為はやめとけ

**デフォルトの名無しさん** · 2023/03/03(金) 23:16:10.01

所有権複製おじさんも仮の所有権おじさんも日本語訳が生み出したものだと思ってたが因果関係が逆なら根本原因は明らかだね

**デフォルトの名無しさん** · 2023/03/03(金) 23:34:12.09

>>11
JP公式って何の公式なん？
日本ユニセフ協会はUNICEF公式みたいな？

**デフォルトの名無しさん** · 2023/03/04(土) 00:17:04.01

>>13
その例でいくと日本ユニセフ協会公式ってことだろ
略してJP公式

**デフォルトの名無しさん** · 2023/03/04(土) 13:59:40.63

https://github.com/rust-lang-ja/book-ja/tree/master-ja/src
の更新日がバラバラだからな
title-pageだけ更新したから>>9みたいになってる
一旦全部AI翻訳にかけた方が早いかもしれない

**デフォルトの名無しさん** · 2023/03/04(土) 14:18:14.66

本家に追従しきれないよりは機械翻訳のほうがマシだけど
可能ならちゃんとした技能のある人が翻訳するに越したことはないのも確かなんだよなー。

**デフォルトの名無しさん** · 2023/03/04(土) 18:04:28.01

翻訳やってる人の言葉使いが複オジとそっくりだから本人っぽいな

**デフォルトの名無しさん** · 2023/03/04(土) 23:12:51.88

いつ時点のものを訳したのかさえ管理できてないって翻訳プロジェクトとしてはもう終わってんね
そんなのよりThis Week in Rustみたいな役立つリンクをテンプレに入れた方がいい

**デフォルトの名無しさん** · 2023/03/05(日) 08:10:28.29

https://gihyo.jp/article/2023/03/tfen009-rust_progress
let-elseも1.65から利用可能になり、if let構文（例：if let Some(b) = a {} else {}）をlet Some(b) = a else {}と書けるようになりました。
この変更により、ネストが減ってコードの見た目がスッキリしたり、処理の流れが読みやすくなったりというメリットを享受できるようになります。
先日let-elseを使いたくなったので、チームでRustのバージョンを1.65に上げて、これからはlet-elseに変えられるところは変えていこう、ということになりました。

**デフォルトの名無しさん** · 2023/03/05(日) 12:20:05.12

いつも常駐してるオジサンがダンマリ決め込んでるところを見ると
JP公式==複オジ説は本当なんだな
最悪

**デフォルトの名無しさん** · 2023/03/05(日) 15:24:37.63

どこかのおじさんが自称公式を名乗っていようが正直どうでもいい
このスレ的にはあそこの日本語訳は害が大きいので必ず公式ドキュメント(英語)を参照することを>>1に入れておけばそれで十分

**デフォルトの名無しさん** · 2023/03/05(日) 15:43:27.49

ここまで複オジの戯言

**デフォルトの名無しさん** · 2023/03/05(日) 16:04:09.72

>>21
それでいいんじゃね
実際前スレ前々スレとそれで良かったわけだから

**デフォルトの名無しさん** · 2023/03/05(日) 18:09:02.89

>>20
隔離スレには出没してるからそういうことなんだろう

**デフォルトの名無しさん** · 2023/03/07(火) 11:59:08.95

メモリが足んなくて、FP16とかBF16とかに興味が出てきたんだけどさ
https://docs.rs/half/latest/half/struct.bf16.html
こういうのをx64系のCPUで使うと、FP32の場合より(SIMDがバシッと効く場合を除いて)どんぐらい遅くなるもんなの？

**デフォルトの名無しさん** · 2023/03/07(火) 15:51:39.46

>>21
公式があの日本語訳は非公式翻訳版ですよとちゃんと明記したからあれを公式翻訳かのように言ってたあのおじさんは無視でOK
https://www.rust-lang.org/ja/learn

**デフォルトの名無しさん** · 2023/03/07(火) 17:36:45.89

単精度のときに全部L1に乗るなら0.6倍、そうでないなら半精度のほうが早くなる模様
https://www.isus.jp/others/half-precision-floats/

**デフォルトの名無しさん** · 2023/03/07(火) 17:39:18.38

おじさんの個人ブログ&リンク集を
JP公式などと呼称するのがそもそもの間違いなんだよな
わかってる人は訪れてもそっ閉じするだけなので
初心者向けの注意喚起だけ書いておけばいいよ

**デフォルトの名無しさん** · 2023/03/07(火) 17:47:17.93

なんでIDコロコロするの？

**デフォルトの名無しさん** · 2023/03/07(火) 19:42:26.18

>>26
どこにその記載あるの？

**デフォルトの名無しさん** · 2023/03/07(火) 19:48:30.54

>>30
と思ったらリンクに「非公式」とあるだけで、否定しているわけじゃないんだな。中国語とかと同じじゃない？

そもそもリンクある時点で「公式の推奨」的な位置づけになってるんじゃないのかね。

**デフォルトの名無しさん** · 2023/03/07(火) 20:33:26.94

>>27
大きなデータ処理でL3キャッシュに乗らない時は半精度を使ったほうが単精度の1.6倍速くなるわけか

>>31
日本語版へのリンクを本家が貼って推奨してるようにみえる

**デフォルトの名無しさん** · 2023/03/07(火) 21:12:05.81

推奨も非推奨もしていない書き方だと思うけど、どうやったら推奨してるように見えるんです？

**デフォルトの名無しさん** · 2023/03/07(火) 21:24:18.71

>>33
本家がフランス語版や中国語版など各言語に応じてその言語版へのリンクを貼っている
非推奨ならばリンクを貼ることはない

**デフォルトの名無しさん** · 2023/03/07(火) 21:29:32.54

日本語コミュニティの中心的な人物は本家コミュニティでも活動してる。
推奨もクソもないんよ。同じ人が日本語でも英語でも議論や発信してるってだけなんだから。

でも本家コミュニティのほとんどの人は日本語なんて知らんのだから翻訳の質にお墨付きを与えられる立場でもない。
本家コミュニティの中に日本語コミュニティへの橋渡し役がいるから
日本語コミュニティの拠点だと認識しているところにリンクしてるんだわ。

リンクは質についての保証ではなく活動実態がある (と本家コミュニティが認識している) という保証なんだわ。

**デフォルトの名無しさん** · 2023/03/07(火) 21:31:53.30

>>34
リンクが貼ってあるから推奨ってのはなんとも面白い解釈だね

**デフォルトの名無しさん** · 2023/03/07(火) 22:07:18.53

>>980
次のテンプレにこれをいれとけ

「The Book非公式翻訳版について」
The Bookには有志による非公式な日本語翻訳版が存在しますが
日本語訳の品質に問題があるとの声が多いことや
数年以上前の古いThe Bookの翻訳となっておりアクティブな更新が行われていないことから
混乱を避けるために当スレでThe Bookを参照する場合は非公式翻訳版ではなく必ず公式のThe Book(英語)を参照するようにして下さい

**デフォルトの名無しさん** · 2023/03/07(火) 22:33:00.74

>>37
いいね
改行はもう少し揃えたほうが読みやすいとは思う

**デフォルトの名無しさん** · 2023/03/07(火) 22:42:05.39

>>37
そんなバカなアンチ活動みたいなことはやめとけ
その唯一の日本語版にもし致命的な間違いが仮にあるとすれば直せばいいだけじゃないのか？
おそらく間接的な協力も直接的な協力のどちらもできるだろう

**デフォルトの名無しさん** · 2023/03/07(火) 23:23:41.62

改善すべき点があるならば改善する方向へ動くのが良いと思う

**デフォルトの名無しさん** · 2023/03/08(水) 07:09:44.47

>>39
なんでそんなにセンシティブになってるの？

**デフォルトの名無しさん** · 2023/03/08(水) 07:14:43.18

>>37はいつものRustの足を引っ張るアンチっぽい

**デフォルトの名無しさん** · 2023/03/08(水) 07:54:43.28

本気でなにか変えたいならGitHubなり公式フォーラムなりで活動すればいいわけで
ここで文句言ってるだけってことは単に言いたいだけなんだろう

**デフォルトの名無しさん** · 2023/03/08(水) 08:08:57.29

>>41
足の引っ張り合いがコミュニティーを殺すから。
否定だけして改善しない無能がはびこると誰もコミュニティーに貢献しなくなる。

**デフォルトの名無しさん** · 2023/03/08(水) 08:31:57.93

>>37
数年以上前の古い翻訳との指摘は勘違いかあるいは意図的なガセか？
英語版が2021 Edition対応になったときに
日本語版もその2021 Edition対応になっていて特に問題ないようだが

**デフォルトの名無しさん** · 2023/03/08(水) 10:39:24.48

一人だけ必死オジねww

**デフォルトの名無しさん** · 2023/03/08(水) 11:13:15.11

>>45
それ以降更新されてなければ数年以上前の古い翻訳で間違いないね

**デフォルトの名無しさん** · 2023/03/08(水) 11:25:12.41

「数年以上前の古い翻訳」は更新があれば嘘になっちゃうから
更新状況の確認方法を挙げて確認を促すことができればそれがよいね

**デフォルトの名無しさん** · 2023/03/08(水) 12:03:18.15

>>36
本家が「紹介する価値がある」と判断したからリンクしているのであって、一般的な感覚としては推奨の範疇に入るんだけど。
少なくとも読み手はそう考える。

**デフォルトの名無しさん** · 2023/03/08(水) 12:09:51.90

>>37の「数年以上前の古いThe Bookの翻訳」で正しい
翻訳の元になっているThe Bookが古いということ

**デフォルトの名無しさん** · 2023/03/08(水) 12:24:02.51

>>37
ウソでしょ
日本語版を見に行ったら最初に2022年と書いてあるよ
数年以上前ってなんのこと

**デフォルトの名無しさん** · 2023/03/08(水) 12:26:44.45

関係者にも関わらず
それを明かさず必死擁護してると
ステマ規制で罪に問われるよ

**デフォルトの名無しさん** · 2023/03/08(水) 12:28:09.23

>>49
読み手っていうか君がそう感じてるだけでしょ？
真に推奨ならば「THE BOOKを読もう！」のリンク先が日本語版になってるよ
だから公式としては推奨も非推奨もしていない、案内だけしてるという状態

**デフォルトの名無しさん** · 2023/03/08(水) 12:35:05.90

>>51
非公式翻訳版は公式のどのブランチのどのコミットバージョンをもとにしてるのかな？
どこに記載されてるののかな？

**デフォルトの名無しさん** · 2023/03/08(水) 12:38:42.68

>>51
2022はさすがに嘘だろ
もっと前に変更されてた内容がが日本語版では古いままだったのが数スレ前に出てだぞ
あれから更新された気配はない

**デフォルトの名無しさん** · 2023/03/08(水) 12:46:44.11

必死オジのわざとらしいミスリードだろ

翻訳版がもとにしているThe Bookのバージョンが古いままという指摘に対して
非公式翻訳版を見たら2022年と書いてたよーだもんwww

**デフォルトの名無しさん** · 2023/03/08(水) 12:57:34.44

>>53
それも君がそう感じてるだけでしょ？

特別に案内している唯一の和訳なのに推奨していないとか、日本語圏の読み手を騙そうとしているとしか思えないね。

**デフォルトの名無しさん** · 2023/03/08(水) 13:00:40.45

>>57
推奨も非推奨もしていないと推奨していないは別なんですが...

**デフォルトの名無しさん** · 2023/03/08(水) 13:32:34.88

今気付いたけど本家のThe Bookから正式に日本語版を含む各言語版のレポジトリへリンクが張られてるんだね
https://doc.rust-lang.org/book/appendix-06-translation.html

日本語版の各セクションの更新日を見てみたら
https://github.com/rust-lang-ja/book-ja/tree/master-ja/src
数ヶ月前がいくつかあるから更新されてるんじゃない？

**デフォルトの名無しさん** · 2023/03/08(水) 14:23:51.90

複オジは非公式翻訳を
公式からリンクされてるという理由で
公式な日本語訳と偽っていた罪を償うのが先

嘘つきの言うことは誰も信用しない

**デフォルトの名無しさん** · 2023/03/08(水) 14:28:59.70

>>59
で？
翻訳のもとになってる公式The Bookがいつ時点のものなのかがわからないなら無意味

**デフォルトの名無しさん** · 2023/03/08(水) 14:38:17.99

評判の悪い日本語訳で勉強するより公式でやったほうがいいのは当然だよな
反対する理由は見当たらない

**デフォルトの名無しさん** · 2023/03/08(水) 14:49:29.41

>>59
二つの問題が一気に片付いたな
日本語版は公認されている
日本語版は更新されている

**デフォルトの名無しさん** · 2023/03/08(水) 15:29:08.93

非公式おじさん涙目ワロw

**デフォルトの名無しさん** · 2023/03/08(水) 17:16:33.70

結局、足を引っ張るだけの無能は口だけ番長ということでいいのかね。

githubの日本語訳リポジトリに改善版のプルリクエスト出して貢献すりゃいいのに。

**デフォルトの名無しさん** · 2023/03/08(水) 17:43:46.69

>>37
わかりやすくていいと思う
内容がすでに古くなっていることに気付かずに利用する人がこのスレでも結構いたからね
そういう人達がテンプレを読むとは限らないけど注意書きは絶対あったほうがいいと思う

**デフォルトの名無しさん** · 2023/03/08(水) 17:49:07.09

まだ件のAIで翻訳は無理なのか

**デフォルトの名無しさん** · 2023/03/08(水) 18:03:44.14

なんか頑張って擁護してる人は日本語版が古くないっていう根拠全く示せてないよね？

**デフォルトの名無しさん** · 2023/03/08(水) 18:11:20.27

事実を書くと足を引っ張るだけの無能になるらしい
GitHub のリポジトリに Issue も PR もいくつかあるけど放置されてるじゃん

**デフォルトの名無しさん** · 2023/03/08(水) 18:21:29.08

>>37の案でok
日本語版の問題点の話ばっかりでこれ以上スレ消費しても仕方ない気がする

**デフォルトの名無しさん** · 2023/03/08(水) 18:27:52.80

>>69
放置されてるね～
これもしかしてメンテナ兼レビュワー1人体制？

**デフォルトの名無しさん** · 2023/03/08(水) 19:27:32.79

>>69
ならメンテナに立候補すりゃいいんじゃない？

**デフォルトの名無しさん** · 2023/03/08(水) 20:56:54.94

もしかしてメンテナご本人？

**デフォルトの名無しさん** · 2023/03/08(水) 22:28:52.95

日本語版に問題がある
→じゃお前がPR送れ
IssueもPRも放置されてる
→じゃお前がメンテナやれ

なんなのこれ
こんなのが関係者にいるんなら改善される見込みゼロでしょ

**デフォルトの名無しさん** · 2023/03/08(水) 22:29:48.23

ここの皆Rust大好きな筈なのに日本語コミュニティに貢献の痕跡がないってやばない？

**デフォルトの名無しさん** · 2023/03/08(水) 23:02:50.55

非公式日本語翻訳には手を出さないよう
積極的に初心者を啓蒙するのが
日本のRustコミュニティにとっての最善手

**デフォルトの名無しさん** · 2023/03/09(木) 00:46:37.28

>>75
今や匿名じゃないと困っちゃう人の巣窟ですからね

**デフォルトの名無しさん** · 2023/03/09(木) 01:16:43.58

常駐してるアンチRustによる妨害連投だろ
何でも文句をつけてRustの足を引っ張ることが目的
日本語版の件も同じ

**デフォルトの名無しさん** · 2023/03/09(木) 02:21:45.87

そして>>69に戻る

**デフォルトの名無しさん** · 2023/03/09(木) 08:46:28.38

>>78
どう見てもあなたの方が常駐してるアンチですよ
何の貢献もせずRustコミュニティの足引っ張るのやめてもらえます？

**デフォルトの名無しさん** · 2023/03/09(木) 09:02:51.43

Rustアンチを見分けるのは簡単
今までどの話でも「改善案や代替案を出したり協力したり」せずに「批判したり言いがかりをつけたり潰そうとしたりする」

今回の話も同様
もし仮に具体的に深刻な問題があるならば改善する方向へ動けばよいだけの話

**デフォルトの名無しさん** · 2023/03/09(木) 09:14:52.26

>>37の具体的なテンプレ改善案に対して
>>39のように最初からヒステリックなレッテル貼りをして理性的な反論をしないあなたは間違いなくアンチですね

簡単に見分けられます

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

> 「批判したり言いがかりをつけたり潰そうとしたりする」
確かに日本語版の問題点が指摘されると
とにかく言いがかりをつけて潰そうとする人がいるね

**デフォルトの名無しさん** · 2023/03/09(木) 09:27:52.51

誤訳も放置
イシューも放置
プルリク来るけど知らんぷり

文句言うな
お前がやれ
今日も5chをぐーるぐる

オラこんなリポいやだ
オラこんなリポいやだ

**デフォルトの名無しさん** · 2023/03/09(木) 09:41:16.94

>>83
問題点を指摘するだけでもコミュニティに対する立派な貢献なのにな
それを必死に潰そうとするやつこそアンチだわな

**デフォルトの名無しさん** · 2023/03/09(木) 09:41:31.57

本家にある程度追いついてて誤訳があるとか未訳があるなら貢献しやすいけどそうじゃないからなぁ
まずはそこまでメンテナー側でやってくれたら貢献する人も現れるんじゃない？

**デフォルトの名無しさん** · 2023/03/09(木) 09:42:37.79

>>84
草

**デフォルトの名無しさん** · 2023/03/09(木) 09:51:30.09

Rustアンチは具体的に日本語版Bookのどの章のどの節にどういう問題があって改善案がどうなのかを言えない
RustアンチはRustやその普及を潰すことだけを目標にしている

**デフォルトの名無しさん** · 2023/03/09(木) 09:56:19.19

>>88
>>86で言ってるやんけ
github.com/rust-lang/book/graphs/commit-activity
github.com/rust-lang-ja/book-ja/graphs/commit-activity

これ見りゃ分かるけど本家の更新が全然入ってないのよ
改善案としては>>86に書いた通りか、リポジトリをアーカイブしてもう更新しないことをこれから見る人に通知するかがいいと思う

**デフォルトの名無しさん** · 2023/03/09(木) 09:56:38.71

>>85
ですよね
自分が経験した問題点を共有して後進の初心者に注意を促すような行為も十分立派な貢献
あとは受け手が内容を判断すればいいわけで

**デフォルトの名無しさん** · 2023/03/09(木) 10:05:17.42

Rustコミュニティに貢献しても
非公式翻訳版の品質改善のために
PR出さずに批判するやつは全員アンチ扱い

**デフォルトの名無しさん** · 2023/03/09(木) 10:07:21.23

>>89
オジ恥

**デフォルトの名無しさん** · 2023/03/09(木) 10:20:37.62

>>92
事実に対して反論できず捨て台詞を吐くだけなら何も書かないほうがいいと思います

**デフォルトの名無しさん** · 2023/03/09(木) 10:26:46.29

>>91
自分達がコミュニティ代表という選民意識だろうね

都合の悪い問題点を指摘されると>>82の言うようにヒステリックなレッテル貼りで言論封殺という行動に出ちゃうあたりは高市とそっくり

やってることはRustコミュニティに対するアンチ活動でしかないんだがこの手の人たちは自分たちの私欲が満たせればあとはどうでもいいんだろう

**デフォルトの名無しさん** · 2023/03/09(木) 10:39:22.78

もしかしてforkしてブランチ切る程度のこともやってないわけ？
ちょっと信じられないんだが

**デフォルトの名無しさん** · 2023/03/09(木) 10:45:17.46

>>95
プルリク出しても無視されることが分かってるのに修正する気になるわけないじゃん

**デフォルトの名無しさん** · 2023/03/09(木) 10:51:11.72

日本語版には問題があるから英語版を使ったほうがいいという意見に対して
批判するならイシューやプルリク出せというのは論点のすり替え

**デフォルトの名無しさん** · 2023/03/09(木) 10:57:51.77

日本語版を潰すことだけに力を入れてるのかー
マジでアンチじゃん

**デフォルトの名無しさん** · 2023/03/09(木) 11:02:16.65

全員単発
応仁の乱

**デフォルトの名無しさん** · 2023/03/09(木) 11:02:36.11

問題点・改善点をあげてもアンチ乙で片付けられるんだから無敵だな

**デフォルトの名無しさん** · 2023/03/09(木) 11:36:59.36

>>96
そういう意味じゃない
翻訳プロジェクトが英語版リポジトリをforkしたり翻訳用リポジトリに取り込んだりしてないのかという意味

**デフォルトの名無しさん** · 2023/03/09(木) 11:41:54.63

まぁ実際のところ日本語版を読みたい初心者がこんなスレに来るわけないし
このスレのローカルルールとしては>>37でいいと思うけどな
もし日本語版を本気でどうにかしたい人がいるならその議論はzuilpなりGitHubのissueでやればいい

**デフォルトの名無しさん** · 2023/03/09(木) 11:59:25.10

>>101
なるほど
元々が fork じゃない形態をとってるからよく分からないんだよね
まぁこれは各言語版そうなってるっぽいけど

**デフォルトの名無しさん** · 2023/03/09(木) 11:59:38.63

>>101
どっちもやってないみたいだぞ
信じられんよな
最低限のソース管理も碌にできない人が
俺のやることに文句を言うなとかどの口で言ってんだか

**96,103** · 2023/03/09(木) 12:07:13.82

もしもしはすぐID変わるからダメだな
これじゃIDコロコロするやつと変わんねぇよ

**デフォルトの名無しさん** · 2023/03/09(木) 12:23:44.08

>>102
日本語版を殲滅するようなローカルルールを決めるのはやり過ぎ
そこまでするのはRustのアンチと言われても仕方ないかな

**デフォルトの名無しさん** · 2023/03/09(木) 12:53:07.30

>>106
単にこのスレでは取り扱わないってことでいいんじゃないかと思うけど
普通の初心者はこのスレ見る前にググればすぐにたどり着くんだし

**デフォルトの名無しさん** · 2023/03/09(木) 13:38:49.60

>>102
同意

**デフォルトの名無しさん** · 2023/03/09(木) 13:56:08.35

5chの1スレで扱わなくなると殲滅されてしまうよう物なら
近いうちに自然淘汰されるだけだから
ここでは扱わないのが正解ということになる

**デフォルトの名無しさん** · 2023/03/09(木) 14:02:00.14

傍から見てるだけだけどさ
わざわざ日本語版を排除しようというのはアンチにしか生じない動機・感情よね

**デフォルトの名無しさん** · 2023/03/09(木) 14:10:10.57

不正確なもんは排除しとくほうがマシ
それを許して欲しいと言う甘えは通用しない
所有権の複製とかいう用語が世間で通用しないのと同じ

**デフォルトの名無しさん** · 2023/03/09(木) 14:12:34.91

更新が英語版のmainに追い付いたらテンプレに戻すという条件付き除外措置なら誰も文句無いですか？

**デフォルトの名無しさん** · 2023/03/09(木) 14:13:47.86

日本語版で不正確なところはどこなの？
所有権？？

**デフォルトの名無しさん** · 2023/03/09(木) 14:16:43.77

総務省の公文書のことか

**デフォルトの名無しさん** · 2023/03/09(木) 14:47:46.87

Rustアンチっていう表現がそもそも疑問なんよね
単にここじゃあ複オジが馬鹿にされてたり
rust-jpに疑問が持たれてたりするだけであって
それがなぜだか
ある人にとっては「Rustアンチ」ってことにすり替わっちゃう

**デフォルトの名無しさん** · 2023/03/09(木) 14:50:24.91

>>110
これから始める人が不正確な物を見ないように配慮するのがアンチ行為になるんですか？

>>113
100レスちょっとしかないんだから頭から流し読みしてくればいいじゃん

**デフォルトの名無しさん** · 2023/03/09(木) 14:51:04.12

cargoを使用していると、過去のクレートのキャッシュ？なのかなんなのかわからないものがどんどん溜まっていってしまいます
これって使い続けるとどこまでも増えていってしまうのですか？何か容量を抑える策はあるのでしょうか？
SSDがしょぼいので気になってしまいます

**デフォルトの名無しさん** · 2023/03/09(木) 14:52:40.57

>>117
cargo clean

**デフォルトの名無しさん** · 2023/03/09(木) 15:28:35.84

会話や議論のベースとするには信頼が置けないというのが最大の理由でしょ
だからこのスレでは信頼のおける公式The Bookを使うローカルルールにするというだけのこと

日本語版の問題箇所を一つ一つ具体的にあげて改善していくためのスレじゃないんだからそれをやりたい人は>>102が言うようにzuilpなりGitHubでやるのが適切

**デフォルトの名無しさん** · 2023/03/09(木) 15:45:47.39

アンチというレッテル貼りしてるだけの人の動機は何なんだろう？

**デフォルトの名無しさん** · 2023/03/09(木) 15:53:09.08

>>120
どうも日本語版のメンテしてる関係者らしいよ
こんなところで一日中書き込みしてるくらいなら
放置してるIssueやPRの対応すればいいのにね

**デフォルトの名無しさん** · 2023/03/09(木) 16:11:36.62

バカが2人に増えたね
信者複製おじさんと謎のrust-jp陰謀論おじさん
地獄

**デフォルトの名無しさん** · 2023/03/09(木) 18:38:23.80

Bookの日本語版を一通り読んでみたけど特に間違ったことはなさげ
訳語は一部意見割れるかもしれないけど不可はない感じ
ネット上の日本語のRust入門としてベストじゃないかな

**デフォルトの名無しさん** · 2023/03/09(木) 18:53:24.39

え、内容が古いことは無視ですか？

**デフォルトの名無しさん** · 2023/03/09(木) 19:03:49.80

なにか古くて間違ってるようなことなかったと思うよ

**デフォルトの名無しさん** · 2023/03/09(木) 20:59:36.65

>>125
古いっていうのは本家と比べてだから誤りがあるかどうかは別だよ
そして少なくとも Box 使用箇所でコンパイル通らないコードがそのままになってたりするよ

**デフォルトの名無しさん** · 2023/03/09(木) 22:00:09.63

>>126
具体的に間違い箇所がわかってるならissue立てたらいいんじゃない？
メンテナの人とやりとりしたことあるけど、間違ってるから優先して直してって言えば対応してくれると思う

**デフォルトの名無しさん** · 2023/03/09(木) 22:25:18.34

>>127
Box 使用箇所は本家では直ってるところだからここだけ言ってもしょうがないよ

> 間違ってるから優先して直してって言えば対応してくれる
issue,pr は何個かあるけどどれも放置だから無駄だよ

**デフォルトの名無しさん** · 2023/03/09(木) 22:28:14.00

日本語訳の話はもういいよ
>>37に同意しない人は1人だけで有効な反論は出なかったからここでの結論は出た
日本語訳の品質改善に取り組みたい人はそれ用のGithubかZulipへどうぞ

**デフォルトの名無しさん** · 2023/03/09(木) 23:01:25.11

じゃスルーしてたlet-else話でもするか
>>19のリンクに書いてあるlet-elseのリファクタリングってあり？
Afterでもダメってほどじゃないが俺はBeforeのほうがいいように思える

//Before
pub async fn close(&mut self) -> Result<()> {
if let Some(mut file) = self.file.take() {
debug!("File {} closed", self.filename());
file.flush().await?;
}

Ok(())
}

//After
pub async fn close(&mut self) -> Result<()> {
let Some(mut file) = self.file.take() else {
return Ok(());
};

debug!("File {} closed", self.filename());
file.flush().await
}

**デフォルトの名無しさん** · 2023/03/09(木) 23:19:16.56

>>37
ネットで読める日本語のRust入門のベストはThe Bookの日本語版です
そんなテンプレは理解できないので反対します

>>130
その長さと深さならどちらでも個人の好み次第でしょう
長く深くなるとlet elseが読みやすくて推奨かな

**デフォルトの名無しさん** · 2023/03/10(金) 07:39:28.49

>>129
「日本語訳は最新版を取り込めていないところもあるから注意」くらいならまだしも、>>37は狭量で排他的だからだめ。
こんなのと同類扱いされたくない。

**デフォルトの名無しさん** · 2023/03/10(金) 12:26:56.89

>>132
追記。
日本語訳を（forkするなりした）修正バージョンを作ってそちらに誘導する、というのならあり。ユーザーにとってより良い改善策になるし。

**デフォルトの名無しさん** · 2023/03/10(金) 13:39:34.28

>>130
その2つならif letバージョンの方が読みやすいね

**デフォルトの名無しさん** · 2023/03/10(金) 17:33:37.91

>>130
前者だな
Okでも違う値を返すようになったりネストが深くなったりした段階でリファクタリングを考慮すれば十分
その例ではtake、flush、dropの一連のつながりを切るほどのメリットが全くない
あと後者はfile.flush.await.into()にする必要があるかもしれない

**デフォルトの名無しさん** · 2023/03/10(金) 17:46:09.19

>>111
不正確なもんは排除しとくほうがマシ、と考えるのも自由だし、5chで主張するのも自由。
もちろんそれによって誰も何の影響も受けない。

**はちみつ餃子** ◆8X2XSCHEME · 2023/03/10(金) 17:46:47.36

>>130
私も前者だと思う。
見通しが特に悪くなるほど複雑な場合でないならやろうとしていることがそのままコードに表れているほうが良くて、
前者のほうが何をやろうとしているのかスッと読める感じがする。

**デフォルトの名無しさん** · 2023/03/10(金) 18:03:17.42

>>130
if letとlet elseは場面に応じてどちらが向いているのか変わるから
その特定の例を比較してもなんの意味もないと思うが
一般的にif letが多段になるとその各else部分を先にlet elseで処理したほうが見やすくなる
一段でもif letの中が長くelse処理があって短いならばlet elseが見やすい

今回の>>130は返り値がResult<()>でelse処理が無い極めて特殊な例だから
当たり前のようにif letで良い
むしろそんな特殊な例を持ち出して議論することに意味がない

**デフォルトの名無しさん** · 2023/03/10(金) 19:08:36.07

>>138
場面に応じてどちらが向いているのか変わるから場面がわかる特定の例で比較することに意味があるのでは？

**デフォルトの名無しさん** · 2023/03/10(金) 19:13:36.55

>>139
返り値がResult<()>でelse時にErrではなくOk(())という極めて特殊な偏った例になんの意味があるんだ？

**デフォルトの名無しさん** · 2023/03/10(金) 19:17:05.20

意味の有る無しを断じるあたり幼稚やな
周り見てご覧
キミ以外はそんなとこに拘っとらんやろ？

**デフォルトの名無しさん** · 2023/03/10(金) 19:36:05.08

>>141
そのあたりも本質の一つじゃね？
まあ俺なら>>130のif letにelse節がないことも問題視するけどな
そんな例ならif letを使うのがいいと自明だから問う価値がない
>>130がアホ

**デフォルトの名無しさん** · 2023/03/10(金) 19:40:18.95

好きな方使ってろバカども
前スレそれで使い潰してまだ反省してねえのか

**デフォルトの名無しさん** · 2023/03/10(金) 20:24:59.10

>>130
前者は表明を表していて、後者は処理の条件を表している。
基本的に関数全体の条件を明示したほうが関数を使う側にとって使いやすいので、前者のほうが望ましい。

**デフォルトの名無しさん** · 2023/03/10(金) 21:43:27.35

現在のIT業界に「代替メモリレイアウト」という概念はありますか？

**130** · 2023/03/10(金) 22:22:59.62

>>130のコードは>>19のリンク先で「let-elseが便利すぎる」と銘打って紹介してたものなんだけど
let-elseを使う例としてはあまり適切な例ではないように感じたので他の人の意見を聞いてみたかった

理由はそれぞれ違うけどおおむね前者のほうがいいという意見が多くてスッキリした
ありがとう

**デフォルトの名無しさん** · 2023/03/10(金) 22:39:57.98

>>142
少なくとも>>19のリンク先ではif let Someでelse節が必要ない状況だからこそ
let-elseを使うケースとして>>130の例を紹介している

**デフォルトの名無しさん** · 2023/03/10(金) 23:34:37.12

好きにしたらええ
それより前スレ埋めない？

**デフォルトの名無しさん** · 2023/03/10(金) 23:46:20.34

>>145
「代替メモリレイアウト」という概念は聞いたことがないが悪魔の証明は無理なのでそういう概念がある可能性を完全に否定することはできない

非公式の日本語翻訳で使われてる用語みたいだけどこのスレで質問する際は公式のドキュメント(英語)を参照するようにしてね

**デフォルトの名無しさん** · 2023/03/10(金) 23:54:51.68

if letを使うかlet elseを使うかはケースバイケースでどちらもありうるのだから揉めるようなことではないと思うんだよな
let elseは要らないから削除せよ！と言ってた人はここを荒らすためだけに言ってただけだと思うし

**デフォルトの名無しさん** · 2023/03/11(土) 00:35:13.78

>>150
ケースバイケースだからこそ具体的な特定のケースを例にどちらがいいかを話してるんだろ

**デフォルトの名無しさん** · 2023/03/11(土) 00:54:45.06

Rust標準ライブラリのソースを見るとよくわかるよ
let else構文はもちろん使われまくっている
可読性が良くなるからね

**デフォルトの名無しさん** · 2023/03/11(土) 06:31:08.87

インストールでつまずいたのでチラ裏させてくれ
サンプルプログラムをコンパイルしたら`link.exe` not foundでコンパイルできなかった。
原因は、Build Tools for Visual Studio 2022をインストールしてしまったこと、アンインストールして
Build Tools for Visual Studio 2019をインストールしてコンパイルできた。

**デフォルトの名無しさん** · 2023/03/11(土) 11:07:27.22

相も変わらず1人だけズレてるな

**デフォルトの名無しさん** · 2023/03/11(土) 11:07:29.53

>>152
ネストが深くならないように積極的にlet else使うのが良いみたいやな
130の例はネストが無いことがif letのままでいい根本的な理由となるわけだ

**デフォルトの名無しさん** · 2023/03/11(土) 12:18:40.44

let-elseはパターンに合致しないと処理を継続できない場合に早期離脱（return、break、etc.）するための構文でしょ
それ以外でも使えるだろうけど逆に可読性が落ちそう

従来の言語で

if (nullable_obj == null) { continue; } // この行を書き忘れるとえらいことになる
nullable_obj.do_something();
...

みたいに書ける処理を今までのRustだと

if let Some(obj) = nullable_obj {
　obj.do_something();
　...
} else { // ループの末尾ならここは不要
　continue;
}

か無理やりunwrapして

if nullable_obj.is_none() { continue; } // この行を書き忘れるとえらいことになる
let obj = nullable_obj.unwrap();
obj.do_something();
...

みたいに書くしかなかったけど、let-elseを使うと従来の言語に近い形で書けるようになる

let Some(obj) = nullable_obj else { continue; }; // この行を書き忘れることはできない
obj.do_something();
...
returnだと?演算子で十分な場合もあるだろうから敢えてcontinueにした

**デフォルトの名無しさん** · 2023/03/11(土) 12:36:22.58

let elseはcontinueでもbreakでもreturnでもpanicでも!なら何でも使えるし使われている
returnの時にErr返しなら?を使ってもよいが
.ok_or_else(|| Error)?; とするか
elseでreturnするか
どちらが見やすいかは意見が別れそうだ

**デフォルトの名無しさん** · 2023/03/11(土) 12:39:50.82

Rustに限った話ではないがリファクタリングの良し悪しを判断するためには該当箇所を含む関数の全容(特に関数シグニチャ)とその関数を呼び出すコード例が最低限必要
関数シグニチャも呼び出すコードもない例では話にならない

呼び出し側が絶対変更できない前提なら前者だけでもいい場合があるが往々にして部分最適になりがち
>>130の例でも呼び出す側を考慮するとまた違った選択肢が見えてくる

**デフォルトの名無しさん** · 2023/03/11(土) 12:48:32.01

コーディング規約で早期リターンが推奨される開発現場であれば
その規約に準拠した表現が書きやすくなったのは良いこと
つうかそのつもりで読んでたから後者のほうが読みやすかったわ

**デフォルトの名無しさん** · 2023/03/11(土) 13:41:29.57

>>158
?とOptionとResultの影響があるから
他の言語よりも関数シグニチャーの持つ意味が余計に大きいように思う

**デフォルトの名無しさん** · 2023/03/11(土) 14:09:20.55

隔離スレでやれ

**デフォルトの名無しさん** · 2023/03/11(土) 20:53:29.08

https://qiita.com/namn1125/items/ccedf9cc06b8cef71557#let-else文のユースケース
この人が書いてるように?演算子のイディオムを踏襲してればlet-elseの出番は多くはない
逆に本来使うべきでないところでも乱用されやすいから注意が必要

**デフォルトの名無しさん** · 2023/03/11(土) 23:05:55.56

>>159
多くのところで言語に関わらずでifネストを深くせずに早期離脱をすることが好まれる
Rustではif let時にそれができなかったためlet else導入まではこうなってしまっていた
let foo = if let Some(foo) {
　foo
} else {
　(早期離脱前の処理があればここ)
　早期離脱
}
これはfooが三重に冗長で不格好
そのためlet else以前は早期離脱をあきらめる本末転倒なことも起きていた

具体的にlet elseが適している早期離脱は「範囲」が広い
・break
・continue
・エラー以外のreturn
・早期離脱前の処理があるエラーreturn

>>162
？が使える「範囲」はlet else より狭く早期離脱前の処理がないエラーreturnのみ
もちろん「量」は多いけどね

**デフォルトの名無しさん** · 2023/03/12(日) 11:57:58.73

カルパッチョ

**デフォルトの名無しさん** · 2023/03/12(日) 12:41:14.42

初見

VS code使い始めたんだが、カーソル移動系のショートカットキーの編集ってできないのか?
さくらEditorみたいにカーソル移動・ドラッグ編集を全部キーボードでやりたいんだが

**デフォルトの名無しさん** · 2023/03/12(日) 12:42:40.81

なぜここできく

**デフォルトの名無しさん** · 2023/03/12(日) 14:07:53.88

File > Preferences > Keyboard Shortcutsで設定画面開いて
cursorでフィルターかければcursorLeftみたいなコマンド出てくるから大体は変更できると思う
知らんけど

**デフォルトの名無しさん** · 2023/03/12(日) 14:14:14.53

vimでもemacsでもrust-analyzer動くよ

**デフォルトの名無しさん** · 2023/03/12(日) 15:10:27.15

>>166
プログラム板で一番勢いあるのここだから

**デフォルトの名無しさん** · 2023/03/12(日) 16:06:30.84

大学生が書いたQiita記事のほうがこのスレの住民より要点おさえてるじゃんw
おまえらも見習えよ

**デフォルトの名無しさん** · 2023/03/13(月) 11:54:44.62

Qiitaは秀才だらけだし
5chム板は文字通り住民がrustだし

**デフォルトの名無しさん** · 2023/03/16(木) 07:24:49.76

>>162
その記事を読んでみたが漏れもあり
>>163のまとめで十分と思った

**デフォルトの名無しさん** · 2023/03/16(木) 10:05:31.80

複オジにいちいち突っ込むのは疲れたよ
>>163見れば素人だとすぐわかる
もう騙される人もいないから注意する必要もない

**デフォルトの名無しさん** · 2023/03/16(木) 10:12:16.89

具体的に何が問題なの？

**デフォルトの名無しさん** · 2023/03/16(木) 18:23:03.08

>>174
いつもの自演だろ。
真面目な話題はワッチョイスレにしようぜ。

**デフォルトの名無しさん** · 2023/03/16(木) 18:54:09.77

オジおじ言ってたら自演
スレ荒らしが目的

**デフォルトの名無しさん** · 2023/03/17(金) 18:16:56.57

こういうコードを書くとエラーになります。
Bar を実装しているのは &T であって T ではないからだというのはわかるのですが、
どういう形で書けばいいのかわかりません。
T そのものではなく &T が Bar を実装しているという制約はどう表現すればよいのでしょうか？

trait Bar {
fn func(&self) {}
}

fn baz<T>(x: &T)
where
T: Bar, // どう書けばいいの？
{
let a = x.func();
}

struct Foo {}
impl Bar for &Foo {}

fn main() {
baz(&Foo {});
}

**デフォルトの名無しさん** · 2023/03/17(金) 19:14:05.96

>>177
✕ impl Bar for &Foo {}
○ impl Bar for Foo {}

**デフォルトの名無しさん** · 2023/03/17(金) 19:33:27.88

>>178
それは変えられない前提の部分です。
制約の付け方 (where句の書き方) を質問しています。

**デフォルトの名無しさん** · 2023/03/17(金) 19:35:54.06

どうしてもimpl Bar for &Foo {}で行きたいなら
こうするしかない

trait Bar: Sized {
fn func(self) {}
}
fn baz<T>(x: T) where T: Bar,

**デフォルトの名無しさん** · 2023/03/17(金) 19:56:30.88

いやできるが……
fn baz<'a, T>(x: &'a T) where &'a T: Bar

**デフォルトの名無しさん** · 2023/03/17(金) 19:59:29.44

なるほど、寿命を省略できないのですね。
ありがとうございます。

**デフォルトの名無しさん** · 2023/03/17(金) 20:06:51.73

>>182
Rustコンパイラからのエラーメッセージを見てる？
参照に対してライフタイム付けろと出ているはず

**デフォルトの名無しさん** · 2023/03/17(金) 20:28:03.09

寿命！

**デフォルトの名無しさん** · 2023/03/17(金) 21:08:25.10

>>183
答えを見たら全く自然なことだということは理解できるんですが
explicit lifetime というのがなんのことかすらぴんと来ない程度なんです……。

**デフォルトの名無しさん** · 2023/03/18(土) 11:19:09.17

>>185
Rustを学びたい人はまず最初に”公式”のThe Bookを読むこと
https://doc.rust-lang.org/book/

**デフォルトの名無しさん** · 2023/03/18(土) 11:40:54.04

>>186
>>177て”公式”のThe Bookに書いてあったっけ？

**デフォルトの名無しさん** · 2023/03/18(土) 11:42:47.58

lifetime 周りは書いてあるだろ

**デフォルトの名無しさん** · 2023/03/18(土) 11:53:17.34

>>188
>>181とかどこだっけ？

**デフォルトの名無しさん** · 2023/03/18(土) 11:57:09.36

>>185
ライフタイムは全てにあるが省略できることが多い
省略できないときはコンパイラがエラーとし教えてくれるのでライフタイムを付ければいい

>>186
日本語版もある
https://doc.rust-jp.rs/book-ja/

**デフォルトの名無しさん** · 2023/03/18(土) 14:05:24.60

>>190
誤訳だらけの粗悪な非公式日本語訳はお勧めしない
簡単なエラーメッセージの意味も分からないような状態なんだからまずは公式The Bookをしっかり読むべき

**デフォルトの名無しさん** · 2023/03/18(土) 16:08:20.29

「非公式な日本語訳」を「日本語版」と呼称するのはそれがあたかも公式かのように錯覚させる意図が見えるので優良誤認の疑いがある

**デフォルトの名無しさん** · 2023/03/18(土) 16:13:56.89

>>187
The Bookはクックブックじゃないからな
特定の方法が書いてるか書いてないかよりも
読んで理解してれば自己解決できる問題かどうかが重要

**デフォルトの名無しさん** · 2023/03/18(土) 17:11:12.32

日本語訳の話題は生産的じゃないのでやめよう
このスレのローカルルールは>>37の通り

**177** · 2023/03/18(土) 18:27:39.58

読んだのは日本語訳のほうの The book ですが、個々の機能はたぶん分かってると思います。
ライフタイムを省略した場合には一定のルールで補われることも知ってました。
ただ、型が満たすべき性質を書くのが where 句なので (エラーメッセージを見てすら！) ライフタイムが必要ということがぴんと来なかったというのと、
引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。

**デフォルトの名無しさん** · 2023/03/18(土) 18:38:31.92

> 引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。
英語版でも日本語版でもどっちでもいいけど 10.3 にちゃんと書いてあるよ

**デフォルトの名無しさん** · 2023/03/18(土) 19:09:39.09

whereの:の左辺に参照とか書けるのをまず知らなかったんでしょ
the Bookにそんな例無いし

**デフォルトの名無しさん** · 2023/03/18(土) 19:27:58.81

日本語版を読まなければこんなことにはならなかった
日本語版を許すな

**デフォルトの名無しさん** · 2023/03/19(日) 04:14:30.76

>>183
ラストコンパイラって響きカッコいいな

**デフォルトの名無しさん** · 2023/03/19(日) 13:06:57.80

>>193
この場合に必要なのはクックブックだろ。
せめて>>196みたいに誘導しないと。

「読んで理解すれば自己解決できる」とか、そもそも読むところも示していないのにできるわけない。読み手を無視してマウントする自慰行為にしか見えん。