プログラミング言語 Rust

1 名前：デフォルトの名無しさん [2012/01/25(水) 20:05:49.96 .net] Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。 www.rust-lang.org/ 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が使えれば完全に重複 論文ではこの重複も問題として扱っている 368 名前：デフォルトの名無しさん mailto:sage [2015/07/23(木) 22:25:53.21 ID:bNJIoU7G.net] それでみなさんはrustで何作ってるんですか？ 369 名前：デフォルトの名無しさん [2015/07/23(木) 22:42:51.27 ID:GSXYPmA+.net] >>368 まあ、昔と違ってシステムプログラミングの需要って減ってるよね。 GTKかwxWidgetsのRustバインディングが安定したら何作るか考えるわ。 370 名前：デフォルトの名無しさん mailto:sage [2015/07/23(木) 22:49:25.52 ID:yXyFyEpk.net] >>367 みなさなきゃ良いんじゃね rustのトレイトの問題じゃなくお前さんの視点の問題だろ？ Cで作るようなシステムアプリケーションとか作ってる 基本評判悪いけど面白い言語よのう 371 名前：デフォルトの名無しさん mailto:sage [2015/07/24(金) 00:32:36.11 ID:D0ziIpoZ.net] >>367 phpでやってみたが、減らせるコードって36-39行と47-50行だけしかなくね？ codepad.viper-7.com/2A7K4h しかもSyncAとSyncBをAを扱う関数に渡したら、syncRead呼ばれないし。継承じゃないなそれ。 学習目的もあるが、PEGをもっと広めたいなーと思って色々触っている。 DSL作るのはLispと関数型言語が楽だとは知っているけど、rustも代数的データ型とパターンマッチがあるから何とかなるんじゃないかと思っている。 std::mem::size_of_valとかで見る限り、構造体のメモリ使用量がCと同じなのが気に入った。 いくらメソッド追加してもコストにならないし、vtableが出てくるのは&Traitみたいなtraitオブジェクトを渡すときだけなのも良い。 struct Container<'a, T: 'a + Trait> { inner: &'a T } のメモリ使用量はusize struct Container<'a> { inner: &'a Trait } はファットポインタなのでusize + usize 372 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 02:29:33.62 ID:qRv1Q/E9.net] 普段ScalaとPlayFrameworkでWeb書いてるんやが、JVM嫌すぎてやめたい。 Rustさんはどうなんすかね。 373 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 02:34:13.24 ID:6f0NYoQy.net] Announcing Rust 1.2 blog.rust-lang.org/2015/08/06/Rust-1.2.html 374 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 11:31:29.07 ID:vDqHzBe+.net] >>372 JVMの何が気に入らないのか分からんが マルチコアプロセッサで効率的な動作を期待するならgoの方が向いてる 375 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 03:37:11.08 ID:f9auPRN7.net] Rust1.2に付随してcargoのバージョンが上がってプロジェクトディレクトリの.cargo/configで [build] rustc = "multirust run nightly rustc" とチャンネルを指定することができるようになったのが嬉しい。 前からcrates.ioのドキュメントにできると書いてあったのに、stableじゃできなかった。 3つもチャンネルがあるとドキュメントがいつから対応しているのか書く側も把握しづらいのかね。 376 名前：デフォルトの名無しさん mailto:sage [2015/08/12(水) 01:45:21.38 ID:7PEu3mkB.net] >>375 できなかった。自分でrust-nightlyとか適当なシェルスクリプトかまさないといけない。 377 名前：デフォルトの名無しさん mailto:sage [2015/08/12(水) 12:36:33.87 ID:0A5qnrPY.net] >>374 ただの技量不足なんですが、メモリ食っちゃうので… 378 名前：デフォルトの名無しさん mailto:sage [2015/08/12(水) 15:02:52.00 ID:rodoarXT.net] そりゃgoを使っても本質的には変わらんなw rustでビルド時に厳密にチェックするのは一案かもな 最初は厳密すぎて実装効率がクッソ下がる悪夢にうなされるだろうけど 379 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 21:19:32.57 ID:gZkyyADQ.net] rustで、機械学習やりたいんですが線形代数とかに便利なライブラリってあります？ 380 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 21:32:20.79 ID:PzFzu2cW.net] 基本的なライブラリも出揃ってないんだからないでしょ。 まぁ速くて関数型だから機械学習に使いたいのは分かるけど 381 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 22:24:22.09 ID:YKJt+Rxb.net] 普通にC/C++ライブラリをブリッジしてフロントをrustで書けば良いのでは ブラックボックスのライブラリまで無駄にrustランタイムに依存しなくて良いだろう 関数型だから(笑)で選んだなら全てがrustじゃないと気に入らないかもだが そうじゃないと思いたい 382 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 23:14:36.16 ID:nvcb5WnS.net] C、C++で書かれたライブラリは予想外な最適化がなされていることがあるのではないか、と https://github.com/BurntSushi/rust-memchr/ のベンチマークを見て、 code.metager.de/source/xref/gnu/glibc/string/memchr.c を覗いて思った。 383 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 06:56:14.33 ID:blwavvg/.net] >>381 単純にrustに触るモチベーションにしようかと思っただけなんですが、 結局c++とかさわることになるなら、もうちょっとまってみます。 384 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 07:57:50.79 ID:OFjX8KNn.net] そうかrustじゃなきゃヤだったか、残念だ rustに限らず新進の言語は自分が早い、と言い張ってるが inlineとかconstexprとか、そういう言語仕様レベルでC/C++には負けそう スクリプト言語よりは早いし、C/C++にない言語特性で勝ってるから良いんだけど 385 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 08:20:01.82 ID:8DhgL6X2.net] どうせバックエンドはLLVMだし、速度はなんとでもなりそう inline指定はC++より細かくできるし そのうちconst関数も実装されるんじゃなかったっけ 386 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 08:36:32.05 ID:+/xffdWO.net] 魔法の言葉、LLVM LLVMを使ってれば全てが横並びになる、、、わけがねーだろ 387 名前：デフォルトの名無しさん [2015/08/14(金) 13:18:33.36 ID:MLcHO6rW.net] CはともかくC++書きたくないからRustに期待するので… GCないし言語仕様自体で遅くなるということはない 現状でも遅くないし、最適化はコンパイラの成熟待ち 388 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 13:23:40.07 ID:ySA2YUfa.net] cppとかもうオワコンだろ 389 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 13:46:27.32 ID:G+XHrt0h.net] だったらrustがzero-costを推してるのは、、、 雨後のたけのこよろしく言語乱立なう 枯れるまでC++は良い言語の一つだと思うよ 390 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 17:04:46.99 ID:mJ5T1H4E.net] 最適化といってもコンパイラができる最適化には限りがあるよ。 例えばサイズnのスライスに対してある特定の処理を書くとしたら、 slice.iter().map(|x| { f(x) }) とか書くじゃん。遅延処理になるから、その後枝刈りができる可能性はあるけど、基本的にn回処理しなきゃならない。 頭のおかしい人が&[u8]とf(x)の中身を見て、&[u64]にしてf(x)を変形させて処理がn/8回で済むアルゴリズムを考えたとき、 そいつをコンパイラに伝える方法があるようには思えない。特にf(x)の中身を見ないといけない部分が難しい。 rustでスマートに書けるところは多いけど、速度が問題になるジャンルでは簡潔さを捨てても取るべきものがある、と思う。 391 名前：デフォルトの名無しさん [2015/08/14(金) 17:18:09.99 ID:MLcHO6rW.net] そりゃアルゴリズム変えるなら別の書き方することになるってだけでは… RustはCとのインターフェイスが簡潔なのがよい ほんとC++さっさと滅ばねーかなー 392 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 18:56:03.00 ID:tSzJ9MLR.net] ちゃんと読んでないけど、アルゴリズムの書き方が言語仕様で縛られるのでは？ C++を滅ぼそうとDだのC#だの出たけど倒れる気配ないからなぁ 時代は変わったけど難しいね 393 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 20:22:55.00 ID:N/BdRhBJ.net] 滅びを願う必要ないでしょうに 394 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 23:57:05.10 ID:bS+eLMvH.net] >>390 f(x)がinline化可能なら、コンパイラがそういう最適化できる可能性もあるのでは？ ただ、最適化突き詰めていくと今のところ人の手でしかできないようなものがあるというのはその通りだと思う 395 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 11:29:55.30 ID:LE4LycT3.net] >>392 C#はc++滅ぼすためにでたんか VM上で動く言語がc++の替わりになるとは思えんけど 396 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 15:00:25.90 ID:BF06i3ZJ.net] C#の4つの+の内2つは†だからね 397 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 16:30:24.95 ID:2bLrWO8C.net] c♯はvm言語だけどjavaとは比較にならないくらい速いぞ 398 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 19:21:36.26 ID:y8T1xilv.net] rustのC/C++にない機能特徴ってメモリ管理以外何かある？ 文法はどーでもいいので、機能面でメリットがあれば教えて頂きたく 399 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 19:44:13.49 ID:b89uyLUZ.net] バックエンドがLLVMということは、裏返せばLLVMにできないことはどう頑張ってもできなくて LLVMを使いこなすという点ではclangの方がずっとこなれている、ということでもあるからなあ clangだと独自拡張やビルトインを駆使してめっさ面倒なことがrustでこんなに簡単に！はあっても clangでできないことがrustならできる、は無いだろ 400 名前：デフォルトの名無しさん [2015/08/16(日) 00:02:58.53 ID:0FrBGB/k.net] >>398 代数的データ型があること 401 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 08:54:35.06 ID:B/eZX+WT.net] 機能なのかね、関数型(笑)の特徴ではあれど文法の話な気が zero-cost abstractionsってサイトのトップで言ってるけど C++のvisual関数と違って、rust traitの抽象化はオーバーヘッドが少ない(もしくはゼロ)、、、？ 402 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 15:52:42.12 ID:LltgmYR9.net] 言語の機能と文法はどう区別するべきか 言語の型システムに影響与えるものは機能に分類されると思う rustのメモリ管理も型レベルで整合性判定しとるらしいし その話は置いといてメモリ管理以外にも色んなファイルやソケットみたいなリソース管理 もやってくれるって宣伝しとる 403 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 17:33:48.92 ID:mucOKkH4.net] >>399 最後の文、なんかおかしくね？ 404 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 17:37:02.87 ID:P0XQ+1Fa.net] Rustのtraitは&TとかBox<T>とかって形以外で使う分には完全にゼロコスト。C++のtemplateと一緒 405 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 19:29:02.58 ID:y6uPjVhI.net] visual 関数… 406 名前：デフォルトの名無しさん [2015/08/16(日) 20:25:28.98 ID:kniDeEJc.net] >>401 ADTのない言語でパーザやコンパイラなんか絶対に書きたくない 407 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 20:32:14.50 ID:+yYCxpZd.net] >>404 C++のvirtual関数だって静的に解決できる範囲だと普通の関数呼び出しだぞ 結局、必要なとこではやっぱりコストがかかりますという当たり前の話でしかない 408 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 20:45:48.84 ID:MwsW2pbd.net] >>402 プログラマじゃなくユーザにメリットある影響なら機能的な意味と見なしたいな メモリやリソースは解放漏れでユーザに悪影響出るが、代数的データ型は影響無さそう 型情報を納めるためのメタデータが必要で (極少量とは言え)性能が落ちるならカティンとくるがまさかそんなこともあるまい 409 名前：デフォルトの名無しさん [2015/08/16(日) 20:54:28.62 ID:kniDeEJc.net] >>408 >型情報を納めるためのメタデータが必要で >(極少量とは言え)性能が落ちるならカティンとくるが 頭おかしい 410 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:05:51.13 ID:+yYCxpZd.net] ユーザへのメリットというなら、まずライブラリの形式がrlibとか特殊入ってる時点で…… もちろんVM言語よりは遥かにましだけど 411 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:06:48.25 ID:ffOxBAui.net] >>406 君が出来なくても賢い人が作ってくれるとからどうでもいいな >>407 原則、静的解決出来ないことがない言語仕様が差別化なのかねぇ これに限らず、ブレを許す気がないコンパイラなのが愉快 412 名前：デフォルトの名無しさん [2015/08/16(日) 21:10:29.90 ID:kniDeEJc.net] >>411 >君が出来なくても賢い人が作ってくれるとからどうでもいいな コンパイラもパーザもそういうもんじゃないんだけど…… まあ、環境の違いかな 413 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:16:25.34 ID:+yYCxpZd.net] >>411 『&TとかBox<T>とかって形以外は』の部分はどこ行った 414 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:16:51.88 ID:YpDp9c6J.net] >>410 一応、普通のstatic, shared libraryにも変換出来るし、、、 (付与されるランタイムのオーバーヘッドがC++のソレとどの程度違うかは知らん) 415 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 23:08:36.25 ID:jt+RDWuc.net] Ownership と Borrowing はなんとか付いていけたけど Lifetimes は，なにがしたいのかすら解らない...ｼｮﾎﾞﾝ 416 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 23:17:23.38 ID:rxm0/YIk.net] trait objectとそれ以外が陽に異なるから、オーバーヘッドの有無が分かりやすくていい。 C++に無さそうなのって、Phantom型とか？ ADTもパターンマッチをバリバリ使うのに必要な機能。 見た目enumなのがC,C++のenumと混同しちゃうかもしれんが、あれとは安全性のレベルが違う。 417 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 23:39:45.12 ID:t+fZbGif.net] C++にPhantomタイプがない・・・？ それともRustのは別のものを示す語彙なのか？ 418 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 01:03:54.38 ID:wXUvnq59.net] 急に人増えたけどなんかあった？ 419 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 08:15:46.05 ID:EwR31uEA.net] 実は増えてないとか？ 420 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 09:22:50.55 ID:++j4diFB.net] >>413 &TやBox<T>多用するのはイクナイrustプログラムの可能性が微レ存？ 421 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 09:33:55.34 ID:Fu9VunjR.net] RustとSwiftはそっくりなんだから統合しちゃえばいいのにな

---

---

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

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