Rust part28

**デフォルトの名無しさん** · 2025/03/24(月) 17:37:00.15

公式
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 part27
https://mevius.5ch.net/test/read.cgi/tech/1733146370/

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

**デフォルトの名無しさん** · 2025/04/03(木) 07:34:50.76

いつまでもアホなこと言っていないで、まずはRust Book最新版の翻訳を作って統一しとけ。

最新版で「トレイト制約」になっていれば文句言わんよ。

**デフォルトの名無しさん** · 2025/04/03(木) 07:55:55.24

機械翻訳みたいに一対一に当て嵌めてるのはどっちなんだか
辞書で引けば constraint = 制限、制約、圧迫、束縛などいろいろあるよ？

英語だと
bound is a constraint that restricts the type ...
のように、ある概念を伝えるのに複数の語を使うことをよく行う
これは同じ単語の繰り返しを避ける (そういう文章を拙いと見做す) 文化があるのと、単語が誤って理解されないようにというのがある
この例なら、 bound が「飛び跳ねる」などの意味と解釈されないよう、 constraint や restrict などと言い換えることでそれが制限・制約という意味だと伝わるようにする

もちろん用語としては trait bonud が正式な名称だから、これを trait constraint や trait restriction とは呼ばない
けど、意味としてはこれらに近いということ

**デフォルトの名無しさん** · 2025/04/03(木) 11:23:23.08

>>226が批判してるのはboundを制約と訳すとBounds are constraints on a type or traitが「制約は制約である」となってしまうからtrait boundsもトレイト制約と訳すべきではないと言ってるやつのほうでしょ

**デフォルトの名無しさん** · 2025/04/03(木) 12:16:36.08

その一文だけ、うまく訳せばいいんじゃないの?
動詞の方を簡易な日本語表現にすれば進次郎構文は避けられる

**デフォルトの名無しさん** · 2025/04/03(木) 12:19:56.95

トレイト制約という明らかに間違った別の訳をしつこく持ち出す人はRust界の混乱を狙った荒らしなんだと思うよ
なぜtrait constraintではなくtrait boundsなのかという一番本質的なRustでの概念の違いに興味を持たないことからも

**デフォルトの名無しさん** · 2025/04/03(木) 12:20:15.17

制約を英英辞典か国語辞典で調べて考えよう

**デフォルトの名無しさん** · 2025/04/03(木) 12:23:12.59

英語的にはboundsの方が身近な表現かもしれんな。コンストなんちゃらは共和党支持層が嫌うラテン語由来なのだっけ

**デフォルトの名無しさん** · 2025/04/03(木) 12:33:49.45

さっさとペンキの色決めろよ

**デフォルトの名無しさん** · 2025/04/03(木) 12:34:32.24

どちらが間違ってるかは>>207や>>215を見れば一目瞭然だよな
改めて振り返ると境界知能というのはあながち冗談ではなさそう

**デフォルトの名無しさん** · 2025/04/03(木) 12:39:11.80

トレイト緊縛で決まりな

**デフォルトの名無しさん** · 2025/04/03(木) 12:52:17.06

「トレイトバウンド」よりも日本語話者の理解を助ける言葉じゃなければ意味がないんだよな
その意味では同じ誤訳でも「トレイト境界」より「トレイト束縛」のほうがベターな訳だった

**デフォルトの名無しさん** · 2025/04/03(木) 12:55:25.10

トレイト緊縛。大勝利ってこと

**デフォルトの名無しさん** · 2025/04/03(木) 15:48:03.91

制限でいいよ

Javaの場合は
「Bounded Type Parameters」
https://docs.oracle.com/javase/tutorial/java/generics/bounded.html
google翻訳では「制限付き型パラメータ」
凄くわかりやすいよね
制約よりも境界よりもずっとわかりやすいよね

**デフォルトの名無しさん** · 2025/04/03(木) 17:10:42.17

次スレは
Rust 29constraints
だね

**デフォルトの名無しさん** · 2025/04/03(木) 18:04:14.96

そういう変なことしだすと隔離失敗するからやめてね

**デフォルトの名無しさん** · 2025/04/03(木) 18:08:12.59

Javaの日本語リファレンス終わったのか。Java終了だな

**デフォルトの名無しさん** · 2025/04/03(木) 18:23:21.08

>>240
俺の環境では
google翻訳は境界付き型パラメータ
DeepLは制約付き型パラメータだな

ただJavaも>>227みたいにboundには一貫して「境界」という訳を当てないといけない方針でやってたから関連語の訳がどうしようもなく悲惨なものになってたからね
同じ轍を踏んではいけない

**デフォルトの名無しさん** · 2025/04/03(木) 18:30:06.80

トレイト制約はトンデモ勘違いだから絶対避けるべきだけど
トレイト境界やトレイト範囲やトレイト領域やトレイト上界やトレイト上限やトレイト限界などの意味するところが合ってる用語ならばどの用語に統一されても構わないよ
もちろんトレイト境界のままでもOK

**デフォルトの名無しさん** · 2025/04/03(木) 18:38:58.21

Bound単体を「型制約」と訳したいならTrait Boundsは「トレイトによる型制約」とでも訳せばいいだろ
重要なのは形式よりも意味のほうなんだから

**デフォルトの名無しさん** · 2025/04/03(木) 18:48:27.65

>>236
その2つ面白すぎるんですけど
特に「境界は制約である」がジワる

**デフォルトの名無しさん** · 2025/04/03(木) 19:00:17.94

>>246
普通に「トレイト境界は型やサブトレイトに対する制約である」でええやん

**デフォルトの名無しさん** · 2025/04/03(木) 19:07:19.95

サブトレイトって言い続けてる奴一人な件ｗ

**デフォルトの名無しさん** · 2025/04/03(木) 19:13:35.15

どういうこと？
みんな使っていてRustのどの記事を見てもスーパートレイトとサブトレイトと訳されてるけど別の訳があるの？

**デフォルトの名無しさん** · 2025/04/03(木) 19:32:15.98

形式主義って、完全情報ゲームなんだよな
オリジナルの原文にない情報が後知恵で追加されたらそれは完全情報とは言えないよね

**デフォルトの名無しさん** · 2025/04/03(木) 19:35:30.32

公式ではなくても定着していてカジュアルな場面では当たり前のように使われる用語ってあるからなぁ。
C++ で構造体とかアップキャストとかメソッドとか言ってることは結構あるでしょ。

**デフォルトの名無しさん** · 2025/04/03(木) 20:32:04.51

ほかに話すことはいくらでもあるのに永遠にboundの訳語だけを言い争い続けるこのスレ、終わってるよ
ていうか別スレ立ててそっちでやれや

**デフォルトの名無しさん** · 2025/04/03(木) 21:30:43.37

structのdrop定義したとき
元のstructのmemberに別のstrustがあったら
どっちのdropが先に呼ばれる？
あと元のstructのmemberに自分のstructがあったら？

**デフォルトの名無しさん** · 2025/04/03(木) 21:31:56.02

>>253
ほかに話すことがないからこうなってるんだって

**デフォルトの名無しさん** · 2025/04/03(木) 21:45:12.33

>>254
必ず宣言順にdropされる
つまり入れ子ならば深さ優先
もしdropの順序を変えたいならばManuallyDropを使って自分の好きな順にdropできる

**デフォルトの名無しさん** · 2025/04/03(木) 21:58:57.73

>>254
最初に構造体自身の drop が呼ばれて、その後に各フィールドの drop が宣言順に呼ばれる
例えば
struct Foo { bar: Bar, baz: Baz }
なら、最初に Foo::drop が呼ばれて、その後に Bar::drop, Baz::drop の順に呼ばれる

「元のstructのmemberに自分のstructがあったら」はちょっと意図が汲み取れなかった
Rcで自身への参照を子が持つようなケースであれば、drop が呼ばれずメモリリークする
(親がdropしないと子がdropしない、子がdropしないと親がdropしない、という関係になるため)

**デフォルトの名無しさん** · 2025/04/03(木) 22:12:13.45

>>248
いやいや「境界」どっから出てきたんだよｗ
公式が言ってるようにboundsに境界なんて意味はない
関係ない変な単語を持ってくるくらいなら訳さないほうが遥かにいいだろ

**デフォルトの名無しさん** · 2025/04/03(木) 22:12:45.42

weekじゃなくてweak

**デフォルトの名無しさん** · 2025/04/03(木) 22:20:03.44

>>258
境界信者：「境界は制約である」
境界信者：「ゆえにboundsは境界である」
境界信者：「ゆえにトレイト境界が正しい」

**デフォルトの名無しさん** · 2025/04/03(木) 22:44:11.30

>>260
仮に「境界は制約である」が正しいとしても「制約は境界である」とは限らないので「boundsは境界である」は成り立たないぞ

**デフォルトの名無しさん** · 2025/04/03(木) 22:54:37.51

Rustの公式リファレンスを見ればわかるけど
boundsはそのトレイトやライフタイムなどが取り得る範囲を意味している
それがジェネリックな型に対しては制約となるという扱い
例えばCopy bounds等の表現があるがCopyという制約があるわけではない
むしろCopyという特性を持つ
結果的にジェネリックな型に対しては制約となるだけである
したがってトレイト制約というねじ曲がった用語はふさわしくない

**デフォルトの名無しさん** · 2025/04/03(木) 23:11:56.25

彼はたった一人で>>262のような主張を繰り返すのである
逆走老人が「みんなが逆走してる」と主張するかのように

**デフォルトの名無しさん** · 2025/04/03(木) 23:58:29.10

トレイト境界は型パラメータに対してだけではなくトレイトオブジェクトでもdyn TraitA + TraitB + TraitCと指定するけど
機能を列挙していく感じで使うから制約とは真逆のイメージだわ

**デフォルトの名無しさん** · 2025/04/04(金) 00:08:35.54

拡張ってこと

**デフォルトの名無しさん** · 2025/04/04(金) 00:13:55.18

>>264
それは trait object であって bound とは呼ばないんじゃないか？
trait Foo オブジェクト, trait Foo+Baz オブジェクトといった感じ
Rust by example だとそもそも bound の説明はジェネリクスの章の中にある
(14. Generics > 14.4. Bounds という構成。ちなみに trait object は 16. Traits の中)

Boundはどちらかというとジェネリクスの型を制限する用途の方を指すと思う

**デフォルトの名無しさん** · 2025/04/04(金) 00:20:38.53

昔は実行時に検査していたことをコンパイル時に検査できるという見方はものすごく理解を助ける
だから検査や制約を強調していい
もしバランスを崩したくないと思ってるなら、単一の言語にこだわること自体がバランス悪いから
Pythonでも使ってみればいい

**デフォルトの名無しさん** · 2025/04/04(金) 00:25:07.15

rubyの方が型無いよ

**デフォルトの名無しさん** · 2025/04/04(金) 00:40:23.72

>>266
一応それもBoundの範疇みたいだけどね
https://doc.rust-lang.org/reference/types/trait-object.html

まあどっちにしろどちらの視点で見るかの話はジェネリクスとなんら変わりない
Boundの公式定義にある通り

**デフォルトの名無しさん** · 2025/04/04(金) 00:44:33.84

いやジェネリクスのように好き勝手に追加していけないという制約があるから
トレイトオブジェクトのほうが「機能を列挙していく」という視点にはより無理があるかもな

**デフォルトの名無しさん** · 2025/04/04(金) 00:45:23.73

そういえば最近use boundとか来てたんだっけ

**デフォルトの名無しさん** · 2025/04/04(金) 00:54:43.92

>>266
そこに明記されてるね

Trait objects are written as the keyword dyn followed by a set of trait bounds,
トレイトオブジェクトはキーワードdynに続くトレイト境界のセットとして記述される
but with the following restrictions on the trait bounds.
ただしトレイト境界に以下の制限がある
(以下略)

**デフォルトの名無しさん** · 2025/04/04(金) 10:34:51.57

こんな分かりきったことで議論する意味は何なのか
制約ではまるっきり意味が違う

**デフォルトの名無しさん** · 2025/04/04(金) 11:01:51.62

トレイト制約（バウンズ）の集合の制限

これ、「ポインタのポインタのポインタ」をいちいちtypedefするやつと同じパターンだな
だから単語の重複が許せないんだな

**デフォルトの名無しさん** · 2025/04/04(金) 11:17:35.72

AsRefやAsMutはtraitになってるのに
sliceのAsPtrやAsMutPtrがtraitになっていないのはなぜ？

**デフォルトの名無しさん** · 2025/04/04(金) 11:54:32.49

アホなこと言っていないで、とっととRust Book最新版の翻訳を作って統一しとけ。

最新版で「トレイト制約」にすりゃいいだろ。

**デフォルトの名無しさん** · 2025/04/04(金) 12:57:24.90

>>272
その公式の記述ではっきりわかった
trait bounds 自体は制約ではなくて境界なんだな
トレイト境界がジェネリックな型パラメータTに適用される時に「型Tの制約」になるだけだ

**デフォルトの名無しさん** · 2025/04/04(金) 14:23:46.45

>>277
そうなんだけど
なぜか知らんけど
クラスとオブジェクトは同じみたいなことを言い出す輩が居てややこしい

**デフォルトの名無しさん** · 2025/04/04(金) 14:43:55.26

>>277
これブックマークしとけばええんかの

**デフォルトの名無しさん** · 2025/04/04(金) 15:06:26.98

RustやるにもC++から始めたほうが良いんじゃないかな
なぜそうなってるのか理解が進むと思う

**デフォルトの名無しさん** · 2025/04/04(金) 15:10:43.72

CやらないとC++分からないからCからオススメ

**デフォルトの名無しさん** · 2025/04/04(金) 16:14:54.75

>>277
“Bounds are constraints on a type or trait.”のbe動詞も、
「AはBである」と訳すものではなく、
「AはBになる(Bの特性を持つ)」で、どっちかといえばhasに近い意味合いになるんだよなぁって思ってる。

**デフォルトの名無しさん** · 2025/04/04(金) 19:30:24.62

まだトイレ制限やってんのか

**デフォルトの名無しさん** · 2025/04/04(金) 22:39:40.99

>>270
トレイトオブジェクトで自動トレイト以外のトレイト境界を複数用いる場合は合成になるね
いわゆるメソッド無し「{}」宣言

// トレイト境界の合成
trait TraitAB: TraitA + TraitB {}

// 合成トレイト境界の実装 (使う型の分)
impl TraitAB for T1 {}
impl TraitAB for T2 {}

// あとは同じ
let x: &dyn TraitAB = &t1;
// または
let y: Box<dyn TraitAB> = Box::new(t2);

**デフォルトの名無しさん** · 2025/04/04(金) 22:42:52.75

トイレット境界は難しいよ。いつもスリッパ履き替えるの忘れる

**デフォルトの名無しさん** · 2025/04/04(金) 22:52:47.44

複オジの苦し紛れのクソみたいな言い訳自演も秒で否決されてて草
さすがにみんな複オジ耐性を身につけたか

**デフォルトの名無しさん** · 2025/04/04(金) 23:41:57.03

>>284
トレイト境界は制約ではなく使う機能の列挙という理解でいいんだよな

**デフォルトの名無しさん** · 2025/04/04(金) 23:56:38.69

>>282
バカすぎだろw
そんな意味になるわけないじゃん
中学生でも絶対やらない間違いだぞ

**デフォルトの名無しさん** · 2025/04/05(土) 00:41:02.94

子供扱いさせてから、大人も子供もどっちもどっちだと洗脳するんだよ
そうやって、自分は大人と同じだと思ってる子供を量産する

**デフォルトの名無しさん** · 2025/04/05(土) 01:02:47.81

>>288
>中学生でも絶対やらない間違いだぞ
大の大人が中学生でも絶対やらない間違いをするから「境界」などというトンデモ訳が出てくるわけで

**デフォルトの名無しさん** · 2025/04/05(土) 01:15:11.42

>>282
そんなバカげた見方をしなくても英語でも日本語でも同じで修飾語がある時にそれ省けば同等を意味しない
例えば
「彼はわたしにとって味方である」
「彼はあなたにとって敵である」
これは両立しえて対象を抜きに彼自体は味方でも敵でもない

「boundsは型に対する制約である」
これもbounds自体は制約でも何でもない
あくまでも型に対しては制約となるだけだ
それを理解できない人がbounds自体を制約と訳してしまうと、
他の至る所で日本語訳が破綻してしまう例が既にいくつも挙げられている通りだ

**デフォルトの名無しさん** · 2025/04/05(土) 02:11:02.04

>>284
論理和"+"はベン図で言えばorだけどその複数のトレイトが適用される条件はandだからやっぱり境界じゃないな

traitA * traitBならandだったのに残念

**デフォルトの名無しさん** · 2025/04/05(土) 04:31:02.03

>>292
トレイト境界は必要となる機能を足していくイメージで使うから＋がしっくり来るよ

**デフォルトの名無しさん** · 2025/04/05(土) 09:21:38.69

+はor
*はand

これが基本

traitA * traitB　は　traitAが実装されている=1　traitBが実装されている=1　と言う時だけ　1(true)
だからこれが正しい

トレイト境界だと表現が矛盾している
+だと　traitAもしくはtraitBでtrueなのでやはりベン図的な境界ではありえない

**デフォルトの名無しさん** · 2025/04/05(土) 09:25:04.62

トレイト制約なら+がしっくりくる
条件がtraitAに加えてtraitBとなるので常識的だと思う

**デフォルトの名無しさん** · 2025/04/05(土) 09:31:25.64

>>295
実際にプログラミングすればわかるけど
必要となる機能を加えていくんだよ
制約なんて視点で考えないよ

**デフォルトの名無しさん** · 2025/04/05(土) 09:33:43.02

トレイト境界なんて変な言葉使ってるけど実際は集合論的な境界とはかけ離れている

**デフォルトの名無しさん** · 2025/04/05(土) 09:37:39.22

型パラメータTを使う場合でも同じ
例えば型Tをデバッグ表示したくなったら
T: Trait1+ Trait2 既存のここへ
デバッグ機能も使えるように足す
T: Trait1+ Trait2 + Debug
制約なんて発想はどこにもないよ

**デフォルトの名無しさん** · 2025/04/05(土) 09:59:12.29

trait境界がベン図的であると言うのはただの勘違いである

**デフォルトの名無しさん** · 2025/04/05(土) 10:05:02.72

A or Bはtypsscriptのユニオン型でそっちは　｜でつなげている

**デフォルトの名無しさん** · 2025/04/05(土) 11:05:30.39

「境界」と書かれてる本は読むに値しない
という事だけはよくわかった

**デフォルトの名無しさん** · 2025/04/05(土) 11:17:04.10

可能なら英語の原文を読む方がいいのは間違いない
bound⇔制約みたいな謎対訳を意識しなくて済む
洋書は高いけどね

**デフォルトの名無しさん** · 2025/04/05(土) 11:17:57.15

>>301
わかりやすいリトマス試験紙だよね

**デフォルトの名無しさん** · 2025/04/05(土) 11:19:18.81

>>301
境界はどうでもいいが
trait boundsの日本語訳をトレイト制約としてしまうとRust公式リファレンスのあちこちで困ったことになることが今回のこのスレでの調査で判明した
少なくともトレイト制約と訳してはいけないことが明白になった

**デフォルトの名無しさん** · 2025/04/05(土) 11:58:20.02

たとえばcobolをjavaに直訳できない問題って

新しい要素を追加した方に原因があるのか？

**デフォルトの名無しさん** · 2025/04/05(土) 13:46:49.67

>>291
ほんそれ

>>292
and にしたいなら TraitA & TraitB だろ常考
&'a TraitB と区別付かなくなるから避けたとかいうのは無しな

**デフォルトの名無しさん** · 2025/04/05(土) 13:48:18.46

>>294 == >>292 か
id変えて御苦労さん

**デフォルトの名無しさん** · 2025/04/05(土) 14:22:39.14

>>291
子供医者は一部の患者にとっては敵である？？

馬鹿みたいな思想だないつも

**デフォルトの名無しさん** · 2025/04/05(土) 14:29:32.69

>>307
日付変わったらid変わるんだよ…馬鹿なのかなあ？

**デフォルトの名無しさん** · 2025/04/05(土) 14:30:52.53

と思ったけど同じ日だな
5chがおかしいんだろ

**デフォルトの名無しさん** · 2025/04/05(土) 21:54:28.18

>>302
洋書のほうが断然安いだろ

**デフォルトの名無しさん** · 2025/04/05(土) 22:12:55.39

ものによるよ
具体的に比較せねば

**デフォルトの名無しさん** · 2025/04/05(土) 22:23:17.94

