Rust part23
一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど
特に提案もなさそうだし誰も困ってないんじゃないかな
そもそもほとんどのケースでclapとか使うだろうし >>733
＞>>725
＞なんでコンパイル時にエラーにできないんだろう？
むしろ何でできると思ってるんだろう。謎 環境変数もvarとvar_osがあるから慣れろとしか言えない
OS標準が全部utf-8になる未来もありえるし >>741
紛らわしいけどvar/var_osとvars/vars_osは別物だよ
varはinvalid UTF-8でもエラーハンドリング可
varsはpanic
argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど
varsはそんな前提をおける状況はほぼなくてよりたちが悪い >>741
>OS標準が全部utf-8になる未来もありえるし
10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない
もう10年経ったとしても状況は変わらないと思う >>732
公式チュートリアルまともに読めるならC++で良いからな よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？
どう考えてもstd::env::argsを非推奨にしろとは思うけどね
欧米人がつくるとこんなことになるんだ
普通は2種類の扱いがある
・実行環境に合わせて自動的に内部での標準形式に変換
か
・何もしない
何もしないならOSから受け取ったままOSに渡して置けば大体問題はない
第三の愚策がRust
受け取ったままそのままOSに渡してもコケる
Rustは何もしないように見えるけど何かしてるからコケるのでは？ >>745
間違いだらけだな
世界の標準はUTF8
ウェブももちろんUTF8
RustもUTF8
Rustがこの件でコケることはない
きちんと各関数の仕様が明記されていて常に正確に動作している >>747
一般的なパニックは色んな意味合いがあるけど
Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた
ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない
だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる >>745
勘違いしてることが多すぎてもう笑うしかないwww >>745
>よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？
30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな？
(UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど)
↓これが15年くらい前のUTF-16に対する一般的な認識
https://softwareengineering.stackexchange.com/questions/102205/ utf-16はUnicode 2.0（1996年7月）のサロゲートペア導入でutf-8に逆転されたな
しばらくはBMPしか使われなかったから耐えてたけど
1990代前半に始動したJavaは運が悪かった >>749
そう書きながら何もまともなレスすらできないレス乞食 Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど
Rustが正しいRustが正しいと繰り返すばかり >>737 >>740
windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。
そもそもargは廃止していい。 >>746
なるほど。
「RustはWindowsをケアする気が無い」
ということですか。 >>754
Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能
まぁ廃止していいには同意するけども Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。
今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。
保証としてはあてにならん。 コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。 >>754
無知にもほどがある！
unicodeとUTF-8が区別できない
Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない >>760
そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。
Rustはメモリ安全しか興味無いんかね。 保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。 どうでもいい話でもめてるな
Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題
こちらはUTF8環境でしか使われないのでargs()のみ利用している https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905
関係する議論はこのあたりかな
もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが
無視や置換はセキュリティ上問題になる可能性があるので却下
varsは将来的にdeprecatedにするかもと言っている
なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね 正しく使え論は暴論だな
それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる >>765
生ポインタは安全ではないから全く違う
argsは常に安全 常に自動変換したほうが安全だけどな
開発者が特別コードを書く必要もない Rustはファイル名も自動変換なんかしていないように
変換するかどうかは各自の自由裁量であるところが非常に良い点だよ
自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど >>768
ここまで読んで何の話をしているのか理解できないならRust使うのは辞めたほうがいい ファイルの引数だけ標準では何もしない
普通のキーボード入力などでは変換している >>768
自動変換は正直意味不明だが（変換元の文字コードが判定不能なのに何を変換するのか？）
argsは今RFC出したらResultにしろって突っ込まれると思うし
1.0であまり深く考えずに入れちゃった気はするよ Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う
argsじゃなくてargs_utf8onlyとか名前をダサくして
逆にargs_osを元のargsに戻しとけば
リファレンスをよく読まない人たちがつまづく可能性を下げられる こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。
Rustは雇われコーダー用Safe Rustのニーズがほとんどで、Unsafe Rustとかのニーズは無いと思うがね。 >>772
自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない 自動変換とかそんなアホなこと言ってるのはあんただけやで
そんなものは無いし必要ない こいつOsStringの概念が分かってないのか
本当に知能レベルが低すぎる OsStringはOSから渡されたバイト列をそのまま格納するだけで
EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが… 想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる
結局内部で使う場合は簡単にutf8に変換してる
なにからutf8に変化するか指示も必要がない
ただのボイラープレート >>777
自動変換なんてものはない
むしろ自動変換を避けるために用意されているのがOsString
もちろん自動変換は行われない 人間じゃなくて壊れたロボットに話しているようだな
いくつになろうとこんなダメな人間になってはいけないな ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって
どんなエンコーディングの文字列でも統一的に扱うことができましゅ
Rustもまだまだでしゅね ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる
もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある 文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。 めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう？
複オジは昔の自分を諭してる気分じゃないか？ >>0774
お前の着眼点は凄えよ！感動した。
その通り、Rustは初心者/素人 御用達言語だよ。 おじいちゃん誰にも相手にされず寂しくなったんだねw 
