次世代言語9[Haskell Rust Kotlin TypeScript Dart]

**デフォルトの名無しさん** · 2018/03/06(火) 10:09:15.60

スレタイ以外の言語もok

前スレ
次世代言語Part8[Haskell Rust Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1512137301/

**デフォルトの名無しさん** · 2018/03/06(火) 10:30:06.56

Dartきてんね

**デフォルトの名無しさん** · 2018/03/06(火) 11:03:49.49

DartとDlangの違いを教えてください

**デフォルトの名無しさん** · 2018/03/06(火) 11:43:03.15

Googleは言語選択保守的すぎるだろ
関数型言語採用しないどころかGolang作っちゃう時点で

**デフォルトの名無しさん** · 2018/03/06(火) 12:27:31.20

Goと関数型は土俵が違わん？

**デフォルトの名無しさん** · 2018/03/06(火) 14:53:26.90

関数型とは具体的に何のことやら
Rustが採用したenumとtraitは関数型か？

**デフォルトの名無しさん** · 2018/03/06(火) 20:42:26.57

>>4
別にそんなとこで冒険しても生産性上がらんよねって感覚なんだろ。

**デフォルトの名無しさん** · 2018/03/06(火) 20:42:29.39

>>6
enum・traitと関数型は関係ないだろ？どちらもHaskellの型システムをパクって来たってだけ
関数型言語の特徴として真っ先に思いつくのは関数を第一級オブジェクトとして扱えるか否かというところだろうな
ただその考え方だけだとC言語でさえ関数ポインタがあるから関数型言語に含まれてしまうことになる
そこからさらに副作用を出来る限り避ける文化があるか否かとかも判断基準になるのかな？
言語の文化とかふんわりした表現は具体性を伴わないから説得力に欠けるんだよな
改めて関数型を具体的に説明しろと言われると難しいな…

**デフォルトの名無しさん** · 2018/03/06(火) 20:57:45.92

>>8
関数ポインタは確かにC/C++系独自だけれども（Javaにはなかった）第一級オブジェクトではない、とおもうよ

**デフォルトの名無しさん** · 2018/03/06(火) 21:32:52.86

もう少しだけ動的に関数定義を変えて返したりできるのが関数型ぽい。

**デフォルトの名無しさん** · 2018/03/06(火) 21:34:37.20

Cの関数は実行時に生成挟めないから第一級オブジェクトではないよ

**デフォルトの名無しさん** · 2018/03/06(火) 21:40:19.40

c++ならクラスのメンバに情報持たせて、メソッド使うことでクロージャぽいものはできるけど。

**デフォルトの名無しさん** · 2018/03/06(火) 21:45:38.71

λ理論を念頭に置いて実装されたかどうかやぞ

**デフォルトの名無しさん** · 2018/03/06(火) 22:00:19.48

c++なら素直にラムダ式使おうよ…

**デフォルトの名無しさん** · 2018/03/06(火) 22:19:34.09

C++ のラムダ式でYコンビネータを記述できるのですか？
できないのならラムダ式などと呼称していいのでしょうか？

**デフォルトの名無しさん** · 2018/03/06(火) 22:36:28.04

>>15
2つの話題を勝手に混ぜるな
>>14 で >>12 に安価付けなかったのは俺が悪いけどさ

実行時の環境を用いた関数定義の有無についてc++ならラムダ式を使おうという話をしているだけだ
しゃーねーだろ言語機能としてラムダ式って命名されてるんだから

関数型言語とはなんぞやという話題についてc++のラムダ式を例に挙げてc++は関数型だ!なんて言うつもりは毛頭ない
Yコンビネータに関しては確かできた気がするが

**デフォルトの名無しさん** · 2018/03/06(火) 22:44:51.87

>>16
正論すぎて草

**デフォルトの名無しさん** · 2018/03/07(水) 00:36:57.39

>>4
goって保守的かな？結構攻めてる言語だと思うが。
swiftのほうが断然保守的。

**デフォルトの名無しさん** · 2018/03/07(水) 00:55:59.65

>>18
保守的にするという意味で攻めてる言語だな

**デフォルトの名無しさん** · 2018/03/07(水) 00:59:12.93

諦めと開き直りを全面に押し出してくる言語だな、確かに。

**デフォルトの名無しさん** · 2018/03/07(水) 01:21:30.28

goの攻めてるところ。
ライブラリのimportにuriを指定してできるようにしてgithubから直接importできるようにした。
例外を辞めた。
公開、非公開をメンバ名が大文字始まりかどうかで決めるように。
クラスをやめて、構造体だけにした。
インターフェース実装は該当メソッドの有無で決定

といった具合に他の言語の当たり前の部分を壊した。全然保守的とは思えないが。

**デフォルトの名無しさん** · 2018/03/07(水) 01:26:49.68

後は未使用ライブラリのimportをコンパイルエラーにするというのも、他の言語であんまり見ない気がする。　

これは、積み重なるとコンパイル時間に影響するから、言語設計にコンパイル時間の考慮を重きにおいている証拠の一つと言える

**デフォルトの名無しさん** · 2018/03/07(水) 01:27:38.81

>>21
例外とか構造体はC時代に逆戻りしてるだけだし、静的ダックタイピングは他の言語にもあるし、githubのurl指定は結局色々な問題起きてるし(この間のgo-bindata騒動とか)、公開/非公開の大文字小文字も気軽に変えられなくて不便だし何のメリットがあるんだ？

**デフォルトの名無しさん** · 2018/03/07(水) 01:28:30.13

>>22
他の言語はエラーにはしないけど警告出す
初期の開発中は未使用importエラーも邪魔なだけでしょ

**デフォルトの名無しさん** · 2018/03/07(水) 01:41:57.73

>>23
むしろ、今まで当たり前にあった言語仕様を振り返って本当に必要かどうかを再検討して
削りに削った仕様だと思うけどな。

c++とか触ってたとき、クラスと、構造体って、本当に両方必要か？どっちか要らないだろって思ってたりしたから、
すごくしっくりきた。

**デフォルトの名無しさん** · 2018/03/07(水) 01:51:00.36

>>24
IDE使ってると半自動だからあんまり面倒だと感じたことはない。警告を無視する開発者もいるから徹底したほうが良いんだろう。
linuxカーネルもコンパイルすると警告出てるし

**デフォルトの名無しさん** · 2018/03/07(水) 01:54:34.87

>>25
構造体とクラスに関しては個人的に同意
ただ型パラメーターとか例外がないのはありえない
エラー処理は長すぎる。if分岐でチェックとかいつの時代だよ
型パラメーターないせいでDRY原則を破るか型安全を破るかしないといけない

**デフォルトの名無しさん** · 2018/03/07(水) 01:56:06.25

>>23
go-bindata騒動はgo固有の問題でもない。nodeだって似たようなことあっただろ。

**デフォルトの名無しさん** · 2018/03/07(水) 02:03:48.32

>>27
例外いるかな？
tryで包まなきゃいけないメソッドや、関数ってドキュメント読むか、実際に実行するまでわかんなくないか？
言語によっては例外が飛ぶ可能性がある関数かどうかわかるんだっけ？
jsはわかんないから不便。

**デフォルトの名無しさん** · 2018/03/07(水) 02:08:04.97

>>27
結局interface{}使うのかよ的なね。わかる。
俺はコード生成に可能性を見出してる。
goはコード生成フレンドリーな言語仕様だし標準ライブラリに、AST系が揃ってるから

**デフォルトの名無しさん** · 2018/03/07(水) 02:19:43.98

>>28
nodeもあったけどnodeの場合はnpmの仕様変えれば解決出来るやん
でもGoはgithubに依存してるから解決不可能じゃん

>>29
それならEither型作ってメソッドチェーンで書けるようにして欲しい
Goのエラー処理は関数呼び出し毎にしないといけないからだるすぎ

>>30
型パラメーターが複雑だから、コンパイル速度に影響出るからって入れなかったのにコード生成しろって矛盾してない？
どっちが複雑だよ。どっちがコンパイル速度に影響出るよ？

**デフォルトの名無しさん** · 2018/03/07(水) 03:07:39.19

>>31
コード生成はプリプロセスとしてコンパイルの度に毎回動かすわけじゃない。stringerとか使ったことない？

inportに関しては、
nodeがnpmの仕様を変えたら解決するならgoもそうすればいいのでは？

現状でも、vendor/もコミット対象にしてしまえば、依存ライブラリを管理対象にできるから

サードパーティライブラリに頼る以上はライブラリ作者の影響をどの言語だって受ける。

**デフォルトの名無しさん** · 2018/03/07(水) 03:12:09.66

Yコンビネータ forall a. (a -> a) -> a のように
forallがつく関数は第一級オブジェクトにならないのが普通だ
総称型がある比較的新しい言語はもう第一級オブジェクトにこだわらない

**デフォルトの名無しさん** · 2018/03/07(水) 04:31:47.78

maybe/eitherが無い言語はあまり触りたくないな

**デフォルトの名無しさん** · 2018/03/07(水) 07:45:36.47

goってなんだかよく使われてる以外の理由で使う理由がないよ
同じことするならrustのがいいわ

**デフォルトの名無しさん** · 2018/03/07(水) 08:21:04.51

Goはマイクロスレッド得意なのはありがたいな。
あとチャンネルと。
そして静的リンクがデフォ。
これだけで、Go使う価値あると思ってる。

**デフォルトの名無しさん** · 2018/03/07(水) 09:16:51.01

>>35
WEBサーバ: go,php,ruby,java,Elixir
IOSアプリ:swift,dart
Androidアプリ:java,kotlin,dart
WEBクライアント:JavaScript,elm,TypeScript
cliツール:go

どこにrustが入る？

**デフォルトの名無しさん** · 2018/03/07(水) 09:50:59.47

Rustは生ポインタが使えるし、C ffiが比較的容易に可能、そのうえwebassemblyにまで対応してる
>>37以外にも組み込み、OS、ドライバ、デスクトップアプリ等どこにでも入ろうと思えば入れる
C++の後継を目指してるだけあってかなり万能な言語ではあるんだが
問題は普及するかどうか…

**デフォルトの名無しさん** · 2018/03/07(水) 10:25:38.57

>>32
goはgithubに依存してるからgithubの仕様変えないと駄目じゃん
具体的にはリポジトリやユーザーの削除禁止。でもそれは無理だろ？

>>32
毎回動かすわけじゃないけど、変更あったら動かすだろ？
しかもそれは他の言語でも差分コンパイルで出来る

**デフォルトの名無しさん** · 2018/03/07(水) 10:51:52.29

>>39
githubが便利だからgithub使ってるけど、別にgithub以外でも公開出来るし、依存してると言うより多くの人間がgithub使ってるだけでは？

**デフォルトの名無しさん** · 2018/03/07(水) 13:02:44.71

プログラマの労力よりコンパイル速度を優先してるのが謎

**デフォルトの名無しさん** · 2018/03/07(水) 13:09:33.87

コンパイル速度が短いとデバッグしやすいからじゃね？

**デフォルトの名無しさん** · 2018/03/07(水) 13:13:30.69

cliツールgoってマジ？

**デフォルトの名無しさん** · 2018/03/07(水) 13:14:29.36

>>38
Rust嫌いじゃないけど普及しないと思う
今年のロードマップもwasmとCLIとNetwork頑張る、っておとなしすぎだろ
いろいろできるならもっとぶっ込んで来いやｺﾞﾙｱってね

**デフォルトの名無しさん** · 2018/03/07(水) 13:19:03.34

Googleが採用しなかったDartよりはMozillaが採用したRustの方が将来性はあると思う

**デフォルトの名無しさん** · 2018/03/07(水) 13:45:40.70

>>37
ウエッブサーバ: rust
他のサーバ: rust
ウエッブクライアント: rust
CLI: rust

**デフォルトの名無しさん** · 2018/03/07(水) 13:53:35.83

>>41-42
その辺の話は
https://talks.golang.org/2012/splash.article
に書いているけど、
Google社内の巨大なソースのコンパイル時間が45分とかかかるようになっちゃって
なんとかしないとという流れで始まったって書いてる。
つまりGoogle以外で恩恵を得る可能性は低いな。

**デフォルトの名無しさん** · 2018/03/07(水) 14:07:05.01

>>46
一応マジメに返しておくと現状webクライアントはrustだけじゃダメだよ
現状ではまだwebassemblyでDOM操作はできないし他にも出来ないことは沢山ある
webクライアントにはRust+JSの組み合わせが必須になる

ただし、Rustのマクロ使ってRustの中にJS書いてビルド時にwasmとJSを両方吐きだして
無理やりRust onlyを実現してるstdwebとかいう先進的？なフレームワークも存在する
あのクレート発見したときは「こいつ天才かよ？」って思った

**デフォルトの名無しさん** · 2018/03/07(水) 14:22:34.19

Rustは気になるけど、さわるモチベーションとなるキッカケがないんだよな。
FirefoxベースのElectronとかでて直接レンダリング部分をrustでいじるようなライブラリがでたら考えるかな

**デフォルトの名無しさん** · 2018/03/07(水) 14:54:16.32

人気が下降しプログラマの求人も少ないプログラミング言語ワースト10は？一方で仕事の多い言語は？ CodementorXとCoding Dojoの調査結果
http://www.publickey1.jp/blog/18/5_codementorxcoding_dojo.html

**デフォルトの名無しさん** · 2018/03/07(水) 15:25:36.37

jsのファミコンエミュを苦労してrust(→webassembly)に書き直してもぜんぜん速くならないという悲しい現実。
ハマるユースケース少なそう。

**デフォルトの名無しさん** · 2018/03/07(水) 16:03:24.12

>>51
憶測でしがないが、それはRustやwasmが遅いというわけではなくて
ファミコン程度の演算ならJSだろうがwasmだろうがパフォーマンス的には大差なくて
それよりもwasmとJSでデータをやり取りする際のコピーのコストが高くついてるんじゃない？
3Dゲームの演算とかもっと重い処理じゃない限りwasmのメリットが活きてこないんじゃ…
もしくは、将来的にwasmから直接DOM操作ができるようになれば…

**デフォルトの名無しさん** · 2018/03/07(水) 16:26:53.26

GoとRustはバランスが悪いんだよな
ラムダ式とかジェネリクスとかGCがあればこそ手軽に使えるものなのに
GoはGC有るのにどちらも無くて
RustはどちらもあるけどGCが無いから不便

**デフォルトの名無しさん** · 2018/03/07(水) 16:37:37.77

RustにもARCはあるんだろ
まあでもARCはゴミのようだという意見には一理あるわな

**デフォルトの名無しさん** · 2018/03/07(水) 16:48:10.62

>>55
RustにARCがあるってのは誤解を招く恐れがあるので補足
RustではARCは標準ライブラリとして用意されてる
SwiftみたいにARCでメモリ管理してるわけじゃないよ

**デフォルトの名無しさん** · 2018/03/07(水) 17:13:59.44

Rustなんてmozillaに金掴まされた奴しか見向きもしてない何にも使えない言語が
次世代言語とか笑わせんでくれ

**デフォルトの名無しさん** · 2018/03/07(水) 17:19:05.18

まだ言ってんのかよｗ

**デフォルトの名無しさん** · 2018/03/07(水) 17:35:57.09

実際誰がどこで使ってるのか教えてくれ
モジラの金掴まされた企業以外で

**デフォルトの名無しさん** · 2018/03/07(水) 18:15:46.78

googleがxi-editor作ってたり、
後railcarってdocker代替作ってたり。
どっちもあんまり魅力的じゃないないな。
ゲームエンジンがrustで書いたらどうなるか興味ある。

**デフォルトの名無しさん** · 2018/03/07(水) 18:19:20.11

dartを知らない人間がdartに触る例。

https://youtu.be/uDKCK8BBPJU

エンジニアのプログラミング実況動画面白いかも。これのrust版ってある？

**デフォルトの名無しさん** · 2018/03/07(水) 18:50:32.83

>>59
1.0出て何年も経ってるのに
その体たらくって時点でお察し

**デフォルトの名無しさん** · 2018/03/07(水) 19:11:36.71

>>59
ゲーム分野もUnityやUnrealでニーズ満たしてるし、それ以外のものは今さら流行らんでしょ

**デフォルトの名無しさん** · 2018/03/07(水) 19:14:43.72

>>41
コンパイル速度が早ければスループットが上がるんだから、労力の定義次第だろ。

**デフォルトの名無しさん** · 2018/03/07(水) 19:15:35.75

>>59
こいつ反応楽しみたいだけの荒らしだから触れるな

**デフォルトの名無しさん** · 2018/03/07(水) 19:17:10.88

>>53
本当これだよな
両方バランスが悪い
ネイティブでバランスの良いKotlinみたいな言語欲しい
Kotlin Nativeはどうなんだろうね

**デフォルトの名無しさん** · 2018/03/07(水) 20:42:19.89

>>53
ラムダ式とジェネリクスはGCとはあまり関係ない機能だと思うが…
特にジェネリクスとGCには全く何の関係も無いような…

**デフォルトの名無しさん** · 2018/03/07(水) 20:57:01.38

https://taiyaq.com/contents/VXd2aV04Gr1mLC8e3AbEg4XKly
Dartの言語ツアーみてるけど、結構言語仕様が辛い。

変数宣言がC由来の「型変数名」なのがつらい。
GoとかTypeScriptみたいに変数宣言は「変数名型」にして欲しいわ
あと内部コードがutf16というのが気になる。jsより後発なのにjsと同じ仕様って。

Flutterは良さげなのになぁ。

**デフォルトの名無しさん** · 2018/03/07(水) 21:02:27.65

RustがC++の代替って枠だと先にも出てる大規模ゲームなんだが、個人やインディーズなら大手エンジンでいいし社内独自エンジンだとこれまでの資産的にツールもゲーム本体も言語変える必要なくない?みたいな所がなぁ

**デフォルトの名無しさん** · 2018/03/07(水) 21:13:00.74

気軽に書くならswiftを使うかな

**デフォルトの名無しさん** · 2018/03/07(水) 21:18:56.44

>>68
rustってc++に絶対勝てないのかね？
メモリ管理を静的に解決できるって不思議なんだけど、もしかしてメモリ節約プログラミングが得意だったらスマホとかIOTでワンチャンあるかもしれん。

**デフォルトの名無しさん** · 2018/03/07(水) 21:24:30.78

今rustで書いてるよ、勿論mozilla全く関係無い
映像系のバックエンドでは結構使ってる情報見るけどな

**デフォルトの名無しさん** · 2018/03/07(水) 21:51:29.88

rustは理論好きで実際はコードほとんど書かないような連中に人気あるだけだろ。
ゼロコスト抽象化カッケーとかそういう層。

**デフォルトの名無しさん** · 2018/03/07(水) 21:58:39.87

>>70
ヒープ周りは言う程魔法みたいな事をしてる訳ではないよ
どこまでいってもコンパイル時の制限をカッツカツにして開放を保証するって話だし

iotもスマホも(もちろんゲームも)クロスプラットフォームしたくて大変なのにそれぞれc++向けに書かれてるsdkラップする?っていう
オープン規格やらそういうsdkがrust向けを公式で出すようになれば採用も出てくるとは思うけどね

**デフォルトの名無しさん** · 2018/03/07(水) 22:05:41.69

メモリ解放のタイミングが分からなくなるっつーのは基本的に
インスタンスを共有してる変数がいくつもあるから
ってのがrustの主張の根幹でしょ。

**デフォルトの名無しさん** · 2018/03/07(水) 22:21:07.09

わたすもrustで書いてるよ
webだけど
メインブラウザがファイヤーフォックスだからモジラの手先かもしれん

**デフォルトの名無しさん** · 2018/03/07(水) 22:26:35.72

まあrust使ってる時点でモジラの手先だしな

**デフォルトの名無しさん** · 2018/03/07(水) 22:26:48.78

実行時に参照カウントを増減するのは、実行しないとわからない場合だけにしろ
コンパイル時にわかることを実行時にチェックするな
これはRustだけでなく静的型がさんざん主張していたこと

**デフォルトの名無しさん** · 2018/03/07(水) 23:11:58.32

>>1
Dartとかいう完全死産のゴミ言語をスレタイに入れるな
おまえほんっとセンスねーなバーカ

**デフォルトの名無しさん** · 2018/03/07(水) 23:22:26.51

Dart2で再始動って言ってるからDart4くらいで良くなるんじゃねｗ
Flutterはちょっと気になってる

**デフォルトの名無しさん** · 2018/03/08(木) 00:02:08.17

>>47
これでコード書く時間が逆に増えたらウケるな

**デフォルトの名無しさん** · 2018/03/08(木) 00:11:20.59

>>79
死んでしまったAngularちゃんの悪口はやめろ

**デフォルトの名無しさん** · 2018/03/08(木) 02:29:26.18

>>79
内部文字コードがutf16とか変数宣言がいまいちとか結構辛い。
flutterとdartを分離してTypeScriptから使えるようにしてくんないかな

**デフォルトの名無しさん** · 2018/03/08(木) 12:46:52.68

>>72
あーわかる超わかる
トイプログラムだけ書いて満足する奴のための言語みたいな

**デフォルトの名無しさん** · 2018/03/08(木) 12:54:28.13

>>71
結構使ってる情報見る（ソースなし）

**デフォルトの名無しさん** · 2018/03/08(木) 13:26:45.90

>>83
個人が趣味でやってるプログラムなんてどんな言語だろうが大体そういうものだろ
別にRustで書いてる奴に限った話じゃない

**デフォルトの名無しさん** · 2018/03/08(木) 13:27:26.60

本格的なものを作ろうとすれば企業が関わらざるを得なくて現状ではどの企業もまだ様子見状態ってだけ
むしろGoogleがRustで実験的にエディタを作ってるってことは
Googleも採用を検討するくらいには注目してる言語ということ

**デフォルトの名無しさん** · 2018/03/08(木) 13:36:32.00

>>86
残念ながらxi-editorは20%ルールの産物で完全に個人のトイプログラムなんですよね

そもそもGoogle社内の公認言語にRustなどという腐ったものは存在しない

**デフォルトの名無しさん** · 2018/03/08(木) 13:55:25.73

Goも元々は20%ルールの産物じゃなかったっけ？

**デフォルトの名無しさん** · 2018/03/08(木) 13:56:46.22

そだよ
てか、GoはRuby同様ガチ勢に嫌われすぎてて、なかなかカチッとしないね

**デフォルトの名無しさん** · 2018/03/08(木) 14:07:05.39

まじで。Go自体が20%ルールの産物なのは知らんかったわ

Goは初期のJava見てるような時代逆行感あるし、それが嫌われる原因だろうね
初期のJavaよりははるかにマシだけど

**デフォルトの名無しさん** · 2018/03/08(木) 15:53:31.02

>>84
Rustアンチ面倒臭い

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002?page=2
https://speakerdeck.com/yaminoma/bitutoretogai-shan-dezhuan-song-liang-wojian-rasitaohanasi

**デフォルトの名無しさん** · 2018/03/08(木) 16:57:24.84

ドワンゴや渋みたいな画質最悪回線ptptのプラットフォームの技術（）なんて参考にならん

Youtubeとか嗶哩嗶哩とかネトフリくらいのプラットフォームが全く採用してない時点でお察しだろ

**デフォルトの名無しさん** · 2018/03/08(木) 17:38:09.62

アンチのいない言語ってあるんかな？
それって誰が見ても引っかかることがなくて無難で分かりやすい言語ってことだよね。
、、、、C言語かな？
いやーないか。Pythonかな？

**デフォルトの名無しさん** · 2018/03/08(木) 18:00:05.39

>>93
C 言語は基本だよね…

**デフォルトの名無しさん** · 2018/03/08(木) 18:05:00.88

マクロ中途半端じゃん

**デフォルトの名無しさん** · 2018/03/08(木) 18:06:09.58

Goが嫌われるのは、意識高い系の人間が欲しがる機能をオミットしたからだろ。
欲しがるやつはバカぐらいの事言ってるし。
学者と機械屋が仲悪いのと同じようなもんで。

**デフォルトの名無しさん** · 2018/03/08(木) 20:42:30.56

機能をオミットする方向を示しただけでもgoは価値あるよ。
他の言語はバカみたいに機能を追加する方向しかみてなかったし。

**デフォルトの名無しさん** · 2018/03/08(木) 20:50:41.00

採用例提示しろって言われたから東証一部上場企業の採用例をいったらいったでまた難癖つけるね
グダグダ言ってないで自分が使わなきゃいいだけじゃん

それでもニコニコがRustでオリジナルファイルシステムまで作ってあのクソさってのはいろいろ思うところはある
よくもまあ10年近くも金をオフパコ会議に突っ込んでろくに鯖の整備もせずに来れたもんだ

**デフォルトの名無しさん** · 2018/03/08(木) 20:53:13.13

FacebookのMononokeとかも除外なのかな
有名所が軒並み使わないと認めないんだろうな、いやそれでも否定するか

**デフォルトの名無しさん** · 2018/03/08(木) 21:19:24.31

>>96
オミット大事だよね。バージョンを重ねていくと機能追加しかできないから
最初の機能は絞ったほうがいい。
Goにはきっと既存にはない独自発想のジェネリクス的な物が搭載されるであろう。
賛否両論なやつが。

**デフォルトの名無しさん** · 2018/03/08(木) 21:38:40.38

>>100
「例外を無くした。あれは大域ジャンプだ。行き先の見えないgotoだ。
　フローが無茶苦茶になる、複数の戻り値返すから各自チェックするように。
　複数の戻り値返せるからマジックナンバーとか返すなよ」
なんて、割り切りというより考え抜いたであろう仕様も、結構叩く人は叩くしな。

ジェネリクス的なものはどうなるんだろう。
正直型でのswitchでだいたい事足りてるし。

**デフォルトの名無しさん** · 2018/03/08(木) 21:46:19.70

>>101
関数の引数にinterface{}型が入るのは良くない。これだけは是非とも改善したい

**デフォルトの名無しさん** · 2018/03/08(木) 21:52:55.87

>>102
何で？
コンパイルする時に誤りに気づかないとかそういう話？
void*が渡せるよりも、interface{}は実際には型持ってるからよほどマシな気が。
ジェネリクスしたらすごい数の関数が作られうるし、使い方の問題な気がするけどな。
そもそも継承という概念が希薄だから、ジェネリクスにしても幸せになれないと言うか、明示的に何らかのinterfaceを渡す方がマシだと思う。
Writer受ける関数みたいに。

**デフォルトの名無しさん** · 2018/03/08(木) 22:31:36.69

>>103
実行時に解決するのは極力避けたい。
防衛的プログラミングをしたい。
AST系ライブラリを使いこなせるようになってコード生成でもいいけど。

**デフォルトの名無しさん** · 2018/03/08(木) 22:35:27.75

テストコード書くのは嫌だってだけだろどうせ。

**デフォルトの名無しさん** · 2018/03/08(木) 22:37:10.68

例えば今、任意のオブジェクトを格納できるコンテナ
（二分木でもハッシュマップでもブルームフィルタでも）
のライブラリを作りたいとしよう

このライブラリに、初期化時に任意の型しか格納できないようにする
まあつまりJavaのList<T>みたいなことをしたいと考えたときに
Goでは型ごとにラッパをつくって実行時に動的にチェックする以外に実現方法がない

これをコンパイル時にチェックしたいという要望は自然と思うが？

**デフォルトの名無しさん** · 2018/03/08(木) 22:46:42.29

つか自分で言ってて思ったがこれinterface{}が悪いとかじゃなくて
単純に高階型が欲しいってだけの話だわ

**デフォルトの名無しさん** · 2018/03/08(木) 22:51:14.55

>>105
それもあるけどライブラリを提供するときに引数がinterface{}だとドキュメントに説明がいるでしょ。そういうのが嫌。

**デフォルトの名無しさん** · 2018/03/08(木) 23:04:06.14

コンパイルが遅くなるので人間が出来る事は人間がやってください

**デフォルトの名無しさん** · 2018/03/08(木) 23:05:42.03

>>108
どっちにしろ実行時に起こる現象は説明が必要だろ。
確かに動的だったりテンプレートみたいなもんだと読むのきついなと思うことがあるけど
型で述べられる記述力なんてコード量の割にそんなに豊かなもんでもない。
俺は優良なドキュメトとテストコードのが上回ると思ってる。
goのinterfaceと比べて継承の方が入力の範囲を特定する能力は高まるけど、
同時に型情報をどっさりコンパイラと人間に読ませることになるわけだ。
割にあってると思わない。

**デフォルトの名無しさん** · 2018/03/08(木) 23:10:55.43

やっぱり型クラスって神だわ

**デフォルトの名無しさん** · 2018/03/08(木) 23:12:19.99

>>110
Scalaとか見てると気持ちはすごくわかる
しかしせめてコンテナ型くらいは型制約欲しいという気持ちもわかってくれ

**デフォルトの名無しさん** · 2018/03/08(木) 23:39:44.92

>>106
型に階層があるという事が前提になってる時点で、goに向いてないんじゃない？

**デフォルトの名無しさん** · 2018/03/09(金) 00:31:33.39

"is a" の機能をomitして "has a" とかmixinとかtraitを使う方向

**デフォルトの名無しさん** · 2018/03/09(金) 00:49:56.76

>>110
ちょっと具体例が浮かばなくて適当な説明になるけど
ある引数に io.Reader もしくは io.Writer だけが来て欲しいって場合に
interface{}で一旦受け入れてどっちかじゃなかったらエラーって書くのがしんどいの。
引数にio.Reader | io.Writerって書けるようになれば
どっちかしか来ないことが保証されるからエラーハンドリングのコードが減る。

別に型システムがほしいとかじゃなくて
なんでも受け入れるinterface{}にしてしまう状況を避けたい。

**デフォルトの名無しさん** · 2018/03/09(金) 04:10:38.55

R | W より Or<R, W> が良い
記号を使うと記号アンチがうるさいし、継承と総称型を混同するやつもうるさい

**デフォルトの名無しさん** · 2018/03/09(金) 07:28:22.67

その場合 `Or<A, Or<B, C>>` と `Or<Or<A, B>, C>` の等価性どうする?って話しになるけどね

**デフォルトの名無しさん** · 2018/03/09(金) 08:17:11.21

>>115
そんな気持ち悪い関数嫌だな…。
分けられないの？

**デフォルトの名無しさん** · 2018/03/09(金) 08:18:50.78

>>114
それはもう、今の定義されたinterfaceで充分だとなってしまうのでは？

**デフォルトの名無しさん** · 2018/03/09(金) 09:19:07.89

せめてパターンマッチくらいは入らんかなあ
型判定のためにifをダラダラ並べるようなコードなんて誰も嬉しく無いよ
:=もあるんだし構文糖衣まで全て拒否してる訳でも無いだろうに

**デフォルトの名無しさん** · 2018/03/09(金) 10:34:44.49

>>118
まぁ例えばだから。もっとぴったり来る例を示せればよかったんだけどね。
関数のオーバーロードも合わせて欲しいな。関数名考えるのがしんどい

**デフォルトの名無しさん** · 2018/03/09(金) 10:59:00.45

>>120
switchは？

**デフォルトの名無しさん** · 2018/03/09(金) 10:59:28.74

>>105
静的型システム全否定だなお前のレス

**デフォルトの名無しさん** · 2018/03/09(金) 12:12:54.21

>>110
ドキュメントが常に最新の状態であることを静的に
保証する方法がない限りは静的型付けの型情報の方が信頼できる
腐ったドキュメントほど有害なものはない

腐らせるヤツが悪いとか言われそうだが
腐らせるのは自分ではなく同じチーム内の誰かだ
他人よりコンパイラの方が信頼できる

**デフォルトの名無しさん** · 2018/03/09(金) 12:43:31.33

interface{}を他の言語のobjectみたいなほんとに雑な受け方と一緒にしないでくれよ…。
実際に書いたら、結構使う場面が限られて来ることもわかるだろ…。

>>121
オーバーロードの禁止ははまあ必要悪だと思う。
型同士に階層が無いので、2種類のinterfaceを受ける関数があったとき、その2つともを実装している型に対して関数が定まらんのでは？

**デフォルトの名無しさん** · 2018/03/09(金) 12:56:29.64

>>125
してねえよ
コンパイル時の型制約を足したいって話で、機能的にinterface{}への switch t.(type) で十分なのは承知の上

ifが並ぶっていってる奴はたぶんswitchで型判定できるの知らない気がする

**デフォルトの名無しさん** · 2018/03/09(金) 13:27:20.95

仮にGoにジェネリクスを実装するとしたらどこまで必要になるんだろ
共変性と反変性は必要？
部分適用は必要？
C++のメンバ型みたいなのは必要？

**デフォルトの名無しさん** · 2018/03/09(金) 13:32:11.39

>>127
そんな難しいのはいらねーから宣言的に書かせろ

**デフォルトの名無しさん** · 2018/03/09(金) 15:24:58.40

>>125
object型と同じだと思ってたわ。具体的な違いとメリットを頼む。_φ(･_･

**デフォルトの名無しさん** · 2018/03/09(金) 16:38:15.55

>>129
渡されたものをどう解釈するかの余地が他の言語と結構違う
たとえば、
type xxx struct {}
func (x xxx) foo(){}
func (x xxx) bar(){}
type Ixxx interface {
foo()
}
func (ix Ixxx) bar(){}

があったときに、interface{}で受けたものをアサーションでxxxとすると、xxxのbarが、
アサーションでIxxxとすると、Ixxxのbarが呼ばれる。
あくまで、すべての構造体はinterface{}を満たしているだけで、実際には型を持ってるし、
interface{}とIxxx{}も満たす範囲が違うだけで上位下位ではないし、構造体の型とも違うのでレシーバは別になる。
interface{}から派生したものではないって感じ。

**デフォルトの名無しさん** · 2018/03/09(金) 17:07:33.29

もしかしてswitchに型チェック機能追加したやつが戦犯かな
ただのVisitorパターンならジェネリクス対応は難しくなかった

**デフォルトの名無しさん** · 2018/03/09(金) 18:13:47.78

型チェックでswitchとジェネリクスは全く関係ない。
オーバーロードと同じく、何として処理するかと、その型が何か、に関して曖昧性を排除してるから。
暗黙のキャストも無いでしょ。
戦犯呼ばわりはどうかと思う。他の言語に毒されすぎ。

**デフォルトの名無しさん** · 2018/03/09(金) 19:09:25.15

Goにオーバーロード無いの批判される事あるけど
HaskellやRustだって型クラスやトレイトを使わないとオーバーロードできないし
TypeScriptも型が多重定義できるだけで実体は一つだし
むしろ最近の言語はC++みたいな単純なオーバーロード付けないのがトレンドな気がする

**デフォルトの名無しさん** · 2018/03/09(金) 19:11:17.45

一方Cには_Genericがついた

**デフォルトの名無しさん** · 2018/03/09(金) 20:41:59.05

>>124
ドキュメントよりコンパイラのが信用できるかも知れんが
それ以上にテストコードの実際の動作のが信用できるよ。
c++まともに開発に使ってた奴ならどれほどコンパイラだよりが危ういかわかると思うけどね。

**デフォルトの名無しさん** · 2018/03/09(金) 20:50:57.42

コンパイラが頼れないからC++から離脱したがってるわかで……

**デフォルトの名無しさん** · 2018/03/09(金) 21:48:54.86

>>133
むしろオーバーロードと型推論を共存させたいというのが型クラスの最初の動機だったのでは

**デフォルトの名無しさん** · 2018/03/09(金) 21:50:23.61

>>135
そりゃテストコードが全てのコードに対して書かれていたらの話で
実際にはテストカバレッジ100%なんてあまり現実的な数値じゃない
GUIの場合はテストを書くこと自体がなかなか難しいし、他にも仕様が変わりやすいような
部分は変わるたびにテストも書き直すんじゃ、コストが割に合わないこともある
それらを考慮して、あえてテストを書かないという選択をすることも充分あり得る
静的型付けならテストが書かれていない部分でも型情報からある程度ならチェックが出来る
動的型付けはテストがなければ何もチェックできない

テストを書かない奴はバカみたいな言い分はあまり好きじゃない
テストカバレッジ100%を目指す奴のほうがよっぽどバカだと思う

**デフォルトの名無しさん** · 2018/03/09(金) 22:24:57.88

C++の型安全とHaskellの型安全って随分違うでしょ
理論がしっかりしてて型システムが豊かな方が型安全で提供される品質は高い
Haskellは「コンパイルが通れば大体想定通りに動く」って言われる程度には型を信じれるよ

これが行き過ぎるとIdrisやCoqみたいに「実行できれば仕様を満たしている」みたいな開発もできる
ハードル高いし実用できるほど簡単じゃないからまだ何個かブレークスルーが要るがね

**デフォルトの名無しさん** · 2018/03/09(金) 22:28:04.16

>>130
残念ながら他言語のobject型とinterface{}の違いがこの説明ではよくわからん。

あんさんは他の言語のobject型を雑な受け方と評したんだぜ。具体的にこの説明では、
なるほど他の言語のobject型で値を受け取るのは雑な受け方だった。って納得しない。
どのへんが雑じゃなくなってるわけ？

**デフォルトの名無しさん** · 2018/03/09(金) 22:30:56.35

>>138
qiitaの記事でだいたいカバレッジが85%位が理想値でそれを超えるとしんどくなるだけで意味ないってのは見たな。

**デフォルトの名無しさん** · 2018/03/10(土) 09:17:00.38

>>135
C++のコンパイラに頼るのは危ないってのはテンプレートがダックタイピングだからじゃないの？
だとしたら、それは単にC++のテンプレートの仕様がクソってだけの話で
C++のコンパイラがクソって言うのは筋違いだと思うんだけど…
それとも他に理由があるの？

**デフォルトの名無しさん** · 2018/03/10(土) 09:30:50.15

書いた後で思ったけど、
C++のテンプレートってダックタイピングって言われてるけど
きちんとコンパイルエラーになったような…？
使ってたの3年以上前だから忘れた。どうだったっけ？

**デフォルトの名無しさん** · 2018/03/10(土) 09:57:39.05

たぶん135は、コンパイラがバグってて出力される機械語が怪しいという話をしてる
別にC++に限った話ではないんだけど昔は結構多かった

**デフォルトの名無しさん** · 2018/03/10(土) 10:03:15.55

>>140
うーん。なんにでもなれるスーパークラスで受けてるんじゃなくて、何もかもを満たすインターフェイスで受けてる。
クラスというか構造体同士に階層も無いし、
インターフェイス同士にも無いから。
だから、他の言語でObjectからキャストし直すときに、キャスト先の階層構造を考えなくてもいいし、
むしろどうキャストするか(何がほしいか)で、それに合わせたレシーバを呼んだりできる。

**デフォルトの名無しさん** · 2018/03/10(土) 10:07:28.98

>>139
なのになぜライブラリのバグがちょいちょい発覚するの？

**デフォルトの名無しさん** · 2018/03/10(土) 10:47:28.09

普通は型の階層を利用したキャストの方が丁寧で
Goのような要件さえ満たせばなんでもキャストできる方が雑なんだけどな
雑なGoに丁寧なジェネリクスは似合わないって話の方がしっくりくる

**デフォルトの名無しさん** · 2018/03/10(土) 11:47:59.83

動的型は丁寧なコードも雑なコードも書けるよ
静的型のキャストは雑なコードだけを集めて濃縮したような存在

**デフォルトの名無しさん** · 2018/03/10(土) 12:02:58.66

型の階層ってのからまず脱却した方が良いところだと思うけどね。
型の階層の横紙破りとしてインターフェイスを作ってさらにインターフェイスも階層を持つとか、goやり始めてから悪手な気がしてきた。
他の言語もmixinとかtraitなんかで色々やってるけど、そういう方向で対応すべきもんなんだと思うよ。俺は。

rubyのようにobjectの親を作る羽目になったり、どのみち破綻する。
型の継承による、と言うが、型の継承に頼ったキャストとしか言いようが無いんでは？

**デフォルトの名無しさん** · 2018/03/10(土) 12:03:37.10

>>145
>だから、他の言語でObjectからキャストし直すときに、キャスト先の階層構造を考えなくてもいいし、

どういうこと？Object型は大抵すべてのインスタンスの親のはずでは？
一度Object型の変数に突っ込んだなら、それってもう実質、動的言語的扱いになるから人間側が元の型を意識しなきゃいけない。
これはGoでもおんなじでしょ？

あと以下は正直どうでもいい話なんだけど敢えて突っ込む。

Goのインターフェースは階層構造を持たないって言ってるけど
も結局用語の違いってだけで実質階層構造みたいなのはあるでしょ。
Io.ReadWriter は io.Writerを内包している
io.Writerはからインターフェースを内包している

Io.ReadWriter => io.Writer => interface{}

他の言語は階層構造を明示しているけどGoの場合はそれがコンパイラによって自動化されているってだけでは?
もちろん自動化されているってのはありがたいけどね。

**デフォルトの名無しさん** · 2018/03/10(土) 12:07:47.02

>>143
静的ダックタイピングって言われてる
本質は変わらない

**デフォルトの名無しさん** · 2018/03/10(土) 12:13:23.90

>>148
動的型のキャストと静的型のキャストに違いがあるとは思えないけどなぁ。
俺の考え方はこう。
動的型: 人間側で型の追跡を頑張る
静的型: コンバイラ側に型の追跡を任せる。ただしobject型とかに渡すことで人間側で頑張ることもできる。

動的型は基本雑なコードだらけ。人間側が型を決め打ちしてメソッドを実行しないとやってられない。
だって毎回instanceof とかで型をチェックしてからメソッドの実行とかしてないでしょ？

**デフォルトの名無しさん** · 2018/03/10(土) 12:16:33.64

>>152
説明されてわかるような奴が>>148を書くと思うか？

**デフォルトの名無しさん** · 2018/03/10(土) 12:24:33.09

>>150
そんなことないよ。例えばtoStringみたいな、親から生えてるメソッドは、objectのまま呼べて、しかもインスタンスのメソッドが呼べるでしょ。
goはそうはなってないの。インターフェイスをレシーバとする関数が呼ばれる。

内包してないよ。
ReaderはReadを
WriterはWriteを
ReaderWriterはReadとWriteを実装しているインターフェイスなだけ。別のインターフェイス。そこに上位下位は無い。

階層構造が暗黙に決まってるんではなくて、そもそも階層構造を持ってない。

**デフォルトの名無しさん** · 2018/03/10(土) 12:35:41.84

なんでもできる c++ で書くなら
なんのメンバーも持たない class interface の直接の
派生型として色んなインタフェースがあるようなもんか

COM に似てるな、というか COM のインタフェースの概念の焼き直しか。

**デフォルトの名無しさん** · 2018/03/10(土) 12:36:05.42

ダックタイピングとnominalな階層型の違いを言葉を変えて繰り返しているだけで
問題のinterface{}がobjectより良いという説明にはなってないな

**デフォルトの名無しさん** · 2018/03/10(土) 12:42:10.90

>>138
別に全部のコードにテスト書けとは思わんが
それでもそこまで引数の型がどうなのか気になるインターフェイスなら
テストコード書けよ。

てかそこまで作業が圧迫してるなら型をガッチガチにやる言語のが
調整する手間考えた場合割に合わんだろ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:01:42.42

>>157
どの程度なら「気になる」のかってところに認識の違いがありそうだな
静的型派の人間は全てコードの型情報が気になっちゃうんじゃない？
少なくとも俺は全ての引数の型が気になってしまうタイプの人間だよ

**デフォルトの名無しさん** · 2018/03/10(土) 13:02:25.28

>>152
動的型のコードは二種類に分けられる
静的型で丁寧に書いてから型を省略したようなコードと
静的型で雑に書いてから型を省略したようなコードだ

**デフォルトの名無しさん** · 2018/03/10(土) 13:10:46.65

「階層を持つから安全にキャストできる」と「安全にキャストできるから階層を持つ」がごっちゃになってる人がいる

**デフォルトの名無しさん** · 2018/03/10(土) 13:12:51.16

>>158
まあ極論すれば感覚的な話だしね。
感覚として型を気にして助かることなんて 5 % くらいじゃないかと思ってる。
対してテストがある場合は 40~50%くらい助かる。
準備するコストとして型が 10~20 としたらテストは 30~40 といった印象。

なんで個人的にはそこまで型を整備するよりかはテストに時間使った方がいいと考えてる。
まあ抽象論一発で済めば嬉しいって気持ちはわかるんだが
実際そうはならんからね。。

**デフォルトの名無しさん** · 2018/03/10(土) 13:17:24.66

>>156
端的に言えば、スーパークラス(と言う概念もないが)にキャストしてして渡してない、as-isで渡してると言うところが違うし大きい。
良いとも言ってないぞ。
違うし混同するなと言ってる。
Objectに相当するものが無いので、良いも何も比較対象ではない。

**デフォルトの名無しさん** · 2018/03/10(土) 13:21:00.62

スーパークラスにキャストねえ。
どの言語でもその場合は as-is で渡るだろう

**デフォルトの名無しさん** · 2018/03/10(土) 13:23:17.42

暗黙的にでも、ね。
Objectで受ける、Ienumerableで受けるを含めて。

**デフォルトの名無しさん** · 2018/03/10(土) 13:24:20.18

as-isで渡るは確かに語弊があったな。
別の型のオブジェクトやインターフェイスとして渡されてるんじゃなくて、って感じ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:27:51.68

>>162
>>125でobjectを雑と評したからには当然interface{}の方が良いという主張と思ってたんだが
実際の詳細は別にしてあなたの説明では聞けば聞くほど同じとしか思えない
俺じゃないが>>155なんかCOM的な構造で代替可能という理解をしてるし

**デフォルトの名無しさん** · 2018/03/10(土) 13:31:43.54

とはいえ言いたいことはわかる
オブジェクトに似ているがオブジェクトを渡しているわけではない、
オブジェクトとそれの持つインタフェースは1対多

COM のインタフェースや多重継承を用いた場合のC++に似ている
特に前者とはほぼ完全に同じものだ
インタフェース抽象って奴だね

この場合実行モデルとしてはインタフェースに階層関係は要らなくなる
複数のインタフェースを持つことから(派生による差分宣言、差分実装ではなく)
ミックスインが基本となるから。

**デフォルトの名無しさん** · 2018/03/10(土) 13:31:58.31

as-is型に実装を合わせるテンプレート
as-is実装に型を合わせるキャスト
これが次世代の争い
動的型は次世代ではないから政治的中立

**デフォルトの名無しさん** · 2018/03/10(土) 13:52:58.58

>>166
同じではないでしょ。
COM的な構造で代替可能ってのは、>>166自身は理解してるの？理解してたらそのレスにはならんと思うけど。
そもそもが思い込みで人の発言に「良い」を勝手に補完してなんでそんなにしつこく食いついてくるかわからん。
理解が足りなくて同じだとしか思えないなら開き直らないでほしいわ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:54:45.25

>>154
だから階層構造がないのはわかってるつーの。実際的な違いがないっていってるの。
実質Object型とinterface{} はおんなじ扱いにしかならない。
Object型にはtoStringがあるけどinterface{}にはない？別にそんなのはどうでもいい話。

interface{} に値を突っ込むと人間側が型を意識する必要がある。
動的言語的な扱いになっちゃう。

この点においてObject側と一緒だよね。

ここが最大の肝であり、「Object型でうけるのは雑」っていってるのはこの部分に差があると期待して質問したのに、
そこに関しては違いを見出していない。
なら雑な理由って何よ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:55:30.73

今気が付いたが>>145の言ってることは根本的に間違ってる
>>130みたいなインターフェイスのレシーバはそもそもコンパイル通らない
つまりどの型にキャストしても同じレシーバが呼ばれることが保証されてる
そこがGoの型は階層を持たないという根拠になってたはず
エアプは黙ってろ

**デフォルトの名無しさん** · 2018/03/10(土) 13:57:07.23

>>169
IUnknownが便利に使われてるのと
QueryInterfaceの実装次第でメンバーに飛ばすこともできるのが似てるって話だろ
COMは実装側が応答する型(GUID)を決めないといけなくてダックタイピングにはならんから
俺は必ずしも似てるとは言わんけど、あなたの説明はそう思われてもしょうがないってことだ

**デフォルトの名無しさん** · 2018/03/10(土) 14:21:55.45

classの多重継承ができる言語ならinterfaceはclassの構文糖ということにできた
多重継承を制限したことでinterfaceとclassの互換性が非自明になった

**デフォルトの名無しさん** · 2018/03/10(土) 14:23:37.99

>>171
これは例が悪かったか。
スマホで書いたからすまん。

ある型にアサーションした場合、アサーション先の型のレシーバが呼ばれるよ。
もとのレシーバではない。

**デフォルトの名無しさん** · 2018/03/10(土) 14:26:15.83

>>170
おんなじ扱いをすれば同じになるだろうな。
扱い方の余地の問題なんだが。

人間側が型を意識する必要がある、この点に於いてObjectと同じと言うのは雑すぎる。
動的言語的扱い方と言うか、jsonのUnmarshalなんか見た方が多分わかりやすいと思う。俺が言ってることは。

**デフォルトの名無しさん** · 2018/03/10(土) 14:26:53.39

>>172
説明が悪いのは申し訳ない。

**デフォルトの名無しさん** · 2018/03/10(土) 14:31:49.68

interface{}で受ける関数を呼ぶときは、
とりあえず、スーパークラスのObjectに(暗黙的に)キャストして渡してるのではなくて、あるインターフェイスを実装している型として渡してる。
全クラスがIfooをimplementsしている状態で、Ifooを受けているだけ。
そこにキャストは発生してないし、だから、キャストではなくアサーションで型を判定するだけで(キャスト無しで)中身の型が分かる。
その時に、もとの構造体ではなく、あるインターフェイスとしてアサーションする事ももちろんできる。

そこだけでも伝わってほしい。

**デフォルトの名無しさん** · 2018/03/10(土) 14:33:10.73

しかし、また「エアプ」かw
好きなんだな、その言葉。

**デフォルトの名無しさん** · 2018/03/10(土) 14:47:03.22

キャストは雑
アサーションは丁寧
という説が伝わってきた

**デフォルトの名無しさん** · 2018/03/10(土) 14:56:06.20

>>175
それって結局reflectバッケージを見ろってこと？
>>177
型キャストが雑ってこと？
型アサーションだと型が合わないとerrorを返すから雑じゃないってこと？

**デフォルトの名無しさん** · 2018/03/10(土) 15:25:20.56

雑なほうがいいんだよ。that's rightって言うだろ？

**デフォルトの名無しさん** · 2018/03/10(土) 15:26:15.03

>>180
アサーションが丁寧というのは語弊があるが、インターフェイスからのアサーションはそもそも本来の型自体も持ってるのでキャストしているわけではなく、assert、言明し直してるだけで、別の型として一度も扱わない。

**デフォルトの名無しさん** · 2018/03/10(土) 15:28:33.49

>>174
アサーションでもレシーバが変わることはない
自分で試したことないから分からないんだろ
>>177のキャスト無しで渡してるってのも間違いで実際はキャストされてる
キャスト無しで渡してたらそれはジェネリクスだ
たぶん>>177はポインタや参照を理解してなくてキャストの意味をはき違えてる
objectにキャストしたら静的オブジェクトが動的オブジェクトに変換されると思い込んでるようにしか見えない

**デフォルトの名無しさん** · 2018/03/10(土) 15:39:34.50

>>183
あることあるから、レシーバが変わる事知ってるんだよ。
そうじゃない。履き違えてないよ。
ジェネリクスはもっとちがう。コンパイル時に関数自体が型ごとに分かれるのが俺が言うジェネリクスとオーバーロード。
オブジェクト指向脳でわけわからん事言わないで。

**デフォルトの名無しさん** · 2018/03/10(土) 15:56:33.06

>>184
が、言いたいことを整理すると
Go言語のinterface{}は他言語のObject型とは違う。
なぜならGo言語のinterface{}型は内部的には型情報を保持しており
reflectバッケージを使うことでいつでも元の型情報を取得できるから
ってことでOK?

これって逆に言うと他言語のObject型は内部的に元の型情報を保持しないの？

**デフォルトの名無しさん** · 2018/03/10(土) 16:04:38.45

本来のデータポインタはそのままで実行時型情報をペアにしてinterface{}(fat pointer)にしているのを
キャストしているしていない言い張ってるだけかな。まあ言葉はどっちでもいいが

ちなJavaタイプのnominalなinterfaceや多重継承はデータポインタに特定のオフセットを加減算する(ポインタの値が変わる)
場合がほとんどだが、fat pointer方式の実装も無いわけではない

**デフォルトの名無しさん** · 2018/03/10(土) 17:15:29.87

>>185
いや保持してるよ
RTTIってやつだね

**デフォルトの名無しさん** · 2018/03/10(土) 17:37:00.44

エアプ呼ばわりされて過剰反応するのが真のエアプ
エアプでないことを示すのが普通の人

**デフォルトの名無しさん** · 2018/03/10(土) 17:37:33.50

>>185
内部的に持ってるが、クラス構造が階層型であるが故にObject型という型で扱われた上で、サブクラスにダウンキャストするじゃん？で、またアップキャストするかもしれん。
だからジェネリクスやオーバーロードだと共変なのか反変なのか、あるいは非変なのかが問題になるし、Javaなんかはジェネリクスは非変だけど、配列は共変みたいな事になってるし、c#なんかだと最近変性注釈できるようになったり、まだゴタゴタしてる。

ちなみに、interfaceへのアサーションはreflectとは違って、interface自体が型を持ってるので、reflectで型を判定したりメソッド呼ぶのとは結構な差がある。
古いけどこのへんか。
https://research.swtch.com/interfaces

**デフォルトの名無しさん** · 2018/03/10(土) 17:38:52.17

>>188
エアプのプロは言うことが違うな。

**デフォルトの名無しさん** · 2018/03/10(土) 17:47:29.26

エアプなんか使ったって、レッテル貼るだけで議論ができないようにしか見えないんだからやめときなって

**デフォルトの名無しさん** · 2018/03/10(土) 17:49:06.20

それが楽しいんだろ、いつもその言葉使うところ見たら。

**デフォルトの名無しさん** · 2018/03/10(土) 17:59:38.11

>>189
>共変なのか反変
急に分かんない用語が出てきて混乱したが
http://www.thekingsmuseum.info/entry/2016/02/07/235454
が参考になった。非変って用語がないが不変の言い間違い？

**デフォルトの名無しさん** · 2018/03/10(土) 17:59:39.44

いや全く楽しくねーわ。

**デフォルトの名無しさん** · 2018/03/10(土) 18:20:49.51

例えば
func ToString(any interface{}) string {
if v, ok := any.(Stringer); ok {
return v.String()
}
switch v := any.(type) {
case int:
return strconv.Itoa(v)
case float:
return strconv.Ftoa(v, 'g', -1)
}
return "???"
}

上記コードはこうできるようにして欲しい

func ToString(any (Stringer | int | float)) string {
if v, ok := any.(Stringer); ok {
return v.String()
}
switch v := any.(type) {
case int:
return strconv.Itoa(v)
case float:
return strconv.Ftoa(v, 'g', -1)
}
}

引数にinterface{} があるのはやっぱりJavaとかで引数にObject型が来るのと同義だと思うわ。

**デフォルトの名無しさん** · 2018/03/10(土) 18:22:28.94

>>193
こっちのページの下のほうに書いてあるじゃん
http://www.thekingsmuseum.info/entry/2016/02/11/111718

**デフォルトの名無しさん** · 2018/03/10(土) 19:46:35.03

結局Objectの方がinterface{}より保証されてるものが多いから、雑なのはinterface{}の方じゃーん

**デフォルトの名無しさん** · 2018/03/10(土) 21:09:45.80

>>105
これ最高に型無しクソペチパー指向的レス

**デフォルトの名無しさん** · 2018/03/10(土) 22:06:56.73

>>197
保証されてるものが多いんじゃないよ。
保証されるべきでない関連性を持ってないものも、関連性を持っているかのごとく扱われるんだよ。

**デフォルトの名無しさん** · 2018/03/10(土) 22:10:01.27

自分が知らないものをたったひとつソースから「言い間違えなのか？」と言うのはどうかしてると思うわ。