Rust part23

**デフォルトの名無しさん** · 2024/02/23(金) 17:37:52.13

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/03/28(木) 07:44:09.91

>>409
公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。

>>411
拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？

**デフォルトの名無しさん** · 2024/03/28(木) 08:15:17.48

rustもいろいろ問題を抱えてるんだね
プログラマの習熟が必要だっていうなら流行らないだろう
メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし
新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう

**デフォルトの名無しさん** · 2024/03/28(木) 08:34:31.08

>>412
こう書くだけでunsafeの使用が禁止されます
#![forbid(unsafe_code)]

>>413
普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません

**デフォルトの名無しさん** · 2024/03/28(木) 08:48:28.49

>>414
>411みたいなマキャベリガイジが混ざると破綻しますな。
MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。

**デフォルトの名無しさん** · 2024/03/28(木) 09:00:19.29

>>415
これでunsafeが使用禁止となり安全なsafe Rustになる
#![forbid(unsafe_code)]
コンパイラがunsafeをエラーとして弾く

**デフォルトの名無しさん** · 2024/03/28(木) 10:37:24.50

結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな

**デフォルトの名無しさん** · 2024/03/28(木) 14:03:58.90

まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。

**デフォルトの名無しさん** · 2024/03/28(木) 17:41:01.08

unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者
一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる

もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、
その部分だけを切り出してライブラリ作成者になれる
それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない

**デフォルトの名無しさん** · 2024/03/28(木) 18:27:15.03

>>419
そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。

Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。

**デフォルトの名無しさん** · 2024/03/28(木) 18:35:39.73

unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが
このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう

でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ

**デフォルトの名無しさん** · 2024/03/28(木) 18:56:54.80

必要な各企業、各プロジェクトなどで義務付け
#![forbid(unsafe_code)]
これでunsafeの話はおしまい

他の言語と比べてRustはコーディング規約もAPI規約も公式で楽
Rust公式APIガイドライン
https://rust-lang.github.io/api-guidelines/

**デフォルトの名無しさん** · 2024/03/28(木) 19:45:10.84

>>422
公式のドキュメントで
#![forbid(unsafe_code)]
の説明を探しているんだけど、どこにあるのかしらん？
doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
の１行でおしまい？

**デフォルトの名無しさん** · 2024/03/28(木) 20:08:10.91

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

**デフォルトの名無しさん** · 2024/03/28(木) 21:59:19.02

Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。

**デフォルトの名無しさん** · 2024/03/28(木) 22:34:58.42

どの開発でも
#![forbid(unsafe_code)]が原則

どうしてもunsafeが必要なら
その安全ロジックを関係者で協議後に
#![deny(unsafe_code)]へそのモジュールのみ変更し
許可する部分のみを
#![allow(unsafe_code)]として監視対象
といった感じが一般的かと

監視対象を極一部に限定できて
全体はコンパイラにより保証できるため
他のプログラミング言語より扱いやすい

**デフォルトの名無しさん** · 2024/03/28(木) 22:41:56.41

>>420
一般とそうでない奴は誰がどうやって区別するのさ？

**デフォルトの名無しさん** · 2024/03/28(木) 22:42:31.88

>>421
正解

**デフォルトの名無しさん** · 2024/03/28(木) 23:58:52.21

時間がない時はunsafe使っていいよ

**デフォルトの名無しさん** · 2024/03/29(金) 00:05:51.94

時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう

**デフォルトの名無しさん** · 2024/03/29(金) 00:19:58.75

>>429
safeで書くのが早くて楽で安全
わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない

**デフォルトの名無しさん** · 2024/03/29(金) 00:24:32.79

>>430
unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる
safe Rustが楽で早く書けて安全

**デフォルトの名無しさん** · 2024/03/29(金) 01:57:50.63

壊れたレコードオジ怖い

**デフォルトの名無しさん** · 2024/03/29(金) 02:36:16.29

>>432
安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？

**デフォルトの名無しさん** · 2024/03/29(金) 07:36:27.65

雑にunsafe使って早く書けるのはFFIくらいかな
FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い
pure Rustでunsafeの方が早いケースはちょっと思いつかないな

**デフォルトの名無しさん** · 2024/03/29(金) 08:25:13.35

>>427
そりゃプロジェクト管理者だろ。
そもそもRust採用するメリットはソースコードの品質管理しか無いし。

デフォルトunsafe禁止は何回か話題に出てきているのな。

**デフォルトの名無しさん** · 2024/03/29(金) 08:27:22.40

>>426
それぐらいやらないとRust採用するメリット無さそうだよな。

**デフォルトの名無しさん** · 2024/03/29(金) 08:41:03.04

初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？

**デフォルトの名無しさん** · 2024/03/29(金) 09:16:34.82

そもそも普通に書いててunsafe使いたいなって場面がない
多人数で書いてるならforbidで落としてもいいけど
コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい

**デフォルトの名無しさん** · 2024/03/29(金) 09:24:57.68

>>436
じゃunsafe使うな、で済む話じゃん。

**デフォルトの名無しさん** · 2024/03/29(金) 09:49:54.05

>>440
そうだね
で？

**デフォルトの名無しさん** · 2024/03/29(金) 11:01:08.74

rustもプログラマがザコだと使いこなせない言語なんだろ？
人材確保すら苦労するってメジャーになれるのかよ

**デフォルトの名無しさん** · 2024/03/29(金) 11:23:44.57

unsafeでサッと書いたほうが出世できるぞ

**デフォルトの名無しさん** · 2024/03/29(金) 11:49:42.05

たしかにプログラムの品質がいいから出世するって見たことないわ
逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな

**デフォルトの名無しさん** · 2024/03/29(金) 11:53:12.39

unsafeは面倒
Rustで書いていてunsafeを使いたい気分になることがない
さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない

**デフォルトの名無しさん** · 2024/03/29(金) 11:54:18.08

>>442
メジャーになれなくて何か問題あるの？

**デフォルトの名無しさん** · 2024/03/29(金) 12:08:03.79

初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。

**デフォルトの名無しさん** · 2024/03/29(金) 12:08:08.24

>>440
PMやったこと無いの？
unsafe使うなと管理するより、そもそも使えない方が遥かに楽。

**デフォルトの名無しさん** · 2024/03/29(金) 12:13:58.45

>>442
C++ とかだと使いこなせてないのになんとなく動いちゃったりするから……
使えてないなら使えないほうがちょっとマシなんだよ。

**デフォルトの名無しさん** · 2024/03/29(金) 12:15:29.32

>>448
言語機能的にunsafeって書かなければそもそも使えないじゃん。

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

>>446
時間の無駄

**デフォルトの名無しさん** · 2024/03/29(金) 13:35:34.69

>>448
そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね

**デフォルトの名無しさん** · 2024/03/29(金) 16:25:54.97

unsafeでサクッと終わらせてどんどん仕事取ろうぜ
safeでチンタラやってる無能に仕事を回すな

**デフォルトの名無しさん** · 2024/03/29(金) 17:20:13.23

アンチはunsafeを使うと早く書けると誤解しているのが面白い
早くもなければ楽でもないので普通は使わない

**デフォルトの名無しさん** · 2024/03/29(金) 17:36:40.68

「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね

**デフォルトの名無しさん** · 2024/03/29(金) 17:56:14.07

このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが

**デフォルトの名無しさん** · 2024/03/29(金) 18:02:08.48

正常なコミュニケーション力を持った優秀なエンジニア
→こいつらは出世するのでプログラミングスキルは生かされない方向に進む

正常なコミュニケーション力がない優秀なエンジニア
→こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない

どうしたら優秀なエンジニア揃えられるんや…

**デフォルトの名無しさん** · 2024/03/29(金) 18:06:18.85

ｶﾁｮｰ「では進捗を報告してください」
unsafe_man「ｱﾉｰ、ﾁｮｯﾄ時間かかってｵﾘﾏｼﾃ、ｱﾝｾｰﾌが、ｿﾉｰ（怒涛の勢いで難しいことを話し続ける）」
ｶﾁｮｰ「???」

**デフォルトの名無しさん** · 2024/03/29(金) 18:22:45.54

>>457
放っておいても勝手に集まるから心配しなくていいよ
そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど

**デフォルトの名無しさん** · 2024/03/29(金) 18:29:23.69

>>459
すまん、集まってるとこの実名あげてくれんか？

**デフォルトの名無しさん** · 2024/03/29(金) 19:20:01.67

>>458
いきなり人格攻撃かよ？Rustらしいな

**デフォルトの名無しさん** · 2024/03/29(金) 19:31:34.50

NとかFとかは優秀な人がいるイメージがない

**デフォルトの名無しさん** · 2024/03/29(金) 19:54:25.38

unsafe使う機会ってほぼないよな
よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか

**デフォルトの名無しさん** · 2024/03/29(金) 19:58:01.23

優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人
でunsafeを使いこなせるかどうかなんか無関係

これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人

**デフォルトの名無しさん** · 2024/03/29(金) 19:59:06.31

システムプログラミング用途も売りにしてなかった？
Cと同等のことをしてみせようってんなら
unsafeくらい当たり前に常用するやろ？しらんけど
ボクは使いません！みたいな意見は誰も求めてないからｗ

**デフォルトの名無しさん** · 2024/03/29(金) 20:37:55.25

unsafe使うと変更する時にだるくなるからできるだけ使わない
グローバル変数使うのと同じ気分

「グローバル変数くらい当たり前に常用するやろ？しらんけど
　ボクは使いません！みたいな意見は誰も求めてないからｗ」
とか言われたら知らん

**デフォルトの名無しさん** · 2024/03/29(金) 20:41:59.79

誰にも影響及ぼさないなら勝手に使えばいい

**デフォルトの名無しさん** · 2024/03/29(金) 20:47:48.55

使う必要があるからunsafeってもんがあるんであって
使う必要がない人の意見や感想は求められてないんよ

使うべきとか使うべきじゃないとか
普通はどうとか普通はどうじゃないとか
無意味な応酬はやめよう

**デフォルトの名無しさん** · 2024/03/29(金) 21:08:57.87

コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。

**デフォルトの名無しさん** · 2024/03/29(金) 21:45:08.79

>>451
君の時間の無駄ってこと？
こんなところで毎日無駄な時間過ごしてるのに？
それって君がやらなければいいだけだよね

**デフォルトの名無しさん** · 2024/03/29(金) 21:46:36.17

>>468
一連のunsafeコントで初めてまともな意見だな

**デフォルトの名無しさん** · 2024/03/29(金) 21:52:31.85

エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで
Rustが普及する日は来るんだろうか
上の方でも言われてたけどコーダー集まらない問題に直面しそうだが

**デフォルトの名無しさん** · 2024/03/29(金) 22:06:45.92

Rustはコーダーは集まらんだろ

普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる
ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる

大手だとこれの繰り返しだがRustはそれが難しい

**デフォルトの名無しさん** · 2024/03/29(金) 22:29:09.47

意図的にどこかで誰かが資金を投入してRustコーダーを栽培（）しないと
増えるわけがない
javaやpythonじゃないんだから

野良Rustコーダーなんて存在しない
使える人間は100%C++使いなので引っ張ってこれない

**デフォルトの名無しさん** · 2024/03/29(金) 22:30:50.06

エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな

**デフォルトの名無しさん** · 2024/03/29(金) 22:35:31.54

まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう

**デフォルトの名無しさん** · 2024/03/29(金) 22:48:02.40

それよりもホントにシステムプログラミングできてんのかが興味あるわ
CからはOSならばUnixやLinuxやWindowsが生まれてきたけど
Rustからは一体どんな素晴らしいものが生まれてくるんだろうか？
Cより書きやすくて？　安全なんだよね？　期待していいんよね？

Systems programming
https://en.wikipedia.org/wiki/Systems_programming
e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications

**デフォルトの名無しさん** · 2024/03/29(金) 23:01:23.64

今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある
でも期待するのは自由だ
Rustファンはみんな期待している

**デフォルトの名無しさん** · 2024/03/29(金) 23:11:14.94

>>477
interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境（Cとアセンブラの独壇場。C++不可の世界）で組み込みRust使う記事とかあったよ。

ビジネスになるかはともかく、技術的には余裕なはず。

**デフォルトの名無しさん** · 2024/03/29(金) 23:55:56.73

既にネットインフラは次々とRust製
ソースは>>51

**デフォルトの名無しさん** · 2024/03/30(土) 00:06:31.16

>>472
Rustは仕様や周辺ツールが飛びぬけて優秀な故
JavaやPHP等他の言語と違って素人でも適当に書いても
大した問題は起こらないから「技術者の立ち位置」を守る観点で見ると
大規模開発現場で普及する事はこれからも無いよ。

**デフォルトの名無しさん** · 2024/03/30(土) 01:01:10.58

それで守られるのはITコン猿の立ち位置じゃね？
エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが

**デフォルトの名無しさん** · 2024/03/30(土) 01:46:17.09

知ってる人間は黙ってRustの恩恵を受けておけば良くて
人売りサル業界は人/月だコミュニケーションスキルだと
喚いていれば良い。

**デフォルトの名無しさん** · 2024/03/30(土) 07:28:24.91

C++が流行った経緯知ってる奴なら想像できるだろ。
C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。
でも流行ったのはC++。

**デフォルトの名無しさん** · 2024/03/30(土) 13:15:43.05

C++はわかりやすく拡張されたCだからさ
ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった

NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない
日本語の書籍がないのが一番つらかった

**デフォルトの名無しさん** · 2024/03/30(土) 20:58:56.17

当時NeXTに触れてたやつおるん？
たまげたなぁ
俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ
いつごろだったかなぁ日本語のやつあったけどなぁ
まさかmacOSで脚光浴びるとは思いもせずに

**デフォルトの名無しさん** · 2024/03/30(土) 21:08:50.38