日本で洋書を買うなら輸入品だもの。
円安の情勢で高くなるのは仕方ないよ。

**デフォルトの名無しさん** · 2025/04/05(土) 22:38:25.51

TraitやTrait boundsが制約だと思ったんだろな
特性や特性の範囲を示しているだけで
必ずしも制限に使われると限らないのだが

**デフォルトの名無しさん** · 2025/04/05(土) 22:41:49.78

オライリーならサブスクで洋書PDF読み放題があったような

**デフォルトの名無しさん** · 2025/04/05(土) 22:54:56.00

Lifetime boundは？

**デフォルトの名無しさん** · 2025/04/05(土) 23:36:18.07

>>284
>>let x: &dyn TraitAB = &t1;

その合成したトレイト境界によるトレイトオブジェクトを、
一昨日リリースのRust 1.86からこのようにスーパートレイトへアップキャストできるようになったという理解でいいんだよな。
let xa: &dyn TraitA = x;
let xb: &dyn TraitB = x;

結局この＋によるトレイト境界の合成も、制約したと考えるより、両方の特性(機能)を持たせたと考える方が理に適ってるよな

>>// トレイト境界の合成
>>trait TraitAB: TraitA + TraitB {}

**デフォルトの名無しさん** · 2025/04/06(日) 01:02:23.74

境界の合成ならｏｒでしょう？なんでandになるんだよ

**デフォルトの名無しさん** · 2025/04/06(日) 01:05:52.29

その特性を持つか持たないか
両方の特性を持つようになるから'+'がふさわしい

**デフォルトの名無しさん** · 2025/04/06(日) 01:12:53.80

質問
トレイト境界と言う言葉があまりしっくりきません

chapGPTの答え

「トレイト境界（trait bound）」っていう言葉、ちょっとピンとこないというのは自然な感覚です。
むしろ「型に課す条件」とか「型パラメータの制約」というようなイメージの方が、Rustの使い方としてもしっくりくるかもしれませんね。

「trait bound」という言葉は英語の「bound（拘束、制約、限界）」の訳で、おそらく「型に制約を課す」という意味から来ています。
ただ、日本語で「境界」というと、物理的な境目やある範囲をイメージしやすく、それが逆にわかりづらくしているかもしれません。

しっくりくる言い換え候補いくつか
表現ニュアンス

トレイト条件 Tに必要な条件、論理的に「T ∈ Debugを満たす型の集合」

トレイト制約 Tにかかる制限。構文的にも意味的にも合ってる

トレイト必須要件必須で満たさなければならない要件

実装条件 implが意味する「Tは〜を実装していないといけない」

実装制限実装可能な範囲を制限する

**デフォルトの名無しさん** · 2025/04/06(日) 01:15:32.61

トレイト境界は誤訳で言いたいならトレイトバウンドでいい
これがFA

**デフォルトの名無しさん** · 2025/04/06(日) 01:23:12.69

欧米でのboundと日本の境界は必ずしも同じ意味ではない
そもそもの単語の概念が違う

boundの制約部分の意味合いを翻訳者が取れずにboundの一番目に来る訳語の境界を当ててしまった
これが結論

**デフォルトの名無しさん** · 2025/04/06(日) 02:18:12.24

うっかりミスをしただけなら喧嘩にはならんがな
原作を改変することは許されない的なルールを守る意志があるだろ

**デフォルトの名無しさん** · 2025/04/06(日) 03:03:56.95

安いな
https://www.rustinaction.com
https://www.manning.com/books/rust-in-action
高いな
https://www.ama損.co.jp/dp/1617294551
輸入だとしてもなんでこんな値段になるんだ

**デフォルトの名無しさん** · 2025/04/06(日) 08:58:25.67

つまらん言い争いする前にとっとと Rust Book最新版翻訳して、好きな方の用語に統一しとけ。

最新版の翻訳も無いのに日本語和訳とかゴミみたいな話しても無駄だろ。

**デフォルトの名無しさん** · 2025/04/06(日) 14:12:55.00

無駄は利益でも損失でもない
つまり有益でも有害でもない

**デフォルトの名無しさん** · 2025/04/06(日) 14:48:28.98

ゴミ翻訳が何万人ものユーザーに悪影響を与えてるんだから単なる無駄どころかガチ害悪