[過去ﾛｸﾞ] Rust part31 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1: デフォルトの名無しさん [] 2025/07/03(木) 21:30:06.95 ID:ORBrZxS2(1) AAS
公式
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 part30
2chｽﾚ:tech
ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
2chｽﾚ:tech
2(1): デフォルトの名無しさん [sage] 2025/07/03(木) 22:02:35.22 ID:5eizpyG1(1) AAS
if let Channel::Stable(v) = release_info()
&& let Semver { major, minor, .. } = v
&& major == 1
&& minor == 88
{
println!("`let_chains` was stabilized in this version");
}
↑よりも↓こっちのほうがわかりやすいな
if let Channel::Stable(Semver { major, minor, .. }) = release_info {
if major == 1 && minor == 88 {
println!("`let_chains` was stabilized in this version");
}
}
3: デフォルトの名無しさん [sage] 2025/07/03(木) 23:20:17.81 ID:DF8MM2z8(1) AAS
>>2
それはサンプルであることと
本質はif多段を避けたい
if let Channel::Stable(Semver { major, minor, .. }) = release_info &&
imajor == 1 &&
minor == 88
{
println!("`let_chains` was stabilized in this version");
}
4(4): デフォルトの名無しさん [sage] 2025/07/04(金) 00:29:23.67 ID:uYpH3kMo(1) AAS
あくまでも例だね
今回の例に限ればこれが短く可読性もいい
if let Channel::Stable(Semver { major: 1, minor: 88, .. }) = release_info {
println!("`let_chains` was stabilized in this version!!!");
}
5: デフォルトの名無しさん [] 2025/07/04(金) 00:39:18.38 ID:OGvk30E1(1/3) AAS
rust楽しい
仕事では全く使わんが趣味で遊んでる
6(1): デフォルトの名無しさん [sage] 2025/07/04(金) 00:42:27.31 ID:sejGpbp9(1) AAS
ClaudeCodeもGeminiCLIもTypeScript製ですが、なぜ最強言語Rustで作らないんだろう
あいつら頭悪いんですかね？なんかムカついてきた
7: デフォルトの名無しさん [sage] 2025/07/04(金) 02:08:21.93 ID:al3hptYi(1) AAS
原理主義者きたー
8: デフォルトの名無しさん [sage] 2025/07/04(金) 04:51:54.94 ID:j3pXRdpv(1) AAS
rust使った後仕事でPythonに戻ると頭の使う場所が変わってすごい疲れる
コンパイラーに頼りっきりの悪い癖で、Python走らせてランタイムエラー出るとドキッとしてしまうわ
9: デフォルトの名無しさん [sage] 2025/07/04(金) 06:06:43.93 ID:JIudql3e(1) AAS
できる限り性的に解決してくれる言語サイコー
10: デフォルトの名無しさん [] 2025/07/04(金) 06:44:45.86 ID:ZoTp4+J7(1/2) AAS
AIを使う上で必要なのはプロンプトエンジニアリングよりも「コンテキストエンジニアリング」
https://gigazine.net/news/20250703-ai-context-engineering/
11: デフォルトの名無しさん [] 2025/07/04(金) 06:52:51.55 ID:OGvk30E1(2/3) AAS
>>6
全てのプログラムをRustにして
そして私もRustになろう
12: デフォルトの名無しさん [] 2025/07/04(金) 07:46:13.09 ID:ZoTp4+J7(2/2) AAS
７月２日 夜の番組で
安倍晋三 総理大臣
ドキュメンタリーをしていたのですが
山口県ではだれも逆らえなかった模様です
※自民党と対立候補ほかしれませんが自民党支持している者関係者？が対立している人が後ろから突飛ばしたりもしていたそうです
※自民党をに牙をむいたら物理的な新た暴力があるように流されていました
自民党が戦略として行ったのが反対意見を速やかにつぶすために自民党の議席を増やして議会で話をさせないようにもしていたようです
自民党の戦術としては裏で統一教会が動いていた模様で
統一教会がしていたことは
1 集会場の助っ人でさくら役であたかも人気があるように見せかけていた
2 選挙のやり方は熟知しているので何も言わなくても事務所は完成する
3 2と同様で選挙違反ぎりぎりの行動をして他の選挙立候補者に嫌がらせもしくは裏工作をしていた？
※兵庫県知事問題も暗躍していた可能性あり
4 統一教会からの投票だけでもまとまった票を集める
5 比例投票で○○党に投票すればさらにその政党の議席を増やせるしキムを作成したのも自民党？
などあったのか知っている人教えて
13: デフォルトの名無しさん [sage] 2025/07/04(金) 08:05:27.91 ID:oaxeMCLD(1) AAS
アンジャッシュの新作コントが見たい
14: デフォルトの名無しさん [sage] 2025/07/04(金) 08:33:07.43 ID:2TtQZu8y(1) AAS
2024 editionでif letチェーンができるようになった前提として
2024 editionでは以下のように一時的生成物のスコープ変更が行なわれている
fn f(value: &RwLock<Option<bool>>) {
if let Some(x) = *value.read().unwrap() {
println!("value is {x}");
}
// <--- 2024 edition だとここで read lock が drop
else
{
let mut v = value.write().unwrap(); // 2021 editionだとここでデッドロック
if v.is_none() {
*v = Some(true);
}
}
// <--- 2021 edition だとここで read lock が drop
}
15(2): デフォルトの名無しさん [sage] 2025/07/04(金) 08:55:18.58 ID:HIBkUYal(1/14) AAS
>>4
C#だとこんな感じだからやっとRustが追いついて来た
if (release_info() is Stable { Semver{ Major: 1, Minor: 88 } } stable)
{
Console.WriteLine($"Matched version: {stable.Version}");
}
16: デフォルトの名無しさん [sage] 2025/07/04(金) 09:11:32.38 ID:O068PO4l(1) AAS
>>15
勘違いしているようだが
Rustでは当初からstruct/enum/list/rangeパターンマッチングできている
むしろC#がRustより遅れてC#8.0でようやくlistパターンマッチングできるようになった
17(1): デフォルトの名無しさん [sage] 2025/07/04(金) 09:48:57.07 ID:HIBkUYal(2/14) AAS
可読性では段違いにC#が優れている
18(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:08:54.80 ID:3ctOs1dz(1) AAS
各言語それぞれ一長一短あるけどC#のように条件節でのパターンマッチがboolean expressionとしても扱われるほうが汎用的でベターな設計だと思う
Rustはパターンマッチはboolean expressionではないから()で括ったり||でつなげたりできない
別のルールが必要になるのはわかるが今のやり方は対処療法というか無理やりパッチを当てたイメージ
当初ターゲットだった2018エディションでは実現できず次のターゲットだった2021エディションでも実現できず8年近くも”慎重に検討を重ねて”対処療法の妥協の産物しか生み出せない現状を見ると根本的な進化はあまり期待しないほうがいいと思ってる
19: デフォルトの名無しさん [sage] 2025/07/04(金) 10:22:41.50 ID:pz2zExAy(1) AAS
>>17
よく見ろよ>>4と>>15
Rustが可読性も良い
20(3): デフォルトの名無しさん [sage] 2025/07/04(金) 10:26:08.30 ID:HIBkUYal(3/14) AAS
主客が逆転している
if let Channel::Stable(Semver { major: 1, minor: 88, .. }) = release_info
の方が可読性が良いというのはおかしい
コーディングする場合も
release_info() が major: 1, minor: 88であるかのチェックなのでC#が自然
これを左辺に持ってきて可読性が良いというのは無理がある
21: デフォルトの名無しさん [sage] 2025/07/04(金) 10:26:51.75 ID:aOfpZ2e6(1/3) AAS
>>18
変数を宣言するからletだという基本を理解しましょう
22: デフォルトの名無しさん [sage] 2025/07/04(金) 10:27:34.97 ID:HIBkUYal(4/14) AAS
Rustでコーディングする際は右辺を書いてから左辺に戻ることになる
非常に不自然で劣っている
23(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:28:08.57 ID:aOfpZ2e6(2/3) AAS
>>20
変数を宣言するからletだという基本を理解しましょう
C#が劣っています
24(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:29:32.89 ID:HIBkUYal(5/14) AAS
>>23
誰が見てもC#の方が優れている
今後Rustにも取り入れられるかもしれない
それが理解できないお前が劣っているとしか言いようがない
25(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:31:15.69 ID:wZ441BSd(1/2) AAS
>>20
そんなの主観と慣れだろう。
OCaml あたりから持ち込まれた記法なので C 系にしか馴染みがなければ読みにくく感じるのは理解できるが優劣をいうような筋合いのものではない。
26(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:31:51.81 ID:HIBkUYal(6/14) AAS
>>25
主観ではない
Rustは事実上ヨーダ記法と同じことをしている
27: デフォルトの名無しさん [sage] 2025/07/04(金) 10:32:09.16 ID:aOfpZ2e6(3/3) AAS
>>24
まずはRustのlet文を学んでください
C#が間違っていると明確にわかりますよ
28: デフォルトの名無しさん [sage] 2025/07/04(金) 10:34:18.39 ID:HIBkUYal(7/14) AAS
C#がやっていることは事実上
x is 88のチェック
Rustがやっているのは事実上
88 is xのチェック
29(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:37:23.35 ID:wZ441BSd(2/2) AAS
>>26
この例でやっていることが比較ではなくパターンマッチなのだということがわからないのか？
比較で書きたきゃそうも書けるよ。
30(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:39:35.11 ID:HIBkUYal(8/14) AAS
>>29
では>>4をまともな日本語に変換してからコーディングしてみろよ
31(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:41:17.29 ID:yzVoJtUY(1) AAS
>>30
そういう人を試すふりですべての答えにいちゃもんを付ける態度が一番卑怯だよ
32(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:42:22.73 ID:h364eCOG(1/4) AAS
>>20
それはC#が文法設計を失敗して間違えているんだよ
C#ではvarや代入でパターンマッチングする時はちゃんと左辺(値が入る変数がある側)と右辺(任意の式)
Rustでも全く同じでこれが正しい
そしてRustではifの中でも>>4のように一貫して同じ形なる
C#は一貫性がなく文法設計を間違えた
33: デフォルトの名無しさん [sage] 2025/07/04(金) 10:43:11.39 ID:HIBkUYal(9/14) AAS
>>31
事実だろ試すふりじゃないだろ？
もしバージョンが丸々ならと言う条件式のコーディング順をなんで逆にするんだよ
34(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:44:29.15 ID:HIBkUYal(10/14) AAS
>>32
Rustはその場しのぎで糖衣構文を導入したので上手くいかなかっただけだろ？
ヨーダ記法が正しいのか？コーディングしやすいのか？
35: デフォルトの名無しさん [sage] 2025/07/04(金) 10:46:38.35 ID:HIBkUYal(11/14) AAS
事実上やりたいのはこれ
if x is 88
xが88に束縛されているか？のチェック
if 88 is x
88がｘに束縛されているのかと言うのは不自然で主客逆転している
36(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:49:13.21 ID:h364eCOG(2/4) AAS
>>34
この件でRustに糖衣構文なんかない
letもif letも新規変数側が左辺となり一貫したわかりやすい文法となっている
一方でC#は一貫性なく真逆にして失敗した
37(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:51:18.40 ID:HIBkUYal(12/14) AAS
>>36
言語として破綻しててコーディングしにくいRustが失敗してる
38: デフォルトの名無しさん [sage] 2025/07/04(金) 10:58:39.15 ID:h364eCOG(3/4) AAS
>>37
文法に一貫性がなく失敗作のC#とは異なり
Rustでは一貫して常に同じ形でわかりやすく記述できる
let Foo { x, y, } = a;
let Foo { x: 123, y, } = a else { ... };
if let Foo { x: 123, y, } = a { ... } else { ... }
39(1): デフォルトの名無しさん [sage] 2025/07/04(金) 10:59:55.20 ID:ZCWHj/xV(1) AAS
醜い争いだなｗ
40: デフォルトの名無しさん [sage] 2025/07/04(金) 11:03:32.72 ID:HIBkUYal(13/14) AAS
もしバージョンが1.88である場合と言うコードを書くときに
先に数値や構造を書くのはおかしな話だろう？
コーディングしにくいなって感じるだろう？
もしバージョンがと言う時点でこれを綺麗にコードに落とせないのはプログラムする側の問題ではなくRustの問題なので
いつかC#のような形式が取り込まれる
そうしないと書きにくいのを我慢して使うことになる
41(1): デフォルトの名無しさん [sage] 2025/07/04(金) 11:09:17.97 ID:h364eCOG(4/4) AAS
C#だけが文法設計に失敗して一貫性のない醜い文法となってしまった
新規変数が右辺に来る異様さ
Rustはわかりやすく可読性の良い形で一貫した文法となっている
42: デフォルトの名無しさん [sage] 2025/07/04(金) 11:13:36.96 ID:HIBkUYal(14/14) AAS
>>41
残りの人生を書きにくいルールで右辺左辺行ったり来たりし続けるつもりか？
もしバージョンが1.88である場合を自然に記述できないRustのことを憂いたほうが良い
Rustの可読性とコーディング性向上のためにC#のような文法の取り入れの提案書でも書けばよい
43: デフォルトの名無しさん [sage] 2025/07/04(金) 11:20:48.50 ID:IQMzIZOQ(1) AAS
この件はRustなどC#以外の言語が正しいよ
代入ならば既出の
＞ let Foo { x, y, } = a;
＞ let Foo { x: 123, y, } = a else { ... };
＞ if let Foo { x: 123, y, } = a { ... } else { ... }
他の言語と同様に代入される側が常に左辺の原則
C#では右辺に来る過ちを犯した
比較ならば
if Foo { x: 123, y: 456, } = a { ... } else { ... }
if a = Foo { x: 123, y: 456, } { ... } else { ... }
対等なので他の言語と同様に左辺と右辺は入れ替えてもよい
C#では入れ替えができない不自由
44: デフォルトの名無しさん [] 2025/07/04(金) 11:26:30.89 ID:OGvk30E1(3/3) AAS
話ずれるけど
Syntactic Sugar （糖衣構文）をカタカナで「シンタックスシュガー」と言い始めたやつを過去に戻ってぶん殴りたい
45: デフォルトの名無しさん [sage] 2025/07/04(金) 17:05:40.02 ID:OI9Lh1US(1) AAS
Algorithmic〜 をアルゴリズミック〜とは訳さないことが多いのと同じで日本人にとって超馴染みの薄い形容詞形の単語をそのまま使わずによく知られた使いやすい名詞形のnoun + noun形式にするパターン
syntax sugarでもネイティブにもノンネイティブにも問題なく通じるからそんなに気にしなくていいよ
46(1): デフォルトの名無しさん [sage] 2025/07/04(金) 20:45:43.08 ID:uq+xMRPp(1/2) AAS
普通にif x is Some(Ok(value))の方が良くね？
chatGPTに案出ししてもらったら
if x matches Some(y)
とか出して来た
47: デフォルトの名無しさん [sage] 2025/07/04(金) 21:40:03.12 ID:TbEgb2Ls(1) AAS
一貫性があり最も優れている記述法
＞ let Foo { x, y, } = a;
＞ let Foo { x: 123, y, } = a else { ... };
＞ if let Foo { x: 123, y, } = a { ... } else { ... }
変数代入は必ず左辺にその変数が来る
48(1): デフォルトの名無しさん [sage] 2025/07/04(金) 21:47:39.19 ID:uq+xMRPp(2/2) AAS
単純な変数代入じゃないし…といってもつたわらないなか？
もしaがSome(ｂ)だとしたらと言う文脈
そのほうが書くのは楽だし
49: デフォルトの名無しさん [sage] 2025/07/04(金) 22:31:48.02 ID:CkdJ7cjj(1) AAS
主観でいうならPython の
def foo() -> str | None: ...
if (f := foo()) is str:
# このブロックでは f は str
が分かりやすいという人もいるんじゃないの？
Pythonは英語の自然な文法に近いと言われるけど、そういうのを「可読性」と呼ぶ人もいる
関数型の書き方が好きなら Rust の構文を好むだろうけど、C#のスタイルだって十分理解しやすい
その言語で書いていればすぐに慣れるような問題だし、正直かなり些細な話だと思う
50: デフォルトの名無しさん [sage] 2025/07/04(金) 22:39:48.52 ID:5zc4SaJd(1) AAS
>>48
Rust使ったことないでしょ？
代入でなく比較なら対称だから入れ替えてどちらでも書けるよ
if a == Some(b) {
if Some(b) == a {
51(1): デフォルトの名無しさん [sage] 2025/07/04(金) 22:40:25.66 ID:xvN7viZF(1) AAS
>>46
考えたことなかったが言われてみればこの2つなら上のほうが明らかに可読性はいいな
if x is Some(Ok(value)) {…}
if let Some(Ok(value)) = x {…}
まあでも今のやり方でも許容範囲なので俺は別に構わないが
52: デフォルトの名無しさん [sage] 2025/07/04(金) 22:51:50.85 ID:YS2Js17U(1) AAS
>>51
上のC#構文は非常にわかりにくくなってる
if letの置き換えだけでなくletやlet elseも書いてごらん
＞ let Foo { x, y, } = a;
＞ let Foo { x: 123, y, } = a else { ... };
＞ if let Foo { x: 123, y, } = a { ... } else { ... }
53: デフォルトの名無しさん [sage] 2025/07/04(金) 23:28:49.57 ID:OevS8/0x(1) AAS
代入される左辺値が右側に来ることもあるC#は最悪だ
文法に整合性がない
54: デフォルトの名無しさん [sage] 2025/07/05(土) 09:29:48.43 ID:pq7Cj05V(1) AAS
>>39
本当にそう思う
笑い無しの真顔で
55: デフォルトの名無しさん [sage] 2025/07/05(土) 09:33:40.72 ID:To+HU3do(1) AAS
色んな言語がある中
最もダメなC#でRustスレを荒らしに来て倒されたコント
56: デフォルトの名無しさん [sage] 2025/07/05(土) 12:48:59.24 ID:IvwLD0VH(1/6) AAS
そうですか
Rustにも早くdowncast patternが入るといいですね
57: デフォルトの名無しさん [sage] 2025/07/05(土) 14:12:46.57 ID:X00W2RsD(1) AAS
Rustは10年前の1.0の時からdowncastできるよ
58(1): デフォルトの名無しさん [sage] 2025/07/05(土) 15:52:38.96 ID:q1Gtuhav(1/2) AAS
他の言語から来るとletみたいな束縛の考えに馴染みが無いんじゃない？
メジャーな言語で採用してるのはRustくらいだし
(Swiftも？)
var x = ... のように代入する言語だと、is string や when x < 0 のような条件は後付けする方が自然な気がする
var (string x) ＝ foo() みたいな構文はあり得ないわけだから
59: デフォルトの名無しさん [sage] 2025/07/05(土) 15:56:08.92 ID:N7XfN1yQ(1/2) AAS
letはHaskellからパクったキーワードでしょ
60(2): デフォルトの名無しさん [sage] 2025/07/05(土) 15:56:29.40 ID:B1JMipmh(1) AAS
Rustに構文を追加するなら「Rustユーザーにとって自然であること」が正義で、C#に構文を追加するなら「C#ユーザーにとって自然であること」が正義というだけの話
61: デフォルトの名無しさん [sage] 2025/07/05(土) 16:13:01.56 ID:Cfq4jI1n(1) AAS
>>58 >>60
どの言語でも新たに代入される変数は必ず左側の左辺に来る原則があるんだよ
C#はそれがなぜか右側に来ることもある不作法と一貫性の無さが批判されてる
62: デフォルトの名無しさん [sage] 2025/07/05(土) 16:20:30.23 ID:7adKTS5g(1) AAS
単なる主観なのに可読性とかかっこつけんなよw
63: デフォルトの名無しさん [sage] 2025/07/05(土) 16:22:02.84 ID:SoZdSA74(1) AAS
いつも可読性の低い汚コードを披露してくださってる複オジ大先生の可読性講義はありがたい
一般人には理解しがたい汚コーダーの心理を知ることができる大変貴重な機会
64: デフォルトの名無しさん [sage] 2025/07/05(土) 16:26:56.00 ID:E3MH6Lcw(1) AAS
複おじはRustならなんでも良い人だから
if x is Some(Ok(value)) {…}が導入されたらどうするのか
65: デフォルトの名無しさん [sage] 2025/07/05(土) 16:35:04.80 ID:2M7CqIfD(1) AAS
整合性がなく他の言語から見ても異端なC#のどうでもいい話でRustスレを荒らして何がしたいんだろうな
66: デフォルトの名無しさん [sage] 2025/07/05(土) 16:46:38.73 ID:qZ93qmfR(1) AAS
>>60
左辺値が右側に来る不自然な文法を採用している言語はC#だけ
67(2): デフォルトの名無しさん [sage] 2025/07/05(土) 17:54:23.08 ID:IvwLD0VH(2/6) AAS
ところでmatches!マクロの引数はpattern, scrutineeの順ですね
間にあるのが=じゃないからどうでもいいか
文法をそこまで気にする意味ってなんだろうね
68: デフォルトの名無しさん [sage] 2025/07/05(土) 17:55:05.10 ID:IvwLD0VH(3/6) AAS
>>67
いや逆だ、scrunitee, patternの順
69: デフォルトの名無しさん [sage] 2025/07/05(土) 18:41:21.67 ID:lbbyBqBC(1) AAS
matches!はmatch式の順序に従ってる
70: デフォルトの名無しさん [sage] 2025/07/05(土) 18:45:25.78 ID:N7XfN1yQ(2/2) AAS
そういや、俺はRustであんまりmatch式使ってないなあ
Scala書いてた時はアホみたいに多用してたのに
71: デフォルトの名無しさん [sage] 2025/07/05(土) 18:55:54.06 ID:/SDSty6t(1) AAS
Rustでも他の言語のmatch文やswitch文と同様にこの順序だよ
match ターゲット {
パターン1 => 値1,
パターン2 => 値2,
...
}
パターンに合致するかの真偽値がほしい時は
match ターゲット {
パターン => true,
_ => false,
}
これをマクロ
matches!(ターゲット, パターン)
として用意してるだけだよ
72: デフォルトの名無しさん [sage] 2025/07/05(土) 19:54:23.33 ID:VOx5iHml(1) AAS
釣り針がデカいですね
73(1): デフォルトの名無しさん [sage] 2025/07/05(土) 20:11:12.40 ID:BbgyVmWu(1) AAS
>>67
matches！で変数に値が代入されてその変数が使われることはありえない
だからそもそも代入変数が左に来る話の対象外
74: デフォルトの名無しさん [sage] 2025/07/05(土) 22:06:06.04 ID:q1Gtuhav(2/2) AAS
「他の言語」てのは関数型言語くらいしか無いんじゃないの？
75(1): デフォルトの名無しさん [sage] 2025/07/05(土) 22:54:21.80 ID:IvwLD0VH(4/6) AAS
>>73
代入じゃなくて束縛な
表層的な文法の話するならC#は=じゃなくてisなんだからRustのif letとは別物だし比較してもしょうがない、とも言える
というかC#er的には「動的型判定のis演算子を拡張して作ったんだから型が後ろに来たほうが自然だね、イチから作り直すなら別の文法でもいいけど」くらいにしか思わないしな
他言語を知る気が無いなら好きに思ってればいいけど、だったら荒らしだとか不自然だとか変なケチ付けずにスルーするべきだ
76: デフォルトの名無しさん [] 2025/07/05(土) 23:01:35.02 ID:lZw753Wj(1) AAS
ここはRustスレ
C#erとやらがいつも暴れていることこそタブー
出禁な
77(1): デフォルトの名無しさん [sage] 2025/07/05(土) 23:16:48.59 ID:PVqr3Cva(1) AAS
>>75
>> 型が後ろに来たほうが自然だね
ここ意味がわからない
右辺式も左辺束縛パターン式も通常は同じ型で区別はないよ
後ろは束縛パターンではなく右辺式となるのが普通だね
78: デフォルトの名無しさん [sage] 2025/07/05(土) 23:25:51.26 ID:CUiBCYBD(1) AAS
if (x is int) のような型判定のisを拡張して
if (x is int a) のようにパターンマッチも使えるようにした
という話を理解してないから意味わからないんでしょ
頼むよ複おじ〜
79: デフォルトの名無しさん [sage] 2025/07/05(土) 23:28:41.76 ID:IvwLD0VH(5/6) AAS
スルーするべきだとこちらからわざわざ書いているのに、それでも反応してしまうなら、これはスレチではないということでいいんだね？
>>77
Rustしか知らないとそれが「通常」で「普通」なんだろうなということはよく分かるよ
80: デフォルトの名無しさん [sage] 2025/07/05(土) 23:31:50.52 ID:IvwLD0VH(6/6) AAS
そもそもmatchでもifでもないif let相当の構文がわざわざ用意されてる言語ってそんなにあったっけという感じ
普通ってなんだっけ
81: デフォルトの名無しさん [sage] 2025/07/05(土) 23:34:23.07 ID:UzVr4/VY(1) AAS
Rustが優秀すぎ
特にlet elseが便利すぎる
82: デフォルトの名無しさん [sage] 2025/07/05(土) 23:39:26.10 ID:fELDm2s5(1) AAS
どのプログラミング言語でも同じ
値が代入される変数がある側を左側に書いて左辺値(L-Value)とも呼ばれる
代入する値がある側を右側に書いて右辺値(R-Value)とも呼ばれる
83: デフォルトの名無しさん [sage] 2025/07/05(土) 23:49:12.59 ID:I56lB4/6(1) AAS
C#だけおかしい
値が代入される変数がなぜか右側に来る
84: デフォルトの名無しさん [sage] 2025/07/06(日) 00:07:39.02 ID:lRp9/n7j(1) AAS
年を取ると固定観念が強くなりすぎて自分のやり方考え方以外は認められなくなるってやつだな
後置ifを親の仇のごとく毛嫌いしてたお年寄りを思い出した
85: デフォルトの名無しさん [sage] 2025/07/06(日) 00:20:16.92 ID:zqvmJlyP(1/12) AAS
またletのこと束縛じゃなくて代入って言ってるし
Rustのほうもダメダメじゃないか
86: デフォルトの名無しさん [sage] 2025/07/06(日) 00:22:40.71 ID:XwybGXxU(1) AAS
左辺値を右に置いたのはC#が初めて？
87: デフォルトの名無しさん [sage] 2025/07/06(日) 00:28:28.56 ID:zqvmJlyP(2/12) AAS
誰からもツッコまれないから延々同じ勘違い垂れ流し続けててウケますね
88: デフォルトの名無しさん [sage] 2025/07/06(日) 00:33:15.50 ID:McLsJkFl(1) AAS
構文なんてのはかなり瑣末な問題だからな
一般的な開発者は「パフォーマンスが必要だからRust」「Unityでゲーム開発したいからC#」「科学計算に強いからPython」のような選び方をする
「パターンマッチの構文が美しい」とかの理由が言語選定に影響することはまず無い
構文の良さで「勝つ」ことは無いというのは、Scalaなんかを見れば分かる話
企業がRustにら求めるメリットは「メモリ安全かつ高速」という特性の方
もし仮にRustが JVM で動く言語だったとしたら、「構文が美しい」というメリットはあっても、それが Java に勝つことは無いというのは分かるでしょ
89: デフォルトの名無しさん [sage] 2025/07/06(日) 00:34:21.43 ID:0as+y0VS(1) AAS
Rustは従来のプログラミング言語と同じ形
左右逆転のC#は前例がないと思う
90(1): デフォルトの名無しさん [sage] 2025/07/06(日) 00:44:22.43 ID:HzRlk2pS(1/2) AAS
前例がないのは別に悪いことではない
現実の実装は知らんけど`x is int a`は`x.Is(int, var out a)`と考えればありふれた形でもある
91: デフォルトの名無しさん [sage] 2025/07/06(日) 00:45:28.51 ID:KkaZGoEi(1) AAS
これ経緯の最初はRustの構文はおかしいと言い出してC#の例を持ち出してきたところからスタートしてるな
C#erとやらはC#のみが異端であることに気付いていなかった
92(2): デフォルトの名無しさん [sage] 2025/07/06(日) 01:12:01.40 ID:HzRlk2pS(2/2) AAS
パターンマッチでC#がRustより優れてる点はis演算子を使ったパターンマッチ式がブール式だということ
ブール式が使えるところではどこでも使えてどのブール演算も使える
型判定のisを拡張した副作用かもしれないが
8年もかけてツギハギだらけのlet-chainsしか作れないのと比べると羨ましい限り
語順はどちらかというと些末な問題
93(1): デフォルトの名無しさん [sage] 2025/07/06(日) 01:19:17.49 ID:11lsXWC0(1) AAS
>>90
それは左辺値を理解できていないかな
例えばC#のlist is [first, .. , last]や
Rustの[first, .. , last] = list
この[first, .. , last]は左辺値だから関数に渡すことはできない
関数に渡すと右辺値になってしまう
94: デフォルトの名無しさん [sage] 2025/07/06(日) 09:20:13.49 ID:KjjDSONE(1/10) AAS
>>93
それこそ勝手に自分の編み出した左辺値の定義にとらわれてる老害としか思えない
if x is y(z)
これがわかりにくいとか、不都合が出てるならダメだけどこれは何も問題は引き起こしてない
95(1): デフォルトの名無しさん [sage] 2025/07/06(日) 09:40:05.23 ID:oWLlECDI(1/3) AAS
Kotlinみたいなのはどうなん？
val a: Any = "hello"
if (a is String) {
// このブロックでは a は String
println(a.length) // .length にアクセス可能
}
合理的だし便利だけど、この値は Any で宣言されてて、かつ String 型の別の引数に代入されてもいない
構文の一貫性に拘る人は、こういうのも受け入れないタイプなんかね？
96: デフォルトの名無しさん [sage] 2025/07/06(日) 09:51:03.49 ID:oWLlECDI(2/3) AAS
パターンマッチでないけど、Golangはかなり一貫性を欠いてると思う
ジェネリクスはずっと無かったのに、ビルドインの make 関数だけ特別扱いされてるなど
だけど多くの人にとってそんなのは重要でないし、そういう気持ち悪さとは関係なく、一定の人気を得ている
言語オタクが拘るようなところって、実用上はそんな問題にされないんだよ
97: デフォルトの名無しさん [sage] 2025/07/06(日) 09:59:51.35 ID:zqvmJlyP(3/12) AAS
この人は言語オタクとかじゃなくてすべてがRust風でないと気に入らない病人だから
98: デフォルトの名無しさん [sage] 2025/07/06(日) 10:09:00.81 ID:E6KLY+k2(1) AAS
みんなはパターンマッチングの話をしているのに
パターンマッチングの例を一つも出せない人が連投してるな
99(1): デフォルトの名無しさん [sage] 2025/07/06(日) 10:23:10.17 ID:KjjDSONE(2/10) AAS
is演算子の話をしてるんだと思う
100: デフォルトの名無しさん [sage] 2025/07/06(日) 10:24:24.82 ID:nk12zw98(1/4) AAS
パターンでなくても左辺値ならどれでもいい
どの言語でも必ず左側に来る
C#だけ右側に来ることがあり異様
上下前次1-新書関写板覧索設栞歴
あと 902 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s