結局C++とRustってどっちが良いの？

**デフォルトの名無しさん** · 2023/02/25(土) 09:49:46.74

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？

**デフォルトの名無しさん** · 2023/03/02(木) 23:06:33.64

>>102
それでRustプログラマが増えることはないな
>>83くらいの状況にならんと

**デフォルトの名無しさん** · 2023/03/03(金) 06:56:09.99

>>99
その「特殊な組み込み環境」とやらでもC/C++は使えるからね。

C++はフルには要らんかもだけど、
クラスと継承は組み込みとかでも便利に使われてたりするね。

できることが大差ないとすると、仕事でRustを使えと言われない限り、個人レベルで積極的に使う理由に乏しいかなぁ。
個人でメンテできる程度だとメモリ安全ってそれほど重要ポイントではないし。

PythonにとってのAIみたいに、こういうアプリケーションなら、C/C++より遥かに楽で簡単に実現できるというものが必要なのではないかな。

今の段階じゃ、メモリ安全にするために制約やチェックを厳しくしたC/C++ってだけって感じだもの。

**デフォルトの名無しさん** · 2023/03/03(金) 07:13:09.62

Rustは後発なアドバンテージで
洗練されたモダンな言語仕様のため非常に書きやすい
これが一番大きなメリット
おまけとしてメモリ安全性の自動保証とデータ競合なしの保証
これらにおかげでC/C++で書いてた時に無駄に必要だった実行時デバッグが激減して消えた
Rustは開発効率が大きく向上する

**デフォルトの名無しさん** · 2023/03/03(金) 09:31:41.76

>>95
Dが出た時に聴いたことあるような文句だな
割とマジでフラッシュバック

**デフォルトの名無しさん** · 2023/03/03(金) 13:09:51.97

>>106
どこが似てんだよ何も区別付かないアフォ

**デフォルトの名無しさん** · 2023/03/03(金) 13:21:04.67

おちんちんランドへおいでよ！

**デフォルトの名無しさん** · 2023/03/03(金) 13:21:58.74

altJSブームが落ち着いたせいで下火になっちゃったけど
やっぱりHaxeは復活すべきだよな

**デフォルトの名無しさん** · 2023/03/03(金) 13:26:08.63

>>107
凄い似てるよ
Javaが出たときにも聞いたぞ
「C/C++を置換する！」は人間の性なんだろうw
長くやってると何度も見るし結果もだいたい分かる

**デフォルトの名無しさん** · 2023/03/03(金) 16:49:35.55

>>110
しかも、Javaの普及速度は物凄く速かったが、Rustは伸びてない。

**デフォルトの名無しさん** · 2023/03/03(金) 19:36:46.54

>>91 >>110
プログラミング言語の一般的な基礎知識を持たない人がRustのアンチをやっているのかしら
JavaがCやC++に置き換わらなかった理由の一つはJavaがガベージコレクション必須の言語だからですよ
CやC++の置き換えとなるためにはGCを必要としないプログラミング言語でないとダメなんですよ

GCを必要としない言語も数少ないながら今までいくつか出て来たのになぜCやC++を置き換えられなかったか分かりますか？
CやC++で問題となってきたのはメモリ操作の安全性とデータ競合の安全性です
それらを完璧に対応して言語自体が安全性を保証する言語が今までなかったからですよ
Rustが初めて対応して初めて真にCやC++を置き換えられるようになりました
だからIT大手各社がライバル関係を超えて共同してRustを支援そして採用しているのですよ

**デフォルトの名無しさん** · 2023/03/03(金) 20:45:25.65

>>112
>>77

お前はそればっかりだなw
そんなものはこの板の住人が知らん訳ないやろw
GCくらいしか語る知識がないんだろうな

**デフォルトの名無しさん** · 2023/03/03(金) 21:06:34.40

>>113
その>>77を見てみましたがリアルタイム性の話ですか
それは直接はプログラミング言語とは関係ない話ですが少し関係がありますね
言語に関わらず作成したシステム側の話でOSからゲームのようなアプリまで必要とされる時間的制約があることをリアルタイム性と言います
もちろんガベージコレクションはリアルタイム性の障害となりますのでそれを軽減する手法を取ったりリアルタイム性を必要としないタイミングでGCを実行します
しかしそれでも現実的なOSや基幹システムでGC言語の利用は厳しいでしょう
そのためOSなどの記述にはCやC++やRustが使われます
メモリ安全性などの保証をプログラマーではなく言語システムに任せることができるRustがベストとなります

**デフォルトの名無しさん** · 2023/03/03(金) 21:20:32.28

エアプするにしてもせめてthe embedded bookくらいざっくり読んでからにすればいいのに

**デフォルトの名無しさん** · 2023/03/03(金) 21:26:29.88

>>114
リアルタイム性の話ではなく
GCの話しかしないことを言っている
GCくらいしか語る知識がないと俺は推測している

**デフォルトの名無しさん** · 2023/03/03(金) 21:48:53.60

C++とRustの比較スレだからGCない言語が前提だもんな
Javaとか持ち出す>>110や>>111はアホすぎ

**デフォルトの名無しさん** · 2023/03/03(金) 21:51:10.69

>>118
>>76

**デフォルトの名無しさん** · 2023/03/03(金) 21:51:28.18

>>117
>>76

**デフォルトの名無しさん** · 2023/03/03(金) 22:54:44.50

ここが新しい隔離スレちゃんですか

**デフォルトの名無しさん** · 2023/03/03(金) 23:40:18.48

ここは純粋にC++とRustの比較スレ
しかし無関係なGC言語を持ち出してくるバカがいてそれを邪魔をしているようだ

**デフォルトの名無しさん** · 2023/03/03(金) 23:41:20.65

実務経験の乏しい人が言語機能だけで頭でっかちなアピールしてるのを見ると狙ってアンチ活動してるのかと勘繰りたくなるよね

まぁ隔離ファイト続けてくれ

**デフォルトの名無しさん** · 2023/03/03(金) 23:57:24.37

それらの言語を実際に書いて使っていればガッべージコレクションのある言語がC言語系を置き換えできないことくらい分かるはずだもんなー

**デフォルトの名無しさん** · 2023/03/04(土) 02:04:08.56

WinAPI/ATL/MFCの系譜をWinFormsが現れて.NETが置き換えていった歴史は無かったことにされたらしい

**デフォルトの名無しさん** · 2023/03/04(土) 05:09:33.55

CやC++に置き換わる言語の話でWinAPIやWinFormsを持ち出してくるとは頭おかしいな

**デフォルトの名無しさん** · 2023/03/04(土) 10:37:16.20

C#もGCないネイティブでビルドするオプションがあったら天下取れたかもな
VB6はGC無かったのになぜこうなった

**デフォルトの名無しさん** · 2023/03/04(土) 10:41:49.65

>>125
君はてをにはがおかしい
寝ぼけた頭で脊髄反射で書き込むのはやめたほうがいいな

**デフォルトの名無しさん** · 2023/03/04(土) 10:54:13.03

>>114
chatGPTの回答に似てるなωωω

**デフォルトの名無しさん** · 2023/03/04(土) 10:59:11.20

>>127
何処が可笑しいか指摘してくれ
おれには判らん

**デフォルトの名無しさん** · 2023/03/04(土) 11:05:58.63

>>129
「CやC++に置き換わる言語の話」なんて誰もしていない
「CやC++に取って代わる」あるいは「CやC++を置き換える」と言いたいのだろう

あるいは本気で「CやC++に置き換わる言語の話」をしているのなら今度こそ本当に頭がおかしいな

**デフォルトの名無しさん** · 2023/03/04(土) 11:14:10.28

それがてにをはどどう関係あるの？

**デフォルトの名無しさん** · 2023/03/04(土) 11:23:10.42

>>126
VB6はトレースGCではないけど参照カウンタGC方式のGC言語
VB6オブジェクトは裏で参照カウンタが自動的に使われていてそれにより使われなくなったメモリを回収している
ちなみにC++のshared_ptrなども参照カウンタ方式だが裏で勝手に使われることはなく必須でもなくプログラマー裁量なのでC++はGC言語ではない

**デフォルトの名無しさん** · 2023/03/04(土) 11:59:27.29

Rustに期待している人のフラストレーションを解消したいなら
フルスクラッチでOSを書くくらいしか方法はないだろうね
OSの普及は更に至難の技だけども

**デフォルトの名無しさん** · 2023/03/04(土) 12:08:40.51

(実務経験ゼロ + 論理的思考力の欠落 + 自己愛性パーソナリティ障害) * Rustへの執着 = 通称複製おじさん

**デフォルトの名無しさん** · 2023/03/04(土) 12:51:29.76

　　　　　　　　　　　|
　　　　　　　　　　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)またGCの話してる
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　　(γ　/:::::::
　　　　　　　　　　　　　　し＼:::
　　　　　　　　　　　　　　　　　＼

**デフォルトの名無しさん** · 2023/03/05(日) 00:54:23.16

うるせー馬鹿

**デフォルトの名無しさん** · 2023/03/05(日) 00:59:18.56

>>133
フルスクラッチの新たなOSを普及させるのは難しいだろうが
>>74に記事があるようにGoogleがRustのみで新OSを作ってるな
あとAndroidもLinuxもWindowsもRustの一部採用を始めて
この流れはOSに限らず全てのシステムでRust化が進んでいくのだろう

GoogleとMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

**デフォルトの名無しさん** · 2023/03/05(日) 09:30:23.81

>>137
次第に現行プロジェクトを置換して増えていくなんて展開はありえないっての
AndroidやWindowsをRust製のOSで置換するくらいしかストーリとしてはない
Linuxに入っているRustコードは>>39で書いた通り

**デフォルトの名無しさん** · 2023/03/05(日) 10:00:51.19

私はRustで年収1億稼ぎましたみたいな話はないのかよ
マイナープロジェクトでちょっと使われたら勝利なのかよ

**デフォルトの名無しさん** · 2023/03/05(日) 11:14:29.69

Winnyの作者みたいに逮捕されるかと思ったら怖くて無理

**デフォルトの名無しさん** · 2023/03/05(日) 11:34:54.12

話し飛躍しすぎでしょ

**デフォルトの名無しさん** · 2023/03/05(日) 11:49:22.14

Rustで検証してうまくいったらそのままCにコンバートすれば余計なチェックコードが削れてる速く動く

とかね。

**デフォルトの名無しさん** · 2023/03/05(日) 14:28:35.02

てかGCって別に悪いもんじゃねぇしな

**デフォルトの名無しさん** · 2023/03/05(日) 14:30:11.56

>>133
それよりもグラフィックソフト作ったほうが広まると思うけどね
Blender参考に3Dモデリングソフトつくってよ

**デフォルトの名無しさん** · 2023/03/05(日) 14:54:49.80

>>144
それでは心が満たされないんだよ
GCの話しかしない人とか

**デフォルトの名無しさん** · 2023/03/05(日) 15:15:15.70

>>143
GCの有無はその言語がカバーできる範囲の差となり優劣関係が明白
GCのない言語は全てをカバーできる

**デフォルトの名無しさん** · 2023/03/05(日) 15:45:42.10

>>146
UEとかのゲームエンジンは当たり前だがついてる
うまく付き合ってくほうが大事

**デフォルトの名無しさん** · 2023/03/05(日) 15:50:56.78

本当にGCの話しかしないんだね
GC以外のことを語る知識がない
GCはこの板見てる人はほぼ誰でも知っているだろう

**デフォルトの名無しさん** · 2023/03/05(日) 15:58:09.36

色んな言語のライブラリがC++(や最近はRust)で書かれているのを考えると
C++とRustが王者決定戦になるのは当たり前じゃね？

**デフォルトの名無しさん** · 2023/03/05(日) 16:07:43.53

入力にゴミデータを与えるとゴミしか出力されないことの好例

**デフォルトの名無しさん** · 2023/03/05(日) 18:26:02.22

いつのまにかPythonやJavaScriptのライブラリがRustで作れるようになってるのな

**デフォルトの名無しさん** · 2023/03/06(月) 00:49:06.50

そりゃラップするだけなんだから作れるだろ
アホか

**デフォルトの名無しさん** · 2023/03/06(月) 09:19:45.87

そして我が道をいくLISP

**デフォルトの名無しさん** · 2023/03/06(月) 09:45:52.37

LISPといえばGCの元祖だな

**デフォルトの名無しさん** · 2023/03/06(月) 13:40:13.02

　　　　　　　　　　　|
　　　　　　　　　　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)またGCの話してる
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　　(γ　/:::::::
　　　　　　　　　　　　　　し＼:::
　　　　　　　　　　　　　　　　　＼

**デフォルトの名無しさん** · 2023/03/06(月) 15:05:53.11

memo
https://zenn.dev/dumblepy/articles/3db2134ff88763

**デフォルトの名無しさん** · 2023/03/06(月) 17:14:45.53

ふと思ったんだけど、Rustのmutableな構造体の中にimmutableなフィールドって持てるんだっけ？

**デフォルトの名無しさん** · 2023/03/06(月) 20:00:50.97

>>157
そういえば、C++のcv属性は、論理和方式で、constは足し算の様に0から1に
変わるが、mut 属性はそうはならないだろうから、どうなるんだろうな。
constは意味的に考えてもcastしない限りは、、constなものはいくらやっても
書き込めるようにはならない、というのは安全性から当然なんだけど、
mutだとそうはいかない。

**デフォルトの名無しさん** · 2023/03/06(月) 20:09:02.49

>>158
mutとconstは逆さまの働きみたいだから、どっちで行くかは言語設計者の自由と
思われがちだけど、constな構造体のメンバは勝手に全てconst扱いになるという
単純な論理に出来るけど、mut方式の場合は、constキーワードも別に必要になりそう。

**デフォルトの名無しさん** · 2023/03/06(月) 21:18:31.55

>>157
他の言語と同じでsetter相当をなくしてgetterだけにすればいい
専用のラッパーを作る方法もあるができて当然の機能なので誰もやらないだろうね

**デフォルトの名無しさん** · 2023/03/06(月) 21:44:09.47

>>159
C++でconstを誤用しているのとは異なり
Rustではconstを正しく定数の意味で使っているので注意
つまりconstは定数でありコンパイル時に静的に定まる
もちろんconstとは別の概念としてmutableとimmutableがあり、これらは可変性の有無を表す
さらにそれらと別の概念として所有権があり、所有権を持っていればimmutableであろうと関係なくmutableな変数へ移すことで可変性を得られる
一方で所有権を持たないimmutableな参照からは可変性を得られない

**デフォルトの名無しさん** · 2023/03/06(月) 21:51:25.41

>>161
>C++でconstを誤用しているのとは異なり
誤用なの?

**デフォルトの名無しさん** · 2023/03/06(月) 22:01:32.22

>>162
そうだよ
実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
変数がimmutableであることを間違えてconstと付けてしまった
そのためC++では定数(＝静的に値が定まること)の場合は苦肉の策でconstexprと変な名前を付けることになった

**デフォルトの名無しさん** · 2023/03/06(月) 22:21:12.53

>>163
C++では単に値が`constant'って意味で使っただけではないのかな?
それを誤用とは言わんと思う

ところで何でconstexprではないconst変数は
静的に定まらないことになってるの?

**デフォルトの名無しさん** · 2023/03/06(月) 22:37:19.16

>>164
もちろんC++は整数などに限ればconstで静的な定数となるが
それ以外C++のconstは定数ではなく静的にコンパイル時に定まらない
そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった

**デフォルトの名無しさん** · 2023/03/06(月) 22:52:19.69

以下の2つは矛盾してないかい?

>>163
>実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
>変数がimmutableであることを間違えてconstと付けてしまった

>>164
>もちろんC++は整数などに限ればconstで静的な定数となるが

2つ目はなるんだっけ?

**デフォルトの名無しさん** · 2023/03/06(月) 22:53:11.95

>>165
>そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった
「本末転倒」とは違うと思うよ

**デフォルトの名無しさん** · 2023/03/06(月) 23:09:16.19

>>166
C++で何らかのクラスのインスタンスを作ってconstに入れることを考えてみるとわかりやすいよ
もちろんこのconstのインスタンスはコンストラクタの引き数の値によって変わるから静的な定数じゃないよね
つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
だから本当の定数に対してconstexprと名付けることになった有名な話だよ

**デフォルトの名無しさん** · 2023/03/06(月) 23:20:34.22

>>168
>つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
C++のconstは単なる`constant'の意味で
静的な定数という意味でないというだけなのでは?
本当に「間違えて」名付けたのかな?
俺にはC++のconstにあなたが「間違えて」静的な定数という意味を
期待しているだけに見えるのだが?

**デフォルトの名無しさん** · 2023/03/06(月) 23:31:32.57

>>169
環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
その変わりうるものに対して、C++がconstと付けたのは失敗としか言いようがないのではないか
そしてC++は本当にconstantなものに対して、後からconstexprと付けざるをえなかったことが、C++の失敗を誰の目にも明らかにしている

**デフォルトの名無しさん** · 2023/03/06(月) 23:33:40.69

>>170
>環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
これはどいう状況か分かりにくい? ソースで書いてみて

**デフォルトの名無しさん** · 2023/03/06(月) 23:42:46.60

>>171
関数に渡ってきた毎回変わりうる引き数を使ってそれを渡してインスタンス作成してconstに突っ込む場合でもよい
あるいは環境変数やargv使ってインスタンス作成でもよい
いずれも毎回インスタンスの値が変わりうるため定数ではないがC++ではconstと付けてしまった
そして本当の定数にconstexprと付けた

**デフォルトの名無しさん** · 2023/03/06(月) 23:47:46.47

>>172
曖昧さを避けたいのでソースで書いて
反論する

**デフォルトの名無しさん** · 2023/03/06(月) 23:52:15.11

ただし*const Tのconstだけはコンパイル時定数の意ではなく、C++と同じで書き換えを行えないという意味です
一貫性がありませんね

**デフォルトの名無しさん** · 2023/03/06(月) 23:56:33.22

>>169
数字でも物理でも定数は静的に定まるものだよ
でもC++はconstをimmutableの意味で間違えて名付けてしまいました
そして定数を表すためにconstを使えなくなりconstexprと名付けたという誰でも知ってる有名な話だよ

**デフォルトの名無しさん** · 2023/03/07(火) 00:01:46.05

>>175
>でもC++はconstをimmutableの意味で間違えて名付けてしまいました
とあなたが思っているだけではないかな?
C++のconstにあなたなが「間違えて」静的に定まるものを期待しているだけでは?

**デフォルトの名無しさん** · 2023/03/07(火) 00:09:47.95

言われてみれば数字や物理で定数は静的に定まる値だな
どうせC++で静的に定まる値を示すキーワードも必要となるんだから素直にそれをconstにしておくべきだったか
設計ミスだな

**デフォルトの名無しさん** · 2023/03/07(火) 00:57:00.01

>>175 >>177の頭が設計ミス

**デフォルトの名無しさん** · 2023/03/07(火) 01:08:45.38

>>177
>言われてみれば
www

**デフォルトの名無しさん** · 2023/03/07(火) 01:27:52.75

immutableとconstantの違いを区別できていない人がimmutableに対してconstと命名してしまったのかな
そのためconstantに対してconstと命名できなくなってconstexprと命名したと

**デフォルトの名無しさん** · 2023/03/07(火) 01:31:47.04

同じ言葉や字句でも言語ごとにその概念が指すものは異なる
相対主義的に考えなさい
相手の価値観を理解しなければ説得力は生まれません

**デフォルトの名無しさん** · 2023/03/07(火) 02:21:18.68

・y = ax　(a=10である)
aをimmutableと呼ぶかconstantと呼ぶか
・y=f(a)　(a=10である)
f(a)をconstantと呼ぶかconstant expressionと呼ぶか

まあ考え方次第だよな

**デフォルトの名無しさん** · 2023/03/07(火) 02:29:20.82

>>182
上はxが実行時に値がわかる変数なんでしょ？
それならconstantには成りえないんじゃない？

**デフォルトの名無しさん** · 2023/03/07(火) 08:05:58.19

>>183
かかるaについてなんと呼ぶかって話だから別にxについて気にする必要は無いよ

**デフォルトの名無しさん** · 2023/03/07(火) 08:10:06.41

>>182
理解できていなさ過ぎだろｗ

**デフォルトの名無しさん** · 2023/03/07(火) 08:16:15.53

>>182
あと例を出すにしても
整数は特殊でconstexprでなくconstでも静的定数になる例外だから例として最も不適切

**デフォルトの名無しさん** · 2023/03/07(火) 09:21:06.13

自演してRustゴリ推し他言語叩きをしてるのは
複製おじさんと呼ばれてるRustスレでは有名な荒らし
しかもそいつが「RustJP公式」の中の人で間違いなさそうって話だから手に負えない

**デフォルトの名無しさん** · 2023/03/07(火) 10:27:35.30

>>187
「RustJP自称公式」なのでなんの問題もない

**デフォルトの名無しさん** · 2023/03/07(火) 11:40:31.33

>>180
それはお前用語なんじゃね?

**デフォルトの名無しさん** · 2023/03/07(火) 11:55:27.75

y = ax
y も a も x も変数としか言いようがない

**デフォルトの名無しさん** · 2023/03/07(火) 12:47:12.28

aを10としたときにコンパイル時
最適化してしまうかaという入れ物残しとくか更にはf(a)も計算して結果だけ使うか

**デフォルトの名無しさん** · 2023/03/07(火) 21:59:54.08

整数はconstやconstexprの有無に関係なくコンパイル時に最適化されるから整数を持ち出して来ても意味がない
C++ならクラスのインスタンスを生成する場合などを考えるとわかりやすい
コンパイル時点でそのインスタンスを定数化できる時にconstexprを使い静的に定数となる
そうでなく実行時にならないと値が定まらない変数となる時はconstexprを使えない
その変数がimmutableつまり生成以降は値を変更できない時はconstを使う

**182** · 2023/03/07(火) 22:28:59.56

constというものの表現を語るうえで言語依存しない形で書いただけなので
少数でも文字列でも適当に読み替えてね

**デフォルトの名無しさん** · 2023/03/08(水) 00:26:55.95

>>192
C++の命名ミスだな
定数にconstと命名すべきであり
immutableな変数にconstと命名すべきでなかった

**デフォルトの名無しさん** · 2023/03/08(水) 00:36:06.87

壊れたテープレコーダは生まれてくるべきでなかった

**デフォルトの名無しさん** · 2023/03/08(水) 00:46:11.75

事後諸葛亮

**デフォルトの名無しさん** · 2023/03/08(水) 01:01:29.10

同じ事しか書けない命名君はGC連呼厨なのか

**デフォルトの名無しさん** · 2023/03/08(水) 01:22:37.49

結果的に後からみればC++の命名ミスなんだろうが歴史的経緯で仕方ないだろ
昔はimmutableとconstantの概念の区別が曖昧だった

**デフォルトの名無しさん** · 2023/03/08(水) 01:53:12.26

どうしても`immutable'を使いたければマクロ定義すれば?
#define immutable const

**デフォルトの名無しさん** · 2023/03/08(水) 02:01:56.79

Rustはconstをimmutableとcompile-time constantの両方の意味で使うので一貫性が無い
>>174

**デフォルトの名無しさん** · 2023/03/08(水) 07:29:50.16

>>200
Rustでconstは常に静的な定数を表す
*constはconstとは全く別のものであり予約語を最小限にするための使い回し組み合わせ

両者は種別も異なるため混乱することもない
constは定数の定義なのでこの位置に来る
let foo: i32 = 12345;
const FOO: i32 = 12345;

*constは生ポインタの型を示すのでこの位置に来る
const BAR: &i32 = &FOO;
const BAZ: *const i32 = &FOO;
このように両者は全く別物で出現位置も異なり共存もでき混乱することもない

この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
そのために新たな予約語を消費するのは馬鹿げているため既存の組み合わせという合理的な選択をした

**デフォルトの名無しさん** · 2023/03/08(水) 07:30:57.28

constはCからの流れだしな。
元々Cがシステムプログラミング向けだったことを思えば、「リードオンリーセクションに置け」っていうくらいのつもりだったんだろ。
定数は#defineで指定しろって感じかな。