Swift を使ってみてがっかりした点まとめ

数日間iOS8/Xcode6/Swiftな環境で色々試してみて、Swiftを使っていて思ったよりがっかりした点が多かったのでちょっとまとめてみようと思います。 動的な処理がSwiftだけでは一切できない [NSObject performSelector:]の類と、NSInvocationがSwiftからは一切呼び出せません。使おうとすると怒られます。objc/runtime.hは試していませんが、同様に直接Swift経由では呼び出せず間にObjective-Cをかます必要があるのではないかと思われます。 @optionalなprotocolが限定的にしか使用できない 具体的には@objc属性を付けないと使えません。しかしながらこのような後方互換性のためだけに存在する属性をいつまでもAppleがサポートするかは疑問が残るというのと、もう一つ以下の様な問題があります。 @objc属性のついた

[fusionstar]

Objective-C の遺産的なものはバージョンが進むことでなくなっていくことを期待したい。

[sionsou]

メリットばかりじゃなくてこういうのありがたい

[kazuhooku]

わかるわかる。つまりvtableとrefcntを使うメモリ破壊おきないC系の言語ってことで、そういう問題点も含めてSwiftは良いところついてると思う

[kasumani]

Swift を使ってみてがっかりした点まとめ 数日間iOS8/Xcode6/Swiftな環境で色々試してみて、Swiftを使っていて思ったよりがっかりした点が多かったのでちょっとまとめてみようと思います。 動的な処理がSwiftだけでは一切できな

[Haaaa_N]

参照カウントって…

[korinchan]

メモリ管理必要なのはがっかりするところじゃなくて、iOSもMacもパフォーマンスの問題が避けられないGCを意図的に排除してる。

[decoy2004]

『ARC 。Swiftでも循環参照が発生しないようにプログラマが明示的に参照の種類を指定しなければなりません。』

[Magicant]

あぁ……

[nemoba]

参照カウント方式はポインタが更新されるタイミングしか解放されないが、GCはあるタイミングでチェックして解放するので循環参照毎解放される可能性がある、比較的クロージャに強い。でもJava8はなんちゃってクロージ

[hisasann]

「closureでselfをキャプチャするときの循環参照対策が相変わらず必要」これまだ残っているのか

[at_yasu]

後々対応しそうよね / NSThread が Selector 呼び出ししとげほえなｓｄｆ

[an_old_pencil]

めもめも

[t-wada]

objc 属性や循環参照の話。このあたりは悩ましい。

[solidstatesociety]

🍣ですし。

[dowhile]

GCのないモダンな関数型・OOP言語というのは割合珍しいのでは

[milkya]

“ARC”

[f-shin]

良い展開

[macbookero]

swift

[KAZUMiX]

“Swiftのメモリ管理はGCではなくARCでありただの参照カウント方式”(´･_･`) ここはパフォーマンスを優先したってことかな

[yashigani_w]

循環参照の話めちゃめちゃつらみある

[yatemmma]

weakself直ってないのか…

[mizchi]

これクロージャがある言語なら仕組み上発生してしまうと思う。その解決法は提案されてない気がする。

[shields-pikes]

ええー。つまり、動的な処理をゴリゴリ書くならSwiftだけじゃ無理で、Objective-Cの併用も必須ということなのかな。

[rryu]

やっぱりARC周りは鬼門なのか。

[ledsun]

なるほどー

[tanakh]

closureのはしんどそうだなあ…

[mas-higa]

Swift にも coffee みたいのがいるかもね。

[uasi]

let f = { self.foo() }; if (cond) { self.f = f } else { other.f = f } すると unowned かどうか静的に決まらないんでは

[muchonov]

今まであまり出てこなかった、具体的なネガティブ面に触れる記事。修正ききそうな部分と、アーキテクチャ／プロジェクト的に今後もいじらなそうな部分と。

[hush_puppy]

とりあえず、循環参照しようがしまいが全てのクロージャーに`[unowned self] in`って書いとけばいいのかな？