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で何作ってるんですか？
369:デフォルトの名無しさん
15/07/23 22:42:51.27 GSXYPmA+.net
>>368
まあ、昔と違ってシステムプログラミングの需要って減ってるよね。
GTKかwxWidgetsのRustバインディングが安定したら何作るか考えるわ。
370:デフォルトの名無しさん
15/07/23 22:49:25.52 yXyFyEpk.net
>>367
みなさなきゃ良いんじゃね
rustのトレイトの問題じゃなくお前さんの視点の問題だろ？
Cで作るようなシステムアプリケーションとか作ってる
基本評判悪いけど面白い言語よのう
371:デフォルトの名無しさん
15/07/24 00:32:36.11 D0ziIpoZ.net
>>367 phpでやってみたが、減らせるコードって36-39行と47-50行だけしかなくね？ URLﾘﾝｸ(codepad.viper-7.com)
しかも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:デフォルトの名無しさん
15/08/08 02:29:33.62 qRv1Q/E9.net
普段ScalaとPlayFrameworkでWeb書いてるんやが、JVM嫌すぎてやめたい。
Rustさんはどうなんすかね。
373:デフォルトの名無しさん
15/08/08 02:34:13.24 6f0NYoQy.net
Announcing Rust 1.2
URLﾘﾝｸ(blog.rust-lang.org)
374:デフォルトの名無しさん
15/08/08 11:31:29.07 vDqHzBe+.net
>>372
JVMの何が気に入らないのか分からんが
マルチコアプロセッサで効率的な動作を期待するならgoの方が向いてる
375:デフォルトの名無しさん
15/08/09 03:37:11.08 f9auPRN7.net
Rust1.2に付随してcargoのバージョンが上がってプロジェクトディレクトリの.cargo/configで
[build]
rustc = "multirust run nightly rustc"
とチャンネルを指定することができるようになったのが嬉しい。
前からcrates.ioのドキュメントにできると書いてあったのに、stableじゃできなかった。
3つもチャンネルがあるとドキュメントがいつから対応しているのか書く側も把握しづらいのかね。
376:デフォルトの名無しさん
15/08/12 01:45:21.38 7PEu3mkB.net
>>375
できなかった。自分でrust-nightlyとか適当なシェルスクリプトかまさないといけない。
377:デフォルトの名無しさん
15/08/12 12:36:33.87 0A5qnrPY.net
>>374
ただの技量不足なんですが、メモリ食っちゃうので…
378:デフォルトの名無しさん
15/08/12 15:02:52.00 rodoarXT.net
そりゃgoを使っても本質的には変わらんなw
rustでビルド時に厳密にチェックするのは一案かもな
最初は厳密すぎて実装効率がクッソ下がる悪夢にうなされるだろうけど
379:デフォルトの名無しさん
15/08/13 21:19:32.57 gZkyyADQ.net
rustで、機械学習やりたいんですが線形代数とかに便利なライブラリってあります？
380:デフォルトの名無しさん
15/08/13 21:32:20.79 PzFzu2cW.net
基本的なライブラリも出揃ってないんだからないでしょ。
まぁ速くて関数型だから機械学習に使いたいのは分かるけど
381:デフォルトの名無しさん
15/08/13 22:24:22.09 YKJt+Rxb.net
普通にC/C++ライブラリをブリッジしてフロントをrustで書けば良いのでは
ブラックボックスのライブラリまで無駄にrustランタイムに依存しなくて良いだろう
関数型だから(笑)で選んだなら全てがrustじゃないと気に入らないかもだが
そうじゃないと思いたい
382:デフォルトの名無しさん
15/08/13 23:14:36.16 nvcb5WnS.net
C、C++で書かれたライブラリは予想外な最適化がなされていることがあるのではないか、と
URLﾘﾝｸ(github.com)
のベンチマークを見て、
URLﾘﾝｸ(code.metager.de)
を覗いて思った。
383:デフォルトの名無しさん
15/08/14 06:56:14.33 blwavvg/.net
>>381
単純にrustに触るモチベーションにしようかと思っただけなんですが、
結局c++とかさわることになるなら、もうちょっとまってみます。
384:デフォルトの名無しさん
15/08/14 07:57:50.79 OFjX8KNn.net
そうかrustじゃなきゃヤだったか、残念だ
rustに限らず新進の言語は自分が早い、と言い張ってるが
inlineとかconstexprとか、そういう言語仕様レベルでC/C++には負けそう
スクリプト言語よりは早いし、C/C++にない言語特性で勝ってるから良いんだけど
385:デフォルトの名無しさん
15/08/14 08:20:01.82 8DhgL6X2.net
どうせバックエンドはLLVMだし、速度はなんとでもなりそう
inline指定はC++より細かくできるし
そのうちconst関数も実装されるんじゃなかったっけ
386:デフォルトの名無しさん
15/08/14 08:36:32.05 +/xffdWO.net
魔法の言葉、LLVM
LLVMを使ってれば全てが横並びになる、、、わけがねーだろ
387:デフォルトの名無しさん
15/08/14 13:18:33.36 MLcHO6rW.net
CはともかくC++書きたくないからRustに期待するので…
GCないし言語仕様自体で遅くなるということはない
現状でも遅くないし、最適化はコンパイラの成熟待ち
388:デフォルトの名無しさん
15/08/14 13:23:40.07 ySA2YUfa.net
cppとかもうオワコンだろ
389:デフォルトの名無しさん
15/08/14 13:46:27.32 G+XHrt0h.net
だったらrustがzero-costを推してるのは、、、
雨後のたけのこよろしく言語乱立なう
枯れるまでC++は良い言語の一つだと思うよ
390:デフォルトの名無しさん
15/08/14 17:04:46.99 mJ5T1H4E.net
最適化といってもコンパイラができる最適化には限りがあるよ。
例えばサイズnのスライスに対してある特定の処理を書くとしたら、
slice.iter().map(|x| { f(x) }) とか書くじゃん。遅延処理になるから、その後枝刈りができる可能性はあるけど、基本的にn回処理しなきゃならない。
頭のおかしい人が&[u8]とf(x)の中身を見て、&[u64]にしてf(x)を変形させて処理がn/8回で済むアルゴリズムを考えたとき、
そいつをコンパイラに伝える方法があるようには思えない。特にf(x)の中身を見ないといけない部分が難しい。
rustでスマートに書けるところは多いけど、速度が問題になるジャンルでは簡潔さを捨てても取るべきものがある、と思う。
391:デフォルトの名無しさん
15/08/14 17:18:09.99 MLcHO6rW.net
そりゃアルゴリズム変えるなら別の書き方することになるってだけでは…
RustはCとのインターフェイスが簡潔なのがよい
ほんとC++さっさと滅ばねーかなー
392:デフォルトの名無しさん
15/08/14 18:56:03.00 tSzJ9MLR.net
ちゃんと読んでないけど、アルゴリズムの書き方が言語仕様で縛られるのでは？
C++を滅ぼそうとDだのC#だの出たけど倒れる気配ないからなぁ
時代は変わったけど難しいね
393:デフォルトの名無しさん
15/08/14 20:22:55.00 N/BdRhBJ.net
滅びを願う必要ないでしょうに
394:デフォルトの名無しさん
15/08/14 23:57:05.10 bS+eLMvH.net
>>390
f(x)がinline化可能なら、コンパイラがそういう最適化できる可能性もあるのでは？
ただ、最適化突き詰めていくと今のところ人の手でしかできないようなものがあるというのはその通りだと思う
395:デフォルトの名無しさん
15/08/15 11:29:55.30 LE4LycT3.net
>>392
C#はc++滅ぼすためにでたんか
VM上で動く言語がc++の替わりになるとは思えんけど
396:デフォルトの名無しさん
15/08/15 15:00:25.90 BF06i3ZJ.net
C#の4つの+の内2つは†だからね
397:デフォルトの名無しさん
15/08/15 16:30:24.95 2bLrWO8C.net
c♯はvm言語だけどjavaとは比較にならないくらい速いぞ
398:デフォルトの名無しさん
15/08/15 19:21:36.26 y8T1xilv.net
rustのC/C++にない機能特徴ってメモリ管理以外何かある？
文法はどーでもいいので、機能面でメリットがあれば教えて頂きたく
399:デフォルトの名無しさん
15/08/15 19:44:13.49 b89uyLUZ.net
バックエンドがLLVMということは、裏返せばLLVMにできないことはどう頑張ってもできなくて
LLVMを使いこなすという点ではclangの方がずっとこなれている、ということでもあるからなあ
clangだと独自拡張やビルトインを駆使してめっさ面倒なことがrustでこんなに簡単に！はあっても
clangでできないことがrustならできる、は無いだろ
400:デフォルトの名無しさん
15/08/16 00:02:58.53 0FrBGB/k.net
>>398
代数的データ型があること
401:デフォルトの名無しさん
15/08/16 08:54:35.06 B/eZX+WT.net
機能なのかね、関数型(笑)の特徴ではあれど文法の話な気が
zero-cost abstractionsってサイトのトップで言ってるけど
C++のvisual関数と違って、rust traitの抽象化はオーバーヘッドが少ない(もしくはゼロ)、、、？
402:デフォルトの名無しさん
15/08/16 15:52:42.12 LltgmYR9.net
言語の機能と文法はどう区別するべきか
言語の型システムに影響与えるものは機能に分類されると思う
rustのメモリ管理も型レベルで整合性判定しとるらしいし
その話は置いといてメモリ管理以外にも色んなファイルやソケットみたいなリソース管理
もやってくれるって宣伝しとる
403:デフォルトの名無しさん
15/08/16 17:33:48.92 mucOKkH4.net
>>399
最後の文、なんかおかしくね？
404:デフォルトの名無しさん
15/08/16 17:37:02.87 P0XQ+1Fa.net
Rustのtraitは&TとかBox<T>とかって形以外で使う分には完全にゼロコスト。C++のtemplateと一緒
405:デフォルトの名無しさん
15/08/16 19:29:02.58 y6uPjVhI.net
visual 関数…
406:デフォルトの名無しさん
15/08/16 20:25:28.98 kniDeEJc.net
>>401
ADTのない言語でパーザやコンパイラなんか絶対に書きたくない
407:デフォルトの名無しさん
15/08/16 20:32:14.50 +yYCxpZd.net
>>404
C++のvirtual関数だって静的に解決できる範囲だと普通の関数呼び出しだぞ
結局、必要なとこではやっぱりコストがかかりますという当たり前の話でしかない
408:デフォルトの名無しさん
15/08/16 20:45:48.84 MwsW2pbd.net
>>402
プログラマじゃなくユーザにメリットある影響なら機能的な意味と見なしたいな
メモリやリソースは解放漏れでユーザに悪影響出るが、代数的データ型は影響無さそう
型情報を納めるためのメタデータが必要で
(極少量とは言え)性能が落ちるならカティンとくるがまさかそんなこともあるまい
409:デフォルトの名無しさん
15/08/16 20:54:28.62 kniDeEJc.net
>>408
>型情報を納めるためのメタデータが必要で
>(極少量とは言え)性能が落ちるならカティンとくるが
頭おかしい
410:デフォルトの名無しさん
15/08/16 21:05:51.13 +yYCxpZd.net
ユーザへのメリットというなら、まずライブラリの形式がrlibとか特殊入ってる時点で……
もちろんVM言語よりは遥かにましだけど
411:デフォルトの名無しさん
15/08/16 21:06:48.25 ffOxBAui.net
>>406
君が出来なくても賢い人が作ってくれるとからどうでもいいな
>>407
原則、静的解決出来ないことがない言語仕様が差別化なのかねぇ
これに限らず、ブレを許す気がないコンパイラなのが愉快
412:デフォルトの名無しさん
15/08/16 21:10:29.90 kniDeEJc.net
>>411
>君が出来なくても賢い人が作ってくれるとからどうでもいいな
コンパイラもパーザもそういうもんじゃないんだけど……
まあ、環境の違いかな
413:デフォルトの名無しさん
15/08/16 21:16:25.34 +yYCxpZd.net
>>411
『&TとかBox<T>とかって形以外は』の部分はどこ行った
414:デフォルトの名無しさん
15/08/16 21:16:51.88 YpDp9c6J.net
>>410
一応、普通のstatic, shared libraryにも変換出来るし、、、
(付与されるランタイムのオーバーヘッドがC++のソレとどの程度違うかは知らん)
415:デフォルトの名無しさん
15/08/16 23:08:36.25 jt+RDWuc.net
Ownership と Borrowing はなんとか付いていけたけど
Lifetimes は，なにがしたいのかすら解らない...ｼｮﾎﾞﾝ
416:デフォルトの名無しさん
15/08/16 23:17:23.38 rxm0/YIk.net
trait objectとそれ以外が陽に異なるから、オーバーヘッドの有無が分かりやすくていい。
C++に無さそうなのって、Phantom型とか？
ADTもパターンマッチをバリバリ使うのに必要な機能。
見た目enumなのがC,C++のenumと混同しちゃうかもしれんが、あれとは安全性のレベルが違う。
417:デフォルトの名無しさん
15/08/16 23:39:45.12 t+fZbGif.net
C++にPhantomタイプがない・・・？
それともRustのは別のものを示す語彙なのか？
418:デフォルトの名無しさん
15/08/17 01:03:54.38 wXUvnq59.net
急に人増えたけどなんかあった？
419:デフォルトの名無しさん
15/08/17 08:15:46.05 EwR31uEA.net
実は増えてないとか？
420:デフォルトの名無しさん
15/08/17 09:22:50.55 ++j4diFB.net
>>413
&TやBox<T>多用するのはイクナイrustプログラムの可能性が微レ存？
421:デフォルトの名無しさん
15/08/17 09:33:55.34 Fu9VunjR.net
RustとSwiftはそっくりなんだから統合しちゃえばいいのにな
422:デフォルトの名無しさん
15/08/17 09:50:54.17 S2KJYKrv.net
そっくりか、心が広いな
423:デフォルトの名無しさん
15/08/17 10:12:49.16 OjKjgwDq.net
rustもswiftもgoも好きで使ってるけどswiftはgoと統合して欲しい
gc以外は感情論を持ち込まなければなんとかなりそう
rustは不毛な大地を一人でどうぞ(好意的な意味で
424:デフォルトの名無しさん
15/08/17 22:06:52.82 qu3dwpPf.net
>>423
swiftとgoを統合の意味がぜんぜんわからないな。
goにGenericsが入ってほしいという話ならわからなくもないけど。
swiftはCocoaライブラリの互換性に縛られて言語仕様として洗練されてない。
goはシンプルを極めすぎて、Genericsとか入れてくれない予感。
rustはLLVMのフロントエンドってところでマルチプラットフォームな言語として一番期待できるよね。(swiftはCocoaがない環境で息できないでしょ)
UE4でC++の代わりにrustを使えないかと妄想してます。
425:デフォルトの名無しさん
15/08/17 22:34:16.53 XjHdii/s.net
swiftの文法とgoの機能が合わさり最強に見える
rustは言語仕様と標準ライブラリが安定してユーザが定住するならなぁ
ユーザ数少ないのにマルチプラットフォームとか誰得だ
特色違えど言ってることがLuaと変わらんので笑える
426:デフォルトの名無しさん
15/08/17 23:35:52.17 rr3yinc6.net
swiftが底センスなのって互換性が原因かなあ
単純に設計者が(ry
427:デフォルトの名無しさん
15/08/18 03:11:58.06 1Gz3JsMv.net
言語設計したAppleを責めるのはヤメロ
>>424
UE4って組み込み環境じゃなくゲームランタイムか
UE4知らんけどstatic library食えるならrustもいけるんじゃね
クロスコンパイラのrustc,cargo作れば良いわけだろ
428:デフォルトの名無しさん
15/08/18 11:59:33.30 6CH1l8he.net
swiftはアップデートするたびにcppに近づいてるな（悪い意味で）
429:デフォルトの名無しさん
15/08/20 15:10:15.72 JJlPzozZ.net
replか、rustの機能に合わせたスクリプト言語、あるいはコンパイラにキャッシュが欲しいです。
crateはコンパイル単位としてはでかすぎて開発サイクルが落ちまくるわ。
430:デフォルトの名無しさん
15/08/20 19:05:12.42 lKgof8/J.net
富豪プログラマ乙
環境一式が提供されれば便利だけど、ないならないなりに自前で便利な環境作れば良いと思うよ
431:デフォルトの名無しさん
15/08/20 20:23:20.16 TcFY2I1R.net
>>429
URLﾘﾝｸ(github.com)
432:デフォルトの名無しさん
15/08/20 20:47:55.40 5WCLlVT0.net
REPL使えるのはありがたいなあ
433:デフォルトの名無しさん
15/08/21 21:43:41.45 JyBfu5gS.net
>>430
富豪じゃないって話だろ？
434:デフォルトの名無しさん
15/08/22 10:13:08.54 EXDgxhBq.net
言語は富豪じゃなく、プログラマが富豪感覚って話だろ？
昔、Pythonをログインシェルにする機構があったが
Rustをログインシェルにする強者は世の中にいるかね
435:デフォルトの名無しさん
15/08/23 10:35:52.76 Gi1OdVG4.net
自前で便利な環境ってどんなの？cargoのソースを少し弄っては動かして、ってのをやろうとしたことがあるけど、
自分のPCだと再コンパイルに何分もかかって苦痛の極みだった。
printデバッグはcrateがある程度大きいと役に立たない。
rust-gdbを使ったものの、メソッドをどう呼べばいいのか分からなくて難儀した。
最終的に特定した不具合はrust-1.1のstableで配布されていたcargoのバージョンが古すぎて
crates.ioのドキュメントにある機能が実装されてなかっただけだったんだけどね。徒労でした。
436:デフォルトの名無しさん
15/08/23 10:49:21.79 DVHNG28Q.net
rustを使わなくて良いと判断することが良い環境じゃないかな
コンパイラ、デバッガ、ライブラリ管理、IDEをMozillaが綺麗に整備する気ないから
他の流行りの言語に比べて環境は人によってマチマチになるのが必然で問われても最適解はないよ
低レイヤーかつメモリ、リソース管理が楽なrustだけど開発環境は中々に不毛だと思う
オールインワンな用意されたモノが良いならswiftが最強、アポーOS内なら文句出ない
437:デフォルトの名無しさん
15/08/23 14:11:14.16 2b/ywy3L.net
静的型付けでIDE使えないとかなんの罰ゲームだ
438:デフォルトの名無しさん
15/08/23 14:36:11.06 myL1fwDZ.net
インクリメンタルなコンパイルもIDEに情報渡すためのコンパイラ側のサポートも
わりと優先度の高い開発目標になってて実際に着手してるから時間の問題
439:デフォルトの名無しさん
15/08/23 14:49:20.21 DiK7bPRN.net
型推論と静的型付けを混在してんのか？
静的型付けならC言語すらそうなわけだが
百歩譲って静的型付け+型推論としてもC++11が標準IDEなしで頑張っとる
emacsでもvimでもsublimeでもAtomでも好きなIDE(エディタ)使えよ
自分で選べず罰ゲームだと思うなら、まだ早い
440:デフォルトの名無しさん
15/08/23 15:29:12.91 vCSJ96fF.net
最強ideとして名高いintellij様がその内rustも対応するだろ（鼻ほじ）
441:デフォルトの名無しさん
15/08/23 17:12:50.17 kGlhzngs.net
>>439
誰も型推論の話はしてなくね？
実際cやらcppでインライン構文チェック、補完できるエディタなんて普通にだろうし
442:デフォルトの名無しさん
15/08/23 19:11:10.03 myL1fwDZ.net
>>441
とはいえ、Rustのように型推論がある言語だとコンパイラが型推論した
結果をIDEに伝えてくれないとマトモな補完はできないので。
パーザと型検査機・型推論機に特化したツールを用意するか、
コンパイラが型推論の結果を別ファイル化なんかで伝達するかしないといけない
443:デフォルトの名無しさん
15/08/23 19:26:43.38 /Chtfvs+.net
>>442
rebuildfmでtypescriptがIDE用にアノテーション情報をコンパイラが提供してると聞いた。
golangは言語としては提供してないけどgocodeってツールがそういう役割してる。
rustは今のところない感じ？
444:デフォルトの名無しさん
15/08/23 20:29:46.00 TP37Tp0e.net
racerとかいう補完ツールがあるけど、中身がどうなってるかは知らない
445:デフォルトの名無しさん
15/08/29 11:33:37.99 LydH6mPU.net
ctags程度のインデックスファイル作成かな > racer
型推論した上で、その型がどんな名前のメンバ変数/関数が扱えるのかまでは補完してくれなさそう
>>441
型推論込みでコード補完してくれるIDEがないと罰ゲームだって話だろ、多分
446:デフォルトの名無しさん
15/08/29 14:35:52.72 ILt1JEYe.net
変数に別名を与える構文とか出来ないかな
refだと所有権の貸し借りが発生するせいで気軽に使えないからね
同じ変数に対して複数の名前で同時に読み書き出来る状況になるけど
Rustではそういうのもデータレースと見なすのだろうか
447:デフォルトの名無しさん
15/08/29 14:44:45.63 h1iic6zY.net
それがメモリ管理のバグを生むから許せねーってのがrustの理念だろうよ
多用するもんじゃないだろうけどArcとか使えば良いんじゃね
448:デフォルトの名無しさん
15/08/29 15:27:58.89 hP/roqxQ.net
ML系みたいに型の構文を関数定義から分離して欲しい…
少し複雑になると読みにくくてかなわん…
449:デフォルトの名無しさん
15/08/29 16:06:46.95 PwA9Vh//.net
ML系統も変数:型だけど、valに相当する構文を入れて、定義の所では省略したいってこと？
val foo : i32 -> i32;
fn foo(n) { n * 2 }
個人的には賛成。
多相型に対してimplを書くとimpl<'a, T1, T2, ...>が続いて読みにくくなるのも何とかならんかな。
punningというか、同じ文字を使っているなら省略してもオッケーみたいな。
450:デフォルトの名無しさん
15/08/29 16:42:49.79 vqRxT/fZ.net
>>446
他の言語ならあるの？
451:デフォルトの名無しさん
15/08/29 17:10:08.52 hP/roqxQ.net
>>449
そうそう。定義内に入ってると読みにくくて読みにくくて…
452:デフォルトの名無しさん
15/08/29 17:27:04.02 r87Lb3Gh.net
>>450
Cのポインタで出来るんじゃない？
>>449
タイプ数、ライン数を増やさんで欲しいな
今の仕様に追加なら見て見ぬふりしよう
453:デフォルトの名無しさん
15/08/29 17:36:28.28 vqRxT/fZ.net
>>452
それだと本質はrefと変わらなくね？
454:デフォルトの名無しさん
15/08/29 17:51:33.64 sBKhQngs.net
>>450
Cならunion、Pascalならabsoluteがあるよ
455:デフォルトの名無しさん
15/08/29 18:24:22.69 u5YtsQ0V.net
単に長い名前を一時的に短い名前にしたいだけだろ
Dのaliasみたいな
unionやabsoluteは別の型でオーバレイするので用途が違う
456:デフォルトの名無しさん
15/08/29 19:18:35.10 x4JINQUQ.net
Cならcpp経由の#defineか
rustでもrustcかける前にcppかまそう
457:444
15/08/29 21:38:49.53 ILt1JEYe.net
すまん言葉足らずだった
>>446は>>455の言うように長い変数名を短くするような使い方を想定していた
>>456のやり方みたいにコンパイル前に名前を置き換えるだけでもいけるから
データレースは起きないと思ったんだ
他の言語だと所有権のチェックが無いからrefのような参照変数で十分代用できる
458:デフォルトの名無しさん
15/08/30 07:01:42.91 HJK6L9Ls.net
そういう無駄な他言語仕様の取り込みは要らない
一見変数名が短くなって特定箇所はシンプルに見えるが
全体のコードからすれば簡素にするではなく、複雑にするだろ
459:デフォルトの名無しさん
15/08/30 07:12:12.11 9R41/ZIA.net
まあまあ
今はいらんかもしれんけど、本格的にいろんな環境で使われだして環境差を吸収しないといけないとなってくると
そういう機能も必要になってくるよ
他言語にある機能だって無駄に存在してる訳じゃないからな
460:デフォルトの名無しさん
15/08/31 11:07:32.54 tdAWRFGn.net
長い変数名ってjavaのメンバ変数みたいな？
想定しているコードがよく分からん。aliasと元の変数が同時に出てくるコードの可読性は低くないか？
自分だったら↓みたいに元の変数からmoveさせて処理した後に元に戻すようにすると思う。
#[derive(Debug)]
struct Foo {
x: i32,
y: i32
}
#[derive(Debug)]
struct Bar {
verylong_named_variable_which_will_be_moved : Foo
}
fn main() {
let mut bar = Bar { verylong_named_variable_which_will_be_moved: Foo { x: 100, y: 200 } };
let mut a = bar.verylong_named_variable_which_will_be_moved;
a.x = 10;
a.y = 20;
bar.verylong_named_variable_which_will_be_moved = a;
println!("bar = {:?}", bar);
}
461:デフォルトの名無しさん
15/08/31 13:07:11.54 yj9JwLwE.net
444の意図とは逸れるかもしれないけど
例えばerrnoなら実際はerrnoだったり_errnoだったり__errorだったり
environならenvironだったり__environだったり*(NSGetEnviron())だったりする
stdinだったら__stdinpだったり__sF[0]だったり(&__iob_func()[0])だったり……
それがヘッダファイル中で#defineされているから、C言語からはどの環境でも同じ名前で使えるわけだ
今は処理系もひとつで動く環境も限られているから表面化しないかもしれないけど
普及と同時に差も広がっていく中で #[cfg(〜)] 使って全ての環境分書き分けろってなったらやってられんと思う
……というつもりだったのが>>459
462:デフォルトの名無しさん
15/08/31 13:48:51.45 gJdrS6xb.net
まあ、低レベル言語でどこまでの抽象化を許すかは難しいよな
463:デフォルトの名無しさん
15/08/31 15:10:03.72 Dkk0mMpb.net
Cでは#define, ifdef使う所を、rustでは#cfg使うのがrustの出した解決策なんじゃなかろうか
464:デフォルトの名無しさん
15/09/01 13:12:24.79 Qh110XSL.net
#cfg濫用は心配することないと思うけどな。
現在でもwinとlinuxとOSXがサポート対象だけど、環境の違いを陽に扱うコード以外は#cfg使って書き分けるなんてやってない。
Cでは抽象化の手段が少ないからプリプロセッサ使わないとやってられないが、
rustならトレイトとかコンテナ型を使って、ゼロコストで環境の違いを吸収できるのではないだろうか。
465:デフォルトの名無しさん
15/09/04 19:40:34.17 PM7GVPA4.net
iOSとAndroidと、それらの各種CPUを対応しててくれてありがたいんだが、libcの#cfgがバグってて悲しい
rust/src/libcは直ってるようなので、gitのリビジョン参照の更新待ちだい
466:デフォルトの名無しさん
15/09/18 08:13:22.55 qEC88fFW.net
1.3来てるぞ
467:デフォルトの名無しさん
15/09/18 10:09:51.13 qiV5MD3f.net
Release Notes v1.3.0
URLﾘﾝｸ(github.com)
468:デフォルトの名無しさん
15/09/23 23:21:07.14 IGgDNXyV.net
メソッドをオーバーロードするのにトレイト組み合わせなきゃならんのは何で？
オペレータのオーバーロードと方法を合わせるためなんか？
469:デフォルトの名無しさん
15/09/24 00:52:09.13 lP9arsTC.net
型推論が面倒になるからじゃない？
仮にオーバーロードができたとして、2つのメソッドdo_somethingがそれぞれAsRef<str>と&Stringを引数として渡せるとしたら、
let bar = "abcde".to_string();
foo.do_something(&bar)とやったとき、どっちのdo_somethingを呼ぶべきか分からない。
470:デフォルトの名無しさん
15/09/25 18:26:11.73 R+TRhKVr.net
try! が使えなくなってるような
471:デフォルトの名無しさん
15/10/06 23:08:05.18 GvY89Hx4.net
>>470
使えるよ？
戻り値の型と合ってないとかでは。
472:デフォルトの名無しさん
15/10/30 08:18:22.20 pCPlChjw.net
1.4来た
473:デフォルトの名無しさん
15/10/30 10:46:42.92 IKqzpUXy.net
スタートダッシュはもたついたけど地道に進んでるようだな。
474:デフォルトの名無しさん
15/10/30 22:03:45.74 wx6dAr+H.net
この言語って将来性ある？
軽量タスクをあきらめた時点で多くの期待を裏切った感があるけど
475:デフォルトの名無しさん
15/10/30 23:07:12.55 r01g6EEx.net
裏切られたのお前だけじゃね？
476:デフォルトの名無しさん
15/10/30 23:57:05.43 FTBRryE0.net
ランタイムを持たずに低水準を弄ろうというシステム向け言語で
デフォルトでグリーンスレッドをサポートとかそりゃ無理でしょ
ま、需要があればライブラリで提供されるだろうさ
477:デフォルトの名無しさん
15/10/31 00:17:04.93 qwGp3Rk5.net
scala使っとけよ
いい言語だぞ
478:デフォルトの名無しさん
15/10/31 00:44:50.75 L1WutJvq.net
>>477
何故にそこでscala？
scalaやるくらいならocamlやる。
JVM上でってことならいっそのことclojureやるわ。
479:デフォルトの名無しさん
15/10/31 03:33:05.27 F9rGVxSD.net
476がなぜそんなにscalaを嫌ってるのか少し気になるw
まぁscalaもocamlもclojureもRustからは遠い言語だけど。
480:デフォルトの名無しさん
15/10/31 04:11:48.61 /cAGFdj7.net
嫌ってる訳じゃないだろ。他に良い言語があるのに、ってだけで。
481:476
15/10/31 06:37:08.04 L1WutJvq.net
うんscalaが嫌いってわけじゃない。
ocamlやclojureがもっと良い言語とも言わん。
単に何故にRustのスレでscalaが出るって思っただけ。
482:デフォルトの名無しさん
15/11/07 12:41:15.36 ptDOELGY.net
OCamlがRustから遠い言語だと！letやらOptionやらを見ればOCamlの香りがするだろう！
OCamlの型システムを魔改造して、ガワをC++やJavaにして、ついでにGCも取っ払ったらRustだろうが！
使えば使うほど「OCamlならもっと楽に書けるなーこの式」とか思っちゃうくらいには近いぞ。
というか何故しなかったのか。
パターンマッチのデリミタを|から,にしたり、ジェネリック型の表記をT ListからList<T>にしたり、
式をML系列(foo x y)からalgol系列(foo(x,y))にした理由が未だに分からない。
括弧の量が増えて困る。
483:デフォルトの名無しさん
15/11/07 13:31:16.74 dEyvNDQG.net
そりゃ「から～にした」っていうのが単に480の習得順序なだけだからでしょ。
484:デフォルトの名無しさん
15/11/07 13:32:09.75 7OElurpY.net
ML系列流行らないからじゃない？話はずれるがOCamlも一旦キーワード整理しなおした文法2.0作らないとツギハギちょっとひどい。
485:デフォルトの名無しさん
15/11/07 16:22:53.29 G421Olyl.net
いっそのこと他人との情報交換はASTレベルで取って、構文解析レベルの表面的な文法は各自で着せ替え可能にしてしまえ
486:デフォルトの名無しさん
15/11/07 16:43:13.48 2WRIWoj2.net
OCamlには既に文法2.0も>>485の言う機能も完備されているが、誰も使っていないという事実がある
URLﾘﾝｸ(caml.inria.fr)
487:デフォルトの名無しさん
15/11/07 18:38:30.39 qNyFmib8.net
>>484
> ツギハギちょっとひどい。
たとえばどんなとこが？
> キーワード整理しなおした文法
どこをどういうふうに？
488:デフォルトの名無しさん
15/11/07 22:37:40.80 ptDOELGY.net
OCamlのRevised Syntaxはcamlp4で拡張する用途がメインだし、作った側も推進しているわけじゃない
F#のlightweight syntaxとはちょっと違う。
>>483 いや、色々な言語を触ってはきているけど、ML畑が主では無いよ。
感じるのは、関数型言語で便利だった機能を持ってきているけど、
よく考えてC++やJavaの見た目にしているのかが分からない、引っかかってるだけなんだ。
パターンマッチは、どうしてわざわざ","で区切るのか。orパターンで"|"も使うのに。
match expr {
| p1 | p2 => doA
| p3 => doB
}
の方が、"|"がORの意味を持つという慣習とも意味が合っていい。
今だと、
match expr {
p1 | p2 => doA,
p3 => doB
}
とdoAの後にセミコロンより見えにくい","を打つか、あるいはSQL的に
match expr {
p1 | p2 => doA
, p3 => doB
}
と書くかしないといけない。 どちらも"|"をデリミタにしたときより見づらいと思う。
489:デフォルトの名無しさん
15/11/07 22:50:12.70 Y3AuFW+E.net
構文見た目とか細かいところなんて慣れだろ。
多言語から来たらそこは我慢しないと