プログラミング言語 Rust 4

**デフォルトの名無しさん** · 2017/10/14(土) 17:38:14.04

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

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

前スレ
プログラミング言語 Rust 3
https://mevius.5ch.net/test/read.cgi/tech/1495343069/

**243** · 2017/11/25(土) 01:18:11.42

>>246
ありがとう。SVGって文字を扱えるんだっけ・・・って調べてみたら扱えるみたいですね
行けそうな気がしますがGPL/LGPL系のライセンスは使えるライブラリを制限するので避けたいです
C++だけどsvgrenとか？情報少なすぎてちゃんと動くのかすら不明。日本語フォントとか大丈夫なのだろうか

CでラップしてさらにRustでラップするようなのかな

**デフォルトの名無しさん** · 2017/11/25(土) 05:40:17.26

Javaも最初の頃はマトモに書いてもコンパイル通らなかったこといくらでもあったもんな。

**デフォルトの名無しさん** · 2017/11/25(土) 12:29:42.95

>>215
本気の荒らしと本気の自演と本気の無自覚アスペはいいのか…？
自分に都合がよいものだけが都合よく残るって都合よく考えるなって言われてるんだろ

**デフォルトの名無しさん** · 2017/11/25(土) 13:02:12.25

終わった話題に粘着する人ｷﾀｰ

**デフォルトの名無しさん** · 2017/11/25(土) 13:14:26.95

RustでGUIってイケてる？っていうか、GUIライブラリ多すぎるだろ・・、

GtkとQtメインでやってるけど、JavaFXもいいし、Pythonなんてバインディング沢山あるし、

Rustなんてやりだしたら、もうキリがないよ・・・

**デフォルトの名無しさん** · 2017/11/25(土) 13:15:21.53

もうどれか一つでGUI決めてくれねえかな・・。スゲエ、面倒。

**デフォルトの名無しさん** · 2017/11/25(土) 13:19:24.38

おじいちゃん、GUIはブラウザってきまったでしょ？

**デフォルトの名無しさん** · 2017/11/25(土) 13:39:30.15

GUIはElectronみたいな方向に行ったほうがいいのかね

**デフォルトの名無しさん** · 2017/11/25(土) 13:42:04.43

Blink を Servo で置き換えた Selectron 来い

**デフォルトの名無しさん** · 2017/11/25(土) 14:09:00.72

>>238
バカが調子に乗って新しい言語使って書き散らしたコードをメンテする経験をすればわかるようになるよ。

**デフォルトの名無しさん** · 2017/11/25(土) 14:37:28.91

言語じゃなくてそのバカをdisれよｗ

**デフォルトの名無しさん** · 2017/11/25(土) 14:41:23.39

個人的に検討するGUIフレームワーク
簡単な奴→MS HTAやElectronなど。Webで使われている技術で実装できる
凝った奴→wxWidgets。高機能かつ高速、大抵の物は作れるが罠もある。もしくはAPI直叩き

昔結構悩んだけど結局上記あたりに落ち着いた。当時検討した物
GTK→LGPLウザイ。パフォーマンスが良くない(最近は良くなった？)
Tk→低機能で作れない物がある。パフォーマンスが良くない
Qt→LGPLウザイ。パフォーマンスが良くない
JavaFX→パフォーマンスは悪くないがJREの初期化(≒起動)に時間がかかる

>>256
バカに無計画にコードを書かせているバカが問題なのであって言語が悪いわけではないだろう

あ · 2017/11/25(土) 14:57:49.91

>>249
良いだろ。というか、それらを止めるのは現実的な方法では不可能。イエスマンを集めて楽しくワイワイ()になるぞ。

記名制のフォーラムでも本気の荒らしや本気のアスペや本気の無自覚は幾らでも居たんだから。

**デフォルトの名無しさん** · 2017/11/25(土) 17:24:23.29

hyperってシングルスレッドなんなね
ベンチマークも結果がバラバラでよう分からん

**デフォルトの名無しさん** · 2017/11/25(土) 21:02:37.96

>>258
まあそうなんだが、
言語によって弾けるとする linus の意見には賛同するところはある。

**デフォルトの名無しさん** · 2017/11/25(土) 21:09:22.03

>>256
そういうやつって言語関係なく台無しにしてるんじゃね？

**デフォルトの名無しさん** · 2017/11/25(土) 21:22:20.34

>>262
確かに、そういう奴ってどの言語使っても大体はクソコードを書くだろうな。
ただし、ベストプラクティスを教えてくれるやつがいるかどうかで差はあると思う。
新興言語はベストプラクティスを教えてくれる奴が極端に少ないから、余計にひどくなる。
対して、普及している言語は周りにベストプラクティスを教えてくれる人がいれば
バカでもある程度はマシなコードを書く(書くことを強制される)んじゃないかな。

**デフォルトの名無しさん** · 2017/11/25(土) 21:32:32.35

>>262
関係ないんだが
「関係ない」ということを理解せずに無駄に新しい言語推しで
現場嵐してくることが問題。まずはてめーのコードを直せと。

**デフォルトの名無しさん** · 2017/11/25(土) 21:34:35.12

そのバカと言語disに走るID:OgtFvRibは同レベルだよ。

**デフォルトの名無しさん** · 2017/11/25(土) 23:18:19.74

>>265
単語の断片に反応してるだけの思い付き厨だろうな。

**デフォルトの名無しさん** · 2017/11/26(日) 00:38:40.95

>>264
それって人事が無能なだけじゃあ。まぁ日本にそういう会社は多いんだけどな

**デフォルトの名無しさん** · 2017/11/26(日) 01:44:59.31

いうほど言語disに走ってる訳ではないけどね。
ただ言語disに走る気持ちは理解できるってこと。
他の言語disパターンとしては単純に自分があんまり知らんから
理解する時間の節約のための dis かな。

**デフォルトの名無しさん** · 2017/11/26(日) 02:00:15.38

rustは組み込み向けの新言語になると思ったけど、全然流行らんな
早くC++から脱したいのに

**デフォルトの名無しさん** · 2017/11/26(日) 02:37:39.20

昔の一部の組み込み系では製品の安定を求めるために
コンパイラのバージョンアップすら信用しない（＝古いバージョンを使用し続ける）ことがあったなー

**デフォルトの名無しさん** · 2017/11/26(日) 02:50:50.14

『"（Rustが売りにしてるような部分に関して）良いコード"を書きたいと思っているh人』にとっては素晴らしい言語となる可能性の高い言語がRust
『"良いコード"の定義が違う人』にとっては
『"良いコード"を書きたいと思っているわけではない人』にとっては

**デフォルトの名無しさん** · 2017/11/26(日) 02:52:44.07

Rustがコケると得するのは誰か

**デフォルトの名無しさん** · 2017/11/26(日) 03:23:13.42

>>269
目的より手段を優先する日本じゃ無理だろｗ
どうしてもやりたいなら自分で立ち上がるしかないんじゃないか

**デフォルトの名無しさん** · 2017/11/26(日) 03:57:56.67

>>273
rustが使いたいからその仕事を立ち上げるって明らかに手段と目的が入れ替わってますよね

**デフォルトの名無しさん** · 2017/11/26(日) 09:03:05.51

>>272
世界中のプログラマ
モジラのクソ提灯で言語未満の自称言語がひとつ減る訳だから

**デフォルトの名無しさん** · 2017/11/26(日) 09:09:55.82

この糖質「提灯」って言葉に執着してるね。

**デフォルトの名無しさん** · 2017/11/26(日) 11:03:05.21

>>276
執着というより単に語彙力がないだけかと。
コイツいつも大体同じようなことしか言ってないよ。

**デフォルトの名無しさん** · 2017/11/26(日) 11:11:18.98

>>263
ガウディ本とかで計算モデルを理解してれば、慣れてるという理由で合わない用途に無理矢理押し込もうとしないんだろうけどね。

**デフォルトの名無しさん** · 2017/11/26(日) 11:35:06.02

当人は必死だけどすっかり珍獣扱い

**デフォルトの名無しさん** · 2017/11/26(日) 16:10:47.30

少なくともswiftに採用しようとしてる機能を先行実装しているだけでも価値ある

**デフォルトの名無しさん** · 2017/11/26(日) 22:44:13.85

Rustが成功したから真似されたんじゃｗ
Ａｐｐｌｅ信者さすがの言い草

**デフォルトの名無しさん** · 2017/11/26(日) 22:54:59.36

>>281
成功？成功ってなんだっけ？

**デフォルトの名無しさん** · 2017/11/26(日) 23:15:44.20

Swift の仕様変更と比べると、Rust のアップデートはかなり大人しいよな。

**デフォルトの名無しさん** · 2017/11/26(日) 23:36:42.57

>>282
Ｒｕｓｔのメモリ管理の仕組みが破綻してないことを証明しただろ！
しかも実務にも耐えてる
これが成功でないわけがない

**デフォルトの名無しさん** · 2017/11/27(月) 01:38:36.80

>>284
循環グラフとか動的計画法とか書けない言語のどこが破綻がないのかいってみろ工作員

**デフォルトの名無しさん** · 2017/11/27(月) 01:55:07.26

RustでDPできないの？

**デフォルトの名無しさん** · 2017/11/27(月) 02:01:44.73

出来ない人がいるだけ

**デフォルトの名無しさん** · 2017/11/27(月) 07:36:56.24

簡単にwasmコンパイルできる環境が整ってきたな
https://twitter.com/badboy_/status/934742946754244613
今、試したけど、Windowsでも動いた。
cargo-wa は動かんかったけど。

**デフォルトの名無しさん** · 2017/11/27(月) 16:32:30.04

このエラーメッセージ、表示されるときと(当該箇所の修正をしていないのに)も関わらず表示されないときがある
Why?

error[E0605]: non-primitive cast: `{integer}` as `f64`

= note: an `as` expression can only be used to convert between primitive typ
es. Consider using the `From` trait

このエラーメッセージが表示されるのは
このエラーメッセージの示す箇所と全然無縁な箇所でコンパイルエラーが出たときに同時に表示される
そしてその他所であるコンパイルエラーを解消するとこのエラーメッセージも同時に消える

**デフォルトの名無しさん** · 2017/11/27(月) 22:23:59.13

言語構文とツーリングを改善したRust 1.21
https://www.infoq.com/jp/news/2017/11/rust-1-21-released

「Rust 1.22」リリース
2017年11月27日17:00
https://mag.osdn.jp/17/11/27/170000

**デフォルトの名無しさん** · 2017/11/27(月) 22:38:51.64

>>270
実際、g++ なんかはバージョン違うと相当挙動違うけどね。

**デフォルトの名無しさん** · 2017/11/28(火) 01:05:16.27

>>289 エラー時には情報足りなくてusize等に推論してるから、かなあ
構文チェック -> 型推論&チェック -> ボローチェッカーって順番でエラー出してる感じだけど、
関係無い場所でのエラーのせいでas f64してるローカル変数の型推論が不十分な可能性がある
型推論は重い処理だから何らかの最適化のせいでエラー時の挙動が分からないのではないか

**デフォルトの名無しさん** · 2017/11/28(火) 01:05:23.35

Rustでイミュータブルに拘る人は何なの？ミュータブル使えよ

**デフォルトの名無しさん** · 2017/11/28(火) 01:26:37.66

ミュータブルなんて怖いもの使えないよ～><

**デフォルトの名無しさん** · 2017/11/28(火) 01:38:14.99

ミュータブルにする必要のない箇所をイミュータブルにする
基本はミュータブルで使え、ミュータブルしてなかったらコンパイラが教えてくれる、そのときイミュータブルに変更すればいい

**デフォルトの名無しさん** · 2017/11/28(火) 02:15:45.91

ID:YEKXo1x2
完全に頭おかしいな

**デフォルトの名無しさん** · 2017/11/28(火) 05:26:38.97

Rustでイミュータブルに拘るのは、TypeScriptで型付けることに拘るようなもん

**デフォルトの名無しさん** · 2017/11/28(火) 06:36:09.88

いミューダブルって、Cellの話をしているの？

**デフォルトの名無しさん** · 2017/11/28(火) 06:49:49.21

最近勉強し始めたんだけど、デフォでイミュータブルなのに思いのほかmutキーワード使う局面が多くて面食らってる。

**デフォルトの名無しさん** · 2017/11/28(火) 06:56:41.60

イミュータブルに拘ると、Scalaとかでもそうだが、コピーだらけになる
コピーを恐れてるとイミュータブルを徹底できないよ

**デフォルトの名無しさん** · 2017/11/28(火) 06:59:54.84

コピーってmut並みに最適化してくれんの？

**デフォルトの名無しさん** · 2017/11/28(火) 07:35:10.58

あ、そういうこと。むりやりイミュータブルにする人たちがいるのか

**デフォルトの名無しさん** · 2017/11/28(火) 09:28:24.80

静的型付け初めてなんだけどいきなりRustは敷居高いだろうか

**デフォルトの名無しさん** · 2017/11/28(火) 10:02:32.22

>>300
> イミュータブルに拘ると、コピーだらけになる
> コピーを恐れてるとイミュータブルを徹底できない

例出してみ

**デフォルトの名無しさん** · 2017/11/28(火) 12:38:41.40

イミュータブルとかメモリを富豪的に使うだけで性能はなんら上がらない、いかにもお偉いさんが机の上だけで考えたクソ手法だろ
なんでFortranやCが現役なのか考えたこともないやつがイミュータブルをもてはやす

**デフォルトの名無しさん** · 2017/11/28(火) 12:59:41.96

メモリが富豪的って、それお前の設計が悪いだけやで

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

それは言い過ぎだろ

なんでもイミュータブルにするべきとは思ってないが、
並列性が必要なプログラムではイミュータブルは重要視しているよ

並列性が性能に直結しない（難しい）のは残念な話だけど……

**デフォルトの名無しさん** · 2017/11/28(火) 13:47:27.77

>>306
値変えないならコピーするしかないだろ。それが富豪的でなくてなんなんだ？

>>307
並列計算で必要なのはイミュータビリティじゃなくて、変数スコープ分離と外部依存性の無いアルゴリズムだ

大方MPIすら使ったことないんだろうが、
共有リソースにアクセスしなきゃいけない並列プログラム組んでる時点で
設計が破綻してるとみなせると思うがそこんとこどう考える？

**デフォルトの名無しさん** · 2017/11/28(火) 14:14:02.57

このバカ、コンパイラが良きに計らうってことを知らんのか？

**デフォルトの名無しさん** · 2017/11/28(火) 14:26:19.19

>>292
thx
なるほど、コンパイル途中でエラーすると一部の推論に失敗してしまうのか

**デフォルトの名無しさん** · 2017/11/28(火) 14:42:06.12

const に異常にこだわるくせに異常に長い関数書く馬鹿は見たことあるな。
その前に関数切り出せと。
たぶん Rust が一般に広まるとボローイングルールをまともに理解できなくて
コンパイルできないから関数に切り出さないバカが増えると思われる。

**デフォルトの名無しさん** · 2017/11/28(火) 15:17:40.57

イミュータブルにすることでコンパイラによる最適化の余地が増えるんでないの？

ミュータブル派とイミュータブル派の宗教戦争勃発なの？

**デフォルトの名無しさん** · 2017/11/28(火) 15:25:32.16

コンパイラが善きに計らうって、
つまりconstついてた（mut非指定の）変数がレジスタ割り当ての結果変更され得る最適化が起こるってことか？
さすかにそんな最適化は聞いたこと無いがソースあるのか？
即値展開ならわからんでもないが、それと並列は関係ないし

**デフォルトの名無しさん** · 2017/11/28(火) 16:00:32.21

アマゾンでオライリーのProgramming Rust出てるのな
アーリー版じゃ無い完全版かな？

どうでも良いけど蟹座の俺が心惹かれる表紙

**デフォルトの名無しさん** · 2017/11/28(火) 16:21:14.75

>>308
「使ったことない」って人を判断したがるのは使ったことを自慢したいから？
ある数学上の問題を高速に解くために 2000年ぐらいにMPI を数ヶ月触ったことある程度で
以降は関わってないけど、それはなんか関係あるのか？

設計が破綻しているかどうかは問題によるだろ
どんなに考えても共有リソースにアクセスしなきゃいけない並列プログラムなんて山ほどある

共有リソースへのアクセス削減なんてみんな取り組んでる
そのための一ツールとしてイミュータビリティは重要な概念だろJK

> 並列計算で必要なのはイミュータビリティじゃなくて、変数スコープ分離と外部依存性の無いアルゴリズムだ
「重要視」と言ってるのに「必要」と解釈するのか……
変数スコープ分離という用語は知らん

**デフォルトの名無しさん** · 2017/11/28(火) 18:02:39.24

>>314
kindle版の話か

紙版を注文しちゃってるんだが

**デフォルトの名無しさん** · 2017/11/28(火) 18:17:27.07

ガーガー言うほど文句が出るもんでも、全力擁護すべきもんでもないと思うがね＞デフォルトでimmutable
Haskellほどやり方が変わるわけでもない、C/C++のconstより明快、letとvarで分けるほど使い心地が違うものにはならない、
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/box-syntax-and-patterns.html
↑にあるようなBoxを使って大きい構造体を関数に渡すのはRustじゃ悪手ってとこだけ知ってればいい

**デフォルトの名無しさん** · 2017/11/28(火) 18:18:12.38

>>315
MPIは不変性は並列化に必ずしも必要じゃないって話の例に出しただけだから、
さわった上で不変性が必要って主張するならまあそうなんだろう

データを不変にして触るノードの分だけコピーすりゃそりゃデータ競合は起きないだろうが、
その分ノードへの転送量だってかかるし、メモリも食う
だから富豪的で、額面上の並列度は上がっても性能には寄与しないと言ってる

俺が知らないだけでもっと良い最適化が不変変数にかかるなら完全に俺が無知晒したでめでたしなんだが

**デフォルトの名無しさん** · 2017/11/28(火) 20:36:19.23

業務のＤＢとかででっかいＢｅａｎやテーブルさわってるとＩｍｍｕｔａｂｌｅこだわると死ぬ気がする
ライブラリレベルだとImmutableすごいよさそうなんだが

**デフォルトの名無しさん** · 2017/11/28(火) 20:40:51.18

immutableがいいのはソースの可読性が高まるのと、マルチスレッド化したときにリソースアクセスに問題ないのが保証できることでしょう。バグらなない自信があるなら効率を求めてmutableにするがよろし。

**デフォルトの名無しさん** · 2017/11/28(火) 21:07:28.65

mut にするのもそこまで困難な言語設定ってわけでもないし、
デフォルトが immutable でもいいんじゃねとは思う。
まあ大規模に作ったことはないからその際の困難はわからんけど、そこまで問題にならんのでは？

**デフォルトの名無しさん** · 2017/11/28(火) 21:37:26.40

let mutって書くのめんどくせーしvar

**デフォルトの名無しさん** · 2017/11/28(火) 21:37:34.07

追加してほしい

**デフォルトの名無しさん** · 2017/11/28(火) 22:58:48.40

mutにするのをめんどくさくするというのが
let mut構文を採用した理由なので
varはよっぽど何かない限り入らないと思う

**デフォルトの名無しさん** · 2017/11/29(水) 00:16:55.36

Haskellのイミュータブルは永続データ構造？参照の使いまわし？
Rustのイミュータブルは？コピーしないと使いまわせない？

**デフォルトの名無しさん** · 2017/11/29(水) 00:58:38.85

wasmに出力するのって、依存ライブラリも全部pure Rustじゃないとダメなの？

**デフォルトの名無しさん** · 2017/11/29(水) 03:28:58.51

1.22でOptionにも?使えるようになって、haskellのMaybeモナドっぽく使えて捗るわ
ブロック内だけでも使えたら良いんだけど仕組み的に無理そうか

**デフォルトの名無しさん** · 2017/11/29(水) 12:04:01.36

try catchみたいな構文検討されていたような

**デフォルトの名無しさん** · 2017/11/29(水) 19:35:23.16

Rustを叩いている奴ってミラーレスカメラを叩いている一眼レフカメラ信奉者と同類に見える
大抵の場合は合理的な方が最終的に選択されるけどな

**デフォルトの名無しさん** · 2017/11/29(水) 20:42:06.07

mutable変数扱うなバーカ、というメッセージだと思ってる
必要なら再宣言させるようにして人為バグを減らそうという魂胆は分かるぞ(Javaのfinal教徒感

**デフォルトの名無しさん** · 2017/11/29(水) 20:50:40.91

BufReaderとかReadするStringとかにもmut必要何だからmut禁止とか無理じゃね？

不要なmutだったらワーニング出るでし、必要だったらコンパイルエラーになるでしょ

必要な形で使えば良いだけなのに一体何を議論してるんだ？
ミュータブルが気に入らないならhaskellおすすめ

**デフォルトの名無しさん** · 2017/11/29(水) 22:01:09.26

Readした結果はmutableでいいのにlet mutと書かなければならんの面倒
人によってはletで再宣言するのかな

**デフォルトの名無しさん** · 2017/11/30(木) 01:36:34.69

例えばさ
mutな変数1つ宣言してそこに足し上げていくのと、
非mutな計算結果同士を足して新しい非mutな計算結果を作るのと

素朴に考えれば前者の方が省リソースだよな

別にその程度コンパイラの最適化やレジスタ割り当てでどうとでもなるだろうとも思うが

**デフォルトの名無しさん** · 2017/11/30(木) 02:16:29.28

https://qiita.com/koji_mats/items/62e85a87cc580e225796
これ見たんだけど、なんでwinがlet mut winじゃないんだろうって不思議に思った。

let win = gtk::ApplicationWindow::new(&app);
win.set_title("Vanilla Text");

で、コードを調べてみたら、こんな感じにFFIを呼んでるだけだから、
概念的にはオブジェクトを変更してるけどRust的にはmutが要らないという仕組みらしい。
ちょっと違和感無い？

fn set_title(&self, title: &str) {
unsafe {
ffi::gtk_window_set_title(self.to_glib_none().0, title.to_glib_none().0);
}
}

**デフォルトの名無しさん** · 2017/11/30(木) 02:51:13.41

ポインタの先がどう変更されようが、ポインタを持ってるだけの側は不変。

**デフォルトの名無しさん** · 2017/11/30(木) 03:27:18.42

gtkはgoのほうが簡単

**デフォルトの名無しさん** · 2017/11/30(木) 07:37:17.88

Cellもしらんのか

**デフォルトの名無しさん** · 2017/11/30(木) 13:33:26.57

Rust的な設計の指針というかコツみたいのって無いですかね…

勉強のつもりで外部のCのライブラリとの間に入るちっちゃなFFIのラッパーを書いてみたんですが、Cの感覚で書く->コンパイラに怒られてあーなるほど修正ってのを繰り返してとりあえずは動くようになったんだけど
何をするにも

let foo = xxx ;
{
let bar = foo.xxx() ;
bar.yyy() ;
}
{
let baz = foo.zzz() ;
baz.www() ;
}
{
let bar = foo.xxx() ;
bar.yyy() ;
}

みたいに書かないといけなくて書いた本人でも｢何やねんこのウンコ！｣ってなってる(´・ω・`)
(Rustがって意味じゃなくて自分の書いたものがって意味で)

**デフォルトの名無しさん** · 2017/11/30(木) 15:21:22.37

どんなエラー出してそんな醜いコード書いてるのかを説明してくれないと。

**デフォルトの名無しさん** · 2017/11/30(木) 19:20:57.05

>>338
RustがRustで書かれてるのだからRustのリポジトリのコードを読んで参考にすれば勉強になるのでは？

https://github.com/rust-lang/rust/search?l=rust

**デフォルトの名無しさん** · 2017/11/30(木) 19:27:22.21

>>338
cと触れる部分はしょうがないんじゃないの？
その何回も触ってる部分をcで書いてインターフェイスを最小化した後で
rust から呼び出す方が正解なんじゃないかね。

**デフォルトの名無しさん** · 2017/12/01(金) 00:02:21.38

Rustに限らず他言語で書かれたライブラリを利用するときは呼び出し元言語の作法に適合するように改修しないと使いにくいことが多いような

**デフォルトの名無しさん** · 2017/12/01(金) 00:53:10.98

>>338
> Rust的な設計の指針というかコツみたいのって無いですかね…

私も知りたいです！

**デフォルトの名無しさん** · 2017/12/01(金) 18:20:32.47

>>338 見た感じFoo::xxx : &mut Self -> BarとかFoo::zzz: &mut Self -> bazとなっているのでbarやbazが生きてるとfooにアクセスできないのが直近の原因だと思うけど、
xxxやzzzが本当にFooの変更を伴わないといけないのかを考えないといけない
CellやRefCellを使ってinterior mutabilityを導入したらFoo::xxx: &Self -> Barというメソッドにできる可能性がある
まあ実際のソースがどんなもんなのか知らないから適当だけど

**デフォルトの名無しさん** · 2017/12/02(土) 18:50:17.68

https://doc.rust-lang.org/book/first-edition/crates-and-modules.html

japaneseってrust作成者らって日本語好きなの？

**デフォルトの名無しさん** · 2017/12/02(土) 19:17:25.64

トーキョー、サムライ、ハラキリ、ゲイシャ！