Swift part10 [無断転載禁止]©2ch.net

2017/02/20(月) 10:00:13.40

WWDC2014で発表されたAppleの新言語Swiftについて語りましょう

関連スレ

プログラミング言語Swift　Part4
http://potato.2ch.net/test/read.cgi/mac/1484763495/

[SDK]iPhoneアプリ開発初心者質問箱48[touch][iPad]
http://potato.2ch.net/test/read.cgi/mac/1484217623/

Xcode part14
http://potato.2ch.net/test/read.cgi/mac/1476190499/

Swiftアンチスレ part1
http://echo.2ch.net/test/read.cgi/tech/1458491343/

前スレ
Swift part9
http://echo.2ch.net/test/read.cgi/tech/1476758084/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2017/05/25(木) 19:55:10.84

でかいデータをstructにつっこんで扱う時に注意すべきことが書いてあるだけだろ
つまり代入が頻繁に発生する状況でも、そのプロパティに実際にアクセスがあるまでコピーを遅延させるテクニックについて触れられてるだけ
別に関数の引数に値型を使うなとかとんちんかんなことは書いてないな

2017/05/25(木) 21:10:12.75

SwiftでCOW意識する人なんているんだ。
そういう人はC++とかRustとか使えばいいのに。

2017/05/25(木) 22:26:04.80

最適化しない場所も含めて意識くらいはするでしょ
その程度のことで言語を変える理由にはならんよ

むしろStructでCoWという設計だからこと気兼ねなく渡せるってことに気付いた方がいい

2017/05/26(金) 05:16:56.16

誤: StructでCoWという設計だからこと気兼ねなく渡せる
正: Array StructでCoWという設計だからこと気兼ねなく渡せる

どうしてもSturct全般でCOWが適用されると思い込みたいアホが食いしばってて笑う

2017/05/26(金) 07:23:41.84

>>686
「Structが」じゃなくて「Structで」な
Arrayに限らず、StringやDictionaryなどのstructでCoWを実装したもの全般

classでCoWを実装する場合は使う側が明示的にcopy()clone()などを呼ぶかinitを使う必要があるが
structでは代入,引数渡し,戻り値がコピーセマンティクスなので透過的に扱うことが出来る

2017/05/26(金) 08:03:17.32

COWの話題から、いつの間にか参照渡し/値渡しの解説になっててワロタ
結局はSturctでCOWが常時適用されるわけじゃないから気をつけようってこったな
参照渡し/値渡しの違いを知らないLL言語勢もいるかもしれんが、別の問題だから気にしない

>>671のReducing Dynamic Dispatchの節も面白い
SwiftはObjective-Cと違ってダイナミックディスパッチを減らす機構を持ってるぜ、と
これを徹底的に使い倒したら、局所的にはObjCよりSwiftの方が性能よくなる可能性が微レ存？

2017/05/26(金) 08:31:19.29

細かいところだけどclassは参照の値渡しでinoutは参照渡し

2017/05/26(金) 08:45:20.46

>>676
protocolにまつわる言い回しを色々見ますが、どれが適当なのでしょう？

1. protocolを切る
2. protocolを当てる
3. protocolに準拠させる

すべてadding protocol confromanceの訳語だとおもうんですけど。

2017/05/26(金) 08:49:45.12

最近のCPUはSIMD命令(SSEとかAVRとか言われるやつ）を内蔵していて、
でかいStructも一発でコピーできるって、理解は正しいっすかねぇ？

512bitレジスタが32個あって、しかもその32レジスタはペアで使える。
って事は、512bit x 32個 = 2Kbyteを一発でレジスタ -> メモリへmoveしたり
メモリ -> レジスタloadできる。

この理解はOKっすかねぇ。

2017/05/26(金) 10:19:08.37

>>689
in-out引数は参照渡しじゃない
in-out引数のセマンティクスはあくまでcopy-in copy-outで、最適化で参照渡しになる"場合もある"だけ
リファレンスではin-out引数が参照渡しであると想定したコードを書いてはいけないとはっきり言ってる
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID545

var i: Int = 0 {
willSet { print("willSet: ¥(newValue)") }
}

i = 1 // prints "willSet: 1"
i = 2 // prints "willSet: 2"

func f(_ v: inout Int) {
v = 3
v = 4
}

f(&i) // prints "willSet: 4"

参照渡しなら"willSet: 3"と"willSet: 4"両方表示されるはずだけど
実際には関数に入るときにiの値がvにcopy-inされ
関数から出るときにvの値がiにcopy-outされるので
copy-out時の"willSet: 4"しか表示されない

2017/05/26(金) 10:43:47.67

>>692
すんばらしい、説明

2017/05/27(土) 14:04:16.20

>>692
え…
参照渡しと値渡しで違う動作するとき
動作がどっちになるかわからんってこと？

2017/05/27(土) 21:00:43.52

>>694の心の声
(やべぇ、まじかよ…。バグ仕込んじまった…)

2017/05/27(土) 21:48:41.96

inoutで渡された配列変数のオリジナルを関数内で操作しても副作用はないみたいただけどな

var a = [Int]()

func f(_ v: inout [Int]) {
v.append(3)
a.append(4)
v.append(5)
}

a.append(1)
f(&a)
a.append(2)

print(a) // [1, 3, 4, 5, 2]

ただ、それを想定するなということなんだろ

2017/05/27(土) 21:57:51.65

SwiftってiOSアプリ以外に広がる可能性ある？

2017/05/27(土) 22:13:54.38

少なくともwillSetがある場合は参照渡しの最適化が掛からないようだね
以下のAはcopy-in, copy-outになっていて、Bは参照渡しになってる
http://swift.sandbox.bluemix.net/#/repl/592977d0d72c2a7516859cca

2017/05/27(土) 22:20:21.28

>>696
いやそれ副作用ある状態じゃん
関数終わった時点で
a=1,4
v=1,3,5
だからoutでvがaに上書きされて
1,3,5,2 が出ないといけないはず

2017/05/27(土) 22:21:46.44

>>696
var a = [Int]() { willSet{ } } にしたら [1, 3, 5, 2] になるね

2017/05/27(土) 22:26:06.26

えええええ
ほんとに動き違うのかｗｗｗｗ

2017/05/27(土) 22:26:19.82

>>699
aの内容を変更するためにf()にaを渡したのだから、f()の中ではaとvは同じ扱い
なので、inoutの仕様からすれば、>>696の挙動が自然だと思うけど

2017/05/27(土) 22:30:22.71

willSetの有無で挙動が変わるのはいただけな
デバッグで混乱する元になる

2017/05/27(土) 22:31:17.31

>>702
>>692のリンク先
In-out parameters are passed as follows:
1.When the function is called, the value of the argument is copied.
2.In the body of the function, the copy is modified.
3.When the function returns, the copy’s value is assigned to the original argument.

コピーされるて書いてあるやん！

2017/05/27(土) 22:38:43.72

>>704
そこに
As an optimization, when the argument is a value stored at a physical address in memory, the same memory location is used both inside and outside the function body. The optimized behavior is known as call by reference
とも書いてある。参照を渡して最適化されると。
それに依存して関数内で参照元にアクセスするなとも書いてあるけど

2017/05/27(土) 22:41:57.41

>>705
うん、>>692を誤読してた
動作変わるのは最適化って言わねーよ！

>>696ってほんとに試したんか

2017/05/27(土) 22:47:16.42

>>706
Playgroundにコピペして試してみればいいだろ

2017/05/27(土) 22:49:30.62

Write your code using the model given by copy-in copy-out, without depending on the call-by-reference optimization,
so that it behaves correctly with or without the optimization.

…最適化と言い張ってるがこれはひどい

2017/05/27(土) 23:01:24.62

このぐらいの最適化はやってくれた方がありがたい
参照渡しの方が確実にパフォーマンス上がるし、通常の使い方で副作用もない
副作用があるようなら書き方に問題があるだろ
inoutで受けた変数のオリジナルにアクセスするコードにワーニングぐらい出してくれたら
とも思うけど、まだそこまで面倒は見きれないんだろ
ただ、最適化の恩恵にあずかりたいなら、willSetなんかは入れない方がいいみたいだな

2017/05/27(土) 23:07:17.91

>>706
いや最適化だよ
参照渡しにしたとしても、外形的にcopy-in copy-outした場合と全く同じ動作をする場合にだけ、参照渡しに最適化される
ただ、>>696みたいなコード書くとその最適化の前提がぶっ壊れるから絶対するなとリファレンスでも言ってるだけで

リファレンスにはっきりやるなと書いてることをやって壊れたからってそれはプログラマの責任でしょ

まぁ将来的にownershipが入れば>>696みたいなコードもちゃんとコンパイルエラーにしてくれるようになると思うよ

2017/05/27(土) 23:47:08.68

willSetがあるとmutating funcもself自体がcopy-in copy-outになった
これもリファレンスのどこかにあるのかな

struct A{
var v = [Int]()
var onAppend: (()->())? = nil
mutating func f() {
v.append(1)
onAppend?()
}
}
do {
var a = A()
a.onAppend = { a.v.append(2) }
a.f()
print("willSetなし", a.v) // [1, 2]
}
do {
var a = A() {willSet{}}
a.onAppend = { a.v.append(2) }
a.f()
print("willSetあり", a.v) // [1]
}

willSetなし [1, 2]
willSetあり [1]

2017/05/28(日) 00:12:22.92

willSet/didSetの挙動が怪しすぎるな
バグなのかもな

2017/05/28(日) 08:47:45.67

>>712
いや挙動的には予想通りだよ
didSetはともかく、willSetの方は呼ばれたコード内では「変更前のオリジナル変数」と「変更後のnewValue」が用意されてるから別の実体作って変更してる
想像だけどinout引数を持つ関数側はバイナリコードレベルでは常に参照で受取るようになっていて
willSetがある変数でmutating funcやinout渡しをすると、呼ぶ側が一時変数作ってそれを渡すコードを生成してると思う

var a = A() { willSet{ } }
a.f() //mutating func f()
　　　↓
var a = A()
func a_willSet(_ newValue:A) { }
do {
var tmp = a
tmp.f()
a_willSet(tmp)
a = tmp
}

inoutの場合は a.f()とtmp.f() が f(&a)とf(&tmp)になるイメージ

2017/05/28(日) 09:31:38.11

この挙動を理解してなければ、structにwillSet/didSetを実装してパフォーマンスに意図しない影響を与える可能性があるな

2017/05/28(日) 11:21:48.67

>>697
ないっしょ…
なぜSwiftとかいう自己満発展途上言語なんか使ってるかって言ったらApple様ご指定だからってだけだし

2017/05/28(日) 11:31:20.31

mutatingはselfをinoutで渡す
a.f() // これは
A.f(&a)() // これと同じ
なので一般のinout引数と同様にmutatingメソッド内のselfもセマンティクス的にはcopy-in copy-out

ただmutatingが暗黙にselfをinoutで渡すって説明はリファレンスには見つけられなかった
リポジトリのdocsに放り込まれてる文書群ではしばしば言及されてるけど

2017/05/28(日) 12:29:40.83

気軽にプロパティ変えたつもりの1行で、コピーが3回も（うち2回は配列全体のコピー）発生するのね
structのwillSetは曲者だな

struct Weapon {
var name: String {
willSet { print("new wepon name = ¥(newValue)") }
}
}

struct Monster {
var name: String
var weapons: [Weapon] {
willSet { print("new weapons = ¥(newValue)") }
}
}

var monsters = [
Monster(name: "Goblin", weapons: [Weapon(name: "Knife")]),
Monster(name: "Orc", weapons: [Weapon(name: "Sword")]),
Monster(name: "Dragon", weapons: [])
] {
willSet { print("new monsters = ¥(newValue)") }
}

monsters[1].weapons[0].name = "Mace"
// output
/*
new weapon name = mace
new weapons = [Weapon(name: "Mace"]
new monsters = [Monster(name: "Goblin", weapons: [Weapon(name: "Knife")]), Monster(name: "Orc", weapons: [Weapon(name: "Mace")]), Monster(name: "Dragon", weapons: [])]
*/

2017/05/28(日) 12:30:23.95

クラスで実装すれば、wellSetあってもコピーはプロバティに対しての一回だけ
class Weapon {
var name: String {
willSet { print("new wepon name = ¥(newValue)") }
}
init(name: String) {
self.name = name
}
}
class Monster {
var name: String
var weapons: [Weapon] {
willSet { print("new weapons = ¥(newValue)") }
}
init(name: String, weapons: [Weapon]) {
self.name = name
self.weapons = weapons
}
}
var monsters = [
Monster(name: "Goblin", weapons: [Weapon(name: "Knife")]),
Monster(name: "Orc", weapons: [Weapon(name: "Sword")]),
Monster(name: "Dragon", weapons: [])
] {
willSet { print("new monsters = ¥(newValue)") }
}

monsters[1].weapons[0].name = "Mace"
// output
/*
new wepon name = Mace
*/

2017/05/28(日) 12:35:53.43

Swift初期にJavaScriptに似てるからWeb屋が参入してくるとか言ってた人もいたけど全然違うしSwiftはObjective-Cより仕様が複雑になってきたね
でもおかしなコードはコンパイラがビシバシ教えてくれるし仕様を詳しく知らなくてもとりあえずコードを書く事はできるかな？

2017/05/28(日) 22:04:52.22

Swiftけっこう難しい
Objective-Cは形式張っていてコードがやたらと長くなるだけで実はそんなに難しくない

2017/05/28(日) 22:35:10.01

>>720
俺もSwift難しい。
structにprotocol適用したり、protocol extensionとか。

2017/05/28(日) 22:44:58.49

詰め込みすぎて開発者のスキルでコードが変わりすぎるのが難点

2017/05/28(日) 22:57:25.17

>>720
C知ってればハードル高くないからなObjCは

2017/05/28(日) 23:22:08.09

そのCがハードル高いからな初心者には

2017/05/28(日) 23:28:56.75

SwiftとCのどっちがハードル高いかって言ったらCとは言えないけどな
Cのシンタックスをベースにしてる言語は多いから、初学者にSwiftとC
どっちをやった方がいいかって言われたら間違いなくCだわ

2017/05/28(日) 23:30:24.66

初心者にポインターは結構ハードル高いと思うけど
あとメモリ管理にシビアな所とか

2017/05/29(月) 00:25:02.54

Cもわからんようなもやしエンジニアが増えると思うと先が思いやられる
ソフト屋もハードウェアに近いプリミティブな部分の理解は必要なんだけとな
そういう意味でCは高級アセンブラ的なバランスがちょうどいい

2017/05/29(月) 00:38:37.93

>>726
ポインタが難しいって言ったって、結局ポインタ的なメモリの知識はあった方がデバッグでメモリ周り疑う疑わないに直結するしなぁ。。。

2017/05/29(月) 00:47:58.23

でも今は簡単なゲーム作りたいとかなら特にポインタの知識なくても作れちゃうからなぁ
初心者にC言語でゲーム作ってだと難しいと思うけど、Swiftなら割と簡単
モグラたたきとかジャンケンゲーム程度なら初心者でも2,3日で作れるかも

2017/05/29(月) 00:57:45.02

誰もポインタないと作れないなんて言ってない。
ポインタの知識はトラブった時にトラブルの原因の候補にメモリが上がるか？どう状態かを推測出来るか？ってのに直結する。
ポインタと言うか、メモリの構造を知らなけりゃトラブルの原因として候補にすら上がらない。
下手すれば永延と原因分からないまま、プログラムは未完に終わる。

2017/05/29(月) 01:03:25.64

そんなこと言い出したら究極的にはコンパイラの癖とかハードの特性とかまで知らないとデバッグできないことになる
初心者にそこまで求めるのは余りにも遠い道のりになる

2017/05/29(月) 01:19:59.07

そこまで言わんが、初心者と言えどもCPUとメモリの仕組みは理解してからプログラミングは始めて欲しいものだが。

体験して見たいだけなら兎も角、プログラマになりたいんならね。

2017/05/29(月) 06:40:45.44

kotlin nativeがllvm対応してるらしいのでiosでもkotlin使えそう。
となればswiftはもういいかな。

2017/05/29(月) 07:01:38.32

フフってなった
昔、SwiftもLLVMだからどこでも動くって言ってたなぁ

まぁKotlinは頑張ってポーティングしてるようだから
実用性はさておき動くんだろうけど

2017/05/29(月) 08:51:21.58

>>722
C言語のソースも、人によって全然違うけどなぁ。
とくに、Headerファイルのマクロ定義によってソースの印象がガラッと変わる。

2017/05/29(月) 09:10:28.76

>>735
Cと比較したらCのがやりたい放題に決まってるだろ…
関数をアドレス指定で直接コールできる言語やぞ…
比較対象がおかしいわ

2017/05/29(月) 10:41:09.25

ポインタとか分からんレベルの人にはやりたい放題出来ないがんじがらめの世界の方がいい気はする
柔軟性はObjective-Cで安全性はSwiftなイメージ

2017/05/29(月) 11:13:19.98

>>733
Kotlin/Nativeなんてのがあるのね！
知らんかった。JVM無しで動くコードが作れるのかな？

2017/05/29(月) 11:14:56.30

It is not a fully functional release yet,

Kotlin/Nativeがどの程度動くのか？気になる。

2017/05/29(月) 11:27:53.51

>>729
ポインタ分からないって人は、参照型の値型の違いが理解出来なくないか？

2017/05/29(月) 12:04:20.43

参照型と値型の違いがわからなくても使い方さえ理解できれば簡単なアプリは作れるからな
ある程度の最適化はコンパイラがやってくれるし、ハードの性能も上がってるから、多少の冗長性は無視できる
C言語だとそうはいかない
ポインタを知らないとまずまともなアプリはつくれない
外部のライブラリを利用する場合もポインタの知識は必須になる
ポインタの理解が参照型の理解の助けにはなるだろうけど厳密にはポインタと参照型は同じものでもないし

2017/05/29(月) 12:14:04.16

それは、ポインタを知らなくても使い方さえ覚えれば簡単なアプリは作れる、っていっても同じじゃないか？

2017/05/29(月) 12:33:55.33

ポインタの場合は概念を理解しないで使い方だけ覚えるってのはちと無理がある
Swiftの参照型は概念をきっちり理解できなくても、大概動くものは作れるし、変なことやろうとしてもIDEやコンパイラが注意してくれる

2017/05/29(月) 13:11:45.84

>>740
ポインタしらなくても挙動でわかるだろ

2017/05/29(月) 13:27:25.51

>>744
じゃなくて、ポインタの概念を理解出来ない人は、参照という概念も理解出来ないって言う意味だけど
挙動で理解出来てるなら、それは理解出来る人だよ

2017/05/29(月) 13:29:35.62

>>745
参照を理解できたからとポインタも理解できたとは言えない
大小が逆

2017/05/29(月) 13:38:22.24

そもそも初心者は参照型だ値型だとあまり意識しないんじゃないか
意識しなくてもコードは書ける
Swiftならね

2017/05/29(月) 21:45:25.45

>>741
だからObjective-Cはいろいろと素晴らしいと考える人が少なくないんだと思うけどな

2017/05/29(月) 21:47:34.02

今後出現して欲しい本

SwiftプログラマのためのKotlin入門

Androidアプリ作りたいけど、Javaは嫌なんだよなぁ。

2017/05/29(月) 21:59:32.56

>>749
そんな本なくてもswiftの簡単版みたいなもんだから余裕でかける

2017/05/30(火) 01:08:42.87

iosもandroidも共通で言えることなんだけどさ、もう一段フレームワークが欲しい。どっちもuiライブラリ止まりで、
全体の管理を行う部分が開発者任せで、正直困る。一画面アプリ止まりならそれでもいいんだけどさ。

2017/05/30(火) 01:09:28.67

？？？

2017/05/30(火) 01:21:48.80

>>751
例えば？

2017/05/30(火) 02:18:06.30

ステート管理だけで言えばreactのreduxみたいなやつとか。
あれってファイルの置き場所とかもある程度誘導されるから迷いが減るんだよね。

2017/05/30(火) 09:52:12.97

ソースファイルの置場所も公式に決まってないSwiftに何期待してるのか
まずはSwift Package ManagerとXcodeで共通化することから始めよう

2017/05/30(火) 10:07:35.91

俺もパッケージマネージャが複数あるのが好かんなぁ。

1. Carthage
2. CocoaPods
3. Swift Package Manager

俺は1.がxcodeprojへの変更が少なくて好みだ。
2.はxcodeprojをどう変更してるのかが、見えない。

2017/05/30(火) 10:49:53.98

CocoaPodsはオープンソースだからxcodeprojをどう変更してるかは見えるだろ

2017/05/30(火) 10:53:32.01

Swiftとはちょいと違う事で質問です。
UMLモデリングって最近でも使われますか？
使う目的は何でしょう？

1. すでにあるコードの解析
2. これから作成するコードの可視化

2017/05/30(火) 11:24:11.63

そんなこと聞いてどうすんの？と聞き返したくなるような質問すんな
皆が使ってるなら使ってみようかってことか

2017/05/30(火) 11:24:54.00

しかるべきスレへ行ってはどうか

2017/05/30(火) 12:41:12.92

>>758
モデリングのために決まってんだろ

2017/05/30(火) 13:35:34.23

>>755
まさにこれ。決めてほしい。
それかアップル自身が公式にリファレンスとなるアプリをオープンソースにしてほしい。
react-nativeだとf8appがそれっぽいが。

なんかそれなりの規模のオープンソースアプリないかな。

2017/05/30(火) 14:59:25.27

swift.orgのPackage Managerのページにゴミのようなサンプルはあるけど
自身(SPM)のことしか考えてないから、自分で作った方が良いだろうねぇ

Swift Package Manager
https://swift.org/package-manager/#conceptual-overview
Package.swift作って、Sources, Testsディレクトリ作る

CocoaPods
https://guides.cocoapods.org/syntax/podfile.html
Podfile作る, Sources/*.swiftを参照

Carthage
https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md#cartfile
Carfile作る, Sources/*.swiftを参照

Xcode
上の全部を適当にpodが作った.xcworkspaceのプロジェクトツリーに加える

2017/05/31(水) 11:13:03.77

qiitaのKotlin記事を読んでて出くわしたphrase。

Android アプリ開発者であれば普段から英語を読んでいると思いますし、平易な英語なので大きな問題はないと思います。

俺にはComputer関連の英語文章が難しく感じるのだけど、どうなんでしょう？
exressionを式だと理解するのに、随分時間がかかったと思う。

2017/05/31(水) 12:18:51.47

和書にも専門用語は英訳も一緒に載ってること多いから違和感無かったけど、入門してすぐ洋書だとそう感じるかも。

2017/05/31(水) 12:45:27.84

たしかに！

順方向伝搬(forward propagation)って書いてあるね。和書には。
expressionを式、statementを文と訳すのは判ったけど、和書には「式文」
ってのが時々出て来て、これ何を翻訳したんだ？

と不安になる。

**デフォルトの名無しさん** (JP 0Hcf-Evzo) · 2017/05/31(水) 16:07:11.28

そんなあなたに
Regular Expression
はどう訳す

2017/05/31(水) 16:13:04.68

>>767
いつも良く使うマッチ式

2017/05/31(水) 16:16:42.72

regular = いつもの
例：regular customer = 常連、regular coffee = 日々よく飲むコーヒー

regular ¥= 正規 = formal, proper

2017/05/31(水) 16:19:06.25

正規表現って訳語は、誤訳だわぁ。

2017/05/31(水) 16:19:30.13

誤訳を永遠と使い続けるのは、よく無い。

**デフォルトの名無しさん** (JP 0Hcf-Evzo) · 2017/05/31(水) 16:25:25.52

>>770
石田晴久が糞って有名ですし

2017/05/31(水) 16:37:31.63

>>772
まあ、情報が入手しずらい時代に苦心して日本語を当てたって感じだ。

Microsoftの文書を読んで、まったく意味がわからんかったのを思い出さしてクレルわぁ。DAO ActiveX Library, RDO ActiveX Libraryに関しての記述を読んで、
さっぱり意味不明だった。和文も、英文も。

サンプルコードを見たら一発で理解できた。

2017/05/31(水) 19:53:48.08

>>771
じゃあ
リベンジ：復讐
を、なんとかしてよ。

あとfeatureをフューチャーって発音するのもなんとかして欲しい。

2017/05/31(水) 20:15:00.41

>>774
頭悪そ。

2017/05/31(水) 21:26:00.22

>>750
Swiftより簡単なの？

2017/05/31(水) 21:33:41.18

>>750
知ったか

2017/05/31(水) 21:47:41.16

>>776
果てしなく簡単

2017/05/31(水) 22:53:30.93

swiftが言語仕様固まらないうちにkotlinがios対応しちゃうな。

2017/05/31(水) 23:40:55.86

Swift使ってる自分が好きな人

2017/06/01(木) 08:38:33.85

モダンな言語Swiftを使ってる最先端な自分

2017/06/01(木) 09:47:53.31

swiftは作る奴の思考によってパラダイムが変わるから他人のコードがストレスになる糞言語
いっそのことclassを消してしまえばいいわ