Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

公式
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 part21
https://mevius.5ch.net/test/read.cgi/tech/1692105879/

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

**デフォルトの名無しさん** · 2024/02/12(月) 20:44:24.28

>>682
そのフレームワークがデザインパターンで出来てるんだけど

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

アルゴリズムはライブラリを一個作れば終わり
もう一個作ったら車輪の再発明
だがデザインのレベルではワンパターンが続いてもなぜか攻撃されない

**デフォルトの名無しさん** · 2024/02/12(月) 21:59:54.43

>>673 >>677
c++ templateは静的ポリモーフィズムのダックタイピングの代表例だろ……

Rustのgenericsはどれくらいダックタイピングできているかね。

**デフォルトの名無しさん** · 2024/02/12(月) 22:09:04.93

>>685
C++の静的ポリモーフィズムはダックタイピングではない
ダックタイピングは実行時に動的に処理されるものだけを指す

例えばGoはinterfaceでダックタイピングするが実行時にランタイムが動的にitable (interface table)を生成して用いる
これは実行時に動的に処理されるためダックタイピングとなる

もちろん実行時に動的に処理するためダックタイピングはどの言語でも問題を孕んでいる
手軽さとの引き換えだ

**デフォルトの名無しさん** · 2024/02/12(月) 22:14:48.84

C++のtemplate（concepts無し）のダックタイピングが好きなら
genericsよりmacro_rules!の方がいいよ

**デフォルトの名無しさん** · 2024/02/12(月) 22:15:23.35

C++のtemplateで正しく関数を呼ぶの難しいよ……

**デフォルトの名無しさん** · 2024/02/12(月) 22:30:02.58

>>677
静的型付けの意味から解説せなあかんのんか？
勘弁してくれよ

**デフォルトの名無しさん** · 2024/02/12(月) 22:30:58.32

C++はちゃんとコンセプト使わないとだめだよ
黒魔術は禁止です

**デフォルトの名無しさん** · 2024/02/12(月) 22:50:06.45

C++のテンプレートは闇深すぎるよね

**デフォルトの名無しさん** · 2024/02/12(月) 22:50:36.74

>>686
C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。
一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。

**デフォルトの名無しさん** · 2024/02/12(月) 22:54:09.63

>>685
Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる

**デフォルトの名無しさん** · 2024/02/12(月) 23:33:02.01

>>692
ダックタイピングの言い回しに前例はなくても原因はあるんだろう
そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある

**デフォルトの名無しさん** · 2024/02/12(月) 23:52:54.50

委譲やダックタイピングを理解してないのもどうかと思ったけど
↓これらの区別ができてないのは致命的だと思うので勉強しようね

静的型付け/動的型付け
静的ポリモーフィズム/動的ポリモーフィズム
静的処理/動的処理

**デフォルトの名無しさん** · 2024/02/13(火) 00:30:00.87

確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？

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

ファクトチェック界隈では事実かデマかが確固たる論点だよね
公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ

**デフォルトの名無しさん** · 2024/02/13(火) 03:26:01.95

オレオレ定義で擬似問題作るの止めろ。

ダックタイピングについてはWikipediaの解説でいいか。
ja.m.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0
英語版が一番詳しいかね。

**デフォルトの名無しさん** · 2024/02/13(火) 07:31:17.64

>>683
フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある
結局パターン通りに作る云々が論じられるのはフレームワークを使う側

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

>>699
アンチパターンや亜種になるだけで全部パターンだぞ

**デフォルトの名無しさん** · 2024/02/13(火) 08:30:13.65

はじめにパターンありき、ではない

**デフォルトの名無しさん** · 2024/02/13(火) 09:29:40.48

ダックタイピングはお手軽さを上回るデメリットだらけの悪手法
問題もなく安全で高速なRustのトレイト方式が最善策
トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所

**デフォルトの名無しさん** · 2024/02/13(火) 10:20:47.32

うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？

**デフォルトの名無しさん** · 2024/02/13(火) 10:23:31.22

>>703
そんなわけないでしょ

**デフォルトの名無しさん** · 2024/02/13(火) 10:29:29.95

>>703
Pythonは遅いし本質でない実行時デバッグも大変だし
速くて実行前に静的に解決できるRustがベストな言語だよ

**デフォルトの名無しさん** · 2024/02/13(火) 10:30:11.10

>>703
その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう

**デフォルトの名無しさん** · 2024/02/13(火) 10:31:44.87

>>703
その講師優秀やな

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

>>705
その講師も大概だがお前もデバッグをまともにやったことないだろ。

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

>>708
Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ

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

ここまで俺の自演

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

>>709
よっぽどレベル低いことしてない限りそこまでキツくはないわ。
むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。

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

>>703
どーせデータ分析やデータサイエンスの講師だろ
くだらない釣りやめろ

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

まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな
くだらねえほんと

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

荒らしに構った時点でお前らの負け

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

>>703が荒らし判定されてて草ww

**デフォルトの名無しさん** · 2024/02/13(火) 12:05:17.83

>>702
trait boundはgenerics と型パラメータの相互依存が重たい気が。

c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？

**デフォルトの名無しさん** · 2024/02/13(火) 12:09:09.09

わかる→　Pythonで簡単なスクリプトを書く
キチガイ→　Pythonでプログラミング開発する

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

Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ

**デフォルトの名無しさん** · 2024/02/13(火) 12:15:32.69

よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？

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

単発NG推奨

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

単発NG推奨
連鎖あぼーん推奨

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

スレNG推奨では？

**デフォルトの名無しさん** · 2024/02/13(火) 14:10:44.85

また境界知能が暴れてんのか
いい加減諦めろよ

**デフォルトの名無しさん** · 2024/02/13(火) 15:09:27.64

C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど

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

XML大嫌い

**デフォルトの名無しさん** · 2024/02/13(火) 20:34:52.16

>>716
やりたいことがよく分からないけどtraitのassociation typeで解決しない？
I: Iteratorだと要素の型はI::Item（正確には<I as Iterator>::Item）になるみたいな
C++のconceptだとtypenameに相当するのかな

traitにgenericsの型パラメータ持たせるかassociation type使うかの判断は慣れるまで難しいけど
選択肢が複数あって外部から決められる　⇒　generics型パラメータ（例：AsRef<T>）
traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target）
みたいに使い分けるといい
全部をgenericsの型パラメータでやろうとするとカオスになる

**デフォルトの名無しさん** · 2024/02/13(火) 21:06:36.86

>>716
できる
例えばこのように

https://docs.rs/hyper/latest/hyper/service/trait.Service.html

pub trait Service<Request> {
　type Response;
　type Error;
　type Future: Future<Output = Result<Self::Response, Self::Error>>;
　
　// Required method
　fn call(&self, req: Request) -> Self::Future;
}

ここで型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタResponseは依存しない

>>726
その二種類の混合も可能

**デフォルトの名無しさん** · 2024/02/13(火) 21:08:42.27

ごめん
>>727はこうね

型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタRequestは依存しない

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

ちょっと違うなぁ。

c++ template & conceptだと
wandbox.org/permlink/74j79ZQ3mbPb2cLO
みたいな感じでCircleはf()の影響を受けずに独立させることができる。
draw()メソッドというダックテストを満たせば他はどうでも良い。

Rustのgenericsだと
wandbox.org/permlink/CvepQKXOXaNTJoJm
みたいにCircleとf()の間にtrait Dという相互依存ができて、Circleを好き勝手に定義できなくなる。

f()が欲しいのはあくまでdraw()メソッドだけだから、双方にtrait Dが必要になるのは過剰な相互依存になる。
クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。

**デフォルトの名無しさん** · 2024/02/13(火) 23:17:32.55

それはgeneric constraintがnominalかstructuralかという違い
Rustはnominalのみでstructural generic constraintはサポートしてないよ

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

Pythonは全てにおいてJuliaに劣った言語だな

**デフォルトの名無しさん** · 2024/02/13(火) 23:28:47.57

>>729
Circleを
fn f<T: Drawable>(t: &T) -> f64 { t.draw() }
に渡したいなら普通に
impl Drawable for Circle {
fn draw(&self) -> f64 { <Circle as D>::draw(self) }
}
を追加するな
コントラクトの明示を余計な依存関係だとは思わない

ちなみに
impl Circle {
fn draw() -> f64 {...}
}
みたいに本体のimplに定義するとCircleのself.draw()は全部こっちで解決されるから
impl Drawable for Circle {
fn draw(&self) -> f64 { self.draw() }
}
って書ける

１つの型に複数のtraitで同じ名前の関数を持たせるのはRustだとたまに見かける
impl Debugとimpl Displayはどっちもfn fmt()で別の実装するし

**デフォルトの名無しさん** · 2024/02/13(火) 23:28:48.94

>>726
>traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target）
ある型に対するtrait実装をただ一つだけにしたいものや
自然と一つだけになるような性質のものはassciated typesを使う

使う側はassociated typesのほうが使いやすいので
悩んだらとりあえずassociated typesからはじめてみる

**デフォルトの名無しさん** · 2024/02/13(火) 23:30:39.22

>>729
そこはtrait介在させなきゃいけないところでしょ
Rustの方針が正しいと思うよ

**デフォルトの名無しさん** · 2024/02/13(火) 23:32:24.97

traitとかいうつまらない機能にこだわってないでPython極めろよ
時代はAIだぞ

**デフォルトの名無しさん** · 2024/02/13(火) 23:35:00.89

>>735
Rustをただ貶したいだけのやつは黙っとけよ雑魚

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

Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。
比較で持ち出すならせめてNimにしろよ。

**デフォルトの名無しさん** · 2024/02/14(水) 05:28:01.52

>732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。

まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。

**デフォルトの名無しさん** · 2024/02/14(水) 06:58:38.09

>>738
>>これはRustが嫌っているクラスの継承みたいなもの

クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない

**デフォルトの名無しさん** · 2024/02/14(水) 07:00:00.30

自演きもいなあ

**デフォルトの名無しさん** · 2024/02/14(水) 07:00:27.71

実装継承はゴミ

**デフォルトの名無しさん** · 2024/02/14(水) 07:05:57.04

>>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い

**デフォルトの名無しさん** · 2024/02/14(水) 07:33:52.24

>>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。

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

>>742
実運用はビルド済だから関係ないな。

**デフォルトの名無しさん** · 2024/02/14(水) 08:09:58.02

>>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない

**デフォルトの名無しさん** · 2024/02/14(水) 08:41:45.06

>>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ

**デフォルトの名無しさん** · 2024/02/14(水) 08:51:32.74

>>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる

**デフォルトの名無しさん** · 2024/02/14(水) 08:55:57.66

>>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。

**デフォルトの名無しさん** · 2024/02/14(水) 09:07:35.89

真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ

**デフォルトの名無しさん** · 2024/02/14(水) 09:20:06.07

>>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか

Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな

**デフォルトの名無しさん** · 2024/02/14(水) 09:36:07.02

>>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね

**デフォルトの名無しさん** · 2024/02/14(水) 09:47:17.10

>>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装することで結果的に各機能の合成となる

**デフォルトの名無しさん** · 2024/02/14(水) 09:59:07.19

細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う

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

>>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。

>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？

**デフォルトの名無しさん** · 2024/02/14(水) 10:17:10.59

ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ

**デフォルトの名無しさん** · 2024/02/14(水) 10:27:45.39

>>738
言語側のサポートならマクロで十分でしょ

macro_rules! impl_drawable {
($type:ty) => {
impl $crate::path::to::Drawable for $type {
fn draw(&self) -> f64 { self.draw() }
}
}}

を定義すれば

impl_drawable!(Circle);

だけでimpl Drawable for Cirle {...}を生成できる
渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング
Drawableに関数を追加したらマクロにも追加すればいい

draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい
impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる

**デフォルトの名無しさん** · 2024/02/14(水) 10:44:54.87

ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう

**デフォルトの名無しさん** · 2024/02/14(水) 10:53:25.15

>>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ

**デフォルトの名無しさん** · 2024/02/14(水) 11:07:38.32

使う側が気をつけるならC++も問題ないからな

**デフォルトの名無しさん** · 2024/02/14(水) 11:17:22.43

>>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター

**デフォルトの名無しさん** · 2024/02/14(水) 11:23:15.20

>>759
そゆこと
だからRustは不要

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

ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない

**デフォルトの名無しさん** · 2024/02/14(水) 11:51:49.92

ここで>>9-20の流れを振り返ってみましょう

**デフォルトの名無しさん** · 2024/02/14(水) 11:52:42.46

C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば

fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}

みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。

**デフォルトの名無しさん** · 2024/02/14(水) 12:13:59.14

>>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん

>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする

**デフォルトの名無しさん** · 2024/02/14(水) 12:19:27.37

>>761
だからの文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。

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

>>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。

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

>>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している

**デフォルトの名無しさん** · 2024/02/14(水) 12:49:07.16

>>768
自明だと検証できる証明を示して頂戴。

検証可能性の無い主張は単なる疑似科学だし。

**デフォルトの名無しさん** · 2024/02/14(水) 12:52:16.39

欠点がない言語なんて無いから言い争ってもね。

**デフォルトの名無しさん** · 2024/02/14(水) 12:57:57.69

そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明

**デフォルトの名無しさん** · 2024/02/14(水) 13:07:28.33

たし🦀

**デフォルトの名無しさん** · 2024/02/14(水) 13:09:31.24

おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき

**デフォルトの名無しさん** · 2024/02/14(水) 13:16:05.40

drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ

**デフォルトの名無しさん** · 2024/02/14(水) 13:33:10.33

境界知能が可視化されてる

**デフォルトの名無しさん** · 2024/02/14(水) 13:53:52.28

>>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。

**デフォルトの名無しさん** · 2024/02/14(水) 13:55:32.21

>>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ

ダックタイピングは白紙の契約書にサインするようなものだ

**デフォルトの名無しさん** · 2024/02/14(水) 13:57:04.55

>>775
お前のこと？

**デフォルトの名無しさん** · 2024/02/14(水) 14:31:04.48

>>777
これな

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

>>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……

**デフォルトの名無しさん** · 2024/02/14(水) 15:12:12.70

>>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな

**デフォルトの名無しさん** · 2024/02/14(水) 15:36:36.14

>>764
Rustで++は排除されている

理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな