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/04(土) 12:23:29.13

>>154
他人が書いたコードの保守しやすさはGoより上だと感じてるけどな
型含めてコード上に情報が豊富で作者の意図を取りやすいから
かなり巨大なOSSでも割と楽にプルリクとか出せる

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

>>155
「自分がRustに慣れてるなら」それは自分も同意
自分の意見は
・Rustは分かるようになるまでが大変
・理解できれば開発者にとって強力な言語
で、「Goの方が向く」というのはとっつきやすさを含めた話のつもりで書いた
他言語の経験者から見たら、たぶんRustは型やトレイトの意味を理解するのが難しいし、参照などのルールを理解しないとコンパイルすら通らないから、Goの方が触りやすいんじゃないかと思う

Arc, Rc, Cell, Mutex とかの型は分かる人にとってはmeaningfulだけど、初学者がすぐに分かるものではないと思う

**デフォルトの名無しさん** · 2025/01/04(土) 13:59:36.84

>>156
単純にメンテする人員を確保しづらいという意味ならそれはそう

**デフォルトの名無しさん** · 2025/01/04(土) 22:40:45.82

rustのいい所はresultやoption.その他色々な型について文脈が大体決まっていること。なので慣れると人が書いたコードでも読みやすい。c#やjavaとの比較であれば開発効率は大体同じか、勝っているぐらい。nullや例外がある言語はプログラムがどうしても汚くなる。
rustはaiにコード生成させた時の品質も割といい。コンパイルエラーでても対応方法が具体的なのでそのままメッセージをaiに渡すだけで直る。

**デフォルトの名無しさん** · 2025/01/04(土) 22:49:58.13

AIが当たり前の時代においてはコードの記述量そのものは開発効率に直結するものではなくなる。どの言語でも似たような事は出来る。でも作られたコードが、正しいかどうかは別の問題。
AIはたまに嘘を付くので、それをコンパイラで厳密にチエックする必要がある。そういう意味では関数型言語へのシフトは進むし、rustはいい位置にいると思う。

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

関数型関係ないから

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

>>159
関数型である部分ではなく
Rustが安全性にも役立つ史上最強の型システムを構築したことが決め手かな
特にトレイトそしてトレイト境界
さらに例えばSendやSyncといった概念的なトレイトなど

**デフォルトの名無しさん** · 2025/01/05(日) 00:44:18.92

そうなんだ、Rustってすごいんだね！

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

関数型関係ないから

**デフォルトの名無しさん** · 2025/01/05(日) 13:34:15.55

お前ら9連休はちゃんと楽しめたか？

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

九連休に一回もコード書いてない陽キャはこのスレ書き込み禁止な

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

体力落ちないように散歩しまくってたら脚の裏に豆出来たよ

**デフォルトの名無しさん** · 2025/01/05(日) 18:46:31.56

陰キャなのに今年のコード書いてなかった

fn main() {
println!("{}年", (0..10u64).map(|i| i.pow(3)).sum::<u64>());
println!("{}年", (0..10u64).sum::<u64>().pow(2));
}

sum()の型アノテーション外せないの？

**デフォルトの名無しさん** · 2025/01/06(月) 00:22:47.46

>>167
型アノテーションは必要。
オーバーフローしない十分に大きな型を選定しなきゃならないから。
浮動小数点ならオーバーフローはしないが必要な精度を推論しようがないことにかわりない。

**デフォルトの名無しさん** · 2025/01/06(月) 00:30:50.77

その論理は明らかにおかしい

**デフォルトの名無しさん** · 2025/01/06(月) 03:11:05.95

0..10がu64なんだからsumの結果も当然u64だろうという気持ちにはなる

**デフォルトの名無しさん** · 2025/01/06(月) 08:35:26.36

そこは指定必須
例えばu64の和をu128で求める型を以下のように増やせるから無指定を許すとコードが曖昧になる

struct MySum(u128);

impl std::iter::Sum<u64> for MySum {
fn sum<I: Iterator<Item = u64>>(iter: I) -> Self {
iter.fold(MySum(0), |sum, n| MySum(sum.0 + n as u128))
}
}

fn main() {
// u64の和をu128で計算できる
let x = [u64::MAX, u64::MAX].into_iter().sum::<MySum>().0;
assert_eq!(x, u64::MAX as u128 * 2);

// このコードはデバッグモード時にoverflowして悪手
let x = [u64::MAX, u64::MAX].into_iter().sum::<u64>();
assert_eq!(x, u64::MAX - 1);

// ラップアラウンドさせたいならこうする
use std::num::Wrapping;
let x = [u64::MAX, u64::MAX].into_iter().map(|n| Wrapping(n)).sum::<Wrapping<u64>>().0;
assert_eq!(x, u64::MAX - 1);
}

このように必ず型を指定して使い分けをする

**デフォルトの名無しさん** · 2025/01/06(月) 16:43:43.88

Monoidを先に整備すればこんなことにはならずに済んだろうに

**デフォルトの名無しさん** · 2025/01/06(月) 17:02:00.56

>>171
そういうのは本来sumの役割じゃなくないかという気持ち

**デフォルトの名無しさん** · 2025/01/06(月) 18:43:17.81

オーバーフローとかは関係なくて型システムの制約と標準ライブラリの実装方法の問題だよ

**デフォルトの名無しさん** · 2025/01/06(月) 19:00:20.90

sum()の戻り値の型をIterator::Itemに固定するとItemが参照型の場合に対応できないな

**デフォルトの名無しさん** · 2025/01/06(月) 21:13:46.20

そら固定したらダメだよ

**デフォルトの名無しさん** · 2025/01/06(月) 21:49:35.38

ジェネリクスで良いとは思うけど、デフォルトの型として元の型になってくれると便利な気はする
参照の場合とかは、数値型なら .copied() で値にできるし

**デフォルトの名無しさん** · 2025/01/07(火) 23:41:33.61

>>177
copy可かつcopyでコスト増にならないのはプリミティブな数値型だけだよ
巨大な整数値やタプルや行列などもありうる
例えば std::simd::Simd のimpl Sumでも参照を扱ってるね
impl<'a, const N: usize> Sum<&'a Simd<u32, N>> for Simd<u32, N>

**デフォルトの名無しさん** · 2025/01/08(水) 00:21:31.60

もうfoldでいい気がしてきた

fn main() {
use std::ops::Add;
println!("{}年", (0..10u64).map(|i| i.pow(3)).fold(0, u64::add));
println!("{}年", (0..10u64).fold(0, u64::add).pow(2));
}

３乗の総和＝総和の２乗の証明は今年の入試で狙われそうだな
帰納法使えば簡単だけどn(n+1)/2の導出からだとだるい

**デフォルトの名無しさん** · 2025/01/08(水) 23:11:07.72

そのSimdのSum実装のこれを見てそこに落ち着いたのか
iter.fold(Simd::splat(0 as $type), Add::add)

**デフォルトの名無しさん** · 2025/01/11(土) 08:43:38.04

Rust排除のためのMozilla潰しが始まったか？

GoogleとLinux FoundationがChromiumの開発と維持を支援する基金「Supporters of Chromium-Based Browsers」を設立、MetaやMicrosoftなども参加 - GIGAZINE
https://gigazine.net/news/20250110-supporters-of-chromium-based-browsers/

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

Chromium プロジェクトが Rust の利用をサポート
https://developers-jp.googleblog.com/2023/02/supporting-use-of-rust-in-chromium.html

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

Rust を導入する目的は、シンプルで（IPC を使わない）安全な（全般的に C++ よりも複雑でなく、サンドボックスでメモリの安全性に関するバグは発生しない）形で 2 の法則を満たすことにより、

**デフォルトの名無しさん** · 2025/01/11(土) 10:08:09.58

Rust は、Mozilla がブラウザを書くために特別に開発したものなので、このテクノロジーが Chromium でようやく使われ始めるようになるのは、理にかなったことです。
システムソフトウェア業界に莫大な貢献をしてくださっている Mozilla に感謝いたします。
Rust は、安全性とパフォーマンスの両方を言語に期待できることを見事に証明しています。

**デフォルトの名無しさん** · 2025/01/11(土) 10:21:28.46

むむっ

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

そもそもMozillaはRust開発者の大半をリストラしてしまったし
すでに単なる1ユーザ企業に過ぎなくて、Rustの発展にはあんまり関係なくなってる
どちらかというとMDNを維持できるかとかの方が重要そう

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

