swiftc でコンパイルすると手元で15秒くらいかかるんだけどそれはそういうもんなのかな var fuga1: Int! = 1 var piyo1: Int! = 1 let hoge: [(fuga: Int?, piyo: Int?)] = [ (fuga: fuga1, piyo: piyo1), (fuga: fuga1, piyo: piyo1), (fuga: fuga1, piyo: piyo1), (fuga: fuga1, piyo: piyo1), (fuga: fuga1, piyo: piyo1), (fuga: fuga1, piyo: piyo1), ] print(hoge)Int! から Int? に変えるとすぐ終わるExpressibleBy***Literal があるからリテラルの型推論は組合せ爆発が起こるのだと僕は推測してます。let hoge: [Int?] = [ fuga1, fuga1, fuga1, fuga1, fuga1, fuga1, ] これはすぐに終わる(Int, Int) から (Int?, Int?) へのアップキャストにも見えてるのかvar fuga1: Int! = 1 var piyo1: Int! = 1 struct A { var fuga: Int? var piyo: Int? } let hoge: [A] = [ A(fuga: fuga1, piyo: piyo1), A(fuga: fuga1, piyo: piyo1), A(fuga: fuga1, piyo: piyo1), A(fuga: fuga1, piyo: piyo1), A(fuga: fuga1, piyo: piyo1), A(fuga: fuga1, piyo: piyo1), ] これでも同じだけ時間かかるlet hoge: [A] = [ A(fuga: fuga1 as Int?, piyo: piyo1 as Int?), A(fuga: fuga1 as Int?, piyo: piyo1 as Int?), A(fuga: fuga1 as Int?, piyo: piyo1 as Int?), A(fuga: fuga1 as Int?, piyo: piyo1 as Int?), A(fuga: fuga1 as Int?, piyo: piyo1 as Int?), A(fuga: fuga1 as Int?, piyo: piyo1 as Int?), ] 明示してもだめだたvar fuga1: Int! = nil だったらクラッシュしない?Int? には nil はいるやんInt! は nil になってはいけないのでは? if x == nil { } とかOKnil になっていることを想定していないのが Foo! だと思ってる。.some() の引数部分に書くと駄目って意味か。 (edited)x as Int? と .some(x) の違いがあるとnil の可能性があるなら Foo? にすべきInt! が、 nilのとき、nilじゃないときを、プログラマーが意識して分岐するコードはありえるFoo! が nil になっているコードは Logic failure だと思う。Foo? にすればよくない?@IBOutlet は利用時に nil でない想定じゃないですか?UIImageView! を UIImageView? として扱いたいみたいなコードを書いてる時にコンパイルが終わらなく鳴って発見したFoo! の ! は foo! の ! と同じ文脈のものと考えるのが自然だと思うけどなぁ。nil でないけど型ではそれは表せない場合のショートカット。lateinit var っていう機能があって、こいつは、同じような目的なんだけど、 nil の再代入ができないからT なんだよねNotNull<T> っていう Delegated Property っていう言語機能を使うようになっていたDelegated Property ってのは、まさにgetter/setterをオブジェクトとして差し込む仕組みでnil の再代入ができないけど未初期状態を持てる って実現できるんだよね@IBOutlet view: HogeView! の1点にはできますね。! で定義したくなっちゃうな?@IBOutlet だけは諦めて、その他の状態についてはちゃんと型に切り出してイニシャライザで初期化して、適切なライフサイクルで生成・破棄するのがいいんじゃないかなぁ。 var estimator: Estimator! var network: Network! var edges: [(Vector3, Vector3, Line3, Edge)]!class App { func openDialog() { /* ... */ } func closeDialog() { /* ... */ } func doDialogSomething1() { self.dialog!.something() } func doDialogSomething2() { self.dialog!.something() } func doDialogSomething3() { self.dialog!.something() } }doDialogSomething1 の呼び出し規約が、 dialogが利用可能な状態である、ってことを規定しているなら、!を毎回付けるより、そもそも dialog: Dialog! と IUO を使っちゃってもいいような気がしてるdoDialogSomething の冒頭で、 guard let dialog = self.dialog else { fatalError("aaa") } とか let dialog = self.dialog! とかやって、 ! を減らす工夫はできるんだけどもね。foo! を毎回書く代わりに Foo! にするってことは、 IUO で Logic failure を引き受けているということになる。IUO にするってパターンが出てくるんじゃないかなとdoSomethingDialog 相当の処理が実行される func doDialogSomething1() { if let dialog = self.dialog { dialog.something() } }! を使ってないからね)doDialogSomething1 を呼び出す時には前提として nil じゃないんだ、っていう表明はむしろできないdoDialogSomething みたいな抽象的な例だと話がすれちがっちゃって空中戦になりそうだから、具体的なケースを考えたほうがよさそう。! 使うのが適切に思える場面が出てくる。! でクラッシュしてたほうが、デバッグがしやすい場合がある → そういう場合なら、型で解決しないで、 ! を含むコードを書いておいたほうが、総合的にお得! 使っても同じ話。? もほぼ存在しないのは、 subscribe しない っていう状態に逃したからなんじゃないかなあT? がなくなったとしても、本質的には if let x = x { x.func() } と同じ事が起こってるのではないかなあopenDialog { dialog in // ここ }// ここ でセットアップした内容にディスパッチさせるときはどうするのっていう前提で話してたけどself: App のイベントハンドラなりなんなりに繋ぎこめば! は出てきそう。EventEmitter とか Rx.Subject にイベントを転送して、ハンドラをひっかける接続点を作る必要があるね。.rx で 接続点がぶら下がってるのはそう考えると便利だな。! で殺す側じゃなくて if let とか ?. で回避した場合のエンバグと等価な形。if let で回避しているよりは、 コードとしての局所性が意味の局所性と対応していて、クロージャで引っ掛けるほうが絶対良いと思う! で殺す以前に、局所性が低いからコーディングが難しくてそもそもバグを踏みやすそうな気もしてきたfunc fastUnwrap<T>(_ arg: ImplicitlyUnwrappedOptional<T>) -> Optional<T> { switch arg { case .some(let wrapped): return .some(wrapped) case .none: return .none } } var fuga1: Int! = 1 var piyo1: Int! = 1 struct A { var fuga: Int? var piyo: Int? } let hoge: [A] = [ A(fuga: fastUnwrap(fuga1), piyo: fastUnwrap(piyo1)), A(fuga: fastUnwrap(fuga1), piyo: fastUnwrap(piyo1)), A(fuga: fastUnwrap(fuga1), piyo: fastUnwrap(piyo1)), A(fuga: fastUnwrap(fuga1), piyo: fastUnwrap(piyo1)), A(fuga: fastUnwrap(fuga1), piyo: fastUnwrap(piyo1)), A(fuga: fastUnwrap(fuga1), piyo: fastUnwrap(piyo1)) ]ImplicitlyUnwrappedOptional これ直接使う発想なかったfuga.fastUnwrap() このコードだと、fugaのほうが先に型が決定して、fastUnwarpを探しに行くんだけど この時にInt!として解釈してくれない。fastUnwrap(fuga) これだと、引数がIUO<T>に束縛出来るし、返り値からT==Intが決定できるので、引数がInt!として決定できる+ みたいな演算子のオペランドとして扱われる前に、 T か T? のどちらかへのキャストが強制で入るんじゃない?!型を推論で伝搬できたT へのキャストを試して、コンパイルできなかったら、 T? へのキャストを試す! をたくさん含む式があると、倍々に探索時間が増えてるんじゃないかなT? で通って、 Tで 通らない ことを確定しないとT! から仮定された T は T? にさらに暗黙キャストされないって規則もあれば筋が通りそう。canBeUpcastToOptional: Bool みたいな。 (edited)T! から 仮定する T を生成する時にはそれを true にしとく。T と 仮定 T? どっちかしか通らない事を保証する必要があるなら// Kotlin fun List<Int>.sum(): Int { return this.fold(0) { a, b -> a + b } } fun List<Double>.sum(): Double { return this.fold(0.0) { a, b -> a + b } }// Kotlin fun List<Int>.square(): List<Int> { return this.map { it * it } } fun List<Double>.square(): List<Double> { return this.map { it * it } }~`^_| あたりも読み方知ったのは随分後な気がする。1位 XYZ色空間に迫る(1) by Ushio (191いいね) 2位 new!JSなんてもう怖くない!JavaScript/ES2015速習ガイド by niba1122 (157いいね) 3位 new!滝沢カレンの理解不能な文章を言語解析してみた。 by naoyu822 (144いいね) 4位 new!Pull Requestに潜むタイポを自動的に検出し、修正を代行するBot by icoxfog417 (142いいね) 5位 new!インタフェースと型クラス、どちらでもできること・どちらかでしかできないこと by koher (117いいね) 6位 最強のWikiと呼び声の高い「Crowi」を、更に最強にした話 by yuki-takei (105いいね) 7位 new!Git、GitHubを教える時に使いたい資料まとめ by yuyakato (97いいね) 8位 JavaプログラマがKotlinでつまづきがちなところ by koher (89いいね) 9位 おじさんが若者たちにモテるためのモダンなHTML/CSSマークアップ by kyoyababa (87いいね) 10位 Pythonのテキスト作りました by KatsunoriNakamura (82いいね) [PR] 社内wikiの更新が止まっている方へ Qiita:Team-ドキュメントを軸にした、プロダクト開発チームのためのサービス 10位 ゲームアプリの「ドット絵」をディープラーニングで自動生成する by shu223 (82いいね) 12位 new!2017年度版 細かすぎて伝わらないJavaScriptの速度の話 by gctoyo (76いいね) 13位 new!TwitterそっくりなMastodonクライアントを作った。Webクライアント制作でハマったことなど by N_ee_t (72いいね) 14位 new!JavaプログラマがKotlinで便利だと感じること by koher (68いいね) 15位 JavaプログラマのためのKotlin入門 by koher (61いいね) 16位 new!デジタルサイネージを作ったので学んだことを晒してみる Part.1 by Akoarum_K (60いいね) 17位 Docker で使えるデータベースの Web GUI まとめ by yamitzky (59いいね) 18位 new!GitHubと連携する新しいアプリの形:GitHub Appsの作り方 by icoxfog417 (55いいね) 19位 new!XYZ色空間に迫る(2) by Ushio (54いいね) 20位 new!Webサービスのフロント側の基本的な確認観点を列挙してみる。 by gctoyo (51いいね)guard let `self` = self else { return } って、selfをクォートするので、特殊だけどOptional かどうかってこと? Self? から Self になる って言ったほうがよかった。guard によって循環参照が生まれうるかという質問なのかと思ったので。self?.hoge() の hoge() の呼び出し中にweak self は var self: Self? にそのクロージャが実行される瞬間に値が代入されるようなものと捉えれば良いと。クロージャ実行の瞬間までに対象が deinit されてれば nil が入る。weak self の self が参照を保持しているから開放されることはない。self?. のたびじゃないですかねguard let self = self を書きましょうという事でclass A { } var a: A = A() func dealloc() { a = A() } let weakClosure = { [weak a] in print(a) // A dealloc() print(a) // nil } weakClosure()guard let a = a これがretain countを増やしていて、増やすまではクロージャの中で消えるかもしれないclass A { } var a: A = A() extension A { func deallocSelf() { a = A() print(self) // A } } let weakClosure = { [weak a] in print(a) // A a?.deallocSelf() print(a) // nil } weakClosure() そもそもメソッド実行中に消えたら世界が壊れますねwクロージャーでつかうweak selfをguard letでアンラップした変数はweak selfでしょうか?それともstrong selfなのでしょうか? については、「 strong self 」の意図次第で、 guard let foo = self の foo は強参照だけど、それがキャプチャされてるわけではないので循環参照の心配はないですよ、と。 (edited)guard let `self` = self のことは言ってない気がする・・・。guard let foo = self でアンラップした瞬間に参照カウントが一つ増え、 foo が消えた瞬間(遅くともクロージャを抜ける前)に解放されて参照カウントが一つ減ります。guard let self = self else { return }はコンパイラのバグだから避けた方がいう話はありますよね。 https://github.com/apple/swift-evolution/blob/master/proposals/0079-upgrade-self-from-weak-to-strong.mdguard unwrap x else {} これ実装して欲しいguard unwrap はMLで誰かが言ってたやつthiz とか clazz とかだった気がする。typ も使ったことある気がしてきた。type を置き換える必要があるの??let type = 42 type(of: type) // Intstrideがあったらstride()が呼べないとかあったようなtype(of:) が特殊だからじゃない?type(of:) は Swift3 では パースの段階で特別扱いだったのですが、 Swift4 では タイプチェック時に特別扱いということになったので、 4 だと Swift.type(of: ) にする必要があります。type をシャドーイングしている箇所があったら、マイグレーターが面倒みてくれるはず。let type = 42 type(of: type) // error: cannot call value of non-function type 'Int'{ "de": "20171109/Feeds/de_lproj/feed.json", "en": "20171109/Feeds/en_lproj/feed.json", "es_419": "20171109/Feeds/es_419_lproj/feed.json", "fr": "20171109/Feeds/fr_lproj/feed.json", "ja": "20171109/Feeds/ja_lproj/feed.json", "zh_CN": "20171109/Feeds/zh_CN_lproj/feed.json" }ios-developers-japanからswift-developers-japanに改名しました。
に変えました
をいっぱい書いていくことになったのでテンションが上っています!よろしくお願いします!
6
6
4let で定義する 3. O オプショナル型は nil を代入できる。 「許容する」ってどういう意味だろう?フォーマルな言葉ではなさそう。 4. 問題作成者の意図予想 O: T? という型は Optional<T> を意味するので、オプショナル型となる 4(2). 僕の解釈 X: 問題作成者はおそらく関数型についての考慮を忘れている。 var a: () -> Int という宣言で「最後に「?」をつける」と var a: () -> Int? となるが、 これはオプショナル型ではなくオプショナルを返す関数型にすぎない 5. 問題作成者の意図予想 X a が nil のときアンラップするとクラッシュする。 クラッシュするけどアンラップする事自体はできているので微妙な言い回し。 「アンラップに成功する」なら明確だけど。
趣味でDiablo4と植物アガベチタノタorオテロイ育てることです。 植物の話できます〜 (edited)
3
2
2zshrc とかはDropboxにまとめてある。秘密鍵だけ手で移してる。.ssh フォルダをコピー→移行先macでホームディレクトリにペースト)