結局C++とRustってどっちが良いの？ 5traits

**デフォルトの名無しさん** · 2023/06/30(金) 21:56:35.52

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

結局C++とRustってどっちが良いの？ 4traits
https://mevius.5ch.net/test/read.cgi/tech/1686046386/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/07/08(土) 09:45:26.32

>>254
>アメリカ生まれの「Security 詐欺」という経営方法が有り、
>このスレの人はそれを使っている。
>「C++は危ないんだから、それを使ってる人は馬鹿、愚か、無能」
>と。
ほんそれ

>Securityの事を言われるとそれに従わざるを得なくなる人間心理を
>悪用し、商売に結びつける詐欺商法。
その通り
USO800認証取得で金も時間も掛かるとか能率を下げさせる攻撃がまかり通ってる

>マイクロソフトがOS Updateしない人を悪人扱いするのは、
>UpdateのたびにOSを遅くして、新しいOSを買わせる手段。
これは言い過ぎ(気持ちは判る)

**デフォルトの名無しさん** · 2023/07/08(土) 09:48:22.81

>>265
どんなに優秀な人たちでもミスを必ずする

Google＆Microsoft「セキュリティ脆弱性バグの70%はC/C++のメモリ管理ミスが原因。それがRustを採用した理由だ。」
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

**デフォルトの名無しさん** · 2023/07/08(土) 09:48:50.55

>>259
>>258
>C++は実行時デバッグとなるため開発効率が低くなる
うそ
>さらにレア発生のため気付かぬまま実運用に入ってから発覚するとペナルティコストも大きい
判る
>早期にコンパイルエラーとなるRustはそれらのコストが不要となる
言い過ぎ

**デフォルトの名無しさん** · 2023/07/08(土) 09:50:07.66

>>261
お前モナ

**デフォルトの名無しさん** · 2023/07/08(土) 09:51:51.79

>>267
それはC/C++の責任ではない
馬鹿プログラマーに描かせてるのが原因

**デフォルトの名無しさん** · 2023/07/08(土) 09:56:21.11

>>270
と、これが馬鹿の思考です

**デフォルトの名無しさん** · 2023/07/08(土) 09:57:58.69

>>270
C++の欠陥のせいでセキュリティ脆弱性が多発している現実の記事
C++はメモリ管理ミスを検出すらできないためコンパイルエラーにすることができない
致命的な欠陥のあるC++を今後は捨てていこうという話

**デフォルトの名無しさん** · 2023/07/08(土) 10:49:35.84

Rustの次の言語に期待

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

メモリ確保と開放位置をきっちり考えて書けないような奴がそれをプログラム言語のせいにしてるだけだな
ここからここまでがどうなってとか理論的に構造を考えれない奴に限って言語が悪いと責任転嫁をする
そういう奴がプログラム書くな
メモリ関連だけじゃなくバグだらけのプログラムしかできない

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

間違わないやつは間違わない
は論理的ではない
エンジニアの考え方ではない

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

まあ、>>230のコードが即メモリバグを起こすかというと、そうではない
CSomeは自分しか使わない、自分はその使い方を間違えない、という条件ならたしかにおかしなことは起きない

ID:Snxto99TはこのCSomeをどう「誤用」すればメモリバグが起きるか説明できる？
できないならやっぱりザコだよ

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

間違う間違わない以前の問題として理論的に構造を考えて書けないでそれ言語せいにする奴
こうい奴はプログラムを書くな

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

話は簡単で
優秀なプログラマーはC++でもRustでも難なく使いこなすことができる

一方で事実として
C++はうっかりメモリ管理やメモリ競合でミスをしてもコンパイラが通してしまう欠陥を抱えた古い言語
Rustはその場合でもコンパイラがエラーにしてくれる点やC++にない様々な高機能を持つ進んだ言語

結論として
優秀な人たちはどちらも使いこなせるので高機能で便利なRustを使っている
高機能な言語を使いこなせない人たちがC++のみに拘る

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

>>232
>馬鹿だからミスや論理間違いを犯すのでnewやdeleteは使うな、
>となる。
make_uniqueとmake_sharedが規格に入ったから
newとdeleteを直接呼ぶ必要がなくなったから

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

優秀なエンジニアは間違わないエンジニアではなく、間違わない方法を考え、選択するエンジニア

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

fn clever_choice() {unsafe {...}}

**デフォルトの名無しさん** · 2023/07/08(土) 12:05:38.94

優秀な人しか使えないんでは何時までたっても普及しないのでわ

**デフォルトの名無しさん** · 2023/07/08(土) 12:31:12.90

現在の選択肢ベースで考えれば十分普及してるでしょ
米しかなかった時代の米食の普及率でも目指してんの？

**デフォルトの名無しさん** · 2023/07/08(土) 12:33:13.38

オレはアホなのでアホでも使える方を選びます

**デフォルトの名無しさん** · 2023/07/08(土) 13:41:39.02

開放と解放を間違えるような人が「俺は間違えない！」とか言っても無自覚バカ宣言にしか聞こえないわな

**デフォルトの名無しさん** · 2023/07/08(土) 13:56:46.11

ある意味あってるな

有名私立は服装も自由でピンク頭金髪可でピアスも開け放題
一方の馬鹿学校は制服で校則も厳しい

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

>>266
>>マイクロソフトがOS Updateしない人を悪人扱いするのは、
>>UpdateのたびにOSを遅くして、新しいOSを買わせる手段。
>これは言い過ぎ(気持ちは判る)
そんなことない。
「計画的陳腐化」や
「薬物売人の経営論（）drug buyer business economics」
などを使っていると言われている。

**デフォルトの名無しさん** · 2023/07/08(土) 14:17:48.79

>>279
古いコンパイラは対応して無い。
新しいコンパイラをまともな速度で使おうとすると、
最新パソコンに買い替えが必要となり、OSも全入れ替えが必要
となり、今まで便利に使えていたアプリの大部分が動かなくなる。
そしてアプリは廃版になっていて新しいバージョンも出てない
から買い換えることも出来ない。
Win10にすると、WinXP時代のアプリが動かなくなったりする。
もっと古いものも持ってるし。
だから新しいハードウェアは買わない。

**デフォルトの名無しさん** · 2023/07/08(土) 14:21:53.18

セキュリティアップデートなんて商売に関係なく
フリーソフトウェアでもあるだろろうがw
リスクがある状況でUpdateしない奴は悪人だよ

**デフォルトの名無しさん** · 2023/07/08(土) 14:25:44.35

>>289
パソコンが遅くなる原因の大部分は、Updateにあるんだが。
Updateしなければいつまでも高速なので買い換えないで済む。
そうするとマイクロソフトが倒産する。

**デフォルトの名無しさん** · 2023/07/08(土) 14:31:35.48

言葉だけではどっちが本当の事を言っているのか分からない。
実際のRustのコードを見れば、汚さが分かるし、
CやC++と全く似て無いことも分かる。
汚いと言うのは論理では表しにくいので、言葉では表現しにくいので
あたかも言葉だけではRustには欠点が無いかのように見えてしまう。

**デフォルトの名無しさん** · 2023/07/08(土) 14:32:02.14

>>288
踏み台にされたら皆にご迷惑が掛かるとか考えないのね
人と一切関わっては駄目だよ
ネットワークに接続しても駄目

**デフォルトの名無しさん** · 2023/07/08(土) 14:33:34.46

>>291
俺はC++ユーザだが
make_uniqueもmake_sharedもないお前のC++とは一緒にされたくない

**デフォルトの名無しさん** · 2023/07/08(土) 14:34:51.65

Rustの本を見てみたら、冒頭のOS環境として
Linux
MacOS
Windows 10
の順序で書いてあった。
まさに、オープンソースカルト左翼であることを目の当たりにした。

**デフォルトの名無しさん** · 2023/07/08(土) 14:46:14.76

>>294
じゃその「カルト」を支援しないように
「カルト」の製品は使わずに生きて下さいね?

**デフォルトの名無しさん** · 2023/07/08(土) 14:49:30.87

>>295
個人が望まなくても使わざるを得なくされてる。
個人には実質的な投票権が無い。

**デフォルトの名無しさん** · 2023/07/08(土) 14:56:05.98

ある意味この人は保護対象じゃないのかと思った

**デフォルトの名無しさん** · 2023/07/08(土) 15:08:40.55

>>296
40年前くらいの生活をすれば良い
40年前にも人は生活していた
批難するなら依存してはいけない
甘えるな

**デフォルトの名無しさん** · 2023/07/08(土) 15:14:57.62

>>298
オープンソースが無かったころの方が日本は豊かだったし、
将来も輝いており、経済も優秀だった。
オープンソースカルトが流行るに従って没落していった。

**デフォルトの名無しさん** · 2023/07/08(土) 15:19:13.13

>>299
だからその日本が輝かしかった時代の水準で
生活してね
それと相関と因果の違いは理解してね

**デフォルトの名無しさん** · 2023/07/08(土) 15:19:27.20

俺らと話しても薬物治療の代わりにはならないよ

**デフォルトの名無しさん** · 2023/07/08(土) 15:22:48.26

悔しいのお。左翼どもよ。いくら頑張っても
Rustは流行らないと言う事実は変わらないよな。

**デフォルトの名無しさん** · 2023/07/08(土) 15:32:10.56

>>302
お前はC++20の開発環境を用意しろ

**デフォルトの名無しさん** · 2023/07/08(土) 15:37:47.72

日本はIT技術者が少ないんだから、これからは世の中のOSSではない外国製のソフトからは多めに税金を取るくらいの姿勢でよい。
OSSはIT弱小国家にとっては唯一の活路でしょ。今の中央集権の先駆者総取りのIT業界は残念ながら日本には不利だ。

**デフォルトの名無しさん** · 2023/07/08(土) 16:06:29.07

Ndarray構造体を全てArcとMutexで書きかえたけどそんなに実行速度が落ちなかった。

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

>>302
大学でちゃんとソフトウェア工学なりプログラミング言語なり勉強した経験はあるん？

**デフォルトの名無しさん** · 2023/07/08(土) 16:14:43.78

>>305
スレッド間で試した？

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

>>306
俺の話は置いとけ。
Rustを作り始めた筆頭プログラマは、大学の専攻はバイオで
真菌を研究しており、真菌の生命力に見せられてRustの名は
真菌の一種から採ったんだそうだぞ。
そしてそのような工学とは縁もゆかりもない人が作った
言語を有りがたそうに崇拝しているのがRust信者なんだぞ。

**デフォルトの名無しさん** · 2023/07/08(土) 16:19:44.04

Rustの速度の見積もりが間違っているのが前から謎だったが、
数学とは縁が無い人が作ったからだったんだな。

**デフォルトの名無しさん** · 2023/07/08(土) 16:23:14.66

>>306
俺はそんなpopularな学科には行って無い。

**デフォルトの名無しさん** · 2023/07/08(土) 16:25:41.23

>>307
まだ、スレッド間は試してない。
とりあえずArcとMutexが単スレの時にオーバーヘッドが出ないかが個人的に懸念だった。

**デフォルトの名無しさん** · 2023/07/08(土) 16:34:49.31

>>304
しかし、OSSには「水源枯渇問題」が有る。
消費者の財布を水源に見立て、山の上流に置いて有る様に見立てる。
OSSが蔓延すれば、その水源が枯渇するのだ。

**デフォルトの名無しさん** · 2023/07/08(土) 16:41:49.73

水源とは何か良く分からんが、OSSでアメリカの大手ITをぶっ潰せるような仕組みを作れば日本には大きな得がある。出遅れた日本にとれる選択肢は少ない。
ビットコインのような非中央集権型のシステムを日本はITの全分野で押し進めていくべき。

**デフォルトの名無しさん** · 2023/07/08(土) 16:43:47.67

優秀でないから様々なオープンソースソフトウェアを使いこなせないのだろう
Rustのアンチ活動をしている人のレベルの低さを知った

**デフォルトの名無しさん** · 2023/07/08(土) 16:44:42.96

>>310
大学では何やってたん？

**デフォルトの名無しさん** · 2023/07/08(土) 16:47:18.72

情報系産業は資本代替性が高いとは言うが殆どそれは資本力勝負となりアメリカには勝てない
なので別の方法で勝負しないといけない
流石にここまでのビッグテック支配は居心地が悪い

**デフォルトの名無しさん** · 2023/07/08(土) 16:49:51.85

>>316
技術と言うより金の問題になっている気がするな。
金で優秀な人や企業を吸収したり、あるいは、検索エンジン用や
AI用のスパコンみたいなものを持っていたり。
いまのITは大量のプログラマやデータセンターが無いと成り立たない様になってきている。

**デフォルトの名無しさん** · 2023/07/08(土) 16:56:40.99

>>317
パブリッククラウドを国家が無償で日本国民に開放するべきだと思う。日本はアメリカの様に大規模な資本家がいないので政府主導で計算資源を国民に開放してくべきだと思う。

**デフォルトの名無しさん** · 2023/07/08(土) 16:57:28.70

AIなんかも結局はぶん回し勝負ってことで電気エネルギーを如何に大量に安価に調達出来るかが勝負となってきている
なのでマイクロソフトやGoogleは核融合発電の研究開発に躍起になっている
資本さえあればなんとでもなる世界になってしまった

**デフォルトの名無しさん** · 2023/07/08(土) 16:59:21.48

左翼がオープンソース化を進めた結果、ソフトウェアを個人で作って
売れる時代が終わってしをいました。

**デフォルトの名無しさん** · 2023/07/08(土) 17:01:20.34

>>318
沢山の人が使うと一人当りの計算リソースが減ってしまって、
使い物にならなくなる。

**デフォルトの名無しさん** · 2023/07/08(土) 17:01:33.20

ID:auRxfwEHは自分で優秀と言うくらいだから
少なくともドクター取ってるんやろね
あれだけ自分で言っててまさか学部生ってことはあるまい

でも
発言からはアカデミックな香りを感じさせないのよね
数学や工学のバックグラウンドが見えないと言うか
文系かまったく畑違いなとこから来てるのかな？

**デフォルトの名無しさん** · 2023/07/08(土) 17:10:00.07

NECや銀行とかでメインフレームを触ってた70代のおじいちゃんでしょ

**デフォルトの名無しさん** · 2023/07/08(土) 17:18:52.84

なんか山に籠もって一人でPC触ってるアマチュアって感じなんだよ正直

仕事からも学問からも遠いっていうか
自分たった一人でおうちで夢見ながら喋ってるような
批判や競争や責任からすごく遠いところに引きこもってるような

**デフォルトの名無しさん** · 2023/07/08(土) 17:58:46.48

>>320
そもそもゼロコストで無限に複製できるものを
製造個数に比例してコストが掛かる有体物であるかのように
扱っているマネタイズ方法に無理がある
俺は価格が適正値に近づいただけだと思うね

**デフォルトの名無しさん** · 2023/07/08(土) 18:05:27.13

急にどうした？
発狂してからに
支離滅裂で会話が成立してないぞ
まずは強いお薬を飲め

**デフォルトの名無しさん** · 2023/07/08(土) 18:06:54.48

>>311
スレッド間じゃないなら最適化されちゃうよ

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

Rustのライフタイムの型注釈についてちょっと真面目に資料読んでみたいんだけど「こういう時困る、だからこうしよう」的な文章しか転がってない
ちゃんと論文レベルで解説してる文章とかないですかね？

**デフォルトの名無しさん** · 2023/07/08(土) 18:32:09.99

ありませんね
次の患者さんどうぞー

**デフォルトの名無しさん** · 2023/07/08(土) 18:41:14.61

>>328
現状の公式ドキュメントとしてはたぶんNLLのRFCが一番詳しいと思う

**デフォルトの名無しさん** · 2023/07/08(土) 18:43:49.70

>>327
確認したことないからわからないけどSendしていないからといってそんな最適化するかな？

まずまったく異なる型のArcをRcへ変えてしまう無茶はしないはず
ではArcの中身のAtomicUsizeをusizeにしてしまう最適化をするだろうか
その両者の速度差はndarrayの計算覧ﾊと比べて微々ｂｽる誤差にすぎｂﾈい話だと思う
Mutexについても同様で最適化するとしたら丸ごと無くすことになるがそれは考えにくい

一方でスレッド間テストをすれば競合時のlockのwaitが起きるなどで少し遅くなる可能性はあるが
それはどのようにコードを書いても必須で避けられない正しい行為

**デフォルトの名無しさん** · 2023/07/08(土) 18:51:22.44

>>330
そうなんですか？
探してみます
ともかく“ライフタイム注釈”って“コンパイラが決定(推論)できないライフタイムを注釈する必要がある”というものらしいけど、どんな時は推論できてどんな時は推論できないのかさっぱり分からない
普通のHindley–Milner (HM) type systemとかだと論文レベルで解説文書がネットに転がっててわかるんですけど、ライフタイム注釈についてはどんな範囲では推論が可能なのかとか資料がひとつも見つからない

**デフォルトの名無しさん** · 2023/07/08(土) 18:52:33.75

日本の工学系は教授ですらIT技術の良し悪しを語る資格は無いのに。

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

このスレは各言語の特徴的なキーワードだけを参考にしている。
どっちが優れているとかどっちがゴミだとかという話は全く参考にならない。

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

>>332
論文レベルじゃないと理解できないのは困りものですね

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

>>332
lifetime elisionは別に推論じゃないぞ
borrowckとしてはライフタイムは必ず事前に注釈されなくてはならない
一部のよくあるパターンで省略を許可する、人間のためのルールがelision rules

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

Rustについて安全であるということだけを切り取って議論しているのは、現場も現実も知らない阿呆

**デフォルトの名無しさん** · 2023/07/08(土) 19:16:23.21

>>332
考え方が逆
ライフタイム注釈はコンパイラにとって常に必要
だからライフタイム注釈するのが基本しかしそれを省略することができる状況が多々あって
その省略された時にコンパイラが省略を補う規則が定められている
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#lifetime-elision
lifetime elision rules
The first rule is that
The second rule is that
The third rule is that

**デフォルトの名無しさん** · 2023/07/08(土) 19:18:56.60

>>337
それ。

**デフォルトの名無しさん** · 2023/07/08(土) 19:19:42.70

>>332
推論せんよ
だから自分で書く必要がある

**デフォルトの名無しさん** · 2023/07/08(土) 19:32:01.59

ここで説明しても無駄だよ
彼は論文レベルじゃないと理解できないんだから

**デフォルトの名無しさん** · 2023/07/08(土) 19:44:44.75

みなさまありがとうございます
ちょっと私まだ疑問が解決してないです
私の認識書いてみます
私の認識だとrustの“ライフタイム”はコンパイラが確保したメモリを解放するタイミングを決定するために必須のものだと考えています
何故なら効率のためにrustは複数の参照が同じオブジェクトを参照する事を許す“参照の貸与”のシステムを導入してるからです
なので所有権を持ちその参照が切れる前に全ての“貸与”していた全ての参照の“ライフタイム”が切れていなければなりません
コンパイラは貸し出された参照のライフタイムが所有権を持つ参照のライフタイムより長いものが有ればそれを検出し、貸借規定違反としてコンパイル時にそれを検出する事でダングリング参照の発生を防ぐシステムだと認識してます
その“参照のライフタイム”はユーザーが宣言するものではなくて本来ならコンパイラが自動的に拾うべきものだと思ってます
何故ならばrustの参照のライフタイムが「プログラマが好き勝手に自由に設定していい」ものなら結局それは“コンパイラがダングリング参照の発生を未然に検出する”システムになど到底ならないからです
少なくともユーザーが“この関数の返り値のライフタイムは引数のこのライフタイム以前に切れる”と宣言してもその宣言の妥当性をコンパイラが検証しないなら意味がありません、もちろん検証すると思います、具体的には返り値として用意された値のライフタイムがその値を作成した右辺値に現れる参照のライフタイムより長ければその時点で不当なライフタイムの宣言を検出できてそれでコンパイラは不適切なライフタイム注釈を検出できると思います
分からないのはそれなら結局コンパイラはライフタイムをやろうと思えば自分で推論できるのではないかという事です、実際rustの初期のコンパイラでは必須だったライフタイム注釈はいくつかの推論可能なケースでは省略可能になっているようです
じゃあいつダメなのか？いつどんな時なら推論がうまくいかないのかの基本的な理論がよく分からないんです

**デフォルトの名無しさん** · 2023/07/08(土) 19:52:23.40

>>342
>私の認識だとrustの“ライフタイム”はコンパイラが確保したメモリを解放するタイミングを決定するために必須のものだと考えています

ちゃうよ

**デフォルトの名無しさん** · 2023/07/08(土) 19:53:38.62

長文しか掛けんのかこいつは

全部関数など使わないで書けばライフタイム自体は一目瞭然
だが不注意な人はブロックから抜けて死んでる物を参照して使おうとする

それをコンパイラが阻止する
ライフタイムは基本的はこれだけ

これが前段階

**デフォルトの名無しさん** · 2023/07/08(土) 19:59:31.52

多分GC言語しか使ったことがないのだろう
参照がある限り値が生き続けるというぬるま湯に浸かってるから理解できない

**デフォルトの名無しさん** · 2023/07/08(土) 19:59:33.99

すいません、私が知りたい事説明するのにこれ以上短くできませんでした

**デフォルトの名無しさん** · 2023/07/08(土) 20:00:38.48

それが途中で関数が使われてると戻り値のライフタイムがわからなくなる
入力した引数と戻り値のライフタイムが関連付けられるならその様にしなければならない

仮に　a とｂが与えられて戻り値がどちらかになるのであれば

「寿命が短い方を共通の寿命」と考えることが必要になる
そうしないと死んでる奴を参照しちゃうから

それを元にライフタイムの範囲を判定してはみ出てたらコンパイルエラーにする

**デフォルトの名無しさん** · 2023/07/08(土) 20:00:57.02

発想を逆転させな？
「変数が生きている間しか参照は存在できない」

**デフォルトの名無しさん** · 2023/07/08(土) 20:08:08.08

>>342
コンパイラはライフタイム注釈の推論をしていない
>>338に公式ソースを示したから読もう！
ライフタイム注釈は原則としてプログラマーが与えるべきもの
ただし例えば1対1に対応しているような、与えなくても自明な場合に省略できる
そして省略されている時にコンパイラが機械的に補うルールが定められている
結果的にプログラムは全てライフタイム注釈されていることになる

つまりコンパイラが推論することはなく
コンパイラがすることは省略を機械的に補うことと
ライフタイム注釈がすべて揃ったプログラムに対してのジャッジ

**デフォルトの名無しさん** · 2023/07/08(土) 20:08:44.10

参照というのは実体がないと生きられないの
関数の引数や戻り値が参照だけだと実体がどれだけ生きてるかわからんでしょ？

**デフォルトの名無しさん** · 2023/07/08(土) 20:13:07.67

ライフタイム自体はコードが書かれた時点で決まってる
それがおかしくないか判定するときのヒントがライフタイム注釈

**デフォルトの名無しさん** · 2023/07/08(土) 20:22:47.98

>>349
はい、rustは型推論をしないのは知ってます
しかしそれが何故なのか分からないんです
例えばHaskellなら一才の型注釈は省略が可能です
全ての型は全てコンパイラによって推論され、型注釈を入れてコンパイルできるプログラムは型注釈を全消ししても(ただし効率のためにmtoplevel monomorphism restrictionというシステムが邪魔してくれますけどそれ外せば)必ずコンパイラが正しく推論してコンパイルしてくれます、その推論メカニズムの理論的根拠は論文として寄稿されネットにいくらでも転がってます
知りたいのはRustのライフタイム注釈は推論して省略可能だけどいつもいつも省略可能なわけではないのは、
・そもそもいつでも推論可能なわけではないので基本宣言させる、コンパイラが推論可能な限られたケースでは可能としている
・いつでも推論可能(私にはそう思える)のだけど効率を考えてそうしない(Haskell の toplevel monomorphic restrictionと同じように)
のどっちなんだろうと
そしてその話をtegulationに求めないのは必ずしもregulationは最新の研究を反映しているわけではないからです
つまり“現在のregulatinでは推論しない”という現状が必ずしも“そもそも推論などできない”を必ずしも意味しないからです
私ちょっとプログラミング言語論齧ってた事がありましてその辺の理論的背景どうなってるのかちょっと知りたいもので

**デフォルトの名無しさん** · 2023/07/08(土) 20:36:53.33

お前のお気持ち表明はいらん

**デフォルトの名無しさん** · 2023/07/08(土) 20:42:31.52

>>352
Rustは型推論します
非常に便利です

ただし間違った型推論の連鎖を起こす混乱やニワタマ問題などを避けるために
関数の引数値と返値については(ジェネリックを除き)
敢えてプログラマーに明確に型宣言させています
つまり型推論が可能な領域はもっと広いけど
意図的にRustは一定の範囲内に抑えていることになります

