プログラミング言語 Rust 4【ﾜｯﾁｮｲ】

2017/12/24(日) 18:27:01.98

Mozilla発のプログラミング言語「Rust」のスレです

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

■ワッチョイ
スレ建て時、一行目に
!extend:on:vvvvv:1000:512
を入れること

■派生元スレ
プログラミング言語 Rust 4
https://mevius.5ch.net/test/read.cgi/tech/1507970294/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2017/12/24(日) 22:11:46.18

>>1乙

2017/12/26(火) 19:52:11.75

皆知ってるかもしれないけど、https://github.com/rust-unofficial/too-many-lists は良いね
公式のbookには無かった「自分で書いてみた時にハマる箇所と解決法」が丁寧に書いてあるんで、
特にプログラミング経験者でRust初学者には自信を持ってお勧めできる

2017/12/27(水) 07:28:12.89

>>3
しらんかた
webのやつはみれなくなってるね

2017/12/27(水) 10:23:26.96

製本？したものを上げてるサーバーが結構長いこと落ちてるね
1. cargo install mdbookでmdbookをインストール
2. git cloneで>>3のリポジトリを取ってくる
3. 取ってきたディレクトリでmdbookを実行
4. book/ にhtmlで製本されたものが出力される
ので、是非読んで欲しい。may not live longとかcannot moveとかで怒られまくってる人なら共感しながら読めるはず

2018/01/09(火) 09:45:01.64

アンチスレのほうが伸びてるやん
枯れ木も山の賑わい

2018/01/09(火) 11:34:47.34

>>3
http://cglab.ca/%7Eabeinges/blah/too-many-lists/book/
読めるようになってるな。

2018/01/12(金) 20:30:43.24

教えてください

VecのDisplay::fmtをカスタマイズしたくて
type MyType<T> = (Vec<T>);

impl std::fmt::Display for MyType {

}

2018/01/12(金) 20:43:39.15

申し訳ありません　途中送信してしまいました
コードをplaygroundに移しました

https://play.rust-lang.org/?gist=10bd65d0bfaf8b5117399b18bd8eb0d2

VecのDisplay::fmtをカスタマイズしたくて上の様にMyTypeを作成したのですが
Vecのメソッド委譲するためのコードを手書きする作業が煩雑になって困っています

何か上手い回避策は無いでしょうか?

2018/01/12(金) 21:23:37.23

>>9
私も初心者で分からないですが最終的に何がしたいんでしょうか？

9 (ﾜｯﾁｮｲ 392d-FSib) · 2018/01/12(金) 21:44:35.31

>>10
レスどうもです
Vec（他標準 struct）のDisplay::fmt出力をカスタマイズしたいんです　例えば
・要素数が多い場合、最初の数個を出力して残りを省略するとか
・要素の出力が長くなる場合、適当なところで改行するとか
・インデントを受け付けてネストしてる場合は改行とインデントで整形するとか

その上でVecのインターフェースをそのまま使いたいんですが
>>9のように新規の構造体を作る場合　手書きで委譲せねばならず
どうにか上手く出来ないもんかな……と

2018/01/12(金) 22:44:10.61

>>11
その用途ならVecに別な名前のメソッドを直接implしちゃってそっち呼び出せばいいような気がしたんですが

println!("{}", v.my_fmt());

みたいに

2018/01/12(金) 23:39:08.93

>>9 https://play.rust-lang.org/?gist=eec6671ba201493eb61891447824b92f&;version=stable

DerefとDerefMutを実装するといい。
↓にあるDeref Coarcionっていうコンパイラの機能で、x: MyType<T>に対し、&xが&MyType<T>とも&Vec<T>ともみなしてくれるようになる
https://doc.rust-lang.org/book/second-edition/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods

更に追加でIntoとFromも簡単に実装できるから不自由は無くなるはず

9 (ﾜｯﾁｮｲ 392d-FSib) · 2018/01/12(金) 23:49:12.53

>>12
ごもっともです
self.0に委譲するマクロが上手く書けなかった経験があり
それに引きずられて本質を見失ってました
コードを整理していったらいけそうな感じになりました
https://play.rust-lang.org/?gist=960819f1fb1b5f9988a1c58cab2b1b9e&;version=stable
ありがとうございます

>>13
ああ、なるほど
Derefは思い至ってませんでしたメソッド委譲の解決になりそうで助かります
こちらもありがとうございます

2018/01/13(土) 07:02:43.11

なるほど

2018/01/13(土) 10:23:49.57

https://stackoverflow.com/questions/45086595/is-it-considered-a-bad-practice-to-implement-deref-for-newtypes

ぐぐったらこんな議論も。

2018/01/13(土) 19:09:49.17

>>16の論旨は「MyType<T>は常にVec<T>として扱われても問題ないか？あるならDerefはおすすめしない」だと思うけど、
今回の場合はむしろMyType<T>は特別なことが無い限りVec<T>として使いたいんじゃないの？

9 (ﾜｯﾁｮｲ 392d-FSib) · 2018/01/13(土) 20:15:02.44

>>16 読みました
見覚えのあるピンク玉はrust playgroundの中の人でした

「smart_ptrぐらいの同一性がある場合にはDerefが必要だけど
strにDeref<Taget = [u8]>が無いように
Derefだとやりすぎな場合もあるからdelegate構文欲しいよね」
ってなとこでしょうか
strの例は「替わりにas_bytesがあるよ」ということかなと

strとsliceとか他のライブラリを眺めた個人的な結論としては
has_aならAsRef、is_aならBorrowをimplして受ける関数で使い易くしておくのが
Rust的な落とし所なのかなーといった印象です
AsRef, Borrow, Derefの使い分けは宣言的にプログラマの裁量に任されてる感じ

よくよく考えれば自分のコードにもas_xxx, as_xxx_mutが散見されている現状なので
Mytypeにもas_vecを書けばそれでも良かったような気がします

>>17
自分のケースの場合はそもそもMyTypeがいらなくなってしまったもので
Derefはオーバーパワーかなと思ってます
とはいえ　smart_ptrのように扱うならDerefが有用ということが
知見として学べたので　大変ありがたかったです

2018/01/14(日) 07:18:07.14

>>17
このスレを読んでる人に情報共有してるだけだよ

2018/01/14(日) 15:21:10.36

元スレやばいね

2018/01/18(木) 23:48:10.50

オライリー届いた。
分厚すぎてわろたわ。読むの大変そう。

2018/01/29(月) 13:41:23.22

dyn Traitが入ってしばらくしたらBox<Trait>はdisconになるの？

2018/01/29(月) 14:45:47.97

deprecated扱いになって警告を出し次のepochで削除とかだったと思う

2018/01/29(月) 17:30:10.02

impl Trait入ったらそもそもほとんど使わなくなるから気にしなくていいのか。

2018/01/29(月) 17:48:02.51

使うケース減るのもそうだけどepochで機能削除する場合はソースコードの変換ツールが提供されるらしい
あと古いepochのソースはそのままコンパイルできるらしいから特に対応不要らしい
だから新しいepochにしか入っていない機能を使いたいcrateとかでなければ何もしなくても困らないはずだし
その場合でも変換ツール通せば簡単に対応できるはず

2018/01/29(月) 21:18:10.28

なるほど

2018/01/31(水) 12:10:20.24

2018年のロードマップのRFC出てる
https://github.com/rust-lang/rfcs/pull/2314
impl Traitついに安定化されるのか

2018/01/31(水) 19:12:32.86

epoch releaseってのはどういうことなんだってばよ？

2018/02/04(日) 00:05:25.67

map: BTreeMap<K,V>で、keyが無かったら挿入、あったら格納されてる値vに応じて新しい値new_vに更新するか決めるってやりたいんだけど、
let v = map.entry(key).or_insert(new_v);
if ... {
*v = new_v;
}
よりもっと綺麗な書き方ある？

2018/02/04(日) 01:05:26.32

and_modify() ?

2018/02/06(火) 16:05:20.14

https://webassembly.studio/

CやRustでWebAssemblyできるOnlineIDEだそうな

2018/02/07(水) 00:06:02.34

Rust Never Sleeps: Community Grows, Eclipse-Based IDE Planned
https://adtmag.com/articles/2018/02/01/rust-grows.aspx

2018/02/07(水) 10:02:06.97

>>31
ええやん

2018/02/07(水) 10:05:39.88

>>32
eclipseはいらんなあ

2018/02/07(水) 21:39:04.86

オライリー本読んだ？

2018/02/10(土) 17:28:13.69

wasmってまだプリミティブすぎて使い物にならないのかと思ってたけど wasm-bindgen すげえな
もうここまでできるのか

2018/02/10(土) 18:48:11.24

Rustすごい！

takahito takabayashiさんのツイート: "ファミコンのエミュレータをRust / WebAssembly で書き直した
https://twitter.com/tatakaba/status/961532612723511296

2018/02/12(月) 12:24:11.46

梅手伝い

2018/02/12(月) 19:13:38.83

苦労して書き直しても全然パフォーマンス上がらないのな…
ぐうの音もでないほど効果があるユースケースってなんなんだ

2018/02/12(月) 21:38:29.65

アルゴリズムが変わらないならそう変わらんのじゃないか
他人のひどいコードならともかく、同じ人が小規模なプログラムを書き直す程度だと特に

C/C++からRustへ書き直して速度が上がったって話はあんま聞いたことが無い
速いネイティブライブラリを言語に組み込んでるJuliaとかなら、書き直すだけで速度上がったって話はちらほら
pythonだったらnumpy使った方が楽でいいとかも

2018/02/12(月) 22:31:51.98

いやだってjavascriptだぜ？アルゴリズムの問題か？

2018/02/13(火) 11:38:21.89

リリースビルドしてないとか

2018/02/13(火) 13:55:22.76

結局本スレどこ？

2018/02/13(火) 14:01:02.73

ここ

2018/02/14(水) 10:32:44.85

c++もそうだがコンパイラに機能を詰め込むってのがそもそも筋が悪い

2018/02/14(水) 16:35:43.73

>>45
どういうこと？じゃあどうすればいいの？

2018/02/14(水) 18:27:22.03

asm!だよ

2018/02/14(水) 19:14:50.70

>>46
ライブラリ、もしくはツールに任せる。

2018/02/15(木) 02:06:38.25

>>48
やっぱりちょっと分からないな。
RustやC++のどの辺がコンパイラに機能を詰め込んでると思うの？
ライブラリorツールに任せるってのもどの辺を任せたいのかな？
話がザックリし過ぎて言いたいことがよく分からないんだが。

2018/02/15(木) 14:13:53.00

プリプロセッサマクロのことかな？あとは型システムとかGCのことかな？ライブラリに任せるの意味がよくわからんが…

2018/02/15(木) 17:01:00.96

C++はコンパイラの方もだけど標準ライブラリでの機能実現も相応に多くて結果ソースの記述が煩雑になっているのは既知の事実でしょう
ライブラリや実装に任せた結果APIの統一が取れなくなって結局細かな仕様策定を余儀なくされたSchemeを見ても銀の弾丸でない事は明らかだよね
それに出来る事を増やすという点においてライブラリは有用だけど変数の不変性や型システムのような制限をする事に関してはコンパイラによしなにしてもらうより他ないよ

2018/02/16(金) 01:22:14.41

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

2018/02/16(金) 07:39:34.93

やっとstableでrustfmtできるようになったな

2018/02/16(金) 11:54:10.92

どうせ明日にはまたnightly限定になってるよ

2018/02/16(金) 14:44:20.68

最近のアップデートつまんねえなあ

2018/02/16(金) 15:41:33.96

>>45は言語仕様の追加、更新が気に入らないんじゃないかな
try!の代わりに?なんて以ての外だ、みたいな？それ以外に思い付かなかったけど
1.0以前に@や~を削除してライブラリにぶん投げた辺りは希望通りな気がする

基本的に電池入りじゃないRustはライブラリやマクロの代わりの言語仕様の追加じゃなく
より効率的なバイナリを吐くための言語仕様の追加が多いイメージだけどなぁ、impl Traitとか

2018/02/16(金) 17:59:54.40

>>56
あー、そういうこと。?記法は確かに若干違和感あったかもな。
でも実際、あれは便利なんだよなぁ。
File::open(path)?.read_to_string(&mut buf)?みたいに繋げられるから。
try!(try!(File::open(path)).read_to_string(&mut buf))は読みづらい。
かといって、
let mut file = try!(File::open(path));
try!(file.read_to_string(&mut buf))
みたいに2行に分けるのも面倒だし、無駄なローカル変数も出来れば避けたい。
結局、あれが妥当な判断だったと思うけど。
まぁ、stableにする必要あったのか？ってところで賛否両論あるかもね。

2018/02/16(金) 19:47:30.32

box キーワードは何時 stable になるんだ？

2018/02/17(土) 11:13:34.80

boxキーワードはどういう時にうれしいのかがわからん

2018/02/17(土) 11:16:00.80

明らかに二行に分けた方が読みやすいわけだが。
新しい機能マンセー厨ってそういう感覚の狂いについて無自覚過ぎんだよね。

2018/02/17(土) 13:27:59.06

俺も違和感はあるけど、多くの人が賛意を出して採用されたんだから
>>60や俺の感覚が狂ってるんじゃね？自身の感覚の狂いって当然ながら無自覚過ぎんよ

boxは在り様の総意を取るの面倒だし、目下はBoxで運用できてるしで、いつまでもstableに来なさそう
ヒープを多用したい人には文法にあればありがたいんだろうけど、そもそもヒープが好まれんしのう

2018/02/17(土) 14:16:54.60

boxっていきなりヒープにメモリ確保されるのが保証されたりするんじゃないの？
今はコンパイラ次第じゃん

2018/02/17(土) 14:41:36.65

ironって今メンテされてないのか
最近のweb FWはrocketの方が人気なんかな
nightly専用だからまだ手を付けてないんだけど

2018/02/17(土) 20:32:28.58

>>59
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/box-syntax-and-patterns.html
> このように書くことでパフォーマンスを犠牲にすることなく、柔軟性を確保することができます。

知らないの？

2018/02/17(土) 23:42:00.44

それはInPlaceとかPlacerがあればよくてbox inはただのsyntax sugarでは

2018/02/18(日) 08:04:09.95

分解のほうは新しいの？

2018/02/18(日) 08:27:52.42

分解の方がよほどsyntax sugarじゃないのかいな
NightlyのInPlace, Placer使わなくても、Stableの環境でmacro使って実現出来そう

2018/02/18(日) 10:49:08.55

boxって名前はBox<T>以外に使う場面で綺麗に見えない
place <- exprは代入みたい

2018/02/20(火) 18:44:44.84

tokio-coreなくなるんか
一通り組み上がった後の悲しいニュース

2018/02/20(火) 21:05:12.64

まじか、ちょっと辛いな
依存してるライブラリも結構あるよね

2018/02/21(水) 00:49:13.91

ワッチョイなしの方アンチが暴れてる

2018/02/21(水) 00:56:09.93

tokio系列のやつってtokioとかtokio-coreとかtokio-ioとかtokio-protoとか複数あってよく分からんのよね
tokio-ioのリポジトリにはtokioに移動したからもう使うなって書いてあるし
tokio-coreは移動じゃなくて廃止予定って書いてある…
tokio-protoはそのまま？tokio-timerとかtokio-serviceとかよく知らんリポジトリもあるし…
誰か各クレートの特徴(役割)と関係性を教えてくれ

2018/02/21(水) 19:02:38.89

>>71
あっちは、アンチが立てたキチガイ専用スレだからいいんだよ

2018/02/21(水) 19:11:26.04

コミットを追うとtokio-coreはtokioに変わったように見える
tokio-core=tokioでtokioの本体

tokio-ioはtokio-coreを使って非同期ioを実装したものだったがしゃらくせえのでtokio-coreに取り込んだのかな

tokio-protoはtokio-coreを使ってネットワークプロトコルを実装したものだったがしゃらくせえからtokio-coreに取り込んだのかな

つまり tokio = tokio-core + tokio-io + tokio-proto

か？