Rust part37

公式
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 part36
https://mevius.5ch.io/test/read.cgi/tech/1779974768/

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

AIの話はAIのスレでやれよｗ

Rustのコンパイルは時間かかるっちゃかかるけど、通ったらメモリ管理のバグがないってことでもあるから、何十倍ものデバッグ時間をなくしてくれてるんだよな

>>81
どうやったらそんな理解になってしまうのか逆に興味がある
これが複おじか

>>85
とりあえず気に入らない奴に複おじって言うの、昨日の複おじっぽいムーブだな

>>75
アサーションができればできることなんだから、それで書くなりクレート入れるなりすればいいじゃん
何でもかんでも言語仕様に入れろってのはシステムプログラミング言語を知らないから言えること

そもそも動的言語じゃないんだからコンパイル時に確定させろよ

> Rustが契約プログラミングをサポートしていない
ｗｗｗ

>>82
それは71と何も矛盾しなくて、要は経路依存性があるってことだ
C++の処理系は昔のマシンでも現実的な時間でビルドできるように元々設計されているし、
長い時間と多大な労力をかけて最適化されてきた歴史がある
対してRustは最初から一貫してコンパイル時間よりも実行時のパフォーマンスや機能性や安全性を優先して設計開発されてきたために、
結果的に今更コンパイル時間の最適化をしようとしても困難なコードベースになっちゃってるんだよ

>>86
めちゃくちゃ頓珍漢なことを書いておいて
それを指摘されると気に入る・気に入らないの問題に矮小化する
これが典型的複おじ仕草

>>87
アサート -> パニック -> クラッシュ
同じじゃん

>>91
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/

>>90
全く説明になっていない
C++にもRustと同様の機能はあるが全部無視している

>>92
契約プログラミングについて知らないのはわかった

>>92
バカなんだからもう黙っとけばいいのに……

>>90-92
複おじ激おこで草

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

なるほど確かに複おじだ🤔

複おじ=Rustスレのアンチ工作員（障害者）
なるほど🤔

>>94 これなんだよな
RustにあってC++にない機能を探す方が難しいのに、>>90のC++の機能はコンパイル速度を意識して作られてるからだ！は説明になってない

処理系って言葉の意味も間違ってるしな

C++のエコシステムのモダンなデファクトって何？
crates.io並にライブラリのアップデートがすぐ降りてきたら、結局コンパイル時間は延びるのでは～と思ったんだけど

>>90
ボローチェッカーと比べたら型推論やジェネリクスなんて誤差程度だって言われてるのにスルーしてて草

ライブラリのアップデートはあまり関係なくないか

C++がコンパイル時間を速くするように開発されてきたなんて聞いたことなくて笑う

複おじと書き込んでいるスレはいつも単発ID
つまり自演である

>>107
また変な奴が湧いてて草

>>107お前やｗｗ

複乳おじさん

乳は複数あるのが当たり前だろ

Rsut応援隊って一人で何人分の自演してるんだろうな

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

Rustの話もせず荒らしばっかりしてるアンチはアンチスレに帰れよ

>>112 隔離場所から出てくるな

隔離場所ｗ

おおよそ180レスのうち、最低でも99レスを1人でやってるって
昨日自分で証明したからな

>>117
複おじはもうバレてるんだから黙ってろよｗｗ

>>117

複おじこれしか言わないよな

IDをコロコロ変えてずっと罵倒を繰り返してた自分は棚に上げてイキってて草

昨日途中までバレてなかったのにバラされたのが気に食わないんだろ
ずっと同じ奴に粘着してスレまで跨いで同じ悪口言い続けてバレないと思ってたのがすごいけど

Rustが依存型をサポートしていない為に起きた悲劇

Rustの話を一切しないくせに自分が正しいと思ってる複おじさんｗ

そんなにIDコロコロ変えて顔真っ赤にするぐらいなら
最初からあんなことやらなきゃよかったのに・・・

>>122
お前ってそれっぽいことをテキトーに書き散らしてるだけだよな結局

>>124
複おじ、なおも言い訳する模様ｗ

どれだけ言い訳したところで粘着荒らしだという事実は変わらんのにな

元々「参照はライフタイム制約を受けない」「任意の参照をその関数に与えて使うことができる」とか吹いてた奴だからな
いかに荒らしと思われたくなくても、複おじには語れるほどのrust知識はありませんw

'static はライフタイムとは関係がないとか、どんなスレッドでも先に死なないことを保証できるとかも言ってたな
とにかく何の知識もないくせに知ったかして、指摘されたら粘着荒らしになっただけの奴だから

>>124 複おじ一人でどれだけ伸ばしてんだよ
Rustの話しない奴は出て行っていいよｗ

障害者は自分の障害を理解できない
何度も同じことをする
周りは学習してるにも関わらず

上げる奴が出る度に複おじが出てたから、上げない方が無難かもな

1.97.1が出てたけど、.1リリースなんて久々じゃね

>>133
1.96.1出てただろ

脆弱性修正したやつあったな

>>134
また荒らしが出るからあんま上げんなよ

572 デフォルトの名無しさん sage 2026/07/01(水) 01:14:29.65 ID:E4CfZuIc
Announcing Rust 1.96.1
https://blog.rust-lang.org/2026/06/30/Rust-1.96.1/

573 デフォルトの名無しさん sage 2026/07/01(水) 02:21:36.27 ID:5WKZWNdO
原因が辛いな

CVE-2025-15661
Updated: 2026-06-23
Title: libssh2 - Heap Buffer Over-read via sftp_symlink() in sftp.c

CVE-2026-55200
Updated: 2026-06-18
Title: libssh2 - Out-of-Bounds Write via Unchecked packet_length in transport.c

Cのせいにするなとか被害妄想してる奴が湧いたアプデだろ

sshもRustで書き直すしか

おじいちゃん起きたのね

複オジが逆認定するようになったのか
書いてる内容バレてるのにな

複オジが不要にスレ伸ばすときは
その直前の恥ずかしいレスを流したいとき

ID:S/Q9GBk8, ID:bhJjxK5U, ID:PQcA2rQz, ID:9maZOq/z, ID:csslsvGN, ID:tnY5WOXG, ID:nqHGciLl, ID:3wFsDlQx

今日の複おじID

>>141
これ

だから複おじはスレ上げたがる

その脆弱なlibsshをRust化すべき

授乳してくる

複オジは荒らしでかつIDコロコロするから印象が悪い

Rustアンチの障害者
脳みそC++

>>147
もしかして複おジ

>>149
何言ってんだこいつ

>>145
既存資産が一斉に入れ替わらんのはしゃーない

Rustは書きやすいからいいわ
Pythonくらい当たり前になっていい

Pythonで書いて、AIにRustへ移植させた方がいい

あっちこっちのスレが複おじに汚染されてるな
伸びてるスレは特に

自分が気に食わない奴を雑に複おじ認定してるだけだろ

Pythonで書いてRustに移植させるとか無駄すぎる
最初からRustで書けばいい

慣れてしまえば制約がキツイと思い込んでいたRustがほとんど自由に書けることに気付く

自然とイメージできるようになるよな

Rustはかなり自由
どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる

>>159
また複おじがめちゃくちゃ言ってるな

もう放っとけよ、前スレからずっと同じコピペで荒らしてる奴だし

>>159
まあそう思うならRust書いてみたら？
入門書のリンクも貼っといてやるからさ
https://doc.rust-jp.rs/book-ja/

>>159
それは出来て当たり前
出来ないことは手元にある値の参照を返すことだけ

ライフタイムについて知らないド素人もおるんやなあ

>>163
出来て当たり前じゃなくて、同期処理してる時だけだぞ

同期処理してれば当然できる
親の方が子より長生きで当然

非同期だとできないこともある
親の方が子より長生きとは限らない

非同期でも>>159の文章は必ず成り立つ

>>167
ArcやRcも参照に入れればそうやな

参照カウント式の管理を「参照」だけで語るのは流石に無理かな
それも「必ず」と言ってしまってるわけで

関数って呼ばれるものの幅って結構広いからね
たぶん>>167の想像にないものがある

そもそも参照って曖昧にせずに借用って言えば解決する

cargo check通れば安全と同じこと言いたいんじゃね

>>159の関数がasync関数でも成立してる

流石に色々無理が生じてきてるなあ

>>168
ArcやRcは参照ではなく所有

>>172
どんなテストでもツールでもそれだけを妄信しちゃいかんのにな
「必ず」とか言い出す奴はだいたいダメ

>>159は必ず成立する
反例はない

関数の範囲をできるだけ狭めて、参照の範囲をできるだけ広げれば、はい

定義を都合よく曲げるのはよくない

参照は&Tだろ
関数はfnだろ
async fnでも同様に>>159は成立

いかなるライフタイムでもと言い切ってるからなあ
それだと成立しないと思われる
「コンパイルが通れば」みたいな言ってない条件を勝手に追加してそう

「どんな参照でも必ず返せる」は「いずれかの参照なら必ず返せる」とは真逆の意味なんでなあ
全部返せないと成立しない