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

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/09/03(土) 11:03:40.39

結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな

GoogleやMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
【脆弱性の70％がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

**デフォルトの名無しさん** · 2022/09/03(土) 11:21:29.31

マジキチだった

**デフォルトの名無しさん** · 2022/09/03(土) 11:53:26.95

>>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか？しないだろ？
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな？

**デフォルトの名無しさん** · 2022/09/03(土) 11:55:04.03

この話題、ここ数年で最もレベル低いんじゃないか？大丈夫か？

**デフォルトの名無しさん** · 2022/09/03(土) 12:31:15.03

Rustは安心安全でC言語と同等の速度ってことでFAだな

**デフォルトの名無しさん** · 2022/09/03(土) 12:34:45.63

体言止めおじさん

**デフォルトの名無しさん** · 2022/09/03(土) 12:53:59.17

最近のレベル低下には目を見張るものがあるな

**デフォルトの名無しさん** · 2022/09/03(土) 12:58:26.77

>>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね

array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい

**デフォルトの名無しさん** · 2022/09/03(土) 13:35:09.09

いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw

**デフォルトの名無しさん** · 2022/09/03(土) 13:37:41.33

Cこそ最強！
1個でもCより遅いケースあったらダメね！

**デフォルトの名無しさん** · 2022/09/03(土) 13:38:08.80

次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。

もうちょっと別の話したいわ。

**デフォルトの名無しさん** · 2022/09/03(土) 13:38:32.50

1個でもCより遅い場合あったら、他にメリットあっても意味ないから！

**デフォルトの名無しさん** · 2022/09/03(土) 13:50:50.43

誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね？

あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの？

**デフォルトの名無しさん** · 2022/09/03(土) 14:31:36.61

このスレは何もかもをRustと比較したがる信者とそれに反応してしまうバカに乗っ取られた隔離スレです
次世代言語スレではありません
次世代言語の話がしたいかたはこちらへ↓

次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

**デフォルトの名無しさん** · 2022/09/03(土) 14:36:16.07

ていうかこいつほんとにRust使ってプログラミングできるの？って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない

**デフォルトの名無しさん** · 2022/09/03(土) 14:49:28.41

>>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう

**デフォルトの名無しさん** · 2022/09/03(土) 17:15:49.49

>>167
最終レスが8月18日とか終わってんじゃねえか

**デフォルトの名無しさん** · 2022/09/03(土) 17:17:49.88

TypeScriptは次世代なのか？
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが

**デフォルトの名無しさん** · 2022/09/03(土) 17:37:42.10

>>169
そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

**デフォルトの名無しさん** · 2022/09/03(土) 18:07:45.82

Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる

**デフォルトの名無しさん** · 2022/09/03(土) 18:32:15.93

>>137
>>109は RustがC言語より圧倒的に遅いコードです

>>166 172
＞Rustが速いのは非常にキツイxor条件を満たす範囲だけ
＞「Rustは安全で高速」とか言うのは詐欺
＞そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

完全同意
Rustの最適化度合いは一貫性がなくて信頼できない
「Rustで高速化」が少しでも視野に入っている人は
Cコードも書いて常にasmとBenchmarkで比較確認するしかない

＞173
109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの？

**デフォルトの名無しさん** · 2022/09/03(土) 18:40:11.28

え？↓これってデマなんだよね？

https://qiita.com/shadowTanaka/items/5fb99819629dcaab3e05

**デフォルトの名無しさん** · 2022/09/03(土) 19:00:48.70

>>174
わざわざ　w = v; 　してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな

**デフォルトの名無しさん** · 2022/09/03(土) 19:10:31.55

>>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?

>>92
はhello worldレベル過ぎて逆に意味なくない?

**デフォルトの名無しさん** · 2022/09/03(土) 19:29:43.18

>>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ

**デフォルトの名無しさん** · 2022/09/03(土) 19:37:31.78

>>178
＞Cのコードを書く必要はない
＞ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ

**デフォルトの名無しさん** · 2022/09/03(土) 20:06:47.23

>>174
最適化度合いに一貫性のある言語って何？
Cだろうがasm確認しないといけないのは同じだと思うが

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

>>109のコードを見てみたが書き方が酷いな
とりあえずそれと全く同じ関数仕様に合わせるとして
Rustならもっと簡潔にこのように書く

fn max_value_slice_vw(v: &[u32], w: &[u32]) -> u32 {
　std::iter::zip(v, w)
　　.map(|(m, n)| m + n)
　　.max()
　　.unwrap_or_default()
}

C言語バージョンより遥かに分かりやすいし
通常Rustでは返り値をu32でなくOption<u32>とするから最後のunwrap_or_default()も不要となる

これでC言語バージョンと全く同じ結果を得られるし
境界チェックも行われないし
そのC言語バージョンと全く同等のアセンブリコードが生成されることも確認できる
つまり今回の>>109の件もRustとCは同じ速さで動作する

**デフォルトの名無しさん** · 2022/09/03(土) 20:17:46.35

>>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...

>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ

**デフォルトの名無しさん** · 2022/09/03(土) 20:34:30.71

「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている

**デフォルトの名無しさん** · 2022/09/03(土) 20:45:21.45

>>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し

**デフォルトの名無しさん** · 2022/09/03(土) 20:48:32.94

>>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね

**デフォルトの名無しさん** · 2022/09/03(土) 20:51:48.37

>>185もはや自虐ネタ。嫌味ですか？

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

Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件

**デフォルトの名無しさん** · 2022/09/03(土) 21:07:27.69

こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ

**デフォルトの名無しさん** · 2022/09/03(土) 21:10:15.24

for文を使わずにメソッドチェーンで書いたことが気に入らないのならば
>>181はfor文を使って以下のように書ける

fn max_value_slice_vw2(v: &[u32], w: &[u32]) -> u32 {
　let mut max = 0;
　for (m, n) in std::iter::zip(v, w) {
　　if max < n + m {
　　　max = n + m;
　　}
　}
　max
}

これもC言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる

**デフォルトの名無しさん** · 2022/09/03(土) 21:13:41.03

せめてID変えずにやってくれればいいのにな
何回NGさせるんだか

**デフォルトの名無しさん** · 2022/09/03(土) 21:15:53.68

>>189
確認乙
POC(>>177,182)積み増し乙

**デフォルトの名無しさん** · 2022/09/03(土) 21:25:28.83

Cだと速いけどRustだと遅くなるケースって存在しないの？
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから

**デフォルトの名無しさん** · 2022/09/03(土) 21:30:23.63

本人はバレてないと思ってるらしいw

**デフォルトの名無しさん** · 2022/09/03(土) 21:34:03.97

>>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝

**デフォルトの名無しさん** · 2022/09/03(土) 21:55:58.00

Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
　　println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
　　println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。

**デフォルトの名無しさん** · 2022/09/03(土) 22:05:33.75

Rustがそんなに速いならなんで競プロはC++一択なの

**デフォルトの名無しさん** · 2022/09/03(土) 22:19:33.41

>>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り

**デフォルトの名無しさん** · 2022/09/03(土) 22:30:44.07

まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然

**デフォルトの名無しさん** · 2022/09/03(土) 22:31:15.35

>>196
解説本がc++が多いからかな

**デフォルトの名無しさん** · 2022/09/03(土) 22:34:08.49

例えば競プロAtCoderでABC182-E問題 i行目j列目のマス(i,j)を扱う問題
提出された各プログラミング言語別の実行時間分布
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

**デフォルトの名無しさん** · 2022/09/03(土) 22:38:11.41

Rustはコーディングに時間がかかるから競プロでは使えない。
競プロにC++とPythonは良い選択。

**デフォルトの名無しさん** · 2022/09/03(土) 22:41:39.07

>>200
競プロでもRustが速いね

**デフォルトの名無しさん** · 2022/09/03(土) 23:18:47.73

>>196
そもそもC++もちゃんと書けるとは言えないでしょ
mainとグローバル変数しか使わないし

**デフォルトの名無しさん** · 2022/09/03(土) 23:28:32.01

他言語を貶しても、Rustが使える言語にはならない。

**デフォルトの名無しさん** · 2022/09/03(土) 23:28:44.38

>>200
Pythonを選んだ時点でPyPy3にしたとしても負け戦が確定かよ
Rustは競プロでも強いのか

**デフォルトの名無しさん** · 2022/09/03(土) 23:33:58.57

>>200 懐かしいなあ
ttps://ビット.ly/3CS8AuV
トップのuzzyさん始めC++勢がじわじわ最適化を進めているのがカッコイイ
ちらほらいるRust勢は一発屋だけでインクリメンタルな最適化が出来ていないね。
Rustは一貫性がない(>>177,>>182)から下手に弄れなかったのかな？

**デフォルトの名無しさん** · 2022/09/03(土) 23:43:22.86

>>204
その定型文のどこが「使える」と思ったのかがさっぱり分からないよ

**デフォルトの名無しさん** · 2022/09/03(土) 23:47:27.33

>>207 Rustって一発作ったらそれ以上で弄れないって開発現場では使えない言語だね(>>206)

**デフォルトの名無しさん** · 2022/09/04(日) 00:08:42.58

>>206
インクリメンタルに最適化したと本気で思い込んでる？
uzzyの上位4つとも全てソース同じまま変化していない
つまり何度も同じのを提出してトライしただけ

**デフォルトの名無しさん** · 2022/09/04(日) 00:27:20.06

で、その競プロでのc言語での参加率はどれくらい？> cオジ

**デフォルトの名無しさん** · 2022/09/04(日) 00:31:23.21

4回ともC++コード同じだな
ただしその一つ前だけコードが違っていて二次元配列を一次元へと書き換えて改善してる
一方でRustの人は最初から一次元にしてるからその改善が必要なかった
つまり>>208はRustを叩きたいだけの完全に的外れ

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

たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな

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

>>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか

**デフォルトの名無しさん** · 2022/09/04(日) 08:07:09.64

>>213
いいや
Pythonは論外だけど他の言語で十分戦える

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

>>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり

**デフォルトの名無しさん** · 2022/09/04(日) 10:34:00.57

本日のRustあげ会場はこちらですか？

**デフォルトの名無しさん** · 2022/09/04(日) 11:16:04.09

貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ

**デフォルトの名無しさん** · 2022/09/04(日) 11:23:49.03

参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。

**デフォルトの名無しさん** · 2022/09/04(日) 11:27:19.04

つまりRustは生産性が低いor利用者の能力が低いってこと？

**デフォルトの名無しさん** · 2022/09/04(日) 11:52:32.99

普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな

**デフォルトの名無しさん** · 2022/09/04(日) 12:28:01.29

CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな？

**デフォルトの名無しさん** · 2022/09/04(日) 12:29:11.61

ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ

**デフォルトの名無しさん** · 2022/09/04(日) 12:57:20.84

>>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける

**デフォルトの名無しさん** · 2022/09/04(日) 13:11:43.10

pythonでアルゴリズム性能出ると思ってるのお前だけだよ。。

**デフォルトの名無しさん** · 2022/09/04(日) 13:31:05.58

お前がアルゴリズムという言葉を知らないと言うことがわかった

**デフォルトの名無しさん** · 2022/09/04(日) 14:04:04.57

行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython

argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる

**デフォルトの名無しさん** · 2022/09/04(日) 14:42:33.66

何と戦ってるのか知らんがイミフな基準

**デフォルトの名無しさん** · 2022/09/04(日) 14:46:33.79

>>223
うーん、いろんな言語で競プロやってる青色だからついコメントしたくなってしまう

CPythonは知らんけど、pypyは実行速度速いからマラソンでもなければ困ることないよ
再帰がしんどいと言われる問題も、コドフォではよく使われてるbootstrapデコレータを使えば簡単に解決する
Rustはusizeの扱いのために余分なコードが必要になることが多かったし、クロージャ使おうとすると引数の型とかめんどいしで、最近は専らPythonを使ってる
Pythonはクロージャを短めに書けることも競プロ的には気が楽だな

**デフォルトの名無しさん** · 2022/09/04(日) 15:31:08.56

Rustは競プロに向いて居ないからな。
避けるのが賢明。

**デフォルトの名無しさん** · 2022/09/04(日) 15:33:36.35

複オジと
複オジにマジレスしちゃう人と
その両方を焚き付けて喜んでる人の三人でお送りしています

**デフォルトの名無しさん** · 2022/09/04(日) 16:44:07.43

Cが普通はintインデクスなのになんで、配列というかスライスをusizeにしたか何回も疑問に上がるよね....
まあインデックスループじゃなく、イテレート操作するからとか、std::ops::Index<T>でusizeだからとか
色々な回答があるけど、どうにもスッキリしない
usize以外の型（より小さい型やsigned)を使えるようにすることは将来ありうるかという開発者への質問も
ライブラリの互換性上ではすぐに実現できないみたいだし、ま、使う人の利便性・プログラマーへの負担軽減を
優先的に考えて作られた言語じゃないからだけど、let mutと書いてる時点でそうだが、せめてこれだけでも
1キーワードに出来なかったんだろうかな
それとCだとint a = 0, b = 1, c = 2;と宣言できるけど、let (mut a, mut b, mut c) = (0, 1, 2);
文末セミコロンで複数行に分けても、理解しやすいという話はどこに行った？使いやすさを求めては
イケないんだろうけど、どうもね....

**デフォルトの名無しさん** · 2022/09/04(日) 16:46:11.53

ミュータブルを極力使うなということだろ

