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/06/07(水) 15:54:04.41

>>564
あなたは、そうやって、ここで、市場調査をして、次なる改良言語のネタに
したいということですね。
帰れ。

**デフォルトの名無しさん** · 2023/06/07(水) 16:20:31.76

書きやすいか否かという話より、rustは意外にタイピング量は多い思想は考え直してほしい。
std::fmtなどの「::」だとか引数名・変数の後の型の「:」だとか、むろんmutも、戻り値の「->」もなぜ引数の「:」と戻り値の「->」を同じにしなかったのか？思想面が分かる人に教えてほしい。
ほかにもなぜマクロ呼び出しに「!」をいちいち付けるのかとか、関数はfnやpubで省略しているのに？アトリビュートも#[xxx]と異様に見える。なぜ@xxxでは駄目だったのか？
まあセミコロンはC/C++からの移行を重視したのだろうけど。言語をディスってる訳じゃなく完全論破されることを願う

**デフォルトの名無しさん** · 2023/06/07(水) 16:59:17.90

細かい構文は互換性やらが重視されて一定の思想が徹底してないことも多いでしょうよ
暇ならissue掘り返してみればいい

とりあえず::はC++由来でattributeはC#由来

**デフォルトの名無しさん** · 2023/06/07(水) 18:36:58.20

Rustが難しいと感じるのは経験不足だと思うわ
困難に立ち向かった経験が少ない

**デフォルトの名無しさん** · 2023/06/07(水) 18:50:18.58

>>572
マクロ呼び出しに「!」を付けるのはコンパイラと人間の両方がマクロ呼び出しをすぐに識別できるようにするため
コンパイラの実装方法によっては無くすことは不可能ではないだろうけど効率が悪くなるし実装も難しくなる

最初は俺も無いほうが良いと思ってたけど
「!」をつけないといけないから不必要にマクロを作らなくて
結果的にメンテしやすいコードにつながってるので考え方変わった

**デフォルトの名無しさん** · 2023/06/07(水) 19:54:20.54

>>572
タッチタイピングできない人？
もしくはVSCode使ってない人？
文字数なんて気にするやつ初めて見たぞ

::はC++由来
->はHaskell由来だよ
マクロの!や?はおそらくRuby由来だが別の意味で使ってる
#[]はわからん

**デフォルトの名無しさん** · 2023/06/07(水) 20:20:10.95

>>576
煽るなら最低限公式ドキュメントの内容はすべて頭に入れてからにしたまえ
https://doc.rust-lang.org/reference/influences.html

>>572が言いたいのはTypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
trait boundとの曖昧性が生まれる状況があるのかなと思ったが、ちょっと具体例が思いつかないので違うかも

**デフォルトの名無しさん** · 2023/06/07(水) 21:01:38.64

というかRustは元々めっちゃタイプ数気にする系言語だったんだよねむしろ
1.0以前にはreturnがretだった頃もあった
今日まで残るfnとかimplとか、比較的新しいdynもそうだが
実際かなり略したがりな言語ではあると思うよ

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

>>572
あらゆる言語で同じことが言えるが
基本的な文法記述方法を考え直してほしいと要求しても
今から変わるわけがないし変わったら利用者が困る
無意味な破壊的な要求をしていることになる

タイピング量が多いといってもわずかな誤差であり
ほとんどの記述方法は既存のメジャーな言語で実績があるものと同じ
現在のメモリCPU開発環境からも余裕で許容される範囲でもある
個人的に気に入らないと主張しているのと変わらない

**デフォルトの名無しさん** · 2023/06/07(水) 22:23:55.97

記述方法が気に入らないのであれば
自分で変換器を作ればいいだけなのでは?

**デフォルトの名無しさん** · 2023/06/07(水) 22:42:25.08

>>577
>TypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
基本的には視認性の問題
TypeScriptも関数の型を明記するときはファットアローを使ってる

**デフォルトの名無しさん** · 2023/06/07(水) 23:12:17.03

気に入らない部分くらいあってもいいだろうに過剰に攻撃的な人は落ち着いて欲しい
どんな人もある程度は興味があってきてるんだろうから建設的に話をしましょうよ
気に入らない部分も背景知ると納得できたりするしそういう情報知るの楽しいから書いてくれてる人はありがたい

**デフォルトの名無しさん** · 2023/06/07(水) 23:20:10.61

戻り値型指定の->には returns や maps to 的なニュアンスを感じられるから個人的には好き

**デフォルトの名無しさん** · 2023/06/07(水) 23:44:37.64

->ってでも実際は不要でしょ？
無駄

**デフォルトの名無しさん** · 2023/06/07(水) 23:52:00.89

>>572が、Rustの思想を考え直して欲しい、と攻撃的にスタートしたのはマズかったかもね。
戻り値の型指定がなぜ「:」ではなく「->」なのかと、素直に質問すればよかったかも。
理由は視認性の良さに加えて、C++の関数の戻り型の後置記法「-> int」と、同じ記法にしたためでしょう。
例えばCarbonでは「-> i32」と、Rustと同じになります。

**デフォルトの名無しさん** · 2023/06/07(水) 23:58:55.09

int foo() {}　C/C++前置
auto foo() -> int {}　C++後置
fn foo() -> i32 {}　Carbon
fn foo() -> i32 {}　Rust

**デフォルトの名無しさん** · 2023/06/08(木) 02:28:36.11

Cと似ても似つかない。

**デフォルトの名無しさん** · 2023/06/08(木) 02:35:35.53

嘘つき大国アメリカには、良いソフトウェアは作れない。
独占によって維持するのみ。

**デフォルトの名無しさん** · 2023/06/08(木) 02:36:59.06

日本人を大量虐殺したことを反省せず、今度はウクライナとロシア人を
殺している。
そんな国に良いものは作りえない。ずるするのみ。

**デフォルトの名無しさん** · 2023/06/08(木) 02:48:48.98

平均寿命がアメリカは日本より5歳も低いことをみんな知らない。
そんな後進国を先進国扱いしている。

**デフォルトの名無しさん** · 2023/06/08(木) 02:53:24.84

特に、githubなんかは、わけの分からんソフトを作ってる人に別の左翼が
寄付する。左翼は相互扶助で虚構世界を作るのが好き。一般需要が全く無い
ソフトウェアに大金が寄付される。
このように、左翼は日本やアメリカにあってもお互いに虚構を流し合うことで
脳内で言論統制し合い虚構世界を生きている。

**デフォルトの名無しさん** · 2023/06/08(木) 03:00:18.36

アメリカのやり口:
・需要が無いのに無理やり使わせる。
・不便なのに無料化することで構造上それしか存在しない状態になっている。
・無料化することでどんなに粗悪品でも対抗製品が現れ得ないからである。
・からくりは、検索エンジンの広告料で大金を永遠と稼ぐことで、ソフトを
　無料化し、検索エンジンを持たない通常企業の参入を永久阻止しているのである。

**デフォルトの名無しさん** · 2023/06/08(木) 03:40:00.34

うーん
やはりﾜｯﾁｮｲなしスレは放棄する他ないか

**デフォルトの名無しさん** · 2023/06/08(木) 03:57:30.29

>>592
各プログラミング言語の本スレを無関係な話で荒らすのはマナー違反なので止めなさい
この一線だけは守りなさい

**デフォルトの名無しさん** · 2023/06/08(木) 04:06:08.75

>>594
アメリカは、基本ルールを守ってないので個別製品の話にまで進まない。
中国の知的財産権違反や著作権違反、不正コピーを言う前に、アメリカこそ、
まずは、基本ルールを守らないと。

**デフォルトの名無しさん** · 2023/06/08(木) 04:07:01.06

アメリカは基本ルールが守れて無いのに、Rustの仕様なんて語る権利が無い。

**デフォルトの名無しさん** · 2023/06/08(木) 04:10:05.28

要は、アメリカは人殺しが刑務所で書いた本が売れて億万長者になっているようなものだ。

**デフォルトの名無しさん** · 2023/06/08(木) 07:29:01.96

C言語の戻り型の前置記述だとC++で色々と不便なことがわかり
C++11では戻り型を"->"により後置できるようになった
ラムダ式でも戻り型を指定する時に同じく"->"で後置する
つまりC++11の時点で"->"による戻り型の後置記法が導入されている
そして>>586のようにRustとCarbonもC++11の"->"を踏襲している

**デフォルトの名無しさん** · 2023/06/08(木) 08:51:14.64

他言語とか視認性置いておいてもfn f(x: T): Uは一貫性ないんだよな
Tはxの型だがUはfの型ではないわけで
:の左辺が名前で右辺が型という原則に従うなら fn f: (x: T) -> U となるはず

**デフォルトの名無しさん** · 2023/06/08(木) 08:52:05.56

うちはインターンの女子大生すらRust使い始めたわ
ﾍﾟﾁﾊﾟｰには辛い世界になっていくだろうな

**デフォルトの名無しさん** · 2023/06/08(木) 09:22:42.20

>>572
お爺ちゃん🥺

**デフォルトの名無しさん** · 2023/06/08(木) 13:15:19.62

>>599
左辺が式だと思えば筋は通るやん？

**デフォルトの名無しさん** · 2023/06/08(木) 14:14:27.48

>>572
関数を評価した結果の型と関数の型は違うものだから表現も異なる。
同じであると誤解するような説明がどこかにあるのならそれを指摘してほしい。

**デフォルトの名無しさん** · 2023/06/08(木) 14:32:27.10

隔離スレにコピペしたからあとはあっちで頼むわ

**デフォルトの名無しさん** · 2023/06/08(木) 15:00:38.73

>>602
どう見ても式ではないが
仮に式っぽい何かだとしても関数宣言にだけ特別に書けるならやっぱり一貫性はないってことになるし

**デフォルトの名無しさん** · 2023/06/08(木) 20:13:04.97

関数型言語から拾っただけで深い考えはないだろ
関数型言語は　引数　-> 戻り値　とか　引数 ->　引数　-> 戻り値でカリー化したら引数の数が減ったりするので意味は通じるけど…

**デフォルトの名無しさん** · 2023/06/08(木) 20:15:30.41

オレオレ一貫性w
全然一貫してない

**デフォルトの名無しさん** · 2023/06/08(木) 20:45:27.43

「-> 戻り型」を批判してる人は先に採用したC++に対しても批判しているの？
ML系で何十年も使われて来た実績と視認性の良さからベストな記法

**デフォルトの名無しさん** · 2023/06/08(木) 21:09:50.06

ML系は関数呼び出しにかっこを使わないし
関数定義と型注釈を分けて書くし
Cスタイルとはだいぶ違う文法体系だよね
同じ記号を使っているという以外に共通点はないと思うよ

そしてx: TはPascalスタイルの型の付け方なんですね
TypeScriptの他にもScala、Kotlin、HaxeなどがPascalに従って(x: T): Uのように戻り値型注釈をつけます
参考までに

**デフォルトの名無しさん** · 2023/06/09(金) 02:12:57.64

sigplan noticeではindentationとlexical syntaxの話は禁止だったw

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

syntaxで言うならライフタイムのsyntaxは今でも違和感あるわ。
具体的に使うわけでもない変数を定義するようなのはどうにかならんかったのか。

**デフォルトの名無しさん** · 2023/06/09(金) 18:41:37.13

>>611
型変数と同じじゃない？
あれも変数として使ってるわけじゃなく、こことここの型は同じってことを示すだけの変数なわけで

**デフォルトの名無しさん** · 2023/06/09(金) 18:57:57.14

変数として使ってないわけじゃないな
具体的なインスタンスが生成されるときに具体的なライフタイムが代入されると思うべきか

**デフォルトの名無しさん** · 2023/06/09(金) 18:59:26.79

型パラメータは変数じゃありません

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

違和感あるようにしてるんだぞ
Bad Partsはあえて汚くなるような構文を選んでる

**デフォルトの名無しさん** · 2023/06/09(金) 19:42:24.19

>>609
Haxe草
君のバックボーンはなんとなくわかったよ

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

rustのstructってなんで中身をカンマで区切るんですか？
C/C++/C#/Swiftはセミコロンだし、影響受けたとされるhaskellの直積型はスペースですよね、デフォルトでメモリースペースが最小になるように再配置されるから？
でもそれだと配列のように直線的に配置されるように感じてしまう気がするのだが

**デフォルトの名無しさん** · 2023/06/09(金) 20:32:17.49

内容の列挙だからカンマの方が自然だと思うけどセミコロンが使われがちなのは
構文解析（エラー復帰）しやすいからなのかな

let Point { x; y; } = p;
だと気持ち悪いからパターンマッチと関係あるかもしれない

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

>>618
なるほど?構文解析が楽だからという理由はある程度は納得できるが、自然と感じる理由が個人的な嗜好で何となくなのかな?
ほかにカンマを使う場面は分割代入(destructuring)があるので、structを分解するときに対称性が良いからなのかと考えたり

**デフォルトの名無しさん** · 2023/06/10(土) 08:59:06.95

cでエンディアン確認するとき

unsigned long x = 0x12345678;
for( int i = 0; i < sizeof(long); i++ ){

**デフォルトの名無しさん** · 2023/06/10(土) 09:07:47.23

cでエンディアン確認するとき

unsigned long x = 0x12345678;
unsigned char *px = (unsingned char *)&x;
for( int i = 0; i < sizeof(long); i++ ){
　fprintf(stderr, "%X ", *px++ );
}
fprintf(stderr, "\n" );

てのをrustならどー書いたらええの>

**デフォルトの名無しさん** · 2023/06/10(土) 09:44:12.87

それと同じこともできるけど、単にエンディアン知りたいだけならこんな感じで

if cfg!(target_endian = "big") {
// big endian
} else {
// little endian
}

**デフォルトの名無しさん** · 2023/06/10(土) 09:56:44.54

>>622
エンディアンと書いたのは一例で
実際用意された型にバイトデータがどう格納されてるかを知りたい
ポインタキャストどー書くの?

forとかも変なことなってるけど
条件判断と goto ラベルさえあれば繰り返しは実行できるんだが,
rustにC/C++にあるgotoとかラベルってあるの?

**デフォルトの名無しさん** · 2023/06/10(土) 10:05:08.69

>>623
その場合はtransmuteかな
https://doc.rust-lang.org/std/mem/fn.transmute.html

gotoはない
ラベルはネストしたループから脱出するためのはある

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

>>621
let x: i32 = 0x12345678;

// 直訳すると生ポインタなのでunsafe
use std::mem::size_of;
let mut px = &x as *const i32 as *const u8;
for _i in 0..size_of::<i32>() {
print!("{:x} ", unsafe { *px });
unsafe { px = px.add(1); };
}
println!();

// byte列とみなすメソッドを使うとsafe
for b in x.to_ne_bytes() {
print!("{b:x} ");
}
println!();

**デフォルトの名無しさん** · 2023/06/10(土) 10:13:46.29

エンディアン君を、ウッカリ助平と命名したい....

**デフォルトの名無しさん** · 2023/06/10(土) 10:25:42.92

>>624
>>625

**デフォルトの名無しさん** · 2023/06/10(土) 10:26:30.43

>>624
>>625
わざわざありがと
勉強になります

>>626
何ソレ?

**デフォルトの名無しさん** · 2023/06/10(土) 10:35:25.62

to_ne_bytesのneはnative endianの意味でleやbeもある
neを使ってlittle endian環境ならば
assert_eq!(0x12345678_u32.to_ne_bytes(), [0x78, 0x56, 0x34, 0x12]);
assert_eq!(0x12345678, u32::from_ne_bytes([0x78, 0x56, 0x34, 0x12]));

**デフォルトの名無しさん** · 2023/06/10(土) 15:12:50.25

テキストデータを画像にレンダリングして最終的に2値モノクロ画像を得たいんだけど
今だとどんなクレートを使うのがいいかな？
フォントレンダラはfont-rs・・・は放置されているしからfontdueとか？
2値化に影響するディザリングのオプションとかを指定できるとありがたい

**デフォルトの名無しさん** · 2023/06/10(土) 15:48:41.24

rusttypeとかab_glyphってのがダウンロード数多いみたい

**デフォルトの名無しさん** · 2023/06/12(月) 12:58:17.77

ただの思いつきだが、CやC++はメモリセーフではないだろ。ってことはプログラム中で結構無駄なメモリを消費してたりしないの？Rustはそこの所最適化されてるから究極的にはRustの方がCやC++よりも高速に動作するのでは？

**デフォルトの名無しさん** · 2023/06/12(月) 13:04:11.65

？

**デフォルトの名無しさん** · 2023/06/12(月) 14:15:17.58

ちょっと何言ってるかわからない

**デフォルトの名無しさん** · 2023/06/12(月) 16:35:03.90

メモリセーフかどうかと
メモリを無駄使いしてるかどうかに直接の関係はない

**デフォルトの名無しさん** · 2023/06/12(月) 16:47:01.05

メモリ安全性とメモリの利用効率に関係はないが、
安全性のために導入したライフタイム管理が最適化に影響する部分がないとは言えない。
依存関係が明瞭だからエイリアス解析がしやすく、
結果的に効果的に最適化しやすい可能性は高い。

しかし実行時でないと安全なアクセスであるかどうか検出が不可能な場合もあるから
それも込みで考えると Rust のほうがやや不利であると言える要素もある。
全体的な性能は互角か Rust のほうがやや遅いくらいじゃないの。知らんけど。

性能が互角くらいでより安全ならそのほうがいいじゃろ。

**デフォルトの名無しさん** · 2023/06/12(月) 18:28:52.16

メモリ安全にするために過剰なコピーや長いライフタイムになる実装をしてしまうことがあり、それをコンパイラがガードしてあげるからルールに従って書いてねってのがRustの思想だと思う。
逆に適当に書いても安全にするし出来るだけメモリ効率も配慮するよってのが他のGC言語

**デフォルトの名無しさん** · 2023/06/12(月) 18:44:13.30

そんな話一般論で語れる訳ないぞ
コードを出しな？

**デフォルトの名無しさん** · 2023/06/12(月) 20:02:49.65

>>636
そんなことはなくRustも適切な方法を選べる
そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん

**デフォルトの名無しさん** · 2023/06/12(月) 21:33:36.66

>>639
ここではメモリ安全性が実行効率に寄与するわけではないというのがトピックなので
安全性 (自動的な安全性の検証) を捨てることも出来るというのは話題の外。

**デフォルトの名無しさん** · 2023/06/12(月) 21:39:50.33

意味のない議論がほんと好きだねー

**デフォルトの名無しさん** · 2023/06/12(月) 21:44:05.58

コードが一切出てこないのが本当不思議

**デフォルトの名無しさん** · 2023/06/12(月) 21:45:00.87

>>640
Rustは実行効率を保ちながら安全性もある
Rustがやや不利でやや遅いと思い込んでいる具体的なケースのコードを出してごらん

**デフォルトの名無しさん** · 2023/06/13(火) 11:32:39.43

>>639
>そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん
ややどころか、大幅に遅くなるケースもあるぞ。
俺はこれ以上指摘しない。自分で分かるかどうかが技術力の試金石だ。

**デフォルトの名無しさん** · 2023/06/13(火) 11:35:33.48

また、
　「Rustは、どんな場合でも、効率を下げずに少数の関数の中に unsafe 箇所を閉じ込められる」
というのも嘘。

**デフォルトの名無しさん** · 2023/06/13(火) 11:43:16.69

ならお前はこれ以上指摘すんなよ未来に渡って

**デフォルトの名無しさん** · 2023/06/13(火) 11:53:41.84

>>644
デタラメ屋さんまた来たのか

**デフォルトの名無しさん** · 2023/06/13(火) 14:38:11.20

>>647
俺は一般プログラマより生まれつきだいぶ頭がいいので、通常のプログラマには
分からないのかも知れない。

**デフォルトの名無しさん** · 2023/06/13(火) 18:50:01.53

>>648
ぷw

**デフォルトの名無しさん** · 2023/06/13(火) 23:11:29.90

>>648
だいぶ頭良いプログラマーはこんなとこ来ねーからw

**デフォルトの名無しさん** · 2023/06/14(水) 17:49:14.80

可変長のバイナリデータを扱う場合の型ってやっぱvec<u8>あたり？
独自の型を定義する以外に他によさそうな型って何かあるかな

**デフォルトの名無しさん** · 2023/06/14(水) 20:22:43.85

>>651
Trait std::io::Readのrequired methodが
fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
であるように&[u8]でアクセスできれば何でもよい
そのうち可変で最もお手軽なのはVec<u8>
Trait std::io::Readのprovided methodの一つ
fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize> { ... }
もVec<u8>の可変参照を渡す仕様

**デフォルトの名無しさん** · 2023/06/14(水) 20:28:50.68

よくわからないんだけど
ライフタイムの例でよく出てくる関数の引数a,bを同じライフタイムの指定にするってやつは
どちらが選ばれるか分からないから使わないほうも長い方の寿命に合わせて残しておきますと言う解釈でいいの？

**デフォルトの名無しさん** · 2023/06/14(水) 20:57:15.56

>>653
その例となってる関数のコードくらいは書けよ

**デフォルトの名無しさん** · 2023/06/14(水) 23:11:40.84

たぶんこういう例のことかな
fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
if s1.len() >= s2.len() { s1 } else { s2 }
}
ここである呼び出しの時に
s1が'staticでs2が'x (!= 'static)だったとすると
'aとして寿命が短い'xの方が採用される
ただしこれはcovarianceである&Tの場合の話
invarianceである&mut Tの場合は逆になるので注意

**デフォルトの名無しさん** · 2023/06/14(水) 23:20:37.20

>>652
サンクス。やっぱvec<u8>が無難か
読みやすさだと構造体だけど要unsafeな上に
環境依存性も出ちゃうからな

**デフォルトの名無しさん** · 2023/06/14(水) 23:43:12.09

構造体とか要unsafeとか何をしたいのかわからないが
上限を決めてもよい用途ならば
ヒープを使わずともArrayVec<u8, CAPACITY>がスタック上のみで動く

**デフォルトの名無しさん** · 2023/06/14(水) 23:49:13.19

データの一部だけ可変長とかブロック構造の個数が
可変(ブロックの中身は固定)とかね

**デフォルトの名無しさん** · 2023/06/14(水) 23:54:41.98

staticは消滅しないから実質参考にならんので無視して短い方をaとする
これは対象が2つだからであって
static 1
その他　2
ならその他2の長い方になると言う考えでいいのかな？

**デフォルトの名無しさん** · 2023/06/14(水) 23:58:17.85

もう何言ってんだよ

**デフォルトの名無しさん** · 2023/06/14(水) 23:59:42.49

>>655
ライフタイムに関しては&も&mutもcovariantなので違いはありません

**デフォルトの名無しさん** · 2023/06/15(木) 00:08:38.46

Tに対して&Tはcovariant
Tに対して&mut Tはinvariant

**デフォルトの名無しさん** · 2023/06/15(木) 08:25:03.26

>>547
OptionとOnceCellの違い

&Tを得ることをgetと呼ぶようになった
【Option】fn as_ref(&self) -> Option<&T>
【OnceCell】fn get(&self) -> Option<&T>

&mut Tを得ることをget_mutと呼ぶようになった
【Option】fn as_mut(&mut self) -> Option<&mut T>
【OnceCell】fn get_mut(&mut self) -> Option<&mut T>

空にしてTを得ることをtakeと呼ぶのは同じ
【Option】fn take(&mut self) -> Option<T>
【OnceCell】fn take(&mut self) -> Option<T>

空(default)を作成することをnewと呼ぶこともできるようになった
【Option】fn default() -> Option<T>
【OnceCell】fn default() -> OnceCell<T> または fn new() -> OnceCell<T>

**デフォルトの名無しさん** · 2023/06/15(木) 11:48:36.10

トヨタの車載OSってRUSTなんだ

**デフォルトの名無しさん** · 2023/06/15(木) 18:17:26.02

ライフタイムもtraitも難しすぎてマジでわからん

**デフォルトの名無しさん** · 2023/06/15(木) 18:21:52.25

ライフタイムの質問してたものだけど
コードを書いてて完全に誤解していたことに気が付いた
コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
多分一般向けには流行らないわな

**デフォルトの名無しさん** · 2023/06/15(木) 18:38:09.80

ライフタイムって該当のメモリがいつまで確保されているかって話であって難しいところはなくね？
所望のタイミングまで開放してほしくないがどのようにするのが望ましいか？って話ならまだわかるが

**デフォルトの名無しさん** · 2023/06/15(木) 18:40:44.72

自明なときに省略できるせいで理解しづらくなってる気はする

**デフォルトの名無しさん** · 2023/06/15(木) 18:44:18.80

日本語がおかしかった
関数では引数に依存する戻り値の寿命がわからない
それで基本的に指定した複数の引数のライフタイムの一番短い奴に合わせて解釈する
そのライフタイムを元にコンパイル時にチェックしてダングリングを防いでる

一番寿命が短い奴に合わせてチェックしたら他はそれより長いのでダングリングが起こらないだろうと
こういうふうに言う人間があまりいないのが現状

**デフォルトの名無しさん** · 2023/06/15(木) 18:47:34.83

普通にコードを書いた時点でスコープや借用の関係で寿命は決まってる
それが範囲外になるかどうかボローチェックしてるんだけどそいつのためにライフタイムを明示してる

ライフタイムを明示してもコード上の寿命は伸び縮みしないけどエラーを見てコードを書いた人は修正ができる

**デフォルトの名無しさん** · 2023/06/15(木) 18:52:46.39

と言う解釈なんだけど今のところ
普通に違ってるかもしれない