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/03/24(月) 19:03:47.22

**デフォルトの名無しさん** · 2025/03/24(月) 19:10:22.24

Boundsを制約と訳すスレ

**デフォルトの名無しさん** · 2025/03/24(月) 19:46:45.83

そろそろ自転車置き場決めた？

**デフォルトの名無しさん** · 2025/03/24(月) 22:53:31.24

ピンポーン「トレイト境界のほうから来ました」

**デフォルトの名無しさん** · 2025/03/24(月) 23:29:23.83

>>3
boundsの意味もtrait boundsでの用法もある範囲や領域の限界や限度や際や境界を意味しています
trait boundsはそのままトレイト境界が正しいです
英語においても制約を意味するconstraintを用いずに境界などを意味するboundsを採用しています

**デフォルトの名無しさん** · 2025/03/25(火) 02:01:12.77

Goを布教する人が「ジュニアクラスとシニアクラスとで書き方が変わらない」と主張していた

格上と比較され、どっちも同じと評価される
この戦術をもし使い回すとしたら意訳ではなく直訳を推すだろうと思う

**デフォルトの名無しさん** · 2025/03/25(火) 07:38:53.95

日本語訳プロジェクトを引き継いで「トレイト制約」で統一すりゃいいんじゃないんかな。
日本語訳プロジェクトは最新版に追随できていないから、誰も文句言わないだろ。

**デフォルトの名無しさん** · 2025/03/25(火) 07:51:42.61

>>8
Trait Bounds自体は制約の意味ではなくてトレイトを満たす型の集合の境界を表している
制約が起きるのはジェネリックな型パラメータに対してであって一般的に型制約(Type Constraint)と呼ばれる
つまり『トレイト境界』によって対象となる型パラメータに『型制約』が生じるという関係

**デフォルトの名無しさん** · 2025/03/25(火) 11:02:27.42

すげーなトレイト制約
これだけで無限に荒らせるじゃん

**デフォルトの名無しさん** · 2025/03/25(火) 11:31:46.22

いつも批判する人「いつでも自由だった」
いつもなら批判を批判する人「今だけ自由じゃん　すげーな自由って」

**デフォルトの名無しさん** · 2025/03/25(火) 11:34:50.46

蒸し返しピンポンダッシュやり続ける境界が荒らし

**デフォルトの名無しさん** · 2025/03/25(火) 12:10:04.70

>>9
>Trait Bounds自体は制約の意味ではなくて
bounds自体に制限する/限定する/制約するという意味があるのだからその解釈は無理筋

**デフォルトの名無しさん** · 2025/03/25(火) 12:19:02.68

そもそも前後の文脈から境界の意味で使ってるのは明白なのに議論する意味あるの？

**デフォルトの名無しさん** · 2025/03/25(火) 13:34:38.92

オライリーが「トレイト制限」で訳してたらもう少し穏便だったな
「制約」にしたせいで「境界」との互換性が破壊された

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

『トレイト境界』には解散命令が出されたな

**デフォルトの名無しさん** · 2025/03/25(火) 15:30:05.21

空の境界

**デフォルトの名無しさん** · 2025/03/25(火) 15:32:23.67

間を取ってトレイトバウンズで平和

**デフォルトの名無しさん** · 2025/03/25(火) 15:43:50.99

>>15
「境界」との互換性ってなんだ？

**デフォルトの名無しさん** · 2025/03/25(火) 16:25:54.64

「制限はしているが制約はしていない」by トレイト境界

**デフォルトの名無しさん** · 2025/03/25(火) 19:06:21.64

Out of bounds.
略してOB

**デフォルトの名無しさん** · 2025/03/25(火) 19:55:23.90

だからトレイトが実装されていないときにOut of Boundsと言われて納得するかと書いたよね？
違和感しかない

**デフォルトの名無しさん** · 2025/03/25(火) 20:19:08.10

だからとっとと「トレイト制約」に修正した最新版のRust Book日本語訳を作って公開しなよ。

日本語で参照できるドキュメントが「トレイト境界」なんだから、今のままじゃ「トレイト制約」が普及することなんてありえん。

**デフォルトの名無しさん** · 2025/03/25(火) 21:04:47.63

それはそう。
間違っていると思うなら正しいと思う形のものを出していくしかないし、それを認めさせないと個人的に何を思おうがコミュニティの意見の代表にはなれない。
少なくとも真っ先に翻訳を出すような熱心な人々は境界と言ってるし、技術用語の習慣としては妥当性がある。

**デフォルトの名無しさん** · 2025/03/25(火) 22:06:22.48

>>23
性的マイノリティっぽい人に「口先だけでなくとっとと本格的な手術をしなよ」と言っているような意見だ

**デフォルトの名無しさん** · 2025/03/25(火) 22:20:34.71

「find」コマンドよりシンプル＆爆速の検索コマンド「fd」の使い勝手を確かめてみた、Rust製でGitHubスター数は3万個以上
https://gigazine.net/news/20250324-fd-find-alternative/

**デフォルトの名無しさん** · 2025/03/25(火) 23:17:31.98

>>26
> コマンド名が2文字しかなく、4文字のfindよりも50％短い

すげえ

**デフォルトの名無しさん** · 2025/03/25(火) 23:33:14.22

>>27
もし R 言語っての作ったらRustより75%向上って言ってもらえるのか

**デフォルトの名無しさん** · 2025/03/25(火) 23:45:58.20

あるぞR言語

**デフォルトの名無しさん** · 2025/03/25(火) 23:58:55.68

>>9
RustのTraitのもとになったのはHaskellのType Class
RustのTrait Boundsに相当するものはHaskellではType Class Constraints
Traits Boundsは単語の意味的にも用途的にも型を制約するために存在していて型制約の一種

**デフォルトの名無しさん** · 2025/03/26(水) 00:41:57.44

もうやめて！旧トレイト境界のライフはもうゼロよ！！！

**デフォルトの名無しさん** · 2025/03/26(水) 00:58:31.81

'a: 'bをlifetime boundって呼ぶのだけは理解できるが
Ty: 'aとかTy: Trがboundかって聞かれるとなあ

**デフォルトの名無しさん** · 2025/03/26(水) 01:44:15.30

lifetimeってスコープじゃないんかい
NLLと言うなら尚更
lexicalではないがスコープではあるんだと誰でも思うでしょ

**デフォルトの名無しさん** · 2025/03/26(水) 02:11:13.95

>>26
> fdは同じ処理を約0.25秒で完了しました。
> 実に6倍以上の速度で処理を行えていることが分かります。

Windowsでも6倍も速くなったということはOsStrのWTF8の影響は微々たるものなのか回避しているのかどちらなのだろう
いずれにせよRustで爆速に作れるんだな

**デフォルトの名無しさん** · 2025/03/26(水) 09:49:55.18

>>33
lifetime boundsはライフタイムそのものではなくてライフタイムを使ったジェネリックの型制約のこと

**デフォルトの名無しさん** · 2025/03/26(水) 10:06:58.48

>>34
time fd --threads=1 > /dev/null と time find . -print > /dev/null
で比べると、findの方が倍程度速かったからfdのはマルチスレッドの威力かな

**デフォルトの名無しさん** · 2025/03/26(水) 10:09:23.49

>>36はWindows MSYS2での結果だからOsStrrのWTF8の影響でfd(シングルスレッド)が遅いのかも

**デフォルトの名無しさん** · 2025/03/26(水) 12:02:53.58

Rustってlinuxコマンドの焼き直しばかりしてるイメージ

**デフォルトの名無しさん** · 2025/03/26(水) 12:17:05.16

>>38
確かにRustは清書用とは良く例えたもんだ、Rustは仕様追加変更に弱そうだし

出始めは高速で注目されたalacrittyなんて文字関連不具合は非対応の一点張りだしなあ
TypeScriptコンパイラ(type checker)で言うと、何年もかけてRustで作ったら、その間の停滞はもちろん、その後も進化止まるからなあ

**デフォルトの名無しさん** · 2025/03/26(水) 12:19:09.43

「Google Chrome」のフォント処理がC/C++言語からRust言語に
「FreeType」からの移行でメモリ安全性を改善
https://forest.watch.impress.co.jp/docs/news/1672186.html

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

性能などでC実装の既存コマンドを越えられるポテンシャルがあるからね
あとは利用者のバックグラウンドがUNIX系の人多いのかな
Goはランタイム付いてきてバイナリが肥大化するから魅力ない

**デフォルトの名無しさん** · 2025/03/26(水) 12:25:26.75

>>30
最初から結論出てたんだな
境界関係者の詭弁にはもう騙されない

**デフォルトの名無しさん** · 2025/03/26(水) 12:35:10.24

>>30
本物アカデミア発のHaskellは流石

**デフォルトの名無しさん** · 2025/03/26(水) 12:37:17.45

>>42
HaskellでBoundsを引数にConstraintsの境界を指定したからといって
BoundsがConstraintsと等価にはならないだろう

**デフォルトの名無しさん** · 2025/03/26(水) 13:00:48.37

拗らせ詭弁爺>>44は境界(boundsじゃないよ、boundaryだよ)の数学的定義も知らずに妄信してるんだろ

**デフォルトの名無しさん** · 2025/03/26(水) 13:32:04.61

>>40
Chromeも次々とRust化されていってるな
停滞しているFirefoxを追い抜いてRust化が進むのだろう

**デフォルトの名無しさん** · 2025/03/26(水) 13:56:36.97

>>46
FirefoxはちょっとRustにかまけたせいで停滞したからな
chromeはお大事に
(カラーとかSVGが済んで今後10-20年間はフォント関係の大きな規格追加変更しないつもりかもね)

**デフォルトの名無しさん** · 2025/03/26(水) 13:59:25.21

>>41
>>36によるとそのポテンシャルは発揮されてないし、マルチスレッドの力技ならGoの方が柔軟で規格追加変更に強そう

**デフォルトの名無しさん** · 2025/03/26(水) 14:06:07.26

>>48
Windowsなんて相手にしてないんよ。MS製品使いなよギガジン
MSのDos窓のfindとの比較してもなあ

**デフォルトの名無しさん** · 2025/03/26(水) 14:11:51.14

恥ずかしいの沸いとるしw
msys2知らんのやろな

**デフォルトの名無しさん** · 2025/03/26(水) 14:30:05.79

そんなものの上で比較して何が嬉しいギガジンと言っている
LinuxDesktop使わんかい

**デフォルトの名無しさん** · 2025/03/26(水) 14:31:52.57

せめてmacOSだな
ﾄﾞｻﾞｰしかギガジンにはおらんのかもな

**デフォルトの名無しさん** · 2025/03/26(水) 14:33:11.38

Rustはリファクタリングや変更に強いため
それらでエンバグしやすい言語よりもRustを使うのが好ましい

**デフォルトの名無しさん** · 2025/03/26(水) 14:41:56.21

恥の上塗りすこいな ID:1e+q4ua7
>>34が気にかけてるOsStr/WTF8の影響の話だからな
windowsでやらなきゃ意味ないよ

とは言えRust自体がWindowsなんて相手にしてない節が多々あるので、RustがWindowsで遅いと言われても納得ではある

> LinuxDesktop使わんかい
まずLinuxでこれやって見ては
> time fd --threads=1 > /dev/null と time find . -print > /dev/null

**デフォルトの名無しさん** · 2025/03/26(水) 14:45:41.09

ガハハ、Linuxで遅いと残念だから調査してみますか

**デフォルトの名無しさん** · 2025/03/26(水) 14:52:45.05

一般的にマルチスレッド対応をする時
並列に動作できるようにアルゴリズムを組み替える
シングルスレッドで動かすと最善アルゴリズムではなく最善より不利になったとしても、並列化できることを最優先にアルゴリズムを変える
そういう常識を知らない無知な人が「--threads=1」で実行して速度比較してしまう

**デフォルトの名無しさん** · 2025/03/26(水) 15:01:36.90

>>56
そんな保険張らなくても良いと思うよ

数値計算などを含めると分割コストが馬鹿にならないけど、ディレクトリトラバーサルはロスなくマルチスレッドが効きやすい処理だから
自分は昔から自作のMPMCキューとスレッドプールでその手の処理やらせてる

**デフォルトの名無しさん** · 2025/03/26(水) 15:05:10.71

>>57
第一生命の人にそれ言えるの？

**デフォルトの名無しさん** · 2025/03/26(水) 15:08:57.08

FreeTyoe終了するんか胸熱

**デフォルトの名無しさん** · 2025/03/26(水) 15:10:32.50

あの記事の比較を真に受けるやつはどうかしてるぞ
簡単なベンチマークすらできないのか？

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

>>53
リファクタリングって車輪の再発明のことだよ

**デフォルトの名無しさん** · 2025/03/26(水) 15:33:35.65

>>60
fd vs (gnu)findの記事で、(ms cmd)dir -s をしかも powershell(.net) 上でやるのが良い味だしてるよなw

--threads=1 比較はこのスレでの話

**デフォルトの名無しさん** · 2025/03/26(水) 17:16:48.66

>>53
そこまで言うなら論より証拠が欲しいな

お題スレで697が型変更(BigInt要件追加703,706)で困ってるかもしれないので助けてあげて
C++の方は難なく型変更出来た、それも(おそらくアルゴリズム内容に感知しない)別人が
https://mevius.5ch.net/test/read.cgi/tech/1691038333/697

**デフォルトの名無しさん** · 2025/03/26(水) 18:28:10.20

rustは身内よりも
外からの攻撃に耐えてる感じか
素性がいいからな
ポテンシャルが危険視されてんだろ

**デフォルトの名無しさん** · 2025/03/26(水) 18:45:50.26

>>64
あんた>>53と同類だな
>>63の実演は>>64がしても良いんだぜ

**デフォルトの名無しさん** · 2025/03/26(水) 18:47:25.84

>>63のこの部分は重要
> (おそらくアルゴリズム内容に感知しない)別人が

アルゴリズムを読み解いて書き直したら>>61の通り車輪の再発明だからな
ましてC++版をRustに書き直すのも車輪の再発明そのもの

**デフォルトの名無しさん** · 2025/03/26(水) 19:03:18.26

再発明禁止したらLispしか書けなくなるぞ
それはそれでいいか

**デフォルトの名無しさん** · 2025/03/26(水) 19:05:21.95

>>41,53,64
そのポテンシャル、いつ発揮するの？

**デフォルトの名無しさん** · 2025/03/26(水) 19:06:51.25

>>41,53,64
そのリファクタリング、いつやるの？

**デフォルトの名無しさん** · 2025/03/26(水) 19:09:36.76

Ubuntuのcoreutilの一部をRust実装にしてみる予定あるよ
ゆっくりかもだが着実に浸透していく

**デフォルトの名無しさん** · 2025/03/26(水) 19:16:40.14

このまんま過ぎる件
>>38
> Rustってlinuxコマンドの焼き直しばかりしてるイメージ

**デフォルトの名無しさん** · 2025/03/26(水) 19:19:09.38

>>71
乗っ取ってる最中だな

**デフォルトの名無しさん** · 2025/03/26(水) 19:20:31.32

やりがいあるのかね
> linuxコマンドの焼き直しばかり

やらされるようになったら愛され言語陥落

**デフォルトの名無しさん** · 2025/03/26(水) 19:22:06.71

>>72
ははw、Linuxはデバドラで軒下貸しただけのつもりだったのかな

**デフォルトの名無しさん** · 2025/03/26(水) 19:33:31.85

Linuxはカーネルだけだから関係ないぞ
置き換えてるのはGNUのコマンドだね

**デフォルトの名無しさん** · 2025/03/26(水) 19:36:49.23

>>63
Rustは強い静的型付け言語なのでその手で問題があれば必ずエラーとなり教えてくれる
問題児となる暗黙の型変換や(!Copyの時の)暗黙のコピーがないため優秀
エラーに従いそれらを手入れしてやるだけだ
もちろんコピーせずに済むところは参照を使い必要なところのみclone()する
アルゴリズムの変更は必要ない

ここまで一般的な話だが
BigIntに限ればさらに効率高めるためにxxx_assign系を使うように変えられるとヒープ割り当て抑制でさらに効率が上がるだろう
頑張れ

**デフォルトの名無しさん** · 2025/03/26(水) 19:42:15.95

BSDがカーネルからgcc消した時もまずはコマンド(linuxからしたらユーザーランド)からコツコツやってたな

**デフォルトの名無しさん** · 2025/03/26(水) 19:44:59.97

でかくて体力あるとこが立ち泳ぎしてる段階

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

車輪の再発明でもいいからOpenCVのRust版みたいなの欲しい、とは思う
巨大だから作り直しが面倒というのは目に見えてるが

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

Rustは車輪の再発明に向かないよな。というのもコスパ悪いから。すでにバグ取りして動いてるC++とかライブラリーをわざわざ書き直すなんて俺たちはしないな

どちらかと言うと真新しいライブラリーの設計するときに導入しやすいし、チームにも勧めやすい。俺たちのチームでは一からスキーマ決めて新しい機能追加していこうってなったときテストコード含めて一括で書けるからライブラリークレイトがデグレイドしなくて開発効率上がってる

0->1型開発ならRustでやりますと言っても承認降りるよ。品質保証部とかの人もリリース済み製品の変更は嫌うが、新規開発は好きにやってと言ってくるし

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

OpenCVのRust版はもうあるんじゃないの
pureRustしか勝たんのなら知らん

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

>>71 >>69
彼らがどうしてもRustに置き換えるのに拘ってる理由は
善意的に深読みするとGPL汚染からの完全脱却を目指してるとか鴨試練

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

>>81
bindingはあるけど、>>79は大元のOpenCVインストール&設定が出来なくて「pureRustだったらCargoが全部やってくれるのに！」と愚痴ってるだけと予想
python等みたいにプリコンパイルライブラリも配信パッケージに含めたら良いのにね

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

>>76
>BigIntに限ればさらに効率高めるためにxxx_assign系を使うように変えられるとヒープ割り当て抑制でさらに効率が上がるだろう
頑張れ

ほんそれ

**デフォルトの名無しさん** · 2025/03/27(木) 12:09:12.20

これとか
https://mevius.5ch.net/test/read.cgi/tech/1698705458/799

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

>>83
なるほどね

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

>>85 の 799 に答えるなら「OpenCVは既に入っている」なんだけどね

**デフォルトの名無しさん** · 2025/03/27(木) 12:26:21.40

>>80
どの言語からどの言語に移植するのもコスパ悪いので必要ないならする意義はない
しかしそれでもRustへの移植が行われているのは実利があるからでその2大理由は
CPUメモリのリソース効率が良くなる場合
セキュリティ脆弱性を含めた安全性が良くなる場合
もちろん単純な移植ではなく再設計を伴うならばそれ自体がRustを選ぶ理由になる

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

そこでGoです

**デフォルトの名無しさん** · 2025/03/27(木) 12:40:56.78

つまり簡単に言えばTrait制約は誤訳ってこと？

**デフォルトの名無しさん** · 2025/03/27(木) 12:49:37.81

つまり、英語の単語と日本語の単語は一対一対応ではないということ

**デフォルトの名無しさん** · 2025/03/27(木) 12:58:01.56

>>90
一貫することが技術用語としては正しい態度なんだよ。
自然言語的な意味で誤訳かどうかは最初から問題じゃなくて「Rust 用語では境界ということにする」という先駆者たちの合意に反して新しい語をあてるのはよくなきだよなって話。

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

バイナリサイズが大きくならない
も入れておこう。Docker imageなどでは重視される

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

>>93
Cと比べて小さかったら、機能がそろってないだけだな

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

Goはインストールすれば必ず動くから
Dockerの必要なし
繰り返す
Dockerの必要なし

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

>>95
docker を何だと思ってんの？

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

>>94
Rustなら同等サイズで同機能狙えるでしょ。アピールポイントやで

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

C の主要な関数は実質的に OS の一部みたいになってる (libc.so) からその分だけ実行ファイルは小さくなる。
工夫すれば Rust でも同等を狙うことは出来るが Rust らしさは失われるよ。

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

コードの見た目と安全性がRustのままならいいよ
libc使うと変わっちゃうか。unsafeが多そう

**デフォルトの名無しさん** · 2025/03/27(木) 14:21:40.81

>>98
>>99
もちろんRustでもlibcを使っているよ
stdでlibcがある環境ならね
no_stdでcoreなら使わない

**デフォルトの名無しさん** · 2025/03/27(木) 14:33:43.34

RustでUNICODEのicu(icu4x)を使うと肥大化するで

**デフォルトの名無しさん** · 2025/03/27(木) 16:58:03.46

>>92
先駆者ｗｗｗ

**デフォルトの名無しさん** · 2025/03/27(木) 17:12:14.97

bounds問題は、もうテンプレに入れておけよ
本によって訳語が違うので注意ってことでいいでしょ
コミュニティ内の合意が、出版社に届くとは限らんのだから

**デフォルトの名無しさん** · 2025/03/27(木) 17:34:35.49

境界vs制約について議論してるコミュニティあったの？

**デフォルトの名無しさん** · 2025/03/27(木) 17:37:35.59

>>92
Rust信者が特にC/C++の先駆者に無礼なのを棚に上げるな

**デフォルトの名無しさん** · 2025/03/27(木) 17:42:30.79

>>104
無いならなおさら。最初の本の訳者同士で決めた用語がスルーされるとか、普及期なら普通のことでしょ
明治時代ならよくあったろ

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

libcクレートをフル活用すれば、CのようなRustのような変なプログラムを作れる
テキスト出力にprintf()使うとか

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

福沢先生に聞いたら良い

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

先行者はRustで制御してるってほんとですか？

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

GC無いから制御も余裕でしょう

**デフォルトの名無しさん** · 2025/03/27(木) 22:05:08.25

どうしても境界を存続させたい勢力(一名)が足掻いてるな

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

どっちでもいいけどとっとと手を動かせ。

the rust book 現行版の翻訳があればそれに従う。

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

まぁ言われてみれば境界ってちょっとおかしいよな
多分境界エラーとかアウトオブバウンズとか
そっちの直訳に引っ張られたんやろけど
制約がいいとも思わんけど
制約のほうが若干マシ

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

でも原文が境界の意味で使ってるからね

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

>>114
根拠を提示しなよ

**デフォルトの名無しさん** · 2025/03/27(木) 23:39:29.81

トレイト範囲が適訳
制約はアタオカ

**デフォルトの名無しさん** · 2025/03/28(金) 00:38:42.10

トレイト制限よな

**デフォルトの名無しさん** · 2025/03/28(金) 11:47:49.50

>>116
範囲イイね

**デフォルトの名無しさん** · 2025/03/28(金) 11:48:49.20

制約と言ってる人は意味が分かっていないのでは？

**デフォルトの名無しさん** · 2025/03/28(金) 12:17:15.99

トレイトをカタカナにしてるんだから、残りもカタカナでいいんじゃないの？

**デフォルトの名無しさん** · 2025/03/28(金) 12:43:54.75

トレィト博士？

**デフォルトの名無しさん** · 2025/03/28(金) 12:44:11.20

トレイト製薬はCで**をダブルポインタと言うくらい恥ずかしい

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

>>106
石田晴久ですねわかります

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

今頃用語に難癖つけてる方が恥ずかしいわ

**デフォルトの名無しさん** · 2025/03/28(金) 13:38:19.20

>>118
トレイト視界がしっくりくる

**デフォルトの名無しさん** · 2025/03/28(金) 13:49:09.58

用語も決まらないほど難解なので初心者お断り言語ってことでよろしく
金にもならんぞ

**デフォルトの名無しさん** · 2025/03/28(金) 13:49:56.56

家族連れはGoでもやっときなさい

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

RustやC++がカバーするほとんどの利用領域でGoは役立たずで選ばれていない現実を見なよ
他の言語のスレを荒らすという人間としてしてはいけない醜い行為をせずにGoスレへ帰りなさい
今後ここでGoは禁止
どうしてもやりたい人は「Rust vs Go」スレでやりなさい

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

一般人向けのGolang
孤高の童貞向けRust
という住み分けで

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

Rustでドライバを書けるようにした時が
Linux凋落の始まりだった
と言われる未来が見える

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

Trait制約とか言って恥ずかしくないのかな
まるで分っていませんと
自分でいふらしてるようなもの

**デフォルトの名無しさん** · 2025/03/28(金) 16:01:53.44

C並に標準化が進むと思いますか

**デフォルトの名無しさん** · 2025/03/28(金) 16:12:38.49

Cはコンパイラ乱立で勝手な拡張方言で標準語を作らざるを得なかった負の側面

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

そこまで普及したらいいね。しかし人類には早すぎだからね

**デフォルトの名無しさん** · 2025/03/28(金) 21:41:02.63

ABIレベルで標準化されてるものはC以外に無いよね
実装はCである必要はない (C++やRustでも良い) けど、FFI用のインターフェースとしてのCの需要は無くならない
正直もう少し表現力のあるものが欲しいけど、これは10年やそこらでは変わらないよなあ

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

cargo build時にlikerオプションとしてスペース込みのパス渡したいんだけど不可能？

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

不可能です

**デフォルトの名無しさん** · 2025/03/29(土) 00:39:07.23

Ferrous Systems が独自にまとめていた Rust の言語仕様が Rust プロジェクトに寄贈された。

**デフォルトの名無しさん** · 2025/03/29(土) 13:40:51.83

「トレイト境界」に文句を言っているやつは先んじて翻訳公開して、「トレイト制約」を定着させないとな。

**デフォルトの名無しさん** · 2025/03/29(土) 13:42:20.41

いつまでもうるさいぞ
英語で言え

**デフォルトの名無しさん** · 2025/03/29(土) 14:49:39.18

自分で crates 造ったとき(他人のでもいい)
docs.rs とかの項目って基本的に pub したものしか出ないと思うけど
lib.rs に描いてる #[cfg(test)] や #[test] の(pubじゃない) fn の一覧ってどこで観れる？

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

>>141
cargo doc --document-private-items

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

複オジはことごとく論破されたのがよほど悔しかったんだろう

**デフォルトの名無しさん** · 2025/03/29(土) 19:54:04.74

トイレット境界

**デフォルトの名無しさん** · 2025/03/29(土) 20:14:42.70

訳を定着させる前に、
公式のRFCなり、zulipなりに「bindingでは意味が分からないconstraintにすべきだ！」というリクエストを上げて、
公式側から「せやな」って言わせるのが先じゃねーの？

失笑買いそうだけど。

**デフォルトの名無しさん** · 2025/03/29(土) 22:48:04.91

>>145
bindingは草
「境界関係者 == 何も理解してない」オジさん

**デフォルトの名無しさん** · 2025/03/29(土) 23:00:53.39

>>146
bindingを否定してバカにする意味がわからないが？
trait boundsは境界または境界線、境界エリアあたりで良いんじゃないの
議論ばかりだとRustの実装が進まないし、もう日本語にこだわらずに英語のまま行こうぜ
相互に相手が馬鹿だと思ってても時間の無駄なだけだ

**デフォルトの名無しさん** · 2025/03/29(土) 23:05:01.36

しょうもないことに執着すんの自閉でしょ

**デフォルトの名無しさん** · 2025/03/29(土) 23:05:15.30

ということで訳者の皆さん、予約語＋〇〇な単語は無理にやくさんでいいです

**デフォルトの名無しさん** · 2025/03/30(日) 00:24:42.12

>>147
trait boundsのboundとbindingが何か関係があると思ってるの？

**デフォルトの名無しさん** · 2025/03/30(日) 09:13:11.97

bindの過去分詞はboundだけどtraitboundsのboundとbindingは何の関係も無い別の単語

**デフォルトの名無しさん** · 2025/03/30(日) 11:09:56.57

境界関係者にとっては本来の単語の意味とかどうでもいいんだろ
誤訳だろうと先駆者ｗに従うだけだから

**デフォルトの名無しさん** · 2025/03/30(日) 11:11:48.21

まだやってんのか
制約でいいじゃん
オライリーがそうなってんだし

**デフォルトの名無しさん** · 2025/03/30(日) 11:33:03.21

nightlyじゃないとカスタムアロケーターすら使えないんか・・・
Rustって思ったより未完成すぎんな

**デフォルトの名無しさん** · 2025/03/30(日) 12:44:09.91

GlobalAllocは使えないの？

**デフォルトの名無しさん** · 2025/03/30(日) 17:14:17.40

sbrkは使えないの？

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

ゲーム開発したいんかな

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

ゲーム開発したいんかな

**デフォルトの名無しさん** · 2025/03/30(日) 20:01:37.56

egui

**デフォルトの名無しさん** · 2025/03/30(日) 23:24:44.75

>>156
Cでも普通はmalloc/reallocを呼んでその中で間接的にsbrkが使われる
Rustの抽象化層の下も同様にlibcのmalloc/reallocを呼んでいる
直接sbrkを呼び出す独自のアロケータを作ろうとしているのかな

**デフォルトの名無しさん** · 2025/03/30(日) 23:43:38.72

Issue出せばいいでしょ。Cで出来ることが出来ないなら考えてくれる人がいるか。自分で実装しても良し

**デフォルトの名無しさん** · 2025/03/30(日) 23:46:35.01

もちろん呼びたければRustからsbrkだろうがmmapだろうが呼び出せる

**デフォルトの名無しさん** · 2025/03/30(日) 23:51:36.82

C++みたいにRAIIな基板でお手軽アロケータ実装したいんじゃないの

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

traitのFromを描いたらIntoは描かなくて良い？
Intoを勝手に造ってくれるのは一部だけ？

**デフォルトの名無しさん** · 2025/03/31(月) 11:08:35.12

>>164
全自動
Fromを実装すれば以下のコードがあるためジェネリックに逆向きのIntoが自動的に実装される

impl<T, U> Into<U> for T
where
　U: From<T>,
{
　fn into(self) -> U {
　　U::from(self)
　}
}

**デフォルトの名無しさん** · 2025/03/31(月) 12:19:01.61

blanket implementation というやつ

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

リファレンスでblanket implementationの定義を確認しようとしたら一つ下にboundの定義もあった
https://doc.rust-lang.org/reference/glossary.html#bound

この定義を踏まえて前スレを読むと境界支持者らの主張はことごとく出鱈目だな
アイツらマジで何なの？

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

Bound
Bounds are constraints on a type or trait. For example, if a bound is placed on the argument a function takes, types passed to that function must abide by that constraint.

**デフォルトの名無しさん** · 2025/04/01(火) 12:14:34.31

その話もうええっちゅうねん

**デフォルトの名無しさん** · 2025/04/01(火) 12:16:55.39

一度こだわり始めたら自分でも制御できないんだ
たぶん自閉症とかの障害がある

**デフォルトの名無しさん** · 2025/04/01(火) 12:29:39.99

Bounds are constraintsワロタｗ
制約大勝利やんｗ

**デフォルトの名無しさん** · 2025/04/01(火) 12:33:32.91

>>171
バカだろ
英語をよく読めよ
constraints on a type
つまりいわゆる型制約が正解
トレイト制約になるのはスーパートレイトがサブトレイトに対する時のみに限られる
したがってトレイト制約の訳は間違っている

**デフォルトの名無しさん** · 2025/04/01(火) 12:37:50.50

俺はトレイト境界よりもトレイト範囲かトレイト限界がベターと思っている派
しかしトレイト境界で定着していて意味するところは同じなのでトレイト境界で構わない
誤訳のトレイト制約だけはNG

**デフォルトの名無しさん** · 2025/04/01(火) 12:40:33.02

訳はこうなる
「トレイト境界は型(もしくはサブトレイト)に対する制約である」

**デフォルトの名無しさん** · 2025/04/01(火) 13:58:37.31

やばい、人類が滅亡する！

**デフォルトの名無しさん** · 2025/04/01(火) 14:18:55.81

トレイト世界とか宇宙でどうや

**デフォルトの名無しさん** · 2025/04/01(火) 14:20:58.62

システムプログラミング用言語であるから簡単な用語がいいんだがね
数学はやめいよ

**デフォルトの名無しさん** · 2025/04/01(火) 14:33:15.61

この画像を貼る時が来たようだな
https://i.imgur.com/vGcEcQa.png

**デフォルトの名無しさん** · 2025/04/01(火) 15:42:56.21

グロ中尉

**デフォルトの名無しさん** · 2025/04/01(火) 15:44:46.09

Trait
A trait is a language item that is used for describing the functionalities a type must provide. It allows a type to make certain promises about its behavior.

Generic functions and generic structs can use traits to constrain, or bound, the types they accept.

**デフォルトの名無しさん** · 2025/04/01(火) 18:32:01.55

旧約聖書の解釈でさえもこのスレほどバトルにはなってないと言うのに！

**デフォルトの名無しさん** · 2025/04/01(火) 19:37:06.51

>>168
バカの極みやね
Bounds are constraints on a type or trait.
Bounds = constraints ではないぞ
トレイト教会がトレイトを聖約するんだぞ

**デフォルトの名無しさん** · 2025/04/01(火) 19:51:03.44

Bounds are constraints(境界は制約である)
Bounds are constraints on a type or trait.(境界は、型または特性に対する制約です。)

つまり制約です

**デフォルトの名無しさん** · 2025/04/01(火) 19:53:23.79

いわゆる型制約だよ
型制約と同様にサブトレイト制約でもある
トレイト制約は誤用

**デフォルトの名無しさん** · 2025/04/01(火) 19:59:34.21

DeepL翻訳
Bounds are constraints(境界は制約である)
Bounds are constraints on a type or trait.(バウンズは型や特性に対する制約である。)

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

だからとっとと Rust Book最新版翻訳して、好きな方の用語に統一しとけ。

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

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

境界信者の反知性主義がここまで凄まじいとは
さすがに想定外

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

訳者本人じゃないの
信者の素性はニート?

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

普及率100パーセント、100人中100人が守るルールか
なるほどたしかに法律なら不可能なことが言語なら可能かもしれない

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

境界と描かれてる本は不良品だから法制化して全数リコール

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

そろそろ凡俗な人達による用語統一議論終わった？

**デフォルトの名無しさん** · 2025/04/02(水) 15:11:44.14

では高尚な話題どうぞ

**デフォルトの名無しさん** · 2025/04/02(水) 15:17:23.33

プロジェクト名に '-' を入れるのって非推奨？

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

では高尚な話題です
原語のboundがまず間違っているのでは？

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

>>193
RFC430にありそうでないや
クレート名は不明瞭

**デフォルトの名無しさん** · 2025/04/02(水) 16:15:00.32

電界磁界より電場磁場が適切である様に
トレイトはトレイト場であるべき

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

ルビを原文ママにするという高尚テクニックがあったなそういえば
解（イコライザ）とか

**デフォルトの名無しさん** · 2025/04/02(水) 19:54:18.16

制約と訳すと原文の意味が失われるので技術翻訳では避けるべき
もちろん小説を訳すなら過激な意訳も可

今回の件はTrait境界が妥当でしょう

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

分かりやすく言ってみましょうか

Trait制約は制約である
制約は制約である

どうです？
何かが失われていませんか？

Trait境界は制約である
境界は制約である

これなら意味が分かるでしょう

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

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