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/

**デフォルトの名無しさん** · 2024/12/17(火) 15:54:52.82

>>121
自分はバカだと自覚したほうがいいぞ
ソフトウェア開発するならな

**デフォルトの名無しさん** · 2024/12/17(火) 16:01:39.84

>>122
それは大変によくわかる。
自分で書いたものすら意味わからんようになるのは普通のことだからな……。

だから意図を表現することが大事で、小さなロジックの断片にでも名前を付ける。
その状況を表すための名前 (専門用語) こそが大事。
訓練されていない人にとって平易であることとは違う。

**デフォルトの名無しさん** · 2024/12/17(火) 16:33:22.09

>>116
現状追認主義なのに推奨されてる用量・用法は守らず動くだけのコードを披露したがるのは理解できないんだが

**デフォルトの名無しさん** · 2024/12/17(火) 17:43:30.54

ママに褒めてもらいたい幼児の心理だよ
わかりやすいだろ

**デフォルトの名無しさん** · 2024/12/17(火) 20:27:48.43

>>117
「ごっちゃに書いて見通しの悪いコードにはせずに、
高階関数のメソッドチェーンにして、
各々のメソッドで個別に関数またはクロージャで処理を指定する。」
ここまでは共通認識でいいんだよね？
万が一これにも反対の人がいるならばまずは代案を明示的に出してほしい

以上の共通認識の上で
語彙の問題という話が出ているからメソッド名の付け方に問題があるということなのか？
それともメソッドが多すぎる(機能が多すぎる)またはメソッドの分別の仕方に問題があるということなのか？
まさか高階関数がわかりにくいという話ではないと思うが

**デフォルトの名無しさん** · 2024/12/17(火) 21:50:43.67

なんでもメソッドチェーンで繋げればいいわけでもなければ
なんでも分割して書けばいいわけでもない
ケースバイケース

一番ダメなのは慣習や暗黙の了解を無視したコード
>>104や>>110はその一番ダメなやつ

つかこんな基本的なことから説明させようとするなよ

**デフォルトの名無しさん** · 2024/12/17(火) 22:05:47.16

>>127
んでお前ならどう書くんだ？
Rust使った新システムで慣習や暗黙の了解はまだない時に自分で考えてソース書くときはどうするんだ？

**デフォルトの名無しさん** · 2024/12/17(火) 22:08:10.40

>>127
また自分勝手な慣習や思い込みの暗黙の了解かよ

**デフォルトの名無しさん** · 2024/12/17(火) 22:18:10.64

vecs.iter().map(|x| x.iter()).flatten().filter(...)

みたいなのは書いてて気持ち良いけど、全員が賛同するわけではないよな
Rustの公式のドキュメントだって関数型スタイルの書き方と手続き型スタイルの書き方の両方を紹介してるわけだし
そういう「高度な書き方」をバッサリ切り捨ててるGO言語が人気というのもそう

**デフォルトの名無しさん** · 2024/12/17(火) 22:20:51.38

>>127
具体的に何を問題視してるのかわからん
Mutexを使わずに効率よく実装できるケースのようにみえるが
初心者入門向けと書かれてるからMutex利用もアリだろう

**デフォルトの名無しさん** · 2024/12/17(火) 22:42:34.79

>>130
そのコード自体はともかく
そういうメソッド連鎖は標準ライブラリや有名クレートのソースにいくらでも出てくるぜ
まずはソース読んでみな

**デフォルトの名無しさん** · 2024/12/17(火) 23:29:57.24

>>132
自分も好みとしては関数スタイルを使うよ
だけど >>126 のような「それが正しい形であり、みんなそちらを使うべき」みたいな言説はあほらしい
有名どころのOSSのコントリビューターだって、利用者からの質問への回答やチュートリアルでは「for文で一つずつ要素を Vec に push_back で詰める」コードを示すことも実際にある

Rust開発者は関数スタイルを好む人も多いと思うけど、それは好みの域を出ないと思う

**デフォルトの名無しさん** · 2024/12/18(水) 09:42:19.11

まあ存在する以上はユースケースがあるってことだからな。

**デフォルトの名無しさん** · 2024/12/18(水) 12:59:18.01

コードゴルファーのために存在してるわけじゃないからな

**デフォルトの名無しさん** · 2024/12/18(水) 13:17:46.53

そろそろitertoolsを標準ライブラリ化する話はないのか？

**デフォルトの名無しさん** · 2024/12/18(水) 18:37:10.88

個別に取り入れられてる
まとめて標準化はない
棲み分け

**デフォルトの名無しさん** · 2024/12/18(水) 19:09:54.98

>>127
そのマルチスレッド対応コードに
指摘の「慣習や暗黙の了解を無視したコード」とやらが見当たらないのだが
そもそも慣習や暗黙の了解とはどういう意味で使ってる？

>> マルチスレッド対応するなら
>> まず初心者入門向け版としてはCellをMutexに変更で動く
>>
>> fn new_id() -> Option<usize> {
>> static ID: Mutex<usize> = Mutex::new(0);
>>
>> let mut id = ID.lock().unwrap();
>> id.checked_add(1).inspect(|&new_id| *id = new_id)
>> }

**デフォルトの名無しさん** · 2024/12/19(木) 11:45:17.60

こういう C のコードを Rust で描く場合どうやればいい？
https://www.youtube.com/watch?v=n2Q1Sp7iew4
もちろん unsafe 利用 ok として

**デフォルトの名無しさん** · 2024/12/19(木) 11:55:22.77

型のキャストは
std::mem::transmute

**デフォルトの名無しさん** · 2024/12/19(木) 12:16:13.05

assert_eq!((3.14_f32).to_bits(), 0b1000000010010001111010111000011_u32);
assert_eq!(f32::from_bits(0b1000000010010001111010111000011_u32), 3.14_f32);

**デフォルトの名無しさん** · 2024/12/20(金) 15:29:01.33

JAIST、「並行量子通信プロトコル」の完全な自動形式検証を実現
http://news.mynavi.jp/techplus/article/20241220-3090485/

**デフォルトの名無しさん** · 2024/12/22(日) 22:27:16.01

>>138
中級者向けにはこれでええんかね

fn new_id() -> Option<usize> {
static ID: AtomicUsize = AtomicUsize::new(0);

let mut old_id = ID.load(Relaxed);
while let Some(new_id) = old_id.checked_add(1) {
match ID.compare_exchange_weak(old_id, new_id, Relaxed, Relaxed) {
Ok(_) => return Some(new_id),
Err(updated_old_id) => old_id = updated_old_id,
}
}
None
}

**デフォルトの名無しさん** · 2024/12/23(月) 22:20:47.40

Rustに興味出てきたからとりあえず、とほほさんのサイトに目を通してみたんだけど
…もしかしてあの方、非同期処理と並列処理をごっちゃに理解している？

https://www.tohoho-web.com/ex/rust.html#async-await

**デフォルトの名無しさん** · 2024/12/23(月) 22:54:25.61

>>143
lock freeはそう
今回のアルゴリズムはRelaxedでも大丈夫だがmemory orderingに注意を要する

>>144
executor (runtime) とそこでの使い方次第
single thread で並列(parallel)なく並行(concurrent)のみも可能であるし
それをmulti threadで並行並列も可能であるし
blockさせて並行なく専属並列も可能

**デフォルトの名無しさん** · 2024/12/28(土) 15:51:05.67

Rustしか勝たん

**デフォルトの名無しさん** · 2024/12/28(土) 17:09:23.73

こういうアホが湧いてきたときがピークだな

**デフォルトの名無しさん** · 2024/12/28(土) 17:20:50.92

WebAssemblyはRustが主流なイメージだけど実際どんなもんだろ

**デフォルトの名無しさん** · 2024/12/28(土) 18:28:20.06

linuxカーネルがシェルスクリプトの付属品にならなかったのはシェルを変更できるから
だがjsは、変更不可能にすればjsが永久に主流だというのを意図的にやっている

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

>>149
何いってんだお前？

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

触るな触るな

**デフォルトの名無しさん** · 2025/01/03(金) 23:49:31.66

ひといないねこのすれ

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

だからマルチスレッドで発生しうる競合はその2つだけじゃないから

それだけで安全と言い切れるわけないだろ

そもそも安全性ってお前が作るアプリで必要なの？
Linuxカーネルや組み込みだったらわかるけどそんな高度なプログラム作ってんの？
飛行機のシステム作ってて命がかかってるとかならわかるが、その辺のアプリで安全性とかどうでもいいよね

Rust馬鹿信者は開発生産性を軽視しすぎだ、開発生産性を犠牲に安全性に振ってるのがRustだがアプリの特性によって安全性なんぞどうでもいいことが多い

開発生産性が一番重要

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

難しさによる障壁はあるけど、慣れれば生産性自体は高い言語だと思う
ライブラリ多いし、ちょっとしたツールを作る程度ならエラーハンドリングもそんなに頑張らなくて良いし (anyhow を使えば割と雑に書ける)

流石にPythonのような手軽さは無いけど、C++よりは遥かに書きやすいし、個人的にはC#やJavaよりも楽だと思うくらい
これは言語仕様でなくツールの話だけど、プロジェクトを作ったり、ライブラリを追加したりするのが楽

学習コストが高いのはその通りで、誰かが書いたツールを他の人が保守しづらいみたいな問題はどうしようもないけど…
(そういう用途ならGoが良さそう)

**デフォルトの名無しさん** · 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
後半の話は全然関係ないじゃん