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/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すると宣言したら
自明だった問題が突如として最先端の未解決問題に変化するのか？
しないでしょ
同じでしょ

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

>>704
ずっと「オブジェクト指向言語のクラスが抱えている問題はRustでは起こらない」と主張してる人がいるでしょ
それに対して、そんなことはないよと言ってるだけ

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

>>716
あらゆる問題が解決されたという話は出てないでしょ
クラスが抱えてる問題でRustによって解決されてる様々な例が出ているだけで

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

>>714
だからLSPが対象としている諸問題はRustじゃ解決しないと主張しているんだよ。

>>715
implの実装次第なのに、
「LSPが対象としている遺物における諸問題に悩まされずに済む」と言っているアホが居るのよ。
そんな機能はRustのTrailには無いわな。

>>717
「遺物における諸問題に悩まされずに済む」と言っているアホが居るのよ。しまいにはRustとLSPは関係無いとか言うし。
そんなわけ無いだろと主張している。

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

>>718
そのアンカ先は全部複オジだろ
LSPも知らない、サブタイピングも知らない、継承で起こりうる簡単な問題も知らない
にもかかわらず知ったかぶりして嘘を並び立てる
こんなやつがそうそういるわけがない

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

キチガイは1人見かけたら10人はいると思え

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

>>701
そのやり方がなぜ悪いのか理解できませんので、教えてください。
例えば、C++だと、以下の様にするのも別に悪いやり方ではないような
気がするのですが。
class Number {・・・};
Number add(Number &a, Number &b);
Number mul(Number &a, Number &b);
class Integer : public Number {・・・};
class Rational : public Number {・・・};

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

ChatGPTってモノシリなんですね？

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

>>721
改めて見てみると、add()やmul()の戻り値にNumberの実態を返しているのがおかしい気もしますが。
IntegerやRationalにadd()やmul()を仮想関数として定義するのが良いのかもしれません。
そのような点で改良の余地が沢山ありそうです。

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

>>720
色んな板の色んなスレをみて来ているが
どこにでもいるのは事実

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

10人いると思ってる人自身が11人目になりやすいから気をつけなよ
数値の計測が抱えている問題は、そもそも計測していない人には起こらない

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

>>721
add(integer, rational)できる？

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

ミイラとりがミイラになるのは昔から

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

>>712
>例外で値をキャッチできなくなることや値を返す抜け道になることを防ぐためだ
違うよ
勝手な想像でLSPを誤解釈しないで

substituteされる型Tに対して定義された仕様上(契約上)の振る舞いを
substituteする型Sが満たしてなければLSP違反
つまり仕様上panicを禁止したトレイトの関数を
panicする関数でimplしたらLSP違反

LSPではあくまで”仕様上定義された振る舞い”が問題

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

>>728
panicを禁止という概念も方法もなく不可能だよ
何をしたいの？

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

catchするという対案がない
対案との比較が抱えている問題はそもそも対案がない言語では起こらない

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

>>729
そいつはRust叩きで連投していた>>684
panicを禁止できると思い込み
unsafeを使うとpanicできると思い込んでいる

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

>>721
「インタフェースを定義し、それに基づいて実装する」という設計なら問題ないのだけど、
これは「あるクラスに依存していたコード群が新しいクラスでも動くようにするため」という発想になっており、大規模な開発だとこのやり方はだいたい失敗するよという話

例を書きづらいけど、例えば「A社製の装置を制御するアプリ」があったとして、
新しく「B社製の装置も制御できるようにする」という追加の開発案件があったとする。
この時点ではまだADeviceControllerは抽象化されておらず、A社装置の仕様に強く依存したクラスであるとする。
これを「ADeviceController が持つメソッドを IDeviceController として取り出し、それを BDeviceControllerにも実装させる」とすると確実に事故る。
「B社装置にだけある機能Xを呼びたい」「A社装置にあった機能YがB社装置にはない」といった違いを吸収しきえれず、インタフェースがぐちゃぐちゃになったり、「呼んでも何もしない」とかの形で誤魔化したり、呼び出し元でサブクラスの判定が必要になったりする

こうならないようにするには
a. 具体的な機器に依存しない、機器の振る舞いを適切に抽象化したインタフェースを定義する
b. 代数的データ型を使う
という方法があり、 Rust では b. の方法も使いやすいので、個人的にはそこが良いなと思う

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

設計が悪いといえばその通りなんだけど、そのせいでインタフェースが崩壊しているプロジェクトは実際にあるし、RustやGoが継承を廃止した理由の一つでもあると思う
クラス継承だとこの問題はもっと簡単に起こりやすい
前述の例は (あくまでも見かけ上は) インタフェースを定義しており、クラスを継承してるわけではないので、Rustのトレイトでもやろうと思えば起こるけどね

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

言語を選ぶにあたって継承の有無は選択肢に入らんし正直言ってどうでもいいわ
代替手段があるのにいつまで言ってんだ

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

>>729
仕様を定義するという簡単なお話がほんとにわからないのかな？

panicを例にすると頭がパニクるみたいなので
リスコフの論文にあるFIFO/LIFOの例で言い換えると
仕様としてLIFOの振る舞いを要求するトレイトの関数を
FIFOの振る舞いで実装したらLSP違反ってこと

簡単なお話でしょ？

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

既に言語を選んだのにまだ、is-aとhas-aどっちにするか選べとか
catchするかしないか選べとか
言語の内部でいつまでも選択が繰り返されるシステムが謎なんよ

いつまで言われるかといえば謎が解けるまでだよ

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

>>732
それは共通インターフェースと特定装置にしかないインターフェースをそれぞれ別で用意すべきだと思う
拡張メソッドや拡張トレイトも活用する

ただA社装置もB社装置も1つの共通したコードで扱うなら
サブクラス判定ではないにしても呼び出し元での分岐は何かしら必要

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

>>733
RustやGoは違う方法で継承を行っているというだけで継承を廃止したというのは誤解
わざと誤解させてるという面もあるにはある

**デフォルトの名無しさん** · 2024/07/11(木) 00:29:09.09

クイズ
JavaScriptのプロトタイプチェーンはis-a？
それともhas-a？

**デフォルトの名無しさん** · 2024/07/11(木) 00:30:41.75

>>732
一般的に何らかの上位層と下位層があるときに
Rustではその界面にtraitを置いて
上位層はそのtraitを利用する側
下位層はそのtraitを実装する側
とSILIDのDIP (Dependency Inversion Principle)にするのがそのa.だね
もしクラスでやるときは抽象化を徹底した上で色んな注意が必要になるところ
Rustは自然にコーディングできてありがたいね

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

スマソ
SILIDはSOLIDのタイポ

**デフォルトの名無しさん** · 2024/07/11(木) 01:26:06.15

>>740
インターフェース知らないの？

**デフォルトの名無しさん** · 2024/07/11(木) 01:37:36.53

>>742
インタフェースは各言語で付加仕様がバラバラ多種多様だから慎重に言うと
それ自体はフィールド変数など持たず完全に抽象化できつつ
実装必須メソッドとデフォルト実装提供メソッドがサポートされて
その中で利用可能な他のインタフェース(またはtrait)群による制約ができて
となるとどの言語が残るかな

**デフォルトの名無しさん** · 2024/07/11(木) 03:34:06.04

それはたぶんDじゃなくてIかな……

**デフォルトの名無しさん** · 2024/07/11(木) 09:53:46.09

https://doc.rust-jp.rs/ 終了の件

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

>>744
DもIも両方関係あるよ

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

>>743
インターフェースが使えるメジャーな言語は全部残る
C#, Java, Kotlin, Swift, TypeScript, Dart

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

ʕ◔ϖ◔ʔ

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

>>747
ウソはあかん

**デフォルトの名無しさん** · 2024/07/11(木) 13:53:08.83

>>747
サーバー用途で強いJavaは残るね
Kotlin/Swiftもモバイルアプリのネイティブ言語として残る
TSはJSで十分っていう風潮が漂いつつあるけどまあ残るだろう
死ぬのはC#とDartかな

**デフォルトの名無しさん** · 2024/07/11(木) 14:12:48.49

LSPで嘘ばっかりついてたのがバレたから
またしょうもない話をはじめてごまかそうとしてるのか
いい加減にしろよ

**デフォルトの名無しさん** · 2024/07/11(木) 16:22:35.45

LSPに書かれていることすら読まずに
RustのトレイトがLSPの対象だと言い張ってたもんな

**デフォルトの名無しさん** · 2024/07/11(木) 16:57:46.28

PartialOrdとPartialEqの一貫性とかLSPっぽいけど
Substitution（置換）とはちょっと違うんだよな
無理矢理Sに当てるならSurrogation（代用）あたりか
これをLSPに含めるかは定義重視vs意味重視で意見が分かれそう

**デフォルトの名無しさん** · 2024/07/11(木) 17:15:40.81

LSPはsupertypeのインスタンス(オブジェクト)とsubtypeのインスタンスの振る舞いを比較してそこで満たすべき原則を挙げていますから
Rustのtraitをsupertypeとしてみてもそのインスタンスが存在しないため振る舞いの比較ができないですね
traitはLSPとは関係ない立ち位置にいます

**デフォルトの名無しさん** · 2024/07/11(木) 20:33:40.77

ごちゃごちゃ難しいこと考えてるうちにエンバグしたりなんかして。

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

>>750
サーバー用途こそJavaはRustとGoに蹴散らされて終わるだろ

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

実際のところRustはサーバーサイドで使われてるの？

**デフォルトの名無しさん** · 2024/07/11(木) 22:25:27.54

実際は派生クラスの方が支持されていたとしても基底クラスを蹴散らしてはならない
とLSPは言っている

**デフォルトの名無しさん** · 2024/07/11(木) 22:35:40.65

>>757
使われてないよ

**デフォルトの名無しさん** · 2024/07/11(木) 22:47:57.53

>>757
Rust利用のトップがウェブのサーバー側
この件は過去スレでも何度も出ているので興味あるなら見るといいよ
その理由も明白でリソースコスト削減が最も効くため

**デフォルトの名無しさん** · 2024/07/11(木) 22:50:39.98

サーバーは常時稼働させるものだからねえ

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

>>757
GAFAMとかCloudflareとかトラフィックの多いとこに入ってるから誰もが必ずお世話になってる程度には使われてる
日本でサーバーサイドの仕事が沢山あるか、という意味ならそんなことはない

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

世界中で着実にRustへ置き換わっていってるね
特にクラウドを利用しているとランニングコストに直結するので

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

>>753, 754
トレイトの場合はLSPで言うsupertypeやsubtypeになるのは
トレイトを利用して作られるimpl Traitやtrait objectの型だよ

PartialOrd/PartialEqやFn/FnMut/FnOnceのように
supertrait/subtraitの関係にあるやつも便宜的にトレイトで互換性が語られるけど
実際はそれらを利用して作られる型についての話なのと同じなんだよ

**デフォルトの名無しさん** · 2024/07/12(金) 00:16:45.77

>>764
真面目に相手してあげるの偉いな

**デフォルトの名無しさん** · 2024/07/12(金) 00:19:01.43

>>764
いいえ
traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため
親となるsupertypeの具体的な型はありませんはありません

**デフォルトの名無しさん** · 2024/07/12(金) 00:19:49.06

>>764
いいえ
traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため
親となるsupertypeに相当する具体的な型はありません

**デフォルトの名無しさん** · 2024/07/12(金) 00:47:16.73

トレイトにはフィールド変数が一つもなくてメソッドも各個別型で実装されるものだから事前条件・事後条件など比較もできなくてLSP適用は無理でしょ

>>764
supertrait/subtraitの場合に例えばある構造体についてそのインスタンスはどちらも同一になるからLSPの前提である二つのインスタンス間での差は論じられないでしょ

**デフォルトの名無しさん** · 2024/07/12(金) 09:52:35.34

>>757
Rustは殆どどこにも使われてないよ

**デフォルトの名無しさん** · 2024/07/12(金) 10:23:09.62

「C言語は分かる。機械語も分かる、回路もわかる。30万払うからRustのメモリ安全のからくりをサクッとレクチャーしてくれ」
みたいなニーズがあっさり無料で満たされているべきだと思うんだ

**デフォルトの名無しさん** · 2024/07/12(金) 10:57:31.20

誤解は色々あるけど「努力すれば必ずゼロコストになるカラクリ」が
あると思ってるならそれが誤解だね
クイックソートやハッシュテーブルと同じく、最悪の場合のコストは低くない