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/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
整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない

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

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

>>638
>整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない
普通、C++だと、整数クラスを作っておき、
分数クラスはそれを継承せずに、
整数クラスを2つメンバに持つクラス
として定義しますよね。
その場合、整数クラスと分数クラスは継承関係を持ってない。

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

>>635
クラス継承の問題はある程度の規模でプログラミングしてきた人の多くが体験してきて、
その根本的原因は実装継承にあることが多くのサイトで解説されている通りだけど、
従来の言語ではクラス継承に代わる手段が弱かったり不便であるため、
仕方なく欠陥のあるクラス継承を使い続けてきた不幸な歴史があるんだよ。
クラス継承を使わずにすむRustは恵まれてる。

**デフォルトの名無しさん** · 2024/07/08(月) 00:13:34.95

>>638
分数クラスを継承して整数クラスを作りたいという要求と
分母を表す変数は継承したくないという要求が矛盾してる

分数クラスを継承して整数クラスを作りたいということは
分数を特化したものが整数であるというモデルを
分数クラスと整数クラスの実装でも作りたいということ
そのためには整数クラスにも分母を表す変数が当然必要

矛盾した要求が実現できないのは実装技術の問題ではなく要求の不備

**デフォルトの名無しさん** · 2024/07/08(月) 00:24:32.58

>>607
コードメトリック - 継承の深さ (DIT)
https://learn.microsoft.com/ja-jp/visualstudio/code-quality/code-metrics-depth-of-inheritance?view=vs-2022

継承もやりすぎると毒になるってだけで、全くダメってわけじゃない。

**デフォルトの名無しさん** · 2024/07/08(月) 00:26:00.53

>>638
不適切な継承の典型例だな

**デフォルトの名無しさん** · 2024/07/08(月) 00:36:15.98

>>638
数学では整数の組から分数作るけど、整数クラスが親クラスじゃないのは変じゃない？
（そもそも、継承より整数クラスのインスタンスを分子用と分母用の2個使う委譲スタイルの方が適切だと思うけど）

(n,m)とn/mは同型

**デフォルトの名無しさん** · 2024/07/08(月) 01:24:33.08

どういう用途のためにクラスを作ろうとしているのか不明瞭な段階で
特定の実装方法が適切だと思い込むのは感心しない

**デフォルトの名無しさん** · 2024/07/08(月) 05:17:42.23

>>630
継承自体は悪くない
重複コードを回避できて保守性も向上する
つまり継承自体は良いもの

ただし実装継承だけは悪
異なる型同士に過度な依存をもたらし保守性を悪くする
クラス継承は実装継承となるため悪
モダンな各言語がクラスを排除した理由はそのため

Rustに実装継承はなく継承でそのような問題を起こさない

**デフォルトの名無しさん** · 2024/07/08(月) 09:13:52.72

継承で重複コードを回避できるのは実装も共有する継承だけ
つまり実装継承だけ

Rustスレでこんな初歩的なことを説明しなきゃいけないのはすごく悲しい

**デフォルトの名無しさん** · 2024/07/08(月) 09:32:49.17

今回はいつまでやるの？

**デフォルトの名無しさん** · 2024/07/08(月) 09:42:44.60

>>647
実装継承の意味を理解したほうがいいんじゃね？
ある型Aの実装を別の型Bが継承することが実装継承と呼ばれているんだよ
これは不必要に依存関係が強すぎて片方を機能拡張しようとしたときなど破綻を招きがち
だから実装継承となるのは避けるべきと言われているね

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

ワイの思う継承はenum_dispatch crate でやれるから困ったことないなぁ
お前らの心の中の継承は知らんがw

**デフォルトの名無しさん** · 2024/07/08(月) 10:42:22.99

分数はバカっぽい
有理数と言え

**デフォルトの名無しさん** · 2024/07/08(月) 10:42:53.94

>>647
Rustに実装継承はないけど
継承があり重複コードを回避できている

**デフォルトの名無しさん** · 2024/07/08(月) 10:43:30.84

例えばどんな型でどんな内部構造でも
その型にトレイトのnext関数を実装するだけでイテーレータとして機能するが
その時に他のメソッド(nthとかmapとかfoldなど)のコードを自分で書かなくても自動的に継承されて機能する

**デフォルトの名無しさん** · 2024/07/08(月) 10:44:27.48

