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/07(火) 20:09:18.77

>>409
こういうバカが一人でも入ってくると現場は苦労するわな

**デフォルトの名無しさん** · 2023/02/07(火) 22:03:06.31

今回のケースはRustのエラー処理を他の言語（C#あたり）の例外処理に寄せようとしてる感じ
「特定の例外クラスをcatchしたい」→「dyn Errorで投げてダウンキャストで分岐すればいい」みたいな
anyhowはそういう人のためにあるのかもしれない

オブジェクト指向言語専攻の人はRustのtraitを基底クラスの代わりに使いがちだよね
is-a継承はRustだとenumで表現できる場合が多いんだけど切り替えが難しいのかも

**デフォルトの名無しさん** · 2023/02/07(火) 22:27:27.04

単純にエラーの種類を列挙する意味がないときに使うだけやで

**デフォルトの名無しさん** · 2023/02/07(火) 23:09:28.73

それならいいんだけど型キャストしてまで分岐するとか言ってる人がいたから
自分で分岐する範囲くらいは自分で列挙しとけって話

**デフォルトの名無しさん** · 2023/02/07(火) 23:53:31.04

下層から上がってくる99種類のエラーはログ吐かせるだけで、特別な処理したいエラーはひとつしかないのにいちいちenumに詰め直したりせんわな

**デフォルトの名無しさん** · 2023/02/08(水) 00:04:28.76

逆
自分で分岐してエラー処理すんなら区別すべきエラーを決めるのは自分なのでanyhowやdyn Errorでダウンキャストしても問題ない

外から呼び出されるコードなら区別して処理するエラーを決めるのは呼び出し側なので区別できるようにenumで書く

**デフォルトの名無しさん** · 2023/02/08(水) 00:35:28.79

すまんが、これってなんでダメなの？
ブロックの最後に式を書いてるのに、なんでreturnって書かないとリターンしないの？？？
そもそもエラーの内容に書いてあるmismatched typesって、一体何と何のタイプがミスマッチなんなんだ・・・・
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d1833710038ed821593015e5382de11f
エロい人教えて！！！

**デフォルトの名無しさん** · 2023/02/08(水) 01:51:02.48

>>416
else句が無いのでifの条件式がfalseの場合はif-expressionは()になるけど
ifの条件式がtrueの場合はif-expressionがi32になるのでミスマッチ

**デフォルトの名無しさん** · 2023/02/08(水) 01:59:22.59

>>414
ログを吐かせるだけでもエラーによってログの吐き方を変えたいこともよくある話なのでケースバイケース
99種類を2種類に詰め直して片方をerased typeにしたりする

**デフォルトの名無しさん** · 2023/02/08(水) 07:28:48.49

上位の関数でもかなり多数のケースに分けてエラー処理する必要な場合だと
個別にenumにエラー型を収容する方が有利なケースもある
もちろんその場合でもanyhowやdyn Errorに収容してダウンキャストしてもよい
enum matchとダウンキャストの実行時コストはほぼ同じで優劣はなく視認性も変わらない
enumを使うとコードが増える問題はあるがあとは好みの問題

**デフォルトの名無しさん** · 2023/02/08(水) 10:45:01.05

ダウンキャストは下位モジュールに不必要に依存することになるので選択の余地があるなら基本的には使うべきではない

自crateで定義したエラー型にダウンキャストするくらいならエラーを定義するついでにenum書いとけばいいだけ
他crateで定義したエラー型にダウンキャストしてるとバージョンアップ時にサイレントにキャストが失敗して動作が変わる

あくまで非常口であって使わざるをえないときはマイナス面を理解した上で注意深く使うもの

**デフォルトの名無しさん** · 2023/02/08(水) 10:52:13.58

UnknownErrorにわざわざ詰め直したログ吐くしかできない99種類あったエラーと1種類の自クレートのMyErrorをenumで2つ列挙して分岐するのと
MyErrorも含めて100種全部dynで上げてMyErrorだけダウンキャストすることの間に大した違いはない

**デフォルトの名無しさん** · 2023/02/08(水) 12:29:34.73

アプリケーション開発とライブラリ開発の2つの視点があって、それぞれで戦略が違うというのが大元にあるからそこは理解してもらわないとね。

**デフォルトの名無しさん** · 2023/02/08(水) 12:40:19.14

ライブラリでdyn Error使うと本体の型がpubじゃないときにめんどくさそう

**デフォルトの名無しさん** · 2023/02/08(水) 12:45:18.46

両者で大きく異なるよね
ただし既出のcargoやreqwestなど違いに関わらずダウンキャストを使っているコードも多いから
どっちだと良くてどっちだとダメというものでもない気がする

**デフォルトの名無しさん** · 2023/02/08(水) 12:48:39.58

424は422へのレスね

>>423
そこはenum作って収容しようがdyn Errorに収容しようが関係なくpubじゃない型はどうにもならないような

**デフォルトの名無しさん** · 2023/02/08(水) 13:05:56.18

>>421
どういう種類の変更に対してコードのどの部分に手を入れる必要が出てくるのかを考えてみるといいよ

**デフォルトの名無しさん** · 2023/02/08(水) 13:15:25.12

求められてもない具体性のない中身のない全く役に立たないアドバイスは有害でしかない

**デフォルトの名無しさん** · 2023/02/08(水) 13:35:42.99

現実にdowncast_ref()が使われているアプリやライブラリが多数あり
それらが問題になったことはないのだから
downcast_ref()を嫌っている人は思い込みで好き嫌いに過ぎないことを理解しようぜ
enumを作っても下位のエラー型を突っ込むだけでは何も変わらない

**デフォルトの名無しさん** · 2023/02/08(水) 14:12:14.99

ここまで具体的なコード例なし

**デフォルトの名無しさん** · 2023/02/08(水) 14:40:13.85

前提条件付けて場合分けして考えろ
てかこんなことでスレの半分近くも消費すんな

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

>>417
そうだったのか！returnを書いたら通るのも、そうするとどちらも戻り値が()同士で統一されるってことか！
ありがとう！全然わかんなかったぜ！

**デフォルトの名無しさん** · 2023/02/08(水) 16:16:54.39

>>417
>>416では無いが、そういう意味だったのか
単に厳し目にチェックしているからだと思っていた

**デフォルトの名無しさん** · 2023/02/08(水) 17:13:58.11

たぶんだけど「Rustでは値を返すのにreturnを省略できる」と誤解してるんじゃないかな
その誤解のためreturn bのreturnを省略してしまったと思われる

正しくは「Rustでは最後の値が返り値となる(のでreturnが不要)(だが使ってもよい)」
と「途中で返したい時はreturnを使う」

だから今回の例だと
if文の中では『途中だから』return bとbにreturnが必須
あるいは関数の最後をif-else式にしてしまえば『最後となるから』bにreturnは不要

**デフォルトの名無しさん** · 2023/02/08(水) 17:28:24.72

ちょっと誤解があるから追加
最後をif-else式にすれば全体に式returnのreturnが不要になる
そしてif-else式の中はreturnは不要というか付けない
そこにreturnを付けるとif-else式ではなぬif-else文になる

**デフォルトの名無しさん** · 2023/02/08(水) 18:12:57.92

文章を難読化しすぎやろw

**デフォルトの名無しさん** · 2023/02/08(水) 18:22:49.80

面倒だから戻るところはすべてreturn書いてる

**デフォルトの名無しさん** · 2023/02/08(水) 20:39:29.96

return式の型は厳密には!なんだけど……
まあ後で知ればいいか

**デフォルトの名無しさん** · 2023/02/08(水) 20:50:18.79

そのおかげでif式でreturnしつつelseで値を与えたりできるね

**デフォルトの名無しさん** · 2023/02/09(木) 11:57:24.62

早期returnはバグにつながるから禁止が常識

**デフォルトの名無しさん** · 2023/02/09(木) 12:14:59.38

>>439
昔はそう言われたけど今はそんなカス風習廃れたしRustに持ち込まないでほしい。

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

早期returnは（>>439みたいなアホが使うと）バグにつながるから禁止が常識

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

わざわざ早期リターンのために?演算子なんて用意してるRustで早期リターン禁止とな？！

**デフォルトの名無しさん** · 2023/02/09(木) 12:43:02.37

スルースキル皆無か

**デフォルトの名無しさん** · 2023/02/09(木) 13:10:12.86

なんで昔は早期returnがバグにつながると考えられてたの？
どう考えても早期returnしない方がバグにつながりやすいと思うんだが

**デフォルトの名無しさん** · 2023/02/09(木) 14:20:08.85

もっと昔にgotoの使いすぎで制御構造がぐちゃぐちゃになったことへの反動で
複雑な制御構造は使わないようにしよう、という流れだったかと

**デフォルトの名無しさん** · 2023/02/09(木) 14:55:47.47

>>444
C言語時代の話な
例えばこういうパターンでメモリーリークしたりするバグがたくさんあった

f(...){
p = malloc(...);
...
if(...) return;
...
free(p);
}

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

そのあたりも自動メモリ開放のRustなら大丈夫だね
if文で早期return/continue/breakしないと、どんどんifネストが深くなっていくのでそれを避けたい

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

>>446
リソース確保・解放するレイヤーとそれを使って処理を行うレイヤーを分ければよくない？

f(...){
p = malloc(...);
g(p, …);
free(p);
}

g(…) {
...
if(...) return;
...
}

ifのネストが浅くなっても逆に関数のネストが深くなりすぎて読みにくくなる側面があるということなのかな？

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

>>448
分けましょうってルール化したくらいで完璧に守られるなら誰も苦労しないんだよな…
そのうち処理レイヤー側でmallocするやつが出てくるやつ

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

RAII無しでの話なんかRustに関係無いだろ。

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

ifがネスとしていたりした場合に、returnみたいにif-expressionの方に結果を返したい時ってどうすればいいの？

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

>>449
早期returnはやめましょうルールは完璧に守られる保証があると？

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

>>451
擬似コードでいいのでイメージを書いてくれ
でないと言いたいことが分からない

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

>>451
最近入ったラベル付きブロックでbreak

https://rust-lang.github.io/rfcs/2046-label-break-value.html

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

言語仕様的に可能でも規則で縛ることで安全を担保しようという方法は
いずれ失敗するからそういう要素は必ず言語側の仕様で保証すべき、というのがRustの思想なんだから
「あれは危険だから駄目、コーディング規則で縛る」という発想自体が間違ってる

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

>>448
リソースが１つだけならいいかも知れないけど複数リソースが絡んでたりすると色々ややこしいコードになっちゃう
>>452
コードレビュー時に return 検索したら

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

>>450
>>439 に言ってくれ

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

>>456
なるほど
そういう方法だけに頼ってるなら早期returnのほうが見つけやすいわな

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

こういうやつ？
let result = 'found: {
　for i in 0..100 {
　　if f(i) {
　　　break 'found Some(i);
　　}
　}
　None
};

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

>>453-454
>>459
やりたかったのこれだ、せんきゅー！

**デフォルトの名無しさん** · 2023/02/09(木) 17:27:44.71

最近はCでもcleanup属性というのが使えるんだな

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/09(木) 17:43:07.29

>>444
構造化が重要視された時代がある。
順次・反復・分岐によって処理の流れを構築するという点から見ると
早期リターンは流れをすっとばして大ジャンプしてることになるので
コードを追うのを難しくすると考えられていた。
「出入口はひとつずつ」は基本思想だったんだよ。
構造化が不十分だった時代にまず構造化することが大事だったという話。

今では構造化が当たり前になったから次の段階として順次・反復・分岐という構造だけでは
上手く扱いづらい部分をどうやるのがいいのかという模索が続いてるわけ。

**デフォルトの名無しさん** · 2023/02/09(木) 18:03:17.12

戻るgotoは結局なんらかのループを表しているので
Rustならラベル付loopに指定continueで表せる
進むgotoは無制限ではなくラベル指定breakの大域脱出型に制限される
という認識で合ってる？

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

>>454
なんか微妙な機能だな
関数化して早期returnさせる手間が嫌ということなんだろうけどそれなら||や&&オペレータをOptionやResult用に上書きできるようにした方がずっと使いやすい
tryブロックとの非対称性も気になる

**デフォルトの名無しさん** · 2023/02/09(木) 18:30:28.03

>>464
今までに既にあった機能のラベル付loop式のラベル指定breakという使われ方のうち
ループしない使われ方が多かったため事実上のシンタックスシュガーが導入されただけだよ
だから微妙な機能が追加されたという見方は正しくない

**デフォルトの名無しさん** · 2023/02/09(木) 18:30:33.67

>>464
ほとんどの場合はこんなん使う前にその部分を関数に切り出すことを考えるべきというのはめちゃくちゃ言われてる
awaitとかResultとかライフタイムとかいろいろ絡んできたときに再利用もされない数行の処理のために長々と型を書かなくても済むのがユースケースのひとつと思われる

**デフォルトの名無しさん** · 2023/02/09(木) 18:46:56.04

>>465
シンタックスシュガーも機能やろがい
公式にもlanguage featureと書いてるぞい

**デフォルトの名無しさん** · 2023/02/09(木) 18:50:34.43

どうせなら仮変数みたいな変数割当機能も用意して、末尾最適化再帰風ループもできるようにならないかね。

**デフォルトの名無しさん** · 2023/02/09(木) 18:53:10.62

>>467
既に昔から存在していたloop式を
loopと書かなくてもよくなっただけだよ
今までは皆はloop式の最後をbreakすることでloopさせずにこの同じ機能を使っていた
今回でloopを省けるようになったため最後のbreakが不要とだけにすぎない
今さら文句をつけるのが不思議

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

早期returnってファウラーのガード節の話じゃないん？
あの使い方する限り安全安心可読性改良にしかならないよな？

**デフォルトの名無しさん** · 2023/02/09(木) 19:04:01.20

>>470
ファウラーじゃなくてリーダブルコード？

**デフォルトの名無しさん** · 2023/02/09(木) 19:05:50.10

リーダブルコードは忘れたけど

part of martinfowler.com
https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html

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

if letでネストが深くならないように早期return等しようとすると無駄コードが膨らんでいた問題も
同時に導入されたlet elseによって解決されたね

**デフォルトの名無しさん** · 2023/02/09(木) 19:24:14.80

>>472
そうこれ、というか第1版からあるならファウラーが先なのね
失礼した

**デフォルトの名無しさん** · 2023/02/09(木) 19:31:22.46

「ルールだからダメ(思考停止)」な人って結構いるよね

**デフォルトの名無しさん** · 2023/02/09(木) 19:40:55.17

ルールの背景を考えずに破ろうとするやつも多いけどな。

守破離は基本だろ。ブルースリーのパンチキックの逸話でもいいけど。

**デフォルトの名無しさん** · 2023/02/09(木) 19:47:18.19

>>476
合理的なロジックがないという点で同類じゃね
「ルールだから問題ない(思考停止)」で他人に迷惑をかけるのも同じ
そして多くの場合無責任までセットだ

**デフォルトの名無しさん** · 2023/02/09(木) 19:54:21.56

そもそも失敗できなくするのがここ10年ぐらいのトレンドだろ。
だから静的型やRustが支持されるわけで。

**デフォルトの名無しさん** · 2023/02/09(木) 20:07:33.02

>>477
ルールについては「決定と実行の分離」という重要な側面があるよ。

頭のいい奴がルールを作れば、アホがルール通りに実行しても被害は少ない。アホがルールを破るよりよほどマシ。

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

Rustの制御構文としては
昨年末の2つの追加で
従来は不便で需要が多かった形が無事に解決したから一段落かな

**デフォルトの名無しさん** · 2023/02/09(木) 22:05:48.35

>>464
わかる
旧世代言語のニオイがする

**デフォルトの名無しさん** · 2023/02/09(木) 22:51:32.40

こういうの書くやつが出るから
基本は使わないほうがよさそうだな
https://github.com/rust-lang/rust/issues/48594/partials/load_more#issuecomment-1184213006

**デフォルトの名無しさん** · 2023/02/09(木) 23:06:57.24

草
何らかの目的で大域脱出を用意すると必ず妙ちくりんな悪用を考える奴が出てくるんだよな

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/09(木) 23:22:20.06

そういえばコンテナのイテレーションの順序が未規定なときに
順序に依存したコードを書かないように乱数でわざとデタラメな順序にしたら
乱数生成器として使うやつが出てきたって話があったな。

どんな機能も下手に使ったら無茶苦茶にしうるってのはもうどうしようもなくない？

**デフォルトの名無しさん** · 2023/02/09(木) 23:42:25.26

>>56のが実現したらRFCの例は||で代替可
let result = (first_container.iter().find(|&&v| v > 0)
|| second_container.iter().find(|&&v| v < 0))
.unwrap_or(&0);

labelやbreakの手続き的なやり方よりこっちの方が汎用性も高いしrustの目指すべき方向に合ってると思う

**デフォルトの名無しさん** · 2023/02/10(金) 01:49:50.47

メソッド抽出は嫌
クロージャの即時実行も嫌
ラベル付きbreakならOK！
って感覚が俺には理解できんが
ニーズがあるならいいんじゃね

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

>>486
関数切り出しやIIFEだと式の値はResult型になるようなところで、
ラベル付きブロックだとエラーまわりは親の関数に完全に任せて該当の式の値を生で返せる

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

ラベルでジャンプより、関数の入れ子の方が分かりやすくない？

**デフォルトの名無しさん** · 2023/02/10(金) 03:36:08.11

>>487
？オペレータ使えばいいだけなんだが？
逆にエラーまわりだけ親関数に任せるとかヤバくね？

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

>>488
ラベルでジャンプしていない
loop式の構文のloop抜きと動作も概念も全く同じだから
今回Rustはたまたま同じ構文を採用しただけ

例えば>>459の例は
ラベルを用いない別の新たな構文{{…}}を導入すればこうなる
let result = {{
　for i in 0..100 {
　　if f(i) {
　　　return Some(i);
　　}
　}
　None
}};
動作も意味も全く同じであり
ラベルにジャンプしていないことが理解できるだろう

**デフォルトの名無しさん** · 2023/02/10(金) 07:32:00.75

そしてRustがなぜ今回の構文の形を採用したか
・returnでもbreakでも多重になった時にどれを終えるのか曖昧になるため何らかの指定は必要
・ラベルによる指定はRustの他の構文でも共通に既に使われており親和性がある
・returnの使用は混乱を防ぐために関数とクロージャーから返る位置付けのみに保ちたい
・既存のloop式と今回の構文はloopキーワードを除けば全く同じであり導入前はloop式で代替されていた

**デフォルトの名無しさん** · 2023/02/10(金) 07:54:41.21

>>488
必要性に応じて関数として切り出すのも構わない
そして関数として分離した方が好ましい場合もあるだろう
しかし常に関数切り出しを強いられる言語だったとしたら煩雑すぎて機能不足と言えるから使い分けできることが必要

**デフォルトの名無しさん** · 2023/02/10(金) 08:05:40.53

>>490
文脈読めなさ過ぎw

**デフォルトの名無しさん** · 2023/02/10(金) 08:18:49.59

>>493
従来からforやloop式で使われてきた早期return(離脱)つまりRustでのラベル指定break
そして今回Rust導入されたブロック式での早期return(離脱)つまり同様に構文としてはラベル指定break
それらに対して「ラベルでジャンプ」とは何を言いたいのか？

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

>>485
短絡orに論理orを使うのは混乱の元だから、別の専用の記号を用意して欲しいわ。

**デフォルトの名無しさん** · 2023/02/10(金) 08:39:40.06

>>495
遅延評価orの型が
現在はbool型のみに制限されているから
それをOption型などにも使えるようにしよう！という話じゃないかな

**デフォルトの名無しさん** · 2023/02/10(金) 08:41:20.86

>>489
関数に切り出した時点で「その範囲のResultの型」を考慮しなくちゃいけなくなるから?演算子では何も解決してないし、
切り出さなきゃ元からその関数の処理だから何もやばくないぞ

**デフォルトの名無しさん** · 2023/02/10(金) 08:50:58.78

関数切り出しすると
その中でも継続して使う変数(値)を参照として全て渡してそれらの型宣言も改めて行なってと煩雑さとコードの重複が大きい
もちろん返り値型も型推論で済まなくなり明確に宣言しなければならなくなる

したがって関数切り出しの方が明確にメリットが上回るケースを除いて
適材適所でブロック式で済ませられるようになった今回の導入は大きな意義があると思う

**デフォルトの名無しさん** · 2023/02/10(金) 09:14:00.68

関数切り出しじゃなくて、関数のネスト

**デフォルトの名無しさん** · 2023/02/10(金) 09:39:52.23

>>490
動作も意味も全く同じとのことだが
その構文でネストしたブロックから抜けられるのかい？

**デフォルトの名無しさん** · 2023/02/10(金) 09:47:31.36

>>495
今も||は「短絡論理OR」で区別されてないよ
短絡論理ORと論理ORを分けてる言語ってある？

**デフォルトの名無しさん** · 2023/02/10(金) 09:58:49.88

5年もの歳月を費やしてstabilizeするほど意味ある機能じゃないよな
超ニッチなnice to haveなんだからこんな機能実装するくらいなら他の作業してくれよ

**デフォルトの名無しさん** · 2023/02/10(金) 09:58:58.37

>>499
Rustで関数のネスト定義は可能だけどスコープを親関数内に限定するだけだよね
親関数の変数をもちろん操作できないので改めて引数も戻り値も全て型宣言して受け渡ししなければならない

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

>>499
関数のネストでやるためには
関数に切り出す必要があるから同じことを言ってるんじゃない？

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

>>500
forやloopを使ったときにどのbreakか区別できるようにラベルが付いてるだけでラベル付ブロック式のネストまでは元々求められていないんじゃないかな
たまたまラベル付となったからネストさせて指定して抜けることも可能なのかも知れないけどさ

**デフォルトの名無しさん** · 2023/02/10(金) 11:35:14.97

>>505
指定したラベル位置に制御を移すような動きのことを一般的にはジャンプと呼ぶ
ラベルで指定したブロックを”抜ける”と呼ぶ感覚ももちろん理解できるが同じようにジャンプと呼ぶ感覚くらいは理解してやれって話

**デフォルトの名無しさん** · 2023/02/10(金) 12:14:15.40

>>502
ブロック式の早期離脱機能は同時に導入されたlet elseと並んでRustにとって必須の機能
これまではブロック式で早期離脱が出来なかったため代替処置として
・ブロックの代わりにわざわざクロージャを用意して即時実行する
・ループさせないのにloop式を目的外でブロック式として用いる
・関数として切り出して引数型や戻り型などコードが無駄に膨らむ
以上3通りの方法が苦しい回避処置として取られてきた
この問題が一気に解決した

**デフォルトの名無しさん** · 2023/02/10(金) 13:14:46.92

>>507
おまえホント壊れたレコードみたいだな
馬鹿の一つ覚えで繰り返し同じことしか言えないからおまえが出しゃばってくるとすぐスレが腐る

**デフォルトの名無しさん** · 2023/02/10(金) 13:40:49.41

オジさんは即時実行マンセー派だったのに宗旨替えしたのかw
と言っても忌み嫌われてた即時実行から半歩前進して半歩後退してるみたいなので実質進歩してないな