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/10(水) 01:14:02.81

rustだいぶ分かってきたつもりだけど
ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理
好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる

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

>>592
進捗報告相手が課長というのが昭和かもな
そんな会社で働きたくない

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

>>596
moonbit くらいならどうかな？

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

>>596
それぞれ理解していれば組み合わさって困ることはないんじゃないかな
Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど

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

Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか？めんどいんですけど

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

メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。

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

self/ mut self/&self/&mut selfの区別もいるしな
self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では

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

C++ の ref-qualifier とか無理のある文法だもんな。
そこに書くんか!? という変な驚きがある。
引数の一種ということにしたほうがかなり単純でよい。
実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された｡ (deducing this)

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

RustでPython実装すりゃ良いんじゃね

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

>>602
普通に全部ダサいんだよなあ
何とかならなかったのかとならなかったのかとならなかったのかと…

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

selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか

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

ぜひとも >>605 の考える最高にイケてる構文を教えてほしい
Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし

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

>>605
nimの関数呼び出しルール
関数名(第一引数,第二引数...)
第一引数.関数名(第二引数...)
で第一引数がself相当
が一番スマートかと。

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

>>605
むしろ>>602はそれらの区別のためにもselfは必須と言ってるようにみえる
さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい
現状のRustの仕様がベストかな

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

selfじゃくてthisならC++マニアも納得

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

>>608
nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね

Vec::push(&mut vec, 123);
(&mut vec).push(123);
vec.push(123);

この&mutを省略できてRust便利

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

thisはたまにselfの代理で使われてるな
Rc::into_innerとか

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

deref後のinto_inner適用と区別のため
敢えてself使わないことでメソッド呼び出し形式をできなくして
明示的にRc::into_inner呼び出しさせるパターンだね

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

メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は
LISP 用に作られたオブジェクトシステム new flavors でやってた。

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

それは同一視というか構文が1つしかないだけでは

**デフォルトの名無しさん** · 2024/04/11(木) 02:14:15.06

呼び出し時には与えない引数って紛らわしくね？

**614** · 2024/04/11(木) 02:45:03.24

>>615
メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。
new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど
new flavors で改良 (かどうかわからんけど) された。

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

>>616
むしろ逆かな
target.method(arg1, arg2, ...)という
targetへのメソッドコールを実現するのを関数で表すと
method(target, arg1, arg2, ...)とする言語が多い

Rustでも同じでこのtargetをselfと書く
targetは送る側から見た視点
selfは受け取った側から見た視点
各実装は受け取った側でなされるためself

**デフォルトの名無しさん** · 2024/04/11(木) 08:24:38.80

UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな
レシーバとして扱われるなら構文上も特別であってほしい

**デフォルトの名無しさん** · 2024/04/11(木) 08:39:59.21

>>619
何が気持ち悪いのかさっぱりわからない
まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね？
次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね？
ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう

**デフォルトの名無しさん** · 2024/04/11(木) 08:49:57.16

言うほどほとんどの言語がこれか？
pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ
これがPythonいまいちだなって思うところ
c++も似た様な理由でstaticでthis

後発で考慮する余裕あるのにそれを引っ張ってる

**デフォルトの名無しさん** · 2024/04/11(木) 09:02:17.34

>>621
君の感性がおかしいんじゃね？
NimもZigもRustもPythonと同じ標準方式
foo(receiver, arg1, arg2, ..)
または
receiver.foo(arg1, arg2, ..)

**デフォルトの名無しさん** · 2024/04/11(木) 09:02:43.98

>>618
なるほどちょっと納得した

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

>>622
実質Pythonフォロワーを含めて言われても…

**デフォルトの名無しさん** · 2024/04/11(木) 09:14:09.83

C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた
それがOOP言語になって指定不要になった
それがまたC言語時代に逆戻り

**デフォルトの名無しさん** · 2024/04/11(木) 09:15:22.73

>>624
何を言ってるのかわからん
文句を言うなら望ましい代案を出してみて

**デフォルトの名無しさん** · 2024/04/11(木) 09:17:05.47

あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは
receiverがNullの可能性がある場合でそう設計されてただけ

**デフォルトの名無しさん** · 2024/04/11(木) 09:20:43.92

代案を出せないってことはRustに言いがかりをつけてるだけだな

**デフォルトの名無しさん** · 2024/04/11(木) 09:24:05.56

別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ
その表記は時間をかけて考えたらいい

**デフォルトの名無しさん** · 2024/04/11(木) 09:30:34.30

>>625
レシーバは必ず必要
Goでも
func (receiver ReceiverType) Foo(引数…) {
　return receiver.xxx + receiver.yyy
}
と書く
レシーバ指定不要という主張は理解できない

