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/02(水) 20:00:01.91

まだ訳の問題だと思っているのか

**デフォルトの名無しさん** · 2025/04/02(水) 20:36:53.45

制約で決まったみたいだね

**デフォルトの名無しさん** · 2025/04/02(水) 21:03:24.67

『ゼロから学ぶRust』という書籍だとトレイト制約だな
訳なんだから複数あることはあり得るし、それ以上でもそれ以下でもない

**デフォルトの名無しさん** · 2025/04/02(水) 21:24:12.08

まぁ自分の思う訳語を広めたいんなら本を書いたり記事を書いたりすればいいのであって
このスレでレスバして決めるようなことではないよな

**デフォルトの名無しさん** · 2025/04/02(水) 21:33:29.51

トレイト制約境界にしよう

**デフォルトの名無しさん** · 2025/04/02(水) 21:56:50.54

まぁオライリーからして制約なんでしょそもそも

**デフォルトの名無しさん** · 2025/04/02(水) 22:06:25.87

オライリーも質が落ちたな

**デフォルトの名無しさん** · 2025/04/02(水) 22:25:27.67

境界信者　　　　：「boundsに制約の意味はない！」
公式リファレンス：「boundsとは型もしくはトレイトに対する制約のことです」

境界信者　　　　：「制約という単語は真逆の意味だから使ってはいけない」
公式リファレンス：「boundsとは型もしくはトレイトに対する制約のことです」

境界信者　　　　：「トレイト制約派は本質を理解できていないから制約なんて間違った用語を用いてしまう」
公式リファレンス：「boundsとは型もしくはトレイトに対する制約のことです」

ｗｗｗ

**デフォルトの名無しさん** · 2025/04/02(水) 22:47:40.00

>>199
そこだよな
少なくとも制約と訳すとおかしくなる

>>207
そこでboundsを制約と訳すと意味のわからない日本語になってしまう
「制約とは型もしくはトレイトに対する制約のことです」

**デフォルトの名無しさん** · 2025/04/02(水) 23:07:01.46

そもそも特定の文脈においてしか「境界」と訳してはいけない単語なのにそれを知らずに誤訳をしてしまったのが間違いの始まり

その後繰り返し指摘があり何度も見直す機会があったにも関わらず自分の誤った判断を修正したくないばかりに「境界」に執着して日本のRustコミュニティの足を引っ張った罪は重い

**デフォルトの名無しさん** · 2025/04/02(水) 23:08:32.45

boundsの訳語を制約としてはいけない理由がようやくわかった

**デフォルトの名無しさん** · 2025/04/02(水) 23:10:03.40

X=X (XはXである) という等式は無意味だとか意味不明だとかいう批判は日本語限定じゃなくて普遍的な話題だ

**デフォルトの名無しさん** · 2025/04/02(水) 23:13:35.48

「制約とは型もしくはトレイトに対する制約のことです」
となり破綻する
だから英語でもboundsとconstraintを使い分けているのだ

**デフォルトの名無しさん** · 2025/04/02(水) 23:22:33.90

美味しんぼ「冬のアラは最高たい！」

※ここでのアラはクエのことです

**デフォルトの名無しさん** · 2025/04/02(水) 23:26:13.72

boundsの訳語を制約としてはいけない理由はわかったけど
boundsの訳語を何にすると良いのかな

**デフォルトの名無しさん** · 2025/04/02(水) 23:52:15.22

境界信者：「boundsに制約の意味はない」
境界信者：「trait boundsが何かを制約することはない」
境界信者：「制約の視点で見るやつは本質を理解してない」
(公式リファレンスが指摘されると)
境界信者：「境界は制約である」

ｗｗｗ

**デフォルトの名無しさん** · 2025/04/02(水) 23:53:09.75

「トレイト制約とは、ジェネリクスとして受け入れる型をトレイトにより制限する機能です」
とでも書けばいいんじゃないの

単語の繰り返しを避けるのは文章表現の問題であって、それらが理屈の上で異なるものという意味ではない
特に英語だと、同じ単語を避けるための言い換えをよく使う

**デフォルトの名無しさん** · 2025/04/02(水) 23:59:24.49

>>216
それは本質を理解できておらず失格
trait boundsは機能ではない
traitのカヴァーする領域を示している
それが型に対する制約となる
したがってtrait boundsをトレイト制約と訳すのは理解できていない証拠

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

いつまで日本語喋ってんだよ

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

>>215
やめたれｗ

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

他のもので例えるとわかりやすい
「人間は哺乳類である」
これは確かに正しいが人間と哺乳類は意味が異なる
人間と言うべきところで哺乳類と言うのは間違い

「boundsは制約(constraint)である」
これは確かに正しいがboundsと制約(constraint)は意味が異なる
boundsと言うべきところで制約と言うのは間違い

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

「制約は制約である」という文は数学的には全く問題ないのだ
でも工学的あるいは商業的には、役に立たない（気がする）文は過度に問題視される

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

人間は哺乳類である
哺乳類は生物である
いずれも正しいが意味が明確に異なる

boundsはconstraintである
これも同様に両者は意味が明確に異なる
だからわざわざ別の単語を用いている
両者を共に同じ「制約」と訳すのは頭が弱い人であると断言できる

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

>>221
なんと進次郎構文だ

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

>>223
詐欺にも誹謗中傷にもならない、比較的安全な構文だ

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

Trait制約と言ってる人は理解が足りていない

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

文脈を無視して対訳表だけで機械的に翻訳しようとするからゴミ翻訳ができあがる
それも指摘されたそばからやってるんだから始末に終えない

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

Trait BoundsやLifetime BoundsなどでのBoundsは一般名詞ではなくて専門用語として位置付けられてるよ
だからBoundsの日本語訳も常に一貫して同一の訳を当てないといけない
そして使われ方の意味合いがconstraint (制約)とは異なるため少なくとも「制約」とは異なる訳を当てないといけないね

**デフォルトの名無しさん** · 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境界がベン図的であると言うのはただの勘違いである