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/ 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] 関数切り出しすると その中でも継続して使う変数(値)を参照として全て渡してそれらの型宣言も改めて行なってと煩雑さとコードの重複が大きい もちろん返り値型も型推論で済まなくなり明確に宣言しなければならなくなる したがって関数切り出しの方が明確にメリットが上回るケースを除いて 適材適所でブロック式で済ませられるようになった今回の導入は大きな意義があると思う 500 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 09:14:00.68 ID:8y57Q10t.net] 関数切り出しじゃなくて、関数のネスト 501 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 09:39:52.23 ID:FTCkglUc.net] >>491 動作も意味も全く同じとのことだが その構文でネストしたブロックから抜けられるのかい？ 502 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 09:47:31.36 ID:XC30Ey72.net] >>496 今も||は「短絡論理OR」で区別されてないよ 短絡論理ORと論理ORを分けてる言語ってある？ 503 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 09:58:49.88 ID:zTpuYOFQ.net] 5年もの歳月を費やしてstabilizeするほど意味ある機能じゃないよな 超ニッチなnice to haveなんだからこんな機能実装するくらいなら他の作業してくれよ 504 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 09:58:58.37 ID:f/xkkyji.net] >>500 Rustで関数のネスト定義は可能だけどスコープを親関数内に限定するだけだよね 親関数の変数をもちろん操作できないので改めて引数も戻り値も全て型宣言して受け渡ししなければならない 505 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 10:00:29.07 ID:76BGvvFm.net] >>500 関数のネストでやるためには 関数に切り出す必要があるから同じことを言ってるんじゃない？ 506 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 10:06:08.19 ID:f/xkkyji.net] >>501 forやloopを使ったときにどのbreakか区別できるようにラベルが付いてるだけでラベル付ブロック式のネストまでは元々求められていないんじゃないかな たまたまラベル付となったからネストさせて指定して抜けることも可能なのかも知れないけどさ 507 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 11:35:14.97 ID:D7CjmUqS.net] >>506 指定したラベル位置に制御を移すような動きのことを一般的にはジャンプと呼ぶ ラベルで指定したブロックを”抜ける”と呼ぶ感覚ももちろん理解できるが同じようにジャンプと呼ぶ感覚くらいは理解してやれって話 508 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 12:14:15.40 ID:53cyCMdn.net] >>503 ブロック式の早期離脱機能は同時に導入されたlet elseと並んでRustにとって必須の機能 これまではブロック式で早期離脱が出来なかったため代替処置として ・ブロックの代わりにわざわざクロージャを用意して即時実行する ・ループさせないのにloop式を目的外でブロック式として用いる ・関数として切り出して引数型や戻り型などコードが無駄に膨らむ 以上3通りの方法が苦しい回避処置として取られてきた この問題が一気に解決した 509 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 13:14:46.92 ID:OY+cHUF0.net] >>508 おまえホント壊れたレコードみたいだな 馬鹿の一つ覚えで繰り返し同じことしか言えないからおまえが出しゃばってくるとすぐスレが腐る 510 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 13:40:49.41 ID:icbsua9B.net] オジさんは即時実行マンセー派だったのに宗旨替えしたのかw と言っても忌み嫌われてた即時実行から半歩前進して半歩後退してるみたいなので実質進歩してないな 511 名前：デフォルトの名無しさん [2023/02/10(金) 14:05:25.21 ID:aIK+hWQq.net] いわゆる　Rewrite it in Rust　といわれる 　　https://zenn.dev/tako8ki/articles/2021-06-awesome-alternatives-in-rust ものだが、CoreUtil代替もでてきたようだ。 　　https://www.phoronix.com/news/Rust-Coreutils-uutils-2023 そのうち、ls や cp , mv みたいなものも実はRust実装でしたという時代がくるのか？ 512 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 15:10:52.96 ID:p1oXUla5.net] 誰もが必ず使うエラーまわりには散々ボイラープレートを要求するくせに ブロックからの早期returnが必要なくらいの処理を関数に切り出したくないという理由だけで プチgoto入れちゃうのはバランス感覚おかしいわな 513 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 15:25:57.81 ID:EzUIw58a.net] ブロック式も関数も複数の文をひとつの式にするものだから関数から早期returnできるならブロック式から早期breakできてもええやん😁 514 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 16:46:17.45 ID:ec863R6+.net] returnやbreakのことをgoto扱いしてる人は頭おかしい むしろgotoを排除するために現在の言語ほとんどに備えられている ラベル付breakをサポートする言語も多い 515 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 17:26:28.28 ID:TiW7YUw7.net] レスバしかしてねーなお前ら 516 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 17:37:10.71 ID:gd5eXGUi.net] Rustの機能はすべて素晴らしいということにしないと気が済まない人がいるのはよく分かった 517 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 17:57:37.26 ID:8u6orso3.net] マクロは強力なのはいいけど出来は悪いと思う 518 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 18:07:23.86 ID:VmkjxzjW.net] Rust の機能が全て優れてるとは思わないけど ラベル付き break なんて揉めるような機能じゃないだろ... 519 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 18:07:48.18 ID:ec863R6+.net] Rustに限らず早期return、早期breakはどの言語でも要 520 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 19:02:21.11 ID:MJOsdNRe.net] ブロックからの脱出とジャンプを同列に考えるやつは勉強不足だと思うがね。 Rustのスタックフレーム志向とかを考えれば、ブロック出入り操作を重視するのは自然。逆にスタックフレームの局所性を破壊する例外フローとかジャンプは嫌われて当然だわ。 例外フローにおけるエスケープ解析て確立しているんだっけ？ 521 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 19:02:40.14 ID:MoSIyINf.net] 規約で禁止していいレベルの機能 Avoid labelled break. Use functions instead. 522 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 19:05:14.63 ID:53cyCMdn.net] >>509 唐突に発狂されても意味不明 反論があるなら技術的な話でお願いします 523 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 19:06:54.13 ID:MJOsdNRe.net] >>521 関数みたいなブロックを作ればいいんじゃない？ あるいはブロックみたいな関数とか。 524 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 19:07:09.08 ID:MJOsdNRe.net] >>521 関数みたいなブロックを作ればいいんじゃない？ あるいはブロックみたいな関数とか。 525 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 19:24:57.65 ID:VelAUwkm.net] >>521 Rustには何年も前からラベル付breakがあります 今さら文句をつけている人はRustを知らずイチャモンを付けたいだけだとバレていますよ メジャーなプログラミング言語の大半がラベル付breakを備えています JavaでもSwiftにもGoもJavaScriptすらラベル付breakを持っています プログラミングにおいて必須の機能だからです 逆にラベル付breakを持っていない代表的な言語がC/C++です 今回のRust叩きをしている犯人はいつもと同じ人だと分かります 526 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 19:52:12.29 ID:ec863R6+.net] breakに対してジャンプだとかgotoだとかトンデモ発言が出ていたのはそういうことか C/C++しか知らないと多重ループすらgotoで抜けるしかないもんな そういう貧弱な世界しか知らない視野の狭い人だから必死にRustを叩いていたわけか 527 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 21:33:52.77 ID:zr0HQZhu.net] 前から常駐してるアンチRustのやつだろ ばればれだがアンチとばれないように装いつつRustの色んな点を批判してきた 特にRustならではの機能とか新たな機能とかRustらしい書き方とかを嫌う 528 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 22:57:01.58 ID:9GdW2Tn6.net] 同じことしか言わないから自演丸分かりやんww 529 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 22:59:03.20 ID:Y2H2O9Fe.net] >>525 大半の言語が備えてるラベル付breakはループから抜けるものでブロックから抜けるものじゃないぞ 530 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 23:14:34.63 ID:z32i1LMi.net] swiftがdo statementでブロックスコープから抜ける機能を用意してるがtry/catchなしの形では誰も使ってない 531 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 23:16:17.28 ID:TiW7YUw7.net] そんなことよりさっさとif let Some(c) = chars.next(); c.is_whitespace() {とかって書けるようになってほしい 532 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 23:22:50.62 ID:KiCBMwJT.net] ブロックは「必ず1回で終了するループ」と解釈可能なのでループからのラベル指定breakがあるならブロックからもbreakで抜けられる方が自然 533 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 23:24:33.98 ID:PcQ6rbEj.net] Javaも文法的にはループ以外でもラベル付きブレイク使えるけど絶対使わないな 534 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 23:32:27.37 ID:Qit9LgYB.net] >>532 その理屈でいけばラベルなしブロックからもbreakで抜けられないとおかしくない？

---

---

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

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