**デフォルトの名無しさん** · 2022/09/04(日) 17:40:27.34

韓国で最も愛される言語と銘打てば流行るのでは？

**デフォルトの名無しさん** · 2022/09/04(日) 17:47:06.26

>>231
わざと面倒臭くさせてることに意味がある
その辺りの思想は今までの言語とは違うかもしれん

**デフォルトの名無しさん** · 2022/09/04(日) 17:48:26.12

>>231
＞Cが普通はintインデクスなのに
そんなルール無いよね？
仕事で他社さん作ライブラリがuint使ってたことある。

**デフォルトの名無しさん** · 2022/09/04(日) 18:06:41.17

普通にprintln!使うと遅いんだけど教プロ上位なんだな

**デフォルトの名無しさん** · 2022/09/04(日) 18:17:28.78

競プロではRustは間違いなく最速レベルだし、proconioみたいなマクロを使えば入出力もめちゃくちゃ扱いやすい
でもまあそれ以外のとこでかなり慣れがいる

**デフォルトの名無しさん** · 2022/09/04(日) 18:21:48.03

安心安全最速、Rust最高じゃん

**デフォルトの名無しさん** · 2022/09/04(日) 19:10:58.79

>>231
インデックスやその長さはusize型で絶対に正しい
まずインデックスは負の数になってはいけないからunsigned型
サイズとしてはポインタなどと同じそのCPUで使われるサイズでなければならないからusizeとなる
そして実際のほとんどの様々なプログラミングにおいてインデックスはusize型で上手く動く

ところが例外が二つある
例外の一つは自分たちで決められない外部指定APIなど規定においてインデックスや長さがusize型でない場合でas usizeにより解決

例外のもう一つは一部の数値アルゴリズムでプログラミングする上で一時的もしくは最初あるいは終端で負の数になると便利なことがある
もちろんその一時的な負の数である時ははインデックスとして使われないようにプログラマーの責任でプログラミングしてインデックスとして使う時はas usize

**デフォルトの名無しさん** · 2022/09/04(日) 19:29:23.15

浮動小数点数から符号無し整数へキャストする命令なくね？
最近の処理系は直接キャスト出来るようなったん？

**デフォルトの名無しさん** · 2022/09/04(日) 19:44:58.67

>>231
その3-tupleはデータ型の一つでもありまとめて変数に格納できるし関数の引数や戻り値に3-tupleは使える
let foo = (1, 2, 3);

letはパターンマッチ文なので分解にも使う
let (a, mut b, c) = foo;
b += 100;
println!("{a} {b} {c}')
ここでbしかmutableを必要としていないのだから個別mut指定が自然
どの言語でも同様だがmutableをできる限り少なくするのがプログラミングのコツ

**デフォルトの名無しさん** · 2022/09/04(日) 20:00:50.97

>>231
Cも配列のインデックス関連は(s)size_tが基本では
strlenやmemcpyの引数や返値はsize_tだし
単にintから暗黙的にキャストできるというだけで

暗黙の数値キャストがないのは確かにめんどくさい

asでのキャストはリリースビルドだと範囲外の値になったときにエラーにならないし、
絶対成功するキャストと失敗する可能性のあるキャストが見た目からぱっと区別がつかないのもよろしくない
かといってn.try_into().unwrap()を書くのもだるい

せめてn.into()で済ませたいが16bitアーキもサポート対象だからusizeに From<u32> が実装されていない

ターゲットを32bit以上のアーキテクチャに限定するした場合はinto()使えるようにするとか、もう少し楽にできないだろうか

**デフォルトの名無しさん** · 2022/09/04(日) 22:29:03.84

>>242
Rustは基本としては正しい一貫した方針をとっていて
型変換が必ず成功するものはinto()つまりfrom()が定義されていて
型変換が成功しない可能性のあるものはtry_into()つまりtry_from()が定義されている
したがって基本的にはどちらかを用いればよい
新たな型に対しても同じ方針で実装していくしライブラリもそうなっている
usizeについても同様だが16bit環境もあるためbool, u8, u16からのみinto()となり一貫している
唯一の例外は浮動小数点で成功が定義されないためにinto()もtry_into()もない

上述のコンパイラが型変換を常に保証する方式に対して
プログラマーが型変換を保証する方式に利便性を兼ね備えたのがasによるキャスト
これは例えばu32を自動的に上位を切り捨ててu8に入れるといったことも含めた広義の型変換も含まれる
いずれのケースもキャストはプログラマーの責任で行なうという一貫した方針がある
わざわざ『as xxx』と記述させるのはそのためで意図的に目立つようにしている
プログラムをチェック、デバッグ、メンテする時にunsafeに準じてas xxxは注視すべきポイントとなる

**デフォルトの名無しさん** · 2022/09/04(日) 23:03:51.17

>>243の基本を踏まえた上で
例えば16bit環境でなければu32からusizeへのtry_into()は常に成功し安全にunwrap()できる
生成コードも以下のようにコストゼロ
https://godbolt.org/z/cEc5fKGjh

キャストasと同様にunwrapも注視ポイントとなるため
利便性も含めてinlineのto_usize()を用意してしまうのがよいかもしれない
bit環境依存性はそのメソッドに押し込めることで注視ポイントが散らばるのを防げる

**デフォルトの名無しさん** · 2022/09/04(日) 23:05:01.26

危険のある操作は面倒にするべきなんだよ。

**デフォルトの名無しさん** · 2022/09/04(日) 23:23:22.66

>>239
それ絶対に正しいとは言えてないよね
下のほうに書いてるんだろうけど、よくある別の言語仕様だと、a[-1]が末尾を表したりできるし、数多くの言語でインデックスループだと
これもよくある相対位置やインデックス演算でa[i-1]とか書くけど、usizeをキャストしてi32にしてもう一度、スライスにアクセスするために
as usizeとか2回キャストを行う。これがどれほど醜くなるし、めんどくさくて労力を要するか
当然、メモリアドレッシングが0x00～上に伸びていくことなんて言わなくてもわかるが、それが合理的であり、かつスライスがusizeで
支持できる理由かといえばどうだろう？少なくとも私はメンドクサイ
またもちろん、(a, b) = t がタプルのアンパッキングなどに使えるのも知ってるけど、それとまとめて変数の宣言と初期化を少ないタイプ量で
出来る話とは別だろう、上からアドバイス頂いてるようでケチをつけて申し訳ないけど、もちろん不変性はマルチスレッドでも有利だしコードの
リファクタリングなどもし易い、ファンクションの変更が良くわかる（そのくせ同じ変数名で別型再定義できたり）とか色々利点があるのは
当然分かってるけど、これもまたmutを多数宣言しなきゃならない時とは全く別の話だよ

**デフォルトの名無しさん** · 2022/09/04(日) 23:56:45.66

>>246
Rustならばusize型そのままa[i-1]と書くことが出来ますが
2回キャスト面倒とは別の言語の話ですか？

例えば前の要素との差が指定のものを見つけてインデックスを返すRustコード例
fn find_diff(a: &[i32], diff: i32) -> Option<usize> {
　for i in 1..a.len() {
　　if a[i] - a[i-1] == diff {
　　　return Some(i);
　　}
　}
　None
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります

**デフォルトの名無しさん** · 2022/09/05(月) 00:30:20.92

まともにプログラム書いたことなさそうだね

**デフォルトの名無しさん** · 2022/09/05(月) 00:34:33.72

>>241
Rustはletとmut指定を分離することでそのようにできるから大成功だな
mut指定が分離していない言語ではそのようにすることができずいつも困っている
方法がないからimmutableで十分な変数も含めてまとめてmutableな変数宣言にせざるをえない
初めて知ったときRustはよく考えられているなあと感動した

**デフォルトの名無しさん** · 2022/09/05(月) 00:43:43.47

>>246
・Rustは、数値リテラルに多くの言語ある固定の型がなく、文脈によりu32とかi32とか変わる（型推測）
・下のほうで境界チェックがないのも1..a.len()としているから
当然ながら、これは胸を張って一貫性があるとは言えないがa[-1]は言語仕様ではコンパイルエラーになるが
for i in 0..a.len()とすれば境界チェックが入り実行時にpanicする
君が勘違いしてるのはa[i+b]とかはbを宣言した場合、as castが必要で、色々ごっちゃになってるYO

アンダースタンド？ｗ

**デフォルトの名無しさん** · 2022/09/05(月) 00:44:27.92

C++は型の特性を調べて、ユーザーがconst性を利用したバージョンの実装を生み出すことができる。
しかも利用時には、型の特性によってコンパイラにどのバージョンを使うか選択させる事が出来る。

**デフォルトの名無しさん** · 2022/09/05(月) 00:48:14.12

RustもIndex<u32>とか実装はできるよ
標準のsliceに実装されてないというだけで

**デフォルトの名無しさん** · 2022/09/05(月) 00:55:53.18

C++は、型の計算ができるんですよ。

**デフォルトの名無しさん** · 2022/09/05(月) 01:07:57.19

すまん、誰が聖闘士星矢で例えてくれないか？