研究室にあったんよ
当時でももう型オチででも予算無いからリプレースも出来ず
MOのデータを消しながら使ってた

古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで

自分は図書館に埋もれたModulaの本を読んでた

**デフォルトの名無しさん** · 2024/03/30(土) 21:14:51.55

羨ましい
俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ
あー羨ましい

**デフォルトの名無しさん** · 2024/03/30(土) 22:32:19.21

モーモーちゃんに入れている人は居たな

**デフォルトの名無しさん** · 2024/03/31(日) 11:42:27.74

C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。
結局は C のままでいくと判断した。
良くなるのだとしても、少なくとも一時的には大きな混乱が起こることを C++ は許容しなかった。
言語ってのはそれを取り巻くエコシステム (言語ユーザーやドキュメントも含む) と離れて成立することはないってこと。
C++ は C のツールチェインにほとんどそのまま乗っかる形で (最初は) 普及したし。

Rust はツールチェインの整備も一緒に取り組んだというのは普及の一助になったとは思うけど、
今までに作られた膨大なソフトウェア資源の最も低レイヤの部分は結局は C なんだよね。
そもそも ABI が C を基準にした仕様だったりするので
他の言語と接続するときは皆が C に合わせる形になる。

もしこれから Rust がもっと普及することがあったとしても低レイヤでは C の残滓はいつまでも消えないと思う。

**デフォルトの名無しさん** · 2024/03/31(日) 15:29:48.98

ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う

**デフォルトの名無しさん** · 2024/03/31(日) 16:44:42.12

>>490
Rustで書いたOSが大流行でもしない限りCと同じようにはならない。
ただ、Linux は Rust を取り込み始めたので何十年も掛けてゆっくり Rust 化する可能性はある。
そうなると移行したライブラリは増え続け、50年後ぐらいには今のCと同じようになっているかも知れない。
もちろんその頃には別の新言語が出てきていて Rust が時代遅れな言語になっているわけだが。

**デフォルトの名無しさん** · 2024/03/31(日) 19:15:56.54

ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない
多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する

**デフォルトの名無しさん** · 2024/03/31(日) 19:55:09.30

ABIこそ良い奴が出たら置き換えられそうだけどな
現状良い奴がないだけで

**デフォルトの名無しさん** · 2024/03/31(日) 21:03:45.67

>>493
何言ってんのwww
相変わらず無知が過ぎる

**デフォルトの名無しさん** · 2024/03/31(日) 22:06:47.20

いやまあ1%もいないんじゃない？

**デフォルトの名無しさん** · 2024/03/31(日) 23:37:37.59

そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど

**デフォルトの名無しさん** · 2024/04/01(月) 19:53:32.69

そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。

**デフォルトの名無しさん** · 2024/04/01(月) 20:06:07.63

C++より多いから問題ない

**デフォルトの名無しさん** · 2024/04/01(月) 22:56:49.63

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

**デフォルトの名無しさん** · 2024/04/02(火) 08:53:54.00

>>500
メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。

c++標準も、Safe Rust に倣って
c++ subset for safe programming
とか作ればいいのに。

**デフォルトの名無しさん** · 2024/04/02(火) 09:19:58.94

メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。

**デフォルトの名無しさん** · 2024/04/02(火) 09:39:48.87

java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。

**デフォルトの名無しさん** · 2024/04/02(火) 11:06:55.03

>>503
安全じゃ無いぞ

**デフォルトの名無しさん** · 2024/04/02(火) 14:49:37.59

>>501
C/C++はプログラム全体がunsafe空間なので難しい
safeにしようとすると全く別言語になってしまう
結局C/C++を捨てるのが正しい

**デフォルトの名無しさん** · 2024/04/02(火) 17:14:03.69

>>503
nullポイントがある時点で…
一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど，だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ

**デフォルトの名無しさん** · 2024/04/02(火) 17:14:28.23

nullポインタだ
ごめんなさい

**デフォルトの名無しさん** · 2024/04/02(火) 18:23:13.98

ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される
nullから何かを読み出して動き続けると危険

**デフォルトの名無しさん** · 2024/04/02(火) 18:43:54.77

>>508
Someである保証がある時のみunwrap()を使う
保証がないのにunwrap()する人はクビ

**デフォルトの名無しさん** · 2024/04/02(火) 18:54:06.54

メモリ安全の文脈だからそういう次元の話ではないのだが

**デフォルトの名無しさん** · 2024/04/02(火) 18:55:57.61

>>505
コーダー向けだから別言語でいいよ。

new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。
operator関数定義も禁止でいいんじゃない？

**デフォルトの名無しさん** · 2024/04/02(火) 19:03:35.75

ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね