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/01/26(日) 13:21:14.47

？ちょっと調べたらバレるくだらない嘘つくんだったらもう相手してあげないよ

**デフォルトの名無しさん** · 2025/01/26(日) 18:31:50.46

外部と内部でデータの表現形式が異なる場合
外部に従属するソフトウェアを作ってるのでなければ
可能な限り境界に近いところで変換を行うのは当然の選択

**デフォルトの名無しさん** · 2025/01/26(日) 19:05:06.86

外部とUTF-8変換する微々たるコストが深刻になる用途があるならば標準ライブラリを使わずに独自に実装すればよいだけの話
標準ライブラリはAsRef<OsStr>やAsRef<Path>でそのままstrやStringが使えるように設計されている
File::openなどでのパス指定の引数もこのAsRef<Path>がトレイト境界となっている
as_で扱える設計が望ましい

**デフォルトの名無しさん** · 2025/01/26(日) 20:54:35.44

>>220
後半の話は全然関係ないじゃん

**デフォルトの名無しさん** · 2025/01/26(日) 21:10:37.51

>>221
後半ためにはOsStringがStringを含む拡張になっていなければならない
そうなっていれば型の読み替えだけでas_refできる

**デフォルトの名無しさん** · 2025/01/26(日) 22:23:21.64

>>222
それは>>213が書いてるようにどうなってるかの話で
なぜそうなってるかの理由ではないよね

File::openはAsRef<Path>を受け取るけど
windowsならすぐにVec<u16>に変換されてる

仮にwindows向けOsStrの内部がu16ベースで
File::openがInto<Path>を受け取る実装だったとしても
処理内容は変わらない

**デフォルトの名無しさん** · 2025/01/27(月) 20:17:02.44

>>223
それは違うな
str.as_ref()と参照を読み替えるだけでOsStrになることが重要
そのためOsStrとstrのPartialEqも用意されていてコストなく比較可能
UTF-8のみであればOsStrとstrは一致することが本質

**デフォルトの名無しさん** · 2025/01/27(月) 23:21:32.51

>>224
どれも結果であって原因ではないね

>str.as_ref()と参照を読み替えるだけでOsStrになることが重要
なんで重要なの？

>そのためOsStrとstrのPartialEqも用意されていてコストなく比較可能
OsStrとstrをコストなく比較可能にするために
System Native StringをOsStrにするタイミングでコストがかかってる
コストをかけるタイミングだけの違い
OsStrとstrがコストなく比較可能でなければならない必然性は全くない

**デフォルトの名無しさん** · 2025/01/28(火) 15:31:40.54

ファイル操作なんてI/O負荷の方が高いんだからファイルパスの変換コスト気にする必要あるか？
文字コードが違う環境はwindows以外にも色々あるだろうし。

**デフォルトの名無しさん** · 2025/01/28(火) 16:58:57.81

直交する話を持ち出しても元の議論には一切影響しませんが

**デフォルトの名無しさん** · 2025/01/28(火) 20:40:46.87

一般的な話として
アスキー非互換かつサロゲートペア問題を抱えるUTF-16は欠陥品なので使用は好ましくない
UTF-16や16bitで扱うシステムはユニコードが16bit時代に決めた古いシステムがほとんどで稀に後に無知者が導入したものがある程度

Rustで文字charは正しく32bitとなっており
文字列strはネット上やファイル内でも推奨されアスキー上位互換のUTF-8になっている
さらにOsStrはそのUTF-8の上位互換となり集合的にはOsStr⊃str⊃アスキーとなっている
それさえ満たせば細かい内部実装は各OS毎に異なってよい
欠陥品のUTF-16は何も満たせずそこでも排除で正しい

**デフォルトの名無しさん** · 2025/01/28(火) 22:01:50.93

また意味のない話を始める
さすが複オジ

**デフォルトの名無しさん** · 2025/01/29(水) 00:32:12.48

OsStringの用途はファイルパスに限られたものではないけど主たる用途で性能が問題にならないというのは今の実装方法が選ばれた理由の一部ではある

**デフォルトの名無しさん** · 2025/01/29(水) 00:58:47.06

UTF16はメモリとパフォーマンスのバランスが良い
オンメモリの内部形式としては悪くないチョイス

**デフォルトの名無しさん** · 2025/01/29(水) 02:25:08.58

別に理由が無いなら無いと言えばいいのに、変にこじつけようとするから

**デフォルトの名無しさん** · 2025/01/29(水) 07:54:01.03

スレを荒し続けているUTF16信者は何がしたいの？
本気でUTF16がいいと信じているならそういうcrateを作って布教すればいい
そんな需要はないと思うが

**デフォルトの名無しさん** · 2025/01/29(水) 08:41:13.10

>>225
それは >>219 が述べるように「変換は境界で」という基本思想による。
このやり方が複雑さを避ける良い方法だというのは歴史の積み重ねで皆が実感してきたことなので今さらどうこう言っても「その話はもう終わった。蒸し返すな」という気持ちなんだよ。

**デフォルトの名無しさん** · 2025/01/29(水) 10:10:29.66

じゃあせめて「その話」がどのissueでされたかでも貼ってくれないかな

**デフォルトの名無しさん** · 2025/01/29(水) 10:45:41.27

甘え過ぎw

**デフォルトの名無しさん** · 2025/01/29(水) 11:52:20.85

ソース無しの妄想だからそう返すしかないか

**デフォルトの名無しさん** · 2025/01/29(水) 11:54:18.78

複オジはともかく質問者もまだ分かってなかったのか

**デフォルトの名無しさん** · 2025/01/29(水) 21:48:50.26

わかった
少なくともこうして容易に使えることが最低必要条件
fn OsStr::to_str(&self) -> Option<&str>
したがってOsStrはstrを含む拡張集合
それ以外に制約はなく各OS毎に内部実装は自由

**デフォルトの名無しさん** · 2025/01/29(水) 22:07:32.91

それがお前の妄想でないという根拠は？

**デフォルトの名無しさん** · 2025/01/29(水) 23:10:55.15

impl AsRef<OsStr> for str

**デフォルトの名無しさん** · 2025/01/29(水) 23:12:05.86

issueで内部が16ビットではそれが機能しないと

**デフォルトの名無しさん** · 2025/01/29(水) 23:17:05.07

機能しないと議論されて決定してる

**デフォルトの名無しさん** · 2025/01/29(水) 23:58:56.14

>>234
219と225は同一人物だぞ

**デフォルトの名無しさん** · 2025/01/30(木) 00:13:31.97

>>232
特定のプラットフォームに依存するコードはなるべく減らしたいという動機は理解できるんだよね？

可能な限り境界に近いところで外部表現と内部表現の変換を行うことがプラットフォーム依存のコードを減らすことに寄与するというのもわかるよね？

あとは外部の表現形式を内部でも維持したとしてもデメリットを上回る十分なメリットがあるかどうか
OsString/OsStrの主たる用途ではそれだけのメリットはないという判断
メリットがある用途ならOsString/OsStr以外を使いましょうということ

**デフォルトの名無しさん** · 2025/01/30(木) 00:26:18.93

str <-> OsStrの話は差異をうまく隠蔽しにくくシグニチャに影響しうるというのがあるけど仮に影響しなくても境界で変換するのが望ましいという判断は変わらなかったはず

**デフォルトの名無しさん** · 2025/01/30(木) 00:39:30.16

https://github.com/rust-lang/rfcs/pull/575
https://github.com/rust-lang/rfcs/blob/master/text/0517-io-os-reform.md#string-handling

**デフォルトの名無しさん** · 2025/01/30(木) 20:50:11.01

>>247
ありがとう、RFCのほう探せばよかったのか

> ## Wide string representation
> Downsides:
> * These conversions have inconsistent performance characteristics between platforms. (Need to allocate on Windows, but not on Unix.)

やっと納得できる理由が出てきた、これはたしかにな…いやでもなあ、直接OsString/OsStrを触るAPIがもっと充実していれば別にString/strとの変換をそこまで気にする必要もないのでは？
一気にString/str相当のAPIを実装するのも手間だし、OsString/OsStrで何かやりたかったらとりあえずString/strと変換してなんとかしてくれ、だからここではプラットフォームごとの差を付けたくない、って方針だったのかね？
とはいえ、考えられる発展としていろいろな文字列型を一般化する抽象化を作れるはずとかちゃんと書いてあるし、まあまあ納得できる経緯説明ではある
ありがとうね

> // and ultimately other functionality typically found on vectors,
> // but CRUCIALLY NOT as_bytes

…とか書いてるけど、今は普通にas_encoded_bytesとして実装しちゃってるし、結局なんだかよく分からんなあ

**デフォルトの名無しさん** · 2025/01/30(木) 23:18:13.05

>>248
>> * These conversions have inconsistent performance characteristics between platforms
こう書かれてるけどパフォーマンスという点では特にDownsideじゃないと思うんだけどね
今の実装でも発生してるし違う環境用のOsStringを1つのプログラムが実行時に混ぜて扱うわけでもないし

問題なのは内部コードにアロケーションタイミングの違いみたいなのが侵食して分岐が増えること
わかりやすい例としてはOsStr::new(“foo”)が&OsStrを返せなくてCow<OsString, OsStr>になるとか

**デフォルトの名無しさん** · 2025/01/30(木) 23:38:58.04

そうだね
だから現状の仕様で正しくて
10年間も問題視されていない
許容できない用途が仮にあるならWindows専用のクレートを作ればいい

**デフォルトの名無しさん** · 2025/01/30(木) 23:54:08.19

as_encoded_bytesの話はこれ
https://github.com/rust-lang/libs-team/issues/306

**デフォルトの名無しさん** · 2025/01/31(金) 02:25:28.04

> # Alternatives
> * A split_at(&self, pos: usize) -> (&OsStr, &OsStr) style method. This is ostensibly simpler than a slicing API. But:
> ** The OMG-WTF-8 encoding does not support this. It requires some splits to produce overlapping slices, so that left.len() + right.len() > orig.len(). The encoded bytes on one side of pos might form a valid OMG-WTF-8 string while those on the other side do not.
> *** RFC #2295 that proposes this encoding was merged five years ago (but has not been implemented).

何その絵に描いた餅を喉に詰まらせて死ぬみたいな話……

**デフォルトの名無しさん** · 2025/02/03(月) 22:01:34.61

ほとんどのシステムはUTF-8以外のファイル名があったら無視かエラーでいいからどうでもええわ

**デフォルトの名無しさん** · 2025/02/06(木) 13:08:01.16

https://mevius.5ch.net/test/read.cgi/tech/1691038333/514-528

ﾜｯﾁｮｲ付いてないとどこにでも出るな妖怪

**デフォルトの名無しさん** · 2025/02/07(金) 13:12:05.02

LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中 - TechFeed
https://techfeed.io/entries/67a52d4677bdbc0f2990eed9

争え……もっと争え……

**デフォルトの名無しさん** · 2025/02/07(金) 21:47:52.74

Linusが一喝するまで収めるの無理やろ

**デフォルトの名無しさん** · 2025/02/07(金) 22:08:06.65

そりゃドライバーはカーネルのインターフェイスに従って動作すべきだから、ラッパーなりで隠蔽すべきなんじゃないんかね。

個別のドライバーのためにカーネル側をカスタマイズするのはインターフェイスを侵食する越権行為だから、そんなのドライバーのラッパー側でやれ、と言いたくなるのはわかる。

**デフォルトの名無しさん** · 2025/02/08(土) 23:53:09.62

>>257
それは君の理解が間違っている

今回はRust製の各デバイスドライバが独自のCバインディングを持つ不便な状況を改善するためのパッチだ
つまりカーネルのC側に手を入れるパッチではなくC側は同じままで変更は一切ない
今回の件は該当部分dma_alloc_coherent()のC⇔Rustの抽象ラッパーのコードを含めるパッチだけだ
それさえメインテナーに拒否されたため大問題になっている

**デフォルトの名無しさん** · 2025/02/08(土) 23:57:46.16

デバドラはRustで書くのが普通になってきているから
そういう共通ラッパーという形のRustインターフェイスが色々と欲しいのよね
でもそれはいずれカーネル自体のRust化へ繋がる道になるから強く反対してるのよ

**デフォルトの名無しさん** · 2025/02/09(日) 00:59:41.26

普通に考えたら異種の言語が混ざるとデバッグと開発の障害でしかないからどこかで境目は必要

**デフォルトの名無しさん** · 2025/02/09(日) 06:01:46.16

>>258
メンテナーがRust用コードのメンテナンスを拒否したということじゃないの？
Rust for Linuxでサポートするような話じゃないんかね。

**デフォルトの名無しさん** · 2025/02/09(日) 06:47:59.48

>>260
異種の言語を混ぜる話なんか誰もしていない
今回の事件のパッチも異種の言語を混ぜることなくCのAPIはそのままで
その上にRustの層を作る話

In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings.

**デフォルトの名無しさん** · 2025/02/09(日) 08:50:09.78

最終的にRust側のメンテナが切れてSNSで晒したりしたのは良くなかったけど
技術的にはC側に迷惑かからないように十分配慮して、出てきた懸念も全て潰したにも関わらず
「とにかくRustに関わりたくないから却下」だったからまぁ切れるのも分かる

**デフォルトの名無しさん** · 2025/02/09(日) 09:09:11.56

>>263
そのコードはcで使えるの？
使えるならともかく、Rust専用ならメンテナーが「そんなののメンテナンスで負担増えるのは嫌だからRustドライバー側でやってくれ」というのもわかる。

Rust for Linuxはこういうのの受け皿にならんのかしらん？

**デフォルトの名無しさん** · 2025/02/09(日) 09:24:37.62

>>264
受け皿も何もそもそもRust for Linuxでやってる話だし
完全にRustドライバー側でやるからCには影響しないって言ってるわけ
具体的にメンテナンスの負担が増える理由を挙げてくれれば対応策も考えられるけど
「とにかくお前らを邪魔するためなら何でもする」って言ってるからどうしようもない

**デフォルトの名無しさん** · 2025/02/09(日) 10:38:22.52

>>265
メンテナが「Rustは俺のサポート範囲に出てこないでドライバ内で閉じてやってくれ」と言うんだから、当面はrust fir linux でドライバーのテンプレートを作るなりCバインディングサポートライブラリを作るなりすればいいんじゃないんかね。

「Rust製の各デバイスドライバが独自のCバインディングを持つ不便な状況」というのもrust fir linuxでフレームワーク作ってサポートすれば解決するし。

**デフォルトの名無しさん** · 2025/02/09(日) 10:58:29.23

互いにブラックボックス内でなにが起ってるのかわからないとすると困るけどね

コレコレこういうコードを書いたらこういう結果が出るはずなのに出ないとコード提示されても
相手が理解できなければこじれるだけ

**デフォルトの名無しさん** · 2025/02/09(日) 11:17:45.05

>>266
そこで言う当面はってのは3-4年前の状況かな
今はもう準備も整って、Mac用のAsahiLinuxとかAndroidとかフォークしてる勢には普通に入ってる段階
だからそろそろ本体にって話になってるわけだけど、拒絶されるなら彼らはフォークに戻っていくだけだとは思う

**デフォルトの名無しさん** · 2025/02/09(日) 11:46:40.81

>>256
Linusの返答も出てるな
https://x.com/lauriewired/status/1888018962811863109

**デフォルトの名無しさん** · 2025/02/09(日) 12:46:41.58

内部の問題をSNSつかって文句言うなアホ
お前が問題じゃ

**デフォルトの名無しさん** · 2025/02/09(日) 13:50:57.72

ここや他のスレでRustに意味のわからん難癖つける人が
いるのは5ちゃん民度のせいではないのがわかった

**デフォルトの名無しさん** · 2025/02/09(日) 14:20:31.41

C++に似ている部分はC++と同じ程度に批判される
それとハイブリッド的な部分
100%ガソリンで動くか100%電気で動くかどっちかにしろという

**デフォルトの名無しさん** · 2025/02/09(日) 16:28:50.86

>>268
該当コード用のメンテナがRustを使いこなすようになるか、専用のメンテナが別に現れるか、現在のメンテナが引退してRust推進のメンテナに代わるまでじゃない？

これはメンテナの複雑性管理＆管理ポリシーの問題だから、普及具合とかはあんまり関係ない。

**デフォルトの名無しさん** · 2025/02/09(日) 23:42:15.23

色んなものがRust製になっていく中
最後まで残りそうなのが巨大でモノリシックなカーネルとブラウザになりそうだな

**デフォルトの名無しさん** · 2025/02/10(月) 00:33:23.09

日本の古文漢文は残らないかもしれないが西洋では全部保存していて選択肢が増えるだけ
だから、向こうが世界の中心みたいな空気になる

**デフォルトの名無しさん** · 2025/02/10(月) 16:53:59.27

firefoxはまだrust製にはならんの？

**デフォルトの名無しさん** · 2025/02/10(月) 17:38:09.01

Linux カーネルは保守的な方針だろ。
数年前まで C89 が前提だったんだぞ。
この速度感で考えるなら Rust 導入なんてまだまだ時期尚早じゃね？

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

Firefoxのレンダリングエンジンは大分前からRust製（Servo）でしょ

**デフォルトの名無しさん** · 2025/02/10(月) 19:49:30.60

>>278
Servoにそんな完成度はない
実験レベル

**デフォルトの名無しさん** · 2025/02/10(月) 22:57:20.26

錆→癌

**デフォルトの名無しさん** · 2025/02/10(月) 22:59:57.28

Mozillaお金なさすぎて色々と切り捨てて
RustもRust Foundationへ移管されたもんな
結果的にRustにとっては中核が安定してラッキーになったけどさ

＞ 2020年にMozillaがすべてのServo開発者を解雇した後、プロジェクトのガバナンスはLinux Foundation Europeに移管された。
＞開発作業は公式には同じGitHubリポジトリで続けられており、プロジェクト自体は完全にボランティア主導です。

**デフォルトの名無しさん** · 2025/02/10(月) 23:42:58.20

C/C++その他の知識を蒸留してないわけがないから
コストもコスパもないんだよ

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

Pointers (this includes values of reference type) in Rust have two components.
- The pointer's "address" says where in memory the pointer is currently pointing.
- The pointer's "provenance" says where and when the pointer is allowed to access memory.
We have to know not only the address the pointer points to,
but also track which other pointer(s) it is "derived from".
Provenance is useful because it allows powerful optimizations.
Provenance can affect whether a program has undefined behavior.

**デフォルトの名無しさん** · 2025/02/16(日) 23:45:42.12

Rust Tokyo 2024 開催レポート
https://gihyo.jp/article/2024/12/rust-tokyo-2024-report

**デフォルトの名無しさん** · 2025/02/21(金) 06:52:59.68

edition = "2024" が来たね

**デフォルトの名無しさん** · 2025/02/25(火) 13:22:53.51

https://softantenna.com/blog/linus-rust-policy/

Linus が一喝して技術的に合理的説明のない
rust拒否は許さないことで決着か

**デフォルトの名無しさん** · 2025/02/25(火) 13:50:37.48

生メモリいじくるのが好きな人たちがいきなりrustやれって言われたらきつい気持ちはわかる
どうせメンテーなんてみんなジジイなんだし

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

rustが嫌でもやれなんて言ってないが

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

Linusの今回の発言は明瞭で
・Cだけ触りたい人はそのままRustを覚えなくてOK
・その代わりRustについて口を挟む権利はない
・CのAPIをその利用者は自由に使えてメンテナといえども用途用法に口を挟む権利はない

したがって今回もめていた「CのAPIの上にRustのAPIを設ける件」について
Cだけ触りたいメンテナは口を挟む権利はなくパッチを拒否する権利もない、ということ
大方の人々が考えていた通りに決着

**デフォルトの名無しさん** · 2025/02/25(火) 17:47:40.26

口を出せない=メンテナ失格ということと受け取った

**デフォルトの名無しさん** · 2025/02/25(火) 18:17:51.25

かつてカーネルを正しく修正した結果として (保証してない挙動に依存した) 間違ったアプリケーションのいくつかがまともに動かなくなったことがある。
そのときに Linux の理念としては技術的合理性でユーザー体験を損なってはならないということで間違っているアプリケーションに合わせて互換性が維持された。
ユーザは一方的な利用者に過ぎずカーネルに口出ししないなんてことはない。
絶対に、絶対に、絶対に、カーネルに口出しするよ。
まあそれが良いか悪いかは知らんけどな。

**デフォルトの名無しさん** · 2025/02/25(火) 18:41:48.14

>>291
そういう具体性を欠いた屁理屈言って拒否するのは
やめろと怒られてるのだね

**デフォルトの名無しさん** · 2025/02/26(水) 04:07:17.14

>>290
そういうデマを言うやつがいるとコミュニティー全体が嫌われるから止めるべき。

Linusが言っているのはせいぜい「Rustコードのメンテナじゃないだろ」ぐらいの話で、Linuxメンテナ失格とは全く言っていない。むしろメンテナが自分のメンテナンス範囲をCコードだけにするのを肯定している。
今回の件も、C APIユーザーとしてのRustコードがCコードとは独立した形で別のメンテナにメンテナンスされるんじゃないんかね。

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

着実にRust APIを増やしていこう
脱libc

**デフォルトの名無しさん** · 2025/02/27(木) 14:26:32.38

Rustは清書用

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

じゃあRoughって言語も要るな

**デフォルトの名無しさん** · 2025/02/27(木) 23:34:31.56

Rustはリファクタリングでの安定度も他より極めて高くて開発効率が良いので
まずは雑に書いて後から可読性を上げたり拡張性を上げたり実行効率性を上げたり普通に行われているね

**デフォルトの名無しさん** · 2025/02/28(金) 08:15:36.47

>>296
クレート境界をダックタイピング化した言語が欲しいわ。

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

>>291
その動作は弊社製品の仕様です
（今後も動作は維持されます）

その動作は弊社製品の問題点です
（今後動作は変更されます）

**デフォルトの名無しさん** · 2025/02/28(金) 12:19:57.96

>>298
それがC++かもしれませんね

**デフォルトの名無しさん** · 2025/02/28(金) 22:27:33.84

>>298
ダックタイピングは各異なる型を統一的に安全に呼び出せる保証が人任せだから使うべきでない
トレイト境界を指定すれば安全が保証されるがそれはトレイトすなわち他言語で言うところのインターフェースに近い存在を仮定していてダックタイピングとは言い難い

**デフォルトの名無しさん** · 2025/02/28(金) 22:51:15.56

>>301
>298のダックタイピングは静的ダックタイピングで構造的部分型のことね。
型の機能的な共通部分を部分型として統一的に扱うから、普通の型と同程度には安全かと。

**デフォルトの名無しさん** · 2025/02/28(金) 23:05:54.93

>>298
Go だと型があるインターフェイスを満たす (満たすつもり) かどうかは明示的な宣言がない。
インターフェイスで定義されたのと同じメソッドを持っていればそのインターフェイスを実装したものと見做される。

**デフォルトの名無しさん** · 2025/02/28(金) 23:49:44.86

>>302
まずその共通部分が存在する保証がない
次に共通部分があったとしてもその部分への任意のアクセスメソッドが完全に同一である保証がない
さらにダックタイピングで用意されるメソッドがその共通部分のみにアクセスされる保証がない
共通部分型方式には問題が山積み

一方でトレイト境界を用いると
共通部分を持たなくても安全に共通メソッドを増やすことができる

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

相変わらず日本語不自由だな

**デフォルトの名無しさん** · 2025/03/01(土) 08:37:01.16

言語によるとしか言えない
その言語にある道具なら、それが便利なら使って問題ないと思う
C++だと標準ライブラリでもダックタイピングをごく普通に使うけど、それに文句を言う人もいないでしょ

**デフォルトの名無しさん** · 2025/03/01(土) 08:57:54.01

C++のような古くてダサい言語は比較する意味ないだろ
ダサくて自己責任となるダッチタイピングはお似合いだが

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

Rust書きやすいって言ってるのは大体c++から移った人間でそういう人がここに集ってる
GC付きの言語から来たらそこまでは思わない

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

>>304
静的ダックタイピングとか構造的部分型はご存知で？

コンパイル時にメソッドとかプロパティとかの部分集合で互換性を判定しているので、通常の型と同じレベルで合致するよ。

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

>>304 に賛成

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

>>306
便利さと安全性は独立してるからな

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

>>310
>>304を理解できるなんて君は天才だねｗ

**デフォルトの名無しさん** · 2025/03/01(土) 13:10:29.22

A:「〇〇な言語があったらいいのに」
B:「言語によるとしか言えない」
A:「・・・」

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

Structural Typingでバイナリ境界を超えて新しいメソッドを追加できるようにしてしまうと衝突時のデメリットがメリットを上回る
Rustにcoherenceがあるのと同じ

**デフォルトの名無しさん** · 2025/03/01(土) 22:44:41.75

>>308
GCの有無は関係ない
異なる型に対するコードの共通化つまりジェネリクスの話

例えばクラスを使えば同じ基底を継承する派生同士は異なる型でも共通のメソッドやプロパティを使える
しかし同じクラス継承の関係しか扱えないのは制約がキツく各機能毎に継承で多重クラス継承など問題が多い

一方でダッチタイピングや構造的サブタイピングは無関係な型同士でも同じメソッドやプロパティがあるだけで暗黙に使える
しかし互換性がなく偶然同じメソッドやプロパティを持つ同士の利用をエラーにできない問題や暗黙であるため複雑化してくると分かりにくくなるなど問題が多い

そこで機能毎にインターフェース宣言と各型でのインターフェース利用宣言することで諸問題を解決し安全で保守しやすいコードにすることができる
そしてインターフェース名(機能名)が付くことで複数の機能の列挙や関係も宣言できるようになる
Rustではトレイトと称する

**デフォルトの名無しさん** · 2025/03/01(土) 22:55:40.18

llmの3B当たりが吐き出す文章みたいで何を言ってるのか意味不明だな

**デフォルトの名無しさん** · 2025/03/02(日) 00:27:51.62

丸一日調べてこれとか泣けてくるな
ついでにRustのトレイト問題も調べとけよ