Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

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

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

日本語の情報
https://rust-jp.rs/

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

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

**デフォルトの名無しさん** · 2021/08/17(火) 15:06:36.98

Rustは例はあるが、ちゃんとした論理的な言葉や数式の様なもので、規則性が
書いてないのではない？
C++だともっと厳密に書いてある。

**デフォルトの名無しさん** · 2021/08/17(火) 15:10:48.52

>>652
何て本？

**デフォルトの名無しさん** · 2021/08/17(火) 15:11:29.96

>>656
そうではなくて、規則性を言葉で書いてくれ、ということだよ。
試してみてなんとなくの経験法則とかじゃなく。

**デフォルトの名無しさん** · 2021/08/17(火) 15:12:37.71

>>658
bookの印刷版も読んだが、途中読み飛ばしたページもあるが
読んだところにはちゃんと書いてなかったと思う。
数学的な規則が欲しいんだ。
文学的な言葉や例ではなく。

**デフォルトの名無しさん** · 2021/08/17(火) 15:13:56.74

>>657
そういう位置付けのドキュメントはこれだね
ただし冒頭にもある通り完全ではない

The Rust Reference
https://doc.rust-lang.org/stable/reference/

**デフォルトの名無しさん** · 2021/08/17(火) 15:15:28.48

>>656
まずはC++を忘れろ
思い込みは習得の邪魔になる
あるいは様々な言語をやってきていれば各言語で概念や書式や用語などが少しずつ異なることが理解できるはずだ

**デフォルトの名無しさん** · 2021/08/17(火) 15:18:24.83

>>662
めんどくさいので試してないんだよ。
試さなくても数学の用に読んで理解できる規則が欲しい。
Cのポインタは難しいとされるが、俺は数学が得意なので本を読んだだけで
完璧に理解できた。
C++探せばちゃんと書いてある本がある。

**デフォルトの名無しさん** · 2021/08/17(火) 15:23:08.50

>>661
BNFで書いてあるようだが、具体的にどこに書いてあるか示してくれ。
ちなみにBNFだと意味論までは語れ無い事があるので無理かも知れない。

**デフォルトの名無しさん** · 2021/08/17(火) 15:24:30.00

「俺は数学が得意なんだ！」
ワロタ
いつものBoxおじいさんじゃん

**デフォルトの名無しさん** · 2021/08/17(火) 15:24:31.45

目次を見てもReferenceの文字が見当たらないが。
C++だとちゃんとあるぞ。
どうしてReferenceも型のはずなのに、目次すらないんだよ。

**デフォルトの名無しさん** · 2021/08/17(火) 15:25:31.33

>>665
トップだったからな。

**デフォルトの名無しさん** · 2021/08/17(火) 15:27:48.00

>>660
そこまで言うならば十数種類あるRustドキュメントのうち、
editionとapiとstdとreferenceとtheとcookとexampleあたりにあとはcliとasyncくらいまでが基礎かな。
あと外部たがcargoとrustcにrustdocなどのbookも。
unstableやnomiconは後でいい。
wasmやembedded系bookも必要なら。

**デフォルトの名無しさん** · 2021/08/17(火) 15:28:18.82

IQ87の人でしょ
相手しちゃダメ

**デフォルトの名無しさん** · 2021/08/17(火) 15:29:44.40

>>668
なんで、この言語に置いて最も重要な型の一つの規則性がそんな何千ページもの
本を読まないと解説されてないんだよ。

**デフォルトの名無しさん** · 2021/08/17(火) 15:30:14.32

>>669
お前の友達と一緒にすんな。

**デフォルトの名無しさん** · 2021/08/17(火) 15:35:47.16

>>667
数学得意ならRustも深く理解しやすい
強い静的な型システムの元にある
そして生死貸借も明確で数学的にメモリ安全性を保証
利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない

**デフォルトの名無しさん** · 2021/08/17(火) 15:44:19.09

>>672
さっきから聞いているのに、ちゃんとした論理的規則を語った人は誰も居ない。
つまり、今このスレに居る人達は誰も理解してない証拠だろう。
つまりこれは、Rustが試してみないと分からない言語だからではないか。

**デフォルトの名無しさん** · 2021/08/17(火) 15:46:21.18

>>673
5chじゃなくて users.rust-lang.org あたりで聞いてみたら
専門家がいっぱいいるよ

**デフォルトの名無しさん** · 2021/08/17(火) 15:48:51.11

>>674
参照型はRustにとって最重要の型。
それがそんなところに質問しなければ分からないというのは困ったことだぞ。

**デフォルトの名無しさん** · 2021/08/17(火) 15:56:13.41

ポインタを理解するのにもRustを理解するのにも数学の得意不得意は関係なくね？

ポインタを理解できない人をあまり多く見たことがないから実際のところどうなのかよく分からないんだが

**デフォルトの名無しさん** · 2021/08/17(火) 15:57:56.00

>>670
どこにも記述されていないことを君が自己中心的な思い込みで間違いなく判断や間違った推測をしているから>>647や>>652の書き込みになっている
let文や呼び出し引数はirrefutable pattern matchingであり各種destruturingはあっても個々の型は対応する
Tと&Tがmatchingすることはない

**デフォルトの名無しさん** · 2021/08/17(火) 15:59:25.04

>>677
どから、それがどこに書いているのかリンクを張ってくれ。
あなたの独自説ではなく、公式のな。

**デフォルトの名無しさん** · 2021/08/17(火) 16:06:26.36

>>672
>利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない

rustではcoercionと呼んでるものが暗黙の型変換だぞ

**デフォルトの名無しさん** · 2021/08/17(火) 17:16:17.31

グリーンスレッド何それ？さんだっけ？

**デフォルトの名無しさん** · 2021/08/17(火) 17:20:32.19

公式の言葉が欲しいってならreferenceのlet statement, reference patternsあたりでもみりゃいいんじゃないっすかね知らんけど

**デフォルトの名無しさん** · 2021/08/17(火) 17:32:50.74

rustは思ったより流行りそうにないなぁ。
使用者爆発的に増えてくるハズがC++知らん人は
そもそも使う層じゃないし、
C++知ってる人は、逆にめんどくさいから様子見、流行らなければスルー
ぐらいかね。

**デフォルトの名無しさん** · 2021/08/17(火) 18:03:44.37

ぶっちゃけ1言語のみしか使えないようなプログラマが有能だとはとても思えないが
実際にそういう人はいるけど融通効かないし生産性が高いとも思えない
所詮ドカタじゃないの

**デフォルトの名無しさん** · 2021/08/17(火) 18:14:54.04

>>682
C++ で疲弊した人が Rust に移ってるってのはあるぞ。

**デフォルトの名無しさん** · 2021/08/17(火) 18:21:01.37

>>675
だからそう主張してくればよいじゃん
ここにいる人じゃ話にならないんでしょ？

**デフォルトの名無しさん** · 2021/08/17(火) 20:01:51.20

疲弊というかドロップアウター

**デフォルトの名無しさん** · 2021/08/17(火) 21:03:40.91

>>647
上３つの式は正しいのに、なんで下２つの式はそうなるのか

**デフォルトの名無しさん** · 2021/08/17(火) 21:04:44.45

>>687
見間違えた
一番下の式だけだね

**デフォルトの名無しさん** · 2021/08/17(火) 21:18:21.30

実際はc++わからんけどrustわかればマウント取れそうじゃね？って馬鹿しか手を出してないという現実。

**デフォルトの名無しさん** · 2021/08/17(火) 21:24:14.87

Rustは、GoogleTrendsでは他の言語に比べて低空飛行だけど(Kotlinと同じくらい
ではあるが)、他の言語が下がる傾向があるのに対してRustだけは少しずつ上がってる。
Stackoverflowでは既にC++の30%～40%位まで質問の量が迫ってきているとか。
なので良く分からない。
GoogleTrendsが実際と合ってないという説も見かけた。

**デフォルトの名無しさん** · 2021/08/17(火) 21:26:37.22

crates.ioでcrateをダウンロードされた回数が20億回を越えていたり、
投稿されたcrateの数が3万種類を超えたりとか。
20億回というのはとんでもない大きな数字。
全世界のプログラマの数は2,500万人くらいだそうだから相当な数だ。
良く分からないくらい異常に大きな数値。

**デフォルトの名無しさん** · 2021/08/17(火) 21:35:56.30

iocrateはきっと誰かがwhile true do; cargo build; cargo clean;doneみたいの流し続けたんだろ

c++よりマシなのは確かだがredosだかみたいの全然進まんしc++,cな代替物にはなれなさそう
tech giantsみたいな連中が根幹部分rustに変えるみたいな事言ってるけど流行ってる感じ全然しないよね(´・ω・｀)

**デフォルトの名無しさん** · 2021/08/17(火) 21:40:50.24

久しぶりに流行ってない流行らないアピールきてるね

**デフォルトの名無しさん** · 2021/08/17(火) 21:41:43.37

土方では流行らないでしょ

**デフォルトの名無しさん** · 2021/08/17(火) 21:45:28.03

リポジトリの分散化考えないとマジ負荷が半端無さそう

**デフォルトの名無しさん** · 2021/08/17(火) 21:49:53.88

rustで作ったライブラリは他の言語から使いやすいんかい？
c\c++置き換えるなら、むしろそここそ一番重要かもしれん。

**デフォルトの名無しさん** · 2021/08/17(火) 22:12:04.05

>>696
Rustのライブラリは他言語からは使いにくいのが問題になっていると聞いたが。
多分、C/C++のライブラリのようにはいかないと思う。

**デフォルトの名無しさん** · 2021/08/17(火) 22:14:00.60

>>692
前半、なるほど。
githubで最高人気であるところのvue.jsも、いいねは2万くらいだったと思うし。
なんか数値に異常さを感じる。

**デフォルトの名無しさん** · 2021/08/17(火) 22:16:21.15

vue.jsのgithubでのStar数は、18万7,000だった。
crate.ioのダウンロード回数はこの1万倍を越えている。
普通に使っているだけでは辻褄が合いそうに無いな。
全世界の全てのプログラマが100回くらいcrateをダウンロードしたことになる。

**デフォルトの名無しさん** · 2021/08/17(火) 22:54:36.64

crates.ioのDL数と比較すべきはnpmのDL数では？
https://www.npmtrends.com/vue

**デフォルトの名無しさん** · 2021/08/18(水) 00:15:56.99

crates.ioのダウンロード数は依存crateのCIが走る度に増えるようなものだからそりゃ多くなるでしょ
GitHubのstarと比較したのはなぜ？

**デフォルトの名無しさん** · 2021/08/18(水) 00:33:37.55

別にプログラマが手動でダウンロードするわけではないんだが…
1回コンパイルすると100個以上落としてくるのも普通だから
2千万回コンパイルが実行された、という程度の話
ざっくり5年で均せば1日1万回ってとこか

**デフォルトの名無しさん** · 2021/08/18(水) 01:06:03.53

CIだろうね。人がcargoを直に打ってるとは思えん

**デフォルトの名無しさん** · 2021/08/18(水) 01:16:27.76

強力にキャッシュが効くはずのCIでツールが未整備なために効かず
異常にDL数が伸びてしまっただけだろう

**デフォルトの名無しさん** · 2021/08/18(水) 04:35:06.87

CIのライブラリインストールが動画の次に無駄な帯域を食ってると言われているだけある

**デフォルトの名無しさん** · 2021/08/18(水) 09:18:01.26

>>639
難しく考えすぎ
&と*の関係は単純明白
let a = 123; // a: i32
let b = a; // b: i32
let p = &b; // p: &i32
let q = p; // q: &i32
let &r = &p; // r: &i32
let x = &q; // x: &&i32
let s = *x; // s: &i32
let c = *r; // c: i32
let y = &&c // y: &&i32
let z = y; // z: &&i32
let d = **z; // d: i32

**デフォルトの名無しさん** · 2021/08/18(水) 09:35:44.42

ライブラリが他言語から使いにくいってのも謎だな
他言語からならC ABI一択なわけで、どの言語でライブラリ書こうが使い勝手は同じだと思うが

**デフォルトの名無しさん** · 2021/08/18(水) 09:48:19.81

>>697
例えばPyO3でPythonからRust呼び出せるよ

**デフォルトの名無しさん** · 2021/08/18(水) 10:49:15.04

>>672
自動的な参照外し(*を記載してないのに*適用)って、値を使うところで&Tや&&Tなどが使われたときにTの値になる、というルールだからそれも数学的でしょ。
あと&Tではない各種スマートポインタや自作の型を、*記載で参照外しする時も、Derefトレイト実装通りに行われるからこれも数学的。

**デフォルトの名無しさん** · 2021/08/18(水) 11:27:15.93

>>647氏が混乱したのもそこかもね
例えば
let a = 99;
let b = &a;
assert_eq!(100, b + 1);
assert_eq!(100, *b + 1);
つまり値を使う所では参照のままではなく安全に*が自動適用

構造体のフィールドアクセスも
struct Point {x: i32, y: i32}
let p = Point {x: 19, y: 31};
let q = &p;
assert_eq!(p.x, q.x);
assert_eq!(p.y, (*q).y);
つまりフィールドアクセスする所では参照のままではなく安全に*が自動適用
だからC言語などにある「q->y」という記法がRustには不要なので存在しない

**デフォルトの名無しさん** · 2021/08/18(水) 11:41:08.71

こじつけの自己レス自演が気持ち悪い
これでバレないとおもってるんだからww

お前も頑張って勉強中なの丸出しなのになぜそんなに上から目線で書きたがる？

**デフォルトの名無しさん** · 2021/08/18(水) 12:12:05.22

>>710
assert_eq!(100, b + 1);　は通るけど
assert_eq!(99, b);　はコンパイルエラーになるところがミソかな

**デフォルトの名無しさん** · 2021/08/18(水) 12:12:56.84

演算子も含めてメソッド呼出しのときの self の参照が調整されるのは言語コアの機能だけど
演算子の右辺で参照が剥がされるのは参照を受け取るバージョンのメソッドも用意されてるから
という理解でいいんだよね？

**デフォルトの名無しさん** · 2021/08/18(水) 12:16:13.67

>>710
>assert_eq!(100, b + 1);

`b + 1`のbは*が自動適用されてるわけじゃない

**デフォルトの名無しさん** · 2021/08/18(水) 12:52:27.85

そこはstd::ops::Addトレイトのimplがあるかどうか
ただしi32と&i32に対してはあるけど&&i32に対してはない
そのためさきほどの例だと
let a = 99;
let c = &&a;
assert_eq!(100, **c + 1); // i32はそのままOK
assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
assert_eq!(100, c + 1); // &&i32のAddトレイト定義はないからコンパイルエラー

**デフォルトの名無しさん** · 2021/08/18(水) 13:56:40.85

繰り返し間違った内容垂れ流すのいい加減やめれ

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

>>715で合ってるよ

**デフォルトの名無しさん** · 2021/08/18(水) 14:42:37.07

ご愁傷様

**デフォルトの名無しさん** · 2021/08/18(水) 15:05:20.49

ご安全に*

**デフォルトの名無しさん** · 2021/08/18(水) 19:37:59.33

質問したようなのと近い流れになってて助かった

(0..7).filter(|&x| x == 0);
↑これ通るから　↓こうしたら駄目だった。なんでなん？
let mut vec0 = vec![1, 2, 3, 4, 5, 6];
vec0.iter().filter(|&x| x == 1);

そこで、様々テストしたら、↓の方法でコンパイルが通ることがわかった
どのやり方が一般的なん？個人的には1か4かと思うんだけど。あと、2は+0することで型推論が働いてるのん？
vec0.iter().filter(|&x| *x == 1); //1
vec0.iter().filter(|&x| x + 0 == 1); //2
vec0.iter().filter(|&x| x == &1); //3
vec0.iter().filter(|&x| x.clone() == 1); //4
vec0.iter().filter(|x| **x == 1); //5
vec0.iter().filter(|x| *x == &1); //6

**デフォルトの名無しさん** · 2021/08/18(水) 19:43:27.81

全部結果まで含めて正しかった？

**デフォルトの名無しさん** · 2021/08/18(水) 19:48:58.01

ベクタの内容を↓にして
let mut vec0 = vec![1, 2, 1, 4, 1, 6];
1の数をcountするようにして表示させてみたけど、>>720の1～6のやり方でどれもcountの数は同じだね

**デフォルトの名無しさん** · 2021/08/18(水) 20:01:07.37

いいぞ！いいぞ！これも通るぞ！！

let mut test6 = vec0.iter().filter(|&&x| x == 1).count();
let mut test7 = vec0.iter().filter(|x| x == &&1).count();
let mut test8 = vec0.iter().filter(|x| *x + 0 == 1).count();

ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ

**デフォルトの名無しさん** · 2021/08/18(水) 20:03:48.63

Bible終えるのにどれぐらい時間かかりましたか？

**デフォルトの名無しさん** · 2021/08/18(水) 20:30:38.07

>>720
(0..7).filter(|&x| x == 0);と同等なのは
let v = vec![1,2,3,4,5,6];
v.into_iter().filter(|&x| x==0);

**デフォルトの名無しさん** · 2021/08/18(水) 20:47:56.15

>>725
うおー、まじか！
わかったありがとう。だからforループはちょっと違う挙動になるんだな

**デフォルトの名無しさん** · 2021/08/18(水) 21:38:07.08

違いをわかりやすく示すと
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());

**デフォルトの名無しさん** · 2021/08/18(水) 21:41:22.71

ありがとうありがとう
&TのイテレータとTのイテレータが別々になっているとはおもわなんだ

**デフォルトの名無しさん** · 2021/08/18(水) 21:54:22.03

まだ慣れてないからideに言われるがままに直してるな、、

**デフォルトの名無しさん** · 2021/08/18(水) 22:38:04.93

イテレータ回りはこのスライドが良いと思ったけど多少基礎知識ないときついかもしれんな
https://speakerdeck.com/optim/domination-of-the-rust-iterators

**デフォルトの名無しさん** · 2021/08/18(水) 23:13:44.45

>>728
そう考えるよりもムーブor借用と捉えるほうがいいかな
vec0.into_iter()だとムーブになるから値そのものが次々と来る。しかしその後にvec0は使えない。
vec0.iter()だと借用になるから値への参照が次々と来る。その後もvec0は使える。
(&vec0).into_iter()でも借用になるから値への参照が次々と来る。その後もvec0は使える。

**デフォルトの名無しさん** · 2021/08/19(木) 02:05:43.13

この2つは何が違うんですか？

演算子?
https://tourofrust.com/38_ja.html
unwrap
https://tourofrust.com/39_ja.html

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/19(木) 02:52:20.85

>>732
これは例がよくないな。
もう一段ほど関数呼出しを挟む構造になっていればより分かり易くなる気がする。

? 演算子はエラーだったときにそのエラー値を返り値として return する。
つまりその例の場合は do_something_that_might_fail が
エラー値を返したときは main から抜ける。
関数がエラーを出したときに上位にもエラーとして伝播させる機能。

unwrap は Result を剥がすが、エラー値だったときにはその場で panic する。
unwrap を書くというのは「エラー値が返されることはないことをプログラマとして保証する」
または「そのエラーに対して対処する方法はない、対処する気はない」という表明で、
assert 的な意味合いを含む。
エラーの対処を書くのが面倒だけど Result を剥がして型は合わせないといけない
というときに雑に unwrap することはあるんだけど、
多少なりとも汎用的なライブラリにするなら (事前条件が正しい限り) panic が
起こるのは好ましくはないので使い方は慎重に。

**デフォルトの名無しさん** · 2021/08/19(木) 03:04:22.69

>>732
?演算子はほぼtry!マクロのsyntax sugar
言語自体に組み込んだ時にその適用範囲を広げた

try!マクロとは見やすく省略して書くと
Result型rに対してはtry!(r)がほぼmatch r { Ok(n) => n, Err(e) => return Err(e) }となる

つまり?演算子はOption型やResult型の尻につけてNoneやErrの時にreturnする
一方でunwrapはpanicして死ぬ

**デフォルトの名無しさん** · 2021/08/19(木) 06:51:23.03

ほぉ、なるへそ
noneとかへの振る舞いの遅延行為としての?op
ある関数を呼んだ関数自体でerrへの振る舞い決定すべきだと考えた場合は?opにする
とすると?op含んだ関数のcallerはmatchとかのタイプ別振る舞い定義をちょっとやかましめ書く必要ありだな

いまいちpanicの振る舞いが分からん
spawned threadが内部でパニくった場合その娘、息子スレッド（スレッドの下層スレッド）とそのスレッド自体にのみunwindが適用されるんだよな？(´・ω・｀)

**デフォルトの名無しさん** · 2021/08/19(木) 08:14:51.20

何でやねん(笑)

**デフォルトの名無しさん** · 2021/08/19(木) 12:31:22.21

vec0.iter().filter(|&x| x == &1);
これの数字に&つけて型同じにしたら通るってのが納得できないな～
比較がプリミティブ型の変数同士だったら自動的に数値として扱って欲しい

**デフォルトの名無しさん** · 2021/08/19(木) 13:09:24.52

>>737
それは強い静的型付けのメリット
異なる型同士の==が通るのは困る

といいたいところだけど
PartialEqトレイト次第で異なる型でも==してくれる場合もある
文字列など
でも整数は厳密でi32とi16ですら不許可

**デフォルトの名無しさん** · 2021/08/19(木) 13:34:53.71

>>738
でも、上の例で
vec0.iter().filter(|&x| x + 0 == 1);
が通るのは+0したときに中身がプリミティブ型だから数値だけ取り出してくれてるんでそ？

**デフォルトの名無しさん** · 2021/08/19(木) 13:41:52.67

>>739
それはまた別で>>715
つまり足し算の実装

**デフォルトの名無しさん** · 2021/08/19(木) 14:53:02.41

&i32 + i32 の計算ができるようAddトレイトで実装されていて、結果をi32で返すようになってるからエラーにならないってことでしょ？

**デフォルトの名無しさん** · 2021/08/19(木) 14:59:15.22

>>741
そのとぉーり！

**デフォルトの名無しさん** · 2021/08/19(木) 15:34:51.11

>>741
ご丁寧にi32+i32 i32+&i32 &i32+i32 &i32+&i32の4種類をカバーしてくれてるね
&&i32はサポートしていないため
vec0.iter().filter(|x| x+1==2)はコンパイルエラー

**デフォルトの名無しさん** · 2021/08/19(木) 16:37:43.70

まず>>715の間違いを反省しようね

>let a = 99;
>let c = &&a;
>assert_eq!(100, *c + 1); // &i32は参照外してi32でOK

**デフォルトの名無しさん** · 2021/08/19(木) 16:44:47.80

>>744
それであってるぜ
&i32+i32は左だけ参照を外してi32にして足し算する

**デフォルトの名無しさん** · 2021/08/19(木) 17:44:32.43

そりゃ当たり前だろw
とことんダメなやつだな

**デフォルトの名無しさん** · 2021/08/19(木) 18:58:02.70

>>733
>>734
丁寧に教えてくれて、ほんとありがとう

**デフォルトの名無しさん** · 2021/08/19(木) 21:41:29.08

>>743
なるほど、なんかすべての挙動を把握しないとならないんだね
でも、やっぱり「&1」が通用するのは納得いかない(´･ω･`)

**デフォルトの名無しさん** · 2021/08/19(木) 22:05:30.35

>>748
基本的には正しく型を用いれば済む
&i32は数値ではなく数値への参照にすぎない
*付けなくても済む便宜の恩恵を受けるのはよいけどそれを理解したうえでしているかどうかの違い

**デフォルトの名無しさん** · 2021/08/19(木) 22:29:20.97

String と &str が == で比較できるなら i32 と &i32 も比較できて良い気はする
単に impl がないだけだから pull req 送ったら取り込んで貰えるのでは

**デフォルトの名無しさん** · 2021/08/19(木) 22:55:59.39

もう純粋に&1て、1の参照じゃんね
その意味がわからんし、存在意義がわからん
変数同士ならわかるけど、定数的に書いてるんだったらもうプリミティブ型だったら
中身で判断してくれよヽ(`Д´)ﾉｳﾜｧｧｧﾝ

**デフォルトの名無しさん** · 2021/08/19(木) 23:28:13.13

>>750
今もi32と&i32の組み合わせ4通り定義
そこへ&&i32が加わると9通り定義
そこまでする意義は？

>>751
だからx==&1ではなくて素直に*x==1と書こう

**デフォルトの名無しさん** · 2021/08/19(木) 23:48:19.67

>>751
プリミティブのwrapper crateを作って自分の好きなように定義すれば万事解決

**デフォルトの名無しさん** · 2021/08/19(木) 23:58:39.37

そういや&1みたいなのって実際に使う場面あるの？

**デフォルトの名無しさん** · 2021/08/20(金) 00:03:22.90

推奨する方法をやりやすく、推奨しない方法をやりにくく
Rustは他の言語に比べると特に後者についてよく考えられてる

**デフォルトの名無しさん** · 2021/08/20(金) 00:07:53.98

>>754
postgresクレートのquery()でparamsに数字を書きたいときとか

pub fn query<T>(&mut self, query: &T, params: &[&(dyn ToSql + Sync)]) -> Result<Vec<Row>, Error>
where
T: ?Sized + ToStatement