Rust part27

**デフォルトの名無しさん** · 2024/12/02(月) 22:32:50.31

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

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

**デフォルトの名無しさん** · 2025/03/14(金) 15:34:58.04

circleじゃなくてdiskの方に適用可能範囲があるから、境界を印象付けてもしょうがない
範囲や領域って言えばいい

**デフォルトの名無しさん** · 2025/03/14(金) 15:53:13.20

>>472
Java語は要らんのだよ

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

清々しいまでにバカばっかだなwww

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

>>471
>わざわざBoundsと言ってる意味を考えてみてはどうか
そのセリフそっくりそのまま返すわ
本当に英語ネイティブなら日本語の「境界」の意味を知らんのだろうな

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

>>472
>限界とか条件ならbounds じゃなくてlimitationだしな
boundsをそのまま表現できる日本語の二字熟語は存在しないから完璧な訳語というのはない
完全な誤訳というのはあるけれども

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

>>475
おいおいｗｗ
bound forのboundとtrait boundsのboundはスペルが同じだけで意味も語源も違う単語だぞ
何が「bound 境界」と「for 方向(対象までの間が主眼)」の組み合わせてそういう意味になるだよ
不適切にもほどがあるかど。

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

束縛を誤用してる言語なんだから

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

inboundももちろんbound forのboundと同じでtrait boundsのboundとは関係ないからな

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

>>476
>circleじゃなくてdiskの方に適用可能範囲があるから、境界を印象付けてもしょうがない
これこれ

**デフォルトの名無しさん** · 2025/03/14(金) 18:07:08.47

他動詞なんだからしゃーない日本語にはその概念が未導入だ
この例を見てくれよ

developers.google.com/maps/documentation/javascript/examples/control-bounds-restriction

ニュージーランドの国境座標で境界固定されてる
Restricting Map Bounds

const NEW_ZEALAND_BOUNDS = {
north: -34.36,
south: -47.35,
west: 166.28,
east: -175.81,
};

Rustじゃなくてタイプスクリプトだがboundって俺らプログラマーは普通にコーティングするとき使ってるから。意味もわからずニュアンスだけ知ってりゃコーティングミスしないよ

**デフォルトの名無しさん** · 2025/03/14(金) 19:03:43.60

>>485
>他動詞なんだからしゃーない日本語にはその概念が未導入だ
よく意味がわからないんだがなんで他動詞だとしゃーないの？
未導入の概念というのはBoundsのこと？

ちなみにその例にあるBoundsは名詞

**デフォルトの名無しさん** · 2025/03/14(金) 22:14:58.94

>>485
2D描画の文脈で使われるboundsは基本的に矩形領域のこと(3Dなら直方体の領域)
trait boundsと同じように何かを制限する範囲/領域という原義から付けられた名前だがもし「境界」と訳されてるとしたらの機械翻訳の質の問題だろう

**デフォルトの名無しさん** · 2025/03/14(金) 22:53:00.25

>>470
オライリー「トレイト制約やで」

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

要するに機械翻訳を誤訳と気づかず採用したんだろ
プロの翻訳家は誤訳に気づいて修正したが間違いを認めたくない勢力が境界で違和感ないと言い張ってるわけだ

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

BoundsChecker って最近見かけなくなったな

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

boundsは境界で正しい
他の候補はない

Type1: Trait2　Type1の取れうる型のうちTrait2がその境界となっている
Trait3: Trait4　Trait3の…(同様)
つまりトレイトにより境界を引いている

このように各々意味が異なる
境界　bounds
限界　limitation
制約　constraints

他の例
array-bounds checking　配列境界検査
Scalaのupper type bounds　上限境界
Scalaのlower type bounds　下限境界

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

際立ちますね
この題材は踏み絵になる

**デフォルトの名無しさん** · 2025/03/15(土) 00:33:27.71

boundというと結び付いてる・紐付いているといった意味合い
日本語で境界というと、外と内といった「堺目」という意味合いが強い
自分はトレイト境界という表現に慣れてしまったのでそこまで違和感はないけど、訳としては不適当だと思う

余談だけどPythonとRustのFFIに使われるPyO3というクレートがあって、そこでは Bound という型が出てくる
これはPythonのGILに紐付いている意味合いで、trait boundのboundと同じ意味合い

**デフォルトの名無しさん** · 2025/03/15(土) 00:51:34.13

「訳がおかしい」と言ってるアホ達が代案を出さないことからも境界がぴったりな言葉
トレイトで境界を引いている

**デフォルトの名無しさん** · 2025/03/15(土) 00:56:44.33

まずこのスレから「トレイト制約」で通しましょう

オライリー「トレイト制約やで」> >>494
>>492同志「際立ちますね」> >>494

**デフォルトの名無しさん** · 2025/03/15(土) 01:20:52.90

boundsに制約なんて意味はない
trait boundsも、ある一定内の数値や、配列のインデックスなどのbounds checkingと同じく境界が定まる

**デフォルトの名無しさん** · 2025/03/15(土) 01:23:20.85

訳語を探すそもそものアプローチというか考え方が間違ってるんだよな

**デフォルトの名無しさん** · 2025/03/15(土) 01:27:28.34

お前らそんなに和訳やる気あんならtatsuya6502のケツひっぱたいてこいや

**デフォルトの名無しさん** · 2025/03/15(土) 01:40:23.59

「制約」という違和感ありまくりの間違った単語を使っているアホどもは、
例えばあるクラスに対してその基底クラスやスーパークラスを「制約」だと捉えているのか？

**デフォルトの名無しさん** · 2025/03/15(土) 01:47:56.77

意味的にはNapsterの水平線に近い

**デフォルトの名無しさん** · 2025/03/15(土) 01:58:38.26

トレイト境界とかいう和製英語やめて特性規定(特性を持ってますよって規定な)とかにしようや。省略しないなら特性保持規定、特性保有規定
ジェネリック型がある特性を持つという規定があるから、その特性を実装するっていう文なら自然だし

**デフォルトの名無しさん** · 2025/03/15(土) 01:59:20.63

しまった、ジェネリックなって書いてしもうたな

**デフォルトの名無しさん** · 2025/03/15(土) 01:59:55.45

>>489
プロポですねわかります

**デフォルトの名無しさん** · 2025/03/15(土) 02:11:53.31

>>501
boundsに規定なんて意味はない
trait boundsはそのトレイトによって定まるトレイト境界だ

**デフォルトの名無しさん** · 2025/03/15(土) 02:27:02.81

集合論的な意味での境界だな
ベン図のイメージ

T: EqはEqを実装する型の領域
T: CopyはCopyを実装する型の領域
T: Eq + CopyはT: EqとT: Copyが重なった領域

**デフォルトの名無しさん** · 2025/03/15(土) 06:28:21.70

>>495
「制約」という単語は真逆の意味だから使ってはいけない
制約ではなく境界を引くことで能力を与えて強力になっていく視点がトレイト境界

>>505
その通り
where句がない場合
<T>　←(Anyしか)何もできない子
<T: Eq>　←Eqを使える子
<T: Copy>　←Copyを使える子
<T: Eq + Copy>　←EqもCopyも使える子
つまりEq + CopyでEqの境界とCopyの境界の両方を満たす境界が引かれる
そしてどんどん使える機能が強化されていく
つまり「制約」とは真逆のイメージなので「制約」という表現は全く合わない
トレイト境界という表現が正しい

**デフォルトの名無しさん** · 2025/03/15(土) 09:13:26.13

数学だと制約に相当するんでは？
三角形の内二等辺三角形があるのは条件を満たしているものだけ

プログラムも機能が充実するとイメージとは真逆で制約が強くなっていることになる
出来ることが増える=制約されてる
void*ポインターが無制限で型が付くと型の制限がある

**デフォルトの名無しさん** · 2025/03/15(土) 09:15:25.47

これはずっと考えていたことで今急にひらめいたとかじゃない

**デフォルトの名無しさん** · 2025/03/15(土) 09:16:05.70

>>495
一般的に constraints の訳語として「制約」をあてるのでこの場合には好ましいとは言えない。
ただ Haskell で constraints と呼んでいるものと Rust で bounds と呼んでいるものに類似点があるかというとまあ結構あるとは思う。

**デフォルトの名無しさん** · 2025/03/15(土) 09:23:16.52

二つの辺の長さが等しいと言う制約のと
○○という関数を持っていると言う制約

**デフォルトの名無しさん** · 2025/03/15(土) 09:24:31.14

>>494
ブランチを切るで暴れてた人ですねわかります

>>501
そんな理由だったら単に「定格」でいいわ

**デフォルトの名無しさん** · 2025/03/15(土) 09:31:26.54

カタカナでいいんじゃないかｗ
英語見た場合に納得できる

**デフォルトの名無しさん** · 2025/03/15(土) 09:43:00.89

こういう時は何故かHaskell = 圏論勢が出てこない

**デフォルトの名無しさん** · 2025/03/15(土) 09:44:01.84

>>506
英語版の Rust book だと「型やライフタイムの使われ方を制限する (to restrict) 」とあるよ

Trait and lifetime bounds provide a way for generic items to restrict which types and lifetimes are used as their parameters.

数学とかプログラミングと関係ない、普通の言葉としての bound は元は「紐で縛る」から来てる
制限、制約、境界といった意味はそこからの派生

**デフォルトの名無しさん** · 2025/03/15(土) 09:53:00.21

そもそも >>506 だって制約だと思う
ジェネリクス関数の中で呼べるメソッドが増えることに注目してるようだけど、利用側から見ればその関数に渡せる型について制限が増えるでしょ

**デフォルトの名無しさん** · 2025/03/15(土) 10:02:10.90

>>515
それはおかしい
トレイト境界の対象は型
最も制約の多いAny状態を出発点として
トレイト境界を増やせば増やすほど型が機能できる自由度が増えていく

**デフォルトの名無しさん** · 2025/03/15(土) 10:28:22.62

>>516
逆
三角形が二等辺三角形のみに限定されて自由度が増えてると思うか？

これが制約だと思えない人は数学的な素養がない

**デフォルトの名無しさん** · 2025/03/15(土) 10:35:19.38

>>506
トレイト視界にすれば良かったんじゃね

**デフォルトの名無しさん** · 2025/03/15(土) 10:37:07.82

トレイトバウンズでええやん

**デフォルトの名無しさん** · 2025/03/15(土) 10:38:12.12

機能実装=制約
情報量が少ないのが自由度が大きくなりがち

確率だとしても明日の天気の状況が全くわからないとすると何の制約もなく平等に各状態がある
天気予報などから明日は降水確率70%などと情報を得ると確率がかわり偏る

情報学で言うエントロピーが増大した状況
ビットの0と1が等しい確率で出てくるような何ら情報の無い状況がエントロピーが少ない

**デフォルトの名無しさん** · 2025/03/15(土) 10:42:25.48

>>516
void * はなんでも渡せるが逆は出来ない
trait もそうで増やせば増やすほど渡せるものが制約されていく

**デフォルトの名無しさん** · 2025/03/15(土) 10:43:38.21

>>517
用語にいちいち反対している人は
AIに質問して還って来た答えを
ここにコピペしてるような臭いがする

**デフォルトの名無しさん** · 2025/03/15(土) 10:50:01.91

>>521
それは真逆の視点だから真逆の結果となっている
型に対するトレイト境界なのだから型の視点で見るべき
トレイト境界がAnyしかない初期状態が最も制約されていて機能がほとんど使えない不自由な状態
そこからトレイト境界を増やせば増やすほど実行できる機能が増えて自由度が増していく

**デフォルトの名無しさん** · 2025/03/15(土) 10:51:10.99

自由度なんて何も考えなくても理解出来るだろ…
思い込みを直す機会だぞ
なんなら大学に行って数学と情報学を学べばいい

**デフォルトの名無しさん** · 2025/03/15(土) 10:52:21.41

>>522
「トレイト境界」という状況を最も的確に表していて正しい訳に対して
なぜ反対しているのか？

**デフォルトの名無しさん** · 2025/03/15(土) 10:54:27.10

>>524
CSを学ぶべきは君だろ
「トレイト制約」派は本質を理解できていないから「制約」なんて間違った用語を用いてしまう

**デフォルトの名無しさん** · 2025/03/15(土) 11:00:14.62

>>526
学生と言うクラスに対してそれが三角形なのかと言う問いはおかしく見えるが
学生であり三角形でもある可能性もある

トレイトが実装されていなくても同等の機能が実装されている可能性もある
一概にトレイトが実装されているから高機能であると言う論は当てはまらない

ある機能を使う場合に対象となるものがトレイトを実装されているものに限定されているだけ
これはただの制約でしかない

**デフォルトの名無しさん** · 2025/03/15(土) 11:03:33.75

トレイト境界　トレイト制約　トレイト要求　トレイト条件　トレイト限定

whereでトレイトを限定しているので指定の自由度は低くなっている

**デフォルトの名無しさん** · 2025/03/15(土) 11:10:08.04

>>527
プログラムを書いたことないのかな？
impl Display for T した時にそれはDisplay機能を追加したのであって制約したわけではない
fn foo<T: Display>() した時もそれはDisplay機能を追加したのであって制約したわけではない
もちろん逆の視点で見れば制約になるのは当たり前だが逆の視点で見る必要がない
普通の視点ではDisplay機能が増えて利便性が上がったと解釈する
その機能を持つ線引きとしてトレイト境界がある
これをトレイト制約と訳すのは違和感ありまくりの間違いだ

**デフォルトの名無しさん** · 2025/03/15(土) 11:11:57.53

>>528
わざと逆方向の視点で語ってるだろ
まともな視点では使える機能が増えている
制約ではない

**デフォルトの名無しさん** · 2025/03/15(土) 11:15:38.63

>>529
トレイト境界について話をしてるんだけど？わかってるか？

トレイト境界は制限でありある種の束縛である

**デフォルトの名無しさん** · 2025/03/15(土) 11:16:16.66

>>530
わざと馬鹿な振りしてるのか？普通に馬鹿なのかどっちなんだ？

**デフォルトの名無しさん** · 2025/03/15(土) 11:19:12.75

トレイト境界　訳語でぐぐったら出来たぞ
https://github.com/rust-lang-ja/book-ja/issues/172

＞　その型がとりうる値を制限し、より具体的な型を定義する

制約を含んでいる

**デフォルトの名無しさん** · 2025/03/15(土) 11:21:18.09

>>531
真逆の視点で見れば制約と解釈できるのは当たり前
しかしそんなバカな視点持つ人はいない
デフォルトとAnyトレイトしか使えない不便で制約が最大の状態から
各トレイト境界により各トレイト機能を使えるように制限を解放していくのがトレイト境界のプログラミングほ本質
「トレイト制約」派は頭がおかしい

**デフォルトの名無しさん** · 2025/03/15(土) 11:23:51.41

>>534
相手に対して決めつけたベン図的な考えをしてるのが間違い
自分はトレイト制約にしろとはいってない

ただトレイト境界は制限を含んだものだと言ってる
自由度が低くなると言っている

トレイト境界で自由度が高くなると言うポンコツと意見が対立するのは当たり前

**デフォルトの名無しさん** · 2025/03/15(土) 11:26:39.91

学生であり三角形の可能性としては

名前が　三角　形さんである場合が当てはまる
その人は学生であり三角形

**デフォルトの名無しさん** · 2025/03/15(土) 11:28:48.27

>>498
これに触れちゃったから真っ赤になっちゃってるね

**デフォルトの名無しさん** · 2025/03/15(土) 11:32:47.50

>>534
もしかして impl X for Foo のように「トレイトを実装する」ことを trait bound と思ってる？
trait bound は「この関数に渡せる型Tは〇〇を満たさなければならない」の意味だよ？
Tとしか書かれてないジェネリクス関数は文字通り「何でも渡せる」から、これが一番制約が少ない

**デフォルトの名無しさん** · 2025/03/15(土) 11:34:15.16

>>535
何度言っても理解しようとしないやつだな
非現実的な視点としてそこでは使わない非該当な型からみれば、その型は使えないのだから制限となるのは当たり前だ
そんなプログラミングとかけ離れた非現実的な視点でみるのはおかしい
プログラミングの視点では各トレイト境界を増やすことでその関数でできることが増えて制限から解放される

**デフォルトの名無しさん** · 2025/03/15(土) 11:40:22.78

>>538
その真逆な視点から見れば制約になるのはの当たり前だとずっと言ってるだろ
どちらを制約と捉えるかの問題
Anyしか何もできない<T>が最も制約されている状況
それに対して<T: Trait>とトレイト境界を課すことで制約がなくなって使える機能が増えていく

**デフォルトの名無しさん** · 2025/03/15(土) 11:41:12.38

>>539
トレイト境界に対しては真逆だろ

プログラミングの視点で見てもトレイト境界を増やすことで制限が増えて対象への制約が増える
実装でトレイトにあたる部分を使用しているかどうかはどうであれ自由度が減る
こんな当たり前のことすら理解できないのか？

**デフォルトの名無しさん** · 2025/03/15(土) 11:43:24.52

あえて造語すれば機能域とかになるのかな
制約とか機能が増えるとかは視点によって出てくる結果だろう

**デフォルトの名無しさん** · 2025/03/15(土) 11:46:45.42

>>541
その180度逆の視点で見れば制約になるのは当たり前だがそんな視点でプログラミングは行われない
「トレイト境界」により「制約された」とは考えることはなく
「(制限されてる状態から)使える機能が増えた」と考える

**デフォルトの名無しさん** · 2025/03/15(土) 11:50:54.00

>>542
その通り
視点によって両方が起こる
だからそこ「トレイト制約」ではなく「トレイト境界」が正しい
各トレイト境界により線引きされて境界が定まるだけ
それにより使える機能が増えて便利になることがプログラミングの本質
制約されて不便になったとは考えない

**デフォルトの名無しさん** · 2025/03/15(土) 11:54:54.99

>>543
脱線になるが自由度の意味が判ってない

三角形なら基礎的なルール（三つの角度を合わせると180度など）守っていれば辺の長さや角度は自由に設定できる　自由度が高い
二等辺三角形は二辺の長さが同じと言う制約がありその他にも角度が制限される　自由度が低い

二等辺三角形は自由度が低いがそのために角度などを利用して他の隣接した線分などとの角度が確定できるようになる
自由度は減っているが他から見ると利用価値がただの三角形から上がってる

**デフォルトの名無しさん** · 2025/03/15(土) 11:57:50.75

制限なしの型パラメータを制限してるだけでしょ

<T>　←制限ナシ
<T: Eq>　←Eqで制限
<T: Copy>　←Copyで制限
<T: Eq + Copy>　←Eq+Copyで制限

制約って言ってる人の感覚のほうが俺も近い
（型パラメータの型を）制約ってことでしょ

> 使える機能が増えて便利になることがプログラミングの本質

そんな主張生まれて初めて目にしたわ正直ｗ

**デフォルトの名無しさん** · 2025/03/15(土) 12:03:05.22

自由度すら理解できないなんて
この人いつもの長文でおかしなRust擁護書いてる人かな？

**デフォルトの名無しさん** · 2025/03/15(土) 12:04:44.44

>>546
その真逆の不自然な視点を取ることももちろん可能だが
普通はこちらの視点

<T>　←(Any以外)何もできず制限最大
<T: Eq>　←Eqが使えるようになる
<T: Copy>　←Copyが使えるようになる
<T: Eq + Copy>　←EqもCopyも使えるようになる

制約を増やしているのではなく
機能を増やしている
だからトレイト制約なんていうバカな呼び方を採用しない

**デフォルトの名無しさん** · 2025/03/15(土) 12:07:05.48

>>523
そう思うならトレイト視界を使ってくれ

**デフォルトの名無しさん** · 2025/03/15(土) 12:10:13.35

>>547
偏った片方の視点でしか見れない可哀想な人だな
まずは視点を変えることで2つの真逆な見方があるという当たり前のことを理解しようね

**デフォルトの名無しさん** · 2025/03/15(土) 12:10:26.25

型を制限してるんよね
機能がどうのこうのの以前にね
これって理解するの難しいのかなあ

**デフォルトの名無しさん** · 2025/03/15(土) 12:13:27.59

>>549
トレイト視界なんて意味不明
トレイト境界を増やしていくことでその型の使える機能が増えていく
そこで各々のトレイトに境界という線引がある

**デフォルトの名無しさん** · 2025/03/15(土) 12:16:19.89

>>551
そんな当たり前のことはわかってると何度も伝えてるだろ
その片方の視点でしか考えられない狭い考えの人が「トレイト制約」という間違った用語にこだわっている

**デフォルトの名無しさん** · 2025/03/15(土) 12:16:42.56

>>548

vec<T>
vec<T>:where T Eq
vec<T>:where T:Copy
vec<T>:where Eq + Copy

自由度が高いvecはどれ？トレイト境界で自由度が増えるなんて馬鹿はいない

**デフォルトの名無しさん** · 2025/03/15(土) 12:23:05.50

>>554
二つの視点を理解できた？
さらにその問題ならVecの視点とTの視点でさらに二つ分かれる
もちろんトレイト境界はTに対するものだからTの視点が普通人の視点
トレイト境界が何もなければTに対して何もできないから一番不自由な状態

**デフォルトの名無しさん** · 2025/03/15(土) 12:24:50.62

「自己責任」の語源という噂もあるIT界隈ってやっぱ最先端なんだな
自由と制約
性善説と性悪説
なんでもITで定義できる

**デフォルトの名無しさん** · 2025/03/15(土) 12:24:54.00

<T: Eq>で考えたとき
「: Eq」はどこにかかってんのか？
「T」でしょ、それ以外ではないでしょ？
で「T]は何かっていうと型でしょ？

この話のどこに「機能」とやらが出てきたの？
片方の視点もなにも、そもそもの話が

**デフォルトの名無しさん** · 2025/03/15(土) 12:25:47.49

まだ自由度すら理解できないんだよな
文系プログラマの末路が見える

**デフォルトの名無しさん** · 2025/03/15(土) 12:30:10.54

「俺の解釈」でなくちゃんと公式の説明を読もう
https://doc.rust-lang.org/reference/trait-bounds.html

**デフォルトの名無しさん** · 2025/03/15(土) 12:32:15.55

>>557
各トレイトは各々の特性という機能を宣言している
Tという型が何をすることができるものかをトレイト境界で指定していく

ちなみに何度も言っているが
Tという抽象型自体の視点ではなくて、Tに入りうる具体型候補の集合という裏の視点で見れば、トレイト境界が制約になることはもちろん理解している
そんな偏った視点で考えるのはおかしいと主張しているだけ
だから「トレイト制約」というアホな用語は絶対に許容しない

**デフォルトの名無しさん** · 2025/03/15(土) 12:34:54.10

文系が誤魔化しに来ている

**デフォルトの名無しさん** · 2025/03/15(土) 12:35:11.48

>>559
恥ずかしながらそれ読んだことなかったｗ

> Trait and lifetime bounds provide a way for generic items to restrict which types and lifetimes are used as their parameters.
> 特性と有効期間の境界は、汎用アイテムがパラメータとして使用される型と有効期間を制限する方法を提供します

はいこれ
型を制限なのです

**デフォルトの名無しさん** · 2025/03/15(土) 12:41:26.07

>>560
>>506
> 「制約」という単語は真逆の意味だから使ってはいけない

**デフォルトの名無しさん** · 2025/03/15(土) 12:41:44.05

言った通りだろ
T自体ではなくTに入りうる具体型候補の集合で考えればもちろん制限になる

**デフォルトの名無しさん** · 2025/03/15(土) 12:43:19.33

>>563
その通り
トレイト制約という不自然な用語を採用するつもりは絶対ない

**デフォルトの名無しさん** · 2025/03/15(土) 12:50:29.91

トレイト境界　機能：型を制約します

その一方で
「トレイト制約は不自然だ～」
これは無いな

**デフォルトの名無しさん** · 2025/03/15(土) 12:58:39.76

>>566
まだ二つの視点を理解できないのかね？
トレイト境界は
機能を強化する側面と
具体型候補を制限する側面がある
互いに裏返しでどちらも正しい
その線引をしているから境界

**デフォルトの名無しさん** · 2025/03/15(土) 13:09:12.24

>>567
bound が「線引き」だとして、例えばRustコンパイラが出す以下のメッセージはどう訳すの？
Error: the trait bound is not satisfied
「制約を満たさない」からエラー、という方が自然じゃない？

**デフォルトの名無しさん** · 2025/03/15(土) 13:22:26.55

>>568
文字通りにトレイト境界を満たさないだよ
例えば具体的に Error: the trait bound 'TypeA: TraitB' is not satisfied と指摘される
つまりこのトレイト境界を満たさないとは
TypeAはTraitB(の機能)を実装していない、という意味

**デフォルトの名無しさん** · 2025/03/15(土) 13:23:13.31

「トレイト境界」という言葉が既に用語として認識されている感はあるし、「トレイト境界を満たさない」と書いても実用上は伝わると思うけど
「境界線を満たす」のように、satisfyの目的語が線になることはないと思う

**デフォルトの名無しさん** · 2025/03/15(土) 13:24:22.65

トレイトも日本語に訳した方がいいよね

**デフォルトの名無しさん** · 2025/03/15(土) 13:26:47.33

>>570
線だとは誰も言っていない
線引をして境界を構成しているわけなので、線ではなく境界
だからトレイト境界(trait bound(s))という用語が英語でも日本語でも正しい

**デフォルトの名無しさん** · 2025/03/15(土) 13:28:22.19

imple S {}
を全面的に禁止して
imple T for S {}
だけしか使えない環境にするべきだったね

**デフォルトの名無しさん** · 2025/03/15(土) 13:35:57.03

>>571
クラスもインターフェイスもトレイトもそのままが良いと思う

>>573
トレイトは異なる型の共通機能に対して共通処理をしてコードの共通化をするためにある
そのコード共通化で必要となる共通機能をトレイト境界として列挙する
各型の独自の機能についてトレイトを設ける必要はない

**デフォルトの名無しさん** · 2025/03/15(土) 13:38:34.38

>>572
>>567 の最後の行で (trait bound は) 「線引きをしている」と主張してない？

**デフォルトの名無しさん** · 2025/03/15(土) 13:43:15.55

>>575
線引をして境界が構成されるんだよ
だからトレイト境界と呼ぶ