Rust part19 - 暇つぶし2ch

Rust part19 at TECH

[前50を表示]
350:デフォルトの名無しさん
23/02/03 18:59:27.03 NDb3ccU3.net
Box<dyn Error>もErrorトレイト実装してないよ(コンフリクトで実装できない)
その点はdyn Errorで返してもanyhowで返しても大差ない
libraryのpublicなAPIでtype erasedなエラーを返したいときは
Errorを実装した独自のエラー型を用意するのが普通
anyhowで返してる有名ライブラリもあるけどね
ライブラリでanyhow使ったらダメなんてことは特にないんだけど
Readme読めばすぐわかるように基本的にはアプリケーション用
なぜ同じ作者のエラー系のライブラリがanyhowとthiserrorと2つあるんだろうか？
と疑問に持つだけでも初心者はstdベースで学習するよりも1歩先に進めてる

351:デフォルトの名無しさん
23/02/04 00:38:01.54 5aCWsuCk.net
ダウンキャストは静的チェックできず変更に弱いからホイホイ使うものじゃないよ

352:デフォルトの名無しさん
23/02/04 07:20:32.73 eqpqpGi8.net
>>351
ダウンキャストは静的に型を指定して
Some()で静的な型で値が返ってきて
その値の使用も静的に型チェックされる
「マッチングが動的ではないか？」については
Enumで複数の型を収容した場合と全く同じ
どちらの場合もマッチングは動的に行われるが静的に型チェックされる
どちらも静的に型を抽象化した定数の整数値との比較によるマッチングとなる点も同じ

353:デフォルトの名無しさん
23/02/04 09:46:17.84 4OrKEijd.net
ばかばかc

354:デフォルトの名無しさん
23/02/04 09:59:08.11 wSUDs8sY.net
Rustのdynとそのdowncastは安全性と最小限のコストを両立させており安心して使える
引数などでimpl Traitが使える場合はimplが有利なケースもあるが
返値などでdyn Traitしか使えない場合もあり適材適所で使い分け

355:デフォルトの名無しさん
23/02/04 10:30:58.71 yB06Lfm4.net
>>352
よくわかってないものを人に勧めちゃダメだよ

356:デフォルトの名無しさん
23/02/04 12:22:28.04 eqpqpGi8.net
久々に荒らし発生かな

357:デフォルトの名無しさん
23/02/04 12:44:13.93 vEFKnpWX.net
ダウンキャストの安全性みたいなのは downcast_ref 使ってりゃ議論の余地はないと思うけど網羅性は限界があるわね。
ライブラリはやっぱエラー型を明示すべき。

358:デフォルトの名無しさん
23/02/04 13:10:09.04 QerlffZr.net
match式によるパターンマッチでは、そのマッチアームによる条件網羅性がコンパイル時に検証される。
enumとmatch式は相性抜群だよな。
URLﾘﾝｸ(doc.rust-jp.rs)

359:デフォルトの名無しさん
23/02/04 13:39:49.84 A1ugYU/e.net
エラー処理で網羅性は関係ないだろ
std::io::Errorのenum ErrorKindからしてnon_exaustive指定だぞ
match式で網羅性はチェックされない
特別な処理が必要なエラーだけ処理対応して残りはエラー表示が普通だ

360:デフォルトの名無しさん
23/02/04 13:52:58.01 RtFCJdnN.net
エラー処理で重要なことは
・エラーが発生しているにも関わらずそのまま通常処理を進めないこと
・エラー表示以外の対応を必要とするエラーの場合にその対応をすること
・それ以外のエラーはエラー表示などをすること
enumタグレベルの網羅性を求められることはないな

361:デフォルトの名無しさん
23/02/04 14:46:52.23 7PnUG+Eh.net
元々の話はdyn Errorかanyhowか、だったような気がするけど、
anyhowはdyn Errorの自作ラッピングみたいなもので、
とちらを使ってもダウンキャストしなきゃいけない点も網羅性がない点も同じだよね。
そしてそれらをアプリ側で使ってる限り困ることもない。

362:デフォルトの名無しさん
23/02/04 17:06:34.73 1vu2ZDPp.net
そもそもがダックタイピングとか向いてる言語じゃない。
フロントでこの言語使おうとするとかただのバカでしかないわ。

363:デフォルトの名無しさん
23/02/04 17:36:37.29 roDrLtFP.net
唐突にフロントとかダックタイピングとかどうした？
しかもその二つも関連性がない

364:デフォルトの名無しさん
23/02/04 18:06:27.05 uIknpDmG.net
上位レイヤーも含めてエラーの内容によって分岐したいならdyn Errorはやめたほうがいい

365:デフォルトの名無しさん
23/02/04 18:34:38.01 srvPtSil.net
分岐にenumのタグを使うかErrorの型名を使うかの違いでしょ
enumを使うと一貫性を担保しやすいから保守性が向上するし
dyn Errorを使うとenumの定義を省略できるからコードを減らせる
自分は（分岐するなら）enum派だけど何を重視するかで結論が変わりそう
ただ「やることが一緒だからどっちも同じ」と考えはいただけない

366:デフォルトの名無しさん
23/02/04 18:40:15.09 3y1LLse5.net
>>364
dyn Errorをやめるべき理由がない
まさかと思うが代わりにanyhow使えとか言い出すんじゃないんだろうな？

367:デフォルトの名無しさん
23/02/04 19:00:20.00 eqpqpGi8.net
dyn Errorもダウンキャストも使用して全く問題ないよ
有名どころでも普通に使われている
例えばreqwestはdyn Errorを使っていてdowncast_ref()してエラー処理している
cargoはanyhowを使っていてdowncast_ref()してエラー処理している
使うのをやめたほうがいいと主張している人は一種の宗教にすぎないことに気付こう

