次世代言語27 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/05(金) 08:26:38.87

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

**デフォルトの名無しさん** · 2022/08/17(水) 18:30:00.14

>>593
デバッグが手間だから静的型付けが必要、という文脈なんだけど？
結局あなたが言ってるのは動けばオッケーってことでは？

**デフォルトの名無しさん** · 2022/08/17(水) 18:52:35.57

動的型とは端的に言えば値に型情報が付属していることであり、おそらくお前らは何か誤解している。
型を指定しないことが動的だと思っているんじゃないか？
図星じゃないか？

**デフォルトの名無しさん** · 2022/08/17(水) 19:16:27.92

実行時の値とソースコードの変数の違いは重要だけど、この違いを意識しているプログラマーは少ないよね。

**デフォルトの名無しさん** · 2022/08/17(水) 19:28:56.47

実行前にコンパイル時点で静的に型も確定する静的型付け言語がベストだな

**デフォルトの名無しさん** · 2022/08/17(水) 20:10:33.59

>>572
Nimはダメだよ
例えばref objectな変数は初期化も何もされないからヌルポ状態となり実際にSIGSEGVで落ちる

もちろんNimでもRustｂﾆ同様のoptionｂgえばヌルポｂﾅきるけｂﾇ
Nimでは前述のようにoptionを使わないコードも許されるからヌルポが起きてしまう

**デフォルトの名無しさん** · 2022/08/17(水) 21:22:11.22

Kotlin Rust Swift ← Null安全な新世代言語
Go Nim ← Null安全ではない旧世代言語

**デフォルトの名無しさん** · 2022/08/17(水) 21:32:11.18

Swiftって将来性あんのかね
アップル依存大きすぎな時点で知れてると思うんだけど

**デフォルトの名無しさん** · 2022/08/17(水) 22:14:45.59

>>559
多くのcli コマンドが go, rust で再実装されつつあるのは perl, python, ruby のようなスクリプト言語から go, rust といったちょうどよいモダンさのあるコンパイル型言語への大きな流れがある気がしている。

**デフォルトの名無しさん** · 2022/08/17(水) 23:47:09.64

>>600
値と変数じゃなくて昔はデータ構造とアルゴリズムの違いを意識していた

どのような演算を想定しているかという型情報を
被演算子の側に付属させるというアイデア自体が
演算子と被演算子を一体化させ、両者を分けて考えない原因になった

**デフォルトの名無しさん** · 2022/08/18(木) 08:11:22.29

動的型付け言語のメリットてなんだ？
(習得が容易とか書き心地とかを除いて理論的なメリット)

**デフォルトの名無しさん** · 2022/08/18(木) 08:38:35.77

>>607
処理系の実装が容易
型検査いらないしホストの実装が直接的に実行時の動作を記述するため圧倒的にシンプル

**デフォルトの名無しさん** · 2022/08/18(木) 08:39:41.85

>>607
インスタンスの型判定を実際のインスタンスで行うことができるので、コードの適用範囲が広くなる。

C++を理解しているなら、dynamic castの適用事例を考えればいい。総称型で保管して具象型で使用するようなケースが代表的。

**デフォルトの名無しさん** · 2022/08/18(木) 09:15:09.69

>>608
> 型検査いらないし
実行時にやるだろ
なので動的型付け言語の多くはインタープリタ
ネイティブコンパイル言語だと逆に結構大変だよ

**デフォルトの名無しさん** · 2022/08/18(木) 09:44:19.64

実行時の型検査なんて、存在しないメンバにアクセスしようとしたらエラーとかオペランドが特定のデータ型でなければエラーといったルールを、演算子やオブジェクトの実装に組み込むだけだよ
ホストとの間で実行モデルやオブジェクトモデルを共有してるから楽勝
JITの場合もオブジェクトモデルは共有するから比較的簡単

**デフォルトの名無しさん** · 2022/08/18(木) 09:50:57.04

そんな言い方するなら静的型付け言語もコンパイル時にやるだけで似たようなもんだろ

**デフォルトの名無しさん** · 2022/08/18(木) 09:55:55.60

全然違うよ
ホスト言語で直接実装すりゃいいだけだからな
JITの場合も極限のパフォーマンスを求める静的型とは違ってホスト言語で書かれたランタイムの呼び出しを多用するのが普通だから、
インタプリタと大差ないし徐々にランタイムを使わないように改良していくアプローチが採れる

**デフォルトの名無しさん** · 2022/08/18(木) 10:05:05.63

>>613
型チェックとどこが違うのか具体的に書いて
あとホスト言語という謎用語使うならちゃんと定義してくれ
（ホスト言語自体はDSL界隈とかで使われてるけどコンパイラとかの文脈で使ってるの見たことない）

**デフォルトの名無しさん** · 2022/08/18(木) 10:15:42.84

事前に型検査をやろうとすると予め静的な型のモデルを厳密に定義しなきゃいけないでしょ？

**デフォルトの名無しさん** · 2022/08/18(木) 10:30:27.96

途中書き込み失礼
一方で動的型の場合、実行時のオブジェクトモデルさえ定義されていれば実行時の検査が可能であり、静的な型モデルと実行時のオブジェクトモデルの両方を厳密に定義する必要がない。
平たく言えば、実装が仕様だ、みたいな進め方をすることが難しいわけだ
更に、リフレクションが可能な処理系の場合には静的型であっても実行時に型検査を行う必要があるよね。

**616** · 2022/08/18(木) 10:54:49.56

> 平たく言えば、実装が仕様だ、みたいな進め方をすることが難しいわけだ
は静的型の場合ね。念のため。

**デフォルトの名無しさん** · 2022/08/18(木) 11:15:33.98

>>607
インタプリタのメリットは自分自身をコンパイルするコンパイラを作らないこと
言語は二つ以上になってしまうがそれでいい

他にもGCを実装する言語がGCに依存するんじゃないかとか
型情報を定義する言語がーとかいう問題に対する煩悩が消える

**デフォルトの名無しさん** · 2022/08/18(木) 11:54:36.40

>>615
型のモデルとかイマイチよくわからんが定義は必要だろ
動的型付でも実行時には必要なんだし

>>616
> 更に、リフレクションが可能な処理系の場合には静的型であっても実行時に型検査を行う必要があるよね。
動的型付と類似の処理だからね
そういう意味で面倒というならまだわかる

**デフォルトの名無しさん** · 2022/08/18(木) 11:55:56.17

言語を作る側のメリットしかわかんねぇの？
言語を作る側じゃなく使う側のメリットを聞いてんだろ

**デフォルトの名無しさん** · 2022/08/18(木) 12:42:07.20

>>608
ツリーウォーク型のインタプリタなら楽だろうけど、速度出すにはJITとか考えないと行けないし、コンパイラ書くのと大差ない気がする

**デフォルトの名無しさん** · 2022/08/18(木) 12:57:08.67

>>620
具体的な実装をギリギリまで遅らせることができる＆設計が間違っていても無理やり嵌め込むことができる。
プロトタイピングとかライブラリ開発とかで楽できるし、リファクタリングで段階的に仕様を固めることができる。

最終的には静的型付けの方が堅牢になるけど、最初からミス無く設計するのは無理だから、開発初期は動的型付けの方が有利。

**デフォルトの名無しさん** · 2022/08/18(木) 13:30:03.60

>>620
言語でも仕事でも持続可能性のためには作る側が儲かるぐらいがちょうどいい

**デフォルトの名無しさん** · 2022/08/18(木) 13:42:10.72

>>620
>>608 から読み直せ

**デフォルトの名無しさん** · 2022/08/18(木) 14:00:24.69

Juliaはここに入らんの？

**デフォルトの名無しさん** · 2022/08/18(木) 14:19:26.19

ぬるぽ

**デフォルトの名無しさん** · 2022/08/18(木) 14:28:23.47