GoogleはChromeが独占禁止法違反にならないようにFirefox支援しててMozillaは生きててもらわなきゃならん
デフォルトの検索エンジンに採用する見返りにGoogle社から受け取ってる金がMozillaの収益の90%を占めるから潰すのはその金を絞るだけでいい

**デフォルトの名無しさん** · 2025/01/11(土) 12:13:12.32

>>187
おまえ日本語不自由なら無理に書き込まなくてもいいんだよ？

**デフォルトの名無しさん** · 2025/01/11(土) 12:35:47.49

>>188
お前には難しかったか
すまんな

**デフォルトの名無しさん** · 2025/01/11(土) 12:37:03.90

添削してあげる

GoogleのChromeが独占禁止法違反にならないように対抗馬のFirefoxにある程度台頭してもらう必要がある
そのためGoogleはMozillaを投資している
投資の一例としてMozillaはデフォルトの検索エンジンに採用する見返りにGoogleからMozillaの収益の90%を占める投資を受け取ってる
仮にGoogleがMozillaを潰すのならその投資を絞るだけでいい

**デフォルトの名無しさん** · 2025/01/11(土) 12:38:54.31

訂正

誤そのためGoogleはMozillaを投資している
正そのためGoogleはMozillaに投資している

**デフォルトの名無しさん** · 2025/01/11(土) 12:49:21.17

いずれも着実にRust化

**デフォルトの名無しさん** · 2025/01/11(土) 12:57:56.78

>>190
俺より頭が良さそう
尻拭いしてもらってすまんな

**デフォルトの名無しさん** · 2025/01/11(土) 16:20:18.17

ところがMozillaに資金援助してるのが
独禁法違反ともめてるわけだ

**デフォルトの名無しさん** · 2025/01/12(日) 23:53:09.91

ChromeもMozillaも各々Rust化へ向かってるなら
今後はここでもう揉めなくて済むな

**デフォルトの名無しさん** · 2025/01/13(月) 05:20:11.26

>>189
結局添削されてるな
ガイジ乙

**デフォルトの名無しさん** · 2025/01/13(月) 13:52:02.59

>>188
あなたは頭が不自由なのですね判ります

**デフォルトの名無しさん** · 2025/01/13(月) 16:13:11.82

Rust 1.84.0でprovenance関係が安定化されてるね

**デフォルトの名無しさん** · 2025/01/18(土) 10:00:11.55

Rustで描かれてるMozillaがめっちゃ不安定なんすけど

**デフォルトの名無しさん** · 2025/01/18(土) 10:07:56.33

>>199
Mozillaのメモリ管理や中核部分はC++で書かれている

**デフォルトの名無しさん** · 2025/01/19(日) 17:48:38.01

＞2016/07/20 まとめ：Firefox 48 には、Rust で書かれたコードが初めて含まれます。以降のバージョンにも Rust での実装が予定されている部分があります。
10年掛けてまだ置き換わってないってどういう事なの

**デフォルトの名無しさん** · 2025/01/19(日) 18:43:58.99

現場を動かすほどの言語じゃなかったってこと
いずれ忘れ去られていくだろうねｗ
必死で宣伝するやつはしばらく残るだろうけど

**デフォルトの名無しさん** · 2025/01/19(日) 18:56:23.31

Rust化を進めようとしているのはChromeの方だよ
ソース >>182 >>184

**デフォルトの名無しさん** · 2025/01/19(日) 21:30:19.41

>>201
単純に考えてその時点で約20年積み上がってからね

**デフォルトの名無しさん** · 2025/01/19(日) 21:49:11.92

firefoxシェアほとんど無くなって自立収入ではやっていけなくて
独占禁止法を逃れるためのGoogleからの資金で開発やってるから
基本部分は変えずに独自機能の強化の方に力を入れてるんじゃないかな

**デフォルトの名無しさん** · 2025/01/19(日) 21:58:50.96

GoogleはRustでXilemやってるね

**デフォルトの名無しさん** · 2025/01/25(土) 15:49:13.35

WindowsのOsStringってなんでUTF-16直接保持しないであんな面倒なことやってるんだろ

**デフォルトの名無しさん** · 2025/01/25(土) 20:21:28.98

