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

2017/06/28(水) 17:58:29.74

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

関連スレ

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

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

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

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

前スレ
Swift part10
http://mevius.2ch.net/test/read.cgi/tech/1487552413/

スレ立て時は1行目に「!extend::vvvvv」

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

2017/07/24(月) 12:00:46.09

rustのメモリ管理の仕組みを見てきたけどプリプロセッサで何とかなるというものじゃなかったから、
c++ならあると言うものじゃなかった。
言語仕様から改変か必要なものだったよ。

簡単に言えば、メモリの参照は一箇所に制限されて、そこからしかアクセスできないようにする。

たから、もしswiftでrustのメモリ管理機構が導入されたら、
100%既存のコードでは動かないし単純に変換もできない。
ロジックの見直しが必要だからね。

例えば配列にループアクセス中は
配列に対する変更操作はすべてコンパイルエラーになる。とか。

2017/07/24(月) 12:08:11.82

いやownership manifesto読めよお前ら
全部書いてあんのに

2017/07/24(月) 14:33:26.45

>>148
https://github.com/sandym/swiftpp
これじゃねえの？XcodeありきObjective-Cありきだろ？
これじゃねえ、どれやねん？

2017/07/24(月) 15:17:51.01

>>161
「メモリの参照は一箇所」
まあ、そうかもしれんけど、俺の理解では参照カウントを１以上に上げない
様なメモリ管理ポリシーを実践する事で、メモリリークは防げると思う。

それから、Instrumentsとdebuggerを活用するのが吉。
最近気がついたのが、command+IでInstruments leaksを起動して捕捉出来なかったメモリリークが、不思議な事に、break pointで一旦止めてdebuggerからInstruments leaksを起動すると捕捉できるんだよねぇ。

2017/07/24(月) 22:22:24.32

>>151
マジか
俺ずっと「つ」って読んでたわ

2017/07/24(月) 22:26:31.27

=ア【はい】

こういうのも👉に見えてなかったとか…

2017/07/24(月) 22:40:40.19

>>153
つ http://i.imgur.com/PCvtAbc.jpg

2017/07/24(月) 22:52:15.68

ﾉｼ

2017/07/24(月) 23:24:01.06

>>153
手の平。
https://nanapi.com/ja/25657

https://m.chiebukuro.yahoo.co.jp/detail/q1410591729?__ysp=MmNoIOOBpA%3D%3D
[つ]は手を表現しています。

例えば、[（・∀・）つ旦]というAAでしたら
旦はお茶のAAですので、
お茶をハイ、と差し出している様子を表しています。
２ちゃんねるでは省略形をよく用いますので
顔文字が省略されて[つ]のみで使用されます。

>>165
まじっす！

2017/07/25(火) 00:35:48.08

つ⌒□

馬券、車券、くじ券をすてている

2017/07/25(火) 11:28:49.52

>>170

そんな、補足説明が必要なAAなんて、不要だわぁ。

2017/07/25(火) 13:50:52.52

わかんねー奴の方が少数だから

2017/07/25(火) 18:36:52.92

>>135
つまりは皆が出来ないうちに自分だけはSwiftを沢山書けるようになっておけば、Swiftがゴリ押しされたときに先行者利益を得られると思ったけどそうはならなかったから悲しいってことだろ？
別にAppleが推してないなんてことないと思うし、Obj-Cを崇めてる奴なんていないと思うし、Swiftはまだまだバージョンごとに変更がある割には十分普及してると思うけどな

大体Swiftをちょっと書かないと作れないぐらいのレベルだったら大してSwiftの知識もいらないと思うし銭稼ぎできるようなもんでもないと思うんだけどな
はじめにObj-C使わなきゃいけなくなったときに本1,2冊ぐらいしか買ってないし、Swiftに関してはお金まったく書けてないし、金稼ぎできる要素がある気がしない

>>138
C++をブリッジするとなるとC++の複雑な機能全てをブリッジ出来なきゃ有用性が落ちそう
限定された機能で書かれたC++コードだけブリッジしてくれるとかだと結局C++側がそれ以外の機能使ってたらラッパー書かなきゃいけなくなるし、落とし所が難しそう

2017/07/25(火) 21:49:06.28

Swiftの完成度が最初から高ければ状況は違ったかもな
あとむだにWithout Cに走ったのは筋が悪かったと思うわ

2017/07/25(火) 22:11:09.32

C++ブリッジってそれもうwith C++だからな
テンプレート除けばそれなりに出来るだろうけど
テンプレート除いたC++に対応したところでだから何なのって話になるし

2017/07/26(水) 00:11:43.09

Without Cをぶち上げたんだからもうCに関わるなよ
韓国人かよ...

2017/07/26(水) 00:29:39.23

Cライクforもインクリメント、デクリメントもなくす無駄な徹底ぶりだからな

2017/07/26(水) 06:41:21.77

Pythonぽくて好きよ

2017/07/26(水) 12:41:46.12

なんかswiftどんどん構文追加して複雑になってないか？
phpみたい

2017/07/26(水) 12:46:08.87

せめてObjCみたいって言ってくれよ

2017/07/26(水) 12:53:13.70

>>176
マルチプラットフォーム化に加えて
膨大なossがcやc++で書かれてるんだから無視は不可能だ。

2017/07/26(水) 13:24:53.92

Without Cは言語仕様(構文)の話

2017/07/26(水) 16:59:40.71

むしろ、Objective-Cの「インスタンスは母体クラスに［おまえのインスタンスを作れ］命令で作成します」とか
「クラス間の通信はクラス［命令:引数］で明示的に他のクラスに実行させてるとわかります」が好きだったので
そのあたりswiftが「退化」しちゃったのが嫌。

言語仕様とクラス仕様が分離しててクラスライブラリだけ進歩してくとか
ソース内で自他の表記がしっかり別れてて「ここであいつがこれやって次…」
と読めるのが気に入ってたのに
他のグチャグチャモダン言語と同じ言語仕様変更地獄と
ソースになんだかわからない誰かが作った記号が普通に混じりますって
これ、ずっとプログラミング文化の発展阻害してた奴だ…と

2017/07/26(水) 17:12:34.07

>>183
>明示的に他のクラスに実行させてるとわかります

Swiftでは分からんの？

2017/07/26(水) 17:16:43.62

>>184
いやわかるよ

2017/07/26(水) 17:17:39.81

>>183
>ソース内で自他の表記がしっかり別れてて

これ何のことを言ってんの？
自他の区別がつかない言語なんてあんの？
そんな精神病みたいなプログラムあっても実行できなくね

2017/07/26(水) 17:37:22.29

多分全部staticで書いてんだろ
おそらくインスタンスとクラス、動的メッセージと静的メソッドの違いがわかってない

2017/07/26(水) 19:04:57.26

$

↑こいつ

今までの理念をぶちこわすような暴挙
itでもなんでもよかったのになんでこれにした

2017/07/26(水) 19:22:50.49

一方俺は、ObjCの言語仕様にクラス変数が追加されて、既存フレームワークのクラスメソッドがクラス変数に変わって発狂していた

>>188
$0, $1, etc.として複数引数の場合でも引数記述を省略させるためでしょ
シェルスクリプトを書いたことないとなんぞこれってなるが、it0, it1よりはスマートだと思うが

2017/07/26(水) 19:32:05.98

>>181
なので普通に考えるとObjective-C 3.0として改良発展させるのがよかったと思うんだよね...

2017/07/26(水) 19:33:29.48

>>183
禿同すぎる

2017/07/26(水) 19:44:28.65

>>189
いちいち引数に名前つけさせて、
省略できるのはひとつまでって感じで今まできてたじゃん！

ここにきてこれ
itですら多少は意味があるが、$ってなに？
なんで急にドル記号が出てくんの

2017/07/26(水) 20:10:19.84

itの方がマシというのは別に否定しないけど
「今までの理念」というのはSwiftには無くね

2017/07/26(水) 21:11:05.37

俺はitより$nの方がマシだと思うけどね

「名前を省略する」ためのものに「名前をつけた気になる」ために$nをやめてitにするってかなり本末転倒じゃない
どうせ具体的な名前が無いなら、極めて曖昧なitなんて単語じゃなく、どこまでも記号的な$nでいい
敢えて単語にするならanonymousArgumentとかclosureArgumentとかにして、クロージャの名前がない引数であるという意味を表さないと
itなんて、$nと同じぐらい何も意味を表さないのに、無駄に単語の体をしてるだけタチ悪いと思うわ

逆にwillSetの引数名省略時のnewValueみたいに、最低限あらかじめ意味が限定されてるところでは、$nでもitでもなくちゃんと最低限の意味を表す省略形になってる

2017/07/26(水) 22:07:58.73

どーでもいいけどいい加減syntaxのセンスがクソ過ぎやしないか？

2017/07/26(水) 23:04:09.76

シンタックスのセンスなんてどーでもいいし・・・

2017/07/26(水) 23:45:24.29

本音をいうと省略させたくない
書き方増やしてどうする

2017/07/27(木) 00:17:20.77

俺も書き方のバリエーションが増えるのは反対だな。誰が書いても同じ文法で、誰が書いたコードでも誰でもさっと読めるのが理想だったな。

2017/07/27(木) 00:19:52.29

swiftでrxSwiftさわったらすごくRxがわかりやすくなったのは良い思い出。
objcだとわけわかめだった。
構文って結構学習コストに関わるんだなって理解した瞬間でした。

2017/07/27(木) 00:21:32.40

>>198
Haskellが普及しないのは、その理想を追い求めすぎてるからだけどね

2017/07/27(木) 00:27:01.52

>>200
書き方のバリエーションの少なさでいったらgoがいい感じではないかと。
中括弧の位置すら強制するからね。

2017/07/27(木) 10:53:29.63

objCは文法に多様性がありすぎて俺には理解できなかった

2017/07/27(木) 19:10:53.39

Blocks構文は「それそういうクラスじゃいかんの？Cに付け足す理由は…？」といまだに

2017/07/27(木) 19:22:06.60

>>199
ObjCにはCocoa Bindingがある。

2017/07/27(木) 20:21:49.26

>>204
双方向バインディングとRxを一緒にするない。

2017/07/27(木) 21:59:22.87

>>202
メッセージ式は面食らったが、CとJavaをやってたからあんまり覚えることなかったけどなObjC

2017/07/28(金) 08:50:56.18

>>183
> クラス［命令:引数］

スレチ引っ張って悪いけど、ObjCにこういう記法あったっけ？
[クラス命令:引数] とかだと思ってたのだが…

2017/07/29(土) 08:59:34.62

>>207
そだね

2017/07/29(土) 13:02:57.19

レベルに合わせた書き方すりゃいいじゃんよ
generics,typealias,operator overload この辺は無理して使うことない
boilerplate無くしてえなーもっとコードを直感的に書きてえなー、そもそも今までの書き方飽きたから違った書き方してえなー
という欲求が生まれた時に導入すれば良い。そうすりゃObjCとも大して見た目変わらんしな

2017/07/29(土) 17:08:58.83

>>209
なるほどぉ。
ところで、Swift -> ObjCへ移行する時に、RxSwift相当のFramework
って、ReactiveCocoaって事になるのかなぁ？

2017/08/05(土) 14:14:44.53

Swift一発屋になってんじゃねえか。
ピコ太郎だってもっとまともにやってるぞ。
もっと頑張れよApple。熱くなれよ！

2017/08/06(日) 17:25:37.14

>>210
言っておくけど、Rxとobjcは全く相性が悪い。
なんでかというとあのobjcのメッセージ式
Rxってメソッドチェーンが無いとかなり実装しづらいのに
objcでは書けないのだよ。
[]のネスト地獄を味わう事になる

2017/08/06(日) 17:36:38.87

Rispも知らないんだろうなぁ..

2017/08/06(日) 17:37:55.69

>>212
なるほどぉ
Cocoa BindingとかCore Dataを使えって事なのね。
ところで、ObjC Wizardの方々は、Core Data使うんでしょうかねぇ？

2017/08/06(日) 17:49:19.26

LISP

2017/08/06(日) 20:13:36.95

Lispのtypoかよw
そういうワードがあるのかと真面目に受け取ってた

あ、自分はvim派なんでelisp含め使ったことないわ
elisp wizardは変態だと尊敬してる

2017/08/06(日) 22:21:23.59

>>216
すまんｗ
まあメッセージ式のネスト地獄もLisp様から見ればかわいいもんですｗ

2017/08/07(月) 09:36:54.43

>>212
メソッド呼び出しに、ドット構文が使えればObjCも描きやすくなるよねぇ。
Objective-C 3.0に期待だね。

id a = [[NSObject alloc] init];
->id a = NSObject.alloc().init(); // こんな感じ！

2017/08/07(月) 10:15:21.88

既にクラスプロパティとオブジェクトプロパティで実現できてるね！ObjCはすごいね！
クラスプロパティの存在を知らないんだろうなぁ、ObjCについてもうちょっと勉強してこい

2017/08/07(月) 11:43:23.35

>>219
いや、引数あったら出来ないだろ

ところでドット構文マンセーな人ってiOSやる前は何の言語がメインの人？

2017/08/07(月) 12:05:53.21

>>218
obj-cの魅力ってあくまでcの拡張でありobj-cの世界は[]の中だけってスタンスであってほしいから
ドット構文?はあんまり増やしてほしくない
個人的にはElixrのパイプ演算子(|>)をobj-cに採用して欲しい。
(元ネタはElixirじゃないかもしれないけど。)

[NSObject alloc] |> [@ init]
みたいな感じで使う。Elixirの場合だと返却値を次のメソッドの第一引数に渡すって意味だけどobj-cでは@を置き換えるみたいな感じで

2017/08/07(月) 16:52:39.28

|> の元ネタは F#

2017/08/07(月) 20:27:43.12

>>218
>ドット記法
既にできたような..

2017/08/07(月) 21:19:58.43

>>223
自己レス
プロパティへのアクセスだけだた

2017/08/07(月) 23:19:41.66

最近ObjC ageが激しいがnukeとかvaporとか読んで腰が引けちゃった連中が多いのかな？
ああこれc++の再発明かなと思うくらい難解なコードになってきたからな
POPがあるからまだ扱いやすいが

2017/08/08(火) 23:44:13.59

SwiftはC++っぽくて地雷にしか見えない。
闇の軍団が好きそうな言語。

2017/08/09(水) 07:04:14.41

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

>>226がアンチスレに行かずObjC ageする狂信者にしか見えない

2017/08/09(水) 13:10:58.09

Objective-Cがまぁ長年主に言語仕様を弄るんじゃなくて
外部のクラスライブラリ更新で"外"に括り出してきたタイプの問題を
2010年代になっていまさら言語仕様直接変更の繰り返しで泥沼って
そりゃ車輪の再発明ってレベルじゃねーぞっつか…
あきらかに(筋の悪い)車輪を知らないところからの使者が
「おまえら未開の蛮族にまったく新しい言語を作ってやるぜ」って
泥の中でのたうってるのを眺めてるこの感じ。

2017/08/09(水) 14:43:22.78

ObjCが長年プロパティ、GC/ARC, ブロック文, nillable, ジェネリクスと言語仕様追加を繰り返して泥沼を作ってる中で
Swiftという新しい泥沼を作ってくれたから皆で泥遊びをしている中、泥遊びって子供かよ・・・と高二病な感じ
一緒に泥遊びしようぜ、やってみたら案外楽しいよ

2017/08/09(水) 14:56:18.93

>>229
Objective-Cでもジェネリクス可能なのか？

どのレベルまでできる？
1. 型汎用な関数
2. 型汎用なクラス
3. 型汎用なプロトコル
4. 型汎用なプロトコル・エクステンション

2017/08/10(木) 00:13:58.72

泥遊びで沼にはまるのは今日の全国的な運勢なのか？

2017/08/11(金) 11:21:49.75

離れて分かるObjCのやかましさと優しさ

2017/08/15(火) 12:29:40.52

LattnerがGoogle Brainに就職
やっぱり人工知能やりたいんだな

2017/08/15(火) 12:33:22.46

Google BrainといったらTensorFlow開発してるところだから、これはいよいよTensorFlowがオフィシャルにSwift対応するかもしれん

2017/08/15(火) 13:50:50.41

良かったな、お前らの教祖様の就職先見つかって。

Apple「Swift」の生みの親がテスラの自動運転開発をやめてGoogleの人工知能開発チーム入り
http://gigazine.net/news/20170815-google-hire-apple-engineer/

2017/08/15(火) 15:23:09.38

もう秋田

2017/08/15(火) 15:23:31.58

あのおっちゃん短期で技術リーダー採用してくれる所を探してたよな
来年には再転職しそう

2017/08/15(火) 15:27:52.81

>>235
kotlinの開発に参加しそう

2017/08/19(土) 04:02:37.38

Swift 5のゴールの一つに設定された非同期実行の構文の議論がevolutionメーリスで始まってる

・kicking off concurrency discussions by Ted Kremenek
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038891.html
・async/await + actors by Chris Lattner
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038892.html
・Concurrency in Swift: One possible approach by Chris Lattner
https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782

2017/08/19(土) 12:28:05.32

どうせまたリスケするんでしょ、、、とか思ってるけど
それとは別にラットナーのgist記事がRustのオーナーシップモデルをディスっててワロタ
Rustライクなメモリ管理をSwift4で投入するって言って結局Swift5に持ち越したのは忘れんぞ

ファーストクラスの非同期とファーストクラスのオーナーシップモデルを並走させるのはキッツイだろうがどうするんだろうね
理論的には出来なかないだろうが時間も技術力も足りずどっちかSwift6に持ち越しすることになるんじゃねーのか

2017/08/19(土) 12:40:33.92

オーナーシップは初めから「4には入れられないけど」「将来的に～」ってエクスキューズしてた
オーナーシップを4のゴールに含めるなんて話は一度も出てないはずだが

2017/08/19(土) 18:39:02.10

思うんだけどrustのオーナーシップモデルって後付で入れられるものなの？
rustを見る限り無理そうだし、
スマホの性能もこれから上がっていく一方なのに学習コストが上がる
メモリオーナシップモデルって導入する意味あるのん？

2017/08/20(日) 00:21:00.45

学習コストが上がるのはそれを必要とする人だけ
というのも設計要件の一つ

https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md
>Criteria for success

2017/08/21(月) 16:42:51.48

SwiftからObjective-CのArreyを取得しようとすると、x0756846 のような、メモリーアドレス？しかとれないのですが、何か特別な変換とか必要ですか？

2017/08/21(月) 16:47:08.07

>>244
詳しく

2017/08/21(月) 17:20:19.06

>>245
CManeger.mmの関係しそうなところ
@property (nonatomic, readwrite) NSArray *hoge;
データ取得関数の最後に
self.hoge = hoge.array;
dispatch_async(dispatch_get_main_queue(), ^{
[self.delegate CManager:self didCompleteWithCandidates:self.hoge];
});
とあり、ブレークポイントはって確認すると、取得したデータがhogeにある。

HOGE-Bridging-Header.h
#import "CManager.h"

Hoge.swift
let objcCMng = CManager()
let ret = objvCMng.hoge
print(ret)

出力データは
Optinal([<CCandidate: 0x170226b80> , <CCandidate: 0x170226ce0>)]
という感じになります。
ただし、デバックエリアで確認するとself>objcCMng>_hoge>_orderedSet>_array>[x]>_hogeに取得データがあることは確認できます。
型変換か何か必要なのでしょうか？

2017/08/22(火) 07:28:48.92

>>246
let ret = objvCMng.hogeを
let ret:Array! = objvCMng.hoge
にしてみたら？

2017/08/22(火) 08:07:48.74

>>247
ありがとうございます。
試しましたが、出力結果はほとんど同じでした。

[<CCandidate: 0x170226b80> , <CCandidate: 0x170226ce0>]

2017/08/22(火) 11:05:06.00

何がみたいのかよくわからんのだが、、
dumpだとどうなる？

2017/08/22(火) 12:26:03.39

多分descriptionをオーバーライドしてなくてprintで<CCandidate: 0x170226b80>みたいに出力されるのと、型変換してなくて[AnyObject]?型のままになってるのの複合で混乱してるんだろう

前者はCCandidateのdescriptionを自分の望みどおりの出力をするようにオーバーライドすればいい
後者はSwift側で as? [CCandidate] するか、Obj-C側で @property (nonnull, nonatomic, copy) NSArray<__kindof CCandidate *> *hoge; とかすればいい

2017/08/22(火) 21:55:20.85

>>249
some: 2 elements
- <CCandidate: 0x170226b80> #0
super: NSObject
- <CCandidate: 0x170226ce0> #1
super: NSObject
となります。

まだはまってます…

2017/08/22(火) 22:44:59.20

何したいのかいまいちわからんな
>>250のいう通りにすればいいだけだろとしか思えない

2017/08/22(火) 23:00:38.58

>>250
ありがとうございます。
書き込み頂いた情報を元に、objc-cの言語仕様を調べながら触ったんですが解決せず、AnyObjectに問題を絞りこんで見ました。

結果、出力部分のコードを書き替え、データの取得が出来ました。

for i in 0..<objvCMng.candidates.count{
let ret = objvCMng.candidates[i] as AnyObject
print(ret.candidate)
}

皆様、ありがとうございました。

2017/08/22(火) 23:03:37.53

>>253
candidatesとhoge置き換えミスってます…

2017/08/23(水) 14:27:29.61

let blue = #colorLiteral(red: 0, green: 0.4577052593, blue: 1, alpha: 1)
let white = #colorLiteral(red: 0.7803494334, green: 0.7761332393, blue: 0.7967314124, alpha: 1)
let orange = #colorLiteral(red: 1, green: 0.5803921569, blue: 0, alpha: 1)
let red = #colorLiteral(red: 1, green: 0.2352941176, blue: 0.1882352941, alpha: 1)

2017/08/27(日) 21:39:01.72

型推論とか何がうれしいのかさっぱりわからん

2017/08/27(日) 21:46:40.55

長ったらしい型名ばっかのコードは思考が阻害される
型チェックはしてるんだからべつにデメリットもない

2017/08/28(月) 10:03:17.19

ビルドに時間がかかるようになるだろ。型推論なんて使わないほうがいい

2017/08/28(月) 13:08:18.25

Swiftの型推論は単純だからObjCの型チェックとビルド時間は変わらないけどな
Rustくらいに賢い型推論して欲しいよ

2017/08/28(月) 13:53:01.33

https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html

2017/08/28(月) 14:18:27.43

その解説だと型推論じゃなく数値型がstructであることが本質の問題だよね？

let a: Double = -(1 + 2) + -(3 + 4) + -(5)
と
double a = -(1 + 2) + -(3 + 4) + -(5);
で違いが出るならそれはコンパイラ組み込み型を常用せずstruct型扱うからでしょ

プリミティブ型削って構造体型を多用するSwiftはイマドキだよな
NSIntegerみたいに32bitなのか64bitなのか分からんことになるよりは良きも悪きもあるわな