swift-developers-japan

@mono あれ、なんか、うまくいかなかったけど何度もやってたらいけました

Discordはゲーマーコミュニティの方で使ってるから

4:03 AM

業務中に起動するとゲームの話題が無限に流れてきて仕事が死んでしまうという

4:04 AM

問題があるけど・・・

4:04 AM

通話機能は便利ですよね。

なるほど、さっき登録したばかりです(　´･‿･｀)

slackに無い機能として

4:10 AM

ゲームを起動してると　右のユーザーリストのところに　起動してるゲームの名前が出るとか

4:10 AM

ゲーム画面に通話UIをオーバレイ表示して、誰が喋ってるかわかるとか

4:10 AM

があります。

へー

@mono discord アカウントを持ってたのですが入れなくなってたので作り直しました

discord は OSS界隈でも使われだしてますね Reactのグループは結構人数も多いですアプリもReactNativeですしね (edited)

@sugigami(susieyy)

discord は OSS界隈でも使われだしてますね

お、知らなかったです。もしかしてすでにこういうサーバーあったりしました？

4:55 AM

今朝、 https://www.udemy.com/swift-kitura/learn/v4/content 観てたら、Discordでサポートしていて、それで使い始めました(　´･‿･｀)

Server API Development in Swift, Kitura, & Bluemix

Build REST APIs in Swift

@sugigami(susieyy) そうなんですか〜。てか、ReactNativeなんですか！

@omochimetaru こちらに記載があります https://facebook.github.io/react-native/showcase.html アプリよくできてますよ

Showcase

A framework for building native apps using React

ふつーにネイティブかと思ってました

4:59 AM

おお。本当だ。

@mono

もしかしてすでにこういうサーバーあったりしました？

2015年にSlackから移行したのですが https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to-discord.html

Reactiflux is moving to Discord - React Blog

TL;DR: Slack decided that Reactiflux had too many members and disabled new invites. Reactiflux is moving to Discord. Join us: http://join.reactiflux.com

1

2

5:00 AM

いまはもうはいれないのかな

5:01 AM

なんどかやってはいれました

デスクトップ版はエレクトロンっぽい挙動で微妙なんですよね

5:03 AM

やたら重いしドラッグすると画像がヒューと

5:03 AM

なったりする

@mono このDiscordチームについて、blogとかでアナウンスしないんですか？ https://mono0926.com/

mono-log

@omochimetaru すごくゆるふわに始めたので特に何もしてないです(　´･‿･｀) あと、そのブログはPVすごく少ないので、やるとしても https://medium.com/@mono0926 とかですね(　´･‿･｀) @omochimetaru さんが誰か誘う分にはまったく構いません(　´･‿･｀)

Masayuki Ono (mono) – Medium

Read writing from Masayuki Ono (mono) on Medium. Software Engineer(iOS, Swift, etc.) http://qiita.com/mono0926. Every day, Masayuki Ono (mono) and thousands of other voices read, write, and share important stories on Medium.

@mono なるほど。何か最低限1ページ、足場が無いと、今このツイートしか無くて誘い方が難しいんですよね。

5:45 AM

https://twitter.com/_mono/status/841496336264380416

@_mono

ブレスオブザイッヌ

Discordが良い感じなので、ios-developers-japan サーバーを作ってみた( ´･‿･｀) https://t.co/pV9sGQg6DI

5:46 AM

SwiftJPもこのツイートしか無いんですけど・・・

5:46 AM

https://twitter.com/norio_nomura/status/583467531358248960

@norio_nomura

Norio Nomura

「Swiftについて日本語で話すSlack」作った。自動招待ちゃんと動くかな？ — Join us on Slack! https://t.co/BxMnHZcNBD

5:47 AM

人を増やすならmonoさんのSwift Letterが最適でしょうけど、そういう意味では僕的には1ページ何かパーマリンクがあればさえすればいいので嬉しいなと思って聞きました。 (edited)

では、近いうちにゆるふわに書いてみます

了解です

なんかやけに知り合いが多い

1

@koher お、きた

では、近いうちにゆるふわに書いてみます

書きました(　´･‿･｀) https://medium.com/swift-column/discord-ios-20d586e373c0#.vrc7fqw8j

Discordが良い感じなので、ios-developers-japan サーバーを作ってみました( ´･‿･｀) – Swi...

先日、こんなTweetをしましたが、DiscordにiOS開発者のサーバーを作ってみました。

おおすばらしい！！

1

シェアしました

ありがとうございます

rtした

1

どうも初めまして

2

お、リバースさんだ

こんにちは。お邪魔します。 @hiragram さんのツイートから来ました。

3

1

medium から来ました

4

hatebu

1

mediumから来ました

2

同じくmediumから来ました。よろしくお願いします。

3

こういうコード書いて 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)

リテラル系の推論くっそおそい

fuga1とpiyo1を Int! から Int? に変えるとすぐ終わる

へー

2:16 AM

tuple辞めてstructにしたらどうなります？

ExpressibleBy***Literal があるからリテラルの型推論は組合せ爆発が起こるのだと僕は推測してます。

hogeの配列の要素をもう一個増やすと手元ではしばらく待ってもコンパイル全然終わる気配がなくなった

あれ？リテラルじゃないのか。

!から?にするときに

!から?がなんかメチャ遅い感じする

!→?のところで探索が倍々に増えてそう

@tarunon tupleをstructってどういうコードだろう

Optional型への変換なのか、暗黙的Optionalのラップなのか

2:18 AM

どっちもあり得そう

tupleをstructは変わらない気がするな

2:18 AM

tupleって実質匿名structみたいなもんだし

でも式レベルで型が明確になるから (edited)

let hoge: [Int?] = [ fuga1, fuga1, fuga1, fuga1, fuga1, fuga1, ] これはすぐに終わる

tuple → struct は速くなりそうな気もする。

(hoge:Int?, fuga:Int?)

あ〜 (Int, Int) から (Int?, Int?) へのアップキャストにも見えてるのか

これをstructちゃんと作ってみて

2:19 AM

そうそう

これ解釈が複数通りあるから重くなっちゃうのか。

把握

Optional周りの問題ならstructでも遅いはず

2:19 AM

ただ、tupleは実際結構やわなんで

やわｗ

そっちもあるかな？って

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), ]

これでも同じだけ時間かかる

2:21 AM

Int! -> Int? の暗黙的な変換が遅い感じっぽいのかな

それっぽい

それでも同じだけ遅いのか。

! -> ? って変換的にはアップキャストなんかな？

うん、それは常に互換性が正しい関係だからアップキャスト

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?), ]

明示してもだめだた

ｗｗｗ

14秒

俺もやってみよ

それ一緒じゃん

2:25 AM

Optional.someで囲うとまともなスピードになるよ

2:25 AM

多分

それって var fuga1: Int! = nil だったらクラッシュしない？

そりゃそうだな

かなしい

？

2:26 AM

Int? には nil はいるやん

Int! は nil になってはいけないのでは？

いけなくないですよ

2:27 AM

Int! は nil ももちえて、 if x == nil { } とかOK

Optional<Int>.some(hoge) のhogeは暗黙的にアンラップされてnilだとクラッシュするっしょ

Optional<Int>にOptional.some(Int!)を初期化しようとして

2:27 AM

nilなら死ぬでしょ

正確時には利用時に nil になっていることを想定していないのが Foo! だと思ってる。

あ、 .some() の引数部分に書くと駄目って意味か。 (edited)

@omochimetaru そう

@hiragram ImplicitlyUnwarappedOptionalに、Optionalに変換するextension書いて

ああ、 x as Int? と .some(x) の違いがあると

利用時に nil の可能性があるなら Foo? にすべき

switchでsome none作れば加速できる

@koher それは違うんじゃないですかねえ

Int!をIntに代入する時にnilだとクラッシュするのがInt!だとおもっている

単に型検査が無いだけで

2:28 AM

Javaの参照型と同じように使えばいいんじゃないか

2:28 AM

つまり、 Int! が、 nilのとき、nilじゃないときを、プログラマーが意識して分岐するコードはありえる

Forced unwrapping と同じで、利用時に Foo! が nil になっているコードは Logic failure だと思う。

2:29 AM

切り分けが必要なら Foo? にすればよくない？

そうするとIBOutletぜんめつめつめつ

2:29 AM

!はほぼIBOutletのためのそれ

2:29 AM

と思ってる

@IBOutlet は利用時に nil でない想定じゃないですか？

ああ利用時、そうですね

もともとこのコードにたどり着いた経緯がIBOutletとして生えてる複数の UIImageView! を UIImageView? として扱いたいみたいなコードを書いてる時にコンパイルが終わらなく鳴って発見した

didSetに書いてるんで、あまりその意識は無かった

うーん・・・

IUOはOptionalな値をOptionalとして扱うのが面倒だから横着できる仕組みだととらえている

俺も同意で、横着用ってことは、nilの保持も想定される

そそ

IBOutletはまた違う話で

2:32 AM

「read before write がlogic failure」ってことを仮定することで

うーん、 Foo! の ! は foo! の ! と同じ文脈のものと考えるのが自然だと思うけどなぁ。

「未初期化状態」を許したいっていうニーズで

2:32 AM

これについて俺はSwiftはいまいちだとおもっていて

2:32 AM

なぜかというと

@hiragram とりあえず、上のextension作るworkaround試してみてよ、絶対速いから

nilの再代入が文法上許されちゃってるのが良くない。

@tarunon これからmtgなのでおわったらで

横着のためでなく、ロジック上 nil でないけど型ではそれは表せない場合のショートカット。

うす(´・ω・｀)

kotlinには lateinit var っていう機能があって、こいつは、同じような目的なんだけど、 nil の再代入ができないから

2:33 AM

見た目の型はちゃんと T なんだよね

未初期化状態表すのは、この間見つけたlazy varにfatalをぶち込むworkaroundが中々キレてた

2:34 AM

使うかって言うと首を捻るけど

ああ

2:34 AM

いやまさにそうで

2:34 AM

kotlinのlateinitは

2:35 AM

少し前のバージョンだと NotNull<T> っていう Delegated Property っていう言語機能を使うようになっていた

2:35 AM

Delegated Property ってのは、まさにgetter/setterをオブジェクトとして差し込む仕組みで

2:35 AM

lazy var も結局は stored propertyのように見える computed propertyを作ってる仕組みだから

2:36 AM

実体が変数的なものじゃなくて関数的なものになってれば nil の再代入ができないけど未初期状態を持てる　って実現できるんだよね

lazy var初回getより前にsetするとそっちが使える、computedなの？ちょっと違和感あるけど。

2:37 AM

中身見ないと議論出来んな

原理的にそうじゃないとできないと思ってるけどIRまで見たことは無い

オブジェクトのライフサイクルとプロパティのライフライクルが一致しない場合は、そのプロパティ群を別の型に切り出して、それを Optional として保持すべきなんじゃないかと思ってる。

setしたとしても、getterの内部にある不可視のフィールドに代入されて、getするときは間接的に受け取ってると思ってる

因みにlazy var fatalはこれ https://twitter.com/tarunon/status/825706291536334849

@tarunon

uounɹɐʇ

あたらしいおもちゃがかんせいしたぞ

2:38 AM

gist作ってなかった

@koher それってつまり、IBOutletの現状の仕組みは微妙ってこと？

2:38 AM

@tarunon お〜〜〜

2:39 AM

それいいね。

2:39 AM

IUOより安全じゃん。

@omochimetaru そうだね。あれは Obj-C に引っ張られてるだけでは。

@koher OBJCっていうかXIBのowner機構にも引っ張られてますね

nilの再代入は禁止、初期化前のアクセスは明確にクラッシュ

@omochimetaru 正確には、Obj-C時代に設計された諸々の仕組みに、だね。

@tarunon @koher の主張してるIUOの利用シナリオにおいてはこっちを使うほうがより型安全なコードになるね

2:42 AM

@koher 一応現状でもカスタムViewをinflateするときはowner使わないから、 HogeViewControllerとHogeViewに型をわけて、個別のボタンとかはHogeViewのIBOutletにしておけば、HogeViewControllerの IUOは @IBOutlet view: HogeView! の1点にはできますね。

2:42 AM

あ、でもだめか、HogeViewの中は ! で定義したくなっちゃうな？

まあそうなるな

なので @IBOutlet だけは諦めて、その他の状態についてはちゃんと型に切り出してイニシャライザで初期化して、適切なライフサイクルで生成・破棄するのがいいんじゃないかなぁ。

IB使うとinit時点で用意できないからIUOの出現はまあしょうがない、んで、うちのコードでは

2:44 AM

それ以外にIUOは存在してないなぁ

まあ、そんなこと言いながら今急ぎで仕上げてるプロトタイプアプリでは↓みたいなプロパティを直接 ViewController に生やすクソコードを書いてる僕ですが・・・。 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() } }

2:47 AM

こういう雰囲気の時、どうしたもんか迷う。

2:47 AM

dialogってのが @koher の言ってる、ライフサイクルに対応してるとして、

それさ

2:48 AM

openDialogの引数にdialogをargumentに取るクロージャ入れて

2:48 AM

諸々ポンじゃダメなの?

諸々ポンとは？

dialog使うなら生きてるスコープでしか触れないようにする

2:48 AM

外から触るのはわからん

doDialogSomethingは、Appのレベルのなんらかのイベントの際に実行する必要があるっていう想定。

2:50 AM

俺が迷ってるのは、 doDialogSomething1 の呼び出し規約が、 dialogが利用可能な状態である、ってことを規定しているなら、

2:50 AM

nilクラッシュは正当化されるので

2:50 AM

!を毎回付けるより、そもそも dialog: Dialog! と IUO を使っちゃってもいいような気がしてる

それがまさに IUO が Logic failure な理由だと思うんよね。 (edited)

doDialogSomething の冒頭で、 guard let dialog = self.dialog else { fatalError("aaa") } とか let dialog = self.dialog! とかやって、 ! を減らす工夫はできるんだけどもね。

foo! を毎回書く代わりに Foo! にするってことは、 IUO で Logic failure を引き受けているということになる。

あかん、脳みそがRxに汚染されてるから、全てクロージャでスコープ切って安全な環境を作ろうとしてしまう

その工夫の行き着く先に型を IUO にするってパターンが出てくるんじゃないかなと

2:53 AM

@tarunon あ〜、open / close 間で購読が切れるようにすれば、有効な間だけ subscriberが繋がってて doSomethingDialog 相当の処理が実行される

2:53 AM

@tarunon みたいな感じ？

まさにそのイメージ

でもそれだとさ

2:53 AM

ちょっと定義が変わってて

2:53 AM

プログラマーにとっては dialogがある想定でロジックを書いたんだけど、なんらかのミスでdialogの生成をしないままそこに来ちゃうバグ

2:53 AM

がうまれていたときに

2:54 AM

俺のコードだとクラッシュすることで間違いを気づけるけど

そのコードを書けないようにしてくれ頼む

tarunonの作り方だと、購読が無いだけだから、「何も起こらない」っていう状況になっちゃって

2:54 AM

バグの検出がややこしくなってない？

そもそもコンパイルが通らなければ良い

いや、コンパイルが通っても、フロー制御上のバグが産まれる可能性は合って

2:54 AM

その場合に、バグの顕在化がしにくくなっていて

2:55 AM

逆にデバッグ効率が落ちる可能性があるって言ってる

2:56 AM

func doDialogSomething1() { if let dialog = self.dialog { dialog.something() } }

2:56 AM

↑意味的にはこう書いてるのと同じ

2:56 AM

↑これも静的検査レベルではクラッシュフリーだけど

2:56 AM

（当然 ! を使ってないからね)

2:57 AM

doDialogSomething1 を呼び出す時には前提として nil じゃないんだ、っていう表明はむしろできない

俺が言いたいのは

「nilの時は何もしない」っていう仕様が欲しいときもあるけど「nilだったらおかしい」時においてはクラッシュするほうが嬉しいって事かな

nilだったらおかしいっていうのは

2:58 AM

イベントフローも含めてコンパイル出来なければ問題ないはずで

2:59 AM

そもそもおもち君の例で、アプリのとあるイベントに対してdialogが生きてなければどう、っていうのを俺が正しく理解できてないかもだけど

イメージ的には、dialogが生きて無ければそのメソッドが呼ばれるのはおかしいって感じかな

3:00 AM

たとえば、ダイアログが表示されてる間は、

そのメソッドがそんなところに生えてるのがおかしいだろって思った

黒半透明のタッチ吸収するビューが乗っかってるから、こっちのボタンが押されることはありえない、とか

3:01 AM

あ、これだと逆の話しになっちゃうけど

3:01 AM

なんか、型よりそとのGUIシステムの都合とかで

3:01 AM

「ある状態AになってるときはイベントXは絶対に起こらない」みたいなことが保証されてるときがあって

doDialogSomething みたいな抽象的な例だと話がすれちがっちゃって空中戦になりそうだから、具体的なケースを考えたほうがよさそう。

そういう保証にもとづいたコードを書こうとすると、 ! 使うのが適切に思える場面が出てくる。

3:02 AM

@koher そうなんですけどね〜　簡単な例だと型でがんばって解決できちゃったりしてパッと出せない

3:03 AM

@tarunon 例えばさ、たるのんのスタイルでやるとさ、絶対にクラッシュはしないと思うけど、でも、バグが産まれることはあるから動作チェックはするわけじゃん

3:04 AM

@tarunon そういうバグが「これを押したら表示されるはずのAが表示されない」とか「ここを押したらこれが赤くなるはずなのにならない」

3:04 AM

みたいな形でバグとして出てくるんじゃないかと思うんだけど

@omochimetaru @tarunon さんが言ってるのは、 @omochimetaru の方法で実行時エラーになるようなケースは @tarunon さんの方法では型エラーにできるってことなんじゃないの？

僕の認識はそれです

で、そこにすれちがいがあるなら、元々のケースの理解にすれちがいがある気がする・・・。

あ〜

3:05 AM

なんか出発点が逆だな

3:05 AM

そうすると。

3:06 AM

前提として型で解決しきれないバグが産まれる(上に上げたような例) → そうしたバグが産まれる時はプログラマの考慮してる状態遷移に見逃しがある → そのときに ! でクラッシュしてたほうが、デバッグがしやすい場合がある → そういう場合なら、型で解決しないで、 ! を含むコードを書いておいたほうが、総合的にお得

3:06 AM

っていう順番。

!はおろか?すらほぼ存在しない世界線はどうすれば…

@omochimetaru そのクラッシュするケースを型で検出できると言ってるんじゃないの？

明確にモデルとしてnullableなものでしか?使ってないですよ

当然 Logic failure は残るけど。

3:09 AM

それは ! 使っても同じ話。

或いはUIKit由来の悲しい?

極力型で押さえ込んで、全部イミュータブルな環境のパス回しにしたい感じですよね？ @tarunon

そう

? もほぼ存在しないのは、 subscribe しない　っていう状態に逃したからなんじゃないかなあ

ふむー

Rxだと、 observerがいるかいないか、何人いるか、ってことは型検査不可能なわけで

3:10 AM

見かけ上 T? がなくなったとしても、本質的には if let x = x { x.func() } と同じ事が起こってるのではないかなあ

多分議論が空中戦になってて、こんなケースだと Rx で型検査できなくて問題になるよという例が出せれば建設的なんじゃないかなぁ。そして、それに @tarunon さんが解決策を示せれば新しい知見が得られるかも？

そうですね

いやあんまりRx関係なくって

3:12 AM

そういう一時的にしか存在し得ないものをOptionalでフィールドに置くのではなく

うん

生存している範囲を決めてそこのスコープだけで参照可能にする

3:12 AM

openDialog { dialog in

3:12 AM

shit

すみません、 Rx は言葉のあやで、 @tarunon さんのような手法を指してました。

openDialog { dialog in // ここ }

3:12 AM

全部こうするって話

そうすると、 @omochimetaru のケースは、メソッドをまたぐようなケースでどうするのって話なのかな？

あ〜わかってきた

3:13 AM

Appからその // ここ でセットアップした内容にディスパッチさせるときはどうするのっていう前提で話してたけど

3:14 AM

tarunonの考え方は

3:14 AM

そのクロージャの中で self: App のイベントハンドラなりなんなりに繋ぎこめば

3:14 AM

Appのメソッドを経由しないデータフローをそのクロージャの中でつなぎ込める

3:14 AM

って言ってるのか

そうっすね

3:14 AM

NotificationCenterでもいいけど

3:15 AM

だから、スコープから出る時にこいつら全部破棄して

3:15 AM

そういうことしようとすると、Rx便利だけどさ

NotificationCenterはそれの最も雑なグローバルなアプローチだね・・・

で、俺が今わからんのは

3:16 AM

まあそういう作り方するとdoDialogSomethingの引数にdialog入れるのが適切なのかな?

3:16 AM

まあそんな感じ

たしかにその発想でやっていけば減らせる ! は出てきそう。

そのクロージャの中で self: App のイベントハンドラなりなんなりに繋ぎこめば Appのメソッドを経由しないデータフローをそのクロージャの中でつなぎ込める

なるほどー

@IBAction だと Appのメソッド呼び出しになっちゃうから、そこからいったん EventEmitter とか Rx.Subject にイベントを転送して、ハンドラをひっかける接続点を作る必要があるね。

3:17 AM

Rxだと @IBOutlet のviewのrx.click.subscribeとかになるか。

そうね

.rx で接続点がぶら下がってるのはそう考えると便利だな。

UIKitはちょっと古すぎてOptionalが無限に生まれるから

3:17 AM

その結果そういうアプローチ取りたくてかなりRx使うことになった

3:17 AM

そして今に至る、という感じ

その主張は賛成

3:18 AM

もっと追求してみようとおもった。

なるほどー。 Rx 自体の話よりも extension がスコープを厳密にするのに役に立つということなのか。

なので、dialogが存在しない状態でdoDialogSomethingを呼び出す、という感覚が理解できなかった。

僕の例が具体的すぎたせいで言いたいことが伝えられてないっぽい。 (edited)

tarunon方式でどこまで突き詰められるのかはやりこんでみないとなんとも言えんなあ

3:21 AM

状態の組み合わせについてもcombineLatestで同じように整理できそうだから結構な範囲をカバーできそうな気もする

一般的な話として、ファイルの open / close でも何でもいいんだけど、メソッドをまたいで存在しないといけないものがある場合はどうなるんでしょう？クロージャ式に閉じ込められないので、 IUO なり Optional なりが必要そうな気が。

3:23 AM

@hiragram 帰ってこないから試してみたけどなんかダメそう

そもそも、その母体（ ViewController とか）にライフサイクルに合わせてクロージャ渡せるメソッドが生えてれば問題ないのか？

ライフサイクルだと2状態しかないから

3:24 AM

一般論としては管理すべき状態がステートマシン的な感じだけど

Rxならcombineとかzipとか使って誤魔化せる感じですね

状態ごとにクロージャの登録/削除を適切にやってけば同じモデルにはできそう

でもそうするとおもち君の言うsubscribeが呼ばれないケースが出てくる気はしている

うん、何か間違えたときのエンバグは、沈黙の形で出てくると予想してる

3:25 AM

! で殺す側じゃなくて if let とか ?. で回避した場合のエンバグと等価な形。

結果として動作が未定義なので何も起こらない

3:26 AM

これをどのレイヤのバグと呼ぶのかはわからんな

特に、そうしたバグが2段、3段組み合わさった時は、追跡が結構たいへんそう

うーん、想定していないタイミング（↑の dialog が存在しない状態）でイベントが発生した場合に、それをクラッシュさせた方がいいんじゃないかってことか。

そうですね、でも、 if let で回避しているよりは、コードとしての局所性が意味の局所性と対応していて、クロージャで引っ掛けるほうが絶対良いと思う

3:28 AM

そういう意味では ! で殺す以前に、局所性が低いからコーディングが難しくてそもそもバグを踏みやすそうな気もしてきた

なんかよくあるコールバックが戻ってくる前に「Back」ボタン押しちゃって View Controller ごと破棄されたみたいなケースか。

エンバグの仕方が変わるという差の前に、コードの局所性が高いっていうメリットでお釣りがあるかも。

↑のケースなら無視したいことも多いけど、一律どっちがいいとは言えなさそう。

@koher そうですね、そういうケースはRx.DisposeBagでうまく解決できるので、また例として微妙な感じがあるけど

@hiragram

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)) ]

3:31 AM

これでOK

やべえコードが出てきた

IUOはかなり特殊で、extensionではやしたメソッドを使えない、postfix operatorも使えない

3:32 AM

って感じだったのでこれで

3:32 AM

FAです

ImplicitlyUnwrappedOptional これ直接使う発想なかった

3:32 AM

ああ、それで関数にするしかないんだ。

でも超絶加速したよ

3:33 AM

当然だけど

おもしろい。 (edited)

コンパイラがさ、

3:34 AM

Int!よりもIntを優先して解釈しやがるんだこれが

もともとこのコードにたどり着いた経緯がIBOutletとして生えてる複数の UIImageView! を UIImageView? として扱いたいみたいなコードを書いてる時にコンパイルが終わらなく鳴って発見した

もともとのケースだと、最初に let imageView: UIImageView? = iuoImageView ってかいとけば高速化した気がする。

まあわかる

ふむ

3:35 AM

優先してっていう意味がよくわからない

左辺と右辺っていうの、俺その辺理解してないんだけど

3:36 AM

fuga.fastUnwrap() このコードだと、fugaのほうが先に型が決定して、fastUnwarpを探しに行くんだけどこの時にInt!として解釈してくれない。

3:36 AM

fastUnwrap(fuga) これだと、引数がIUO<T>に束縛出来るし、返り値からT==Intが決定できるので、引数がInt!として決定できる

IUOはかなり特殊で、extensionではやしたメソッドを使えない、postfix operatorも使えない

ちょうどこれアレレ〜って思ってた

3:40 AM

いない間にえっらい盛り上がってたんだな

IUO型はメソッド呼び出しや + みたいな演算子のオペランドとして扱われる前に、 T か T? のどちらかへのキャストが強制で入るんじゃない？

ぽいね

IUOのままでいられるのは関数の引数に書いたときだけで

3:40 AM

それ以上なにか操作しようとするとキャストが差し込まれる

そして、T?へのキャストが、何故か遅い

Swift3になるときに、代入文の右辺に書くだけでもそのキャストが入るように変更されたね

3:41 AM

以前は左辺に !型を推論で伝搬できた

3:41 AM

先に T へのキャストを試して、コンパイルできなかったら、 T? へのキャストを試す

いやTへキャストできたらそこから暗黙にT?になるでしょ

っていう優先度になってて、 ! をたくさん含む式があると、倍々に探索時間が増えてるんじゃないかな

3:42 AM

あ〜

しかもnilクラッシュ出るから意図通りにならない

3:42 AM

なんかここらへん死体が転がってそう

キャストを試すっていうのは実行時の話じゃなくて、コンパイル時のその後の式の型解釈のことよ。

いやそうよ

意図通りにならないってどゆこっちゃ？

T! => T => T?なんて型変換が生まれたら

3:43 AM

死ぬでしょ

3:44 AM

T優先だとそっちになってしまうんじゃない?

3:44 AM

で、それを避けるための処理が入っていて

3:44 AM

そいつが超遅い

3:44 AM

だと思った

3:44 AM

まー空想ですね

あ〜そういう意味か。

3:45 AM

Tの仮定は T? が通る時には T->T? の変換も続けて入るから絶対成功しちゃうって

3:45 AM

言ってるのね。

そう

3:45 AM

T!から生まれたTを暗黙T?にしないための処理が遅い、のでは? [予想]

で、逆に

3:46 AM

先に T? をためしているなら、コンパイルが遅い理由がわからない

3:46 AM

と。

そう

本当にそうかなあ？これも仮説なんだけど

3:46 AM

ある暗黙のアップキャストがあって、式が多重に解釈できるときって

3:46 AM

どっちでも通っちゃう時は、「オーバロードが曖昧だからコンパイルできません」

3:47 AM

っていうエラーが出るじゃん？

でもT優先っぽいのは、extension funcよベない時にIntには生えてねーよって言ってたのから

3:47 AM

妥当な線だと思ってる

3:47 AM

あるね

ってことは、優先度関係なく、 T?　で通って、 Tで　通らない ことを確定しないと

3:47 AM

いけないんじゃないか？

いやそれありえないじゃんw

あー

Tは暗黙的にT?だよ

3:48 AM

だからここだけ特別扱いで

3:48 AM

TがT?にならない処理が必要

T! -> T or T! -> T? のルールと
T -> T? のルールは、多段では通らないんかな

3:49 AM

T! から仮定された T は T? にさらに暗黙キャストされないって規則もあれば筋が通りそう。

やっぱりOptionalへの暗黙変換が邪悪だよ

3:49 AM

やめよう

わかる。

T! から仮定された T は T? にさらに暗黙キャストされない

これどうやって実現するんやろか

推論器の実装の型変数にそういうフラグがあればできるっしょ

3:52 AM

T から T? への暗黙変換を試すところでフラグ見て無視する

3:52 AM

canBeUpcastToOptional: Bool みたいな。 (edited)

3:53 AM

T! から仮定する T を生成する時にはそれを true にしとく。

それだとそんなに遅くならなさそうだなぁ

3:53 AM

遡って見てるんじゃないの?w

それに加えて、さっきいった、仮定 T と仮定 T? どっちかしか通らない事を保証する必要があるなら

3:54 AM

式が1個増えるたびに倍々に計算量が増えてくよ。

あーそっか

3:54 AM

Arrayをinitする時は要素が全部掛け算になってるんだった

3:54 AM

そら遅いわ

そうそう。

3:54 AM

だから探索範囲は指数増加する

3:55 AM

ちょっとためしてみる

今更だけどここ #general やん

1

ワイがさっきそう思って #swift に別の話題投下したけど無意味だった

別の話題じゃなくてここの話題を転記しないと意味ないのではw

