Rustとか言うダブスタ言語

**仕様書無しさん** · 2024/10/17(木) 08:07:52.57

値型と参照型で振る舞い変えるダブスタ言語だけど使ってるやついる？

**仕様書無しさん** · 2024/10/17(木) 08:12:28.58

いる

**仕様書無しさん** · 2024/10/17(木) 08:13:54.33

>>2
どうやって心の整理つけてる？
俺はこんなクソ設計の塊みたいなダブスタ言語使いたくないって思っちゃったわ

**仕様書無しさん** · 2024/10/17(木) 08:37:23.18

何がダブスタと思ってるのかわからない
何がわからないのかわからない
キミが使いこなせないのはわかった
がんばれー

**仕様書無しさん** · 2024/10/17(木) 08:46:55.28

一定の複雑さをオーバーすると発狂する低能

**仕様書無しさん** · 2024/10/17(木) 12:46:09.51

>>4
だから値型と参照型でlet a ＝ bの振る舞いが違ってくるでしょ
値型の場合bは再度使えるけど参照型の場合bはprintfでも使えない(コンパイルエラーになる)
同じコードで
let a ＝ str bと
let a ＝ String::bで比べてみたらわかるよ

**仕様書無しさん** · 2024/10/17(木) 12:47:07.69

ちなみにわかってると思うけどstr型は値型でString::型は参照型なタコ

**仕様書無しさん** · 2024/10/17(木) 18:42:30.86

所有権の考え方ってRustやるなら変数より前に習うぐらいじゃないの？

**仕様書無しさん** · 2024/10/17(木) 18:46:57.12

すまん文法間違えてた
正しくはstrは &str
String::bは std::string bだ

**仕様書無しさん** · 2024/10/17(木) 18:47:39.35

>>8
そのうえで値型と参照型で振る舞いを変えるダブスタ言語だなぁって思いました。

**仕様書無しさん** · 2024/10/17(木) 18:49:05.98

これは値型だからこいつに代入しても使える～
こいつは参照型だからもうこの変数使わないどこ～
とかやってんだろうなw

**仕様書無しさん** · 2024/10/17(木) 18:53:47.00

用途に応じて使う型を変えることの何がダブスタなんだろう・・・

**仕様書無しさん** · 2024/10/17(木) 18:54:00.69

単純作業で修行しなはれ
値を代入したり譲渡したり何なり

**仕様書無しさん** · 2024/10/17(木) 19:06:20.93

値型なんてあったかな
プリミティブ型とは違うのか

**仕様書無しさん** · 2024/10/17(木) 19:07:33.26

>>12
普通のプログラミング言語はちがうけど
値型だろうが参照型だろうが変数が使えなくなることなんて割と無い

**仕様書無しさん** · 2024/10/17(木) 19:07:57.66

>>14
それがいわゆる値型
メモリそのものに値が入ってるから値型

**仕様書無しさん** · 2024/10/17(木) 19:08:52.19

>>15
所有権を移してるんでないか？

**仕様書無しさん** · 2024/10/17(木) 19:08:57.54

参照型はアドレスが入ってる

**仕様書無しさん** · 2024/10/17(木) 19:09:35.85

>>17
だからその所有権移したりコピーした値を渡したりダブスタだろって言う話

**仕様書無しさん** · 2024/10/17(木) 19:12:11.84

所有権の管理を俺様ではなくたかがプログラム言語ごときが勝手にやるのが気に食わないっていうのなら言ってることはわかるけど
ダブスタと言われると意味が分からない

**仕様書無しさん** · 2024/10/17(木) 19:13:49.52

>>20
ダブスタだろ
値型と参照型で振る舞い変えるんだから

**仕様書無しさん** · 2024/10/17(木) 19:14:02.74

ここで言う値型が、所有権を失ったり失わなかったりコロコロ挙動が変わるならまあダブスタだけど
参照だって定義してるんならそりゃ動きも変わるだろう

**仕様書無しさん** · 2024/10/17(木) 19:17:34.52

そこまで理解していて「わからない」とか言ってるのがわからない

**仕様書無しさん** · 2024/10/17(木) 19:26:04.18

>>23
いやなんで2つの振る舞いにしたの？ってなるくね？
値型もメモリコピーしないで参照型のように値渡したら開放するでいいじゃん

**仕様書無しさん** · 2024/10/17(木) 22:33:51.75

