Kotlin [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/02/27(土) 01:46:01.68

JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org

**デフォルトの名無しさん** · 2017/06/30(金) 15:20:46.15

何に困ってるのか分からない
その辺の経験あるなら手動かせば身に付くまで大して掛からないだろう

**デフォルトの名無しさん** · 2017/06/30(金) 15:38:15.91

googleのやるべきことはFWを全てkotlinに書き換えることやな

**デフォルトの名無しさん** · 2017/06/30(金) 16:02:16.24

英語読めない奴がLISPとかすげえな
やってて死にたくならない?

**デフォルトの名無しさん** · 2017/06/30(金) 16:17:39.99

>>341
つhaskel

**デフォルトの名無しさん** · 2017/06/30(金) 16:43:11.20

>>344
Scheme は日本語訳あるからそんなにつらくない。
Common Lisp とかみたいに仕様の日本語訳がなくてクソ巨大なのを使いこなすのは大変だと思うけど、
最初からリッチなライブラリがそろっているので実用しやすいという人もいる。

>>342
興味本位なので面倒くさかったらやらないだけ。
ハードルの低い入門があれば見るかもっていう感じ。

**デフォルトの名無しさん** · 2017/06/30(金) 17:11:37.52

>>335
RuntimeExceptionの子クラスの例外は総じて同レベルで恥ずかしいんだが
原則、どれもパラメータチェックしてないから発生する例外だからな
むしろ、ヌルポが一番恥ずかしくて、それが起きないようにオプショナルがあるんだと思ってる

**デフォルトの名無しさん** · 2017/06/30(金) 17:59:28.75

Javaがクソなのと、クソの処理をしないプログラマがマヌケなのは別の話。一緒にすんな。

Optionalはその変数がnullでないことをコンパイル時に保証できたっけ？
実行時コストをかけて解決するのは鈍臭い。

**デフォルトの名無しさん** · 2017/06/30(金) 18:12:49.54

そのクソの処理をしないプログラマでも安全にコーディングさせるためにオプショナルがあるんだよ...
オプショナルがあるからヌルポが起きないわけでもないから完全に安全とは言えんがまぁ言及すまい

**デフォルトの名無しさん** · 2017/06/30(金) 21:30:17.46

>>349
まともな言語なら(c++でさえ)コンパイル時に済ませられるのを、わざわざ実行時にチェックしなきゃいけないのは鈍臭い、つうこと。

**デフォルトの名無しさん** · 2017/07/01(土) 06:09:20.91

全く噛み合ってなくてワロタ
どんだけ崇拝してるんだかwww

**デフォルトの名無しさん** · 2017/07/01(土) 12:59:00.78

C++でヌルポが起きないってマジ？w

**デフォルトの名無しさん** · 2017/07/01(土) 15:33:59.29

Rustだとガチでヌルポが起こせないゾ
オプショナルとかいう中途半端なモノを誇ってるKotlinとは格が違う
まぁ他の面倒が多くて全く勧められるものじゃないけど

オプショナル()だけで素晴らしいとか絶賛してる子は他にメリットを見出してどうぞ

**デフォルトの名無しさん** · 2017/07/01(土) 15:53:26.04

トレイリングクロージャ無いと死ぬマン

**デフォルトの名無しさん** · 2017/07/01(土) 20:36:50.31

ここまで、lazy 初期化の話が出ないw

**デフォルトの名無しさん** · 2017/07/01(土) 21:29:59.25

ヌル安全つうのはモダンな言語じゃ標準装備なんじゃろ？

**デフォルトの名無しさん** · 2017/07/02(日) 13:51:47.79

>>338
Koansとか英語読めなくても(読まなくても)分かるんだが…
メインはKotlinのソースコードで説明読めないなら問題と答えを比べて見るだけで基本的な構文は勉強出来るし
そもそもプログラミング自体の理解が浅いならJavaとかから始めないと例え日本語の解説あっても分からんと思うよ

**デフォルトの名無しさん** · 2017/07/02(日) 23:49:50.72

Java + Groovy = Kotlin

つまり、Javaに関数型を付けた言語だから、
最初に、オブジェクト指向を学ぶ必要があるから、かなり大変

まずこの本で、オブジェクト指向を学ぶ
スッキリわかる Java入門第2版、2014

Kotlinスタートブック -新しいAndroidプログラミング、長澤太郎、2016
WEB+DB vol.94 の特集が、Kotlin, Electron

Try Kotlin のサイトで、ブラウザからプログラミングできる

**デフォルトの名無しさん** · 2017/07/03(月) 00:00:56.60

ここまで出張して来たか、、、

**デフォルトの名無しさん** · 2017/07/03(月) 00:27:08.93

sageじゃない時点でスルーでいいよ

**デフォルトの名無しさん** · 2017/07/03(月) 00:37:26.98

NGワード：スッキリわかる

**デフォルトの名無しさん** · 2017/07/03(月) 06:33:05.51

Kotlin.NativeよりSwiftのが使えるって本当？
Kotlin.Nativexはキーワードばかり散見されて実質何がどこまで完成してるのか分からんのだが
SwiftはWin, *nix, Androidで普通に動くようになってるけど、Kotlinはそこまで至ってないんだよね？

**デフォルトの名無しさん** · 2017/07/03(月) 08:38:14.08

swiftって仕様安定したの？

**デフォルトの名無しさん** · 2017/07/03(月) 09:06:19.84

おおよそ

**デフォルトの名無しさん** · 2017/07/03(月) 09:13:44.93

Kotlin/NativeのCとの連携ってJNIを踏襲するんじゃなくて、現在進行形で独自I/F仕様を作ってるっぽいな
一応、Linux, Mac, Winで動くようだけど完成度はSwiftのがまだマシだ

**デフォルトの名無しさん** · 2017/07/03(月) 12:50:39.71

いまさらJNIはないだろ。
JVMの方も10か11でJNIに代わるNative対応が予定されているし。

**デフォルトの名無しさん** · 2017/07/03(月) 15:28:28.68

なおさら踏襲しとけよと思わなくもないな
Kotlin/NativeのNative I/F
Java9以前, KotlinのJNI
Java10以降のFFI
と仕様が乱立するのか・・・

Kotlinって仕様安定してないのな

**デフォルトの名無しさん** · 2017/07/03(月) 18:16:02.56

JNI踏襲とか無いわ
そうしたいなら普通にJava使っとけば良いと思う

**デフォルトの名無しさん** · 2017/07/04(火) 09:13:03.70

KotlinがJNIを踏襲していることは知らないのか、知ってて度外視なのか
Kotlin/NativeアゲのためにKotlinを蔑んでちゃどうしようもないな

**デフォルトの名無しさん** · 2017/07/04(火) 15:17:21.36

Kotlin/Javaが使うのは何でもないこと。
もしKotlin/NativeがJNI使うとしたら、それどこのXamarinだよってことだろｗ

**デフォルトの名無しさん** · 2017/07/04(火) 16:48:31.76

JNIのI/F踏襲して
external fun fgetc(file: CPointer) char;
とかでいいじゃんっつーね
externalの先はわざわざVM/Runtimeかます必要はなくてCに繋げればいい

Kotlin/NativeのNative I/FはC++に対応してないようだし
後発で新規に仕様を作り始めてる割にしょっぱいなぁと思う
C++に対応するならまぁアリかと思うけどないんだろうしね

**デフォルトの名無しさん** · 2017/07/04(火) 18:27:25.69

>Cに繋げればいい
ならJNI要らないじゃん
JNI踏襲ならJNIEnvの実装必須でしょ

C++対応とか正気かよ
C++同士でさえコンパイラやバージョン違いで
マングリングが異なってリンク不可能だからCリンケージ使うのに

**デフォルトの名無しさん** · 2017/07/04(火) 19:45:38.53

I/Fとランタイムの区別が出来てない
まぁ>>368とかもJavaとKotlinとKotlin/Nativeと区別してないからその程度なんだろうけど

> C++対応とか正気かよ
Rustのアホはbindgenって補完ツールで実現したぞ
他言語では見たことないから当然Kotlinもナイと思ってる, 後発なんだから検討はして欲しいけどねー

**デフォルトの名無しさん** · 2017/07/04(火) 19:58:52.39

javaに触らずにkotlinだけでandroid開発できるようになんないかな

**デフォルトの名無しさん** · 2017/07/04(火) 19:59:34.67

なればいいね

**デフォルトの名無しさん** · 2017/07/04(火) 20:44:06.85

>>373
>>365からの一連の流れはKotlin/NativeでのI/Fの話だぞ
区別云々は君が話の前提から混乱しているだけ

>bindgen
見たけどClang 3.9(～4.0)のマングリングを前提としてるから
ヘッダだけじゃなく実装本体もClangでビルドする必要があるようだが

完全なC++コードがある場合は使えるが、ABIの代わりにはならないだろう

**デフォルトの名無しさん** · 2017/07/04(火) 22:22:00.36

>>374
5年後にバージョン3とかになればなんとか…

**デフォルトの名無しさん** · 2017/07/05(水) 11:03:55.64

スマホアプリの言語ぐらい統一して欲しい
googleとappleで話し合えないのかねぇ
mac以外でもios用のアプリ製作からリリースまで最後まで出来るようにしてほしいよねぇ

**デフォルトの名無しさん** · 2017/07/05(水) 11:08:55.38

>>378
統一したいならC#

**デフォルトの名無しさん** · 2017/07/05(水) 12:07:39.48

Appleの昔から自分たちのプラットフォームにユーザーを囲いこんで、他のプラットフォームからの鎖国という考え方
Googleは自分たちのサービスを他のプラットフォームでも利用してもらってユーザーを増やし、収益を伸ばしたい考え方
統一でという方向で動く時、どちらがそれを拒んだり我を通した条件を突きつけてくるかは明白

**デフォルトの名無しさん** · 2017/07/05(水) 12:09:06.92

>>378
お互い何のメリットが？
開発者としても何のメリットも感じないが

**デフォルトの名無しさん** · 2017/07/05(水) 12:46:52.77

開発者として開発環境を統一できるメリットがあるだろうが

**デフォルトの名無しさん** · 2017/07/05(水) 12:51:04.90

>>382
開発側からすればwebフロントエンド系のように開発者余りまくりで単価デフレになるデメリットしかない

**デフォルトの名無しさん** · 2017/07/05(水) 14:04:19.57

>>378
ブラウザですら自分の思い通りに開発できないからってwebkitからblinkフォークさせたのに

**デフォルトの名無しさん** · 2017/07/05(水) 16:01:58.60

>>382
androidとiPhoneでフレームワークが違うから無理。

**デフォルトの名無しさん** · 2017/07/05(水) 16:10:10.15

>>378
react native とtypescriptに期待してる。
typescriptならサーバサイドにも耐えそう。言語仕様もパターンマッチング提案中だったり、
結構格好いい言語になってきた

**デフォルトの名無しさん** · 2017/07/05(水) 16:35:02.36

>>385
JVM言語で「iOSとAndroidを統一環境で開発できる」と言うのもなんかがっかりではある
君は一体歴史のどこを見てきたのかと

**デフォルトの名無しさん** · 2017/07/05(水) 16:42:58.42

>>383
金の話はまた次元の違う話かと思われる

**デフォルトの名無しさん** · 2017/07/05(水) 17:00:43.66

>>388
別次元？なにが？
ある側面だけみてメリットデメリットの話してもなんの意味もないやろ

**デフォルトの名無しさん** · 2017/07/05(水) 18:58:19.44

>>378
GoogleはAndroid開発環境を複数ＯＳ向けに出している

iOSアプリの公式開発環境がMac用しかないのはAppleが狭量なだけだし、Googleは無関係
話し合いで進展する問題ではない

**デフォルトの名無しさん** · 2017/07/05(水) 18:59:51.81

これはアスペ

**デフォルトの名無しさん** · 2017/07/05(水) 19:12:52.25

仮にAppleがiOSの開発環境をWindows向けに出すとして、iOSエミュレータはついてくんのか？っていう
Androidのような大真面目なエミュレータではなく、iOSはMac上でも「シミュレータ」しか動かん
それがWindows上で動かせるようになるとはあまり思わない

**デフォルトの名無しさん** · 2017/07/05(水) 21:24:57.18

技術の問題じゃなくて政治の問題だろ。

**デフォルトの名無しさん** · 2017/07/06(木) 07:36:12.02

>>376
JNIEnvが必須とか言い出すからIFじゃなくRuntimeの話を交え始めたと理解したが？

RustがclangでC/C++本体のコンパイルが必要だからNGなら
Kotlin/Nativeがclang等々でC本体のコンパイルを必要とするのもNGになっちまうだろw
他言語を他コンパイラでコンパイルするのは当然で、C++に限ってはその上でKotlin/Nativeが頑張るんだよ

**デフォルトの名無しさん** · 2017/07/06(木) 09:16:31.44

どうでもいいけど擬人化ことりんちゃんまだかよ
無能ども

**デフォルトの名無しさん** · 2017/07/06(木) 13:03:11.11

>>394
>IFじゃなくRuntimeの話
Javaからnativeを使う方のJNIは以下から成り、JNIEnvはJNI仕様の中核
　・CのABI
　・シンボル名と引数のルール
　　　　※ Java_パッケージ_クラス_メソッド(JNIEnv*, thisインスタンス, java側引数)
　・プリミティブ型の定義
　・JNIEnv(JNI関数群)のインターフェイス仕様

>clang等々
特定のコンパイラ/バージョン依存なのと, CのABI依存なのはまったく異なる

Kotlin/Nativeのinterop, JavaのJNI, C#のP/Invoke, RustのFFIなどはABIで連携するけど
bindgenはI/FでなくC++コード全体を取り込む外部ツール
Clangの実装に強く依存するからRustの仕様の一部として取り込まれることも無いだろう

誰かがKotlin版bindgenを作ろうとすることに特に反対は無いけどすべきとも思わない
Kotlin/NativeでJNIのI/Fを使う話も労力に見合うものは得られない

**デフォルトの名無しさん** · 2017/07/06(木) 13:14:33.18

>>394
追記
そもそも根本的な話としてCのABIと呼んでいるもの(↓と同義)が何か分かってる？

https://github.com/JetBrains/kotlin-native/blob/v0.1.0/INTEROP.md
>target is a C library

https://doc.rust-lang.org/book/first-edition/ffi.html
>C ABI

バイナリ内のシンボル名や呼出規約であって別にコード自体がC言語である必要は無い
C++(extern "C"), Rust, Haskellなどネイティブにビルド出来るものは
C ABIでのライブラリを作成する機能を持つものは多い

Cに無い機能(C++例外など)をそのまま透過出来ないというだけで、
C++やRustで作った共有ライブラリをKotlin/Nativeから呼べる

**デフォルトの名無しさん** · 2017/07/06(木) 17:54:27.44

なんでandroidのために新しい言語覚えなきゃいけないねん

**デフォルトの名無しさん** · 2017/07/06(木) 18:08:30.77

別にいいんじゃない？android使わなくても。

**デフォルトの名無しさん** · 2017/07/06(木) 19:00:34.42

汎用言語が Android では使えないというのは制約だろう。

**デフォルトの名無しさん** · 2017/07/06(木) 20:22:03.24

不満はあってもJavaよりはずっと良い

**デフォルトの名無しさん** · 2017/07/06(木) 23:28:02.58

呼出規約には、2種類ある

呼び出した方で、引数のスタック領域の確保・解放をするものと、
呼び出された方で、するもの

**デフォルトの名無しさん** · 2017/07/06(木) 23:43:32.25

さらには引数を後ろからスタックに積むもの、前から積むものもってのもある。

**デフォルトの名無しさん** · 2017/07/08(土) 16:04:44.48

萌えキャラKotlinたんの誕生まだ？

**デフォルトの名無しさん** · 2017/07/08(土) 17:26:45.29

>>396
なんか長々書いてるけど、結局新規のIF, 文法切っても現仕様はSwift同程度なんだよね
中身がどうあろうがいいけどショボい機能しか載せられないなら、Kotlinの上っ面IFだけはKotlinとKotlin/Nativeで共通化して欲しかったって話だよ

まぁ絶賛開発中の言語仕様だし期待しないで気長に待つわ

**デフォルトの名無しさん** · 2017/07/08(土) 19:34:40.80

しょっぱいだのショボいだのディスるのは簡単だが
浅い知識と考えでそれを言うのは恥ずかしいことだと少しは自覚しろよ・・・

**デフォルトの名無しさん** · 2017/07/09(日) 10:04:20.42

>>398
Kotlinは簡単な言語だからいいでしょ

**デフォルトの名無しさん** · 2017/07/09(日) 12:16:36.95

構文糖衣が多くてperlみたいな雰囲気を感じないでもない

**デフォルトの名無しさん** · 2017/07/09(日) 12:55:49.42

await使えるようになるだけで移行したいわ

**デフォルトの名無しさん** · 2017/07/09(日) 14:03:09.85

xamalin使えばいいじゃん

**デフォルトの名無しさん** · 2017/07/09(日) 22:15:33.42

>>408
>構文糖衣が多くてperlみたいな雰囲気を感じないでもない
カッコとかなしでむき出しで書かれる A keyword B みたいな構文はどうにも慣れないね
A.method(B)やfunction(A,B)と同じはずなんだが、空白という文字で区切られていると脳が一瞬括りを拒否する

**デフォルトの名無しさん** · 2017/07/10(月) 13:10:30.69

>>406
最初(>>367の時点)からKotlin層の文法だけを注視してて、C層は気にしてないからなぁ
Kotlin層の共通化が大変な訳でも無し、わざわざ大変な新規IF切ってしょぼい機能になってるのは恥ずかしいよ

**デフォルトの名無しさん** · 2017/07/10(月) 13:34:33.04

>>412
何何どういうこと？
まだkotlinは遠くから眺めているだけだから気になる？

**デフォルトの名無しさん** · 2017/07/10(月) 23:27:47.39

>>412
C層を気にしてないんじゃなく知らないだけだろ
だから「わざわざ大変な新規IF」なんて的外れなレスをすることになる
JNIライブラリを書いたことすら無さそうだし

良案と思っているものがあれば↓で提案してみたらどうだ？
https://discuss.kotlinlang.org/
鼻であしらわれるのがオチだが

**デフォルトの名無しさん** · 2017/07/11(火) 02:41:16.53

言語なんて色々あるんだから自分の好きなの選んだらええんやで
Androidに正式採用されてから一気に書き込み増えたな

**デフォルトの名無しさん** · 2017/07/11(火) 03:44:11.61

>>414
別にKotlinがそこまで好きなわけじゃないし、ここでKotlin/Nativeの喜劇を鼻で笑ってた方が楽だし・・・
業務でJNIを書いてたのは15年くらい前の1.3の頃だねぇ、あの頃はJNIはC++が使えなくてラッパー層の実装も面倒だった
いつからか知らんけど、JNIEnvにC++ APIが追加されててC層の実装が楽になってて数年前にビビったわ

・・・と老害なレスしとけば、論点ズラして技術論から離れた場外乱闘になって俺が飽きれるだろ

**デフォルトの名無しさん** · 2017/07/11(火) 11:50:37.31

>>413
Kotlin
--
external fun sayHello();
System.loadLibrary("hello")
sayHello() // C API呼び出し

Kotlin/Native
--
import kotlinx.cinterop.*
sayHello() // C API呼び出し
// 別途、defファイル, gradleファイルを用意

Kotlin/Nativeはexternal funを宣言しないでシームレスにC APIを利用させるために、KotlinからIF構成を変えてる
external funの宣言がなくなった分だけKotlin層の記述は楽になったけど
代わりにdef, gradleが必要で、Kotlinと互換性なくて、C++ APIは呼べないという制限がある

そこまで変えるなら、頑張ってC++ API呼べるようにして欲しいなーって冗談半分で言ったら噛み付かれた

**デフォルトの名無しさん** · 2017/07/11(火) 12:19:57.03

プログラマの勉強しようとおもってますが、これはジャバとなにがちがいますか？
大差ないようであればこれを勉強しようおおもいます

**デフォルトの名無しさん** · 2017/07/11(火) 12:23:20.73

>>418
Javaとの大きな違いは、Javaを完全に理解してる人向けで初心者向けの情報がほぼゼロという点

**デフォルトの名無しさん** · 2017/07/11(火) 12:38:05.79

ObjCというマイナーで黴の生えた言語がiOS開発入門の障害になっていたところに現れたSwiftとは違い、
Javaは開発者ならはっきり言ってできて当然なので今後も初心者向けの情報の充実は望めない

**デフォルトの名無しさん** · 2017/07/11(火) 12:44:27.43

Android入門は今後kotlinベースになるだろ。

**デフォルトの名無しさん** · 2017/07/11(火) 13:43:49.66

それ頼む。javaのライブラリに依存すると言ってもandroid似関係するのはごく一部でしょう？
フルセットのjavaを学ぶ必要ないよね

**デフォルトの名無しさん** · 2017/07/11(火) 14:41:08.33

>>418
Kotlinは話題になってはいるが「Java言語を使いこなしている人がその知識を使うと楽に書ける」ので好評を得ている
Java言語を全く知らないのであればKotlinはむしろ二重三重の習得障壁があるので勧められない
なにするかもぜんぜんわからないし現実世界で聞ける師匠もいないというのならJavaでいいんじゃないかな

JavaなしでのKotlin学習術というのは数年したら出てくるとは思うがそれはKotlin本体の充実も待たねばならんのでしんどい

**デフォルトの名無しさん** · 2017/07/11(火) 15:36:02.36

>>417
随分トーンダウンしたなｗ

>Kotlin/NativeのNative I/FはC++に対応してないようだし
>後発で新規に仕様を作り始めてる割にしょっぱいなぁと思う
　↓
>頑張ってC++ API呼べるようにして欲しいなーって冗談半分で言った

そもそもKotlin(JNI)との互換性の話にC++は関係無いだろう
JNIでもエクスポートする部分はextern "C"なんだから

**デフォルトの名無しさん** · 2017/07/11(火) 17:16:47.08

おう、そうだなｗ
それでKotlin/NativeのIFの話はどうした？論点ズレてんよ

**デフォルトの名無しさん** · 2017/07/11(火) 18:38:24.21

>>425
日本語が不自由なのか？
「Kotlin(JNI)との」と書いているんだが

**デフォルトの名無しさん** · 2017/07/11(火) 21:08:20.35

僕Javaはちょっとしか使ったことないLisperだけど、Kotlinサクッと学んでAndroid開発してるよ？難しくないよ？

**デフォルトの名無しさん** · 2017/07/11(火) 21:13:00.00

LISPerが書くコードとか他人が読めなそうやな

**デフォルトの名無しさん** · 2017/07/11(火) 23:22:21.14

>>423
javaのエコシステムが学習障害なのかな。歴史がある分根深そう
gladleとかいうタスクランナー用に専用言語あるんだっけか

**デフォルトの名無しさん** · 2017/07/11(火) 23:23:35.24

swift、typescriptと触ってoptionalが無い言語は正直触りたくなくなっとる。

**デフォルトの名無しさん** · 2017/07/12(水) 06:26:01.18

>>418
Kotlin = Java + Groovy

Javaのオブジェクト指向に、Groovyの関数型を付けたもの。
クロージャを多用する

まずこの本で、Javaとオブジェクト指向を学ぶ
スッキリわかる Java入門第2版、2014

その後、
プログラミング GROOVY、2011
Kotlinスタートブック -新しいAndroidプログラミング、長澤太郎、2016

**デフォルトの名無しさん** · 2017/07/12(水) 06:44:11.99

KotlinはGroovyはあんまり関係ないだろ
機能的にはC#をリスペクトしていて、文法はScalaを簡略化したもの

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

>>432
さわっちゃだめよ

**デフォルトの名無しさん** · 2017/07/12(水) 08:14:26.72

C#の思想でScalaを再設計した感じだな

**デフォルトの名無しさん** · 2017/07/13(木) 00:38:10.55

メソッドの最後の引数にクロージャを書いて、
そのクロージャの中のメソッド呼び出しの最後の引数にクロージャを書いて・・・
って感じの記法でDSLを作れるのが ruby から groovy 経由で kotlin に引き継がれた特徴かね？
gradle の build.gradle みたいな奴ね

これを引き継いでる関係で build.gradle を kotlin で書けるのがもう実装されてる
Androidのレイアウトを kotlin のこの DSL 記法で書けたりもするね

**デフォルトの名無しさん** · 2017/07/13(木) 01:28:56.84

>>435
その辺はほぼScalaだよ

**デフォルトの名無しさん** · 2017/07/13(木) 10:30:47.12

最近の言語はどれもよく似てるだろ
Swiftにも似てると思ったし

**デフォルトの名無しさん** · 2017/07/13(木) 10:37:01.80

>>436
そりゃあscalaは何でもてんこ盛りだから同じことできるだろうけど、
公式がGroovy-styleって言ってるんだよね

Type-Safe Groovy-Style Builders
https://kotlinlang.org/docs/reference/type-safe-builders.html

**デフォルトの名無しさん** · 2017/07/14(金) 05:04:39.07

>>437
Swiftより古い言語なんだよなぁ…

**デフォルトの名無しさん** · 2017/07/14(金) 09:50:43.08

>>426
> そもそもKotlin(JNI)との互換性の話にC++は関係無い
KotlinとKotlin/NativeでNative I/Fを変えるなら、Kotlin/NativeでC++ APIをシームレスに使いたい、けど実現しないだろうねー
って笑い話をしてるのに、JNIEnvがーとか、JNIやったことないだろーとか関係ないこと言い出した子に言われても・・・
素直に、clangに依存するrustと違って、kotlin/nativeは特定C/C++コンパイラに依存しない選択をしたんだ、で良いだろうに

SwiftがKotlinのOptionalをパクったって、それ一番言われてるから
ここ10年の新興言語はお互いにパクリあってるからもう何が大元か分からなくなってるよね

**デフォルトの名無しさん** · 2017/07/14(金) 11:53:31.95

>>440
実現していないことに対し「しょっぱいなぁと思う」「ショボい機能」と罵ることと
「けど実現しないだろうねーって笑い話」というのは
お前の中では同程度の表現なのか？

**デフォルトの名無しさん** · 2017/07/14(金) 11:59:48.94

>>440
I/Fの話というだけで、JNI踏襲とC++対応は別々の話で関係無いだろ？
だから>>371に対しての>>372は改行で分けている

>>417といい、そのレスといい何故混ぜて話そうとするんだ？
「JNI踏襲するか、しないならC++対応」という思考のようだが
どちらも愚案だと言ってるだけだぞ

外部ツールとしてC++→Kotlinの変換ツールなら否定しないが