12/01/25 20:05:49.96 .net
Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。
URLﾘﾝｸ(www.rust-lang.org)
2:デフォルトの名無しさん
12/01/25 20:09:28.45 .net
もうJavaの亜種はおなかいっぱい
3:デフォルトの名無しさん
12/01/25 20:52:58.74 .net
なんでこんなネガティブな名前なの
4:デフォルトの名無しさん
12/01/25 21:03:34.50 .net
次世代Mozillaというキラーアプリを書くための言語ってことで
相当期待していいんじゃないの。
5:デフォルトの名無しさん
12/01/25 21:56:42.64 .net
これ、BLISSと同じ式言語なのな。
6:デフォルトの名無しさん
12/01/26 02:15:43.94 .net
チュートリアルぱっと眺めてみたけどmodとかifaceとか予約語のセンスの
悪い省略っぷりだけで流行らない臭いがプンプンした。
今時IDEで入力するからそんな中途半端な省略いらんだろ。
7:デフォルトの名無しさん
12/01/26 02:32:43.15 .net
>>6
fnとかダセェｗ
8:デフォルトの名無しさん
12/01/26 02:33:52.49 .net
Fnキーかと思った
9:デフォルトの名無しさん
12/01/26 04:26:12.06 .net
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
10:デフォルトの名無しさん
12/01/26 08:08:35.07 .net
予約語があえて一般名とかぶらないようにする利点のひとつに
変数名などに一般名を利用した時にかぶらない、というのがある。
11:デフォルトの名無しさん
12/01/26 23:47:15.02 .net
キーワードとかは最初取っ付きにくいかもするけど、なかなか良さげな感じ。
12:デフォルトの名無しさん
12/01/27 04:10:03.22 .net
Hello, World見た瞬間に駄目だわこれおもたわ
いまどきfu[Enter]でfunctionが出るIDEもあるのにな。fmtも蹴り飛ばしたくなる。
> Rust's alt construct is a generalized, cleaned-up version of C's switch construct.
>
> alt my_number {
> 0 { std::io::println("zero"); }
> 1 | 2 { std::io::println("one or two"); }
> 3 to 10 { std::io::println("three to ten"); }
> _ { std::io::println("something else"); }
> }
これがcleaned-up versionってどんな美的センスだよ。
いらん独自性を発揮してgdgdになっとるわ。
まあ名前通りの言語のようだな。
いかにも言語オタが考えた感じ。これ以上0.1秒も関わりたくない。
13:デフォルトの名無しさん
12/01/27 04:21:56.48 .net
名前省略自体は個人的にはぜんぜんオッケーなのだけど
functionならfnかfunがよかったな。それはさておき
std::io::println("one or two");
IPv6アドレスみたいでステキ
14:デフォルトの名無しさん
12/01/27 13:48:49.83 .net
::の多用はダサい。
15:デフォルトの名無しさん
12/01/27 17:40:31.63 .net
>>12
>いまどきfu[Enter]でfunctionが出るIDEもあるのにな。fmtも蹴り飛ばしたくなる。
入力が楽になることよりも、見た目が見やすくなることのほうが大事だろ。
「function」なんて自己主張が強すぎる。「fn」や「def」ぐらい短い方が控えめで見やすい。
callback(x, y, function() { ... } ) // JS
より callback(x, y) { ... } # Ruby
のほうがだんぜん読みやすいしな。
16:デフォルトの名無しさん
12/01/27 17:47:45.51 .net
変数名をよく短い形で書くから嫌だな
17:デフォルトの名無しさん
12/01/27 19:58:14.45 .net
defは良いがfnはねえよ
18:デフォルトの名無しさん
12/01/27 19:59:47.77 .net
昔のLispの本を見ると時々たまに見かける
19:デフォルトの名無しさん
12/01/27 20:51:32.20 .net
fnなんて中途半端はやめてfにしろよ
20:デフォルトの名無しさん
12/01/27 21:44:38.89 .net
これってネイティブコンパイラ？
21:デフォルトの名無しさん
12/01/28 00:44:54.49 .net
ぶっちゃけ昔のBASICみたいで私は好きよ
22:デフォルトの名無しさん
12/02/07 01:29:54.05 .net
マルチコア、メニーコア時代
これは、ひょっとするかも知れないね
23:デフォルトの名無しさん
12/02/09 19:28:30.25 .net
見た目の話ばっかりじゃねぇか
24:デフォルトの名無しさん
12/02/14 05:37:02.70 .net
Goの勢いが異常だったのか
go
ｽﾚﾘﾝｸ(tech板)
>1 デフォルトの名無しさん 2009/11/11(水) 15:23:15
Go part3
ｽﾚﾘﾝｸ(tech板)
>1 デフォルトの名無しさん 2009/11/24(火) 23:14:03 /
25:デフォルトの名無しさん
12/02/16 00:24:45.10 .net
まぁ、まだバージョンも0.1だし。
俺法則だとソフトウェアはメジャーバージョンが3あたりが丁度良い。
26:デフォルトの名無しさん
12/03/17 18:05:57.64 .net
>>24
Goはあのマスコットキャラがきもい
27:デフォルトの名無しさん
12/03/17 18:13:32.34 .net
これだろ？まじきもいよな
URLﾘﾝｸ(www.tv-asahi.co.jp)
28:デフォルトの名無しさん
12/03/18 11:10:53.28 .net
>>24
Goはコンセプトが明快かつ独自性もあったからな
そしてあのGoogleが、あのRob Pikeがという話題性も付随してたし
だがRustは「数多提案されたCの代替の一つだろ？」で済んでしまう
見た目の話に終始してるのも、Cの代替として使いやすいのか？という視点で見られているからだし
29:デフォルトの名無しさん
12/03/24 01:56:34.48 .net
Goスレ落ちてたからもう見限る
これ流行るか？
30:デフォルトの名無しさん
12/03/24 02:24:39.97 .net
Firefoxに載ってからが勝負だろ
そのためにはDartにコケてもらわないとな
31:デフォルトの名無しさん
12/03/24 10:23:58.67 .net
いや、DartとRustは全く用途が違うんだが…
32:デフォルトの名無しさん
12/03/24 16:57:17.00 .net
Mozillaがリリースってだけで勘違いしちゃったんだろうね
33:デフォルトの名無しさん
12/03/24 21:18:54.50 .net
FirefoxのバックエンドがRustで書かれるようになるってのは何年後なんだろうな
34:デフォルトの名無しさん
12/03/25 05:39:43.79 .net
コアプロジェクトで無いとはいえ３年掛かってようやくv0.1という
歩みの遅さを見れば、そんな日は来ないと思えるわな
35:デフォルトの名無しさん
12/05/16 01:47:27.44 .net
完成度は高いんだけどなぁ
36:デフォルトの名無しさん
12/05/20 12:33:46.53 .net
URLﾘﾝｸ(github.com)
コンパイラ以外の実用例が出てきたな
37:デフォルトの名無しさん
12/05/23 15:55:37.46 .net
Note that Servo is a research project, it may or may not become an actual product.
まあ元々それのために作ってたもんだしな
38:デフォルトの名無しさん
12/07/01 03:26:06.09 .net
0.3ﾏﾀﾞｧ?
39:デフォルトの名無しさん
12/07/07 09:31:58.43 .net
Note development roadmap
URLﾘﾝｸ(github.com)
40:デフォルトの名無しさん
12/07/13 10:35:38.10 .net
[rust-dev] Rust 0.3 released
URLﾘﾝｸ(mail.mozilla.org)
41:デフォルトの名無しさん
12/08/06 13:59:02.80 .net
作者Graydon Hoareへのインタビュー
URLﾘﾝｸ(www.infoq.com)
"it seems a long time ago when @sayrer and I agreed to invest in
@rustlang. But it was not, in Internet time."
URLﾘﾝｸ(twitter.com)
42:デフォルトの名無しさん
12/08/11 02:31:50.01 .net
URLﾘﾝｸ(www.infoq.com)
日本語版。
英語併記するくらいなら原語に統一すればいいのに
43:デフォルトの名無しさん
12/08/22 13:46:06.71 .net
最近 Perl みたいな記号地獄になりつつある
44:デフォルトの名無しさん
12/08/23 14:28:35.10 .net
URLﾘﾝｸ(mozillamemes.tumblr.com)
45:デフォルトの名無しさん
12/08/29 03:39:36.89 .net
URLﾘﾝｸ(smallcultfollowing.com)
46:デフォルトの名無しさん
12/09/01 19:29:13.78 .net
JITコンパイラ！
URLﾘﾝｸ(blog.z0w0.me)
47:デフォルトの名無しさん
12/09/20 01:17:13.40 .net
~"UNIQUE STRINGS EVERYWHERE" は見直すつもりなさそう
Mozillaに腱鞘炎が流行する日も遠くないな
48:デフォルトの名無しさん
12/09/24 11:43:06.43 .net
URLﾘﾝｸ(speakerdeck.com)
49:デフォルトの名無しさん
12/10/01 13:17:32.11 .net
URLﾘﾝｸ(github.com)
ぱっと見は整理されてるような
個人的にgoよりは見やすくかんじたが
Cとのバインディングとかはやり難そうかな
50:デフォルトの名無しさん
12/10/01 18:26:43.02 .net
"This four-post series on Rust is intended to introduce you to the language,
to teach you about Rust's cool language features"
URLﾘﾝｸ(winningraceconditions.blogspot.jp)
51:デフォルトの名無しさん
12/10/13 17:50:46.65 .net
月曜に0.4出るってよ
52:デフォルトの名無しさん
12/10/16 17:20:09.68 .net
[rust-dev] Rust 0.4 released
URLﾘﾝｸ(mail.mozilla.org)
53:デフォルトの名無しさん
12/10/17 17:37:54.93 .net
* Syntax
* All keywords are now strict and may not be used as identifiers anywhere
* Keyword removal: 'again', 'import', 'export', 'check', 'new', 'owned', 'send', 'of', 'with', 'to', 'class'.
* Classes are replaced with simpler structs
* Explicit method self types
* `ret` became `return` and `alt` became `match`
* `import` is now `use`; `use is now `extern mod`
* `extern mod { ... }` is now `extern { ... }`
* `use mod` is the recommended way to import modules
* `pub` and `priv` replace deprecated export lists
* The syntax of `match` pattern arms now uses fat arrow (=>)
* `main` no longer accepts an args vector; use `os::args` instead
かなり変わったな。チュートリアルもなんだか縮小したし、一通り勉強してみたけど、
仕様が落ち着くまで離れとくか。
54:デフォルトの名無しさん
12/10/20 20:59:13.37 .net
互換性がなくなるような変更はなるべく0.4に詰め込んだみたいなこと言ってたけど、
0.2のときもそんなこと言ってたし今後もモリモリ変化しそうだな
55:デフォルトの名無しさん
12/12/22 20:08:12.52 .net
[rust-dev] Rust 0.5 released
Version 0.5 (December 2012)
---------------------------
* ~900 changes, numerous bugfixes
忍法帖のせいでリンク貼れねぇ。。。
56:デフォルトの名無しさん
13/02/02 00:24:16.59 .net
保守
それなりにユーザー増えてきたね
www.reddit.com/r/rust/
57:デフォルトの名無しさん
13/02/23 03:01:37.29 .net
let a = vec::filter([~"foo", ~"bar"], |&x| { str::starts_with(x, ~"f") });
な感じのコードを書いたときに出てくる
warning: instantiating copy type parameter with a not implicitly copyable type
の意味と解決法を教えてください
58:デフォルトの名無しさん
13/02/24 21:22:56.45 .net
>>57
Rust 0.5だとvec::filterの第1引数はコピー可能な値の配列でなければならない
~str型の値は暗黙的にコピーできないから明示的にcopy修飾子を書く必要があるんだけど、
そうしてないから警告が出てる
次に出るRust 0.6からはvec::filterの定義が変わって、配列の値がコピー可能である必要はなくなった
解決方法は、|&x|のあたりにcopyを書く（どこに書くかは忘れた）か、
incomingブランチのsrc/libcore/vec.rsからvec::filterをコピペして使うとか
59:デフォルトの名無しさん
13/02/24 21:39:10.10 .net
補足
Rust 0.6ではvec::filteredとvec::filterに分かれてる
vec::filteredは配列の各要素をコピーして返す（0.5のvec::filterと同じ）
0.6のvec::filterは配列のオーナーシップが移動するようになってて、要素はコピーされない
オーナーシップが移動ってことはつまり、
渡せるのは~[T]だけで@[T]は不可、んで渡した配列はそれ以降参照できなくなる
60:デフォルトの名無しさん
13/02/24 22:28:47.69 .net
ありがとうございます
所有権についてはC++で少しやったつもりでいましたが
なかなかどうして精進が足りませんね
61:デフォルトの名無しさん
13/02/28 22:58:06.05 .net
>all Rust executables require a MinGW installation at runtime
もしかしてwindowsでバイナリ配るのハードル高い
62:デフォルトの名無しさん
13/03/28 14:29:15.85 .net
最近触りだしたけど、いい言語だな
63:デフォルトの名無しさん
13/04/01 02:47:35.67 .net
[rust-dev] 0.6 prerelease testing
URLﾘﾝｸ(mail.mozilla.org)
64:デフォルトの名無しさん
13/04/04 14:37:04.74 .net
rust 0.6 なんか面白そうだと思って拾ってみた。コンパイル終わらない…。
でもこれ、C/C++ に文法が似てるって嘘だと思う。{} を使うって以外は、全然違うじゃん。
65:デフォルトの名無しさん
13/04/04 21:01:21.86 .net
文法だけは似てるとおもう
66:デフォルトの名無しさん
13/04/04 21:03:52.14 .net
HaskellやらMLやらErlangやらに比べれば似てるよねってことだよ
[rust-dev] Rust 0.6 released
mail.mozilla.org/pipermail/rust-dev/2013-April/003427.html
67:デフォルトの名無しさん
13/04/04 21:14:22.06 .net
* Syntax changes
* The self type parameter in traits is now spelled `Self`
* The `self` parameter in trait and impl methods must now be explicitly named (for example: `fn f(&self) { }`). Implicit self is deprecated.
* Static methods no longer require the `static` keyword and instead are distinguished by the lack of a `self` parameter
* Replaced the `Durable` trait with the `'static` lifetime
* The old closure type syntax with the trailing sigil has been removed in favor of the more consistent leading sigil
* `super` is a keyword, and may be prefixed to paths
* Trait bounds are separated with `+` instead of whitespace
* Traits are implemented with `impl Trait for Type` instead of `impl Type: Trait`
* Lifetime syntax is now `&'l foo` instead of `&l/foo`
* The `export` keyword has finally been removed
* The `move` keyword has been removed (see "Semantic changes")
* The interior mutability qualifier on vectors, `[mut T]`, has been removed. Use `&mut [T]`, etc.
* `mut` is no longer valid in `~mut T`. Use inherited mutability
* `fail` is no longer a keyword. Use `fail!()`
* `assert` is no longer a keyword. Use `assert!()`
* `log` is no longer a keyword. use `debug!`, etc.
* 1-tuples may be represented as `(T,)`
* Struct fields may no longer be `mut`. Use inherited mutability, `@mut T`, `core::mut` or `core::cell`
* `extern mod { ... }` is no longer valid syntax for foreign function modules. Use extern blocks: `extern { ... }`
* Newtype enums removed. Use tuple-structs.
こりゃまた随分と
68:デフォルトの名無しさん
13/04/05 23:28:45.01 .net
頑張ってんね
69:デフォルトの名無しさん
13/04/06 20:51:22.53 .net
リリースノートに載ってないけどしれっと pure キーワードがなくなってる
70:デフォルトの名無しさん
13/04/06 21:07:52.13 .net
borrowed pointerとmutabilityの扱いが変わったおかげで、
pureがいらなくなった
71:デフォルトの名無しさん
13/04/10 00:53:09.94 .net
セミコロンがあると値がnilになるってのは、
バグの温床になりそうだなー
72:デフォルトの名無しさん
13/04/10 09:07:44.24 .net
おれも仕様読んでちょっと気になったが、コンパイルでほぼチェックできるんじゃないのかね？
73:デフォルトの名無しさん
13/04/10 12:33:33.44 .net
最近触ってなかったけど、セミコロンがあると返ってくるのはvoidじゃなかったか
74:デフォルトの名無しさん
13/04/10 13:04:25.52 .net
ブロックの最後の式に;が付いてる場合は、
そのブロックが値を持たない(=voidを返すなの？)って話だよね？
75:デフォルトの名無しさん
13/04/10 13:22:24.50 .net
() と書いて nil = void だったか。
$ cat test.rs
fn test() -> () {
io::println("2");
}
fn main() {
io::println("1");
let a : () = test();
if a == () {
io::println("3");
}
}
$ rustc test.rs
$ ./test
1
2
3
こういうのもできるのか。
76:デフォルトの名無しさん
13/04/10 18:37:34.99 .net
値を返すべきブロックからうっかりnilを返したら、
その値を使う箇所でコンパイル時に型エラーが出るから問題ないよ
77:デフォルトの名無しさん
13/04/20 16:47:37.45 .net
法則発動でオワコン
78:デフォルトの名無しさん
13/04/20 18:08:39.74 .net
じゃあAndroidはいまごろ瀕死になってないと
79:デフォルトの名無しさん
13/04/24 22:18:08.03 .net
あくまで一サプライヤーとして利用するなら法則も回避できるのだがFirefoxOSはどうなるか。。。
80:デフォルトの名無しさん
13/04/25 06:57:16.70 .net
そもそもオープンソースの協力者の一つでしかないし。
81:デフォルトの名無しさん
13/06/16 00:12:12.46 .net
ほっしゅほっしゅ
82:デフォルトの名無しさん
13/07/05 NY:AN:NY.AN .net
v0.7 is coming.
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(www.rust-lang.org)
83:デフォルトの名無しさん
13/07/12 NY:AN:NY.AN .net
URLﾘﾝｸ(stackoverflow.com)
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(groups.google.com)
年末にはだいぶモノになるとかいってるけど
だいぶ先は長そうだなこれ…
84:デフォルトの名無しさん
13/07/14 NY:AN:NY.AN .net
もう諦めて寝るわ。1.0になったら起こしてくれ
85:デフォルトの名無しさん
13/07/14 NY:AN:NY.AN .net
一目ゴミっすね。
86:デフォルトの名無しさん
13/07/15 NY:AN:NY.AN .net
土方にはゴミにしか見えんだろうな
87:デフォルトの名無しさん
13/07/18 NY:AN:NY.AN .net
わかりやすい日本語解説きたで
URLﾘﾝｸ(gifnksm.hatenablog.jp)
88:デフォルトの名無しさん
13/07/20 NY:AN:NY.AN .net
早く1.0になってクレヨン
89:デフォルトの名無しさん
13/07/22 NY:AN:NY.AN .net
mut 周りがよく分からんな。 C++ でいう
int* const
int const*
みたいな区別はない（0.2 くらいのときはあった気がするけど）んだよね。
90:デフォルトの名無しさん
13/07/22 NY:AN:NY.AN .net
>>89
昔は構造体のフィールドに mut をつけて、そこだけミュータブルにすることはできたね。
今は、データの所有者のミュータビリティが継承されるという仕様だから、
データの一部だけがミュータブルということはなくて、
全部ミュータブルかイミュータブルの2つしかない。
ただし、例外が @ で表されるマネージドボックス。
これは所有者が複数いるので、所有者のミュータビリティを継承するのでは無く、
ボックス自体がミュータブルかイミュータブルかの属性をもっている (@ と @mut)。
なので、@ を使えば C++ でいう例のようなことは一応できる。
Rust では @ の使用をできるだけ避けようという風潮があるから、
C++ と同じ事をやる目的で @ を使うのはあまり推奨されないとは思う。
91:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN .net
>>90
分かりやすい説明ありがとう。 @-ptr が mutability を継承しないという点が分かってなくて
コード書いていて混乱した。って Tutorial にも書いてあるね。最近読み返してなかった。すまん。
92:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN .net
あと、
(~[0]).push(1); // OK
(@mut [0]).push(1); // NG
メモリの再配置が行われる可能性のある操作が @mut [T] で不可能なのは
考えてみればそうなのだけど、ちょっとびっくりする。
93:デフォルトの名無しさん
13/09/27 21:30:47.89 .net
v0.8 is coming.
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(www.rust-lang.org)
94:デフォルトの名無しさん
13/10/25 06:37:23.40 .net
C++でいいような気がしてきた
95:デフォルトの名無しさん
13/10/25 23:47:33.48 .net
いつなったら1.0になるのよ？
96:デフォルトの名無しさん
13/10/27 14:59:23.36 .net
あまりに大きな変更は2.0に持ち越すとか言ってる1.0はそう遠くないと思う、半年とか1年以内には
>>94
GCを言語コアからライブラリに追い出すことが決まったあたりから、
競合のDやGoよりもシステム寄りの、ちょうど今C++が占めてるニッチを奪おうぜって流れになった
URLﾘﾝｸ(pcwalton.github.io)
97:デフォルトの名無しさん
13/11/28 00:01:30.48 .net
死ねバカｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
死ねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
死ねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
死ねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗ
ゴミｗｗｗｗｗｗｗｗｗｗｗｗゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
死ねゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗコラｗｗｗｗｗｗｗｗｗｗｗｗ
死ねコラゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
98:デフォルトの名無しさん
14/01/04 23:59:41.80 .net
ゴミではない
錆だ
99:デフォルトの名無しさん
14/01/06 06:20:11.18 .net
C4のレシピってゾンビからドロップしますか?
100:デフォルトの名無しさん
14/01/10 22:48:46.46 .net
0.9来たか
101:デフォルトの名無しさん
14/01/17 11:19:41.93 .net
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(sourceforge.jp)
0.9になっても結構変更あるな。Managed boxes (@) が非推奨てｗ
102:デフォルトの名無しさん
14/01/17 11:37:16.72 .net
1.0は2014年末の予定とか URLﾘﾝｸ(cmr.github.io)
103:デフォルトの名無しさん
14/01/17 12:00:54.65 .net
Rust on rails、トップシェアになる
104:デフォルトの名無しさん
14/01/17 12:01:44.79 .net
「レール上の錆」か……
105:デフォルトの名無しさん
14/01/18 20:24:08.48 .net
あと1年もこの調子で変更すんの?
とっとと1.0出してよ
106:デフォルトの名無しさん
14/01/19 13:30:19.84 .net
おい、台本ちゃんと読めよ そこの台詞は
「けっノロマめ、俺がフォークして先に1.0を立ち上げちまったぜ」
だろ
107:デフォルトの名無しさん
14/01/26 22:35:01.51 .net
どちらかというと v1.0 以降の破壊的変更の方に期待してしまう（マゾ）。
108:デフォルトの名無しさん
14/01/26 22:46:55.05 .net
良く訓練されたD言語erのような性癖だな
109:デフォルトの名無しさん
14/01/26 22:49:10.16 .net
Feature gate なんて大義名分があるんだからいくらでも破壊的変更してきそうだよな
ワクワクする
110:デフォルトの名無しさん
14/02/21 19:40:13.77 .net
rust速いらしいけどgoに比べて並列化し辛いから結局goのが速いって聞いてんですけどそんな感じなの？
111:デフォルトの名無しさん
14/02/21 22:04:36.27 .net
シングルスレッド遅い言語はどんなに並列化しても無駄
112:デフォルトの名無しさん
14/02/22 04:50:05.65 .net
>>110
その手の、Erlangっぽい並列処理は、ライブラリレベルで実装可能。
Scala/JavaのAkkaがその実例。
113:デフォルトの名無しさん
14/03/17 11:54:37.97 JigeyuIH.net
破壊的変更が毎週たくさんあるね
114:デフォルトの名無しさん
14/03/30 07:00:36.43 aNkl6/ok.net
次期バージョンは0.10かね
115:デフォルトの名無しさん
14/04/14 02:41:46.21 AgBD4gFn.net
v0.10 is coming.
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(github.com)
・@ ポインタを remove
・do キーワードを remove
・etc...
116:デフォルトの名無しさん
14/05/21 09:58:53.67 Fj6ednoX.net
なんで1.0が出てから始めないん
117:デフォルトの名無しさん
14/06/09 22:39:55.58 nLviVS/4.net
DとかGoとかポストC気取ってるくせにCを駆逐する気がない言語より頑張って欲しい
118:デフォルトの名無しさん
14/06/12 00:32:07.72 e6x9cJlC.net
頑張って欲しいけど、1.0 が遅いから Swift に浮気しちゃうぜ
119:デフォルトの名無しさん
14/07/06 20:45:53.22 8W/9eoDc.net
rustでRAIIはどう実現したら良いのでしょうか
120:デフォルトの名無しさん
14/07/09 09:47:39.31 ICY9ltLE.net
v0.11 is coming.
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(github.com)
・構造体のフィールドがデフォルトで private に
・private enum 変数が不許可に
・priv キーワードを remove
・`use foo, bar, baz;` シンタックスが remove
・……
121:デフォルトの名無しさん
14/07/26 21:14:51.31 fwCKMr/Y.net
Rust言語の明日は何処だ
122:デフォルトの名無しさん
14/08/08 02:51:15.07 lSQPAJbI.net
C++を駆逐するなら大歓迎だ
123:デフォルトの名無しさん
14/08/10 14:07:48.02 FUhgKhzg.net
>>122
俺も同意。
Rust頑張れ。
124:デフォルトの名無しさん
14/08/10 15:13:03.34 rgbQez8I.net
それならDとGoに勝たないといけない
おれはRustに頑張って欲しいから早く1.0だして欲しいけど、もう手遅れな気はしてる
125:デフォルトの名無しさん
14/08/10 15:30:16.69 AMGvL8Wx.net
DはともかくGoは厳しかろうなあ
126:デフォルトの名無しさん
14/08/10 16:15:08.44 559thib6.net
GoではC++の駆逐はできないと思う。
たとえば、goでOSを作れるかというとそうではない
127:デフォルトの名無しさん
14/08/10 18:47:02.34 mPHamUGI.net
C++の代わりになるのはCで作られたlibやDLLを直接呼べなくてはならないが
Dはヘッダーファイル作ればできるけど
Goは問題外だった。
rustってどうやんの？
128:デフォルトの名無しさん
14/08/10 20:21:22.22 7WLKXo+Z.net
extern "C" とかつけて関数宣言すると、Cの関数が呼び出せる。
呼び出し時の余計なオーバーヘッドとかは今はなくなってるはず
129:デフォルトの名無しさん
14/08/12 23:54:09.61 pueQuLPm.net
次のC++17までに実用になってなかったら逆に駆逐されるな
130:デフォルトの名無しさん
14/08/13 16:43:46.11 450ISMpY.net
>>128
おお、良いぞ。そんな感じで十分だ。
C++は規格化に関わってる連中が（ここだけの話）キモいので駆逐してほしい
131:デフォルトの名無しさん
14/08/20 17:02:00.56 cYiGvIKn.net
C++で中間コード吐き出すコンパイラ作ったほうが喜ばれる
132:デフォルトの名無しさん
14/09/17 09:15:58.87 y1+4ScdQ.net
Road to Rust 1.0 URLﾘﾝｸ(blog.rust-lang.org)
133:デフォルトの名無しさん
14/09/19 01:19:00.42 oDXr8xMe.net
はよ 1.0 になれ
134:デフォルトの名無しさん
14/09/25 22:01:45.45 /UWIY2F4.net
Mozillaは永遠にベータ版しか出さん連中だから無理
135:デフォルトの名無しさん
14/10/02 23:11:57.53 C3h6KQmN6
これ、C風の見かけのために curly braces { } 使ってるだけで、中身は露骨にML系言語だよね。
もっとML寄りの記法で書けるようにしてほしいなあ。
136:デフォルトの名無しさん
14/10/10 08:24:39.99 iwp7TUt6.net
[rust-dev] Rust 0.12.0 released
URLﾘﾝｸ(mail.mozilla.org)
137:デフォルトの名無しさん
14/10/10 12:32:52.94 tQ87SuYa.net
1.0ｺﾈｰ
138:デフォルトの名無しさん
14/10/12 00:12:55.83 wVymFFZ9.net
だいぶ見ないうちにもはや別言語になっとる。
es6みたいにどうせ新機能使ったら互換性なくなるのにbreak the webとか抜かして右往左往し続けて
仕様がコロコロ変更されるより元から破壊的変更上等だけどバージョンが安定しないな。
139:デフォルトの名無しさん
14/10/12 23:09:08.17 fD2p7D4P.net
moveって名前の関数つくれないんだ？
140:デフォルトの名無しさん
14/10/13 01:56:12.89 NYVg+AhM.net
moveはキーワードだから、使えない
141:デフォルトの名無しさん
14/10/21 13:03:52.26 4Y1dgKOT.net
仕様が安定するのはいつですか
142:デフォルトの名無しさん
14/10/29 00:30:10.05 uvk5/wlk.net
&strとstringやっぱめんどくさい。
せめてリテラルの中に変数値埋め込むような書式が欲しいけどそれだとそもそも&strにならない。
もう文字列リテラルはstringにしてくれよ
143:デフォルトの名無しさん
14/10/29 08:02:03.12 PJ7XKhhs.net
文字列リテラル書く度にメモリの動的確保するのは、
さすがに発狂ものだろ
slicing_syntax使えば、.as_slice()が[]になるし、それで我慢してくれ
144:デフォルトの名無しさん
14/10/29 08:43:24.44 Seh2VPHk.net
stringといえばcoreutilsのコード読んでて思ったんですが
URLﾘﾝｸ(github.com)
> let show_nonprint = matches.opts_present(["A".to_string(), "e".to_string(), "t".to_string(), "v".to_string()]);
こういういちいちto_string()してるコードもうちょっと上手く書けませんかね
145:デフォルトの名無しさん
14/10/29 21:06:45.55 GrpYtfpz.net
これの解決方法を教えてください
URLﾘﾝｸ(melpon.org)
146:デフォルトの名無しさん
14/12/13 09:03:40.20 BbKnnj5O.net
Rust 1.0: Scheduling the trains
URLﾘﾝｸ(blog.rust-lang.org)
はよ
147:デフォルトの名無しさん
15/01/05 00:17:31.79 62ndYAiq.net
公式のGuideに従って Hello, world! コンパイルしたら600kBくらいのができたんだけど、これ何が入ってるの？
たしかGoもこんなだったっけw
148:デフォルトの名無しさん
15/01/05 23:04:03.12 XrgG4/ce.net
>>147
標準ライブラリが静的リンクされてる。
jemallocとかサイズでかいらしい。
-C lto つけてリンク時最適化有効にすると若干サイズ縮むはず
149:デフォルトの名無しさん
15/01/09 16:50:57.81 1ny7jOif.net
ガイドページの右下に出てる
Rust 1.0.0-nightly
ea6f65c5f
って何？
150:デフォルトの名無しさん
15/01/09 21:31:25.08 ecLcmkaN.net
ドキュメントのバージョンだよ。
151:デフォルトの名無しさん
15/01/10 09:03:15.68 qZSZ4EVX.net
1.0のalpha来てた
もうすぐ安定するんだと思うとなんだか感動する
152:デフォルトの名無しさん
15/01/10 09:25:29.41 aqSa96PR.net
楽しみだね。
153:デフォルトの名無しさん
15/01/10 10:50:52.48 VYrUioRX.net
Guessing Gameまで来たら
↓が変な感じがする。値を返すかcontinueで離脱。例外みたいなノリなんだろうか
let num = match input_num {
Some(num) => num,
None => {
println!("Please input a number!");
continue;
}
};
154:デフォルトの名無しさん
15/01/12 07:44:13.71 V9nd0xt7.net
見てきたけど
uint に変換できない場合
None が返って来て、
もう一度 loop の最初からやり直し
なだけじゃないか？
Option で返って来るのに慣れてないのかな？
例外については下記が日本語訳(ただし、前のverなので文法が違うかもしれない)
URLﾘﾝｸ(qiita.com)
155:153
15/01/12 14:05:00.11 uQy2oTpW.net
ああなるほど、None（と言うか() のことかな？）を返してからcontinue動作したと考えればいいのか
156:デフォルトの名無しさん
15/01/12 14:14:00.52 smRTP4TA.net
そこ俺も違和感あった
HaskellやOCamlにおけるパターンマッチは条件分岐というよりも値の分解の意味合いがつよいと思うのだけど, Rustでは条件分岐としての側面が強いのかなと感じた
要するにif文ってことだよね
157:デフォルトの名無しさん
15/01/13 00:20:23.58 iAaaaZAE.net
大域脱出と見ればそんなに違和感ないと思う
bookに記載はされてないけど縦棒で複数のパターンに対応させることもできるのな
match foo {
Bar | Baz => do_X,
Huga => do_Y
_ => do_Other
}
みたいなのもいけた。無かったら嫌だなと思ってたがreferenceにはあった
158:デフォルトの名無しさん
15/01/13 21:46:02.73 oe8+YAa0.net
>>156
ガチの関数型とはなんか違うfeelingと言うか空気感を感じる
159:デフォルトの名無しさん
15/01/13 22:27:52.83 QfRKSulC.net
関数からIteratorを返す方法が分かりません
具体的には型に何書いて良いか分からない
160:デフォルトの名無しさん
15/01/14 00:27:11.46 e9uoW40m.net
>>158
Rustの良さの一つではあると思う
メモリモデルの問題で普通の関数型プログラミング言語と全く同じようには出来ない中で、なるべく関数型の良さを取り入れようという結果なんだろうな
161:デフォルトの名無しさん
15/01/14 00:48:27.71 MazRL5ri.net
>>159
関数の中身によるけど、
戻り値書かなかった場合のコンパイルエラーで出てる型名コピペすればたぶんいけると思う
162:デフォルトの名無しさん
15/01/15 20:50:25.52 b84/qUeG.net
言語が固まったらREPLの開発も再開するよね
163:デフォルトの名無しさん
15/01/15 21:34:03.91 E2BgZv7k.net
RustでREPLはめんどくさそうだな
寿命とか
でっかいひとつのスコープって考えたら別にむずかしくはないのな
164:デフォルトの名無しさん
15/01/16 14:15:52.84 9+9TOoEF.net
1.0.0-alpha をビルドしてるんだけど
configure に --libdir=/usr/lib64 を指定すると
lib.rs がコンパイルエラーになってしまう
前からこんなんだったっけ・・・
165:デフォルトの名無しさん
15/01/16 22:33:39.21 KEq1J0ex.net
ここ最近の怒涛の変更はヤバい
166:デフォルトの名無しさん
15/01/17 00:15:44.35 Wxv5Etsa.net
clayもそうだったけど、llvm使った言語のビルドってすげー時間かかるのな。ナイトリービルド落とした方がええわ。
167:デフォルトの名無しさん
15/01/17 02:06:27.12 CWvWtJ6X.net
クロージャ周りが変更されまくってて全然わからん
168:デフォルトの名無しさん
15/01/17 18:17:59.12 H+D/soOr.net
そろそろ試してみようと思ったらまだそんな感じなの?
169:デフォルトの名無しさん
15/01/17 18:38:22.05 rzZFM78t.net
これから構文の変更は極力減らすらしいし、1.0がリリースされるまでのあと2～3ヶ月は詰めの時期だろう
ドキュメント周りは絶賛崩壊中。Rust by Exampleとか全然動かん（Issueは立ってるけど）
まあ検索しても古いブログとか引っかかりまくるからな―
なんかあったらGitHub該当レポをいちいち見に行くくらいのことをしないと勉強するのは厳しい
170:デフォルトの名無しさん
15/01/17 18:40:22.92 CWvWtJ6X.net
構文の変更はなくてもAPIの変更はあったりするんだろうか
171:デフォルトの名無しさん
15/01/17 19:02:31.26 P4fG3Fn9.net
このスレ立ったときから安定したら使ってみようと思ってたけど
もう少しらしいね
172:デフォルトの名無しさん
15/01/17 19:41:57.99 Om8PoyqQ.net
ベータのリリースサイクルでライブラリの安定化やるから、
APIはまだまだ変更されるはず
173:デフォルトの名無しさん
15/01/17 20:40:08.53 H+D/soOr.net
ベータ出てからも長そうだな...
174:デフォルトの名無しさん
15/01/19 03:43:45.49 b8H1tohZ.net
1. 全ての値、変数はそれが定義されたスコープ内で死ぬ(読み書きできなくなる)
2. ある値を殺さずスコープの外に出すには、死ぬ前に外の変数に入れるしかない
3. ただし、参照を外に出すことはできない
lifetimeの原則ってこんなもんだよね？これはまだ分かるけど、ownershipはも少し理解が必要。
マルチスレッドを学ぶときにきっと理解できると信じてる。
175:デフォルトの名無しさん
15/01/20 02:47:53.78 CAQhwwqz.net
fnで定義される関数とクロージャって区別されてるのか。fnで定義できる関数は環境を持たないクロージャとして扱うことができるけど、逆は無理なのな。
fn map<S,T> (x:Vec<S>, f:fn(S) -> T) -> Vec<T> { ... }
っていう高階関数はfnで定義される関数しか受け付けないが、
fn map<S,T,F:Fn(&S) -> T> (x:Vec<S>, f:F) -> Vec<T> { ... }
は関数もクロージャも通す。
クロージャの定義を見ればコンパイル時に環境を持たないで済むか分かると思うんだけどなあ
関数 ∈ クロージャみたいな関係なんだから、関数で済むなら関数にして欲しい
176:デフォルトの名無しさん
15/01/20 07:57:01.37 WTvBD7gs.net
unboxed closureならほぼ関数みたいに使えると思うけど。やりたいことは、boxingが必要なケース？
177:デフォルトの名無しさん
15/01/20 08:02:49.45 WTvBD7gs.net
よくわからん事を言ってしまった。
そもそも、クロージャとして扱うってどういう意味で言っている？
rustではクロージャ「型」というものは最近なくなってしまって、
ただFnを実装した型が関数のように呼び出すことが出来るだけという認識。
Fnを実装したある型が関数として定義されているか、
クロージャの構文を使って定義されているかは、
渡される側からは意識する必要がない。
178:デフォルトの名無しさん
15/01/20 14:02:52.06 CAQhwwqz.net
>>177
クロージャとして扱うってのは>>175の二番目のmap<S,T,F:Fn(&S)->T>っていう高階関数は、
fn foo(...)で定義された関数を渡すことができるし、let baz = |&:| { ... }とかやって定義したクロージャを渡すこともできる。
>>175の一番目のmap<S,T>はfnで定義した関数は渡せるけど|&:| {...}は渡せない。
つまり、関数とクロージャは別物なんだけど、クロージャを受け取る高階関数は関数も受け取れる。
それを指して「クロージャを受け取れる高階関数は、普通の関数もクロージャとして扱う」っていう意味で言った。
referenceのfunction typeの項
URLﾘﾝｸ(doc.rust-lang.org)
にもあるとおり、関数の型はfn(args) -> retと書けるもので、traitの実装とかではない。
一方でクロージャはFnトレイトの実装。違いは環境を持つか否か。
179:デフォルトの名無しさん
15/01/20 18:02:24.49 5OYX7sX+.net
>>178
おそらくだけど、Rustの言語仕様で閉じる範囲に関しては、すべて区別せず Fn traitに統一したい意図があると思う。
関数型が残されているのはFFIの都合かと
180:デフォルトの名無しさん
15/01/20 20:43:45.16 CAQhwwqz.net
そうなの？関数内で関数を定義できるからある程度は使えるんだけどな。
ついでに質問なんだけど、Fn traitの記法Fn(s) -> tってのはこれ専用の記法なの？
それとも一般的な記法の一例？
181:デフォルトの名無しさん
15/01/21 01:12:38.06 YXeDnvLj.net
Fn みたいな () -> を使う記法はいまのところFnとFnMutとFnOnce専用だったはず。
他にこの記法使えるとうれしい場面があるならば提案すれば使えるようになるかも。
そもそもこの記法採用されたきっかけというのが、
Fn(A. B) -> C を desugar した形式の Fn<(A, B), C> が書きにくいというのもあるけど、
Fn のdesugarした形式自体がまだfixできていないから、
ひとまずsugarだけ使えるようにして実体の表記は使えなくしようというものだったはず。
実際、Fnの戻り値型はAssociated typeで与えるようにしようとか、
Foo()-> Aの記法は Foo<Output=A> の意味にしようとか、いろいろ議論があるらしい。
当面は、RFCウォッチすると議論が追えると思う。
182:デフォルトの名無しさん
15/01/21 09:15:31.70 mE4mMlsp.net
トップレベルで型注釈を強制するのはひとつの見識だとは思うんだが、
型の表記がもう少しスッキリしたマトモなものじゃないと面倒臭すぎる。
なんでそういうところはMLやHaskellを見習わなかったのか……
183:デフォルトの名無しさん
15/01/21 11:29:22.51 4FCeMM5/.net
>>182
本当だねえ。関数引数リストの中がゴミゴミしい
184:デフォルトの名無しさん
15/01/22 01:22:08.93 KmZyTX6h.net
URLﾘﾝｸ(github.com)
associated typesを使っているtraitが拡張できん…
185:デフォルトの名無しさん
15/01/25 05:05:02.45 47J/10kQ.net
>>184の問題の再現コードは、
trait DeclaredTrait {
type Type;
}
impl DeclaredTrait for i32 {
type Type = i32;
}
struct Struct<B: DeclaredTrait> {
b: B,
b1: B::Type,
}
とあり、 Struct { b: 0, b1: 0}などとするとICEになるが、色々試した結果、Structを少し弄って
struct Struct<T, B: DeclaredTrait<Type=T>> { ...
とすれば回避できることが分かった。やったと小躍りしていたらfixされた。Oh...
186:デフォルトの名無しさん
15/01/29 19:53:46.66 zNgdEinm.net
URLﾘﾝｸ(arthurtw.github.io)
borrowingについてはbookより良い説明になってる。
URLﾘﾝｸ(stackoverflow.com)
この解答はかなりlifetimeについて分かりやすかった。
lifetimeとsubtypingの類似性をまとめようと思ったが力尽きた。
1つの事柄を説明しようとすると別の関連項目も入れた方がいいなとかやってると膨大になる。
187:デフォルトの名無しさん
15/02/04 22:01:24.98 TC60WqWu.net
rustはじめました
バカなんですけど教えてください
fn main() {
let mut a = &1is;
let mut b = &2is;
a = b;
}
b = a だと平気なのに a = b だと叱られます。なぜですか
188:デフォルトの名無しさん
15/02/05 01:26:26.56 dGetvNcg.net
先に宣言した方がlifetimeが長くなるルールだから？
189:デフォルトの名無しさん
15/02/05 01:47:21.88 u4P5BLYw.net
nightlyなら通るよ>>187
190:デフォルトの名無しさん
15/02/05 20:57:01.65 xsa081YG.net
お二方どうも
>>188
どこで寿命尽きるのかlifetimeムズカシイです
>>189
通るのですか
しかしエラー出ます rustc 1.0.0-nightly (eaf4c5c78 2015-02-02 15:04:54 +0000)
githubのをビルドしないとダメでしょうか
面倒なのでブック読みながらバイナリの更新待ちます
191:デフォルトの名無しさん
15/02/06 00:07:57.08 ZZvCiYpX.net
今なら2015-02-04のバイナリ落ちてくるよ
192:デフォルトの名無しさん
15/02/06 01:45:16.44 f5aiPF8n.net
うーん。変わらずエラーが出ます rustc 1.0.0-nightly (ba2f13ef0 2015-02-04 20:03:55 +0000)
本来>187はコンパイル通るものですか
193:192
15/02/06 01:49:34.64 f5aiPF8n.net
エラーこんな感じで
src/main.rs:3:14: 3:17 error: borrowed value does not live long enough
src/main.rs:3 let mut b = &2is;
^~~
src/main.rs:2:17: 5:2 note: reference must be valid for the block suffix following statement 0 at 2:16...
src/main.rs:2 let mut a = &1is;
src/main.rs:3 let mut b = &2is;
src/main.rs:4 a = b;
src/main.rs:5 }
src/main.rs:3:17: 5:2 note: ...but borrowed value is only valid for the block suffix following statement 1 at 3:16
src/main.rs:3 let mut b = &2is;
src/main.rs:4 a = b;
src/main.rs:5 }
194:デフォルトの名無しさん
15/02/06 02:10:23.34 9alBoo2L.net
playpenでも転けるし駄目っぽい
195:デフォルトの名無しさん
15/02/06 17:39:55.66 uj3RHvbm.net
nightlyで通ると言ってた者だが、1月24日のは通ったが、今日2月6日では通らなくなってた。
196:デフォルトの名無しさん
15/02/06 23:25:09.25 gZSM6axtP
やっぱりlifetimeの長い短いとちゃうかなぁ。
>let mut a = &1is;
>let mut b = &2is;
aの型は&'i isize
bの型は&'j isize
だとするとlifetimeの長さはi > jであるからaはlifetime i以上のisizeへの参照を要求する。
bのlifetimeはjであるからnot live long enoughなんじゃないかなぁ。
197:デフォルトの名無しさん
15/02/06 23:36:12.02 gZSM6axtP
うーん、でも
fn print_type_of<T>(_: &T) -> () {
let type_name =
unsafe {
(*std::intrinsics::get_tydesc::<T>()).name
};
println!("{}", type_name);
}
fn main() {
let mut a = &1is;
let mut b = &2is;
print_type_of(&a);
print_type_of(&b);
}
の出力は
&'static isize
&'static isize
やなぁ。
198:デフォルトの名無しさん
15/02/07 01:46:20.54 Gp97gMW3.net
やっぱりlifetimeの長い短いとちゃうかなぁ。
>let mut a = &1is;
>let mut b = &2is;
aの型は&'i isize
bの型は&'j isize
だとするとlifetimeの長さはi > jであるからaはlifetime i以上のisizeへの参照を要求する。
bのlifetimeはjであるからnot live long enoughなんじゃないかなぁ。
199:デフォルトの名無しさん
15/02/07 01:46:51.82 Gp97gMW3.net
うーん、でも
fn print_type_of<T>(_: &T) -> () {
let type_name =
unsafe {
(*std::intrinsics::get_tydesc::<T>()).name
};
println!("{}", type_name);
}
fn main() {
let mut a = &1is;
let mut b = &2is;
print_type_of(&a);
print_type_of(&b);
}
の出力は
&'static isize
&'static isize
やなぁ。
200:デフォルトの名無しさん
15/02/07 08:13:43.05 iwrmCGgo.net
print_type_of ってデバッグでしょっちゅう使うから、標準ライブラリに入ってると良いのに
201:デフォルトの名無しさん
15/02/07 11:09:20.93 cThHTNUW.net
get_tydescでlifetimeってstatic以外も出せるの？
fn main() {
let x = &1;
print_type_of(&x); // &'static i32
{
let k = &3;
print_type_of(&k); // &'static i32
}
}
202:デフォルトの名無しさん
15/02/07 13:33:02.38 cThHTNUW.net
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
何言ってるか分からん。誰か解説してください。
203:デフォルトの名無しさん
15/02/21 07:04:27.61 Olg1CcTP.net
1.0.0 あるふぁ2 来た
We’ve managed to land almost all of the features previously expected for this cycle.
The big headline here is that all major API revisions are finished: path and IO reform have landed.
At this point, all modules shipping for 1.0 are in what we expect to be their final form, modulo minor tweaks during the alpha2 cycle. See the previous post for more details.
URLﾘﾝｸ(blog.rust-lang.org)
ってことは主な標準ライブラリのAPIも安定するってことか？
安定バージョン出たら使おうと思ってたからそろそろ本格的に勉強しよう
204:デフォルトの名無しさん
15/02/21 07:08:43.49 Olg1CcTP.net
rust 日本で人気ないのなんでだろ
hackernews とかでは話題になるのに
205:デフォルトの名無しさん
15/02/21 07:54:16.64 r4ISt4ZW.net
なってねーよ
Rustユーザーの声がでかいだけ
Githubのトレンド見ろよ
てかいつ1.0になるんだよ
コンパイルクソ遅せーよ
206:デフォルトの名無しさん
15/02/21 08:28:43.29 R5TBrCid.net
今見たらハッカーニュースで話題になっててワロタ
207:デフォルトの名無しさん
15/02/21 11:27:04.19 Fus77TES.net
日本人なんでいつも出遅れじゃん
半島人や大陸人ではないので念のためw
208:デフォルトの名無しさん
15/02/21 11:37:56.64 Fus77TES.net
RELEASES.md
Version 1.0.0-alpha.2 (February 2015)
URLﾘﾝｸ(github.com)
本題と離れたこの辺が好き→Rust is tested against a LALR grammar
209:デフォルトの名無しさん
15/02/21 18:56:18.12 NoRQyCne.net
日本はシステム寄り言語はあまり盛り上がらない印象
フレームワークでこんなんできた、とかそういうのばっか
210:デフォルトの名無しさん
15/02/21 19:05:24.66 XLU71/kI.net
そのフレームワークにも乗り遅れてるけどな
211:デフォルトの名無しさん
15/02/21 20:18:51.42 4tV2h1eL.net
今のペースだと1.0は早くても5月の半ば
GWあたりから勉強すればいいや
212:デフォルトの名無しさん
15/02/21 22:16:25.60 u58zLpzB.net
URLﾘﾝｸ(github.com)
Cross-platform Rust rewrite of the GNU coreutils
面白そうだから時々覗いてるけど、作る宣言してやりかけか音沙汰なしが多い
213:デフォルトの名無しさん
15/02/21 22:19:24.18 SweHsfSk.net
1.0が出てからが本番
214:デフォルトの名無しさん
15/02/21 22:47:20.72 24QmOmn3.net
最近Nimとの比較記事よく見る
試したことないが速いんか
215:デフォルトの名無しさん
15/02/22 05:47:39.50 XKjiDtco.net
試せよ
馬鹿なの？
216:デフォルトの名無しさん
15/02/22 08:13:00.52 NjIsBkYB.net
やだね
217:デフォルトの名無しさん
15/02/22 10:43:53.32 x4NvaSP0.net
"「Unix in Rust」の作者がRustを捨ててNimに移行"
URLﾘﾝｸ(developers.slashdot.jp)
Nimの詳しいところは見てないけど、ソースぱっと見で括弧や大文字小文字のめりはり無くて散り散りした感じは嫌だな
その点はこっちの方がいい
218:デフォルトの名無しさん
15/02/22 20:28:37.40 0ELzUNxg.net
NimはRustよりかなり前からあったでしょ。少なくともぽっと出の新人じゃない。
Nimは高速化、拡張の手段が多い(テンプレート&マクロ, コンパイル時計算, 最適化処理)にもかかわらず、
それらを作るときに変態的な見慣れぬ処理をしているようには見えない。
この、LispのマクロがPythonの文法でやれているのがおそらく一番凄いところ。
Python人口は多いから間口は広いと思うよ。Pythonと違ってまともなスコープだし。
型システムはRustの方が見通しが立っている。Nimはちょっと独特。
そして何より、Rustは低レベルもターゲットだけど、Nimはそうじゃない。
高速 -> 低レベルってのは昨今じゃ成り立ってない。
219:デフォルトの名無しさん
15/02/22 20:59:13.82 LRANqcPT.net
あっちはGC、こっちは全手動
220:デフォルトの名無しさん
15/02/22 22:12:46.57 7JvXqGjL.net
>>219
全手動って、ほぼRAIIとレファレンスカウンタで足りてるように思うけど。
別にmalloc,freeを一々手で書いてるわけではない。
221:デフォルトの名無しさん
15/02/23 00:57:37.90 AFp5DLmZ.net
NimのGCがスレッドセーフになるのと、RustにGCが搭載されるのと、どっちが先か
222:デフォルトの名無しさん
15/02/23 08:07:08.31 5h1ypUSf.net
RustはGC搭載だったのを取り除いたんじゃなかったか
223:デフォルトの名無しさん
15/02/23 19:40:30.09 eyhGdPbs.net
RustでもDでもNimでもなんでもいいよ
俺は勝ち馬に乗りたいだけだ
共倒れになるのが一番困るんだよ
224:デフォルトの名無しさん
15/02/23 21:48:25.71 hrwL6DMU.net
勝ち馬おじさんは適当なほにゃららbindingsでも作ってオポを得てください
225:デフォルトの名無しさん
15/02/24 00:16:34.89 Xk/EueOy.net
>>222
RustのあれはGCじゃなくて今で言うところのRcだったはず
GCの一種といえば一種だけど、実装は異なるから区別したい
226:デフォルトの名無しさん
15/02/24 02:31:58.07 F5ABen3P.net
参照カウンタもオブジェクトマップも両方GCで最近の参照カウンタは実行時じゃなくてコンパイル時にやるGCじゃないやつがあるんだよ。
227:デフォルトの名無しさん
15/02/27 03:23:46.29 SOolYU16.net
Boxはownership付きのポインタだ！と気付き、ヒープに限定しなくてもいいんじゃないかと思ったんだが、
move semanticsがあるので、そんなに便利にはならないことが分かった。
うまくできているなと思う。
228:デフォルトの名無しさん
15/02/28 17:38:52.88 zVTmyizc.net
RustでC++のコードを呼び出せるようにならないかな
229:デフォルトの名無しさん
15/02/28 17:40:37.54 ODdhY4Z/.net
呼べるんじゃね
230:デフォルトの名無しさん
15/03/01 14:43:26.72 GK+mth0P.net
FFIくらいあるじゃろ
231:デフォルトの名無しさん
15/03/02 19:48:54.98 jKoObBcz.net
ServoではCのラッパー関数作ってるって書いてあった
ただそれだと関数呼び出し増えた分のオーバーヘッドがあるから、
言語を跨がった最適化を検討中だとか
232:デフォルトの名無しさん
15/03/02 21:38:37.91 r8lAZceI.net
rust自身も自分用llvmを使っていて、ビルドに超時間がかかる。
Servoは自分用rustを使っているのでもっと時間がかかるので、面倒でしょうがない。
233:デフォルトの名無しさん
15/03/02 22:35:12.26 jKoObBcz.net
同じくrustcのバージョン固定してるcargoはnightlybuildのバイナリ使ってるけど、
servoはソースからコンパイルしてるの？
234:デフォルトの名無しさん
15/03/12 17:19:15.80 RfbJhqVK.net
してた。ゴ食わず嫌いだったゴメンよ
235:デフォルトの名無しさん
15/03/16 00:17:19.80 eDQflfth.net
rustは配列内包無いん？
236:デフォルトの名無しさん
15/03/20 18:24:48.01 +SAQAguo.net
今は動かない＆配列じゃなくてイテレータを返すやつだが、
URLﾘﾝｸ(github.com)
を自分で修正したらいいんじゃないかな。うまくいったら使い心地とか教えてほしい
ところで、マクロに名前空間とか欲しくない？vec!じゃなくてVec::new!みたいにできたら、
長い名前を付けないでも衝突の心配が無くなっていいと思うんだけど
237:デフォルトの名無しさん
15/04/01 20:39:05.61 cmpu1vG2.net
ちょっと見ないでいると新しい構文ができてたり、前の構文が禁止になったりと変遷がまだ激しい
関数定義にも型推論が効くようになったらありがたいんだけど、lifetimeパラメータがあるから当分は無理だろうな
238:デフォルトの名無しさん
15/04/04 10:44:07.36 3u9gfu59.net
URLﾘﾝｸ(blog.rust-lang.org)
ベータきた
239:デフォルトの名無しさん
15/04/04 17:25:52.34 tHhrzAt2.net
これで他所様のcrateがコンパイルできないって事態が減るのか。ありがたや。
240:デフォルトの名無しさん
15/04/06 02:32:19.13 h+YQESxX.net
std::fsのPathExt使いたいんだけどどうすりゃいいの？
#![feature(PathExt)]追加してけど今度はこれに対して文句言われるし
241:デフォルトの名無しさん
15/04/06 07:54:14.20 TRGNibS3.net
>>240
使ってるrustはbetaとnightlyのどっち？
unstableな機能はbetaじゃ使えないから、nightlyを使う必要がある
242:デフォルトの名無しさん
15/04/06 09:14:39.34 SQyZe7Rp.net
>>240
#![feature(path_ext)]としたら動かない？あと1.0.0-betaじゃなくてnightly buildだったらunstableがエラーにならない、はず。
243:デフォルトの名無しさん
15/04/07 17:58:26.92 sYJ921on.net
nightly buildにして#![feature(path_ext)]にしたら動きました
244:デフォルトの名無しさん
15/04/19 19:52:26.06 KK4Vp0dw.net
rust-lang.orgのトップにあるコード、あれでRustに魅力を感じることはないよね……
245:デフォルトの名無しさん
15/04/19 22:55:50.22 Pae6mGZb.net
どんなコードなら魅力を感じる？
246:デフォルトの名無しさん
15/04/20 20:41:29.82 SBrGan7W.net
パターンマッチはRustくらい低レベルな分野では珍しいから悪くはない。
だけど色くらい付けた方がいいのは確か。
247:デフォルトの名無しさん
15/04/21 12:34:26.69 DovQc0Av.net
その程度の輩を入口でフィルタアウトできてちょうどいい
248:デフォルトの名無しさん
15/04/21 20:58:23.87 8SfamI7q.net
完成度高いけど読みづらい
色々詰め込みましたって感じであまりセンスを感じないかな
249:デフォルトの名無しさん
15/04/21 21:13:43.96 t5rHangx.net
syntaxにケチつけてセンスとか言ってるのも片腹ポンポンペイン感がある
見た目はC言語ユーザーに合わせてsemanticsは全然違ようにしてあるのに
250:デフォルトの名無しさん
15/04/21 22:17:14.88 p6Hmsc0c.net
構文のC言語風な部分に文句を言ってる訳じゃなさそうだが……
251:デフォルトの名無しさん
15/04/21 22:35:19.48 wBLqiLA1.net
実際、読みづらいし書きづらいだろ。
関数型の感覚で書こうとするといたるところで引っかかる。
直和型に対するenumっていう命名のセンスも
シンタクスの話だが、無視できない筋の悪さを感じる。
252:デフォルトの名無しさん
15/04/22 00:19:44.26 G0rTsYMJ.net
Mozilla自体、将来性怪しい
253:デフォルトの名無しさん
15/04/22 01:52:28.56 8x+/Tpq3.net
GNUもそうだけどだいたいのユーザーは結局利便性>>>思想だから
その思想に属するソフトが最も良い時はその理念を支持してくれるけど
そうじゃなくなったら...ねえ
254:デフォルトの名無しさん
15/04/22 03:13:38.70 Itj79n5U.net
泥臭いレベルで考えれば直和型はenumでいいと思う。
以前は、例えばOption型のand_thenとかor_elseがクロージャを取らなかったから繋げるのが面倒だったけど、
今はそうでもないよ。
ただ、プロトタイピングとか手探りでモックアップ的なものを書きながら試すのは相変わらずしんどい。
慣れたら型エラーlifetimeエラー出さずにガリガリ書けるのかもしれんが、「誰が資源の所有者であるか」を意識し続けるのはまだ難しい
255:デフォルトの名無しさん
15/04/23 23:36:44.51 wT/D2HMU.net
javaのenumも定数クラスをフィールドと見なせば直和型だがセンス悪いですか・・・。
定義もEnum<E extends Enum<E>>だし
クラス使ったオブジェクト指向っぽくやるとそうなるんじゃないかな。
256:デフォルトの名無しさん
15/04/24 12:44:05.34 /IU9j/kd.net
enumは直和型の特殊事例として表現できるが、
逆に直和型をenumの拡張とみなしているうちは面白い使い方はできないだろ。
257:デフォルトの名無しさん
15/04/24 22:34:58.83 w/TzYGT8.net
特殊事例じゃなくて表現方法の1つじゃないの？
例えばhaskellの直和型で可能でenumじゃ無理なことって何がある？
面白い使い方って色々とサポートが必要でしょ？特にメモリ周りで。
例えばリストだったらenum List<T> { Nil, Cons(T, Box<List<T>>)}って面倒だったり、
コンストラクタを関数として扱おうとするなら部分評価時のクロージャを誰が保持するのか利用者が注意しなくちゃならない。
そういう細々としたことをGCや遅延評価で隠せない、隠さないのがいいところでもあるんだから。
オーバーヘッド無しにもっと便利にできるよ！っていうなら取り入れられるよ多分。
低レベルな分野で型推論とか自動メモリ管理とか入れようとしたらどうなるの？っていう実験やってるようなもんだし。
258:デフォルトの名無しさん
15/04/25 09:17:20.05 YZfn/g4I.net
ServoみたいなRustの大きいプロジェクトでは
ファントム型がよく使われてるが、これが普通に定着するといいな。
ただ、型はすぐ濫用されるからなあ。
Rustで型レベルプログラミングとか見たくないわ……
259:デフォルトの名無しさん
15/04/28 14:45:42.12 TsKA4yAm.net
Reenix: Implementing a Unix-Like Operating System in Rust
URLﾘﾝｸ(twitter.com)
早速OS作ってる人いたか
260:デフォルトの名無しさん
15/04/28 14:58:13.79 nSrS/3uC.net
URLﾘﾝｸ(github.com)
Rust OS勢は前から結構いるのでどの程度のものなのか謎である
261:デフォルトの名無しさん
15/04/28 16:10:37.53 TsKA4yAm.net
ほんとだ、いろいろいるわ
でもちょっとブートしてみた、とか何とかutils作ってみた系が多くて
ガチOS始めた人は少数なのか
262:デフォルトの名無しさん
15/05/05 13:51:43.12 k0XsKdeW.net
パーティ行きたいけど遠いな(´･ω･`)
URLﾘﾝｸ(www.eventbrite.com)
やっと1.0、そろそろ本気出す人多そう
263:デフォルトの名無しさん
15/05/06 06:07:02.36 mzucxP2W.net
日本でもあるよ。枠埋まっちゃったけど
URLﾘﾝｸ(rust-samurai.connpass.com)
264:デフォルトの名無しさん
15/05/06 09:17:16.43 JOkpKlyr.net
自分の使っているディストリはソースからビルドされたrust(1.0.0-beta.3)を使っているため、cargoは入っていない。
で、cargoがnightly(1.1.0系列)に追随している&他のパッケージもnightly追従になっているおかげでcargoのビルドがCargo.tomlを編集しないと通らない。
travis CIに通っているパッケージもnightly準拠。ええい、安定と言うにはまだ色々あるぞ。
265:デフォルトの名無しさん
15/05/06 10:01:59.45 cmDHtTLB.net
rust開発チームは何かと前のめりな人が多いのかな
266:デフォルトの名無しさん
15/05/06 11:33:10.40 2ABYi4qj.net
前のめりな人ってどないやねん
267:デフォルトの名無しさん
15/05/06 13:55:18.13 xpDcmA5j.net
いろいろあるけどとりあえず1.0にして酒盛りだw
直す所はまだあるとしても、仕様が固まってくれると学ぶ気になれるのでありがたい、けど
268:デフォルトの名無しさん
15/05/06 16:17:50.78 am6Qsc64.net
cargo使うにはnightly build使えって事？
269:デフォルトの名無しさん
15/05/06 22:51:00.49 JOkpKlyr.net
>>268いや、公式サイトからバイナリ落として使うなら1.0.0-beta.3にcargoが入っているので大丈夫。
自分のLinuxディストリがソースからビルドしたものを提供していたり、自前でrustをビルドしている人は自分でcargoをビルドする必要がある。
で、自分でbeta用のcargoをビルドするのが面倒だねって話。
crate.ioのgetting startedは相変わらずnightlyを推奨しているのは温度差を感じる。
Cargo.tomlにコンパイラのバージョンあるいはstdのバージョンを示すダミーcrateを登録できたらいいのか？
270:デフォルトの名無しさん
15/05/07 00:38:18.86 aZRIIXEP.net
>>264
travisはbetaチャンネルのコンパイラとcargo使うオプションあるよ。
フォーラムにやり方の投稿があったはず
271:デフォルトの名無しさん
15/05/07 13:27:05.75 23tsmTPn.net
>>263
日本人のcontributorって結構いるの？
272:デフォルトの名無しさん
15/05/07 17:33:22.03 aZRIIXEP.net
>>271
GitHubでの開発だからいわゆるcontributorとはずれちゃうんだけど、
PullRequest出してマージされてる日本人は何人か見たことある
今回の主催の人はservoリポジトリへのコミット権持ってて結構活躍している
273:デフォルトの名無しさん
15/05/07 18:24:03.66 ADm0d2/c.net
On Lisp 和訳の人の名前を見た気がする
274:デフォルトの名無しさん
15/05/11 03:01:17.51 bJJob3eC.net
BetaのドキュメントにComing Soonが多いんだが、Nightly見た方が良いの？
275:デフォルトの名無しさん
15/05/12 01:10:22.42 xKmS5U3V.net
どうせ動かないんでしょ
276:デフォルトの名無しさん
15/05/14 00:16:14.10 K0fBW8ZW.net
'The Rust Programming Language' as EBook
URLﾘﾝｸ(github.com)
277:デフォルトの名無しさん
15/05/14 06:37:57.45 HvPUnCOb.net
>>263
元日立社員が転職して後悔してさらに転職を計画
ｽﾚﾘﾝｸ(net板)
278:デフォルトの名無しさん
15/05/16 00:11:55.14 3gBP+Qn+.net
Programming Rust Paperback – November 25, 2015
URLﾘﾝｸ(www.amazon.com)
ISBN-13: 978-1491927281
ISBN-10: 1491927283
279:デフォルトの名無しさん
15/05/16 02:23:52.03 3gBP+Qn+.net
Announcing Rust 1.0
URLﾘﾝｸ(blog.rust-lang.org)
Today we are very proud to announce the 1.0 release of Rust, ...
280:デフォルトの名無しさん
15/05/16 02:43:58.46 7PFiMYNq.net
正真正銘バージョン1.0リリース! おめでとう。
281:デフォルトの名無しさん
15/05/18 01:33:56.23 sVRosqPI.net
sage
282:デフォルトの名無しさん
15/05/18 13:05:27.84 I8sSWQip.net
let mut って…
気持ちは分かるが厳密過ぎだろ…
283:デフォルトの名無しさん
15/05/18 14:22:47.25 N0SAwEsK.net
普通だと思うけど... 今までCしか使ったことないのか。
284:デフォルトの名無しさん
15/05/18 14:33:14.59 J+DllwNy.net
>>282
それならそもそもmutableな変数が無い方がいい、とな。
なるほど賛成だ。
285:デフォルトの名無しさん
15/05/18 15:22:04.80 I8sSWQip.net
>>283
普通は
const immutable = 0; または let immut immutable = 0;
let mutable = 0;
だろ
なぜ良く使う変数の方がタイプ数が多いんだよ…
286:デフォルトの名無しさん
15/05/18 15:44:06.55 N0SAwEsK.net
>>285
mutableな変数の出番が多いのはあなたの書き方の癖であって、他の全員に当てはまるわけでは無いと思う。
特にRustはifやmatch等が値を返すからmutableと相性が良いと思うけど。
287:デフォルトの名無しさん
15/05/18 15:45:07.29 N0SAwEsK.net
>>286
修正: immutableと相性が良い
288:デフォルトの名無しさん
15/05/18 16:26:46.46 J+DllwNy.net
>>285
>なぜ良く使う変数の方がタイプ数が多いんだよ…
immutableな変数の方をよく使わないのだとしたら、
そもそもRustでのプログラミングには向いてないな。
基本的には破壊的更新をしない関数型スタイルで書かせて、
それをコンパイラが巧く処理してゼロコストにする、
というのがRustの設計思想なんで。
いい機会だから、変数の再代入を一切使わずにコード書いてみるといい。
289:デフォルトの名無しさん
15/05/18 17:11:40.54 hULj5jYE.net
つまりC++でconst書きまくるのに疲れてる俺向きということですな!
290:デフォルトの名無しさん
15/05/18 22:19:14.44 eEjXu/P7.net
関数型言語を触ってみるとリフレッシュできるよ。OCamlが緩くてお勧め。
RustはセルフコンパイルできるまでOCamlで開発されてた位にはメジャーで実用的。
パターンマッチや型推論、その他色々なRustの機能は関数型言語由来のものがあるから触ってみて損は無い。
「低レベルな領域に関数型言語の便利なエッセンスを(ゼロコストで)どれだけ入れられるか、入れたらどれだけ楽になるか」
みたいな発送がRustから感じられる。
もっとMLライクな文法でも良かったと思うけどね。
291:デフォルトの名無しさん
15/05/18 23:34:48.44 J+DllwNy.net
>>290
>もっとMLライクな文法でも良かったと思うけどね。
せめて型宣言はムリにC系のものにして関数定義の頭に押し込めずに
別立てにしたほうが良かったと思うんだよなあ。
とはいえ、確かにML系つうかOCamlの匂いは強くするよね。
292:デフォルトの名無しさん
15/05/19 15:09:00.81 UYmTOlX3.net
>>285
まあそのまま仕様を受け取って、immutな方を自然に使って欲しいんだろう。
命令型言語に関数型の風味を取り込んでみたってことで。
ocamlの方は逆な風味だが命令型取り込んだ無理やり感がする。
rustも一実験言語で終わるのか、伸びるのか
293:デフォルトの名無しさん
15/05/19 21:19:02.97 AGcxeKzS.net
前はマニアのための実験的言語って書いてあったのに今では1.0だなんて感動する
294:デフォルトの名無しさん
15/05/21 00:03:14.73 R841WaTJ.net
今更セミコロンがある謎言語
295:デフォルトの名無しさん
15/05/21 02:10:17.69 gi6AaWSD.net
val foo : i32 -> i32とかできると便利よな。前方宣言は一応できるけどCスタイルだから冗長だし、
定義時に同じこと書かないといけないから面倒。
まあ、ML寄りの文法で変数の宣言とか並べるのも汚いかもしれんし、
関数型に近寄るとその分デバッグが難しくなる。誰かがML系rustを作ったら今の文法の良さが見えてくるかもね。
296:デフォルトの名無しさん
15/05/21 11:04:47.93 HQdruXcL.net
正式版でたんで久々に入れてみたら
単純計算ものでも2倍くらい速くなってるな
node.jsと同じくらいにはなった
297:デフォルトの名無しさん
15/05/29 01:21:31.51 CYHwmvYd.net
The evolution of Rust
URLﾘﾝｸ(lambda-the-ultimate.org)
298:デフォルトの名無しさん
15/05/30 07:05:58.43 AYzItcLB.net
>>296
単純計算だけならC++と同じぐらいだろ
所詮LLVMのフロントエンドなんだし
299:デフォルトの名無しさん
15/05/30 10:56:09.40 qPmgq1NQ.net
言語はけっこう好みだけど仕事はC++だし
趣味用にはもうひと押し欲しい気がする
300:デフォルトの名無しさん
15/05/31 07:07:23.95 QzJY7rQQ.net
Rust って let (a,b) = (1,2); は出来ても、
let a = 1, b = 2;
は出来ないのか。
何故？ 別に何かの文法と衝突でもするのか？
301:デフォルトの名無しさん
15/05/31 09:03:35.54 chRy4RzH.net
>>300
let mut a =1, b=2;
としたときにbがmutableになるのかならないのか曖昧に見えるから、という理由だった記憶がある
とにかく、なにかしら理由があったはずだよ
302:デフォルトの名無しさん
15/05/31 09:58:57.84 QzJY7rQQ.net
なるほど。でも、なら let mut を var にして欲しいな。
mutable 変数は var で宣言する方が好みだ。
でググったら当然過去に let mut <-> var 議論あった。
ざっと読んだら、Rust の精神には immutable が根本にあって、
mut は気安く使うんじゃねーよ、的な障壁としての let mut みたいだ。
確かに var だと気安く使っちゃうからね。ってこれスレのすぐ上で話題になってた話だな……
303:デフォルトの名無しさん
15/06/11 07:46:19.89 JhAQPJZl.net
mutable参照を共有できないって厳しすぎないか？
警告ならわかるがエラーは勘弁してほしい
304:デフォルトの名無しさん
15/06/11 09:39:17.92 tuFYxFU/.net
Rc<RefCell<T>>やArc<Mutex<T>>をどうぞ
305:デフォルトの名無しさん
15/06/11 18:40:49.25 JhAQPJZl.net
>>304
なるほどRefCellを使えばある程度は解決しそう
ちょっと強引かもしれないけどこんな使い方も出来た
// これはエラー（配列やスライスは同時に1つの要素しかmutable参照が作れない）
let mut array = [ 0, 1 ];
std::mem::swap(&mut array[0], &mut array[1]);
// これならOK
let array = [ std::cell::RefCell::new(0), std::cell::RefCell::new(1) ];
std::mem::swap(&mut *array[0].borrow_mut(), &mut *array[1].borrow_mut());
306:デフォルトの名無しさん
15/06/11 19:42:13.90 rjZb8+Jq.net
記述めんどいやろmut使うなという強烈なメッセージを感じるｗ
307:デフォルトの名無しさん
15/06/13 11:23:17.39 /rtQk4xD.net
>>305
試してないけど
let array = Rc::new(RefCell::new([0, 1]));
じゃだめかな？こっちのほうがまだましかなと思うんだけど
308:デフォルトの名無しさん
15/06/13 22:39:23.60 kJh3Un39.net
>>307
RefCellを使えば所有権を動的に貸し借りできるようになるってだけで
mutable参照は同時に1つまでというルールは変わってない（2つめを取得しようとしたらpanic）
>>305は配列の要素の所有権を取ると配列全体の所有権まで取ってしまうのが
要素毎にRefCellを使えば要素毎に所有権を取れるという話
それとRcは寿命を動的管理するためのものであって所有権とは無関係
ちなみにstd::mem::swapは引数が&mutだけどstd::ptr::swapなら*mutだから所有権を取らない
結局unsafe使うのがベスト
let mut array = [0, 1];
unsafe { std::ptr::swap(&mut array[0], &mut array[1]); }
309:デフォルトの名無しさん
15/06/19 11:24:27.05 7YWFihrY.net
WebAssembly対応すればブラウザゲーをRustで作れるようになるんかな
310:デフォルトの名無しさん
15/06/26 05:16:57.34 MTQE4YuR.net
borrow checkerや型チェックで弾かれるのはまだいいんだけど、unsized typeで怒られるのが面倒。
AsRefとかDeRefとか、traitを多用し過ぎじゃないのか。traitに関する構文(多相型関数の定義とか)も冗長に思ってしまう。
311:デフォルトの名無しさん
15/06/26 22:05:32.88 4tQavpY6.net
久しぶりに見たら1.1になってた
URLﾘﾝｸ(github.com)
312:デフォルトの名無しさん
15/06/27 01:28:47.33 F+n2jvy1.net
rebuld.fm聞いて、rust触ってみたくて来ました。
今から手を出す場合、どこを見るところから始めればいいです？
313:デフォルトの名無しさん
15/06/27 02:07:48.13 fUkToYrK.net
>>312
Rust by Exampleとか？
URLﾘﾝｸ(rustbyexample.com)
314:デフォルトの名無しさん
15/06/27 05:34:06.57 F+n2jvy1.net
>>313
おお、良さ気です。ありがとうございす。
URLﾘﾝｸ(www.youtube.com)
をみてたら、すごく、関数型言語ぽくていいっすね～
俄然やる気でます。
315:デフォルトの名無しさん
15/06/27 10:51:13.60 nreZwDj/.net
実際に書いてみると全然関数型言語っぽくないのだよなあ。
あと、なんかイディオマティクな標準的コーディングスタイルが
確立されないと辛いと思う。
316:デフォルトの名無しさん
15/06/27 15:58:00.61 rIdxbF5x.net
C++テンプレート以来のコンパイラに怒られまくる言語だ
317:デフォルトの名無しさん
15/06/27 16:26:20.28 wfeMnVHy.net
URLﾘﾝｸ(github.com)
これがなぜだか分からん。
fn main() {
let a: &mut i32 = &mut 0;
{ let b = a; }
let c = a;
}
上が駄目で、下がおｋな理由。
fn main() {
let a: &mut i32 = &mut 0;
{ let b: &mut i32 = a; }
let c = a;
}
318:デフォルトの名無しさん
15/06/27 17:22:32.78 99+F8Q1T.net
>>317
下の例はこれと同じになるらしい
fn main() {
let a: &mut i32 = &mut 0;
{ let b = &mut *a; }
let c = a;
}
Rustには型推論と暗黙の変換があるせいで分かりづらいね
319:デフォルトの名無しさん
15/06/27 17:34:52.26 wfeMnVHy.net
上では move されるのに、下では borrow されるのか。
#![feature(core_intrinsics)]
fn print_type_of<T>(_: &T) -> () {
let type_name =
unsafe {
std::intrinsics::type_name::<T>()
};
println!("{}", type_name);
}
これを入れて型を表示すると、上でも下でも b の型は同じ
&'static mut i32 なのに、型注釈するだけで挙動が変わるのは違和感あるなあ。
320:デフォルトの名無しさん
15/06/27 17:35:27.20 wfeMnVHy.net
>>318
ありがとう。うーむ悩ましい。
321:デフォルトの名無しさん
15/06/27 18:38:39.26 SbfB1Jvt.net
>>310
unsized typeで起こられるのってどんな場合？
322:デフォルトの名無しさん
15/06/27 18:40:12.36 SbfB1Jvt.net
>>320
既出じゃなさそうならissue立ててみたら？
323:デフォルトの名無しさん
15/06/27 20:45:16.24 j6fAeiVj.net
>>321 いや、超基本的なミスなんだけど、 fn foo(it: Iterator<Item=i32>) { ... } とかすると怒られるの。
traitを引数にするなら、 fn foo<T: Iterator<Item=i32>> (it: T) { ... } みたいにしないといけない。
解決法は知ってるつもりなんだが、Sizedを実装していないからダメよ、と怒られるのは何故なのか未だに理解はしていない。
324:デフォルトの名無しさん
15/06/27 23:20:55.81 SbfB1Jvt.net
>>323
Trait型は実際にはそのTraitを実装した何かしらの型が実体になるんだけど、
関数引数とかローカル変数としてスタック上に配置するためには型自体のサイズがコンパイル時に分かってる必要があるから、
Trait型はポインタを経由するなどしないといけない
T: Traitとかすると、Tで指定された型それぞれに応じて特殊化された関数が生成されるからコンパイル時に型が特定できてサイズもわかるから問題にならない
325:デフォルトの名無しさん
15/06/28 03:45:02.95 sui11WPz.net
やっぱりスタック上に配置が理由なのね。でもそれって人が配慮する必要があるのか？という部分に不満が残る。
コンパイラが自動的に多相型の関数とみなしたら不都合があるのかな。
326:デフォルトの名無しさん
15/06/28 10:13:01.42 6byfIPXR.net
foo: Traitを<T: Trait> fooのシンタックスシュガーとみなすのはありかもしれないけど、
スマートポインタ型なんかを定義する時とか本当にunsizedな型が必要なケースに困ってしまいそうな気がする。
自動で&Traitなどに変換してしまうのは、ヒープへのメモリ確保とか仮想関数呼び出しが必要で
ゼロオーバーヘッドの原則に反してしまうからrustではやらないと思う。
327:デフォルトの名無しさん
15/06/28 17:45:54.19 l0DVu4po.net
?Sizedが必要な場合もあるし面倒だよね
328:デフォルトの名無しさん
15/06/28 19:16:48.49 l0DVu4po.net
トレイトは別のトレイトを継承できるけど
継承しててもトレイトからトレイトにはアップキャスト出来ないっぽい
これじゃあオブジェクト指向のような多態性を活かした設計は難しいね
329:デフォルトの名無しさん
15/06/29 09:33:30.50 8+Jbzv8W.net
単なる型クラスになに要求してんのかと。
Rustがオブジェクト指向でないのは結構なことだ。
330:デフォルトの名無しさん
15/06/29 17:09:32.97 9FsJz544.net
trait FooExt : Foo { .. } ってのは、単にFooExtを実装する型はFooも実装しなければならない、という意味しかない。
FooトレイトをimplするだけでFooExtトレイトも使えるようにしたい、という目的なら、
impl<F: Foo> FooExt for F { ... } とすると良い。
struct STFoo;
impl Foo for STFoo { ... }
とかすると、STFooはFooExtのメソッドも呼び出せる。
FooとFooExtに同じ名前のメソッドdo_foo(&self)があったときは、呼び出し側でFoo::do_foo(&foo)とかしないといけない。
OOPでアップキャストが必要な場面ってあったっけ？
331:デフォルトの名無しさん
15/06/30 22:00:52.85 5IIg4rdj.net
暗黙のアップキャストてOOPの基本の一つじゃね？
332:デフォルトの名無しさん
15/06/30 22:32:05.66 uCmnNLIn.net
どの言語のOOPかにもよるのでは。知らんけど。
333:デフォルトの名無しさん
15/06/30 22:34:50.83 OotDes5f.net
Rustって強力なトレイトという名の型クラスを導入することでOOP(のRustにとって必要な部分)が(綺麗に)できるというだけで、別にOOPするための言語では無いと思う。
ちなみにアップキャストってこれじゃいかんの?
URLﾘﾝｸ(stackoverflow.com)
334:デフォルトの名無しさん
15/07/01 01:38:30.43 Co4dDuJ+.net
インターフェースを拡張した場合において、拡張元のインターフェースにアップキャストできるかどうかは、OOPL次第。
同一のメソッド名であれば実装を一本にまとめてしまうJavaはできるが、
同一のメソッド名だが異なるインターフェースで異なる実装をもてるDelphiはアップキャストできない。
C#はどうだったかな？
後者だった気がする。
335:デフォルトの名無しさん
15/07/01 01:51:50.96 paBhA78F.net
アップキャストできない場合て、多態できなくね？
多態出来ないと、OOPの1/3位の価値が失われる気がするんだが…
ま、別にrustにOOPを求めてはいないんだけどね。
336:デフォルトの名無しさん
15/07/01 05:52:25.11 /48a4Fba.net
>>334
DelphiもC#もできるぞ……なんか勘違いしてそう
337:デフォルトの名無しさん
15/07/01 06:53:23.75 va2KIQhQ.net
>>335
Derived→Baseというtrait間のキャストができないだけで、
traitを実装した型を&Baseへキャストすることはできるけど、
それだけではたりない？
338:デフォルトの名無しさん
15/07/04 23:29:18.24 Swd5RGwS.net
Documentation↓読んでみたけど使い方まるで分からなかった orz
URLﾘﾝｸ(doc.rust-lang.org)
どこか分かりやすいサイトあったら教えて
339:デフォルトの名無しさん
15/07/04 23:41:44.31 JArIChSh.net
rustbyexample
340:デフォルトの名無しさん
15/07/05 00:58:16.90 D54Ug4Aq.net
>>338
実際に rustdoc を使ってみれば慣れるだろ
341:デフォルトの名無しさん
15/07/07 12:17:44.59 6KFd5cV4.net
implでトレイトに対して実装すると範囲が広くて使い勝手が悪くなるのを知った。
impl<T> TraitFoo for T where T: TraitBar { ... }
ってやった後、
impl<T> TraitFoo for T where T: TraitBaz { ... }
と別のトレイトも実装しようとすると
conflicting implementations for trait `TraitFoo`
と怒られる。TraitBarとTraitBazが全く関係が無いもの(例えばstd::net::ToSocketAddrsとstd::ops::Add)であっても駄目。
今、TraitBarとTraitBaz両方を実装した型が無くても、この先作られるかもしれないから、という理屈？らしい。
じゃあ impl TraitFoo for TraitBar {...} とすると、コンパイルは通るけどTraitBarを実装した型はTraitFooを実装したことにならないので、
意味が無い。
342:デフォルトの名無しさん
15/07/07 22:52:02.79 cXg5joXk.net
Neative boundsが実装されるのを待とう
343:デフォルトの名無しさん
15/07/09 07:18:05.44 3KxMUrWp.net
RustのTraitは正直失敗だよ
本来のトレイトとは別物だしインターフェースや型クラスとも違う
中途半端な出来損ない
344:デフォルトの名無しさん
15/07/14 00:55:02.57 vqJ6PXtp.net
scalaのtrait implicit classを関係があるんかな
345:デフォルトの名無しさん
15/07/14 20:39:40.07 s1SvBZBN.net
本来のトレイトって何？何がRustのトレイトに足りないの？
346:デフォルトの名無しさん
15/07/15 16:36:48.46 Kkrt7iJt.net
本来のトレイトは実装を再利用するための機能であって
使うトレイトの組み合わせを変えるなどして実装を変えられるものだ
普通はトレイトに型システムの機能は無く
トレイト型にキャストとか出来ないし
どのトレイトを使っているのかで区別もしない
ましてトレイトの関数を再実装できるようにしてトレイト型に多態性を持たせるとか
名前が衝突してもトレイト型にキャストすれば別々の実装が呼べるとかすべきでなかった
おかげで本来の使い方が出来なくなった
347:デフォルトの名無しさん
15/07/15 17:45:25.68 4s1838+j.net
いやだからRustでできない本来の使い方って何さ。他の言語でもいいから例をプリーズ。
Rustでも実装の再利用ってできるでしょ。Iteratorをimplするのに最低限必要なのはnextだけでいい。Readだったらreadだけ。
implする型に制限は無い。基本型にすらtraitを与えることができる。
オレオレ実装を使いたいならstruct Myi32(i32)とかすればいい。
traitは関数のみ定義できて値を持たせることはできないけど、これはimplする型全てが構造体のような形態を持っていないため。抜け道は普通にある。
traitは型ではない、型であるべきではない、という主張も正直分からない。
traitを実装したものは全て特定の関数を持っているんだから、それをまとめて型Xとするとどこに不都合があるのか。
348:デフォルトの名無しさん
15/07/15 23:54:13.14 Kkrt7iJt.net
極端な例になるけどこれを見て欲しい
trait FooA {
fn foo(&self) { self.bar1(); self.bar2(); }
}
trait FooB {
fn foo(&self) { self.bar2(); self.bar1(); }
}
trait BarA {
fn bar1(&self) { println!("A-1"); }
fn bar2(&self) { println!("A-2"); }
}
trait BarB {
fn bar1(&self) { println!("B-1"); }
fn bar2(&self) { println!("B-2"); }
}
一般的なトレイトだとFooAとFooBのどちらかとBarAとBarBのどちらかを組み合わせることができる
それがトレイトの再利用
この場合トレイト型で区別しても意味が無い
349:デフォルトの名無しさん
15/07/16 01:05:53.97 AYGKegct.net
はぁ？
350:デフォルトの名無しさん
15/07/16 03:44:30.67 xr+gKr/s.net
その一般的なトレイトだと、FooAかFooBをミックスインした対象はbar1とbar2を呼び出せないといけないんだよね？
OCamlの書き方でやると < bar1 : (); bar2: () > というシグネチャを持っている型しかFooA/FooBをミックスインすることはできないわけだ。
その型に、例えばBarと名づけて型チェッカで検査させて都合がでるとは思えない。実際に問題は起きていない。
URLﾘﾝｸ(codeshare.io)
↑で一々implの羅列を書くのが面倒だという声に応えて>>341のようなimpl<F> Foo for F where FooA { ... }があって、
けどこれはまだ使い勝手が悪いからnegative boundがRFCに上がっている。
それも待ちきれないならnightlyのlibsyntax、あるいはsyntexを使って自動化することもできる(はず)。
他の言語だと、traitは型じゃないの？FooA+BarAをミックスインした型とFooB+BarAをミックスインした型は多相リストに入れたら駄目だったりするの？
351:デフォルトの名無しさん
15/07/16 23:56:38.15 P5KxMz2p.net
一応トレイトの論文(Composable Units of Behaviour)があって
それを本来のトレイトと呼んでるんだけど本来のトレイトは型じゃないってのは事実
PHPのトレイトが型としての機能が無くて本来のトレイトに近い
Scalaのトレイトは型として扱うことで継承構造も再利用できるようになってるけど
Rustと違ってそれで本来の使い方が出来なくなったりはしてない
それと読み返してて思ったんだけどもしかしたら誤解させたかもしれない
今のRustでトレイトの型としての機能を無くすならトレイトの代わりになる別の抽象型が必要になる
PHPもトレイトの他にインターフェースがある
それにトレイトが型なのが問題というよりも型として強力にするために多態性を持たせたり
名前が衝突しても解決しなくていい仕様にしたのが一番の問題
そこで本来のトレイトと使い方が大きく変わってしまった
352:デフォルトの名無しさん
15/07/17 00:25:13.89 GZRy2HRh.net
論文のタイトル正確にはTraits: Composable Units of Behaviourだった
353:デフォルトの名無しさん
15/07/17 13:44:39.09 vkp5Zmx6.net
型とクラスを混同しているようだけど、型とクラスは違う。その論文のどこにもトレイトは型じゃないと言ってない。むしろ型以外の何者でもない。
クラスベースのOOPLは型≒クラスだけど、rustにはクラスもその階層構造も無い。
その論文で言及している、inheritance由来のデメリットはrustには存在しない。
よってトレイトがクラスベースの言語で解決してくれるような問題はrustには無く、論文の定義通りのはたらき、
すなわち「requiredなメソッドを用意したらあるメソッドをprovideする」を行っている。
「本来の使い方」という曖昧な言い方はやめてくれ。
useで明示的に指定したメソッドしか使えないのは論文の定義(トレイトをミックスインした場合と、しないで同名のメソッドを定義したものは同等であるべき)とは違うように見えるが、
クラスが無いんだからあまり変わらない。むしろあるメソッドがどこから提供されているのかを曖昧にしないのは利点ですらある。
トレイトに関する多相性というと、トレイトをミックスインした型全てを扱える仕組み(fn do_foo<T:>(f: &T) where T: TFoo {...})と、
多相トレイトを定義できる仕組み(trait TFoo<V> { ... })の2つがあるが、後者があるのがどう問題になるのか？
多相トレイトを使う時、すなわちミックスイン時には単相化されるか、多相型のパラメータに渡されるだけなんじゃないの？
そして多相トレイトをやめた場合、例えばIterator<Item=T>というものはどう実現すればいいのか。
354:デフォルトの名無しさん
15/07/17 14:25:23.54 Zvxj9F2y.net
結論：オブ脳の恐怖
355:デフォルトの名無しさん
15/07/18 21:30:37.89 FAOQ/v/X.net
まあrustのトレイトはその言葉の意味「特性」をそのまま持ち込んでいるから、シグネチャ以外の特徴の表現にも使われている。
SizedとかSyncとか。
この過剰な応用がどんなデメリットになるかはもう少し様子を見てみる必要があるとは思う。
今も初見じゃ分かりづらいエラーメッセージの元になっている。Sizedトレイトが実装されてないから駄目ってどういうこと？とか。
356:デフォルトの名無しさん
15/07/18 22:39:00.92 vVMIYXNu.net
あの論文を読んでどうやったらトレイトを型と見なせるのか俺にはわからん
型＝クラスと思ってるわけじゃないけど型という用語の認識が違うのは確かだろうね
君はRubyのモジュールも型とみなすのかな俺は違うと思ってる
正直認識が違いすぎてどう説明していいのか分からん
他言語のトレイトを使って確かめてくれとしか言いようがない
357:デフォルトの名無しさん
15/07/19 02:51:08.17 0GQY2ef7.net
論文に書いてあるのは「トレイトはクラスではなく、クラスを構成する部品である」ということなのはいいか？
「トレイトは型じゃない」とは一言も書いてないし、それ以前に型という単語すら使ってない。言及していない。
だから型じゃないと主張するなら、自分でその根拠を述べる必要があるのは分かってるか？
クラスの無い静的型付け言語のrustでのトレイトは、
1. 階層構造が無い、あるメソッドを定義すればそれに基づいたメソッドをstruct, enum, primitiveに与えるもので、
2. (Struct | Enum | Primitive) = State + Traits + Glueを満たすんだから、
論文にあるトレイトとほぼ同義。linear compositionができるんだから使い方も間違っちゃいない。
動的型付けでは曖昧にしていた所をはっきりさせれば、多相トレイトが自然であることも分かるだろ？
話を曖昧にしたがるあなたに付き合う必要は無いけれど、ついでに適当に書くよ。
Rubyのモジュールをミックスインしたクラスから生成されるオブジェクト全てを扱えるメソッドが書けるなら、モジュールは型とみなせる。
例えばFooモジュールを作るだろ？
module Foo
def bar
return "bar"
end
def baz(x, y)
return x + y
end
end
で、こいつをミックスインしたクラスのインスタンスを、例えばdef do_something(f) return (f.bar , f.baz(1,2)) endに渡せるんだろ？
ならインスタンスはパラメトリック多相なFoo型を単相化したもの、と呼べるだろ。
Foo型とはメソッドbar : () -> stringとbaz : int -> int -> intを持つもの全て、だ。
動的型言語の関数に対して、静的型言語の型注釈を無理なく与えようとしたら、
殆どの関数は多相型になり、多相性を制限するもの(haskellの型クラス, OCamlのモジュール+ファンクタ, rustのトレイト, Javaのアドホック多相かジェネリクス)が必要になる。
358:デフォルトの名無しさん
15/07/19 18:51:02.73 pLL2VJtZ.net
なるほど要するに
trait Foo {
fn bar(&self) {}
}
となってるときにselfの型はFooだからトレイトは型である必要があると言いたいわけだ
普通のトレイトはクラスにミックスインした時にコピーされるから
その時selfの型が決まるけどそうやって曖昧にすることを許さないと
でもその考え方はやっぱりトレイトと違う
一応論文のURLを貼っておくけど
URLﾘﾝｸ(www.ptidej.net)
8ページの図にあるTCircleとTDrawingがトレイト
白丸が提供するメソッドで右矢印が必要とするメソッド
9ページの図がトレイトのミックスイン
これがRustのトレイトと同じに見えるらしいけど
俺にはむしろ5ページの図にある多重継承の例がRustのトレイトだと思ってる
そこに多重継承の問題が書いてあって実装が重複すると書かれているけど
それを>>341で解決を試みているように見える
この流れだと多重継承もトレイトだとか言われそうだけど
そうなったらもう何も言えない
359:デフォルトの名無しさん
15/07/20 21:03:10.22 oqUyaDhZ.net
だーかーらー「思ってる」だけじゃなくて根拠を書いてくれ。どうしてrustのトレイトが多重継承と同じになるんだ？
例えば多重継承によって発生するdiamond problemをrustのトレイトを使って書いてくれ。
>>341で愚痴ったのは自分だが、あるトレイトTFooBarをimplすれば、自動的に他のトレイトTFooもimplしたことにしたい、という横着な欲求を実現しようとして、
(実現できたらtraitを使ってOOPのクラス継承を簡単に作れる)
impl<T> TFoo for T: TFooBar {...} と書いたら、自分の予想外の事態(TFooBazも同様にしたら、TFooBarとTFooBazの両方をimplした型はどうなる？)
をコンパイラが検出してエラーを出しただけの話だ。
普通に実装を羅列すれば問題ない。デフォルト実装を書けばimplにコードを書く必要もない。型SFooに対し、impl TFoo for SFoo {}と impl TFooBar for SFoo {} と書けばいいだけ。
多重継承の問題じゃない。implを多相にしたら範囲が広すぎて怒られただけの話。
rustのトレイトは、論文の通りで、継承はあるけどそれで階層構造を作るわけじゃない。
trait FooBar : Fooと書いたら、Fooの要求するメソッドをFooBarも要求する、Fooの提供するメソッドをFooBarも提供する、だけ。
impl FooBar for SFoo {...}でFooから受け継いだrequiredメソッドを書けないじゃないかと思うかもしれんが、
静的型付けの言語でFooBarとFooの関係を完全に切り離すのは利便性を下げるだけなのは分かるよな？
impl Foo for SFoo {...}と書くだけでSFooはFoo型としてもFooBar型としても扱えるようになるんだから。
360:デフォルトの名無しさん
15/07/20 21:06:59.38 XuKvM2I+.net
トレイトは多相性の制限という形で不変条件を表現してるものなんだから
>>357が正しいとしか思えんけどなあ。
361:デフォルトの名無しさん
15/07/21 21:00:10.36 Nw2FJ/oz.net
論文の5ページの図は菱形継承とは関係無い
むしろ親クラスと子クラスの2階層でも問題があることを示してる
具体的には親クラス同士の連携のために親クラスに連携用のメソッドを追加する必要があること
その連携用のメソッドを子クラスで実装しなければならないことが書かれている
Rustが名前の衝突を許すせいで分かりづらいけど名前の衝突を避ければ>>348は
trait FooA {
fn foo(&self) { self.FooA_bar1(); self.FooA_bar2(); }
fn FooA_bar1(&self);
fn FooA_bar2(&self);
}
となってミックスインする時にFooA_bar1を呼んだらbar1を呼ぶように実装することになる
名前を同じにしようがtrait FooA: Barにしようが実装の数は変わらない
そしてこの連携のための実装は再利用が出来ない
>>350でこの問題の解決方法として>>341を挙げてるからそれを指摘した
別に>>341のエラーを多重継承のせいにしたつもりはない
確かに論文ではトレイト間の階層構造に意味が無いことは書かれていたけど
同時にトレイトはクラスの階層構造に影響しないとも書いてあったはず
クラスとトレイト間では階層構造を作るという解釈はどこから来た？
ここで2階層になってるからさっきの多重継承の問題が出てきた
362:デフォルトの名無しさん
15/07/21 23:59:09.59 BEOiskjZ.net
あなた「Rustのトレイトはクソ！本来の使い方ができない！」 >>343
ぼく「どうクソなの？本来の使い方って？」 >>345
あなた「トレイトは実装の再利用をするための部品。トレイトを型として扱ってるからクソ！多相性があるからクソ！」 >>346
ぼく「再利用できるじゃん。例もあるでしょ」 >>347
あなた「例えばこんなコードでトレイトを組み合わせることができない！」 >>348
ぼく「できたよ」 >>350
あなた「論文の定義と違うからクソ！トレイトがクラスになっているRustはクソ！」 >>351
ぼく「そもそもrustにクラス無いじゃん。クラスと型は違う」 >>353
あなた「じゃあお前はrubyのモジュールも型と言うんだな！話にならん！」 >>356
ぼく「rubyよく知らないけど型と呼べそうだよ。そもそも元の論文でtraitと型の関係は何も書いてないじゃん」 >>357
あなた「rustのトレイトは論文5pの図で言うところの多重継承だ！クソ！」 >>358
ぼく「多重継承じゃないでしょ。フラットになってるでしょ。Rustのトレイトが多重継承ならdiamond problemを書いてみてよ」 >>359
あなた「5pは菱型問題じゃない！お前分かってない！親子だけの2階層だけでも問題！」 >>361
363:デフォルトの名無しさん
15/07/22 00:06:40.09 pdX/k3oq.net
あなたが書かなければならないのは、>>343で吠えたようにrustのトレイトが実装の再利用において、
本来のトレイトが解決してくれることができないこと、なんだけど1つも例を挙げてないよね。
>>348で折角「極端な例」を出してくれたが、それが>>350でrustでも書けることを示したんだが。
で、クラスと型を混同している頭ではトレイトが型なのが許せないようで、論文という他人の言葉だけを頼りにグダグダやっているけど、
第一級市民としてのクラスが無い、多相型のあるrustで、という文脈をずーっと無視しているよね。
論文は動的型付けの、継承がコードの再利用方法としてメジャーな言語の中での話、っていう文脈も無視しているよね。
トレイトは型ではいけない理由も、rustのトレイトが多重継承だと思った理由も、何にも説明してくれないからこっちで補完して反論してきたが、
もうお節介はやめるよ。ちゃんと自分の頭で考えなさい。
364:デフォルトの名無しさん
15/07/22 13:50:02.41 tlwxTsYf.net
>>362
何を長々と、、、と思ってたらまとめが出来ていて分かった、乙
関数型の議論と同じく実用はおいといてセンシティブな定義で気に入らないのかな
定義に敏感な人は大変だなぁ
365:デフォルトの名無しさん
15/07/22 21:55:10.25 ubJIybN+.net
論文ではまず実装の再利用に関して既存のやり方には問題があることを示した上で
その問題を解決するためにトレイトを提案してる
その問題の1つが>>350のimplで理由は>>361に書いた
結局トレイトで否定したやり方をRustはトレイトと呼んでるわけだ
Rustの文脈を無視してるというのならトレイトの目的や背景も考慮したらどうだ
トレイトが型ではいけないってのは結局俺の間違いだった
型の機能を優先しすぎてトレイトの機能を無くすのが問題だっただけで
トレイトの機能と型の機能は両立できそう
366:デフォルトの名無しさん
15/07/22 23:45:21.91 pdX/k3oq.net
>論文ではまず実装の再利用に関して既存のやり方には問題があることを示した上で
>その問題を解決するためにトレイトを提案してる
だからその問題を具体的に、自分の言葉で説明しろよ。>>350を書いたのは俺だ。
そこにかかれているのはimpl TFoo for SFoo {}をひたすら書くのが面倒だね、ってことだけだ。勝手な誤読をすんな。
これが論文で言うcode duplicationだと思っているなら、あなたは論文を読む以前の知識が足りない。
しかも>>361で性懲りもなく親クラスなんて言葉をrustに持ち込んで妄言を吐いてるだけ。rustの何が親クラスなんだ？
トレイトの背景と目的？だから継承ベースのコードの再利用にある問題を解決するには、って分かってるから>>353で
「そんな問題はrustには無いんで、論文の言葉どおりにトレイトを定義した」と書いている。
で、親クラスって何よ？>>350のどこにも親クラスなんて存在しない。
367:デフォルトの名無しさん
15/07/23 21:35:53.52 XXd04llZ.net
Rustのトレイトを親クラス、構造体を子クラスと見なせば論文の例はこうなる
URLﾘﾝｸ(play.rust-lang.org)
SyncAとSyncBのimplがほとんど同じでA::やB::の代わりにsuperが使えれば完全に重複
論文ではこの重複も問題として扱っている
368:デフォルトの名無しさん
15/07/23 22:25:53.21 bNJIoU7G.net
それでみなさんはrustで何作ってるんですか？