もちろんプログラマーや生成物実行者やサービス利用者にとっては静的型付け言語の方が大きく有利
プログラミングも静的型付け言語は支援が大きく楽だし実行時デバッグも減らせる
そして実行速度も静的型付け言語の方が速くできるため実行者やサービス利用者も時間の節約や応答性の良さを得られる

**デフォルトの名無しさん** · 2022/08/18(木) 14:31:48.41

>>624
>>608とか一番ダメな回答じゃん
このスレでイキってるやつらって結局このレベルなんだな
視野狭窄

**デフォルトの名無しさん** · 2022/08/18(木) 14:33:36.79

>>627
使い分けができない人の典型的な言い訳ですね

**デフォルトの名無しさん** · 2022/08/18(木) 14:36:30.08

>>628
だからダメダメって言ってるのに横からアホみたいに絡んでくるなよ

**デフォルトの名無しさん** · 2022/08/18(木) 15:54:24.58

>>630
ダメさ加減は君も引けを取ってないぞ
イキり加減もねw

**デフォルトの名無しさん** · 2022/08/18(木) 16:45:13.83

はいはいw

**デフォルトの名無しさん** · 2022/08/18(木) 16:58:47.72

小規模なプログラムを早く作りたいというときに
動的型付け言語は向いている

**デフォルトの名無しさん** · 2022/08/18(木) 17:26:35.30

main関数の型がいつも同じなのはシェルが静的型付けではないからだ
設定より規約
独自のユーザー定義型を設定しなくても使える

**デフォルトの名無しさん** · 2022/08/18(木) 18:13:32.09

>>622
あえて突っ込んでみるが

>具体的な実装をギリギリまで遅らせることができる
to_foo()できるFooableなインスタンスを受け取る前提でBarを作るみたいなのは動的型付けでも静的型付けでも同じじゃない？

>設計が間違っていても無理やり嵌め込むことができる。
これも動的型付けでも静的方付けでも同じじゃない？
渡す型が間違ってるみたいなのは設計間違いというよりコーディングミスでしょ

**デフォルトの名無しさん** · 2022/08/18(木) 18:32:21.72

>>607
今やない
モダンな言語は静的型だけど動的型のように書けるから

**デフォルトの名無しさん** · 2022/08/18(木) 19:10:46.93

>>635
＞なインスタンスを受け取る前提

そういう前提を開発当初に決められなかったり、そもそも問題領域に対する知見が足りなくて手探りで開発を進めるたり。当然「前提」が間違っていることもある。
間違うことを前提に「とりあえず動くものを用意して情報収集しながら開発する」というプロトタイプ開発だと、静的型付けは設計が重すぎて使いづらい。そういうケースだと柔軟性の高い動的型付けの方が便利。

**デフォルトの名無しさん** · 2022/08/18(木) 20:34:52.46

テスト書かないで書き散らすなら静的型はミスが生じにくい分本来的には有利だと思うけどね
ただ、静的型ってモデルとビューモデルみたいな似た型を複数作って左から右に渡すような設計をしがちだからコード量が増えやすいんだよね
静的型でも共通の型を使い回して重複を発生させないことはできるだろうけど、動的型と違って型が目に見えてしまうもんだから、
オプショナルな属性だらけの汚い型が目についてしまって、心理的に適切に型を使い分ける設計になりがち

**デフォルトの名無しさん** · 2022/08/18(木) 20:43:30.66

そもそもメンテをするつもりもテストをするつもりもない程度の用途なら、短いコードで完結に書けることが多い動的型言語は比較的有利そうだね
まあそういうときはなんでもいいから一番慣れてる言語を使えばええやんって感じだが

**デフォルトの名無しさん** · 2022/08/18(木) 20:59:53.63

>>637
いや、それは型推論の無かった静的型言語を使ってた時代の話だよ。
今時の言語は型推論あるからコード書く分には動的型言語と遜色ない。

いくら動的型言語が柔軟だと言ったって想定と異なる型のデータで関数なりメソッドなり呼ばれれば、その部分は動かない。下手したらデータ破壊しながら処理進めてしまいかねん。

**デフォルトの名無しさん** · 2022/08/18(木) 21:02:31.69

>>638
そのあたりの問題は最近の静的型付け言語は既に解決済みではないかな
そういう様々な異なる型に対して、横断的な共通の扱いをしたいならば、
例えばRustでは用途ごとに3通りの対応方法を提供しているよね
(1) ボディ付きenumによる複数の異種型の横断的な収容
(2) impl Traitによる複数の異種型の横断的な共通振る舞いとその静的モノモーフィゼーション
(3) dyn Traitによる複数の異種型の横断的な共通振る舞いとその動的ディスパッチ

**デフォルトの名無しさん** · 2022/08/18(木) 21:10:33.58

プロトタイプには動的型って一見もっともなんだけど
じゃあいつ本番開発に移行すんの？ってのは気になるな
結局ある程度動き始めたらそのままズルズル行っちゃうのでは？
それとも「今日から静的型で書き直すので一ヶ月開発止まります」とかやるの？

**デフォルトの名無しさん** · 2022/08/18(木) 21:10:45.17

>>641
そんな小難しいことを最初から真面目に考えて設計しなければならない時点で遅いんだよ

**デフォルトの名無しさん** · 2022/08/18(木) 21:13:42.36

動的型だと素早く開発できるという話は品質を犠牲にすれば素早く開発できるという話と同じ匂いを感じる

**デフォルトの名無しさん** · 2022/08/18(木) 21:17:56.92

>>643
え？めっちゃ簡単な話しかしていないし
最初から設計せずとも後付けで型ごとに自由なタイミングで任意の対応traitを増やしていける仕組み

**デフォルトの名無しさん** · 2022/08/18(木) 21:18:41.05

かといってサーバーサイドに静的なJavaを導入して安全か？と言われてもなぁｗ
PHPだから危険なのか？という話だし
そもそも関数で引数に型の指定があるない関わらず期待した型じゃないと普通動かないし
静的だから安全というのは何か間違ってる気がするわ

**デフォルトの名無しさん** · 2022/08/18(木) 21:24:02.04

>>637
前提が間違ってた場合の修正範囲に
動的型付けと静的型付けで顕著な違いが出る？
出るならそれを具体的に説明してよ
できれば簡単な擬似コードとかで

柔軟性が高いとか設計が重いとか言うだけだと説得力が乏しい

**デフォルトの名無しさん** · 2022/08/18(木) 21:25:00.81

>>646
動的型付け言語でそれなりの規模のもの書いてたら
関数の引数の型が想定と違った結果
非常に調査が難解なバグとかエラーが出た頃には
致命的な結果になってるとか経験しませんかね…

**デフォルトの名無しさん** · 2022/08/18(木) 21:25:37.80

>>642
>>644
まあそれはある
大抵、プロトタイプと言いながら作り過ぎなんだよ
本来プロトタイプってのは本当に必要最低限のハリボテで十分で、実際に客から金貰って売る前にPMFが完了していなければならない
現実として、そこまでやれるほど優秀なプロダクトマネージャはまず存在しないから、大抵のスタートアップは作って売ってから考えるという馬鹿な状況になる

**デフォルトの名無しさん** · 2022/08/18(木) 21:26:20.58

>>646
そのあたりも最近の静的型付け言語が対応しているでしょう
例えばRustならば引数に対して型指定ではなくtrait指定にできるし
その具体化解決は静的にも動的にも可能だし
もちろんいずれも安全に適用できることをRustでは保証される

**デフォルトの名無しさん** · 2022/08/18(木) 21:43:21.22

>>646
わかる
何か間違ってるよね

極端に言えば
「濡れた猫を電子レンジで温めようとしたらエラーで弾いてくれるから安全」
と同じイメージ

**デフォルトの名無しさん** · 2022/08/18(木) 21:43:46.51

>>643
？？？
動的型付け言語による開発でもこの程度の設計は必要だろ

**デフォルトの名無しさん** · 2022/08/18(木) 21:48:40.33

>>641
「ModelとViewModelみたいな似た型」で普通そんなことするんか？
したことあるんか？
そうさせるFWがあるんか？

**デフォルトの名無しさん** · 2022/08/18(木) 21:57:29.78

>>651
その場合だと
静的型付け言語ならば実行前にそれは危険だとコンパイルエラーで教えてくれて未遂で済む
動的型付け言語ならば実行してしまってネコ死んじゃったエラー

**デフォルトの名無しさん** · 2022/08/18(木) 22:02:54.58

>>648
ぶっちゃけないな
型の想定が違ってるのにそれらしく動いて
かつテストでも発見できないバグで
かつ調査が難解となると相当にレアでしょ

それに定義してる型とあっているからと言って
ドメインエラーを常に拾えるわけじゃない

**デフォルトの名無しさん** · 2022/08/18(木) 22:08:16.63

>>654
猫を電子レンジに入れて本番で実行するような開発者のいるプロジェクトなら
動的型付け言語に比べたら静的型付け言語のほうがリスクは低いだろうね
ただそういう開発者を排除するほうが遥かに安全性が高いと思うよ

**デフォルトの名無しさん** · 2022/08/18(木) 22:11:31.85

静的型付け不要って主張してるのはPHPおじさんしかいないようだけど
何でこのスレにいるのかわからん

**デフォルトの名無しさん** · 2022/08/18(木) 22:13:54.84

>>657も何でいるのか分からんｗ
PHPやってていたらダメとか偏見も良い所
こんな事言っている奴はPHPでも作れんだろｗ

**デフォルトの名無しさん** · 2022/08/18(木) 22:14:06.50

類は友を呼ぶ

**デフォルトの名無しさん** · 2022/08/18(木) 22:19:32.70

>>655
テストで担保というのが手間でしょ
カバーできてなくて本番のランタイムで
エラーを経験してことないのはよっぽど
丁寧に書いているか大してもの作ってないかの
どっちかだね

あと関係ないドメインエラーとか待ちだすのは
詭弁論破の練習？

**デフォルトの名無しさん** · 2022/08/18(木) 22:45:49.60

>>656
で、そういう人を排除できてんの？

**デフォルトの名無しさん** · 2022/08/18(木) 22:48:29.89

>>655
＞それに定義してる型とあっているからと言って
＞ドメインエラーを常に拾えるわけじゃない

0か100の世界線の人ですか？
エラーは早い段階でわかったほうがいいというのは世界の常識だけど、お前の世界線では違うみたいだな。

**デフォルトの名無しさん** · 2022/08/18(木) 22:56:27.19

猫とか車とか飯とか脳みそOOPかよ
お前らのしょうもない例え話は実害があるから本当迷惑なんだよ

**デフォルトの名無しさん** · 2022/08/18(木) 23:30:39.35

>>660
「あーそれなら確かに静的型付けにしてたら有利だね」
って言う現実的なコード例出してみてよ

ドメインエラーってのは
文字列を期待してるところに数値を渡したり
注文番号を期待してるところに配送番号を渡したり
First Nameを期待してるところにLast Nameを渡したりした状況のこと

**デフォルトの名無しさん** · 2022/08/18(木) 23:36:33.83

>>664
それぞれ別の型にしておけば静的に型チェックにて実行前にミスを無くせる
それよりも「文字列を期待してるところに数値を渡したり」が型不一致エラーとならない超弱い型付け言語を使ってるのかね？

**デフォルトの名無しさん** · 2022/08/18(木) 23:40:19.24

>>665
で現実にFirstName型とLastName型を定義して使い分けてるのかね？
OrderId型くらいなら使ってるところそこそこあるが多数派ではないわな

**デフォルトの名無しさん** · 2022/08/18(木) 23:42:51.05

>>666
お前さあ
自分の都合の良いように設計論の話と
どっかの現場の話を切り分けて話するのも
詭弁論破の練習？

**デフォルトの名無しさん** · 2022/08/18(木) 23:52:50.33

>>667
答えられなくなったから逃げてるのかね？
静的型付けマンセーで思考停止してるのでなければ少しは考えてみれば？

**デフォルトの名無しさん** · 2022/08/19(金) 00:09:50.57

>>666
FirstNameとLastNameを間違えるのはプログラミング言語やその型付け方法と関係ない話
そして静的型付け言語が不利になる話でもない
それにより何を主張したいのか？

もし本当に厳格に区別する必要があるならば各々を扱う専用型を設ければよい
そうせずに両方を文字列型で扱っても、変数名、フィールド／メンバー名、関数／メソッド名などの名付けを分ければ互いに入れ違いを避けられる

**デフォルトの名無しさん** · 2022/08/19(金) 00:12:18.59

>>668
いやーすごいすごい完全論破されちゃったな
これでOK？

**デフォルトの名無しさん** · 2022/08/19(金) 00:32:53.46

ドメインエラーとか型付けと関係ない話持ち出してきてるのは何なん？
型が何なのかわからん奴なんだろうな。そりゃ型付きが面倒・邪魔に感じるだろうよ。

**デフォルトの名無しさん** · 2022/08/19(金) 00:40:23.18

KEИTAωωω

**デフォルトの名無しさん** · 2022/08/19(金) 00:45:33.75

変数に型がないRubyとかでも、ドメインモデリングするならバリューオブジェクトのクラスも作るし、
変数に型がある言語でもメンテの必要があるアプリケーションならテストコードは必須だろ

どっちがどういいかはトレードオフがあるだけ

**デフォルトの名無しさん** · 2022/08/19(金) 07:54:59.22

静的型であっても型推論なら姓と名の型をそれぞれa, bとして
どっちもstringと確定するまではaとbは区別される
aとbが入れかわるコードが紛れ込んでいたらstring確定しなくてもa=bは確定

**デフォルトの名無しさん** · 2022/08/19(金) 08:02:21.75

そもそも、ここに書き込んでるような人は、意識高い人だから、自分を基準に考えてはダメでは？

**デフォルトの名無しさん** · 2022/08/19(金) 08:09:54.91

スレタイにある次世代言語は全て静的型付け言語
静的型付け言語が圧倒的に優れているため全てがそうなっている
動的型付け言語には次世代言語が存在しない

**デフォルトの名無しさん** · 2022/08/19(金) 08:39:00.86

>>647
Visitorパターンみたいな処理をする時かね。静的型付けだと型を識別するためにacceptが必要だけど、動的型付けなら動的に型を判定することで手を抜ける。

まぁ、そもそも静的型付け言語も動的な型判定をある程度取り込んでいるからなぁ。パターンマッチとか。
型判別可能な共用体を使える静的型付け言語なら、上手いこと動的に判定する範囲を制限できる。
けど、そういう言語てあったっけ？

**デフォルトの名無しさん** · 2022/08/19(金) 08:54:53.36

>>677
型判別可能な共用体はまさに>>641の(1)でしょう
それに加えてジェネリックから型を制限していく(2)や(3)の方法も可能

**デフォルトの名無しさん** · 2022/08/19(金) 09:24:26.81

今回セレクトされてないけどElixirとJuliaは動的型付けだね
Elixirはerlangの系譜だから特にこだわりがないかもしれないがJuliaが動的型付けなのは示唆的に思える

**デフォルトの名無しさん** · 2022/08/19(金) 10:07:48.19

juliaが目指したのがpythonの置き換えだからでしょ。

**デフォルトの名無しさん** · 2022/08/19(金) 10:24:36.76

Juliaは少量のコードで大量の計算をする言語だからJITに無茶苦茶時間かけても大して問題にならないし、
そもそも数値計算で扱う型って整数と浮動小数点数とその配列が殆どで、型を厳密に扱う必要性が薄い
同様にFORTRANなんかも型は緩めだよ

**デフォルトの名無しさん** · 2022/08/19(金) 11:40:00.25

型というかテンソルのshapeとかは気にするけどね。
ただ型というよりもうちょっと具体的というかレイヤーが低いとこでの合わせって感じではある。

**デフォルトの名無しさん** · 2022/08/19(金) 11:47:47.45