**デフォルトの名無しさん** · 2024/04/11(木) 09:45:56.75

レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな
selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい

**デフォルトの名無しさん** · 2024/04/11(木) 09:51:28.66

いやいやｗ
無知って怖いねとしか…

**デフォルトの名無しさん** · 2024/04/11(木) 09:52:17.20

>>630

**デフォルトの名無しさん** · 2024/04/11(木) 10:19:57.47

UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの

>>619はそれを分かった上でNimについて書いてるのかもしれないけど>>620や>>622は明らかに誤解してる

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

>>631
そう言われるとRustの仕様がベストなのかな
レシーバに名前を付けないと名前空間の分離ができなくて
レシーバに名前を自由に付けられると読みづらくて

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

IDころころお爺さんは明らかに話を理解できないな

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

Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな
型指定にSelfやSelf::Itemなど使えるだけでなく
Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる
Selfによって自分自身であるとわかりコードが読みやすい
型名変更の影響も受けず読みやすいメンテしやすい

ダメな言語だと以下のダメなパターンがある
・Selfの代わりに型名を書かなくてはいけない言語　(自分自身だとわかりにくくメンテ性も悪い)
・Selfの代わりにself(やthis)を用いてしまう言語　(値と型の区別がつかない)
・Selfを使わずに名前空間の区別がない言語　(間違いが起きやすく自分自身だとわかりくくメンテ性が悪い)

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

関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな……

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

複オジは見えてる範囲が狭過ぎる
だから長文になればなるほど勘違い度や害悪度が高まる

**デフォルトの名無しさん** · 2024/04/11(木) 12:47:47.10

自分が使ってきた特殊な仕様の言語に慣れ親しんでいると
一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない
Rustを叩く前に視野を広く持つべきだな
Rustの仕様はよく考えられ機能的に洗練されている

**デフォルトの名無しさん** · 2024/04/11(木) 12:59:00.66

>>640
Rustに無いからといってUFCS叩くのはさすがにアホかと。

**デフォルトの名無しさん** · 2024/04/11(木) 13:15:55.80

そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん

**デフォルトの名無しさん** · 2024/04/11(木) 15:57:20.01

>>642
エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない

**デフォルトの名無しさん** · 2024/04/11(木) 15:59:23.14

くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い

**デフォルトの名無しさん** · 2024/04/11(木) 16:41:03.54

まともな質問にいつものノリで適当に答えて嘘だったら良くないしね

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

そっか
俺の答えも間違ってたしな
正しくはdowncastのために必要らしい
詳しくはfix_errorのRFC見て

**デフォルトの名無しさん** · 2024/04/11(木) 17:41:58.72

Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環？

**デフォルトの名無しさん** · 2024/04/11(木) 17:48:38.15

動き出した
サーバー側の問題っぽいな
https://github.com/rust-lang/rust-playground/issues/831

**デフォルトの名無しさん** · 2024/04/11(木) 18:55:11.06

downcastなんて別にしないからいらねーよって思ったけど

そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか
ヒントありがとう

**デフォルトの名無しさん** · 2024/04/11(木) 19:06:32.42

複おじはc++も使ってなかったんだな

**デフォルトの名無しさん** · 2024/04/11(木) 20:25:23.50

>>641
UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。
Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。

**デフォルトの名無しさん** · 2024/04/11(木) 20:52:12.80

>>651
UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。

それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。

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

>>652
Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。
そのためUFCSのような愚かな方式を採る必要がない。

**デフォルトの名無しさん** · 2024/04/11(木) 21:15:01.99

答えを教えてもらっているのにヒントありがとうというオジさんw

**デフォルトの名無しさん** · 2024/04/11(木) 21:16:29.71

メソッド名空間www

**デフォルトの名無しさん** · 2024/04/11(木) 21:54:13.50

>>653
それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。
もっとUFCSならではの問題点を指摘してくれ。

せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。

**デフォルトの名無しさん** · 2024/04/11(木) 23:54:23.85

アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ
アラビア語おすすめ

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

>>656
それはメソッド呼び出しのメリット
モジュール化や結合の観点からも最初からメソッド定義していくのが正しい

UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる
具体的には歴史的な負の遺産でボロボロなC++が該当する
そのためC++ではUFCSを導入しようと今も悪あがきをしている

ほとんどの言語にUFCSがないのはそんなものを必要としないためだ

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

モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい

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

それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない
AddAssignやSubやShlなど多くの演算は非対称

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

いや別にSubでもDivでも左のみに紐づいているのはキモい

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

>>658
やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。
例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ？

グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。

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

>>662
トレイルではなくトレイト
トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ

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

>>663
だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。

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

>>659
＞モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ

同意

**デフォルトの名無しさん** · 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にデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず