次世代言語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/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の戻り値になる

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

>>689
自分でcontext manager的なものを作るのがいいと思う
flush以前にエラーが発生してる場合にflushすべきかどうかは
アプリロジックなのでコンパイルエラーにするのは何か違う気がする

**デフォルトの名無しさん** · 2022/08/20(土) 01:26:15.59

>>689
アホか。
write(2)のマニュアルのエラー項目を読み直せ。
コンパイル時点で全部対処できると思ってるのかよ。

**デフォルトの名無しさん** · 2022/08/20(土) 03:52:49.34

>>695
その通りで原則drop内でエラーが発生しうる処理はやらせるべきではないよね
だからエラー発生しうる処理がdropに至るまでに呼び出されているかコンパイル時に検知できると良い

>>697
プログラムの実行パス内で値がmoveされたか否かの解析が現状できているので、それと同じ仕組みでできるのではないかな

>>698
マルチスレッドならそれでも良いけど、単なるIOで必ずスレッドなりタスクなり生成させるのはよろしくない
catch_unwindでも良いがあらゆるpanicをせき止めてしまうのはオーバーキルすぎる

>>699
そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
flushを呼び忘れてスコープ終端に到達してしまった場合ね
BufWriterなんかだと書き込みデータ量が少ない場合にwrite(2)が一度も呼び出されないままdropが呼び出されて、
そこで初めてwriteしようとしてエラー検出されることがある
BufWriterのドキュメントにはdrop前にflush呼ぶようにとは書いてあるが、プログラマが気をつけるのではなくできる限り機械的に検知できるようにしたいよね

**デフォルトの名無しさん** · 2022/08/20(土) 04:00:19.70

>>700
コンパイル時にIOエラーに対処せよなんて話はしてないよ
そもそもコンパイル時にwrite(2)が呼び出されないんだからそのエラーに対処できるはずもない

drop内でエラーが発生しても検知できないから、dropの前にflushなどの呼び出しを強制できないの？という話

**デフォルトの名無しさん** · 2022/08/20(土) 05:07:56.91

>>702
なるほど。
4回目ワクチンのせいで読解力が低下してるようだ。エロいページ見て心を静めてくる。

**デフォルトの名無しさん** · 2022/08/20(土) 07:41:29.18

論理的にモノを考えられるヤツは４回も打たない

**デフォルトの名無しさん** · 2022/08/20(土) 09:18:15.53

医療従事者とか高齢者施設従業員とか正規の4回目来てるんですよ

**デフォルトの名無しさん** · 2022/08/20(土) 10:31:20.74

>>701
>そういうことではなくて、drop内でエラーが起きた場合の話を気にしている
わかってるよ
drop前に確実にflushが呼ばれるようにしてflushした場合のエラーをハンドリングしたいなら
context managerを自作するのがいいって話

buffer.len()をチェックしてcompile_error!でエラーにするようなAPIも作れなくは無いかもしれないけど
それをやる場合にもBufWriterへの一連操作をラップしたcontext manager的なのを作ることになるので
エラーにするんじゃなくてflushしてあげたほうが親切

**デフォルトの名無しさん** · 2022/08/20(土) 11:15:29.57

なにこれ
ワクチン接種証明書の例え話が役に立つという寓話なのか
fn hoge(&mut self) -> flush証明書 {
flush証明書::new(self.file)
}

**デフォルトの名無しさん** · 2022/08/20(土) 14:05:39.10

>>686
システムプログラミング向け言語という時点でGC言語は対象外となる
無条件RAIIによる自動デストラクタ呼びを前提としている点でもGC言語は対象外となる

>>689
書き忘れていたらコンパイルエラーにするという時点で
RAIIもどき実現のためのusingやdeferなど使うGC言語はそれを書き忘れてもエラーとしないから
GC言語は前提にすら辿り着けないことになる

結局その機能を現在もしくは今後に実現できる言語は非常に限られている

**デフォルトの名無しさん** · 2022/08/20(土) 14:47:10.43

>>706
context managerを知らないんだけど、pythonの用語で合っているかな？
スコープの入り口と出口に処理を差し込むようなものに見えたけど、こんな関数を用意するようなイメージ？

fn with_file(f: impl FnOnce(&mut File) -> io::Result<T>) -> io::Result<T> {
　let file = File::create(...)?;
　let res = f(&mut file)?;
　file.flush()?
　Ok(res)
}

確かにこれで解決するケースも多いね

**デフォルトの名無しさん** · 2022/08/20(土) 15:11:47.48

>>709
そういう単純な対応は他言語含めてよくあるパターンだが狭い範囲しかカバーできない欠点がある
例えば複数のファイルなどを順序前後して扱うと破綻
その観点の専用クロージャとなっているためそれ以外からの処理を巻き込みたい時にも破綻
ファイルディスクリプタを保持して戻りいつ解放かすぐ決定しない場合も破綻
並行並列化する時も破綻

**デフォルトの名無しさん** · 2022/08/20(土) 15:25:13.28

>>709
こういっては失礼かもしれないけど、なんて汚い実装だ....

**デフォルトの名無しさん** · 2022/08/20(土) 15:32:14.61

>>710
だからこれで解決するケース "も" あるって書いたでしょ
もっとよいワークアラウンド考えるか次世代言語の仕様提案してくれ

>>711
どこがご不満？

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

>>712
Rustスレで半年前に出ている以下のアプローチはどう？
他の言語では無理だけどRustならば所有権の行方を静的に解析してコンパイラが持っているため

https://mevius.5ch.net/test/read.cgi/tech/1636247099/700
＞コンパイラは解析してdropさせるべき位置を把握しているから
＞そこへ至る全ての経路上で例えばFinalize trait実装型はそのメソッドfinalize()を呼んでいないとコンパイルエラーとなる
＞というような制約をするFinalize trait

**デフォルトの名無しさん** · 2022/08/20(土) 16:55:09.50

>>713
それは良さそう
dropに至るまでの処理でエラーが発生した場合はFinalize不要にするとかの考慮は必要そうだね
?で脱出したか否かで区別できるかな？

**デフォルトの名無しさん** · 2022/08/20(土) 18:48:46.98

>>709
そう、そういうイメージ
FileManager的なstructを定義してnewするときに内部でFile::createして持っておいて
withでクロージャを受け取るようにするとネストしたりしやすい気がする

buffer.len()とcompile_error!マクロでどうにかする方法は無理そうだった

あとは明示的flush未実行の型と実行済みの型とをそれぞれ作って
一連のI/O処理の戻り値をflush実行済みの型にしておくことで
flush忘れたらコンパイルエラーにするという方法ならできそう
面倒くさいけど

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

>>715
後半のアイディアについてはコンパイルエラーにするのは難しそうだね
dropの呼び出しを禁止したりコンパイルエラーにしたりする方法は多分ないと思う
リンク時エラーにするアイデアはあるみたいだけど、ちとやり過ぎな感がある
https://mevius.5ch.net/test/read.cgi/tech/1636247099/695

**デフォルトの名無しさん** · 2022/08/20(土) 21:47:48.47

リソース確保、開放といった共通化できる操作はテンプレート化したいが、そのために真にやりたい操作をクロージャや関数にして一段ネストを深くしてしまうのがなんか違う気がするんだよなぁ。

**デフォルトの名無しさん** · 2022/08/20(土) 21:56:02.14

システムプログラミングじゃそれが本質的に指摘すべきことなんだから仕方ないだろ。

**デフォルトの名無しさん** · 2022/08/20(土) 22:17:19.61

>>713のやり方ならば
そのような対応も不要でプログラムの構造も変えずに済むし
関数から返したり長生きしてもよいし
デストラクタでエラーが起きうる型に適用しておくだけでよく
利用側プログラムに他の付加コードは不要だから理想的にみえる

**デフォルトの名無しさん** · 2022/08/20(土) 22:34:29.93

>>719
特定条件のときだけ開放処理が行われるみたいな分岐があるケースとか考え出すと難しくないかな。

まだ finalize してなければ finalize するみたいな処理を Rust が決定したdrop位置の直前に書かせるという制約を課すだけでいいのか？

**デフォルトの名無しさん** · 2022/08/20(土) 23:34:50.48

>>720
>>713のメソッドfinalize()は最後に呼ばれるべきものだから
Selfで受けて消費しちゃう仕様でもいいよね
するとコンパイルエラーが起きない正しいプログラムでは自動drop()が全てfinalize()の中で起きる
つまりfinalize()以外で自動drop()が起きる部分をコンパイルエラーとすればよいのではないか？
例えばfinalize()を呼ばずにスコープブロックエンドに達しているコードと
ブロックから脱出return/breakしているコードをコンパイルエラーとする

**デフォルトの名無しさん** · 2022/08/21(日) 00:02:05.58

>>713は実現不可能だよ

**デフォルトの名無しさん** · 2022/08/21(日) 00:50:42.36

>>722
実現できる
コンパイラはdropする可能性のある場所を全て把握していて、そこへdrop()呼び出しコードを埋め込んでいる
つまり>>713を>>721の方法で実現するのは容易
finalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする対応をコンパイラ加えるだけで実現できる

**デフォルトの名無しさん** · 2022/08/21(日) 01:16:56.45

こういう時は自前主義の方が冷静
自前でできないことを期待するのは虫が良過ぎる

**デフォルトの名無しさん** · 2022/08/21(日) 02:47:44.56

絵に描いた餅はおいしいですか？

**デフォルトの名無しさん** · 2022/08/21(日) 05:02:05.10

>>723
> finalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする対応をコンパイラ加えるだけで実現できる
それは「現状では」実現不可能って言うんでは？

**デフォルトの名無しさん** · 2022/08/21(日) 05:25:55.50

Rustならば現状のコンパイラで実現できる
finalize()を呼び忘れていたらコンパイルエラーとすることが可能

**デフォルトの名無しさん** · 2022/08/21(日) 09:26:43.80

他人の現状よりも
自前でできそうな願望がいい

**デフォルトの名無しさん** · 2022/08/21(日) 10:53:20.77

>>721,723
「つまり」の前後の論理が全くつながってない

**デフォルトの名無しさん** · 2022/08/21(日) 11:04:13.82

つまり
絵にすらなってない餅

**デフォルトの名無しさん** · 2022/08/21(日) 11:37:20.10

つまり霊感商法

**デフォルトの名無しさん** · 2022/08/21(日) 12:28:30.42

容易と言い切るなら実装見せて欲しいな

**デフォルトの名無しさん** · 2022/08/21(日) 13:05:23.69

つまり複製おじさん論法

**デフォルトの名無しさん** · 2022/08/21(日) 15:07:41.13

つまり「募ってはいるが募集はしていない」的な話？

**デフォルトの名無しさん** · 2022/08/21(日) 16:22:57.49

つまり
現状のコンパイラで容易に実現できるが
コンパイラに手を加えずに実現できるわけではない
ということでしょw

**デフォルトの名無しさん** · 2022/08/21(日) 17:39:47.32

>>735
現状のrustならできるらしいよ ⇒ >>727
なおどうやるかは本人しか知らないみたいだけどw

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

>>735
「現状のコンパイラで実現できる」
というのは
「現状のコンパイラ(の機能を活用してfinalize()内以外でdrop()呼び出すコードを必要としたらコンパイルエラーとする新機能をコンパイラに加えるだけ)で実現できる」
という意味なんでしょw

**デフォルトの名無しさん** · 2022/08/21(日) 19:08:55.38

次世代言語の話だから、現行言語をもとに「原理的には可能」で議論も悪かないと思うけどね。

**デフォルトの名無しさん** · 2022/08/21(日) 19:35:37.95

悪くはないがコンパイラに手を加える必要があるならそう言わんといかんわな。
しょーもないわかりやすいプライド見せられてもなって気分になるわけで。

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

行動経済学あるある
実験前の説明では「原理的にはどっちを選んでもOK」と言う
実験後「経済的にはこっちを選ぶのはバカ」と言い出す

**デフォルトの名無しさん** · 2022/08/21(日) 21:53:47.95

話題の要件は「finalize()等の関数を呼び忘れていたらコンパイルエラーにすることができるかどうか」でいいんだよな
そして他の言語ではそれを実現できなくて「Rustで実現できるか否か」という話でいいんだよな

それならば現行のRustで実現可能　実行確認可能なソースコード
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7086ce3b73ad74a5375e970c7dfc5951

fn main() -> std::io::Result<()> {
let foo = Foo::new("Hello, World!");
foo.finalize()?; // この行をコメントにするとコンパイルエラー
Ok(())
}

struct Foo { s: String, }
impl Foo {
fn new(s: impl Into<String>) -> Self {
Foo { s: s.into() }
}
fn finalize(self) -> std::io::Result<()> {
let mut me = std::mem::ManuallyDrop::new(self);
println!("Finalizing... {}", me.s);
drop(&mut me.s);
Ok(())
}
}
impl Drop for Foo { ...

**デフォルトの名無しさん** · 2022/08/21(日) 22:38:05.89

>>741
それ>>716に書いてあるリンクエラーのコードを改変したんだとおもうが
let fooとfoo.finalize()の間に処理挟むだけでリンクエラー発生する

**デフォルトの名無しさん** · 2022/08/21(日) 22:51:41.20

使い勝手を含めて改善すべき点はあるから
それらはRustコンパイラが直接サポートすることで解決すればよい
例えば>>741でも用いているManuallyDropはコンパイラサポートによりその機能を実現している

**デフォルトの名無しさん** · 2022/08/21(日) 22:54:16.54

リンクエラーってコンパイルエラーではなくない？

**デフォルトの名無しさん** · 2022/08/21(日) 22:56:51.95

この人これで日曜日丸1日潰したのかな

**デフォルトの名無しさん** · 2022/08/21(日) 23:03:08.26

proc-macro作るとかclippyのlint追加するとかそういう方向性ならやりようはあるんでないの

**デフォルトの名無しさん** · 2022/08/21(日) 23:05:54.42

型情報必要だからproc-macroは無理そう
compiler-pluginでなんとかしてくれ

**デフォルトの名無しさん** · 2022/08/21(日) 23:07:11.79

コンパイラがサポートすればリンク使わずに済むから真のコンパイルエラーとなるのでプロトタイプとしてはいいんじゃない

**デフォルトの名無しさん** · 2022/08/21(日) 23:13:22.78

実用上は実行前に検出できれば良いのでリンク時エラーでも問題ないとは思うけど
リンクまでしないcargo checkやrust-analyzerやclippy等で検出できないという違いはあるから
コンパイルエラーとリンク時エラーは区別はした方が良いだろうね

**デフォルトの名無しさん** · 2022/08/21(日) 23:26:12.30

Rustではコンパイラ対応で完全版も実現できる見込みが立ったようだけど
他の言語ではどうなの？