Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

**デフォルトの名無しさん** · 2024/06/14(金) 08:56:27.95

聖地に向かっている者だけが地政学を信じている

**デフォルトの名無しさん** · 2024/06/14(金) 09:19:59.81

>>109
現在進行形だけどC/C++が絶滅するわけじゃなさそう

**デフォルトの名無しさん** · 2024/06/14(金) 10:01:07.05

>>115
C++のロードマップを見てくると良いよ

**デフォルトの名無しさん** · 2024/06/14(金) 11:03:03.69

今考えられてるアノテーションではmaybe safer C++になるだけで根本的にsafeではない

既存資産を活用するという最大のメリットを捨てて非互換新言語を作れば可能だけどRustがある現状で誰もそんな事に投資しないから実現不可能

**デフォルトの名無しさん** · 2024/06/14(金) 11:28:58.36

>>117
carbonとか完全に忘れてたわ。あれ絶対c++やRustより先に無くなるやろ

**デフォルトの名無しさん** · 2024/06/14(金) 17:00:20.45

https://imgur.com/a/layer-A7vGJjY
使い分けは
こんなイメージ

**デフォルトの名無しさん** · 2024/06/14(金) 17:29:32.96

C++を安全にしようとすると標準ライブラリの各インターフェースから全て作り直しとなり
標準でないライブラリも同様なので既存のコード資産は使えず全面書き直しとなってしまう
それだけでは済まなくて互換性のない言語仕様も取り入れないといけない
なんとか手間暇かけてそこまで頑張って安全なC++ができあがっても何の意味もメリットも無くなってることに誰もが気付いた

**デフォルトの名無しさん** · 2024/06/14(金) 17:31:19.78

色使いが目にunsafeすぎる

**デフォルトの名無しさん** · 2024/06/14(金) 18:01:13.88

zlib-rsで移植のほぼ完了したdeflateを見ればよくわかるけどすごくメモリ安全だぞ
現実を見ろ

**デフォルトの名無しさん** · 2024/06/14(金) 18:18:31.44

>>109
ゲーム分野のC/C++は置き換わらない

**デフォルトの名無しさん** · 2024/06/14(金) 18:24:39.72

ゲームなんざ脆弱性があろうが最悪クラッシュさせりゃいいからな😁
まともなゲームエンジンフレームワークのないRustを使う意味がない
それよかクラッシュしたら人死の出るようなところのRust化が優先

**デフォルトの名無しさん** · 2024/06/14(金) 19:04:14.04

ネットワーク対戦ゲームだと細工したパケット送ると
バッファーオーバーフローで云々とよくある
脆弱性になるじゃん

**デフォルトの名無しさん** · 2024/06/14(金) 19:13:14.40

>>132
そんなつまらない欠陥じゃなくてC++ではなくRust選ぶ利点になりえる脆弱性を言ってよ

**デフォルトの名無しさん** · 2024/06/14(金) 20:42:46.16

今すぐ物を作るのは損
10年後20年後に作れば得
これがインフレだが
本当はどちらか一つだけ選ぶのは損で両方選ぶのが得だと思わないか

**デフォルトの名無しさん** · 2024/06/14(金) 21:29:25.97

>>133
あなたがつまらんかどうかが評価軸じゃないので

**デフォルトの名無しさん** · 2024/06/14(金) 22:51:10.89

>>134
>今すぐ物を作るのは損
>10年後20年後に作れば得
>これがインフレだが

違う
前提が間違ってるので議論が成り立たない

**デフォルトの名無しさん** · 2024/06/14(金) 23:07:33.93

C++書くのダルイんよ
Rustのゲームエンジン来るの待ってる

**デフォルトの名無しさん** · 2024/06/14(金) 23:46:55.69

ゲームはまずdirectxやopenglとかがrustで書き直されないことには何も始まらんと思うわ

**デフォルトの名無しさん** · 2024/06/15(土) 00:13:27.25

この板はプログラムを作らない人のための板ですね

**デフォルトの名無しさん** · 2024/06/15(土) 00:24:57.03

作ると断言するが、時の指定まではしていない

**デフォルトの名無しさん** · 2024/06/15(土) 04:55:57.02

>>138
WebGPUの参照実装であるwgpuを知らんのか。
ライブラリ使う側のIFはだいぶsafeだよ。
まぁ、バックエンドは結局、valkanやOpenGLになるけど。

**デフォルトの名無しさん** · 2024/06/15(土) 06:54:41.07

>>138
それらは書き直されてもunsafeばっかになって意味ないだろ

**デフォルトの名無しさん** · 2024/06/15(土) 07:07:04.66

OSのシステムコールだって生ポインタを渡したりunsafeな仕様だけど
Rustはsafeなインターフェースのライブラリとして提供して安全に使われているよ

**デフォルトの名無しさん** · 2024/06/15(土) 08:12:25.38

AIに組み込まれた検閲による命令拒否を打ち消してあらゆる種類の質問に応答できるようにする「アブリテレーション」とは？
2024年06月14日
※自分の身近な人の嘘や陥れようかが話されたことと実際の動き【動画撮影含む】っを解析すれば判明
スポーツで動的シミレーションなどをする不正をしているや審判の判定がおかしいも判明
日常生活の動きも同時に併用されればボイス・トォ・スカルを使用しているかが判明

スマフォにAIが搭載されるので容易に判定
120フレームと8ｋ【人間の網膜の解像度と同じ】あればかなり制度が上がる

相手の望まない手助けは数週間持続する高いストレスを与える！
2024.06.13
↕サイコパスはどう考えるのかな
使えない人」を排斥するとき周りの人の心は痛みにくいと判明
2021.05.22 SAT
ネット上で問題発言をする人は、暗い性格特性「ダーク・トライアド」かもしれない
2021.04.02 FRI
ナルシストは他の人よりも早くCEOの地位にたどり着く
2021.02.09 TUE
つい被害者を責めてしまう「公正世界仮説」とは何なのか？
2019.07.22 MON
「無能」でもOK？　社会的地位の高い人ほど信頼されやすい理由とは
2019.06.02 SUN

**デフォルトの名無しさん** · 2024/06/15(土) 08:12:46.55

「問題を指摘する人」に問題があると思い込む心理バイアス「自発的特性転移」が陰謀論を生んでいるという主張
2024年05
悪いニュースを伝えた人は理不尽に嫌われてしまうことが明らかに
2019.05.17
「恋人がサイコパス」だった時の見分け方とは
2018.12.09 SUN
ロンドン市民の娯楽だった？！近代イギリスの公開処刑
2023/12/17
スラップ訴訟
>>ある程度の発言力や社会的影響力のある、社会的に優位といえる立場の者が、特に発言力や影響力を持たない相対的弱者を相手取り訴訟を起こすこと。
巨大IT企業から「法的措置をちらつかせる停止通告書」を受け取った場合の対処方法とは？
2024年02月01日 08時00分

**デフォルトの名無しさん** · 2024/06/15(土) 10:23:21.15

サイバーエージェント、画像認識できる75億パラメーターの日本語LLM公開　商用利用OK
サイバーエージェントは6月13日、日本語大規模言語モデル（LLM）に画像認識機能を追加した大規模視覚言語モデル（VLM）「llava-calm2-siglip」を公開した。

「ChatGPT」画像を見ながら人間みたいに話せる新機能、今後数週間でリリースと予告
OpenAIは6月14日、同社の公式Instagramアカウントを通じ、ChatGPT（GPT-4o）に音声と映像を同時に理解する機能を追加し、今後数週間以内にリリースすると発表した。

画像生成AI「Stable Diffusion 3 Medium」公開　プロンプトの理解力が上がり、リアルな画像が生成可能に
Stability.aiは6月12日、同社が開発する画像生成AI「Stable Diffusion 3」シリーズの最新モデル「Stable Diffusion 3 Medium」を発表、無償の非商用ライセンスおよびクリエイターライセンスの下で利用可能だ。
サイバーエージェント、画像認識できる75億パラメーターの日本語LLM公開　商用利用OK
サイバーエージェントは6月13日、日本語大規模言語モデル（LLM）に画像認識機能を追加した大規模視覚言語モデル（VLM）「llava-calm2-siglip」を公開した。

「ChatGPT」画像を見ながら人間みたいに話せる新機能、今後数週間でリリースと予告
OpenAIは6月14日、同社の公式Instagramアカウントを通じ、ChatGPT（GPT-4o）に音声と映像を同時に理解する機能を追加し、今後数週間以内にリリースすると発表した。

画像生成AI「Stable Diffusion 3 Medium」公開　プロンプトの理解力が上がり、リアルな画像が生成可能に
Stability.aiは6月12日、同社が開発する画像生成AI「Stable Diffusion 3」シリーズの最新モデル「Stable Diffusion 3 Medium」を発表、無償の非商用ライセンスおよびクリエイターライセンスの下で利用可能だ。

**デフォルトの名無しさん** · 2024/06/15(土) 11:03:47.63

>>143
それなら既存のRustラッパーでよくね？

**デフォルトの名無しさん** · 2024/06/15(土) 12:50:26.14

根っこの技術がc/c++製でガワだけrustで、それでc++を置き換えたと言えるのか？

**デフォルトの名無しさん** · 2024/06/15(土) 12:55:07.64

>>148
置き換える意味があるかないかの問題でしょ
ほぼシステムコールなグラフィックAPIのRust実装の有意義性はあるのか

**デフォルトの名無しさん** · 2024/06/15(土) 13:06:53.11

>>148
根っこを捨ててpure Rust で再構築したとして
それは置き換えたんじゃなくて
別のものを似せて造り治しただけじゃないのか

**デフォルトの名無しさん** · 2024/06/15(土) 13:08:57.41

>>149
完全に pure Rust の OS があったとして
その上で動くアプリケーションは全て Rust で描かないといけない世界が良いのか
Rust OS の上でも C/C++ で開発したい(API は C 相当)のかで意見が変わる

**デフォルトの名無しさん** · 2024/06/15(土) 13:33:19.67

完全に純粋に一人で打席に立つことは
そいつの年収やそのカネの所有権を定義するのに必要みたいな感じでしょ

**デフォルトの名無しさん** · 2024/06/15(土) 15:03:07.44

勘違いしてる人が多いようだけど
Rustの目的は全てをRustで書くことではなく安全にすることなんだよ
だからOSシステムコール呼び出しもRust(と最小限の各アーキテクチャ毎のレジスタ積み等)で頑張るのではなくCで書かれたlibcを用いている
つまりRustのunsafe部分を最小限にするとともに、unsafeだが枯れて安全なlibcを活用している

**デフォルトの名無しさん** · 2024/06/15(土) 15:11:35.25

勘違いしてんのはここでまともなRustの話ができると思ってるお前だよ

**デフォルトの名無しさん** · 2024/06/15(土) 15:51:53.03

概論でいいんならこれ貼るよ

オブジェクト指向を学ばなかった話
https://qiita.com/adaiimps/items/e04ae03371435aeffe87

**デフォルトの名無しさん** · 2024/06/15(土) 15:54:39.14

自分は pure Rust に全然拘っていないし
むしろ unsafe 大好きだが
pure Rust に拘ってる人や
unsafe 絶対無くせって言ってる人も居るのを知ってる
後者は基地外

**デフォルトの名無しさん** · 2024/06/15(土) 16:13:09.69

use std::io::{self, BufRead, BufReader};
const FULL_BITS: u32 = (1 << 26) - 1;
fn main() {
　let mut shortest: Option<String> = None;
　for line in BufReader::new(io::stdin()).lines() {
　　let line = line.unwrap();
　　let mut bits = 0;
　　for b in line.as_bytes() {
　　　let index = match b {
　　　　b'A'..=b'Z' => b - b'A',
　　　　b'a'..=b'z' => b - b'a',
　　　　_ => continue,
　　　};
　　　bits |= 1 << index;
　　}
　　if bits != FULL_BITS {
　　　continue;
　　}
　　if let Some(ref shortest) = shortest {
　　　if shortest.len() < line.len() {
　　　　continue;
　　　}
　　}
　　shortest = Some(line);
　}
　if let Some(shortest) = shortest {
　　println!("{shortest}");
　} else {
　　eprintln!("ERROR: no matched lines");
　}
}

**デフォルトの名無しさん** · 2024/06/15(土) 17:55:06.95

ソースコードのコピペで止まるスレ

**デフォルトの名無しさん** · 2024/06/15(土) 20:29:16.21

ソースコード貼るなんて暴力ですよ！

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

コピペしただけなんだけどね

http://mevius.5ch.net/test/read.cgi/tech/1691038333/6

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

>>156
unsafeは好き嫌いというよりも
最下層のCPUとメモリもしくは境界のFFIで必須な存在とみるべきではないかな
ただしそこだけにunsafeを閉じ込めて一般プログラマーはsafeなインタフェイスのみを使う

**デフォルトの名無しさん** · 2024/06/15(土) 21:10:47.55

一行のコードも書かずに形而上学みたいにプログラミングを学ぶ贅沢はいいね

**デフォルトの名無しさん** · 2024/06/15(土) 21:54:03.45

Rust「で」作るんじゃなくてRust「を」作る秘密が知りたいんだよね
すべてのソースコードがコンパイル時に手元にあったとして、メモリの使途を解析してしまえるなんて普通は思わないからね
この点を「たまたま思いついた天才がいた」で済ませたくない

**デフォルトの名無しさん** · 2024/06/15(土) 22:10:08.33

Copy型とそうでない型。よろしい
Copy型の自動変数みたいにそうでない型もスコープを抜けると解放。それはよろしい
しかしそんなものは遥か実用に遠い

**デフォルトの名無しさん** · 2024/06/15(土) 22:29:19.17

いったい何がきっかけでメモリの使途を把握してしまえるかもと思ったか
それが分かるまでごくごくゆっくりとしか勉強しないよ

**デフォルトの名無しさん** · 2024/06/15(土) 22:33:28.01

ヒープを一切使わないパラダイムは昔に戻っただけ
スタックの安全性だけを考えてヒープはライブラリに任せる

**デフォルトの名無しさん** · 2024/06/15(土) 22:46:06.16

全部スタックでやってるって本当の話なの？

**デフォルトの名無しさん** · 2024/06/15(土) 22:51:02.34

allocaとかとっくにあったよ？

**デフォルトの名無しさん** · 2024/06/15(土) 23:22:17.89

逆のものを想像してんだけどな
スタックでなくヒープにあっても同じなのがRustじゃないの？

**デフォルトの名無しさん** · 2024/06/15(土) 23:47:36.34

参照の寿命が尽きても参照元のデストラクタは呼ばれない
だから参照元がヒープにあろうがなかろうが参照の寿命はスタックに基づいて決めてしまえば良い

**デフォルトの名無しさん** · 2024/06/16(日) 00:42:56.54

>>170
「参照元」は誤用か
参照先と言うべきだったか

**デフォルトの名無しさん** · 2024/06/16(日) 00:50:00.04

>>169
スタック上への参照とヒープ上への参照をRustでは区別しない
ライフタイムさえ満たしていればどこを指していても区別なく参照を扱う
そのため、従来行われてきた「安全にヒープ上でに領域を確保してヒープ上への参照を返す」をしなくても
ライフタイムさえ満たしていればスタック上への参照を安全に渡したり返したり自由にできるようになった
そのため、従来はヒープ上に確保していていたケースがRustではスタック上に置くことができるようになり、その点でも高速化に寄与している

**デフォルトの名無しさん** · 2024/06/16(日) 01:00:26.12

複オジのレスはいつも通り8割は嘘だな

**デフォルトの名無しさん** · 2024/06/16(日) 01:15:13.88

>>172
別にC言語だってallocaの返したポインタとmallocの返したポインタを区別しないけど

**デフォルトの名無しさん** · 2024/06/16(日) 01:25:03.80

誰が解放するか責任もなく解放忘れや多重解放を生むＣ言語は論外だろ
解放されたスタックフレームやヒープエリアを指し続けているポインタが残ったりな

**デフォルトの名無しさん** · 2024/06/16(日) 01:32:46.10

C言語と違って区別しないわけじゃないし、C言語と違って高速ってわけでもない

**デフォルトの名無しさん** · 2024/06/16(日) 01:39:48.74

C言語同様に区別しないし、C言語同様に高速なんでしょう

**デフォルトの名無しさん** · 2024/06/16(日) 01:45:22.24

そろそろ自己隔離しとけザコども

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

**デフォルトの名無しさん** · 2024/06/16(日) 03:32:45.56

へえ、コピーじゃなくて移動をデフォにしちゃうのか

**デフォルトの名無しさん** · 2024/06/16(日) 04:03:11.69

>>174
mallocで得たポインタとallocaで得たポインタは明確に区別しなければならない
mallocで得たポインタのみfreeの対象としなければならない
この区別はCプログラマーの責務でありミスると破綻する

**デフォルトの名無しさん** · 2024/06/16(日) 04:10:20.19

>>180
コンパイラが区別してくれるわけじゃないからそう書いた
今はRustコンパイラの秘密を探ってるんだし

**デフォルトの名無しさん** · 2024/06/16(日) 04:28:58.35

Rustはヒープで確保したメモリ領域も完全自動で安全にメモリ解放されるからプログラマーの負担がなくていいよね

ヒープへの参照とスタックへの参照に区別がないだけでなく
それらをたとえ混ぜて関数間で渡したり返したりたらい回しにしても安全で
もし安全でない使い方をした時はライフタイムが切れてコンパイルエラーになるから自由と安全が両立されてるね

警備員[Lv.18] · 2024/06/16(日) 04:37:34.79

解放されたスタックフレームが残って、どうやって呼び出し元に帰るつもりなんだろう。😱

**デフォルトの名無しさん** · 2024/06/16(日) 04:43:29.58

メモリはコピーじゃなくて（所有権の）移動がデフォ
所有者がスコープを抜けるとメモリは解放
所有者に別の値が代入された際もメモリは解放
代入元は所有権が移ると未初期化の扱いになる

これだけでもかなり面白いね

**デフォルトの名無しさん** · 2024/06/16(日) 04:50:45.28

>>183
C/C++/Rustすべて関数が呼び出し元に戻るときにスタックフレームは自動解放されます
もしその破棄されたスタックフレーム上を指すポインタ(参照)がどこかに残っていた場合、
C/C++ではそのポインタ使用でそこをアクセスしてしまい気づかないバグや穴となるでしょう
Rustではコンパイル時点でライフタイムエラーとなるため問題が起きないです

**デフォルトの名無しさん** · 2024/06/16(日) 05:46:32.57

正体不明のボイス・トォ・スカル
マイクロ波聴覚効果の機能より

神の声兵器は機器の場所が割れているので
ハッキング下と奪取後に器機を複製できた音を宣言していた

電磁波音波なのでむやみに器機に仕掛けると誰かが攻撃しているとすぐに設置したものは察知するが
その監視網をかいくぐるということは一発で危機をジャックしたことになる

そして機器の性能は年々よくなるので自分に行って見分けがつかないくらいになると器機使用者が幻覚を見ていると錯覚し始める

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

メモリはそれ自体は無論のこと、それを指すポインタもひとつしかないわけだ

**デフォルトの名無しさん** · 2024/06/16(日) 07:56:02.10

この発想は正直なかったわ
ひとつのメモリをあちこちから参照すればするほど高効率みたいな思い込みがあるからね

**デフォルトの名無しさん** · 2024/06/16(日) 10:08:57.93

>>167
>全部stack
そういう描き方をすればそうなるってだけで
そういう描き方ならCでも出来る

**デフォルトの名無しさん** · 2024/06/16(日) 10:11:02.64

>>169-171
CにBoxを導入すれば解決

**デフォルトの名無しさん** · 2024/06/16(日) 10:13:30.02

>>173
ほんそれ

**デフォルトの名無しさん** · 2024/06/16(日) 10:32:48.33

で、配列の要素だったり構造体のメンバだったりは「移動済み」にできない？

**デフォルトの名無しさん** · 2024/06/16(日) 10:36:59.18

とにかく&をつければアドレスを借用できて、その生存規則違反はコンパイラがはじく、と

**デフォルトの名無しさん** · 2024/06/16(日) 10:41:20.79

新参に教えといてあげると
172, 175, 180, 182あたりはすべて複製おじさん(通称複オジ)という同一人物だよ
知ったかぶりで出鱈目ばかり書いて全く反省しないという
悪い意味で有名な人ので騙されないように注意してね

**デフォルトの名無しさん** · 2024/06/16(日) 10:51:27.98

1日10行推敲するより1日1万行書いた方が数値化に貢献しやすいからしょうがない

**デフォルトの名無しさん** · 2024/06/16(日) 11:21:38.24

ボローチェッカーは作るのも使うのも難しそう
よくこんなこと可能だと思ったもんだ

**デフォルトの名無しさん** · 2024/06/16(日) 11:48:19.48

Rustの中ではつまらないというか泥臭い部分だね

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

>>196
ライフタイムについてまじめに知りたいなら（ある程度Rustには慣れた前提として）NLLのRFCを読むのをおすすめしたい
ttps://rust-lang.github.io/rfcs/2094-nll.html

そろそろこれよりいい資料は出ないもんかね……というかReferenceに明記してもらえんかね
なんか1.79でも地味にルールが拡張されたようだし

**デフォルトの名無しさん** · 2024/06/16(日) 12:23:11.10

ええっと、メモリの所有者が
・スコープを抜けること
・別の値が代入されること
・別の変数に所有権を移動させること
はもともと検出できる前提なのだよね
ボローチェッカーと言ってもその３つの組み合わせに毛が生えた程度なのかどうか

**デフォルトの名無しさん** · 2024/06/16(日) 12:27:02.82

>>198
全ての言語仕様を「仕様書」としてまとめる提案は出ているんだけど何年も動きがないんだよね……

**デフォルトの名無しさん** · 2024/06/16(日) 12:30:31.60

>>174
allocaで得たポインタfreeしてそうなコメントだな

**デフォルトの名無しさん** · 2024/06/16(日) 12:32:49.98

>>199
メモリとかアドレスとか言ってる時点で正確な理解から遠いと思う。
変数はメモリではないし、参照はアドレスではない。
処理系の実装としてはそのように対応するという想定はあるだろうけど機械語レベルの事情と言語のルールはレイヤが違う。

**デフォルトの名無しさん** · 2024/06/16(日) 12:33:46.16

>>201
機械語知ってるからそんな心配はない

**デフォルトの名無しさん** · 2024/06/16(日) 12:36:26.13

>>202
そうだね。Rustは高級アセンブラってわけではまったくないね。勘違いしてた

**デフォルトの名無しさん** · 2024/06/16(日) 12:42:20.38

代入だったり関数呼び出しの引数だったりはコピーじゃなくて移動がキホンって時点で機械語ともC言語とも違う

**デフォルトの名無しさん** · 2024/06/16(日) 12:51:16.07

>>205
代入と考えるよりもパターンマッチングと考えるといいかな
＝や引数などで複雑なパターンを書いてもマッチングしてくれるよ
それがたまたま1対1の時が昔からの代入に相当してマッチングして移動

**デフォルトの名無しさん** · 2024/06/16(日) 13:26:09.91

あえて機械語レベルでも考えるとするなら概念的には移動でも (最適化を別にすれば) ビットパターンはコピーしている。
所有権を失った変数にはアクセスできないように静的に制限されるから所有権が移動したように見える。
借用は (借用が存在している間は) 移動を許さない権利として捉えることができる。

**デフォルトの名無しさん** · 2024/06/16(日) 13:35:38.29

>>200
現状だとここを見ておくのがいいかも
https://public-docs.ferrocene.dev/main/specification/index.html
ISO 26262の認定通すために書かれたものだからかなりちゃんとしている

**デフォルトの名無しさん** · 2024/06/16(日) 15:11:48.05

>>208
C/C++はISO認定だからな
一方、Rust連中はほんぽん仕様変える(変えたい)から、そんなISOレベルの仕様書書く意味がないって感じじゃないのか

**デフォルトの名無しさん** · 2024/06/16(日) 15:51:37.66

>>209
C++ だって三年ごとに更新する制度になってるし、その間の議論でも仕様の文面をどう変えるかという形式をとる。
頻繁に変えるつもりがあるならなおさら今どうなってるのかの全体像を把握できる仕組みがないと困る。

**デフォルトの名無しさん** · 2024/06/16(日) 15:52:59.06

RubyもISOになったことあるし

**デフォルトの名無しさん** · 2024/06/16(日) 15:57:39.35

15.4:16 ??? (this should describe the order of borrowing and when the borrow is returned)

わろた

**デフォルトの名無しさん** · 2024/06/16(日) 16:23:56.88

NLLというくらいだからもともとLL

**デフォルトの名無しさん** · 2024/06/16(日) 16:49:41.43

まあ一応（ボローチェッカーというものが）可能そう

**デフォルトの名無しさん** · 2024/06/16(日) 17:20:46.77

コンパイラはプログラム中の全ての参照型に対してライフタイムを割り当てる、と

**デフォルトの名無しさん** · 2024/06/16(日) 17:45:29.17

言語にISO標準を求めるのって相当なお爺ちゃんでしょ
もうそういう時代じゃないですよ

**デフォルトの名無しさん** · 2024/06/16(日) 17:52:05.41

>>215
所有者がどのスタックフレーム(の中のどのブロックスコープ)にいるかだけの話だよな
そこより先なら参照は生きて
そこより元なら参照も死ぬ

もちろんそんな神の絶対的な視点を実行前のコンパイル時点で静的に持つことはできない
しかし各関数内での出入り(引数がinで返り値がout)は静的にわかるから
相対的な視点で有効か無効かわかることになると

**デフォルトの名無しさん** · 2024/06/16(日) 17:55:19.72

>>216
ISO 規格が必要なんて話はしてないだろ。
仕様書が要るって話をしてるんだぞ。

**デフォルトの名無しさん** · 2024/06/16(日) 18:05:26.18

複製おじさんと遊ぼうスレ

**デフォルトの名無しさん** · 2024/06/16(日) 18:43:24.33

>>218
>仕様書が要るって話をしてるんだぞ。
別に全然要らないぞ
逆になんで要るんだ？