ライフタイム注釈についても同様で
推論可能な領域は確かに存在するけれど
意図的にRustは推論をせずに機械的な省略補完ルールの適用のみに抑えていることになります

**デフォルトの名無しさん** · 2023/07/08(土) 20:52:23.19

そして明確に型宣言することが基本である関数の引数値と返値についても
ジェネリックな型とそのトレイト境界による制限を用いることで個別の型宣言をさけることができるし
さらに型宣言の位置に「impl トレイト名」という形で静的なopaqueな型指定をしたり
「dyn トレイト名」という形で動的な型指定をすることで
幅広い型を受け付ける関数を書くこともできたり
複雑な型を返す時にそれを明示せずに済むなど
Rustでは型推論とは別のアプローチで利便性と可読性の向上に役立っています

**デフォルトの名無しさん** · 2023/07/08(土) 21:00:55.19

ChatGPTみたいなレスだな…

**デフォルトの名無しさん** · 2023/07/08(土) 21:01:52.49

>>354
そうですね
一般的には“コンパイラにできないわけではない”場合でもユーザーにあえて“注釈をつけさせる”事が非常に便利な場合があります
多分Rustのライフタイム注釈もそれだと思ってはいるんですけど、ほんとにそれで間違い無いのか文書でまとめられたものがないか確認したいんです
HaskellやRustの型推論システムはもう論文でいくつか読んだ事があるのでそのメカニズムもまぁわかります
Rustのライフタイム注釈の場合も多分同じ事ができそうだとは思ってるんですけど敢えてか何故かやってない、それが“できそう”と思ってる自分の勘違いなのか、やはり“できるけど敢えてやってない”のか、あるいは現時点の最新研究でどこまではできることが確認されているのかとかその辺の情報持ってる人いないかなと

**デフォルトの名無しさん** · 2023/07/08(土) 21:16:10.37

いやいや
関数を使う人間側が推論不可だろ

**デフォルトの名無しさん** · 2023/07/08(土) 22:06:00.43

NGでスッキリ

**デフォルトの名無しさん** · 2023/07/08(土) 22:07:59.43

ググったら理由が出てきた

基本的に関数シグネチャが変わるような事態を避けたいようだ
関数内部を変更したら推論されるライフタイムを含んだシグネチャも変わってしまう事態が起こりうる

変更で呼び出した側であちこちにボコボココンパイルエラーが出るのはプログラマ的にうれしくないので避けてる
呼び出し規約は人間が決めてそれをコードを書く側が守ると言うこと

**デフォルトの名無しさん** · 2023/07/08(土) 22:12:52.52

Rustは関数単位で色んなチェックしてるけど
その関数が「どこでどう使われているか」を材料にして検証とか推論はしないし
最初からそんなつもりはないと思う

関数を全部インライン展開して１つのmain関数にできれば理論的には全部推論できそうだけど
関数ポインタとかdyn traitを使った動的な呼び出しが絡むと多分無理
Haskellレベルの推論は動的な呼び出しが存在しない参照透過性？が前提にあるはず

**デフォルトの名無しさん** · 2023/07/08(土) 22:13:25.29

推論されたライフタイムを含むシグネチャと人間側が思ってる必要なシグネチャ（ライフタイム）と違うことが起こりうる

例えば他人が作ったライブラリのコードが変わって自分のところに波及してきたら嫌だろ？
従来のはそのままで別のシグネチャの関数を作れと思うだろ？

**デフォルトの名無しさん** · 2023/07/08(土) 22:19:22.93

イヤ、ライふタイム注釈の推論に“使われる場所”まで検証する必要はないですよ
関数の返り値を作成してる右辺値を調べればそれで十分だと思います
その単位で返り値のライフタイム注釈が決定されれは、返り値が解放後に参照されるエラーが発生するか否かはその返り値を利用する呼び出し側関数のコンパイル時点で検出できると思います

**デフォルトの名無しさん** · 2023/07/08(土) 22:20:56.17

>>332
論文を探す前にチュートリアルを読みましょう

**デフォルトの名無しさん** · 2023/07/08(土) 22:24:17.70

せっかくググって答えを見つけてきたのにガン無視されてる…