プログラミング言語 Rust

1 名前：デフォルトの名無しさん [2012/01/25(水) 20:05:49.96 .net] Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。 www.rust-lang.org/ 267 名前：デフォルトの名無しさん mailto:sage [2015/05/06(水) 13:55:18.13 ID:xpDcmA5j.net] いろいろあるけどとりあえず1.0にして酒盛りだw 直す所はまだあるとしても、仕様が固まってくれると学ぶ気になれるのでありがたい、けど 268 名前：デフォルトの名無しさん mailto:sage [2015/05/06(水) 16:17:50.78 ID:am6Qsc64.net] cargo使うにはnightly build使えって事？ 269 名前：デフォルトの名無しさん mailto:sage [2015/05/06(水) 22:51:00.49 ID:JOkpKlyr.net] >>268いや、公式サイトからバイナリ落として使うなら1.0.0-beta.3にcargoが入っているので大丈夫。 自分のLinuxディストリがソースからビルドしたものを提供していたり、自前でrustをビルドしている人は自分でcargoをビルドする必要がある。 で、自分でbeta用のcargoをビルドするのが面倒だねって話。 crate.ioのgetting startedは相変わらずnightlyを推奨しているのは温度差を感じる。 Cargo.tomlにコンパイラのバージョンあるいはstdのバージョンを示すダミーcrateを登録できたらいいのか？ 270 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 00:38:18.86 ID:aZRIIXEP.net] >>264 travisはbetaチャンネルのコンパイラとcargo使うオプションあるよ。 フォーラムにやり方の投稿があったはず 271 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 13:27:05.75 ID:23tsmTPn.net] >>263 日本人のcontributorって結構いるの？ 272 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 17:33:22.03 ID:aZRIIXEP.net] >>271 GitHubでの開発だからいわゆるcontributorとはずれちゃうんだけど、 PullRequest出してマージされてる日本人は何人か見たことある 今回の主催の人はservoリポジトリへのコミット権持ってて結構活躍している 273 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 18:24:03.66 ID:ADm0d2/c.net] On Lisp 和訳の人の名前を見た気がする 274 名前：デフォルトの名無しさん mailto:sage [2015/05/11(月) 03:01:17.51 ID:bJJob3eC.net] BetaのドキュメントにComing Soonが多いんだが、Nightly見た方が良いの？ 275 名前：デフォルトの名無しさん [2015/05/12(火) 01:10:22.42 ID:xKmS5U3V.net] どうせ動かないんでしょ 276 名前：デフォルトの名無しさん mailto:sage [2015/05/14(木) 00:16:14.10 ID:K0fBW8ZW.net] 'The Rust Programming Language' as EBook ttps://github.com/killercup/trpl-ebook 277 名前：デフォルトの名無しさん mailto:sage [2015/05/14(木) 06:37:57.45 ID:HvPUnCOb.net] >>263 元日立社員が転職して後悔してさらに転職を計画 yomogi.2ch.net/test/read.cgi/net/1429876526/ 278 名前：デフォルトの名無しさん mailto:sage [2015/05/16(土) 00:11:55.14 ID:3gBP+Qn+.net] Programming Rust Paperback – November 25, 2015 ttp://www.amazon.com/Programming-Rust-Jim-Blandy/dp/1491927283/ ISBN-13: 978-1491927281 ISBN-10: 1491927283 279 名前：デフォルトの名無しさん [2015/05/16(土) 02:23:52.03 ID:3gBP+Qn+.net] Announcing Rust 1.0 ttp://blog.rust-lang.org/2015/05/15/Rust-1.0.html Today we are very proud to announce the 1.0 release of Rust, ... 280 名前：デフォルトの名無しさん mailto:sage [2015/05/16(土) 02:43:58.46 ID:7PFiMYNq.net] 正真正銘バージョン1.0リリース! おめでとう。 281 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 01:33:56.23 ID:sVRosqPI.net] sage 282 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 13:05:27.84 ID:I8sSWQip.net] let mut って… 気持ちは分かるが厳密過ぎだろ… 283 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 14:22:47.25 ID:N0SAwEsK.net] 普通だと思うけど... 今までCしか使ったことないのか。 284 名前：デフォルトの名無しさん [2015/05/18(月) 14:33:14.59 ID:J+DllwNy.net] >>282 それならそもそもmutableな変数が無い方がいい、とな。 なるほど賛成だ。 285 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 15:22:04.80 ID:I8sSWQip.net] >>283 普通は const immutable = 0; または let immut immutable = 0; let mutable = 0; だろ なぜ良く使う変数の方がタイプ数が多いんだよ… 286 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 15:44:06.55 ID:N0SAwEsK.net] >>285 mutableな変数の出番が多いのはあなたの書き方の癖であって、他の全員に当てはまるわけでは無いと思う。 特にRustはifやmatch等が値を返すからmutableと相性が良いと思うけど。 287 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 15:45:07.29 ID:N0SAwEsK.net] >>286 修正: immutableと相性が良い 288 名前：デフォルトの名無しさん [2015/05/18(月) 16:26:46.46 ID:J+DllwNy.net] >>285 >なぜ良く使う変数の方がタイプ数が多いんだよ… immutableな変数の方をよく使わないのだとしたら、 そもそもRustでのプログラミングには向いてないな。 基本的には破壊的更新をしない関数型スタイルで書かせて、 それをコンパイラが巧く処理してゼロコストにする、 というのがRustの設計思想なんで。 いい機会だから、変数の再代入を一切使わずにコード書いてみるといい。 289 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 17:11:40.54 ID:hULj5jYE.net] つまりC++でconst書きまくるのに疲れてる俺向きということですな! 290 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 22:19:14.44 ID:eEjXu/P7.net] 関数型言語を触ってみるとリフレッシュできるよ。OCamlが緩くてお勧め。 RustはセルフコンパイルできるまでOCamlで開発されてた位にはメジャーで実用的。 パターンマッチや型推論、その他色々なRustの機能は関数型言語由来のものがあるから触ってみて損は無い。 「低レベルな領域に関数型言語の便利なエッセンスを(ゼロコストで)どれだけ入れられるか、入れたらどれだけ楽になるか」 みたいな発送がRustから感じられる。 もっとMLライクな文法でも良かったと思うけどね。 291 名前：デフォルトの名無しさん [2015/05/18(月) 23:34:48.44 ID:J+DllwNy.net] >>290 >もっとMLライクな文法でも良かったと思うけどね。 せめて型宣言はムリにC系のものにして関数定義の頭に押し込めずに 別立てにしたほうが良かったと思うんだよなあ。 とはいえ、確かにML系つうかOCamlの匂いは強くするよね。 292 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 15:09:00.81 ID:UYmTOlX3.net] >>285 まあそのまま仕様を受け取って、immutな方を自然に使って欲しいんだろう。 命令型言語に関数型の風味を取り込んでみたってことで。 ocamlの方は逆な風味だが命令型取り込んだ無理やり感がする。 rustも一実験言語で終わるのか、伸びるのか 293 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 21:19:02.97 ID:AGcxeKzS.net] 前はマニアのための実験的言語って書いてあったのに今では1.0だなんて感動する 294 名前：デフォルトの名無しさん [2015/05/21(木) 00:03:14.73 ID:R841WaTJ.net] 今更セミコロンがある謎言語 295 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 02:10:17.69 ID:gi6AaWSD.net] val foo : i32 -> i32とかできると便利よな。前方宣言は一応できるけどCスタイルだから冗長だし、 定義時に同じこと書かないといけないから面倒。 まあ、ML寄りの文法で変数の宣言とか並べるのも汚いかもしれんし、 関数型に近寄るとその分デバッグが難しくなる。誰かがML系rustを作ったら今の文法の良さが見えてくるかもね。 296 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 11:04:47.93 ID:HQdruXcL.net] 正式版でたんで久々に入れてみたら 単純計算ものでも2倍くらい速くなってるな node.jsと同じくらいにはなった 297 名前：デフォルトの名無しさん mailto:sage [2015/05/29(金) 01:21:31.51 ID:CYHwmvYd.net] The evolution of Rust lambda-the-ultimate.org/node/5169 298 名前：デフォルトの名無しさん mailto:sage [2015/05/30(土) 07:05:58.43 ID:AYzItcLB.net] >>296 単純計算だけならC++と同じぐらいだろ 所詮LLVMのフロントエンドなんだし 299 名前：デフォルトの名無しさん mailto:sage [2015/05/30(土) 10:56:09.40 ID:qPmgq1NQ.net] 言語はけっこう好みだけど仕事はC++だし 趣味用にはもうひと押し欲しい気がする 300 名前：デフォルトの名無しさん mailto:sage [2015/05/31(日) 07:07:23.95 ID:QzJY7rQQ.net] Rust って let (a,b) = (1,2); は出来ても、 　let a = 1, b = 2; は出来ないのか。 何故？　別に何かの文法と衝突でもするのか？ 301 名前：デフォルトの名無しさん mailto:sage [2015/05/31(日) 09:03:35.54 ID:chRy4RzH.net] >>300 let mut a =1, b=2; としたときにbがmutableになるのかならないのか曖昧に見えるから、という理由だった記憶がある とにかく、なにかしら理由があったはずだよ 302 名前：デフォルトの名無しさん mailto:sage [2015/05/31(日) 09:58:57.84 ID:QzJY7rQQ.net] なるほど。でも、なら let mut を var にして欲しいな。 mutable 変数は var で宣言する方が好みだ。 でググったら当然過去に let mut <-> var 議論あった。 ざっと読んだら、Rust の精神には immutable が根本にあって、 mut は気安く使うんじゃねーよ、的な障壁としての let mut みたいだ。 確かに var だと気安く使っちゃうからね。ってこれスレのすぐ上で話題になってた話だな…… 303 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 07:46:19.89 ID:JhAQPJZl.net] mutable参照を共有できないって厳しすぎないか？ 警告ならわかるがエラーは勘弁してほしい 304 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 09:39:17.92 ID:tuFYxFU/.net] Rc<RefCell<T>>やArc<Mutex<T>>をどうぞ 305 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 18:40:49.25 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 19:42:13.90 ID:rjZb8+Jq.net] 記述めんどいやろmut使うなという強烈なメッセージを感じるｗ 307 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 11:23:17.39 ID:/rtQk4xD.net] >>305 試してないけど let array = Rc::new(RefCell::new([0, 1])); じゃだめかな？こっちのほうがまだましかなと思うんだけど 308 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 22:39:23.60 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/06/19(金) 11:24:27.05 ID:7YWFihrY.net] WebAssembly対応すればブラウザゲーをRustで作れるようになるんかな 310 名前：デフォルトの名無しさん mailto:sage [2015/06/26(金) 05:16:57.34 ID:MTQE4YuR.net] borrow checkerや型チェックで弾かれるのはまだいいんだけど、unsized typeで怒られるのが面倒。 AsRefとかDeRefとか、traitを多用し過ぎじゃないのか。traitに関する構文(多相型関数の定義とか)も冗長に思ってしまう。 311 名前：デフォルトの名無しさん mailto:sage [2015/06/26(金) 22:05:32.88 ID:4tQavpY6.net] 久しぶりに見たら1.1になってた https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-110-june-2015 312 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 01:28:47.33 ID:F+n2jvy1.net] rebuld.fm聞いて、rust触ってみたくて来ました。 今から手を出す場合、どこを見るところから始めればいいです？ 313 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 02:07:48.13 ID:fUkToYrK.net] >>312 Rust by Exampleとか？ rustbyexample.com 314 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 05:34:06.57 ID:F+n2jvy1.net] >>313 おお、良さ気です。ありがとうございす。 https://www.youtube.com/watch?v=i17doLVXlYU をみてたら、すごく、関数型言語ぽくていいっすね〜 俄然やる気でます。 315 名前：デフォルトの名無しさん [2015/06/27(土) 10:51:13.60 ID:nreZwDj/.net] 実際に書いてみると全然関数型言語っぽくないのだよなあ。 あと、なんかイディオマティクな標準的コーディングスタイルが 確立されないと辛いと思う。 316 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 15:58:00.61 ID:rIdxbF5x.net] C++テンプレート以来のコンパイラに怒られまくる言語だ 317 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 16:26:20.28 ID:wfeMnVHy.net] https://github.com/rust-lang/rust/issues/25899 これがなぜだか分からん。 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 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 17:22:32.78 ID:99+F8Q1T.net] >>317 下の例はこれと同じになるらしい fn main() { 　let a: &mut i32 = &mut 0; 　{ let b = &mut *a; } 　let c = a; } Rustには型推論と暗黙の変換があるせいで分かりづらいね 319 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 17:34:52.26 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 17:35:27.20 ID:wfeMnVHy.net] >>318 ありがとう。うーむ悩ましい。 321 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 18:38:39.26 ID:SbfB1Jvt.net] >>310 unsized typeで起こられるのってどんな場合？ 322 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 18:40:12.36 ID:SbfB1Jvt.net] >>320 既出じゃなさそうならissue立ててみたら？ 323 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 20:45:16.24 ID:j6fAeiVj.net] >>321 いや、超基本的なミスなんだけど、 fn foo(it: Iterator<Item=i32>) { ... } とかすると怒られるの。 traitを引数にするなら、 fn foo<T: Iterator<Item=i32>> (it: T) { ... } みたいにしないといけない。 解決法は知ってるつもりなんだが、Sizedを実装していないからダメよ、と怒られるのは何故なのか未だに理解はしていない。 324 名前：デフォルトの名無しさん mailto:sage [2015/06/27(土) 23:20:55.81 ID:SbfB1Jvt.net] >>323 Trait型は実際にはそのTraitを実装した何かしらの型が実体になるんだけど、 関数引数とかローカル変数としてスタック上に配置するためには型自体のサイズがコンパイル時に分かってる必要があるから、 Trait型はポインタを経由するなどしないといけない T: Traitとかすると、Tで指定された型それぞれに応じて特殊化された関数が生成されるからコンパイル時に型が特定できてサイズもわかるから問題にならない 325 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 03:45:02.95 ID:sui11WPz.net] やっぱりスタック上に配置が理由なのね。でもそれって人が配慮する必要があるのか？という部分に不満が残る。 コンパイラが自動的に多相型の関数とみなしたら不都合があるのかな。 326 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 10:13:01.42 ID:6byfIPXR.net] foo: Traitを<T: Trait> fooのシンタックスシュガーとみなすのはありかもしれないけど、 スマートポインタ型なんかを定義する時とか本当にunsizedな型が必要なケースに困ってしまいそうな気がする。 自動で&Traitなどに変換してしまうのは、ヒープへのメモリ確保とか仮想関数呼び出しが必要で ゼロオーバーヘッドの原則に反してしまうからrustではやらないと思う。 327 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 17:45:54.19 ID:l0DVu4po.net] ?Sizedが必要な場合もあるし面倒だよね 328 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 19:16:48.49 ID:l0DVu4po.net] トレイトは別のトレイトを継承できるけど 継承しててもトレイトからトレイトにはアップキャスト出来ないっぽい これじゃあオブジェクト指向のような多態性を活かした設計は難しいね 329 名前：デフォルトの名無しさん [2015/06/29(月) 09:33:30.50 ID:8+Jbzv8W.net] 単なる型クラスになに要求してんのかと。 Rustがオブジェクト指向でないのは結構なことだ。 330 名前：デフォルトの名無しさん mailto:sage [2015/06/29(月) 17:09:32.97 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/06/30(火) 22:00:52.85 ID:5IIg4rdj.net] 暗黙のアップキャストてOOPの基本の一つじゃね？ 332 名前：デフォルトの名無しさん mailto:sage [2015/06/30(火) 22:32:05.66 ID:uCmnNLIn.net] どの言語のOOPかにもよるのでは。知らんけど。 333 名前：デフォルトの名無しさん mailto:sage [2015/06/30(火) 22:34:50.83 ID:OotDes5f.net] Rustって強力なトレイトという名の型クラスを導入することでOOP(のRustにとって必要な部分)が(綺麗に)できるというだけで、別にOOPするための言語では無いと思う。 ちなみにアップキャストってこれじゃいかんの? stackoverflow.com/questions/28632968/why-doesnt-rust-support-trait-object-upcasting 334 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 01:38:30.43 ID:Co4dDuJ+.net] インターフェースを拡張した場合において、拡張元のインターフェースにアップキャストできるかどうかは、OOPL次第。 同一のメソッド名であれば実装を一本にまとめてしまうJavaはできるが、 同一のメソッド名だが異なるインターフェースで異なる実装をもてるDelphiはアップキャストできない。 C#はどうだったかな？ 後者だった気がする。 335 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 01:51:50.96 ID:paBhA78F.net] アップキャストできない場合て、多態できなくね？ 多態出来ないと、OOPの1/3位の価値が失われる気がするんだが… ま、別にrustにOOPを求めてはいないんだけどね。 336 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 05:52:25.11 ID:/48a4Fba.net] >>334 DelphiもC#もできるぞ……なんか勘違いしてそう 337 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 06:53:23.75 ID:va2KIQhQ.net] >>335 Derived→Baseというtrait間のキャストができないだけで、 traitを実装した型を&Baseへキャストすることはできるけど、 それだけではたりない？ 338 名前：デフォルトの名無しさん mailto:sage [2015/07/04(土) 23:29:18.24 ID:Swd5RGwS.net] Documentation↓読んでみたけど使い方まるで分からなかった orz https://doc.rust-lang.org/stable/book/documentation.html どこか分かりやすいサイトあったら教えて 339 名前：デフォルトの名無しさん mailto:sage [2015/07/04(土) 23:41:44.31 ID:JArIChSh.net] rustbyexample 340 名前：デフォルトの名無しさん mailto:sage [2015/07/05(日) 00:58:16.90 ID:D54Ug4Aq.net] >>338 実際に rustdoc を使ってみれば慣れるだろ 341 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 12:17:44.59 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 22:52:02.79 ID:cXg5joXk.net] Neative boundsが実装されるのを待とう 343 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 07:18:05.44 ID:3KxMUrWp.net] RustのTraitは正直失敗だよ 本来のトレイトとは別物だしインターフェースや型クラスとも違う 中途半端な出来損ない 344 名前：デフォルトの名無しさん mailto:sage [2015/07/14(火) 00:55:02.57 ID:vqJ6PXtp.net] scalaのtrait implicit classを関係があるんかな 345 名前：デフォルトの名無しさん mailto:sage [2015/07/14(火) 20:39:40.07 ID:s1SvBZBN.net] 本来のトレイトって何？何がRustのトレイトに足りないの？ 346 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 16:36:48.46 ID:Kkrt7iJt.net] 本来のトレイトは実装を再利用するための機能であって 使うトレイトの組み合わせを変えるなどして実装を変えられるものだ 普通はトレイトに型システムの機能は無く トレイト型にキャストとか出来ないし どのトレイトを使っているのかで区別もしない ましてトレイトの関数を再実装できるようにしてトレイト型に多態性を持たせるとか 名前が衝突してもトレイト型にキャストすれば別々の実装が呼べるとかすべきでなかった おかげで本来の使い方が出来なくなった 347 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 17:45:25.68 ID:4s1838+j.net] いやだからRustでできない本来の使い方って何さ。他の言語でもいいから例をプリーズ。 Rustでも実装の再利用ってできるでしょ。Iteratorをimplするのに最低限必要なのはnextだけでいい。Readだったらreadだけ。 implする型に制限は無い。基本型にすらtraitを与えることができる。 オレオレ実装を使いたいならstruct Myi32(i32)とかすればいい。 traitは関数のみ定義できて値を持たせることはできないけど、これはimplする型全てが構造体のような形態を持っていないため。抜け道は普通にある。 traitは型ではない、型であるべきではない、という主張も正直分からない。 traitを実装したものは全て特定の関数を持っているんだから、それをまとめて型Xとするとどこに不都合があるのか。 348 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:54:13.14 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 01:05:53.97 ID:AYGKegct.net] はぁ？ 350 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 03:44:30.67 ID:xr+gKr/s.net] その一般的なトレイトだと、FooAかFooBをミックスインした対象はbar1とbar2を呼び出せないといけないんだよね？ OCamlの書き方でやると < bar1 : (); bar2: () > というシグネチャを持っている型しかFooA/FooBをミックスインすることはできないわけだ。 その型に、例えばBarと名づけて型チェッカで検査させて都合がでるとは思えない。実際に問題は起きていない。 https://codeshare.io/5XfJ1 ↑で一々implの羅列を書くのが面倒だという声に応えて>>341のようなimpl<F> Foo for F where FooA { ... }があって、 けどこれはまだ使い勝手が悪いからnegative boundがRFCに上がっている。 それも待ちきれないならnightlyのlibsyntax、あるいはsyntexを使って自動化することもできる(はず)。 他の言語だと、traitは型じゃないの？FooA+BarAをミックスインした型とFooB+BarAをミックスインした型は多相リストに入れたら駄目だったりするの？ 351 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 23:56:38.15 ID:P5KxMz2p.net] 一応トレイトの論文(Composable Units of Behaviour)があって それを本来のトレイトと呼んでるんだけど本来のトレイトは型じゃないってのは事実 PHPのトレイトが型としての機能が無くて本来のトレイトに近い Scalaのトレイトは型として扱うことで継承構造も再利用できるようになってるけど Rustと違ってそれで本来の使い方が出来なくなったりはしてない それと読み返してて思ったんだけどもしかしたら誤解させたかもしれない 今のRustでトレイトの型としての機能を無くすならトレイトの代わりになる別の抽象型が必要になる PHPもトレイトの他にインターフェースがある それにトレイトが型なのが問題というよりも型として強力にするために多態性を持たせたり 名前が衝突しても解決しなくていい仕様にしたのが一番の問題 そこで本来のトレイトと使い方が大きく変わってしまった 352 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 00:25:13.89 ID:GZRy2HRh.net] 論文のタイトル正確にはTraits: Composable Units of Behaviourだった 353 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 13:44:39.09 ID: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 名前：デフォルトの名無しさん [2015/07/17(金) 14:25:23.54 ID:Zvxj9F2y.net] 結論：オブ脳の恐怖 355 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 21:30:37.89 ID:FAOQ/v/X.net] まあrustのトレイトはその言葉の意味「特性」をそのまま持ち込んでいるから、シグネチャ以外の特徴の表現にも使われている。 SizedとかSyncとか。 この過剰な応用がどんなデメリットになるかはもう少し様子を見てみる必要があるとは思う。 今も初見じゃ分かりづらいエラーメッセージの元になっている。Sizedトレイトが実装されてないから駄目ってどういうこと？とか。 356 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 22:39:00.92 ID:vVMIYXNu.net] あの論文を読んでどうやったらトレイトを型と見なせるのか俺にはわからん 型＝クラスと思ってるわけじゃないけど型という用語の認識が違うのは確かだろうね 君はRubyのモジュールも型とみなすのかな俺は違うと思ってる 正直認識が違いすぎてどう説明していいのか分からん 他言語のトレイトを使って確かめてくれとしか言いようがない 357 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 02:51:08.17 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 18:51:02.73 ID:pLL2VJtZ.net] なるほど要するに trait Foo { 　fn bar(&self) {} } となってるときにselfの型はFooだからトレイトは型である必要があると言いたいわけだ 普通のトレイトはクラスにミックスインした時にコピーされるから その時selfの型が決まるけどそうやって曖昧にすることを許さないと でもその考え方はやっぱりトレイトと違う 一応論文のURLを貼っておくけど ttp://www.ptidej.net/courses/ift6251/fall06/presentations/061122/061122.doc.pdf 8ページの図にあるTCircleとTDrawingがトレイト 白丸が提供するメソッドで右矢印が必要とするメソッド 9ページの図がトレイトのミックスイン これがRustのトレイトと同じに見えるらしいけど 俺にはむしろ5ページの図にある多重継承の例がRustのトレイトだと思ってる そこに多重継承の問題が書いてあって実装が重複すると書かれているけど それを>>341で解決を試みているように見える この流れだと多重継承もトレイトだとか言われそうだけど そうなったらもう何も言えない 359 名前：デフォルトの名無しさん mailto:sage [2015/07/20(月) 21:03:10.22 ID: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 名前：デフォルトの名無しさん [2015/07/20(月) 21:06:59.38 ID:XuKvM2I+.net] トレイトは多相性の制限という形で不変条件を表現してるものなんだから >>357が正しいとしか思えんけどなあ。 361 名前：デフォルトの名無しさん mailto:sage [2015/07/21(火) 21:00:10.36 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/07/21(火) 23:59:09.59 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 00:06:40.09 ID:pdX/k3oq.net] あなたが書かなければならないのは、>>343で吠えたようにrustのトレイトが実装の再利用において、 本来のトレイトが解決してくれることができないこと、なんだけど1つも例を挙げてないよね。 >>348で折角「極端な例」を出してくれたが、それが>>350でrustでも書けることを示したんだが。 で、クラスと型を混同している頭ではトレイトが型なのが許せないようで、論文という他人の言葉だけを頼りにグダグダやっているけど、 第一級市民としてのクラスが無い、多相型のあるrustで、という文脈をずーっと無視しているよね。 論文は動的型付けの、継承がコードの再利用方法としてメジャーな言語の中での話、っていう文脈も無視しているよね。 トレイトは型ではいけない理由も、rustのトレイトが多重継承だと思った理由も、何にも説明してくれないからこっちで補完して反論してきたが、 もうお節介はやめるよ。ちゃんと自分の頭で考えなさい。 364 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 13:50:02.41 ID:tlwxTsYf.net] >>362 何を長々と、、、と思ってたらまとめが出来ていて分かった、乙 関数型の議論と同じく実用はおいといてセンシティブな定義で気に入らないのかな 定義に敏感な人は大変だなぁ 365 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 21:55:10.25 ID:ubJIybN+.net] 論文ではまず実装の再利用に関して既存のやり方には問題があることを示した上で その問題を解決するためにトレイトを提案してる その問題の1つが>>350のimplで理由は>>361に書いた 結局トレイトで否定したやり方をRustはトレイトと呼んでるわけだ Rustの文脈を無視してるというのならトレイトの目的や背景も考慮したらどうだ トレイトが型ではいけないってのは結局俺の間違いだった 型の機能を優先しすぎてトレイトの機能を無くすのが問題だっただけで トレイトの機能と型の機能は両立できそう 366 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 23:45:21.91 ID:pdX/k3oq.net] >論文ではまず実装の再利用に関して既存のやり方には問題があることを示した上で >その問題を解決するためにトレイトを提案してる だからその問題を具体的に、自分の言葉で説明しろよ。>>350を書いたのは俺だ。 そこにかかれているのはimpl TFoo for SFoo {}をひたすら書くのが面倒だね、ってことだけだ。勝手な誤読をすんな。 これが論文で言うcode duplicationだと思っているなら、あなたは論文を読む以前の知識が足りない。 しかも>>361で性懲りもなく親クラスなんて言葉をrustに持ち込んで妄言を吐いてるだけ。rustの何が親クラスなんだ？ トレイトの背景と目的？だから継承ベースのコードの再利用にある問題を解決するには、って分かってるから>>353で 「そんな問題はrustには無いんで、論文の言葉どおりにトレイトを定義した」と書いている。 で、親クラスって何よ？>>350のどこにも親クラスなんて存在しない。 367 名前：デフォルトの名無しさん mailto:sage [2015/07/23(木) 21:35:53.52 ID:XXd04llZ.net] Rustのトレイトを親クラス、構造体を子クラスと見なせば論文の例はこうなる https://play.rust-lang.org/?gist=8f1db295cff07a5163e7&version=stable SyncAとSyncBのimplがほとんど同じでA::やB::の代わりにsuperが使えれば完全に重複 論文ではこの重複も問題として扱っている

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef