Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/06/04(木) 13:20:58.04

難しいのはネストした場合のオブジェクトに対するイミュータブルかどうかとライフタイムだろう。

**デフォルトの名無しさん** · 2020/06/04(木) 14:06:07.27

ライフタイムはコンパイラが親切丁寧に指摘してくれるから難しくは無いだろ
依存関係とか指摘出来ない系のエラーで詰まる事のが多い

**デフォルトの名無しさん** · 2020/06/04(木) 19:40:21.91

>>647
コンパイラに指摘されれば問題ないかというと総でも無い。
プログラミングはコンパイルする前に予想可能で無いと困る。

**デフォルトの名無しさん** · 2020/06/04(木) 20:10:09.15

競馬かな？

**デフォルトの名無しさん** · 2020/06/04(木) 20:37:04.46

>>648
難しくないってのは「学習は」難しくないって話じゃね？
いずれは自分でわかるようになるというのは当然の前提で、
まあわかるようになっても間違えることはあるのでそれを指摘してくれるのもありがたい。

**デフォルトの名無しさん** · 2020/06/04(木) 22:06:35.88

>>650
ところが、コンパイラを実際に動かさなくても、仕様書や例を見ただけで
理解できる言語も多いんだよ。
たとえば、CやBASIC,JS,Java,C#,Ruby,Python,Perlなどがそれに該当する。
C++は、03まではまあ分かったが、だんだん難しくなっていった。
もはやSTLのソースも仕様書ですらも理解できるのは一部の特殊な人に
限定されてきているかも知れない。STLの
forward()の意味を理解したりどう実装されているかをソースを見て理解できる
る人は本の一握りだろう。
move()とforward()の役割の違いも実装レベルでどれだけの人間が理解できることか。
でもRustも同じように難しくて同じようなことは起こると考えている。

**デフォルトの名無しさん** · 2020/06/04(木) 22:49:18.31

そのレベルで理解できてない人がC++使うのはどういうメリットがあるのだろうか

**デフォルトの名無しさん** · 2020/06/04(木) 22:52:33.61

実はC++は、forwardやmove, templateなどの詳細を理解できてなくても高級言語的な部分だけを使ってプログラムすることは出来る。
それはRustでも同じ。

**デフォルトの名無しさん** · 2020/06/04(木) 23:01:33.43

C++は仕様が難しいというより
仕様ではないけど当然知ってるべきイディオムが
たくさんあってきつい、という感じがするな。

**デフォルトの名無しさん** · 2020/06/05(金) 01:02:20.04

将棋しか知らない人が囲碁というゲームを見ると
何やってるかわからないしなんだかむずかしそうと言う
しかし実は囲碁はルールそのものはおそろしくシンプルなのだ
ところがルールだけ知っていても、囲碁は打てない
(打てるけど次に何していいかわからなくなる)
なぜなら囲碁はルールとは別に「こういう場面はこういう風に
打ち回す」というイデォムが大量にあってそれを知る必要があるからだ
C++はそれに似ている

**デフォルトの名無しさん** · 2020/06/05(金) 01:41:15.67

そもそもRustの仕様って難しいか？
いろんな言語から取り込んだ概念があって
C一筋とかRuby一筋みたいな人には学ぶべきことが多いとは思うけど、
特に複雑な仕様って思い当たらないんだけどな。
JSの型変換の仕様とかの方がよっぽど複雑だしワケわからんと思う。

**デフォルトの名無しさん** · 2020/06/05(金) 09:30:38.65

>>651
C が仕様や例で理解できるってどんな超人だよ。
コンパイルエラーにも実行時エラーにもならない未定義だの処理系定義だのが山もりだろうが。
初心者の書くコードで完全に仕様に沿ったコードなんて見たことないぞ。

**デフォルトの名無しさん** · 2020/06/05(金) 09:38:30.26

Haskell の入門書を一通りは読んでたから Rust の型システムは似たようなものとして理解できたなぁ。
ライフタイムもプログラムの字面に書きこそしないでも C/C++ では意識せざるを得ないし、
複雑になるとわけわからんってときは C/C++ で書いてもわけわからんようになるやつ。

**デフォルトの名無しさん** · 2020/06/05(金) 12:01:32.43

きっとそういう感じでべた褒めする人が多いから、Rubyみたいに一回大人気言語になった後、急速に衰退する気がする。
Rubyも最初は良いと思われていた。

**デフォルトの名無しさん** · 2020/06/05(金) 12:13:12.11

>>657
Cの仕様はシンプルで、
ポインタと明示的な型宣言と文字列比較をstrcmp()で行うという以外、
基本的な枠組みは既存の言語と変わりはなかったので理解は難しくなかった。

**デフォルトの名無しさん** · 2020/06/05(金) 12:14:22.73

Ruby は今でも十分に使われているよ。 (俺は使ってないけど。)
適切ではないところまで広がった分がそぎ落とされてちょうどいい感じに落ち着いたってだけ。
プログラミング言語の良さはスカラ値で測定できるようなものではなくて、用途による。
利用事例が減ったからといってその勢いで衰退して消えるっていうような話ではない。

Rust はまだ実際のプロダクトでどう使うのが適切なのか見極め切れていないから過剰に広まっている
というのはあると思うが、少なくとも C/C++ で問題だった部分を解決したという側面はある。
そんでそのかわりに出てきた問題ももちろんあるので両方を天秤にかけて判断する材料を集めているとこって感じ。

**デフォルトの名無しさん** · 2020/06/05(金) 12:15:46.52

>>660
うん。 C がシンプルで理解しやすいと思い込みやすい言語なのは俺も知ってる。

**デフォルトの名無しさん** · 2020/06/05(金) 12:32:15.42

Google Trends によれば、検索数の増加曲線はほぼ kotlinと同じ位。
ただし、kotlinは、2017/05に急激に上がってRustと重なりあった曲線になったのに対し、Rustは、2014/01に急激に上がった後、徐々に増えている感じ。
Rustはこの1年くらいでわずかに増加速度がKotlinより上がったが、それでもKotlinの曲線とほぼ重なった状態からは脱してはいない。

**デフォルトの名無しさん** · 2020/06/05(金) 12:34:07.49

>>662
匿名性掲示板では何でも言えてしまうが、実績を見れば俺がちゃんとCやC++を使いこなしていることは分かる。
ただし、C++は一度学んでも仕様が大幅に変更されるので、細かいところを理解するのは時間が掛かるようになってきている。
Cはそんなことはなかったが。

**デフォルトの名無しさん** · 2020/06/05(金) 12:58:47.64

もしかして伝説のスーパーハカーさんですか！？

**デフォルトの名無しさん** · 2020/06/05(金) 13:22:50.72

chronoつかってるんだけど、このyearってなんでi32なの？

https://docs.rs/chrono/0.4.11/chrono/offset/trait.TimeZone.html#method.ymd
fn ymd(&self, year: i32, month: u32, day: u32) -> Date<Self>

**デフォルトの名無しさん** · 2020/06/05(金) 13:32:05.31

>>664
仮に C や C++ を使いこなせているとして、
使いこなせている言語よりも使いこなせてない言語の方が難しいに決まってるじゃないの。
あなたはそうなんですねってだけ。

**デフォルトの名無しさん** · 2020/06/05(金) 13:35:12.28

>>666
符号付きなのがなんでってこと？
month や day はマイナスになる意味はないけど、
年はマイナス (紀元前) を扱いたいこともあるんじゃね。
知らんけど。

**デフォルトの名無しさん** · 2020/06/05(金) 13:44:02.67

合ってんじゃね？
知らんけど。

**デフォルトの名無しさん** · 2020/06/05(金) 14:06:52.05

C++の仕様が大幅に変更されたというのは
なんのことだ？

**デフォルトの名無しさん** · 2020/06/05(金) 14:17:19.64

>>670
有る意味では僅かな修正であっても、基礎的な部分における修正は多大な影響を及ぼすことがある。
moveを出来るようにするために追加されたもろもろの事や、=を書かないタイプの{}
による初期化はそれに該当する。
なんでも無いようでいて、可読性を下げたり危険をもたらすことがある。

**デフォルトの名無しさん** · 2020/06/05(金) 14:41:22.49

>>662
Cほどシンプルな言語もないだろ。それと簡単に使いこなせるかは別問題。

**デフォルトの名無しさん** · 2020/06/05(金) 14:48:48.89

>>671
それ仕様の変更なの？

**デフォルトの名無しさん** · 2020/06/05(金) 14:55:26.22

>>666
そこに書いとるやん
This assumes the proleptic Gregorian calendar, with the year 0 being 1 BCE.

つまり-1は2 BC

**デフォルトの名無しさん** · 2020/06/05(金) 15:08:35.22

Cのプリプロセッサやパーサーを書くと全然シンプルじゃないことが分かる

**デフォルトの名無しさん** · 2020/06/05(金) 15:11:02.16

>>675
それは、使う側にはシンプルそうに見えるCも実は細かく見るとシンプルではないということであって、使う側目線で既に複雑なものはそれ以前の問題他。

**デフォルトの名無しさん** · 2020/06/05(金) 15:43:45.14

依存先より寿命が長くなってはいけないなんていうのは C でも当たり前のことだろ。
Rust のライフタイムはライフタイムを簡単に「表現 (したものをチェック)」する言語機能であって、
C でプログラマがやってる (はずの) ライフタイムの管理より複雑ということはない。

Rust なら処理系がチェックしてくれることを
C ではプログラマがやってたんだぞ。
C で出来てたことが Rust ではやれないってのは言語のせいか？

Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
複雑だとか学習難易度が高いというのは納得しかねる。

**デフォルトの名無しさん** · 2020/06/05(金) 15:54:02.73

>>677
>Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
>複雑だとか学習難易度が高いというのは納得しかねる。
一つあるとすれば、難しさは、ちゃんと本も読んでいるか、ネットに書かれている情報だけに頼っているかの違いに起因している可能性。

**デフォルトの名無しさん** · 2020/06/05(金) 21:26:05.32

これにて、このスレがRust関連の本の作者の巣窟であることが証明されました。

**デフォルトの名無しさん** · 2020/06/05(金) 21:32:24.36

だいぶ前からじつは言語系のスレはほとんどソレなんだな
宣伝してるやつは気付かれれないと思ってるだろうけど

**デフォルトの名無しさん** · 2020/06/05(金) 21:49:15.38

>>618
2018/11/28の時点で、

https://www.infoworld.com/article/3324488/rust-language-is-too-hard-to-learn-and-use-says-user-survey.html
ユーザーの調査によると、Rust言語は習得も使用も難しい
Rustユーザーの調査では、メモリの安全性と正確性のためにこの言語の非常に宣伝されている機能に困難と不満を感じています
Rust言語チームが実施したRustユーザーコミュニティの新しい調査では、言語とその使用への関心が高まっていますが、プロジェクトが利点として宣伝しているいくつかのRust機能に対するユーザーの不満も示されています。
Rustの習得が難しいのはなぜですか？ユーザーは、Rustの最も特徴的な2つの機能（寿命と所有権/借用システム）は、「トリッキー」、「非常に難しい」、または「まだ得られない」ものであると報告しました。
その他の質問は、Rustを続行するための課題を中心に展開されました。Rustの使用をやめた人の約半分は、わずか1か月後にそうしました。Rustを使用していない最も一般的な理由は、「威圧的すぎる、習得が難しい、または複雑すぎる」（25％）、

**デフォルトの名無しさん** · 2020/06/05(金) 22:00:56.76

Rust言語は、学んだり使ったりするのが難しすぎるということが、ユーザーに対する調査で分かった。
--Rustユーザーに対する調査では、安全性と正確性のために言語が非常にうるさく押し付けてくる特長により困難と欲求不満を感じていることが分かった。

Rust language is too hard to learn and use, says user survey
A survey of Rust users finds difficulty and frustration with the language’s highly touted features for memory safety and correctness.

tout = 押し売りする, うるさく勧誘する, 客引きする
(tout for custom うるさく注文を求める.)
・切符をプレミア付きで売る, ダフ屋をやる.
・うるさく勧める.
・ほめちぎる.

**デフォルトの名無しさん** · 2020/06/05(金) 22:04:18.63

誤:安全性と正確性のために言語が非常にうるさく押し付けてくる特長
誤:安全性と正確性のために言語が非常にうるさく押し付けてくる機構(機能)

**デフォルトの名無しさん** · 2020/06/05(金) 23:15:24.59

>>674
へー。西暦にゼロ年っていうのは無いのか。

**デフォルトの名無しさん** · 2020/06/06(土) 04:00:23.67

この言語廃れてきそうな気がした。
だってみんなが触るって未来が想像できないもん

