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/02/23(金) 18:14:46.11

**デフォルトの名無しさん** · 2024/02/23(金) 18:15:20.65

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/

**デフォルトの名無しさん** · 2024/02/24(土) 14:37:44.58

前スレ終盤がRust特有の型🔵ナニー症候群の典型(この用語は出典参照)
https://mevius.5ch.net/test/read.cgi/tech/1705760500/977-

Netflixは2年かけて気が付いたけど凡人程のめり込む沼
出典
https://www.youtube.com/watch?v=6gwF8mG3UUY

Haskellの時と同様、概念だけ触れたら他の言語に活かすのが良い
長居していると症候群認定される危険性があるから

**デフォルトの名無しさん** · 2024/02/24(土) 14:48:37.96

>>4
それ何の情報もなく見ても無駄
具体的な説得力ある話がない
TypeScriptが嫌いでGoが好きらしい

**デフォルトの名無しさん** · 2024/02/24(土) 16:14:50.39

Rustから前スレ終盤の型オナニーをなくしたような言語があれば使いたいけど、ないから仕方なくRustを使っている

**デフォルトの名無しさん** · 2024/02/24(土) 16:23:38.76

静的型チェックレベルを高めつつジェネリクス等による汎化を活用しようとすれば大なり小なり型オナニーは避けられない
RustやTypeScriptだけでなくC++のtemplateやPythonの型ヒントでも同じこと

単独のTraitだけの話で型オナニーとか言ってるやつはオナニーレベルが低過ぎ
静的型チェックへの適性がないのでRustも辞めた方がいい

**デフォルトの名無しさん** · 2024/02/24(土) 16:34:30.38

型オナニーより所有権やライフタイム管理の方が面倒だけどな
それが型と絡むからさらにややこしくなる

**デフォルトの名無しさん** · 2024/02/24(土) 17:03:48.32

動的型付け言語しか慣れてない初心者が静的型付け言語に慣れるまで時間がかかるのは当たり前
GC前提言語しか慣れてない初心者がそうでない言語に慣れるまで時間がかかるのは当たり前
プログラミングに向いてる人ならどちらもすぐに慣れる
そんなことで文句を言っているようではプログラミングに向いていない

**デフォルトの名無しさん** · 2024/02/24(土) 17:13:41.82

Rustの型オナニーは「本当は1つにまとめても良いんだけど歴史的経緯で2種類あります」みたいなのが稀にあって気持ち良くない

**デフォルトの名無しさん** · 2024/02/24(土) 17:33:53.05

>>10
妄想楽しいですか？

**デフォルトの名無しさん** · 2024/02/24(土) 18:25:50.38

>>8 それRust特有だよね時間がどんどん溶ける

**デフォルトの名無しさん** · 2024/02/24(土) 18:33:24.91

asはそろそろFrom/TryFromに統一してほしいんだけど

**デフォルトの名無しさん** · 2024/02/24(土) 20:45:24.03

型オナニーって全部習得するまでにいったいどれだけ時間かかるんだ

**デフォルトの名無しさん** · 2024/02/24(土) 20:47:39.26

型オナニー四十八手

**デフォルトの名無しさん** · 2024/02/24(土) 22:10:17.16

>>13
機能が異なるので統一されない
asはcastなので変換From/TryFromとは異なる
例えばi32からu8の場合は変換できない値があるため
impl From<i32> for u8は実装がなく
impl TryFrom<i32> for u8の実装があり
u8::try_from(-3_i32)は変換できずErrとなる
一方でasはcastなので-3_i32 as u8は8bitに切り捨てられ252となる

**デフォルトの名無しさん** · 2024/02/24(土) 22:13:12.85

打ち間違い
252でなく253ね

**デフォルトの名無しさん** · 2024/02/24(土) 22:51:22.10

>>16
それだけならstdにimpl From<i32> for Wrapping<u8>でも入ってくれれば事足りると思うが……

asって手軽なだけで変換元と変換先の型ごとに意味が複数あるのが複雑で嫌いなんじゃ
C++のC形式キャストみたいな印象

**デフォルトの名無しさん** · 2024/02/24(土) 22:53:55.08

え、てかそもそも演算オーバーフローはpanicするのにキャストはpanicしないのか
だるっ
そういうとこやぞ

**デフォルトの名無しさん** · 2024/02/24(土) 23:26:44.50

生演算子はオーバーフローせずラッピングされる
panicはデバッグ時のみ
明示的にラッピングしたいときはwrapping_add
オーバーフローを処理したいときはchecked_addやoverflowing_addまたはsaturating_add

**デフォルトの名無しさん** · 2024/02/25(日) 01:04:03.14

型オナニーって複雑な型パズルを解いて悦に入ることを言ってるのかと思いきや
標準ライブラリの基本的な使い方を覚えることなのかよ
オナニー要素ゼロじゃん
そんなマインドではRustに限らず言語習得は無理だぞ

**デフォルトの名無しさん** · 2024/02/25(日) 01:05:34.01

そんなマインドでもGo言語なら習得出来るんだよなあ

**デフォルトの名無しさん** · 2024/02/25(日) 01:14:51.15

バカはGoへ行くしかないよ
Rustなどは一般的なプログラミング能力がある人向け

**デフォルトの名無しさん** · 2024/02/25(日) 01:52:59.15

>>22
それはたまたま動いてるようなもんだぞ。

**デフォルトの名無しさん** · 2024/02/25(日) 09:14:13.54

Rustの開発って時間掛かりそうなイメージある
とりあえず作ってみて後でリファクタリングって作り方ができない感じ？

**デフォルトの名無しさん** · 2024/02/25(日) 09:49:58.55

termuxよりscreen派なんだよなぁ。ライセンスはgplよりbsdのが好きなんだけど。

**デフォルトの名無しさん** · 2024/02/25(日) 10:13:55.36

>>21
リアルの会話でこうやってRustのマイナス面を他と同じと言う奴は
内心信用してない
>>23
言い方があれだけどこっちの方が信用できる

**デフォルトの名無しさん** · 2024/02/25(日) 10:16:51.38

>>25
リファクタリングってのは外部から見た時の挙動を変えないのが原則なので
少なくとも型やライフタイムについては辻褄が合っていることを保証できる仕組みは
リファクタリングでも便利なんだぞ。

内部的な処理でもあまり柔軟には変えづらいということはあるけど
変えづらいところは (外部に対する保証に関わってくるので) 変えてはならない箇所だってことがわかる。

**デフォルトの名無しさん** · 2024/02/25(日) 10:21:38.07

>>9
✕プログラミングに向いていない
○rustに向いていない
皆さん、これがrust信者です

**デフォルトの名無しさん** · 2024/02/25(日) 11:59:50.84

>>6
せめてtraitに外延性があって集合的操作ができればいいんだけど、さすがにビルドに時間掛かりそうだしな。

ただでさえビルド時間が重たいから、設計の「早すぎる最適化」は仕方ないのかね。

**デフォルトの名無しさん** · 2024/02/25(日) 12:12:53.79

>>26
screenってまだメンテされてんの？

**デフォルトの名無しさん** · 2024/02/25(日) 12:43:55.95

>>28
例えばpythonとかだと型とかプログラム構造気にせずにパパッと書いて
ある程度動くスクラッチでレビューして内容詰めて
スクラッチから流用できそうなら作り込んでリファクタリングみたいにできるけど
Rustだとそういう風にできなさそう

**デフォルトの名無しさん** · 2024/02/25(日) 12:48:37.70

>>23
こういうのに限ってgoでもろくなもの書けない

**デフォルトの名無しさん** · 2024/02/25(日) 12:50:53.73

>>32
Pythonだとそのリファクタリング前後で挙動が変わってしまわないように気を遣うのがしんどいな
そういうとりあえず試しに作るケースだとユニットテストなんかも当然ない状況なんで
Rustに限らず静的型ならその辺をだいたいコンパイルエラーで拾えるのが楽

**デフォルトの名無しさん** · 2024/02/25(日) 13:03:20.25

>>27
「僕は基本Traitがよくわからない => それはRustのマイナス面」
この発想が幼稚さがわからないのかな？
他の言語と比べたときのRustのマイナス面はたくさんあるがそういう話のレベルじゃないだろ

**デフォルトの名無しさん** · 2024/02/25(日) 13:05:42.89

>>32
動的型付け言語しか使ったことがない初心者が
静的型付け言語の圧倒的なメリットを理解できないのはよくあるあるある
脱初心者の壁を乗り越えよう

**デフォルトの名無しさん** · 2024/02/25(日) 13:18:05.49

どんな言語にもマイナス面がありRustにもある
しかしマイナス面を上回る莫大なメリットがRustにはいくつもあるからIT業界をあげてRustを支援＆採用している
揚げ足取りでRustを叩きたいだけの人はアンチスレへ行け

**デフォルトの名無しさん** · 2024/02/25(日) 13:23:45.23

>>36
知らないのかもしれないけど今のPythonはどちらもできる

**デフォルトの名無しさん** · 2024/02/25(日) 13:29:34.11

>>35
どんな理由であれ複雑なのはマイナスだろ
複雑なのがプラスだってんならC++かbrainfuckやれよ

**デフォルトの名無しさん** · 2024/02/25(日) 13:33:19.74

漸進的型付けは静的片付けと動的型付けのどちらも出来るわけではなくて漸進的型付けという別物だと解釈すべきだと思うよ。

**デフォルトの名無しさん** · 2024/02/25(日) 13:35:59.16

>>39
能力が同じなら複雑さはマイナスだが複雑にしてでもそれを上回るメリットが得られることがあるという話だということも理解できないの？
トレードオフ

**デフォルトの名無しさん** · 2024/02/25(日) 13:47:25.26

>>41
>>35はそんなこと書いてないぞ

> 「僕は基本Traitがよくわからない => それはRustのマイナス面」
> この発想が幼稚さがわからないのかな？

だぞ。勝手に自分の文脈を他の人のレスに上乗せして書いてない解釈を押し付けるなよガイジ

**デフォルトの名無しさん** · 2024/02/25(日) 13:51:18.30

Rustで有名アルゴリズムに挑戦第16回 Rustで機械学習に挑戦 - k近傍法でアヤメの分類をしよう
https://news.mynavi.jp/techplus/article/rustalgorithm-16/
共同作戦で壊滅したマルウェア「Qakbot」復活、米国は犯行グループを逮捕できず
https://news.mynavi.jp/techplus/article/20240225-2885670/
悪意あるPythonパッケージを2つ発見、DLLサイドローディング技術悪用
https://news.mynavi.jp/techplus/article/20240225-2889952/
充電式バイブレータからマルウェア検出、USB充電デバイスに注意
https://news.mynavi.jp/techplus/article/20240224-2889949/

**デフォルトの名無しさん** · 2024/02/25(日) 13:53:04.35

ここはRustユーザが集うRustスレ
叩きたいだけのキチガイはアンチスレへ行け

**デフォルトの名無しさん** · 2024/02/25(日) 13:56:41.04

>>43
なるほど
https://news.mynavi.jp/techplus/article/rustalgorithm-16/images/001.jpg

**デフォルトの名無しさん** · 2024/02/25(日) 14:00:42.93

C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と
https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html

**デフォルトの名無しさん** · 2024/02/25(日) 14:05:55.86

>>37
嘘はいかんよ
Rustにはメリットなし、がIT業界の総意
Adaの方が上

最新版IEEE調査Jobs
https://i.imgur.com/Z8hI9C6.png

**デフォルトの名無しさん** · 2024/02/25(日) 14:10:17.03

Jobで判断するのはちょっとなあ
Jobの要件にするのってその言語さえ出来れば良い人を探す時じゃん
Rustってまだそのフェーズではないんだよな

**デフォルトの名無しさん** · 2024/02/25(日) 14:19:17.62

>>48
言うてメインはOSS用だよね
大手はちょっとばかり資金援助してレバレッジ効かせようと宣伝して
2021-2022がRustハイプのピークだったんだけど真水のJobは稀

**デフォルトの名無しさん** · 2024/02/25(日) 14:25:08.84

>>46
Carbonはその公式FAQに明記してるように
Rustを使える状況ならRustを使ったほうがいいという立ち位置
Carbonは既存のC++遺産メンテ用

**デフォルトの名無しさん** · 2024/02/25(日) 14:32:26.24

>>49
次々とRust製へ変わっていってる
リソース面すなわち経済的にもエコ的にもRustが有利なので今後次々とRust製へ置き換わっていく

ソース
＞【クラウド世界トップシェアAWS】
＞https://japan.zdnet.com/article/35183866/
＞Rustで構築されたAWSサービスの例としては、
＞コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
＞「Amazоn Simple Storage Service（S3）」、
＞「Аmazоn Elastic Compute Cloud（EC2）」、
＞コンテンツ配信ネットワーク「Аmazоn CloudFront」、
＞LinuxベースのコンテナーOS「Bottlerocket」などがある。

＞【CDN世界トップシェアClоudflare】
＞https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
＞同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。

**デフォルトの名無しさん** · 2024/02/25(日) 14:38:19.37

Rustは知らず知らずのうちに技術的負債を量産しそうな気配だな
Rustは既に違法建築だから
前スレで言われる矮小化オンパレードで笑ったw

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1705760500/9
>>https://mevius.5ch.net/test/read.cgi/tech/1692105879/990
一応知らない人のために書いておくけど

「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる
特定の機能導入のタイミングでコードが発見されたけど、
「Rustの仕様バグ」だと認識されていて直せない

>>4
そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ

最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから
たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな
(githubの議論でも矮小化して放置)
気を付けろよ

https://github.com/rust-lang/rust/issues/114936

**デフォルトの名無しさん** · 2024/02/25(日) 14:45:16.11

>>52
情報古いな
AmazonはLLRTでしょ
cloudflareのRustは放置だ

**デフォルトの名無しさん** · 2024/02/25(日) 14:48:00.26

誰も問題視していないどうでもいいことでしかRustを叩けない状況
アンチが追い込まれている

**デフォルトの名無しさん** · 2024/02/25(日) 14:53:16.67

>>53は>>51向けな

>>52のは違うIssue/PRのcommitで場当たり的fixしただけで知れっと本質を隠蔽した

>>54
問題視したから取り繕いfixしたんだよ

**デフォルトの名無しさん** · 2024/02/25(日) 14:56:15.69

>>37,47
上位は納得だから結局のところ「IT業界をあげて」なんて言いたかったら
Jobで判断するのが客観的で中立フェアな基準なんだな

**デフォルトの名無しさん** · 2024/02/25(日) 14:59:17.67

>>53
LLRTはAWS LambdaでJavaScriptを使いたい人向けのJSランタイムの一つ
Rustが使えるならRustを使ったほうが有利
さらにAWS自体も>>51にソースがあるようにRustで書かれている

**デフォルトの名無しさん** · 2024/02/25(日) 15:03:11.52

>>57後半
部分的にな
あとそのソースとやらのLiam Tungはいなくなったね
飛ばし過ぎた？

**デフォルトの名無しさん** · 2024/02/25(日) 15:09:15.42

>>57
>Rustが使えるなら

時々見るこの枕詞は実際の現場では使えない事の証拠なんだよなぁ

**デフォルトの名無しさん** · 2024/02/25(日) 15:10:35.35

>>57

>JavaScriptを使いたい人
これが圧倒的だからAmazonが独自魔改造したから凄い

**デフォルトの名無しさん** · 2024/02/25(日) 15:27:26.81

>>59
そのAWS Lambdaでも当然Rustを使えます
Rustを使えないのは環境ではなく低層プログラマー

**デフォルトの名無しさん** · 2024/02/25(日) 15:30:50.61

>>55
この恣意的な例以外で同様の脆弱性が生まれる例があれば教えて欲しい
煽りとかではなく

**デフォルトの名無しさん** · 2024/02/25(日) 15:48:37.00

>>62
俺も煽りじゃなく警鐘で言うけど
>>55の根本原因究明がならなかったから、今後も散発的に発見しては穴ふさぎをするのでは
(CVE報告しないで悪用されたら最悪だけど)

Rustのメモリ安全性目標チェックは他の言語と比べて
相対的にメリットがあったりデメリットがあったりするだけのことだから

**デフォルトの名無しさん** · 2024/02/25(日) 16:02:53.19

>>62
恣意的ってそういう意味じゃないですよ

**デフォルトの名無しさん** · 2024/02/25(日) 16:07:08.08

例出せないならお前が偉そうに言うことではないぞ
どの立場からもの言ってるんだ？

**デフォルトの名無しさん** · 2024/02/25(日) 16:10:58.09

>>62>>65
化けの皮が剥がれるの早すぎて草

**デフォルトの名無しさん** · 2024/02/25(日) 16:11:46.86

俺の質問に答えずに訳のわからないことを言うしかできないんですね
くだらないクズが

**デフォルトの名無しさん** · 2024/02/25(日) 16:14:14.27

>>52
実際の開発では出てこない極端に作り上げた例のみだから
Rustを採用しているIT大手を含めて問題視していない

**デフォルトの名無しさん** · 2024/02/25(日) 16:19:05.44

>>66
ちなみに急に煽り始める>>65,67はあのコテハン

>>68
>実際の開発では出てこない極端に作り上げた例
自分で踏んだ事ないから想像だけど、失敗を犯すのはその考え方の人間

**デフォルトの名無しさん** · 2024/02/25(日) 16:21:52.97

いや煽ってきたのはお前だろw
何を勘違いしてるんだ

**デフォルトの名無しさん** · 2024/02/25(日) 16:23:31.57

自分が攻撃するのは良くて攻撃されるのは嫌か？
そういうやつには徹底的にやるから覚悟しろよ
俺に攻撃するってことはそういうことだ

**デフォルトの名無しさん** · 2024/02/25(日) 16:24:39.64

誰やねん

**デフォルトの名無しさん** · 2024/02/25(日) 16:27:11.46

自分以外が全部同一人物だと思い込んでるアタオカの着火点は意味不明だよな

**デフォルトの名無しさん** · 2024/02/25(日) 16:31:47.21

>>69
実際にコードを見てごらん
ありえない無意味なコード
識者たちも問題視していない

**デフォルトの名無しさん** · 2024/02/25(日) 16:36:11.19

>>71 誰も攻撃してないのにこの人怖い、やめてくれませんか
心理的安全性を通り越して身の危険を感じる((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

**デフォルトの名無しさん** · 2024/02/25(日) 16:37:37.04

例の#25860、ジェネリクスとかマクロ生成の裏で意図しないでこのパターン踏んだりしない？
絶対ない？

**デフォルトの名無しさん** · 2024/02/25(日) 16:37:39.99

rustでリファクタリングしながらの開発ってなると多分unsafeを途中経過で入れたりとか
そういうテクニックが必要になると思う。
その辺の整備が進めば割と広まるかもね。

**デフォルトの名無しさん** · 2024/02/25(日) 16:45:35.35

>>76
絶対にないから安心していい
その「&'static &'a ()」が出てくることはない

**デフォルトの名無しさん** · 2024/02/25(日) 16:50:17.61

>>78
理由は？

**デフォルトの名無しさん** · 2024/02/25(日) 16:51:49.35

>>32
サクッとプロトタイピングする目的ならそりゃRustよりPythonのほうが向いてる
Rustは多少手間がかかったとしても速度・安全性・堅牢性を高い水準で求める場合に使う言語

>>39
AsRefやTryFromが複雑とか言われても困ります

**デフォルトの名無しさん** · 2024/02/25(日) 16:52:52.76

>>77
unsafeは基本的に不要
必要だと思ってもまず標準ライブラリにその機能がないか調べる
次にクレートにその機能がないか調べる
どこにも存在しない場合
unsafeを安全に閉じ込めて安全に使うことができる有用な機能を発見したのならばラッキー
それをクレートとして公開するとよい

**デフォルトの名無しさん** · 2024/02/25(日) 17:06:44.48

Rustコンパイラチームは意図せず発生する可能性を否定していない様子
ここのヤツはやっぱりテキトー言ってるだけか

https://hackmd.io/@rust-compiler-team/SkkrA1DCK#Variance
> https://github.com/rust-lang/rust/issues/25860
> root issue of most variance issues
> ⚠🚨⚠ can potentially just happen by accident

**デフォルトの名無しさん** · 2024/02/25(日) 17:26:51.68

>>77
同じ構造体の一部を参照しながら別の一部を書き換える大きめのメソッドを
複数のメソッドに分割しようとするとborrow checkerに引っかかる的な話かな
他の言語のクラスと同じ感覚で構造体作るとたまに嵌る
Rustの構造体はRDBのテーブルを正規化する雰囲気で分割した方がいい

**デフォルトの名無しさん** · 2024/02/25(日) 17:30:07.94

>>82
Rustのvariance仕様だから発生させることはできるけど
現実に使うコードでは発生しない
意図的にその仕様の狭間をつく現実的でないコードでのみ発生する
そのためその2015年からそのまま放置で誰も困っていない

**デフォルトの名無しさん** · 2024/02/25(日) 17:45:11.19

>>84
by accidentを辞書で引いてこい

**デフォルトの名無しさん** · 2024/02/25(日) 17:51:15.22

>>85
その2015年から9年間
その問題でトラブルが起きたことがない

**デフォルトの名無しさん** · 2024/02/25(日) 17:55:53.01

>>81
>unsafeは基本的に不要
>...ラッキー
嘘で始まって運頼みで締めるとはw

信者の心の支えの大手のあそこは
見境なくunsafeを使わざるを得なくなって
Rustでやった意味が無くなってるってよ

**デフォルトの名無しさん** · 2024/02/25(日) 17:56:42.46

可能性を論じるならお前の頭に隕石が落ちてくる可能性だってあるが、そんなことを心配したことある？

**デフォルトの名無しさん** · 2024/02/25(日) 18:03:36.71

RustはVec等のCVE前科があるからなぁ
頭に隕石が落ちたんじゃね？

**デフォルトの名無しさん** · 2024/02/25(日) 18:07:11.51

開発プログラムでunsafeを直接使うことはほとんどない
unsafeが閉じ込められ安全なインターフェースが公開されている形で間接的にのみ用いる
どうしてもunsafeが必要になった場合でもそのように安全な形で分離して用いる

**デフォルトの名無しさん** · 2024/02/25(日) 18:10:03.77

隕石であれ何であれそれがエンジニアリング可能な対象なら問題を特定して語る意味はあるだろう

**デフォルトの名無しさん** · 2024/02/25(日) 18:19:05.40

>>89
Dropで型がpanicする時にその要素をた用いたVec::from_iter()で二重解放のバグが発見された件か
もちろん他の言語と同様に全ての言語においてライブラリにバグが見つかることは当然ある
Rustはその点でも少ない方なので信頼して使える

**デフォルトの名無しさん** · 2024/02/25(日) 18:30:56.08

>>90,92
思い描く理想と現実の落差が激しいな
Rust不信の原因だぞ

とくに>>92の最後の行があるから信用されない

**デフォルトの名無しさん** · 2024/02/25(日) 18:43:22.50

Rustの2023年のCVEはCargoで名前をエスケープし忘れた1件のみ
Rustの2022年のCVEは0件
つまりRustコンパイラについて過去2年間でCVEなし
信頼度が高いと言える

**デフォルトの名無しさん** · 2024/02/25(日) 18:49:05.16

Rust以外のコンパイラってそんな言うほどバグないか？

**デフォルトの名無しさん** · 2024/02/25(日) 19:34:08.90

普通にあるけどみんなで使うから大部分はリリース前に潰される
コンパイラというよりライブラリのバグみたいだけど他の言語より未定義動作にシビアだから
バグ扱いされる事例が増えるのは仕方ない

**デフォルトの名無しさん** · 2024/02/25(日) 19:46:15.91

>>91
お前のとこは無限のリソースがあるのかな？
いいなぁ優先順位考えなくていい環境。うらやましいよ。

**デフォルトの名無しさん** · 2024/02/25(日) 19:49:21.58

今となっては未定義動作の多い言語を使うのは悪行だ
Rustを使うべし

**デフォルトの名無しさん** · 2024/02/25(日) 20:11:25.55

>>82
ここの信者はテキトー過ぎるよな
コンパイラ開発チームはもとより、サーベイ回答者もコンパイラバグ潰しを最優先、が一番多い

**デフォルトの名無しさん** · 2024/02/25(日) 20:15:02.43

>>97
余裕があるからRustもやる、と言うのが普通だな
サーベイでも(余裕がなくなって)Rust採用予定なし、なぜなら他言語採用予定だから、が一番多い
(ただし採用にはインターンも含まれる)

**デフォルトの名無しさん** · 2024/02/25(日) 20:24:50.38

>>99
対処の必要があるものはその通り
しかし実害がないと皆が判断して対処優先度低いまま9年間が経過したが実害がな起きていない
そんな状況のものを杞憂したり揚げ足取りでRustを叩いてる連中がゴミ

**デフォルトの名無しさん** · 2024/02/25(日) 21:16:46.71

事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな

**デフォルトの名無しさん** · 2024/02/25(日) 21:34:47.98

>>101
これが矮小化と言うやつか

7割がバグ潰しを「最優先」と回答している事実
直したくても直せないまま何年も経過、unsafe無しでメモリ安全ではない(事実)、Rustの不健全仕様(事実)
(unsound=不健全は数学用語、要は矛盾があるという事)

幸運にもRustが使われなさ過ぎで実害がないように見える(または報告がないだけ)
(良心的に考えてRustが広く使われてない内に)バグ潰しをしとけ、がユーザーの9割の意見(中優先含めて)

週明けのテック記事はどう書くのかな
良い所だけ抜き出してビューが取れるハイプ期間は弱まったと思う
それと飛ばし過ぎるといなくなるorz

**デフォルトの名無しさん** · 2024/02/25(日) 21:37:20.20

アンチもMozillaが変なことやってるだけで
firefoxに導入できるわけがない一般人が
使えるようになるのは妄想とか
言ってた頃に比べると細かい実装の穴を
ネチネチやるまでになって大変だなあ

**デフォルトの名無しさん** · 2024/02/25(日) 22:03:27.18

>>103
根本的なことを理解できてないようなので一点だけ
unsafeがプログラム全体に散らばっている他の言語に対して
Rustはunsafeを局所的に閉じ込めて安全なインタフェイスを公開しそれを使ってプログラミングする言語
よく使われる基本機能は標準ライブラリとしてunsafeを閉じ込めてあるが
必要なら自作を含めてunsafeを閉じ込めたライブラリを使ってよい
他の言語と比べてunsafeを局所的に閉じ込めた部分のみ注視すればよいことがRustのメリット

**デフォルトの名無しさん** · 2024/02/25(日) 22:16:32.90

>>105
unsafeに閉じ込められなかった事実を提示されてるんだが何言ってるんだ？

**デフォルトの名無しさん** · 2024/02/25(日) 22:32:50.41

Rustコンパイラにバグがあるのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな

**デフォルトの名無しさん** · 2024/02/25(日) 22:47:36.07

C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。

**デフォルトの名無しさん** · 2024/02/25(日) 23:03:18.85

unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは
もちろん呼び出される側の安全性ではない
呼び出す側だけが検査される
しかも検査が完璧かどうかは実装依存
じゃあ言語仕様により保証されるのは何か

言語仕様は、あとは検査が通るか通らないかを確かめればよいというところまで仕様を確定しなければならない

**デフォルトの名無しさん** · 2024/02/25(日) 23:10:45.79

プログラム全体がunsafeなC/C++は使いたくない
未定義な動作も多すぎる

**デフォルトの名無しさん** · 2024/02/25(日) 23:49:12.62

>>109
Rust関係無しに基本的なことを理解できてないようだけど
掛ける情けも無し

**デフォルトの名無しさん** · 2024/02/26(月) 00:02:36.23

反論できないときは関連するワードを含むRustの宣伝文句をぶつける
いつもの流れです

**デフォルトの名無しさん** · 2024/02/26(月) 00:08:01.38

難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」
https://news.mynavi.jp/techplus/article/20240222-2889545/

**デフォルトの名無しさん** · 2024/02/26(月) 00:10:06.79

>>105,109
詐欺師みたいな偽者だな、Rust不信の種まきするのやめろ
>>112
分かっていれば支離滅裂文章なんだけど騙されるのは学生位だろうか

**デフォルトの名無しさん** · 2024/02/26(月) 05:11:35.79

>>前スレ992
Derefは演算子
・そのためstd::ops::Derefにある　(変換std::convert::AsRefと対照的)
・演算子*によりderefされる
・&**へとcoerceされる

**デフォルトの名無しさん** · 2024/02/26(月) 13:22:06.51

Derefの名前の由来は*演算子（dereference：参照解決）だろうけど
機能は&**へのcoerceを前提にしてて結果的にrefのままだからややこしいな
現状だとInnerRefの方がしっくりくる

**デフォルトの名無しさん** · 2024/02/26(月) 13:34:26.79

意味的にはFollowRefの方が自然かな
まあ*演算子で使われるtraitだからDerefでいいんだけど

**デフォルトの名無しさん** · 2024/02/26(月) 17:12:18.82

【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1708865670/l50

ボイス・トォ・スカるしている者も攻撃を受けるようになりました

**デフォルトの名無しさん** · 2024/02/26(月) 18:21:55.22

>>115
>・&**へとcoerceされる
これDeref Coercionのこと言ってる？だとしたら&**に限定する意味がわからない
あと前スレ992で重要なのは&T→TはDerefの役割ではないというところね

>>116,117
スマートポインタのdereferenceのために存在するTraitだから
InnerRefやFollowRefよりDerefのほうがずっと自然だと思う
*演算子の振る舞いとは別にcoercionの振る舞いは理解しなければいけない
そういう点でも「Derefは演算子」という捉え方は良くないよ

**デフォルトの名無しさん** · 2024/02/26(月) 19:05:39.95

Rustて、演算子と関数を(意味論的に)区別していたっけ？
中間記法によるややこしい結合順の違いがあるぐらいで、構文解析後は等価だから、あんまりこだわっても仕方が無い気が。

中間記法の演算子は人間の算数の記法に配慮しているだけの悪習でしか無いから、積極的に差異をつけないほうが良い気がするけど。

**デフォルトの名無しさん** · 2024/02/26(月) 19:26:28.00

Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。

**デフォルトの名無しさん** · 2024/02/26(月) 19:44:24.36

+に対するAdd, &=に対するBitAndAssignと同じ位置づけで
(*T)に対するDerefがstd::opsに入ってるイメージだけど
(*T）自体は
let x: Box<String> = Box::new(String::from("foo"));
let y: String = *x;
みたいに参照先の値を取り出す使い方ができてむしろそっちが本来の意味なのに
それができないtrait DerefがDerefを名乗ってるのが微妙だと思った

**デフォルトの名無しさん** · 2024/02/26(月) 19:45:57.01

>>121
サンクス。
「演算子」じゃなくて「 * (参照外し演算)」ということね。

**デフォルトの名無しさん** · 2024/02/26(月) 19:57:36.80

>>116
*を明示的に付けるとdereferenceされるからDeref
&**によるcoerceは何も付けずに適用される
そのため参照から参照へ型が変わるだけで参照のままとなる

>>119
Derefはoperatorなのでstd::opsにある
Derefでも&T→Tと実装されている
Derefによるcoerceは&**となる

**デフォルトの名無しさん** · 2024/02/26(月) 20:43:46.74

関数と同じでは困るものといえば && || が有名だけど = が一番やばい
初期化とか代入とかコピーとか移動とか

**デフォルトの名無しさん** · 2024/02/26(月) 20:52:21.27

>>125
=はパターンマッチング
マッチングした時にCopy実装があればコピーされる
以上で極めてシンプル

**デフォルトの名無しさん** · 2024/02/26(月) 21:10:51.91

Rustにおける = は心の中でバインド演算子って呼んでるわ

**デフォルトの名無しさん** · 2024/02/27(火) 01:03:26.56

>>124
>Derefはoperatorなのでstd::opsにある
https://doc.rust-lang.org/std/ops/index.html
ここ見ればわかると思うけど各Traitの説明に”The ~ operator”と書いてるものがoperator
Derefは”Used for immutable dereferencing operations, like *v.”とあるようにDerefそのものはoperatorではない

>Derefでも&T→Tと実装されている
Deref<Target=T> for &Tの実装が提供されてるのは別の役割のため
その実装が実行されて&T→Tになっているのではない
Box<T>→Tなんかも正確に言えば&Box<T>→&T

>Derefによるcoerceは&**となる
全然わからない
何か一つくらい根拠を提示してくださいな

**デフォルトの名無しさん** · 2024/02/27(火) 01:17:48.86

Derefによるcoerceは&**となるのが全然わからないって本気なのかな？

「corece後の参照」= &**「corece前の参照」
となるのがDerefによるcoerceだよ

**デフォルトの名無しさん** · 2024/02/27(火) 03:35:57.72

READ THE FUCKING MANUAL
https://doc.rust-lang.org/beta/reference/type-coercions.html#coercion-types

**デフォルトの名無しさん** · 2024/02/27(火) 05:16:27.87

>>129
＞「corece後の参照」= &**「corece前の参照」

実験コード書いて一通り確認してみたら
たしかにそうなった

**デフォルトの名無しさん** · 2024/02/27(火) 08:57:02.46

上の一連の流れ見てるだけでRustしんどそうに見える

**デフォルトの名無しさん** · 2024/02/27(火) 10:40:40.53

>>129
なるほどそういう風に捉えてるのか
ちょっと独特だね
それはcoercionの動きというよりderefのシグニチャを
内部的にderefを使ってる*演算子で再定義しようとしてるので
循環が気持ち悪いけど一つの見方として頭の隅にしまっておく

ちなみにThe Bookにある一つの例ではderef coercionがなければ*が余計に必要と説明されてる
https://doc.rust-lang.org/book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods
それに&**とは必ずしも等価じゃないからDeref Coercionを説明するのにはあまり勧められないかな
let x = "Hello".to_string();
let y = Box::new(x);
let z = &**y; //zは&strになる
let z:&str = y; //これはcoerceしないのでコンパイルエラー

**デフォルトの名無しさん** · 2024/02/27(火) 10:44:06.64

こんな議論が発生する時点でかなりややこしくて面倒な言語がであることは認めざるを得ない

**デフォルトの名無しさん** · 2024/02/27(火) 11:23:28.24

そんなことよりDerefの定義の中で参照外ししている↓が無限ループにならない理由でも調べてみたほうが面白いよ
https://doc.rust-lang.org/src/alloc/boxed.rs.html#1927

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

>>135
それが&T→TはDerefの役割ではないという話

**デフォルトの名無しさん** · 2024/02/27(火) 11:56:56.99

rustは使い勝手のために暗黙にokにした構文が逆にわかりづらさを生んでる。

**デフォルトの名無しさん** · 2024/02/27(火) 12:07:27.17

>>137
まあそれは他の言語も歩んできた道だから……
良いとは言わんけどなくてもめんどいんだよな。

**デフォルトの名無しさん** · 2024/02/27(火) 12:18:37.87

>>136
*selfはそれでいいけど、**selfはそれじゃ説明付かんぞ

**デフォルトの名無しさん** · 2024/02/27(火) 17:59:37.59

>>139
&T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない

**デフォルトの名無しさん** · 2024/02/27(火) 18:12:58.39

Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ？
Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・

**デフォルトの名無しさん** · 2024/02/27(火) 18:13:56.86

>>133
まず基本を理解しよう
deref coreceは必ず参照から参照へのみ起きる
Box自体は当然deref coreceされない

その例だと
let b = Box::new("Hello".to_string());
まずc0は単なるBox参照
let c0: &Box<String> = &b;
このc1とc2がderef corece
let c1: &String = &b;
let c2: &str = &b;

そのc1とc2を明示的に書くとこうなる
let c1: &String = &**(&b);
let c2: &str = &**(&**(&b));
この暗黙に適用される&**がderef corece

この自動適用のおかげでstrのメソッドが使える
assert!(b.starts_with("He"));
フルに書くとこうでもちろん対象はbではなく&b
assert!(str::starts_with(&b, "He"));
この&bが前述の通り自動的に&**(&**(&b))となり&str型へcoreceされている

**デフォルトの名無しさん** · 2024/02/27(火) 18:33:30.42

>>141
圧縮アーカイブならzipクレート
圧縮ならlibflateクレートなど

**デフォルトの名無しさん** · 2024/02/27(火) 19:01:36.79

>>133
＞ coercion

横から素人がすまん、これ何て読めばいいの？

**デフォルトの名無しさん** · 2024/02/27(火) 19:26:56.87

Rustもちょっと前の熱狂はなくなってしまった感じ
入込数が減ってると思う

**デフォルトの名無しさん** · 2024/02/27(火) 19:39:57.60

まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは

**デフォルトの名無しさん** · 2024/02/27(火) 19:51:34.77

>>144
発音[US] kouə́ːrʒən ｜ [UK] kouə́ːʃən
カナ[US]コウアァジョン、[UK]コウアーション

参考：https://eow.alc.co.jp/search?q=coercion

自分はコアジョン派

**デフォルトの名無しさん** · 2024/02/27(火) 20:18:10.37

>>144
コアーション派

**デフォルトの名無しさん** · 2024/02/27(火) 20:23:00.40

>>147
サンクス。愛してる

**デフォルトの名無しさん** · 2024/02/27(火) 21:54:58.65

Tのスマートポインタの参照 -> Tの参照
文字の配列の参照 -> 文字のスライス
一連の流れを見るとみんなポインタに熱狂している

**デフォルトの名無しさん** · 2024/02/27(火) 22:22:03.42

>>150
そこはポインタと参照の根本的な違いを理解しできるかどうかかな

「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが
「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ
したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる
だからスマートポインタの参照を渡すことになる
一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない
しかし参照＝ポインタではなく参照は抽象的なものなのだ

**デフォルトの名無しさん** · 2024/02/27(火) 22:43:38.35

Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。
C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、
参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。

**デフォルトの名無しさん** · 2024/02/27(火) 22:57:53.18

その橋渡し役がDeref coercion
&Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが
Box<T>→TのDerefがあるため
&Box<T>→&TとDeref coercionが適用できる
静的にコンパイル時点で行われるため実行時コストはかからない

**デフォルトの名無しさん** · 2024/02/27(火) 23:09:15.00

>>142
この辺り最初理解するまで訳分からんかったな
理解すると大したことはないのだが

**デフォルトの名無しさん** · 2024/02/27(火) 23:37:04.57

>>142
>deref coreceは必ず参照から参照へのみ起きる
&**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね

それは別にいいんだけど書いてる内容を見る限り
Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく
実際に&**が適用されると思ってるみたいに感じるね
だとしたらそれは完全な間違い

derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ
Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし

**デフォルトの名無しさん** · 2024/02/27(火) 23:45:58.16

とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね

**デフォルトの名無しさん** · 2024/02/27(火) 23:58:10.03

Derefは*
Deref coercionは&**
前者は明示が必要な点が違い

x: &Box<T> とすると
*x: Box<T>　(by Deref &T→T)
**x: T　(by Deref Box<T>→T)
&**x: &T　(xのDeref coercion結果)

x: &Vec<T> とすると
*x: Vec<T>　(by Deref &T→T)
**x: [T]　(by Deref Vec<T>→[T])
&**x: &[T]　(xのDeref coercion結果)

x: &String とすると
*x: String　(by Deref &T→T)
**x: str　(by Deref String→str)
&**x: &str　(xのDeref coercion結果)

**デフォルトの名無しさん** · 2024/02/28(水) 00:29:07.11

>>157
とりあえずDerefの定義が

pub trait Deref {
type Target: ?Sized;

// Required method
fn deref(&self) -> &Self::Target;
}
（https://doc.rust-lang.org/std/ops/trait.Deref.html）

でderef()の戻り値には自動的に&がつくから
*x: Box<T>
*x: Vec<T>
*x: String
はDeref traitと関係ないことを抑えておこう
そこに（by Deref…）を書かれると話がおかしくなる

*Tができることの一部をDeref traitではできない
正確な表現かは分からないけどDerefは&の向こう側でしか*を適用できない

**デフォルトの名無しさん** · 2024/02/28(水) 00:41:03.68

こうだろ

x: &Box<T> とすると
*x: Box<T>　(by Dereference)
**x: T　(by Deref Box<T>→T)
&**x: &T　(xのDeref coercion結果)

x: &Vec<T> とすると
*x: Vec<T>　(by Dereference)
**x: [T]　(by Deref Vec<T>→[T])
&**x: &[T]　(xのDeref coercion結果)

x: &String とすると
*x: String　(by Dereference)
**x: str　(by Deref String→str)
&**x: &str　(xのDeref coercion結果)

**デフォルトの名無しさん** · 2024/02/28(水) 00:49:10.38

なんかゲシュタルト崩壊してきたんだがｗ

関係ないけど微積のdxとかdyを思い出してしまった

**デフォルトの名無しさん** · 2024/02/28(水) 01:22:37.90

C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ

**デフォルトの名無しさん** · 2024/02/28(水) 01:32:01.63

Deref coercion &**のうち
右側の*は参照に対する参照外しで
左側の*はDerefで定義(実装)されてるものなのね

**デフォルトの名無しさん** · 2024/02/28(水) 04:46:46.07

let s = String::from("xyz");
let x: &str = &s;
let x: &str = &&s;
let x: &str = &&&s;
これ全てコンパイル通ってderef coercionされるから
『by Deref &T→T』も適用されていると思うぞ

**デフォルトの名無しさん** · 2024/02/28(水) 11:30:56.58

>>163
&&T→&Tのことを&T→Tとは書かないわな
前者の用途にDeref for &Tは存在してる

**デフォルトの名無しさん** · 2024/02/28(水) 17:44:48.30

>>156
演算の名前はdereference
derefはDerefトレイトに定義してあるメソッドの名前

>>157
>Derefは*
違う
Derefはトレイト
*はdereference operator

>Deref coercionは&**
違う
Deref Coercionとはcoercionが行われる場合に「&Tを&<T as Deref>::Target」にcoerceすること
Deref Coercionと*などの演算子は全く別の独立したものとして扱われている
それぞれの処理の一部で必要に応じてDerefに定義されたderefメソッドを活用してるというだけ
片方がもう片方に依存してたりもしない

Deref Coercionの処理の一部として呼び出されるderefメソッドを
演算子で擬似的に再定義しようとすれば&**になるというの話はかろうじて理解できるが
前述のように定義が循環してるだけでなく再定義する価値を見いだせない

**デフォルトの名無しさん** · 2024/02/28(水) 18:08:21.49

なるほどね。勉強になるわ。

**デフォルトの名無しさん** · 2024/02/28(水) 18:17:32.89

>>164
&&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない？

**デフォルトの名無しさん** · 2024/02/28(水) 18:20:50.27

>>164
Deref coercionの定義を理解しよう
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
&String→&str　(by Deref String→str)
&Vec<T>→&[T]　(by Deref Vec<T>→[T])
&Box<T>→&T　(by Deref Box<T>→&T)
&&T→&T　(by Deref &T→T)
これらはすべてDeref coercion

**デフォルトの名無しさん** · 2024/02/28(水) 18:22:38.09

>>165
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される

U＝*T
↓　&Tから出発すると
U＝**(&T)
↓　両辺の参照をとると
&U＝&**(&T)
つまり
Deref coercionとは&**の自動適用のこと

**デフォルトの名無しさん** · 2024/02/28(水) 18:49:11.26

*xが左辺値なら代入、*xが右辺値なら複製とかいう演算に
ビルトインderefみたいな名前をつけるのが間違っている

**デフォルトの名無しさん** · 2024/02/28(水) 19:13:20.58

>>170
mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない
左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない

**デフォルトの名無しさん** · 2024/02/28(水) 20:06:21.19

判りにくい仕組みだけどこれから開発が進むと
文法変えたりするのかな？

**デフォルトの名無しさん** · 2024/02/28(水) 20:12:51.73

これほど分かりやすくて便利な明確な仕組みはない
他の言語と比較すれば明らか

**デフォルトの名無しさん** · 2024/02/28(水) 21:00:40.37

これが分かりやすいと思ってる人間には聞いてないよ

**デフォルトの名無しさん** · 2024/02/28(水) 21:10:22.04

他の言語でこれより良いものが存在しないね

RustのDeref
・自動適用されプログラマーの負担を軽減し利便性も良い
・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能
・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作

**デフォルトの名無しさん** · 2024/02/28(水) 23:39:05.31

>>172
Pythonが分かりやすいのは知ってるけど
RustとPythonは両極端だから文法を微調整してもしょうがない
文法を変える必要があるのは両極端を否定する言語だけだ

**デフォルトの名無しさん** · 2024/02/28(水) 23:49:09.85

Derefなのに&が消えてない（小並感）

背景を理解しないと引っかかりやすいRustの七不思議候補

**デフォルトの名無しさん** · 2024/02/29(木) 01:04:43.74

この仕組みがベストであるという主張は3種類ある
一つは馬鹿な信者が言ってるだけという可能性
一つは本当にこの仕組みがベストである可能性
最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性

このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる
馬鹿な反論が返ってきたら馬鹿な信者
合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない
意見を翻されたら素直な馬鹿

**デフォルトの名無しさん** · 2024/02/29(木) 01:16:58.91

この仕組みがない方が良いということ？
下手で全部書くべきと？

**デフォルトの名無しさん** · 2024/02/29(木) 01:51:37.80

RustのDerefとそのcoercion枠組みの利点
・プログラマーの負担が減る
・コードが見やすくなる
・枠組みはDerefトレイト利用で明白かつ汎用的になっている
・自分で作った型にも実装して作動させることができる
・静的に解決しているためミスしてもコンパイル時にわかる
・実行時に付加的な動作がなく高速に実行される

これらの利点を上回る方法があるならば知りたい
既存の言語でも新規の方法でも

**デフォルトの名無しさん** · 2024/02/29(木) 03:43:48.10

https://manishearth.github.io/blog/2017/01/10/rust-tidbits-box-is-special/
Boxのまほう

**デフォルトの名無しさん** · 2024/02/29(木) 10:19:46.23

>>179
>下手で全部書くべきと？
どこかの方言？

**デフォルトの名無しさん** · 2024/02/29(木) 12:07:39.99

>>178
いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。

**デフォルトの名無しさん** · 2024/02/29(木) 12:33:18.56

Rustの方式の利点は>>180に挙げられているから
もしRustより良い言語が存在するならば
その方式およびRustの利点を上回る利点を挙げればいいんじゃね？

**デフォルトの名無しさん** · 2024/02/29(木) 12:41:20.92

そんなに比較したいならﾜｯﾁｮｲスレ行けばいいんじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1701997063

**デフォルトの名無しさん** · 2024/02/29(木) 13:11:40.55

検証可能とはコンパイラが無謬であることではない
ここが難しい
コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること
これが検証可能

**デフォルトの名無しさん** · 2024/02/29(木) 14:11:14.15

>>182
この仕組みがない方が良いということ？

**デフォルトの名無しさん** · 2024/02/29(木) 14:14:12.31

単に理解できないから難癖つけてるだけだよねこの人
自分の主張も一切ないし

**デフォルトの名無しさん** · 2024/02/29(木) 14:15:14.41

誰かの難癖を自分が思い付いたかのように言ってるだけで
何一つまともな批判はない

**デフォルトの名無しさん** · 2024/02/29(木) 14:15:53.86

全く相手にすべき人間ではないと判断する
よって今後無視する

**デフォルトの名無しさん** · 2024/02/29(木) 14:45:30.61

>>184
それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき
その際他の道具との比較も必須ではない

**デフォルトの名無しさん** · 2024/02/29(木) 14:51:42.06

技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂

**デフォルトの名無しさん** · 2024/02/29(木) 14:52:32.46

Rustの方式の利点は>>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？

**デフォルトの名無しさん** · 2024/02/29(木) 15:05:04.64

>>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう

**デフォルトの名無しさん** · 2024/02/29(木) 17:17:49.66

物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか

**デフォルトの名無しさん** · 2024/02/29(木) 17:44:22.90

や、そもそも「人の心」の認識が無いのだろう

**デフォルトの名無しさん** · 2024/02/29(木) 18:01:07.55

わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな

**デフォルトの名無しさん** · 2024/02/29(木) 18:25:15.72

>>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった

**デフォルトの名無しさん** · 2024/02/29(木) 18:37:38.45

ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど

**デフォルトの名無しさん** · 2024/02/29(木) 20:49:33.50

impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど