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/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
線引をして境界が構成されるんだよ
だからトレイト境界と呼ぶ

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

二項演算を使いたいだけなのに単位元の定義を強制されるパターンはたまにある
制約がないと言えるのは、使いたい関数の名前とトレイトの名前が同じやつだ

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

なんか伸びてるけどトレイトのようなものは他言語でもよくあるでしょうに
ジェネリックくらいちゃんと理解しとけ

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

PHPだね

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

Pythonにはトレイト無いんだよね

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

>>578
Javaのジェネリクスどうなってるかなって見てみたら

https://docs.oracle.com/javase/tutorial/java/generics/boundedTypeParams.html
> Bounded type parameters are ...
> ..., use a type parameter bounded by the Comparable<T> interface:

Bounded type parametersって呼び方なんだな

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

制約と言う人達は trait を理解していない
C++03からやり直すべき

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

>>582
このスレで出てる話は trait でなく trait bound という言葉についてだぞ

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

>>570
日本語では「境界を満たしていません」なんて言い方はしないんだよ
質の悪い機械翻訳以外ではね

現代日本語の「境界」は境界線や境目のことであって境界づけられた範囲や領域を指して「境界」とは言わない

“bound is not satisfied”や”requird by this bound”などからもわかるようにRustを開発してる中の人も明らかに制約面を重視してboundsという用語を使っている

それだけじゃなくtrait boundsはジェネリックの型パラメーターの型制約の一種
ジェネリックにおける「型制約」という用語はRustに限らずプログラミングの概念として広く定着しているものでRustでももちろん使われている

それらを完全に無視して無理のある「境界」という訳語を当ててこじつけ解釈を続けるメリットは何もない

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

bounds に制約という意味はない

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

trait は特性を表現するのみで
それが何かを制約することはない

trait bounds はある特性の範囲を表現するのみで
それが何かを制約することはない

これで理解しないならお手上げだ

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

日本に匙を投げる日は近い
備えよ

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

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

制約という訳語がそのまま載ってない辞書でも制限や許容範囲という訳語はあるはず
制限と制約は微妙に違う単語でニュアンスも違うけど状況によっては代わりに使える単語
英語でconstraintとrestrictionを使い分けるのに似てる
type restrictionとtype constraintのどちらが伝えたい意味に近いかという話と同じ

伝えたいニュアンスとは別に「型制約」という概念・用語がかなり昔から広く浸透してることを考えるとトレイト制限とトレイト制約を比べれば後者のほうがより適切と判断するのはごくごく自然なことだと思う

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

>>586
>trait bounds はある特性の範囲を表現するのみで
>それが何かを制約することはない

型パラメーターが自由に動ける範囲を制約するもの
そもそもboundsは単純な「範囲」という意味ではなく何かが許された範囲・領域のことで制約・制限的なものが必ずついて回る

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

「境界」という言葉のほうを軸にするなら満たす/満たさないではなく越える/越えないと言ったほうが自然かなとは思う。

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

でも技術用語は不自然なくらいで良いとも思う。
下手に日常用語の意味と合わせると仕様上の意味と日常の意味が混ざって混乱する。
「Rust 用語ではこういうんだよ！」で行くべき。

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

T: Traitは未知の型Tに対して可能（必要）な操作を明示するためのもので
Tの型に制限がかかるのはその結果にすぎないよ
Tの型を制限する目的で境界を設定してるわけではない

これはジェネリクスを含む型とか関数を実装する側になれば分かる
できるだけTの制限が緩くなるように配慮しないといけない

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

Scala目指すのか。コップ本は挫折したな。共変半平

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

>>584
boundsに制約の意味はない
何らかが有効な境界や限界を意味し
もしくはその境界線や境界面
もしくはその範囲や領域を意味する
そこに制約(constraints)という発想や概念はない

trait boundsも同様
ある型やサブトレイトに対してそのトレイトが境界となる
敢えて境界(bounds)という単語を用いており
訳語もそのままトレイト境界が望ましい

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

>>588
ANSI C からやり直せ

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

cargo test --test-threads=1
でシングルスレッド実行出来るけど
テスト用のプログラムの中からシングルスレッドを強制する方法は？

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

例の爺さんまだ頑張ってるの？
その時間の使ってコードでも書けばいいのに

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

>>592
リファレンスには制限するためのものだとはっきり書いてあるよ
Trait and lifetime bounds provide a way for generic items to restrict which types and lifetimes are used as their parameters.
https://doc.rust-lang.org/stable/reference/trait-bounds.html

もうこれで終わりかな？

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

1) interfaceは境界
2) traitsはinterfaceに似たようなもの（although with some differences）
3) トレイト境界＝頭痛が痛い

https://doc.rust-lang.org/book/ch10-02-traits.html
> Note: Traits are similar to a feature often called interfaces in other languages, although with some differences.

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

トレイト制約に決定したね
ここからは踏み絵フェーズ

正しくトレイト制約と言えない人がリアルでもヤバイ人
際立つ言動はネットだからと思うかも知れないが、Linuxのごたごたで明白になった通りリアルにゴロゴロいる

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

決定も自己責任でいいんだよ自己責任で
決定の権限をコミュニティに握らせるな

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

>>601
オライリー「せやからトレイト制約やで」

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

>>598
なんか最初のパラグラフだけで「もうこれで終わりかな？」とか言って読むの終わりにしてそう
リファレンスは全部目を通した方がいいと思うけど英語は最初のパラグラフ大事だから判断が難しいな

一応次のパラグラフも載せとく
Bounds on an item must be satisfied when using the item.
When type checking and borrow checking a generic item, the bounds can be used to determine that a trait is implemented for a type.

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

ライフタイム境界

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

>>600
boundsに制約の意味はない
トレイト制約は間違い

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

boundsの意味は英英辞書的にはlimit
https://dictionary.cambridge.org/dictionary/english/bounds

limitの意味は最も大きい量や数値
https://dictionary.cambridge.org/dictionary/english/limit

なので境界でも良くねって思う。

あと制約はないかなぁ。
制限だったらまだわかる。

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

もはやお手上げだ
K&Rからやり直すことをお勧めする

traitを制約に使うことと
traitが制約であることは
全く別なのだ

この説明でもわからんのかな？
テキサスの小学生でもわかりそうなもんだが

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

本当だ
ゴロゴロいる

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

>>606
ジェネリックパラメータの取りうる範囲が
trait boundsによって制限されるだけであって
トレイト制限やトレイト制約という表現はおかしい
この違いが重要

trait boundsは
トレイト限界か
トレイト境界なら正しい
トレイト境界で良いと思う

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

制約と誓約なら知ってる

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

1～2人だけ制約ではないと言い張っている印象

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

>>606
まさかの制限派出現嬉しい
境界、制約、制限の中で一番平易でヨシ

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

トレイト境界　機能：型を制約します
ライフタイム境界　機能：コンパイラに寿命を示します

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

オライリーで翻訳本出すのかい?

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

>>611
どこにも記述されていない制約という言葉を唐突に持ち出してる人？
トレイト制約では根拠もなく意味も通らない

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

>>614,615
既にある
オライリープログラミング Rust「トレイト制約」

トレイト制約は天下のオライリー本での訳語なので5chに限らずSNSやgithubで普通に提案できる

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

>>616
だから根拠を示しなさい
制約に該当する英語すら見当たらない

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

QiitaやZennでも

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

>>617
本を見てくれ

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

>>619
どういう根拠が書かれているの？

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

[0、9)という半開区間があったとして
これを数値範囲の制限に使ったとしても
半開区間を制約とは言わない
半開区間で示される数値の範囲を制約に使っただけである

これで理解できるか？

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

おいおい大丈夫か日本列島？

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

>>621
それは通常 bound と呼ばないものを持ち込んで無理にこじつけてないか？

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

凡俗法則だっけ？
どうでもいい話題ほど盛り上がるってやつ

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

オライリー教は難儀だなぁ

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

>>616 が誤解している可能性と
オライリーの質が落ちてる可能性と
二つの可能性が存在する

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

trait boundsはそのトレイトによる境界・限界・領域を表している
そこには制約の概念も意味も一切ない
そのtrait boundsによってパラメータの取り得る範囲が制限を受ける