**デフォルトの名無しさん** · 2020/06/06(土) 04:10:18.67

みんなが触る言語なんて世の中に存在するか？

**デフォルトの名無しさん** · 2020/06/06(土) 05:29:47.06

Rustを使ったことはないけどC++は既存の資源で堅実に作るのに対して
Rustは一人のスーパープログラマが複雑高度なライブラリやモジュールを一点突破で書くのに使われそうなイメージ

**デフォルトの名無しさん** · 2020/06/06(土) 09:51:25.89

まあScalaと同じ道を辿るだろうね
あっちはビッグウェア系でそれなりに採用されてたから被害が甚大だったけど、
Rustに関してはそういうビジネス的な得意分野は今のところ無いのが救いか

**デフォルトの名無しさん** · 2020/06/06(土) 15:58:34.19

>>687
ところがスーパープログラマは、C++でもメモリー関連のバグで詰んで挫折したりすることはないんだな、これが。

**デフォルトの名無しさん** · 2020/06/06(土) 17:06:05.01

>>687
Rust の偉大さのひとつには crates.io の存在がある。
資源の利用という意味じゃ Rust はかなり積極的だぞ。

**デフォルトの名無しさん** · 2020/06/06(土) 17:17:15.77

C++は標準のライブラリリポジトリと標準のビルドツールがあればなぁ、と思う。
野良のは乱立してるけど、結局ほしいライブラリはなかったりするし…。

**デフォルトの名無しさん** · 2020/06/06(土) 17:37:45.92

>>688
MicrosoftもAppleも使っていくのに爆死したら
IT業界壊滅じゃね

**デフォルトの名無しさん** · 2020/06/06(土) 18:11:03.05

>>691
各環境のパッケージマネージャに乗っかってることが多いからある意味では一等の地位ともいえる。
メジャーなものは apt-get とか pacman とかで一発で入るだろ。

**デフォルトの名無しさん** · 2020/06/06(土) 18:38:18.22

>>690
crates.ioがダメダメだから代替のサイトあるのってご存知でない？

**デフォルトの名無しさん** · 2020/06/06(土) 18:42:21.81

Webサイトの話をしてるわけじゃないだろ

**デフォルトの名無しさん** · 2020/06/06(土) 18:56:38.50

>>691
漏れは、Windows 10, WSL, Ubuntu 18.04 で、
anyenv(rbenv)で、Ruby をコンパイルするのに、build-essential を使っているけど

build-essential には、
gcc(GNU C compiler), g++(GNU C++ compiler), libc6-dev(GNU C Library), make などが入っています

パッケージ: build-essential
https://packages.ubuntu.com/ja/bionic/build-essential

**デフォルトの名無しさん** · 2020/06/06(土) 19:37:13.44

>>693
結局それってディストリビューション依存だからなぁ。
バージョンだって固定できないし、OSS拾ってきてコンパイルが通るようにするだけで試行錯誤が必要。

>>696
いや、頑張って環境構築すればなんとかなるのはその通りだけど、
別のソフトだとまた別の環境構築が必要になって辛いのです。

**デフォルトの名無しさん** · 2020/06/06(土) 21:37:30.50

Rustでプロキシーサーバー実装してみようと思ったんだけどTCPStreamとreqwest::headerの連携がうまくいかない

**696** · 2020/06/06(土) 22:21:08.03

漏れは、日本人が作った、バージョンマネージャーのanyenv で、
rbenv, nodenv を使って、ruby 2.6.6, node 12.16.2 を入れた

環境構築が、各言語でバラバラになるのは面倒なので、
anyenv・asdf などを使えば？

**デフォルトの名無しさん** · 2020/06/06(土) 23:04:13.04

hyperのサンプルに答えがありました

**デフォルトの名無しさん** · 2020/06/07(日) 00:03:49.64

こんな書き込みを見つけた：
loop {
// 1. you finally understood lifetimes
// 2. you get compiler lifetime /borrow complaints
// 3. you feel stupid for taking hours to fix <5 LoC
}

**デフォルトの名無しさん** · 2020/06/07(日) 00:19:04.85

ループ {
// 1. あなたはついに lifetime を理解した。
// 2. あなたはコンパイラに lifetimeやborrow の苦情を複数個言われる。
// 3. 5行未満のコードを直すのに何時間もとられることにあなたは馬鹿馬鹿しさを感じる。
}