これをデフォルト実装と言い特定の型の構造に全く依存しないコードのみを書くことができる
つまり問題を起こす実装継承とならず
Rustでは健全な継承が実現されている

**デフォルトの名無しさん** · 2024/07/08(月) 10:55:22.37

複オジの耳に念仏
まさに>>630

**デフォルトの名無しさん** · 2024/07/08(月) 11:03:01.23

デフォルト実装の制限のかけ方が成功の肝かな
トレイトなので各型のメンバーフィールドには一切アクセスできないため実装継承が上手く回避されてる

**デフォルトの名無しさん** · 2024/07/08(月) 11:27:47.73

「実装は継承しているけど実装継承ではない」ｗ

**デフォルトの名無しさん** · 2024/07/08(月) 11:38:02.68

複オジ論法は無敵だな

**デフォルトの名無しさん** · 2024/07/08(月) 11:49:10.64

>>657
他の型の実装に実装が依存することが実装継承と呼ばれてる

**デフォルトの名無しさん** · 2024/07/08(月) 13:25:29.85

継承の本当の問題は、LSPを満たさない部分型関係を作ってしまいがちということ
他の型の実装に依存するのが良くないというのはDIの話で、直接は関係ない

**デフォルトの名無しさん** · 2024/07/08(月) 13:56:53.31

うそん
crate製作者サイドでCargo.toml内の
他のcrateへの依存関係の描き方がいい加減だと
割りと頻繁に詰む
人間が追跡して治して行けば使えなくもないが
cratesは破綻する可能性がある

**デフォルトの名無しさん** · 2024/07/08(月) 15:03:24.53

クレートdownloadでか過ぎ

どうみてもどんぐりです
ばいばいおさるさん
ころころす

**デフォルトの名無しさん** · 2024/07/08(月) 17:42:30.38

>>660
クラスを用いる言語では必ず満たすべきLSP(リスコフの置換原則)が頻繁に守られていない現実から
GoやRustなどモダンな言語はクラスそのものを廃止して改善したわけだ
他の型の実装に依存するのが良くないのも当たり前の話でそこは各型へ移譲しなければならない

**デフォルトの名無しさん** · 2024/07/08(月) 18:36:24.36

>>663
LSP全然理解してないんやな
クラスの有無とか全く関係ないぞ

**デフォルトの名無しさん** · 2024/07/08(月) 18:41:05.12

>>657
ジワジワくる

**デフォルトの名無しさん** · 2024/07/08(月) 19:00:42.33

>>657が実装継承とは何かすら理解できていなくて草

**デフォルトの名無しさん** · 2024/07/08(月) 23:32:15.60

所有権といい継承といいLSPといい
某オジは抽象概念を捻じ曲げるスキルが高すぎだろ

**デフォルトの名無しさん** · 2024/07/09(火) 00:42:48.79

>>660
LSPは派生型がその基底型を継承する時その振る舞いは同じで代替できるという当たり前な話なんだが
クラスはこの件でも欠陥があるため意識してプログラムを書かないとLSPに反してしまう
Rustはクラスがなくトレイトは枠組みだけで基底型ではないためLSPは全く関係ないぞ

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

>LSPは派生型がその基底型を継承する時その振る舞いは同じで代替できるという当たり前な話なんだが

0点

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

書けば書くほど無知をさらしてしまう複製オジさん草る

**デフォルトの名無しさん** · 2024/07/09(火) 12:31:29.17

>>664
対象となるものはクラスしかないよね

**デフォルトの名無しさん** · 2024/07/09(火) 12:39:43.65

>>668
φ(x) を型 T のオブジェクト x に関して証明可能な性質とする。このとき、φ(y) は型 T のサブタイプ S のオブジェクト y について真でなければならない。

φは主に事前条件・事後条件・不変条件で、言語によっては例外条件も入ってくる。
この観点からはRustのTraitは力不足。なんでLSPを引き合いに出せるのかわからん。

**デフォルトの名無しさん** · 2024/07/09(火) 12:57:46.02

>>672
自分でそれを書いておいて理解できていないのかよ
そこに明記されてるようにTもSもオブジェクトを持つ具体型についての話だ
Rustのtraitは具体型ではないため関係ないぞ
そしてtraitを実装する各型の間にはサブタイプの関係はないためそこも対象とならない
そこを理解できずに「RustのTraitは力不足」とデタラメを吹聴するのは恥ずかしい

**デフォルトの名無しさん** · 2024/07/09(火) 13:01:26.64

>>673
事前条件とかはどこ行ったの？

**デフォルトの名無しさん** · 2024/07/09(火) 13:20:56.23

>>674
φ(x) のxはオブジェクトと明記されてるのが見えないのかね
さらにSはTのサブタイプと明記されている
Rustのtrait自体はオブジェクトを持たない
さらにtraitを実装する二つの型同士にサブタイプの関係は生じない
つまり対象外でφが存在しないため事前条件も何もない

**デフォルトの名無しさん** · 2024/07/09(火) 13:35:41.29

>>675
＞明記されてるのが見えないのかね
＞Rustのtrait自体はオブジェクトを持たない

それは「RustのTraitはLSPと関係ない」と言いたいの？

＞φが存在しないため事前条件も何もない
事前条件も何も表明できないのは「力不足」そのものですな。

**デフォルトの名無しさん** · 2024/07/09(火) 14:43:14.46

リファクタリングするとき
プログラム(CPU)の動作の副作用は起きないけど
コーディングの変更に対して副作用が大き過ぎるというか広過ぎる

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

>>673
マジでLSP全然理解してないんやな
LSPは具体型かどうかなんて全く関係ないぞ

**デフォルトの名無しさん** · 2024/07/09(火) 15:20:15.91

>>676
LSPに明記されている前提すら満たさない異なるものであるため
「RustのTraitはLSPと関係ない」で合っている
LSPが対象としている遺物における諸問題に悩まされずに済むように
新たな視点で整理されたより良いものとしてRustのTraitが提供されている

**デフォルトの名無しさん** · 2024/07/09(火) 15:28:08.29

>>678
LSPは具体型のみが対象
抽象型を対象にしようとしても適用するにはそのいずれかの具体型となる

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

https://x.com/shuzaibusoku7/status/1809567812555542920
リアル複おじ

**デフォルトの名無しさん** · 2024/07/09(火) 20:23:57.43

>>679
RustとLSPが関係ないのなら、LSPを引き合いに出すのは大嘘か。
知ってて言っているなら詐欺師だな。

そもそもTraitでpanic禁止にできない時点で「LSPが対象としている遺物における諸問題に悩まされずに済む」というのも大嘘だしな。

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

簡単な話だよな
オブジェクト指向プログラミングで
例えばクラスを使うと
LSPに違反する二つの型のコード例を容易に作れてしまう
つまりクラスは本質的に欠陥品なんだよ

Rustのトレイトを使うと
LSPに違反する二つの型のコード例を作ることができない
つまりRustのトレイトは優れた方式なんだよ

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

>>683
あるトレイトでpanic2を禁止しようとしました。事前条件(あるいは例外条件)でnopanicとしたかったけど、そんなのは無いのでとりあえずデフォルト実装でpanic禁止にしました。
しかしトレイトユーザーはそんなのお構い無しにunsafe rustでpanicを使います。ついにpanicが発生してシステムダウンしました。

LSPでケアしている問題はRustのTraitを使っている限り発生しないんじゃないんだっけ？

**デフォルトの名無しさん** · 2024/07/09(火) 21:56:05.19

Rustのトレイトは優れているため
LSPに違反するコード例を作ることができないんだよ
もしRustに文句をつけたかったら
LSPに違反する二つの型のコード例を作って示してごらん
Rustで違反例を作るのは不可能だよ

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

>>685
Rustに文句をつけたいとかではなく
>>660でLSPに言及された途端に実装継承とか言わなくなって「最初から自分はLSPを理由に継承のダメさを語ってましたけど」って態度でイキリ倒してるの(+結局理解してなさそうなの)がバカにされとるんやで

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

>>685
>>684みたいに、
トレイトがpanicを禁止したいのに、ユーザーのトレイト実装がpanicを返す
というのはLSP違反だろ。

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

LSPはそんなことを要求していないよ
LSPをちゃんと読んで理解しようね

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

>>686
クラスは様々な問題点を抱えている
クラスでは実装継承となるため異なる型同士に不必要に過度な依存関係をもたらす硬直性も問題点の一つ
クラスはLSP(リスコフの置換原則)を満たさないプログラムが量産されてしまう問題点も別の一つ
どちらの問題点もRustならtraitを使うため問題が起きない

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

猿ども落ち着いてください！

ここで論破合戦したところでなんの得にもなりません

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

>>685
リスコフの置換原則は設計的な原則だから言語仕様で違反を防ぐことはできないぞ
悪名高い長方形・正方形の問題はトレイトがあっても起こり得る

trait Rectangle {
　fn set_width(&mut self, width: i32);
　fn set_height(&mut self, height: i32);
　fn width(&self) -> i32;
　fn height(&self) -> i32;
　fn area(&self) -> i32 { self.width() * self.height() }
}

struct Square { len: i32 }

impl Rectangle for Square {
　fn set_width(&mut self, width: i32) { self.len = width; }
　fn set_height(&mut self, height: i32) { self.len = width; }
　fn width(&self) -> i32 { self.len }
　fn height(&self) -> i32 { self.len }
}

fn func(x: &mut impl Rectangle) {
　x.set_width(3);
　x.set_height(4);

　// xが長方形であれば以下が成り立つはずだが、Square型を渡された場合に失敗する
　assert!(x.area() == 12);
}

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

>>691
長方形がトレイトで正方形が構造体とか意味不明なんだが他の形はどっちにするんだ？
おかしいだろ

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

>>691
トレイトは機能を表します
2つの異なる長さを持つ(受け取る)機能を定義しているのならば
正方形はその実装型にはなりえません

**デフォルトの名無しさん** · 2024/07/09(火) 23:24:11.46

>>692
IRectanble トレイトとかに読み替えてくれ
これは設計的に問題のある例を恣意的に示しているので不自然な点はあるけど、意図は伝わると思う

分かる人は分かると思うけど、問題は「そもそも正方形はwidthとheightという2つの値を扱うインタエースを持つべきでない」というところなので、Rectangleトレイトを作った時点で破綻している
けどそれは設計の問題なので、トレイトという仕組みによってコンパイラが防げるものではないということ

**デフォルトの名無しさん** · 2024/07/09(火) 23:30:16.52

>2つの異なる長さを持つ(受け取る)機能を定義しているのならば
>正方形はその実装型にはなりえません
論理的にはそう
でも実際にそういうコードを書けばビルドは通る

>>685 で
>LSPに違反する二つの型のコード例を作って示してごらん
>Rustで違反例を作るのは不可能だよ
とあったので、これはその反例として示した
このような問題は設計の問題であり、まずい設計をする人が使えばRustでも問題は起こり得るということを言いたい

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

>>691
君はLSPを理解できていない
LSPはis-aの関係を持つ二つの型に対して遵守すべきルールだ
Rustのtraitとその実装型はis-aの関係ではなくhas-aの関係を持つ
したがってtraitとその実装型は明らかにLSPの対象外となる

**デフォルトの名無しさん** · 2024/07/09(火) 23:40:48.87

>>695
LSPに違反する二つの型はis-aの関係を持つsupertypeとsubtypeでなければならない
>>691はhas-aの関係なのでLSPに違反する二つの型のコード例とはなっていない

**デフォルトの名無しさん** · 2024/07/09(火) 23:56:35.46

>Rustのtraitとその実装型はis-aの関係ではなくhas-aの関係を持つ

すげーのが出てきたなこりゃｗ

**デフォルトの名無しさん** · 2024/07/09(火) 23:59:12.82

LSPはis-a関係に対して守るべき原則
has-a関係に対してLSPの適用は論外
コード>>691はLSPの違反例となっていない

**デフォルトの名無しさん** · 2024/07/10(水) 00:09:07.13

メンバ関数名をそのままtraitの名前にしちまえば
そのメンバを持つ者とtraitの関係はhas-a

**デフォルトの名無しさん** · 2024/07/10(水) 00:10:24.05

過去に見た (rust以外の) プロジェクトの失敗例だと
・もともとFooというクラスがあった
・新しく作るBooクラスについて、Fooクラスと同じように扱えれば既存コードをあまり変更しなくても済むぞ！と誰かが気づいた
・その人物は Foo クラスのメソッドを元に IFoo インタフェースを定義し、それを Foo と Boo に実装させた
ことから混沌としたコードが生まれた例がある

この失敗をやらかした人は、Rustでも同じように「既存の Rectangle クラスを元に IRectangle トレイトを作り、それを Rectangle と Square に実装させる」ことをやりかねない

Rustではそれが不自然なパターンになりやすいし、起こりにくくはあるけど、本質的には設計の問題

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

「Rustを書く人はみんな賢いからそのような問題は起こさないはずだ」というなら話は別たけど
実装者の設計能力は言語仕様によって担保できるものではない

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

>>701
それらインタフェースやトレイトを用いている時点でLSPの対象外となっている
LSPを満たす必要がないどころかそんな制限があったら支障が出る
>>691のコードをLSP違反例として出してきたのは明確に間違い
おバカな設計例としてならば理解する

**デフォルトの名無しさん** · 2024/07/10(水) 00:35:49.38

>>702
おバカな設計を言語仕様で防げるなんて主張は誰もしていない
あなたが勘違い思い込みで暴走している

**デフォルトの名無しさん** · 2024/07/10(水) 00:36:32.00

LSPを全く理解してないばかりか
サブタイピングも理解しとらんのやな
よう継承継承言うたなぁｗ

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

クラスが問題だらけの欠陥品なことが災いを招いてるよね
モダンなプログラミング言語の多くがクラスを捨て去ってくれて感謝

**デフォルトの名無しさん** · 2024/07/10(水) 01:13:16.99

>>688
>>679の言う「LSPが対象としている遺物における諸問題に悩まされずに済むように」するためには必要なんだよ。
LISKOVのA behavioral notion of subtyping でも「include exception」と言っているだろ。

まぁ、panicが例外にもなれないそびえ立つクソだからRustから排除すべき、と言うなら同意するが。

**デフォルトの名無しさん** · 2024/07/10(水) 01:26:45.94

>>707
LSPはsuperclassとsubclassといったような関係を持つ型同士について満たすべき話が書かれてるんよ
その前提を無視してpanicがどうこう言い出してるからズレとるんよ

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

>>708
それを言うなら>>682で言っている通り、RustのTraitでLSPに言及するのが大嘘なんだよ。

RustのTraitは同じTraitでも簡単に異なる振る舞いを実装できる(panicみたいな致命的な振る舞い含め)のに、「LSPが対象としている遺物における諸問題に悩まされずに済む」とかの大嘘が出てくるのは何ともアホらしい話。

**デフォルトの名無しさん** · 2024/07/10(水) 02:13:28.47

>>698
RustのTraitとImplの関係はまさしくsubtypeだしis-aの関係なのにな。「継承しなければsubtypeじゃないしis-aにもならない」と間違って覚えているんかね。

**デフォルトの名無しさん** · 2024/07/10(水) 02:30:31.13

どこかで聞きかじっただけの「継承は悪」に辻褄を合わせようとしてどんどん変な理屈を積み重ねているだけでしょ

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

>>707
LSPでは例外を返すなら基底型で返す例外とそのサブタイプのみに限られるとしか言及していない
例外で値をキャッチできなくなることや値を返す抜け道になることを防ぐためだ

ちなみにRustのpanic!では値を返すことはできなくてpanicメッセージのみ
そして普通のプログラムでpanicをキャッチすることはない点など前提が全く異なる
Rustで従来の例外を扱うケースはpanic!を使わずにResultの返り値で返す
したがってpanic!はLSPで出てくる例外の話に該当しないだろう

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

>それらインタフェースやトレイトを用いている時点でLSPの対象外となっている
間違ってるよ
インターフェースだろうがトレイトだろうがサブタイピングは成立するよ
サブタイピングが成立すれば当然LSPの対象範囲だよ

>>691の例もLSPの違反例としては合ってるよ
間違った継承の使い方の例としてよく使われてるよね

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

>>684
>panic禁止にしました。

たとえno_std環境であろうとpanicは禁止にできない

>unsafe rustでpanicを使います。

panicを引き起こすのも扱うのもunsafeを必要としない

>panicが発生してシステムダウンしました。

panic発生がそのままシステムダウンではない
何ら特別な設定をしない標準状態でもスレッド内で起きたpanicはエラーとして返るだけで他のスレッドは動き続ける

**デフォルトの名無しさん** · 2024/07/10(水) 07:01:39.33

>>710
型クラスのinstanceであると宣言すればsubtypeじゃないのは自明だぜ
じゃあtraitをimplすると宣言したら
自明だった問題が突如として最先端の未解決問題に変化するのか？
しないでしょ
同じでしょ