Rustに値型と参照型という区別はないぞ
参照という概念はあるけど、これは &i32 なども作れるもので、「整数なら値型」といったものではない
どちらかというとC++に近い

let a = b でbが所有権を失うかどうかは、その型が「コピー可能かどうか」で決まる

**仕様書無しさん** · 2024/10/17(木) 23:08:56.00

Rustでグラフィックやると面白い
まぁCでもC++でもいいけど

**仕様書無しさん** · 2024/10/17(木) 23:56:52.39

>>25
メモリコピーできるかできないかだろ？
でそのメモリコピーできるかできないかで変数の振る舞いを変えるの？

**仕様書無しさん** · 2024/10/17(木) 23:57:39.64

>>26
でもあれって結局DirectXラップするだけなのでは？
それともDirectXすら使わずに1から作るってことかい？

**仕様書無しさん** · 2024/10/18(金) 00:06:57.13

例えばめちゃくちゃ誇張した表現にはなるが

fn main() {
let a＝3.402823e+38;←便宜上float16の最大値とする(4byte)
Hoge(a);←Rustわかってないやつはここでaが移譲されたと勘違いする
let b＝3.402823e+38;←もう一度使いたいがために宣言する
Hage(b);
.
.
.
}
↑
こんな感じのことやってたらチリ積でメモリリークしてないか？(↑の例をだと8byteのメモリリーク)
aやbが解放されないから

**仕様書無しさん** · 2024/10/18(金) 00:08:11.83

コピーするかしないかって相当重要なポイントだと思うんだけど
なんだろうWeb系ばっかやってるとそういうのどうでもいいと思うのかね？

**仕様書無しさん** · 2024/10/18(金) 00:14:51.03

>>30
いや重要なのはわかるけど変数に代入したあとは解放なりなんなりすればよくないか？
それか普通の言語のように記述を変えるか
let b ＝ mcopy(a);
とかならだれも文句言わないけど

**仕様書無しさん** · 2024/10/18(金) 00:16:30.68

a.mcopy;とかでもいいよaはメモリコピーインターフェースを実装しているならこれが一般的な書き方になるか？

**仕様書無しさん** · 2024/10/18(金) 00:17:31.57

だから型を変えることで記述変えてるじゃん？
他の言語の記法が絶対正義でRust固有のものは常に間違ってるっていうなら、それはもうどうしようもない

**仕様書無しさん** · 2024/10/18(金) 00:22:13.10

Rustの良いところってintやfloat,longなんかにbit数書いてるところだよね
あれたまにど忘れしちゃうときあるからみたらわかるの便利

**仕様書無しさん** · 2024/10/18(金) 00:25:13.10

>>33
記述は変えてなくね？

**仕様書無しさん** · 2024/10/18(金) 06:24:57.13

>>29
RAIIでググれ
変数はスコープを外れたら寿命が尽きるからリークにはならないし、そもそもスタックとヒープの違いを理解してないと思う

**仕様書無しさん** · 2024/10/18(金) 07:28:21.04

所有権はメモリだけでなくリソース管理の問題でもある
ファイルハンドルなんかが良い例で、実態はせいぜい数バイトしかないからコピー自体にコストがかかるわけではないんだけど、ファイルというリソースに絡むから所有権の管理の対象になる
あるファイルへのアクセスを行う変数が同時に複数ある状態を許容しない、ということ

共有するなら Rc や Arc などの『シェアされてる』ことを示す型でのラップが必要だし、実際にアクセスする際に Mutex などでのガードが必要になる
これらをコンパイル時に制限することでバグを生みにくい設計にしようというのがRust的な考え方

**仕様書無しさん** · 2024/10/19(土) 00:29:07.32

全く見たことがない言語なんだ、なんか発狂している海外のエンジニアを見るとこの言語は大丈夫なのかとは思う

**仕様書無しさん** · 2024/10/19(土) 02:18:52.28

名前通りだよまったく

**仕様書無しさん** · 2024/10/19(土) 05:07:26.68

rustではコピートレイトが実装されてる型というのがあって、基本的にはプリミティブな型がそれに相当するの。で、それらはスタックに確保されるから解放しなくていいの。コピートレイトを実装出来る条件というのがあって、デストラクタが不要な物に限るの。解放しなくていいものだけ。わかりやすいでしょ？

**仕様書無しさん** · 2024/10/19(土) 07:17:05.73

ヒープに確保したらどんな型だろうが開放しないといけないのでは？

**仕様書無しさん** · 2024/10/19(土) 08:22:30.66

i32型ならスタックに確保される。
ヒープに確保したかったらBox<i32>で、それはもう別の型。なのでコピー出来ない。

**仕様書無しさん** · 2024/10/19(土) 08:47:12.01

わあわかりやすい

**仕様書無しさん** · 2024/10/19(土) 09:07:55.40

デストラクト不要のプリミティブ型は小文字で書かれてて、それ以外の型は大文字で書かれてるでしょ。
一応その辺でCopyが出来るか区別つくようにはなってる。

**仕様書無しさん** · 2024/10/19(土) 09:39:04.12

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などのプログラミング言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html

警備員[Lv.11][芽] · 2024/10/19(土) 11:35:17.55

>>36
だからmain関数で宣言してたらソフト終了するまでメモリ解放されないだろアホ
>>44
でもメモリコピーするクラスというか型は各々作れるよね？そのときどうすんの？
俺は素直に変数.mcopyで良いと思うが

**仕様書無しさん** · 2024/10/19(土) 12:02:44.51

struct Point {
x: i32,
y: i32.
}

例えばこのようなPoint構造体を作ったら。それは新しい型であってデフォルトではCopy出来ない。

もしこの構造体の所に
#[derive(Copy,Clone)]
という指定を付けるとCopyトレイトが実装されるのでコピー出来るようになる。ただ慣習的には構造体は暗黙的にコビーされるのは良くないので、Cloneだけ実装して明示的にCloneしてねというのが推奨。

警備員[Lv.11][芽] · 2024/10/19(土) 12:05:15.32

>>47
だったらはなから変数.mcopyでいいだろ

警備員[Lv.11][芽] · 2024/10/19(土) 12:06:10.07

それつけなかったらプリミティヴも移譲にするでいいじゃん
そっちのほうがはるかに神言語のそれだろ

**仕様書無しさん** · 2024/10/19(土) 12:10:59.43

let p1 = Point { x:100, y:200 };
let p2 = p1; // copy が実装されてる場合
let p3 = p1.clone(); // 明示的な clone

**仕様書無しさん** · 2024/10/19(土) 12:20:52.07

C言語から来た人は型をメモリのサイズで捉えてる人が多いよ。関数型言語で言うところの型というのは機能や文脈や制限や寿命やら色々な情報を含むもので全部区別すべきもの。これが凄い便利機能なわけ。
暗黙的な型変換をする言語は型の力を利用出来ないのでバグる。

**仕様書無しさん** · 2024/10/19(土) 12:33:15.92

あと勘違いしてるかもしれないけど、プログラム上の変数のスコープの範囲と、実際の寿命の範囲は別物だよ。
Rustコンパイラは変数が使われている所を全て把握しているので用が済んだ変数はスコープ抜けなくても最適化で消されてる。
定数になるものなら変数の領域すら確保されない。

**仕様書無しさん** · 2024/10/19(土) 12:46:30.82

fn main() {
// 整数型
let a: i32 = 42;
let b = a.clone();

// 浮動小数点型
let c: f64 = 3.14;
let d = c.clone();

// ブール型
let e: bool = true;
let f = e.clone();

// 文字型
let g: char = 'A';
let h = g.clone();
}

明示的に書いたほうが分かり易いという人は全部 clone って書いてもいいんですよ。

警備員[Lv.11][芽] · 2024/10/19(土) 12:46:36.00

>>52
それ君らが嫌いなガベコレとなにが違うの？

**仕様書無しさん** · 2024/10/19(土) 12:51:14.23

ガベコレは用が済んだタイミングで即解放されるんじゃなくて、GCを走らせたタイミングで解放です。
なのでメモリを倍ぐらい余分に確保しとかないと足らなくなることがある。

**仕様書無しさん** · 2024/10/19(土) 15:46:59.73

無職ってすぐ人に聞こうとするよな
だから無職なんだろうけど

**仕様書無しさん** · 2024/10/19(土) 16:17:01.01

>>54
ガベージコレクション(GC)は
・「ガベージ＝ゴミ＝使われなくなったメモリ」がどんどん溜まっていく
・そのため実行中のあるタイミングで溜まってきたゴミをまとめて収集(コレクション)する
・ゴミかどうかは実行中に使われなくなったかどうかを何らかの方法で追跡して判断する
・このGCを判断実行できるように冗長なメモリ管理をすることとゴミが溜まるためメモリ消費量が多い
・これらの処理を行なえるようGCランタイムと呼ばれるプログラムが必ず内蔵される

このGCにメモリ管理を依存する言語がGC言語と呼ばれている
C/C++/Rustは依存しないため非GC言語

**仕様書無しさん** · 2024/10/19(土) 16:48:14.21

【GC言語】常に安全にメモリ自動解放されるがGCのため遅くてメモリ利用量も多い
【Rust】常に安全にメモリ自動解放されて速くて省メモリ
【C/C++】安全ではなく解放済み領域をメモリ参照してしまうことも発生

警備員[Lv.12][芽] · 2024/10/19(土) 19:17:09.27

まぁどんだけ安全でもダブスタ言語なんて使いたく無いけどね

**仕様書無しさん** · 2024/10/19(土) 19:23:41.39

それは単に使わなければ良いだけじゃないの？

**仕様書無しさん** · 2024/10/19(土) 19:23:41.76

それは単に使わなければ良いだけじゃないの？

**仕様書無しさん** · 2024/10/19(土) 19:39:45.66

>>45
アメリカでは政府も国防総省もRust言語なんだね

**仕様書無しさん** · 2024/10/19(土) 21:27:12.32

メモリの仕組み理解してからRustやろうね
できればCかC++やってから

警備員[Lv.13][芽] · 2024/10/19(土) 21:29:03.92

>>63
いや理解してんだわ
だからこそ同じ書き方で2つの振る舞いをするRustが嫌いなの

**仕様書無しさん** · 2024/10/19(土) 21:35:54.87

JavaやC#もそういうことはある

**仕様書無しさん** · 2024/10/19(土) 21:37:56.86

「本当に理解した？」
「はいっ！」←こういう新人いるよね

**仕様書無しさん** · 2024/10/19(土) 21:44:28.27

こいつは何をダブスタって言ってるんだ？

**仕様書無しさん** · 2024/10/19(土) 21:50:24.57

>>64
誤解してるんじゃないの？
Rustにはコピー可能型とコピー不可能型の2種類しかない
それを理解すれば振る舞いは常に一意に定まることがわかる

**仕様書無しさん** · 2024/10/19(土) 22:03:38.72

無職はほっとけよ
仕事してないんだから

警備員[Lv.4][新芽] · 2024/10/19(土) 22:59:12.10

このスレには、僕のスッキリしない部分を言語化して説明してくれる人が多くて助かります

警備員[Lv.14] · 2024/10/19(土) 23:29:07.21

>>67
移譲とメモリコピーで振る舞い変える

警備員[Lv.14] · 2024/10/19(土) 23:30:10.12

>>68
だから.cloneを明記しないと移譲になるでいいじゃん

**仕様書無しさん** · 2024/10/19(土) 23:46:47.34

>>72
コピーとcloneは明確に異なると定められている
コピーはプログラマーが実装することはなくビットパターンごとサイズ分のメモリがコピーされる
cloneはプログラマーが自由に実装することができて例えばヒープ領域を持つデータならその部分も含めてコピーすることもできるしコピーせずに共有することもできてcloneは型毎に自由度がある
このようにコピーとcloneは明確に異なっている

**仕様書無しさん** · 2024/10/19(土) 23:49:27.57

コピーと同じ動作になるのはムーブ
どちらもプログラマーは実装することができない
ただしムーブはムーブ元の値が無効になるという点のみコピーと異なる

**仕様書無しさん** · 2024/10/20(日) 02:08:40.13

ムーブとコピーで同じイコールを書くのが気に入らないって事かな？

所有権の移譲とか言うから分かりにくいんだと思う。「メモリ管理責任」が無いからコピー、有れば「メモリ管理責任」ごとムーブするだけ。

で、プリミティブ型はそもそも移動する意味がないしコピーの方が速い。

優先順位の考え方が逆で、イコールはコピー出来る型ならコピー、出来ない型ならムーブする。ムーブも出来ない型ならコンパイルエラー。で、エラーが出る場合は明示的にcloneを書いたりする。でcloneも出来ない型なら更に他の方法で対策する。
そうやって型で制約をはめる事で誰が書いても同じ挙動になるようにしている。

警備員[Lv.14] · 2024/10/20(日) 03:27:08.69

>>73
じゃあなおさら変数.mcopyが必要だね

警備員[Lv.14] · 2024/10/20(日) 03:30:07.84

>>75
そうやって色々試して型探ってくよりはるかにプリミティヴ系も＝のみの場合はメモリ解放して使えなくなるくらいのほうが楽だろ
コピーは上で言ってるように.mcopyを明示的に示せばいいだけ

**仕様書無しさん** · 2024/10/20(日) 04:25:09.91

>>77
なんか物事の捉え方がインタプリタと勘違いしてない？

コンパイラなんだからコンパイル時に全部処理されるのよ？

**仕様書無しさん** · 2024/10/20(日) 04:29:33.89

プログラム的な意味論とそれが最適化されて出力された後のコードの挙動まで解説しないと駄目なのかな？

**仕様書無しさん** · 2024/10/20(日) 06:39:19.66

>>77
ムーブとコピーはプリミティブな相補的な動作なので
.move()や.copy()といったメソッド呼び出しは不可能
トレイトCopy実装型は常にコピーされ
Copy非実装型は常にムーブされる
Rustは非常にシンプルでわかりやすくなっている

警備員[Lv.15] · 2024/10/20(日) 09:19:34.07

>>80
だからそれを同じ
let b ＝ a;
let d ＝ c;
で表現させちゃダメだろ
↑見てどっちがプリミティヴかわかるか？

警備員[Lv.15] · 2024/10/20(日) 09:20:49.24

低レベル言語やってるやつって保守のこと全く考えないのかな？

**仕様書無しさん** · 2024/10/20(日) 09:30:55.71

C#でいうと
var a = new Foo();
var b = a;

で a と b が同じオブジェクトを指す状態になるけど、これを許容しないのがRust
この場合は b だけが Foo に責任を持つべきで、そのためにaは所有権を無くす (「解放する」ではなく「所有権を移す」だけ)
これはメモリ使用量というよりも管理の問題で、「a の操作がbに影響を与える」ことによる複雑性を取り除くために厳しくしてる

var a = 1;
var b = a;

C#でもそうだけど、これはスタックメモリに積まれるもので、単に値コピーされる
これは関数を抜ければ解放される (GCのような機構を必要としない) し、C#でもaの書き換えがbに作用しないはず
Rustでもこれでaを使えなくする理由はないので単にコピーされる

Rustでもオブジェクトを共有する仕組みはあるけど、その場合は共有のための型 (Rc<T> のような型) を使うことになる
これは特にマルチスレッドの場合に有用で、スレッドを跨いで共有されるオブジェクトは「ロックをかけないと内部の値にアクセスできない」型で包まないとコンパイルエラーになる仕組みがある
これは個人的にすごく便利だと思う部分で、Rustだと安心してコードを書ける感じがする

**仕様書無しさん** · 2024/10/20(日) 09:41:57.61

C#でも
var b = a;
でbがaと同じオブジェクトを参照するかコピーされるかは型に依存するでしょ

**仕様書無しさん** · 2024/10/20(日) 09:46:56.69

【結婚難】金稼ぎ共働き妨害するな【孤独死】

☆犠牲になるのは犯罪幇助SEの結婚相手☆

実態派遣で非婚や離婚や中絶や少子化や親不孝を促進

・キモい
・モラルない
・ファッションセンスない
・コミュニケーション苦手
・時間外労働違反で共働き妨害
・泥棒客先に開発報酬を奪わせる
・泥棒客先に知的財産を奪わせる
・裁判官が技術判断不正をする

SEは多重派遣の料金詐欺は非婚
https://codelearn.jp/articles/about-engineer-marriage

**仕様書無しさん** · 2024/10/20(日) 09:55:32.58

>>82
保守性は言語でなく開発者や組織のレベルの問題
あえて言語の特徴を書くなら、OOP言語だとクラスのフィールドに参照型の値がある場合に、それが他のクラスと共有されるものであるかを知る方法がないけど、Rustはそれが明確という利点がある

struct Foo { a: T } のTがStringならこれはFooの中に閉じ込められてるし、Rc<String> なら他と共有される (ただしスレッドは跨がない) し、Rc<Mutex<String>> なら複数スレッドから共有されるかつ書き換わる可能性があることを意味する

そのために面倒な部分があるのは確かで、C#やJavaは逆にそれらを簡略化してるともいえる

**仕様書無しさん** · 2024/10/20(日) 10:41:24.68

>>82
Rustの保守性がこれまでの言語と比べて格段に保守性が高く優れているのは様々な仕組みで実現されている
例えばRustのデータ参照競合の防止機構やデータ競合の防止機構は保守においてそれらによるバグ混入を確実にコンパイルエラーとして検出する

**仕様書無しさん** · 2024/10/20(日) 11:20:15.04

初学者がコードを見た時のとっつきにくさはあると思う
けどこれは simple vs easy みたいもので、Rustは難しいけど仕組みを理解すればシンプルではある

警備員[Lv.16] · 2024/10/20(日) 12:59:21.64

>>87
だからわざわざそれをコンパイルエラーで確認するのかって話になるだろ
>>84
でもaは使えなくならないよね

**仕様書無しさん** · 2024/10/20(日) 13:05:09.09

>>1
値型と参照型って何のこと？
Rustは全ての型に対して値と参照の両方があるよ
もしプログラマーがそれらを取り違えばコンパイルエラーとなるから問題は起きないよ
まずは正しい現状認識をしてから批判しようね

警備員[Lv.16] · 2024/10/20(日) 13:19:31.73

>>90
だからわざわざコンパイルエラー確認しましょうってことだろ？
どっち使ってんのかわかんないから
どっち使ってるかわかんねぇからコンパイルエラーで確認しましょうってそんなスマートか？
俺なら無理

警備員[Lv.16] · 2024/10/20(日) 13:20:41.41

普通の人間ならコンパイルエラーで確認するより書かれたプログラムの中身見て判断できるようになったほうがいいよねってなると思うよ
それがいわゆる可読性というやつや

**仕様書無しさん** · 2024/10/20(日) 13:33:04.04

>>91 >>92
型の違いなどはどの言語もコンパイル時にエラーか実行時にエラーとなる
もちろんRustのようにコンパイル時にエラーとなる言語の方が優れている

**仕様書無しさん** · 2024/10/20(日) 14:06:18.94

Rust書いた事ない人が言いそうな事だな。
vs-codeなりなんなりでコード書いてればコンパイルするまでもなく書いてるそばから rust analyzer が間違いを指摘してくれるのに。どう直せばいいかも細かく出てくるよ。

**仕様書無しさん** · 2024/10/20(日) 14:26:59.39

>>93
実行時エラーが出るまでわからないプログラミング言語はその仕様が静的にエラーを指摘できない言語仕様になってるからな
例えばC/C++のサニタイザーも実行させて問題が発生した時に初めてコードに問題があることがわかる
実行前に静的に様々な問題が判明できる最先端の言語はRustで間違いない

**仕様書無しさん** · 2024/10/20(日) 16:04:59.07

プログラム板のRustスレにいる人が出張してきてるね

警備員[Lv.16] · 2024/10/20(日) 16:28:14.26

>>94
それIDEが無いと無理でしょ

警備員[Lv.16] · 2024/10/20(日) 16:30:01.63

ふつうにコピーして渡してるのか参照で渡してるのかくらいプログラムのコード見て分かるようになったほうが遥かにいいだろ
Rust信者は盲信してるだけで普通の感性が全くない頭悪い人間ども

**仕様書無しさん** · 2024/10/20(日) 16:45:11.52

>>98
実際にプログラミングをすればわかる
ほとんどのムーブは関数呼び出しの引数や返り値に表れる
そしてほとんどの関数の引数はムーブではなく参照を受け取る
つまりムーブで渡してしまう関数は限られた特殊なものだけなのだ
レアケースなのですぐに意識できるため困る人が出現していない

**仕様書無しさん** · 2024/10/20(日) 16:48:55.21

>>97
普段コード書くのに何のエディタ使ってるんだよ。今時、emacsでもvimでもrust analyzer使えるぞ？
もし Langurge Server Protocol に対応してないエディタ使ってたらそれがこそプログラム書いてない証拠。

**仕様書無しさん** · 2024/10/20(日) 16:57:37.13

rustfmtとclippyとrustcだけがあれば十分
LSPは補助輪として優秀だが必須ではない
むしろLSPに依存しないとコーディングできなき人は下に見られる