**デフォルトの名無しさん** · 2020/06/07(日) 11:58:43.41

コンパイラに緊縛されて未定義動作を踏まないという快感を得るプレイ

**デフォルトの名無しさん** · 2020/06/07(日) 17:57:12.72

Rsutって、早い話が、CやC++に、NULLバグ等々が発生しないようにするための補助機能がついた言語ってこと？

**デフォルトの名無しさん** · 2020/06/07(日) 18:44:36.11

そうだね～、で、俺様はNullチェックは忘れないしダングリングポインタなんて組み込まないのでC/C++で良いや
という俺様スパハカがゴミグラムを生み出してきたのでRustは必須

**デフォルトの名無しさん** · 2020/06/07(日) 18:48:57.09

>>704
書き方がC/C++の文化とはかけ離れているように感じるが。

**デフォルトの名無しさん** · 2020/06/07(日) 19:46:37.12

>>706
いや、言語誕生の思想を考えただけです。
言語誕生の思想をきちんと抑えないと、メリットとデメリットを正答に評価出来ないから

**デフォルトの名無しさん** · 2020/06/07(日) 19:59:02.69

どっちかというと「関数型C++」な印象

**デフォルトの名無しさん** · 2020/06/07(日) 22:51:27.97

Hindley-Milner 型推論を元にしているから考え方は ML 系統からの影響は大きいと思う。

**デフォルトの名無しさん** · 2020/06/08(月) 02:06:14.90

C++の地獄をML（とアフィン型）の知見で楽にしようとした言語

Cの遺産を引き摺ったが故に煩雑だった前者の記法を捨てて後者のいいとこを貰ってきたので、記法が後者に似てるように見えはするけど、やってる事はそう大きく変わってはいない

**デフォルトの名無しさん** · 2020/06/08(月) 10:53:34.76

「C++ のメンバ関数の実態は this を暗黙に渡しているだけ」ってのを露骨にしたのも Rust の面白い部分だよね。
関数的な意味論を用いながらも構文糖としてのメソッド記法も用意することでオブジェクト指向的な表現が出来る。

**デフォルトの名無しさん** · 2020/06/08(月) 13:11:59.47

RustはC++ではゼロコストで出来ていたものが、出来なくなってしまっていることが多い。

**デフォルトの名無しさん** · 2020/06/08(月) 13:14:25.82

>>712
具体的には？

**デフォルトの名無しさん** · 2020/06/08(月) 13:19:16.88

関数的な意味論ねぇ
表層的に一部それっぽいってだけでは？

**デフォルトの名無しさん** · 2020/06/08(月) 13:28:01.70

言語として純粋関数型に分類される Haskell ですら
オブジェクト指向のスタイルで構築されたライブラリは有るから……。
(そのためのフレームワークである lens はまあまあ人気。)

言語仕様での理屈がどうあれ最終的には使い方次第。

**デフォルトの名無しさん** · 2020/06/08(月) 13:36:41.82

>>713
言うと改善されるので言わない。

**デフォルトの名無しさん** · 2020/06/08(月) 13:46:18.64

memmove()すらunsafeなしではかけないし。

**デフォルトの名無しさん** · 2020/06/08(月) 13:53:57.25

RustではpChildがHeapにとられている時、次のようなループすら書けない。
CPerson *pChild=pPerson->pChild;
while(pChild != NULL) {
(pChildに対する処理);
pChild=pChild->pNext;
}

**デフォルトの名無しさん** · 2020/06/08(月) 14:30:52.23

>>718
こういう感じのこと？

#[derive(Default)]
struct Person {
pub childs: Box<[Person]>
}

fn main() {
let person : Person = Default::default();
let childs = person.childs;
for ref child in childs.iter() {
// child に対する処理
}
}

**デフォルトの名無しさん** · 2020/06/08(月) 14:39:32.30

>>719
Heap領域にある構造体の中に、さらにHeap領域にあるデータへの
参照を持つためにBox型のメンバが有る場合、後者のBoxは、unique_ptrなので
ローカル変数にmoveすることができないためコンパイルエラーになる。
なので、参照カウント方式のRcを使う必要がある。

**デフォルトの名無しさん** · 2020/06/08(月) 14:44:31.30

>>719 の場合だと personがスタック領域にあるが、もしそれがHeap領域に
あったとすると、
let childs = person.childs;
とするとエラーになるはずだ。

**デフォルトの名無しさん** · 2020/06/08(月) 14:48:41.29

>>721
ならない。

　　　　　　(完)

**デフォルトの名無しさん** · 2020/06/08(月) 14:53:38.92

チュートリアルも読まない難癖おじいちゃんの相手すんなし

**デフォルトの名無しさん** · 2020/06/08(月) 14:56:15.14

そもそも、
struct Person {
　pub child: Box<[Person]>
}
がおかしくて、正しくは、
struct Person {
　pub child: Box<Person>
　pub next: Box<Person>
}
だ。

**デフォルトの名無しさん** · 2020/06/08(月) 14:56:44.39

>>722
全く同じではないが、こっちの環境ではなったがな。

**デフォルトの名無しさん** · 2020/06/08(月) 14:58:43.87

後付けやめろよ。
C++ のどういうコードを Rust でどう書けて欲しい (そして実際にはどういうエラーになる) のかちゃんと書け。

いや、書くな。 (どうせ見当違いなので。)

**デフォルトの名無しさん** · 2020/06/08(月) 15:03:12.27

>>725
#[derive(Debug)]
struct TAaa {
　　x: Box<i32>,
　　y: i32
}
fn main() {
　　let mut vec:Vec<TAaa> = Vec::new();
　　vec.push( TAaa {
　　　　x : Box::new(333),
　　　　y : 444
　　} );
　　let　　 x　 = vec[0].x;　// error[E0507]: cannot move out of index of `std::vec::Vec<TAaa>`
　　println!("{:#?}", x);
}
↑のように vec をHeapに確保した場合、エラーになる。
ところが、stackに確保した場合はエラーにならない。
実験済み。

**デフォルトの名無しさん** · 2020/06/08(月) 15:04:31.00

>>726
海外のサイトでも、RustはC/C++から単純移行ができ無い事が問題とされている。
FortranからCへは単純移行が出来たからCが普及したと書いてあった。

**デフォルトの名無しさん** · 2020/06/08(月) 15:16:36.76

>>726
後付ではない。
C++で、pChild、pNextと言えば、当然そういう構造体になる。

**デフォルトの名無しさん** · 2020/06/08(月) 15:47:14.20

>>727
型・寿命・所有権の条件が同じならヒープかスタックかというのは関係ない。
お前が結果的に違う条件で書いるだけ。

>>728
知らんがな。
同じように書けるんなら新しい言語を導入する意味ないだろ。
制約が厳しい替わりに問題点が検出されやすいのが Rust の利点なんだから、
その利点が要らんなら別に Rust を使わんでいいよ。

**デフォルトの名無しさん** · 2020/06/08(月) 16:43:05.54

>>730
>型・寿命・所有権の条件が同じならヒープかスタックかというのは関係ない。
>お前が結果的に違う条件で書いるだけ。
1.実験してみたところ、>>727でBoxをRcに変えてもエラーのままだった。
2.単純にTAaaをスタックに確保した場合、正常にコンパイルされた。
3.TAaaを以下のようにHeapに確保した場合も、正常にコンパイルされた：
fn main() {
let bbb = Box::new( TAaa {
x : Box::new(333),
y : 444
} );
println!( "bbb = {:#?}", bbb );
println!( "bbb.x = {:#?}", bbb.x );
println!( "let x = bbb.x;" );
let x = bbb.x;
println!( "x = {:#?}", x );
}
つまり、Vec<TAaa>の場合にだけエラーになる。

**デフォルトの名無しさん** · 2020/06/08(月) 16:57:23.12

>>731
ついでに言えば >>727 のエラーが出る行を

let ref x = vec[0].x;

とか

let x = vec.swap_remove(0);

とか

let x = vec[0].x.clone();

とかすることでもコンパイルは通る。

**デフォルトの名無しさん** · 2020/06/08(月) 17:21:28.18

>>732
>let x = vec.swap_remove(0);
let x = vec.swap_remove(0).x
のことかな?

**デフォルトの名無しさん** · 2020/06/08(月) 17:33:12.05

rustじゃ書けないおじさんのコードを添削する流れ、何度目だ

**デフォルトの名無しさん** · 2020/06/08(月) 18:00:02.94

std::mem::take

**デフォルトの名無しさん** · 2020/06/08(月) 18:06:13.25

>>733
おっと、せやな。
.x が無くてもコンパイルは通ってしまうからミスったわ。

**デフォルトの名無しさん** · 2020/06/08(月) 18:15:14.24

ID真っ赤、お顔も真っ赤ｗ

**デフォルトの名無しさん** · 2020/06/08(月) 18:20:45.97

>>734
ワイも初心者ではあるんよ。
The book (第二版の日本語訳の無料で読めるやつ) を読み終わって、試しに 500 行くらいのコードを書いてみたって程度。
本を読んでいる間はコードを書いてない。
手を動かすと理解しやすいという人も多いけど、
感覚でやってしまいがちで書いてある理屈をしっかり把握するのが疎かになる気がするから。

で、 The book を読めばこの程度には理解できるので理解できてないやつは単にアホという証明でもあるし、
逆に返答に詰るようなら俺がまだ入門級のことが理解できてない (どこが理解できていないか) ことがわかるので
練習の題材としてちょうどいいわという気持ちで相手してた。

**デフォルトの名無しさん** · 2020/06/08(月) 18:37:00.38

>>738
では、>>732 で
>let ref x = vec[0].x;
の borrow が合法かどうか、どうやってコンパイラが静的に解析しているか
アルゴリズムを説明してみてください。

**デフォルトの名無しさん** · 2020/06/08(月) 21:16:08.81

>>739
let ref というのは直接的には The book に出てこないと思うけど、
let もパターンマッチだということはタプルの項目で示されている。
たとえば let a = &1; と書いたら a には 1 の参照が入るし、
let &a = &1; と書いたら a は (参照を経由する) 値になる。

参照にマッチするのではなく値にマッチさせた上で参照が欲しいときに使うのが
ref であるということは match の説明の中にある。
つまりこの場合に let ref x = vec[0].x; というのは
let x = &(vec[0].x); と書くのと理屈は同じ。

**デフォルトの名無しさん** · 2020/06/08(月) 21:34:44.64

公式で丁寧にしかも無料で公開されてる本もろくに読めないガイジたちがわらわらするスレになっちまったな
ちょっと名が知れ渡っただけでこんなことになんだから、一般的になったらとんでもないな

**デフォルトの名無しさん** · 2020/06/08(月) 22:57:09.22

rust+wasmちょっとやってみたけど、単純な処理に記述だけが無駄に複雑になりすぎる
組み込みとかシステム系で使われそうだけど、一般的とか言う広く色々な使われ方はしないだろコレ

**デフォルトの名無しさん** · 2020/06/08(月) 23:32:06.17

JSみたいに直接DOM触れて、直接実行できるなら普及するけど、現状のめんどくささならなぁ・・・

**デフォルトの名無しさん** · 2020/06/09(火) 00:44:22.52

>>740
それは分かっている。
iとjがループ内で変化したような場合、
vec[i].x
からmutableで借用した場合、
vec[j].x
からimmutableで借用できるかどうかの判定をコンパイラが一般的に行うのが難しいんだよ。
だからそのアルゴリズムを理解しているのかと聞いている。

**デフォルトの名無しさん** · 2020/06/09(火) 00:52:40.12

>>744
似た例で言えば、
dst[i]をmutableで借用した場合、src[i]をimmutableで借用しようとしたときに、
srcとdstが同じアドレスに被って無いかの判定が静的には物凄く難しいと
されているので、エラーになってしまうかも知れないというようなことを心配
しているんだよ。

**デフォルトの名無しさん** · 2020/06/09(火) 01:01:34.80

>>745
もっとちゃんと書くと、
src[0]～src[99]までに対して処理するような場合だと、src[i]をaに借用してから
f(a)、g(a)、h(a)に順番に渡して何か処理するようなことは出来ると思われるが、
ここに、dst[0]～dst[99]も加わって、dst[j]をbにmutableで借用
しようとすると、mutableで借用した場合にimmutableでは借用できないというルールを
この場合にはコンパイラが静的には判断できなくなってコンパイル・エラーになって
しまう可能性を心配している。

つまり、コンパイルの借用チェッカは、予めよくあるパターンに対して特別な
処理を実装している場合には通るが、一般的には判断できるわけ無いので通らない
のではないかと考えられるんだよ。