Rust part19 - 暇つぶし2ch

Rust part19 ..

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

521:デフォルトの名無しさん
23/02/10 19:02:40.14 MoSIyINf.net
規約で禁止していいレベルの機能
Avoid labelled break. Use functions instead.

522:デフォルトの名無しさん
23/02/10 19:05:14.63 53cyCMdn.net
>>509
唐突に発狂されても意味不明
反論があるなら技術的な話でお願いします

523:デフォルトの名無しさん
23/02/10 19:06:54.13 MJOsdNRe.net
>>521
関数みたいなブロックを作ればいいんじゃない？
あるいはブロックみたいな関数とか。

524:デフォルトの名無しさん
23/02/10 19:07:09.08 MJOsdNRe.net
>>521
関数みたいなブロックを作ればいいんじゃない？
あるいはブロックみたいな関数とか。

525:デフォルトの名無しさん
23/02/10 19:24:57.65 VelAUwkm.net
>>521
Rustには何年も前からラベル付breakがあります
今さら文句をつけている人はRustを知らずイチャモンを付けたいだけだとバレていますよ

メジャーなプログラミング言語の大半がラベル付breakを備えています
JavaでもSwiftにもGoもJavaScriptすらラベル付breakを持っています
プログラミングにおいて必須の機能だからです

逆にラベル付breakを持っていない代表的な言語がC/C++です
今回のRust叩きをしている犯人はいつもと同じ人だと分かります

526:デフォルトの名無しさん
23/02/10 19:52:12.29 ec863R6+.net
breakに対してジャンプだとかgotoだとかトンデモ発言が出ていたのはそういうことか
C/C++しか知らないと多重ループすらgotoで抜けるしかないもんな
そういう貧弱な世界しか知らない視野の狭い人だから必死にRustを叩いていたわけか

527:デフォルトの名無しさん
23/02/10 21:33:52.77 zr0HQZhu.net
前から常駐してるアンチRustのやつだろ
ばればれだがアンチとばれないように装いつつRustの色んな点を批判してきた
特にRustならではの機能とか新たな機能とかRustらしい書き方とかを嫌う

528:デフォルトの名無しさん
23/02/10 22:57:01.58 9GdW2Tn6.net
同じことしか言わないから自演丸分かりやんww

529:デフォルトの名無しさん
23/02/10 22:59:03.20 Y2H2O9Fe.net
>>525
大半の言語が備えてるラベル付breakはループから抜けるものでブロックから抜けるものじゃないぞ

530:デフォルトの名無しさん
23/02/10 23:14:34.63 z32i1LMi.net
swiftがdo statementでブロックスコープから抜ける機能を用意してるがtry/catchなしの形では誰も使ってない

531:デフォルトの名無しさん
23/02/10 23:16:17.28 TiW7YUw7.net
そんなことよりさっさとif let Some(c) = chars.next(); c.is_whitespace() {とかって書けるようになってほしい

532:デフォルトの名無しさん
23/02/10 23:22:50.62 KiCBMwJT.net
ブロックは「必ず1回で終了するループ」と解釈可能なのでループからのラベル指定breakがあるならブロックからもbreakで抜けられる方が自然

533:デフォルトの名無しさん
23/02/10 23:24:33.98 PcQ6rbEj.net
Javaも文法的にはループ以外でもラベル付きブレイク使えるけど絶対使わないな

534:デフォルトの名無しさん
23/02/10 23:32:27.37 Qit9LgYB.net
>>532
その理屈でいけばラベルなしブロックからもbreakで抜けられないとおかしくない？

535:デフォルトの名無しさん
23/02/10 23:37:03.68 q3LdPEQ+.net
RFCの例を4パターンで書いてみたけどラベル付きbreakは無いな
1か2のパターンに収まる形にリファクタリングする
大半の人がラベル付きbreakを選びたくなるようなサンプルはないのかな？
1. 関数化
2. Optionコンビネータ
3. クロージャ
4. ラベル付きbreak
URLﾘﾝｸ(play.rust-lang.org)

536:デフォルトの名無しさん
23/02/10 23:46:57.14 XHs/nBWT.net
流れと一切関係ないけど
rubyは一時期tapとbreakで値を返す文化？あったな
foo.tap {|x| bar} // selfつまりfooを返す
foo.tap {|x| break bar} // breakでbarを返す
foo.then {|x| bar} // ブロックの結果つまりbarを返す。今はthen使うのが素直。

537:デフォルトの名無しさん
23/02/11 00:18:21.11 VRz38Asr.net
>>531
セミコロンじゃなくて&&だよね
stableになるのは半年後くらいじゃない

538:デフォルトの名無しさん
23/02/11 00:22:48.96 LT0L6YWb.net
>>535
再利用しない前提ならクロージャを変数に束縛してしまえば3.も視野に入ると思うんだ
URLﾘﾝｸ(play.rust-lang.org)

539:デフォルトの名無しさん
23/02/11 00:29:21.70 N8U5Q6xc.net
異なる種類のエラーを返す関数が絡んできたとき、ラベル指定breakのみエラーの合成を?演算子で関数境界に押し込められる
関数やクロージャだと「ブロック内のエラーを合成した型」を明示的に取り扱うことになって二度手間

540:デフォルトの名無しさん
23/02/11 00:48:21.15 C7Sk8k8l.net
>>536
tapでbreakなんて初めて知ったわ
イテレータのメソッドチェーンの途中経過を出力する時にしか使ったことなかった

541:デフォルトの名無しさん
23/02/11 01:02:10.14 rZ1nyaTw.net
>>538
これは同意
 >>539
サンプルコード書いてみてよ

542:デフォルトの名無しさん
23/02/11 01:49:22.40 sVZS7q05.net
すまんがRustlingsでまたちょっと教えてほしいんだけどさ
これ↓のListing 8-8の&mutって、一体どういう意味があるの？？？
URLﾘﾝｸ(doc.rust-lang.org)
Rustlingsをやっていて、似たような場面で&mutなしでも動いちゃうように見えるけど・・・・状況が似て非なるものなんだろか・・・・・
URLﾘﾝｸ(play.rust-lang.org)

543:デフォルトの名無しさん
23/02/11 02:18:23.31 N8U5Q6xc.net
>>542
詳細はトレイトとか Deref とか IntoIterator とか関連型とかその章ではまだ出て来てない概念が色々絡むが
for item in v の v に対して
Vec<T> を渡したら item はＴになって所有権ごと持ってく
&Vec<T> を渡したら item は &T になって不変参照のイテレーションになる
&mut Vec<T> を渡したら item は &mut T になって可変参照のイテレーションになる

Vec<T>は DerefMut<Target=[T]> を実装しているから &mut Vec<T> は暗黙のうちに deref_mut のメソッドを通して &mut [T] に変換されて
その &mut [T] が IntoIterator<Item=&mut T> を実装しているからfor文で &mut T のイテレーションができる

544:デフォルトの名無しさん
23/02/11 03:08:28.64 ClzSOMcn.net
>>535
その程度ならば型宣言で冗長になる関数化をするまでもないからブロック式でも十分かな
使い分けできるようにブロック式の不備を整備したRustの方針は正しいと思うよ
 >>542
所有権を渡すのは消費尽くすときだけでその後も使いたい時は参照&か可変参照&mutを渡す
そのコードのv.iter_mut()の方に見かけ上&mutが見当たらないのはメソッド定義にそれがあるから
メソッドでは所有権を渡すか参照を渡すか可変参照を渡すかをその定義でselfか&selfか&mut selfか指定することでメソッド使用時に毎回指定しなくて済むようになっている

545:デフォルトの名無しさん
23/02/11 03:56:21.21 VRz38Asr.net
>>542
vがVec<T>の場合
for i in &mut v {…} と
for i in v.iter_mut() {…} は同じ
前者は&mut Vec<T>のIntoIteratorトレイトのinto_iter()が呼ばれる
その中身はself.iter_mut()なので後者と同じになる
for loopはiterable(IntoIteratorを実装してるもの)を受け取って
そのinto_iter()を呼び出してからイテレートする仕組み
URLﾘﾝｸ(doc.rust-lang.org)