Kotlin 6

**デフォルトの名無しさん** · 2019/06/22(土) 15:59:57.23

JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/

**デフォルトの名無しさん** · 2019/10/09(水) 21:58:29.86

Swiftのコードを移植しやすくするために、プロトコルを移植する術を用意して欲しいな

**デフォルトの名無しさん** · 2019/10/10(木) 07:03:41.74

>>334
スマホや、インターネット使ってる癖に？w

**デフォルトの名無しさん** · 2019/10/10(木) 09:44:34.71

>>334
今回ノーベル賞貰った人のIQは150未満だったのか？
電池使いやすいぞ。入れとくだけだし。

**デフォルトの名無しさん** · 2019/10/10(木) 09:47:43.02

ま、しかし、大人のIQって一体何を基準にして出すのか謎だな。子供ならまだわかるんだが。

**デフォルトの名無しさん** · 2019/10/10(木) 09:58:04.45

IQ = 偏差値 x 2

**デフォルトの名無しさん** · 2019/10/10(木) 10:06:40.36

>>341
その前にfunとfuncを統一して欲しかった
いまだにとっさにどちらだか分からなくなる

**デフォルトの名無しさん** · 2019/10/10(木) 12:54:39.50

>>345
そうするって決まってるの？どこで決めた？

**デフォルトの名無しさん** · 2019/10/10(木) 13:15:24.31

>>347
そう固い頭だと色々無理ですわ

**デフォルトの名無しさん** · 2019/10/10(木) 13:24:45.83

偏差値50でIQ100
50前後だと合ってるが端の方は違うだろうな

**デフォルトの名無しさん** · 2019/10/10(木) 21:06:55.89

>>348
そうか。

とりあえずWikipediaで「知能指数」を見てみることをおすすめする。
16歳ぐらいまでしかちゃんとした測定はできないと考えて良い。

**デフォルトの名無しさん** · 2019/10/10(木) 21:14:30.21

>>345
俺メンサに入れるかも

**デフォルトの名無しさん** · 2019/10/10(木) 22:10:25.98

>>346
ぱっと見ただけでどの言語のコードかわかるので、悪い話ばかりではない。

**デフォルトの名無しさん** · 2019/10/23(水) 00:35:02.53

kotlinがサーバサイドで動く日は来るのだろうか

**デフォルトの名無しさん** · 2019/10/23(水) 02:08:32.92

とっくに動いてるけど？

**デフォルトの名無しさん** · 2019/10/23(水) 07:52:04.30

うちの

**デフォルトの名無しさん** · 2019/10/23(水) 13:23:08.82

サーバかどうかに関わらず動くと言えば動く

**デフォルトの名無しさん** · 2019/10/23(水) 13:25:26.53

ていうかだな、VMのレベルでJavaとの互換性あるんだからJavaでできることはなんでもできるよな。
互換性というかJavaバイトコードそのままなわけだが。

**デフォルトの名無しさん** · 2019/10/24(木) 23:51:39.67

何で誰もscalaのライブラリ移植してくれないんだ？

**デフォルトの名無しさん** · 2019/10/25(金) 08:03:33.95

>>358
JavaからScalaを呼び出せるはずだから、Kotlinからも呼び出せるのでは?

**デフォルトの名無しさん** · 2019/10/29(火) 19:28:43.34

bit演算子がand/orで、conditionalの方が&&/||って紛らわしいな。

**デフォルトの名無しさん** · 2019/10/30(水) 09:41:04.16

>>360
伝統的に BASIC言語では、and, or が条件分岐(BOOL)用だったので、
混乱しそうですね。

**デフォルトの名無しさん** · 2019/10/30(水) 10:21:31.19

単語と記号の混在が紛らわしいって話でしょ
VB系がAndとAndAlsoで、C系が&と&&で一貫しているのに対して、Kotlinはandと&&の組み合わせを選んでて言われてみると少し変
andはメソッドで&&は演算子だから差別化したかったというなら理解できるが、andを演算子オーバーロードしなかったのは何でだろうな
notはしてるのに

**デフォルトの名無しさん** · 2019/10/30(水) 10:32:29.86

VBではAndもAndAlsoも、条件分岐用(BOOL系)で、AndAlsoが、
C での&&相当なんですね。x And y も C のx && yに近いが、
xが偽の場合でもyを評価してしまうところが && と違う。
そこで && と同じ動作を行わせるために導入されたのが AndAlsoと。

**デフォルトの名無しさん** · 2019/10/30(水) 16:18:46.97

Pythonは、kotlinとは反対だな。
and/orはいかにも文章的で、こっちの方がしっくりくる。

**デフォルトの名無しさん** · 2019/10/30(水) 17:38:05.90

それに、&& や || は長さも & や | より長いので、少し長い and, or と対応し易い。
後やはり、伝統的なBASIC言語との互換性は重要だ。そっちを覚えている人は
世界では沢山入るはず。特にアメリカ。

**デフォルトの名無しさん** · 2019/10/30(水) 17:38:32.15

>>365
誤：世界では沢山入るはず。特にアメリカ。
正：世界では沢山いるはず。特にアメリカ。

**デフォルトの名無しさん** · 2019/10/30(水) 20:40:57.63

and, orは値によっては計算を評価しないというifの役目もしてるから
ほかの演算子と一緒くたにするのは気分が悪かったのかもしれない

とおもったけど&&使ってもandと評価される項目一緒だっけ

**デフォルトの名無しさん** · 2019/10/31(木) 06:45:28.23

Kotlinの言語開発者は、andとorは拡張関数で実装すればKotlinの文法の範囲内で文章的に書けると思ったのかも。
ただ、>>367が指摘するように拡張関数のand, orは短絡評価がないから
&&, ||とは同じ動作にならない上にパフォーマンスも若干落ちるという残念な仕様に。
将来的に短絡評価するアノテーションとかを作れば何とか出来ると思っているのかいないのか。

**デフォルトの名無しさん** · 2019/10/31(木) 07:22:01.32

>>368
短絡評価しないから残念というものではなく副作用を考えて使い分けるものだよ
だから多くの言語ではわざわざ2種類用意されてる
前段については同意だがやはりなぜ演算子オーバーロードしなかったのか疑問

**デフォルトの名無しさん** · 2019/10/31(木) 11:07:41.22

ビット演算と論理演算の違いって>>360が書いてるやろ
ビット演算を短絡評価のない論理演算と捉えてるやつが多くてオシッコちびるわ

**デフォルトの名無しさん** · 2019/10/31(木) 19:32:54.61

kotlin使ったことないもので

**デフォルトの名無しさん** · 2019/10/31(木) 20:48:39.66

ビット演算と論理演算の違いはC C# Javaとかでも同じっすよ
言語仕様を広げたくなかったんじゃね

Kotlinのandとかは言語仕様に無くて単なる標準ライブラリの関数扱いだし

**デフォルトの名無しさん** · 2019/10/31(木) 20:58:37.80

>>371
ただちに使いなさい。

**デフォルトの名無しさん** · 2019/10/31(木) 22:36:23.90

>>369
演算子オーバーロードを許すと、Int, Boolean等以外のLocalDateTimeのようなプリミティブでない
クラスにまでユーザーが論理演算(もしくはビット演算)を定義できてしまうから
好ましくないと思ったのかなと。

>>370
Booleanに限って言えばビット演算と論理演算は(短絡評価を除けば)等価なはず。
Booleanとand, orを組み合わせれば、(短絡評価の問題を除けば) &&, || が不要になる。

**デフォルトの名無しさん** · 2019/11/01(金) 00:09:01.18

>>374
notやplusは演算子オーバーロードしてるのにandがしてないのが疑問だと言っているんだよ

**デフォルトの名無しさん** · 2019/11/01(金) 01:05:00.03

>>375
何を言っても推測にしかならないけど、一つは&&の短絡評価を演算子オーバーロードで再現できないからではと思う。
a && b が bがBooleanかどうかでbが評価されるかどうかが変わるということを避けたかったのではと。
もう一つは、>>372の言うように言語仕様を最低限にしようとしたのではと思う。
Kotlinはシフト演算を見る限り、ビット演算しようとする人には優しくない気がする。
>>375がandでオーバーロードしたかったのが&か&&かはっきりしないけど、少なくともどちらか一つは答えになっているかと。

**デフォルトの名無しさん** · 2019/11/01(金) 01:21:46.87

「演算子オーバーロードしなかった」の意味がよくわからない
&演算子が無いことの話なのか、オーバーロード出来るかどうかの話なのか

後者なら単なる関数なので普通に出来るけど
class A(val s:String) { override fun toString() = s }
infix fun A.and(o:A) = A("${this.s}∩${o.s}")
fun main(args: Array<String>) = println( A("x") and A("y") )

**デフォルトの名無しさん** · 2019/11/01(金) 09:34:45.45

演算子がないことを、演算子オーバーロードしてないと言ってるんだろう

https://github.com/Kotlin/KEEP/issues/142
中の人は演算子提供するのに乗り気じゃなさそうだけどそのうち追加されるんじゃないか
shl/shrとかわかりにくいしand/orも他言語から来ると思考ノイズでしかない

**デフォルトの名無しさん** · 2019/11/02(土) 17:53:52.29

ビット演算するとき、|=、&=って激しく便利だし頻出だと思うんだけどなぁ。

**デフォルトの名無しさん** · 2019/11/02(土) 18:52:11.73

そもそも複数のbooleanで扱うべきフラグをビット演算で1つにしてるAPI設計が良くない説

**デフォルトの名無しさん** · 2019/11/03(日) 06:01:49.39

>>380
ハードウェアがそうなってるのだから仕方なかろう。
いっぺんに書き換えないと挙動が変わってしまう

**デフォルトの名無しさん** · 2019/11/08(金) 01:15:52.84

しーん

**デフォルトの名無しさん** · 2019/11/16(土) 20:04:36.15

ｊａｖａﾗｰがｺﾄﾘﾝに乗り換える勉強するのにどれくらい移行期間かかります？

**デフォルトの名無しさん** · 2019/11/16(土) 20:26:59.99

1年働く

**デフォルトの名無しさん** · 2019/11/16(土) 20:43:38.98

>>383
君の全角半角のセﾝスからするとだな

**デフォルトの名無しさん** · 2019/11/16(土) 22:11:24.92

超天才でスーパーな人なら入門書パラパラめくって眺めて30分ぐらいかな

**デフォルトの名無しさん** · 2019/11/16(土) 22:13:58.74

1時間後にはもっと凄い新言語に閃いて作りはじめる

**デフォルトの名無しさん** · 2019/11/16(土) 23:33:33.74

java -> kotlin変換しますか？
Y?/N?

Y -> 数秒まて

**デフォルトの名無しさん** · 2019/11/17(日) 00:14:20.35

それだと !! がたくさん残るしそもそもビルド通らない

**デフォルトの名無しさん** · 2019/11/17(日) 09:48:27.71

そっから手直しすればいいんじゃない？？
無駄が多いし効率も悪いけど…

**デフォルトの名無しさん** · 2019/11/17(日) 11:45:54.92

3日で慣れる

**デフォルトの名無しさん** · 2019/11/17(日) 17:31:59.24

あれ？forループで変数インクリメントするようなのできねーじゃん。なに？while使ってやれっての？えー！

ってなってから、なーんだ (a..b).forEach { } でやりゃあいいんじゃん。
と、気づくまでに3日以上掛かった。

**デフォルトの名無しさん** · 2019/11/17(日) 17:34:56.22

ていうか for (n in a..b) でもいいのだが、a..b が Range になっててあとはコンパイラが自動でうまいことやってくれる事に気づかなかった。

**デフォルトの名無しさん** · 2019/11/17(日) 23:38:24.23

ひとまず小一時間感覚で書いてみるのは良いとしても
言語リファレンスを一通り流し読みする時間をどこかで確保しないとな
https://kotlinlang.org/docs/reference/idioms.html

**デフォルトの名無しさん** · 2019/11/19(火) 06:21:31.09

!!ってダメなのか？
むしろ入れて解決してるんだが…w

**デフォルトの名無しさん** · 2019/11/19(火) 09:50:11.74

!!は全部消さないとダメ

**デフォルトの名無しさん** · 2019/11/19(火) 09:55:32.18

>>395
ダメじゃないけど沢山あると嫌な感じ

**デフォルトの名無しさん** · 2019/11/19(火) 10:47:58.28

Kotlin 1.3.60 リリース
https://blog.jetbrains.com/kotlin/2019/11/kotlin-1-3-60-released/

**デフォルトの名無しさん** · 2019/11/19(火) 14:30:37.08

なぜどうしてもそこに必要なのかを説明できない!!は書いてはならない
あとあと絶対にそこでコード的にまたは仕様的にバグるから、むしろ遠回りになる

**デフォルトの名無しさん** · 2019/11/19(火) 16:25:17.02

null許容変数がnullになるかもしれないから!!なんじゃないの？
そういう認識なんだが

**デフォルトの名無しさん** · 2019/11/19(火) 16:29:22.93

val a = ThreadLocal<String>().get()
val b:String = a //暗黙の a!!

**デフォルトの名無しさん** · 2019/11/19(火) 19:32:30.25

!!は全部消すべき

**デフォルトの名無しさん** · 2019/11/19(火) 19:39:12.55

>>400
動作の説明としては全くその通り
しかしそれをコードに適用するデメリットが大きいので全世界中からやめと毛と言われている

**デフォルトの名無しさん** · 2019/11/19(火) 21:21:13.73

毛

**デフォルトの名無しさん** · 2019/11/19(火) 23:23:22.22

>>403
nullになるかも？なだけで実行順を追っていくとならないことが多いからそのままにしている
必要なら対策するけど、ほとんどの場合は実行タイミングに何か値が入ってる
変に怖れて潔癖にならない方がいい

**デフォルトの名無しさん** · 2019/11/20(水) 00:18:44.73

!! は、絶対に、null にならない場合だけに使うべし！
notnull

強制キャストと同じ

**デフォルトの名無しさん** · 2019/11/20(水) 00:47:14.79

例外が発生するから!!が良くないと考えているならそれはnull安全を履き違えている
重要なのは区別することで、どう処理するかは要件次第

処理のタイミングで非nullであるべき変数なら
ガード節、requireNotNull、!! などによって早期にスマートキャストすべき
そのような箇所で不用意にセーフコール(?.)を使うことはいわゆるエラーの隠蔽に繋がる

nullが正常系の内ならもちろんセーフコールなりエルビスなりで問題無い

**デフォルトの名無しさん** · 2019/11/20(水) 00:51:02.81

!!はforce unwrapと呼ぶべし!!
!!演算子に名前を付けない言語は滅ぶべし!!

**デフォルトの名無しさん** · 2019/11/20(水) 00:53:35.65

>>408
Kotlin公式では not-null assertion operator とある
Swiftと合わせた方が分かりやすいとは思うけどな

**デフォルトの名無しさん** · 2019/11/20(水) 01:40:06.34

例えば画像Aを表示する座標x,y
初期値を画面外の-500,-500にしておけば!!は消せるけど
画面外に表示ってリソースの無駄
これを良しとするやつは複数の画像を画面外に常に表示している
逆にメモリ足らなくなって落ちない？
使わない場合はnullでよくね？
読込みに時間かかるなら初期値設定するのもありだけど
あくまで重い画像を複数使用する例なんだけどnullを悪としてとらえず利用しようよ
上記の理由により、!!潔癖症はただ邪魔なだけ

**デフォルトの名無しさん** · 2019/11/20(水) 02:09:26.97

!!を使わなくても安全に実装できるのにあえて!!を使うのは頭が悪いですと言っているようなもの

**デフォルトの名無しさん** · 2019/11/20(水) 07:14:57.99

ファイルヘッダとかにマジック定数あるが、これを表現するには
val hoge = arrayOf('a','1').map { it.toByte() }.toByteArray()

みたいな悲しいことしないといけないのでしょうか?

それとkotlinで一般的なバイトバッファを表現するにはByteArrayつかっておけば間違いなないでしょうか?

**デフォルトの名無しさん** · 2019/11/20(水) 07:18:15.00

今はJVM環境で使ってますが、一応コード書くときに、特定のプラットホームに依存しないように書けるとこは書こうと思います

ちょっとつっぱしてByteArrayじゃなくてexperiment なUByteArrayを使おうと思いますが

**デフォルトの名無しさん** · 2019/11/20(水) 07:47:32.01

>>411
なぜ使うべきでないのかを説明出来ない限り、議論の出発点にも立っていない

例えば俺は>>407で書いた順の通りガード節、requireNotNullの方が
より明示的かつメッセージ付加可能でなので!!より優先すべきと考えるが
本質的には大差無い

NullObjectパターンは有用ではあるが
セーフコールがあるKotlinでは必ずしも必要としない
そのようなケースはnullが正常系の内であるのと同義

**デフォルトの名無しさん** · 2019/11/20(水) 09:35:14.21

>>410
使わない場合はnull、っていうケースは文字通りガード節や?.を使って
nullならなにもしない場合、と同義なのでは
!!を使うべき例としてはピンとこない

!!を使っている関数は引数つまり関数の仕様としては一見null許容型だけど、実装としてはnullを拒絶する不整合がある
何らかの事情で回避が難しいときの苦肉の策で、多用するのは作りが悪いように思う

あとは関数内で既に非nullであることが保証されてるパスの中にいる場合の簡略化で使うか
でもこれを多用するようなら関数が長すぎるという問題を暗に抱えていたり
安全や可読性よりも手抜きを選ぶ悪癖の疑いを感じる

**デフォルトの名無しさん** · 2019/11/20(水) 11:41:13.79

!! null即エラー演算子。
force unwrapでは全く本質を言ってない。

**デフォルトの名無しさん** · 2019/11/20(水) 12:48:32.17

>>414
型安全でないnullを使うこと自体が問題。
!!も、使う前に型安全なnullobjectを検討すべき。

**デフォルトの名無しさん** · 2019/11/20(水) 14:43:02.05

!!を使うやつとは一緒に仕事したくない

**デフォルトの名無しさん** · 2019/11/20(水) 15:16:56.32

なんだと!!

**デフォルトの名無しさん** · 2019/11/20(水) 15:29:37.98

>>419
ちょっとワロタw

**デフォルトの名無しさん** · 2019/11/20(水) 17:12:40.65

val なんだと: Int? = null

**デフォルトの名無しさん** · 2019/11/20(水) 22:37:14.64

checkNotNull(nullable) { "説明" } がいいんだろうけど、!! で楽したくなる時がある

>>412
byteArrayOf が使いたいって言ってる？

**デフォルトの名無しさん** · 2019/11/20(水) 23:09:14.16

絶対nullにならないなら型変えるべき

**デフォルトの名無しさん** · 2019/11/20(水) 23:19:54.39

>>410
もし遅延初期化、lateinit が使えるなら、その方がよい

**デフォルトの名無しさん** · 2019/11/21(木) 00:03:38.40

java のライブラリの @Nullable とか、json で条件によって null / not null が切り替わるプロパティとか

**デフォルトの名無しさん** · 2019/11/21(木) 02:18:34.58

!!使うやつは馬鹿でFA

**デフォルトの名無しさん** · 2019/11/21(木) 03:55:49.74

ならなんであるんだろう

**デフォルトの名無しさん** · 2019/11/21(木) 04:20:54.23

あたたたたたたたひでぶ!!

**デフォルトの名無しさん** · 2019/11/21(木) 06:28:21.69

>>427
nullableな値を返す外部の関数について、文脈上nullが返らないことが保証できる場合にまで
null対応を書くのは、可読性やパフォーマンスの上で無駄が多いからだと思う。
特にJava(あるいはJavascriptやnative)由来の関数とか。

**デフォルトの名無しさん** · 2019/11/21(木) 06:34:18.07

>>429
誤解されそうなので補足。
1行目の「外部」っていうのは3行目のKotlin外という意味ではなくて、
標準ライブラリを含めて他人が作ったライブラリという意味です。

**デフォルトの名無しさん** · 2019/11/21(木) 06:56:28.51

そのkotlinの存在意義ぶち壊す特異性からしても、どーしても仕方なく使うものであるのだけど
エラー消すおまじないみたいなノリで初心者から中級者が使うので戒められている次第
あと、感染するんだコレ

**デフォルトの名無しさん** · 2019/11/21(木) 07:43:43.53

>>426 >>431
requireNotNullは？

**デフォルトの名無しさん** · 2019/11/21(木) 08:03:18.32

1.3.60出てたから久しぶりにkotlin native試してみたらhello,worldのコンパイル時間が更に伸びてた！
10秒→16秒！
何か早くする方法ないの？

**デフォルトの名無しさん** · 2019/11/21(木) 08:04:59.80

>>432
値チェックに使う字面だからいいのでは

**デフォルトの名無しさん** · 2019/11/21(木) 08:06:53.77

実行タイミングが来るまで置いておくだけの関数の中で使う変数は、その関数を実行する前までnullでいいよな？
そういう理由で!!のままにしてるんだけど!!潔癖以外の意見が聞きたい、ロジカルな理由を
その会社の規約なら!!使わないけど
使っていけないならそもそもビルド通らんだろ

**デフォルトの名無しさん** · 2019/11/21(木) 08:38:35.83

>>435
型安全が破綻するのでnullobject定義して使っとけ。

**デフォルトの名無しさん** · 2019/11/21(木) 08:53:15.49

>>433
所詮はオモチャなんだからどうでもいいでしょ
JetBrainsとしてもまだコンパイル時間の最適化なんか気にする段階じゃないだろうし

**デフォルトの名無しさん** · 2019/11/21(木) 08:54:35.85

状況が限定されるが、あるクラスがnull相当の状態をとりうるメンバ変数を持っていて
その値がnullのときに呼んだらバグとして例外を出したいメソッドがあるときは
!!を使ってもいいかなと思う

requireNonNullのほうが可読性と保守性でベターだけど本質的には大差ない
残念な!!の使い方ではないんですよと表明している程度（それが重要でもあるわけだが）

NullObjectパターンは必ずしも良い置き換えにはならない
NullObjectかどうか忘れず判定してIllegalStateExcptionを投げなければならない状況になるくらいなら
nullチェックを言語仕様で強制されるほうが手が掛からず安全性も高い
上でも言われていたが例外も何も出ずにバグがしれっと埋もれるほうが危険

**デフォルトの名無しさん** · 2019/11/21(木) 09:05:08.85

require と check の使い分けちゃんとしとけよ

**デフォルトの名無しさん** · 2019/11/21(木) 10:47:03.33

>>438
オモチャだから発売日が気になっちゃう精神やん