Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

公式
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 part20
https://mevius.2ch.net/test/read.cgi/tech/1677771928/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/09/15(金) 23:48:06.93

>>228
どの辺りが重い感じ？

**デフォルトの名無しさん** · 2023/09/15(金) 23:52:51.61

>>231
borrowed, inout, owenedって全部キーワード指定だし結構長くない？
自分はRustみたいに明示的なのが好きだから多少長くてもいいけど
Python好きな人だとどうなんだろうって

**デフォルトの名無しさん** · 2023/09/15(金) 23:54:33.01

パターンマッチの場合束縛する変数が複数になり得るので、それぞれの変数に対して異なるmutabilityを宣言できる

あと、Rustは変数への束縛にmove/refの区別もあることも関係してるかもね
letやvarのように別構文を用意するなら、それぞれに対してmove版、ref版が必要になってしまう

**デフォルトの名無しさん** · 2023/09/15(金) 23:59:25.63

let (foo, ref mut bar) = とかよく使うもんね
mutやrefが分離キーワードになっているRustが便利

**デフォルトの名無しさん** · 2023/09/15(金) 23:59:43.71

>>230
なるほどね
mojoでunpackがどうなるのか知らないけど
unpack用のlet/varシンタックスはあった方が良いね

let/var方式の他の言語を参考にするんだろうな

**デフォルトの名無しさん** · 2023/09/16(土) 00:02:44.62

>>234
>mutやrefが分離キーワードになっているRustが便利

これを突き詰めるとponyになるって5chで聞いたよw

**デフォルトの名無しさん** · 2023/09/16(土) 00:03:10.36

>>234
いや、今となってはrefはほとんど使わん

**デフォルトの名無しさん** · 2023/09/16(土) 00:26:11.63

TauriとTauri Mobileが別々の実装として統合されないの悪手だと思うんだがな
せっかくRustでロジック書けてネイティブ呼び出しまで簡単で手頃なフロントエンド実装で期待してたのにわざわざコミュニティ分断する必要あるんか？
なんかXamarinみたいな結末迎えそうで残念だわ

**デフォルトの名無しさん** · 2023/09/16(土) 09:10:27.83

T,o,k（迷惑という方は←をあぼーんしてください。）

更に家族に教えて加えて￥4000×人数をGET。
https://i.imgur.com/p75gBok.jpg

**デフォルトの名無しさん** · 2023/09/16(土) 09:55:59.18

>>238
無理に一つにしようとすると条件分岐増えてごちゃごちゃしてわかりにくくなる、というのはありそう。知らんけど。

**デフォルトの名無しさん** · 2023/09/16(土) 10:40:22.96

>>239
もう現金化してアンインスコしてる

**デフォルトの名無しさん** · 2023/09/16(土) 11:27:20.46

RustRoverを試してみる
https://zenn.dev/helloyuki/scraps/a0241df49b2556

**デフォルトの名無しさん** · 2023/09/16(土) 11:55:36.71

ウェブ系の奴らがやけにJetBrains推してくるけどAndroid Studio使ったら如何にゴミIDEなのかよくわかった
しかも個人使用でも買い切り数百ドルもしたのに今はサブスク月額1300円とかぼったくりもいいところ
VSCodeがあって本当によかったVSもCEならデバッガに制限あるけど無料だしこれほどMSに感謝したことはないね

**デフォルトの名無しさん** · 2023/09/16(土) 12:20:19.81

mut よりもShared XOR Mutableの方が難しいだろ。

**デフォルトの名無しさん** · 2023/09/16(土) 12:41:23.41

>>243
Android Studio は IntelliJ IDEA がベースになっていて無料の community 版があるが?
ていうか Android Studio の方は最初から無料じゃなかったか? 金取るやつあるの?

**デフォルトの名無しさん** · 2023/09/16(土) 12:57:41.63

>>223
let x: &mut Type = ...
でよくね？

**デフォルトの名無しさん** · 2023/09/16(土) 13:00:07.59

>>244
lifetimeが難しいというのも大体がshared xor mutableの話だしな

**デフォルトの名無しさん** · 2023/09/16(土) 13:07:54.84

>>246
それだとimmutableとなり変数値を書き換えできないから根本から違う

**デフォルトの名無しさん** · 2023/09/16(土) 13:23:53.43

描き替え出来るから問題無い

**デフォルトの名無しさん** · 2023/09/16(土) 13:57:40.01

>>249
ポインタ値の書き換えと
ポインタが指す先の書き換えの
区別がついていないのはCでも初心者レベル

**デフォルトの名無しさん** · 2023/09/16(土) 14:05:34.65

うん
だから付ける必要無い所まで描く必要無いよね

**デフォルトの名無しさん** · 2023/09/16(土) 14:06:34.42

refとmoveの区別がある言語とそうでない言語の構文比較しても仕方なかろう

**デフォルトの名無しさん** · 2023/09/16(土) 14:10:34.38

>>246
ダメです
全く異なります
let mut x: &mut Type = ...　←xの値を書き換えられる
let x: &mut Type = ...　←xの値を書き換えられない

**デフォルトの名無しさん** · 2023/09/16(土) 14:24:43.82

>>253
だから付ける必要無い所まで描く必要無いよね

**デフォルトの名無しさん** · 2023/09/16(土) 14:32:47.40

>>239
絶対に試すべきだね。

**デフォルトの名無しさん** · 2023/09/16(土) 14:37:19.47

>>254
mutabilityを必要とする分に応じてmutを付ける必覧vがあります
そのため以下4種類がコードに応じて使い分けされています
let mut x: &mut Type = ...
let x: &mut Type = ...
let mut x: &Type = ...
let x: &Type = ...
前者のmutは変数xの値を更新するならば不可欠です
後者のmutはType型の可変参照で参照先の値を更新するならば不可欠です
それぞれの値を更新するためにはそれぞれのmutを欠くことはできません

**デフォルトの名無しさん** · 2023/09/16(土) 14:43:13.66

ほんまジャップはアホやな
しょーもない重箱の隅をつつきあって知識自慢のマウント合戦
そして出来上がった成果物は誰も使わないクソゴミ
ジャップがオナニーしてる間にソフトウェアは中国に30年遅れているという現実
お前ら見てるとマジで日本人がソフトウェアで土人の未開レベルな理由がよーくわかる

**デフォルトの名無しさん** · 2023/09/16(土) 17:08:24.37

まともなプログラミング言語ならばそれら四つの区別がある
例えばC/C++ではこのように対応する

// 変数値は不変で参照先も不変
Rust: let p1: &i32 = ...
C/C++: const int* const p1 = ...

// 変数値は可変で参照先は不変
Rust: let mut p2: &i32 = ...
C/C++: const int* p2 = ...

// 変数値は不変で参照先は可変
Rust: let p3: &mut i32 = ...
C/C++: int* const p3 = ...

// 変数値は可変で参照先も可変
Rust: let mut p4: &mut i32 =...
C/C++: int* p4 = ...

つまり可変な時にmutを付けるか
不変な時にconstを付けるかの些細な違いにすぎない

**デフォルトの名無しさん** · 2023/09/16(土) 17:14:29.95

参照の可変性という概念を持つ言語がそもそも少ない

**デフォルトの名無しさん** · 2023/09/16(土) 17:15:13.87

概念が異なるのに構文の話だけをしても仕方ない

**デフォルトの名無しさん** · 2023/09/16(土) 17:34:04.75

参照先の値がread onlyかwritableかはプログラミングで極めて重要だよね
間違えて意図せず書き換えてしまっていたバグなどの減少にも繋がるから必要な機能じゃないかな

**デフォルトの名無しさん** · 2023/09/16(土) 17:37:07.29

>>258
2番目と4番目はRustだとsmellyなのでリファクタリング検討候補

**デフォルトの名無しさん** · 2023/09/16(土) 19:41:48.63

>>204が言ってるのはmutの区別が不要じゃなくて
良く使うmutable側でタイプさせんなってことでしょ

**デフォルトの名無しさん** · 2023/09/16(土) 20:04:56.12

ほとんどのプログラムではmutと記述すべきところが少ない
もしmutが多いならレアケースを除いてコードを改善すべき可能性が高い

**デフォルトの名無しさん** · 2023/09/16(土) 20:10:22.45

>>263
＞良く使うmutable側でタイプさせんなってことでしょ

お前、それプログラミングのセンス無いわ。
あ、もしかして使い捨てのコードしか書いたこと無い？

**デフォルトの名無しさん** · 2023/09/16(土) 20:12:22.58

>>263
慣れてきたらmutあんま使わなくて書けるようになるよｗ
関数型言語やってるとmut相当のもんなんて基本使わんのだし

**デフォルトの名無しさん** · 2023/09/16(土) 20:31:44.89

>>266
その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん

mut祭りで読みづらい代わりに高速でメモリ効率が良いのがRustの売りでしょ

**デフォルトの名無しさん** · 2023/09/16(土) 20:37:59.24

多い少ないの話したいなら定量的な根拠持ってきてくれ
根拠ないなら断言するのはやめて

**デフォルトの名無しさん** · 2023/09/16(土) 20:45:23.05

>>267
それは関係ない
まずRustのほとんどのプログラムでmut祭りになることはなくmutの出現は少ない
その上でRustはCとほぼ同じ程度速い

**デフォルトの名無しさん** · 2023/09/16(土) 20:50:47.30

どちらがより目立つべきかを考えたら
mutable なほうが目立つべきだし
目立って欲しい方に指定をつける文法が自然だ。

良く使うほうが短く書けるべきという視点だって
もちろん間違いではないし、評価軸は無数にある。

定量化したところでそれぞれの重みをどう捉えるかは
感性の問題だろ。

**デフォルトの名無しさん** · 2023/09/17(日) 12:16:37.26

>>211
Goでできない非同期処理って何？
channelとselectとgoroutineとsyncパッケージでなんでもできるけど

**デフォルトの名無しさん** · 2023/09/17(日) 13:48:53.24

>>271
例えばベアメタル環境での非同期とか？
まぁ大抵の環境でだいたい上手く行くってのがGoのいいところだから
別に悪くはないと思うけど

**デフォルトの名無しさん** · 2023/09/17(日) 17:36:59.55

毎日ちょっとずつ課題でてそれを解いていくようなRust勉強サイトってないの？
ナンプレ毎日１問クリアしていく感じなやつ

**デフォルトの名無しさん** · 2023/09/18(月) 01:48:58.76

>>273
exercism.org どうかな

**デフォルトの名無しさん** · 2023/09/18(月) 10:51:29.83

>>267
>その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん

Rustのことなら#[derive(Copy)]とか.clone()とか描いちゃだめだよ絶対

**デフォルトの名無しさん** · 2023/09/18(月) 12:04:31.40

>>267
エイリアス解析がやりやすくなって本質的に同じものなのか
複製が必須なのか自動で判断して最適化される。
プログラマが判断するよりたぶん賢い。

mut を付けるかどうかは性能じゃなくてロジック的な妥当さで決めるもんだよ。

**デフォルトの名無しさん** · 2023/09/18(月) 12:15:08.64

techempowerベンチ見るとrustと比較してgoがしょぼいけど
こんなものなの?

**デフォルトの名無しさん** · 2023/09/18(月) 12:28:49.50

つよつよプログラマがチューニングすれば際限なく性能を挙げられるという意味での性能の良さと
非プログラマがテキトーに書いても及第点程度の性能が出るというのは言語として両立しにくい。

仮にしょぼいのが本当だとしてもトレードオフになる何かがあったりするから
総合的な使用感は実際に使ってみないとよくわからん。

**デフォルトの名無しさん** · 2023/09/18(月) 12:39:00.83

>>277
GoはGC内蔵言語だから本質的に遅い
GC内蔵言語はGCするから遅いわけではなくGCのためにヒープメインにならざるをえないため遅い

**デフォルトの名無しさん** · 2023/09/18(月) 12:44:14.37

なんでもイミュータブルじゃなくて必要な時にミュータブルにしつつ安全性をコンパイラが保証してくれるのがいいんだよなぁ。

**デフォルトの名無しさん** · 2023/09/18(月) 13:13:11.65

そもそも、goはc#にすら負けてね?
1番高速じゃなくても2番目あたりでいいかなと思ってるんだけど
どれがいいのかなと

ななやむぐらいならわかりやすい1番にしとけばいいのか?

**デフォルトの名無しさん** · 2023/09/18(月) 13:16:25.44

goのgc調べてみましたが参照カウントとかじゃないのか

**デフォルトの名無しさん** · 2023/09/18(月) 13:54:07.10

Rustは見た目が汚いのが困る
もういっそCの方がきれいで安全で保守性が高いまである

**デフォルトの名無しさん** · 2023/09/18(月) 14:01:16.96

Cは大きなプロジェクトが汚すぎる
モジュールで名前空間分けられないから

**デフォルトの名無しさん** · 2023/09/18(月) 14:04:02.95

C言語は"安全装置のない銃"に徹しているからな
シンプルなだけに危険いっぱいだ

**デフォルトの名無しさん** · 2023/09/18(月) 14:43:26.49

C#はunsafeやSpanがあるので頑張れば結構速い
ネイティブコンパイルもできるようになってきたからとにかく速度を求めるようなアプリじゃなければ十分

**デフォルトの名無しさん** · 2023/09/18(月) 15:27:10.56

Rustもcrateのダウンロード数に応じて
crate開発者が課金される時代か
メシウマじゃなかった胸熱

**デフォルトの名無しさん** · 2023/09/18(月) 15:57:52.35

何の話かと思えばunityか

**デフォルトの名無しさん** · 2023/09/18(月) 16:04:36.29

とりあえずミュータブルの話をするならshared xor mutable に触れなきゃ意味ないし、それなら元ネタのトランザクション分離レベルぐらいは勉強しとかんといかん。

**デフォルトの名無しさん** · 2023/09/18(月) 16:05:47.88

>>285
C(C++含む)の真のヤバさはそれが周知されていないことだと思う
セキュリティ、セキュリティ吠えながら妄信的にC/C++使っているところとか普通にあるし

**デフォルトの名無しさん** · 2023/09/18(月) 17:52:28.36

>>283
＞もういっそCの方がきれいで

前置宣言だからそれは無い。

**デフォルトの名無しさん** · 2023/09/18(月) 22:02:21.17

>>291
前置宣言だから綺麗に書けるまである

**デフォルトの名無しさん** · 2023/09/18(月) 22:29:41.23

>>283
Rustは普通というか見た目キレイ側

**デフォルトの名無しさん** · 2023/09/18(月) 23:41:51.16

>>290
ロジックが正しくてもバイナリレベルでは脆弱性になることがある。
分かりやすい例では、言語の理屈では寿命を終えたはずのオブジェクトでも再利用される機会がなくて内容が残り続けるとかね。
そういうときにでもどうにかする知見が C/C++ では積み上がってる。

普通に書いて脆弱性が発生しにくいに越したことはないが、脆弱性が発生していることがわかったときに直せる確信があるというのはセキュリティが重要な場面で C/C++ を使う理由になる。
C/C++ が「自分の足を撃つ」ことになるなんてのは百も二百も承知の上で、「自分の足を撃つことも出来る」ことに価値を見いだしてるんだよ。
もともと自分の足を撃つというのは戦争に行かなくて済むようにわざと撃つことがあるというのを下敷きにした言い回しで、危険であると同時にそれが必要なこともあるというニュアンスを含んでいる。

**デフォルトの名無しさん** · 2023/09/18(月) 23:47:04.73

>>294
それRustに対するアドバンテージになってないな
むしろディスアドバンテージ

**デフォルトの名無しさん** · 2023/09/19(火) 07:20:03.69

>>294
目的のために敢えてUB引き起こすってこと？

**デフォルトの名無しさん** · 2023/09/19(火) 11:44:23.57

>>294
＞そういうときにでもどうにかする知見が C/C++ では積み上がってる。

所謂、バッドノウハウね。
そりゃさんざん今までやりまくって、なんなら現在進行形だったりするんだからノウハウも積み上がるさ。

**デフォルトの名無しさん** · 2023/09/19(火) 13:23:13.06

データベースのデータファイルの中の構造は、
C言語の「全部生メモリ」状態で、ポインタの
変わりにファイルポジションになっていて
普通に相互リンクトリンクやファイルポジション
をデータの位置を表現するのに使われていたりする。
だから、実行中のプログラムの RAM のメモリー安全
は確保されたとしても、ファイルの中は安全には
ならない。

**デフォルトの名無しさん** · 2023/09/19(火) 13:27:32.55

>>298
[補足]
・ポインターの代わりにファイルポジションが使用され、
　古来の plain C と同様のプロググラミングが行なわれている。
・LockFile や fnctl で「部分ロック」が当たり前
　のように使用されており、非常に複雑な
　配慮が必要なプログラミングになっている。

もっといえば、DBMS を使うアプリケーションも、非常に
配慮が必要な場合も多く、どのようなテーブルやカラム構造
にするかは難しい。ID番号をリンクしたり、どうやって
データを参照しあうかなどが生ポインタと同様の難しさ
を持っていて、わずかでも間違えば、全データが論理破損
してしまう可能性を持っている。

**デフォルトの名無しさん** · 2023/09/19(火) 14:54:41.30

だれか巻き込まれてないか？
https://www.youtube.com/watch?v=SzpaDEhm-8Q

**デフォルトの名無しさん** · 2023/09/19(火) 15:58:16.52

形式検証をrustに組み込むのってどれくらい現実的なんだろ
言語本体ではなくてproc macroで実現できるのかね

**デフォルトの名無しさん** · 2023/09/19(火) 16:39:15.02

>>299
一般的なDBMSは中央集権でページアクセスを一元管理してるから生ポインタとは全く質が異なる

**デフォルトの名無しさん** · 2023/09/19(火) 17:37:47.80

>>302
ただ、購入履歴などは「誰が購入したか」のIDを
購入項目テーブルとユーザーテーブルを結びつける
必要があるので、IDがポインタの役割になる。
わずかでも狂うと、別人が買った項目が結び付け
られてしまう。
値が1つ、または、行が一行でもずれるとほぼ全体が破綻する。

**デフォルトの名無しさん** · 2023/09/19(火) 18:14:50.54

DBでも何でもそうだけどshared xor mutableも必要

**デフォルトの名無しさん** · 2023/09/19(火) 18:23:26.80

販売サイトなどのバグって怖くて、500円のものが
バグれば5000円になったりする可能性ある。
そういうものは、プログラミングを気をつける
しかなくて、Rustの安全対策でも防げない。

**デフォルトの名無しさん** · 2023/09/19(火) 18:32:19.28

「気を付ける」の内訳にはテストを書く習慣とかが含まれてる。
気を付けないとしょうがないけど
気を付けるのに使える道具はそれなりに揃ってる。

**デフォルトの名無しさん** · 2023/09/19(火) 18:34:24.73

すべてのバグをなくせる言語がないのは当たり前
データ競合により起こるそういう値のバグも現実にあるのだからRustでその手のバグをなくせるのも事実

**デフォルトの名無しさん** · 2023/09/19(火) 18:55:07.79

>>303
そのレイヤーの話でもDBMSはトランザクション管理されてるから生ポインタとは状況が全く異なる
トランザクショナルメモリで管理された共有メモリと生ポインタの違い(実際はそれよりもまだ差がある)

**デフォルトの名無しさん** · 2023/09/19(火) 19:02:27.03

>>304
同時実行制御には大きく楽観的制御と悲観的制御があるがshared xor mutableは後者
高い同時実行性能が求められる場合には楽観的同時実行制御を使うことが増えている
DBの話だけでなくロックフリーアルゴリズムも基本は楽観的制御

**デフォルトの名無しさん** · 2023/09/19(火) 19:54:07.45

>>309
楽観的排他制御を用いることができる現実的ケースが狭い
衝突した時の処理やり直しコストも考慮する必要がある

その一般的な話とは別にポインタ(参照)の話の方は必ず衝突するためsingle writer xor multiple readersが必須

**デフォルトの名無しさん** · 2023/09/19(火) 21:00:27.72

排他制御も凄く奥深い話ではあるが、そういう
ものだけでなく、単なるプログラムミスで、
ID番号が1つずれたり、行がなんらかの事が
原因で1ぎょうずれたりしても、大変な問題
を巻き起こす。だからテストは必須。

**デフォルトの名無しさん** · 2023/09/19(火) 21:30:53.89

RDBMSで物理的な一行とか関係ない
テキストファイルに永続化してる素人だな

**デフォルトの名無しさん** · 2023/09/19(火) 21:34:30.39

>>312
DBMS自体をプログラムする場合には関係ある。

**デフォルトの名無しさん** · 2023/09/19(火) 21:41:37.42

それと、DBMSを使うに徹する場合でも、行に
付ける ID 番号の管理がまた問題になる。
それも慎重に良く考える必要がある。

**デフォルトの名無しさん** · 2023/09/19(火) 21:50:10.01

それサロゲートキー義務で設計したらの話でしょ

**デフォルトの名無しさん** · 2023/09/19(火) 21:55:08.52

>>315
色々な機能を実装する上で、色々有り得る。

**デフォルトの名無しさん** · 2023/09/19(火) 22:32:18.55

>それと、DBMSを使うに徹する場合でも、行に
>付ける ID 番号の管理がまた問題になる。

DB板にもそういうのいるけどRDBにID必要と考えてるやつはもっかい勉強してこい

**デフォルトの名無しさん** · 2023/09/19(火) 22:44:03.77

>>310
>楽観的排他制御を用いることができる現実的ケースが狭い
MVCCやCASが楽観的制御
分散非同期が前提の世界では楽観的制御がデフォルト
じゃないとスケールしないから

Rustがコンパイル時悲観的制御にしてるのは実行時の管理を無くしたいからであってポインタだとshared xor mutableが必須だからではない
トランザクショナルメモリがその一例

**デフォルトの名無しさん** · 2023/09/19(火) 22:57:59.75

DBMSをプログラムする場合には当然関係ある
でも1行ずれたら大変とかいう下手くそは任されないので関係ない

**デフォルトの名無しさん** · 2023/09/19(火) 23:03:17.25

>>319
下手クソとか上手いとかっていうより、
そうならないようなアルゴリズムやデータ構造を
ちゃんと考える能力があるかどうかなん
だろうけどな。

**デフォルトの名無しさん** · 2023/09/19(火) 23:06:22.84

可変参照と不変参照に対してMVCCなんて使えないよ
それはデータをコピーすることと同じになってしまう
ソフトウェアトランザクショナルメモリはどの環境でも使用可能なのに不利だからほぼ使われていない
さらにRustのshared xor mutableはそれらと独立した話であり共存できる話なのでshared xor mutable必須は問題ない

**デフォルトの名無しさん** · 2023/09/20(水) 01:44:31.66

会話のドッジボール

**デフォルトの名無しさん** · 2023/09/20(水) 09:31:56.94

>>303
マイニャンバーですね判ります

**デフォルトの名無しさん** · 2023/09/20(水) 09:33:37.66

>>305
500円の商品が5000円になるバグよりも
500円の商品が5円になるバグの方がはるかに怖い

**デフォルトの名無しさん** · 2023/09/20(水) 09:37:31.04

>>313
いやいやωωω

**デフォルトの名無しさん** · 2023/09/20(水) 09:39:49.95

>>324
一番の問題は、レジ打ちの人間だったら絶対間違わない
ミスがコンピュータでは起こりえるということだよ。

**デフォルトの名無しさん** · 2023/09/20(水) 09:41:04.74

>>325
DBMSのアルゴリズムやSQLiteのソースなどを見ていたが、
大いに関係あるぞ。

**デフォルトの名無しさん** · 2023/09/20(水) 10:30:52.85

SQLiteはファイルロックに頼らざるを得ない仕組みなのでDBとしては特殊

**デフォルトの名無しさん** · 2023/09/20(水) 11:17:52.24

俺が高校生だった25年前頃、志木駅で500円分ぐらいのパンを買ったら4000円ぐらい請求されたぞ

**デフォルトの名無しさん** · 2023/09/20(水) 11:46:41.00

まあ他のバグが減ればその分本質的な問題に注力出来るわな
そういうのはテストケースも綿密に行う必要がある