行列の大きさとかを型で指定したいと思うことはあるけどIdrisにあるような依存型が必要になるのかな
ちゃんと勉強してないからわからんw

**デフォルトの名無しさん** · 2022/08/19(金) 12:07:38.97

>>678
ボディ付きenumというのはF#の判別共用体のことかしらん。Haskellだと直和型かね。

**デフォルトの名無しさん** · 2022/08/19(金) 14:15:06.23

>>684
いわゆる代数的データ型だな。
プログラミング言語によってそれを、
直和で表したり、
タグ付き共用体で表したり、
値格納付きenumで表したり、
視点は各々で異なるが同じもの。

**デフォルトの名無しさん** · 2022/08/19(金) 18:07:04.50

Rustはデストラクタ内のエラーは無視される実装が多いので、
IO絡みのデータ構造はdropされる前にflushなりsync_allなり呼び出さないけないが、忘れられがちで誤ってプログラムが世に溢れている
このあたり良い感じに処理してくれる安心なシステムプログラミング向け言語ってありますか？

**デフォルトの名無しさん** · 2022/08/19(金) 18:15:52.02

いい感じってなに

**デフォルトの名無しさん** · 2022/08/19(金) 18:39:22.66

RustはC++の3倍速い。

**デフォルトの名無しさん** · 2022/08/19(金) 19:04:29.00

>>687
Rustベースで考えるならスコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラーにしてくれるようなものを想像している
標準ライブラリやサードパーティーライブラリもこのルールに従って作られていてほしい
?で関数の途中で抜けた場合はエラーにしない

**デフォルトの名無しさん** · 2022/08/19(金) 19:10:51.99

>>689
ラッパー作ってDrop実装してその中で「特定の関数」を呼べばいいんじゃね
dropの前にflushなりsync_allなり呼ぶべきかは用途次第だと思う

**デフォルトの名無しさん** · 2022/08/19(金) 19:20:17.50

>>690
それはFile等従来の構造体でもやっている
dropの中でエラーが発生した場合にpanicくらいしか呼び出し元に伝える手段がないのが問題
標準ライブラリでは単にエラーを無視する実装になっていて、他のライブラリも多くは同じだと思う

**デフォルトの名無しさん** · 2022/08/19(金) 19:34:55.23

> dropの中でエラーが発生した場合にpanic

そっか
つらいね

**デフォルトの名無しさん** · 2022/08/19(金) 19:37:53.86

Rustプログラマはすぐにpanicに頼る
アホなんだろうなと

**デフォルトの名無しさん** · 2022/08/19(金) 19:39:05.15

>>686
ない
良い感じに処理してくれる時点でシステムプログラミング言語ではない
システムプログラミング言語とは良い感じ処理してくれるシステムを作るための言語である

**デフォルトの名無しさん** · 2022/08/19(金) 20:02:15.51

>>691
ぶっちゃけどんな言語でもデストラクタ的な処理を途中で止めるのはダメじゃね？
そういうのは本来は独立した関数なりメソッドなりにするしか無いと思うが。

**デフォルトの名無しさん** · 2022/08/19(金) 20:23:10.52

>>693
それは逆でpanicは続行不可であり、
続行のためには発生してはいけないこと。
つまり続行させるつもりがないならば、
panicを引き起こしても構わない。
続行させる意志がある場所ならば、
自分でエラー処理を書いてpanicを発生させない。

>>695
もちろん用意されているので、
それを自分で呼べばエラー発生したかどうかも掴める。
そして、デストラクタでpanicすることもない。

**デフォルトの名無しさん** · 2022/08/19(金) 20:55:29.37

コンパイルエラーにするためにはどの経路を通っても終了処理を経由すると解釈できなくてはならないけどそれってあまり簡単ではなくないか

**デフォルトの名無しさん** · 2022/08/19(金) 22:59:39.17

dropの呼び出し元ではなく
JoinHandle::joinの呼び出し元に結果を伝えればいいんでしょ
実際、panicの引数はjoinの戻り値になる