Rust part19

**デフォルトの名無しさん** · 2023/01/17(火) 12:41:32.25

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

**デフォルトの名無しさん** · 2023/02/13(月) 10:01:54.27

>>621
＞処理に意味ある名前をつけて”意図”を伝えるコードを書くこと
つまりラベル付きブロックでいいよね
現代的なエディタならブロックは折り畳めばいいし、ラベルで名前もつけられるし
何より型推論と?演算子に任せれば済むような非本質的なエラー型の合成というノイズをメインロジックから分離できて"意図"が伝わりやすくなるので

**デフォルトの名無しさん** · 2023/02/13(月) 12:37:14.05

>>572の比較表に付け加えるとこんな感じか

関数化:
〇機能名の明示　(関数名)
×利用する変数(値)と結果の型推論
〇変数、ライフタイムのスコープ
×環境(変数)のキャプチャ
〇早期脱出
×?演算子のエスカレーション・合成

ラベル付きブロック式:
〇機能名の明示　(ラベル名)
〇利用する変数(値)と結果の型推論
〇変数、ライフタイムのスコープ
〇環境(変数)のキャプチャ
〇早期脱出
〇?演算子のエスカレーション・合成

**デフォルトの名無しさん** · 2023/02/13(月) 13:43:55.80

関数の特徴としては、
○コード記述箇所と実行箇所の分離
○再入可能性
というのがあるな。

まぁ、ブロックは記述箇所と密接に関係しているから当然の話だけど。

**デフォルトの名無しさん** · 2023/02/13(月) 13:50:02.53

ブロック式はその場でしか呼ばれないから再入可能性はそもそも必要ないね
そしてブロック式がある関数として再入可能性を保証でいいわけだから

**デフォルトの名無しさん** · 2023/02/13(月) 16:19:13.75

>>623
そういうループを使う現実的なユースケースは
通常の多次元データではなくフォルダとファイルのようなCompositeデータを扱うときだけなので
インナーループから返す値にはiを必要とせずSome(j)で十分になるように作る
もしそれができない場合でも(Some(i), None)はSome(i)に(Some(i), Some(j)はSome(f(i,j))に変換できるようにする

**デフォルトの名無しさん** · 2023/02/13(月) 16:27:32.48

>>628
勝手に様々な特殊なケースのみに限定して話をしても全く意味がない
さらに二次元インデックスi,jをjだけに折り畳めるという特殊な仮定を持ち出すのも意味がない
そしてインデックスを返す機能の話をしているのにf(i,j)を持ち出すのも意味不明すぎる

**デフォルトの名無しさん** · 2023/02/13(月) 16:46:00.57

>>624
let message = 'get_latest_unread_message {
…
break 'get_latest_unread_message Some(Foo::foo_bar(result)
…
};
とか書くわけ？

**デフォルトの名無しさん** · 2023/02/13(月) 16:47:27.73

>>629
具体的なユースケース出せないなら話にならないよ

**デフォルトの名無しさん** · 2023/02/13(月) 16:53:40.18

>>631
いくらでも様々なデータ処理があるだろ
狭い範囲の仕事しかしていないから
>>628のような何重もの特殊な仮定だらけになるのだろう
そして我々がしている議題はRustの言語機能の話がメインでそこでの例として汎用的なサンプルコードが出ている

**デフォルトの名無しさん** · 2023/02/13(月) 17:52:42.13

そもそもラベルいらんよね？（構文上必要なんだろうけど？）
ブロックに区別が必要ない場合は

>>630を例に取ると
let latest_unread_message = 'b { // 変数名がブロックが返す値を表現
break 'b Some(Foo::foo_bar(result)) // 具体例はbreak以降に表現
};

ブロックが二重三重になってるときだけそれを区別したいだけであって？

**デフォルトの名無しさん** · 2023/02/13(月) 17:53:01.42

型推論のおかげで>>626の機能を諦めれば記述量を大幅に減らせるってことなのかな？

>>630
これに、breakで一番内側の名前付きブロック名を省略する記法があれば、こんな感じに出来て、エディターで表示補完も出来るな

let message = 'get_latest_unread_message {
…
break '' Some(Foo::foo_bar(result)
…
};

**デフォルトの名無しさん** · 2023/02/13(月) 18:03:44.02

>>634
ブロックは関数と異なりリエントラントの必要性も概念もない
ブロックは関数内のその場所で呼ばれるだけだから他から不意打ちで呼ばれる対策も必要ない
ブロックが所属する関数がリエントラントを保証しているから大丈夫

そしてブロックのメリットは環境変数をそのままキャプチャできて型宣言は必要なくブロック式の結果も型推論されること
さらに？オペレータがifやmatchやループの時と同様にブロックを飛び越えてくれるからResultを気にせずに値だけの型に専念できる

**デフォルトの名無しさん** · 2023/02/13(月) 18:08:53.41

>>633
なるほどね
いっそラベルをretとかにしてしまえばクロージャっぽく見えるのか

let latest_unread_message = 'ret {
break 'ret Some(Foo::foo_bar(result))
};

**デフォルトの名無しさん** · 2023/02/13(月) 22:41:07.13

うーん、それは....ちょっと

**デフォルトの名無しさん** · 2023/02/14(火) 06:32:02.86

>>633
ラベルは必要
ラベルが付いてるブロック内でのみラベル指定breakができる

例えばforの中でmatchでアーム右辺が無名ブロックで無名breakしている既存のコードはそのブロックをbreakせずforをbreakする
しかしそれら全体がラベル付ブロックに覆われていてラベル付breakしていればラベル付ブロックをbreakできる

既存コードと互換性があり曖昧さもなく良い構文となっている
既存のloop構文からloopキーワードを抜いただけの構文である点からも自然な受け入れやすい構文拡張となっている

**デフォルトの名無しさん** · 2023/02/15(水) 22:09:51.65

同時に導入されたlet elseも便利やな
それまではif letするたびにネストがどんどん深くなっていって困るかそれを回避するために
let xxx = if let Some(xxx) = foo() { xxx } else ...と三度も変数名を書かされて悲惨だった

**デフォルトの名無しさん** · 2023/02/15(水) 23:56:03.48

どちらも長年Rustで構文的に残っていた不便な点だったから解決してうれしい

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

>>639
早速テストコードに使ったら、ifを除去出来て大変満足

**デフォルトの名無しさん** · 2023/02/16(木) 10:43:33.51

>>639
unwrap_orじゃダメなのか？

**デフォルトの名無しさん** · 2023/02/16(木) 11:19:26.94

>>642
え？！
elseの後の型は！じゃないとlet else使えないよ

**デフォルトの名無しさん** · 2023/02/16(木) 12:55:00.75

>>642
例えばこれは深さ3段だからギリだけど
どんどん深くなるのを早期continueしたい時にどうする？って話
環境問題などで別関数化も無しでね
for x in iter {
　if let Some(boo) = get_boo(x) {
　　if let Some(foo) = get_foo(x) {
　　　if let Some(woo) =get_woo(x) {
　　　　let pigs = three(boo, foo, woo);
　　　　...
　　　}
　　}
　}
}

**デフォルトの名無しさん** · 2023/02/16(木) 14:44:50.54

>>644
関数化無しの前提を置かないといけない状況を改善した方がいいのでは？
その例も普通ならxを受け取ってOptionを返す関数に簡単に抽出できるよね？

**デフォルトの名無しさん** · 2023/02/16(木) 14:59:14.48

>>645
それは無理
実際のコードだと全部揃ってから処理ではなく途中で処理しつつになる
さらにbreakによるfor抜けも入ったりする
さらに使う環境が多くてその別関数へ参照渡しまくりになる
さらに途中でエラーも返るから別関数はOptionではなくResult返しになる
つまり?はOptionに対して直接使えない

**デフォルトの名無しさん** · 2023/02/16(木) 15:15:34.23

goto >>459;

**デフォルトの名無しさん** · 2023/02/16(木) 16:37:34.02

関数を分けると?を逃がすことが出来なくなる点など含めて
ラベル付ブロック式の時と同じ話だな
いずれにせよ関数化は愚策でありlet elseによりcontinueするのが正解

**デフォルトの名無しさん** · 2023/02/16(木) 17:21:40.49

無限ループってこわくね？

**デフォルトの名無しさん** · 2023/02/16(木) 17:31:08.98

continueはforでnext()に進んで無限ループじゃないぞ

**デフォルトの名無しさん** · 2023/02/16(木) 18:48:57.26

ちゃんとしたプログラマーは無限ループになりそうなところはブレークMAXカウンターやシグナルブレイク出来るように書いてるから大丈夫ですYO！

**デフォルトの名無しさん** · 2023/02/16(木) 21:14:40.29

サーバーやデーモンなどは同じことを繰り返せるように敢えて無限ループにプログラミングする

**デフォルトの名無しさん** · 2023/02/16(木) 22:57:51.48

>>646
なるほどResult<Option<T>>でOptionだけハンドリングしたいパターンならif let使えばネストしていくわな

普通にmatch使えばいい場面だと思うんだが何かlet else使うメリットがあるの？

**デフォルトの名無しさん** · 2023/02/16(木) 23:01:01.44

>>653
matchとif letは同じ
コード書けば分かる

**デフォルトの名無しさん** · 2023/02/16(木) 23:07:53.84

ああif letの結果を受けるように書くからってことね
それ普通は使わないよね

**デフォルトの名無しさん** · 2023/02/16(木) 23:15:48.94

let foo = match get_foo(x)? { Some(x) => x, None => continue} が
let Some(foo) = get_foo(x)? else { continue };になると行数が短くなってうれしいということ？

**デフォルトの名無しさん** · 2023/02/16(木) 23:15:53.10

matchを使おうが元の問題これ何も解決しなくね？
>> let xxx = if let Some(xxx) = foo() { xxx } else ...と三度も変数名を書かされて悲惨だった

**デフォルトの名無しさん** · 2023/02/16(木) 23:17:38.28

Someの中の文字は何でもいいんだから短いスコープなら同じ名前を律儀に書く必要ない

**デフォルトの名無しさん** · 2023/02/16(木) 23:29:57.12

変数名短くしても結局3度も書かされるのは異常で改善の余地あり
それが1度で済むようになってようやく正常化した

**デフォルトの名無しさん** · 2023/02/17(金) 00:34:38.77

swiftのようにguard let ~ elseとしてくれれば
行頭見るだけでguardだとわかって良かったのにな
少し複雑なパターンマッチだとelseが埋もれてしまう

**デフォルトの名無しさん** · 2023/02/17(金) 07:21:19.98

冒頭だけで分かるよ
let x = ... ←通常
let Some(x) = ... ←elseあり

**デフォルトの名無しさん** · 2023/02/17(金) 08:35:50.31

if let って可読性悪くない？

**デフォルトの名無しさん** · 2023/02/17(金) 08:45:48.10

>>662
両方の観点から分かりやすい
普通のletではなく、ifにより条件付きだと分かる
普通のifではなく、letにより新たな変数定義付きだと分かる

**デフォルトの名無しさん** · 2023/02/17(金) 10:34:35.45

>>661
let Foo { bar, baz, … } = get_woo?.map_or_else(Bar::default(), |x| …

**デフォルトの名無しさん** · 2023/02/17(金) 10:59:52.09

>>664
その観点からはRustではrefutableなのかirrefutableなのかが一番重要な概念になる
噛み砕いて言うと条件付マッチングとなるのがrefutableで無条件マッチングとなるのがirrefutable
Foo { bar, baz, … }はirrefutableパターンだから普通のlet
Some(foo)はrefutableパターンだからif letかlet else

**デフォルトの名無しさん** · 2023/02/17(金) 11:46:57.46

>>665
おおいいね
じゃこれは？
let foo::Foo { bar, baz, … } = get_woo?.map_or_else(Bar::default(), |x| …

**デフォルトの名無しさん** · 2023/02/17(金) 12:26:34.10

>>666
letについては既に説明した通り
それはFooとBarは型が異なりエラー
型の一致は必須
struct内の略は...と3つでなく..と2つ
Bar::default()の()は付けてはいけない
型の明示が必要ないならDefault::defaultでもよい
map_or_else(Default::default, |x| …)は
map(|x| …).unwrap_or_default()と書ける

**デフォルトの名無しさん** · 2023/02/17(金) 14:50:20.18

>>667
はい残念

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

>>662
elseがある場合はmatchのほうが可読性いい
elseがない単純な場合はif letでも悪くない
ネストすると最悪

**デフォルトの名無しさん** · 2023/02/17(金) 21:58:40.37

let elseが需要の隙間を埋めてくれた

**デフォルトの名無しさん** · 2023/02/17(金) 22:52:21.88

letするたびにインデントが深くなる言語もあるぞ
そういう失敗を記憶しているおかげで、比較的成功した例を認識できる

**デフォルトの名無しさん** · 2023/02/17(金) 23:13:25.95

let elseはシンプルなケースじゃないと通常のletと見分けがつきにくい
でもシンプルなケースならlet chainでまとめた方が圧倒的に可読性高まるのでいらない子になりそう

**デフォルトの名無しさん** · 2023/02/18(土) 00:32:34.89

最初見たとき便利そうだな思ったけど意外と使わない let else
? とか unwrap_or_elseとかで事足りることが多い
あって困るような機能でもないけど

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

論駁可能性の有無で区別つくし、elseによる処理文があるのだから、let elseが見分け付かないなんてことはない
if letと同様にlet elseはエラー値を捕獲する構文ではないため、エラー処理に用いないのは当たり前で、?を持ち出す人はその基本を理解できていない
マッチングしない時にcontinueやbreakする時などは、特にlet elseが最も適している

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

たしかに
でもコンテニューやブレーク書くことが稀

**デフォルトの名無しさん** · 2023/02/18(土) 18:28:41.55

やってることは同じ早期離脱なのに
新しいバインディングを伴う場合は
breakやcontinueならlet else
returnなら主に?かlet~match
新しいバインディングを伴わない場合はifかmatch

書くのは多少楽になってもこれだけ種類があると読みにくくなる

**デフォルトの名無しさん** · 2023/02/18(土) 18:44:10.63

if letを廃止してmatchだけに統合すればすっきりする
match boolでifも廃止できる
breakとcontinueもmatch boolで括れば済むから廃止できる

**デフォルトの名無しさん** · 2023/02/18(土) 20:05:29.88

>>677
それだと'outer指定ができなくないか？

**デフォルトの名無しさん** · 2023/02/18(土) 20:16:45.16

C/C++は多重forの多重breakを持たないが状態変数などで工夫して対応できている

**デフォルトの名無しさん** · 2023/02/18(土) 20:28:10.99

状態変数とか使うぐらいならgotoの方がマシだろ

**デフォルトの名無しさん** · 2023/02/18(土) 20:45:44.21

>>679
>工夫して対応できている
これ言ったら自分の発言のブーメランになってないか？
そりゃ言語仕様に盛り込まずに工夫して対応しろってことなら、
なんだって工夫しろで終了じゃん

**デフォルトの名無しさん** · 2023/02/18(土) 20:59:41.48

いや、工夫する方が正解という信念とかは持ってなさそう
正解なんてあるわけないという結論から逆算されたムーブじゃないか

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

>>677
>>659にある3回書く問題を無視していいなら今でもmatch縛りで書けばいいよね

その方が読みやすくなる面があるのは確か

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

>>680
gotoの導入いいね
loopとforも廃止してシンプルにmatchとgotoだけで見やすそう

**デフォルトの名無しさん** · 2023/02/18(土) 21:28:03.45

デストラクタがあればgotoの少なくとも一部は許されないことが確定する
なければ雰囲気で決める

**デフォルトの名無しさん** · 2023/02/18(土) 23:00:33.44

>>675
たまたま自分で使うことが稀だからといってcontinueやbreakを要らない子扱い？

**デフォルトの名無しさん** · 2023/02/18(土) 23:56:17.68

そりゃアルゴリズムは出来合いのものしか使いませんっていうならcontinueもbreakも使わんだろうな。

**デフォルトの名無しさん** · 2023/02/19(日) 00:00:34.67

なにさ！ループの中へジャンプしたっていいじゃない！

**デフォルトの名無しさん** · 2023/02/19(日) 00:36:19.05

昔みたいに関数を長々と書く時代じゃないから
breakやcontinueは関数抽出で不要になることが多くて出番がすごく少ないんだよ

**デフォルトの名無しさん** · 2023/02/19(日) 00:45:12.81

100行関数の時代の反動で5行の処理でも関数切り出しする時代からのさらに揺り戻しで
最近はむしろ型推論に任せて明示的に型を書かないために全体が一望できる程度の30行ぐらいの関数は増えているので
breakもcontinueも普通によく見かける

**デフォルトの名無しさん** · 2023/02/19(日) 00:45:16.79

?はunwrap or return (Err/None)
.unwrapはunwrap or panic
欲しかったのはこれらと同じように使える
unwrap or breakとunwrap or continue

でも出来たのは新しい構文のlet elseでしたとさ

**デフォルトの名無しさん** · 2023/02/19(日) 01:10:22.21

https://rust-lang.github.io/rfcs/3137-let-else.html#examples
RFCのExamplesなんてbeforeもafterもlet else以前の問題
typestate使ってtry_fromとnewを用意するというrustのidiomを使えば良いだけなのに

実施して当然のリファクタリングもやってないようなコードを前提に議論が進んでるのを見ると悲しいね

**デフォルトの名無しさん** · 2023/02/19(日) 06:25:34.88

>>692
それはRFCつまり単なる叩き台
無意味に長いサンプルだからThe Rust Referenceでは短く書き換わっている
typestateは適用できないケース、不向きなケース、向いているがそこまでやらなくてもいいと判断するケースがあり
それ以前にlet elseとは無関係だから持ち出して批判するのは揚げ足取りにしか見えない

**デフォルトの名無しさん** · 2023/02/19(日) 07:06:24.11

>>686
稀と言ってるだけ
確かに俺はアルゴリズム博士じゃないね

**デフォルトの名無しさん** · 2023/02/19(日) 08:40:02.37

特定のサンプルに対してこう書けるから要らないと主張したり、
自分は使わないから要らないと主張したり、
それらの主張は何の意味もないことにそろそろ気付かないと

**デフォルトの名無しさん** · 2023/02/19(日) 09:32:40.87

関数の「切り出し」とか行数で語ってるのとかまだまだ幼いなってオモタｗ
最近の流れじゃあ>>689サンだけ一個上のレベルにおるな

**デフォルトの名無しさん** · 2023/02/19(日) 10:03:16.21

>>685
> デストラクタがあればgotoの少なくとも一部は許されないことが確定する
ならtry〜throw〜catchで

**デフォルトの名無しさん** · 2023/02/19(日) 10:56:50.58

>>696
君はまだ参照の持ち回りや明示的に型を書くことのデメリットを理解せずになんでもかんでも関数にするレベルにいるんだね

**デフォルトの名無しさん** · 2023/02/19(日) 11:10:19.79

相手すんなよ、どう見ても>>689の自演だろ

**デフォルトの名無しさん** · 2023/02/19(日) 11:13:57.20

>>693
最終的なRFCはたたき台じゃないよ
RFCは議論の進行とともに更新された上で提案された機能を採用するどうかを判断するための公式ドキュメントとなる
採用決定後に書かれるリファレンスとは全く役割が違う

**デフォルトの名無しさん** · 2023/02/19(日) 11:21:38.84

>>689
関数切り出しでは出来ないこともあれば無駄な記述が増えることを含
めて様々なデメリットもあるから、
それらをクリアできて上回るメリットがある時に絞って使い分けるとよい
あと関数切り出しすれば何でもcontinueやbreakという制御構造を無くせるわけでもない
そして君の使い方だと出番がないからそれらが不要だとの主張には何の意味もない

**デフォルトの名無しさん** · 2023/02/19(日) 11:30:31.86

>>700
だから議論中はたたき台だろ
会社の提案資料とか書いたことないのか？

**デフォルトの名無しさん** · 2023/02/19(日) 13:11:23.57

>>688
フフッ、奴らはRust魔術師なんて名乗ってるが所詮は、正確な儀式魔法陣の設計と、正確で美しい呪文の詠唱にこだわる愚物よ！
それで発動するのが初級のファイヤーボールたるファイル検索とか笑えるだろ？
無詠唱でループで取り囲まれている敵陣真っただ中に転移ジャンプすることすら叶わぬのだッ！

**デフォルトの名無しさん** · 2023/02/19(日) 14:21:00.44

>>702
ユーザーマニュアルと開発時の要件定義書や設計書の違いだよ
承認された最終版の要件定義書や設計書をたたき台と呼んでる会社なのかな？

提案資料と捉えても別に構わないとは思うが
採用判断の妥当性を確かめるために参照するのは間違ってもユーザーマニュアルではない

**デフォルトの名無しさん** · 2023/02/19(日) 14:23:05.09

実装は正確に、商談はいい加減にやればいいのに
消費税込み0円で物々交換することすら叶わぬのだ

**デフォルトの名無しさん** · 2023/02/19(日) 14:26:53.65

>>673
Option,Resultならunwrapで良いけど、任意のenumから同じように中身を取り出す方法ある？

**デフォルトの名無しさん** · 2023/02/19(日) 14:33:14.38

if letとlet elseがmatchのsyntax sugarなのは自明だから
RFCのサンプルという特定の例に対して別の書き換えが可能だと主張しても何の意味もない
if/let/elseという既存の概念と既存のキーワードの組み合わせによりmatchより短く書けて利便性も良いと総合的に判断されてRustに導入された

**デフォルトの名無しさん** · 2023/02/19(日) 14:44:02.93

>>704
> 承認された最終版の要件定義書や設計書をたたき台と呼んでる会社なのかな？
お前さんが
>> だから議論中は
という簡単な文章すら理解できないことはよくわかった

**デフォルトの名無しさん** · 2023/02/19(日) 15:44:36.19

RFCは叩き台だと思う

たたき‐だい【×叩き台】
読み方：たたきだい

批判・検討などを加えて、よりよい案を得るための原案。

**デフォルトの名無しさん** · 2023/02/19(日) 15:53:32.74

>>708
じゃlet elseのRFCは議論中じゃないからたたき台じゃない
>>693の認識が間違い

**デフォルトの名無しさん** · 2023/02/19(日) 16:00:16.45

単なる叩き台wに従って仕様が変わる言語w

**デフォルトの名無しさん** · 2023/02/19(日) 16:00:56.96

RFCに議論の過程もなぜ導入しようとしたのかもメリットも書いてるのに
サンプルコードが別の書き方できるってもう重箱隅つつきたいだけでしょ
せめてRFCテキスト一文に対する反論なり書いてれば議論になるんだろうけど

**デフォルトの名無しさん** · 2023/02/19(日) 16:07:55.43

IDコロコロしてレベルの低いこと連投する複オジ

**デフォルトの名無しさん** · 2023/02/19(日) 16:09:05.87

let elseの話ならばもはやRFCの段階ではなく、
既に正式にlet文の一部として位置付けられて取り込まれており、
公式Referenceにもletの機能として必要な条件などが記載されている段階

**デフォルトの名無しさん** · 2023/02/19(日) 16:26:24.12

RFC (request for comment)はもちろんその名の通り『叩き台』で合ってる
ただしlet elseについては既に結論が出ているので、
RFCのtracking issueと合わせて過去の経緯と議論を見るための存在へと変わっている
今はRust公式Referenceを見るだけで十分

**デフォルトの名無しさん** · 2023/02/19(日) 16:39:11.76

複オジさんの役に立たない自演珍説言い訳レスはもうお腹いっぱい

**デフォルトの名無しさん** · 2023/02/19(日) 17:04:26.59

3ヶ月も前にstableに導入されたlet elseやラベル付ブロックbreakを今になって自分は使わないからその機能は不要だと主張している人は何をしたいのだろう？
時期的にも不明であるし執拗に不要だと言い続けている意図も不明だ
同時に導入されたGATも使わないから不要と言い出しそうだな

**デフォルトの名無しさん** · 2023/02/19(日) 17:10:07.16

>>717
ようわからんけどお前の発言の意図も不明だぞｗ

**デフォルトの名無しさん** · 2023/02/19(日) 17:58:31.87

そもそも要らん機能だと言い張るならRustフォークして削除した版作って勝手にやってりゃいいと思う

**デフォルトの名無しさん** · 2023/02/19(日) 19:36:27.82

うむ

**デフォルトの名無しさん** · 2023/02/19(日) 20:00:19.52

まぁCのgotoも使う人にとっては要る機能だしね

**デフォルトの名無しさん** · 2023/02/19(日) 20:04:13.68

有意義ではないとは言ってない
使うのは稀だと言ってるだけ
稀で済むからRustを使ってるの

**デフォルトの名無しさん** · 2023/02/19(日) 20:21:42.49

Cの時代にはgotoは普通に要る機能だったからな
コンパイラも今ほど賢くないし