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/12(水) 21:01:47.70

>>428
一番重要な独自の分類方法を最初にまとめて書かないからクソ記事になる

**デフォルトの名無しさん** · 2025/03/12(水) 21:52:39.29

>>430
>クロージャの引数は、毎回変わるのだから常に何をしても自由であり

なるほど。言われてみれば納得。
ありがとう

**デフォルトの名無しさん** · 2025/03/13(木) 02:14:17.95

なんでtypescriptのソースをrustに移植できないの？
プログラムなんだから不可能ってことはないでしょ？

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

>>433
出来ることと効果的に出来ることは別というシンプルな話。

**デフォルトの名無しさん** · 2025/03/13(木) 07:14:12.10

TypeScriptのコンパイラはその利用の多さからもっと高速さを狙ってC/C++・Rust・ZigなどのGC非依存言語で書く価値がありブラウザ上Wasm実行の観点からもそうすべきだったが
担当者の能力不足のため遅いGC依存言語から速いGC依存言語へ書き換えるだけで終わってしまった
そのため早くもWasmでの実行が遅いという指摘が出ている

**デフォルトの名無しさん** · 2025/03/13(木) 07:27:03.63

要するに、GC依存症の人にはrustは過ぎた物って事か。

**デフォルトの名無しさん** · 2025/03/13(木) 07:45:56.77

アンダース・ヘルスバーグが能力不足なんて話があるかいな。
Rust や C# が得意なのにあえて Go を選定したんだぞ。
WASM 上で遅いのは WASM のほうの性能不足だ。
Go の優秀さはランタイムサポートの作り込みにあり、それが十全に発揮されない環境ではそりゃ遅い。

**デフォルトの名無しさん** · 2025/03/13(木) 07:53:47.23

Rustで書けばwasmの件も問題なかったわけだからGoという中途半端な言語を選んだ選択ミスだな～

**デフォルトの名無しさん** · 2025/03/13(木) 08:52:01.37

WASM ってそんなに絶対に考慮が必要なほど重要なプラットフォームか？
コンパイラを WASM 上で動かそうとする判断をするやつがいたらそのほうが選択ミスだろ。

TypeScript からの移植という前提があったから Go が比較的やりやすいと判断された。
関数単位でほとんど一対一のベタ移植を出来てる。

**デフォルトの名無しさん** · 2025/03/13(木) 09:41:53.87

GC言語で書かれたプログラムをRustに移植しようとするとプログラムの構造を大幅に変えなきゃいけないからな

まあRustでのプロトタイピングも絶対やってるだろうけど

**デフォルトの名無しさん** · 2025/03/13(木) 09:56:55.03

スパゲッティになってる下手なプログラムは、Rustで書く時にそれをほどいてまともなプログラムにしなきゃいけないもんね
それにより効率改善や機能拡張などの保守性も格段にアップするから、当たり前で必須な作業なんだけど、手間を惜しんだのかね

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

また的外れなことを
普段Rust書いてれば嫌でも分かることなんだけどなぁ

**デフォルトの名無しさん** · 2025/03/13(木) 10:39:22.49

TypeScript で書いてあることの弊害としてランタイム (つまりは JavaScript 実行環境) がウェブ用に最適化されてることを挙げてる。
ウェブのプログラムではリクエストごとのターンアラウンドタイムが重要だが、コンパイラは時間あたりの計算量が重要で、違う戦略が要る。

コードの保守などはとりたてて問題になっていない。
もしより良く出来る余地があったとしても組織としてコストを支払うほどの価値じゃない。

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

Rustの話題だとダンマリなのに
どうでもいい他の言語の話だと連投するヤツいつもいるな

**デフォルトの名無しさん** · 2025/03/13(木) 12:14:30.28

政治や流行に流されない決断ができる土壌があるのは良い組織
動画を見るとヘルスバーグの優秀さがひしひしと伝わってくる
windowsのPMとは大違い

**デフォルトの名無しさん** · 2025/03/13(木) 12:57:02.36

一通りいろんな言語でプロトタイプコンパイラー作ってみたって動画内でも言ってたじゃねーか。で、Goが一番一対一で手堅く移植できる上に十分に速度アップもしたと言うことかと
パランスの問題だよ。時間をかけてリターンがどれだけあるか。だって営利企業だしプログラマーは無料じゃない。実際、方針決まってからはギットハブ・コパイロットに大部分やらせたんだろうがな

**デフォルトの名無しさん** · 2025/03/13(木) 14:32:17.25

なんでfirefoxのソースをrustにできないの？
プログラムなんだから不可能ってことはないでしょ？

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

新たに作るものはRust一択になりつつあるが
既に別の言語で書かれているものはそれを負の遺産として考慮しなければいけなくなる
サンクコスト効果コンコルド効果に加え既存言語プログラマの抵抗勢力も足を引っ張る要因となる

**デフォルトの名無しさん** · 2025/03/13(木) 16:51:18.65

>>448
> 新たに作るものはRust一択になりつつあるが

んなこたーない。
選択肢として普通のものになったが、あくまで選択肢のひとつだ。

**デフォルトの名無しさん** · 2025/03/13(木) 16:55:33.59

日本語を型付きにして文法的に正しく無い書き込みは投稿ボタン押した時点で弾くようにならんかな。必ず日本語コンパイルエラー無しなのを確認してからしか誰も会話しちゃいけないなら世の中より良くなるはず。頭の中がスッキリする。

**デフォルトの名無しさん** · 2025/03/13(木) 17:09:05.03

型への幻想期は誰しもが通る
そのうち人間には無理なことを悟るまでがテンプレ

**デフォルトの名無しさん** · 2025/03/13(木) 17:23:47.86

>>448
頭おかしい

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

状況に応じて適切な言語を選択するのが普通の技術者

特定の言語に入信して
なんでRustじゃないんだなんでC#じゃないんだと
感情的にコメントを書いてるやつが多くてすごく滑稽

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

>>451
ちょろっと書く程度なら何でもいいけど
まともに開発するなら強い静的型付け言語が開発効率面から必須

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

「あると良いね」くらいじゃね
DropboxもPythonだったんだから、Dropboxくらいちゃんとしたサービスのレベルまで行っても必要条件であることはありえない
そしてそれよりデカいサービスの立ち上げは言語どうこうとかよりそもそもそのサービスが参入できる隙間を見つけて高速に参入することが重要。

**デフォルトの名無しさん** · 2025/03/13(木) 20:08:43.13

やりたければどんな言語でも手間暇かければできるのは当たり前
強い静的型付け言語で構築しないと開発保守効率が劣り時間と労力の無駄

**デフォルトの名無しさん** · 2025/03/13(木) 20:36:11.24

効率の話か
それで言うと、ビジネス感覚のある人が好まない言語はそもそもビジネスが成功しないから開発するだけ無駄だな

**デフォルトの名無しさん** · 2025/03/13(木) 21:26:10.48

時間をかけないためにスタートアップは動的言語を使ってるんだけどな

Facebook, Instagram, Youtube, Github, Twitterと例をあげればキリがない

**デフォルトの名無しさん** · 2025/03/13(木) 21:29:22.70

ここまでIT時代になる前だけじゃね

**デフォルトの名無しさん** · 2025/03/13(木) 21:29:44.10

スタートアップは静的型付言語しか勝たん
https://zenn.dev/ficilcom/articles/static-typing-for-startup

**デフォルトの名無しさん** · 2025/03/13(木) 22:02:56.19

動的型付け言語を捨てて静的型付け言語に移行したとか
静的型付け拡張の開発を主導してるような…

あと最近はスタートアップでフルスタック
typescriptにしてるところは珍しくない

**デフォルトの名無しさん** · 2025/03/13(木) 22:24:27.62

それぞれに適したものがあっても関連するプロジェクト全体で一貫した言語を使った方がスキルセットの管理が単純になるから運用が楽になることはある。
ウェブ系だと JavaScript か AltJS は避けられないのでそれに寄ってしまうのは仕方がない。

**デフォルトの名無しさん** · 2025/03/13(木) 22:26:07.36

自分の頭で考えられない人ほど
またスキルや経験の幅が狭い人ほど
特定の技術を宗教化して盲信しやすい

そうなるとますます自分の頭で考えられなくなり
どんな不都合な事実があろうと
教義に反さないよう都合よく解釈しようとする

優秀な技術者の対極

**デフォルトの名無しさん** · 2025/03/13(木) 23:02:12.20

>>462
フロントサイドはTypeScript＋WebAssemblyで良いけど
サーバーサイドまでTS/JSはリソースの無駄遣いなんだよね

もちろんまだ技術の発展途中なのでSSG/SSRをハイドレーションしてCSRするなら
その部分に限ってTS/JSでコード共通化は理解できるけどね

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

>>460
最も普及しているC++を消している時点で論外。

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

静的であろうと動的であろうと重要なのは(関数呼び出しなどの)コードの接続面・境界面の互換性であって、オブジェクト操作の互換性があれば良い。

動的型付けはこの互換性が実行時でないと判定されないのが問題であって、コード開発時(コンパイル)等に互換性を判定する仕組みがあれば問題無くなる。
コード解析は貧弱なので役に立たないが、静的インターフェイスのサポートなどで改善するだろう(今はそういうの無いけど)

静的型付けは互換性の判定のために型の命名を強制されるので、設計の柔軟性が無いなどの問題を持つ。こちらもC++コンセプトのよう静的インターフェイスで改善するので、今後は変数のコンセプト対応のようなインターフェイス改善で解決していくだろう。

RustのTrait境界もコンセプトのような柔軟性が欲しいところ。

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

>>458
スタートアップ時は動的型言語で造って
軌道に乗ったら静的型言語で造り治す例もあるが

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

>>462
https://qiita.com/YukiMiyatake/items/9904ed5b481e3f307bba
わろす

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

>>468
さすが書き手も読み手もQiita品質
テラワロス

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

「トレイト境界」などという完全な誤訳をいつまで使い続けるのかね？

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

わざわざBoundsと言ってる意味を考えてみてはどうか
第一言語が英語の俺からすると境界で違和感ない
お前は日本語が怪しいだろと言われれば確かにその通りだが

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

限界とか条件ならbounds じゃなくてlimitationだしな。

interface的な意味合いが強いのにinterfaceにしなかった理由はなんでかね？

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

>>472
英単語としてはそうかもしれんが、他の言語の用語にある interface と似た部分はありつつもやっぱり違うし、そこらへんは違う語をあてたほうが自然だと思う。

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

通勤電車乗ってなくてうらやましい

> 目的地を意味する表現です。例文. This train is bound for Tokyo station. この電車は東京駅 ...

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

>>474
それは「bound for」という熟語だし、さらに言えば
bound 境界
for 方向(対象までの間が主眼)
の組み合わせでそういう意味になるから、boundの例示で出すのは不適切かと。

inboundも外→内の境界付近のイメージが強いし、なんか良い例無いんかね。

**デフォルトの名無しさん** · 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
わざと逆方向の視点で語ってるだろ
まともな視点では使える機能が増えている
制約ではない