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/04(火) 17:44:45.66

>>387
新たなトレイトを作ってメソッドを移しても破壊的な変更にならない
もちろん移すだけでは意味はないが
使う側でそのトレイト境界を用いてコードの共通化が可能となるため普通に行なわれる

**デフォルトの名無しさん** · 2025/03/04(火) 18:39:12.83

>>389
いつの時代のC++だよｗ

**デフォルトの名無しさん** · 2025/03/04(火) 23:48:22.54

>>391
昔も今もC + +のs t r i n g関数s u b s t r (開始位置, サイズ)は別の領域を確保してコピーだよ
\0終端するためにコピーは避けられないね

ちなみにライブラリ実装依存だろうけど
毎回ヒープ領域確保はコストが大きすぎるため
結果が15文字までならば静的に各16バイトの領域を事前に持っていてそこを使って頑張っていたりはする
でもそこへのコピーは避けられないね

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

>>390
うわぇー
なんでそんな嘘を吐くの？
もしかして破壊的変更の意味を知らない？

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

>>391
C++ の中だけでやるなら今は range を中心にライブラリが編成されてるから文字列の一部を取り出すのにコピーは必要ないしゼロ終端も不要だが、ここでは (古いライブラリなり API なりの都合で) ゼロ終端が必要になったときはという前提の話をしてるんだぞ。
外の世界は言語の都合に合わせて勝手に変わってくれたりはしない。
モダンな C++ を使っていても外と繋がる境界では外の都合に合わせなきゃしょうがないんだ。

**デフォルトの名無しさん** · 2025/03/05(水) 01:23:27.50

>>394
Rustの中だけでやるなら文字列の一部を取り出すのにコピーは必要ないしゼロ終端も不要だが、ここでは (古いライブラリなり API なりの都合で) ゼロ終端が必要になったときはという前提の話をしてるんだぞ。
外の世界は言語の都合に合わせて勝手に変わってくれたりはしない。
モダンなRustを使っていても外と繋がる境界では外の都合に合わせなきゃしょうがないんだ。

君の言う前提に沿えば>>389の比較は無意味

**デフォルトの名無しさん** · 2025/03/05(水) 01:31:23.03

>>395
「いつの時代の C++ だよ」に対していつの時代でもそうだよと言ってるだけ。
>>389 には興味ない。

**デフォルトの名無しさん** · 2025/03/05(水) 01:45:32.35

>>395
あらためて >>389 を見たら「ゼロ終端にするにはコピーが必要なのは同じだ (型の整理の仕方は違っても)」というのが趣旨だから結論が同じなのは意図どおりだろ。

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

>>389
CString::new(string)で0終端してくれて
c"ABCDE"は最初から0終端されてて便利だね

// 固定文字列は c"..." リテラルで作成
let c1 = c"ABCDE"; // &CStr型
// 文字列を組み立てる場合はStringで作成しておいて
let s = ('A'..='E').collect::<String>();
// そのStringを消費して0終端してくれる (途中に0があるとError)
let c2 = CString::new(s).unwrap();
// 左右どちらも &CStr型の c"ABCDE" で一致
assert_eq!(c1, &*c2);

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

このスレいつからﾜｯﾁｮｲとかIDとか無くなった？

**デフォルトの名無しさん** · 2025/03/05(水) 11:21:05.48

隔離スレにそんなもん必要ねえよ

**デフォルトの名無しさん** · 2025/03/05(水) 12:18:55.35

ﾜｯﾁｮｲとかIDがあると自演するのに不便だからいらない

**デフォルトの名無しさん** · 2025/03/05(水) 12:31:30.46

本スレどこ？

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

まともに他人の意見を尊重できる人たちが集まり議論が行われればそこが本スレになるだろうが、期待するだけ無駄じゃろ

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

>>398
自分で'\0'プッシュすればええやんと以前は思っていたけど
ミスがないことを型システムに保証してもらえる安心感

**デフォルトの名無しさん** · 2025/03/05(水) 23:13:15.92

>>402
DかZにおいで

**デフォルトの名無しさん** · 2025/03/06(木) 07:37:15.29

自分でNULL終端しようとする老害は
安全を保証する型システムと相性悪い

**デフォルトの名無しさん** · 2025/03/06(木) 15:59:09.42

[c_char]が[u8]だと思ってたら[i8]だったでごじゃる

**デフォルトの名無しさん** · 2025/03/06(木) 17:21:49.66

c_charは処理系依存っぽいからu8かi8に決め打ちするならc_ucharかc_scharにキャストした方がいい
ターゲット変更した時にコンパイラに文句言われる可能性がある

**デフォルトの名無しさん** · 2025/03/06(木) 18:39:39.08

\0終端じゃないと困るってcやc++から来た人だろ…
老害っているんだな

**デフォルトの名無しさん** · 2025/03/06(木) 19:04:31.26

>>409
OS の要求ならしょうがないだろ……
適当なラッパー作るにしてもそのラッパーの中ではゼロ終端にしないわけにはいかん。

**デフォルトの名無しさん** · 2025/03/06(木) 23:08:05.29

>>398
あとはCString/CStrからの変換だな
&[u8]として扱えるのは当然として

// CStringを消費して Stringとして扱う (非UTF8だとError)
let c = CString::new([b'A', b'B', b'C', b'D', b'E']).unwrap();
assert_eq!(c.into_string().unwrap(), String::from("ABCDE"));

// &Cstrを &strとして扱う (非UTF8だとError)
assert_eq!(c"ABCDE".to_str().unwrap(), "ABCDE");

// &Cstrを Cow<str> にする
// UTF8なら &strとして扱い Cow::Borrowed(&str)型
let cow = c"ABCDE".to_string_lossy();
assert_eq!(cow, Cow::<str>::Borrowed("ABCDE"));
// 非UTF8部分があると U+FFFD置換Stringにして Cow::Owned(String)型
let cow = c"AB\xccDE".to_string_lossy();
assert_eq!(cow, Cow::<str>::Owned(String::from("AB\u{FFFD}DE")));

いずれも'\0'の存在は気にしなくていい

**デフォルトの名無しさん** · 2025/03/07(金) 23:55:18.15

&selfで読み取り参照のまま、別の型の読み取り参照に読み替えるのはもちろん、
selfで消費してしまい、確保メモリをそのまま活用して、別の型に読み替えるのが効率ええんやな

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

>> http://mevius.5ch.net/test/read.cgi/tech/1708677472/784

Ruby (が採用している CSI 方式) での文字列オブジェクトはそれぞれどの文字コードであるかの情報を持っていて処理系は各文字コードの処理方法を知っている。
つまり文字列を扱うあらゆる箇所で様々な文字コードごとの処理をやってる。
それが先進的か？
文字コードが統一できない世界でも「なんとかする」方法だろ。

内部的には統一した文字コードで扱い、様々な文字コードを扱いたければ入出力の段階で変換するというのが Rust 的なスタイルを含む現代的なプログラムが目指すところで、そのために Unicode はあるゆる文字コードから「変換可能であること」を指向してる。
とはいえ、これが先進的と言えるわけでもなく総合的に考えて現代の事情に合うやり方ってだけだ。

様々な文字コードの変なところも含めて Unicode に取り込んでいるのは既存のテキストのデータを (情報を失うことなく) 移行できなきゃ Unicode に統一されていかないからで、同じ駄目なら統一されていないことによる駄目さより統一されてる駄目さのほうがかなりマシという価値観による。
いろんな駄目さに個別に対処するのではなくデカい駄目に皆で立ち向かう。

人間の言語が数千年・数万年の歴史的経緯の積み重ねなので文字も駄目だし文字コードも駄目。
根本的に駄目なものはどう扱ったって駄目。
綺麗なやり方で扱わないのは綺麗なやり方が存在しないから。。

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

AIで3行程度にまとめてから書き込んてくれる？

**デフォルトの名無しさん** · 2025/03/08(土) 22:27:54.11

ネットもファイルもUTF-8で統一しちゃうのが吉
外部のcharset=Shift_JISとか扱わないといけない分だけencoding_rs _io

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

>>356
>>375
>既にimpl Tにあるのだからimpl Trait for Tへ移動させるだけだぞ

pub 付いてると知名的なので doubt

**デフォルトの名無しさん** · 2025/03/10(月) 08:58:57.66

crateとかdocsの事考えるとそんな単純な話じゃないんだよ
実践的なコード描いてない人か

**デフォルトの名無しさん** · 2025/03/10(月) 12:17:05.04

歴史的にマクロ＝悪の固定観念もってるプログラマも多い気がするから
macro_rules!()はtemplate!()に改名した方がいいかもしれんね
impl Traitとかマクロ使わないと面倒な場合が多い

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

Rustってfor_eachのclosureのなかでbreak出来ないのです

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

>>418
名前は Scheme の syntax-rules から持ってきたんだと思う。

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

>>419
map_whileやtake_whileか
try_for_eachやtry_foldを使えば？
ControlFlowを使って自分で作る方法もある

**デフォルトの名無しさん** · 2025/03/11(火) 19:10:27.26

>>419
クロージャは(変数をキャプチャできる)関数の一種なのでbreakなんて概念はない
for_eachはクロージャを引数に取る高階関数なのでbreakなんて概念はない
次々とやってくる「全ての各エレメント」に対して何度もそのクロージャを呼び出すだけなのでクロージャで早期returnしようとしても全てのエレメントに対して処理される
やりたいことはおそらく次々とやってくるエレメントの途中で処理を終えたいのだろうからfor_eachではなく以下のイテレーターメソッドを使う

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

>>419
中断条件を分離できるならばイテレータを返してくれる(そして他のイテレータメソッドを繋げられる)以下を使うのがベター
take(n)　最初のn個だけ
while_some()　OptionがSomeの間だけ
take_while(f)　fが真の間だけ
　その後に続きを漏れなく使いたいときは
　　take_while_ref_inclusive(f)
　　take_while_ref(f)
　　peeking_take_while(f)
map_while(f)　変換しながらfがSomeの間だけ
scan(init_state, f)　状態を持ちながら変換しながらfがSomeの間だけ

いきなり結果を(ResultやOptionやControlFlowで)返したいならば
try_for_each(f)　fが中断(ErrorやNoneやBreak)になったら終えてそれを返す　中断なければ()を返す
try_fold(init_state, f)　状態を持ちながら同上　中断なければ状態を返す
try_collect()　iterとitertoolsで仕様が異なりiter版はnightlyのみだけど　中断になるまでをcollect

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

要点をまとめる力って大事だな

**デフォルトの名無しさん** · 2025/03/12(水) 00:42:42.49

クロージャが関数の一種なのか関数がクロージャの一種なのかそれが問題だ

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

大雑把な説明としては、
クロージャは(キャプチャがある)関数の一種、
関数は(キャプチャのない)クロージャの一種、
と言っても構わないが、
実際には、
Fnで使えるのはsafeなfnのみ、
fnにコアースできるのはキャプチャのないFnのみ、
といった関係。

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

クロージャと言えばFn(&mut T) -> ()みたいな定義が許容されてるのはなんでなの？
間違った使い方をすればownershipルールに違反してエラーにはなるだろうけどFnMut(&mut T)->()にするよう弾いたほうがよくない？

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

ここ観るのが早い
https://qiita.com/lo48576/items/34887794c146042aebf1

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

試しに見てみたがリファレンスと同じ情報の劣化版なので見る価値なし(個人の感想です)

>try_for_each(): Iterator<T> -> (T -> Try<B=()>) -> Try<B=()>
>失敗するかもしれない関数について for_each 的な操作を行う関数。
>これといって特記すべきこともないが、今まで for で書いていたものがシンプルにできる、ありがたい関数である。
>もし成功時にも何らかの意味ある値を返したいのであれば、 try_fold を使うべきである。

例えばtry_for_eachの最後の行の解説とか
ツッコミどころが盛り沢山

**デフォルトの名無しさん** · 2025/03/12(水) 18:16:35.74

>>427
クロージャの引数は、毎回変わるのだから常に何をしても自由であり、引数を消費してしまおうが、可変参照があって参照先を書き換えようが自由。
クロージャで制限がありうるのはキャプチャした値のみ。

Fnはキャプチャした値がある時に、それを読み取り参照しようが自由だが、書き換えたり消費したりはできないという意味。
FnMutはキャプチャした値を読み取り参照しようが書き換えようが自由だが、消費してはいけないという意味。
FnOnceはキャプチャした値を消費しようが書き換えようが参照しようが自由という意味。
キャプチャ値を消費をしてもしなくても自由ということは、2回以上の実行は不可で、そのクロージャの実行は1回だけという意味、だからFnOnceという名前。

トレイト間の関係は「Fn: FnMut」かつ「FnMut: FnOnce」、つまりFnOnceは他の最上位のスーパートレイト。
集合で見ると、FnOnce⊃FnMut⊃Fnとなり、Fnが最も制限がきつくて集合としては小さい。
蛇足だが、fnはさらに制限がきつくて読み取り参照キャプチャすら許容されないから、Fn⊃(safeなfnの集合)となって、safeなfnは任意のクロージャの位置で代わりに使える。

例えば、LazyLock::new(f: F)のような、1回しか指定クロージャが実行されない高階関数では、最も緩いFnOnceでトレイト境界「F: FnOnce」を指定できる。
逆に何度もクロージャが実行されるIterator::fold(init, f: F )では、初期値initは消費されるが、fがキャプチャした値が消費されては困るためFnOnceではダメで「F: FnMut」となり、fの引数二つは毎回消費できる。

**デフォルトの名無しさん** · 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

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