@tarunon wt は、 Cat が Protocol に準拠した時の、witness-tableへのポインタ。

3:32 AM

例えば Dog が Protocol に準拠した時のテーブルは別に存在していて

だから、呼び出せる関数はもう決まっていて

でもその2つのテーブルの、エントリの並びは、 Protocolの定義に従って揃ってる。

テーブルの探索は浅くて済むんだよね

探索はしない。

3:32 AM

インデックス番号だけ。

3:32 AM

テーブルの2番目、とか、テーブルの3番目、とか (edited)

3:33 AM

静的なインデックスにコンパイルされてる。

じゃあfunc hoge<Foo: Protocol>(foo: Foo)と、fucn (foo: Protocol) だと

3:33 AM

この関数の中で使われるfooが呼び出す関数は

3:33 AM

テーブルの探索の有無の差が生まれる

あ、いや、

3:34 AM

後者の場合も、

3:34 AM

Protocol 型の変数っていうのは

3:34 AM

結局、 (x, wt, xt) の 3つのフィールドを持つ特殊な型なんだよね (edited)

んー

だから結局同じ。

おお

3:35 AM

じゃあ僕が最初に言っていた

3:35 AM

Protocol型の変数は暗黙的にGenerics型の変数と同じ状態になる?

3:35 AM

というが既に存在している、ということ

Associated Type が無い場合に限っては、YES (edited)

おおお~

3:35 AM

理解完了

3:35 AM

あざっす

逆に言うと、

3:35 AM

Associated Typeがある場合でも

3:36 AM

引数には渡す事が今もできるわけで

そうだね

その時にはさっきの3タプルになってるわけだから

3:36 AM

そもそも既にExistentalのバイナリ表現はこの３タプルで

3:36 AM

完成してるやんけ

3:36 AM

っていうのが

3:36 AM

http://qiita.com/omochimetaru/items/b41e7699ea25a324aefa#%E3%83%97%E3%83%AD%E3%82%B3%E3%83%88%E3%83%AB%E3%81%AB%E3%82%88%E3%82%8B%E5%8B%95%E7%9A%84%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81%E3%81%AE%E5%AE%9F%E8%A3%85-sil

Swiftのジェネリックなプロトコルの変数はなぜ作れないのか、コンパイル後の中間言語を見て考えた - Qiita

導入

