プログラミング言語 Rust

Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。

http://www.rust-lang.org/

もうJavaの亜種はおなかいっぱい

なんでこんなネガティブな名前なの

次世代Mozillaというキラーアプリを書くための言語ってことで
相当期待していいんじゃないの。

これ、BLISSと同じ式言語なのな。

チュートリアルぱっと眺めてみたけどmodとかifaceとか予約語のセンスの
悪い省略っぷりだけで流行らない臭いがプンプンした。
今時IDEで入力するからそんな中途半端な省略いらんだろ。

>>6
fnとかダセェｗ

Fnキーかと思った

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

予約語があえて一般名とかぶらないようにする利点のひとつに
変数名などに一般名を利用した時にかぶらない、というのがある。

キーワードとかは最初取っ付きにくいかもするけど、なかなか良さげな感じ。

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秒も関わりたくない。

名前省略自体は個人的にはぜんぜんオッケーなのだけど
functionならfnかfunがよかったな。それはさておき

std::io::println("one or two");

IPv6アドレスみたいでステキ

::の多用はダサい。

>>12
>いまどきfu[Enter]でfunctionが出るIDEもあるのにな。fmtも蹴り飛ばしたくなる。
入力が楽になることよりも、見た目が見やすくなることのほうが大事だろ。
「function」なんて自己主張が強すぎる。「fn」や「def」ぐらい短い方が控えめで見やすい。
callback(x, y, function() { ... } ) // JS
より
callback(x, y) { ... } # Ruby
のほうがだんぜん読みやすいしな。

変数名をよく短い形で書くから嫌だな

defは良いがfnはねえよ

昔のLispの本を見ると時々たまに見かける

fnなんて中途半端はやめてfにしろよ

これってネイティブコンパイラ？

ぶっちゃけ昔のBASICみたいで私は好きよ

マルチコア、メニーコア時代
これは、ひょっとするかも知れないね

見た目の話ばっかりじゃねぇか

Goの勢いが異常だったのか

go
http://pc12.2ch.net/test/read.cgi/tech/1257920595/
>1 デフォルトの名無しさん 2009/11/11(水) 15:23:15
Go part3
http://pc12.2ch.net/test/read.cgi/tech/1259072043
>1 デフォルトの名無しさん 2009/11/24(火) 23:14:03 /

まぁ、まだバージョンも0.1だし。

俺法則だとソフトウェアはメジャーバージョンが3あたりが丁度良い。

>>24
Goはあのマスコットキャラがきもい

これだろ？まじきもいよな
http://www.tv-asahi.co.jp/channel/contents/anime/0041/img/0_3.jpg

>>24
Goはコンセプトが明快かつ独自性もあったからな
そしてあのGoogleが、あのRob Pikeがという話題性も付随してたし
だがRustは「数多提案されたCの代替の一つだろ？」で済んでしまう
見た目の話に終始してるのも、Cの代替として使いやすいのか？という視点で見られているからだし

Goスレ落ちてたからもう見限る
これ流行るか？

Firefoxに載ってからが勝負だろ
そのためにはDartにコケてもらわないとな

いや、DartとRustは全く用途が違うんだが…

Mozillaがリリースってだけで勘違いしちゃったんだろうね

FirefoxのバックエンドがRustで書かれるようになるってのは何年後なんだろうな

コアプロジェクトで無いとはいえ３年掛かってようやくv0.1という
歩みの遅さを見れば、そんな日は来ないと思えるわな

完成度は高いんだけどなぁ

https://github.com/mozilla/servo
コンパイラ以外の実用例が出てきたな

Note that Servo is a research project, it may or may not become an actual product.
まあ元々それのために作ってたもんだしな

0.3ﾏﾀﾞｧ?

Note development roadmap
https://github.com/mozilla/rust/wiki/Note-development-roadmap

[rust-dev] Rust 0.3 released
https://mail.mozilla.org/pipermail/rust-dev/2012-July/002087.html

作者Graydon Hoareへのインタビュー
http://www.infoq.com/news/2012/08/Interview-Rust

"it seems a long time ago when @sayrer and I agreed to invest in
 @rustlang. But it was not, in Internet time."
https://twitter.com/BrendanEich/status/231566448017948672

http://www.infoq.com/jp/news/2012/08/Interview-Rust
日本語版。
英語併記するくらいなら原語に統一すればいいのに

最近 Perl みたいな記号地獄になりつつある

http://mozillamemes.tumblr.com/post/29632512055/want-to-write-code-in-rust-youd-better-develop

http://smallcultfollowing.com/babysteps/blog/2012/08/24/datasort-refinements/

JITコンパイラ！
http://blog.z0w0.me/posts/2012/09/01/experimental-jit-compiler-for-rust/

~"UNIQUE STRINGS EVERYWHERE" は見直すつもりなさそう
Mozillaに腱鞘炎が流行する日も遠くないな

https://speakerdeck.com/u/dherman/p/rust

https://github.com/mozilla/servo/blob/master/src/servo/gfx/geometry.rs

ぱっと見は整理されてるような
個人的にgoよりは見やすくかんじたが
Cとのバインディングとかはやり難そうかな

"This four-post series on Rust is intended to introduce you to the language,
to teach you about Rust's cool language features"
http://winningraceconditions.blogspot.jp/2012/09/rust-0-index-and-conclusion.html

月曜に0.4出るってよ

[rust-dev] Rust 0.4 released
https://mail.mozilla.org/pipermail/rust-dev/2012-October/002489.html

* 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

かなり変わったな。チュートリアルもなんだか縮小したし、一通り勉強してみたけど、
仕様が落ち着くまで離れとくか。

互換性がなくなるような変更はなるべく0.4に詰め込んだみたいなこと言ってたけど、
0.2のときもそんなこと言ってたし今後もモリモリ変化しそうだな

[rust-dev] Rust 0.5 released

Version 0.5 (December 2012)
---------------------------

* ~900 changes, numerous bugfixes

忍法帖のせいでリンク貼れねぇ。。。

保守

それなりにユーザー増えてきたね
www.reddit.com/r/rust/

let a = vec::filter([~"foo", ~"bar"], |&x| { str::starts_with(x, ~"f") });
な感じのコードを書いたときに出てくる
warning: instantiating copy type parameter with a not implicitly copyable type
の意味と解決法を教えてください

>>57
Rust 0.5だとvec::filterの第1引数はコピー可能な値の配列でなければならない
~str型の値は暗黙的にコピーできないから明示的にcopy修飾子を書く必要があるんだけど、
そうしてないから警告が出てる
次に出るRust 0.6からはvec::filterの定義が変わって、配列の値がコピー可能である必要はなくなった

解決方法は、|&x|のあたりにcopyを書く（どこに書くかは忘れた）か、
incomingブランチのsrc/libcore/vec.rsからvec::filterをコピペして使うとか

補足
Rust 0.6ではvec::filteredとvec::filterに分かれてる
vec::filteredは配列の各要素をコピーして返す（0.5のvec::filterと同じ）
0.6のvec::filterは配列のオーナーシップが移動するようになってて、要素はコピーされない

オーナーシップが移動ってことはつまり、
渡せるのは~[T]だけで@[T]は不可、んで渡した配列はそれ以降参照できなくなる

ありがとうございます
所有権についてはC++で少しやったつもりでいましたが
なかなかどうして精進が足りませんね

>all Rust executables require a MinGW installation at runtime
もしかしてwindowsでバイナリ配るのハードル高い

最近触りだしたけど、いい言語だな

[rust-dev] 0.6 prerelease testing

https://mail.mozilla.org/pipermail/rust-dev/2013-March/003402.html

rust 0.6 なんか面白そうだと思って拾ってみた。コンパイル終わらない…。
でもこれ、C/C++ に文法が似てるって嘘だと思う。{} を使うって以外は、全然違うじゃん。

文法だけは似てるとおもう

HaskellやらMLやらErlangやらに比べれば似てるよねってことだよ

[rust-dev] Rust 0.6 released
mail.mozilla.org/pipermail/rust-dev/2013-April/003427.html

* 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.
こりゃまた随分と

頑張ってんね

リリースノートに載ってないけどしれっと pure キーワードがなくなってる

borrowed pointerとmutabilityの扱いが変わったおかげで、
pureがいらなくなった

セミコロンがあると値がnilになるってのは、
バグの温床になりそうだなー

おれも仕様読んでちょっと気になったが、コンパイルでほぼチェックできるんじゃないのかね？

最近触ってなかったけど、セミコロンがあると返ってくるのはvoidじゃなかったか

ブロックの最後の式に;が付いてる場合は、
そのブロックが値を持たない(=voidを返すなの？)って話だよね？

() と書いて 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

こういうのもできるのか。

値を返すべきブロックからうっかりnilを返したら、
その値を使う箇所でコンパイル時に型エラーが出るから問題ないよ

法則発動でオワコン

じゃあAndroidはいまごろ瀕死になってないと

あくまで一サプライヤーとして利用するなら法則も回避できるのだがFirefoxOSはどうなるか。。。

そもそもオープンソースの協力者の一つでしかないし。

ほっしゅほっしゅ

v0.7 is coming.

https://github.com/mozilla/rust/blob/release-0.7/RELEASES.txt
http://www.rust-lang.org/

http://stackoverflow.com/questions/17514598/building-a-cross-platform-application-using-rust
https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust

https://groups.google.com/forum/#!msg/haxelang/WKAWQK4WGa8/wZxViCsLzOYJ

年末にはだいぶモノになるとかいってるけど
だいぶ先は長そうだなこれ…

もう諦めて寝るわ。1.0になったら起こしてくれ

一目ゴミっすね。

土方にはゴミにしか見えんだろうな

わかりやすい日本語解説きたで
http://gifnksm.hatenablog.jp/entry/2013/07/15/170736

早く1.0になってクレヨン

mut 周りがよく分からんな。 C++ でいう
int* const
int const*
みたいな区別はない（0.2 くらいのときはあった気がするけど）んだよね。

>>89
昔は構造体のフィールドに mut をつけて、そこだけミュータブルにすることはできたね。

今は、データの所有者のミュータビリティが継承されるという仕様だから、
データの一部だけがミュータブルということはなくて、
全部ミュータブルかイミュータブルの2つしかない。

ただし、例外が @ で表されるマネージドボックス。
これは所有者が複数いるので、所有者のミュータビリティを継承するのでは無く、
ボックス自体がミュータブルかイミュータブルかの属性をもっている (@ と @mut)。
なので、@ を使えば C++ でいう例のようなことは一応できる。

Rust では @ の使用をできるだけ避けようという風潮があるから、
C++ と同じ事をやる目的で @ を使うのはあまり推奨されないとは思う。

>>90
分かりやすい説明ありがとう。 @-ptr が mutability を継承しないという点が分かってなくて
コード書いていて混乱した。って Tutorial にも書いてあるね。最近読み返してなかった。すまん。

あと、
(~[0]).push(1); // OK
(@mut [0]).push(1); // NG
メモリの再配置が行われる可能性のある操作が @mut [T] で不可能なのは
考えてみればそうなのだけど、ちょっとびっくりする。

v0.8 is coming.

https://github.com/mozilla/rust/blob/0.8/RELEASES.txt
http://www.rust-lang.org/

C++でいいような気がしてきた

いつなったら1.0になるのよ？

あまりに大きな変更は2.0に持ち越すとか言ってる1.0はそう遠くないと思う、半年とか1年以内には

>>94
GCを言語コアからライブラリに追い出すことが決まったあたりから、
競合のDやGoよりもシステム寄りの、ちょうど今C++が占めてるニッチを奪おうぜって流れになった
http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/

死ねバカｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

死ねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ


死ねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ


死ねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗ

ゴミｗｗｗｗｗｗｗｗｗｗｗｗゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
死ねゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗコラｗｗｗｗｗｗｗｗｗｗｗｗ
死ねコラゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ゴミではない
錆だ

C4のレシピってゾンビからドロップしますか?

0.9来たか

https://github.com/mozilla/rust/blob/0.9/RELEASES.txt
http://www.rust-lang.org/
http://sourceforge.jp/magazine/14/01/15/203000

0.9になっても結構変更あるな。Managed boxes (@) が非推奨てｗ

1.0は2014年末の予定とか http://cmr.github.io/blog/2014/01/12/the-state-of-rust-0-dot-9/

Rust on rails、トップシェアになる

「レール上の錆」か……

あと1年もこの調子で変更すんの?
とっとと1.0出してよ

おい、台本ちゃんと読めよ　そこの台詞は
「けっノロマめ、俺がフォークして先に1.0を立ち上げちまったぜ」
だろ

どちらかというと v1.0 以降の破壊的変更の方に期待してしまう（マゾ）。

良く訓練されたD言語erのような性癖だな

Feature gate なんて大義名分があるんだからいくらでも破壊的変更してきそうだよな
ワクワクする

rust速いらしいけどgoに比べて並列化し辛いから結局goのが速いって聞いてんですけどそんな感じなの？

シングルスレッド遅い言語はどんなに並列化しても無駄

>>110
その手の、Erlangっぽい並列処理は、ライブラリレベルで実装可能。
Scala/JavaのAkkaがその実例。

破壊的変更が毎週たくさんあるね

次期バージョンは0.10かね

v0.10 is coming.
http://www.rust-lang.org/
https://github.com/mozilla/rust/blob/master/RELEASES.txt

・@ ポインタを remove
・do キーワードを remove
・etc...

なんでこの手の言語（といっても某Dくらいしか思いつかんけど）って1.0が遠いん

なんで1.0が出てから始めないん

DとかGoとかポストC気取ってるくせにCを駆逐する気がない言語より頑張って欲しい

頑張って欲しいけど、1.0 が遅いから Swift に浮気しちゃうぜ

rustでRAIIはどう実現したら良いのでしょうか

v0.11 is coming.
http://www.rust-lang.org/
https://github.com/mozilla/rust/blob/master/RELEASES.txt

・構造体のフィールドがデフォルトで private に
・private enum 変数が不許可に
・priv キーワードを remove
・`use foo, bar, baz;` シンタックスが remove
・……

Rust言語の明日は何処だ

C++を駆逐するなら大歓迎だ

>>123
俺も同意。
Rust頑張れ。

それならDとGoに勝たないといけない
おれはRustに頑張って欲しいから早く1.0だして欲しいけど、もう手遅れな気はしてる

DはともかくGoは厳しかろうなあ

GoではC++の駆逐はできないと思う。
たとえば、goでOSを作れるかというとそうではない

C++の代わりになるのはCで作られたlibやDLLを直接呼べなくてはならないが
Dはヘッダーファイル作ればできるけど
Goは問題外だった。
rustってどうやんの？

extern "C" とかつけて関数宣言すると、Cの関数が呼び出せる。
呼び出し時の余計なオーバーヘッドとかは今はなくなってるはず

次のC++17までに実用になってなかったら逆に駆逐されるな

>>129
おお、良いぞ。そんな感じで十分だ。
C++は規格化に関わってる連中が（ここだけの話）キモいので駆逐してほしい

C++で中間コード吐き出すコンパイラ作ったほうが喜ばれる

Road to Rust 1.0 http://blog.rust-lang.org/2014/09/15/Rust-1.0.html

はよ 1.0 になれ

Mozillaは永遠にベータ版しか出さん連中だから無理

[rust-dev] Rust 0.12.0 released
https://mail.mozilla.org/pipermail/rust-dev/2014-October/011267.html

1.0ｺﾈｰ

だいぶ見ないうちにもはや別言語になっとる。
es6みたいにどうせ新機能使ったら互換性なくなるのにbreak the webとか抜かして右往左往し続けて
仕様がコロコロ変更されるより元から破壊的変更上等だけどバージョンが安定しないな。

moveって名前の関数つくれないんだ？

moveはキーワードだから、使えない

仕様が安定するのはいつですか

&strとstringやっぱめんどくさい。
せめてリテラルの中に変数値埋め込むような書式が欲しいけどそれだとそもそも&strにならない。
もう文字列リテラルはstringにしてくれよ

文字列リテラル書く度にメモリの動的確保するのは、
さすがに発狂ものだろ
slicing_syntax使えば、.as_slice()が[]になるし、それで我慢してくれ

stringといえばcoreutilsのコード読んでて思ったんですが
https://github.com/uutils/coreutils/blob/master/src/cat/cat.rs

> let show_nonprint = matches.opts_present(["A".to_string(), "e".to_string(), "t".to_string(), "v".to_string()]);

こういういちいちto_string()してるコードもうちょっと上手く書けませんかね

これの解決方法を教えてください
http://melpon.org/wandbox/permlink/Ce549z8Z26NYtfpj

Rust 1.0: Scheduling the trains
http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

はよ

公式のGuideに従って Hello, world! コンパイルしたら600kBくらいのができたんだけど、これ何が入ってるの？
たしかGoもこんなだったっけw

>>147
標準ライブラリが静的リンクされてる。
jemallocとかサイズでかいらしい。
-C lto つけてリンク時最適化有効にすると若干サイズ縮むはず

ガイドページの右下に出てる
Rust 1.0.0-nightly
ea6f65c5f
って何？

ドキュメントのバージョンだよ。

1.0のalpha来てた
もうすぐ安定するんだと思うとなんだか感動する

楽しみだね。

Guessing Gameまで来たら
↓が変な感じがする。値を返すかcontinueで離脱。例外みたいなノリなんだろうか

let num = match input_num {
Some(num) => num,
None => {
println!("Please input a number!");
continue;
}
};

見てきたけど
uint に変換できない場合
None が返って来て、
もう一度 loop の最初からやり直し
なだけじゃないか？
Option で返って来るのに慣れてないのかな？

例外については下記が日本語訳(ただし、前のverなので文法が違うかもしれない)
ttp://qiita.com/kondei/items/c7175ed278bb4fbd4d16

ああなるほど、None（と言うか() のことかな？）を返してからcontinue動作したと考えればいいのか

そこ俺も違和感あった
HaskellやOCamlにおけるパターンマッチは条件分岐というよりも値の分解の意味合いがつよいと思うのだけど, Rustでは条件分岐としての側面が強いのかなと感じた
要するにif文ってことだよね

大域脱出と見ればそんなに違和感ないと思う
bookに記載はされてないけど縦棒で複数のパターンに対応させることもできるのな
match foo {
Bar | Baz => do_X,
Huga => do_Y
_ => do_Other
}
みたいなのもいけた。無かったら嫌だなと思ってたがreferenceにはあった

>>156
ガチの関数型とはなんか違うfeelingと言うか空気感を感じる

関数からIteratorを返す方法が分かりません
具体的には型に何書いて良いか分からない

>>158
Rustの良さの一つではあると思う
メモリモデルの問題で普通の関数型プログラミング言語と全く同じようには出来ない中で、なるべく関数型の良さを取り入れようという結果なんだろうな

>>159
関数の中身によるけど、
戻り値書かなかった場合のコンパイルエラーで出てる型名コピペすればたぶんいけると思う

言語が固まったらREPLの開発も再開するよね

RustでREPLはめんどくさそうだな
寿命とか
でっかいひとつのスコープって考えたら別にむずかしくはないのな

1.0.0-alpha をビルドしてるんだけど
configure に --libdir=/usr/lib64 を指定すると
lib.rs がコンパイルエラーになってしまう
前からこんなんだったっけ・・・

ここ最近の怒涛の変更はヤバい

clayもそうだったけど、llvm使った言語のビルドってすげー時間かかるのな。ナイトリービルド落とした方がええわ。

クロージャ周りが変更されまくってて全然わからん

そろそろ試してみようと思ったらまだそんな感じなの?

これから構文の変更は極力減らすらしいし、1.0がリリースされるまでのあと2〜3ヶ月は詰めの時期だろう
ドキュメント周りは絶賛崩壊中。Rust by Exampleとか全然動かん（Issueは立ってるけど）
まあ検索しても古いブログとか引っかかりまくるからな―
なんかあったらGitHub該当レポをいちいち見に行くくらいのことをしないと勉強するのは厳しい

構文の変更はなくてもAPIの変更はあったりするんだろうか

このスレ立ったときから安定したら使ってみようと思ってたけど
もう少しらしいね

ベータのリリースサイクルでライブラリの安定化やるから、
APIはまだまだ変更されるはず

ベータ出てからも長そうだな...

1. 全ての値、変数はそれが定義されたスコープ内で死ぬ(読み書きできなくなる)
2. ある値を殺さずスコープの外に出すには、死ぬ前に外の変数に入れるしかない
3. ただし、参照を外に出すことはできない

lifetimeの原則ってこんなもんだよね？これはまだ分かるけど、ownershipはも少し理解が必要。
マルチスレッドを学ぶときにきっと理解できると信じてる。

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> { ... }
は関数もクロージャも通す。

クロージャの定義を見ればコンパイル時に環境を持たないで済むか分かると思うんだけどなあ
関数 ∈ クロージャみたいな関係なんだから、関数で済むなら関数にして欲しい

unboxed closureならほぼ関数みたいに使えると思うけど。やりたいことは、boxingが必要なケース？

よくわからん事を言ってしまった。
そもそも、クロージャとして扱うってどういう意味で言っている？
rustではクロージャ「型」というものは最近なくなってしまって、
ただFnを実装した型が関数のように呼び出すことが出来るだけという認識。
Fnを実装したある型が関数として定義されているか、
クロージャの構文を使って定義されているかは、
渡される側からは意識する必要がない。

>>177
クロージャとして扱うってのは>>175の二番目のmap<S,T,F:Fn(&S)->T>っていう高階関数は、
fn foo(...)で定義された関数を渡すことができるし、let baz = |&:| { ... }とかやって定義したクロージャを渡すこともできる。
>>175の一番目のmap<S,T>はfnで定義した関数は渡せるけど|&:| {...}は渡せない。
つまり、関数とクロージャは別物なんだけど、クロージャを受け取る高階関数は関数も受け取れる。
それを指して「クロージャを受け取れる高階関数は、普通の関数もクロージャとして扱う」っていう意味で言った。

referenceのfunction typeの項
http://doc.rust-lang.org/reference.html#function-types
にもあるとおり、関数の型はfn(args) -> retと書けるもので、traitの実装とかではない。
一方でクロージャはFnトレイトの実装。違いは環境を持つか否か。

>>178
おそらくだけど、Rustの言語仕様で閉じる範囲に関しては、すべて区別せず Fn traitに統一したい意図があると思う。
関数型が残されているのはFFIの都合かと

そうなの？関数内で関数を定義できるからある程度は使えるんだけどな。

ついでに質問なんだけど、Fn traitの記法Fn(s) -> tってのはこれ専用の記法なの？
それとも一般的な記法の一例？

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ウォッチすると議論が追えると思う。

トップレベルで型注釈を強制するのはひとつの見識だとは思うんだが、
型の表記がもう少しスッキリしたマトモなものじゃないと面倒臭すぎる。
なんでそういうところはMLやHaskellを見習わなかったのか……

>>182
本当だねえ。関数引数リストの中がゴミゴミしい

ttps://github.com/rust-lang/rust/issues/20797?#issuecomment-69947098
associated typesを使っているtraitが拡張できん…

>>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...

http://arthurtw.github.io/2014/11/30/rust-borrow-lifetimes.html
borrowingについてはbookより良い説明になってる。

http://stackoverflow.com/questions/22188088/what-does-a-scoped-lifetime-in-rust-actually-mean
この解答はかなりlifetimeについて分かりやすかった。

lifetimeとsubtypingの類似性をまとめようと思ったが力尽きた。
1つの事柄を説明しようとすると別の関連項目も入れた方がいいなとかやってると膨大になる。

rustはじめました
バカなんですけど教えてください
fn main() {
let mut a = &1is;
let mut b = &2is;
a = b;
}
b = a だと平気なのに a = b だと叱られます。なぜですか

先に宣言した方がlifetimeが長くなるルールだから？

nightlyなら通るよ>>187

お二方どうも

>>188
どこで寿命尽きるのかlifetimeムズカシイです

>>189
通るのですか
しかしエラー出ます　rustc 1.0.0-nightly (eaf4c5c78 2015-02-02 15:04:54 +0000)
githubのをビルドしないとダメでしょうか
面倒なのでブック読みながらバイナリの更新待ちます

今なら2015-02-04のバイナリ落ちてくるよ

うーん。変わらずエラーが出ます　rustc 1.0.0-nightly (ba2f13ef0 2015-02-04 20:03:55 +0000)
本来>187はコンパイル通るものですか

エラーこんな感じで
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 }

playpenでも転けるし駄目っぽい

nightlyで通ると言ってた者だが、1月24日のは通ったが、今日2月6日では通らなくなってた。

やっぱりlifetimeの長い短いとちゃうかなぁ。
>let mut a = &amp;1is;
>let mut b = &amp;2is;
aの型は&amp;'i isize
bの型は&amp;'j isize
だとするとlifetimeの長さはi > jであるからaはlifetime i以上のisizeへの参照を要求する。
bのlifetimeはjであるからnot live long enoughなんじゃないかなぁ。

うーん、でも
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
やなぁ。

print_type_of ってデバッグでしょっちゅう使うから、標準ライブラリに入ってると良いのに

get_tydescでlifetimeってstatic以外も出せるの？

fn main() {
let x = &1;
print_type_of(&x); // &'static i32
{
let k = &3;
print_type_of(&k); // &'static i32
}
}

https://github.com/rust-lang/rust/pull/21657
https://github.com/rust-lang/rust/pull/21022
何言ってるか分からん。誰か解説してください。

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.

http://blog.rust-lang.org/2015/02/20/Rust-1.0-alpha2.html

ってことは主な標準ライブラリのAPIも安定するってことか？
安定バージョン出たら使おうと思ってたからそろそろ本格的に勉強しよう

rust 日本で人気ないのなんでだろ
hackernews とかでは話題になるのに

なってねーよ
Rustユーザーの声がでかいだけ
Githubのトレンド見ろよ
てかいつ1.0になるんだよ
コンパイルクソ遅せーよ

今見たらハッカーニュースで話題になっててワロタ

日本人なんでいつも出遅れじゃん

半島人や大陸人ではないので念のためw

RELEASES.md
Version 1.0.0-alpha.2 (February 2015)
ttps://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-alpha2-february-2015

本題と離れたこの辺が好き→Rust is tested against a LALR grammar

日本はシステム寄り言語はあまり盛り上がらない印象
フレームワークでこんなんできた、とかそういうのばっか

そのフレームワークにも乗り遅れてるけどな

今のペースだと1.0は早くても5月の半ば
GWあたりから勉強すればいいや

ttps://github.com/uutils/coreutils
Cross-platform Rust rewrite of the GNU coreutils

面白そうだから時々覗いてるけど、作る宣言してやりかけか音沙汰なしが多い

1.0が出てからが本番

最近Nimとの比較記事よく見る
試したことないが速いんか

試せよ
馬鹿なの？

やだね

"「Unix in Rust」の作者がRustを捨ててNimに移行"
ttp://developers.slashdot.jp/story/15/02/20/2132207/

Nimの詳しいところは見てないけど、ソースぱっと見で括弧や大文字小文字のめりはり無くて散り散りした感じは嫌だな
その点はこっちの方がいい

NimはRustよりかなり前からあったでしょ。少なくともぽっと出の新人じゃない。

Nimは高速化、拡張の手段が多い(テンプレート&マクロ, コンパイル時計算, 最適化処理)にもかかわらず、
それらを作るときに変態的な見慣れぬ処理をしているようには見えない。
この、LispのマクロがPythonの文法でやれているのがおそらく一番凄いところ。
Python人口は多いから間口は広いと思うよ。Pythonと違ってまともなスコープだし。

型システムはRustの方が見通しが立っている。Nimはちょっと独特。
そして何より、Rustは低レベルもターゲットだけど、Nimはそうじゃない。
高速 -> 低レベルってのは昨今じゃ成り立ってない。

あっちはGC、こっちは全手動

>>217
全手動って、ほぼRAIIとレファレンスカウンタで足りてるように思うけど。
別にmalloc,freeを一々手で書いてるわけではない。

NimのGCがスレッドセーフになるのと、RustにGCが搭載されるのと、どっちが先か

RustはGC搭載だったのを取り除いたんじゃなかったか

RustでもDでもNimでもなんでもいいよ
俺は勝ち馬に乗りたいだけだ
共倒れになるのが一番困るんだよ

勝ち馬おじさんは適当なほにゃららbindingsでも作ってオポを得てください

>>220
RustのあれはGCじゃなくて今で言うところのRcだったはず
GCの一種といえば一種だけど、実装は異なるから区別したい

参照カウンタもオブジェクトマップも両方GCで最近の参照カウンタは実行時じゃなくてコンパイル時にやるGCじゃないやつがあるんだよ。

Boxはownership付きのポインタだ！と気付き、ヒープに限定しなくてもいいんじゃないかと思ったんだが、
move semanticsがあるので、そんなに便利にはならないことが分かった。
うまくできているなと思う。

RustでC++のコードを呼び出せるようにならないかな

呼べるんじゃね

FFIくらいあるじゃろ

ServoではCのラッパー関数作ってるって書いてあった
ただそれだと関数呼び出し増えた分のオーバーヘッドがあるから、
言語を跨がった最適化を検討中だとか

rust自身も自分用llvmを使っていて、ビルドに超時間がかかる。
Servoは自分用rustを使っているのでもっと時間がかかるので、面倒でしょうがない。

同じくrustcのバージョン固定してるcargoはnightlybuildのバイナリ使ってるけど、
servoはソースからコンパイルしてるの？