24/03/21 01:05:26.83 CBfowBe/.net
直接の原因はunsafeなメソッドをsafeメソッドにしたこと
unsafeのsafe wrapperの質は大事
今のコードもunsafeの使い方が怪しくて信頼できない
fn get_release_unchecked_mut(&mut self, index: usize) -> &mut UntypedValue {
debug_assert!(index < self.capacity());
// Safety: This is safe since all wasmi bytecode has been validated
// during translation and therefore cannot result in out of
// bounds accesses.
unsafe { self.entries.get_unchecked_mut(index) }
}
357:デフォルトの名無しさん
24/03/21 01:39:19.40 t5wrhqh7.net
>>350
俺んとこもそのコードはよく書くけれど
今回の敗因は引数のindexが生のusizeであること
そこをusize直接ではなくそのラッピングの専用型にする
そしてその専用型が動く範囲が必ず範囲内であることを保証する形で
get_uncheckefのunsafeを使う関数をsafeに仕上げる
358:デフォルトの名無しさん
24/03/21 19:05:54.93 QWnK+qvS.net
unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？
359:デフォルトの名無しさん
24/03/21 19:57:12.18 7RDAu5V5.net
全然そういう事
Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい
360:デフォルトの名無しさん
24/03/21 20:09:58.67 gM/gTjZ5.net
>>353
それ言うなら
無闇に「ヤバい」を使うぐらいヤバい
じゃね
361:デフォルトの名無しさん
24/03/21 20:26:53.11 1l7zk65j.net
俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな
ガンガンunsafe使ってこーぜ！！
362:デフォルトの名無しさん
24/03/21 20:28:39.30 7RDAu5V5.net
>>354
それだと単なる自己言及だから352に対する答えとして不十分では
363:デフォルトの名無しさん
24/03/21 20:45:04.06 t5wrhqh7.net
少なくとも>>350のindex: usizeは
何らかラッピング { index: usize }と別型にすべきところ
まず範囲外のusizeでうっかり使っても型エラーにできる
そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる
364:デフォルトの名無しさん
24/03/21 21:05:14.02 7RDAu5V5.net
NonZeroとかNonNullみたいな固定条件ならいいけど
範囲みたいな可変条件だと型だけじゃ厳しいでしょ
別の条件で作られた同じ型の値を使われるかもしれないし
ライフタイムで条件と関連付けるのも限界がある
結局テストパターン増やしてdebug_assert踏むしかない
365:デフォルトの名無しさん
24/03/21 21:44:37.76 t5wrhqh7.net
>>358
もちろん二段階
まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける
次にコーディングやレビューやメンテでその専用型の動きに注視できる
366:デフォルトの名無しさん
24/03/21 22:18:44.86 cOunjWn7.net
unsafeをsafeでないのにsafeにしておいて
ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです
367:デフォルトの名無しさん
24/03/21 22:27:42.27 WuGieKPN.net
結局プログラマが色々意識してコーディングしないと安全にはならないのね
こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど
368:デフォルトの名無しさん
24/03/21 23:07:15.31 7RDAu5V5.net
unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる
実際は安全の為でもpanicで止まると困るから色々注意しないといけないし
unsafeで余計なチェック省いたり黒魔術使ったりもする
Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない
369:デフォルトの名無しさん
24/03/21 23:12:07.
370:53 ID:v/mpoJJ8.net
371:デフォルトの名無しさん
24/03/21 23:22:25.34 WuGieKPN.net
いつもの人がきたｗ
結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ
Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど
372:デフォルトの名無しさん
24/03/21 23:58:23.31 z414Bs3I.net
> Rustであれば安全と思ってる人が多そう
いや一応言っとくけど多くはないよ流石にｗ
一部の人が連呼してるだけ
ほかの人はもっと現実的だろな
373:デフォルトの名無しさん
24/03/21 23:59:21.08 t5wrhqh7.net
原則はunsafeを使うな！
これだけだ
理解できていてunsafeを使う場合も
とにかく閉じ込めろ！
専用のクレートを作れ
専用のモジュールを作れ
専用の型を作れ
374:デフォルトの名無しさん
24/03/21 23:59:51.15 XJ9dJAV6.net
unsafe使わなければ安全
375:デフォルトの名無しさん
24/03/22 09:16:28.77 IQ7X1X+j.net
まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。
それは意識して気をつけた方がいい。
376:デフォルトの名無しさん
24/03/22 10:19:34.77 avPqaarP.net
ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。
チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。
そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ……
普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。
377:デフォルトの名無しさん
24/03/22 11:58:26.79 7Rs7masV.net
>>358
0～127の範囲のみを取りうるようなEnumなら作れる
wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど
サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本
それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない
>>359のやり方はそれができてないように感じる
378:デフォルトの名無しさん
24/03/22 12:34:01.41 TbCMvv+/.net
実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい
そうすればその型に対して常に安全にget_uncheckedを使える
379:デフォルトの名無しさん
24/03/22 14:04:42.65 ZrfX32kv.net
Rustは失敗言語
380:デフォルトの名無しさん
24/03/22 14:10:55.04 ceR9yHkM.net
今回の件でRustの安全性が確実になったのが興味深いよな
アンチが必死に探してきた問題も>>350でunsafe利用だった
381:デフォルトの名無しさん
24/03/22 16:00:31.63 JqYXTM4B.net
>>371
「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど
実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ
unsafeにする意味がない
382:デフォルトの名無しさん
24/03/22 17:14:19.13 vuLWDWdh.net
>>374
実行時コストをかけないためにget_uncheckedを使うのが一般的
その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法)
383:デフォルトの名無しさん
24/03/22 19:27:28.32 G6tKD1fj.net
Adaなら特定の範囲の型作れるみたいよ
384:デフォルトの名無しさん
24/03/22 20:07:18.97 vuLWDWdh.net
今回は範囲が固定ではなく変わり得る
385:デフォルトの名無しさん
24/03/23 23:29:45.64 eeq00BcS.net
誰にでもunsafeが使えてしまうのが問題なのでは？
原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。
386:デフォルトの名無しさん
24/03/24 00:34:36.37 iaJ2USO3.net
Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。
まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。
387:デフォルトの名無しさん
24/03/24 10:55:06.56 UXqlkypu.net
>>375
「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350の引数のindexをその型に変えたところでsafeにしたらダメだよ
388:デフォルトの名無しさん
24/03/24 11:08:34.82 BHU0SFkf.net
なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？
389:デフォルトの名無しさん
24/03/24 11:48:11.45 uu8/yG2s.net
indexの境界チェックが律速になるようなコード書いてみてえな
390:デフォルトの名無しさん
24/03/24 20:37:14.59 YsO86RjG.net
>>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー 配列もその範囲指定で自由に作成できる。
391:デフォルトの名無しさん
24/03/24 20:45:58.90 Rrl8qRWO.net
>>383
定数じゃなければ結局実行時にチェックするってことだよね
392:デフォルトの名無しさん
24/03/25 01:12:47.74 yMlw6u5B.net
>>384
新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。
393:デフォルトの名無しさん
24/03/25 07:21:41.59 CNajD+3j.net
>>384 何十年も前なのですまそ
array(-2)とかarray(6)をアクセスしたら例外発生 array(-1)はOK
type Month is range 1..12
type Month_Array is array(Month) of Integer;
ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12);
for m in ma'first..ma'last loop // カウンタは1から12
ma(m) = m;
end loop;
394:デフォルトの名無しさん
24/03/25 14:37:28.19 x/lXcXel.net
今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど
そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね
395:デフォルトの名無しさん
24/03/25 16:23:44.40 9GDk/VLW.net
How much does Rust's bounds checking actually cost?
URLﾘﾝｸ(blog.readyset.io)
396:デフォルトの名無しさん
24/03/25 17:27:16.04 MT/jL+52.net
こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。
問題は浮動小数の取り扱いだっての。
397:デフォルトの名無しさん
24/03/25 21:23:48.62 x/lXcXel.net
unsafeは可能な限り避けるべきで
safe Rustでの改善をまずすべき
その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える
現実にはsafe Rustでの改善ができてないことが多い
例えばよく見かける例としては
iが動いていくのにa[i]でアクセスしてしまう
これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern
参照(ポインタ)化することで範囲checkを1回に減らせる
398:デフォルトの名無しさん
24/03/27 15:06:55.14 g9hYSxJr.net
unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね
unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事
399:デフォルトの名無しさん
24/03/27 15:29:03.70 pFQTMi8v.net
「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」
が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので
400:デフォルトの名無しさん
24/03/27 16:02:47.08 BwG0n/Az.net
unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。
unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？
401:デフォルトの名無しさん
24/03/27 16:59:36.71 LwoOYerE.net
>>393
そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。
402:デフォルトの名無しさん
24/03/27 17:05:39.09 6Vj8sISV.net
>>392
センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ
今はそれが全然できてないから>>350のような基本的なミスを犯すやつが後を絶たない
403:デフォルトの名無しさん
24/03/27 17:08:09.55 6japDZ8y.net
windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。
404:デフォルトの名無しさん
24/03/27 18:09:17.85 345wycOn.net
>>395
～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。
405:デフォルトの名無しさん
24/03/27 18:27:03.05 3NgGdhlw.net
>>397
問題点の指摘や解決策の提案と
問題解決のために実際に誰が動くのかという
2つの異なるものを混同したらだめだよ
マネジメント101
406:デフォルトの名無しさん
24/03/27 18:54:43.86 nHNmKGrp.net
その素晴らしい提案がなぜされていないのか考えよう
そしてなぜ自分は実行から逃げているのか考えよう
407:デフォルトの名無しさん
24/03/27 20:42:45.86 deTzlgug.net
>>394
Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。
408:デフォルトの名無しさん
24/03/27 21:06:58.89 LwoOYerE.net
unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。
危険な操作も含まれるけど危険な部分を分けれてるわけではない。
もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。
409:デフォルトの名無しさん
24/03/27 21
410::18:47.87 ID:deTzlgug.net
411:デフォルトの名無しさん
24/03/27 21:31:01.25 LwoOYerE.net
>>402
だからそうしたいならそうすりゃいいって話をしてる。
あなたが裁量権をもつプロジェクトでは。
私が反論してるのは「そのためのものだ」という部分に対して。
412:デフォルトの名無しさん
24/03/27 21:44:58.62 deTzlgug.net
>>403
Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。
unsafeはデフォルト禁止でいいよ。
413:デフォルトの名無しさん
24/03/27 21:49:49.48 Fy0R0co2.net
理想をいえばunsafeなんて無いならサイコーだったんだろうね
rust陣営もしゃあなしでunsafe導入したんやろうし
unsafeなしですべてがセーフで効率的だったら
そりゃあrustは本当に素晴らしい文句なしの言語だったやろな
414:デフォルトの名無しさん
24/03/27 22:08:33.46 toZsv7uT.net
生ポインタすなわちCPUによるメモリアクセスはunsafe
そこが出発点
unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる
それがsafe Rustの基本原理
つまりunsafeに行き着くためunsafe無しでは何もできない
これが真理
一方で
unsafeを閉じ込めたライブラリ利用可を前提にすれば
unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実
415:デフォルトの名無しさん
24/03/27 22:24:02.18 cgbLYCC5.net
>>406
だったらデフォルトunsafe禁止で良い。
どこでもunsafe okはやっぱりチグハグ。
416:デフォルトの名無しさん
24/03/27 22:52:47.09 qNf/D02g.net
そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？
417:デフォルトの名無しさん
24/03/27 22:57:38.14 LwoOYerE.net
>>404
「そうであって欲しいと自分は思っている」なら別にいいよ。
ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。
418:デフォルトの名無しさん
24/03/27 23:02:28.02 toZsv7uT.net
#![forbid(unsafe_code)]
を宣言すればいい
もちろんすべてはunsafeへ行き着くため
unsafeを禁止できるのは自分のコード部分だけ
419:デフォルトの名無しさん
24/03/27 23:55:45.93 pFQTMi8v.net
unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな
平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する
420:デフォルトの名無しさん
24/03/28 07:44:09.91 OabXy/xk.net
>>409
公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。
>>411
拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？
421:デフォルトの名無しさん
24/03/28 08:15:17.48 wHq/ItvK.net
rustもいろいろ問題を抱えてるんだね
プログラマの習熟が必要だっていうなら流行らないだろう
メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし
新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう
422:デフォルトの名無しさん
24/03/28 08:34:31.08 5loDhjzb.net
>>412
こう書くだけでunsafeの使用が禁止されます
#![forbid(unsafe_code)]
>>413
普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません
423:デフォルトの名無しさん
24/03/28 08:48:28.49 OabXy/xk.net
>>414
>411みたいなマキャベリガイジが混ざると破綻しますな。
MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。
424:デフォルトの名無しさん
24/03/28 09:00:19.29 5loDhjzb.net
>>415
これでunsafeが使用禁止となり安全なsafe Rust�
425:ﾉなる #![forbid(unsafe_code)] コンパイラがunsafeをエラーとして弾く
426:デフォルトの名無しさん
24/03/28 10:37:24.50 dWo+4s1T.net
結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな
427:デフォルトの名無しさん
24/03/28 14:03:58.90 61/ABBlz.net
まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。
428:デフォルトの名無しさん
24/03/28 17:41:01.08 Li+1uESY.net
unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者
一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる
もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、
その部分だけを切り出してライブラリ作成者になれる
それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない
429:デフォルトの名無しさん
24/03/28 18:27:15.03 OabXy/xk.net
>>419
そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。
Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。
430:デフォルトの名無しさん
24/03/28 18:35:39.73 2Ez7VURh.net
unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが
このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう
でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ
431:デフォルトの名無しさん
24/03/28 18:56:54.80 Hx0Q8eMq.net
必要な各企業、各プロジェクトなどで義務付け
#![forbid(unsafe_code)]
これでunsafeの話はおしまい
他の言語と比べてRustはコーディング規約もAPI規約も公式で楽
Rust公式APIガイドライン
URLﾘﾝｸ(rust-lang.github.io)
432:デフォルトの名無しさん
24/03/28 19:45:10.84 OabXy/xk.net
>>422
公式のドキュメントで
#![forbid(unsafe_code)]
の説明を探しているんだけど、どこにあるのかしらん？
doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
の１行でおしまい？
433:デフォルトの名無しさん
24/03/28 20:08:10.91 uNPCtnZO.net
forbidもunsafe_codeもrustcのlintの一部だな
doc.rust-lang.org/rustc/lints/levels.html#forbid
doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code
434:デフォルトの名無しさん
24/03/28 21:59:19.02 vhhc95Ef.net
Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。
435:デフォルトの名無しさん
24/03/28 22:34:58.42 jTiWvkZ+.net
どの開発でも
#![forbid(unsafe_code)]が原則
どうしてもunsafeが必要なら
その安全ロジックを関係者で協議後に
#![deny(unsafe_code)]へそのモジュールのみ変更し
許可する部分のみを
#![allow(unsafe_code)]として監視対象
といった感じが一般的かと
監視対象を極一部に限定できて
全体はコンパイラにより保証できるため
他のプログラミング言語より扱いやすい
436:デフォルトの名無しさん
24/03/28 22:41:56.41 8+kd1npI.net
>>420
一般とそうでない奴は誰がどうやって区別するのさ？
437:デフォルトの名無しさん
24/03/28 22:42:31.88 8+kd1npI.net
>>421
正解
438:デフォルトの名無しさん
24/03/28 23:58:52.21 KGiLR8kg.net
時間がない時はunsafe使っていいよ
439:デフォルトの名無しさん
24/03/29 00:05:51.94 B//2x2dm.net
時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう
440:デフォルトの名無しさん
24/03/29 00:19:58.75 Rgc3qInF.net
>>429
safeで書くのが早くて楽で安全
わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない
441:デフォルトの名無しさん
24/03/29 00:24:32.79 Rgc3qInF.net
>>430
unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる
safe Rustが楽で早く書けて安全
442:デフォルトの名無しさん
24/03/29 01:57:50.63 EplliVDI.net
壊れたレコードオジ怖い
443:デフォルトの名無しさん
24/03/29 02:36:16.29 B//2x2dm.net
>>432
安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？
444:デフォルトの名無しさん
24/03/29 07:36:27.65 9Pm5HVgJ.net
雑にunsafe使って早く書けるのはFFIくらいかな
FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い
pure Rustでunsafeの方が早いケースはちょっと思いつかないな
445:デフォルトの名無しさん
24/03/29 08:25:13.35 bd1Zch8f.net
>>427
そりゃプロジェクト管理者だろ。
そもそもRust採用するメリットはソースコードの品質管理しか無いし。
デフォルトunsafe禁止は何回か話題に出てきているのな。
446:デフォルトの名無しさん
24/03/29 08:27:22.40 bd1Zch8f.net
>>426
それぐらいやらないとRust採用するメリット無さそうだよな。
447:デフォルトの名無しさん
24/03/29 08:41:03.04 ev5kqnbp.net
初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？
448:デフォルトの名無しさん
24/03/29 09:16:34.82 cTkAvXQI.net
そもそも普通に書いててunsafe使いたいなって場面がない
多人数で書いてるならforbidで落としてもいいけど
コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい
449:デフォルトの名無しさん
24/03/29 09:24:57.68 vaG7EqUh.net
>>436
じゃunsafe使うな、で済む話じゃん。
450:デフォルトの名無しさん
24/03/29 09:49:54.05 AosFf04R.net
>>440
そうだね
で？
451:デフォルトの名無しさん
24/03/29 11:01:08.74 8PtB/vi4.net
rustもプログラマがザコだと使いこなせない言語なんだろ？
人材確保すら苦労するってメジャーになれるのかよ
452:デフォルトの名無しさん
24/03/29 11:23:44.57 34VMnlB4.net
unsafeでサッと書いたほうが出世できるぞ
453:デフォルトの名無しさん
24/03/29 11:49:42.05 ZM8BmiyA.net
たしかにプログラムの品質がいいから出世するって見たことないわ
逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな
454:デフォルトの名無しさん
24/03/29 11:53:12.39 opHbD1qf.net
unsafeは面倒
Rustで書いていてunsafeを使いたい気分になることがない
さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない
455:デフォルトの名無しさん
24/03/29 11:54:18.08 K6ErCtbZ.net
>>442
メジャーになれなくて何か問題あるの？
456:デフォルトの名無しさん
24/03/29 12:08:03.79 6hM9S6Vd.net
初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。
457:デフォルトの名無しさん
24/03/29 12:08:08.24 GuqFwMZD.net
>>440
PMやったこと無いの？
unsafe使うなと管理するより、そもそも使えない方が遥かに楽。
458:デフォルトの名無しさん
24/03/29 12:13:58.45 E/kaNL72.net
>>442
C++ とかだと使いこなせてないのになんとなく動いちゃったりするから……
使えてないなら使えないほうがちょっとマシなんだよ。
459:デフォルトの名無しさん
24/03/29 12:15:29.32 vaG7EqUh.net
>>448
言語機能的にunsafeって書かなければそもそも使えないじゃん。
460:デフォルトの名無しさん
24/03/29 13:21:21.11 l8m+nc89.net
>>446
時間の無駄
461:デフォルトの名無しさん
24/03/29 13:35:34.69 ZM8BmiyA.net
>>448
そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね
462:デフォルトの名無しさん
24/03/29 16:25:54.97 34VMnlB4.net
unsafeでサクッと終わらせてどんどん仕事取ろうぜ
safeでチンタラやってる無能に仕事を回すな
463:デフォルトの名無しさん
24/03/29 17:20:13.23 Cl3C8AEw.net
アンチはunsafeを使うと早く書けると誤解しているのが面白い
早くもなければ楽でもないので普通は使わない
464:デフォルトの名無しさん
24/03/29 17:36:40.68 cTkAvXQI.net
「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね
465:デフォルトの名無しさん
24/03/29 17:56:14.07 uhU4IUEm.net
このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが
466:デフォルトの名無しさん
24/03/29 18:02:08.48 uhU4IUEm.net
正常なコミュニケーション力を持った優秀なエンジニア
→こいつらは出世するのでプログラミングスキルは生かされない方向に進む
正常なコミュニケーション力がない優秀なエンジニア
→こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない
どうしたら優秀なエンジニア揃えられるんや…
467:デフォルトの名無しさん
24/03/29 18:06:18.85 fG0MAqjd.net
ｶﾁｮｰ「では進捗を報告してください」
unsafe_man「ｱﾉｰ、ﾁｮｯﾄ時間かかってｵﾘﾏｼﾃ、ｱﾝｾｰﾌが、ｿﾉｰ（怒涛の勢いで難しいことを話し続ける）」
ｶﾁｮｰ「???」
468:デフォルトの名無しさん
24/03/29 18:22:45.54 TAofIzHh.net
>>457
放っておいても勝手に集まるから心配しなくていいよ
そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど
469:デフォルトの名無しさん
24/03/29 18:29:23.69 /REVrZ9A.net
>>459
すまん、集まってるとこの実名あげてくれんか？
470:デフォルトの名無しさん
24/03/29 19:20:01.67 GuqFwMZD.net
>>458
いきなり人格攻撃かよ？Rustらしいな
471:デフォルトの名無しさん
24/03/29 19:31:34.50 wqpOcL9O.net
NとかFとかは優秀な人がいるイメージがない
472:デフォルトの名無しさん
24/03/29 19:54:25.38 M7FjmHlu.net
unsafe使う機会ってほぼないよな
よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか
473:デフォルトの名無しさん
24/03/29 19:58:01.23 wqpOcL9O.net
優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人
でunsafeを使いこなせるかどうかなんか無関係
これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人
474:デフォルトの名無しさん
24/03/29 19:59:06.31 0Uoml8t7.net
システムプログラミング用途も売りにしてなかった？
Cと同等のことをしてみせようってんなら
unsafeくらい当たり前に常用するやろ？しらんけど
ボクは使いません！みたいな意見は誰も求めてないからｗ
475:デフォルトの名無しさん
24/03/29 20:37:55.25 TAofIzHh.net
unsafe使うと変更する時にだるくなるからできるだけ使わない
グローバル変数使うのと同じ気分
「グローバル変数くらい当たり前に常用するやろ？しらんけど
ボクは使いません！みたいな意見は誰も求めてないからｗ」
とか言われたら知らん
476:デフォルトの名無しさん
24/03/29 20:41:59.79 wqpOcL9O.net
誰にも影響及ぼさないなら勝手に使えばいい
477:デフォルトの名無しさん
24/03/29 20:47:48.55 0Uoml8t7.net
使う必要があるからunsafeってもんがあるんであって
使う必要がない人の意見や感想は求められてないんよ
使うべきとか使うべきじゃないとか
普通はどうとか普通はどうじゃないとか
無意味な応酬はやめよう
478:デフォルトの名無しさん
24/03/29 21:08:57.87 bd1Zch8f.net
コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。
479:デフォルトの名無しさん
24/03/29 21:45:08.79 DW6NdCQ6.net
>>451
君の時間の無駄ってこと？
こんなところで毎日無駄な時間過ごしてるのに？
それって君がやらなければいいだけだよね
480:デフォルトの名無しさん
24/03/29 21:46:36.17 wXELlTG7.net
>>468
一連のunsafeコントで初めてまともな意見だな
481:デフォルトの名無しさん
24/03/29 21:52:31.85 TAofIzHh.net
エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで
Rustが普及する日は来
482:るんだろうか 上の方でも言われてたけどコーダー集まらない問題に直面しそうだが
483:デフォルトの名無しさん
24/03/29 22:06:45.92 wqpOcL9O.net
Rustはコーダーは集まらんだろ
普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる
ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる
大手だとこれの繰り返しだがRustはそれが難しい
484:デフォルトの名無しさん
24/03/29 22:29:09.47 wqpOcL9O.net
意図的にどこかで誰かが資金を投入してRustコーダーを栽培（）しないと
増えるわけがない
javaやpythonじゃないんだから
野良Rustコーダーなんて存在しない
使える人間は100%C++使いなので引っ張ってこれない
485:デフォルトの名無しさん
24/03/29 22:30:50.06 UmT7/PmU.net
エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな
486:デフォルトの名無しさん
24/03/29 22:35:31.54 B//2x2dm.net
まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう
487:デフォルトの名無しさん
24/03/29 22:48:02.40 0Uoml8t7.net
それよりもホントにシステムプログラミングできてんのかが興味あるわ
CからはOSならばUnixやLinuxやWindowsが生まれてきたけど
Rustからは一体どんな素晴らしいものが生まれてくるんだろうか？
Cより書きやすくて？ 安全なんだよね？ 期待していいんよね？
Systems programming
URLﾘﾝｸ(en.wikipedia.org)
e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications
488:デフォルトの名無しさん
24/03/29 23:01:23.64 B//2x2dm.net
今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある
でも期待するのは自由だ
Rustファンはみんな期待している
489:デフォルトの名無しさん
24/03/29 23:11:14.94 JKQcuRe5.net
>>477
interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境（Cとアセンブラの独壇場。C++不可の世界）で組み込みRust使う記事とかあったよ。
ビジネスになるかはともかく、技術的には余裕なはず。
490:デフォルトの名無しさん
24/03/29 23:55:56.73 VDRjyKLu.net
既にネットインフラは次々とRust製
ソースは>>51
491:デフォルトの名無しさん
24/03/30 00:06:31.16 v9pXWAWc.net
>>472
Rustは仕様や周辺ツールが飛びぬけて優秀な故
JavaやPHP等他の言語と違って素人でも適当に書いても
大した問題は起こらないから「技術者の立ち位置」を守る観点で見ると
大規模開発現場で普及する事はこれからも無いよ。
492:デフォルトの名無しさん
24/03/30 01:01:10.58 7ofxl8DK.net
それで守られるのはITコン猿の立ち位置じゃね？
エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが
493:デフォルトの名無しさん
24/03/30 01:46:17.09 v9pXWAWc.net
知ってる人間は黙ってRustの恩恵を受けておけば良くて
人売りサル業界は人/月だコミュニケーションスキルだと
喚いていれば良い。
494:デフォルトの名無しさん
24/03/30 07:28:24.91 6WvjgMqi.net
C++が流行った経緯知ってる奴なら想像できるだろ。
C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。
でも流行ったのはC++。
495:デフォルトの名無しさん
24/03/30 13:15:43.05 Kpt9p6/a.net
C++はわかりやすく拡張されたCだからさ
ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった
NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない
日本語の書籍がないのが一番つらかった
496:デフォルトの名無しさん
24/03/30 20:58:56.17 IReUP+am.net
当時NeXTに触れてたやつおるん？
たまげたなぁ
俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ
いつごろだったかなぁ日本語のやつあったけどなぁ
まさかmacOSで脚光浴びるとは思いもせずに
497:デフォルトの名無しさん
24/03/30 21:08:50.38 Kpt9p6/a.net
研究室にあったんよ
当時でももう型オチででも予算無いからリプレースも出来ず
MOのデータを消しながら使ってた
古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで
自分は図書館に埋もれたModulaの本を読んでた
498:デフォルトの名無しさん
24/03/30 21:14:51.55 IReUP+am.net
羨ましい
俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ
あー羨ましい
499:デフォルトの名無しさん
24/03/30 22:32:19.21 VLAlfJh3.net
モーモーちゃんに入れている人は居たな
500:デフォルトの名無しさん
24/03/31 11:42:27.74 lJUXuXT4.net
C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。
結局は C のままでいくと判断した。
良くなるのだとしても、少なくとも一時的には大きな混乱が起こることを C++ は許容しなかった。
言語ってのはそれを取り巻くエコシステム (言語ユーザーやドキュメントも含む) と離れて成立することはないってこと。
C++ は C のツールチェインにほとんどそのまま乗っかる形で (最初は) 普及したし。
Rust はツールチェインの整備も一緒に取り組んだというのは普及の一助になったとは思うけど、
今までに作られた膨大なソフトウェア資源の最も低レイヤの部分は結局は C なんだよね。
そもそも ABI が C を基準にした仕様だったりするので
他の言語と接続するときは皆が C に合わせる形になる。
もしこれから Rust がもっと普及することがあったとしても低レイヤでは C の残滓はいつまでも消えないと思う。
501:デフォルトの名無しさん
24/03/31 15:29:48.98 dXzgmT0X.net
ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う
502:デフォルトの名無しさん
24/03/31 16:44:42.12 PaHOJUqO.net
>>490
Rustで書いたOSが大流行でもしない限りCと同じようにはならない。
ただ、Linux は Rust を取り込み始めたので何十年も掛けてゆっくり Rust 化する可能性はある。
そうなると移行したライブラリは増え続け、50年後ぐらいには今のCと同じようになっているかも知れない。
もちろんその頃には別の新言語が出てきていて Rust が時代遅れな言語になっているわけだが。
503:デフォルトの名無しさん
24/03/31 19:15:56.54 r1rO2LMH.net
ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない
多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する
504:デフォルトの名無しさん
24/03/31 19:55:09.3
505:0 ID:T95JlUSJ.net
506:デフォルトの名無しさん
24/03/31 21:03:45.67 rhKYEfc8.net
>>493
何言ってんのwww
相変わらず無知が過ぎる
507:デフォルトの名無しさん
24/03/31 22:06:47.20 HimKkZni.net
いやまあ1%もいないんじゃない？
508:デフォルトの名無しさん
24/03/31 23:37:37.59 PUonJ710.net
そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど
509:デフォルトの名無しさん
24/04/01 19:53:32.69 QJf4H8j7.net
そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。
510:デフォルトの名無しさん
24/04/01 20:06:07.63 lQvViLVK.net
C++より多いから問題ない
511:デフォルトの名無しさん
24/04/01 22:56:49.63 wqqAiPYQ.net
「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
512:デフォルトの名無しさん
24/04/02 08:53:54.00 i0O60K8Z.net
>>500
メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。
c++標準も、Safe Rust に倣って
c++ subset for safe programming
とか 作ればいいのに。
513:デフォルトの名無しさん
24/04/02 09:19:58.94 D6QICSr8.net
メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。
514:デフォルトの名無しさん
24/04/02 09:39:48.87 EeET/S7r.net
java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。
515:デフォルトの名無しさん
24/04/02 11:06:55.03 lti1kN7b.net
>>503
安全じゃ無いぞ
516:デフォルトの名無しさん
24/04/02 14:49:37.59 b3hi6lw5.net
>>501
C/C++はプログラム全体がunsafe空間なので難しい
safeにしようとすると全く別言語になってしまう
結局C/C++を捨てるのが正しい
517:デフォルトの名無しさん
24/04/02 17:14:03.69 kERS+9TD.net
>>503
nullポイントがある時点で…
一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど，だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ
518:デフォルトの名無しさん
24/04/02 17:14:28.23 kERS+9TD.net
nullポインタだ
ごめんなさい
519:デフォルトの名無しさん
24/04/02 18:23:13.98 mnREx4SD.net
ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される
nullから何かを読み出して動き続けると危険
520:デフォルトの名無しさん
24/04/02 18:43:54.77 0YGJ2wff.net
>>508
Someである保証がある時のみunwrap()を使う
保証がないのにunwrap()する人はクビ
521:デフォルトの名無しさん
24/04/02 18:54:06.54 mnREx4SD.net
メモリ安全の文脈だからそういう次元の話ではないのだが
522:デフォルトの名無しさん
24/04/02 18:55:57.61 i0O60K8Z.net
>>505
コーダー向けだから別言語でいいよ。
new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。
operator関数定義も禁止でいいんじゃない？
523:デフォルトの名無しさん
24/04/02 19:03:35.75 mnREx4SD.net
ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね
524:デフォルトの名無しさん
24/04/02 19:19:41.72 qL7KDCYj.net
rustって楽しい？
525:デフォルトの名無しさん
24/04/02 19:20:30.34 kERS+9TD.net
どの言語にも共通するけど，書けるようになってくると楽しいよ
526:デフォルトの名無しさん
24/04/02 19:40:54.12 lti1kN7b.net
でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね
527:デフォルトの名無しさん
24/04/02 19:43:54.71 ptOw8ylO.net
>>512
あ、未定義と定義されているのも全部禁止ね。
528:デフォルトの名無しさん
24/04/02 20:13:32.30 +hiVU8fL.net
>>500
これでRustの知名度も上がるし普及も加速しそう
529:デフォルトの名無しさん
24/04/02 20:26:12.86 lti1kN7b.net
>>517
結構前にもNASAが同じ様な事言って今やんw
530:デフォルトの名無しさん
24/04/02 20:31:06.25 EeET/S7r.net
rustを無理に使ってまですることがぬるぽ対策とかアホだよね
531:デフォルトの名無しさん
24/04/02 20:45:15.37 lti1kN7b.net
>>519
まあ戦争によるサイバー攻撃に備えろってのは分かるんよ
日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね
532:デフォルトの名無しさん
24/04/02 21:20:14.32 +5bQ5ala.net
>>518
NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね
間違いなく日本も追随することになる
533:デフォルトの名無しさん
24/04/02 21:56:04.08 mnREx4SD.net
Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがｗ
ONCDは健全なのかな
534:デフォルトの名無しさん
24/04/02 22:51:50.04 ZP8DsSPi.net
>>518
NASA？NSAじゃなく？
NSAはNASAじゃないぞ。
535:デフォルトの名無しさん
24/04/02 23:24:29.45 JjgiIhmH.net
ワロタ
NSAとNASAの区別もできんとはｗｗ
メッセージを出してるところが広がってトーンも厳しくなってきてるのは確か
2022/11 NSA
2023/09 CISA
2023/12 CISA+NSA,+FBI+Five Eyesの各機関
2024/02 White House(ONCD)
536:デフォルトの名無しさん
24/04/02 23:39:08.04 /KZzSXx2.net
とりあえず良いcrateが増えまくってほしいな
537:デフォルトの名無しさん
24/04/02 23:51:33.79 DOFjhDY0.net
>>524
あとは日本がどれだけ遅れるかだな
数ヶ月か、1年か、数年か、
538:デフォルトの名無しさん
24/04/02 23:57:17.27 ULMcj34Q.net
外部のお墨付きを欲しがる時点でオワっとるんよ
言語として
ここでそういう話題使って必死で盛り上げようとして
消えそうな火に風送ってるつもりかしらんけど
539:デフォルトの名無しさん
24/04/03 00:07:33.86 xB8sPKZQ.net
IT大手ライバル同士が
GAFAMからHUAWEIまで一致団結して
Rust Foundationを設立した時点で未来は確定していた
そしてRustに対抗できるライバル言語の芽が今も存在しない
540:デフォルトの名無しさん
24/04/03 05:31:15.82 SWmJ9bDO.net
>>527
話題にも上がらないよりまし
541:デフォルトの名無しさん
24/04/03 07:36:47.52 ClJR5oeK.net
Rustの代替になる思想の言語が全くそれ以降全く見ないからな。
今のところGCレスでメモリ安全に向き合った唯一の言語でねえの？
後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。
542:デフォルトの名無しさん
24/04/03 08:17:45.92 OgaFV8I4.net
>>527
欲しがってるかね？
むしろ外部が乗っかろうとしてる感じ。
543:デフォルトの名無しさん
24/04/03 08:58:53.93 7dkIXzmY.net
>>530
メモリ安全に向き合う、程度ならそれこそc++11が先駆けだろ。
過去互換性のせいで徹底できないけど。
それよりもRustはスタックフレーム指向であることに価値がある。
スタック is god, 再帰 is god.
544:デフォルトの名無しさん
24/04/03 11:38:42.38 TbyA9/um.net
>>515
まあ標準ライブラリがかなりミニマムだなぁって感じるときはある
乱数くらい用意しておいてよ…
545:デフォルトの名無しさん
24/04/03 11:38:56.67 zWYr6uc2.net
>>530
ある言語Aがあってその弱点が強烈で直したいけどすでに普及しきっている
で別の言語Bが作られる
その言語Bが普及しきっていなければ容易に弱点を変更できるので別のC言語は必要とされない
546:デフォルトの名無しさん
24/04/03 13:08:37.11 VOIzFFgw.net
>>534
>その言語Bが普及しきっていなければ容易に弱点を変更できる
これが真とは限らない
容易に変更できる場合もあればそうでない場合もある
547:デフォルトの名無しさん
24/04/03 13:33:20.93 7LWlVk3J.net
Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか
wikipedia
> 2015年に1.0版がリリースされるまでにいくつもの破壊的な仕様変更があったが、1.0版以降は基本的には後方互換を保って6週間間隔で定期的にリリースされている。
548:デフォルトの名無しさん
24/04/03 21:45:24.20 ClJR5oeK.net
GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。
549:デフォルトの名無しさん
24/04/03 22:40:40.78 7LWlVk3J.net
後発言語？？？
550:デフォルトの名無しさん
24/04/04 03:50:23.61 6dtGhNgR.net
>>537
所有権は最終的にはプログラム間の境界の問題になるから、c++のスマートポインタのようにアダプタで管理範囲を調整することで改善可能。
適切なアダプタを用意しても境界のプロトコルをどうやって徹底するかという問題は残るから、Rustみたいに言語レベルで強制できると頑強になる。
ただ、Rustみたいにガチガチにすると設計の柔軟性を失うから、実装も早すぎる最適化になりがち。Rustの絶壁の学習曲線と相まって、開発初期のRust導入はプロジェクトを破綻させる要因となりうる。Rustが適しているのは、ある程度枯れた設計の実装を置き換えるようなプロジェクトかと。
551:デフォルトの名無しさん
24/04/04 04:13:47.93 KZy/sIny.net
Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ
とりあえず動くように雑に書いて動かしてみて
次に機能追加充実させる上で整理しながらモジュール化や共通事項のtrait化など
このようなリファクタリング過程で
他の言語だとメモリ安全性だけでなく書き換え競合やヌル値エラー値取り扱いミスなどエンバグすることも多いが
Rustではコンパイル通せばそれらの心配がなくリファクタリングできる
552:デフォルトの名無しさん
24/04/04 08:02:04.20 KuogGH/c.net
そもそもGC無しの言語ってニッチじゃない？
当面は、Rustで充足されて安泰な気がする。
553:デフォルトの名無しさん
24/04/04 08:06:01.77 wZ/e8tnl.net
うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。
関数型言語にも良いのあるけど、普及しなさそうだしね…。
（OCamlとか次世代HaskellらしいIdrisとか）
それにCとアセンブラしかない分野（C++不可なくらい低スペックな組み込み）でC++以降のモダンな言語が使えるのは大きい。
554:デフォルトの名無しさん
24/04/04 08:41:03.15 VIrJEXhK.net
学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど
メモリの動作モデルをそこそこちゃんと仕様にしてるのは C/C++ しかないんだよね。
LLVM が C/C++ を前提にしてるところもあるし、
Rust もそれに合わせる形になってるところもある。
C/C++ 的な分野をよりよくやる言語と考えると Rust はとても良い。
555:デフォルトの名無しさん
24/04/04 12:25:37.65 Gnl54rZ8.net
すまんが↓これが動く理由を教えて欲しいんだけどさあ
URLﾘﾝｸ(paiza.io)
一見すると5行目で所有権が失われて、6行目で使ってるように見えるんだけど・・・・
これって5行目が借用に推定されてるの？
それともリテラルを引数にした場合だと5行目で「1」が他のスタックにコピーされて、所有権が失われる問題なんか起きないのかな？
へるぷみい
556:デフォルトの名無しさん
24/04/04 12:36:31.67 xh1kANkn.net
マクロだからセーフ
557:デフォルトの名無しさん
24/04/04 12:40:39.97 yz59nStO.net
>>544
値とその所有権が複製されて関数fに渡される分とそのまま残る分の2つになる
558:デフォルトの名無しさん
24/04/04 12:49:08.15 w8P1RFve.net
値が複製されて、複製された値の所有権が関数fに渡るだな。
所有権の複製とかいうクソワードは避けてくれ。
559:デフォルトの名無しさん
24/04/04 14:09:00.66 VIrJEXhK.net
>>544
i32 は Copy トレイトが実装されてる。
普通なら所有権の移動になる文脈で暗黙に clone されると思ったら良い。
560:デフォルトの名無しさん
24/04/04 14:21:30.05 Gnl54rZ8.net
そう言うことなのか、ありがとう！
理由が分からなかったから不気味だったぜ
561:デフォルトの名無しさん
24/04/04 15:21:14.87 AF0jRQyM.net
>>547
>値が複製されて、複製された値の所有権が関数fに渡るだな。
複製された値の所有権は最初から関数fのスコープの中で発生するものなので
「関数f」に渡るという表現には少し違和感を感じる
562:デフォルトの名無しさん
24/04/04 15:34:13.46 1vyOHDUL.net
「違和感を感じる」という表現に違和感を感じる
563:デフォルトの名無しさん
24/04/04 18:59:50.97 mbQWc9lN.net
>>551
滑ってるぞ
564:デフォルトの名無しさん
24/04/04 19:04:00.82 mNkWQBjH.net
感じてるから違和「感」だからね
要は頭痛が痛いと同じ
565:デフォルトの名無しさん
24/04/04 19:08:09.03 v0TcrcAn.net
違和感がある。これでどうだ
566:デフォルトの名無しさん
24/04/04 19:17:51.63 v7LceGlx.net
>>553
感じるを感じるメタ表現だろ。
ポインタのポインタみたいなもんだ。
567:デフォルトの名無しさん
24/04/04 20:07:49.07 xDxHg+AD.net
>>542
embedded 対応アーキ少なくね？
568:デフォルトの名無しさん
24/04/04 23:05:07.77 94OMF7T7.net
>>553
「違和感を感じる」は「頭痛が痛い」とは違って重言ではないよ
URLﾘﾝｸ(togetter.com)
URLﾘﾝｸ(www.nhk.or.jp)
569:デフォルトの名無しさん
24/04/04 23:18:56.70 94OMF7T7.net
>>557
重言ではあるけど間違った日本語ではない
といったほうがよかったね
570:デフォルトの名無しさん
24/04/05 00:09:35.95 Lw8p7kTG.net
>>556
少ないね。
でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。
それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。
571:デフォルトの名無しさん
24/04/05 00:21:09.11 dub3Z8tI.net
後発言語？
572:デフォルトの名無しさん
24/04/05 00:50:16.55 Lw8p7kTG.net
少し前まで次世代言語と言われてた程度には後発。
鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。
むしろ崩し始めることすら無理だと思ってた。
573:デフォルトの名無しさん
24/04/05 05:07:52.53 CPVE6BHF.net
>>559
状況も追い風なのかもね。
二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。
先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな？
574:デフォルトの名無しさん
24/04/05 08:11:28.72 Lw8p7kTG.net
Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性の
575:ための知見は役立つ。 複数言語使えますってだけでもアピールになるしね。 Rustは多分仕事自体はまだ多くない。 これからアピールして増やしていく感じなので、両方使えてた方がいい。
576:デフォルトの名無しさん
24/04/06 22:48:03.64 4i1Gvjc8.net
rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ
577:デフォルトの名無しさん
24/04/06 23:06:32.76 7kpWL/Du.net
Rustが実用的になったのは2020年
それ以降の新規案件はRustになっている
578:デフォルトの名無しさん
24/04/07 01:26:10.29 Hmt7T+4v.net
Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前
579:デフォルトの名無しさん
24/04/07 10:55:29.15 QD1FKAnH.net
絶壁の学習曲線。
貧弱なライブラリと人材。
早すぎる最適化。
しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。
580:デフォルトの名無しさん
24/04/07 14:17:46.28 vzw88H1n.net
P系言語の糞思考に染まっていない初心者こそ
最初にRustを学ぶべき
581:デフォルトの名無しさん
24/04/07 18:04:59.36 Sj2oLPpI.net
>>567
移植なんて無駄な作業はどの言語間でも行われることが少なく
582:デフォルトの名無しさん
24/04/07 18:05:33.79 nD4MmBKu.net
初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか
583:デフォルトの名無しさん
24/04/07 18:09:00.76 Sj2oLPpI.net
>>567
移植なんて無駄な作業はどの言語間でも行われることが少なく
通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる
Rustでも同様でほとんどがそれら含む新たな案件
584:デフォルトの名無しさん
24/04/07 18:16:09.73 TV6Dkj8m.net
>>567
早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ
そしてRustを叩きたいためにウソを散りばめる
585:デフォルトの名無しさん
24/04/08 02:24:45.08 BHlkyWwA.net
>>567
貧弱なライブラリとかエアプかよ
そしてRustを叩きたいためにウソを散りばめる
586:デフォルトの名無しさん
24/04/08 03:09:59.48 BqmMXmQi.net
単なる感想を必死にウソ扱いして何がしたいんだコイツw
587:デフォルトの名無しさん
24/04/08 11:48:22.86 hzcejt90.net
ライブラリはPythonと比べると流石に貧弱
特に数値計算とか物理・機械学習系
簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している
もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない
588:デフォルトの名無しさん
24/04/08 12:32:47.46 64QjhTLf.net
>>575
キチガイアンチ
すべての分野でライブラリが充実している言語は存在しない
ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前
そういう無意味なことをして叩いて楽しいか？
589:デフォルトの名無しさん
24/04/08 13:16:14.61 JoalanBl.net
>>576
貧弱なことを指摘するのは叩きではない
俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ
590:デフォルトの名無しさん
24/04/08 14:02:16.22 7wfBslr8.net
>>576
そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。
591:デフォルトの名無しさん
24/04/08 14:10:54.87 7wfBslr8.net
>>570
絶壁の学習曲線だから無理だろ。
moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない？
592:デフォルトの名無しさん
24/04/08 14:43:36.67 IC0NBj1d.net
Crypto分野はRustが他言語よりも充実してるかもね
593:デフォルトの名無しさん
24/04/08 15:06:06.34 rjHvzTUw.net
ライブラリの多さってイコールでユーザの多さなんだよ
更にいうとその言語開発者の意欲の表れでもある
ライブラリが少ないという事はユーザが少ない
更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね
594:デフォルトの名無しさん
24/04/08 15:43:54.88 JoalanBl.net
いやまあ数はあるんよ数は
意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな
資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う
595:デフォルトの名無しさん
24/04/08 16:39:42.51 9qnuy4NE.net
てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。
そんなんで数値計算ライブラリが入るわけがない。
596:デフォルトの名無しさん
24/04/08 17:11:27.78 7wfBslr8.net
初心者向けのSimplified Rustと、
c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。
Safe Rustじゃ難しそうだし。
597:デフォルトの名無しさん
24/04/08 17:54:43.90 JoalanBl.net
ゼロからプログラム書くならSafe rustが一番簡単だよ
こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける
まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが
598:デフォルトの名無しさん
24/04/08 19:05:28.67 ifgKIXku.net
C++を完全に理解した者のための言語それがRust
故に誰も
599:デフォルトの名無しさん
24/04/08 20:39:36.28 cqL1RV99.net
C++を使ったことないけど
Rustで困ったことないな
Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな
所有権は単なるヒープ解放責任だから大したことではない
所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話
非常にシンプル
600:デフォルトの名無しさん
24/04/08 21:02:11.65 YkdU7kgc.net
所有権を複製するとか間違った事を言い続けてる人が良く言うわw
601:デフォルトの名無しさん
24/04/09 00:09:53.71 pItuq1gX.net
>>588
それは俺じゃないぞ
602:デフォルトの名無しさん
24/04/09 02:45:12.09 hsAXyuRl.net
>>589
誰だよお前。
603:デフォルトの名無しさん
24/04/09 09:16:17.69 OXfvzIgi.net
今のところ>>458が一番面白い
604:デフォルトの名無しさん
24/04/09 10:16:36.65 Po0ZJOeT.net
昭和ギャグ？
ちょっと意味がわかりません
605:デフォルトの名無しさん
24/04/09 11:01:29.74 cj+QXWpg.net
今どきイジりを面白いとか、イジメ肯定派かよ。
606:デフォルトの名無しさん
24/04/09 13:18:19.32 9AcR/8+u.net
進化論肯定派じゃないの
人を淘汰することを志している
607:デフォルトの名無しさん
24/04/09 17:18:23.86 +rnauHt3.net
ｶﾁｮｰ「???」じゃなくて
ｶﾁｮｰ「で?」なら共感できたかも
608:デフォルトの名無しさん
24/04/10 01:14:02.81 /k7xUJZy.net
rustだいぶ分かってきたつもりだけど
ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理
好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる
609:デフォルトの名無しさん
24/04/10 08:03:56.89 ltqciZ07.net
>>592
進捗報告相手が課長というのが昭和かもな
そんな会社で働きたくない
610:デフォルトの名無しさん
24/04/10 11:01:40.54 5Js//1cu.net
>>596
moonbit くらいならどうかな？
611:デフォルトの名無しさん
24/04/10 11:35:35.51 AS+TZoYk.net
>>596
それぞれ理解していれば組み合わさって困ることはないんじゃないかな
Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど
612:デフォルトの名無しさん
24/04/10 16:55:22.63 yZA7mDLP.net
Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか？めんどいんですけど
613:デフォルトの名無しさん
24/04/10 17:30:31.18 Fk7YBwaR.net
メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。
614:デフォルトの名無しさん
24/04/10 17:38:51.91 t7JkSWKp.net
self/ mut self/&self/&mut selfの区別もいるしな
self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では
615:デフォルトの名無しさん
24/04/10 17:52:25.08 5Js//1cu.net
C++ の ref-qualifier とか無理のある文法だもんな。
そこに書くんか!? という変な驚きがある。
引数の一種ということにしたほうがかなり単純でよい。
実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された｡ (deducing this)
616:デフォルトの名無しさん
24/04/10 17:58:48.34 Q64PiueS.net
RustでPython実装すりゃ良いんじゃね
617:デフォルトの名無しさん
24/04/10 18:34:01.75 3h5gXXiJ.net
>>602
普通に全部ダサいんだよなあ
何とかならなかったのかとならなかったのかとならなかったのかと…
618:デフォルトの名無しさん
24/04/10 19:34:40.80 8DE+tVvz.net
selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか
619:デフォルトの名無しさん
24/04/10 19:44:04.66 y0DX5npz.net
ぜひとも >>605 の考える最高にイケてる構文を教えてほしい
Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし
620:デフォルトの名無しさん
24/04/10 19:47:55.68 IjfZ+vUr.net
>>605
nimの関数呼び出しルール
関数名(第一引数,第二引数...)
第一引数.関数名(第二引数...)
で第一引数がself相当
が一番スマートかと。
621:デフォルトの名無しさん
24/04/10 20:06:03.20 AS+TZoYk.net
>>605
むしろ>>602はそれらの区別のためにもselfは必須と言ってるようにみえる
さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい
現状のRustの仕様がベストかな
622:デフォルトの名無しさん
24/04/10 21:28:15.02 8DE+tVvz.net
selfじゃくてthisならC++マニアも納得
623:デフォルトの名無しさん
24/04/10 21:34:35.54 6SjCdg5T.net
>>608
nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね
Vec::push(&mut vec, 123);
(&mut vec).push(123);
vec.push(123);
この&mutを省略できてRust便利
624:デフォルトの名無しさん
24/04/10 21:37:52.75 Mpv09JwO.net
thisはたまにselfの代理で使われてるな
Rc::into_innerとか
625:デフォルトの名無しさん
24/04/10 23:19:28.12 AS+TZoYk.net
deref後のinto_inner適用と区別のため
敢えてself使わないことでメソッド呼び出し形式をできなくして
明示的にRc::into_inner呼び出しさせるパターンだね
626:デフォルトの名無しさん
24/04/10 23:45:41.84 Fk7YBwaR.net
メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は
LISP 用に作られたオブジェクトシステム new flavors でやってた。
627:デフォルトの名無しさん
24/04/11 02:11:03.37 4f6XcC0j.net
それは同一視というか構文が1つしかないだけでは
628:デフォルトの名無しさん
24/04/11 02:14:15.06 7FNbL3Xb.net
呼び出し時には与えない引数って紛らわしくね？
629:614
24/04/11 02:45:03.24 C4qhk0zm.net
>>615
メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。
new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど
new flavors で改良 (かどうかわからんけど) された。
630:デフォルトの名無しさん
24/04/11 04:57:52.23 r6y9Ju0a.net
>>616
むしろ逆かな
target.method(arg1,
631:arg2, ...)という targetへのメソッドコールを実現するのを関数で表すと method(target, arg1, arg2, ...)とする言語が多い Rustでも同じでこのtargetをselfと書く targetは送る側から見た視点 selfは受け取った側から見た視点 各実装は受け取った側でなされるためself
632:デフォルトの名無しさん
24/04/11 08:24:38.80 McLA6Ner.net
UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな
レシーバとして扱われるなら構文上も特別であってほしい
633:デフォルトの名無しさん
24/04/11 08:39:59.21 UjbgXeUt.net
>>619
何が気持ち悪いのかさっぱりわからない
まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね？
次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね？
ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
634:デフォルトの名無しさん
24/04/11 08:49:57.16 azFLg2co.net
言うほどほとんどの言語がこれか？
pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ
これがPythonいまいちだなって思うところ
c++も似た様な理由でstaticでthis
後発で考慮する余裕あるのにそれを引っ張ってる
635:デフォルトの名無しさん
24/04/11 09:02:17.34 NXydgA7G.net
>>621
君の感性がおかしいんじゃね？
NimもZigもRustもPythonと同じ標準方式
foo(receiver, arg1, arg2, ..)
または
receiver.foo(arg1, arg2, ..)
636:デフォルトの名無しさん
24/04/11 09:02:43.98 7FNbL3Xb.net
>>618
なるほどちょっと納得した
637:デフォルトの名無しさん
24/04/11 09:11:33.28 azFLg2co.net
>>622
実質Pythonフォロワーを含めて言われても…
638:デフォルトの名無しさん
24/04/11 09:14:09.83 azFLg2co.net
C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた
それがOOP言語になって指定不要になった
それがまたC言語時代に逆戻り
639:デフォルトの名無しさん
24/04/11 09:15:22.73 NXydgA7G.net
>>624
何を言ってるのかわからん
文句を言うなら望ましい代案を出してみて
640:デフォルトの名無しさん
24/04/11 09:17:05.47 azFLg2co.net
あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは
receiverがNullの可能性がある場合でそう設計されてただけ
641:デフォルトの名無しさん
24/04/11 09:20:43.92 NXydgA7G.net
代案を出せないってことはRustに言いがかりをつけてるだけだな
642:デフォルトの名無しさん
24/04/11 09:24:05.56 azFLg2co.net
別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ
その表記は時間をかけて考えたらいい
643:デフォルトの名無しさん
24/04/11 09:30:34.30 cvuvfjXO.net
>>625
レシーバは必ず必要
Goでも
func (receiver ReceiverType) Foo(引数…) {
return receiver.xxx + receiver.yyy
}
と書く
レシーバ指定不要という主張は理解できない
644:デフォルトの名無しさん
24/04/11 09:45:56.75 gYo8nOa5.net
レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな
selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい
645:デフォルトの名無しさん
24/04/11 09:51:28.66 azFLg2co.net
いやいやｗ
無知って怖いねとしか…
646:デフォルトの名無しさん
24/04/11 09:52:17.20 azFLg2co.net
>>630
647:デフォルトの名無しさん
24/04/11 10:19:57.47 UmgPKlgb.net
UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの
>>619はそれを分かった上でNimについて書いてるのかもしれないけど>>620や>>622は明らかに誤解してる
648:デフォルトの名無しさん
24/04/11 10:33:59.60 Nlu6ipA3.net
>>631
そう言われるとRustの仕様がベストなのかな
レシーバに名前を付けないと名前空間の分離ができなくて
レシーバに名前を自由に付けられると読みづらくて
649:デフォルトの名無しさん
24/04/11 11:00:57.82 azFLg2co.net
IDころころお爺さんは明らかに話を理解できないな
650:デフォルトの名無しさん
24/04/11 11:23:46.71 CaCoKmZ3.net
Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな
型指定にSelfやSelf::Itemなど使えるだけでなく
Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる
Selfによって自分自身であるとわかりコードが読みやすい
型名変更の影響も受けず読みやすいメンテしやすい
ダメな言語だと以下のダメなパターンがある
・Selfの代わりに型名を書かなくてはいけない言語 (自分自身だとわかりにくくメンテ性も悪い)
・Selfの代わりにself(やthis)を用いてしまう言語 (値と型の区別がつかない)
・Selfを使わずに名前空間の区別がない言語 (間違いが起きやすく自分自身だとわかりくくメンテ性が悪い)
651:デフォルトの名無しさん
24/04/11 11:57:27.19 17a5lmDN.net
関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな……
652:デフォルトの名無しさん
24/04/11 11:57:34.08 6x2Zth+c.net
複オジは見えてる範囲が狭過ぎる
だから長文になればなるほど勘違い度や害悪度が高まる
653:デフォルトの名無しさん
24/04/11 12:47:47.10 ZruVErXu.net
自分が使ってきた特殊な仕様の言語に慣れ親しんでいると
一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない
Rustを叩く前に視野を広く持つべきだな
Rustの仕様はよく考えられ機能的に洗練されている
654:デフォルトの名無しさん
24/04/11 12:59:00.66 AZdBjU6j.net
>>640
Rustに無いからといってUFCS叩くのはさすがにアホかと。
655:デフォルトの名無しさん
24/04/11 13:15:55.80 4f6XcC0j.net
そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん
656:デフォルトの名無しさん
24/04/11 15:57:20.01 R8LZpbjl.net
>>642
エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない
657:デフォルトの名無しさん
24/04/11 15:59:23.14 v1XXdeLJ.net
くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い
658:デフォルトの名無しさん
24/04/11 16:41:03.54 KhnNkcJ8.net
まともな質問にいつものノリで適当に答えて嘘だったら良くないしね
659:デフォルトの名無しさん
24/04/11 17:01:08.25 TWMZ6q+3.net
そっか
俺の答えも間違ってたしな
正しくはdowncastのために必要らしい
詳しくはfix_errorのRFC見て
660:デフォルトの名無しさん
24/04/11 17:41:58.72 McIjmFt1.net
Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環？
661:デフォルトの名無しさん
24/04/11 17:48:38.15 McIjmFt1.net
動き出した
サーバー側の問題っぽいな
URLﾘﾝｸ(github.com)
662:デフォルトの名無しさん
24/04/11 18:55:11.06 4f6XcC0j.net
downcastなんて別にしないからいらねーよって思ったけど
そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか
ヒントありがとう
663:デフォルトの名無しさん
24/04/11 19:06:32.42 VFM//2+p.net
複おじはc++も使ってなかったんだな
664:デフォルトの名無しさん
24/04/11 20:25:23.50 81s1BzdD.net
>>641
UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。
Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。
665:デフォルトの名無しさん
24/04/11 20:52:12.80 AZdBjU6j.net
>>651
UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。
それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。
666:デフォルトの名無しさん
24/04/11 21:02:41.98 81s1BzdD.net
>>652
Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。
そのためUFCSのような愚かな方式を採る必要がない。
667:デフォルトの名無しさん
24/04/11 21:15:01.99 mF0oHAZm.net
答えを教えてもらっているのにヒントありがとうというオジさんw
668:デフォルトの名無しさん
24/04/11 21:16:29.71 2g+gCFiF.net
メソッド名空間www
669:デフォルトの名無しさん
24/04/11 21:54:13.50 AZdBjU6j.net
>>653
それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。
もっとUFCSならではの問題点を指摘してくれ。
せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。
670:デフォルトの名無しさん
24/04/11 23:54:23.85 A4VQpdsZ.net
アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ
アラビア語おすすめ
671:デフォルトの名無しさん
24/04/12 00:40:05.77 fvGN/jjJ.net
>>656
それはメソッド呼び出しのメリット
モジュール化や結合の観点からも最初からメソッド定義していくのが正しい
UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる
具体的には歴史的な負の遺産でボロボロなC++が該当する
そのためC++ではUFCSを導入しようと今も悪あがきをしている
ほとんどの言語にUFCSがないのはそんなものを必要としないためだ
672:デフォルトの名無しさん
24/04/12 00:44:02.94 tVNhffJ+.net
モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい
673:デフォルトの名無しさん
24/04/12 02:47:17.34 DYhqcHWh.net
それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない
AddAssignやSubやShlなど多くの演算は非対称
674:デフォルトの名無しさん
24/04/12 04:21:38.21 tVNhffJ+.net
いや別にSubでもDivでも左のみに紐づいているのはキモい
675:デフォルトの名無しさん
24/04/12 04:49:28.47 rUQyilnM.net
>>658
やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。
例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ？
グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。
676:デフォルトの名無しさん
24/04/12 05:26:42.25 CIaMPOtu.net
>>662
トレイルではなくトレイト
トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ
677:デフォルトの名無しさん
24/04/12 07:31:40.11 rUQyilnM.net
>>663
だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。
678:デフォルトの名無しさん
24/04/12 12:27:40.08 OadUyd3M.net
>>659
＞モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
同意
679:デフォルトの名無しさん
24/04/12 12:33:34.40 rAepnpk2.net
>>664
Rustはそうやってきちんと管理できつつ便利でいいよなー
他の言語も導入すればいいのに
680:デフォルトの名無しさん
24/04/12 12:43:39.99 6xQx5uEa.net
>>665
オブジェクト指向を全否定するキチガイか
クラスのある言語もクラスのないGoやRustなどの言語も
一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
681:デフォルトの名無しさん
24/04/12 13:04:32.76 qd6Rxygz.net
とりあえず感覚で一行目から罵倒する人
682:デフォルトの名無しさん
24/04/12 15:24:23.71 XC+pkKeZ.net
>>667
>一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
オブジェクト指向前提思考？
683:デフォルトの名無しさん
24/04/12 16:22:22.83 RDQRwL9V.net
>ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
からの
>UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
schizoかな？
684:デフォルトの名無しさん
24/04/12 17:02:05.38 oSrgtnnN.net
それらの件でもRustの仕様が優秀すぎ
685:デフォルトの名無しさん
24/04/12 20:51:13.79 NYkXEvAJ.net
>>670
虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ
686:デフォルトの名無しさん
24/04/12 22:18:23.28 HgYc1X5O.net
おじいちゃんは昼だけ起きてて
夕方を過ぎると寝てしまう
687:デフォルトの名無しさん
24/04/12 22:50:23.70 3nYhUDoK.net
RUSTがトレンドに！！
688:デフォルトの名無しさん
24/04/12 23:58:18.71 lpyrPPhz.net
>>667
つジェネリック
689:デフォルトの名無しさん
24/04/13 04:39:15.20 0YGiYUZr.net
ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか
690:デフォルトの名無しさん
24/04/13 07:36:48.57 beXAxXwF.net
トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ？
柔軟性のために外延性は欲しいところ。
691:デフォルトの名無しさん
24/04/13 08:07:59.96 S51MIqUj.net
異なる型間の共通項をトレイトとして切り出すだけでよく
コードを美しく整理して保守性を高めやすい
692:デフォルトの名無しさん
24/04/13 13:32:34.24 OrtqC7Lq.net
敬称ないせいで苦労してるんだってな
693:デフォルトの名無しさん
24/04/13 13:36:34.54 F3jinTSj.net
143 デフォルトの名無しさん 2024/04/07(日) 19:27
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない
それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
694:デフォルトの名無しさん
24/04/13 16:56:52.49 L60jXWVE.net
継承がなくても構造体にメソッドついてたら実質クラスだろ
関数に構造体渡してたらそれはクラスじゃないけど
695:デフォルトの名無しさん
24/04/14 23:56:10.96 RjsA2T1t.net
>>681
構造体にメソッドが付くことはカプセル化と言う
クラス＝カプセル化＋実装継承 なのでクラスとカプセル化は異なる
このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった
実装継承とは具体型が別の具体型を継承することを指す
クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる
正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する
つまりクラスを完全に排除できるためモダンな言語群にクラスはない
696:デフォルトの名無しさん
24/04/15 00:05:55.58 R9iMDmBn.net
用語も色々。
Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、
JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。
極論すればクラスと名付けたものがクラス。
Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。
C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、
クラスとは何かを定義せずにクラスかどうかを論じても無意味。
697:デフォルトの名無しさん
24/04/15 00:26:07.32 rd9697wK.net
型クラスとクラスは全く異なるので混乱しない
クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す
JavaScriptはプロトタイプを親として実装継承するためクラス
一方でRustにクラスはない
698:デフォルトの名無しさん
24/04/15 01:47:00.44 YLFAz6O4.net
クラスとは何か？継承とは何か？
こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい
>>681が一番まとも
699:デフォルトの名無しさん
24/04/15 01:58:25.85 CPtYka/u.net
話は非常に単純
具体的な型から具体的な型への継承が実装継承でこれがよくない
classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承
interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない
最近の言語がclassのみ採用しなかった理由はその違い
700:デフォルトの名無しさん
24/04/15 02:39:20.65 zOelqs9y.net
RustにはJavaのクラスはありません
RustはJavaではないからです
あたまいいね
701:デフォルトの名無しさん
24/04/15 03:16:04.95 0QcDOjSQ.net
Javaの生みの親であるJames Goslingも、
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」に対して、
「クラスを除外するでしょうね」と答えている。
その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。
702:デフォルトの名無しさん
24/04/15 08:31:26.40 Mqs/ngjj.net
クラスのようなものでいいよ
703:デフォルトの名無しさん
24/04/15 10:16:50.96 dcBtWsLv.net
バカの一つ覚えの相手をしても時間の無駄
704:デフォルトの名無しさん
24/04/15 12:54:52.68 f4iHJAq/.net
クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな
705:デフォルトの名無しさん
24/04/15 21:09:43.00 97bFGSba.net
それは単に使い分けが出来ない馬鹿な子向けの説明だぞ
706:デフォルトの名無しさん
24/04/16 07:27:41.72 10PaZXAR.net
>>691
言語仕様としてあった方が良いということ。
707:デフォルトの名無しさん
24/04/16 07:42:24.51 KU96szRc.net
馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ
708:デフォルトの名無しさん
24/04/16 08:43:42.78 OvO8gS8m.net
Javaの生みの親も言ってるようにクラス継承の機能はない方がいい
なくても困らない
あると問題を引き起こす
709:デフォルトの名無しさん
24/04/16 09:30:25.53 YlYBNC7y.net
そういうのは話半分に聞いておけばいいよ
nullを使ったのは失敗だったとか
後からそれらしいことを言ってるだけ
javaはクラスと継承が無くなったらまともに機能しない
interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず
710:デフォルトの名無しさん
24/04/16 09:50:49.42 pgei3+18.net
>>696
interfaceにデフォルト実装を後から入れたので問題なくなった
そうなるとclass継承は不要
711:デフォルトの名無しさん
24/04/16 09:55:41.24 YlYBNC7y.net
最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから
今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって
後から○○無くせばよかったと言うのは誤りで浅はか
NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ
712:デフォルトの名無しさん
24/04/16 10:21:05.77 pgei3+18.net
今となってはclass継承は廃止でいい
713:デフォルトの名無しさん
24/04/16 11:59:36.87 NkOUpCFP.net
インターフェイスにも集合で言うところの外延性は欲しいところ。
714:デフォルトの名無しさん
24/04/16 13:49:22.28 DzgCvS5T.net
そういうの使いたいならTSがいいよ
715:デフォルトの名無しさん
24/04/16 14:56:34.55 vP0l1V0c.net
具体的なデメリットって何なの？
716:デフォルトの名無しさん
24/04/16 15:29:25.10 ePcpSD5e.net
ダサい
717:デフォルトの名無しさん
24/04/16 20:4
718:5:11.55 ID:scEyspJl.net
719:デフォルトの名無しさん
24/04/16 22:20:54.32 pbIQ4i0L.net
基底クラスで保証してる内部条件を継承クラスで壊されやすい
Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど
C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う
古い知識だから最近の動向は知らない
720:デフォルトの名無しさん
24/04/17 08:15:23.25 eua5YI/M.net
Unreal EngineがRist対応するんだってね
721:デフォルトの名無しさん
24/04/17 16:42:11.69 eua5YI/M.net
Ristってなんだ、Rustだた
722:デフォルトの名無しさん
24/04/17 21:06:33.89 ZcFRYo3q.net
Rast
Rist
Rest
Rost
723:デフォルトの名無しさん
24/04/17 21:31:42.40 O0zLY4aF.net
Risp
724:デフォルトの名無しさん
24/04/18 23:48:18.11 mul2o/Jt.net
>>706
時代の流れだな
725:デフォルトの名無しさん
24/04/19 17:19:41.25 QdSz4ItG.net
隙間作って床下チェスト収納ってできなくなった？動画みてるけどうまくできん
726:デフォルトの名無しさん
24/04/20 17:39:26.03 pCmD4UWo.net
shift-jiｓのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない
全部読んでデコードして\nで切り分けるしかないの？
727:デフォルトの名無しさん
24/04/20 17:53:01.46 AAPU1iqE.net
read_lineはutf-8じゃないと無理だけどread_untilならバイト列で１行ずつ取れそう
728:デフォルトの名無しさん
24/04/20 22:11:31.95 pZNdwQSZ.net
>>712
encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る
あとはreader.lines()で同じ
729:デフォルトの名無しさん
24/04/20 22:28:20.55 pZNdwQSZ.net
std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines()
730:デフォルトの名無しさん
24/04/21 07:15:48.69 QKVewSeW.net
BufReaderもFile::openもそのまま使える点がいいね