Rust part19

1 名前：デフォルトの名無しさん mailto:sage [2023/01/17(火) 12:41:32.25 ID:nikBFIMQ.net] 公式 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/ 399 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 12:48:04.84 ID:/nZ/7Knj.net] 昔ながらの例外論争見てるみたいだ 全部取ればいいいや個別だ 400 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 14:14:21.50 ID:C/yeK4bx.net] >>397で合っているけど補足すれば 全網羅列挙コードを書いてもコンパイラがそれを許さずエラーとなる 全網羅列挙しなくていいから必ず全マッチの　_ =>　アームをコンパイラが要求してくる つまりコンパイラによるエラーの網羅性チェックは不可能 401 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 21:51:09.46 ID:MJNtWgHJ.net] そもそもRust以前に他のプログラミング言語でもそのようなエラーの種類の網羅が行なわれたことはない IOエラーだけでも何十種類もあり列挙するだけでも大変で意味のない作業 エラー処理で必要とされる網羅性とはエラーの種類を全て列挙することではなく >>391の説明が正しい RustでResultを使えば保証される 402 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 21:59:33.19 ID:T23InEdz.net] 自分の書いたレスを正しい正しいと 一人で連呼してて虚しくならないのかな 403 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 22:26:04.02 ID:7y0OcpN0.net] エラー処理の網羅性という話は元々 関数からエラー値が返って来る可能性があるのに見落として処理せずに続行しちゃったり あるいは例外が返って来る可能性があるのに見落として処理しないままでいたり そういう見落としがよく起きていたから いつどこでどんなエラー(or例外)が起きても処理漏れがないようにプログラミングしましょうという話 もちろんRustではResultで返せばコンパイル時点でエラーや警告が出るためエラー処理の網羅性は満たされます Resultを返していればdyn Errorやanyhowを使っていてももちろん大丈夫 そしてエラー処理の分岐にそれらのダウンキャストを使うのも何ら問題なし 404 名前：デフォルトの名無しさん [2023/02/07(火) 02:02:21.05 ID:smEuFI89.net] anyhow使ってて困ったことないので、これからもanyhow使いますね 405 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 02:09:15.61 ID:2blGAjQQ.net] enumで網羅派の完全敗北だな anyhowやdyn Errorでdowncast_ref分岐して何ら困らない 406 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 02:13:05.33 ID:fMWAnbF1.net] anyhowは邪道だろ 407 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 10:30:33.69 ID:jDwZWgRX.net] 下手に分かったふりせず疑問をぶつけるパニック君のようなレスはスレにとっては有益 逆に知ったかぶりして嘘を撒き散らす某オジのレスは害しかない 一緒に仕事してても伸びるのは断然前者のタイプ 後者は多少知識があってもチームの足を引っ張る老害タイプ 408 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 11:56:13.05 ID:Yu/MJcLX.net] >>407 知ったかぶりもだけど ご飯論法的に毎回論点を捻じ曲げてくるのが悪質 スルー推奨 409 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 12:39:13.84 ID:GmLWJf7C.net] どの言語を使っていようがテスト設計とエラー処理設計は初心者と脱初心者を見分けるリトマス試験紙 チュートリアルやリファレンス読むだけでは身につかない 410 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 13:41:38.43 ID:vPUoP0i3.net] そう、IT土方必修 411 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 20:09:18.77 ID:RZZKb5qe.net] >>410 こういうバカが一人でも入ってくると現場は苦労するわな 412 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 22:03:06.31 ID:u8XyY9YO.net] 今回のケースはRustのエラー処理を他の言語（C#あたり）の例外処理に寄せようとしてる感じ 「特定の例外クラスをcatchしたい」→「dyn Errorで投げてダウンキャストで分岐すればいい」みたいな anyhowはそういう人のためにあるのかもしれない オブジェクト指向言語専攻の人はRustのtraitを基底クラスの代わりに使いがちだよね is-a継承はRustだとenumで表現できる場合が多いんだけど切り替えが難しいのかも 413 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 22:27:27.04 ID:23ICgzsB.net] 単純にエラーの種類を列挙する意味がないときに使うだけやで 414 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 23:09:28.73 ID:u8XyY9YO.net] それならいいんだけど型キャストしてまで分岐するとか言ってる人がいたから 自分で分岐する範囲くらいは自分で列挙しとけって話 415 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 23:53:31.04 ID:23ICgzsB.net] 下層から上がってくる99種類のエラーはログ吐かせるだけで、特別な処理したいエラーはひとつしかないのにいちいちenumに詰め直したりせんわな 416 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 00:04:28.76 ID:mV68xos2.net] 逆 自分で分岐してエラー処理すんなら区別すべきエラーを決めるのは自分なのでanyhowやdyn Errorでダウンキャストしても問題ない 外から呼び出されるコードなら区別して処理するエラーを決めるのは呼び出し側なので区別できるようにenumで書く 417 名前：デフォルトの名無しさん [2023/02/08(水) 00:35:28.79 ID:ydIblX/+.net] すまんが、これってなんでダメなの？ ブロックの最後に式を書いてるのに、なんでreturnって書かないとリターンしないの？？？ そもそもエラーの内容に書いてあるmismatched typesって、一体何と何のタイプがミスマッチなんなんだ・・・・ https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d1833710038ed821593015e5382de11f エロい人教えて！！！ 418 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 01:51:02.48 ID:U3de6tMw.net] >>417 else句が無いのでifの条件式がfalseの場合はif-expressionは()になるけど ifの条件式がtrueの場合はif-expressionがi32になるのでミスマッチ 419 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 01:59:22.59 ID:W8WwzKcT.net] >>415 ログを吐かせるだけでもエラーによってログの吐き方を変えたいこともよくある話なのでケースバイケース 99種類を2種類に詰め直して片方をerased typeにしたりする 420 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 07:28:48.49 ID:2c2bFNHO.net] 上位の関数でもかなり多数のケースに分けてエラー処理する必要な場合だと 個別にenumにエラー型を収容する方が有利なケースもある もちろんその場合でもanyhowやdyn Errorに収容してダウンキャストしてもよい enum matchとダウンキャストの実行時コストはほぼ同じで優劣はなく視認性も変わらない enumを使うとコードが増える問題はあるがあとは好みの問題 421 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 10:45:01.05 ID:ENpYrX9l.net] ダウンキャストは下位モジュールに不必要に依存することになるので選択の余地があるなら基本的には使うべきではない 自crateで定義したエラー型にダウンキャストするくらいならエラーを定義するついでにenum書いとけばいいだけ 他crateで定義したエラー型にダウンキャストしてるとバージョンアップ時にサイレントにキャストが失敗して動作が変わる あくまで非常口であって使わざるをえないときはマイナス面を理解した上で注意深く使うもの 422 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 10:52:13.58 ID:fJPPomwd.net] UnknownErrorにわざわざ詰め直したログ吐くしかできない99種類あったエラーと1種類の自クレートのMyErrorをenumで2つ列挙して分岐するのと MyErrorも含めて100種全部dynで上げてMyErrorだけダウンキャストすることの間に大した違いはない 423 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 12:29:34.73 ID:/lg+THEr.net] アプリケーション開発とライブラリ開発の2つの視点があって、それぞれで戦略が違うというのが大元にあるからそこは理解してもらわないとね。 424 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 12:40:19.14 ID:TursxKDi.net] ライブラリでdyn Error使うと本体の型がpubじゃないときにめんどくさそう 425 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 12:45:18.46 ID:QfEWSkwW.net] 両者で大きく異なるよね ただし既出のcargoやreqwestなど違いに関わらずダウンキャストを使っているコードも多いから どっちだと良くてどっちだとダメというものでもない気がする 426 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 12:48:39.58 ID:QfEWSkwW.net] 424は422へのレスね >>424 そこはenum作って収容しようがdyn Errorに収容しようが関係なくpubじゃない型はどうにもならないような 427 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 13:05:56.18 ID:B9DUhvwN.net] >>422 どういう種類の変更に対してコードのどの部分に手を入れる必要が出てくるのかを考えてみるといいよ 428 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 13:15:25.12 ID:Fgr/3fzw.net] 求められてもない具体性のない中身のない全く役に立たないアドバイスは有害でしかない 429 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 13:35:42.99 ID:DnIJ53A+.net] 現実にdowncast_ref()が使われているアプリやライブラリが多数あり それらが問題になったことはないのだから downcast_ref()を嫌っている人は思い込みで好き嫌いに過ぎないことを理解しようぜ enumを作っても下位のエラー型を突っ込むだけでは何も変わらない 430 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 14:12:14.99 ID:SqObziFu.net] ここまで具体的なコード例なし 431 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 14:40:13.85 ID:J3DHyZUt.net] 前提条件付けて場合分けして考えろ てかこんなことでスレの半分近くも消費すんな 432 名前：デフォルトの名無しさん [2023/02/08(水) 16:15:41.93 ID:ydIblX/+.net] >>418 そうだったのか！returnを書いたら通るのも、そうするとどちらも戻り値が()同士で統一されるってことか！ ありがとう！全然わかんなかったぜ！ 433 名前：デフォルトの名無しさん [2023/02/08(水) 16:16:54.39 ID:VvFQM19K.net] >>418 >>417では無いが、そういう意味だったのか 単に厳し目にチェックしているからだと思っていた 434 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 17:13:58.11 ID:e6ub/0SO.net] たぶんだけど「Rustでは値を返すのにreturnを省略できる」と誤解してるんじゃないかな その誤解のためreturn bのreturnを省略してしまったと思われる 正しくは「Rustでは最後の値が返り値となる(のでreturnが不要)(だが使ってもよい)」 と「途中で返したい時はreturnを使う」 だから今回の例だと if文の中では『途中だから』return bとbにreturnが必須 あるいは関数の最後をif-else式にしてしまえば『最後となるから』bにreturnは不要 435 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 17:28:24.72 ID:e6ub/0SO.net] ちょっと誤解があるから追加 最後をif-else式にすれば全体に式returnのreturnが不要になる そしてif-else式の中はreturnは不要というか付けない そこにreturnを付けるとif-else式ではなぬif-else文になる 436 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 18:12:57.92 ID:uJD0QVJP.net] 文章を難読化しすぎやろw 437 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 18:22:49.80 ID:KYgqZ0R0.net] 面倒だから戻るところはすべてreturn書いてる 438 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 20:39:29.96 ID:EOwXjjdD.net] return式の型は厳密には!なんだけど…… まあ後で知ればいいか 439 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 20:50:18.79 ID:e6ub/0SO.net] そのおかげでif式でreturnしつつelseで値を与えたりできるね 440 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 11:57:24.62 ID:w55r8U1C.net] 早期returnはバグにつながるから禁止が常識 441 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 12:14:59.38 ID:bVNNfLSa.net] >>440 昔はそう言われたけど今はそんなカス風習廃れたしRustに持ち込まないでほしい。 442 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 12:15:50.03 ID:UhaInviD.net] 早期returnは（>>440みたいなアホが使うと）バグにつながるから禁止が常識 443 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 12:41:16.10 ID:S7fEOBGh.net] わざわざ早期リターンのために?演算子なんて用意してるRustで早期リターン禁止とな？！ 444 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 12:43:02.37 ID:EmRyIpwb.net] スルースキル皆無か 445 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 13:10:12.86 ID:wPt4Q+MY.net] なんで昔は早期returnがバグにつながると考えられてたの？ どう考えても早期returnしない方がバグにつながりやすいと思うんだが 446 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 14:20:08.85 ID:QqGr+Vdk.net] もっと昔にgotoの使いすぎで制御構造がぐちゃぐちゃになったことへの反動で 複雑な制御構造は使わないようにしよう、という流れだったかと 447 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 14:55:47.47 ID:UhaInviD.net] >>445 C言語時代の話な 例えばこういうパターンでメモリーリークしたりするバグがたくさんあった f(...){ p = malloc(...); ... if(...) return; ... free(p); } 448 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 15:21:57.59 ID:9WtqRr2n.net] そのあたりも自動メモリ開放のRustなら大丈夫だね if文で早期return/continue/breakしないと、どんどんifネストが深くなっていくのでそれを避けたい 449 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 15:37:28.09 ID:Ktnp537B.net] >>447 リソース確保・解放するレイヤーとそれを使って処理を行うレイヤーを分ければよくない？ f(...){ p = malloc(...); g(p, …); free(p); } g(…) { ... if(...) return; ... } ifのネストが浅くなっても逆に関数のネストが深くなりすぎて読みにくくなる側面があるということなのかな？ 450 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 15:51:48.67 ID:oQtbOpVY.net] >>449 分けましょうってルール化したくらいで完璧に守られるなら誰も苦労しないんだよな… そのうち処理レイヤー側でmallocするやつが出てくるやつ 451 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 15:59:20.91 ID:Ieoj7bJI.net] RAII無しでの話なんかRustに関係無いだろ。 452 名前：デフォルトの名無しさん [2023/02/09(木) 16:04:18.76 ID:1694Wm1I.net] ifがネスとしていたりした場合に、returnみたいにif-expressionの方に結果を返したい時ってどうすればいいの？ 453 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:22:54.26 ID:eQhq+cyr.net] >>450 早期returnはやめましょうルールは完璧に守られる保証があると？ 454 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:24:27.43 ID:g7YoScpU.net] >>452 擬似コードでいいのでイメージを書いてくれ でないと言いたいことが分からない 455 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:25:56.79 ID:VnFQyKoO.net] >>452 最近入ったラベル付きブロックでbreak https://rust-lang.github.io/rfcs/2046-label-break-value.html 456 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:36:32.32 ID:8ktpZl0b.net] 言語仕様的に可能でも規則で縛ることで安全を担保しようという方法は いずれ失敗するからそういう要素は必ず言語側の仕様で保証すべき、というのがRustの思想なんだから 「あれは危険だから駄目、コーディング規則で縛る」という発想自体が間違ってる 457 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:43:33.27 ID:UhaInviD.net] >>449 リソースが１つだけならいいかも知れないけど複数リソースが絡んでたりすると色々ややこしいコードになっちゃう >>453 コードレビュー時に return 検索したら 458 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:44:45.59 ID:UhaInviD.net] >>451 >>440 に言ってくれ 459 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:48:27.59 ID:jx1YaHu3.net] >>457 なるほど そういう方法だけに頼ってるなら早期returnのほうが見つけやすいわな 460 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 16:49:18.29 ID:9WtqRr2n.net] こういうやつ？ let result = 'found: { 　for i in 0..100 { 　　if f(i) { 　　　break 'found Some(i); 　　} 　} 　None }; 461 名前：デフォルトの名無しさん [2023/02/09(木) 17:15:30.09 ID:1694Wm1I.net] >>454-455 >>460 やりたかったのこれだ、せんきゅー！ 462 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 17:27:44.71 ID:vSSl5weC.net] 最近はCでもcleanup属性というのが使えるんだな 463 名前：はちみつ餃子 mailto:sage [2023/02/09(木) 17:43:07.29 ID:zt0qN6wf.net] >>445 構造化が重要視された時代がある。 順次・反復・分岐によって処理の流れを構築するという点から見ると 早期リターンは流れをすっとばして大ジャンプしてることになるので コードを追うのを難しくすると考えられていた。 「出入口はひとつずつ」は基本思想だったんだよ。 構造化が不十分だった時代にまず構造化することが大事だったという話。 今では構造化が当たり前になったから次の段階として順次・反復・分岐という構造だけでは 上手く扱いづらい部分をどうやるのがいいのかという模索が続いてるわけ。 464 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 18:03:17.12 ID:9WtqRr2n.net] 戻るgotoは結局なんらかのループを表しているので Rustならラベル付loopに指定continueで表せる 進むgotoは無制限ではなくラベル指定breakの大域脱出型に制限される という認識で合ってる？ 465 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 18:18:38.11 ID:xZSrodqJ.net] >>455 なんか微妙な機能だな 関数化して早期returnさせる手間が嫌ということなんだろうけどそれなら||や&&オペレータをOptionやResult用に上書きできるようにした方がずっと使いやすい tryブロックとの非対称性も気になる 466 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 18:30:28.03 ID:9WtqRr2n.net] >>465 今までに既にあった機能のラベル付loop式のラベル指定breakという使われ方のうち ループしない使われ方が多かったため事実上のシンタックスシュガーが導入されただけだよ だから微妙な機能が追加されたという見方は正しくない 467 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 18:30:33.67 ID:QonGkYb5.net] >>465 ほとんどの場合はこんなん使う前にその部分を関数に切り出すことを考えるべきというのはめちゃくちゃ言われてる awaitとかResultとかライフタイムとかいろいろ絡んできたときに再利用もされない数行の処理のために長々と型を書かなくても済むのがユースケースのひとつと思われる 468 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 18:46:56.04 ID:RAzSpXh0.net] >>466 シンタックスシュガーも機能やろがい 公式にもlanguage featureと書いてるぞい 469 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 18:50:34.43 ID:hFEBZw9k.net] どうせなら仮変数みたいな変数割当機能も用意して、末尾最適化再帰風ループもできるようにならないかね。 470 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 18:53:10.62 ID:9WtqRr2n.net] >>468 既に昔から存在していたloop式を loopと書かなくてもよくなっただけだよ 今までは皆はloop式の最後をbreakすることでloopさせずにこの同じ機能を使っていた 今回でloopを省けるようになったため最後のbreakが不要とだけにすぎない 今さら文句をつけるのが不思議 471 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:02:26.27 ID:o9a7e9s5.net] 早期returnってファウラーのガード節の話じゃないん？ あの使い方する限り安全安心可読性改良にしかならないよな？ 472 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:04:01.20 ID:EmRyIpwb.net] >>471 ファウラーじゃなくてリーダブルコード？ 473 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:05:50.10 ID:o9a7e9s5.net] リーダブルコードは忘れたけど part of martinfowler.com https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html 474 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:15:02.58 ID:9WtqRr2n.net] if letでネストが深くならないように早期return等しようとすると無駄コードが膨らんでいた問題も 同時に導入されたlet elseによって解決されたね 475 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:24:14.80 ID:EmRyIpwb.net] >>473 そうこれ、というか第1版からあるならファウラーが先なのね 失礼した 476 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:31:22.46 ID:Kxe1JjXm.net] 「ルールだからダメ(思考停止)」な人って結構いるよね 477 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:40:55.17 ID:rpwFU8e5.net] ルールの背景を考えずに破ろうとするやつも多いけどな。 守破離は基本だろ。ブルースリーのパンチキックの逸話でもいいけど。 478 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:47:18.19 ID:Kxe1JjXm.net] >>477 合理的なロジックがないという点で同類じゃね 「ルールだから問題ない(思考停止)」で他人に迷惑をかけるのも同じ そして多くの場合無責任までセットだ 479 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 19:54:21.56 ID:bVNNfLSa.net] そもそも失敗できなくするのがここ10年ぐらいのトレンドだろ。 だから静的型やRustが支持されるわけで。 480 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 20:07:33.02 ID:rpwFU8e5.net] >>478 ルールについては「決定と実行の分離」という重要な側面があるよ。 頭のいい奴がルールを作れば、アホがルール通りに実行しても被害は少ない。アホがルールを破るよりよほどマシ。 481 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 20:20:31.75 ID:9WtqRr2n.net] Rustの制御構文としては 昨年末の2つの追加で 従来は不便で需要が多かった形が無事に解決したから一段落かな 482 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 22:05:48.35 ID:nhsBAAgr.net] >>465 わかる 旧世代言語のニオイがする 483 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 22:51:32.40 ID:YnVskMRN.net] こういうの書くやつが出るから 基本は使わないほうがよさそうだな https://github.com/rust-lang/rust/issues/48594/partials/load_more#issuecomment-1184213006 484 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 23:06:57.24 ID:QonGkYb5.net] 草 何らかの目的で大域脱出を用意すると必ず妙ちくりんな悪用を考える奴が出てくるんだよな 485 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2023/02/09(木) 23:22:20.06 ID:zt0qN6wf.net] そういえばコンテナのイテレーションの順序が未規定なときに 順序に依存したコードを書かないように乱数でわざとデタラメな順序にしたら 乱数生成器として使うやつが出てきたって話があったな。 どんな機能も下手に使ったら無茶苦茶にしうるってのはもうどうしようもなくない？ 486 名前：デフォルトの名無しさん mailto:sage [2023/02/09(木) 23:42:25.26 ID:iUuqvbE0.net] >>56のが実現したらRFCの例は||で代替可 let result = (first_container.iter().find(|&&v| v > 0) || second_container.iter().find(|&&v| v < 0)) .unwrap_or(&0); labelやbreakの手続き的なやり方よりこっちの方が汎用性も高いしrustの目指すべき方向に合ってると思う 487 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 01:49:50.47 ID:JoKDyp+E.net] メソッド抽出は嫌 クロージャの即時実行も嫌 ラベル付きbreakならOK！ って感覚が俺には理解できんが ニーズがあるならいいんじゃね 488 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 02:22:12.82 ID:KiCBMwJT.net] >>487 関数切り出しやIIFEだと式の値はResult型になるようなところで、 ラベル付きブロックだとエラーまわりは親の関数に完全に任せて該当の式の値を生で返せる 489 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 02:35:52.13 ID:8y57Q10t.net] ラベルでジャンプより、関数の入れ子の方が分かりやすくない？ 490 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 03:36:08.11 ID:eoPLVAGF.net] >>488 ？オペレータ使えばいいだけなんだが？ 逆にエラーまわりだけ親関数に任せるとかヤバくね？ 491 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 06:59:25.26 ID:Fpp4vOr0.net] >>489 ラベルでジャンプしていない loop式の構文のloop抜きと動作も概念も全く同じだから 今回Rustはたまたま同じ構文を採用しただけ 例えば>>460の例は ラベルを用いない別の新たな構文{{…}}を導入すればこうなる let result = {{ 　for i in 0..100 { 　　if f(i) { 　　　return Some(i); 　　} 　} 　None }}; 動作も意味も全く同じであり ラベルにジャンプしていないことが理解できるだろう 492 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 07:32:00.75 ID:Fpp4vOr0.net] そしてRustがなぜ今回の構文の形を採用したか ・returnでもbreakでも多重になった時にどれを終えるのか曖昧になるため何らかの指定は必要 ・ラベルによる指定はRustの他の構文でも共通に既に使われており親和性がある ・returnの使用は混乱を防ぐために関数とクロージャーから返る位置付けのみに保ちたい ・既存のloop式と今回の構文はloopキーワードを除けば全く同じであり導入前はloop式で代替されていた 493 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 07:54:41.21 ID:Fpp4vOr0.net] >>489 必要性に応じて関数として切り出すのも構わない そして関数として分離した方が好ましい場合もあるだろう しかし常に関数切り出しを強いられる言語だったとしたら煩雑すぎて機能不足と言えるから使い分けできることが必要 494 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 08:05:40.53 ID:nOIBi0US.net] >>491 文脈読めなさ過ぎw 495 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 08:18:49.59 ID:Fpp4vOr0.net] >>494 従来からforやloop式で使われてきた早期return(離脱)つまりRustでのラベル指定break そして今回Rust導入されたブロック式での早期return(離脱)つまり同様に構文としてはラベル指定break それらに対して「ラベルでジャンプ」とは何を言いたいのか？ 496 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 08:34:37.12 ID:wb0Nj+xg.net] >>486 短絡orに論理orを使うのは混乱の元だから、別の専用の記号を用意して欲しいわ。 497 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 08:39:40.06 ID:Fpp4vOr0.net] >>496 遅延評価orの型が 現在はbool型のみに制限されているから それをOption型などにも使えるようにしよう！という話じゃないかな 498 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 08:41:20.86 ID:KiCBMwJT.net] >>490 関数に切り出した時点で「その範囲のResultの型」を考慮しなくちゃいけなくなるから?演算子では何も解決してないし、 切り出さなきゃ元からその関数の処理だから何もやばくないぞ 499 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 08:50:58.78 ID:Fpp4vOr0.net] 関数切り出しすると その中でも継続して使う変数(値)を参照として全て渡してそれらの型宣言も改めて行なってと煩雑さとコードの重複が大きい もちろん返り値型も型推論で済まなくなり明確に宣言しなければならなくなる したがって関数切り出しの方が明確にメリットが上回るケースを除いて 適材適所でブロック式で済ませられるようになった今回の導入は大きな意義があると思う

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef