swift-developers-japan

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

これは僕もfileprivate導入しっくり来てなかったです(　´･‿･｀) (edited)

2:17 AM

ファイルスコープのprivate概念自体は好きです

「fileprivate廃止してswift2仕様に戻そうぜ」

The private keyword should be reverted back to its Swift 2 file-based meaning and the fileprivate keyword should be deprecated.

これ派ですね

2:20 AM

こんなすぐ戻そう議論が出てくるくらいのものを https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md でどうして採用に至ってしまったのかなと不思議です

メーリス漁れば分かりそうですが

http://www.hasegawa-tomoki.com/development/2016/06/07/slack-ios-developers-ja/

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

そこらへんの空気感は謎ですね

1

2:22 AM

自分自身は、微妙な気はしつつも、SE25のレビュープロセスの時に当事者意識は無いので何も言えんけど (edited)

2:25 AM

@mono ここって招待自由ですか？

@omochimetaru 自由です、アクセス権など弄って無いですが、それもじゃんじゃん付与してしまってよいかな気分です(　´･‿･｀) でも、作って放置状態なので、ちゃんと話したい場合、 https://ios-developers-ja.slack.com の方がオススメだと思いますが(　´･‿･｀)

@mono あれ、こんなのもあるの・・・

ほんとだ

あつまった

2

2:40 AM

@hiragram さっきの件だけど、メソッド足すだけでconformできるのと、フィールドも足さないとできないのは大きな違いがあると思う

一番新しいので言うと、cellHeightsを管理するのは誰ぞという。何かしら任意のタイミングで変更しなきゃ使えないじゃん

2:42 AM

アイコン変えたい

@tarunon アイコン設定しよ

@omochimetaru たるのん氏にもURLはったけど　http://qiita.com/usagimaru/items/664d0d67fe6f8f7fafed#%E3%81%B2%E3%81%A8%E3%81%A4%E3%81%AE%E5%9B%9E%E9%81%BF%E7%AD%96　例えばこういうのをやろうと

Autolayout で UITableViewCell の高さを設定すると reloadData 後にカクカクすることがある ...

# 未だセルの高さ計算処理は面倒くさい気がする ![cells.png](https://qiita-image-store.s3.amazonaws.com/0/3603/1d878a3a-42b2-ac56-d5ce-6cf69...

変えた

@tarunon willDisplayCell で cellHeights を更新して、 estimatedRowHeightAtIndexPath で読み出すからdelegateメソッドでしか使われてないよね、という話ではなく？

2:43 AM

@mono おじゃまします

気持ちはわかる

willDisplayCellだとestimatedRowHeightに関与できなくね

2:45 AM

できるの？

2:45 AM

おっと、打ち合せだ、一旦離脱します

気持ちはわかるんだけど、なんかそういうの楽にやりたいとかは、ビューとかに限った話で

humu

ライブラリとかでそういうフィールドが外装されてる可能性があるとしんどい

そのしんどみがまだピンときてないんだけど、ライブラリ使用者としてということだよね

最近カスタムビュー作るほどではないなってときに Extension でプロパティ持てなくて死んだし、気持ちとしては間違いなくあるもののうーん

@biacco42 カスタムビューじゃないのにプロパティもつ意味がぜんぜんわからん

2:48 AM

@biacco42 生のUIViewを改造したいって意味？

2:48 AM

@hiragram そうだね、どこから何が変化してどういう状態遷移するのか、ソースコードだけから追いかけようとした時に

2:48 AM

@hiragram フィールド(StoredProperty)ってのは足場として重要

ImageView にドラッグアンドドロップお試しでつけたいなー、お、Extension あるやんけ(死亡) みたいな (edited)

あー、状態を持つものがあっちこっちにあるとそもそも読むの辛いよねという話ね

@biacco42 なんかそれは逆に継承してカスタムビュー作れば良いだけの話じゃない？

2:49 AM

カスタムビュー作るほどではない

2:49 AM

↑ここが気持ちが弱いだけに見える

2:49 AM

カジュアルにカスタムすればいいだけ

気持ちが弱いのはそれはそう

あと、もしそれができちゃうと、別の所のImageViewも影響を受けちゃう

それは思った

@hiragram うんうん

読むの辛いはわかるものの、やっぱりextension+stored property欲しいという気持ちはある

問題はさ

2:52 AM

そのstored propertyがそのextensionだけからしか使われて無ければ

2:52 AM

いいけど

2:52 AM

そのstored propertyをまた他のところから参照してたりするとカオスになりそう

それはわかる

@hiragram なので、ViewControllerとかは、あまり読む事大事じゃないと思ってて、１度書くことの重要性が実際高いと思う

2:53 AM

ViewControllerは画面仕様と結合度が高いから再利用する事自体稀だし。

やりたいことはスコープというか文脈ごとにextensionを分けてその中のprivateなメソッドとプロパティで全部それぞれが完結して他のextension同士は互いを知らなくていいっていうのがやりたいなあなのでextension内のプロパティをそのスコープ外に公開したいきもちはない

それってさ

2:54 AM

そのやりたいことの単位を

型に分けろ説はある

classかstructにまとめれば

2:54 AM

保証できるのでは？

それな

で、実装本体は、そのまとめた単位を並べるコードと

2:55 AM

メソッドをそのまま転送するコードの束にすると

2:55 AM

見通しが良さそうだし再利用性も高そう。

やっぱちゃんとやるならそうやって型に分けるべきだよね〜

やりたいことをextensionごとにわけて隔離するつもりがあるなら、型切っておけばうっかり相互依存するのも防げるしね

でっかいクラスをザクザクextensionに分けまくっていらないプロパティを消しまくるみたいなリファクタを最近やったのでextension好き〜という気持ちが勝手に高まってるだけかもしれない

なるほど

2:57 AM

なんか引き継ぎで萎えてたやつかな

そう

やっぱextensionでフィールド追加は良くないなあと思ってきた

3:02 AM

最近カスタムビュー作るほどではないなってときに Extension でプロパティ持てなくて死んだし、気持ちとしては間違いなくあるもののうーん

3:02 AM

↑これが氾濫しそう

3:03 AM

hirariの言ってる自作クラスの実装の縦割りのためならまだわかるけど

3:03 AM

UIKitに対してそれをやるようになって

3:03 AM

秩序が完全に終わりそう

カスタムビュー作るほどではない

プロダクトコードなら殴りそう

3:04 AM

まーTextKitの系がヒラギノでレンダリング終わってて一括で変えたいとかはあるんだけど

前述の通りプロトタイピングでお試し実装したかったときなのでさすがにプロダクションには載せないですね…

OtameshiImageView一個作っておけばok

1

UIKitに対してそれをやるようになって秩序が完全に終わりそう

それは起きそうなので出来なくていいので https://twitter.com/hiragram/status/844008993932505089 class HogeObj { } が書いてあるファイルでのみHogeObjのextensionにstored propertyを持たせられるようになったらな〜という話。これだったらUIKitのクラスに対してextensionでstored property足せない

@hiragram

大元の定義と同じファイル内だったらextension内でstored property使えるようにしてくれよ

なるほど。

自作クラスの実装の縦割りのためならまだわかるけど

コレだけができれば僕ははっぴー

class本文の中で // MARK: -- で分けるのはどうかと思ったけど、 protocol conformanceが一番上に集まっちゃうから微妙かな (edited)

結局みんなどうしてるのか気になる

「このプロパティはこの範囲でしか使われない」ということを明示したくて、且つその範囲をなるだけ狭くしたいので、それだと達成できないかなー

やはりそれは別classだなという感じがしてくるｗ

3:13 AM

機能要件としては完全にそう

3:14 AM

他の言語だと、「あるprotocolへのconformanceは、フィールドでもってるこのオブジェクトに全部転送する」ことを1行で記述できたりするんで

それが欲しいな

そういうのがあるとクラスで分けた時に、転送メソッドを書き下す手間が無くて良さそうじゃないか

@omochimetaru それきになる　他の言語ってたとえばどれですか

ちょっとまってね

Rustで見た気がしたけど提案にすぎなかった

3:23 AM

https://internals.rust-lang.org/t/syntactic-sugar-for-delegation-of-implementation/2633

Syntactic sugar for delegation of implementation

Sorry if something similar has already been proposed. In short A nice feature of usual OO languages is the implicit code reuse through inheritance: the fact a subclass does not need to redeclare any method existing in its base class provided the behaviour is the one expected. Wouldn't it be a nice feature if Rust had some syntaxic sugar to mimic this ? Composition and inheritance When I have: // java-like language interface Foo { void doSomething(); } class Bar : Foo { void do...

3:23 AM

https://ja.wikipedia.org/wiki/%E5%A7%94%E8%AD%B2

委譲

委譲 (delegation) とはオブジェクト指向プログラミングにおいて、あるオブジェクトの操作を一部他のオブジェクトに代替させる手法のこと。

3:23 AM

Go[編集] Go言語においては、他の言語と異なり始めから委譲を想定した委譲専用構文を備えている。

(edited)

3:24 AM

Goもそれっぽい機能があったけどなんか詳細が、コレじゃない感

3:24 AM

http://magazine.rubyist.net/?0012-BundledLibraries

Goか

rubyのこれも近いけど、言語自体にinterfaceが無いせいでメソッド全部並べてるな・・・

3:26 AM

https://kotlinlang.org/docs/reference/delegation.html

Delegation - Kotlin Programming Language

Kotlin is a statically typed programming language for the JVM, Android and the browser, 100% interoperable with Java

3:26 AM

あった！

3:26 AM

kotlinだ！

3:26 AM

interface Base { fun print() } class Derived(b: Base) : Base by b

3:27 AM

bはこれ、型名のところに書いてるけどコンストラクタ引数とフィールド定義を同時にやってるので、 b は Base 型のフィールドで、 Derived が Base に conformさせるのを by b で指定してる。

3:28 AM

The by-clause in the supertype list for Derived indicates that b will be stored internally in objects of Derived and the compiler will generate all the methods of Base that forward to b.

"Baseに準拠したbをもってDerivedもBaseに適合したことにする" ということよね

そうです〜

これは良い

これが class の右にしか書けないけど、 Swiftなら conformanceがそもそもextensionに書けるわけだから

3:30 AM

extension UserStatusViewController : UIScrollViewDelegate by scrollViewDelegateMixIn {}

3:30 AM

みたいに書けたらイイネ

おー

scrollViewDelegateMixIn は UserStatusViewController の storedProperty名で struct ScrollViewDelegateMixIn : UIScrollViewDelegate という型がついてる想定。 (edited)

3:31 AM

あーまあフィールドは class { } の中に書かないといけないならkotlinみたいに上のところでもいいのかな

今でもscrollViewDelegateの実装をクラスに切り出すことは出来るはずで(VCがGenericsなら3.1以降で)

6:36 AM

extension ViewController { class ScrollViewDelegate: UIScrollViewDelegate { //ここに実装 } } だけどこれでも、ViewController.ScrollViewDelegateの宣言は本体側にないといけないよね、そこは解決しないのでは。まあすっきりはするか。

@tarunon うん、ここで話してたのは、クラスを切っても結局デリゲートメソッドを転送するだけのメソッドを全部書かないといけないのがめんどいね、という問題がのこるので、そこの糖衣構文がほしいねという事

別にViewController.ScrollViewDelegateをDelegateにセットする、でも現状大きな問題ない気がするけどな

それおもった

だけど、糖衣構文が有ろうと無かろうと、var scrollViewDelegate: ScrollViewDelegateをどこに書くの？と言う問題は残っている

@tarunon ああ〜 tableView.delegate = self の右辺が self じゃなくてもいいじゃんって事か

そう

すっかり忘れてたけどそれは確かにありだね

class ScrollViewDelegate: NSObject, UIScrollViewDelegate { weak var parent: ViewController? } とかでまあおおよそ問題はないはず

var を書くのは本体class {} 部分でいいじゃんと思ってるけどね〜

それでいいなら現状そういう作り方すれば問題はなくなる

6:49 AM

どこに入れるかは趣味がありそうだけどね

まあ、それで解決するのはScrollViewみたいな .delegate = なケースだけで (edited)

6:49 AM

一般のprotocol conformanceの話では成り立たないけど

そうね

あれ、Discordって

6:51 AM

syntaxハイライトあるのか。

1

適当にmarkdown書いたら普通に動いてびっくりしてる

Slackに対する優位性だ

6:57 AM

let a = 3

6:57 AM

let a = 3

6:57 AM

おお〜〜〜

6:57 AM

言語指定構文も使えるやんけ

めっちゃいいじゃんこれ

# 見出し

6:57 AM

コードブロックだけか

aaa

6:58 AM

strong1 strong2 (edited)

や _ による強調はできたけど

引用もさっき使った感じなかった気がする

箇条書きやリンクはできなかった

https://www.google.com

引用だめなのか

custom emojiはないんですか

@hiragram あるよ

あ、リンクってのは Swift みたいなの。

あるのか

僕が入ってる身内の鯖で変な絵文字流行ってる

シンタックスハイライトはいいなぁ。できれば箇条書きもほしいけど。

- aaa - bbb

6:59 AM

なるほど

@omochimetaru なんでコードフェンスの中に箇条書き書いてるの？？

@koher なんかこの中がすごい構文なのかなって試した

7:01 AM

画面共有機能を含む「Discord」のアップデート予告が公開 https://t.co/YpgCv5yPkh

7:01 AM

画面共有できるようになるならSkypeのユースケース消えるわ

引用は結構使うから > で引用できないのはちょっと微妙だなぁ。

@koher 引用や箇条書きは > や - のままでも見た目にわかるし平気な気もする

@omochimetaru まあ、たしかに Slack みたいに >> の二段目だけ > になっちゃうよりマシかも？

2段目問題なんてあったのかｗ

とりあえず > とか - で書いておいて Discord のアップデートに期待とか

2

https://github.com/Microsoft/TypeScript/issues/8476#issuecomment-288340157

Check non-undefined properties are initialized in the constructo...

class C { p: number; // Should be an error under --strictNullChecks method() { this.p; } }

9:22 AM

@koher との合作でコメント投稿した

9:23 AM

class C { p: number; // Should be an error under --strictNullChecks method() { this.p; } }

1

やっぱ GitHub だと見やすいね。 Swift の ML も早く移行してほしい。

Swiftユーザー各位には信じられないと思うがTypeScriptが提供する --strictNullChecks はこのようなコンストラクタでのフィールドの初期化忘れに対して何も検査しないため簡単に undefined を踏むのだ (edited)

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031657.html

Githubに移行して治安維持出来るのか気になるマン

GithubじゃなくてDiscorseという掲示板？サービスよ

9:28 AM

治安は悪くなるけどそれこそこういう事は減るんじゃないかな・・・ https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md

swift-iuo-implicit-cast.swift

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

www

9:29 AM

「俺達は雰囲気でfileprivateとprivateを使い分けている」

9:29 AM

って割りとありそう

今日まさに、 private プロパティに（同じファイル中の） extension からアクセスしようとして残念な気持ちになった。

9:30 AM

private let な定数をそっと ViewController の外に出した・・・

外ｗ

private struct Hoge {} fileprivate struct Hoge {} これが一番モニョい

@tarunon 別に定義できんの？

いや違う

9:31 AM

両者が(多分)同じ

9:31 AM

ああ、中身が外から見れなくなる違いはあるか?

確かにトップレベル private 書く時、意味が fileprivate なので微妙な気持ちになる。private func とか。

あ、そうなのか。なるほど。

9:32 AM

トップレベルにおけるprivateはスコープがファイル、みたいな雰囲気か

9:33 AM

クラスの中とかだとprivateがそのクラス自身でfileprivateだと外側のファイルレベルまで広がると

そのクラス自身

そのスコープ。同じファイルでも extension の中からはアクセスできない

extensionはクラスの外ってイメージでした。

9:36 AM

SwiftMLのフォーラム引越しのスレ見て

9:36 AM

スレッド別れまくってて「いいね！」みたいなレスがついてるだけだったりして

9:36 AM

やはりMLは無理ではという気持ちになる

9:37 AM

「引越しプランは追って出すけど忙しいからとりあえず方向性だけアナウンスしたよ」　って感じのようですね

今日まさに、 private プロパティに（同じファイル中の） extension からアクセスしようとして残念な気持ちになった。

昨日まさに同じことになってた

class Cat { var a: String { didSet { // 呼ばれない print("nyaa") } } init() { self.a = "a" } } Cat() @here 知ってた？

知ってる

おー

最初にdidSet呼ばれない、はーーー

2:21 AM

ってやった

今ためしてて気づいてた。

didSetはselfのメンバにアクセスできるから

そう！

initより前に使えると破綻する

そのあたりの挙動を探ってて俺の推測も同じ結論。

2:23 AM

ワンチャンswiftも本物のヌルポが出せるのかと思ったが残念。

調べたけどよくわからなくなった

4:39 AM

https://gist.github.com/omochi/90326839d097cc162c0d7e30d5f5e9bb IUOの暗黙キャストについて調べた結果。メソッド呼び出しは T? へのキャストはされない事がわかった。 T と T? 両方行けるときは T? になることがわかった。

まあ妥当だと思う

4:39 AM

だけど遅そう

https://gist.github.com/omochi/ea49fb9cae8b1073c6cedfa1661b697c 元々のコンパイル時間の増大について調べた結果。要素が1つ増えると、コンパイル時間が4倍に増える。

swift-heavy-compile-time.swift

4:41 AM

両方通る場合は T? になることから、 T では駄目になる事を検証しているという仮説は成り立たなかった。 T と T? の倍々で増えていくという仮説についても、 4倍で増えていくことから成り立たなかった。

うーん

4:45 AM

4:45 AM

これを見る限りはTとT?があり得る場合にTを優先しているようにも見えるんだが

ちゃう、それは俺の検証見るとわかるけど、そもそもメソッド呼び出しの時は T? への暗黙キャストはしない。

4:46 AM

.hoge() ってドット構文になった時点で Int しか試されない。

ふむ

両方を試すのは関数が引数IntとInt?でオーバロードされてるときだった。

func commonIntFunc(_ x: Int?) -> Int {...} func commonIntFunc(_ x: Int!) -> Int {...} この2つは共存出来ないのか

マジか

IntとInt!は共存できるので

4:50 AM

引数としてはInt?の扱いに近い

ほんとだ〜〜

この検証だと

4:51 AM

引数の時に特別扱いされることが考慮されていないので

4:51 AM

Int?が優先される証左にはならない気がする

うーんでも、純粋な検証はそもそもできないよ

まあそらなw

常に何かしらの場合に依存した検証になってしまう。 (edited)

4:52 AM

さっきのはコンストラクタ呼び出しだったから

4:52 AM

コンストラクタ呼び出しと関数呼び出しで挙動が違う可能性は否定できないから

4:52 AM

まあコンストラクタも試してみたほうがいいかも。

コンストラクタも同じっぽいね

4:53 AM

でもこれ

4:54 AM

TとT?をオーバーロードしてる時にどっちを優先するか、と

4:54 AM

T!からT?へキャストをするときの性質がどうなのか

4:54 AM

は、完全に別の問題な気がしていて

4:54 AM

この検証は面白い結果だけど

https://gist.github.com/omochi/ea49fb9cae8b1073c6cedfa1661b697c 15個時点で47分かかるンゴね

swift-heavy-compile-time.swift

ｗｗ

16個を試すと退勤時刻が来る・・・

どんなmacでやってるのん

@hiragram ひらりのやつは引数が２個だったけど、シンプルに１個にして調べたよ

okok

MacBook (Retina, 12-inch, Early 2015)

ちっさいやつか

1.3 GHz Intel Core M

つらすぎる

機種名: MacBook 機種ID: MacBook8,1 プロセッサ名: Intel Core M プロセッサ速度: 1.3 GHz プロセッサの個数: 1 コアの総数: 2 二次キャッシュ（コア単位）: 256 KB 三次キャッシュ: 4 MB メモリ: 8 GB

引数

引数2個で、5KのiMacで配列が6個のとき15秒なんだけど、引数1と2でこんなに違うんね

多分引数2個で要素6個は引数1個で12要素と同じだから

8:02 AM

で、僕のだと12個のとき33秒だから

8:02 AM

そっちが15秒なら2倍ぐらいの速度が出てるってことかな？

8:02 AM

多分並列化が効かないタスクで単純に周波数のスピードになってる

2x6ってことか

3GHz x 4core ぐらいじゃない？

↑機種名のやつってどこでみれるの

で、単純に単一コアでの3GHz : 1.3GHzの比率

8:03 AM

左上のりんごのアイコンから

8:03 AM

このmacについて　→　システムレポート

機種名： iMac 機種 ID： iMac17,1 プロセッサ名： Intel Core i7 プロセッサ速度： 4 GHz プロセッサの個数： 1 コアの総数： 4 二次キャッシュ（コア単位）： 256 KB 三次キャッシュ： 8 MB メモリ： 32 GB

4G!

8:04 AM

つっよ

会社のだよ

うん。

Speeeはアプリエンジニアこれだよ

おー

8:04 AM

俺のも会社費用だけど、個人的な希望で軽い方がいいから

8:04 AM

スペックは下げてる。

8:05 AM

MBP15inchの人が多いね。

いま1個席が空いて1台余ってるのでスピ社どうぞ

うちはMBP15inchすな

8:05 AM

ww

ここでリクルートするなｗ

MBP Touch bar だけど、外付けキーボードないと発狂するよ

hiraraiためしに俺のgistのコードそのまんまで12個にしてやってみると何秒か教えて欲しい

ok

俺は計測は time コマンドの real を張ってる。1回しかやってないし他の作業も止めてないからだいぶガバガバだけど。 (edited)

~ (๑˃̵ᴗ˂̵)ﻭ < time swiftc compile.swift -o compile swiftc compile.swift -o compile 15.78s user 0.30s system 99% cpu 16.137 total

8:07 AM

33秒と比べると半分くらいか

引数2個x要素6個のときの12秒って結果とほぼおなじってことか。

ぽい

8:12 AM

プロンプトが可愛いということに誰も触れてくれなくてかなしい

あ、それシェルに出てるのかｗ

いつ青い顔に変わるの？

exit 0以外のとき

ステータスか

8:14 AM

へ〜

Ctrl+Cしてもなる

Ctrl+Cはシグナル送るからだいたいそうなるね

そそ

8:15 AM

コレ自体はどっかzshの設定といっしょに拾ってきた受け売りなんだけどね

8:15 AM

かわいいからきにいってる

なるほど

8:15 AM

かわいいけど飽きそう

かなしい

可愛いシェルより可愛いコード

8:21 AM

はやくして、やくめでしょ

可愛いコードとは

IUOでコンパイルタイム4^nは良いおやつだった

おやつｗ

fileprivateネタ手厚く載ってました(　´･‿･｀) https://swiftweekly.github.io/issue-62/

Issue #62

This week swift-stdlib-tool was open-sourced, a number of proposals were accepted, Swift releases have themes, and a new proposal for fixing access controls in Swift is now under review!

TypeScriptの初期化をSwiftのように型安全にしようとして議論に参加している件だけど、そもそもTSからコンパイルした先のJS ES2016のクラス機能の仕様が厳しくて、厳しくなってきた厳しさ1. super()を呼び出した後でしか this が使えないためサブクラスのフィールドを埋める前に親クラスのコンストラクタが呼ばれる厳しさ2. サブクラスのコンストラクタ内部で呼ばれた親クラスのコンストラクタにおいてメソッドを呼び出すと、それがサブクラスでオーバーライドされている場合、サブクラスの実装が呼ばれるこれらの組み合わせによって、フィールドが未初期化のサブクラスのメソッドが呼ばれて、 undefined を踏む。下記はその問題によって、純粋なJSユーザーが困っている事例2件 http://stackoverflow.com/questions/32615034/call-parent-function-which-is-being-overridden-by-child-during-constructor-chain http://stackoverflow.com/questions/32449880/parent-constructor-call-overriden-functions-before-all-child-constructors-are-fi

Call parent function which is being overridden by child during c...

I've encounter a problem below with JavaScript(ES6) class A{ constructor(){ this.foo(); } foo(){ console.log("foo in A is called"); } } class B extends A{ constructor(){ sup...

Parent constructor call overriden functions before all child con...

ECMAScript 6 (Harmony) introduces classes with ability to inherit one from another. Suppose I have a game and some basic class to describe basic things for bot behavior. I simplify my real architec...

@mono 最後に乗ってるMatthewのコメントが不穏ですねｗファイルスコープになった private と、構文スコープになった scoped に再び分裂する、みたいな流れになったら草

ww

たしかに機能が悪いんじゃなくてキーワードの名前が悪いって気はする。

fileprivateと打つのは怠いですね

自然と手が伸びる方は private ですよねえ。

2:04 AM

お、 @ikesyo さんも来た (edited)

2

@here ここにKotlinのletメソッドについて知ってる人居ますか？Swiftに同じものを実装する事ができないんですけど、 @koher が演算子にしたらどう？って言っていて、わりと良さそうな気がしている。

2:45 AM

kotlinのletは・・・ https://github.com/JetBrains/kotlin/blob/1.1.0/libraries/stdlib/src/kotlin/util/Standard.kt#L62

/** * Calls the specified function [block] with `this` value as its argument and returns its result. */ @kotlin.internal.InlineOnly public inline fun <T, R> T.let(block: (T) -> R): R = block(this)

JetBrains/kotlin

kotlin - The Kotlin Programming Language

2:46 AM

Rubyのtapとおそらく等価 http://ref.xaio.jp/ruby/classes/object/tap

2:47 AM

仮にこれを => 演算子でSwiftに導入すると、次のような事ができる

2:51 AM

// こんな関数があったとして func hogehogeFunc(str: String, int: Int) -> String { return "" } // こんなStructがあったとして struct Cat { var name: String var age: Int } // こんな関数が合ったとして func createPrettyCat() -> Cat { return Cat(name: "mike", age: 2) } // 従来は・・・ func demo1() { let cat = createPrettyCat() let result = hogehogeFunc(str: cat.name, int: cat.age) print(result) } // こういうのがシュッと1行にできなくて萎える // 提案のもとでは・・・ func demo2() { print(createPrettyCat() => { hogehogeFunc(str: $0.name, int: $0.age) }) } // 左から右にシュ〜っとかける

https://github.com/koher/swiflet (edited)

koher/swiflet

Contribute to swiflet development by creating an account on GitHub.

2:53 AM

説明してる間に実装しちゃった。

2:53 AM

=> の方がいい？

@koher ホタルイカみたいな演算子 ->> よりダブルアローのほうが打ちやすくていい

任意の構造をモナドと見做してmapしたい感じですかね

モナドとは違うよ、 => 式の評価結果はクロージャの結果そのものだから、

ですよねこれつよい

モナドに包まれる必要はない。

2:55 AM

ただ指摘の通り使い勝手はモナドに近い。

確かに箱は存在してない

=> にするか。

Rubyのtapはレシーバ自身を返すので型変換はなく、等価じゃないですね

@ikesyo あ〜・・・そうですね

2:55 AM

あれ？ tapの末尾に評価値かけなかったっけ

hoge => { $0.piyo } => { $0.fuga }

@Biacco42 yes

2:55 AM

you can

すごーい！たーのしー！ (edited)

任意のテンポラリ値を変数に束縛できるので　左から右に書けない時に、だいたいそれができるようになります

2:56 AM

わざわざ let で変数におかなくちゃ〜〜　みたいな気持ちの時に効く

Rename した

2:58 AM

前から @omochimetaru との間で Kotlin の let が Swift にほしい話があって、でも Any に extension でメソッド生やせないから諦めてた。

2:58 AM

で、さっきまたほしくなって、よく考えたら演算子だったらいいんじゃない？って思った。

2:58 AM

関数だと順序が気に入らないけど、演算子だと let メソッドと同じ順序で書ける。

それで、そうやってすぐ演算子に逃げるの良くないよと思ったんだけど、でも、Swiftでは何にでもあるメソッドって作れないから、実際メソッドとは違う特別な存在なんだよな、と思って。 (edited)

3:00 AM

class Cat attr_accessor :name, :age def initialize @name = "mike" @age = 3 end end p Cat.new.tap {|x| x.age } # => #<Cat:0x007f1790eb9b60 @name="mike", @age=3>

Rubyのtapは確かに違った。。 (edited)

SwiftPM に対応してるので、↓だけで使えます。 dependencies: [ .Package(url: "https://github.com/koher/swiflet.git", majorVersion: 0) ] (edited)

1

Objective-Cの時にまさにtapを作っていたのを思い出した https://github.com/ikesyo/NSObject-Tap

ikesyo/NSObject-Tap

NSObject-Tap - tap: method for Objective-C borrowed from Ruby.

@ikesyo 本当だ〜

この間のT! -> T?変換が遅い件、何も別にIUOをswitchしなくても

9:34 AM

func fastUnwrap<T>(_ arg: T!) -> T? { return arg } (edited)

9:34 AM

これだけでいい気がしてきた

9:37 AM

いけたっぽい

それは暗黙の変換にはならないんですか

暗黙の変換が return arg として出現していますが

探すわけじゃないからいいのかな

こいつはfuncで1回しか評価されないため

10:44 AM

差し当たりO(4)かな?

10:44 AM

fastUnwrapの方は別段問題が発生しない。明示的だから。

ふむ

Swift3.1のGeneric Classのinner classって

2:09 AM

外側のGeneric Classの型パラメータによって

2:09 AM

static contextって分離されるの？

2:09 AM

つまり・・・

2:10 AM

class Outer<T> { static var staticVar: T class Inner { static var staticVar: T } }

2:10 AM

としたとき

2:10 AM

Outer<Int>.staticVar = 3 Outer<String>.staticVar = "abc" Outer<Int>.Inner.staticVar = 4 Outer<String>.Inner.staticVar = "xyz"

2:10 AM

こう？なんだっけ？

そもそもstatic なT作れたっけ

えーっと、そもそものstaticなTについては、Swift3.0でも問題になるテーマだから、どうだろう。

2:12 AM

Innerがあってもそれを一貫して引き継いだ仕様になるか。

そうだと思うよ

なんかアプデがエラーになっちゃってまだ試せていない・・・

iPadで試そう

Swift Playgroundsは3.1なんだよねｗ

なんかAppStoreアプリぶっ壊れてXcodeのアプデが終わらん

devから直接ダウンロードすればいいんでない？

staticなTは無理みたいですね error: static stored properties not supported in generic types static var staticVar: T

まあそうですよね (edited)

なるほど

2:56 AM

じゃあ CatInt, CatString は static contextが2つあるけど、 Cat<Int>, Cat<String> は1つしか無いんだな

static var x = 0を生やして書き換えたら共有されるのかな？

@tarunon

Tは暗黙的にT?だよ

古い話題ですが、これ、メソッドコールだと起こんないんですよね。 let a = 42 a.map { $0 } // error (edited)

そうですね、その場合はOptionalは決定しようがなさそう

このあたりは使い勝手を考えると絶妙なラインだけど、法則がわかりづらすぎてやっぱり暗黙の型変換は邪悪・・・

3:09 AM

昔 Kotlin の Any? に map を生やしてみたら、 List の map が正しく動かなくなって大変なことに。

ListがList?に変換されたのか

はい。

邪悪だ

それで初めて、 Swift の T? への暗黙の型変換は起こる場合と起こらない場合が使い分けられていることに気付きました。

swiftの場合は、他の要素によってOptionalが決定される場合にのみ暗黙的に変換されるので、辛うじて秩序を保てている(?)

3:11 AM

正確なルールがどうなってるのかはわからないです。単に . の左側では暗黙の型変換をしないだけかもですが。

.の左って暗黙変換すると非決定性が高すぎて実現不可能な気がするんですが

3:26 AM

他の言語で例があったりするのかな

3:26 AM

ObjCのidがある意味そうか。でもあれはobjc_msgSendだからswiftの話とは全然違う (edited)

C++とかどうなってるんでしょう？

3:27 AM

暗黙の型変換ができる言語自体が少ない気も？

vtableか何か、implを引ける仕組みがあれば、そこに乗せればいい気はしてるんですが

3:31 AM

そういうのが無い場合に出来るイメージが全く湧かない

3:31 AM

いや、左の型が非決定的だからvtableあっても意味ない

Java のオートボクシングでできそうな気がしたけどできなかった。 public class Main { public static void main(String[] args) { System.out.println(2.compareTo(3)); } }

$ javac Main.java Main.java:3: error: ')' expected System.out.println(2.compareTo(3)); ^ Main.java:3: error: not a statement System.out.println(2.compareTo(3)); ^ Main.java:3: error: ';' expected System.out.println(2.compareTo(3)); ^ 3 errors

ObjCも本質的に違う話題ですね、あれはOオブジェクトとselectorからimpl引いてるだけだ

↓なら OK 。 a を int に変えたらダメ。 public class Main { public static void main(String[] args) { Integer a = 2; System.out.println(a.compareTo(3)); } }

C++の暗黙の型変換は引数に渡す時だけな気がする

3:34 AM

ドットオペレータでメソッドを呼ぶ時は差し込まれない

単純にやっぱり、型を決定する材料足りないと思う

static var x = 0を生やして書き換えたら共有されるのかな？

そうそう。そこらへんが気になった。 (edited)

KotolinのAny?の話は聞いた感じ

3:35 AM

って感じ

まあ、基本的に nullable にメソッドは生えてないので、意図的に生やさなければ問題にはならないです。 (edited)

map flatMapないのか

let みたいな Any 由来のメソッドは使えるけど、それは暗黙の型変換なく使えるんで。

そうか、kotlinはT??とT?が等価でしたっけ

はい

なるほど

foo?.let { x -> bar(x) }

3:39 AM

↑が map かつ flatMap になります。

なるほどー

3:40 AM

まあ実用上75%くらいは問題ないですね

です。

?.let { } はアツいよね

↑に気づく前の Kotlin を使い始めたばかりの頃に map を生やしてみたら、という話なので、実用上は問題ないです。

Promiseの.thenみを感じる

Kotlin と言えば、この前 @omochimetaru と話してた Ceylon : Anything : Null = Kotlin : Any? : Nothing? の話を整理して Qiita に書きたい。 (edited)

3:44 AM

typealias Anything = Any? typealias Null = Nothing? とすれば Ceylon と同じになる。

3:45 AM

typealias Object = Any これもいるか。

3:46 AM

で、これと関連して、 Swift の Never が bottom type になるかもという話も興味深い。

3:48 AM

Joe Groff の言ってる↓がもし実現されるなら https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032267.html

IMO, if we accept a single error type per function, there could be a simpler model for this. We could say that the `throws` type is a generic parameter of all function types, and it defaults to the uninhabited `Never` type for functions that don't throw. () -> () == () throws Never -> () () throws -> () == () throws Error -> () In this model, you'd get many benefits: - `rethrows` could become first-class, reducing down to just polymorphic `throws`: func foo(_: () throws -> ()) rethrows // Swift 3 func foo<T: Error>(_: () throws T -> ()) throws T // Swift X

3:48 AM

Never が bottom type でないと辻褄が合わない。

ああ、そういう意味か

3:49 AM

いいですね、美しい

これはこれでキレイなんですけど、 rethorws がただのシュガーになっちゃって、 reasync との対応の解釈が難しいです・・・。 https://gist.github.com/koher/df007741788cb197d65b6babe2acf480

throws-vs-async-is-try-vs-await.md

asyncの話は出てないんですか？

ちゃんと watch できてないです・・・。

3:53 AM

でも Swift 4 のスコープじゃなさそうな気も？

3:54 AM

Generics と Memory Ownership と String でお腹いっぱいなんじゃないですかね。

それはそんな気がする

3:55 AM

asyncも後から足して破壊的変更になるか、というと

3:55 AM

stdlib周りが壊れるかー

壊れますか？追加だけなような気も。

ああ、追加すれば良いのか

3:56 AM

殺さなくて良いので確かに

↓の Chris Lattner のスライドの actor も Swift 5+ って書かれてるし、 4 ではない気がしてます。 http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf

3:58 AM

多分、 async レベルの変更は Core Team で良く練った上でマニフェストが出て、それベースで話し合いとかじゃないですかね？

https://github.com/apple/swift-package-manager/blob/master/Sources/PackageDescription/Package.swift#L36-L38

apple/swift-package-manager

swift-package-manager - The Package Manager for the Swift Programming Language

7:11 AM

 public class func Package(url: String, versions: ClosedRange<Version>) -> Dependency { return Package(url: url, versions: versions.lowerBound..<versions.upperBound.successor()) }

7:12 AM

a...b と a..<b の両方に対応しようとすると、 a...b => a ..< b.successor() の変換をオーバーロードの内側でやらないといかんのか。

あーーー

7:22 AM

Swift3.1でコンパイルできなくなった

w

http://qiita.com/tarunon/items/343ec5fcc059a144f2d1#追記20160324

SwiftのassociatedtypeをSelfに束縛する - Qiita

Swift2.2になって、Protocol周りのバグが幾つか修正されて、ProtocolとClassを組み合わせて使うシチュエーションが現実的になってきました。ということで、Swift2.2から可能になったテクニックを備忘録も兼ねて...

7:25 AM

これ、extensionの束縛部分を他のライブラリに逃してたら今まで通ってたけど

7:25 AM

ついに殺されたっぽい

7:26 AM

エラーの出方もAmbiguous type nameじゃなくてセグフォだしとても嫌な感じだ…

たるのんのこれ、いまいちシナリオがわからなかったけど

7:28 AM

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#recursive-protocol-constraints-

https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md

swift - The Swift Programming Language

7:28 AM

ここでいう recursive protocol constraints に該当するパターンかね

それそれー

protocol Sequence { associatedtype Iterator : IteratorProtocol ... associatedtype SubSequence : Sequence // currently ill-formed, but should be possible }

シーケンスのサブシーケンスはシーケンス、としたいけど現状はできない、とかがあるらしい

今まではWorkaround作って無理やり押し通ってた

7:29 AM

しんでしまった

7:29 AM

どうしようかな~

あ〜

7:30 AM

protocol Eq { static func (a: Self, b: Self) -> Bool } ↑これはできるけど protocol EqX { associatedtype X static func (a: X, b: X) -> Bool } struct Hoge : EqX { typealias X = Hoge } これはできない？ (edited)

nn

7:31 AM

↑は↓の糖衣では

2つめのはできて、

protocol EqX { associatedtype X static func (a: X, b: X) -> Bool } protocol EqSelf { typealias X = Self } struct Hoge : EqSelf { }

これが駄目なのかな？

Equatableは暗黙的にassociatedだぞ

7:32 AM

えっとですね

記事で本題ってなってるケースは↑のEqXも駄目になりそう。

7:32 AM

protocol EqX { associatedtype X static func (a: X, b: X) -> Bool } struct Hoge : EqX { typealias X = Self } HogeじゃなくてSelfか (edited)

protocol A { associatedtype B } class C: A { typealias B=Self } ↑できない

だよね

サブクラスのBはサブクラス自身であってほしいが、それが出来ない

7:33 AM

しかし、Workaround積み上げまくってそれを実現してた

7:33 AM

バベルの塔はついに崩壊した

Cを継承したDがいるときに

7:34 AM

Cの中でSelfって書いておくとDにおいてそれがDになるやつよね

そうそう

そもそもSelfって書けるの最近しったワｗ

7:34 AM

しかも self 式の型が Self だし。

7:35 AM

https://gist.github.com/tarunon/f211f246d126d6ffdbdb931a2b95e084

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

7:35 AM

RecursiveProtocolConstraintsはAcceptedになってるし

4までおあずけかな

待ってれば綺麗な解決が来そう

@tarunon これだとまた意味変わってきます？

protocol HasB { associatedtype B } protocol A: HasB { } class AnyAs: HasB { typealias B = AnyAs.Type } class AnyA<T>: AnyAs where T: A { typealias B = T.B } class C: A { typealias B = C } AnyA<C>.B.self

class D: C {}と書いたらどうなりますか?

10:05 AM

昔は、AnyAとか用意しなくても、常にA.B==Selfな型が作れたんですが、今は死んでしまったので。

確かに継承してしまうと追いかけてくれないですね...うーむ

なんかObjCと絡ませて型をしっちゃかめっちゃかするとコンパイル通らなくなるなー最小ケース探さないと

Swiftに慣れてくるとRubyのコードがこんなんばっかになる xs.map {|x| y = f(x) y ? [y] : [] }.flatten(1)

みつけた

5:05 AM

Cannot compile code on Swift 3.1

5:05 AM

セグフォです

いけそうだけどダメなんですね

fugaのみだと通るのか...

Xが具体型なら通ります、この場合はStringに変更すればOK

なるほど

Swift3.1 ErrorからNSErrorへの暗黙の型変換追加されてるくさい

7:23 AM

邪悪すぎる

それ前からあったと思う

いや

全てのError は is NSError だった

error.method

7:23 AM

これでerrorがNSErrorになる

w

あーそゆこと？まじ？

多分

7:24 AM

もうちょっと掘るけど、かなり辛い感じ

7:29 AM

理解完了

7:29 AM

こういうコードを書いた時に、前までだと

7:29 AM

キャストが先だったが3.1からNSErrorへのキャストが先に挿入されてから変換される

NSErrorが優先されるのか

7:30 AM

あ、順番の話か

MyCustomErrorのhogeとNSErrorのhogeの値を変えて欲しい

変えてる

1と-1

あ、見間違えた

7:30 AM

ほんとだ・・・

let error: Error

error as NSError

(error as NSError) as? MyCustomErrorProtocol ということ？ (edited)

そう

7:32 AM

強制的にNSErrorになってる

21行目を let error: MyCustomError = MyCustomError() にしたらどうなるの？

7:32 AM

それは1か

そう

7:32 AM

でもthrowがErrorだから型明記するの全く意味ない

おー

7:33 AM

extension NSError: MyCustomErrorProtocol これ消せばちゃんと動くんよね

それはそう

へー

7:35 AM

参考までにこの変更で何が困ってるのか聞いてもいいですか

Errorを受け取ってダイアログ出してるけど

7:36 AM

3.1にしたら全てが破壊されて???ってなった

7:36 AM

ダイアログはProtocolに基づいてラベル付をしている。

カテゴリ分けみたいな意図でprotocolを使っていてってことかな

error.method これでerrorがNSErrorになる

タイムリーに昨日話してた . の左の暗黙の型変換ですかｗ

ほぼ

8:01 AM

それですね

8:01 AM

激怒ですよ

8:03 AM

なんか

8:03 AM

そのくせNSErrorの引数にError渡したらコンパイルエラー吐きやがったぞ…

8:03 AM

ふざけやがって…

そっちは暗黙の型変換ないんですね。カオスｗ

迂闊にNSErrorにprotocol準拠させて共通化するの危険になりましたね... 修正するならNSError用のcontainerで包むとか別で対応入れる形になるんでしょうか

コンテナ作ってError型入れて

8:52 AM

Protocolでキャストして片方取り出しつつ、NSErrorの処理はそこに書く

8:53 AM

みたいなことしなきゃいけないです。あーめんどくせーーー

やっぱりそうなりますよね。。NSErrorの存在感ｗ

protocolでキャストする必要が出てくるのでAssociatedなProtocolは死体ですねこれ

9:26 AM

無念

全然関係ない話ですが、

9:35 AM

Swift PM の新しい pinning について、

Since package pin information is not inherited across dependencies, our recommendation is that packages which are primarily intended to be consumed by other developers either disable automatic pinning or put the Package.pins file into .gitignore, so that users are not confused why they get different versions of dependencies that are those being used by the library authors while they develop.

https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md とあるんですが、これについて話していて pins ファイルは ignore しない方がいいんじゃないかという話になったんですがどう思いますか？アプリでは環境をそろえるために pins ファイルを共有した方がいいのは当然として、ライブラリ利用時には、依存している側からはライブラリ内部の pins ファイルは無視されるようなので、 "so that users are not confused why they get different versions of dependencies that are those being used by the library authors while they develop." という理由だけであればライブラリ開発者間で環境をそろえるために（ atuo pinning も有効にして） pins ファイルも push した方がいいんじゃないかなぁという話です。

https://gist.github.com/tarunon/922dc1e58261484ea44962f209db4c22

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

ライブラリ開発中は依存先のバージョンが

9:38 AM

微妙に変わったりした時に

9:38 AM

壊れる事を検出したいから

9:38 AM

固定しないほうがたまに壊れてくれて嬉しい気がする

9:38 AM

もし、特定のあるバージョンでしか、動かないライブラリなら

9:39 AM

pinじゃなくて、そもそものPakcage.Swiftのほうで、ピンポイント依存していをしないと

それは明示的に repin して確認すればいい話なのでは？

いけないのではないか

9:39 AM

めんどくさくてやらなそう＞明示的に

9:39 AM

とりあえず固定しないでおけば、いろんな人が作業するタイミングのズレで自然とバラける

アプリにせよライブラリにせよ、それぞれが微妙にブレたバージョンで開発していたりすると微妙なバージョンのブレの組み合わせが原因で問題が起こったりして現象を再現できないから

9:41 AM

開発者間でバージョンをそろえて作業できるようにしたいというニーズがそもそもあって pinning が導入されたと思っていて

9:41 AM

色んなバージョンで動くかどうかの検証はそれとは別の話じゃないかな。 pinning してなくても網羅的にチェックできるわけじゃないし。

cocoapods使っててPodfile.lockをignoreするかしないか論争のSwift PM版って話ですよねチームで開発してるときなんかはそれぞれで環境が変わると問題が起きたときに切り分けに困るのでpinsは共有した方が良い派です (edited)

@moaible ですよねぇ・・・。

9:44 AM

ignore するか auto pinning を disable することが推奨って書いてあるんですけど、それによって得られるメリットが "users are not confused why they get different versions of dependencies that are those being used by the library authors while they develop" なのは納得がいかないんですよね・・・。

9:45 AM

@omochimetaru

めんどくさくてやらなそう

デフォルトが auto pinning になるから、もし pins ファイルを commit しないなら、少なくとも auto pinning を disable するか、 pins ファイルを ignore するかしないといけないんです。

--type libraryで初期化してもauto piningがデフォルトでoffになってない？

9:46 AM

それはよくわからないな。

9:47 AM

一貫性が無い

The package manager will have automatic pinning enabled by default (this is equivalent to swift package pin --enable-autopin), although package project owners can choose to disable this if they wish to have more fine grained control over their pinning behavior.

(edited)

ウーム

アプリ作る人はpinsを含めたほうがいいけど、ライブラリ作る人はpinsはignoreしたほうがいいってことじゃないんですかね。

@rb-de0 そういう内容なんですが、それが微妙じゃないかなぁという話ですね。

9:59 AM

pins ファイルを commit することのデメリットが「まぎらわしいから」くらいなら、 commit するメリットが勝る気が。

10:00 AM

それに、ライブラリ開発環境の pins が含まれていれば、それを再現すれば最低限そのときと同じ環境でライブラリを動かすことができるわけで、利用者視点でも、トラブル発生時のドキュメントとしても価値があると思うんですよね。

Swift2 -> 3のタイミングでのSwift PMは大分辛かった記憶があるのでpinsあるとその辺緩和されると嬉しいお気持ちはありますね

1

10:03 AM

どこで依存壊れてんのか追うのがしんどかったです

あんま詳しくないですが、ここに書いてあることと同じ意味なんじゃないですかね。http://sanemat.github.io/archives/langturn.com-translations-33/

同じっぽい。rubyやnodejsの開発者のほうが

10:05 AM

ライブラリ小分けにしまくって依存が100個とかぶら下がるみたいな

10:05 AM

開発になれていて

10:05 AM

知見がありそう

利用者側からすると依存関係のバージョンがズレていると使えないことになってしまって不便です。

Ruby 詳しくないですが、↑これって利用者側がライブラリ中の lock ファイルの影響を受けるってことですよね？

10:10 AM

Swift PM ではそれは起こらないのでは？

The pins file will also not influence dependency resolution for dependent packages; for example if application A depends on library B which in turn depends on library C, then package resolution for application A will use the manifest of library B to learn of the dependency on library C, but ignore any Package.pins file belonging to library B when deciding which version of library C to use.

Gemって依存先のLockも見ちゃうのかな？その文章はどっちでも取れると思いますが

10:13 AM

Gemコマンドで扱われないような精密さを要求してしまうからです。

技術的にって意味じゃなくて、固定して開発するからコードがそうなっちゃうって意味かと思った。

NewOptionalAssociatedType.swift

2:49 PM

associatedtypeにデフォルト型置けるようになってる

話し合われてるのは知ってたけど3.1からだったか

この間のwhere Voidの変態workaroundは用済みとなった

あれ謎だった

LazyCollectionProtocolとか、その辺見て気が付いた

2:52 PM

あれ？associatedtypeでSelf??マジ？って

ふむふむ

associcatedtypeのやつって2.xの時からできてたと思ったけど、何か違うものです？ https://github.com/ikesyo/Himotoki/blob/1.7.0/Sources/Decodable.swift

ikesyo/Himotoki

Himotoki - A type-safe JSON decoding library purely written in Swift

これforceじゃないですかね

2:57 PM

上書き不可能な気がする

2:57 PM

associatedtypeのそれは、他の型で上書きできます

2:58 PM

無宣言の時だけ=の向こう側になる

これと同じに見える http://stackoverflow.com/a/36810484

Swift Protocols with Associated Type Requirement and Default Imp...

I have been struggling very hard with Swift Protocols and Associated Types for a long time. I started again with basic to really understand what is going wrong and I followed this article of TypeEr...

3:02 PM

手元で今シュっと試せないのでハッキリとは分からないですが(>_<)

iswift.orgで試したら3.0.2の時点で出来てたみたいですね

3:04 PM

2.2はSelfが消せなくてコンパイルエラー

なるほど3.0でか

3:04 PM

ありがとうございます

3:07 PM

Gemfile/.lockはPodfile/.lockと同じで、それに依存する側からは関係ないはずという認識です。そのライブラリの利用者に影響を与えるのはgemspec, podspecでは？

であれば、条件設定はspmとgemで同じですね

3:11 PM

条件設定と、慣習が同じで、ライブラリ開発時はロックをコミットするな、で

3:11 PM

でもライブラリ開発同士でも環境が同期したほうが良いのでは？という話

CarthageでもCartfile.resolvedはライブラリ利用者には影響を与えない

3:12 PM

Carthageではドキュメントでreslovedはコミットをすすめてるかな (edited)

ほー！

あ、ですよね

開発者間で同期すべきものという認識で、僕もその立場です

そんな気はしてた

so that users are not confused why they get different versions of dependencies that are those being used by the library authors while they develop.

3:16 PM

実際これはよくわからないよなあ

ロックするのはまさにこういうことかなぁ

それに、ライブラリ開発環境の pins が含まれていれば、それを再現すれば最低限そのときと同じ環境でライブラリを動かすことができるわけで、利用者視点でも、トラブル発生時のドキュメントとしても価値があると思うんですよね。

ライブラリ作者と違う依存先バージョンを取得していまう理由にユーザーが混乱しないから、と、言われても、依存の依存はLockを見ない、で説明終わるからなあ

3:19 PM

あ～

3:19 PM

CIをまわしている場合に

3:20 PM

CI botもpinしたバージョンでライブラリをビルドするけど

3:20 PM

pinよりも先のリビジョンアップデートがリリースされている場合に

3:20 PM

ライブラリ作者が明示的にupdateしてpinを更新しないと

3:20 PM

それが検査されない、みたいな違いはある？

3:20 PM

ライブラリのロックがコミットされていなければ、

3:21 PM

pushされるたびに依存先のバージョンの指定の範囲で最新のものが使われるから

3:21 PM

健全性は保ちやすい？

3:25 PM

@tarunon どこかで見たつもりだったけどこれしか見つからなかった　rejectされた別の提案の一部として出てきてる　https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0108-remove-assoctype-inference.md#default-type-for-associated-type

https://github.com/ikesyo/Himotoki/blob/1.7.0/Sources/Decodable.swift#L10

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

3:26 PM

うーんどこから入ったんだろう

IBMのサンドボックスでは3.0.0時点から可能だった

3:27 PM

見落としてたのかーという気持ち

2からいけた可能性は？

2.2はしんだ

なるほど・・・俺も釈然としない・・・

コンパイラはAbortかなこれは

3:29 PM

ああ、まってね

3:30 PM

2.2にprotocol extensionって無かったよね

3:31 PM

いけたいけた

3:31 PM

2.2でも同様の型の作り方書いて上書きできた

えーじゃあ全然前からできたってこと？

ぽい

あれ～～～

2.2だとprotocol extension無いからやるメリットはほぼない

3:32 PM

3.0からメリットの塊だけど、見逃し続けてた。今の今まで

ikesyo/Himotoki

Himotoki - A type-safe JSON decoding library purely written in Swift

3:32 PM

himotokiのこれも上書き可能ってことかね

できちゃいますね

oh・・・

でもHimotokiはそこら中でwhere Decodable==Selfって書いてた気がする

typealiasっていうキーワードの印象で上書きできないって思い込んでただけかな

3.0からなんで出来ないと思い込んでたのかが謎

3:34 PM

HimotokiのDecodable==Selfはサブクラスをやっつけてるのかと勝手に解釈してた

あいや、それはそうなはずで

3:36 PM

http://qiita.com/omochimetaru/items/621f1ef62b9798ee5ff5#swift%E5%AE%9F%E8%A3%85%E3%81%AE%E4%BF%AE%E6%AD%A3

Swiftの強力な機能であるstaticメソッド制約の紹介と、Kotlin, TypeScript, Java, Scala, ...

# 先に結論 - Swiftのstaticメソッド制約はちょっとしたシンプルな機能に見えるけど便利で深い - Kotlin, TypeScript, Java で同じことをすると冗長で間接的なコードになってしまう - TypeScr...

3:36 PM

ちょうどこの記事書いたときにも確認してる

うん、やっつけれるのは確かなんだけど

3:37 PM

それは兎も角Decoded=Intとか勝手にかけるそれらもやっつけ対象だったのは、完全に盲点だった

ロックの件、CIも確かに話題としてありそう。CI上で勝手に新しいの使われてぶっ壊れるのも嫌な気もして、好みによりそう (edited)

3:38 PM

あとはブランチ指定かなー

3:39 PM

複数ライブラリを並行に開発してて、開発中のブランチを使いたい時に、ロックがないと用意に壊れる気がする

@ikesyo アプリAから見てライブラリBの依存先Cに勝手に新しいのを使われる事自体はそもそも防止できないのでは

3:40 PM

アプリユーザーはBのpinを無視する仕様だから、Bの開発者はCのリビジョンアップデートはそもそも対応を拒否できない

3:41 PM

(根本的に依存先定義をピンポイント指定すれば別だけど)

@omochimetaru それはそうですね。そうなってから何か報告があれば直すというスタンスか、ライブラリ側でそういう状況を常に把握できるようにあえてロックしないか、というスタンスの違い

ああ、なるほどです。 (edited)

まあその辺はsemverの世界観ではそうそう壊れないという期待はあると思う。compatibleなバージョン範囲を指定してる上では。

たまにRails触るとだいたいlibv8となんちゃらモンキーが問題起こしてたから、semverの世界に全く信用がおけない・・・

依存先が勝手にアップデートされないためには完全バージョン固定するしかないけど、それはそれで依存の依存に新しいバージョン出てるのにそれが使えなくて困ると上位の利用者から文句言われることになりそう。なので~>とかになる (edited)

npmとかも一瞬で200個とかライブラリぶっこまれて、こんなん動くわけないやろって気持ちによくなる。でもnodejsはブラウザ向けとかはわりと動くんだよな。

3:46 PM

そうですね

jsのライブラリ粒度はすごい世界だ……

ですよねｗｗ

3:49 PM

ワンファイルどころか10行ぐらいの関数単位のパッケージがザラにある

3:50 PM

browser swiftとか始まったらブラウザ差分吸収の需要からそういう世界になってしまうんだろうか

依存先が勝手にアップデートされないためには完全バージョン固定するしかない

これだと、複数のライブラリが同じ別のライブラリの（互換性のある）バージョン違いに固定されちゃってたら、本来解決できるはずなのに解決できなくなっちゃいますよね？

それはそれで依存の依存に新しいバージョン出てるのにそれが使えなくて困ると上位の利用者から文句言われることになりそう。なので~>とかになる

2:25 AM

そういう事ですね

ああ、「使えなくて困る」というのは、単に新しいのにしたいけどできないから古いの我慢するというだけじゃなく、そもそも不整合が起こって解決不能になるという意味も含んでいるのか。

2:28 AM

ワンファイルどころか10行ぐらいの関数単位のパッケージがザラにある

これ自体は別にいいと思う。むしろ粒度小さくした方がいい派。

2:32 AM

ライブラリのロックがコミットされていなければ、 pushされるたびに依存先のバージョンの指定の範囲で最新のものが使われるから健全性は保ちやすい？

この目的だと、pinsファイルをignoreするよりも、開発者側がauto pinningをdisableして何もpinしないのが良さそう。ignoreしてる時点で開発者間で環境そろえられないからpinningの意味ない気がするし。

そもそも共有しないpinって意味あるんですか？

2:52 AM

pinが無いと自分の手元もどんどん新しくなるのかな

Use Cases

Our proposal is designed to satisfy several different use cases for such a behavior:

1. Standardizing team workflows

When collaborating on a package, it can be valuable for team members (and continuous integration) to all know they are using the same exact version of dependencies, to avoid "works for me" situations.

This can be particularly important for certain kinds of open source projects which are actively being cloned by new users, and which want to have some measure of control around exactly which available version of a dependency is selected.

2. Difficult to test packages or dependencies

Complex packages which have dependencies which may be hard to test, or hard to analyze when they break, may choose to maintain careful control over what versions of their upstream dependencies they recommend -- even if conceptually they regularly update those recommendations following the true semantic version specification of the dependency.

3. Dependency locking w.r.t. deployment

When stabilizing a release for deployment, or building a version of a package for deployment, it is important to be able to lock down the exact versions of dependencies in use, so that the resulting product can be exactly recreated later if necessary.

3:23 AM

うーん、 commit しなくてもうれしいケースがあるとすると 2 かな？

3:25 AM

いずれにせよ auto pinning では 2 は実現できないから、 auto pinning が enabled な状態のまま、 pins ファイルを ignore するシナリオがよくわかんないな。

なるほど

やっと再現できた

11:37 AM

https://gist.github.com/tarunon/b653d9326f1196e126e6edfcf60f7284

Swift3.1 crashes caused 3 file.

11:41 AM

まだ小さく出来たので小さくした。今のが最小かな

a

a.zip

4.67 KB

1:58 PM

ビルド、実行できたよ

1:58 PM

$ cd a $ swift build $ .build/debug/a

む

main.swift let a = F<O>() print(a.f())

同じファイルだと動く

別のファイルだよ

1:59 PM

tarunonのgistをzipでおとしてから

マジか

swift package initしたから

1:59 PM

全くおなじはず

ふーむ

2:02 PM

出来るな

Swiftのライブラリの名前って

2:02 PM

Swiftに洒落を効かせたほうがいいんですかね

2:02 PM

たくさんライブラリを使うようになったら

2:02 PM

そういうのいちいちあるとややこしい気がするんだけど

2:03 PM

あーでも同じことをするライブラリが2つあったら微妙なのかな

2:04 PM

でもResultとかあるしな

同じコードの二つのプロジェクトがあって

2:29 PM

片方は通って片方はセグフォになった

ええｗ

2:29 PM

ビルドキャッシュの影響じゃない？クリーンしたら同じになるよ

いや、

import GlibC したとき何が使えるのかさっぱりわからん (edited)

消しても再現するし、DerivedData消しても同じ

ふむ

2:32 PM

UbuntuならGlibc.swiftmoduleとかあると思うんだけど、あったとして、中身見る方法もわからんな・・・

タイミングとしては、extensionに書いたfの解析中にセグフォで死ぬ

2:33 PM

今死んでる方はバグの再現できるプロジェクトから最小単位まで削ったコードで、会社のpcに最初からプロジェクト作って再現したのがあるから、

2:34 PM

明日そのプロジェクトをzipに詰めてアップロードしとこう

2:34 PM

githubに上げるのがはやいか

@ikesyo さんとか、HimotokiのLinux対応やったとき、Glibcの中身ってどうやって確認したんでしょうか

1:45 AM

サーバーサイドLinuxでGlibc叩いてる人は居ませんか〜〜

HimotokiはstdlibとFoundationだけで済んでいてGlibcは使ってなかったと思います

あ〜　じゃあLinux固有のヘッダーを読む必要は無かったんですね

2:37 AM

Mac上でFoundationを外すだけで作業できた

FoundationはLinux版でもcorelibs-foundation使ってるので外してはないですけど、Glibcを使う必要はなかったですね (edited)

corelibs-foundationってFoundationのLinux対応版の事ですか？

https://github.com/apple/swift-corelibs-foundation/ Swift実装のFoundation（≒Linux版）

SwiftはどのようにJavaの検査例外を改善したか - Qiita

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

2:44 AM

macOSでもSwiftFoundationとして独立して動きます（なのでmacOSで開発、テストもできる）

なるほど

2:44 AM

なるほど〜

deferの中でthrowできないのか・・・

returnより後ろだから無理じゃないの

 var fileActions: posix_spawn_file_actions_t? try PosixError.run { posix_spawn_file_actions_init(&fileActions) } defer { try PosixError.run { posix_spawn_file_actions_destroy(&fileActions) } }

3:16 AM

これとかすごい素直なコードだと思うんだけど通らなくて悲しい

いやVoid値返ってからエラー発生はおかしいでしょ

3:17 AM

それやったらtryがEitherと等価じゃなくなる

返ってからじゃなくてreturnの直前に差し込まれるんじゃないのかね

3:17 AM

コンパイル結果的には。

返り値確定してから差し込まれてるから、deferの中にthrowは直感に反するというか

いや、てか、defer自体が open - defer { close } ってパターンが基本だと思うんだけど

混乱生みそう

このcloseが失敗した時が無理じゃない？

3:19 AM

それができないなら、javaの try - catch -finally のfinallyの代替にはならないね自分でwith resources文作らないといけないか

foo() defer { bar() } return baz() は foo() let r = baz() bar() return r と等価だと思ってた。

そうそう、そういう話しです

それはそうなんですが

foo() return baz() bar() こう考えると、throwできないわけだ

そう、それはthrowは出来ない

deferがいったいどこまで遅延するのか return前だと思っていたけど、後だと考えたほうが

3:22 AM

仕様とは合致して解釈できるね

直感的に理解しやすいとは思う

微妙な仕様だな・・・

defer で try できないのは↓書いてるときに遭遇して、できてもいいのになぁと思った。 http://qiita.com/koher/items/e4c1d88981291c35d571

Swift には Java の検査例外によく似た仕組みがあります。 swift func foo() throws -> String { ... } // Java のような `throws` 節 ```swift...

with文作るのはいいけど、それだとネストが深くなっちゃうんだよな

3:23 AM

モナドにすればいいのか？

iPhone版Playgroundめっちゃ欲しい

3:24 AM

こういうのスッと試したい

今mac無いの？

でんしゃ

deinitもthrowできないし、Swiftのdeinitやdeferは全然RAIIパターンに使えねえんだなあ

3:25 AM

あ〜でもopenできたならcloseできない事はありえないし try! で辻褄あうのか

3:25 AM

一周回ってやっぱり何も問題無い気がしてきた

iPhoneだと↓かなぁ。 https://swift.sandbox.bluemix.net/

IBM Swift Sandbox

An interactive website that lets you write, execute, and share Swift code in a server environment – on top of Linux!

↑このサイト叩くだけのwebviewアプリがあるといいのか

ふむ

一応スマホ対応されてるんだな

3:27 AM

アプリ化しなくてもこれブックマークしておけば良い気もしてきた。

うん。実行するとアニメーションして結果画面にスライドする。

一応SPAサイト化されてるなこれ

3:27 AM

えらい

3:28 AM

なんかいろいろおすとすりあがって来たりしてそれっぽい

あ〜でもopenできたならcloseできない事はありえないし try! で辻褄あうのか

これよくわかんないんだけど、 close できないことがありえないならそもそも throws である必要ないんじゃ？

APIの設計に依存しそう

3:30 AM

賢い作りならcloseできる時だけオブジェクトが存在してる

3:30 AM

メモリオーナーシップの機能は必要っぽい

@koher PosixError.runがそもそも

 public static func run(proc: () -> Int32) throws { let code = proc() guard code == 0 else { throw PosixError(code: code) } }

こういうユーティリティだから try! PosixError.run { posix_spawn_file_actions_destroy(&fileActions) } try! になる

3:32 AM

もしそれをつかわないなら (edited)

3:32 AM

let ret = posix_spawn_file_actions_destroy(&fileActions) fatalError(ret == 0, PsoxiError(code: ret).description) (edited)

3:33 AM

っていうコードになるんだけど、これだと、 ret がスコープ汚染しちゃって、同じような処理を他にも書く必要があるから、これは採用できない。

お、この前話してた >= の出番だ。

いや、えーっと、

3:34 AM

retの再定義が解決したとしても

3:34 AM

まだ冗長で

そういや、 >= は rethorws にしないといけない気がしてきた。

fatalError(ret == 0, PsoxiError(code: ret).description) 0判定、PosixErrorで包む、descriptionを呼び出す、などが冗長

3:35 AM

try! PosixError.run { posix_spawn_file_actions_destroy(&fileActions) } これならそのいずれもなくなっていて、同じことをする上で無駄が無い

>=はrethrowsじゃないとダメですね

ですよね。

はやく

3:38 AM

そういえばRxSwiftのどっかにrethrowsにして統合できる関数があったな

3:44 AM

昨日の、クラッシュするプロジェクトをGithubにおいたので

3:44 AM

https://github.com/tarunon/Xcode3_1Crashes

tarunon/Xcode3_1Crashes

Contribute to Xcode3_1Crashes development by creating an account on GitHub.

3:44 AM

お手すきの方コンパイルできるか試して頂けると

@ukitaka が謎を解いてくれた

3:56 AM

コンパイラに渡すファイルの順番でコンパイルの可否が決まる

えーｗ

プロジェクトに寄って結果が違うのもそれ

w

なにそれｗ

3:58 AM

SPMだとソース回収だから一貫するけどXcodeだと追加順があるからか・・・

プロジェクトタブの、CompileSourcesで順番弄ると

3:59 AM

コンパイル通ったり通らなかったりする

3:59 AM

笑う

Foundation無しだとString.componentsすら無いのか・・・

String.componentsが内部的にNSStringに依存してる?

そこはわからんけど

extension NSString { open func components(separatedBy separator: String) -> [String] @available(iOS 2.0, *) open func components(separatedBy separator: CharacterSet) -> [String] }

10:58 AM

これしか見つからん

ってことはそもそも暗黙のアップキャスト？

じゃねーかなー

アップですらないな

アップキャストではない気がする

10:59 AM

initしてますね

暗黙のキャスト！

ちょっと悪い事してみるか

10:59 AM

NSStringもSwiftStringも

11:00 AM

実行時はCFStringだからinstrumentsじゃ見分けつかねーんだわ

へ～

昔は_NSﾅﾝﾁｬﾗStringが沢山居た気がするんだけど

11:01 AM

SwiftでNSString書いても最初からCFStringっぽい

いたいたｗ

11:02 AM

_NSCFConfiguousString とかそんなん

そうそれ

11:02 AM

あー

11:02 AM

じゃあObjC経由でswizzlingしてもだめか

11:02 AM

そもそも奴らはコンクリートクラスだからSwizzlingできねえ (edited)

11:02 AM

じゃあcomponentsかな?

11:08 AM

詠唱完了

11:08 AM

確定ですね

11:08 AM

componentsはNSString由来、その上暗黙キャストが走ってる

11:08 AM

.の!!左側で!!!

お〜〜なるほど

11:09 AM

method_exchangeImplementationsうけるな

1年以上ぶりぐらいに詠唱したけど指が覚えてた

ｗｗ

一番知りたいのは

11:10 AM

NSStringがinitされてるか…なんだけど

11:10 AM

うーんどうやって調べれるかな

initも同じように差し替えられないの？

11:12 AM

あ、initなんたらがたくさんあると捕まえられない可能性があるのか

コンクリートクラスだから実体は違って、initは差し替えられなかった記憶がある

11:12 AM

俺の勘違いでなければ

11:14 AM

暗黙キャストというか

11:14 AM

違うな…なんだ…

11:15 AM

@omochimetaru 会社出ちゃった、NSStringにextension生やしてStringから呼べる？

TのコンストラクタでUを受けるものは総じて本来的な型キャストで良いと思う

11:18 AM

import Foundation extension NSString { func piyo() -> Int { return 33 } } let a: String = "abc" a.piyo()

11:18 AM

@tarunon いけるね。

実行時は同一のCFStringつまり

あ〜、内部の実体が同じ場合はinitが呼ばれてない事もありえるね

そそ

11:19 AM

てことはー

11:20 AM

Foundationをimportすると、StringがNSStringとして扱われる魔術がかかる

11:20 AM

structですらない

11:20 AM

ってところかな、キャストとは違う

11:21 AM

置き換わってるのはオブジェクトではなく、型自体だ

11:22 AM

いや、CFStringだからstructか

11:22 AM

むむ、わからんくなってきた

11:22 AM

Foundationに何か魔法が書いてそうだな

確かどこかで見たことあるんですが、Objective-Cと互換性を持たせるようにimport Foundationで変更がかかるらしいです

Stringはstructだからそれが可能ですね

11:24 AM

だがErrorはprotocolだから無理だな

Foundationのクラスを優遇して推論してるような雰囲気ありますよね

あーこれかなー

11:27 AM

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSString.swift

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

11:27 AM

下の方に魔術用の型が存在する

この辺ですかね https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSString.swift#L1465-L1532

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

これを見るに実行時に型変換は走ってるはず

11:28 AM

ですです

11:28 AM

一番下にも居ますね

11:29 AM

この辺が揃っていればコンパイラ君が実行時に暗黙的な変換を許してくれる…

_SwiftBridgeable が気になる感

2.xまでは内緒プロトコルも、取り敢えず名前を当てればコード見つけられたし、動く型を作れたんですが今はどうかな

自分で書いたらStringから暗黙変換される型自作できんのか？ｗ

やってみて！

11:32 AM

いや、Stringからの暗黙変換は

11:33 AM

_NSBridgableと_CFBridgableだから

11:33 AM

Stringから、は無理かな

11:33 AM

Stringへ、はいけそう

_SwiftBrideableとかが見えないっぽい

見えなくても実装できる

11:34 AM

気合で！

https://github.com/apple/swift-corelibs-foundation/blob/4d0880fdbfa027b635576ced5c9d2e22827bb7aa/Foundation/Bridging.swift#L60 これ系internalやね

https://github.com/tarunon/AnyObjectConvertible

swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence

3.0の時は気合で実装できたけど

11:34 AM

今はもう防がれた？

気合とは・・・

型名わかってれば、取り敢えず書くと

11:35 AM

2.xなら全てのメソッドが足りないよと怒られて出てきた

11:35 AM

3.0はどうやったんだったかな

11:36 AM

tarunon/AnyObjectConvertible

AnyObjectConvertible - Convert your own struct/enum to AnyObject easily.

11:37 AM

こういうのが出来た。今はもうこいつは要らない

それって

11:37 AM

public protocol AnyObjectConvertible: _ObjectiveCBridgeable {}

11:38 AM

この_ObjectiveCBridgeableがFoundationをimportすると見えるからできたのでは？

うーん、コード補完は効かないし、参照も出来なかった気がするんだけど

11:39 AM

ああ、2.xはprivate/internalが不完全で

11:39 AM

名前を当てれば動いてしまったからかな

ｗｗ

NSErrorは特にそれっぽいコードなさそうですね...

いや、あったはず

11:43 AM

_BridgedStoredNSError

11:43 AM

この辺

この辺を見るとよさそう https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift

https://github.com/apple/swift/blob/master/stdlib/public/core/ErrorType.swift

swift - The Swift Programming Language

core側もおもろい

11:50 AM

https://developer.apple.com/reference/swift/collection

swift - The Swift Programming Language

昨日のNSErrorの件が気になりすぎてて、色々のぞいて見ます

// // util.swift // RuString // // Created by omochimetaru on 2017/03/31. // // internal func findSubArray<C: Collection, I>( array: C, index: I, target: C ) -> I? where I == C.Index { var i: C.Index = index while i < array.endIndex { if matchArray(array1: array, index1: i, array2: target, index2: target.startIndex, length: target.distance(from: target.startIndex, to: target.endIndex)) { return i } i = array.index(after: i) } return nil } internal func matchArray<C: Collection, I, D>( array1: C, index1: I, array2: C, index2: I, length: D) -> Bool where I == C.Index, D == C.IndexDistance, C.SubSequence.Iterator.Element : Equatable { if array1.index(index1, offsetBy: length) >= array1.endIndex { return false } if array2.index(index2, offsetBy: length) >= array2.endIndex { return false } let test1 = array1[index1..<array1.index(index1, offsetBy: length)] let test2 = array2[index2..<array2.index(index2, offsetBy: length)] for (x1, x2) in zip(test1, test2) { if x1 != x2 { return false } } return true }

2:07 PM

util.swift:16:46: Cannot convert value of type 'C.Index' to expected argument type '_.Index'

2:07 PM

うーん・・・

2:09 PM

2:09 PM

referenceでもIndexがCollectionのassociatedtypeに書いて無くて

2:09 PM

なぞ

型パラ2重に定義してないかこれ

最初は C.Index って書いてたんだけど

2:18 PM

それでもだめだった

2:19 PM

internal func findSubArray<C: Collection>( array: C, index: C.Index, target: C ) -> C.Index? { var i: C.Index = index while i < array.endIndex { if matchArray(array1: array, index1: i, array2: target, index2: target.startIndex, length: target.distance(from: target.startIndex, to: target.endIndex)) { return i } i = array.index(after: i) } return nil } internal func matchArray<C: Collection>( array1: C, index1: C.Index, array2: C, index2: C.Index, length: C.IndexDistance) -> Bool where C.SubSequence.Iterator.Element : Equatable { if array1.index(index1, offsetBy: length) >= array1.endIndex { return false } if array2.index(index2, offsetBy: length) >= array2.endIndex { return false } let test1 = array1[index1..<array1.index(index1, offsetBy: length)] let test2 = array2[index2..<array2.index(index2, offsetBy: length)] for (x1, x2) in zip(test1, test2) { if x1 != x2 { return false } } return true }

2:23 PM

あ〜〜〜〜いけた

2:23 PM

上の方の関数に where C.SubSequence.Iterator.Element : Equatable を付ける必要があった

ああまあそりゃそうやね

エラーメッセージにつられてしまった

Collectionの定義からIndex消えてるのはなんやろな

それ今のところ

2:25 PM

associatedtype Iterator = IndexedIterator<Self>

2:25 PM

この行によって

2:25 PM

IndexedIterator<T> の Tの制約が　間接的にSelfに掛かって

2:25 PM

SelfがIndex持ちになってる仮説を立てた

無茶苦茶な

GenericClass<T> の Tのところ使って外側に制約かけてるのでは

Collection、前はIndexableみたいな型貼り付けてたよね (edited)

2:27 PM

where Elements : _IndexableBase

2:27 PM

ははーん

2:27 PM

わかった

そのElementsがIndexedIterator<Elements>でしょ？

_IndexableBase

2:27 PM

こいつはinternalなProtocolなので

2:28 PM

それが前提になったProtocolを外から観測すると

2:28 PM

消えて見える

2:28 PM

なので

消えて見えるｗ

2:28 PM

あ〜 _IndexableBaseにIndexが書いてあってCollectionはそれを継承してる？

https://github.com/apple/swift/blob/master/stdlib/public/core/Collection.swift