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

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

前スレ
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/

**デフォルトの名無しさん** · 2022/01/31(月) 10:12:07.29

>>89
C/C++の可読性の悪さは
Rustで改善されていてとても使いやすくなっている
GC依存で設計された既存システムをそのまま移植するのは無謀だが
最初からGCに依存せずに設計が可能でありRustなら可読性が問題になることはない

**デフォルトの名無しさん** · 2022/02/01(火) 01:49:52.13

自分はRustのCargoとその気になればunsafeで自由に書けるのが気に入ってる
Rustはとにかく美しいと思うな

**デフォルトの名無しさん** · 2022/02/01(火) 01:53:40.31

たしかに、Cargoらへんのエコシステムに関してはC++とは勝負にすらならないな
npmを反面教師にしたのかな、よくできてるよね

**デフォルトの名無しさん** · 2022/02/01(火) 14:13:16.30

Rustが美しいと思うのはどういう点なのか、具体的に聞きたくなる。これはC/C++と比べてる話じゃなく現代的な言語の話で
無駄にタイプ量が多くマクロと言語が一貫してなく、アトリビュートも独立しおり言語との一貫性が全くない

**デフォルトの名無しさん** · 2022/02/01(火) 14:17:41.49

例えば const fnやコンパイル時定数などはコンパイル時にコードを動かして計算したりするが、一方でアトリビュートで
#[cfg(unix)]とかやったりして思想がバラバラ、まあ破綻はしてないしC/C++のマクロなんかと比べれば100倍ましだけど

**デフォルトの名無しさん** · 2022/02/01(火) 14:19:22.77

>>93
型推論も賢く強力な静的型付け言語なのにタイプ量は少ない
アトリビュートが言語本体と独立していて区別しやすくプログラミングする上で見やすい

**デフォルトの名無しさん** · 2022/02/01(火) 15:56:11.68

>>93
マクロと言語が一貫してる言語ってどういうイメージなんだろう
Lispしか思い浮かばなかったけどさすがに違うよね

**デフォルトの名無しさん** · 2022/02/01(火) 19:27:41.48

>>92
Cargoが良すぎて今まではちょっとしたスクリプトをPythonで書いてたのだけど
そういうのも全部Rustで書くようになってしまった

>>93
むしろこのアトリビュートが好きで
同一ファイルにtestをちゃちゃっと書けるのだったり
あーこれこれ、こういうのが欲しいんだよってのがほぼ全て揃っている

大小様々なソフトウェアを書くためにやっと人類が手に入れた言語かなって
だがなんかマンセーしすぎてスマソ

**デフォルトの名無しさん** · 2022/02/02(水) 09:03:27.50

Rustの長い長い型名
https://qiita.com/mp2147483647/items/4cc56b0cc80369828a88

**デフォルトの名無しさん** · 2022/02/02(水) 20:32:31.23

>>93
マクロはRustの言語ルールを満たしていなくてよいところが要点
その定義文法も変換が主たるものだから別記法が理に適っている

>>98
Rustは強力な静的型付けにより安全と効率を両立させている
結果としての型名が長くなることがあっても
強力な型推論およびトレイト静的実装型宣言により実際の型名を記述する必要がない
その例は極端な特殊な例にも関わらず同様にして最終型名を記述せずに済んでいる

**デフォルトの名無しさん** · 2022/02/03(木) 02:33:37.86

もしかしてrustってめちゃくちゃ完成度高くね？
バックエンドだけじゃなくて
wasmでブラウザのフロントエンドにも進出してくるっぽいし
typescriptのシェアも奪いそう

**デフォルトの名無しさん** · 2022/02/03(木) 11:10:49.98

Go人気らしいけど嫌い
やっぱりC++使いはRustに行くべきなんかな

**デフォルトの名無しさん** · 2022/02/03(木) 11:48:25.31

Rust、アルゴリズム書くのに超絶向いてないよ。

**デフォルトの名無しさん** · 2022/02/03(木) 13:51:46.29

アルゴリズム書くのは普通疑似言語でやるわな

**デフォルトの名無しさん** · 2022/02/03(木) 17:00:23.94

>アルゴリズム書くのは普通疑似言語でやるわな
何言ってんの？

**デフォルトの名無しさん** · 2022/02/03(木) 18:00:00.71

アルゴリズム自体の記述には自然言語か疑似言語かpythonみたいなスクリプト言語使うのが多いのでは

｢アルゴリズムを書く｣ってアルゴリズムを使ったプログラムを書くという意味？
そうだとしたら対象が広すぎるのでもうちょっと具体化して欲しい

**デフォルトの名無しさん** · 2022/02/03(木) 18:01:17.86

そんなしょーもない誤魔化しはしなくていいよ。

**デフォルトの名無しさん** · 2022/02/03(木) 18:07:41.52

アルゴリズムと一概に言ったってソートみたいなのは別にrustでも普通に書けるでしょ
どういうアルゴリズムを実装しようとして困ったのか教えて欲しい

**デフォルトの名無しさん** · 2022/02/03(木) 18:24:36.45

じゃあB-tree、赤黒木、ダイクストラ、フィボナッチtree、なんでもいいから書いてみりゃいいよ。

**デフォルトの名無しさん** · 2022/02/03(木) 18:28:40.55

木構造やグラフ構造が書きづらいって話かな

**デフォルトの名無しさん** · 2022/02/03(木) 18:59:23.99

変な日本語だな
アルゴリズムの勉強には向いてない、ということを言いたいんだろうけど

**デフォルトの名無しさん** · 2022/02/03(木) 19:05:25.62

どうでもいいイチャモンづけにこだわるやつだな。。
だから実際組んで見ろって。。何もしないくせに。

**デフォルトの名無しさん** · 2022/02/03(木) 19:12:44.13

新しいrustの弱点の話聞けるかと思ったら結局いつものグラフ構造の話だったので興味を失ってしまっただけです

**デフォルトの名無しさん** · 2022/02/03(木) 19:23:59.05

>>112
Rustでキューとかスタックとかって便利に使えるの？

所有権の関係で、要素をいじるときはpopしてから操作するのかしらん？

**デフォルトの名無しさん** · 2022/02/03(木) 19:34:47.62

>>113
普通は get_mut に類するメソッドが用意されててコレクションから取り出さなくても編集できるはず
同じコレクション内の他の要素への参照を持たせようとすると難しいかもね

**デフォルトの名無しさん** · 2022/02/03(木) 19:51:02.49

>>114
サンクス。
さすがにスタック・キュー(所有者)に要素の操作を移譲するようなことはしないか。実用上は妥当なところか。

**デフォルトの名無しさん** · 2022/02/03(木) 19:57:30.61

>>113
言語と切り離して論理的に考えた時に
安全な構成と操作ならばRustでも簡単
危険な構成や操作ならばRustでは出来ない(unsafe使えばCと同じ操作が可能)

さらに加えて
危険な構成や操作に成り得るが
限られた一貫した用い方をしている限り安全な場合
新たな型を作って危険な操作を内部に閉じ込めてしまい
安全な操作のみ外部に提供することで利用者はunsafeを用いずに済むことができる
Rustの標準ライブラリもそのようにして作られている

**デフォルトの名無しさん** · 2022/02/03(木) 23:53:53.52

>>112
毎回そうやって曖昧にして逃げてるんだね。進歩ないね。

**デフォルトの名無しさん** · 2022/02/04(金) 00:36:32.80

>>117
そこはグラフも表現できないクソ雑魚言語乙ってあおるべきなのになんで下手くそな人格攻撃してしまうのか

**デフォルトの名無しさん** · 2022/02/04(金) 12:24:28.50

具体的にするならミュータブルなグラフ構造をスレッドセーフに扱うのは人類が思っている以上に難しいことで、それを言語側の制約で扱うならこうならざるを得ないくらい難しい問題だ、ということではないの？

**デフォルトの名無しさん** · 2022/02/04(金) 13:24:42.43

例えば何かノードをたどっている最中にいつの間にか戻り先が変わってるとかいちいちケアしてコード書けないから、結局排他処理やスナップショットすりなんらかの工夫が必要
データ構造の操作だけ完璧に仕上げても応用きかないからそこまで深く考える必要ない

**デフォルトの名無しさん** · 2022/02/04(金) 15:25:21.40

そうね
スレッドセーフを諦めれば他の言語に近いくらいに簡単にできるのではないか

**デフォルトの名無しさん** · 2022/02/04(金) 15:44:53.55

C言語→Rustするトランスパイラーですべて解決じゃね？
Rustだからメモリも安心安全だぞ

**デフォルトの名無しさん** · 2022/02/04(金) 17:43:24.41

>>95-99
今どきのコンパイル型言語で型推論が強力でない言語なんてありますか？#[attribute(key = "value", value2)]とか書いててタイプ量は少ない？
最近は自作のアトリビュートが書けるようになりましたが、普通は言語サブセットは小さくして、そのサブセット言語でアトリビュートを実現してれば
このように無理やりカスタムアトリビュートを出す必要はなかった。
一番の最低なところはCargoだと思う、これのせいでコンパイルが異常に遅い。Pythonでもpipやデコレーターはありますがホントにマンセーですね
マクロの定義文法も変換が主たるものだから別記法が理にかなっているとの事ですが、設計段階では、そんな事は一言もホアレは
言ってません。0.2でクラスが導入され、0.3でインターフェースが導入され、0.4でトレイトが出来てクラスが削除された。1.0以降も酷い互換性の
破壊が続いて、安定しだしたのは1.20以降です。
個人的に気に入らないのはfunctionはfnとするのにmutableはmutと使用頻度が高いものがfnよりタイプ量が多い事。「::」も無意味に
2回打たせる意味が分からない。アトリビュートも#[...]とか異常に無駄。ほかの言語のようにパターン束縛表現があるので@は使えませんが
「#」だけで良いでしょう・・・
確かにマクロ呼び出しは「!」とわざと区別するように思想が影響していますが、マクロ中の$はマクロ展開ではコンパイラを単純化させて
コンパイルを速くするためだけにプログラマへ負担を押し付けているだけです。ただ「!」もNeverと別の意味があり、暗黙の型強制なんて
わざと敷居を高くすることに言語設計者は考えているとしか思えない
Occamで最初のバージョンが作られたけど、インデントスタイルのオフサイドじゃなくC/C++風にしたのは、好みで｛｝スタイルを好む人が
多いから（タイプ量は増えますが）許容範囲でしょうが・・・

**デフォルトの名無しさん** · 2022/02/04(金) 17:50:56.66

趣味・好みじゃなくて問題があるという話なら
なぜ本家じゃなくここに書くw

**デフォルトの名無しさん** · 2022/02/04(金) 18:12:52.54

0.2からおっかけてたのならattributeの文法議論の時にそれ主張しとけば良かったのに

あとcargoのせいでコンパイルが遅くなるというのはどういうこと？
パッケージマネージャーがあるせいでcrateが細分化されてリンク時間が延びることを言いたい？

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

>>123
Rust 1.0がリリースされた2015年よりも昔の0.x時代の話で叩いても無意味ですぜ
あとは1文字タイプ量が多いとかどうでもよい話ばかり
言語機能については批判がないということはRustの優秀性を認めてるわけか

**デフォルトの名無しさん** · 2022/02/04(金) 23:40:44.00

Rust並に実行速くて
Rustよりもプログラミングしやすい言語がない
結果として現時点でのベストな選択肢はRust

**デフォルトの名無しさん** · 2022/02/05(土) 00:06:09.72

c言語の型宣言も後置にしてくれねーかな。

**デフォルトの名無しさん** · 2022/02/05(土) 08:13:51.74

Rustの唯一の欠点は、メモリ管理をしないといけないところだな。
ここも選択肢を用意してくれれば良いのに。

**デフォルトの名無しさん** · 2022/02/05(土) 10:00:32.68

手動でメモリ管理したい人向けの言語に何言ってんだ

**デフォルトの名無しさん** · 2022/02/05(土) 12:03:26.16

そうは言っても、メモリ管理したい人って需要少なくない？
今のままでは、C.C++代替以上にはなれない気がする。

**デフォルトの名無しさん** · 2022/02/05(土) 12:54:51.75

それ以上に何を求めるってんだ

**デフォルトの名無しさん** · 2022/02/05(土) 13:14:08.46

言うほどメモリ管理してるか？RAIIとスマポに頼りっきりのくせに
参照カウンタとかもはや実質的に確定的ですらないやん

**デフォルトの名無しさん** · 2022/02/05(土) 14:54:37.48

>>133
そこはC++も同じだけど
C++よりも更にメモリ管理の記述が少なく済むのがRust
それでいてコンパイルが通った時点でメモリやデータ競合などの安全性が保証されるのがRust

**デフォルトの名無しさん** · 2022/02/05(土) 15:02:39.39

その上でRustは現代的なプログラミングパラダイムが洗練されて採り入れられているため書きやすい
つまりちょっとしたメモリ管理を意識してプログラミングするだけで他より数倍～十倍速くなることもあるのだから
例えばサーバー経費を何分の1に激減させつつレスポンスも良いという実利的なメリットにも効いてくる

**デフォルトの名無しさん** · 2022/02/05(土) 17:29:39.72

>>133
> 参照カウンタとかもはや実質的に確定的ですらないやん

原理的には確定的やん
GC有り言語でガベコレタイミングに苦しんだことあるやつなら
ハッキリとRAIIとGCの間に線が引ける

**デフォルトの名無しさん** · 2022/02/05(土) 17:48:34.36

>>136
不要となったら直ちにデストラクタが呼ばれる点で優れてるよな
GC言語ではそれが出来ないので後始末の記述を毎回書くことで一部補うかその機能がないか

**デフォルトの名無しさん** · 2022/02/05(土) 18:36:32.12

RAIIとGCは対立する概念じゃないがな。C++/CLIで共存できてる。

**デフォルトの名無しさん** · 2022/02/05(土) 20:00:06.29

RAII言語は必要があれば言語の枠外でGCライブラリなどを用いてGC利用も可能
その逆にGC言語はRAII利用が不可能

**デフォルトの名無しさん** · 2022/02/05(土) 20:40:28.08

それはRAIIの機能がない言語ではRAIIが使えないと言っているに等しい。

**デフォルトの名無しさん** · 2022/02/05(土) 21:10:31.12

循環参照もプログラマが自分でWeak<T>使ってなんとかするっていう言語だ
面構えが違う

**デフォルトの名無しさん** · 2022/02/07(月) 00:03:08.00

>>126
で、Rustって駄目ブラウザ以外に何作れんの？お前何作ってんの？内容ゼロで優秀性なんて言い出すウンコのコード見せろよ

**デフォルトの名無しさん** · 2022/02/07(月) 00:13:06.30

>>142
Deno

**デフォルトの名無しさん** · 2022/02/07(月) 02:07:52.70

数年前ならいざ知らず未だにRustに実用プロダクトあるのという
煽りは痛い人になっちゃったな

**デフォルトの名無しさん** · 2022/02/07(月) 03:24:58.20

なんかRuby界隈みたいに知識のアップデート止まってる人たち多いね
もうRustなんてそこら中で使われまくってんのに

**デフォルトの名無しさん** · 2022/02/07(月) 09:18:42.53

Rustは低レイヤやライブラリから徐々に侵食していく感じだからなかなか気付かれにくいかもね
Cのライブラリと思ってたら実装はRustに置き換わってた、とかよくある

**デフォルトの名無しさん** · 2022/02/07(月) 12:33:27.96

「よくある」んなら具体例をどうぞ

**デフォルトの名無しさん** · 2022/02/07(月) 12:54:30.50

自分はGNOMEとFirefoxしか知らんな
既存の実装がrustに置き換わるというよりrustで書き直された代替実装が登場してる印象

**デフォルトの名無しさん** · 2022/02/07(月) 12:56:04.35

VSCodeの検索にripgrepが使われるようになったのも広義の置き換えとは言えるか？

**デフォルトの名無しさん** · 2022/02/07(月) 13:02:36.93

この手の手合はそんなものは下らない一般的じゃないと
言い続けるだけだからなあ

**デフォルトの名無しさん** · 2022/02/07(月) 13:48:06.41

curlとかpycaもかな
この手のは最初に入るときはレガシープラットフォーム対応の問題とかで話題になるけど
一度入ってしまうと採用が広がっても特に取り上げられることはないからなぁ

**デフォルトの名無しさん** · 2022/02/07(月) 14:27:21.78

pythonのファンシーコンソール風ゲームライブラリであるpyxelの実装がrustで書かれてて、お？ってなったわ

**デフォルトの名無しさん** · 2022/02/07(月) 15:19:33.56

その言語で書き直された〜みたいなことが話題になるうちはほぼ広がってないと考えて良いわ。

**デフォルトの名無しさん** · 2022/02/07(月) 15:43:24.90

>>153
こうなったらOKというお前の合格ラインは？

**デフォルトの名無しさん** · 2022/02/07(月) 17:52:12.40

>>150
「よくある」とやらの根拠に興味あるだけだから心配すんな
絶対批判したり非難したりしないからリラックスして述べてみ

**デフォルトの名無しさん** · 2022/02/07(月) 18:19:47.49

>>155
最近じゃITニュースサイトでも
Rustで書き直しましたという記事がちょくちょく出てることに
興味もないレベルだと次世代言語スレは難しくない？

**デフォルトの名無しさん** · 2022/02/07(月) 22:00:41.23

>>153
スクリプト言語のボトルネック部分をCで書き直さしたなんてよく話題になるからCもマイナー言語ということで良いか？

**デフォルトの名無しさん** · 2022/02/07(月) 22:12:11.68

Rustは現代的なマルチパラダイムが洗練されて採り入れられているためプログラミングがしやすい
それなのにCやC++のように最高速で動いてくれて快適かつリソースや経費の節減となってくれる
さらにオマケとしてメモリ安全やデータ競合安全などの保証まで付いてくる

**デフォルトの名無しさん** · 2022/02/07(月) 22:14:03.66

まあまあ他人に期待するのではなく自分で何か書けばいいだけでしょ
今なら車輪の再発明と叩かれることもないだろう

**デフォルトの名無しさん** · 2022/02/07(月) 22:42:44.19

「よくある」はずなのダンマリｗ

**デフォルトの名無しさん** · 2022/02/08(火) 01:03:57.80

いうほどランタイム速度を必要とするようなアプリ、どいつもこいつも書いてないってのが現実。
はったりかましたバカはよくいるけど。

**デフォルトの名無しさん** · 2022/02/08(火) 01:36:44.45

だいたいのアプリはAPI呼び出しの塊だからアプリ自体が実行時間のボトルネックになることはレアかもね

**デフォルトの名無しさん** · 2022/02/08(火) 10:12:32.37

Nimを使って作られたゲームを紹介しよう。
https://goodboygalaxy.com/
ゲームボーイアドバンス向けに作られた2Dアクションゲーム。
https://store.steampowered.com/app/1444480/Turing_Complete/
論理回路を組み立てて自作CPUを作るゲーム。Godotっていうゲームエンジンが使われている。

**デフォルトの名無しさん** · 2022/02/09(水) 13:13:49.61

>>157
そんなこといちいちドやって報告しないって意味だよ。どこぞの言語と違ってな。

**デフォルトの名無しさん** · 2022/02/09(水) 13:57:31.22

>>164
へー、リリースノートとかにも載せずにしれっと更新するのが世の中では当たり前なのね

**デフォルトの名無しさん** · 2022/02/09(水) 13:58:40.10

>>164 CからRustに書き直されることはあっても逆は無いから当然だろ

**デフォルトの名無しさん** · 2022/02/09(水) 21:57:32.65

まっ、Cはこれだけ広範囲に使われているからね。基礎教養みたいなもの。
知っていて、使えて当たり前。

Rustでなにか画期的に高速化されるわけでもないし、コーディングの量が圧倒的に減るわけでもない。Pythonのように特定分野で格段の強みがあるわけでもなし。
メモリ安全性といっても、それが課題になってくるほど大きなプロジェクトに関わってるわけでもないしなぁ・・・

組み込み的にはオブジェクト志向な方がハードウェアと馴染みがいいって感じもあるかな。

**デフォルトの名無しさん** · 2022/02/09(水) 23:51:15.16

>>167
＞メモリ安全性といっても、それが課題になってくるほど大きなプロジェクトに関わってるわけでもないしなぁ・・・

俺のやってるプロジェクトは小さい自慢かよ

**デフォルトの名無しさん** · 2022/02/10(木) 02:47:32.09

>>167
オブジェクト指向の方がハードウェアとなじみが良いというのはどういうこと？
カプセル化とか継承とか、もしかしたらメッセージパッシングとかがハードウェアの抽象化に適しているということ？

**デフォルトの名無しさん** · 2022/02/10(木) 08:14:50.21

>>169
相手にしちゃだめ

**デフォルトの名無しさん** · 2022/02/10(木) 12:40:20.38

デバイスドライバーみたいなソフトウェアだと、linuxのVFSみたいなインターフェイスを意識するのが普通だから
オブジェクト指向や関数ポインタ渡しが普通。
動的に操作方法を変える必要性が大きいものはこういう仕組みは必要になる。

**デフォルトの名無しさん** · 2022/02/10(木) 12:43:32.46

そういやRustって、コールスタック重視なのになんで所有権移動をデフォルトにしたのかね？

スタックにデータがあるなら、戻ってくるのを想定して借用をデフォルトにした方が効率良い気がするけど。

**デフォルトの名無しさん** · 2022/02/10(木) 13:01:13.03

値渡し警察「参照渡しは存在しない。あるのは借用<T>の値渡しだけだ」

**デフォルトの名無しさん** · 2022/02/10(木) 19:06:35.96

>>172
そこはRustでは最適化される
例えば大きな構造体 struct Foo { 略 } があったとして
fn main() {
let foo = sub1();
}
fn sub1() -> Foo {
let foo1 = sub2();
return foo1;
}
fn sub2() -> Foo {
let foo2 = Foo { 略 }; // 上述の大きな構造体
return foo2;
}
と多段の関数の深いところから大きな構造体を返すとする
(注: 他言語の人にもわかりやすく敢えて「return」を明記してます)

Rustではこれは最適化されて
深いsub2()の変数foo2の格納場所はmain()のスタックの位置となる
特に今回の場合だと次々に渡していくだけなので
変数foo2のアドレスとfoo1のアドレスとfooのアドレスは一致する
(もちろんこのコードでヒープは一切利用されない)

つまり返り値(の格納場所)をポインタ渡ししているのと同じことになる
C言語ではそれを自分でコードとして記述しなければならないが
Rustでは概念上や記述コード上は「値返し」でシンプルにわかりやすく
実行コードでは最適化されて「返り値の格納場所を参照渡し」になる
もちろん小さな型を返す場合は実行コードも効率よく「値返し」のままである

**デフォルトの名無しさん** · 2022/02/10(木) 19:53:19.62

>174
いや、RVOの話じゃなくて、
スタックにあるオブジェクトの所有権を関数呼び出し先に移動するのを
デフォルトにした設計的な意図は何なんだろう
という話。

継続を第一級オブジェクトとしてサポートするのでもなければ
サブルーチンはいずれリターンしてくるんだから、スタックに積んだ
オブジェクトも呼び出し先に所有権を移動しないで持ち続けるのが
自然な感じがするんだよね。
それをわざわざ移動してスタックの奥で破棄する（＝スタックに残骸が残る）
ようにしたのはなんでかね、と。

**デフォルトの名無しさん** · 2022/02/10(木) 20:19:32.65

>>175
ヒープにあるオブジェクトだと deep copy にコストかかるから shallow copy (move) をデフォルトにして
コストかかる処理はソースコード上明確になるようにしたかったからだと思う

**デフォルトの名無しさん** · 2022/02/10(木) 20:31:58.46

>176
Rustもなんだかんだ言ってヒープ使用を想定している、ということかね。
それなら所有権移動をデフォルトにした理由は判る。

**デフォルトの名無しさん** · 2022/02/10(木) 20:36:51.31

https://www.reddit.com/r/rust/comments/fa9pkp/what_is_the_motivation_behind_default_move/
このスレで作者が答えているけど、すでに参照を示す&が広く使われてるのにデフォルトを借用にすると、moveを示すために「非参照演算子」みたいなものが必要になって整合性が取れないから、とのこと
あとはスタックにどう置いてどうアクセスするかはコンパイラの最適化の問題であって
言語のセマンティクスとは別、みたいな話も

**デフォルトの名無しさん** · 2022/02/10(木) 20:48:03.49

>>175
Rustではそんな無駄なことはしていないので大丈夫
まずメソッド定義は以下の3つの方法がある
(1) fn method1(self: Self, 引数)
(2) fn method1(self: &Self, 引数)
(3) fn method1(self: &mut Self, 引数)
Selfは自分の型を示す特別な型であり省略して以下のように略記も可能
(1) fn method1(self, 引数)
(2) fn method1(&self, 引数)
(3) fn method1(&mut self, 引数)
ここで>>175が最初に言っている方法は(1)のケース
参照しか利用しないメソッドなれば(2)のように定義して所有権は移動しない
参照を利用して書き換えるならば(3)のように定義して所有権は移動しない
そして所有権を移動させたいメソッドのみ(1)の定義を用いる
この3つの区別があるためRustでは無駄なことは起きない

**デフォルトの名無しさん** · 2022/02/10(木) 21:34:34.23

>>174
Rustは所有権がはっきりしてるためコンパイラが安全に最適化をガンガン出来る点が良いな
しかもプログラマーはそれを意識せずにRustのセマンティクスだけ把握して書けば後はコンパイラが勝手に最適化してくれる
これがC/C++だと自分で戻り値の場所を確保して自分でポインタを渡していき競合安全性も含めて自分でメモリ管理しなければならない
CG言語だとスタック上はあきらめてヒープで確保して返して後始末はGC任せ
Rustが有利

**デフォルトの名無しさん** · 2022/02/10(木) 21:40:15.72

>>178
どちらかに指定が必ず必要なのだから
ライフタイムを管理する必要のある参照の方に＆指定する現方法が大正解だな
参照にはsingle writer XOR multi readersのルール義務もあるしな

**デフォルトの名無しさん** · 2022/02/10(木) 21:50:15.02

ある程度は既存のメジャー言語と作法を揃えないと、タダでさえヤバい学習曲線がさらにとんでもないことになるしねえ

**デフォルトの名無しさん** · 2022/02/10(木) 22:07:58.55

可変参照と可変じゃない参照の区別が安全性保証の要になっているため
参照の方に記号を付けるのは理に適っている
いずれにしてもC/C++で安全に書く時はそれら含めて意識せざるをえない
それがRustでは様々な点でかなり楽になっているのだからC/C++より学習が大変ということはない

**デフォルトの名無しさん** · 2022/02/11(金) 12:06:27.49

>>178
なるほどねぇ。
個人的にはconst refを標準にして非参照演算子を用意するのも有りだと思うけど
（変数そのものの状態変更を呼び出し元で明記するという意味で）
そのあたりは作者の設計思想だからなぁ。

ただ、コンパイラの最適化と言語のセマンティクスを切り離すのは単純すぎる気が。
>>180みたいな話もあるんだし。

**デフォルトの名無しさん** · 2022/02/11(金) 12:49:33.03

>>184
参照を返す関数を書いてみればわかる
参照の方が特殊な存在であり記号は何でもよいが記号を付けるべき存在だとわかる
そして適切な記号としては微妙に概念が一部重なるC言語の＆を選んだのも適切

**デフォルトの名無しさん** · 2022/02/11(金) 13:38:34.47

>>185
もともとコールスタック（>>172）の話をしているのに、ヒープデータ前提の参照戻し関数の話をされてもねぇ。
Rustが「効率的にするという約束はしているが、コールスタックとかヒープとかは関係ない」というスタンスなら別だけど。

**デフォルトの名無しさん** · 2022/02/11(金) 13:47:41.99

>>186
ほら理解できていない
まずは実際にプログラミングしてみなさい
ヒープなんか一切用いなくてスタック上しか使わなくても参照返しは必ず起きるしライフタイムの管理が必須となる

**デフォルトの名無しさん** · 2022/02/11(金) 14:39:24.16

>>187
そこまで言うんだったら具体的なコードを例示してくれない？
「参照返しは必ず起きる」と理解できるような普遍的なコードで頼むよ。

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

>>187
>ヒープなんか一切用いなくてスタック上しか使わなくても参照返しは必ず起きるしライフタイムの管理が必須となる
これは嘘だろ。実際fortranはヒープ使わないし、変数の寿命なんて問題は考えなくて済む。
そういう意味じゃめっちゃ安全。