368:デフォルトの名無しさん
23/02/04 22:40:19.42 JjHQagj1.net
勘違いしてる内容が同じだから
自演しまくっても同一人物なの丸分かりだね
ダウンキャストオジ==複オジ

369:デフォルトの名無しさん
23/02/05 02:20:20.64 VCqNNrEk.net
無敵やな
もちろんいい意味で

370:デフォルトの名無しさん
23/02/05 02:25:01.54 a/eU++XN.net
一年ぐらい前にanyhowを標準化する、みたいな話なかったっけ？

371:デフォルトの名無しさん
23/02/05 02:59:04.83 26rYdUrG.net
anyhowはダウンキャストするしかないクソ

372:デフォルトの名無しさん
23/02/05 06:00:11.27 TqN0qcyT.net
オライリーの本って出てから1年経つけどさあ
これの電子版って、セールになったりする機会ってあるもんなの？

373:デフォルトの名無しさん
23/02/05 06:31:13.67 qzS4+JVd.net
ダウンキャストを毛嫌いしてる人の心理を知りたい

374:◆???
23/02/05 12:21:29.64 gCGZ2Fk+q BE:2843802656-2BP(0)
std::mem::transmute

375:デフォルトの名無しさん
23/02/05 12:11:30.30 vL4nY6Md.net
>>359-360
おまえはまるで何もわかってないのな
エラーハンドリングの基礎すらおさえてないじゃん
無知なのはいいが自信満々で嘘を書きまくるのはやめろ

376:デフォルトの名無しさん
23/02/05 12:37:36.14 yQ5U4c14.net
作るシステムの性質や分野ごとで許されるエラーハンドリングは別物だからね。
ミッションクリティカルだけが正解ってわけでもないのよ。

377:デフォルトの名無しさん
23/02/05 14:02:09.96 dIeXO9aa.net
>>376
何がまちがってるかさえも分からないようならThe Bookを一から読み直して出直してこい

378:デフォルトの名無しさん
23/02/05 14:22:39.74 Ib1Yzzhk.net
たまに出てくる「間違っている」「勘違いしてる」「嘘を書くな」の人
今までも文句をつけるだけで正確を書いたことがないから信頼できないのよね

379:デフォルトの名無しさん
23/02/05 14:23:18.13 8OOQa3AE.net
どっちも自分の脳内シチュでしか語ってないからふわっふわで論破出来るわけもなし
自分の主張が通る具体例上げるといいよ

380:デフォルトの名無しさん
23/02/05 14:35:53.55 LY0V54Tb.net
｢カッコウのアルゴリズムさえまともに実装できてないからクソ遅いんだよな｣
みたいに適当なワード混ぜて意味不明なこと言いつつ同意してる風を装うと｢そうなんだよ！｣とか勝手に乗っかってきて自爆するから面白いぞ

381:デフォルトの名無しさん
23/02/05 15:42:56.66 XUJKjP/6.net
>>378
それは信頼以前に、相手にしなくていい外野
 >>380
すごく目に見えるわその展開ｗ

382:デフォルトの名無しさん
23/02/05 15:53:21.98 ANWYibFj.net
>>373
台所まで行けば箸（enum）があるのに手元のフォークで焼きそばを食べてる感じ
食べてるのがパスタ（Python）なら平気なんだけど

383:デフォルトの名無しさん
23/02/05 16:01:07.42 3wawDpMD.net
>>382
微妙にわかりにくい例えで草
でも複オジに比べると1000倍マシ

384:デフォルトの名無しさん
23/02/05 16:04:59.96 0ZBI/vwq.net
>>378
信頼するかどうかはあなた次第
>>359-360が嘘だらけだということが分からない人は基礎がなってないから勉強やり直すかパスタにするか

385:デフォルトの名無しさん
23/02/05 17:40:20.51 X5wQdMGf.net
網羅性が必要ないならResult使う必要もRustを使う必要もないわな

386:デフォルトの名無しさん
23/02/05 18:32:46.51 rtbv+KUs.net
>>382
凄い納得
enum使わずにanyhow使うような連中はPythonでも使っていろ
anyhowなんてものがあるから勘違いが起こる

387:デフォルトの名無しさん
23/02/05 20:10:29.95 QsKcw+fO.net
cargo crateのコード見てみた
anyhowを使ってエラーを上へ上げていく
enumを使っておらずエラーの網羅性はない
downcast_refを使ってエラー分岐している

388:デフォルトの名無しさん
23/02/05 20:38:51.85 1L9Nz43N.net
エラーなんて作成時点で未知のものが後から増えることもザラだし
何なら抽象レイヤー以下の実装の差し替え（ストレージのネットワーク化とか）で
動的に増えたりすることもあるんだから、網羅性とかすぐ成り立たなくなる。
可能なところで逃すものじゃないけど、こだわるものでもない。

389:デフォルトの名無しさん
23/02/05 21:15:55.10 yQ5U4c14.net
cargo みたいに手元や CI で実行するツールのエラー処理なんてその程度で十分ってこった。
もちろん、網羅が必要な領域のコードじゃそんなエラーハンドリングのやりかたじゃあ駄目だろうよ。

390:デフォルトの名無しさん
23/02/05 21:31:31.79 kVul7/Hf.net
多数の下部ライブラリから色んなエラーが上がってくるreqwestはそれらをdyn std::error::Errorへ入れているね
そしてdowncast_refで必要な分岐をして処理しているね
エラー処理はこれで十分でしょ
網羅しなくても残りは最終的にちゃんとエラー表示されるのだから

391:デフォルトの名無しさん
23/02/05 22:59:47.83 cfofmdL5.net
エラー処理で必須な網羅性とはenumの網羅性とは異なる
いつどこでどんなエラーが発生しても必ず処理されることがエラー処理の網羅性
つまりエラー処理されないまま通常処理に進まないことでありRustではResultの利用によりそれが保証されている
したがってdyn Errorを使って一部をダウンキャストによりエラー処理し残りをエラー表示処理でも網羅性を満たしている

392:デフォルトの名無しさん
23/02/05 23:51:35.27 BjcIBdbF.net
opaqueなerror typeを使うメリットは何なのか？デメリットは何なのか？
少なくともreqwestの開発者はそのトレードオフを検討した上で判断を下している
メリットもデメリットも理解できてないやつが珍説唱えても虚しいだけだぞ

393:デフォルトの名無しさん
23/02/05 23:54:47.07 arvSMdBl.net
>>391
おまえはエクストリームな言い訳並べ立てる前にnon_exhaustiveの意味から調べろな

394:デフォルトの名無しさん
23/02/05 23:58:58.86 QsKcw+fO.net
>>391
やっぱりそれでいいのか
Rustの標準IOライブラリはenumを使っているけどnon_exhaustive指定がしてありenumの網羅性チェックをむしろ使えないようにしてる

395:デフォルトの名無しさん
23/02/06 00:09:01.18 ZXNgtENY.net
>>391
一般的なエラー処理の網羅性はその解釈だな
Rustでは型システムと返り型Result及びResult放置をコンパイラが警告してくれるため必ず網羅される仕組み

396:デフォルトの名無しさん
23/02/06 01:23:09.90 Kt6dB8yb.net
>>394
non_exhaustive指定があると
なぜenumの網羅性チェックが使えないの？

397:デフォルトの名無しさん
23/02/06 06:52:59.94 OJBoAdFu.net
逆だよ
網羅性の扱いを禁止するために意図的にnon_exhaustive指定されている
そのようなエラーの種類には網羅性は必要がないだけでなく
今後もしエラーの種類が増えた場合に全網羅列挙して使用している既存のコードがエラーとなってしまう
そのためこういう時は不要である網羅性の扱いを禁止して全列挙コードを書かせないことで
今後エラーの種類が増えても既存の利用コードに影響を与えずに済む仕組み

398:デフォルトの名無しさん
23/02/06 12:30:43.08 wr+6RDlb.net
>>397
自信満々に間違った情報を中身のない文章で膨らませてもっともらしく見せようとするところがChatGPTそっくりww

399:デフォルトの名無しさん
23/02/06 12:48:04.84 /nZ/7Knj.net
昔ながらの例外論争見てるみたいだ
全部取ればいいいや個別だ

400:デフォルトの名無しさん
23/02/06 14:14:21.50 C/yeK4bx.net
>>397で合っているけど補足すれば
全網羅列挙コードを書いてもコンパイラがそれを許さずエラーとなる
全網羅列挙しなくていいから必ず全マッチの　_ =>　アームをコンパイラが要求してくる
つまりコンパイラによるエラーの網羅性チェックは不可能

401:デフォルトの名無しさん
23/02/06 21:51:09.46 MJNtWgHJ.net
そもそもRust以前に他のプログラミング言語でもそのようなエラーの種類の網羅が行なわれたことはない
IOエラーだけでも何十種類もあり列挙するだけでも大変で意味のない作業
エラー処理で必要とされる網羅性とはエラーの種類を全て列挙することではなく
 >>391の説明が正しい
RustでResultを使えば保証される

402:デフォルトの名無しさん
23/02/06 21:59:33.19 T23InEdz.net
自分の書いたレスを正しい正しいと
一人で連呼してて虚しくならないのかな

403:デフォルトの名無しさん
23/02/06 22:26:04.02 7y0OcpN0.net
エラー処理の網羅性という話は元々
関数からエラー値が返って来る可能性があるのに見落として処理せずに続行しちゃったり
あるいは例外が返って来る可能性があるのに見落として処理しないままでいたり
そういう見落としがよく起きていたから
いつどこでどんなエラー(or例外)が起きても処理漏れがないようにプログラミングしましょうという話
もちろんRustではResultで返せばコンパイル時点でエラーや警告が出るためエラー処理の網羅性は満たされます
Resultを返していればdyn Errorやanyhowを使っていてももちろん大丈夫
そしてエラー処理の分岐にそれらのダウンキャストを使うのも何ら問題なし

404:デフォルトの名無しさん
23/02/07 02:02:21.05 smEuFI89.net
anyhow使ってて困ったことないので、これからもanyhow使いますね

405:デフォルトの名無しさん
23/02/07 02:09:15.61 2blGAjQQ.net
enumで網羅派の完全敗北だな
anyhowやdyn Errorでdowncast_ref分岐して何ら困らない

406:デフォルトの名無しさん
23/02/07 02:13:05.33 fMWAnbF1.net
anyhowは邪道だろ

407:デフォルトの名無しさん
23/02/07 10:30:33.69 jDwZWgRX.net
下手に分かったふりせず疑問をぶつけるパニック君のようなレスはスレにとっては有益
逆に知ったかぶりして嘘を撒き散らす某オジのレスは害しかない
一緒に仕事してても伸びるのは断然前者のタイプ
後者は多少知識があってもチームの足を引っ張る老害タイプ

408:デフォルトの名無しさん
23/02/07 11:56:13.05 Yu/MJcLX.net
>>407
知ったかぶりもだけど
ご飯論法的に毎回論点を捻じ曲げてくるのが悪質
スルー推奨

409:デフォルトの名無しさん
23/02/07 12:39:13.84 GmLWJf7C.net
どの言語を使っていようがテスト設計とエラー処理設計は初心者と脱初心者を見分けるリトマス試験紙
チュートリアルやリファレンス読むだけでは身につかない

410:デフォルトの名無しさん
23/02/07 13:41:38.43 vPUoP0i3.net
そう、IT土方必修

411:デフォルトの名無しさん
23/02/07 20:09:18.77 RZZKb5qe.net
>>410
こういうバカが一人でも入ってくると現場は苦労するわな

412:デフォルトの名無しさん
23/02/07 22:03:06.31 u8XyY9YO.net
今回のケースはRustのエラー処理を他の言語（C#あたり）の例外処理に寄せようとしてる感じ
「特定の例外クラスをcatchしたい」→「dyn Errorで投げてダウンキャストで分岐すればいい」みたいな
anyhowはそういう人のためにあるのかもしれない
オブジェクト指向言語専攻の人はRustのtraitを基底クラスの代わりに使いがちだよね
is-a継承はRustだとenumで表現できる場合が多いんだけど切り替えが難しいのかも

413:デフォルトの名無しさん
23/02/07 22:27:27.04 23ICgzsB.net
単純にエラーの種類を列挙する意味がないときに使うだけやで

414:デフォルトの名無しさん
23/02/07 23:09:28.73 u8XyY9YO.net
それならいいんだけど型キャストしてまで分岐するとか言ってる人がいたから
自分で分岐する範囲くらいは自分で列挙しとけって話

415:デフォルトの名無しさん
23/02/07 23:53:31.04 23ICgzsB.net
下層から上がってくる99種類のエラーはログ吐かせるだけで、特別な処理したいエラーはひとつしかないのにいちいちenumに詰め直したりせんわな

416:デフォルトの名無しさん
23/02/08 00:04:28.76 mV68xos2.net
逆
自分で分岐してエラー処理すんなら区別すべきエラーを決めるのは自分なのでanyhowやdyn Errorでダウンキャストしても問題ない
外から呼び出されるコードなら区別して処理するエラーを決めるのは呼び出し側なので区別できるようにenumで書く

417:デフォルトの名無しさん
23/02/08 00:35:28.79 ydIblX/+.net
すまんが、これってなんでダメなの？
ブロックの最後に式を書いてるのに、なんでreturnって書かないとリターンしないの？？？
そもそもエラーの内容に書いてあるmismatched typesって、一体何と何のタイプがミスマッチなんなんだ・・・・
URLﾘﾝｸ(play.rust-lang.org)
エロい人教えて！！！

418:デフォルトの名無しさん
23/02/08 01:51:02.48 U3de6tMw.net
>>417
else句が無いのでifの条件式がfalseの場合はif-expressionは()になるけど
ifの条件式がtrueの場合はif-expressionがi32になるのでミスマッチ

419:デフォルトの名無しさん
23/02/08 01:59:22.59 W8WwzKcT.net
>>415
ログを吐かせるだけでもエラーによってログの吐き方を変えたいこともよくある話なのでケースバイケース
99種類を2種類に詰め直して片方をerased typeにしたりする

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

421:デフォルトの名無しさん
23/02/08 10:45:01.05 ENpYrX9l.net
ダウンキャストは下位モジュールに不必要に依存することになるので選択の余地があるなら基本的には使うべきではない
自crateで定義したエラー型にダウンキャストするくらいならエラーを定義するついでにenum書いとけばいいだけ
他crateで定義したエラー型にダウンキャストしてるとバージョンアップ時にサイレントにキャストが失敗して動作が変わる
あくまで非常口であって使わざるをえないときはマイナス面を理解した上で注意深く使うもの

422:デフォルトの名無しさん
23/02/08 10:52:13.58 fJPPomwd.net
UnknownErrorにわざわざ詰め直したログ吐くしかできない99種類あったエラーと1種類の自クレートのMyErrorをenumで2つ列挙して分岐するのと
MyErrorも含めて100種全部dynで上げてMyErrorだけダウンキャストすることの間に大した違いはない

423:デフォルトの名無しさん
23/02/08 12:29:34.73 /lg+THEr.net
アプリケーション開発とライブラリ開発の2つの視点があって、それぞれで戦略が違うというのが大元にあるからそこは理解してもらわないとね。

424:デフォルトの名無しさん
23/02/08 12:40:19.14 TursxKDi.net
ライブラリでdyn Error使うと本体の型がpubじゃないときにめんどくさそう

425:デフォルトの名無しさん
23/02/08 12:45:18.46 QfEWSkwW.net
両者で大きく異なるよね
ただし既出のcargoやreqwestなど違いに関わらずダウンキャストを使っているコードも多いから
どっちだと良くてどっちだとダメというものでもない気がする

426:デフォルトの名無しさん
23/02/08 12:48:39.58 QfEWSkwW.net
424は422へのレスね
 >>424
そこはenum作って収容しようがdyn Errorに収容しようが関係なくpubじゃない型はどうにもならないような

427:デフォルトの名無しさん
23/02/08 13:05:56.18 B9DUhvwN.net
>>422
どういう種類の変更に対してコードのどの部分に手を入れる必要が出てくるのかを考えてみるといいよ

428:デフォルトの名無しさん
23/02/08 13:15:25.12 Fgr/3fzw.net
求められてもない具体性のない中身のない全く役に立たないアドバイスは有害でしかない

429:デフォルトの名無しさん
23/02/08 13:35:42.99 DnIJ53A+.net
現実にdowncast_ref()が使われているアプリやライブラリが多数あり
それらが問題になったことはないのだから
downcast_ref()を嫌っている人は思い込みで好き嫌いに過ぎないことを理解しようぜ
enumを作っても下位のエラー型を突っ込むだけでは何も変わらない

430:デフォルトの名無しさん
23/02/08 14:12:14.99 SqObziFu.net
ここまで具体的なコード例なし

431:デフォルトの名無しさん
23/02/08 14:40:13.85 J3DHyZUt.net
前提条件付けて場合分けして考えろ
てかこんなことでスレの半分近くも消費すんな

432:デフォルトの名無しさん
23/02/08 16:15:41.93 ydIblX/+.net
>>418
そうだったのか！returnを書いたら通るのも、そうするとどちらも戻り値が()同士で統一されるってことか！
ありがとう！全然わかんなかったぜ！

433:デフォルトの名無しさん
23/02/08 16:16:54.39 VvFQM19K.net
>>418
>>417では無いが、そういう意味だったのか
単に厳し目にチェックしているからだと思っていた

434:デフォルトの名無しさん
23/02/08 17:13:58.11 e6ub/0SO.net
たぶんだけど「Rustでは値を返すのにreturnを省略できる」と誤解してるんじゃないかな
その誤解のためreturn bのreturnを省略してしまったと思われる
正しくは「Rustでは最後の値が返り値となる(のでreturnが不要)(だが使ってもよい)」
と「途中で返したい時はreturnを使う」
だから今回の例だと
if文の中では『途中だから』return bとbにreturnが必須
あるいは関数の最後をif-else式にしてしまえば『最後となるから』bにreturnは不要

435:デフォルトの名無しさん
23/02/08 17:28:24.72 e6ub/0SO.net
ちょっと誤解があるから追加
最後をif-else式にすれば全体に式returnのreturnが不要になる
そしてif-else式の中はreturnは不要というか付けない
そこにreturnを付けるとif-else式ではなぬif-else文になる

436:デフォルトの名無しさん
23/02/08 18:12:57.92 uJD0QVJP.net
文章を難読化しすぎやろw

437:デフォルトの名無しさん
23/02/08 18:22:49.80 KYgqZ0R0.net
面倒だから戻るところはすべてreturn書いてる

438:デフォルトの名無しさん
23/02/08 20:39:29.96 EOwXjjdD.net
return式の型は厳密には!なんだけど……
まあ後で知ればいいか

439:デフォルトの名無しさん
23/02/08 20:50:18.79 e6ub/0SO.net
そのおかげでif式でreturnしつつelseで値を与えたりできるね

440:デフォルトの名無しさん
23/02/09 11:57:24.62 w55r8U1C.net
早期returnはバグにつながるから禁止が常識

441:デフォルトの名無しさん
23/02/09 12:14:59.38 bVNNfLSa.net
>>440
昔はそう言われたけど今はそんなカス風習廃れたしRustに持ち込まないでほしい。

442:デフォルトの名無しさん
23/02/09 12:15:50.03 UhaInviD.net
早期returnは（>>440みたいなアホが使うと）バグにつながるから禁止が常識

443:デフォルトの名無しさん
23/02/09 12:41:16.10 S7fEOBGh.net
わざわざ早期リターンのために?演算子なんて用意してるRustで早期リターン禁止とな？！

444:デフォルトの名無しさん
23/02/09 12:43:02.37 EmRyIpwb.net
スルースキル皆無か

445:デフォルトの名無しさん
23/02/09 13:10:12.86 wPt4Q+MY.net
なんで昔は早期returnがバグにつながると考えられてたの？
どう考えても早期returnしない方がバグにつながりやすいと思うんだが

446:デフォルトの名無しさん
23/02/09 14:20:08.85 QqGr+Vdk.net
もっと昔にgotoの使いすぎで制御構造がぐちゃぐちゃになったことへの反動で
複雑な制御構造は使わないようにしよう、という流れだったかと

447:デフォルトの名無しさん
23/02/09 14:55:47.47 UhaInviD.net
>>445
C言語時代の話な
例えばこういうパターンでメモリーリークしたりするバグがたくさんあった

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

448:デフォルトの名無しさん
23/02/09 15:21:57.59 9WtqRr2n.net
そのあたりも自動メモリ開放のRustなら大丈夫だね
if文で早期return/continue/breakしないと、どんどんifネストが深くなっていくのでそれを避けたい

449:デフォルトの名無しさん
23/02/09 15:37:28.09 Ktnp537B.net
>>447
リソース確保・解放するレイヤーとそれを使って処理を行うレイヤーを分ければよくない？
f(...){
p = malloc(...);
g(p, …);
free(p);
}
g(…) {
...
if(...) return;
...
}
ifのネストが浅くなっても逆に関数のネストが深くなりすぎて読みにくくなる側面があるということなのかな？

450:デフォルトの名無しさん
23/02/09 15:51:48.67 oQtbOpVY.net
>>449
分けましょうってルール化したくらいで完璧に守られるなら誰も苦労しないんだよな…
そのうち処理レイヤー側でmallocするやつが出てくるやつ

451:デフォルトの名無しさん
23/02/09 15:59:20.91 Ieoj7bJI.net
RAII無しでの話なんかRustに関係無いだろ。

452:デフォルトの名無しさん
23/02/09 16:04:18.76 1694Wm1I.net
ifがネスとしていたりした場合に、returnみたいにif-expressionの方に結果を返したい時ってどうすればいいの？

453:デフォルトの名無しさん
23/02/09 16:22:54.26 eQhq+cyr.net
>>450
早期returnはやめましょうルールは完璧に守られる保証があると？

454:デフォルトの名無しさん
23/02/09 16:24:27.43 g7YoScpU.net
>>452
擬似コードでいいのでイメージを書いてくれ
でないと言いたいことが分からない

455:デフォルトの名無しさん
23/02/09 16:25:56.79 VnFQyKoO.net
>>452
最近入ったラベル付きブロックでbreak

URLﾘﾝｸ(rust-lang.github.io)

456:デフォルトの名無しさん
23/02/09 16:36:32.32 8ktpZl0b.net
言語仕様的に可能でも規則で縛ることで安全を担保しようという方法は
いずれ失敗するからそういう要素は必ず言語側の仕様で保証すべき、というのがRustの思想なんだから
「あれは危険だから駄目、コーディング規則で縛る」という発想自体が間違ってる

457:デフォルトの名無しさん
23/02/09 16:43:33.27 UhaInviD.net
>>449
リソースが１つだけならいいかも知れないけど複数リソースが絡んでたりすると色々ややこしいコードになっちゃう
>>453
コードレビュー時に return 検索したら

458:デフォルトの名無しさん
23/02/09 16:44:45.59 UhaInviD.net
>>451
>>440 に言ってくれ

459:デフォルトの名無しさん
23/02/09 16:48:27.59 jx1YaHu3.net
>>457
なるほど
そういう方法だけに頼ってるなら早期returnのほうが見つけやすいわな

460:デフォルトの名無しさん
23/02/09 16:49:18.29 9WtqRr2n.net
こういうやつ？
let result = 'found: {
　for i in 0..100 {
　　if f(i) {
　　　break 'found Some(i);
　　}
　}
　None
};

461:デフォルトの名無しさん
23/02/09 17:15:30.09 1694Wm1I.net
>>454-455
>>460
やりたかったのこれだ、せんきゅー！

462:デフォルトの名無しさん
23/02/09 17:27:44.71 vSSl5weC.net
最近はCでもcleanup属性というのが使えるんだな

463:はちみつ餃子
23/02/09 17:43:07.29 zt0qN6wf.net
>>445
構造化が重要視された時代がある。
順次・反復・分岐によって処理の流れを構築するという点から見ると
早期リターンは流れをすっとばして大ジャンプしてることになるので
コードを追うのを難しくすると考えられていた。
「出入口はひとつずつ」は基本思想だったんだよ。
構造化が不十分だった時代にまず構造化することが大事だったという話。
今では構造化が当たり前になったから次の段階として順次・反復・分岐という構造だけでは
上手く扱いづらい部分をどうやるのがいいのかという模索が続いてるわけ。

464:デフォルトの名無しさん
23/02/09 18:03:17.12 9WtqRr2n.net
戻るgotoは結局なんらかのループを表しているので
Rustならラベル付loopに指定continueで表せる
進むgotoは無制限ではなくラベル指定breakの大域脱出型に制限される
という認識で合ってる？

465:デフォルトの名無しさん
23/02/09 18:18:38.11 xZSrodqJ.net
>>455
なんか微妙な機能だな
関数化して早期returnさせる手間が嫌ということなんだろうけどそれなら||や&&オペレータをOptionやResult用に上書きできるようにした方がずっと使いやすい
tryブロックとの非対称性も気になる

466:デフォルトの名無しさん
23/02/09 18:30:28.03 9WtqRr2n.net
>>465
今までに既にあった機能のラベル付loop式のラベル指定breakという使われ方のうち
ループしない使われ方が多かったため事実上のシンタックスシュガーが導入されただけだよ
だから微妙な機能が追加されたという見方は正しくない

467:デフォルトの名無しさん
23/02/09 18:30:33.67 QonGkYb5.net
>>465
ほとんどの場合はこんなん使う前にその部分を関数に切り出すことを考えるべきというのはめちゃくちゃ言われてる
awaitとかResultとかライフタイムとかいろいろ絡んできたときに再利用もされない数行の処理のために長々と型を書かなくても済むのがユースケースのひとつと思われる

468:デフォルトの名無しさん
23/02/09 18:46:56.04 RAzSpXh0.net
>>466
シンタックスシュガーも機能やろがい
公式にもlanguage featureと書いてるぞい

469:デフォルトの名無しさん
23/02/09 18:50:34.43 hFEBZw9k.net
どうせなら仮変数みたいな変数割当機能も用意して、末尾最適化再帰風ループもできるようにならないかね。

470:デフォルトの名無しさん
23/02/09 18:53:10.62 9WtqRr2n.net
>>468
既に昔から存在していたloop式を
loopと書かなくてもよくなっただけだよ
今までは皆はloop式の最後をbreakすることでloopさせずにこの同じ機能を使っていた
今回でloopを省けるようになったため最後のbreakが不要とだけにすぎない
今さら文句をつけるのが不思議

471:デフォルトの名無しさん
23/02/09 19:02:26.27 o9a7e9s5.net
早期returnってファウラーのガード節の話じゃないん？
あの使い方する限り安全安心可読性改良にしかならないよな？

472:デフォルトの名無しさん
23/02/09 19:04:01.20 EmRyIpwb.net
>>471
ファウラーじゃなくてリーダブルコード？

473:デフォルトの名無しさん
23/02/09 19:05:50.10 o9a7e9s5.net
リーダブルコードは忘れたけど
part of martinfowler.com
URLﾘﾝｸ(refactoring.com)

474:デフォルトの名無しさん
23/02/09 19:15:02.58 9WtqRr2n.net
if letでネストが深くならないように早期return等しようとすると無駄コードが膨らんでいた問題も
同時に導入されたlet elseによって解決されたね

475:デフォルトの名無しさん
23/02/09 19:24:14.80 EmRyIpwb.net
>>473
そうこれ、というか第1版からあるならファウラーが先なのね
失礼した

476:デフォルトの名無しさん
23/02/09 19:31:22.46 Kxe1JjXm.net
「ルールだからダメ(思考停止)」な人って結構いるよね

477:デフォルトの名無しさん
23/02/09 19:40:55.17 rpwFU8e5.net
ルールの背景を考えずに破ろうとするやつも多いけどな。
守破離は基本だろ。ブルースリーのパンチキックの逸話でもいいけど。

478:デフォルトの名無しさん
23/02/09 19:47:18.19 Kxe1JjXm.net
>>477
合理的なロジックがないという点で同類じゃね
「ルールだから問題ない(思考停止)」で他人に迷惑をかけるのも同じ
そして多くの場合無責任までセットだ

479:デフォルトの名無しさん
23/02/09 19:54:21.56 bVNNfLSa.net
そもそも失敗できなくするのがここ10年ぐらいのトレンドだろ。
だから静的型やRustが支持されるわけで。

480:デフォルトの名無しさん
23/02/09 20:07:33.02 rpwFU8e5.net
>>478
ルールについては「決定と実行の分離」という重要な側面があるよ。
頭のいい奴がルールを作れば、アホがルール通りに実行しても被害は少ない。アホがルールを破るよりよほどマシ。

481:デフォルトの名無しさん
23/02/09 20:20:31.75 9WtqRr2n.net
Rustの制御構文としては
昨年末の2つの追加で
従来は不便で需要が多かった形が無事に解決したから一段落かな

482:デフォルトの名無しさん
23/02/09 22:05:48.35 nhsBAAgr.net
>>465
わかる
旧世代言語のニオイがする

483:デフォルトの名無しさん
23/02/09 22:51:32.40 YnVskMRN.net
こういうの書くやつが出るから
基本は使わないほうがよさそうだな
URLﾘﾝｸ(github.com)

484:デフォルトの名無しさん
23/02/09 23:06:57.24 QonGkYb5.net
草
何らかの目的で大域脱出を用意すると必ず妙ちくりんな悪用を考える奴が出てくるんだよな

485:はちみつ餃子 ◆8X2XSCHEME
23/02/09 23:22:20.06 zt0qN6wf.net
そういえばコンテナのイテレーションの順序が未規定なときに
順序に依存したコードを書かないように乱数でわざとデタラメな順序にしたら
乱数生成器として使うやつが出てきたって話があったな。

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

486:デフォルトの名無しさん
23/02/09 23:42:25.26 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:デフォルトの名無しさん
23/02/10 01:49:50.47 JoKDyp+E.net
メソッド抽出は嫌
クロージャの即時実行も嫌
ラベル付きbreakならOK！
って感覚が俺には理解できんが
ニーズがあるならいいんじゃね

488:デフォルトの名無しさん
23/02/10 02:22:12.82 KiCBMwJT.net
>>487
関数切り出しやIIFEだと式の値はResult型になるようなところで、
ラベル付きブロックだとエラーまわりは親の関数に完全に任せて該当の式の値を生で返せる

489:デフォルトの名無しさん
23/02/10 02:35:52.13 8y57Q10t.net
ラベルでジャンプより、関数の入れ子の方が分かりやすくない？

490:デフォルトの名無しさん
23/02/10 03:36:08.11 eoPLVAGF.net
>>488
？オペレータ使えばいいだけなんだが？
逆にエラーまわりだけ親関数に任せるとかヤバくね？

491:デフォルトの名無しさん
23/02/10 06:59:25.26 Fpp4vOr0.net
>>489
ラベルでジャンプしていない
loop式の構文のloop抜きと動作も概念も全く同じだから
今回Rustはたまたま同じ構文を採用しただけ
例えば >>460の例は
ラベルを用いない別の新たな構文{{…}}を導入すればこうなる
let result = {{
　for i in 0..100 {
　　if f(i) {
　　　return Some(i);
　　}
　}
　None
}};
動作も意味も全く同じであり
ラベルにジャンプしていないことが理解できるだろう

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

493:デフォルトの名無しさん
23/02/10 07:54:41.21 Fpp4vOr0.net
>>489
必要性に応じて関数として切り出すのも構わない
そして関数として分離した方が好ましい場合もあるだろう
しかし常に関数切り出しを強いられる言語だったとしたら煩雑すぎて機能不足と言えるから使い分けできることが必要

494:デフォルトの名無しさん
23/02/10 08:05:40.53 nOIBi0US.net
>>491
文脈読めなさ過ぎw

495:デフォルトの名無しさん
23/02/10 08:18:49.59 Fpp4vOr0.net
>>494
従来からforやloop式で使われてきた早期return(離脱)つまりRustでのラベル指定break
そして今回Rust導入されたブロック式での早期return(離脱)つまり同様に構文としてはラベル指定break
それらに対して「ラベルでジャンプ」とは何を言いたいのか？

496:デフォルトの名無しさん
23/02/10 08:34:37.12 wb0Nj+xg.net
>>486
短絡orに論理orを使うのは混乱の元だから、別の専用の記号を用意して欲しいわ。

497:デフォルトの名無しさん
23/02/10 08:39:40.06 Fpp4vOr0.net
>>496
遅延評価orの型が
現在はbool型のみに制限されているから
それをOption型などにも使えるようにしよう！という話じゃないかな

498:デフォルトの名無しさん
23/02/10 08:41:20.86 KiCBMwJT.net
>>490
関数に切り出した時点で「その範囲のResultの型」を考慮しなくちゃいけなくなるから?演算子では何も解決してないし、
切り出さなきゃ元からその関数の処理だから何もやばくないぞ

499:デフォルトの名無しさん
23/02/10 08:50:58.78 Fpp4vOr0.net
関数切り出しすると
その中でも継続して使う変数(値)を参照として全て渡してそれらの型宣言も改めて行なってと煩雑さとコードの重複が大きい
もちろん返り値型も型推論で済まなくなり明確に宣言しなければならなくなる

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

500:デフォルトの名無しさん
23/02/10 09:14:00.68 8y57Q10t.net
関数切り出しじゃなくて、関数のネスト

501:デフォルトの名無しさん
23/02/10 09:39:52.23 FTCkglUc.net
>>491
動作も意味も全く同じとのことだが
その構文でネストしたブロックから抜けられるのかい？

502:デフォルトの名無しさん
23/02/10 09:47:31.36 XC30Ey72.net
>>496
今も||は「短絡論理OR」で区別されてないよ
短絡論理ORと論理ORを分けてる言語ってある？

503:デフォルトの名無しさん
23/02/10 09:58:49.88 zTpuYOFQ.net
5年もの歳月を費やしてstabilizeするほど意味ある機能じゃないよな
超ニッチなnice to haveなんだからこんな機能実装するくらいなら他の作業してくれよ

504:デフォルトの名無しさん
23/02/10 09:58:58.37 f/xkkyji.net
>>500
Rustで関数のネスト定義は可能だけどスコープを親関数内に限定するだけだよね
親関数の変数をもちろん操作できないので改めて引数も戻り値も全て型宣言して受け渡ししなければならない

505:デフォルトの名無しさん
23/02/10 10:00:29.07 76BGvvFm.net
>>500
関数のネストでやるためには
関数に切り出す必要があるから同じことを言ってるんじゃない？

506:デフォルトの名無しさん
23/02/10 10:06:08.19 f/xkkyji.net
>>501
forやloopを使ったときにどのbreakか区別できるようにラベルが付いてるだけでラベル付ブロック式のネストまでは元々求められていないんじゃないかな
たまたまラベル付となったからネストさせて指定して抜けることも可能なのかも知れないけどさ

507:デフォルトの名無しさん
23/02/10 11:35:14.97 D7CjmUqS.net
>>506
指定したラベル位置に制御を移すような動きのことを一般的にはジャンプと呼ぶ
ラベルで指定したブロックを”抜ける”と呼ぶ感覚ももちろん理解できるが同じようにジャンプと呼ぶ感覚くらいは理解してやれって話

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

509:デフォルトの名無しさん
23/02/10 13:14:46.92 OY+cHUF0.net
>>508
おまえホント壊れたレコードみたいだな
馬鹿の一つ覚えで繰り返し同じことしか言えないからおまえが出しゃばってくるとすぐスレが腐る

510:デフォルトの名無しさん
23/02/10 13:40:49.41 icbsua9B.net
オジさんは即時実行マンセー派だったのに宗旨替えしたのかw
と言っても忌み嫌われてた即時実行から半歩前進して半歩後退してるみたいなので実質進歩してないな

511:デフォルトの名無しさん
23/02/10 14:05:25.21 aIK+hWQq.net
いわゆる　Rewrite it in Rust　といわれる
　　URLﾘﾝｸ(zenn.dev)
ものだが、CoreUtil代替もでてきたようだ。
　　URLﾘﾝｸ(www.phoronix.com)
そのうち、ls や cp , mv みたいなものも実はRust実装でしたという時代がくるのか？

512:デフォルトの名無しさん
23/02/10 15:10:52.96 p1oXUla5.net
誰もが必ず使うエラーまわりには散々ボイラープレートを要求するくせに
ブロックからの早期returnが必要なくらいの処理を関数に切り出したくないという理由だけで
プチgoto入れちゃうのはバランス感覚おかしいわな

513:デフォルトの名無しさん
23/02/10 15:25:57.81 EzUIw58a.net
ブロック式も関数も複数の文をひとつの式にするものだから関数から早期returnできるならブロック式から早期breakできてもええやん😁

514:デフォルトの名無しさん
23/02/10 16:46:17.45 ec863R6+.net
returnやbreakのことをgoto扱いしてる人は頭おかしい
むしろgotoを排除するために現在の言語ほとんどに備えられている
ラベル付breakをサポートする言語も多い

515:デフォルトの名無しさん
23/02/10 17:26:28.28 TiW7YUw7.net
レスバしかしてねーなお前ら

516:デフォルトの名無しさん
23/02/10 17:37:10.71 gd5eXGUi.net
Rustの機能はすべて素晴らしいということにしないと気が済まない人がいるのはよく分かった

517:デフォルトの名無しさん
23/02/10 17:57:37.26 8u6orso3.net
マクロは強力なのはいいけど出来は悪いと思う

518:デフォルトの名無しさん
23/02/10 18:07:23.86 VmkjxzjW.net
Rust の機能が全て優れてるとは思わないけどラベル付き break なんて揉めるような機能じゃないだろ...

519:デフォルトの名無しさん
23/02/10 18:07:48.18 ec863R6+.net
Rustに限らず早期return、早期breakはどの言語でも要

520:デフォルトの名無しさん
23/02/10 19:02:21.11 MJOsdNRe.net
ブロックからの脱出とジャンプを同列に考えるやつは勉強不足だと思うがね。

Rustのスタックフレーム志向とかを考えれば、ブロック出入り操作を重視するのは自然。逆にスタックフレームの局所性を破壊する例外フローとかジャンプは嫌われて当然だわ。
例外フローにおけるエスケープ解析て確立しているんだっけ？

次ページ