>>207
Rustは時代に応じて文字列をUTF-8で扱っていてString型には必ず正規なUTF-8が入ることが保証される
しかし外の世界は魑魅魍魎でUnicodeですらないものを扱えないといけない
ファイル内容やネット通信でUTF-8以外が定められてるならencoding_rsを使って明示的に変換しながら読み書きする

**デフォルトの名無しさん** · 2025/01/25(土) 20:22:51.37

>>207
一方で問題となるのはファイルシステムのパス等だ
OS環境毎に異なるプログラムは書きたくないからコード上はString型つまりUTF-8で統一して扱いたい
パスがUTF-8自体もしくはUTF-8に1対1で対応するUTF-16等ならプログラム中はString型(＝UTF-8)で扱えてうれしい
しかしパス内にはUTF-8に変換できないものも含まれている可能性があるためOsString型(＝UTF-8＋α)として区別して扱う

**デフォルトの名無しさん** · 2025/01/25(土) 20:30:47.77

>>207
OsString型は以下の2つを満たす抽象的な型となっている
正規UTF-8のみを含むならばコスト無しでString型に変換できて逆にString型からは常にOsString型にコスト無しで変換できる
各OS環境で扱える全ての表現と1対1に対応できる(特に正規なUnicodeならばUTF-8に対応する)
この1対1が重要でありUnicodeでない場合も読み書きしての同一性が保証される
これらを満たせば内部の構造は自由でありユーザープログラムがその構造に依存することはなく構造を知る必要もない

**デフォルトの名無しさん** · 2025/01/25(土) 20:42:28.32

>>207
Windows OSのUTF-16環境であってもユーザープログラムは環境の違いを気にせず統一して扱えるようにString(＝UTF-8)とOsString(＝UTF-8＋α)で扱う
そのため正規なUTF-16はUTF-8に変換して内部で扱うことになる
しかし実際には任意の16bit列がパス等に現れることも可能なのでUTF-16以外の場合も1対1にOsStringに変換できなければならない
この任意の16bit列にはUTF-16のみの場合も含まれるため区別してWTF-16と呼ぶ
つまりWTF-16＝UTF-16＋αの関係になっている
あとはそれと1対1に対応するWTF-8＝UTF-8＋αを上手く定義してやれば前述の性質を満たす内部構造が完成する
以上おわり

**デフォルトの名無しさん** · 2025/01/25(土) 22:15:52.59

> Windows OSのUTF-16環境であってもユーザープログラムは環境の違いを気にせず統一して扱えるようにString(＝UTF-8)とOsString(＝UTF-8＋α)で扱う

OsStringの内部エンコーディングがWTF-16だと統一的に扱えないと言いたいの？

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

どうなっているか、ではなく、なぜそうなっているか

**デフォルトの名無しさん** · 2025/01/25(土) 23:56:53.55

String <-> OSString <-> System Native String

右の変換コストよりも左の変換コストを下げることを優先してる
そのほうが標準ライブラリ内部で共通の実装や似通った実装を使いやすい

**デフォルトの名無しさん** · 2025/01/26(日) 00:33:00.73

System Native Stringは直接取り扱わず、OsStringでラップして扱うのが原則なら
ゼロコスト抽象化の観点から言えば右の変換コストをゼロにするべきでは？
左の変換は必ず行うとは限らないのだから

**デフォルトの名無しさん** · 2025/01/26(日) 00:38:12.14

というか、Windows以外なら実際右の変換が実行時チェック無しのゼロコストになってて、左の変換時にチェックしてるんだから、その説明には合わないじゃないか
どこにそんな説明が書いてあるんだ

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

>System Native Stringは直接取り扱わず、OsStringでラップして扱うのが原則なら
別にそんな原則ない
OsStringで楽できないなら使わなくてもいいよ

>ゼロコスト抽象化の観点から言えば右の変換コストをゼロにするべきでは？
それは君がマルチプラットフォーム対応のライブラリを維持管理する立場で考えず
Windows中心でしか物事を見てないからだよ

>というか、Windows以外なら実際右の変換が実行時チェック無しのゼロコストになってて、左の変換時にチェックしてるんだから
間違って理解してるね

>どこにそんな説明が書いてあるんだ
公式ドキュメント

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

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