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(木) 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

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

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

でも、あなたの影響は0だった

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

>>320
すげーまともだな

**デフォルトの名無しさん** · 2025/04/07(月) 17:37:54.88

Trait制約では意味が全く違う

**デフォルトの名無しさん** · 2025/04/07(月) 17:41:13.06

Javaのインターフェイス程度の代物にそんあ小難しい概念いらんけどな

**デフォルトの名無しさん** · 2025/04/07(月) 17:42:09.21

「トレイト制約」が正しい！

**デフォルトの名無しさん** · 2025/04/07(月) 18:06:19.68

Trait boundsが正解
無理に日本語にすんな

**デフォルトの名無しさん** · 2025/04/07(月) 18:31:33.33

>>330
どう意味が違うの？

**デフォルトの名無しさん** · 2025/04/07(月) 22:20:40.10

ジェネリクスは小難しいから普及が遅かった
Javaのインターフェースはそれ自体はジェネリクス普及前からあった
Javaのインターフェースはそれ自体はジェネリクス引数の制約ではない

ここで重要なのは、主語を変えても同じことが言えるなどといった保証はないってことだ

**デフォルトの名無しさん** · 2025/04/07(月) 23:52:56.67

ジェネリクスはAda発祥やで

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

CLUやろ

**デフォルトの名無しさん** · 2025/04/08(火) 10:44:56.88

Java界隈も「境界」という訳の異常性に気付いて徐々に避けるようになってる

**デフォルトの名無しさん** · 2025/04/08(火) 14:07:35.74

制約とか言ってる低能

**デフォルトの名無しさん** · 2025/04/08(火) 14:17:58.70

traitも日本語訳すべきだろ
大陸中国語では「特質」と訳してるらしい
ただし漢字は簡体字で

**デフォルトの名無しさん** · 2025/04/08(火) 14:31:57.06

特質系とか漫画の読みすぎかよ
漫画の語彙を訳に使うのあるかもしれん
無量空所

**デフォルトの名無しさん** · 2025/04/08(火) 15:12:55.89

boundが”trait bounds”のような名詞のでしか出てこないのであれば”トレイトバウンド”で十分なんだが動詞としてもその過去分詞が形容詞としても使われるから意味の通じる日本語にする必要はあるだろうな

**デフォルトの名無しさん** · 2025/04/08(火) 15:13:35.03

君らの議論見てると日本語と英語の意味が完全には一致してないからもめてるんだろ
適切な言葉が日本語にないのなら原語そのまま使えよ
どうしても日本語にしたけりゃ新語つくっちゃえよ、トレイト制界とかトレイト境約とか

**デフォルトの名無しさん** · 2025/04/08(火) 15:25:59.18

完全には一致してないではなくて
境界は完全に間違ってるからな

**デフォルトの名無しさん** · 2025/04/08(火) 15:32:05.13

ワッチョイつけようぜ

**デフォルトの名無しさん** · 2025/04/08(火) 15:32:48.21

10人中8～9人がおおよその意味を想像できるような新語ならともかく想像できないような新語なら訳さないほうがよっぽどマシ

**デフォルトの名無しさん** · 2025/04/08(火) 15:37:41.98

トレイト境界(trait bounds)のboundsは境界・領域・範囲などどれでもいいんだけど、
境界はもちろん二次的な意味の二者間の意味ではなく単独の意味の方で、
どうしても二者間に固執したい人なら内と外の二者間の境界と考えて。

**デフォルトの名無しさん** · 2025/04/08(火) 15:47:16.64

なんでもいいというのが一番困る、という寓話があるが、その寓話には名前がない

**デフォルトの名無しさん** · 2025/04/08(火) 15:59:24.30

題名も何でもいいからか

**デフォルトの名無しさん** · 2025/04/08(火) 16:48:31.19

道？

**デフォルトの名無しさん** · 2025/04/08(火) 17:08:27.56

トレイト執着

**デフォルトの名無しさん** · 2025/04/08(火) 17:19:56.75

粘着やな

**デフォルトの名無しさん** · 2025/04/08(火) 17:56:08.61

>>254-257
現象的にメンバの方のdropが先に呼ばれて
最後に自分のdropが呼ばれているようなのですが
これって仕様？

**デフォルトの名無しさん** · 2025/04/08(火) 20:49:57.66

>>353
Drop::drop()が呼ばれるのは親が先で子が後になるけど、
実際のptr::drop_in_place()が自動で呼ばれるのはもちろん子の処理を終えた後に親が後になる。
そのため安全に全自動で任せつつ、子の処理の前に親がやっておきたいdrop以外の前処理だけを親のDrop::drop()に書くことができる。
複数の子どもの処理の順序や自動の有無も含めて制御したい時はManuallyDropをつかう。

**デフォルトの名無しさん** · 2025/04/08(火) 21:53:23.33

The impl Trait syntax ... is actually syntax sugar for a longer form known as a trait bound

構文糖じゃない方のトレイト
実際のトレイト

**デフォルトの名無しさん** · 2025/04/09(水) 12:19:06.96

トレイト制約などといってる輩は全く理解できていないと自白してるようなもの

**デフォルトの名無しさん** · 2025/04/09(水) 15:01:13.51

糖質境界

**デフォルトの名無しさん** · 2025/04/09(水) 18:04:17.50

もうちょっと正義感が強かったら
べつにカジノ経営者が自白しなくても、カジノは特殊詐欺とほぼ同じというのは確定事項として扱えるようになる

**デフォルトの名無しさん** · 2025/04/09(水) 18:54:36.47

三店制約

**デフォルトの名無しさん** · 2025/04/09(水) 18:55:51.86

パチ屋

**デフォルトの名無しさん** · 2025/04/09(水) 19:16:50.12

インターフェース統一協会

**デフォルトの名無しさん** · 2025/04/09(水) 19:33:46.61

言語仕様らしきものに忠誠心を示すのはわかるけど
誤訳された用語にすら全面的に支持して従うってどういうことなの？