Swiftでは通常のプロトコルは変数の型として使用することができますが、型パラメータ(associated type)を持つジェネリックなプロトコルの変数は作れません。非ジェネリックな例 ```swift prot...

3:36 AM

この記事で最終的にぶつかってる謎で

3:37 AM

だから、パフォーマンスのために あえて やってないのかなあ？って話をした。

ふーむ

3:37 AM

構文が完成してなかっただけでは?という気もしている

そうだね、SILの時点で表現可能な文法が無かったから、それもある。

3:38 AM

技術的にはできるけど作らないといけない部品がいっぱいあるのは確かだからそれで止まってるだけなのかもしれない。

namespaceを作りたいときってclassとstruct(or enum)どちらを使いますか？ struct API { private init() { } struct Request { private init() { } struct GetDayOfWeekStories: APIRequest { (edited)

case なし enum だとどうやってもインスタンス化できないので、 private init 書く必要ないからいいんじゃないかと思ってます。

1

おお、たしかに（いま、private init() { fatalError() }くらいにした方がいいかなと思ってました）

/// Namespace for diagnostics enum diag {} extension diag { // メンバー群 ... 実際にはすべてのメンバーを extension に実装することにより、 case を書けなくするということをやっています。 (edited)

なるほど。ありがとうございます。

Swiftの??って、もしかしてコンパイルすごい遅いんでしょうか

1:31 PM

 func apiErrorWithPromise(_ errorMsg: String? = nil, _ httpNumber: Int? = nil) -> Promise<Void>{ let errorMessage = "エラーメッセージ:\n"+(errorMsg ?? "不明なエラー(iMast)")+" ("+String(httpNumber ?? -1)+")\n\nエラーメッセージに従っても解決しない場合は、アプリを再起動してみてください。" return alertWithPromise( title: "APIエラー", message: errorMessage ) }

1:31 PM

こういう関数があるのですが、この関数のコンパイルに30秒ほどかかってしまっていて

1:32 PM

以前はerrorMessageに代入しているところをmessageに直接書いていたのですが、複雑すぎるとSwiftコンパイラに怒られてしまったので分けたのですが

1:33 PM

他の似たような関数では遅くないので、??が原因なのかなあto

1:33 PM

思ったのですが

?? あるケースとないケースで、計測してみては？

とりあえず??を!にしてみたところありえん早くなりました

https://bugs.swift.org/browse/SR-1102 (edited)

1:35 PM

認識はされていますが、なかなか直りませんねー。

なるほど、認識はされているのですね...

1:35 PM

代わりの書き方とかあるんでしょうか（あまり良くわかってない）

??が常に遅いわけではなく、遅くなるケースがちょくちょくある、ということですよね？

そうですね

もう少し細かく分離して変数で受けるだけでも速くなりそうな気がしました。 (edited)

なるほど

これリテラルと混ざって書いてるのが原因の一端なので、Optionalが関わるところを隔離するだけで楽になるはず

var errorMessage:String = "" errorMessage = "エラーメッセージ:\n" errorMessage += errorMsg ?? "不明なエラー(iMast)" errorMessage += " (" errorMessage += String(httpNumber ?? -1) errorMessage += ")\n\nエラーメッセージに従っても解決しない場合は、アプリを再起動してみてください。"

のようにしたら早くなりました、ありがとうございます

大体リテラルいくつかとオペレーターいくつかと並べると、組み合わせ爆発して遅くなります。これは??に限らず、有名なのだとBoolでorを並べたら大変なことになる、とか。

なるほど

1:40 PM

無理に一行で書こうとせず、何行かに分けたほうがいいんですね

人間が読むのが大変なのは機械も大変だったりします。

なるほど

+=で連結ではなく、??絡むところだけ隔離して、()で文字列組み立てた方がベターに思いました。

1:44 PM

バッククォート()と書いたのにバッククォートの記号消えちゃいました。

\()←こいつ、中にちょっと式書くと音を上げるのであまり使ってないw

2

うーん、\()どうも個人的に読みにくいんですよね

文字列補間は他のモダンな言語でも大抵取り入れていて一般的に読みやすい気がしますが、それが嫌でも += ではなく、+でつなげるのが良いかなと思いました。

1:50 PM

名前は適当ですが、こう分離して、 let errorMessage に +で連結して代入 let errorMsg2 = errorMsg ?? "不明なエラー(iMast)" let httpNumber2 = httpNumber ?? -1

なるほど

多国語対応するつもりがなくても、Localizeファイル作っておいて、swiftgenなりR.swiftなりで、文字列を静的型で評価できるようにしておいた方が良い、というのもあった。

ですね。

1:52 PM

一覧されて見やすく管理しやすくもなりますね(　´･‿･｀) (edited)

%@や%iだと、Stringを作るための関数群として提供されるので非常に楽ですね。おすすめです。

本当に多言語対応するつもりが無いのか、単に直近で無いだけのか、怪しいこともあるので、そういう意味でも、分離しておいた方が無難かなと思っています、分離も大した手間ではないので。 (edited)

なるほどー

なんか

1:56 PM

リテラルと足し算が絡んでると踏みやすい

1:57 PM

感じがしている

1:57 PM

配列リテラルに並べてjoinでくっつけるとかでも軽くなるかも

Localizeファイル使うと、いずれにせよバッククォート() じゃなくて String(format: "", a, b) とかになりますね。 (数値絡んだりすると、 String.localizedStringWithFormat("", a, b) ) 今回の場合、これだけで速くなりそう。 (edited)

なるほど、ありがとうございます

‪アプリとWebが同じ機能をもっていて、万が一アプリで、ViewControllerが初期化できないとき開発ではfaitalError or nilでもいいが、本番ではnilで返して、遷移するコードでユーザーに遷移できません、その機能は現在使えませんでしたって伝えて戻るか、同じWebのページが表示できればバグ修正するまでWebを表示するのがいいんじゃないかと思うのですが、皆さんどうしてます？全部落とすとユーザーがもう一度アプリを開かない限りCrashlysticsにエラーが送られないので、障害検知できない気がするのですよ (edited)

@applideveloper #ui-ux で返信しました

https://twitter.com/clattner_llvm/status/877341760812232704

Chris Lattner (@clattner_llvm)

Turns out that Tesla isn't a good fit for me after all. I'm interested to hear about interesting roles for a seasoned engineering leader!

Retweets

128

Likes

219

3

2:09 AM

クリスラトナーがテスラ辞めそう

マジかよw

https://twitter.com/KrauseFx/status/877347713012047872

Felix Krause (@KrauseFx)

@clattner_llvm Let's all fix code signing together

ええっｗ

セグフォで落ちる自動運転車が生まれずに済んだのかもしれない。

めちゃめちゃエラー出る自動運転車見たかったンゴ

これでマイクロソフトとか行ったらおもしろそう。

リプライちょこちょこありますね

GoogleがSwift採用はないだろうけど、Microsoftならワンチャンあるかも？

そして産まれるSwift.NET

ｗ

AWSとか行ってサーバーサイドSwiftもっとやってほしい

そのうちもとの Swift がわざわざ Swift Native って呼ばれる流れか

www

Microsoftに行ってWIndows対応→Obj-CとSwiftみたいにC#と連携できるように→これまでのWindows資産を活かしてSwiftで開発できるように

2:19 AM

ができればパイが広がりそう

列強がドコドコリプライ送っててめっちゃおもろい

わかる

https://twitter.com/clattner_llvm/status/877353276676612102

Chris Lattner (@clattner_llvm)

My resume is easy to find online. 7 years of Swift experience

2:33 AM

けっこうしっかり辞めそう

Swift（スウィフト）は、アップルのiOSおよびmacOS､Linuxで利用出来るプログラミング言語。Worldwide Developers Conference (WWDC) 2014で発表された。

2:36 AM

表に出てから3年しか経ってないから

4年かけて作ってたんやなあ

Appleは4年間開発してたんだ

iOSいくつの頃よ

2:37 AM

4とかか

ARC無い頃から作ってたの？

3.2 Wildcat 2010年4月3日 iPad（第1世代）

I started work on the Swift Programming Language (wikipedia) in July of 2010. I implemented much of the basic language structure, with only a few people knowing of its existence. A few other (amazing) people started contributing in earnest late in 2011, and it became a major focus for the Apple Developer Tools group in July 2013.

iOS3.2が2010年に出てる

http://www.nondot.org/sabre/

2010 ってまだ iOS そんな化石みたいなバージョンだったのか…

ARCがiOS4からだから

これswiftに合わせてObjCにARC作られた説、割と罷り通る

MRCのときからやってたのか

2:38 AM

あ〜〜〜

ありえますね

LLVM側の改修が並行してObjCにおすそ分けされていたのか

おお

2:39 AM

納得感あるなたしかに

"Automatic Reference Counting" という文字列が含まれる swift と clang の最初のコミット。 2011年4月15日 7:05:07 JST https://github.com/apple/swift/commit/3cce5623cb84cb839923ae4ac579ae50d18a0740 2011年6月16日 6:21:53 JST https://github.com/apple/swift-clang/commit/8246702d0cbecc3fd5748b58614ffed7ad9e04a5 (edited)

add a bunch of random documents · apple/swift@3cce562

Swift SVN r369

The specification document for the new ObjC Automatic Reference Counting · apple/swift-clang@8246702

feature. Implementation to follow. :) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133090 91177308-0d34-0410-b5e6-96231b3b80d8

3:14 AM

この時のSwiftのリポジトリにARCの実装が含まれているかどうかはよくわからないな。

3:17 AM

clangにARCの実装が入った時のコミット 2011年6月16日 8:02:42 JST https://github.com/apple/swift-clang/commit/f85e193739c953358c865005855253af4f68a497

Automatic Reference Counting. · apple/swift-clang@f85e193

Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug,...

この時のSwiftのリポジトリにARCの実装が含まれているかどうかはよくわからないな。

その時点のSwift Language Referenceを見るとARCの実装とか影も形もなさげ。 https://github.com/apple/swift/blob/3cce5623cb84cb839923ae4ac579ae50d18a0740/docs/LangRef.html

apple/swift

swift - The Swift Programming Language

typealias DataSearchFlags : oneof { None, Backward, Anchored }

3:30 AM

enumもどきみたいなやつおる

SwiftKickoff.rtf https://github.com/apple/swift/blob/3cce5623cb84cb839923ae4ac579ae50d18a0740/docs/SwiftKickoff.rtf

More Open Discussion

More concrete goals, plans, schedule through WWDC, etc.

How/when to engage with the rest of the company, when to go more public.

(edited)

apple/swift

swift - The Swift Programming Language

3:43 AM

この時点ではApple社内でもSwiftの存在は知られていなかったぽいね。 (edited)

ほお〜〜

ARCがSwift発祥というのは無理がありそう。

違ったか~

あーなるほど。

https://twitter.com/StateOfNetwork/status/877387757383016448

The State Of Network (@StateOfNetwork)

Tesla's autopilot software head quits in less than six months https://t.co/B8qvSrWDnS Via @Reuters #companynews

4:49 AM

確定っぽい。

Tesla Inc (TSLA.O) said the head of its autopilot software, Chris Lattner, left the company in less than six months since joining the electric carmaker.

4:50 AM

head of って、リーダーだったのかな？

VPじゃなかったけ

4:50 AM

VP of Autopilotみたいなんだったきがする

ほー

http://jp.techcrunch.com/2017/01/11/20170110tesla-hires-apples-creator-of-swift-as-new-vp-of-autopilot-software/

Darrell Etherington

TeslaがAppleのSwift開発責任者を、自動運転担当副社長として引き抜いた | TechCrunch Japan

Teslaは自動運転の取り組みを率いる新しい副社長を獲得した。Chris Lattnerだ。そのAppleからの離職は本日（米国時間10日）の早い時間に発表されたばかりだ。LattnerはAppleで11年働いた。その主な貢献はAppleの最新のプログラミング言語であるSwiftの開発である。Swiftは初心者がm..

http://twitter.com/koher/status/879184882932473856

koher (@koher)

この新しいsubscriptめちゃくちゃ便利そう。 https://t.co/mN88tMyEoq

4:14 AM

http://twitter.com/tarunon/status/879189954592505856

uounɹɐʇ (@tarunon)

@omochimetaru @koher いや、それはそうだけど、dictionary[$0]が値の存在が保証されてるならdefaultは0じゃなくてNeverが妥当じゃない?って話

4:14 AM

@tarunon [default: ] を指定するのは、値の存在が保証されてない場面では？？

Non Optionalにするための用法だから

4:14 AM

+=するなら値保証されててもdefault要るっしょ

4:15 AM

dict[key]! += 1 ってできたっけ?

それじゃあ意味が違ってない？

4:16 AM

というか、値保証されてるときはむしろdefault使っちゃだめでしょ

4:17 AM

値が無いかもしれない => なかった時に使うデフォルト値を指定したい => 今回の dict[key, default: d] を使うべき値があるはず => なかったときはクラッシュさせたい => dict[key]! を使うべき (edited)

dict[key]!で+=使えるならそれはそう

dict[key] += 1 ができるかどうかはわからないけど、それができないからといって

使った記憶がないから使えるか解っていない

default: を使っちゃたら

4:18 AM

値がない場合のエラーを握りつぶすパターンに書き換えていてよろしくないと思う。

だから、0じゃなくてNeverいれようぜって話

あ〜

4:19 AM

dict[key, default: never()] += 1 こう？

なおdict["key"]! += 1はSwift3時点で無理

4:19 AM

そう

http://twitter.com/tarunon/status/879186494677630976

uounɹɐʇ (@tarunon)

@koher デフォルト値が絶対ある場合はundefined<T>とか使えば良さそう。

4:19 AM

dict[key, default: undefined()] += 1

4:19 AM

こう書くと良さそうですね、って言ってるのか。

Optional, throwsで値が返ってくる系の問題は、返り値に対してvar structなパターンが使えないという点だな

4:20 AM

それを克服できるので、しかし

4:20 AM

デフォルト値に適当な数値を入れてしまうと

「めちゃくちゃ便利そう」に対して、「undefined()で代用できるから不要」って反対してるのかとおもった。

1. エラーが握りつぶされる　2. そこだけ読んで0が妥当かわからない

他の応用方法を提示していたのか。誤読した。

という問題を孕むので

4:21 AM

最初から一貫してそう主張してるぞなw

なるほど

4:21 AM

いや、undefinedを「default: のところに指定する」っていうのがわかってなかった (edited)

Neverがボトムになれba

4:21 AM

まどろっこしい関数用意しなくて良くなるんだがな

var x: [String: Int] = [:] x["aaa"] = 3 x["aaa"]! += 1 print(x["aaa"])

4:23 AM

コンパイルできた。出力 Optional(4)

あれ、まじ?

マジ

4:24 AM

Version 8.3.3 (8E3004b)

4:24 AM

これ不思議だね

あーいけた

4:24 AM

なんかミスってたっぽいな

! 演算子はオペランドが左辺値の場合、左辺値のままにしてくれるのか。

4:25 AM

そうすると話が巻き戻って dict[key]! += 1 で良いってことになるのか・・・？

せやね

てかそれだったら

4:26 AM

dict[key] ?? defaultValue += 1

4:26 AM

これがかけたら良かったような・・・？

4:26 AM

これは厳しいか。 ?? の右側は別のストレージだもんな

それどうやってdict[key]見つけんの

一応できると思うんだよな

まあそもそもDictionaryをガチャガチャ操作するのをやめろって話ではある

readとwriteで別のストレージを見るアクセサになればいいから

4:29 AM

なやましい

4:29 AM

dict[key] ||= 3 rubyだとこういうのよく見る (edited)

dict[key] ?? dict[key2] ?? default += 2

4:29 AM

これとかどうすんのっていう

同じようにできると思うイメージ的には

func doubleQuestion( left: (read: ()->T?, write: (T)->Void), right: (read: ()->T, write: (T)->Void) ) -> (read: () -> T, write: (T) -> Void)

(edited)

4:33 AM

実際には auto closure 的に read / write それぞれを取り出すことができないから無理だけど。

結果の値を左辺の全ストレージにぶっこむってことね

そだね、でもたしかに、２個めのdict[key2]にwriteするのかどうかとかわかりにくいな

素直に理解できる構文ではなさそうだ

完全に乗り遅れたけど、 Neverがボトムになれba まどろっこしい関数用意しなくて良くなるんだがな これおもしろいですね。

8:20 AM

dict[key, default: fatalError()] += 1 (edited)

8:20 AM

ってできるのか。

出来ますね、fatalErrorを使う優位性はメッセージ付きにできるところかな。

Never がボトムタイプでない現状だと、 func never<T>(_ message: String = "") -> T { fatalError(message) } みたいなのがいると。

ですです

Never がボトムタイプにならないのって誰も Proposal 書かないから？

8:23 AM

なんか前スレッドありましたよね。どうなったんだろ。

8:24 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md#never-as-a-universal-bottom-subtype

apple/swift-evolution

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

8:26 AM

An uninhabited type can be seen as a subtype of any other type ... This can be considered as a separate proposal.

↓全然伸びてなかった・・・。残念。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170508/036629.html

はやいとこMLじゃないところに出てきてほしい、Thumbs upとか使いたい

わかりすぎる

議論しないと同意できないフローかなり辛い。Neverがボトムタイプになるべきなんて、議論する余地無いんじゃねっていうのが伸び悩むのが本当に良くない

特に反対意見でなければ Proposal 作るフェーズに進んじゃってもいいのかも？でもスレ主的にはやりづらそうだけど。

githubとかだと

の絵文字が連打されたりするけどMLでそういうの無いしね

How to propose a change https://github.com/apple/swift-evolution/blob/master/process.md#how-to-propose-a-change

apple/swift-evolution

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

8:49 AM

今は "Socialize the idea" のフェーズだから

8:49 AM

"Develop the proposal" に進んじゃうという手もある。

8:49 AM

"Request a review" まで行けば Core Team も判断せざるを得ない。

8:51 AM

ただ、これって元々の Proposal が Joe Groff だし、 Core Team が認識してないわけはないから

8:51 AM

型システムに影響与えそうだし、 enum Never {} がボトムってどうなの？とか、他の enum Foo {} はどうなるの？とか、色々ややこしいから後回しにされてるのでは。

8:52 AM

それとは別に↓には強く賛成です。

はやいとこMLじゃないところに出てきてほしい、Thumbs upとか使いたい

8:53 AM

今も ML で +1 みたいなリプライあるけどｗ

あるけどMLでやると迷惑じゃないですか？

8:53 AM

と思って、やらない人と、気にせずやる人にわかれそう

8:54 AM

ていうか僕だったらスレッド一覧で見ていざ中身みたら +1 しか書いてなかったりして、そういうところもMLはだるい

まあそもそも議論は多数決じゃないから +1 に本質的な意味はないのかもしれないけど、提案社的には賛同者がいることがわかればやりやすいかも。

特に問題がないから議論が起きないのか、誰も興味が無いのかの判別がつかないのが辛い

そうそう。

ML からの移行は早くしてほしいし、 Core Team もやると言ってるし、でも急にはできないし、気長に待つしかなさそう・・・。

グローバル関数使うライブラリってSwifty的にNGですかね？

3:03 AM

someFunc(AnyProtocol, parameter...) 的なのを考えてたんですが型で判別できるから、ありかどうかで迷ってる感じです

Alamofireはdownloadとかあった気が

確かに、ありますね

https://github.com/Alamofire/Alamofire/blob/master/Source/Alamofire.swift#L179

Alamofire/Alamofire

Alamofire - Elegant HTTP Networking in Swift

型で分かるなら十分じゃないですか？

1

ありがとうございます、ちょっと思いつめてたので助かりましたｗ

というか

3:09 AM

パッケージでネームスペースが切れているのでは？

3:10 AM

さっきの download は Alamofire.download ですよね　正式には

3:10 AM

ちなみに min とかの組み込みも Swift.min です

そういう意味だとグローバル関数とは？という話に

確かに、downloadで衝突してたらAlamofire.downloadで呼ぶしか無いのはあります

3:11 AM

なんというか命名モラル的に行儀が良いのかって所がどうなのかなーと

ネームスペースが切れててもdownloadでアクセスできるので結局そこがどうなのかって話なわけですよね

別に困らないし良いのでは

1

気にしすぎだった説

Javaだといざ衝突したときに com.omochimetaru.Alamofire.download とかなってシンドイけど Alamofire.download ならまあ別に平気だし、だいたいは引数の型でも区別可能だし。

3:14 AM

もし複数のライブラリから download が出てきてごちゃごちゃしてきたときは

3:14 AM

func alamofireDownload() { .. } とかを自作してラップするのが良いんじゃないでしょうか

3:14 AM

本当は別名インポートの言語機能がほしいけど無いので。

import ... as ... 的なやつですか

そうです

それほしいですね

ただ、グローバル関数って、ある意味シングルトンに対するメソッド呼び出しなので

3:15 AM

シングルトンの問題と同じで、なんらかのレシーバにぶら下げて挙動を変えたいように

3:15 AM

今後変更がかかりそうなら注意したほうが良さそう

https://twitter.com/moaible/status/879488838720045056

MOAI (@moaible)

@tarunon なるほど、確かにそこも組み替えできるようにした方が可動域的な部分で良さそうです、もう少しいじって見ます

レビューありがとうございます、まさか誰か見てくれるとは思わずｗ

3:16 AM

文脈はここだと思うんですが(具体的なアプローチを提案できて無くて申し訳なく...

いえいえ、レビュー嬉しかったですどういう風に直そうかなーって考えてました

APIClient.init(URLSession)な実装にしておいて、シングルトンを避けて任意のAPIClientをinitするのが良いと考えていて

3:18 AM

そもそもAPIClientのベースをfunc loadを持つprotocolとして定義しておけば、MockClientの実装をサクッと作れるよ、という感じでした

protocol APIRequestable { func load<R: Request>(request: R) -> R.Response } って感じですかね？

そうですね。僕が最近書いたコードは大体そんな感じになってます

なるほど、確かにそれぞれ用途ごとに準拠したものを用意すれば済みますね

3:25 AM

自分が言われてからぼんやり考えてたのは requests<R: Request>(adapter: RequestAdapter=DefaultRequestAdapter()) -> (request: R) -> R.Response みたいにしようかで悩んでました (edited)

3:25 AM

結局どこに状態持たせるかって話になっちゃいますかね

↑ありがとうございます、とりあえずまた直してみます。また何かあれば相談させてください

@norio_nomura > emscriptenちょっと試してみたけど「クロスコンパイルターゲットをどの様に用意するか？」な問題に移ってる様に見える。どのように用意するか、とはどういうことですか？

1:26 AM

emscriptenのコンパイルターゲットって宛先がJSかwasmかぐらいしか無いのかと思っていました

エラーを見ると

warning: Linking two modules of different target triples: /Users/norio/.emscripten_cache/asmjs/libc.bc' is 'asmjs-unknown-emscripten' whereas 'hello_world.bc' is 'x86_64-apple-macosx10.9'

swiftcが生成したhello_world.bcのターゲットがx86_64-apple-macosx10.9になってるからダメだよ、となってる。

1:29 AM

swiftcでtargetがasmjs-unknown-emscriptenな.bcを生成できないとダメなんじゃないかな。

Swift -> LLVMIR のコンパイル時点でemscripten環境をターゲットにするのか。そういうアーキテクチャなんですね

あまりよくわかっていないのだけど、たぶんクロスコンパイル用のtoolchainを用意しなければいけないのと同じなんだと思ってる。 https://github.com/apple/swift-package-manager/pull/1098

cross compilation support (configurable destinations) by weissi · Pull Request #1098 · apple/swift-package-manager

General This adds experimental support for cross compilation or more precisely configurable destinations for binaries to SwiftPM. The basic idea is that you hand a JSON file in the format described...

なるほど

2:01 AM

emscriptenの時点で darwin-x64環境とかを抽象化するわけじゃないんですねえ

emscriptenのissueには「asmjs-unknown-emscriptenはWebAssembly(wasm32)とほぼ同じだよね？」って話してる人がいて、同じ人がSwiftをWebAssemblyへクロスコンパイルする話題をswift-devに投げてる。 https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170626/004860.html (edited)

おおアツい

2:08 AM

For example, the Clang that ships with Xcode 9 includes support for wasm32 as a compilation target.

2:09 AM

なるほど

https://gist.github.com/koher/3e04b4f1b8adbbf0379d38c0ad83a3ea asyncの話なんですが @koher

async-await-fitting-to-swift.md

3:04 AM

ぼんやり考えていて、コールバック時の結果にErrorが入ってるときに、(T?, Error?)やResult<T>を使うのは辛いなと思っていたのが解決するなと。

そうですね。僕は JS の Promise みたいに非同期処理とエラー処理をまとめて扱うような設計が嫌いで、非同期処理なら非同期処理、エラー処理ならエラー処理と責務を分解しておくべきだと考えて、エラー処理を含まない Promise ↓を作ってました。 https://github.com/koher/PromiseK/tree/dev-3.0

koher/PromiseK

PromiseK - The Promise class designed as a Monad for Swift.

3:07 AM

で、そうすると、この Promise と Result が対応してるなと思って、それらを throws, try と (edited)

3:08 AM

async, await に対応させれば、自由にまぜて使えるよなぁと考えたものです。

今でもやろうと思えば、コールバックの値を() throws -> Tにすればイケると思うんですが

3:09 AM

あまりやってるのは見ないですね

ですねー。できるけど面倒ですしね。

3:10 AM

せっかく安全なエラー処理機構を持っているのに、Promise にエラー処理を担当させちゃうと、 catch 忘れがおこっちゃうんですよねぇ。

純正だとT?, Error?、Resultの民はResult<T>だ

Promise と Result を一緒に使うとモナドパズルになっちゃうんですよねぇ。

3:11 AM

Result<Promise<Result<Foo>>> を Promise<Result<Foo>> にしたいとか。

最近それやってて、windows版はasync+throwでできて良かった

C#ですか？

はい。

C#はasync-awaitは明示的だけどthrowが・・・

Array<Promise<Result<Foo>>> を Primise<Result<Array<Foo>>> にしたいとか。

その移し替えはめんどくさそうだ

その辺のメリットも明記したら伝わりやすいのかな、というのと

jsだとPromise.allとかあったけどエラーハンドリングが分離してるから純粋にはできないのか。

そうですねぇ。あまり詳細まで書くと長くなって読まれないんじゃないかという心配もあって、議論の中で説明できればいいかなと。英語で議論についていけるのかあやしいですが。

3:16 AM

ちなみに、 PromiseK 3.0 では let a: Promise<Int> = ... let b: Promise<() throws -> Int> = a.map { try foo($0) } みたいに、 map 等の中で throw される場合は戻り値の型パラメータを () throws -> Foo に変換する API を考えてます。

3:17 AM

async, await ができれば無用の長物ですが。

ambiguous出そうw

あと、おもしろいかなと思って、 typealias Promise<Value> = (@escaping (Value) -> ()) -> () とする Promisure (= Promise + Closure) というライブラリも作ってましたｗ

3:19 AM

// Wrapping let a: Promise<Int> = { $0(3) } // like `Promise.resolve(3)` in JS // Promisifying a callback let b: Promise<Int> = promise { resolve in // Gets 5 after 1.0 seconds DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { resolve({ $0(5) }) } } // Operators let sum: Promise<Int> = a >>- { a in b >>- { b in { $0(a + b) } } } // flatMap let square: Promise<Int> = { $0 * $0 } <^> a // map let vector: Promise<Vector2> = curry(Vector2.init) <^> { $0(2.0) } <*> { $0(3.0) } // apply

Promiseの型パラに関数型入っとる・・・

関数型は non-nominal なので extension が生やせないので、メソッド代わりに全部演算子になってます。

3:24 AM

@tarunon Rx の Observable にエラーが組み込まれてるのも僕は好みじゃないんですが、どうにかならないものでしょうか。

あ〜 > extension

僕も全く同じ気持ちで

3:26 AM

あーでも

3:26 AM

ObservableはErrorは停止なので、色々厳しそう

Error排除できるタイプのもあるしそういう方向で対応しようってことになってるんじゃないですか？

SharedSequenceですね

その場合って、 failable な型が重複して似た仕組みを持つことになるけど、それは仕方ないか・・・。

Observableになんとか、throws-rethrowsの機構を組み込みたい

やっぱ、 throws, try みたいな特殊構文用意するよりも、モナドに対して do 記法用意するとかの方が汎用性はありますよねぇ。

3:29 AM

入れ子モナドのパズルを解決するいい方法が必要だけど・・・。

さっきのPromiseの例は上手い解決かもしれなくって

3:30 AM

ちょっと後で考えてみよう

あれって、 Result と Promise なら Promise が外側にいてほしいとか、モナド感での precedence みたいなものが考えられる気がして、

3:31 AM

その順に全部いいように組み替えてね関数が一つあればうまくいきそうな気も？

物凄い筋肉質なオーバーロードした関数が存在しそう

筋肉質なオーバーロードｗ

いや、オーバーロードじゃなくて

3:32 AM

Monad 型に対して演算子みたいな precedence を指定できて

3:32 AM

sort 関数みたいに、それを使って入れ子を関数が解決する。

高階型ないからオーバーロード必須ですよ多分

ああ、高階型あり前提です。

型同士の合成規則を２つの型の優先度の２項関係を表す型の集合で記述して

3:34 AM

型解決の枠組みで静的に決定

3:34 AM

みたいな・・・

で、後はネストモナドまとめてアンラップもできれば。↓みたいな？

let a: Result<Promise<Int>> = ... let b: Promise<Result<Int>> = magic(a) do { let c: Int <-- b // 多段アンラップ let d: Result<Int> <- b // 一段アンラップ }

3:37 AM

そしたらモナドのネストも恐れる必要がない（組み換え問題とアンラップ問題を同時に解決できる）気がするし、いちいち try とかキーワード足さなくても自作モナドを組み込みモナドと同じように便利に使える。

うーん

3:42 AM

殊、asyncとthrowsに関しては汎用性云々というより (edited)

3:42 AM

あまりにも出現頻度が多すぎるので言語仕様でサポートしたほうが平和なのでは?という気がしている

そうですねぇ。特殊構文はそれはそれで見やすいんですよね。

3:43 AM

PromiseK では then が map と flatMap になってるんですけど、ネストしてくると読みづらいんですよねぇ・・・。

then、Swiftコンパイラには荷が重いのでmap/flatMapにしたほうが良いよ派の人間です

人間にも重いと思う派

コンパイラが理解できないのは人間にも理解できないよ

3:45 AM

大体の場合ね

じゃあ同じ意見だった

ただ、 Swift は Result を作らなかったから thorws, try を別の型でラップしたい場合に Promise<() throws -> Int> とかなるのはちょっとつらいですよね。

Promiseがasyncに昇格されれば辛さは消えますよ

はい、それはそうです。けど、 Observable とかでやろうとしたらできないですよね？

そうなんですよねぇ

結局別のエラー処理機構を導入せざるを得ない。

ですね

throws () -> Tにしなきゃいけないのがしんどいので

async / awaitが言語に入ったときに

throws Tがあれば

言語サポートがあるけど非同期としては貧弱なPromiseと

3:47 AM

言語サポートが無いけど非同期機構としてはリッチなObservableが

3:47 AM

存在する環境になって

3:47 AM

甲乙つけがたくなりそうでそこはちょっとナーバスになっている

Observable相当のものが言語機能に降りてこないかな~というのを考えてるけど

それはなあ・・・

これは前おもちくんと話したな

細かい設計に柔軟性がありすぎてコンセンサスも取れなさそう。

3:48 AM

RACだと Signal / SignalProducer で Hot / Cold を型付けしたりしてるし

シンプルな Promise であれば議論の余地がほぼなさそうだけど、 Observable レベルになると枯れてなくて言語機能にするにはつらそう・・・

そうなんですよねえ

だから、ライブラリでも組み込み構文に近い便利さを享受できる言語仕様になってればいいなぁと思うんですけどねぇ。

治安は悪化しそう

それはそうですねｗ

3:51 AM

文化が断裂してお互いに理解できないコードの世界が出来上がりそうｗ

3:51 AM

まあ、でも Rx はすでにそうなってるような気も。

Rxはそうなんですけど

3:53 AM

言語をまたいだ世界だから

3:54 AM

まあいっかって気持ちになる

3:54 AM

(RxSwiftの呪文を覚えるとJavaでも使える

まだ関数呼び出しの範疇に収まってるから平気だけど

3:54 AM

構文拡張とかやっていったら人死にが出る

3:54 AM

オレオレoperatorですら結構辛いのに

ですね

構文拡張というか、汎用的に使える構文って意味ですね。

Javaのアノテーションもしんどい

RxSwiftのSwift2の頃のオペレータは結構好きでした

3:55 AM

>-

マジすかあ

隣の同僚がオレオレオペレーターてんこ盛りプロジェクト引き継いでブチ切れながら消していってて、まぁそうっすね…みたいな感じ

最初ひょえ〜っとなって、やっていくうちに、あれ、これメソッドでいいのでは？となって、Swift側の制約でできないからやってるとわかって、Swift3でメソッドになって気持ちが落ち着いた (edited)

他のライブラリ含めてオレオレoperator廃止されていってるのを見て、これあかんやつなのかってなったのは記憶にあります

たしかジェネリック型に対するextensionメソッドがまだショボくって

3:58 AM

でも演算子ならいけるみたいな

3:58 AM

状態だったんですよね。

あったあった

3:58 AM

オレオレオペレータ廃止の流れは

今でも、 non-nominal の extension 書けないから

そもそも言語機能としてオレオレオペレータの何かが削られたからっていうのが

Swift3の仕様強化でだいぶオペレータが排除できた

オペレータならできる状態が終わってない・・・

大きかった気がする

3:58 AM

non-nominalはありますね

例の => も。

そうですねえ　そして関数型が non-nominal である影響がでかい。

3:59 AM

=> が演算子にしかできないのも Any型がnon-nominalだからだっけ (edited)

まあ、 => レベルだと演算子の方が可読性高そうだけど。

3:59 AM

Any でもダメで、任意の型パラじゃないといけないから辛い・・・

ん？とは？

4:00 AM

もしAnyに対するextension methodで書けたとして、それでも拾えないパターンってどういうのがあるんでしょうか (edited)

extension Any { func `let`<T>(_ f: (Any) -> (T)) -> T { ... } }

4:00 AM

だったら、クロージャの引数が Any になっちゃって

4:01 AM

ダウンキャストしないといけなくて面倒。

そこは Self では

そこ Self にする extension ってできるんだっけ？

わからないｗ

えーっと

4:01 AM

Anyはprotocolなんでいけます

4:02 AM

are

↓演算子実装 public func =><T, U>(lhs: T, rhs: (T) throws -> U) rethrows -> U { return try rhs(lhs) }

classだとできないな

class Animal {} class Cat : Animal { func nya() { print("nyaa") } } extension Animal { func exec(f: (Self) -> Void) { f(self) } } let cat = Cat() cat.exec { $0.nya() } error: TempGround.playground:11:12: error: value of type 'Animal' has no member 'nya' cat.exec { $0.nya() } ^~ ~~~

classはですね

4:03 AM

extension SomeProtocol where Self: SomeClass {} (edited)

4:04 AM

これでSelfが使えるようになる

4:04 AM

Anyがextensionできるなら、

4:04 AM

extension Any where Self: SomeClass {}

4:04 AM

これでよさ

お、できた

4:06 AM

protocol Anything {} extension Anything { func `let`<T>(_ f: (Self) throws -> T) rethrows -> T { return try f(self) } } extension Double: Anything {} (42.0).`let` { $0 + 1.0 / $0 }

protocol Proto {} class Cat : Proto { func nya() { print("nyaa") } } extension Proto { func exec2(f: (Self) -> Void) { f(self) } } let cat = Cat() cat.exec2 { $0.nya() }

4:06 AM

できた

4:06 AM

@tarunon whereなしでかけた

いやいや

4:07 AM

それだとCatのメソッド使えなくなるぞ

exec2のなかで nya() が呼べたよ。

exec2自体の実装の中でnya()呼べないという意味

今の => の議論からするとそれは問題ないのでは

用途をletに限るならまあそう

=> の実装をオペレータからメソッドにできるかどうかだけを今考えていて

これで問題なのは Any が nominal でないってことだけなわけだ。

現状は Any に対する extensionが書けないからできない、

4:10 AM

もし書けるのであれば Self を f に渡す形で実装はできる。

4:10 AM

@koher 現状でも

うん

Any じゃなくてLettable という protocol のメソッドとして作って

4:10 AM

.let を使いたい型については extension Cat : Lettable {}

4:10 AM

と、１つずつユーザーが書いていけばできそう。

面倒すぎでしょｗ

はい・・・

1

そして可読性の観点でも => の方がいいと思う。

let束縛感がありますね

可読性はちょっと疑問があって

4:11 AM

広く知られてればまあそれはそう

4:12 AM

1 + 1 と 1.add(1) だと俄然前者のほうが良い

4:12 AM

f <$> [1] と [1].map(f) はさてどうだろう、という (edited)

4:12 AM

広く知られればいいけど。

<$> は順番が逆転しちゃう問題もありますしねぇ・・・

4:13 AM

さっきの Promise のチェーンは

あー逆だったか

promise.flatMap { ... }.flatMap { ... }.flatMap { ... }

4:13 AM

よりも

なんじゃこれって思ったときに調べにくいという問題はあるね

primise >>- { ... } >>- { ... } >>- { ... }

4:14 AM

のようが見やすい

4:14 AM

ググラビリティ低い問題はある。

4:14 AM

記号検索させてほしい。

4:14 AM

記号検索エンジンにニーズある気がする。

あとはxcodeがもっとキビキビ動けば Cmd + Click できるんだが

4:15 AM

だいたい indexing...

だからな

1

4:15 AM

定義にも飛べないしググることもできなくておわり

4:16 AM

http://blog.fkoji.com/2017/03052055.html Google 検索ではすでに記号1文字の検索はできるようになっていましたが、新たにプログラミングでよく使われる「===」や「+=」といった、複数の記号が連なる演算子などの特殊記号の検索ができるようになったそうです。

Googleで記号が連なる演算子の検索ができるようになってた - F.Ko-Jiの「一秒後は未来」

Google 検索ではすでに記号1文字の検索はできるようになっていましたが、新たにプログラミングでよく使われる「===」や「+=」といった、複数の記号が連なる演算子などの特殊記号の検索ができるようにな…

=> は標準ライブラリに入れてほしい・・・。

4:16 AM

え、できるの？

最近グーグルが強化されたらしいけどさっきpythonの r''' 出せなかったし嘘だと思う

正規表現ですか？

r''' は正規表現じゃなくて生マルチライン文字列

知らないのだ

@t.ae さっきこれを解読してた https://github.com/apple/swift/blob/master/utils/gyb.py#L67-L82

apple/swift

swift - The Swift Programming Language

ああ、rってregexのことかとおもってたらrawなのか

4:19 AM

正規表現でしか使ったことなかったから完全に勘違いしてた

pythonは正規表現リテラルは存在しない

うーん、なんとなく動いてそう？ Swift >>- で検索したら、一つ目は https://www.apple.com/jp/swift/ だけど、二つ目は typelift/Operadics で、三つ目は thoughtbot/Runes だった。

4:20 AM

以前よりはずっとマシな気が。

https://www.google.co.jp/search?client=safari&rls=en&q=Swift+%3C$%3E&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=j9FVWfP3N4Pf8AeCzIWIAw Swift <$> の検索結果だけど全く駄目

<$> はないよ

できない

<^> にマッピングされてる。

ああそっか。でも <^> も駄目っぽいですよ

>>= は重複してるから >>- に、 <$> は言語仕様上の制約で <^> になってる。

haskell <$>でもいまいちヒットしてない感

What does <$> mean in Haskell? - Stack Overflow https://stackoverflow.com/questions/.../what-does-mean-in-haskell このページを訳す 2016/05/17 - Google is not the best search engine for Haskell. Try Hoogle or Hayoo, both will point you right away to this ...

4:22 AM

最初に出た！

haskell <$> は https://stackoverflow.com/questions/37286376/what-does-mean-in-haskell が出たから

What does <$> mean in Haskell?

While reading a piece of Haskell code I came upon this: <$>. What does it mean in Haskell? After some google searches I remain in the dark.

いけてそう

公式じゃないけど

4:22 AM

まあないよりマシそう。

4:23 AM

swift <^> は出ないなぁ。

要約のほうがぜんぜんでないだけかな

普通の Google 検索と比べると、 10% くらいの精度で一応動いてそう・・・。

1

普通のGoogle検索もSEO頑張る人間に潰されててなんか辛い。最近動きありましたっけ。

|>は出た

SEO は辛いですが、 Google ないよりはるかにいいですからねぇ。

4:26 AM

この前、 Google を初めて知ったときのことを思い出してたんですが、試しに何かの名称を検索してみたら公式サイトが一番上に出てきて感動したことを覚えてるんですよ。 (edited)

4:27 AM

つまり、 Google 以前の検索エンジンは、何かで検索してトップに公式サイトが出ることがなかったってことなんです。もうそんな世界で生きていけない・・・。

associatedvalueを持ったenumの抽象化を書きたくて、

6:54 AM

結局具体型を作らざるを得ないのはわかったけど名前が困る

6:54 AM

2つならEither<L, R>でいいけど3つ以上(個数ごとに作る必要はある)の名前は何にするべきなのか

Either2<T1, T2> Either3<T1, T2, T3>

それ割とやるんだけど

Either<T, Either<U, V>>

他の言語とか見てもEither型はL,Rしかない

そもeitherという語から二者択一感を感じる

じゃあN者択一型はなんて名前になってるん？

either a, b or c って言えないんだっけ？

@koher ネストさせるとツリー構造に対して無限の分岐を埋めなきゃいけなくなるんでちょっと

3者以上からの選択1の用法では, ｟まれ｠に3者以上からの択一の際にeitherを用いることがあるが, any (one)の方が普通

1

Whichなのかなーとか

6:57 AM

思ったけど型名であると考えるとEither型の方が認知は絶対高くて、しかしEither3,4,5のような用法は

6:58 AM

ググった感じそんなになさそう

多分 Tagged Union で Untagged 的な振る舞いをさせるのがあまりよくないような・・・

ほしいのはenumの抽象化

6:59 AM

ケースが幾つあって型がそれぞれあってswitchで保証される

僕は C++ で Tagged Union が使いたくてシコシコ実装中

気になって見ててもAnyで使ってる人が多そうな雰囲気 > 複数形 https://english.stackexchange.com/questions/129288/words-similar-to-either-and-neither-for-3-items

Given two options, we can use 'either and 'neither' to show no preference. Do you want to watch A or B Neither, I don't like either. The only option I can see for more than two options is:...

AnyOf とか OneOf とか？

public enum Either2<A, B> { case a(A) case b(B) } public protocol Either2Convertible { associatedtype CaseA associatedtype CaseB var asEither: Either2<CaseA, CaseB> { get } } extension Either2: Either2Convertible { public var asEither: Either2 { return self } }

7:01 AM

↑こういうのを、あと3,4,5くらいまで作っておくとして

7:01 AM

Either3…ん?となった

enum の抽象化ってことは、 Either2<Int, String> と Either2<String, Int> は区別したいってことですよね？

それはしますね

7:04 AM

enumの抽象化、いい加減方方で使いすぎてるんで、マイクロフレームワークで作りおきしておこうというモチベになった

うーん、このレベルで抽象化したいことがあまりなさそうで、それをしたくなったときは諦めて複数書くとか？

7:04 AM

使いまくってるのか・・・

任意のenumを引数に取る関数、が必要になることが多くて

7:05 AM

そのたびに作ってますね

7:05 AM

ん?

たとえばどんな関数ですか？

enum Enum2, protocol Enum2Convertible

7:05 AM

これでいいんじゃないかな

7:06 AM

直近で言うと

Enum2, Enum2Convertible は良さそう

RxDataSourcesのdataSource作るのが面倒くさいので

7:07 AM

型を食わせてprotocol orientedに半自動生成させていて

Enum1 と Enum0 もいらないですか？ Box と Never

Cell型が複数の時に必要になる

7:07 AM

作っちゃおう

7:08 AM

個数ごとにコードを書く必要はあるんですが、1~5個作っておけば5個まではもう、DataSourcesを生成するコードを書かなくて良くなるんで

Enum3 とかだと CaseA より Case1 とかの方がよさそう

ですね

0 から始めるか少し迷うけど 1 からかなぁ。

7:09 AM

でもタプルは 0 からか

7:09 AM

それなら 0 からかなぁ

Tuple 0はVoidなんで

7:09 AM

Enum 0はNever

あ、ではなくて

まあそこはそう、美しいと思う

enum Enum2<T0, T1> { case Case0(T0) case Case1(T1) }

あw

7:10 AM

そういうことか

にするかです。

まあ0でいいんじゃないですかね

そのほうが一貫性はありますよね

7:11 AM

パッケージ名は EnumN とか？

EnumConvertibleかなんかにしようかと思っていた

7:11 AM

Convertible大好き人間

なるほど

ここで言うところのenum CellModelがさらにEnum2的な型で抽象化されるイメージです？ https://twitter.com/tarunon/status/854349403322175489

uounɹɐʇ (@tarunon)

@moaible つまり、enum CellModel { case cellType1, .... }と enum SectionModel { case section1([CellModel]), ... }

あとはリポジトリ名を UpperCamelCase するか小文字ハイフンつなぎにするかも迷いどころｗ

あーですね

7:14 AM

UpperCamelCase vs chain-caseは宗教戦争っぽい

7:14 AM

どっちがどうなんだ

enum絡むライブラリ作ったら名前これにしようと思ってた http://ejje.weblio.jp/content/Houyhnhnm

Houyhnhnm - Weblio 英和・和英辞典

Houyhnhnm: フーイナム

GitHub の主流はハイフンつなぎだけど Swift のライブラリは UpperCamelCase が多かったけど

7:15 AM

https://swift.org/package-manager/

Swift.org

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

Houyhnhnm 音節Hou・yhn・hnm 発音記号/hwínəm｜húːɪ‐/ 名詞可算名詞 フーイナム 《Swift 作 Gulliver's Travels (ガリバー旅行記)の中の人間的な理性が徹底している馬; 人間の形をした Yahooを支配する》. ［馬の鳴き声からのSwiftの造語］

これのサンプルが https://github.com/apple/example-package-fisheryates なのを見て以来、やがてハイフン区切りの波に抗えなくなるんじゃないかという気がして、最近僕はハイフンばっかです。

apple/example-package-fisheryates

example-package-fisheryates - Example package for use with the Swift Package Manager

？？？？

7:16 AM

Swiftとはクイック再生プレーヤー再生ピン留め単語を追加主な意味スウィフト《1667‐1745; 英国の文人; Gulliver's Travels の作者》音節 swift 発音記号・読み方 /swíft(米国英語)/

ガリヴァー旅行記はスウィフト作

なるほどー

Swiftって名前の人いたのか

ガリバー旅行記から名前取るのオシャンティー過ぎて僕にはちょっと

@omochimetaru テイラー・スウィフトもいるでしょ？

https://github.com/apple/swift-package-manager

apple/swift-package-manager

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

7:17 AM

SPMそれじたいもハイフンですね

うん

7:17 AM

Apple がそのスタイルとってる以上、やがて抗えなくなると思うんよね

7:18 AM

パッケージ名は UpperCamel 、リポジトリ名はハイフンかなぁと。でも、ディレクトリは UpperCamel にしとかないと、 swift package init したときに面倒

ローカルではUpperCamelで作ってリポジトリはハイフンつなぎが一番楽そう

コマンド引数で渡せたら楽なのにとは思いますね

ですねー。渡せないですよね？何かあるのかなと思ってたんですが見つけられず。

$ swift package init --help OVERVIEW: Initialize a new package OPTIONS: --type empty|library|executable|system-module

ここの文化的な不整合、Apple製APIがchain-caseなのにCodableでスッとできないのは草っていう話題

enum絡むライブラリ作ったら名前これにしようと思ってたフーイナム《Swift 作 Gulliver's Travels (ガリバー旅行記)の中の人間的な理性が徹底している馬; 人間の形をした Yahooを支配する》.

これは Swift 絡みなのはいいとして、なんで enum なの？

7:21 AM

chain-case って言うんだ。

発音から。ネイティブだったらどう発音するのかわかんないですが

ああ、そういうことか < 発音

https://github.com/apple/swift-package-manager/blob/master/Sources/Workspace/InitPackage.swift#L55-L58 現状はディレクトリ名になっちゃいますね。

apple/swift-package-manager

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

Yahoo もガリバー由来なんだ・・・

Yahoo!の名前の由来は英語の「Yet Another Hierarchical Officious Oracle」（さらにもう一つの階層的でお節介な神託）の略だといわれている[57]。また、ファイロとヤンは自分たちのことを「ならずもの」だと考えているので、「粗野な人」という意味がある「Yahoo」（『ガリヴァー旅行記』に登場する野獣の名前が由来）という言葉を選んだと主張している[10]。さらに感嘆符が付いていることに関しては「ヤッホー！」「やったー！」を意味する英語の感動詞「yahoo」と掛けているとも考えられる。

Package.swiftでの指定はURLなのでハイフンつなぎにしといても問題ないかなぁと思っている。

別にConvertするわけじゃないからConvertibleは不適切な気がしてきた

ほんとだ・・・ < 現状はディレクトリ名

abstract-enumとかかなぁ (edited)

え？ EnumNConvertible を EnumN に convert するんじゃないんですか？

いやそれはその通りなんですが

abstract-enum 長いから abstenum とか？

7:27 AM

CustomStringConvertible とかを考えても EnumNConvertible とかならおかしくない気も。

なるほど

N がなかったらどうだろう

Nm

別にライブラリ名だし良さそう？

がちゃっと書いたけど、これgyb使ってビルド時にOption渡して任意個のEnumサポートできるようにしたいな

gyb、実行時に $ gyb -D Key=Value でパラメータ渡せるから、できるよ

おお

https://github.com/omochi/cpp-rhetoric/blob/master/src/rhetoric/optional.h https://github.com/omochi/cpp-rhetoric/blob/master/src/rhetoric/result.h

omochi/cpp-rhetoric

cpp-rhetoric - small fundamental library for modern C++ programming.

omochi/cpp-rhetoric

cpp-rhetoric - small fundamental library for modern C++ programming.

10:57 AM

OptionalとResultがEither2実装になった。

public func animatedItems<S: AnimatableSectionModelType, O: ObservableType, C0: Reusable, C1: Reusable, C2: Reusable, C3: Reusable, C4: Reusable>(for type0: C0.Type, _ type1: C1.Type, _ type2: C2.Type, _ type3: C3.Type, _ type4: C4.Type) -> (O) -> Disposable where C0: UICollectionViewCell , C1: UICollectionViewCell , C2: UICollectionViewCell , C3: UICollectionViewCell , C4: UICollectionViewCell , S.Item: Enum5Convertible , S.Item.T0 == C0.Dependency , S.Item.T1 == C1.Dependency , S.Item.T2 == C2.Dependency , S.Item.T3 == C3.Dependency , S.Item.T4 == C4.Dependency , O.E == [S] {

使う側がこんな感じの地獄じみた形相になってるから、任意個数サポートできるのはもはや必須の感じがする

ｗｗｗ

11:06 AM

https://github.com/omochi/cpp-rhetoric/blob/master/tool/run-gyb.bash

omochi/cpp-rhetoric

cpp-rhetoric - small fundamental library for modern C++ programming.

11:06 AM

指定のディレクトリ配下から *.gybを探して変換するラッパー。参考にどうぞ。

あざます

11:07 AM

これUI{Table, Collection}Viewの{Animated, Reload}DataSourceに対応しなきゃいけないから

11:07 AM

Enum5でも5x4で20個関数用意していてバカじゃないのって感じがする

要素全部型定義してるんですね

これがあると

自動生成の機運

dataSourceObservable .bind(to: tableView.rx.animatedItems(for: MyCell1.self, MyCell2.self)) .disposed(by: disposeBag)

11:12 AM

こんな感じのコードを、ちょっとだけ型定義するだけで書けるようになる

なるほど

定義側がしんどいのは自動生成でカバーできれば完全勝利だから

curry は昔ジェネリック引数14個（？）でコンパイル終わらなくなる問題がありましたが大丈夫そうですか？

1TableViewに14種類Cell使う人が居たら大丈夫じゃないかもですねw

w

ww

多分、1-14までオーバーロードさせるとそうなるんで、連番で作るのとピンポイントで作れるのを用意しておけば良い気がします

gyb環境構築微妙にハマった... --line-directive= 入れないと ###sourceLocation が各行入るからなんなのかと思った

そうですねｗ

1:13 PM

https://github.com/omochi/cpp-rhetoric/blob/master/tool/run-gyb.bash#L8

omochi/cpp-rhetoric

cpp-rhetoric - small fundamental library for modern C++ programming.

1:13 PM

わざわざ空にしないといけない

1

参考に書きました

http://moapp.hateblo.jp/entry/2017/06/30/210636

moapp

Swift gybの環境構築 - モアイはコードを書く

Swift gybの環境構築ふとSwiftのgybが気になったので環境構築を試して見ました gybとは Swift言語開発の副産物のメタプログラミングツールgybがとても良い— おもちメタル (@omochimetaru) 2017年6月30日 gybは「Generate Your Boilerplate」の略称みたいです(gyb --helpより) 具体的に何かと言うと、Swiftの公式リポジトリの中でSwiftコードの自動生成に使われているPython製のテンプレートエンジンになります gybを導入する qiita.com というわけで、こちらを参考に環境構築して見ましたまずgyb自体…

###sourceLocationというgyb側のログ？も一緒に出力されてしまうので必須で追加した方が良いです

3:39 PM

これは多分、Swiftコンパイラに対して、ソースコードの本当の位置を教えるための仕組みですね

3:40 PM

gybから生成された.swiftにおける行数を表示したところで

3:40 PM

ほんとうの意味でのソースコードは.swift.gybだから

3:40 PM

それの場所をデバッガに伝えるためのやつ

なるほど、修正しときます

typescriptとかESJSでやるsourcemapがソース自体に埋め込まれてるようなもんですね

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170626/037730.html

4:10 AM

このメールで提案されてるのってここでも何度かでた話を全く同じ提案じゃない？

4:11 AM

右辺値に説明文を書かないといけない !! オペレータ。機能は ! と同じ。

4:13 AM

never型ちゃんとやって preconditionFailure　を ?? に並べたらええってレスもついてるな

4:14 AM

スレが70投稿ぐらい伸びてて読みきれん

2017/06/28にkoherさんが #swift にそのリンクを投げて盛り上がってましたよ。

ああ話題自体がここソースだったのか

そのスレッド、僕のメールボックスでは100件になってる。

ブラウザ1ページしか見なかったので全部だとそのくらいありそうです

Swift4のCodableが内部で何をやっているか確認する by @kenmaz on @Qiita http://qiita.com/kenmaz/items/8bfd386ad4a978b6ed6d

Swift4のCodableが内部で何をやっているか確認する - Qiita

ほんの小ネタです。 Swift4から導入されるCodableですが、どういう仕組で実現されているんでしょうか。WWDCのプレゼンによるとCodableを適用すると、encode/decodeを実現するための実装をコンパイラーが生...

2:19 AM

ASTフェーズですでに自動生成コードが展開されてるってことは、ちゃんとSwiftのソースコードとしてコンパイルされてそう

あれ、Xcode9 beta3、se0110はRevokeされてるけどRxSwiftのテストケースは死屍累々のままだ

5:07 AM

Overloadとの兼ね合いで何か壊れている気がするな…

5:10 AM

理解した、クロージャがOptionalだとぶっ壊れるw

5:15 AM

struct ObservableA<T> { func subscribe(onNext:(T) -> () = { _ in }) { } } ObservableA<(Int, Int)>().subscribe(onNext: { (a, b) in // ok }) struct ObservableB<T> { func subscribe(onNext:((T) -> ())? = nil) { } } ObservableB<(Int, Int)>().subscribe(onNext: { (a, b) in // 死ーん })

Bダメなんですね、見たところ問題なさそうに見える

後でbugsに上げとこう

5:18 AM

RxSwiftはどうするかな、まだ待った方が良いか…

これって問題なのは一度型変数に入れたタプルをタプルとして解釈できないのが問題なんでしたっけ？ (edited)

タプルを複数引数に分解できないようにするのがse0110、rollbackしたけど、Optionalなクロージャは判定されてないのでse0110の影響が生きている

2

なるほど

ということだと思います、確かにse0110ロールバックのPRは、Optional考慮してなかったような気がする

5:30 AM

swiftコンパイルできる環境あればこういうの直にpr投げれるな、早く環境作ろう

[omochi@omochi-iMac bin]$ pwd /Users/omochi/work/swift-source/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/bin [omochi@omochi-iMac bin]$ ./swift --version Swift version 4.0-dev (LLVM a15decabe3, Clang 60a12bf739, Swift fcd389b17e) Target: x86_64-apple-macosx10.9

3

5:47 AM

ちょうどいまできた

どのぐらいビルドかかりました？

はやくMacPro回収しないと

本当はplaygroundでやりたいからtool-chain全部いりにしたいんだけどこの前やった結果それはとてもつらい

5:48 AM

うーん　お昼ごはんたべにいってたから

5:48 AM

12:30　〜 14:30 ぐらいかな？

あ、そんなもんなんや

もうちょっと速いかも

5:49 AM

飯に行ってたから終わった時刻が正確にわからない（飯に２時間いっていたという意味ではないｗ

ｗｗなるほど、ありがとうございます

iMac Corei7 3.6GHz / memory 16GB / SSD

1

xcode9.3betaに同梱されてるやつとswift-4.0-branchって何が違うんだろう

6:01 AM

githubでコミットの差分みたらええんか

おそらく 9 beta3 は https://github.com/apple/swift/tree/swift-4.0-branch-06-23-2017 ブランチ

apple/swift

swift - The Swift Programming Language

ありがとうございます

6:02 AM

ディスクは19Gつかった

6:02 AM

これtimemachineはずしとこ

6:04 AM

https://github.com/apple/swift/compare/swift-4.0-branch-06-23-2017...fcd389b17e

apple/swift

swift - The Swift Programming Language

6:04 AM

ちょうどrintaroさんのコミットからだｗ

そうか、Xcode 9 beta 3はCodableの実装がまだ古いのか。

1

例のOptionalですかね

これの変更が入ってないです https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037672.html

https://github.com/apple/swift/pull/10881 Optionalのclosureでtupleが分解できない問題治してもらえた。はやいw (edited)

[Constraint system] Improve SE-0110 exception by allowing optional in… by rudkx · Pull Request #10881 · apple/swift

…jection. There was an oversight in the exception that was added to SE-0110 to maintain compatibility for closure arguments. We were not allowing optional injection to happen for the closure being ...

4

なんかbugs.swift.orgのチケットのステータス、今どうなってるのか不明でレポートしてもそれが解決したのかわかりにくいw

6:08 AM

昨日報告したこれ https://bugs.swift.org/browse/SR-5433 は、もうPRがマージされてて見た感じ解決済みなんだけど、チケットは相変わらず未解決だし。

ひそかに（？） @rintaro さんの第二弾が投稿されてる。前回のと合わせてビルドしてテストできるようになるので、これに従えば swift リポジトリに PR 出せそう。 http://qiita.com/rintaro/items/2f84776cf1629150b312

Swiftコンパイラのテスト環境 - Qiita

この記事は、 Swift.org のオープンソース Swift の開発に参加してみたい方のためのものです。普通にSwiftでアプリの開発をするのにはまったく役立たない知識です。 Swift コンパイラのテスト環境は普通のプロジェクト...

1

Twitterでpublishしてたからひっそりではないですねw

お、 Twitter みてませんでした

XCTestにXFAIL欲しい

9:11 AM

litはテキストファイルならなんでも良いので、.mdにテストを書いたりできるのが面白いと思った。 https://github.com/apple/swift-integration-tests/blob/master/swift-package-init-exec.md

apple/swift-integration-tests

swift-integration-tests - Automated tests for validating the generated Swift snapshots behave correctly

lit.cfg で指定すればですね。 https://github.com/apple/swift-integration-tests/blob/master/lit.cfg#L56

apple/swift-integration-tests

swift-integration-tests - Automated tests for validating the generated Swift snapshots behave correctly

あ、そうですね。

↓なるほどー、改行をエスケープしたくなるのか。 https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md

apple/swift-evolution

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

XCTestといえばAssert系の関数を自前実装できるようにしてほしい。特にXCTAssertEqualWithAcuracyはフィールドごとに確認するので増えるほど書くのがきつくなる stcuct Hoge { val a: Float } let x = Hoge(a: 0) let y = Hoge(a: 0) XCTAssertEqualWithAcuracy(x, y, accuracy: 1e-10) かといって関数に切り出すとXCodeで停止地点が分かりづらくなる。 XCTAsserEqualはEquatableを実装するだけで使えるので同様にNealyEquatableみたいなプロトコルを切ってXCTestがそれを使うXCTAssertEqualWithAcuracyを用意してくれるのがベストかな。

XCTestを捨てたら良いのでは

1:47 AM

その問題はXCTestとか昔のJUnitとかのテストフレームワークがずっと抱えてきた問題で

1:47 AM

最近のだとそういうオペレータをユーザ定義できるのが主流だと思う

なるほど。といってswiftの場合swift testとかで結構密接に結びついてるのでこちらからどうこうもしにくい気が。

1:48 AM

XCTest上で動く別のテストフレームワークを用意する？とかができるのかな

詳しくは知らないけど誰かが知ってそう・・・

Carthage は Quick が使われてそう。 https://github.com/Carthage/Carthage/blob/master/Package.swift#L28-L29

Carthage/Carthage

Carthage - A simple, decentralized dependency manager for Cocoa

1:53 AM

あ、 Carthage を SwiftPM でビルドする話。

かといって関数に切り出すとXCodeで停止地点が分かりづらくなる。 切り出した関数に…file: StaticString = #file, line: UInt = #line)とかつけると良いのでは。

それでもいいですけど標準だと視覚的にぱっとわかりますからね……

QuickSpec が（間接的に） XCTestCase を継承してるのか。 https://github.com/Quick/Quick/blob/cd89737d3d5306124e91c357b66cde274a3269b4/Sources/Quick/QuickSpec.swift#L13

Quick/Quick

Quick - The Swift (and Objective-C) testing framework.

どうやってXCode上で色々出来てるんだろうと思ったらXCTestにつながってるわけですか。 swift testもできるのかな？

そりゃ継承してるんだからできるんじゃない？< swift test

個人的な意見としては、SwiftPMを使うならQuickとNimbleは使いたくないな。

お

carthageのPackage.swiftはdependenciesがなんか複雑になってますね……

なんかトレンドとかあったらしりたいです

テストのときだけ Quick を使いたいからじゃない？ < 複雑

そうですね。 https://github.com/Carthage/Carthage/blob/master/Package.swift#L4-L6 このへん何なんだろうってなる

Carthage/Carthage

Carthage - A simple, decentralized dependency manager for Cocoa

1:59 AM

ただの環境変数か

Obj-C runtime でも XCTestCase を継承してる https://github.com/Quick/Quick/blob/cd89737d3d5306124e91c357b66cde274a3269b4/Sources/QuickSpecBase/include/QuickSpecBase.h#L8

Quick/Quick

Quick - The Swift (and Objective-C) testing framework.

2:01 AM

.Package.test.swiftって何？？ https://github.com/ReactiveCocoa/ReactiveSwift/pull/86/files

[SwiftPM] Remove test dependencies from Package.swift by ikesyo · Pull Request #86 · ReactiveCocoa/ReactiveSwift

We still run swift test on CI using separated .Package.test.swift. This is the same as Carthage/Commandant#83.

script: + - mv .Package.test.swift Package.swift

2:01 AM

これがあるし

2:01 AM

すり替えるんじゃないかな、自力で

Swift 3 では結局testDependenciesがなかったので、テストの時だけ使う依存を実現してる。

Currently "Test-only dependencies" feature is disabled in the Swift Package Manager. It was implemented initially, but was removed in this commit.

https://stackoverflow.com/a/41407032

Test-only Dependencies When Using the Swift Package Manager

I've seen mentions of test-only dependencies when using the Swift package manager but haven't been able to get them to work. For example: https://lists.swift.org/pipermail/swift-evolution/Week-of-...

2:03 AM

おおお、初期に testDependencies 見た気がしてたんだけど使えなくなってるのか・・・

2:04 AM

Remove testDependencies from PackageDescription This feature was supposed to support dependencies only for the root package but at some point it stopped working however the API still remained open. This patch removes the public API. This is a valid and desired feature which is supposed to come back after it goes through proper review on swift evolution.

https://github.com/apple/swift-package-manager/commit/34b7826cb586b0769ea5f60a7718d7de599ce27f

Remove testDependencies from PackageDescription · apple/swift-package-manager@34b7826

This feature was supposed to support dependencies only for the root package but at some point it stopped working however the API still remained open. This patch removes the public API. This is a va...

2:05 AM

それだと Quick とか使いたくないですね・・・。

swift evolutionのほうは誰も出して無いのかな……

テスト用のPackage.swiftを用意してたけど、環境変数で切り替えられることをikesyoさんに伝えたら使ってくれた。 (edited)

2:06 AM

Swift 4のPackage ManifestでQuick, Nimbleがどの様に使えるかは、僕は知らない。

SWIFTPM_TEST_Carthage

ああこれはSPMが定義してくれるのか。

2:07 AM

なんか若干矛盾を感じるな・・・ SPMが定義するならSPM上のSwift APIで良いのでは・・・

改めて考えると、テストって本体と別パッケージだと思うんですけど、本体用に作った Package の dependencies がテストからも使えるのなんか変な気も。

そこはテストが間接的に依存してるからいいのでは？

@koher 使えないとメソッド引数の型とかに依存ライブラリの型が使われてたらテストできなくないですか？

まあ実用面で考えるとテスト用のパッケージは本体に付随して生まれるものということでいいのかなぁ。

てか本来的には

2:10 AM

アプリターゲットとテストターゲットをわけて、テストターゲットがアプリターゲットに依存

> SWIFTPM_TEST_Carthage ああこれはSPMが定義してくれるのか。 Makefileで実行するときに設定してます。 https://github.com/Carthage/Carthage/blob/master/Makefile#L82

Carthage/Carthage

Carthage - A simple, decentralized dependency manager for Cocoa

っていう構造が自然な気がするけど

2:11 AM

Carthageの構造はあくまで Carthageパッケージがテスト用の状態に変化するっていう

2:11 AM

作りなんですね

2:11 AM

@norio_nomura ああ、なるほど、自前でタスクランナーかましてるなら納得です。最初分岐みたときそれを想像しました。

2:12 AM

環境変数で切り替えられることをikesyoさんに伝えたら使ってくれた。(

これを誤読しました。

Package.swiftがサンドボックス内で解釈される際に、SwiftPMがあえて環境変数を引き継ぐ様にしてるので、あながち間違いでもない。

2:15 AM

最初、環境変数を処理分岐に使えたのは意図せぬ挙動だったけど、サンドボックス化の際にサポートされた挙動になった、という感じ。

ふむふむ。

2:18 AM

https://github.com/apple/swift-package-manager/blob/a5d08ffca407abc4f26cddf8329ca040082f8eb0/Sources/Commands/SwiftTool.swift#L405

apple/swift-package-manager

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

2:19 AM

「サンドボックス」ってここらへんの話ですか？

そう。

$ which -a sandbox-exec /usr/bin/sandbox-exec

2:19 AM

なんかはいってた

2:20 AM

DESCRIPTION The sandbox-exec command is DEPRECATED. Developers who wish to sandbox an app should instead adopt the App Sandbox feature described in the App Sandbox Design Guide.

2:20 AM

man引いたらいきなりDEPRECATEDって書いてあったｗ

2:21 AM

macになんかあった仕組みかあ

SwiftPMのSlackでその辺りが話されてたのを読んでました。

なるほど

sandbox-execを使う様にしたコミットには環境変数がらみが特に書かれてないぽいから「環境変数をあえて渡す」というのは、チャットの中だけの話だったかも。

なるほど。

そういえば、Xcode 9のXCTestに追加されたAPIって、もうswift-corelibs-xctestに移植されたのかな？

2:38 AM

なさげ…

@norio_nomura 先程の#lineを使うってこれのことですか。 http://masilotti.com/xctest-helpers/ そもそもrecordFailureの存在を知らなくてログに行番号出るだけじゃ分かりにくいとか思っていました。

Custom Helpers in XCTest

How to extract XCTest helper methods and keep sane failure messages.

そそ。XCTAssert*()シリーズにも渡せます。

テストフレームワークが欲しいとかいうわけじゃないので僕の問題はこれで解決しそうです。ありがとうございます！

3:00 AM

XCTAssert*()シリーズに渡せるってのは何でしょう？ recordFailureがXCTestCaseのメソッドなのでXCTAssert*()のようにトップレベルのを定義するにはデフォルト引数で呼び出し元のselfを渡すとかするのかなぁと思ったのですが。

3:01 AM

以前ここで話されたデフォルト引数にselfを渡す話をよく覚えていない……

XCTAssertEqualにline引数があるんじゃ？ (edited)

ありますね。 XCTestCaseは引数にないのでどこから渡っているのか謎。別の仕組みになっているんだろうか。

XCTestCaseは関数じゃなくてクラスでは？？

recordFailureはXCTestCaseのメソッドなんですよ。で、XCTAssert*()はトップレベルなのでrecordFailureが使えない（はず）

3:08 AM

まぁ新しいのをXCTestCaseのextensionにすればいいんですが XCTAssert*()と同名を用いると例のバグ？でトップレベルのほうが見えなくなる。 (edited)

APIの外側にあるランナーが「現在のTestCase」を保持していて、XCAssertEqualは内部でそれを拾ってる気がする

SwiftLintで、SwiftLintのソースコード自体をlintしてviolationがあったらテストの失敗として記録する仕組みを作りました。そこではrecordFailure() ではなく XCTFail() を使ってました。 https://github.com/realm/SwiftLint/blob/master/Tests/SwiftLintFrameworkTests/IntegrationTests.swift#L35

realm/SwiftLint

SwiftLint - A tool to enforce Swift style and conventions.

ああ、recordFailureを使うんじゃなくて内部でfile, line指定付きのXCTAssert*()を使えってことですね。間違った方向に進んでました。

#swift の array[...]ハック、引数を@autoclosure () -> Tで表現すれば割と何でも出来るな、ということに気がついた

5:41 AM

関数である必要もなくなる

ふむ

そうするとつまり

5:44 AM

enum Foo { static var foo: Foo { fatalError() } } func bar(_ foo: @autoclosure () -> Foo, ....) { ... } bar(.foo, ....) これが可能になる

5:45 AM

何やりたいのか理解するのが非常に難しいw

5:45 AM

第一引数に与える型でオーバーロードを実現したいって話なんだけどね

Foo.foo が実際には生成されないのがポイント？

Foo.fooの評価は、bar内でfoo()をするまで実行されない。したがってbarの中で使っていなければ…というのがポイント

delegate.scrollView(scrollView, .didScroll) とかにいいかも (edited)

struct Foo {} let foo = Foo() func bar(foo: Foo, ....) { ... } bar(foo, ....) そもそもこれじゃ駄目な理由は？

グローバルfooは少なくともなし

5:49 AM

struct Foo { static var foo = Foo() } ならまあ差はそれほど無いのかもしれない。

5:49 AM

実態渡してるから都度コピー出るけど最適化で消えるんですかね

それだと .foo で書けるね

5:49 AM

そもそも0バイトの型になって消えてそう。

最適化で無になるなら、差は無いと言い切って良さそうだ

struct BarOverloads { static let foo = BarFoo() static let poo = BarPoo() } func bar(_ overload: BarFoo, ...) func bar(_ overload: BarPoo, ...) bar(.foo, ...) // できない bar(.poo, ...)

(edited)

5:52 AM

あ、だめだな

5:53 AM

うまく定義をまとめられないかとおもったけどダメだった

struct Bar { struct Foo { static let foo = Foo() } struct Poo { static let poo = Poo() } } func bar(_ overload: Bar.Foo, ...) func bar(_ overload: Bar.Poo, ...) bar(.foo, ...) bar(.poo, ...)

(edited)

5:53 AM

これならおk

なるほどｗ

朝ラトナーがメーリスに投げてましたけど、Multi-line Stringのリファイメントが始まったみたいですね。改行に \ を使う感じで。 https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md (edited)

apple/swift-evolution

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

これはうれしい気がする

これいいですよね。

いいですよね。メーリスみてても評判よさそう

swift-evolution で、↑の改行エスケープを認めると↓が思いがけないバグになるって意見が出てる。なるほど。 let s = """ ... In Windows you have paths like C:\ ... """

Windowsの民はパス文字列にバックスラッシュがあって思わぬことが起きるのに慣れてて警戒するから大丈夫

現仕様だと↑はコンパイルエラーになって \ を \\ に直さないといけないけど、新使用だとコンパイルエラーにならないから問題だと。特に """ だからといって文字列コピペしてきたときとかに問題起こりそう。

それ言い出しちゃうと c:\news とかもそうなんで。ちょっと弱い。

それはコンパイルエラーになるから直せるけど、たまたま行末に紛れてたら見過ごしそうじゃないですか？

nがにくっついて\nになるからコンパイルエラーにならないという意味では？

ああ、そういうことか。

つまり現状でもコンパイルエラーにならないが意図せず出現した \ などによって思わぬ変化は起きるのだから同じだよと

なるほど、たしかに。

Optionalのclosureでtupleが分解できない問題治してもらえた。はやいw swift-4.0-DEVELOPMENT-SNAPSHOT-2017-07-11-a以降で直ってるぽいですね。

1

WWDC の "What's New in Swift" で COW Existential Buffers について触れられてますが、 Existential じゃない普通の struct でもサイズが大きいと勝手に最適化されたりするんでしょうか？どこかで触れられてましたっけ？ https://developer.apple.com/videos/play/wwdc2017/402/

What's New in Swift - WWDC 2017 - Videos - Apple Developer

Swift 4 continues the evolution of the safe, fast, and expressive language, with better performance and new features. Learn about the new...

自分が調べた限りではstructについては大きくなってもヒープ化はされなかったですよ

1:02 PM

その話なのかはわからないですが

↑の COW Existential Buffer は Swift 4 からの話なので、新しく何かあるのかも？

あと、ヒープ化が標準で、小さい時のスタック化の方が最適化だと思う

1:03 PM

なるほど

（興味があれば）↑のビデオの15:30あたりから話してる。

興味アリアリ

https://github.com/apple/swift/pull/8909 これの話かと思ったら違った。

Code Size Reduction: Pass large loadable types by address instead of by value by shajrawi · Pull Request #8909 · apple/swift

radar rdar://problem/28680453 Reduce the size of the text area (code size of the compiled output) by changing the way we generate LLVM IR for loadable types: We do a SIL level transformation, durin...

1:23 PM

https://github.com/apple/swift/pull/9142 こっちか。大きい値型を自動的にアドレス渡しにしてコードサイズを減らそうっていう件。

Code Size: Pass large loadable types by address instead of by value - Updated Version by shajrawi · Pull Request #9142 · apple/swift

radar rdar://problem/28680453 This is an updated version of #8909 It addresses the code review comments and splits the PR into multiple commits Reduce the size of the text area (code size of the co...

1:24 PM

が実装されたんだけど、問題起きて disable されちゃいました。4.0 には入らないと思います。 https://github.com/apple/swift/pull/9452

Disable large types irgen pass by shajrawi · Pull Request #9452 · apple/swift

radar rdar://problem/32064645 Disable large types irgen pass (for now) Swift 4.0 PR #9447

1

we'll get back to this transformation at some point, making sure it is truly great, but it is not going to be re-enabled on the 4.0 branch.

1:27 PM

残念・・・。

https://teratail.com/questions/13866 ここで岸川さんが言ってる、

structは24バイトを越えるとheapに追い出されます。

とは別の話ですか?

Swiftのstructは、どのようなケースで使うと効果的ですか｜teratail

Swiftのstructはclassとよく似ているところがありますが、どのように使い分けるのでしょうか。structの性質を使った、実際の実装パターンなどありましたらご教授をお願いできればと思います。

32バイトのstructでも、スタックに置かれていることが分かります。

どんなコードを書いたらstructはヒープに置かれるんですか？また、あたなのSwiftのバージョンはいくつですか？（ちなみに上記の結果はSwift1.2です。）仮にstructがヒープに置かれた場合、CやObjective-Cとの互換性はどうなりますか？

1:29 PM

レスで反論されてるね

お、ほんとだ

俺もおかしいと思った

岸川さんの情報源は何だったのか気になる・・・

Existential に入れたときの挙動とごっちゃになったのかな？

Existentialのときはヒープ退避しますね、２４で

1:31 PM

24までは収まるから25以上で、か

そのヒープ退避されたバッファの扱いがSwift4でCOWになる？ (edited)

1:36 PM

これまでは代入の度にヒープに新しい領域確保してコピーしてたってこと？？

https://github.com/apple/swift/pulls?utf8=%E2%9C%93&q=is%3Apr%20copy-on-write%20existential%20is%3Aclosed%20

apple/swift

swift - The Swift Programming Language

僕がLLVM読んだときはそんなふうに見えた

1:37 PM

C++のstd::stringみたいな感じで。

std::string は確か COW だったけど COW 止めたんよね？

ポインタを持った外側の構造体(existential)がコピーされるときに、その参照先の実態をヒープ上で複製する

1:39 PM

そうですね。

1:39 PM

24バイトまでのSSO (Small String Optimization)っていって

1:39 PM

それは残ってる

1:40 PM

全く同じですね

マルチスレッドでリファレンスカウント操作するところで同期しないといけなくてパフォーマンス上の問題があったって聞いたんだけど、 Swift の Array 等の場合はマルチスレッドをサポートしないことで問題を回避している？？

Swiftの参照カウンタもスレッドセーフっぽかったですよ

1:41 PM

atomicなんたらとか出てきた

うーん、昔はアプリレベルだと問題ないんじゃない？と思ったけど、Swiftをあらゆる用途で使おうとすると同じ問題にひっかかりそうな気がするんだけどどういう判断なんだろう？

僕はそもそも参照カウンタ操作が遅いっていうのがあんまり信じられない

1:45 PM

atomic操作になるんで

インクリメントやデクリメントはatomicにできても

1:46 PM

COWの参照カウントチェックの部分は同期しないといけないのでは？

？

1:47 PM

インクリメントして、結果をもらうところまでがアトミックです

1:47 PM

デクリメントして0になるスレッドはひとつだけだから

1:47 PM

0かどうか観察する分岐はロックしない

Arrayの要素を変更しようとしてバッファの参照カウントを確認した結果1だったからコピーしなくていいやとなったけど、それと同時に別スレッドで代入されて参照カウントが2になったらバグらない？ (edited)

https://github.com/apple/swift/pull/7557 非アトミック版の参照カウンタを使うっていうオプションがあります。興味あれば。

おお、そんなものが・・・

ソースレイアウトが結構変わってて探し中

うーん、単に代入前に変更されたように見えるだけか？

Arrayの要素を変更しようとしてバッファの参照カウントを確認した結果1だったからコピーしなくていいやとなったけど、それと同時に別スレッドで代入されて参照カウントが2になったらバグらない？

これはデクリメントじゃなくてコピーするときの話ですよね

1:55 PM

えーっと・・・

1:55 PM

1だったときは

1:55 PM

そもそも１つのスレッドからしか参照されてないのでは

同じ変数が複数スレッドから参照されることはあるのでは？

そのためにはカウンタが2になりません？

↓のようにしても参照カウントは 1 のままじゃないの？ var a = [2, 3, 5, 7] // スレッドA a[2] = 4 print(a) // スレッドB a[3] = 8 print(a) (edited)

ちょっと僕も考えながらなので不正確かもしれないですが (edited)

1:59 PM

まずスレッドっていうのは

1:59 PM

関数ポインタと任意ポインタのペアでエントリするのが一番ローレイヤにあって

1:59 PM

Swift上で考えると

1:59 PM

startThread( closure: () -> Void )

1:59 PM

な処理を呼び出すことになって

1:59 PM

そのコードだと

2:00 PM

var a = [2, 3, 5, 7] a[2] = 4 startThread { a[3] = 8 }

2:03 PM

Swiftって参照キャプチャなんだっけ・・・

2:04 PM

func startThread(f: @escaping () -> Void) { f() } func main() { var a = [2, 3, 5] a[0] = 88 startThread { a[1] = 99 } print(a) // [88, 99, 5] } main()

今ってバッファは struct である Array に包まれてるから

2:05 PM

バッファがキャプチャされるわけではなくない？

2:06 PM

var a = 2 let foo: () -> () = { a += 1 } foo() print(a) // 3