(続きは #swift に書きました。結論として僕の仮説は2つとも間違い・・・)

設定 > ゲーム > 追加するで、 xcodeを追加すると、Xcodeをプレイ中って出せるのね

本当だ

おー

Alfred3をプレイ中というのを目撃した

Xcode 少数

4:20 AM

そうでもなかった

done https://developer.apple.com/wwdc/

WWDC 2017 - Apple Developer

The Apple Worldwide Developers Conference (WWDC) 2017 takes place June 5-9 in San Jose, California.

4

https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/

1:40 AM

KotlinがJVMを介さないネイティヴコンパイルをやるとのこと

1:43 AM

プラットフォームによってメモリマネジメントを変更できるようにするつもりらしくて、iOSならARC、サーバーならトレースGC、といった展開を考えているそう

1:43 AM

既存のJVM版Kotlinとは別の、プラットフォーム中立な共通部分のKotlinを定義するつもりらしい。

1:44 AM

個人的にはクロプラ言語の設計方針としては理想的に思う

1:46 AM

TypeScriptなどよりヌル安全言語としてもちゃんとしてるので

1:46 AM

JSRuntime挟まない分早くなるだろうし

1:47 AM

ReactNativeよりポテンシャルを感じる

あとはブラウザでも動いてくれたらいよいよ...ですね (edited)

Kolin/JSは既にリリースされてますよ

1:50 AM

これも同じ発想で、JVM完全互換は狙ってないから、自然なJSにコンパイルされるはず

そういえば、もともとJS吐くようになってましたね Kotlin強い

1:51 AM

reactもある https://github.com/andrewoma/reakt

andrewoma/reakt

reakt - Reakt is a Kotlin wrapper for facebook's React library

JVMやJSVMといったランタイムに固有なコードを分離して書けば、かなりポータブルなコードが書けるはず

1:55 AM

個人的にはSwiftでそれをやりたいからJetbrainsはどんどん頑張ってもらってアップルもAndroid対応とブラウザ対応を急いでくれたらいいな

Kotlin、ジェネリクス周りをJavaにひっぱられすぎてて辛い・・・

2:49 AM

あれ？？できないと思ってた↓ができちゃったんだけど、前からできたっけ？

// 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のほうが最初から進んでた

2:50 AM

Swiftよりも、直感的にやったことが動く傾向

わかった。↓ができないんだ。

// Kotlin fun List<Int>.square(): List<Int> { return this.map { it * it } } fun List<Double>.square(): List<Double> { return this.map { it * it } }

JVMのTypeErasureのせいのやつか

うん

これ見てきました。 http://qiita.com/omochimetaru/items/7265e440418b38088ccb

Swift の struct の stored property は var にしよう - Qiita

# 記事についてこの記事は potatotips#39 という勉強会で発表した内容を再掲したものです。スライドの画像と、喋った言葉を載...

9:55 AM

ここと #swit の過去ログを読ませてもらったけど、濃かった。

お、ノムラさん。こんにちは

こんにちは。

SlackBotみたいな、実験場所ぽいのはDiscordには無いのかな？

ディスコードにもボットAPIとかはありますよ

10:07 AM

身内のコミュニティでは音楽再生ボットとか入ってる

いきなりチャンネルに書き込むのではなく、お試しで書き込める場所がないのかな？と。

ああ、なるほど。誰にも見えない窓は無さそうな気がしますね

Swift歴短いですが宜しく御願いします！

2

ひょっこり。よろしくです

4

swift大好きです❤️よろしくです

2

初心者質問チャンネルとかあったらROMの人ももっと発言するだろうか？

1

Swiftと人間初心者です。よろしくお願いします！

1

Swift初心者で人間未経験者ですよろしくお願いします！

3

ミスってボイスチャンネルポチってしまった

全然使われてないよね

使えるのこれ

ボイスチャンネルってなんだろうっていじってたら即繋がった？！失礼しましたー

www

おいで

Mac mini マイクついてたかな・・・

macminiはついてないっすねえ

orz

@mono もくもくチャンネル/ボイスチャンネルが欲しいです

@omochimetaru 僕が作ろうかなと思いつつ、adminロール付与したので、操作してもらえますか？(　´･‿･｀) (edited)

ありがとうございます

5:58 AM

名前が赤くなった

(　´･‿･｀)

何かが3倍に

Swift色に変更

6:00 AM

あまり変わらない

6:01 AM

チカチカしますね

6:01 AM

test

6:02 AM

彩度を下げました

6:03 AM

@omochimetaru 色も適当に弄ってOKです。(ロール通り、他も色々弄ってもOKです)

@mono 了解です、ありがとうございます

6:04 AM

あ、@aryzae さんのプレイ中の絵文字、 X かこれ。

やっぱ小さいからわかりづらいっすねぇ

SwiftJP内の #swiftコミュニティ情報 というチャンネルでこちらを紹介しました。 (edited)

4

お、ちゃんと2つのアプリがある場合でも直近？でアクティブになったほうが表示されるな。

2:39 AM

というわけでAndroid Studioをプレイしています・・・

Xcode開いている方を見るだけでモチベーションになってます。ありがとうございます。よろしくお願いします!

これおもしろいですよねｗ

正直、メニューバーに、これだけの機能ほしいです笑

Xcodeなどのノンゲームアプリはデフォルトでは検出されないので、「ユーザー設定 > ゲーム > 追加する」から、設定する必要があります。気になっている人が居たらご参考まで。

3

2

自分でアプリ名変更できるから、TweetbotにXcodeって名前をつけて仕事してるフリをしても良いですね:)

4

早速、iTunesをNapにしました。昼寝しますー

サービスごとにElectronランタイムを走らせたくないので、最近は全部Safariで開くようにしてしまいました。

4:04 AM

なのでアプリ名出ない。

ネイティブアプリと比べるとちょっともっさりしてますよねElectron

オフラインメンバー一覧が見れなくなったと思ったら、100人を超えると不可視になるらしい。直してってスレがあった。 https://support.discordapp.com/hc/en-us/articles/213492467-Why-is-my-offline-User-List-missing-

Why is my offline User List missing?

To help keep Discord's lightweight performance, the offline portion of the user list will automatically be hidden once your server surpasses 100 members. Server admins still have access to offline ...

それはつまり100人inしたってこと

1

今102人ｗ

富士山でおにぎり食えるぞ

2

チャンネルをミュートにするとiOSアプリ側にPushが飛ばなくなるのかな

#cocoa とか #uikit があっても良い気がしてきた

つくってみるか

3:53 AM

作ったゾイ

2

@hiragram すぐに何か話題があるのかと思ったらナイんかい

えー

3:58 AM

話題かいてきた

こんにちは！好きなプロパティはUIViewの exclusiveTouch です

3:58 AM

好きなプロパティｗ

あるでしょ好きなプロパティ

書いてきました。

そのプロパティは存在悪だろいい加減にしろ

4:00 AM

デフォルトを全て書き換えて存在毎消し去りたい

ｗｗｗ

わかる

素朴な話題を投げて発言を促していこうな

WebKit部屋あったら僕が無限にQ&Aにお答えできるなw

#tarunon

ｗｗｗ

ツイッターでどうぞ

beginnerじゃなくて質問部屋とかのほうがいいのかな

swiftとswift-2ってどう違うんでしょ？

swiftが

9:32 AM

ワイワイしすぎたときの避難所

9:32 AM

ですね

なるほど納得です

一応部屋を開くと、画面中央上部に、部屋の説明が出ます

1

（気づかなかった）

swiftはswift1の昔話、swift-2はswift2の昔話じゃなかったんですね

@takasek 話が並列しててややこしいときに作られてました

Discordの機能の「ピン留めされたメッセージ」、これってアーカイブ的な役割持てるんでしょうか

1:43 PM

ログ追うの結構大変で、ピン留めされたメッセージを契機としてそこからのログが辿れるなら、盛り上がった話題の契機となるメッセージをピン留めして探しやすく出来るかも。

ピン留めって個別じゃなく、全体で行われるんですね。てか権限ある人のみ可能なのね

部屋で共通のアーカイブが作れそうだったので気になった

トピックのストックしたいよなー

出来無さそう?

ピンはたくさん止めるのは向いてない感じ

ふーむ

あくまでチャンネルのローカルルールとかを止めておくためみたいな。

発言にURLが振られてないのが痛い

雑にまとめる別のサービスがあれば良さそう

3:28 PM

タンブラーみたいな。

WWDC参加勢いますか？

WWDC落選勢です。

2

初めましてー

1

2

今127人なんだけどオンラインなの12人だけだし少ない

WWDCをみんなで見る音声通話とかやりたくない？

16人通話ぐらいまでならやったことあるが

2:15 AM

・・・このくらいならいけるなｗ

2:16 AM

たしかにせっかくSlackじゃなくてDiscordなんだから

何人居るの、管理者だけ見れるの

@tarunon うん。100人を超えると「オフラインの人数」が表示されなくなる謎仕様のため、そう。

2:16 AM

100人未満のときは全員見れた。

2:16 AM

たしかにせっかくSlackじゃなくてDiscordなんだからWWDC実況楽しそうだな

何のためにそうしてるのかわからんｗ

2:17 AM

わいがやしたい

@hiragram Discordのフォーラムも荒れてた

残当感

日本時間6月6日午前2時から

WWDC心置きなく見るために6日は有給取った

普通に翌日が出社なんやが

あー

有給ｗ

有給にしようかな

何この流れ

5日は既に休みで元々6日も休みにするつもりだったけど、やっぱ行こっかなって思ってたけど揺れる

前日にたくさん寝ておけばいっかな

有給使わなきゃ消えちゃうマンなので無理やり使うぞ

@omochimetaru WWDC鑑賞のため後ろにシフトして勤務とかでいいんじゃない？

@koher そういえばそんな事が可能な気もするな

3:32 AM

事前遅刻連絡しておくか

WWDC は業務にも関係してるし余裕だと思う。むしろ、業務に関係してなくてもオリンピック見たいからここで 2 時間抜けますとかも（業務に大きな支障がなければ）可能にすることで従業員満足度を高められるんじゃないかという主旨で、私用シフト制度を提案したはず。

そういう意味だと @tarunon も完全な裁量労働で遅刻し放題なんじゃなかったっけ

それはそう、でもだるいから休みたいじゃん?

草

3:39 AM

@tarunon Swift発表された時も前日にWWDC見てたけど、その日は翌日めっちゃ出勤モチベあったよ

出勤モチベあるかどうかは朝起きないとわからないからなぁ、夜更かし確定してるなら有給に倒しといたほうが安全ぽい

なるほど。

別にそれで査定さがるわけじゃないからね

iOS界隈こんなDiscordでやってたんですね、ゲーム界隈でしか流行ってないのかと思ってました

3

ここより大きなスラックのコミュニティもありますよ〜

monoさんのブログ告知から来ました。よろしくお願いします！

2

アイコン、きれいなものに変えました。 (前のも解像度高かったものの、一部環境ですごく粗く見えてしまったり微妙だったので)

4

こんにちは

2

この間同僚から教えてもらったの、⌥⇧Kでが使えます。

3



「キーボードビューア」を使うとそれ系探しやすい。

なんでKなんだろ

2:42 AM

⌥⌘⇧←この辺スッと入力したいけど無いんですよね

社外キーボードなのでそれらの記号がどのキーなのかパッと紐付かない

2:43 AM

Cmd+Opt+Shift...とかって書いてあるほうがわかるｗ

オルト理解したらだいぶ楽になった

前にtarunonさんが言ってたんだっけ？⌥は分岐を表してるみたいな。あれでようやく覚えられた。

@Biacco42 が言ってた

ぼくそんなこといってない

tarunonさんじゃなかったｗ



@Biacco42 だったらここじゃなくて社内Slackだったかもしれない・・・

言語より記号のほうが覚えやすいから最初から記号しか覚えてなくて、口頭でOptionって言われると混乱してしまう

記号の方が覚えやすい・・・？

僕も分岐ぽく覚えてます(　´･‿･｀) http://labs.torques.jp/2011/01/21/1610/

yamada

Macの特殊キー記号を覚えてしまおう！

Macの特殊キーの記号ってなんかよく分からないと思い込んでしまっていて、なかなか覚えていなかった。が、ちょっと考えてみたら意味があるはずで、過去の経験から「物事の意味を理解...

tarunonだけ説

音がないから記憶できません

⌘⌥⇧^

2:59 AM

キーボードの位置と記号のペア

音が"Option"で表現が⌥ (edited)

3:00 AM

とか

@Biacco42 > 言語より記号のほうが覚えやすいから最初から記号しか覚えてなくて、口頭でOptionって言われると混乱してしまう

キーバインディングの設定も全部記号表記じゃん…!

@omochimetaru ピュアに記号だけっておぼえられるんかな？音というか文字列のラベルがないと覚えられんそう

@Biacco42 たるのんの書いてるのはまさにそう読める

たるのんさんはそうっぽい

六芒星（✡）とか別に音じゃなくてそういう記号だと認識しない？

‰とか、そういう記号あるんだーで最初記号だけ覚えて、それがパーミルと読むのを知ったのは随分あと

3:04 AM

*とかアスタリスクと読むのはずっと知らなかった

左から右に読んでいく時に　音のわかってない記号が出てくると　？？　ってなって脳に入らない

3:04 AM

@koher それは「ホシ」って読む

1

~`^_| あたりも読み方知ったのは随分後な気がする。

|読み方あるんですかw

ぱいぷ

それはShell寄り過ぎでは

| はなんて読むかわかんない。

チルダ　バッククォート　ハット　アンスコ　パイプ

vertical bar？

バーティカルバーでもよい

3:05 AM

@tarunon シェルでしか出てこねえ記号だから仕方ない

こういうの、伝える時にどうしようもなくって

ビット演算

なんか、これ、あれ、

3:06 AM

こんなの!ってジェスチャーしてる、めっちゃ頭悪い

ジェスチャーｗ

でも @omochimetaru が言ってるのも正式名称を知らないとってことじゃなくて、頭の中で音がないと読めないってことだと思うから、何かしら自分なりの読み方ができれば OK ってこと？

@koher そうです

⌥⌘^⇧の表記だと100%間違えないけど、CmdとOptionだと未だに3割ぐらい間違えるなぁ。

別に正式名称ではなくても自分の中の音がスッと出てくれば読める。

3:08 AM

@tarunon CmdとOptionは射撃とフラググレネードぐらい別物な感覚

わからんご

単語の読み方が間違ってても自分の中ではラベルとして対応してるので使えるのと同じ

3:08 AM

ハチャメチャにわかりづらいたとえが来た

小さい頃記号文字大好きで

3:10 AM

古今東西のいろんな文字とか書き取って遊んでたのが原因化も知らん

ヒエログリフとかいけそうｗ

ポケモンバグらせて出て来るビットの壊れたものですら、文字の一種として認識してた記憶がありますね

3:14 AM

ロックマンエグゼも、パスコード入れる時にアルファベットの外に謎記号あった

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いいね)

4:53 AM

キータのランキングメールの1~20に @koher が4ついる・・・

なぜか今日のQiitaニュース届かない・・・

僕は13:52に届いてました

なるほど、送信中なのか。

初歩的な質問ですみませんクロージャーでつかうweak selfをguard letでアンラップした変数はweak selfでしょうか？それともstrong selfなのでしょうか？ strong selfって言われて疑問に思ったので教えていただけないでしょうか？

strong self ですよ

6:19 AM

それをやる場合、 guard let `self` = self else { return } って、selfをクォートするので、特殊だけど

関数の実行開始から関数の終了までretain countが増えます。その間はstrong

6:19 AM

実行開始というかguardから

6:19 AM

から?あれ

ガード文より上では self はweak ref で guard より下では strong ref

一瞬わからなくなったw

ありがとうございます

@omochimetaru ↓は Optional かどうかってこと？

ガード文より上では self はweak ref で guard より下では strong ref

あ、えーっと、そうですね。型が Self? から Self になる　って言ったほうがよかった。

guard によって循環参照が生まれうるかという質問なのかと思ったので。

weak selfって、関数実行した瞬間にretain count増えませんでしたっけ? weak のまま使ってたら実行中でもdeallocがあり得る?

6:50 AM

そんなことはないと思うけど

6:51 AM

あれ、わからなくなってきた…

@tarunon self?.hoge() の hoge() の呼び出し中に

6:51 AM

hogeを呼び出す瞬間はカウント1以上であれば

6:51 AM

呼び出す瞬間は大丈夫だけど

6:52 AM

hogeの中でその1をもたらす変数がnil入っても大丈夫なように

6:52 AM

コンサバティブに+1しているはず。

6:52 AM

Ownership周りにそういうコンサバな+1がたくさんあるんやでって書いてあった

テストコードで証明できないですかね？

メソッド実行はretain count増えるから実行中には消えない

↑のシナリオを自前で書けば検証できるかと

6:53 AM

YESYES「メソッド実行はretain count増えるから実行中には消えない」

つまり、 weak self は var self: Self? にそのクロージャが実行される瞬間に値が代入されるようなものと捉えれば良いと。クロージャ実行の瞬間までに対象が deinit されてれば nil が入る。

ん？

実行中は weak self の self が参照を保持しているから開放されることはない。

クロージャ突入時じゃなくて self?. のたびじゃないですかね

6:56 AM

それをクロージャの間ずっと生かしたければ guard let self = self を書きましょうという事で

ん？クロージャ途中で開放はあるのか。

ありますね、 self をもってるグローバル変数をクロージャの中から nil にするとか。

class A { } var a: A = A() func dealloc() { a = A() } let weakClosure = { [weak a] in print(a) // A dealloc() print(a) // nil } weakClosure()

6:57 AM

ok

↑まさにそう

なるほど。

6:57 AM

「メソッド実行中」か。

6:57 AM

クロージャと読み間違えてた。

guard let a = a これがretain countを増やしていて、増やすまではクロージャの中で消えるかもしれない

6:59 AM

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)

7:04 AM

多分 guard let `self` = self のことは言ってない気がする・・・。

fooのこと言ってました

strong self とは strong reference （強参照）を意図していましたか？それなら strong reference となります。 guard let foo = self でアンラップした瞬間に参照カウントが一つ増え、 foo が消えた瞬間（遅くともクロージャを抜ける前）に解放されて参照カウントが一つ減ります。

循環参照するかどうかでよく揉めるケースな気がします（以前コードレビューで揉めたことありました） closure内でweakでキャプチャしてるのに更にstrongキャプチャした後ってどうなるんだっていう (edited)

@moaible 「さらにstrongキャプチャ」これは「キャプチャ」じゃなくてただのローカル変数への代入(Optional unwrapping) ですよね。

@omochimetaru すいません言い回し良くかったですが、言いたいことは実際にキャプチャしたのが代入によって強参照でキャプチャされるわけではないってことでした (edited)

はい、なんていうか、クロージャによる変数のキャプチャと、ローカル変数への代入は、全く関係ない独立な機能だと思うので

8:29 AM

混乱ポイントがよくわからないけど「キャプチャ」って言葉が曖昧になっているだけな気がしました

ただの代入を循環参照につながるような参照の仕方をするんじゃないかって勘違いする人が一定数いるようです、サンプル数3なのでどうしてそう思うのかは分かんないですけど (edited)

なるほど。

一回MRCのコード書けばどこでretain countが変化するのかが理解できて良い

そういう意味だとiOS4から経験できて良かったと思いますｗ（戻りたくはない）

retain/release/フィールド代入の順番を間違えると壊れる

8:37 AM

初心者がセッターをかけない世界ね

ARCから書き始めた勢だけど、MRCのコードをメンテする度にARCは文明だ…という気持ちになる

移行期にな

8:38 AM

プリプロセッサでな、ARCとMRC両方でコンパイルできるマクロを定義したな、ライブラリがあったんじゃ

それやった...懐かしいｗｗ

わかる・・・

本題からはずれますが、guard let self = self else { return }はコンパイラのバグだから避けた方がいう話はありますよね。 https://github.com/apple/swift-evolution/blob/master/proposals/0079-upgrade-self-from-weak-to-strong.md

apple/swift-evolution

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

Apple’s Chris Lattner has stated that “this is a compiler bug”.

8:45 AM

Swift特有のバグなのか仕様なのかわかんないアレかと思ってたけどクリスラトラー的にはバグなのか・・・

まぁ実用上使えているので問題ないといえば問題ないですけどね。そのうちコンパイラ通らなくなるので気づけるかなとは思っています。 (edited)

使うの避けようと思ってstrongSelfとか使うとカオスになって良くない、zelfとか使うのが良いのかなぁ

guard unwrap x else {} これ実装して欲しい

8:47 AM

同じ変数名でアンラップするやつ

8:47 AM

２回書くのヤダ

欲しいですね

strongSelf使いたくないですよね・・・

ワシはzelf派じゃ

8:48 AM

guard unwrap はMLで誰かが言ってたやつ

class→klass self→zelf this→? type→?

classをclazzとするからアリか...

thiz?

type は鬼門

あーclazz

先に言われたｗ < thiz

tyqe

8:48 AM

どうよ

ty9e は？

this -> thatとかもどこかで見た記憶が

天才か〜

JavaScriptだとthisをキャプチャするためにvar self = this とかあってスゴイ

@omochimetaru tyqeみたいですねそれ

マジクソなんでやめてほしい

JNI が thiz とか clazz とかだった気がする。

@t.ae よくみたら左右逆だったワ

unicodeつかえるしtyρeで

typ3

8:51 AM

tyqeで良いと思った

tyqeよくなってきた

8:51 AM

そういえば typ も使ったことある気がしてきた。

なんで予約後じゃない type を置き換える必要があるの？？

予約語の言語もあるので

typeが予約語である別の言語の話をしていました

なるほど。

#swift じゃなかったw

僕がunicode云々言ってるのだけswiftの話でしたね

2

↓このコード闇感ある・・・ let type = 42 type(of: type) // Int

それいま行けるんですかね

8:56 AM

変数strideがあったらstride()が呼べないとかあったような

Swift 3.1 で確認中。 3.2 とか 4 は知らないです。

8:57 AM

これができるのは type(of:) が特殊だからじゃない？

8:57 AM

関数じゃない

うん呼べましたね

8:58 AM

関数じゃないと言われたら関数じゃないのかと思うけどではなんと言うのかが分からない

あれ？関数なのかな？特殊な式だと思ってたけど

8:59 AM

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Expressions.html#//apple_ref/doc/uid/TP40014097-CH32-ID383

8:59 AM

ここに見当たらない

8:59 AM

ってか、 "The Swift Programming Language (Swift 4)" になってるんだけど気が早くないですか。

1

type(of:) は Swift3 ではパースの段階で特別扱いだったのですが、 Swift4 ではタイプチェック時に特別扱いということになったので、 4 だと Swift.type(of: ) にする必要があります。

9:02 AM

既存で type をシャドーイングしている箇所があったら、マイグレーターが面倒みてくれるはず。

なるほど、 Swift Programming Language が早々と 4.0 にアップデートされたことで Expression から消えたんですね。

確かに4だとダメっぽいですね let type = 42 type(of: type) // error: cannot call value of non-function type 'Int'

なるほど〜〜〜〜〜 > 4 だと Swift.type(of: ) にする必要があります。

tyqe？

というかこれ治んないんですかねべつにシャドウイングしててもいいところですよねこれ

9:04 AM

Swift2あたりでは確か行けてたはず

関数への参照なのか変数なのかわからなくない？

https://developer.apple.com/documentation/swift/2885064-type

あー変数がラムダの可能性はあるのか。

おおお、関数になってる。

内容が #swift みじみてきた

そうそう。 > ラムダの可能性

引っ越しましょう

ですねｗ

9:05 AM

ここは #general だった

会話の内容からチャンネル誘導するbotあったらよさそうだなあ (edited)

そういえば @mono さんのこの記事の

1

9:16 AM

https://medium.com/swift-column/discord-89019089480d

Discord に #wwdc チャンネルを用意したのでWWDCネタでワイワイできます

– Swift・iOSコラム – Medium

以下の記事で紹介しましたが、DiscordにiOS系開発者のチームがあります

こちらのリンクからiOS界隈興味ある方ならどなたでも参加できます

9:16 AM

上のは公開設定ではあるものの個人用のつもりですが、みんなで共有編集できるTrelloもありかなとも思ったり

特にDiscordはパーマリンク無くて発言が流れてしまい、昔の情報を追いにくい問題があり、Trelloなど併用して適宜ストックしておくなど良いかもと思ったり

9:16 AM

この件

9:16 AM

良さそう

1

9:17 AM

Trelloがなんなのか1mmの理解してないが

カンバンツールで色々使い方はありますが、これとか見ると1つの使い方としてイメージ湧くかもです。 https://trello.com/b/myf7rKwV/twitter-api-platform-roadmap

9:21 AM

https://trello.com/c/SYbf1BfN/285-please-note-we-are-no-longer-using-trello-for-our-road-map-it-just-doesnt-scale-well-we-will-use-github-issues-and-milestones-as

PLEASE NOTE -- We are no longer using Trello for our Road Map. It ...

1

9:22 AM

https://trello.com/b/5tj4qAvo/trello-ios-app

ふむふむ

9:23 AM

ちょっと湧いてきた

9:24 AM

悪意ある編集に対して過去の状態にロールバックしたりできるなら

9:24 AM

誰でも編集可能にして

9:24 AM

建ててみると良さそうな気がする

ロールバックはできないような

Wiki系の方が良いですかねー。

ふーむ

9:28 AM

コピペはそもそも厳しそうだな　崩れまくった発言勝手にアーカイブされると嫌な人も要るだろうし、トピックとしてまとめなおす必要があるなあ

これとかも面白そう。名前が似てる

http://www.discourse.org

Discourse - Civilized Discussion

Discourse is a civilized discussion platform for your community. Use it as a mailing list, discussion forum, long-form chat room, and more!

サービスをまたいじゃうとメッセージのオーナーが紐付かないから本人が削除したりできないんだな。

1

ちなみに、DiscourseはSwiftメーリスの移行先候補です(　´･‿･｀) https://medium.com/swift-column/issue19-91bc4cf17aa1 (edited)

Swiftレター #19 – Swift・iOSコラム – Medium

2017/02/05

SwiftMLの引越し先に検討されてるやつですね

有料なんですね https://payments.discourse.org/pricing

Discourse pricing

Offical Discourse hosting plans for communities of every size.

try it FREE　とは・・・

9:30 AM

FREE 14 day trial

9:30 AM

あー

質問です。APIのfetcherを使う時などにクロージャーを書くときの引数の型って省略しますか？僕は、右辺から型がすぐに推測できないものについては読み手に定義元を見る時間を奪うのが好きじゃないので省略しないのですが、どちらがいいのでしょうか？あと、物によりますが、型を書かなくて推論させるとどのぐらい遅くなるんでしょうか？

#swift チャンネルで返信します

#apple-official-event テキストチャンネルをリストを上の方に持ってきました

3

発言が最近にある順でチャンネルをソートしました

3

初めまして。monoさんのブログから参加しました。よろしくお願いします！

11

2

よろしくおねがいしま〜す

初めまして。monoさんのブログからの参加です。よろしくお願いしますー

9

5

4

よろしくでーす

初めまして、ダンボーの動向を追って参加してみました。宜しくお願いしますー

4

7

お、ラビーさんどうも

どうもでーす、いつもお騒がせしておりますー

#recruitment 作りました(　´･‿･｀)

1

ジョブズってことですか？

目的は、トピックの説明に書きました(　´･‿･｀)

iOS・Swift・その他Apple系のお仕事の募集・依頼をするトピック。

(edited)

なるほどッ

しかし、ジョブズと混同しますね

11:23 AM

https://swiftnews.curated.co とかにあるJobsぽいものがDiscordにもあっても良いかなとお試しです(　´･‿･｀)

2

11:24 AM

job から jobs にリネームしたのですが、job の方が混同は避けられそう

（素で反応してしまいました）

1

recruitとかofferとかはどうでしょう？

1

それだと単発の案件がカバーできなそう

1

悩みつつ #recruitment にしてみました

2

間も無くですね(　´･‿･｀) https://swift-tweets.connpass.com/event/55313/

Swift Tweets 2017 Summer (2017/07/22 21:00〜)

# 概要 Swift Tweets は Twitter 上で開催される Swift に関する Meetup Tweetup です。発表者が Swift についてツイートで発表します。 https://swift-tweets.github.io/ 当日は Twitter で #swtws のハッシュタグを御覧下さい。リプライやメンションするときもできるだけ #swtws のハッシュタグをつけて下さい。 Swift Tweets の目的の一つとして、オフラインの懇親会のように気軽に交流できる場をオンラインでも作りたいということがあります。開催中は面識のない...

1

裏会場だｗ

ちらっと思ったものの、趣旨とずれそうなので、トピックは作らず、リマインドにとどめました(　´･‿･｀) (edited)

ありがとうございます。

1

11:52 AM

僕もここの扱いをどうするのがいいのか迷ってます。ディープな話はここの方がしやすいんですけどね〜。

1

1分フライングしてしまった

宣伝しちゃいました

4

2

1

@koher すいませんバタバタしててみれてませんでした！おつかれさまです

1

初めまして〜。nnnさんからの招待で参加しました。Swift開発歴2年の未熟者です(._.)よろしくお願いします！

5

6

こんにちは

2

こんにちは

1:29 PM

お初です

1:29 PM

最新ios11,0? をダウンロードして (edited)

1:30 PM

ウハウハです

1:31 PM

開発は勉強中です

4

試しに #zatsu チャンネルを作りました。雑談用のチャンネルです。

こんにちは

1:20 AM

自分はiosのアプリを作っていてswiftという言語を習っています！

8

はじめまして。ひろしといいます。元ラーメン屋店長でswift、最近はSSS触っています

4

11

お、ひろしさんどうも

ひろしです。

今夜のイベント、ワイワイやるならどのチャンネルがいいんでしょ？

#apple-official-event を再利用でしょうか？

そう思いました、名前調整しましょうか

#event とか？

#apple-official-event

1

今夜のイベント、ワイワイやるならどのチャンネルがいいんでしょ？

#apple-official-event へどうぞです

ありがとうございます！

1

ios開発初学者です。よろしくお願いいたします。師は@hiragramです。

2

やめろよ

よろしくおねがいしますー

1

はじめまして。よろしくお願いいたします。

3

宜しくお願いしますー

1

iOSDCいく？

2:16 AM

チャンネル立てとくか

2:17 AM

#iosdc 立てました。

初めまして。よろしくお願いします！

14

お、rayさんだ

1

レイさんこんにちは〜 (edited)

1

7

1

はじめまして！田代といいます！よろしくお願いします！

7

田代さん！

1

はじめまして。よろしくお願いします〜 m( )m

6

Discordがアップデートされてチャンネルカテゴリという機能が実装されたようだ

2

1

bonjour

1:00 PM

hello ^^

3

1:01 PM

i from Paris

1

1:01 PM

nice to meet you

o.O welcome!

im french artist

1:02 PM

thanks

1:02 PM

everyone here from japan ?

2

1:02 PM

I love japan ❤

We're iOS developerps and mostly live in japan.

1

wwaaw so cool

3

Hi

11:39 AM

I'm from korea

2

11:40 AM

: )

1

welcome!

thank

11:43 AM

日本語を学んでいるが

1

11:43 AM

ゲームを一緒にする人いますか？

Do you mean to develop or play ...?

yes With the Japanese

Are you an iOS app developer?

no i'm pc now

11:48 AM

play game

11:48 AM

no develop : )

11:49 AM

I just want to play games with Japanese people.

11:49 AM

I think it will help me study Japanese.

Most people in this chat are developer and most topics are about programming so I don't know whether you can find people to play games.

oops

11:51 AM

i'm sorry...

今日の21時からですね(　´･‿･｀) https://swift-tweets.connpass.com/event/62883/

Swift Tweets 2017 Fall (2017/10/21 21:00〜)

# 概要 Swift Tweets は Twitter 上で開催される Swift に関する Meetup Tweetup です。発表者が Swift についてツイートで発表します。 https://swift-tweets.github.io/ 当日は Twitter で #swtws のハッシュタグを御覧下さい。リプライやメンションするときもできるだけ #swtws のハッシュタグをつけて下さい。 Swift Tweets の目的の一つとして、オフラインの懇親会のように気軽に交流できる場をオンラインでも作りたいということがあります。開催中は面識のない...

10:56 AM

https://twitter.com/search?f=tweets&q=swtws (edited)

#swtws - Twitter Search

The latest Tweets on #swtws. Read what people are saying and join the conversation.