Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

**デフォルトの名無しさん** · 2024/07/01(月) 14:22:38.11

flat_map の関数名を and_then にしたのはどこの言語の文化？

**デフォルトの名無しさん** · 2024/07/01(月) 14:43:32.98

iostreamの記号をまるでセガサターンのように見下して英単語を推した文化

**デフォルトの名無しさん** · 2024/07/01(月) 14:48:54.46

and_thenはor_elseに対してのantitheseだと思った

**デフォルトの名無しさん** · 2024/07/01(月) 14:51:31.68

result1.and(result2) がまずあって
result1.and_then(|ok1| return_result2(ok1)) が関数版だね
OptionでもResultでも同じ命名

**デフォルトの名無しさん** · 2024/07/01(月) 14:59:21.90

iostreamの << をRustに導入しなかったのはなぜ？

**デフォルトの名無しさん** · 2024/07/01(月) 15:05:11.12

std::fmtで十分だから

**デフォルトの名無しさん** · 2024/07/01(月) 15:05:34.52

うるせぇやりたきゃShl実装しろ

**デフォルトの名無しさん** · 2024/07/01(月) 15:30:41.32

>>543
単純な二項演算子でやると書式指定の範囲を制御できないんだよ。
C++ ではストリームに対する書式指定は永続的な効果を持っていて、その効果を上書きするまで続く。
普通の方法で指定したらグローバルな影響を持ってしまうのは明らかにまずい。

iostream が出来たときは可変長引数の関数を型安全に扱う方法 (variadic template) が無かったし、
書式指定文字列をコンパイル時に解釈して安全に扱う方法 (constexpr) も無かったから
その範囲内で当時の知見で比較的マシな形にしたらああなったという程度のもんで、
今の考え方からすると iostream は真似したいようなもんじゃない。

むしろ C++ のほうが新しい仕様では Rust 風のやり方に寄せて来てる。

**デフォルトの名無しさん** · 2024/07/01(月) 15:53:07.19

>>543
ダサすぎるから

**デフォルトの名無しさん** · 2024/07/01(月) 15:56:35.04

rustもprint時のstring interpolationはもう少しどうにかならんものかね

**デフォルトの名無しさん** · 2024/07/01(月) 18:51:52.61

macroなんで自分で描き替えればええんやで

**デフォルトの名無しさん** · 2024/07/01(月) 20:45:22.07

自作した後の自己肯定を10年続けるまでがプログラム技術

**デフォルトの名無しさん** · 2024/07/01(月) 23:04:21.05

昔、C++でprintf使ったら怖い人に怒られたのに
今じゃあれはクソ設計だったって評価に固まってるんだね、英語圏でも

**デフォルトの名無しさん** · 2024/07/01(月) 23:12:10.92

>>551
C/C++ の printf は iostream 以上にカス。
型のチェックがガバガバだし、ちゃんと理解してないやつのほうが多いので常に問題を引き起こしていた。
ただ、記法としてはこれで良かった。

**デフォルトの名無しさん** · 2024/07/02(火) 02:06:02.53

今の C/C++ の printf はコンパイル時に型チェックして警告してくれる

**デフォルトの名無しさん** · 2024/07/02(火) 05:00:17.05

>>553
型チェックできて型がわかっているのに
なぜ%dや%fや%sなど指定しなきゃいけないのか理解できない
型がゆるゆるだった大昔の遺物にみえる

**デフォルトの名無しさん** · 2024/07/02(火) 06:06:14.65

>>554
みえる、じゃなくて完全に遺物だろ

**デフォルトの名無しさん** · 2024/07/02(火) 06:44:02.90

表示はRustのDisplayトレイト実装方式が洗練されていて使いやすくていいね

**デフォルトの名無しさん** · 2024/07/02(火) 08:28:24.43

仕様書が聖書のようなものだから遺物だろうが仕様書に逆らうわけにはいかないじゃん

**デフォルトの名無しさん** · 2024/07/02(火) 08:41:47.20

>>544
C の関数は基本的にはちゃんと型はついてるが可変長引数は静的な型情報を捨てること実現してる。
もちろんそれを引き継いだ C++ も。
C++ は後に variadic template による安全な可変長引数を導入したが古いスタイルの可変長引数も廃止はしてない。
言語仕様を素朴に実装したら型はわからないんだよ。
printf などの一部の関数に限っては「関数の型情報によらずに」コンパイラが特別扱いでチェックしてる。
関数の型を元に検査してるんじゃなくて printf の仕様をビルトインして特別扱いしてるの。

**デフォルトの名無しさん** · 2024/07/02(火) 10:27:11.96

>>538
result.and_then(|val| Ok(f(val)?))
とか
result.and_then(|val| Ok(f(val).unwrap()))
じゃなくて
result.and_then(|val| Ok(f(val)))
で良いのはなぜ？

**デフォルトの名無しさん** · 2024/07/02(火) 10:37:23.15

Rust初めて使ったときは「println! みたいな基本的なものがマクロで？大丈夫かこの言語」みたいに思ったもんだが、
よくよく考えるとマクロにせずに、柔軟なシグニチャでなんとかしようとする他の言語のほうがよっぽど醜いもんな。

**デフォルトの名無しさん** · 2024/07/02(火) 10:55:15.33

>>559
上2つはResult<T>
最後のはResult<Result<T>>かResult<Option<T>>
ネストが一つ深くなる

**デフォルトの名無しさん** · 2024/07/02(火) 11:50:20.39

>>560
C++ のライトユーザは関数テンプレートのことを誤ってテンプレート関数と呼ぶことが頻繁にある。
関数テンプレートが関数であるという誤解が言葉になって表れてるんだと思う。
単に使うだけなら関数みたいに見えてしまうからかもしれない。

関数テンプレートは関数を生成する元になるテンプレートだから関数テンプレートなので「生成する」というところに着目したらマクロで生成するのでも理屈はあまり変わらないかもしれない。

ただ、 LISP 系言語の経験から言うと構文レベルで制御されるマクロはエディタのサポートが受けづらいし、ドキュメントを型で表現できないのはやりづらい。
マクロ展開の失敗がどういう失敗なのかをきちんとエラーメッセージにするのも難しい。
デメリットもあるけど、どうせどこかに問題があるならこのくらいで良いという潔さは感じる。

**デフォルトの名無しさん** · 2024/07/02(火) 12:37:13.61

仕様書がなくなっても
統合環境の支援の成功体験から逆算された縛りがあるんだな

**デフォルトの名無しさん** · 2024/07/02(火) 16:01:50.82

and_thenってネストが深くても自動で中いじってくれるのか

**デフォルトの名無しさん** · 2024/07/02(火) 17:51:34.66

Slint ってなんなん？ javascript ?
conrod とどう違うん？

**デフォルトの名無しさん** · 2024/07/02(火) 18:31:45.59

conrodならもう死んだよ

**デフォルトの名無しさん** · 2024/07/02(火) 18:32:06.29

>>559
Rustでそれらは全てmatchになるので置き換えて比較すれば理解は簡単
ちなみにmatchにすると記述が長くなるが同レベルで「?」オペレータ適用できるメリットがある

result.and_then(|val| f(val))
これはこう置き換えられる
match result {
　Ok(val) => f(val),
　Err(err) => Err(err),
}

result.map(|val| f(val))
これはこう置き換えられる
match result {
　Ok(val) => Ok(f(val)),
　Err(err) => Err(err),
}

つまり常にこれが成り立つ

>>534
＞以下の二つは同等
＞ result.map(|val| f(val))
＞ result.and_then(|val| Ok(f(val)))

**デフォルトの名無しさん** · 2024/07/02(火) 18:34:46.10

>>565
SlintはGUI部分だけ専用スクリプトで宣言して
プログラムはRustでもC++でもJavaScriptでも記述できる

**デフォルトの名無しさん** · 2024/07/02(火) 22:09:25.08

RustのGUIまわりは安定しない印象
conrodやdruidやorbtkのようにここ数年内に消えたものもあるし、いま人気のものも今後消えないとは言い切れない感じがする

**デフォルトの名無しさん** · 2024/07/02(火) 23:44:50.93

RustでGUIならこの5つ
https://iced.rs/
https://slint.dev/
https://tauri.app/
https://www.egui.rs/
https://dioxuslabs.com/
方向性がそれぞれ異なるので目的に合わせて選ぶ

**デフォルトの名無しさん** · 2024/07/03(水) 03:55:17.90

tauri遅いな
eguiはサクサク

**デフォルトの名無しさん** · 2024/07/03(水) 06:25:46.46

>>570
tauriはその中に入れるべきじゃないだろ
あれはReact/JSだぞ

**デフォルトの名無しさん** · 2024/07/03(水) 07:06:30.59

>>572
無知すぎ
Reactは全く関係ない
併用可能な一つに過ぎない

TauriではJavaScriptを一切書かなくても利用可能
Rustによるプログラミングのみでも使うことができる

**デフォルトの名無しさん** · 2024/07/03(水) 09:04:55.71

rstkはどうなの？

**デフォルトの名無しさん** · 2024/07/03(水) 20:03:02.84

しかしほんとにデスクトップアプリのライブラリってすぐ出ては消えていくな
自分で作ったほうが安定するんじゃないか

**デフォルトの名無しさん** · 2024/07/03(水) 22:16:18.13

クロスプラットフォームでいくならwinitとwgpuぐらいは頼らないと無理じゃないかな。
しかしその2つもまだまだブレイキングチェンジ激しい発展途上だけどね。

**デフォルトの名無しさん** · 2024/07/03(水) 22:53:26.72

>>574
*/Tkは30年以上の歴史と実績があるGUIライブラリ
rstkはそのRust版

**デフォルトの名無しさん** · 2024/07/03(水) 23:54:41.68

>>573
Yewのこと？ならそう書けよYewなんてくっそマイナーでReact使うのが普通なのに

**デフォルトの名無しさん** · 2024/07/03(水) 23:56:15.32

Yew使ったことあるけどゴミだぞまじで

**デフォルトの名無しさん** · 2024/07/04(木) 00:31:14.93

30年くらい前にTcl/Tkを使ったわ。

**デフォルトの名無しさん** · 2024/07/04(木) 00:37:01.85

>>575
利用者が集まらなきゃ結局のところ本番環境で使われないもんね
MAUIもだけど本番環境で使われなきゃ不具合修正すらされずにフェードアウトしていく

**デフォルトの名無しさん** · 2024/07/04(木) 04:07:16.49

>>570
eguiの公式サイト、オサレね

**デフォルトの名無しさん** · 2024/07/04(木) 07:04:39.24

サイト自体が見本なのな

**デフォルトの名無しさん** · 2024/07/04(木) 10:17:42.23

reactもこの10年でだいぶ変わったわな。
プレゼンテーション層はそういうもんかもなと思ってる。

**デフォルトの名無しさん** · 2024/07/05(金) 08:36:28.68

銀河英雄伝説で考えるセキュリティ--将来の「帝国の双璧」が陥った罠とセキュリティ業界
https://japan.zdnet.com/article/35220819/

**デフォルトの名無しさん** · 2024/07/05(金) 10:29:56.20

>>574 >>577
rstk より tk ( https://crates.io/crates/tk ) の方が良いよ

**デフォルトの名無しさん** · 2024/07/05(金) 18:22:04.62

どちらも利用者少なくて数の差ではわからんな

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

Tkは何十年も前のGUIで古いからね

**デフォルトの名無しさん** · 2024/07/06(土) 04:24:49.23

やりたいことを出来る範囲で最小限の道具を選ぶのが望ましい。
Tk で足りるときは Tk を使えばよい。

**デフォルトの名無しさん** · 2024/07/06(土) 09:36:32.81

UNIX系でGUIをどうしても使わないといけない場合にTk使ってたけど
今はhtmlでいいかなって

**デフォルトの名無しさん** · 2024/07/06(土) 09:36:55.52

wgpu最強だが変化速過ぎ

**デフォルトの名無しさん** · 2024/07/06(土) 10:12:50.18

正直GUIをRustで書くメリットが思いつかない
ただの2DグラフィックでRustの実行速度を求めるってのはおかしな話だと思うもん
ロジックをRustで書いてGUIは安定してるReactでいいよ

**デフォルトの名無しさん** · 2024/07/06(土) 10:14:23.55

wgpuは三角を書きたい人向けでGUIとは関係ない

**デフォルトの名無しさん** · 2024/07/06(土) 11:05:29.63

>>592
お前がそう思うならそうなんだろう
お前ん中ではな

**デフォルトの名無しさん** · 2024/07/06(土) 12:27:12.12

>>592
reactはデータリフトアップして上にまとめるのめんどい。状態管理だけにライブラリ導入とか無理あるんじゃねーの

**デフォルトの名無しさん** · 2024/07/06(土) 12:35:51.52

streamlitなどのHTML書かないでも作れるようなのがメジャーになればいいんだけど

**デフォルトの名無しさん** · 2024/07/06(土) 12:47:45.00

reactがパックされてて高度なページはjinjaみたいので中のデータだけいじれればなんでもいい気がする

通常のページの記述はhtmlではなく素のrustで簡単に書ける必要がある

**デフォルトの名無しさん** · 2024/07/06(土) 13:00:47.32

ウェブ技術系は普段使いするにはリッチすぎるんだよな。
屋上屋を重ねまくった一番上でしょうもないことをするのは気が引ける。

**デフォルトの名無しさん** · 2024/07/06(土) 13:56:26.87

streamlitレベルでいいんだけどな

**デフォルトの名無しさん** · 2024/07/06(土) 14:33:03.19

rust版のstreamlit作れよ

**デフォルトの名無しさん** · 2024/07/06(土) 14:56:55.97

タウリンなんていらん
eguiで充分

**デフォルトの名無しさん** · 2024/07/06(土) 22:06:51.02

Rustってオブジェクト指向言語ではないということですが、それでも困ることはないんですか？

これが最後の言語だ！とRustって名付けたんですか？

**デフォルトの名無しさん** · 2024/07/06(土) 22:35:00.58

Rust触ってないから分らんけど、QtのRustラッパーライブラリは無いのん？
一応Android/iOS含めたソースコードレベルでのマルチプラットフォームライブラリに進化しているらしいが、Haskellにすらラッパーライブラリあるんなら、Rustにも探せばあるんじゃ？

**デフォルトの名無しさん** · 2024/07/07(日) 00:52:56.61

>>602
ネタにマジレスかもしれないけどRustはオブジェクト指向的なものも使えるよ
構造体にメソッドを持たせたり、インターフェースのようなものも扱える
継承はないけど、これはむしろ「その方が良い」というもので、同じくモダンな言語であるGOでも継承は無くしてる

**デフォルトの名無しさん** · 2024/07/07(日) 01:50:01.52

オブジェクト指向プログラミングには
クラス継承という悪いやり方を用いるダメな方法と
クラス継承を用いない正しい方法があって
RustやGoなどのモダンな言語は後者の方法をサポートしている

**デフォルトの名無しさん** · 2024/07/07(日) 08:48:31.04

>>603
ないわけじゃないけどまともに使えるレベルではないらしい。使ってないから知らんけど。
Qt自体QMLとか迷走してる感じあるし結局JSでやるならもうReact使えばいいんじゃね？感ある

**デフォルトの名無しさん** · 2024/07/07(日) 09:17:14.13

>>604-605
ありがとうございました。
「継承」って良いからオブジェクト指向言語の機能になっていたのではないんですか？
なんか時代とともに、昔は良いとされていたものが今ではダメになったりするんですか？
なぜそんなに揺らぐのでしょうか？
言語の設計の学者はぼんくらばかりなんですか？

**デフォルトの名無しさん** · 2024/07/07(日) 09:17:45.74

継承がないほうが「正しい」というのは行きすぎた思想だよ。
正しく使えないカスばっかりだという現実に敗北しただけ。

**デフォルトの名無しさん** · 2024/07/07(日) 09:49:42.70

何がダメかというと「ある型(クラス)が別の型(クラス)の実装を継承してしまうこと」でこれが依存関係となり負の連鎖をもたらす
クラスの継承はこれに該当するから使ってはいけない
Rustにも継承とみなせる機能はあるけれど上記に該当しないため大丈夫
そこが決定的な違い

**デフォルトの名無しさん** · 2024/07/07(日) 10:06:45.11

>実装を継承してしまうこと」でこれが依存関係となり負の連鎖をもたらす
実装継承を使えないレベルの人はだいたいこういうふわっとした認識だよね

**デフォルトの名無しさん** · 2024/07/07(日) 10:11:15.42

暗殺術を正しく使える賢者がいる国なんてあったら嫌だなあ
正しく使える者など絶対存在しないという思想は行き過ぎではなくむしろ穏健派

**デフォルトの名無しさん** · 2024/07/07(日) 10:27:32.62

全部が悪いと言う話じゃないけど

既存部分をただ継承させるだけならいいけど一部を上書きしたりして
それが全ての箇所で矛盾のない正しい挙動になるか判定が難しいか不可能な場合がある

結果実装コスト以上に考えざるを得ない…残念なことに本当に楽をしたのかどうか不明な場合がある
継承がないとそれは避けられるから使うな！と言う人が出てくる

**デフォルトの名無しさん** · 2024/07/07(日) 10:29:57.11

変数などに細かいアクセス制限のない言語は特に陥りやすい
制限があったところで制作者がそれを適切に選ばなければならない

どうしても経験や思考時間を必要とする
ガチ勢にはそれが無駄に思えるんだろう

**デフォルトの名無しさん** · 2024/07/07(日) 10:32:06.74

実装継承は問題を引き起こすだけでなく
代わりの継承機能を提供することで
実装継承は全く不要になったことが大きい
そのためRust、Zig、Nim、Goなどモダンな言語はいずれも言語仕様からクラスを追放している

**デフォルトの名無しさん** · 2024/07/07(日) 10:33:57.16

それをやっても実質オーバーライド問題は解決されていないけどな

**デフォルトの名無しさん** · 2024/07/07(日) 10:45:17.84

>>607
実装継承はすごく便利だからオブジェクト指向言語では誰でも使いやすい機能としてサポートされてた
でも便利すぎて乱用されたからその経験と反省から不便でも乱用されにくいようにした方が得策という考えに至った言語開発者が増えたというのが2010年代
だから今は実装継承は上級者向けの機能という扱い
GoでもRustでも一般的なオブジェクト指向言語よりもわざと使いにくくすることで利便性と問題点を理解して実装方法を選択できる上級者向けの技術になっている

**デフォルトの名無しさん** · 2024/07/07(日) 10:46:54.77

>>615
それは(実装継承となる)クラスでのみ問題となるよな

**デフォルトの名無しさん** · 2024/07/07(日) 10:53:40.16

>>616
デタラメを書くなよ
問題となる機能の代わりに便利で問題を起こさない機能を導入したのがRustだ
頭の固いクラス原理主義の人だけが使いにくいと主張してるが
クラスの洗脳から解き放たれた普通の人たちはRustが便利で使いやすいとの理解に至っている

**デフォルトの名無しさん** · 2024/07/07(日) 11:05:57.49

>>618
それは違うかなｗ
Rustで具体的に他と何が違ってて便利になってるか明言できるか？

Rustでも本質は変わってないのでなんも考えないでコピペ（継承）は避けましょうね
ぐらいのレベルでしかない

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

>>607
当時は良いと考えられてたものが後から振り返って「あれは良くなかった」と分かる例はプログラミングに限らず多くあるだろ
Cの時代にRustを設計しろというのは無理で、その間にC++やJavaを経験し、そこで生まれた課題意識がないとGoやRustは生まれなかった
ニュートンの時代に古典力学を超えた量子力学を発見しろみたいなもの

**デフォルトの名無しさん** · 2024/07/07(日) 11:23:38.24

>>619
コピペを避けるためにあるのが継承
ただし継承には2種類あって
>>609に説明がある実装継承とそうならない継承がある
実装継承の典型例がクラス継承
実装継承は他の型(またはクラス)に実装を完全に依存してしまっているために硬直化や崩壊などを招いてしまう
解決方法は単純で実装継承とならない継承機能をRustのようにサポートすればよい

**デフォルトの名無しさん** · 2024/07/07(日) 11:31:52.81

当初から、算数の四則演算の型を継承で説明できないことを
知りながら無理を通したぼんくらが流行らせたのだ

難しい算数よりも布教しやすい教義を優先するほうが儲かるという判断
その判断が合理的と思うかどうかは人それぞれ

**デフォルトの名無しさん** · 2024/07/07(日) 11:55:49.26

根本的に継承だけの問題じゃない
結局可視であろうがなかろうが関数自体の挙動が理解しないといけない

addがあってもリストの一番前に追加するか後ろに追加するかと言う機能の違いが合って
コーディングする側がそれを統一的に扱って思った場所に追加されずにバグになる
そういう話だからトレイトだからとか継承亡くしたからとかどうとか関係ない

**デフォルトの名無しさん** · 2024/07/07(日) 11:59:33.31

継承はなくても良いがあると便利 vs 継承はあってはならない
C++は知らなくてもいいが先に知っておくと理解が速い vs C++の理解はいらない

こういう境界線のビミョーな議論だと「まだ結論は出てない」と嘯きやすく続けやすいんだろうか

**デフォルトの名無しさん** · 2024/07/07(日) 13:43:23.71

interfaceはおっけー、abstractは隠蔽されるからだめってことだよ
継承全てが悪というわけではない

**デフォルトの名無しさん** · 2024/07/07(日) 13:46:30.77

kotlinでもabstractクラスはコード自動生成するときしか書かないもん
rustはtraitで十分だし

**デフォルトの名無しさん** · 2024/07/07(日) 14:05:34.19

rustにも派生はあるじゃん

**デフォルトの名無しさん** · 2024/07/07(日) 16:52:52.64

大きなプログラムを実際に書かずに、本を読むだけで、この言語のこの仕様は悪いとか良いとか判断できるようになりますか？

**デフォルトの名無しさん** · 2024/07/07(日) 17:13:03.91

継承はいらん。

理想(のひとつ)はダックタイプで、継承は実装上の都合でそうなっている妥協の産物でしかない。

**デフォルトの名無しさん** · 2024/07/07(日) 17:36:36.74

今まで築いてきた価値観を繰り返し短い言葉で否定して徹底的に壊すというのが洗脳の基本

「継承は悪」「モダンな言語に継承はない」「Rustでは継承による問題は発生しない」(※全部嘘ですよ)

最初に洗脳をはじめた人と違って
洗脳者に洗脳された人は本質を理解していない
そればかりか真実かどうかなんてもはやどうでもよく
自分が信じてることだけが真実だと思っている
だから議論しようという気もなく一方的に同じことを繰り返し書くだけ
掲示板界隈では身近によくあることなので気をつけようね

**デフォルトの名無しさん** · 2024/07/07(日) 18:10:28.88

継承はプログラミングで絶対に必要な重要な機能で重複コードを避けることができる
ただし継承といっても複数の方法があって実装継承だけは害を招いてしまう

実装継承とは別の型の具体的な実装をそのまま継承してしまうことを指す
つまり実装継承をすると二つの型の間に不必要に強力な依存関係が生じてしまう

クラス継承でプログラムを書くと自然にこの害悪な実装継承となってしまう
そのため様々な異なる方針のモダンな言語が同じ結論に達してクラスを言語仕様から無くした

Rustではトレイトを使うことで健全な継承機能のみを使うことができる
特にトレイトのデフォルト実装はどの型にも依存しないため実装継承にならずに健全な継承のメリットを最大限に享受することができる

**デフォルトの名無しさん** · 2024/07/07(日) 18:53:59.08

>>628
たくさん本を読み自分の頭で考える努力をすればある程度まではなれる
ただし実地の経験がなければ最終的には他人の受け売りを判断基準にするしかなく
経験のある人間に比べると妥当な判断ができない状況が多くなる

言語の仕様は一面的に良いとか悪いとかという判断を下せるものはほとんどない
長所短所を把握した上でどういう状況であれば他の仕様に比べて優れていて
逆にどういう状況であれば他の仕様に比べて劣るのかという
状況に合わせた判断が必要

つまり妥当な判断を下せる確率を上げるためには
言語の仕様を把握する力よりもそれが使われる状況を幅広く奥深く想定する力を身につけることが重要
これを本を読むだけで身につけようとしてもすぐに頭打ちになる

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

>>622
>算数の四則演算の型を継承で説明できない
詳しく。

**デフォルトの名無しさん** · 2024/07/07(日) 19:34:52.42

>>628
他の言語での開発経験がある人が仕様を見て「この言語のこの仕様は好き/嫌い」と言うことはあると思う
どの言語も初心者という人だと無理
それに言語の良し悪しなんて点数で評価できるようなものでないし、好みの問題だったり、ライブラリなどの周辺環境だったり、作りたいもの次第だったりする

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

好き嫌いと良い悪いはしっかり区別つけなければならない
他の型との間で不必要に強力な依存関係が生じてしまう実装継承は悪い
この実装継承となってしまうクラス継承は悪い
Rustに実装継承はなくトレイトを用いることで健全な継承を活用してプログラミングできる

**デフォルトの名無しさん** · 2024/07/07(日) 22:26:34.08

受け売り知識しか持たないとこういう感じで論拠薄弱で空疎な意見しか書けなくなる
いい反面教師だね

**デフォルトの名無しさん** · 2024/07/07(日) 22:51:49.25

Rustが継承の問題を防げるのってトレイトだけじゃなくてenumの存在も大きいよね
静的ポリモーフィズムを自然に実装できるから、多態のために無理やりインタフェースに当て嵌めようとしたり、ダウンキャストが必要になったりといったものを防げる
本質的に違うものを抽象化しようとして失敗してる例を見たことのある人はそれなりにいるはず

**デフォルトの名無しさん** · 2024/07/07(日) 23:03:31.83

>>633
整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない

それと文字列 + 文字列が定義されている言語では
分数 + 整数の定義に必要な関数も継承したくない
その関数は文字列と無関係だから