Rust part15

**デフォルトの名無しさん** · 2022/05/12(木) 18:28:20.99

公式
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/

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

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

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

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

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

**デフォルトの名無しさん** · 2022/05/23(月) 21:10:50.44

>>301
copyを気にするのではなくusize or BigIntのどちらを使うべきか意識すべきと解釈した
usizeで良い場合はcopyは気にせずして良い

>>303
FnOnceかFnMutかFnかは関係なくて
moveなclosureでキャプチャしたらmove発生するよ
moveでキャプチャされた値をクロージャの中でさらにmoveできるか、refしかとれないかがFnOnceとFnの違い

**デフォルトの名無しさん** · 2022/05/23(月) 21:18:12.89

https://www.reddit.com/r/rust/comments/3wubj0/comment/cxzlvt4/

num_traitsによるジェネリクスは絶対の正解ではないから適当なところで諦めようね

**デフォルトの名無しさん** · 2022/05/23(月) 21:23:42.08

>>304
それは別の話でその違いを理解できていないようにみえる
クロージャへのmoveはクロージャが作られた時に終っていてクロージャ内のコードでの動作なは関係ない
間違っているのは後者の話でこの部分

>>296
> curr?で発生するのはmove(とそれに伴うmemcpy)

curr?でmoveは起きない
curr?で起きるのはコピーである(!Copy型ならエラー)

**デフォルトの名無しさん** · 2022/05/23(月) 21:33:03.23

>>296
コピーもmoveも同じでそれがボトルネックかどうかが重要
数値プリミティブの場合はコピーを他の方法に変えたところでボトルネックが解消されることはまずないから気にする必要はない

BigUint前提ならVecと同じでmoveやクローンやのオーバーヘッドはそれなりに気にした方がいい
逆に現実的にはオーバーフロー考慮する必要がなくなるからCheckedAddが余計なオーバーヘッドになる

特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事

**デフォルトの名無しさん** · 2022/05/23(月) 21:43:43.53

>>307
それは間違ってるぜ
BigUintのchecked_add()は常にSomeを返すためにチェックとSomeは消えてオーバーヘッドとならない
さらにRustのジェネリックは各型にmonomorphizationされるためジェネリックで書いてもプリミティブ型やBigUint型のコードはそれぞれに最適化される

**デフォルトの名無しさん** · 2022/05/23(月) 22:04:52.01

ヒント:
Ratio<T> where T: Integer + Clone + CheckedAdd + CheckedMulは>>295の条件を満たす

**デフォルトの名無しさん** · 2022/05/23(月) 22:25:54.83

fibonacci_iter::<Ratio<u8>>()すると
ちゃんと最後233で止まるのね
ジェネリック凄い

**デフォルトの名無しさん** · 2022/05/23(月) 22:34:47.31

ククク……RatioのCheckedAddの実装を見ても果たして同じことが言えるかな

**デフォルトの名無しさん** · 2022/05/23(月) 22:37:22.49

汚染が始まった！

**デフォルトの名無しさん** · 2022/05/23(月) 22:55:06.68

>>311
たしかにRatioの実装が悪いな
まずAddと同様に
if self.denom == rhs.denom {の分岐をし
そして1の場合は
self.numberとrhs.numberでchecke_addするくらいはしないとな

**デフォルトの名無しさん** · 2022/05/23(月) 23:14:26.50

ジェネリックに書いてもRatio専用コードを書いても
どちらもRatioの実装を使わざるをえないのだから同じ結果となる

そしてRatio専用コードを書こうとしても外部からは工夫のしようがないため
ジェネリックからコンパイル時にモノモーフィゼーションされるコードと全く同じになる

**デフォルトの名無しさん** · 2022/05/23(月) 23:46:45.42

このスレごちゃごちゃした書き込み多すぎ

**デフォルトの名無しさん** · 2022/05/24(火) 00:53:51.91

各型を個別に確認しないと良いか悪いか判断できないならジェネリックにしちゃだめでしょ

**デフォルトの名無しさん** · 2022/05/24(火) 01:46:13.03

>>316
そんな個別に確認しなきゃいけないことは起きないから大丈夫
Rustの標準ライブラリも大半はジェネリックに書かれている

**デフォルトの名無しさん** · 2022/05/24(火) 07:59:54.71

>>307
>特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事
禿同だわ
コードパズルやってるやつにいつも感じる違和感の原因はこれだな
こういう能力って何て言うんだろ？

**デフォルトの名無しさん** · 2022/05/24(火) 08:06:11.71

>>318
でも今回の件の数列ならばジェネリックが正解やろな
わざわざ各数値型に個別に実装しなくて済む
分けるほうが不自然で手間

**デフォルトの名無しさん** · 2022/05/24(火) 08:45:23.72

男の人って気持ち悪い…
どうして少女をそんなに汚したがるの？
お母さんに悪いとわおもわないの？

**デフォルトの名無しさん** · 2022/05/24(火) 08:52:13.15

>>318
広く言えば設計能力
狭く言えば実装パターンの選択能力

総合的な能力だから一朝一夕には身に付かない
実装パターンの整理が進んでないRustだと特に

**デフォルトの名無しさん** · 2022/05/24(火) 11:37:27.58

KISS原則だろ

**デフォルトの名無しさん** · 2022/05/24(火) 19:12:35.28

>>202のlet n = curr?;の部分を
>>189はlet n = curr.take()?;としてコピーになるのを回避しているだけかと思ったら
両者が全く異なるアルゴリズムを採用していることに気付いた
>>202のアルゴリズムだとどうやってもコピーを避けられないから詰んでるね

**デフォルトの名無しさん** · 2022/05/24(火) 22:16:43.51

prev, currの状態管理だとcurrの値をprevに代入するのと戻り値として使うのと2箇所に必要になるからね
curr, nextで管理すればいい

**デフォルトの名無しさん** · 2022/05/24(火) 22:24:27.19

アルゴリズムというほど大げさな話ではないだろ
f(n)を求めるnext()が呼ばれた時に

>>189は内部にf(n)とf(n+1)を持っていて、足し算してf(n+2)を作る
そして内部にf(n+1)とf(n+2)を残して、f(n)を返す

>>202は内部にf(n-1)とf(n)を持っていて、足し算してf(n+1)を作る
そして内部にf(n)とf(n+1)を残して、f(n-1)は捨てて、f(n)をコピーして返す
つまりムダ

>>324
同意

**デフォルトの名無しさん** · 2022/05/24(火) 23:52:58.32

フィボナッチ数のような単純な問題でもプログラミングセンスに差が出るものなんだな

**デフォルトの名無しさん** · 2022/05/25(水) 09:34:10.65

>>218
まずはCから始めるのは間違ってない
Cは仕様が小さいからひと通り学ぶのにそんなに時間は掛からないからね

**デフォルトの名無しさん** · 2022/05/25(水) 13:26:51.10

Webシステム中心ならRustとRails どっちを中心に勉強すればいい？

どうせ仕事で使うのPHPとjsだけど

**デフォルトの名無しさん** · 2022/05/25(水) 13:32:36.84

RustでETみたいなのって書けるん?
てかテンプレートはC++みたいに汎用性高いの?
それともC#みたいに適用範囲絞ってる?

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/25(水) 13:40:48.57

>>329
C++ で言うところのテンプレートは Rust には無いよ。ジェネリクスは ML 風の型システムでやってる。
マクロは Lisp 風と言えると思うけどトークンが型付けされてるから Template Haskell とかのほうが近いかもしれない。

**デフォルトの名無しさん** · 2022/05/25(水) 20:05:45.57

なんだじゃあRustだめじゃん。

**デフォルトの名無しさん** · 2022/05/25(水) 20:20:43.79

>>331
むしろC++のテンプレートよりもRustのの方がほとんどの利用方法で便利かつプログラミングしやすく快適になった

**デフォルトの名無しさん** · 2022/05/25(水) 20:47:56.26

>>331
そうだよ。ダメだから君もRustは使わないほうがいい

**デフォルトの名無しさん** · 2022/05/25(水) 21:47:24.60

行列クラスを作って

X += A*(B+C)/D

みたいな演算子の多重定義して、すっきり1式で書くことできますか?

**デフォルトの名無しさん** · 2022/05/25(水) 22:02:04.30

Matrix<Complex> X(2,2 );
Matrix<double> Y(2,2 );

Y << 1., 2.,
3., 5.;

X = (double)(Y^3);

みたいなことrustで書きたい

**デフォルトの名無しさん** · 2022/05/25(水) 22:12:09.13

>>335
もちろんできる
こういうのがほしいんでしょ
https://docs.rs/simple-matrix/latest/simple_matrix/

初心者の題材としては適切そうだから、自分で実装してみてはいかがか

**デフォルトの名無しさん** · 2022/05/25(水) 22:17:54.75

スマソ
X=(Complex)Y^3
だた

**デフォルトの名無しさん** · 2022/05/25(水) 22:26:34.33

>>332
そこんとこ詳しく
解説サイトでもいいけど

**デフォルトの名無しさん** · 2022/05/25(水) 22:36:32.50

とりあえず一度は the book を読め。
根本的な言語デザインが違うからそこだけ抜き出して詳しい説明なんてできないよ

**デフォルトの名無しさん** · 2022/05/26(木) 00:08:48.87

rustてこんなコードも許すんだな

fn main() {
println!("Hello, world!");
main();
}

https://play.rust-lang.org/
でやってみるとスタック溢れて死んだけど一応実行できるのねww

**デフォルトの名無しさん** · 2022/05/26(木) 07:58:26.46

そんなことで草生やすのはおそらくキミひとり
他の人らは真顔でキミの発言を見守ってるよ

**デフォルトの名無しさん** · 2022/05/26(木) 08:48:32.43

>>341
いや、そんなふうに思ってるのはキミひとりだから

**デフォルトの名無しさん** · 2022/05/26(木) 09:21:13.14

エントリポイントであるmainの停止条件のない再帰が
何のerrorもwarningもなくコンパイルできてしまい、
当然スタックオバフロで停止してしまうなんて間抜けすぎると思ったんだけどね
これが先進言語なのか?ww

**デフォルトの名無しさん** · 2022/05/26(木) 09:45:45.88

>>343
最適化したら、ループに変換されて死ななくなるとか？

**デフォルトの名無しさん** · 2022/05/26(木) 10:23:40.75

Go でやってみたら gopls(Language Server)で infinite recursive call って warning が出た
実行できるけど、

runtime: goroutine stack exceeds 1000000000-byte limit

と表示されて強制終了

**デフォルトの名無しさん** · 2022/05/26(木) 10:39:49.31

>>343
警告出るよ

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2c7c027a6cf5a2e1c065faaad3a63680

warning: function cannot return without recursing

**デフォルトの名無しさん** · 2022/05/26(木) 18:28:21.56

じゃあGoのほうが良いんじゃん。

**デフォルトの名無しさん** · 2022/05/26(木) 19:07:49.07

そこに気づくとはやはり天才か

**デフォルトの名無しさん** · 2022/05/26(木) 19:23:40.54

>>347
RustもGoもどちらもwarningが出る
そして実行するとスタックが溢れて止まる
完全に同じ

**デフォルトの名無しさん** · 2022/05/26(木) 21:03:33.74

草

**デフォルトの名無しさん** · 2022/05/26(木) 21:33:44.65

イキッてスタックを増し続ける再帰を書くのは愚か、まともなら限界値でブレイクする、天才と努力家は末尾再帰でスタックを増やさない

**デフォルトの名無しさん** · 2022/05/26(木) 21:43:27.13

リリースビルドだと最適化されてスタックオーバーフローにならない
loopと同じになる
fn main() {
loop{ println!("Hello, world!"); }
}

**デフォルトの名無しさん** · 2022/05/26(木) 21:45:32.94

あれ？
前にRustは末尾呼び出し最適化はしないって聞いたけど

**デフォルトの名無しさん** · 2022/05/26(木) 21:53:44.25

言語仕様的に最適化を保証してるわけではないというだけでは？
LLVMがある程度やってくれる
https://godbolt.org/z/os9YMfozf

**デフォルトの名無しさん** · 2022/05/26(木) 22:19:48.49

わかりやすい例
確実にスタックが溢れるusize::MAX回の再帰

fn main() {
assert_eq!(usize::MAX, count(usize::MAX));
}

fn count(n: usize) -> usize {
// println!("{:p}", &n);
match n {
0 => 0,
n => 1 + count(n - 1),
}
}

①デバッグモードだとスタックオーバフロー
②リリースモードだと溢れずアサートも通る
③リリースモードでもコメントになっているprintlnの//を外すと最適化されなくなるようでスタックオーバフロー

**デフォルトの名無しさん** · 2022/05/26(木) 22:41:19.49

>>355
わかりやすい？
println入れるとなぜ最適化されなくなるの？

**デフォルトの名無しさん** · 2022/05/26(木) 23:01:45.92

>>356
再帰だと&nは毎回異なる
つまり再帰をループ化する阻害要因

**デフォルトの名無しさん** · 2022/05/26(木) 23:18:51.46

ごめん
n表示だけでもあかんわ
ループ化されず溢れる
調査のために、printよりもっと軽くて最適化で消えない操作、何かないかな

**デフォルトの名無しさん** · 2022/05/27(金) 10:47:17.91

>>358
ターミナルが標準出力に出てきたのを表示するのがボトルネックになってるだろうな
./a.out > /dev/null するか、printlnの代わりにファイル書き込みするのが手っ取り早い

**デフォルトの名無しさん** · 2022/05/27(金) 23:42:23.72

traitでasync fnなメソッドを宣言してはいけない理由を教えてください

**デフォルトの名無しさん** · 2022/05/28(土) 00:48:37.27

https://github.com/rust-lang/rfcs/issues/2739

**デフォルトの名無しさん** · 2022/05/28(土) 18:21:29.07

async fnはsyntax sugarだから例えば以下は同じ

async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}

fn delayed_add(a: i32, b: i32) -> impl Future<Output = i32> {
async move {
sleep(Duration::from_secs(5)).await;
a + b
}
}

つまり現在のRustコンパイラではまだimpl Traitを使える場所が限定されているというもっと大きな問題のために今は使えない
GATsなど現在進行中の諸問題が解決すればいずれ使えるようになるはず

**デフォルトの名無しさん** · 2022/05/28(土) 18:34:44.90

現状の対策方法としてはimpl FutureをdynにしてBox::pinして返す

trait Foo {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>>;
}

impl Foo for () {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>> {
Box::pin(async move {
sleep(Duration::from_secs(5)).await;
a + b
})
}
}

fn main() {
block_on(async {
let x = <() as Foo>::delayed_add(1, 2).await;
println!("x = {x}");
});
}

これでtraitにて非同期関数を使える

**デフォルトの名無しさん** · 2022/05/28(土) 18:41:39.92

それを手動で変換するのは面倒かつコードも見にくいので自動変換してくれる#[async_trait]を使えばasync fnと書ける

use async_trait::async_trait;

#[async_trait]
trait Foo {
async fn delayed_add(a: i32, b: i32) -> i32;
}

#[async_trait]
impl Foo for () {
async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}
}

**デフォルトの名無しさん** · 2022/05/28(土) 19:10:23.06

おじさん調査お疲れ様でした。

**デフォルトの名無しさん** · 2022/05/28(土) 19:23:54.07

・塩野義製薬が週休3日制導入へ来年4月、副業も解禁
・塩野義製薬が「週休３日」選択可能に　給与は『週休２日の８割』副業や学び直しを支援
・【フォーカス】サタケ／週休３日制　通年導入めざし夏季のみ試行中　交代制で水曜を休日に
・旅館なのに週休3日!?陣屋・若女将の常識を覆した組織改革
・“時代錯誤”から残業ゼロ、週休3日に！　鳥取の不動産会社が
　レガシー企業からDX先進企業になれたワケ
・ネクスウェイ、週休4日制・1日3時間勤務選択できる勤務体系を導入
・日本初「週休4日制度」で、優秀な人材を採用するしくみとは？ ?
　ナレッジソサエティ久田社長に聞いてみた

**デフォルトの名無しさん** · 2022/05/28(土) 20:19:11.57

もう借りまっか

**デフォルトの名無しさん** · 2022/05/28(土) 21:23:09.11

ジェネレーターはいつstableになりますか

**デフォルトの名無しさん** · 2022/05/28(土) 23:09:24.03

stableを期待しているということは現状の仕様で納得なんだろうけど
resumeの仕方とか値の受け取り方とか軽快じゃなくね？

let mut generator = || {
yield 1;
yield 2;
yield 3;
return "end"
};
assert_eq!(GeneratorState::Yielded(1), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(2), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(3), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Complete("end"), Pin::new(&mut generator).resume(()));

例えばresume構文を用意して記述を見やすくするとか
return値は廃止してOption<T>で返しreturn;でNoneにするとか

**デフォルトの名無しさん** · 2022/05/28(土) 23:30:01.77

個人的にはIteratorがyield使って実装できるようになれば満足なのでGeneratorそのものの型とかはそんなに気にしてなかった

**デフォルトの名無しさん** · 2022/05/28(土) 23:58:46.72

>>370
yieldを使うとIteratorの実装が楽になる？
from_fn()のようなfrom_generator()を用意するのかな

**デフォルトの名無しさん** · 2022/05/29(日) 01:25:03.17

またイテレータの話してる……

**デフォルトの名無しさん** · 2022/05/29(日) 01:35:28.37

結局イテレータを作るには構造体か何かを用意してnext()実装するしかないぜ
それが面倒ならfrom_fnやunfoldなどの汎用イテレータ作成関数を使うしかないな
こんな感じか

fn iter_from_generator<G: Generator + Unpin>(mut generator: G) -> impl Iterator<Item = G::Yield> {
iter::from_fn(move || {
match Pin::new(&mut generator).resume(()) {
GeneratorState::Yielded(n) => Some(n),
_ => None,
}
})
}

fn main() {
let one_two_three = || {
yield 1;
yield 2;
yield 3;
};
for n in iter_from_generator(one_two_three) {
println!("{n}");
}
}

**デフォルトの名無しさん** · 2022/05/29(日) 10:29:01.34

複クンなんですぐここに貼り付けてしまうん？
それお母さんに見てもらうだけでは不満なん？

**デフォルトの名無しさん** · 2022/05/29(日) 16:18:25.46

すまんが、関数とジェネリックについてわかんないんだけどさ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c548f2825b9f164eeabdd479c4950484
これってなんで動かないん？

**デフォルトの名無しさん** · 2022/05/29(日) 16:49:19.09

>>375
<T>という型情報だけじゃT{b:1}が正しい式か分からないから
値の内容にまで踏み込みたければtrait boundを付けてtraitが許す範囲内でやるしかない

**デフォルトの名無しさん** · 2022/05/29(日) 16:52:27.60

>>375
Tに渡されるのがいつもAだとは限らないからrustはエラーを出すんや
c++だったらエラーにならないが

**デフォルトの名無しさん** · 2022/05/29(日) 17:03:06.39

そういうことなのか！ありがとう！
だからサンプルコードみんなTを引数で受け取って戻値Tを返してるのばっかなのか

**デフォルトの名無しさん** · 2022/05/29(日) 17:10:58.33

「(i64 の) 1 から変換可能な型」という制約を付けるのであればたとえばこんな感じかな。

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=73e1d04ceeb2c0aff1dae461126dfb6e

**デフォルトの名無しさん** · 2022/05/29(日) 18:07:23.25

>>378
Tを引数に取らずにTを返すことも一般的に可能
その場合もTに何らかのトレイト境界を付けてそのトレイトのメソッドを呼ぶ形で実現する
fn c<T>() -> T {
T { b: 1 }
}
↓修整
fn c<T: Trait1>() -> T {
T::method1()
}

自分を返すmethod1()を持つトレイトTrait1を宣言しておく
trait Trait1 {
fn method1() -> Self;
}

そして型Aに対してそのトレイトを実装すれば動く
impl Trait1 for A {
fn method1() -> Self {
Self { b: 1 }
}
}
もちろんmethod1を引数付きのメソッドにしてもOK

**デフォルトの名無しさん** · 2022/05/29(日) 18:42:28.03

>>377
C++すごいな
なんでエラーにならんのかわからん

**デフォルトの名無しさん** · 2022/05/29(日) 19:12:40.72

>>381
Tに依存する箇所のコンパイルを保留してから、実際にT=Aとしてみてインスタンス生成するからね。
https://wandbox.org/permlink/zOH2lP3k2MEPYwsp

conceptで制限はかけられるけど本質は変わらん
https://wandbox.org/permlink/CdKBg61cUgFy2tBs

**デフォルトの名無しさん** · 2022/05/29(日) 19:30:37.85

なんだじゃあRustダメじゃん。

**デフォルトの名無しさん** · 2022/05/29(日) 20:03:03.02

そうだよ
ダメだからお前はRust使わないほうがいいよ

**デフォルトの名無しさん** · 2022/05/29(日) 20:16:50.49

どう見てもRustの方が安全安心
C++では>>382においてb以外のメンバ変数(フィールド)があっても動作してしまう
つまり初期化されていない部分が残り未定義動作となる

**デフォルトの名無しさん** · 2022/05/29(日) 20:38:31.90

未定義動作ではない。

**デフォルトの名無しさん** · 2022/05/29(日) 20:38:35.33

単一の機関が作ってるなら未定義動作なんて生じないんだけどなｗ

**デフォルトの名無しさん** · 2022/05/29(日) 20:50:06.03

C++では未初期化部分がある時
そこを利用した全体が未定義動作となる

**デフォルトの名無しさん** · 2022/05/29(日) 21:08:46.86

>>382
なるほど
俺の知ってるジェネリックの常識とは違うがある種の合理性はあるな

**デフォルトの名無しさん** · 2022/05/29(日) 21:14:08.45

未初期化領域があっても未初期化領域を読み出さなければ未定義動作にはならない
なので後からでも読み出す前にデータを書き込めば合法

**デフォルトの名無しさん** · 2022/05/29(日) 21:23:18.26

そもそも初期化されます

https://ja.cppreference.com/w/cpp/language/aggregate_initialization

struct A { int x; int y; int z; };
A a{.y = 2, .x = 1}; // エラー、指示子の順序が宣言の順序と一致しません。
A b{.x = 1, .z = 2}; // OK、 b.y は 0 に初期化されます。

**デフォルトの名無しさん** · 2022/05/29(日) 23:05:13.03

>>385
嘘つき。

**デフォルトの名無しさん** · 2022/05/29(日) 23:38:42.10

Rustのジェネリクスは
型Tに対してトレイト境界を増やせば増やすほど型Tを使って様々なことができるようになっていく
今回のように型Tに対してトレイト境界が何も無ければ任意の型に適用できる代わりにできることが非常に少ない

例えばC++とは異なりRustではデフォルト値で初期化することすら指定なしにはできない
Defaultトレイトをトレイト境界に持ち、さらにそのメソッドを用いてT::default()することで、
初めてようやくデフォルト値で初期化されたT型を得ることができる
これにより「ある型にとってデフォルト値とは何か」「そもそもその型にデフォルト値はあるのか」「デフォルト値が使われるのはいつか」
といった諸問題を全て解決している
C++の複雑なルールと異なりRustでは非常に簡単でわかりやすくなっている

**デフォルトの名無しさん** · 2022/05/30(月) 00:14:44.37

一方C++erはデフォルトコンストラクタを使ってデフォルト値を定義した

**デフォルトの名無しさん** · 2022/05/30(月) 00:34:37.40

長いからデフコンって略したほうが良くないっすか？

**デフォルトの名無しさん** · 2022/05/30(月) 00:37:19.04

全てを明瞭シンプルにしたことがRustの勝因

**デフォルトの名無しさん** · 2022/05/30(月) 00:39:32.57

なんだじゃあJavaと一緒じゃん。

**デフォルトの名無しさん** · 2022/05/30(月) 00:45:18.57

明示的に指示されないメンバも初期化されることに気づけなかったのはC++の仕様が複雑すぎるため
僕が悪いのではないことは明らか

**デフォルトの名無しさん** · 2022/05/30(月) 02:47:26.12

Rustは綺麗に整理されてるいるから複雑な個別ルールを覚えなくて済むね

**デフォルトの名無しさん** · 2022/05/30(月) 08:58:04.28

トレイトを増やしすぎて普段は必要ない補完候補が気持ち悪いぐらい出てくる破綻言語

**デフォルトの名無しさん** · 2022/05/30(月) 09:26:55.13

C#は良い言語ですよ

**デフォルトの名無しさん** · 2022/05/30(月) 18:11:00.15

>>400
ほんこれ

**デフォルトの名無しさん** · 2022/05/30(月) 18:37:20.51

そんなに補完優秀だったっけ？
rust-analyzer?