以上の二つの事実を混同して
trait boundsをトレイト制限と呼ぶのはおかしい
ましてやトレイト制約と呼ぶのは論外

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

https://github.com/rust-lang-ja/book-ja
ここ見てみたらそもそも最初はTatsuya Kawanoって人がいきなり書いた文章よね？
「トレイト境界」ってのは
それ以前にrustコミュニティでこの用語定義されてるの見たことある？
誰かrustの歴史に詳しい人ー

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

>>628
そのissueで議論されている
・既に多くの人たちがブログetc.の記事でトレイト境界と書いていた
・Scalaでもboundsは境界と訳している
・配列のbounds checkも境界チェック
・制約と訳される場合は英語がconstraint

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

わかった何がモヤってたのか
CならJIS規格があって用語も定義されてるからそれに倣えばいい
Javaなら開発元がご存命のときに日本語のドキュメントはすでにあったんでそれに倣えばいい
Rustの場合は現時点では規格が無いんよね
規格があったらそれがなんであれ書いてある用語に従うよねみんなが

>>628
それだけ？

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

規格が重視されなくなったのは多分CPythonがCでライブラリを大量生産した歴史のおかげだ

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

trait boundsの概念の理解を間違えて「トレイト制約」だと誤認してしまった人は
>>627で指摘した二つの話を混同している

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

おじいちゃんはいつも一人でわあわあ言って泡吹いてるよな

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

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

「型を制約します」って言い回しとして変じゃない？
「型”に”制約を課します」だったらまだ理解はできる。
もっとも制約を課してるわけではないので、この言い回しも適切ではないと思う。

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

>>628
そのリポジトリは比較的最近のやつで訳語は過去のを踏襲しただけ
一番最初のTRPL翻訳の該当するPRはおそらくこれかな
https://github.com/rust-lang-ja/the-rust-programming-language-ja/pull/38

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

じゃあ何だったら気に入るんだ？
型を限定しますか？

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

「型の境界を明示する / 明確に示す」とか？
これが適切かどうかはわからんけど。

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

>>630
それはそう。
その上で、 >>628 は実質的に規範の地位を確立してるからもう妥当性を検証するような段階は過ぎてる……と認識してる人とそうでない人がいるんだと思う。
出来の良し悪しを言うやつも多いがそんなことをいったら JIS だってたいしたクオリティじゃないし、それでもなお規範という「ことにする」ということで納得しないとしょうがないんだけどなぁ。

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

>>635
ご丁寧にありがとうございます(>>629さんもあらためてありがとね)

https://qiita.com/_Nnwww/items/529ad0397e4b3a59da67
> ジェネリック関数は'トレイト束縛'と一緒に使えば最高に便利になります

初めて目にしたけど
正直良いやん！って思った
トレイト束縛
最初はこれだったんやね

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

倫理的な「殺すな」「盗むな」等に比べて、言語的な規則が実在すると何故そんなに信じているのかが分からない
どっちも存在するか、あるいはどっちも存在しないと考えるのが自然ではないかね

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

>>639
束縛は変数束縛とかで使うニュアンスがすでに定着しているので違和感を持つ人が多いと思う。

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

>>639
それ以降も訳語を変えてはどうかという話は何度も出ているけど
結局のところ誰も説得力のある代案を出せなかったからそのままになっている、って感じ
確かrust-jpのslackでもいろいろ議論はあったと記憶しているけど
slackの過去ログは消えたので詳細は分からなくなってしまったね

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

今回は代案が明確だから決定した

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

主語がでかいっていうか主語が確定してない

**デフォルトの名無しさん** · 2025/03/16(日) 00:20:19.13

日本における Rust 黎明期から特に翻訳に取り組もうとした人たちが相談して決めたことより自分のほうが妥当だと思える感性が信じられない。

**デフォルトの名無しさん** · 2025/03/16(日) 01:02:58.08

>>645
どこの馬の骨ともわからん有志が対した議論もせずに
JavaやScalaの誤った訳か機械翻訳を間違って採用しただけだろ

しっかりした議論が残ってればもう少し違う見方もできるけど
これに関してはどのイシューひどいじゃん