Kotlin 6

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

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

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

**デフォルトの名無しさん** · 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
オモチャだから発売日が気になっちゃう精神やん

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

>>435
ものによる。初期化しないとか by lazy にするとか他の方法があるならそちらを使う方が良いかも知れない。

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

nullのまま素通りさせたくない場合は
!!でなくcheckNotNullやrequireNonNullを使えばOK？

このコードの3つ目のように
https://paiza.io/projects/Ao4mGnYxwoWEuMNRtj_gkg

**デフォルトの名無しさん** · 2019/11/21(木) 13:52:56.76

香ばしくなってまいりました

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

!!を使うやつを絶対に許してはいけない

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

明日の朝刊載ったゾテメー!!

**デフォルトの名無しさん** · 2019/11/21(木) 15:30:07.46

>>438
nullには型チェックが働かないことを忘れちゃいかん。

nullobjectじゃなくてnullがきたときは型チェックでエラーにできるんだから、nullobjectを使ったほうがいい。

**デフォルトの名無しさん** · 2019/11/21(木) 16:27:17.17

!!潔癖症でもいい
変更方法さえ教えて頂けるなら
それに従い変更します

**デフォルトの名無しさん** · 2019/11/21(木) 16:37:36.16

Kotlinプログラマーは未だにforce unwrappingの使いどころを知らない
NullObjectのメリットデメリットも知らない
ということはよ～くわかった

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

>>444
>432と>>442についても意見が欲しい

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

>>448
nullobjectのデメリットって、null汚染されたクラスの再利用が面倒なことくらいじゃない？
他になんかある？

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

NullObjectのデメリット？
「オナニーとしては気持ちいいが、実際の開発において便利なシーンがほとんどない」
これに尽きる

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

>>451
オナニーとして気持ちいいなら誰でも使うだろ。
そんなこともわからない無能かぁ……

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

あるデータが有限の数値をとる場合と
値なしの特殊な状態をとる場合があるとする
その厄介さってのは多くの場合、処理の場合分けが必要ってところにある
ヒトがそういう分岐を書き忘れがちなのはご存じの通り
その結果もあって多くのプログラマはNPE恐怖症になったが、NPEを回避することが目的になっても意味がない
NullObjectの多態性やアルゴリズムの妙で分岐を潰せるならベスト
だがそうでない場合、むしろ分岐を書き忘れたとき、下手なNullObjectはフェイルファストのメリットを失うことがある

**デフォルトの名無しさん** · 2019/11/22(金) 08:14:50.32

nullセーフな言語におけるNullable型の素晴らしい点は
そのままではメソッドを呼び出すことができず
特殊値に対し場合分けの判断が必要ではないかとヒトに思い出させてくれること
不適切な!!はこれを台無しにする
不適切なNullObjectも同じで、より厄介なバグ隠蔽をもたらす

**デフォルトの名無しさん** · 2019/11/22(金) 09:18:52.84

>>454
requireNotNullやcheckNotNullも同じく台無しにする？
それともこっちは良い？

**デフォルトの名無しさん** · 2019/11/22(金) 10:51:25.32

!!のほうが2文字だし、ここでヌルポが上がるかもと分かるので好き

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

念のため書いておくとKotlin標準ライブラリの関数のことね
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/check-not-null.html

**デフォルトの名無しさん** · 2019/11/22(金) 15:35:14.32

>>455
何を使うにしても状況に適したものを使えば問題ないと思うよ

**デフォルトの名無しさん** · 2019/11/24(日) 06:37:41.88

>>450
NullObjectはどのような場合でも正しく機能するNullObjectを定義できるなら優れているが、「どのような場合でも」を満たすのは難しい。
null発生の状況が複数ある場合は「どのような場合でも」というい条件を満たすNullObjectが定義可能である保証もない。
最初は条件を満たしていても、プログラムを修正していくうちに条件を満たせない場合が出てくる可能性もある。
しかも「気づかないうちに」そうなっている可能性がありたちが悪い。
条件を満たせない場所だけ分岐させるのは、NullObjectがnullチェック分岐消去を目的にしている
ことを考えると本末転倒な解決策。

**デフォルトの名無しさん** · 2019/11/24(日) 12:53:04.20

APIレスポンスとかデータ定義はNULLじゃない扱いしておいてビルドエラーもでないけど、
実際に動作させるとNULLが来てクラッシュするとかあるな

**デフォルトの名無しさん** · 2019/11/25(月) 11:44:00.50

すごーく簡略化すれば、
private hoge: Hoge? = null
public Hoge apiX() {
if (hoge == null) hoge = Hoge() //
return hoge!! // ここでnullはあり得ないよと「宣言」
}
実際にHoge()のところは、さらにJavaの他のAPI呼び出しだったりするとしても、
とにかくnullでないことさえはっきりしているならばなんでもいい。
要するにこの場合は、apiXがnullを消費する責任を持つってことだ。
持たないなら、nullableのまま返す（つまりAPIとしてはnullも正常系だと言っている）。
そんだけのことじゃないかな。

**デフォルトの名無しさん** · 2019/11/25(月) 12:58:08.39

>>459
nullobjectは「賢いnull」なんだから、null的な使い方してもいいだろ。
型安全なnullとして受け取ってnull分岐してもいいしな。

あと、null発生の状況が複数あるなら、それぞれ別のnullobjectにしていいんじゃない？。

**デフォルトの名無しさん** · 2019/11/25(月) 16:14:54.66

Javaではnullobjectを賢いnullとするのは正しいと思う

でもnull許容/非許容を型で区別出来るようになったKotlinでは
nullobjectはその利点を無くしてしまう

実装持ちobjectとnullobjectを区別する必要が無い場合は何も問題無いけど
もし「nullobjectかどうか」を判定する必要がある場合は
賢いどころか逆になると思う

**デフォルトの名無しさん** · 2019/11/25(月) 17:15:40.69

NullObjectは"Tell, Don't Ask"なクラス設計ではうまく機能するんだけど、
関数型チックになAskだらけのコードだと使い物にならんね

**デフォルトの名無しさん** · 2019/11/25(月) 17:22:39.99

＞もし「nullobjectかどうか」を判定する必要がある場合は
これはないだろ。動機そのものだから。

**デフォルトの名無しさん** · 2019/11/25(月) 18:23:52.73

>>465
それなら良いけど、ケースによらずnullの代わりに使うみたいな話の流れだったから
ログインユーザーとかも無効ユーザーオブジェクトになるのかなと

**デフォルトの名無しさん** · 2019/11/25(月) 18:24:22.70

nullの場合の動作を
呼び出す側が決めるのか呼び出される側が決めるのか
どちらが適切なのかを考えるといい

呼び出される側が100%決め打ちできるユースケースならNullObjectは有効
呼び出し側でハンドリングしたくなったら邪魔

**デフォルトの名無しさん** · 2019/11/25(月) 18:27:30.40

java脳からkotlin脳へアプデが必要だけど
私の脳はnull

**デフォルトの名無しさん** · 2019/11/25(月) 18:49:15.70

Null Objectは単なる先送りで、ある意味!!が目指す方向とは真逆。
エラーが起きないから落ちることはないだろうけど、
使う側はエラーなのか無視されているのかわかりにくくなる。

**デフォルトの名無しさん** · 2019/11/25(月) 19:00:53.76

>>468
>呼び出し側でハンドリングしたくなったら邪魔

型無しのnull使うよりマシだろ。
許容するととんでもないところから紛れ込むnullの方がよっぽど邪魔。

**デフォルトの名無しさん** · 2019/11/25(月) 19:04:09.34

>>470
Nullableって知ってる？

**デフォルトの名無しさん** · 2019/11/26(火) 08:06:30.50

>>471
nullableでnon-nullにできたっけ？

**デフォルトの名無しさん** · 2019/11/26(火) 09:17:18.40

>>472
nullが正常系である場所ではnullabeを使い、nullが紛れ込んだらバグになる場所では非nullを使うって話がもう出てる
適切にゾーニングできているなら紛れ込むことをそう恐れる必要がない
nullという特殊値に対して意識が必要な場所はnullabeという型で言語仕様レベルで明確化でき区別できるからメリットがあり、型無しのnullというほど不便なものでもない

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

>>465
それがないならNullObjectがいいと思うよ
そこを否定している人はいないはず
ただ多くの人は経験上避けがたいと思ってるから意見が合わないんだろうね
解放閉鎖原則と単一責任原則とで作ってくと最初の動機だけではなかなか完結しない
全部ビジターパターンでとことんNullObject-ableな型にお伺いをたてるように作れば完璧にできるだろうけど、そこまで作り込むコストを考えたら適材適所でnullableを使い分けるのが現実解ってのが落としどころだと思う
Kotlinが選び提供している価値はnullセーフであってnullフリーではないし

**デフォルトの名無しさん** · 2019/11/26(火) 10:05:06.19

NullObjectって非同期呼び出しとかどうすんの
OOの原理主義的にはコールバックの呼び出しもしないのが正しいんだろうけど、
最近は前後で文脈が繋がってて、コールバックが呼ばれないままだとまともに動かないケースがほとんどだよね
かといってコールバックしようにも引数に何渡せばいいのかとか色々無理がある

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

>>473
nullを使っても問題は限定的だと思うけど、あえてnullを使うメリットはあるのかしらん？
実装上の手間が省ける、くらいしかないと思うけど。

**デフォルトの名無しさん** · 2019/11/27(水) 12:55:51.34

>>476
>>438,453-454あたりを見てくれ

**デフォルトの名無しさん** · 2019/12/06(金) 11:58:04.47

なぜKotlin/Nativeのメモリモデルが成り立たないか
https://itnext.io/why-the-kotlin-native-memory-model-cannot-hold-ae1631d80cf6

**デフォルトの名無しさん** · 2019/12/06(金) 14:42:47.13

三行に要約すると？

**デフォルトの名無しさん** · 2019/12/06(金) 15:14:59.67

>>479
freezeによる制限とAPIはKotlin/Nativeのみ
そのせいでマルチプラットフォーム機能がお通夜状態
だから考え直せ

**デフォルトの名無しさん** · 2019/12/06(金) 16:40:22.09

> This is the work of “top-level objects are frozen by default” and “a frozen datum cannot be mutated”.
Kotlin native試したことないけどこれ糞過ぎやろ
既存の(JVM向けに書かれた)コードがほぼ例外なく実行時にクラッシュすることになるやんけ
こんな互換性の欠片もないもん作るんやったらもう別言語でええやろ

**デフォルトの名無しさん** · 2019/12/06(金) 22:26:57.61

kotlinてクラス変数に型推論使えるの？
Javaで無名クラスに利用できたらいいのにと思ったことがある

class Hello {
public var xyz = new Object (){　int x; int y; int z;　};
void setX(int value){ xyz.x = value; }
}

**デフォルトの名無しさん** · 2019/12/06(金) 23:00:45.17

>>482
private varでもいいなら使える
https://paiza.io/projects/qjWZT-Uy91UelIcTFqoKIA