Rust part23

**デフォルトの名無しさん** · 2024/02/23(金) 17:37:52.13

公式
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 part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/04/12(金) 12:33:34.40

>>664
Rustはそうやってきちんと管理できつつ便利でいいよなー
他の言語も導入すればいいのに

**デフォルトの名無しさん** · 2024/04/12(金) 12:43:39.99

>>665
オブジェクト指向を全否定するキチガイか
クラスのある言語もクラスのないGoやRustなどの言語も
一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ

**デフォルトの名無しさん** · 2024/04/12(金) 13:04:32.76

とりあえず感覚で一行目から罵倒する人

**デフォルトの名無しさん** · 2024/04/12(金) 15:24:23.71

>>667
>一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
オブジェクト指向前提思考？

**デフォルトの名無しさん** · 2024/04/12(金) 16:22:22.83

>ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
からの
>UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
schizoかな？

**デフォルトの名無しさん** · 2024/04/12(金) 17:02:05.38

それらの件でもRustの仕様が優秀すぎ

**デフォルトの名無しさん** · 2024/04/12(金) 20:51:13.79

>>670
虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ

**デフォルトの名無しさん** · 2024/04/12(金) 22:18:23.28

おじいちゃんは昼だけ起きてて
夕方を過ぎると寝てしまう

**デフォルトの名無しさん** · 2024/04/12(金) 22:50:23.70

RUSTがトレンドに！！

**デフォルトの名無しさん** · 2024/04/12(金) 23:58:18.71

>>667
つジェネリック

**デフォルトの名無しさん** · 2024/04/13(土) 04:39:15.20

ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか

**デフォルトの名無しさん** · 2024/04/13(土) 07:36:48.57

トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ？

柔軟性のために外延性は欲しいところ。

**デフォルトの名無しさん** · 2024/04/13(土) 08:07:59.96

異なる型間の共通項をトレイトとして切り出すだけでよく
コードを美しく整理して保守性を高めやすい

**デフォルトの名無しさん** · 2024/04/13(土) 13:32:34.24

敬称ないせいで苦労してるんだってな

**デフォルトの名無しさん** · 2024/04/13(土) 13:36:34.54

143 デフォルトの名無しさん 2024/04/07(日) 19:27
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない

それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている

**デフォルトの名無しさん** · 2024/04/13(土) 16:56:52.49

継承がなくても構造体にメソッドついてたら実質クラスだろ
関数に構造体渡してたらそれはクラスじゃないけど

**デフォルトの名無しさん** · 2024/04/14(日) 23:56:10.96

>>681
構造体にメソッドが付くことはカプセル化と言う
クラス＝カプセル化＋実装継承　なのでクラスとカプセル化は異なる

このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった
実装継承とは具体型が別の具体型を継承することを指す
クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる

正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する
つまりクラスを完全に排除できるためモダンな言語群にクラスはない

**デフォルトの名無しさん** · 2024/04/15(月) 00:05:55.58

用語も色々。
Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、
JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。
極論すればクラスと名付けたものがクラス。

Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。
C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、
クラスとは何かを定義せずにクラスかどうかを論じても無意味。

**デフォルトの名無しさん** · 2024/04/15(月) 00:26:07.32

型クラスとクラスは全く異なるので混乱しない
クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す
JavaScriptはプロトタイプを親として実装継承するためクラス
一方でRustにクラスはない

**デフォルトの名無しさん** · 2024/04/15(月) 01:47:00.44

クラスとは何か？継承とは何か？
こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい

>>681が一番まとも

**デフォルトの名無しさん** · 2024/04/15(月) 01:58:25.85

話は非常に単純
具体的な型から具体的な型への継承が実装継承でこれがよくない
classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承
interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない
最近の言語がclassのみ採用しなかった理由はその違い

**デフォルトの名無しさん** · 2024/04/15(月) 02:39:20.65

RustにはJavaのクラスはありません
RustはJavaではないからです

あたまいいね

**デフォルトの名無しさん** · 2024/04/15(月) 03:16:04.95

Javaの生みの親であるJames Goslingも、
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」に対して、
「クラスを除外するでしょうね」と答えている。
その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。

**デフォルトの名無しさん** · 2024/04/15(月) 08:31:26.40

クラスのようなものでいいよ

**デフォルトの名無しさん** · 2024/04/15(月) 10:16:50.96

バカの一つ覚えの相手をしても時間の無駄

**デフォルトの名無しさん** · 2024/04/15(月) 12:54:52.68

クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな

**デフォルトの名無しさん** · 2024/04/15(月) 21:09:43.00

それは単に使い分けが出来ない馬鹿な子向けの説明だぞ

**デフォルトの名無しさん** · 2024/04/16(火) 07:27:41.72

>>691
言語仕様としてあった方が良いということ。

**デフォルトの名無しさん** · 2024/04/16(火) 07:42:24.51

馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ

**デフォルトの名無しさん** · 2024/04/16(火) 08:43:42.78

Javaの生みの親も言ってるようにクラス継承の機能はない方がいい
なくても困らない
あると問題を引き起こす

**デフォルトの名無しさん** · 2024/04/16(火) 09:30:25.53

そういうのは話半分に聞いておけばいいよ
nullを使ったのは失敗だったとか
後からそれらしいことを言ってるだけ

javaはクラスと継承が無くなったらまともに機能しない
interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず

**デフォルトの名無しさん** · 2024/04/16(火) 09:50:49.42

>>696
interfaceにデフォルト実装を後から入れたので問題なくなった
そうなるとclass継承は不要

**デフォルトの名無しさん** · 2024/04/16(火) 09:55:41.24

最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから

今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって
後から○○無くせばよかったと言うのは誤りで浅はか

NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ

**デフォルトの名無しさん** · 2024/04/16(火) 10:21:05.77

今となってはclass継承は廃止でいい

**デフォルトの名無しさん** · 2024/04/16(火) 11:59:36.87

インターフェイスにも集合で言うところの外延性は欲しいところ。

**デフォルトの名無しさん** · 2024/04/16(火) 13:49:22.28

そういうの使いたいならTSがいいよ

**デフォルトの名無しさん** · 2024/04/16(火) 14:56:34.55

具体的なデメリットって何なの？

**デフォルトの名無しさん** · 2024/04/16(火) 15:29:25.10

ダサい

**デフォルトの名無しさん** · 2024/04/16(火) 20:45:11.55

そういう感覚的なもの？

**デフォルトの名無しさん** · 2024/04/16(火) 22:20:54.32

基底クラスで保証してる内部条件を継承クラスで壊されやすい

Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど
C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う
古い知識だから最近の動向は知らない

**デフォルトの名無しさん** · 2024/04/17(水) 08:15:23.25

Unreal EngineがRist対応するんだってね

**デフォルトの名無しさん** · 2024/04/17(水) 16:42:11.69

Ristってなんだ、Rustだた

**デフォルトの名無しさん** · 2024/04/17(水) 21:06:33.89

Rast
Rist
Rest
Rost

**デフォルトの名無しさん** · 2024/04/17(水) 21:31:42.40

Risp

**デフォルトの名無しさん** · 2024/04/18(木) 23:48:18.11

>>706
時代の流れだな

**デフォルトの名無しさん** · 2024/04/19(金) 17:19:41.25

隙間作って床下チェスト収納ってできなくなった？動画みてるけどうまくできん

**デフォルトの名無しさん** · 2024/04/20(土) 17:39:26.03

shift-jiｓのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない
全部読んでデコードして\nで切り分けるしかないの？

**デフォルトの名無しさん** · 2024/04/20(土) 17:53:01.46

read_lineはutf-8じゃないと無理だけどread_untilならバイト列で１行ずつ取れそう

**デフォルトの名無しさん** · 2024/04/20(土) 22:11:31.95

>>712
encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る
あとはreader.lines()で同じ

**デフォルトの名無しさん** · 2024/04/20(土) 22:28:20.55

std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines()

**デフォルトの名無しさん** · 2024/04/21(日) 07:15:48.69

BufReaderもFile::openもそのまま使える点がいいね

**デフォルトの名無しさん** · 2024/04/21(日) 10:23:00.52

>>715
ありがとうございます
動作確認しました

ちょっと仕組みがむずかしいですね

**デフォルトの名無しさん** · 2024/04/21(日) 18:25:05.39

decoderが挟まるだけだよ

// UTF8の場合
let file = File::open(path)?;
let reader = BufReader::new(file);
for line in reader.lines() {

// SJISの場合
let file = File::open(path)?;
let decoder = DecodeReaderBytesBuilder::new()
　.encoding(Some(SHIFT_JIS))
　.build(file);
let reader = BufReader::new(decoder);
for line in reader.lines() {

**デフォルトの名無しさん** · 2024/04/22(月) 06:09:19.12

バッファリングせず丸ごと贅沢にメモリ使っていいなら単純
let bytes = fs::read(path)?;
let (s, _, _) = SHIFT_JIS.decode(&bytes);
let reader = BufReader::new(s.as_bytes());
for line in reader.lines() {

**デフォルトの名無しさん** · 2024/04/22(月) 20:07:02.52

コマンドラインからファイル名取るようにしたらパニック
windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい

**デフォルトの名無しさん** · 2024/04/22(月) 20:46:10.62

何を言ってんのw

**デフォルトの名無しさん** · 2024/04/22(月) 21:19:42.71

知らないとそういう反応するんだろうけど
std::env::args_osを使ってOsStringを取って対処する必要があるんだよ
勉強になっただろ？

**デフォルトの名無しさん** · 2024/04/22(月) 21:24:48.26

日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える
アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう

世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている

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

>>722
チュートリアルレベルの基礎を
バッドノウハウwとか
積み重ねでいかないといけないwとか
言ってるから何言ってんのwになる

**デフォルトの名無しさん** · 2024/04/22(月) 23:32:38.83

>>720
Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある
さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる
まずは基礎知識を身につけよう

>>722
std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある
さらに対処方法はargs_osを使えと明記されている
ドキュメントを見よう

**デフォルトの名無しさん** · 2024/04/22(月) 23:35:51.77

>>724-725
こういう低能がありがたがるんだろうな
信者としか言いようがないｗ

**デフォルトの名無しさん** · 2024/04/22(月) 23:42:55.88

リリースした後の実行時のpanicを有り難がる信者

Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本

**デフォルトの名無しさん** · 2024/04/22(月) 23:57:01.81

>>722
Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから
その関数のドキュメントのpanicの項目を見れば明記されてる
他の言語と比べても良い環境

**デフォルトの名無しさん** · 2024/04/23(火) 00:03:29.34

馬鹿と話しててもらちが開かない

世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実
お前らそれを一個一個プルリク送ったりしてるのか？

**デフォルトの名無しさん** · 2024/04/23(火) 00:13:45.98

所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ
世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる

非合理的

**デフォルトの名無しさん** · 2024/04/23(火) 00:34:48.42

そんなことより The Embedded Rust 読み始めたんです。
冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね？と言わんばかりの内容。
おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。

**デフォルトの名無しさん** · 2024/04/23(火) 09:44:34.04

公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる
プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す
ヤバすぎね？

**デフォルトの名無しさん** · 2024/04/23(火) 11:06:58.83

>>725
なんでコンパイル時にエラーにできないんだろう？

Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは？
c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。

**デフォルトの名無しさん** · 2024/04/23(火) 12:06:18.33

panicは安全ですヨ

**デフォルトの名無しさん** · 2024/04/23(火) 12:11:09.83

>>734
緊急停止して「安全ですよ」はちょっと……

**デフォルトの名無しさん** · 2024/04/23(火) 12:14:00.43

>>733
セキュリティホールにならない
異常データに対して止まり動作を続けない

**デフォルトの名無しさん** · 2024/04/23(火) 15:43:54.29

>>733
>なんでコンパイル時にエラーにできないんだろう？
出来るわけないだろw
実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw
バカすぎる

**デフォルトの名無しさん** · 2024/04/23(火) 16:19:44.91

しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス
もう治る見込みはないからargs_os()を使おうねってだけだけど

**デフォルトの名無しさん** · 2024/04/23(火) 16:52:58.90

一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど
特に提案もなさそうだし誰も困ってないんじゃないかな
そもそもほとんどのケースでclapとか使うだろうし

**デフォルトの名無しさん** · 2024/04/23(火) 17:20:16.94

>>733
＞>>725
＞なんでコンパイル時にエラーにできないんだろう？

むしろ何でできると思ってるんだろう。謎

**デフォルトの名無しさん** · 2024/04/23(火) 17:22:13.22

環境変数もvarとvar_osがあるから慣れろとしか言えない
OS標準が全部utf-8になる未来もありえるし

**デフォルトの名無しさん** · 2024/04/23(火) 17:48:20.12

>>741
紛らわしいけどvar/var_osとvars/vars_osは別物だよ
varはinvalid UTF-8でもエラーハンドリング可
varsはpanic

argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど
varsはそんな前提をおける状況はほぼなくてよりたちが悪い

**デフォルトの名無しさん** · 2024/04/23(火) 18:06:35.01

>>741
>OS標準が全部utf-8になる未来もありえるし
10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない
もう10年経ったとしても状況は変わらないと思う

**デフォルトの名無しさん** · 2024/04/23(火) 19:06:07.68

>>732
公式チュートリアルまともに読めるならC++で良いからな

**デフォルトの名無しさん** · 2024/04/23(火) 20:01:34.96

よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？

どう考えてもstd::env::argsを非推奨にしろとは思うけどね
欧米人がつくるとこんなことになるんだ

普通は2種類の扱いがある
・実行環境に合わせて自動的に内部での標準形式に変換
か
・何もしない
何もしないならOSから受け取ったままOSに渡して置けば大体問題はない

第三の愚策がRust
受け取ったままそのままOSに渡してもコケる
Rustは何もしないように見えるけど何かしてるからコケるのでは？

**デフォルトの名無しさん** · 2024/04/23(火) 20:52:29.82

>>745
間違いだらけだな
世界の標準はUTF8
ウェブももちろんUTF8
RustもUTF8

Rustがこの件でコケることはない
きちんと各関数の仕様が明記されていて常に正確に動作している

**デフォルトの名無しさん** · 2024/04/23(火) 21:05:41.35

Rustのパニックは綺麗なパニック
いいね？

**デフォルトの名無しさん** · 2024/04/23(火) 21:12:51.81

>>747
一般的なパニックは色んな意味合いがあるけど
Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた
ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない
だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる

**デフォルトの名無しさん** · 2024/04/23(火) 23:35:29.98

>>745
勘違いしてることが多すぎてもう笑うしかないwww

**デフォルトの名無しさん** · 2024/04/23(火) 23:41:39.78

>>745
>よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？
30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな？
(UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど)

↓これが15年くらい前のUTF-16に対する一般的な認識
https://softwareengineering.stackexchange.com/questions/102205/

**デフォルトの名無しさん** · 2024/04/24(水) 00:43:41.33

utf-16はUnicode 2.0（1996年7月）のサロゲートペア導入でutf-8に逆転されたな
しばらくはBMPしか使われなかったから耐えてたけど
1990代前半に始動したJavaは運が悪かった

**デフォルトの名無しさん** · 2024/04/24(水) 01:21:01.63

>>749
そう書きながら何もまともなレスすらできないレス乞食

**デフォルトの名無しさん** · 2024/04/24(水) 01:23:24.26

Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど
Rustが正しいRustが正しいと繰り返すばかり

**デフォルトの名無しさん** · 2024/04/24(水) 12:36:38.15

>>737 >>740
windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。

そもそもargは廃止していい。

**デフォルトの名無しさん** · 2024/04/24(水) 12:47:56.41

すげーどうでもいい話だな

**デフォルトの名無しさん** · 2024/04/24(水) 12:47:57.96

>>746
なるほど。
「RustはWindowsをケアする気が無い」
ということですか。

**デフォルトの名無しさん** · 2024/04/24(水) 12:58:45.05

>>754
Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能
まぁ廃止していいには同意するけども

**デフォルトの名無しさん** · 2024/04/24(水) 13:18:14.84

Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。
今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。
保証としてはあてにならん。

**デフォルトの名無しさん** · 2024/04/24(水) 13:18:30.26

コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。

**デフォルトの名無しさん** · 2024/04/24(水) 14:25:14.78

>>754
無知にもほどがある！

unicodeとUTF-8が区別できない
Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない

**デフォルトの名無しさん** · 2024/04/24(水) 15:25:54.44

>>760
そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。
Rustはメモリ安全しか興味無いんかね。

**デフォルトの名無しさん** · 2024/04/24(水) 15:53:48.65

保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。

**デフォルトの名無しさん** · 2024/04/24(水) 16:02:42.64

どうでもいい話でもめてるな
Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題
こちらはUTF8環境でしか使われないのでargs()のみ利用している

**デフォルトの名無しさん** · 2024/04/24(水) 16:05:40.76

https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905
関係する議論はこのあたりかな
もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが
無視や置換はセキュリティ上問題になる可能性があるので却下
varsは将来的にdeprecatedにするかもと言っている
なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね

**デフォルトの名無しさん** · 2024/04/24(水) 16:26:19.27

正しく使え論は暴論だな

それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる