結論

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

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

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

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

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

swift - The Swift Programming Language

2:28 PM

そう

でもそれだと、Self.Index見えるのがマズイ気が

2:28 PM

可視性汚染や

まあそこはバグってことで

2:29 PM

報告したほうがええんやろか

public protocol Collection : _Indexable, Sequence {

2:29 PM

この_Indexableか

そやね

なるほど・・・

2:29 PM

見えるけど見えない型とは。

private/internal隠してるけど隠しきれてないな

2:30 PM

これはーーー

バグなのか仕様なのかよくわからんな

バグでいいと思うけど

2:30 PM

いたずらできそう

まあねえ。

2:31 PM

あと

2:31 PM

String.UnicodeScalarView.init() は呼べるのに

2:31 PM

String.UTF8View.init()が呼べなくて

2:32 PM

これもなんなのか迷ってる

謎いな

2:32 PM

悪いことしようとしたらPlayground死んだ

extension String.UnicodeScalarView : RangeReplaceableCollection { /// Creates an empty view instance. public init()

2:34 PM

extensionで生えてた

2:34 PM

UTF8Viewには無いのはなぜなんだ〜〜

なんじゃこりゃ

2:37 PM

Reflection掘ってたらこんなのあった

2:37 PM

/// A type that explicitly supplies its own playground Quick Look. /// /// A Quick Look can be created for an instance of any type by using the /// `PlaygroundQuickLook(reflecting:)` initializer. If you are not satisfied /// with the representation supplied for your type by default, you can make it /// conform to the `CustomPlaygroundQuickLookable` protocol and provide a /// custom `PlaygroundQuickLook` instance. public protocol CustomPlaygroundQuickLookable { /// A custom playground Quick Look for this instance. /// /// If this type has value semantics, the `PlaygroundQuickLook` instance /// should be unaffected by subsequent mutations. public var customPlaygroundQuickLook: PlaygroundQuickLook { get } }

2:37 PM

楽しそう

ほ〜〜

2:38 PM

LiveViewはこの前使ったけど

2:38 PM

こっちはあれかな、１行ごとの結果とかを可視化する方

そうそう

2:38 PM

Mirror周りもなんか色々悪いことできそうな感じになってる

2:38 PM

/// A type that explicitly supplies its own mirror. /// /// You can create a mirror for any type using the `Mirror(reflect:)` /// initializer, but if you are not satisfied with the mirror supplied for /// your type by default, you can make it conform to `CustomReflectable` and /// return a custom `Mirror` instance. public protocol CustomReflectable { /// The custom mirror for this instance. /// /// If this type has value semantics, the mirror should be unaffected by /// subsequent mutations of the instance. public var customMirror: Mirror { get } } /// A type that explicitly supplies its own mirror, but whose /// descendant classes are not represented in the mirror unless they /// also override `customMirror`. public protocol CustomLeafReflectable : CustomReflectable { }

numswチームに共有しとこ

ObjectIdentifierっていうAnyからHash取れる構造も見つけた

2:40 PM

やっぱリフレクション最高やで!

2:40 PM

おもちゃ箱や

Hashってハッシュ値？それとも辞書のこと？

public struct ObjectIdentifier : Hashable {

2:41 PM

Anyからinitできる

2:41 PM

ああ違う

2:41 PM

AnyObjectとAny.Typeだ

まあAnyObject行けるなら事実上いけるか

同一性の抽象化か

でもBoxになるやろうからあんまり使えないかな

In Swift, only class instances and metatypes have unique identities. There is no notion of identity for structs, enums, functions, or tuples.

2:42 PM

かいてあるね。

だよなー

あ〜〜そうか、これが必要なのって

2:43 PM

== じゃなくて === ベースでDictionaryのキーにしたいときに

2:43 PM

[ObjectIdentifier: Hoge] こうすんのか

できるね

2:49 PM

しかしCollectionからIndex消えてるのよろしくないな

前は見えたよねえ。

不可視のtypealias/associatedtypeはどう考えてもやばい

splitメソッド、Foundationに合わせてcomponentsの方がいいんだろうか・・・

2:50 PM

なんかstdlibのジェネリクスは前からワケワカメすぎて、ヤバさがよくわからない

いや

2:50 PM

Collection参照した時に

2:50 PM

subscript(index:Self.Index)って書いてあって

うん

前は飛んでいったらIntが見つかるからああまあIntやねって感じ

そうなんよね

今はそも飛べない

あ〜ｗ

2:51 PM

たしかに。

2:51 PM

昔はそこでとべたな確かに。

/// Supply the default "slicing" `subscript` for `BidirectionalCollection` /// models that accept the default associated `SubSequence`, /// `BidirectionalSlice<Self>`. extension BidirectionalCollection where Self.SubSequence == BidirectionalSlice<Self>, Self.SubSequence.Index == Self.Index, Self.SubSequence.IndexDistance == Self.IndexDistance, Self.SubSequence.Indices == DefaultBidirectionalIndices<BidirectionalSlice<Self>>, Self.SubSequence.Iterator == IndexingIterator<BidirectionalSlice<Self>>, Self.SubSequence.SubSequence == BidirectionalSlice<Self>, Self.SubSequence._Element == Self._Element, Self.SubSequence.Indices.Index == Self.Index, Self.SubSequence.Indices.IndexDistance == Int, Self.SubSequence.Indices.Iterator == IndexingIterator<DefaultBidirectionalIndices<BidirectionalSlice<Self>>>, Self.SubSequence.Indices.SubSequence == DefaultBidirectionalIndices<BidirectionalSlice<Self>>, Self.SubSequence.Indices._Element == Self.Index, Self.SubSequence.Iterator.Element == Self._Element, Self.SubSequence.SubSequence.Index == Self.Index, Self.SubSequence.SubSequence.Iterator == IndexingIterator<BidirectionalSlice<Self>>, Self.SubSequence.SubSequence.SubSequence == BidirectionalSlice<Self>, Self.SubSequence.SubSequence._Element == Self._Element, Self.SubSequence.Indices.IndexDistance.IntegerLiteralType == Int, Self.SubSequence.Indices.IndexDistance.Stride == Int, Self.SubSequence.Indices.IndexDistance._DisabledRangeIndex == Int._DisabledRangeIndex, Self.SubSequence.Indices.Iterator.Element == Self.Index, Self.SubSequence.SubSequence.Iterator.Element == Self._Element, Self.SubSequence.Indices.IndexDistance.Stride.IntegerLiteralType == Int { public subscript(bounds: Range<Self.Index>) -> BidirectionalSlice<Self> { get } }

3:46 PM

あたまおかC

4> for (i, c) in "a\r\nb".characters.enumerated() { 5. print("[\(i)] \(c)") 6. } [0] a [1] [2] b CR + LFは書記素クラスタとして1つに結合するらしい

この前のpinファイルと絡むネタです https://www.slideshare.net/mobile/teppeis/do-you-commit-yarnlock

読んでみました。20ページの「ユーザーは？」のところがよくわからない

先週のString.compontentsの話

うん

スタック見るの忘れてたからチェックしたら

2:35 AM

一応Stringに生えているみたいだった

あ〜

libswiftFoundation.dylib`(extension in Foundation):Swift.String.components (separatedBy : Swift.String) -> Swift.Array<Swift.String>:

Foundationの中でextensionが生えてるだけか

2:35 AM

じゃあNSStringへの変換はやってないけど中で同じ実装は呼んでる (edited)

そうそう

なるほど

 0x1032ae46b <+43>: callq 0x103326aaa ; symbol stub for: Swift.String._bridgeToObjectiveCImpl () -> Swift.AnyObject 0x1032ae470 <+48>: movq %rax, %r15 0x1032ae473 <+51>: movq %rbx, %rdi 0x1032ae476 <+54>: callq 0x10332706e ; symbol stub for: swift_unknownRetain 0x1032ae47b <+59>: movq %r12, %rdi 0x1032ae47e <+62>: movq %r14, %rsi 0x1032ae481 <+65>: movq %rbx, -0x38(%rbp) 0x1032ae485 <+69>: movq %rbx, %rdx 0x1032ae488 <+72>: callq 0x103326aaa ; symbol stub for: Swift.String._bridgeToObjectiveCImpl () -> Swift.AnyObject 0x1032ae48d <+77>: movq %rax, %r12 0x1032ae490 <+80>: movq 0x97881(%rip), %rsi ; "componentsSeparatedByString:" 0x1032ae497 <+87>: movq %r15, %rdi 0x1032ae49a <+90>: movq %r12, %rdx 0x1032ae49d <+93>: callq 0x103326f00 ; symbol stub for: objc_msgSend

それなら素直だな

2:36 AM

そのまんまなシンボルだ

最後にobjc_msgSend

ひえっ

そこからimplに流入してる

+80でレシーバ名リテラルをｗ

2:36 AM

可読性が高いアセンブリだ(?)

String.componentsの、下の方見るとswift_rt_swift_dynamicCastClassとかあったりして

2:37 AM

なるほどーという感じ

2:39 AM

StringからNSStringのキャストと、NSArrayからArray<String>を持ってる

2:39 AM

String.componentsが見えない、参照できないのは

2:40 AM

Collectionにおける不可視のIndexと似た何かな?と思った

たしかにCmd+CLickでfoundationのトップが開いて

2:41 AM

シグネチャにとべないから

2:41 AM

変な事が起きてると感じてたけど

2:41 AM

飛べるはずのものが飛べない現象が他にもあるから

2:41 AM

これだけじゃなんとも言えないんだなあ

あ

2:42 AM

Foundationに何回か飛んだら見つけたわ

2:42 AM

import FoundationでFoundtationに飛んで、その中にあるimport Foundationからもう一回飛ぶと

2:42 AM

全部見えるようになった

ほんとだ！！

2:43 AM

なんだこれｗ

カラクリだなぁ

2:43 AM

わからんよこんなの

めちゃめちゃ定義されとる

2:43 AM

２回飛ぶの

2:43 AM

覚えておこう

2:44 AM

あ、そもそも

2:44 AM

import Foundationの文から飛べば見えるわ

2:44 AM

メソッドのところからだと見えないバージョンの画面になる

ひどい

(rintaroさんが知見を入力してる気配がする

オーバーレイで定義されているメソッドに直行できないっていう単なる Xcode のバグなのかなと思っただけです。

2:48 AM

https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSStringAPI.swift#L395-L397

http://twitter.com/hiragram/status/848800253327196160

swift - The Swift Programming Language

直行できないだけじゃなくて、定義が無い空っぽ？のヘッダ空間みたいなものが出てくるんですよね

これですけど、やってることは (self as NSString).components(separatedBy: separator)

おおー

2:49 AM

_nsが生えてる

extension String { //===--- Bridging Helpers -----------------------------------------------===// //===--------------------------------------------------------------------===// /// The corresponding `NSString` - a convenience for bridging code. var _ns: NSString { return self as NSString }

(edited)

2:49 AM

なるほど

Xcode で飛んだときに上部に Foundation > String っていうパスが出ますけど、そんなものは無いと。

あ〜なるほど

2:53 AM

この何もない画面は Foundation/String で

2:53 AM

いろいろ出てるやつは Foundation だから

2:53 AM

import Foundationから飛ぶと出てくるんですね　理解した

2:54 AM

てことは単純にクリックした時に本当は Foundation の中の extension String に行くべきところが、 Foundation/String なページに飛ぼうとするところがバグっぽいですね。

Xcode か SourceKit のバグですね。

@hiragram もしもし

@omochimetaru もち

@hiragram

@tarunon それは確かに。ちょっと極端すぎる例だった。

7:32 AM

この話題最近俺も考えてた

7:32 AM

思うのは

https://twitter.com/tarunon/status/848799292101869568　これね

うん

7:33 AM

APIに応じてフィールドが欠損したりする方と

7:33 AM

画面に表示するデータ構造をモデル化する方の型は

7:33 AM

別にせざるを得ないと思うんだよね

7:33 AM

扱ってるものが違うから

うん

元々の意味でのViewModelかな

そうだね、表示系の方はまさにViewModelかも。

APIを扱うRepository層としてのエンドポイントのモデルと、アプリ内のデータ基盤としてのモデルがありそう

同意

7:35 AM

たぶん現在のSwiftの型システムでは

7:35 AM

現実のユースケースに対応しきれていない問題でもあると思ってて

7:35 AM

本当は欲しいのは

7:36 AM

一通りのキーが定義された型に対して

7:36 AM

静的に選択された一部のキーだけを持った

7:36 AM

部分構造型とでもいえばいいのかなあ

7:36 AM

そういうものが簡単な記法で生成できないと

7:37 AM

常に冗長なキーだらけの型で共通化したコードになっちゃう

7:38 AM

たとえば CommentListResponseの中の Comment.Userは名前しか持たないんだけど、そういう名前しかもたないNameOnlyUserに対して、完全なUserは User is NameOnlyUser な互換性がないといけない

User型がエンドポイント毎に違って辛いのは

7:38 AM

User型単体ならそれほどでもないけど

プロトコルでシコシコ頑張ればできそうだけど記述量が多すぎる

例えばTweet型にUser型が含まれる時に

7:38 AM

SearchとHomeTimeLineでUserの型が違うけどTweet型のプロパティは同じとかな

7:38 AM

そういうウンコみたいな状況が普通に発生し得る

うんうん。

7:39 AM

現状だと同じ部分について重複して書いた上で相互の変換メソッドを書き下す

7:39 AM

みたいになってしんどくなって

7:39 AM

ボトムタイプを作って逃げてしまう

現状だと同じ部分について重複して書いた上で相互の変換メソッドを書き下す

それやってる　つらい

ことになる

Tweet<U: User>は有りなんじゃねーかなーとか

7:39 AM

考えたけどなぁ

7:40 AM

何れにしてもprotocol使ってHimotoki/Argoのアプローチだと

7:40 AM

重複したデコード処理書かなきゃいけなくなって辛い

Himotokiライクなデコーダは、例外的な事が起こらない時は機械生成可能だから

7:40 AM

それはそれでほしいよね

7:40 AM

Himotokiの、最もお行儀が良いスタンダードなパターンのdecodeメソッドについては手書きしたくない (edited)

7:45 AM

@hiragram ところでその、あるかないか未取得かの型は

はい

enum NullableResponseField<T> { case .some(T) case .null case .notProvided } enum NonnullResponseField<T> { case .some(T) case .notProvided }

とかやるか、 Optional<Optional<T>> とするしか無さそう (edited)

そうそう

で、この2つを使ってフィールドを埋めまくった

そこまでは発想できた

二重Optionalは可読性が著しく下がりそう

struct UserResponse { var name: NonnullResponseField<String> var bio: NullableREsponseField<String> }

二重optionalはやりたくないなあ

とかやって

extension NonnullResponseField { var asOptional: E?? } ならまぁ。

protocol PartialResponseType { associatedtype ConcreteType } 的な何かで、 User と UserResponse を紐付けておくとなんか嬉しいところがあるかも・・・？ (edited)

7:49 AM

ぐらいのところまでで考え中

そうそう　大体そんな感じのことを考えていて、 NullableResponseField に当たる、Optionalみたいなパシッとした名前ないかなあというのが最初のツイート

7:50 AM

たるのん氏からAmbiguous案をもらったけど、若干エラーっぽい雰囲気があるのでもうちょっと他のないかなってかんじ

APIに依存した話だからOptionalみたいにセントラルな名前じゃなくて良い気がするなあ

Optional<T> は T? みたいなシンタックスシュガーがあるけどこれから作るやつは無いからごちゃごちゃ長い名前を書きたくない　というのがあった

なるほど。

型シンタックスシュガー任意に作りてーと思ったけどあったらあったで混沌化しそう

使うファイルでだけ typealias K<T> = NulableResponseFiled<T> みたいな手はあるけどね

シンタックスシュガー欲しい気持ちはあんまりないなあ　混沌化しそうわかる

7:53 AM

なぜK

Key

なる

Absentable<T>

7:56 AM

Optionalの類義語探すだけになりそう。なんか有名なパターンとかないんかねえ。

Optionalの類義語探すだけになりそう

そうなのよｗ

まあ、大事なのはその類義語に特別な意味を付与したってことをREADMEに書いておくことだから・・・

エンドポイントによって型が違うのどーすんの問題にみんな悩んでいるということで安心した

サーバーサイドをしばいてAPIを作り直させるというひどい方法もあります

Optionalだけ ? があってズルいっていうのはさもありなんだなあ

Unbox使ってますがエンドポイントで変わりそうな箇所は全部雑にOptionalにしちゃってます

@moaible さっきのhiragramの要件では、実際に取得しなかったのか、値nullが入っているのかで、制御が変わる場面があるとのことです (edited)

なんかOptionalにtypealiasつけて

8:15 AM

Maybeでもいいけど

8:15 AM

Maybe<T?>とかしておけば

8:16 AM

可読性そこまで犠牲にせずに済むのでは?って気もした

あーそういうことですか...

optionalにtypealiasってどゆこと

面白い

typealias Maybe<T> = Optional<T>

ああなるほど

で、キーの有無についてはこれを使う

8:17 AM

まーコンパイラで制約違反を弾けないから微妙かな (edited)

8:17 AM

人間は怠惰で傲慢なので、決まりごとは守らないからコンパイラには厳しく躾けてもらう必要がある

parser側で3パターンのenum(nonnull/nullable/responsenull)で定義したResponseFieldに合わせてdecodeするような作りだといまいちです？

8:43 AM

この例と被るのか

enum NullableResponseField<T> { case .some(T) case .null case .notProvided } enum NonnullResponseField<T> { case .some(T) case .notProvided }

そうですね、あと、その3値enumの名前が悩ましいです。

Swaggerとかだとnullableの属性が3.0から追加されるらしいのと、key自体の存在はrequiredだからrequiredの対義語とかだと通じやすかったりするんですかね

8:53 AM

ってなるとoptionalなのか...一周してしまう

そうなんですよね〜

omochimetaru - 今日 午後4時55分 Absentable<T> Optionalの類義語探すだけになりそう。なんか有名なパターンとかないんかねえ。 hiragram - 今日 午後4時56分 > Optionalの類義語探すだけになりそう そうなのよｗ

やっと皆さんに追いついた感

8:58 AM

個人的には @omochimetaru さんが言ってた通りセントラルな名前じゃなくていい派ですね、用途が限定的なわけですし

APIに依存した話だからOptionalみたいにセントラルな名前じゃなくて良い気がするなあ

なるほど

アプリ全体から見るとセントラルじゃなくていいけど、モデル層を別ターゲットに切り出してるのでそこでみると結構セントラルなのではという気がしている

9:00 AM

モデル層というかAPI叩く層

レイヤー的に分けてるのであればAPIを意識した名前だと冗長なのも分かるし...うーん

セントラルかどうかは僕はけっこうどうでもいい気持ちで名付けについては

Optional<T> は T? みたいなシンタックスシュガーがあるけどこれから作るやつは無いからごちゃごちゃ長い名前を書きたくない　というのがあった

これに尽きる

9:02 AM

ところでdiscordって1メッセージに対するパーマリンクってどうやって取るの

見当たらないね＞パーマリンク

日付時刻を右クリックで取れるのが相場だろうが〜というきもちだ

確かに

うーん3値enumはダメな気がしてきた

11:01 AM

状態としては

11:01 AM

キーの有無とキーが存在する時にnullableである、という2つは独立であるはず

11:01 AM

なので、結局T??でしかない

11:01 AM

外側に名前をつけるべきなんだろう。

11:02 AM

typealiasはコンパイラ弱くなるから、型作るとしてもそれはKeyの有無を意味する型に留めるべき

11:02 AM

nullableはお前の仕事じゃねぇ

まあ理論的にはそうだよね

11:03 AM

Optionalの場合は3値で元々がNonnullの場合は2値で両方実装したりしないといけないし。

いや

11:03 AM

T??って3値だよ

11:04 AM

switch x { case .none, case .some(.none) case .some(.some) }

enum NullableResponseField<T> { case .some(T) case .null case .notProvided } enum NonnullResponseField<T> { case .some(T) case .notProvided }

11:04 AM

3値方式だと、この2つを作らないといけなくなるってこと

そうそう

11:04 AM

使いにくい、外側だけにして中身任意にしたほうが良い

クラスのプロパティの型が2重入れ子のジェネリクスになるのが微妙かなと思った

11:04 AM

ま〜でも Observable<Int?> とかも2重か

まあ見た目はNullableResponseField<T?>になるし

11:05 AM

いいんじゃね

11:07 AM

ふーむ、大体わかってきた

11:09 AM

Genericsなnested classも作れるようになったし、その気になればなんとかなるかな?

11:09 AM

暇な時にもう一回試してみよう

11:10 AM

前回はうまく行かなかった

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034902.html

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

1:44 AM

rejectされたｗｗｗｗｗ

w

今朝Elica氏の哀しみのツイット見て笑った

メーリスではみんないいねいいね言ってなかった？

Finally, the core team discussed a different potential design for “private” that admits a limited form of type-based access control within files. We will open a separate discussion thread on Swift Evolution, with the subject "Type-based ‘private’ access within a file", and are seeking further discussion there and a motivated volunteer to turn it into a new proposal for Swift 4.

1:46 AM

型ベースのファイル内アクセス制御の方式について考える事にした？

さっき流れてた　Type-based ‘private’ access within a file　はコレか

1:47 AM

typeprivateみたいなのはほしいと思ってた

あ〜

1:47 AM

ある型から見えるみたいな？

同じ型からじゃないかな

お、それは欲しい

1:47 AM

extensionからもアクセスできるのね

C++の friend 文はけっこ〜闇だったけど

struct Hoge { typeprivate var fuga: String } extension Hoge { func sayFuga() { print(fuga) } } みたいな？

それがファイルを超えてアクセス可能なのか、ライブラリ超えたらどうなるのか

これほしいとおもっていた　今までfileprivateにするしかなかったのがもにょもにょしてた

が、気になる

とりあえず突っぱねただけじゃなくてもっと考えるぞっって感じなら良さそう

within a file だから同一ファイルだけじゃないかな

ほんとだ

fileprivateだと同じファイルなら別の型からも見えてたけど、同一ファイルでかつ同じ型じゃないとみれないのがType-based ‘private’ access within a fileだとおもう

ちなさっきの引用はこのメールね>[swift-evolution-announce] [Rejected] SE-0159: Fix Private Access Levels

ああ、本スレにもそのまま書き込まれてんのか

1:50 AM

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034903.html

1:50 AM

[swift-evolution] Type-based ‘private’ access within a file

swift-evolution-announceなんてMLがあったのか(今知った)

あんまりアクセス修飾子をぽこじゃか追加しても、多くの人間は結局まともに使えないとかならないかな

Type-based ‘private’ access within a fileについてはむしろfileprivateの本来あるべき姿な気がするのでこれは歓迎

1:51 AM

むしろType-based ‘private’ access within a fileじゃなくてfileprivateじゃなきゃこまるようなシーンなくない

それはわかる

@hiragram うん、僕はアナウンスしか取ってない

名前がわかりやすくなるならそれで良い

スレの提案を読んだ

2:06 AM

 * An extension of “X” in the same file * The definition of “X”, if it occurs in the same file * A nested type (or extension thereof) of one of the above that occurs in the same file This design has a number of apparent benefits: + “private” becomes the right default for “less than whole module” visibility, and aligns well with Swift coding style that divides a type’s definition into a number of extensions. + “fileprivate” remains for existing use cases, but now it’s use it more rare, which has several advantages: + It fits well with the "progressive disclosure” philosophy behind Swift: you can use public/internal/private for a while before encountering and having to learn about “fileprivate” (note: we thought this was going to be true of SE-0025 <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>, but we were clearly wrong) + When “fileprivate” occurs, it means there’s some interesting coupling between different types in the same file. That makes fileprivate a useful alert to the reader rather than, potentially, something that we routinely use and overlook so that we can separate implementations into extensions. + “private” is more closely aligned with other programming languages that use type-based access control, which can help programmers just coming to Swift. When they reach for “private”, they’re likely to get something similar to what they expect—with a little Swift twist due to Swift’s heavy use of extensions. + Loosening the access restrictions on “private” is unlikely to break existing code.

2:08 AM

・privateは同じファイル内のエクステンションからも見えるようになる・fileprivateは元々同じファイル内で別々の型の間で可視性をつなぐためで、コードを読む人にとって注意する場所として警告するためのキーワードで、その役割は残す

妥当な感

とか書いてある

現状のコードとの互換性を壊さずより便利に、だとこれが精一杯じゃないの

で、「これだと完全なスコープprivate無くなっちゃうけど何か欲しい？」とか、意見くれやって感じ

今のprivate相当のものはほしいなあ

scopedとか追加すんの？

そこらへんは、意見をくれや〜ってのが >>1

ふむー

スレは結構伸びてるからまだわからん

2:10 AM

でもSE159の話のときみんなextensionのことばっか言ってたしだいたいこれで良さそうな気がする。個人的には。 (edited)

スコープprivateなくなっておっけーってこと？

俺的には無くて良い気がするなあ

2:11 AM

なんかそれがあると結局同じループしそう

うーむ

増えてもヒトには扱えない、かなぁ

なるべくscopedにしろ派 vs 拡張の余地を残せ派 vs 適切に考慮しろ派

2:12 AM

第一印象であってまだ深く考えられてはないです

アクセス修飾子についてあんまり深く考察してないけど↑だとなるべくscopedにしろ派かなあ

昨日のGenericsネタ、この定義で試してみました

Optional<T> は T? みたいなシンタックスシュガーがあるけどこれから作るやつは無いからごちゃごちゃ長い名前を書きたくない　というのがあった

これは解決できてないのでなんともですが ↓修正版

protocol FieldProperty { associatedtype Value } struct Field<T> { enum Requirable: FieldProperty { typealias Value = T case some(T) case notProvided } enum Nullable: FieldProperty { typealias Value = T? case some(T?) case notProvided } }

(edited)

nested使ってもっと便利に書けるかと思ったけどそんなに変わらずですね

(edited)

ザハ先生の踏んだ2つのバグやばすぎるのなー

11:11 AM

https://github.com/ReactiveX/RxSwift/issues/1171

Xcode 8.3 broke RxSwift releases · Issue #1171 · ReactiveX/RxSwi...

️ It looks like there is significant number of regressions in Swift 3.1 compiler

️ The problems occur in Release builds when optimizations are turned on. It looks like Debug versions work ok so f...

deinitやばそう

その件に絡んでた人アップルのSwiftの人だった

11:15 AM

https://mobile.twitter.com/slava_pestov

deinitもですが、NSErrorのキャストでクラッシュも相当

最適化で結構問題起きるので、ReactiveSwiftとかではReleaseでCI回してます

この間見つけた強制キャストとのコンボで確実にクラッシュさせられる

自分でも確かめた https://gist.github.com/omochi/2d6dc0d661958c9faef6e6b171369a8a

swift-compiler-leak.swift

Errorもさっき確認した

コンボw

強制キャストで死ぬの確認してないけど、多分死んでるの_bridging系だから死ぬと思う

3.1移行してるんですが3.0に上げた時より破壊的な変更な気がしてます

破壊的、仕様が変更されたではなく、unstableという意味ですか？

11:24 AM

壊れ方は書いてる型に依存しそう

主にSwiftTaskで書いてる箇所と、TableViewでenum利用してsectionとrowを分けてるところが全部ビルドエラーですね..

壊れ方は書いてる型に依存しそう

このパターンなのが否めないです (edited)

SwiftTaskはそもそも3.0対応してましたっけ

一応branchはあって､tagは切られておらずです

inamiyさんがまだ同僚だった頃に同僚だし質問できるからと採用したら、RxSwiftかReactiveCocoaに移住してねと言われた記憶

oh...

3.1からのtypealiasの件、wandboxで試してみました下記のコードで3.0.2までは動きますが、3.1-devとXcode8.3ではエラーになります

open class Hoge<T> { public typealias ErrorInfo = (error: Error?, isCancelled: Bool) var receiveError: ((ErrorInfo) -> Void)? } Hoge<String>().receiveError = { (errorInfo: Hoge.ErrorInfo) in print(errorInfo) }

3:50 PM

これは3.1でも通ります

open class Hoge<T> { public typealias ErrorInfo = (error: Error?, isCancelled: Bool) var receiveError: ((ErrorInfo) -> Void)? } Hoge<String>().receiveError = { (errorInfo: Hoge<Any>.ErrorInfo) in print(errorInfo) }

3:52 PM

型変数を定義してるスコープ内の型にアクセスする際は、アクセスする際に型変数を埋めることが3.1から必須になったってことみたいです // o Hoge<Any>.ErrorInfo // x: 3.1〜Hoge.ErrorInfoとHoge<T>.ErrorInfoは区別する Hoge.ErrorInfo (edited)

ネストしたGenerics型作れるようになったので、妥当な感

3:53 PM

前まで通ってたのが謎ではある

確かに以前の方がアクセスできてしまうのはおかしい感あります (edited)

スコープがジェネリクス型の中ならinner typeを自身の型を省略して書ける。typealiasの宣言場所がprotocolなら、自身の型を書かなければいけないが、型パラメーターは省略可能、スコープが外なら型パラメーター含め全て書かないといけない

4:14 PM

こんな感じだったはず

起きたら治ってた https://twitter.com/slava_pestov/status/849370397825011713

@slava_pestov

Slava Pestov

@omochimetaru @KrunoslavZaher @juliobailon Looks like Erik from the optimizer team just fixed it: https://t.co/oUFgxzYCE0

リリース待ちか

こんなスピード感あると思ってなかった

またファイルを分けるとコンパイルが通らなくなるバグを踏んでしまった

またｗ

protocol extensionをファイル毎に分割して生やしまくると死ぬっぽい

11:58 AM

最小ケース探しの時間だ…

12:02 PM

https://github.com/tarunon/Instantiate/tree/feature/environmentable

tarunon/Instantiate

Instantiate - Type-safe Interface Builder protocols.

12:02 PM

InstantiateTestsResourceをビルドすると再現できる。電車に間に合わなくなる前に会社でよ

これもコンパイル順っぽいですね…

4:00 PM

つら

昨日の、associatedtypeにTupleを与えてるのがどうも良くなかったらしく

12:02 AM

GenericsなTuple2を作って入れ替えたら素直に動くようになった

12:03 AM

Tupleを使ってるとPlaygroundも動いたり動かなかったりで、まだ調べないといけない。結論出たらまた貼り付けます。

1

良さそうなプロポーザルがガシガシ来てる

なんか今朝めっちゃ賑やかだった

7本？一体何が起こったんだ・・・

昨日の夜と今日起きてからで半々ぐらいに別れた

1:06 AM

あっちでは1日かな？

たぶんね。

1:07 AM

まだ一日終わってないと思う。

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

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

最近 struct に indirect なプロパティほしいなぁと思ってるんだけどどうでしょう？

プロパティがインダイレクトってどういうことです？

1:09 AM

型定義のときに使うやつ？

1:09 AM

enumとかで。

struct Hoge { let a : Hoge } ↑できない

あー

@tarunon そうそれ。

Box挟めばいいけど

enum は indirect の導入で解決された

いや、それできちゃまずくない？

1:10 AM

enumは、caseによってループが終端するけど

どういうシーンでほしいのか気になりますね

structだとループから抜けられない

あー、 Optional じゃないといけないかも。

1:11 AM

あれ？ Optional だと入れられるのか

indirectは実装が参照なだけで、実際にはヌルにならないから。

なんか最近これが出来なくて困ったことがあって

1:11 AM

なんだったかな

うん、僕も困ったことが最近あって

Optionalならそもそも普通に書ける気が

エンドレスにはなってなかったはず

Optionalなら書けそう

SwiftScriptのASTで再帰的な構造が出てきて

1:12 AM

コンパイルエラーになって気づいたから

1:12 AM

何かできないことがあったはず。

1:12 AM

で、そのときは enum に逃がして解決したはず。

1:12 AM

ちょっと今時間ないので後で調べてみます。

https://github.com/apple/swift/blob/master/docs/SIL.rst#id20

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

1:13 AM

これは例の0025の続きだな

いやOptionalでも無理では

 1> struct Foo { 2. var bar: Int 3. var foo: Foo? 4. } error: repl.swift:1:8: error: value type 'Foo' cannot have a stored property that references itself struct Foo { ^

1:13 AM

ああそうか

そう、Optionalで無理だから困ってた

Optional は indirect じゃないからだ。

1:14 AM

indirect な Optional を作れば解決するのか。

そのfooにindirectをつけたいということか

indirect enum IndirectOptional<T> { case some(T) case none } struct T { let i: Int let a: IndirectOptional<T> }

1:15 AM

OK っぽい

お

やっぱり

1:15 AM

ユーザー定義型構築演算子が

1:16 AM

ほしいね。

そうなっちゃいますね

ww

それか素Optionalが初めからindirectで、良いんじゃないって気がしたけど

1:16 AM

コンパイラの負荷が増大するかな

うん、何がよくないのか今考えてました

それだと効率が悪い

1:17 AM

ペイロードがスタックに置けなくなる

Optional で包んだ時点でヒープにいっちゃうのか

あれ、よくわかってないんですが、Optionalがindirectじゃないって、じゃあなんで Hoge?? が書けるんですかね

Optional<Optional<Hoge>>は別にループしてない

それはHogeがループしてるわけじゃないから

あ、そうか

Tがループする場合がindirectが要る

理解です

うーん

1:20 AM

IndirectOptional、普通に筋が悪い

やっぱ↓みたいに書きたいなぁ。 struct Foo { var bar: Int indirect var foo: Foo? }

indirect enum Foo { case Tail(int: Int, str: String) case Head(int: Int, str: String, foo: Foo) var int: Int { // switch書く } var str: String { // switch書く } var foo: Foo? { // switch書く } init(int: Int, str: String, foo: Foo?) { if let foo = foo { self = .Head(int: int, str: str, foo: foo) } else { self = .Tail(int: int, str: str) } } }

1:22 AM

Foo使う人にとってはこれが一番使いやすいな

1:22 AM

Fooを書く人は犠牲になってもらおう

なるほど。

indirect var x : T? で良いと思う

あればねw

同じこと書きたくないし。

待ってる間、どう書くかを考えていて、IndirectOptional追加するのは

1:24 AM

使う側はしんどいなーと

でも struct Foo { var bar: Int indirect var foo: Foo } はできないわけだし、ちょっとややこしそうだな。

なるる

まあ、 enum の indirect も同程度の理解を要求されるしいいのか？

1:25 AM

swift-evolution に投げてみてもおもしろいかも？

indirect enum IndirectOptional<T> { case some(T) case none init(_ value: T?) { switch value { case .some(let t): self = .some(t) case .none: self = .none } } } extension IndirectOptional { var asOptional: T? { switch self { case .some(let t): return .some(t) case .none: return .none } } } struct T { var i: Int private var _a: IndirectOptional<T> init(i: Int, a: T?) { self.i = i self._a = IndirectOptional(a) } var a: T? { set { _a = IndirectOptional(newValue) } get { return _a.asOptional } } }

使う側も書く側も楽に出来た気がする。

1:30 AM

やっぱスッと書きたいですね

Haskell とかだと問題にならない再帰的構造を作るときにひっかかっちゃうのは微妙ですね。

1:32 AM

Swift が値型で完結できる範囲を広げるには、やっぱり indirect プロパティほしいなぁ。

1:33 AM

enum も昔は参照で Box してたけど indirect で解決されたわけだから、 struct でだけ Box が必要って今の状況は変な気がする。

今ってindirectってプロパティじゃなくてenumの頭に付けてるんですよね？

case にも付けられます。

なるほど

enum IndirectOptional<Wrapped> { case none indirect case some(Wrapped) }

1:35 AM

↑のノリでプロパティにも indirect 付けたい。

今多分できてない理由の推測で

1:35 AM

indirectついたら、それは常にindirectなんじゃないかな

1:35 AM

おそらく、 indirect var a: Int? と var b: Int? があるときに (edited)

1:36 AM

a と b のメモリ上でのレイアウトが違っちゃって、 Int? に2種類のレイアウトがあることになるから

1:36 AM

うまいこと変換処理を挟まないといけないからとりあえず今は無いって木がする

ん？？ a だけアドレスになんじゃないの？

そのaを

1:37 AM

func f(x: Int?) に渡す時に

1:37 AM

あ、でも今もコピーしてるから同じか？

struct Foo { var bar: Int indirect var foo: Foo? } のサイズは 64 bit 環境だと 16 バイト

1:37 AM

という想定。

いや、Fooのサイズは1種類だと思います。

1:38 AM

全然別の所で書かれた var xx: Foo? は

1:38 AM

ポインタになってないって話し

Foo? は 17 バイトでしょ？？

1:38 AM

Foo は値型で、 Foo が 16 バイトだから。

Foo.fooとxxで受け渡しするときに

1:38 AM

ポインタ型からOptionalへの変換が必要で

1:38 AM

これはまだない、ということ？

そう

1:39 AM

indirect Int? と Int? の2つがあることを前提にコンパイラを修正しないといけない

それって indirect case から値を取り出すときと何が違うの？

enumに関するindirectの場合は、「ついてない場合」を考えてない

1:39 AM

のではないかという推測

1:39 AM

常にBox型で取り回されてる

indirect プロパティも「ついてない場合」なんてないのでは？？

だから、単純に、indirectついてる場合をクラスと同じようにコンパイルするように切り替えるだけで良かった

1:41 AM

indirectプロパティは

1:41 AM

xxのような場合についてない。

1:41 AM

型に付いてるのではなく、プロパティについてるから (edited)

1:41 AM

型としては2種類ありえることになる

indirect var foo: Foo? を var foo: Box<Foo?> と読み替えるのでは？

1:42 AM

問題に鳴るのは

indirectが書かれたpropertyを持ってる型はクラスと同じようにコンパイルする、とかだと上手くいくのかな

値を変更するときだと思う。

1:42 AM

enum だと変更できない。

1:43 AM

いや、いいのか？取り出すときにコピーしてれば問題にならないか？

読み替えるついでに、Javaでいうところの AutoBoxingとAutoUnboxingの挿入が必要

Box が取り回されるだけで。

enumにindirectを導入する際にはそのような修正は必要なかったけど

1:43 AM

プロパティにつける場合には必要になるから

enum でもパターンマッチして取り出す時にアンボクシングしてるのでは？

実装の手間が違うから、とりあえずやらなかったんんじゃないか、という推測

1:44 AM

それは別に

1:44 AM

クラスからフィールド読むのと同じ

indirect は enum 全体が indirect されるわけじゃなくて、あくまで個別 case が indirect されるだけでしょ？ (edited)

だからその個別のcaseが参照型だったと

1:45 AM

解釈できます

1:45 AM

でもそれは

1:45 AM

そのcaseは常にindirectだから

caseに付けるときと、enumに付けるときとでバイナリに差が生まれるのか気になった

だから、 struct でも個別のプロパティが Box だったと解釈すればいいんじゃないの？

そのcaseのindirectじゃないバージョンを考慮する必要がない

プロパティの indirect じゃないバージョンも考慮する必要がないよ。

ありますよ

1:46 AM

だって Int? は実在してるから。 (edited)

1:46 AM

Fooの中で indirect Int? であっても、一般のInt?はそれとは別に存在する

1:46 AM

この2つは区別されて、適宜変換が必要

だから、適宜変換が必要なのは enum の case も同じなんじゃないの？

いいえ

1:47 AM

caseは

1:47 AM

常にindirect

enum に入れるときにはボクシングするし

それはassociated valueの話で

だって、 enum そのものが indirect されてるわけじゃなくて

associated valueの話しはstructの中のフィールドの話し

あくまで個別の case が indirect なだけだから。

おもち君の言ってるのはassociatedvalueでkoher氏が言ってるのはenum型そのものやな

enum Foo<T, U> { case bar(T) indirect case baz(U) }

1:48 AM

↑ U だけ Box になる。

1:48 AM

enum Foo<T, U> { case bar(T) case baz(Box) } ↑と等価。 (edited)

enumはcaseから取り出すときにautounboxingを挟み込む余地があったから、楽だったのでは？

うーん、それって struct のプロパティから値を取り出すときとそんな違いがありますか？ indirect なプロパティなら unboxing すればいいだけな気が。

1:50 AM

ちょっと、昼までにやらなきゃいけない作業があるので離脱します・・・

enum-caseの場合は baz が indirectだからうんぬんってことを気にすればいいのが明示的に記述される switch-caseでの分解の時だけってのが大きな違いだと思うって事

enum Foo { indirect case bar(int: Int, str: String, foo: Foo) } この時に、barの中身が全部Boxingされてると仮定するなら、内側のFoo単体についてはBoxに纏わる何かを考えなくて良い。従ってBoxが関わってるのは外側のFoo型でswitchなりif caseなりで一気になんとかできる。 structのpropertyとは別な印象があります。 (edited)

https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md

swift - The Swift Programming Language

1:57 AM

SIL上でだけ存在する Box型があるみたい

ン…

2:01 AM

でもswitch/if caseにBox処理入ってるのと,property { set get }にBox処理入ってるのそんなに違わない気がしてきたぞ

値型のプロパティアクセスって、

2:04 AM

house.cat.name = "tama" みたいなときのgetter/setterの差し込み , didSet等が無ければその省略

2:04 AM

とかあるから、ややこしそうな気がする

2:04 AM

常にcomputed property扱いにコンパイルしちゃえば同じ気がするね

それで良い気がする

http://qiita.com/omochimetaru/items/64b073c5d6bcf1bbbf99

swift - The Swift Programming Language

2:08 AM

メモリ周りの強化が入った時に

2:08 AM

プロパティの参照を取るってことができるようになりそうな気がしてて

お…

その場合に、stored propertyとcomputed propertyで結構変わってきそう

2:09 AM

Rustの真似して、ある実体に対して、shared参照が複数、もしくは、inout参照が1つ、をフロー解析的に保証するとか書いてある (edited)

2:10 AM

func ==(left: shared String, right: shared String) -> Bool { ... } これとか面白い

2:11 AM

COWモデルのおかげで現状でもかなり早いと思うけど、これが入れば引数渡しのコストがC++に肉薄する

pure funcを型レベルで保証するのってこの辺の話だっけ

それはまた別な気がする

2:16 AM

shared referenceで受けてる時は確かにそこから書き込めないから副作用が無いけど

2:16 AM

それで言うならSwiftの値型は常にコピー渡しだから普通に副作用無い

まあそれはそうか

2:19 AM

sharedって、参照で渡すけど書き込み禁止って事だよね

です

2:20 AM

mutating funcが呼べない状態やね

2:20 AM

inoutは書き込める参照。現状仕様にあるやつ。

今の何も書かない奴は、sharedと等価ではない？

2:20 AM

コピー走るからか

何も書かないやつはそもそも参照渡しじゃない

2:21 AM

値渡し（実体のコピーを伴う

2:21 AM

実体のコピーを伴うがCOWが仕込んであるからデータメモリまではコピーされないので話がややこしい。

indirect property は現状これが一番現実的だと思う

struct Foo { private var _inner: Any? = nil var inner: Foo? { get { return _inner.map { $0 as! Foo } } set { _inner = newValue } } }

(edited)

お〜なるほど

4:40 AM

get { return _inner as! Foo? } はうまくいかないんですっけ？

あ、いきますね

そっか、privateならAny?でも問題ないか

Any に Optional<T> を入れる手と Optional<Any> の Any を T にさせる手があるのかな

as!アレルギー解除していかないと

あーけどこれだとメモリ効率悪すぎるか。 Any に Any 込みの struct 入れたら絶対にヒープに入っちゃう。32バイト無駄すぎ。

5:17 AM

素直にBox作ったほうがいい気がしてきました。これなら MemoryLayout<Foo>.size == 8。

indirect enum Box<T> { case val(T) init(_ val: T) { self = .val(val) } var val: T { switch self { case .val(let val): return val } } } struct Foo { private var _inner: Box<Foo>? var inner: Foo? { get { return _inner?.val } set { _inner = newValue.map(Box.init) } } }

1

@omochimetaru 前確かめた感じだとOptional<Any>のほうが筋が良かった。

5:22 AM

でもこの場合はBoxですね

5:23 AM

case 1個のindirect enum Boxすごい、脳汁出る

おおなるほど、まさに最適だ

indirect のメモリ上の扱いの話ってどういうの見たらわかりますかね？

Swiftのメモリレイアウトを調べる - Qiita

# 導入 Swiftには値型と参照型があります。また、Optionalはそれらと組み合わせてよく使われます。メモリ上ではどのように表現されているのでしょうか。調べてみました。(Swift 3.0.2) # メモリダンプ関数メモ...

6:47 AM

↑これを真似すれば直接的なものは見れるよ

6:48 AM

あとはコンパイラを読むとかコンパイル後のLLVM-IRを読むとか。

やっぱ基本的にはそーゆーアプローチになるのか

6:48 AM

ありがとうございます

indirect enum Box<T> って class Box<T> じゃダメなんでしょうか？ class 使わずあくまで値型で済ませるならってこと？

8:54 AM

あー、

8:54 AM

書き変えのときに

8:54 AM

いや、そんなことないか

8:54 AM

Box は隠蔽するからやっぱ class でも変わらないような？

BoxEは代入文でBoxEの実体も複製されて値的に振る舞うけど (edited)

8:56 AM

BoxCは代入文がBox自体の参照コピーになって

ああ、そうか。コピーのときが問題なのか。

もともとのkoherがやりたいといった挙動と

8:56 AM

変わってる

get, set のことばっか考えてた・・・

9:01 AM

Swift 1 で indirect を class の Box で代替しても問題なかったのは、 enum がイミュータブルだからなのか。 (edited)

9:02 AM

もちろん Box そのものをいじっちゃったらダメだけど。

Swift1でもpattern matchしてBox自体をつかめば変な感じになりえますね (edited)

多分 Swift 1 にパターンマッチはなかったです。

9:04 AM

あったんだっけ？？どうやって enum の値取り出してたんだ？？

Swift1 でもパターンマッチはありましたよ。

9:44 AM

class Box でも大丈夫だと思います。Boxの中身がイミュータブルなら実用上は変わらないんじゃないかな。

あれ？あったんですね・・・。

2 で case let value? とかが追加になったくらい

てっきり 2 で追加されたと勘違いしてました。

最近ふと気がついたんだけどSwiftのデストラクタがObjCの dealloc から deinit に名前が変わっている点について

2:07 AM

弱参照が残っている限りオブジェクトのペイロードメモリは解放されないから

2:08 AM

まさに dealloc じゃなくて deinit であるなあと気がついた

それはdeallocの名前が不適切、ということ

UnsafePointer 周りの用語としても、メモリ確保はAllocation/Deallocation、確保したメモリにオブジェクトをレイアウトする/剥がしてデストラクトするのが Init / deinit って用語がちゃんと揃ってる

それとも呼ばれるタイミングがそもそも違う？

いやObjCも弱参照残っててもdealloc呼ばれるから

2:09 AM

そもそもdeallocじゃなかったわけなんだけど

2:09 AM

コレは仕方なくて

2:09 AM

iOS4以前は弱参照が無かったから

確かに確かに

deallocされるときは絶対にメモリ解放されてたんよ

言語仕様追加して名前と機能が噛み合わなくなった訳か

うんうん

こんにちは

9:31 AM

https://twitter.com/hiragram/status/851366176978382848

@hiragram

Swiftのプロトコル、Compare+ableでComparableでしょ、Equate+ableでEquatableでしょ、Stride+ableがStrideableになるのってなんでなの

9:31 AM

これ気になってるんだけどだれか答え持ってませんか

なんちゃら XXXXeable ってよく間違えられてるから間違えてるのでは

そうだよね

9:33 AM

https://technet.microsoft.com/ja-jp/library/security/dd743744.aspx

9:33 AM

MSにはStridableっていうなにがしかがある

有名なやつ https://docs.oracle.com/javase/jp/6/api/java/lang/Cloneable.html

ぶ〜

9:33 AM

すごいな

ただ、たまに、

9:34 AM

アメリカ英語とイギリス英語で答えが違うとかあるから

9:34 AM

調べてみないとわからん

そっちのほうがまだ信じられる

able-eable タグ

http://english.stackexchange.com/questions/tagged/able-eable

Newest 'able-eable' Questions

Q&A for linguists, etymologists, and serious English language enthusiasts

1

convertibleとかあるし結構何でもありなのかも

9:38 AM

英語ネイティブじゃなきゃわからんきがする

swift-lang slackで意見聞けるかな

正式な単語ではないからブレるのではという気も

入ってないや > swift-lang slack

9:39 AM

送り仮名の揺れみたいなもんだな

9:39 AM

多分

https://swift-lang.slack.com/stats

自動招待みたいなURLあったら教えて

http://swift-lang.schwa.io/

11:27 AM

https://potatotips.connpass.com/event/51176/

potatotips #39 (iOS/Android開発Tips共有会) (2017/04/13 19:00〜)

# 開催概要 potatotipsは参加者全員がTipsを発表するというコンセプトのiOS/Androidアプリ開発者向けの勉強会です（ただし、最近はオーディエンス枠があります）。今回はCyberAgent, Incさん主催での開催となります。引き続き主催をいただける会社さんを募集中です。（potatotipsの管理ページはコチラです） # 内容 ## LT * 5分 × 発表者数で２時間程度 * 途中で休憩を挟みます ## 懇親会 * LTフェーズ完了後に会場の時間の許す限り # 参加枠の種別 ## Tips発表枠 ### iOS/A...

3

RxSwiftのCompleteableは直りましたね

ものさんおるの？

スパイから写真が来ました

12:08 PM

僕は家です(　´･‿･｀)

スパイw

Completeable治ったけど、[at]available書かずにやっちゃったからざわついてた

よくみたらものさんからスパイのヒント出てたっていうね

2

SwiftのTupleは共変サポートされてないけど、クロージャの引数の型になっていればクロージャは半変サポートされているという話

12:39 AM

この間社内勉強会のえづらさんの会でたまたま気がついた

12:39 AM

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

covariance.swift

本当だw

1:07 AM

Swiftのタプル、いろいろあるべきものが足りてなくてたまに萎える

コード補完が本当に雑魚い

1:11 AM

ラベル付きタプルをtypealiasに書こうものなら、いざコードを書くときに苦しみ抜いて死ぬことになる

1

1:13 AM

仕方ないのはわかるから、再利用してinitが発生するような型パラにはTuple入れないでねってコーディング規約を最近提案した

なんか不便だから返り値とかにとどめて、配列にいれて保持したりするならstruct定義してるたぶんその規約に従うとそうなりそう

そう、返り値からメソッドチェインで次の引数になるような

1:16 AM

まさにmap/flatMapでは使うべき

1:17 AM

だけど、他の場所で宣言したものを入れる必要があるなら、struct作って、という感じ

本当にただパックしたい時だけって感じだよね

tupleにinitが生えていてそれがコード補完されるなら、この規約はいらない

1:18 AM

Aliasからinit含むfunctionが補完されるか否かの差がめちゃくちゃ大きい。tupleだと無なので死ぬ

1:19 AM

まあそういうこともあって、上ので何か便利なworkaround産めないかと朝飯食いながら考えてるが、何も思い付かないw

ジェネリックマニフェストで、タプルにエクステンション書けるようにしたい、みたいな展望が書いてあって、そこらへんの絡みで、ちゃんとした型に整備されたらいいなあ

型パラにtuple入れるの、そう言えばそれ+αでコンパイラクラッシュするんだった

1:21 AM

struct Tuple2<A,B> ← 正直これ使いたくなるwww

C#とc++はマジでそれだけど使うと悲しくなるよ

Javaもこんな感じじゃなかったっけ

1:23 AM

stdではないかな

気持ちはわかるけどそうなったらちゃんと名前つけた型つくる

そう、Tuple2はラベルが付けられないのがダメ

1:24 AM

型推論はめちゃ強くなる

あーそれもあるか→ラベル

型名は最悪typealiasでも良い

なるほど。たしかに。

Genericsな実装があるメリットは大きい、でもラベル無いのが

1:25 AM

うーん

1:25 AM

まあ素直にstruct作るのが正解だな

変性の話、↓もイケた。戻り値ならタプルも共変になる。

class Animal {} class Cat: Animal {} let cf: () -> (Cat, Cat) = { (Cat(), Cat()) } let af: () -> (Animal, Animal) = cf // エラーにならない let aa: (Animal, Animal) = af()

あ、じゃあそれを取り回せば・・・ｗ

おw

普通のタプルが共変でないのなんでなんだろう・・・

これは悪さが出来る

黒いなあ

あ、Swift 3.0の方のマシンで試してしまった。3.1未確認。

GenericsでU,T宣言してwhere U:Tが書けないから、出来ることが限られてるけど

2:25 AM

取りあえず大枠としての目標は、型消しで共変を無理矢理サポートさせるみたいな事がしたい。

2:26 AM

AnyHogeでラップしたら共編の範囲内で推論される

タプルは値型だから var だったとしても共変で問題ないはずで、そもそもできないのが謎だけど何か理由があるのかな。

あ、Swift 3.0の方のマシンで試してしまった。3.1未確認。

3.1でもイケるみたいです

@moaible 確認ありがとうございます！

ドキュメントでそれに触れてるものを見たことはないです > 理由

これは勝った

↓値型と共変

class Animal {} class Cat: Animal {} class Dog: Animal {} var cats: [Cat] = [Cat()] var animals: [Animal] = cats // ここがコピーなので animals.append(Dog()) // これができても問題ない

2:28 AM

↑このコード、参照型言語の人が見たら発狂しそうｗ

そこのコピーってどうなってんだろう　共有してんのかな

最終行でCoWで（実際の）コピーってのが理想だけど、どこでコピーが起こってるか確認したことはないなぁ。 (edited)

Swiftのclassはcovariance対応してないから

2:30 AM

Arrayのstruct部分の実Swiftコードで

2:30 AM

適切にその期待する挙動を書けない

Array を Swift で実装するならってこと？

実際そうですよね？

Array ってピュア Swift なんだっけ？違った気が。

var cats: [Cat] = [Cat()] var animals: [Animal] = cats // ここがコピーなので は _arrayForceCast() ってので実装されているので、cats.map { $0 } とほぼ同義です。 https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L30-L50

swift - The Swift Programming Language

あ、そうですね

2:36 AM

Arrayの代入は暗黙的な変換です

2:36 AM

Arrayは引数と返り値の両方でTを使っているので

おー、じゃあ先行してコピーされちゃうのかぁ。

共変はない

おお

2:37 AM

@tarunon いや、COWにおいては最初のwriteをするまではreadonlyだから本来共変で共有できる

2:37 AM

writeする瞬間に共変性が破綻するのでコピーするっていうのが理想

ふむ

2:37 AM

じゃあmapがlazyならokかな

Arrayがpure swiftだと思ってたのは勘違いだった

2:38 AM

というかソースを検索しても見当たらん

実際試してみたけど、やっぱ代入時にコピーだ・・・。

import XCTest class SwiftCovariantCopyTests: XCTestCase { func testCopyWithoutAppend1M() { measure { let cats: [Cat] = [Cat](repeating: Cat(), count: 1_000_000) let animals: [Animal] = cats XCTAssertTrue(animals.last! is Cat) } } func testCopyWithAppend1M() { measure { let cats: [Cat] = [Cat](repeating: Cat(), count: 1_000_000) var animals: [Animal] = cats animals.append(Dog()) XCTAssertTrue(animals.last! is Dog) } } func testCopyWithoutAppend10M() { measure { let cats: [Cat] = [Cat](repeating: Cat(), count: 10_000_000) let animals: [Animal] = cats XCTAssertTrue(animals.last! is Cat) } } func testCopyWithAppend10M() { measure { let cats: [Cat] = [Cat](repeating: Cat(), count: 10_000_000) var animals: [Animal] = cats animals.append(Dog()) XCTAssertTrue(animals.last! is Dog) } } } class Animal {} class Cat: Animal {} class Dog: Animal {}

Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithoutAppend1M]' passed (0.592 seconds). Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithAppend1M]' passed (0.790 seconds). Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithoutAppend10M]' passed (4.162 seconds). Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithAppend10M]' passed (6.556 seconds).

(edited)

_arrayForceCast() ってので実装されているので、cats.map { $0 } とほぼ同義です。

なので当たり前だけど。

appendの有無で変わらないと

はい。計算量のオーダーが変わってなくて、純粋に append 分だけ遅くなってる。

2:43 AM

コピーが起こってなければ代入は O(1) 、コピーが起こってれば O(N) だから、 10 倍にしたときの増え方に変化が見られるはず。

2:44 AM

コピーというか、 map だから再生成って感じ？

ArrayはLazyCollectionじゃないからmapで普通に全コピー、であってる？

最初のArrayのコンストラクトを measure 外に移したらどうなります？

確かに。試してみます。

public var lazy: LazyRandomAccessCollection<Array<Element>> { get } これを使うとlazyになるのかあ。 (edited)

ObjCランタイム(=Darwin)かつTがクラスなら #if _runtime(_ObjC) のほうに流れると思うのです。 (edited)

lazyにしても、readした瞬間に遅延実行されない？writeじゃなくて。 (edited)

実際にアクセスするまでmapのクロージャが走らないはず？

https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L41 こっちの最適化が効くはず。

https://github.com/apple/swift/blob/397d801e191a5e75d2ba60c306fbd702af8942fe/stdlib/public/core/Arrays.swift.gyb#L460

swift - The Swift Programming Language

お

なんかそっちはバッファ共有っぽくみえる

2:48 AM

41行目の方は中身の保証があるからチェックなしの理想の共有で、 45行目の方は、アクセスに型チェックが挟まるのかな。Javaみたいな。

2:50 AM

https://gist.github.com/tarunon/4d0f33a6d2525ee94b6a3ce95c7b637b

swift - The Swift Programming Language

2:50 AM

Arrayのソースこれか？

2:51 AM

GYPになってるけど

public struct ${Self}<Element>

%{

arrayTypes = [ ('ContiguousArray', 'a ContiguousArray instance'), ('ArraySlice', 'an ArraySlice instance'), ('Array', 'an array'), ] }%

Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithoutAppend10M]' passed (0.624 seconds). Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithAppend10M]' passed (2.282 seconds). Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithoutAppend100M]' passed (4.037 seconds). Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithAppend100M]' passed (23.242 seconds).

なんかここらへんが組み合わさってArrayのswiftコードが出てきそう

初期化を measure の外に出した。

2:53 AM

いや、まちがえた

2:53 AM

これ measure の値じゃなかった

2:53 AM

普通に swift test が出してる値だった

ｗ

measure外で reserveCapacity() で +1 確保しておくと完全かと。

Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithoutAppend10M]' measured [Time, seconds] average: 0.000, relative standard deviation: 114.231%, values: [0.000023, 0.000005, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003], Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithAppend10M]' measured [Time, seconds] average: 0.163, relative standard deviation: 4.494%, values: [0.183134, 0.158554, 0.160044, 0.163250, 0.155895, 0.158189, 0.163386, 0.161289, 0.159981, 0.167179], Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithoutAppend100M]' measured [Time, seconds] average: 0.000, relative standard deviation: 115.617%, values: [0.000020, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003, 0.000003], Test Case '-[SwiftCovariantCopyTests.SwiftCovariantCopyTests testCopyWithAppend100M]' measured [Time, seconds] average: 1.762, relative standard deviation: 2.715%, values: [1.793434, 1.729103, 1.745168, 1.726823, 1.730955, 1.749660, 1.729168, 1.716899, 1.845567, 1.851858],

(edited)

最適化効いてるみたいですね。

っぽいですね。 reserveCapacity はまだしてないです。 (edited)

2:57 AM

ということは、共変っぽい代入しても CoW が効いてると。

@omochimetaru Arrayのソースはそれですが、 compiler intrinsic な処理もけっこう入るので Pure Swift とは言えない。

@rintaro ふむふむ

2:58 AM

_arrayForceCast って as! の時が基本の用途っぽいんですけど今回みたいな型安全な代入でも挿入されるのか今気になってて探ってるけどまだ手がかり無し

む、 measure 外で reserveCapacity できない・・・。 animal は measure の中で代入して生成されてるから・・・。

-emit-sil で

 %17 = function_ref @_TFs15_arrayForceCastu0_rFGSax_GSaq__ : $@convention(thin) <τ_0_0, τ_0_1> (@owned Array<τ_0_0>) -> @owned Array<τ_0_1>, loc "test.swift":7:27, scope 21 // user: %18 %18 = apply %17<Cat, Animal>(%14) : $@convention(thin) <τ_0_0, τ_0_1> (@owned Array<τ_0_0>) -> @owned Array<τ_0_1>, loc "test.swift":7:27, scope 21 // user: %19

おお！ありがとうございます

cats で reserveCapacity しておけば、buffer 共有されているなら capacity 維持されるはずだから

3:01 AM

問題無いと思います。

今 reserveCapacity したいのって、代入時にコピーが走ってるけど append でバッファのallocateが走ってしまってるから With と Without で差が付いている可能性を排除したいってことですよね？

3:03 AM

代入時にバッファが共有されてる=CoWが効いてるのであれば、 append 時にはどのみち allocate されるから関係なくないですか？

あー、ごもっともｗ

あー

3:05 AM

Tupleで悪いことしようとしてたらまたコンパイラクラッシュした

すーぐ壊す

今度はマジで天才だと思ったんだ

3:06 AM

undefined<T>以来のヒットだよ

3:06 AM

壊れたけど

仮にコピーが走っているとすると 10M と 100M で差が出るはずですが、両方 0.000003 [s] だし、CoW効いてそう。観測下限って可能性もあるけど、さすがに100Mのコピーがこんなに速いことはない気がする。

C++と違ってユーザー定義コピーオペレータが書けないからそこがもどかしいんだよな

3:08 AM

C++なら Catの operator= とコピーコンストラクタと・・・まあいろいろに printf しこめばはっきりする (edited)

やりました

3:09 AM

typeerasure_with_converient.swift

（ユーザー定義うんたらがあると Plainじゃなくなって動作が変わるかのうせいがあるけど

型消しに共変性に近い機能を+する

後でみる

@koher 上の最適化効いてるのは、catArrayの生成をmeasureの外に移した場合、ですか? (edited)

@tarunon 最適化はそもそも効いてたけど最初のArrayの生成が単純に重くて測定上のノイズになっていたという事

あ、今気付いた。そうです。コードは↓。

import XCTest class SwiftCovariantCopyTests: XCTestCase { func testCopyWithoutAppend10M() { let cats: [Cat] = [Cat](repeating: Cat(), count: 10_000_000) measure { let animals: [Animal] = cats XCTAssertTrue(animals.last! is Cat) } } func testCopyWithAppend10M() { let cats: [Cat] = [Cat](repeating: Cat(), count: 10_000_000) measure { var animals: [Animal] = cats animals.append(Dog()) XCTAssertTrue(animals.last! is Dog) } } func testCopyWithoutAppend100M() { let cats: [Cat] = [Cat](repeating: Cat(), count: 100_000_000) measure { let animals: [Animal] = cats XCTAssertTrue(animals.last! is Cat) } } func testCopyWithAppend100M() { let cats: [Cat] = [Cat](repeating: Cat(), count: 100_000_000) measure { var animals: [Animal] = cats animals.append(Dog()) XCTAssertTrue(animals.last! is Dog) } } } class Animal {} class Cat: Animal {} class Dog: Animal {}

ありがとうございます!

上の最適化効いてるのは

これが、 Without の方が速かったのが、という意味ならその通りですし、 CoW が効いてるのがという意味なら @omochimetaru の言う通りどちらでも効いてて、生成が measure のノイズになっていたということです。

CoW意図してました

3:31 AM

なるほど…

結論としては Linux版だと遅い

Linux版だと遅い

これはどこから出てきたの？

ObjcRuntimeを積んでないから (edited)

3:32 AM

#if に入らない

ObjCランタイム(=Darwin)かつTがクラスなら #if _runtime(_ObjC) のほうに流れると思うのです。

これか。

あい

なるほど。そうじゃないと単純な map になっちゃうのか。

3:34 AM

https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L50

http://qiita.com/tarunon/items/e3fd01b02a199747eb5e

swift - The Swift Programming Language

はい

クラスじゃないとObjCに行かないなら、Cat/Animalをstruct/protocolで作ってる場合も同様に遅いのかな

そういうことだと思う

たるのんのさっきの gist やっと理解した

3:54 AM

いわゆるAnySequence<T> みたいなType Erasureを作るときに、AnySequence(cats) ってやると AnySequence<Cat> ができるけど、これの左辺をAnySequence<Animal> で受けたいってことねで、このパターンだと DogとDogAを足したときに、何も書き足さずに同じ仕組みでそれができると

そうそう

・やりたいこと・よく知られた手法で何ができないかを冒頭に書いてほしいでござるよ

今までだと、多変数のprotocolだと多変数をバラバラに渡せばなんとかinit出来るみたいな

3:56 AM

すまんw

3:56 AM

状況であんまり嬉しくなかったのが、パラメータ1個渡せばいけるようになるから

3:56 AM

かなり便利

ちょっとかいてあったけどヒントが足りない

3:56 AM

ふむう

UIKitのラップ周りで

4:01 AM

共変性持たせたいなーっていうシチュエーションが無限にあったので

4:01 AM

これはマジで嬉しい

あ〜

4:02 AM

AnimalとCatの代わりに UIView と UIImageViewとかがあって

4:02 AM

AnyXってのはViewModel<V: UIView> みたいな

4:02 AM

やつになる？

ViewModelではないけど

4:02 AM

まっちくり

4:02 AM

一つはTransitioningAnimationの拡張周り

4:03 AM

この間SwiftTweetsで発表したやつの、3つ目の型変換が苦しかったのが

4:03 AM

ほぼほぼ解決する

ふむ

Swiftの型の限界を超える - Qiita

これはSwift Tweetsの発表をまとめたものです。イベントのスポンサーとして Qiita に許可をいただいた上で、このような形（ツイートの引用）で投稿していま...

ViewModelもGenericsで書いてたら嬉しいシチュエーションありそうだ

// こういうジェネリックなstructがあるときに struct S<T> { var s: T } var scat: S<Cat> = S<Cat>(s: Cat()) // ↓こんな事や var sani1: S<Animal> = sa // ↓次善でこんな事が var sani2: S<Animal> = sa.upcast() // できたらいいのにな

(edited)

そうそう

4:21 AM

C++だと

↑シンプルにこういう課題があると思うんだけど、簡単な解法がない・・・？

Genericsパラメータに共変か反変かみたいなの

4:21 AM

書けるんだよね

std::enable_if<std::is_convertible<T, U>::value> なんかこんな雰囲気でできる。

で、これ

4:22 AM

パラメータが1個なら

共変か反変かっていうのを概念として直接はかけないけど、代入可能かを静的に判定できるので、まあできる

var sani1: S<Animal> = S(s: scat.s)

4:22 AM

まあこう書けばいいんで、そんなに苦じゃない

4:22 AM

でもパラメータが複数になると全部取り出すの辛いんだ

いや、1個でも苦しいよ・・・

書いててだるい

4:23 AM

でー

まあフィールド数に比例してしまうのは終わってるね

これをFunctionの共変/反変で判定するところまで持ち込んで、多変数でも1パラメータでいけるようにして、ってやったのが

4:24 AM

さっきの

C++で std::shared_ptr<Tp> から std::shared_ptr<Yp> へのアップキャストコンストラクタがこれ https://github.com/llvm-mirror/libcxx/blob/master/include/memory#L3531-L3535

llvm-mirror/libcxx

Mirror of official libcxx git repository located at http://llvm.org/git/libcxx. Updated every five minutes.

func some<T, U> (_ something: A<T>) -> A where T: U

4:26 AM

こういうの書けないから今はFunctionに落とし込むしか無い

extension S { init<U>(_ o: S<U>) where T: U { self.init(s: o.s) } } // ↑これでいけるかとおもったけど駄目だった。

(edited)

Tがprotocolじゃねーぞって怒られる

ですね。

4:27 AM

あくまでプロトコルコンフォーマンスだけがコンディションとしてかけて

4:27 AM

代入互換性が書けない事が問題と理解した

functionの引数と返り値に関してはかなり強力な型チェックができるっぽいので

4:29 AM

それを頼るのが良さそう

iOSアプリだとどうしてもクラスが出て来るけど、値型で書いてたらそもそも継承が出てこないから変性考える必要もない気も。

4:31 AM

プロトコル型で取り回すのもあんまりやらないし。

まあ理想の世界はそうなんですがw

「iOSアプリだと」って、それが前提だからまあ・・・

いや、なので、Swiftが変性まわりをないがしろにしてるのって、そういうこともあるのかなぁと。

ああ。Swiftyな世界ではstruct指向だからジェネリック型境界というテーマ自体の比重が軽いと

はい

そういう意図は感じます

とは言えclassが全く必要でないかというとそうでもなく

4:37 AM

現実の問題ではしばしばお世話になるはずなのでなんとかして欲しい

ふと思いついたんですが、Swiftのタプルの辛みって「 (T, (S)) を (T, S) と同一視する」というルールを設ければ色々解決したりしませんかね

今すでにそうなってるような。 type(of: (1, (2))) // (Int, Int).Type type(of: (1, 2)) // (Int, Int).Type

「(T) を T と同一視する」はそうなってるんですが、それとは違って…　と思ったけど言い方がよくなかったですね

12:45 AM

つまりタプルを単方向リスト的に処理できればいいんじゃない？という話をしたかったのでした

(1,2) == (1, (2)) // 2 == (2) なので true (1,2,3) == (1,(2,3)) // Binary operator '==' cannot be applied to operands of type '(Int, Int, Int)' and '(Int, (Int, Int))'

下が通れば無限個のタプルを処理できるなーということです (edited)

タプルは型として扱われてないから Equatable 準拠とか出来ないので == もタプルの要素数毎に定義されてますよね。(6要素まで)

public func == <A : Equatable, B : Equatable, C : Equatable, D : Equatable, E : Equatable, F : Equatable>(lhs: (A,B,C,D,E,F), rhs: (A,B,C,D,E,F)) -> Bool {

たぶんタプルを型として扱える様にしないとタプルのネストとか解決できない。

はい、その6要素分の定義があまりにuglyなので… もし (A,B,C) が (A,(B,C)) のシュガーシンタクスだと解釈できるようになれば、 public func == <A : Equatable, B : Equatable>(lhs: (A,B), rhs: (A,B)) -> Bool で全て賄えるはずだなと思ったんです、が… たしかにご指摘の通り、現状の言語仕様だとそもそもタプルをEquatable準拠させることが不可能なので、 B: Equatable が成立しないとこで詰みますね

1:17 AM

まあuglyなだけで、大抵は６要素分までのoperatorがあれば事足りるし、困ったら自分で拡張すればいいから、実運用上は何も問題ないってので今の実装なんだとは思いますけど

Tupleが型Tuple2<A,B>になって、Conditional conformancesがある上でTupleNが全てTuple2の組み合わせのエイリアスなら成り立ちそうですが、これってバイナリツリーの平衡化とかも考えるんですか？効率は悪くなる気がしますね。

個人的には(A)と((A))はそのまま全く違う型なので、同一視はしないほうが嬉しいです例えばjsonへの変換を考えると全く結果が違うし

6:19 AM

現状が型として不完全である問題の解決という意味なら、素直にタプルがらちゃんと型になってくれるほうが良いと思います

ああ一個だと同じなのか。ややこしいな。

SE-0169がacceptされて読んでるけど英語大変

12:37 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

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

privateがextensionから見えるようになるよ、終わり！

12:51 AM

って感じに見える

fileprivate を使う機会を減らせそう

@omochimetaru 多分言いたいのは ((A, B), C) と (A, (B, C)) は違う型ということやんね？それは同意です。

2:05 AM

個人的にはタプルが nominal でないのは、タプルの乱用を防ぐためには理に適っているように思います。タプルを使うべきでないケースで struct を利用する圧力になっていると思う。

@koher そうです

2:06 AM

んん？

2:06 AM

仮にextensionが定義できるなど、型としてちゃんと扱えるようになったとしても

2:07 AM

ノミナルじゃないのはノミナルじゃないままで

2:07 AM

Swiftにおいてノミナルじゃない、というか、ストラクチュラルな型に対して、

2:07 AM

いろいろできない、

2:07 AM

という理解だったけど間違ってるかな

2:08 AM

それとも、 kotlinのPair<T, U>とかC#/C++のTuple2<T, U>, std::tuple<T, U> みたいな、ノミナルなタプル達を対比した発言？

nominalじゃない=extensionが書けないの意図でした。

なるほど

2:10 AM

その下では、Swiftのtupleがいろいろ不便で、structへの圧力になってるという現状は僕もそう思っているけど、それがSwiftの設計思想上の意図なのか、単にズボラでこうなってるのかわからない

タプルって、メソッド呼び出し・戻りのペイロードを融通できるようにしたもので、効率が優先されるものだと想像。

2:15 AM

タプルを型として扱えるようにすると、その効率が維持できないと想像。

効率というのは実行速度の事ですか？

2:15 AM

それともコンパイル時間？

どっちもですかね。

2:16 AM

~~型にするとメタデータの生成が必要になり、それをメソッド呼び出し・戻りへ含めなければいけなくなる。~~ (edited)

他の struct 型と同様にそのような無駄なバイトは生まれないと思います (edited)

コンパイル時に型を決定できるならそうかもしれないけど

structと同様にfinal強制であれば大丈夫ですね

値型なのにfinalでないこととかあるの？？

プロトコルとか。

protocolは値型ではないですね

2:23 AM

そもそもあれはただの型なので

タプルの話ではなく？？

@koher 値型なのにfinalでない事はありえないと思いますがそんな発言有った？

@omochimetaru ↓これ。タプルの話だと思ってたから、当然そうだと思ってた。

structと同様にfinal強制であれば大丈夫

final強制と言っているのだから

タプルの中身がプロトコルの時とか、どういう扱いになるのだろう。

finalだというのが僕の意見ですよ。

ああ、「であれば」が「だから」の意なのか。

2:26 AM

@norio_nomura それは struct がプロトコル型の stored property を持ってるのと同じじゃないですか？

あいや、今でもタプルのメタデータはちゃんと作られてるのか。

タプルの中身がプロトコルの時とか、どういう扱いになるのだろう。

プロトコルにassociatedtypeが無い場合しか無理なはずで、仮にprotocol P1 だったとすると、 var x: (P1, P1) の取扱は、 var y: P1 と、ただの単一変数が、 struct S { var y: P1 ; var z: P1 } とフィールドに並んだ場合と同じだと思います。

2:36 AM

メタデータってのは型の型の事ですかね、Anyに突っ込むことができるので存在はすると思います。

ちゃんと記述があった。 https://github.com/apple/swift/blob/master/docs/ABI.rst#tuple-metadata

swift - The Swift Programming Language

おお。

2:39 AM

バイナリ表現まで規定されてるんですね

僕の認識は大きく間違っていました。

Tuple metadata has a kind of 9.

2:41 AM

Class metadata, instead of a kind, has an isa pointer in its kind slot, pointing to the class's metaclass record. This isa pointer is guaranteed to have an integer value larger than 4096 and so can be discriminated from non-class kind values.

2:41 AM

うわ、ここでも整数とポインタの同居が・・・

enum のペイロードもタプルだと思っていたのだけど、記述がない？

The nominal type descriptor is referenced at offset 1.

2:45 AM

ここからnominal type descriptorのところに

2:45 AM

For an enum:

2:45 AM

とかの節がありますが

For enums that are members of an enclosing nominal type, this is a reference to the enclosing type's metadata.

とあるので、複数型含む場合には enclosing type がタプルってことでいいのかな。 (edited)

ここは

2:50 AM

parentとか書いてあるし、enclosingっていうのは

2:50 AM

struct Cat { enum State {} } みたいな

2:50 AM

型の中の型の場合に

なるほど。

自身が定義される型の外側の型のメタデータを持つって記述では

2:50 AM

enum自体の中身がかいてああるのは、その一個上のoffset1のところで

2:51 AM

nominal type descriptorへの参照になってて、nominal type descritporの説明を読んでいくと、enumの場合について書いてありました

これか https://github.com/apple/swift/blob/master/docs/ABI.rst#multi-payload-enums

swift - The Swift Programming Language

2:53 AM

あいや違う。

For an enum:

The number of payload cases and payload size offset are stored at offset 2. The least significant 24 bits are the number of payload cases, and the most significant 8 bits are the offset of the payload size in the type metadata, if present.

2:54 AM

↑こんなテキストのところ。

ありがとうございます

ABI周りって型のメタデータ一通りちゃんと規定する必要があるんだなあ・・・

2:57 AM

そりゃそうだよなあ大変そう

先に「ノミナル」って出てきてたのは Nominal Type Descriptor https://github.com/apple/swift/blob/master/docs/ABI.rst#nominal-type-descriptor を持つ型たち、ってこと？

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types

swift - The Swift Programming Language

えーっと

2:58 AM

発端は @takasek さんの以下の発表で https://speakerdeck.com/takasek/what-is-a-nominal-type

1

2:58 AM

nominal type自体は

2:59 AM

型システム理論での概念で https://en.wikipedia.org/wiki/Nominal_type_system

Nominal type system

In computer science, a nominal or nominative type system (or name-based type system) is a major class of type system, in which compatibility and equivalence of data types is determined by explicit declarations and/or the name of the types. Nominal systems are used to determine if types are equivalent, as well as if a type is a subtype of another. It contrasts with structural systems, where comparisons are based on the structure of the types in question and do not require explicit declarations.

1

2:59 AM

そこらへんを指して話していて

2:59 AM

僕はSwiftのNominal Type Descriptorとの対応でちゃんとは考えていませんでした。

2:59 AM

というか、そんなものがあるのは今しったｗ

3:01 AM

The kind of type is stored at offset 0, which is as follows: 0 for a class, 1 for a struct, or 2 for an enum. 結果的に認識とは一致していそう。タプルやファンクションはnon-nominalですね

「Swiftのタプルの辛み」をなんとかするには nominal type descriptor や protocol descriptor を持つ型にしないといけない雰囲気ですね。

non-nominalなままextensionとかが書けるようになったらいいと思うんですけどね

3:10 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

swift - The Swift Programming Language

3:11 AM

GenericManifestoではそのトピックも上がっている

おお、まさにこれじゃん。

3:15 AM

Function typeにもextensionが欲しいと以前思ったことがあったんだけど "Extensions of structural types" っていう括りだと、それも含まれるのかな。

そう思います。

Function typeはサブタイピングがあるからさらにややこしそう・・・

タプルもサブタイピングはほしくないですか？

3:18 AM

covarianceだから

() -> Animal に対する extension は () -> Cat にも使えるのか。

(Animal, Int)に対するextensionは(Cat, Int) でも使いたいですよね

タプルは今のところ covariant になってないから、素直に考えればそれはないのでは？

あ〜

3:19 AM

Functionは今もう既になってるからか。

うん

Functionの引数と返り値のみ、何故かタプルもCovariantになりますけどね

3:19 AM

完全に謎

作りかけなだけだと思うんだよなあそこらへん

引数と戻り値は、タプルだけどタプルじゃなくて、複数引数と複数戻り値なんでしょうね。

でも、そこがちゃんと区別されるようになりますよね

3:21 AM

今までは ( (A,B,C) ) -> R が (A, B, C) -> Rと同一視されてたけど

3:21 AM

(3要素タプルを引数に受ける関数 = ３引数関数）

3:21 AM

そこちゃんとわけようぜって方向に進んでる

メタデータではタプルになってますね

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

3:23 AM

Swift's type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments.

あれ？↓もできるんだっけ？？

class Animal {} class Cat: Animal {} let a: () -> (Int, (String, Cat)) = { (42, ("xyz", Cat())) } let b: () -> (Int, (String, Animal)) = a

3:24 AM

戻り値の一番外側のタプルはともかく、内側でも Covariant なの謎だ。

そうそう

3:26 AM

引数も内側のタプルがそうなるんで

3:26 AM

謎だった

これもできた。 let c: (Int, (String, Animal)) -> () = { _, _ in } let d: (Int, (String, Cat)) -> () = c

3:27 AM

なるほどー。関数型については、ネストした分も含めて、戻り値ではタプルは Covariant 、引数では Contravariant になってるんだ・・・。

それ利用すると、Genericsのinitを関数で受け渡しすることで

これ、 swift-evolution に出してもいいんでは？ Inconsistent bihavior of tupple variances みたいな。

GenericsにCovariant/Contravariantっぽい機能を追加できるようになる

このまえやってたやつですね。

そうです

ネストの内側までこうなってるのって確信犯的ですよね。あえてやってる。

3:29 AM

ということは、普通のタプルでそうなってないのは実装漏れなのかな。

で、それを書いてる途中で、またassociatedtypeにtupleを入れてdefault implを書くとコンパイラクラッシュに遭遇した

鉄板落ちみたいになってて笑う

でも今回は、associatedtypeをBoxingすれば回避できることに気がついたので

stdlib内にその挙動を利用した実装があるのかどうか。

この実装ができた。　https://github.com/tarunon/Covariancable

tarunon/Covariancable

Covariancable - Add covariance/contravariance feature on your type-erasure.

3:30 AM

let convarianceAnimalCage = AnyAnimalCage<Animal>(~catCage) // Adding `~` operator, pass compile it! 💪

最後のめんどくさい部分をオペレーター定義で簡単にしたのね

let foo: () -> (Cat, Int) = { (Cat(), 1) } let foo2: () -> (Animal, Int) = foo のときは -dump-astで (function_conversion_expr implicit type='() -> (Animal, Int)' (declref_expr type='() -> (Cat, Int)' )) だけど

1

3:33 AM

function_conversion_expr が噛まされているってことですね

おー

https://github.com/apple/swift/blob/master/lib/Sema/CSApply.cpp#L4427 みると、ASTで tuple を変換する expr が無いからまだ実装出来ないよ的な。

[Constraint application] Coerce tuples to tuples. · apple/swift@...

swift - The Swift Programming Language

1

 // We need to convert the source element to the destination type. if (!fromTupleExpr) { // FIXME: Lame! We can't express this in the AST.

で、このFIXMEが書かれたコミットは 2013年という https://github.com/apple/swift/commit/e114abe21ca7fb831a648412026151aaef5a53f6#diff-d0d0e69db69e2be448d225547cbeb53eR100

Start factoring out the logic that computes the mapping from one tuple type to another. We're only using it in one place now (the tuple-to-tuple coercion), but it should be picked up by the constra...

1

FIXMEだ。

3:36 AM

てことは、やってないんじゃなくて、まだやってない、説が強くなってきたぞ

じゃあ PR 作れば通る可能性も？

忘れ去られているだけのような気がしますね。

なるほどー。

素晴らしい

3:43 AM

この辺りの挙動は未定義で、たまたま今こうなってると。

3:47 AM

他と整合取れた実装にすると tarunon さんの Covariancable は動かなくなる？

えっ

3:47 AM

TupleにCovariantが追加されるのが平和で良いのではないでしょうか

サブタイピングが効く側に倒れる分には動かなくはならなそうだけど、そもそも不要になりそう

不要というか

効かない方に統一されたら動かなくなりそうですね

中でfunction作って渡してる部分が、tupleでOKになるだけですね

あ〜

効かない方に統一とか鬼畜の所業、やめていただきたく

そっか、taruninのライブラリがやるのはgeneric structのcovarianceの話か

そうそう

3:49 AM

他パラメータ渡すのしんどいから~で簡単にする、でそれで受け渡しするのが

3:49 AM

tupleをreturnするfunctionから、tupleを使うだけの素直な実装になる (edited)

前に Chris Eidhof が挙げてた Proposal が Review 入りしてる。これできたらうれしい。 https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

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

これは欲しい

3:56 AM

これが無いのでDictionaryを外に書かないといけない

reduce で Dictionary 作る時とかだるすぎたから

3:56 AM

ですよね。

ASTで tuple を変換する expr が無いからまだ実装出来ないよ的な。

これって、タプルごとキャストが動かないのと同じもの？

let anyany: (Any, Any) = (Int(1), Int(1)) if let intint = anyany as? (Int, Int) { print(intint) // 3.0.2: unreachable, 3.1: "(1, 1)\n" } if let int0 = anyany.0 as? Int, let int1 = anyany.1 as? Int { print(int0, int1) // "1 1\n" }

(edited)

4:00 AM

お、3.1で動くようになってた。

キャストとはまた違う気がする

4:02 AM

でもキャスト動かなかったんですね、知らなかった

別物ですかね。 (edited)

関係ありそうな気もしてきた、理解が半端だけど直感的にexpr無しで動かないような気もする。

4:10 AM

どうやって動くようにしたんだろ

let a: (AnyObject, AnyObject) = (Cat(), Cat()) let b = a as! (Animal, Animal) みたいなときは、静的なキャストができなくてタプル全体が実行時キャストになるから FIXME のところまで到達しないと思います。 (edited)

あー

4:26 AM

なるほど

4:26 AM

なるほど、なるほど

4:26 AM

ありがとうございます

4:26 AM

そうか、こっちはコンパイル時に解決しなくて良いのか

↓これもほしいやつだ。 https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md

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

2

Array扱う分にはprefixとdropで足りるんですけどね

これが通ったらまたRangeファミリーが増えてしまう・・・。

ファミリーが多い問題点はconditional conformanceが入れば解決するのでは。

6:34 AM

特定のジェネリックなコードで4回オーバーロードしてるのが辛いって話ですよね (edited)

はい。 conditional conformance で解決というのは？

１つの定義にできるような気がしてる

protocol 作ればできる気がする。

あれっ、今ってprotocolすら何もついてないんですね

6:39 AM

今も自分でプロトコル付けたら1個にできるのかも

protocol GeneralRange { associatedtype Value: Comparable var lowerBound: Value? var upperBound: Value? } extension Range: GeneralRange {} ...

(edited)

下限値はどっちも取れるんで上限値をとるのをつければ良さそうですね

6:41 AM

RangeとClosedRangeでupperBoundの意味が違った記憶

単純な subscript だと 4 通りだけど、組みわせになると爆発するから https://github.com/koher/EasyImagy/blob/swift-3/EasyImagy/Image.swift#L78-L92

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

EasyImagy - Makes it easy to deal with images in Swift

/// An interval over a comparable type, from a lower bound up to, and

/// including, an upper bound. >> /// A half-open interval over a comparable type, from a lower bound up to, but /// not including, an upper bound.

6:43 AM

var includingUpperBound: Bool も生やせば解決？ (edited)

↑は本当は 16 通りある。↑は 2 乗だけど、 TensorSwift とか numsw でやってるようなのだと N 乗になっちゃうから一つにまとめないと実装できない。

6:43 AM

どうせなら 1<..42 とかも作って欲しい。

下が開いてるのは需要ないんですかねぇ

6:44 AM

<..<まででてくると気持ち悪そう

コーディング上少ないだけで、絶対にあると思うけどね〜。

6:45 AM

<.< か <..< か悩ましいな。

１個点だともはやレンジ感が無くて謎なので２個がいいな

6:48 AM

僕は一般に範囲を制御する時は (begin, end): begin <= x && x < end とするのが好きで、理由はこれだと連続な直線を過不足なく繰り返し分割できるから

6:50 AM

したがって 4月いっぱいまでのキャンペーン期間を定義する時は 04-30_23:59:59 じゃなくて05-01_00:00:00にしたい (edited)

つまり Range で事足りると言ってる？

そういう事ですね

6:50 AM

整数直線上で端が欲しい時はendを1個みぎにずらせばいいので。

6:51 AM

SwiftやRubyで記法があるときはまあClosedRange使うけれども別に型として存在して無くて良かった気がしてる

それはそうなんだけど、それってそのスタイルが普及してるだけだし、普遍的に a<..b が要らない理由とはならない気が。 (edited)

まあそうですね。

6:53 AM

ライブラリのバージョン、みたいな、離散的で計数不能な数の指定において、そういう表現が欲しい可能性はある

SwiftPMのPackage.swiftでプレリリースバージョンの指定がうまくできなかったのを思い出す

ちょうどSPMのコードを最近眺めてたんで僕もそれを思い浮かべていました

7:02 AM

[stdlib][WIP do not merge]One-sided ranges and RangeExpression b...

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

7:02 AM

↑Range２種オーバロード

良さげ https://github.com/apple/swift/pull/8710/files

Still needs niceties like custom string conversion, fix out of date tests and add new ones.

extension ${Self}: RangeExpression { こんな書き方初めて見た

7:12 AM

いやこれ自体はswiftじゃないのか

gypだね

7:13 AM

あっ、gypじゃなくてgybだ！

Generate Your Boilerplate

https://github.com/apple/swift/blob/master/utils/gyb.py

swift_oss_helper.py helps debugging Swift Standard Library usi...

swift - The Swift Programming Language

7:14 AM

てっきりGoogleのGYPを流用しているのかと思っていた

7:15 AM

swiftプロジェクト内で作られたツールなんですね

swift.orgで配布されているツールチェーンのシンボルデータはgybから生成されたソースコードを指しているので、ツールチェーンのビルドなしにgybを適切な場所へ展開するツールとか作りました。 https://gist.github.com/norio-nomura/10d9790e7b5e414e20ae5ac6e621ef20 (edited)

swift_oss_helper.py helps debugging Swift Standard Library using source code with Swift Toolchain distributed at swift.org.

お〜

タプル続き

class Animal {} class Cat: Animal {} let strinCat: (String, Cat) = ("xyz", Cat()) if let stringAnimal: (String, Animal) = strinCat as? (String, Animal) { print(stringAnimal) }

でエラー:

Playground execution failed: warning: 20170418-130912.xcplaygroundpage:1:50: warning: conditional cast from '(String, Cat)' to '(String, Animal)' always succeeds if let stringAnimal: (String, Animal) = strinCat as? (String, Animal) { ^ error: 20170418-130912.xcplaygroundpage:1:41: error: cannot express tuple conversion '(String, Cat)' to '(String, Animal)' if let stringAnimal: (String, Animal) = strinCat as? (String, Animal) { ^

always succeedsとは

warning: conditional cast … always succeeds と言われるので as? から as へ変えると、2番目のエラーだけになる。 (edited)

実行時エラーじゃなくてコンパイルエラーですかね

です

ああ、本当だ、 always successなのに消しても怒られるｗ

つらいw

先の FIXME: に引っかかってるぽいです

class Animal {} class Cat: Animal {} let strinCat: (String, Cat) = ("xyz", Cat()) print(strinCat) if let stringAnimal: (String, Animal) = strinCat as Any as! (String, Animal) { print("yatta") print(stringAnimal) }

これでyattaが出力された・・・ (edited)

そういえば、 "always failed" もバグってるんですよね。

protocol Integral {} extension Int: Integral {} struct Foo<T> {} extension Foo where T: Integral { func foo() { let zelf = self as! Foo<Int> print(zelf) } } let foo: Foo<Int> = Foo() foo.foo()

$ swift AlwaysFailed.swift AlwaysFailed.swift:8:25: warning: cast from 'Foo<T>' to unrelated type 'Foo<Int>' always fails let zelf = self as! Foo<Int> ~~~~ ^ ~~~~~~~~ Foo<Int>()

(edited)

今はT == Intできるから見なくなったやつですね

あー　できるときもありえるのに絶対ダメでコンパイルできないのか

いや、 warning

8:10 AM

でも、確か Foo を Array にするとコンパイルエラーになるという謎挙動だったはず。 (edited)

extension Array where Element: Integral { func foo() { let zelf = self as! Array<Int> print(zelf) } } swift sandboxで何も言われない

いや

8:12 AM

これやろうと思ったら

8:12 AM

unsafeBitCastしなきゃいけなかったはず

aliasingとかの話ですか？

let zelf = self as! Foo<Int>

8:17 AM

これですね

8:17 AM

ArrayはそもそもunsafeBitCast無理か

8:18 AM

unsafeBitCastはファントムタイプでwarningでなくなるのと無理やり動かせるだけだった

8:18 AM

勘違いス、すみません

1

この辺の話（Ty<Some> から Ty<Covariant> への変換) って https://devforums.apple.com/thread/261699 で語られているんですが、 https://devforums.apple.com/message/1102432#1102432 のArrayとかは出来るけど任意の value type には当てはまらないって文脈で＞ this doesn't apply to every value type (because value types can contain references and not enforce copy-on-write) らしいのですが、どういうケースなんでしょう？ (edited)

この元の話は variance の話ですよね？

8:40 AM

Farm<Cow> を Farm<Animal> として扱えないという。

です。

で、 SevenTenEleven さんが言ってるのはこの前検証してたみたいな Array<Cow> を Array<Animal> として扱っていい理由の話ですが、 CoW はあんま関係ない気がしますね。

8:41 AM

別に代入時にコピーしちゃえばいいだけだから。

Farm が struct だった場合に Farm<Cow> as Farm<Animal> できるとして、どういう不整合が発生する可能性があるのかを知りたい。

発生しない気がします。

Farmの上位のprotocolの規約として、func some(_ t: T) が生えてる場合は困ったことになる気がする

8:44 AM

でもArrayは暗黙的なmapで別に困ってないのか

8:44 AM

ふむー

二つ下で Core Team の Dave が func makeAllAnimalsSpeakInFarm(farm : Farm<Animal>) { farm.listenToAnimals() } じゃなくて func makeAllAnimalsSpeakInFarm<A: Animal>(farm : Farm<A>) { farm.listenToAnimals() } でいいんじゃない？って言ってる。この、サブタイピングに頼らずジェネリック関数で解決するの、 Swift 的に正しいと思う。 (edited)

実際このCovariantが欲しくなるシチュエーション、Covariantにしなければいけない型の代わりにGenerics宣言するとスッと解決するんですよね (edited)

8:48 AM

ただまぁ、

8, 9 割は↑で解決できるからプロトコル型変数自体も作れなくしちゃってもいいんじゃないかと思ってます。

func some<T, U> (...) where T: U が書けないので

8:49 AM

引数に入れる側の型にGenericsを書かなければいけなくって、結構ウッてなる

8:49 AM

回りくどい

func some<T, U> (...) where T: U ←これのどこらへんが書けない？

普通にコンパイル通りませんよ (edited)

どういうときに使うんですか？

Tがprotocolじゃないって怒られる

あ〜

なんかでも最近それで怒られた記憶が・・・

UIView/UIViewController周りで型パラでなんとかしたい~~ってなって、その辺でSwiftラッパー書いてると

8:51 AM

絶対遭遇しますね

8:51 AM

ラッパー側の汎ゆる場所をGenericsで宣言すればまあ動くんですが

8:52 AM

なので、func some<T, U> (...) where T == U って書いて、Uに束縛される側を、サブタイピングなGenericsで宣言し直す

8:52 AM

これが今のところ一番マシなWorkaround

8:52 AM

超回りくどい

Generalized existentials↓を導入する方向性よりも、プロトコル型変数を禁止する方向性の方が、言語がシンプルになってうまくいくような気がしてる。さすがにサブタイピングなくなりすぎできついかな・・・。 https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials

Swiftはジェネリックなプロトコル型変数を作れないから速い仮説 - Qiita

swift - The Swift Programming Language

classが存在する以上、問題はついて回りますね

@koher その章の例で示されているように、typealiasしちゃえば、 typealias AnySequence<Element> = Any<Sequence where .Iterator.Element == Element> これって完全にあの書くのがめんどくさいTypeErasureの

8:56 AM

自動生成機能にすぎない気がします

8:57 AM

それともめんどくさい事によって濫用が防がれているのがいいのかな。

initしなくていいっていう差はあるんじゃない?

あ、なるほど。

あでも値型ならコピーするからほぼ変わらないのか

あくまで型関係なのか

8:58 AM

あー、うん、実行時モデルではそうなるけど

データはともかくポインタは

プログラマがコンストラクタは書かなくていい

それはそうね

8:58 AM

今は

8:58 AM

AnySequence(array)

8:59 AM

絶対こう

8:59 AM

で、これを利用者側に書かせるのがうんkだから、

あー、個人的にはむしろ、そこが大事な気がする・・・

init<S: Sequence>(, , , sequence: S) みたいな

8:59 AM

そう言うの毎回作る

そこが明示的に変換していることでブリッジオブジェクトを生成しているコストが肌で感じられる

APIのUXかな?(計算量の重い操作は使いづらい)

そうそう。

TypeErasure自体アンチパターン感が。

で、この章のように、いらなくなってしまうと、

ええーー

多分、ライブラリの引数で受けるところとか

9:00 AM

全部これで書きましょうって方向に

9:01 AM

みんな流れていく気がする

引数はそのままで、格納するところはこれになるんじゃ

9:01 AM

だからあんまり変わらない気もする

9:01 AM

外見は一緒じゃないかなぁ

多分、ライブラリの引数で受けるところとか全部これで書きましょうって方向にみんな流れていく気がする

そう、こうなるのを恐れてる。

List<Integer> xs = new ArrayList<Integer>

Java で List<String> とか書くノリで、 [String] じゃなくて AnySequence<String> になってしまいそう。

これの世界になってしまうと、値型ベースのSwiftの高速な世界が

9:02 AM

Javaのなんでもメソッドディスパッチコストかかる世界になっちゃいそう

↓これ http://qiita.com/koher/items/88f6d7a9c9dd2d8c25a7

Java では次のようなコードが一般的です。 java // Java List strings = new ArrayList(); ArrayList インスタンスを `Arr...

引数はそのままで、格納するところはこれになるんじゃ

格納するところがこれになっちゃうと、遅くなるはず。

ふむ

9:05 AM

今はAnySequence入れてるけど

9:05 AM

それは遅くならない?

今AnySequenceになっちゃってるならそれと同程度に遅い

9:05 AM

Arrayにしたほうが早いはず。

ほー

これって、中身Arrayになるんじゃないの? (edited)

Java 的な List<String> な世界を目指すなら Generalized existentials や Type Erasure はめんどくさすぎますし、サブタイピングに頼らない静的ディスパッチな世界を目指すなら Generalized existentials もプロトコル型変数すらもいらないと思うんですよねぇ。

@norio_nomura それは不可能なはずです。 SequenceはmakeIteratorでイテレーターが取れるっていうだけのインターフェースだから、例えばmakeIteartorのたびに異なる数列を返すイテレーターを返す挙動がありえます。 AnySequenceのコンストラクタは S: Sequence な S を受け取るだけだから、その S の makeIteartorに転送するだけのコードがAnySequenceの実体です

9:11 AM

makeIteartorインターフェースは、無限数列も表現可能なので、そういういみでもArrayにできない

これの話だよね？

typealias AnySequence<Element> = Any<Sequence where .Iterator.Element == Element> let strings: AnySequence<String> = ["a", "b", "c"]

(edited)

9:13 AM

今の AnySequence とは別物では？

あ、そっちの話か。すいません。

9:14 AM

そっちの場合は、現状で、 func f <E, S : Sequence> (s: S) where S.Iterator.Element == E とかやったときに、これを呼び出す時に引数に渡したArrayがSequenceとしてアップキャストされるときと、同じような仕組みで実現されると思っていて

9:15 AM

その場合、protocol existential 的なものになっていて、　元々のArrayもコピーしてるけど、メソッド呼び出しはいったんprotocol witness tableっていう、仮想関数テーブルを経由する形になります

9:16 AM

9:16 AM

http://qiita.com/omochimetaru/items/b41e7699ea25a324aefa

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

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

ん

9:18 AM

AnySequenceはmakeIteratorをclosureとして持つ構造じゃないの?

今のAnySequenceはそうだけど

受け取ったSequenceからmakeIteratorを取り出す時にwitness-tableが要るのか

いや、２つのAnySeqneceの話があって

9:18 AM

今実在しているSTDLIBのAnySeqnceはクロージャーでメソッドを転送してるけど

9:19 AM

koherが張ったGenericManifestoで書かれてる typealias AnySequence<Element> = Any<Sequence where .Iterator.Element == Element> Generic Existential + type alias としての AnySequenceは

9:20 AM

クロージャー方式じゃなくて、既存のジェネリック関数で引数のところで現れるメモリ表現になるんじゃないかなあという事

AnySequenceが遅いっていうのは

9:21 AM

今のクロージャーを引き回すそれも遅いという事だと受け取ったんだけど

9:21 AM

それは違う?

どちらの方式でも遅い、という意見です

ふむ

クロージャー方式でもwitness-table方式でも

9:22 AM

結局、プロトコルの型としてそのメソッドを呼べるようにするための関数呼び出しと、そこから、中で捕まえてる本当の型の対応するメソッドを呼び出すための、ブリッジするだけの関数の呼び出しが必要だから。

9:23 AM

witness-tableに入ってる関数ポインタの先にある関数の実装は

9:23 AM

結局、中身のArrayをダウンキャストで取り出して、Arrayの本当のメソッドを呼ぶ、っていう構造になってる。

ん

9:25 AM

クロージャー方式本当に遅い?

9:25 AM

クロージャーにキャプチャする時点で、関数ポインタの先にある実装を渡しているなら

9:25 AM

それほどクリティカルにならないんじゃね、と思ったんだけど

9:26 AM

_makeIterator = { _ in s.makeIterator() } ←これはクソ遅くなりそうだというのはわかるけど、 _makeIterator = s.makeIterator ←これはセーフでは?

AnySequenceの場合: AnySequenceのmakeIterator呼び出し→ _makeItaratorフィールドの関数を呼び出し → 内部でArrayのmakeItarotを呼び出し Arrayの場合: ArrayのmakeItarotorを呼び出しで、手数が増えてる。

それは関数1個分のオーバーヘッドで

9:29 AM

tableの探索みたいなO(n)になり得るサムシングではない

それはそう

遅いと言われたのでO(n)なのかと思った

それはJavaのList<Integer>でも同じ話で

9:30 AM

でも、そのオーバーヘッドが無いからこそ

9:30 AM

Swiftは C/ C++ と比肩するスピードが出せる

9:30 AM

設計上のポテンシャルがあるのが

9:30 AM

魅力だと僕は思っているので

9:30 AM

関数１個分とか２個分のジャンプが増えるのが嫌だ。

9:30 AM

という話し。

Generalized existentials はビルド時に型が決まれば specialize されたりしないのかな？

ジェネリック関数については基本的にspecializeされまくって消去されます。

9:31 AM

でも、外部からリンクしたときのために、柔軟なバージョンがオーバーロードされて残る。

9:31 AM

Generalized Existentialsも同じ事が言えるはずで

9:32 AM

特に型の中のフィールドとかで使われちゃうと

9:32 AM

public な struct とかだったら、無理ですね

9:32 AM

パッケージローカルなstructだったら、 Arrayで使われてる場合は、Arrayにspecializeされた版で動かして・・・という風に消去できれば、

9:32 AM

最高な可能性はあります

9:33 AM

それならC++のtemplate classと同じになりますね。

そういうものを目指してるのかと勝手に思ってました。

なるほど。

実際の実装が出てこないとわかりませんね。

ちなみに、現状のstdlibの Any＊＊＊はクロージャー方式ではないですよ。

ファッ

class MyAnyIteratorBoxBase<Element> { func next() -> Element? { fatalError("abstract") } } class MyAnyIteratorBox<I : IteratorProtocol> : MyAnyIteratorBoxBase<I.Element> { var base: I init(_ base: I) { self.base = base } override func next() -> I.Element? { return base.next() } } struct MyAnyIterator<Element> : IteratorProtocol { var base: MyAnyIteratorBoxBase<Element> init<I : IteratorProtocol>(_ base: I) where I.Element == Element { self.base = MyAnyIteratorBox(base) } func next() -> Element? { return base.next() } }

こんな感じ。

うおお

9:36 AM

IteratorがAnyIteratorにinしてる…

クラスのインスタンスメソッドへの動的ディスパッチが入るから、非常に遅い。

かなしかった

クロージャーより遅くなるのでは

9:38 AM

クロージャーとくらべてvtableの方がis_aを手繰る分１メモリ操作遅い気がしてる

Rationaleとしては、クロージャにするとメソッドが多くなったときに、Any*** 変数のMemoryLayout.size が非常に大きくなってしまうから。

9:39 AM

けど、Iterator は next() だけなんだしクロージャにしようよっていう議論がある。

なるほどなるほど。

Generalized Existentialsのspecializeって難しくないですか？↓みたいな Foo<T> があったときに

struct Foo<T> { var ts: Any<Sequence where .Iterator.Element == T> init(_ ts: Any<Sequence where .Iterator.Element == T>) { self.ts = ts } }

↓で作った a と b の間で同じ型なのにメモリレイアウトを変えないといけなくなりません？

var a: Foo<Int> = Foo(Array([2, 3, 5])) // Arrayにspecializeされる var b: Foo<Int> = Foo(Set([2, 3, 5])) // Setにspecializeされる a = b // どうなる？？

たしかに。

9:41 AM

それをフィールドに持つ型　に　ついては最適化不可能ですね

9:41 AM

ローカル変数とかぐらいなら・・・

specializeできるケースって、ジェネリック関数で問題ないケースな気が。

ローカル変数ならそもそも生の型でいいんだな

うん

specializeできるケースって、ジェネリック関数で問題ないケースな気が。

そんな気がしてきた

用途としては動的ディスパッチがメインってことですかね。

FYI: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170403/004304.html https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160905/002852.html

1

用途としては動的ディスパッチがメイン

そうなるように思います。

おー、クリスエイドフが、クロージャーのほうが10%速いんだけど〜って書いてる。

9:58 AM

見てなかったけど swift-dev ML も面白いですね。

あれ？ Generalized existentials って、今の AnySequence とかの延長なの？

ちがうけど、Generalized existential があれば AnySequence とかいらなくね？っていう文脈だとおもってます。

ですよね。ありがとうございます。

10:02 AM

swift-dev MLの「9割はCIが失敗した〜」です。

10:04 AM

ああ、AnySequenceの代わりになるなら、AnySequenceと同じ問題にぶち当たるだろう、ってことか。

Farm が struct だった場合に Farm<Cow> as Farm<Animal> できるとして、どういう不整合が発生する可能性があるのか

あー、わかった

11:42 AM

class Animal {} class Cow : Animal {} class Sheep : Animal {} class Fence<T> { var animal: T? = nil } struct Farm<T> { var fence: Fence<T> = Fence<T>() } func buySheep(farm: Farm<Animal>) { farm.fence.animal = Sheep() } let farm = Farm<Cow>() buySheep(farm: farm as Farm<Animal>)

11:43 AM

Farm が Generic なクラスを持ってたらだめってことでした。

それはfenceも同様にcovariantなら問題ないはず

11:44 AM

swiftのGenericsパラメータが、内部的にTがどのような使われ方をされてるかがわからなくて、多分一番問題になるのは

11:46 AM

struct Farm<T> { var 困る奴: (T)->() }

11:47 AM

こんな感じで、クロージャを持たせて引数にTを置くと、この場合はFarm<Animal>をFarm<Cat>に代入できるはずで、逆は成り立たない

うむ。いずれにしても Farm.T を持つリファレンスタイプのプロパティは Farm のコピー時には普通なら deep copy はされないからですね。 (edited)

Tについて、covariantなのかcontravariantなのかが宣言できれば、無理なく機能を追加出来そう。今やろうとすると、Generics型の変数と関数と場合によってはextensionすらチェックして、covariantかcontravariantなのかを判断することになるのかな、無茶っぽい。

11:55 AM

covariantなら、covariantなGenerics型と変数と返り値がTな関数が通る。 contravariantなら、contravariantなGenerics型と引数がTな関数が通る。

11:55 AM

これであってるだろうか…

ああなるほど、Array<T>がいけるのに、任意のFarm<T>がダメなの、完全にクロージャがあり得るからだ

1

12:18 PM

functionならパラメータ書き換えて安全に動くけどクロージャは無理だ

12:23 PM

と言うことは、stored propertyに関してのみ変性を確認すればokなはずで、であれば宣言無しでも現実的な時間に収束し得るかしら？

@tarunon >Tについて、covariantなのかcontravariantなのかが宣言できれば、無理なく機能を追加出来そう。 C#やkotlinのdeclaration site varianceがまさにそういう設計ですね class Box<out T> {} みたいに、 Tの前に in か out をつけられる (edited)

そうすると、引数のTをコンパイルエラーにできる

オーバーライド可能なメソッドの返り値部分はそのままで、引数部分はcovariance/contravarianceが反転する

正負の数としてイメージしたら解りやすいな、Out Tで、functionの引数にcontravarianceなTを入れるのはok

http://docs.scala-lang.org/tutorials/tour/variances.html class Foo[+A] // A covariant class class Bar[-A] // A contravariant class class Baz[A] // An invariant class

12:46 PM

scalaはまさにそんな雰囲気の文法

12:47 PM

[ ] は < > だと思えばOK

おおーー超解りやすい

12:47 PM

最高じゃん

マジかあｗ

概念的にはまさにこれだ

12:48 PM

俺の脳内イメージにピッタリあったw過去最高に理解できた

（マジかあの意図は僕がkotlin派だからです) (edited)

Mirror って積極的に使っても良いものなのだろうか？

リフレクションエンコーダーで結構使ってます

1

Farm が Generic なクラスを持ってたらだめってことでした。

なるほどー。↓値型のままだとわかりづらいので struct とイミュータブルクラスは等価だから書き変えて、 variance annotation ( out ) を付けて考えると Fence の animal がコンパイルエラーですね。 setter が許容できない。

class Animal {} class Cow : Animal {} class Sheep : Animal {} class Fence<out T> { var animal: T? = nil // コンパイルエラー } class Farm<out T> { let fence: Fence<T> = Fence<T>() } func buySheep(farm: Farm<Animal>) { farm.fence.animal = Sheep() } let farm = Farm<Cow>() buySheep(farm: farm as Farm<Animal>)

↓Kotlinでやってみた。

// Kotlin open class Animal() class Cow : Animal() class Sheep : Animal() class Fence<out T> { var animal: T? = null } class Farm<out T> { val fence: Fence<T> = Fence<T>() } fun buySheep(farm: Farm<Animal>) { farm.fence.animal = Sheep() } fun main(args: Array<String>) { val farm = Farm<Cow>() buySheep(farm) }

予想通り Fence の animal でコンパイルエラー。

$ kotlinc NestedGenerics.kt NestedGenerics.kt:6:17: error: type parameter T is declared as 'out' but occurs in 'invariant' position in type T? var animal: T? = null ^

セッターもそうなるのか

3:51 AM

そうか、そうですね。

out な型パラメータは引数でつかえず、 in な型パラメータは戻り値で使えません。

3:51 AM

が、 contravariant なパラメータは反転するので、 Foo<in T> だったときに

セッターに関して言うと、外から処理が差し込まれるわけじゃないので

3:52 AM

Arrayと同じような扱いにしてしまっても

out T の型の中で Foo<T> を引数として使うことはできます。

問題はないのでは、と思っていた

引数や戻り値に関数型が来る場合も簡単で、 (T) -> U を Function<in T, out U> と読み替えれば OK です。

お、 Swift でも T について covariant な Foo<T> （ Foo<out T> のように振る舞う）を作ることに成功した。

typealias Foo<T> = () -> T class Animal {} class Cat: Animal {} let a: Array<Foo<Cat>> = [] let b: Array<Foo<Animal>> = a // OK

見た目がそれっぽいだけw

それっぽいだけですが、 variance の挙動は確認できますね。

class Animal {} class Cow : Animal {} class Sheep : Animal {} class Fence<T> { var animal: T? = nil } typealias Farm<T: Animal> = () -> Fence<T> func makeFarm<T: Animal>() -> Farm<T> { return { Fence<T>() } } func buySheep(farm: Farm<Animal>) { farm().animal = Sheep() } let farm: Farm<Cow> = makeFarm() buySheep(farm: farm) // Fenceがinvariantなのでfarmもinvariantでコンパイルエラー

おおー

Fence を covariant にしようとして typealias Fence<T> = () -> T? にすると、今度は animal を var にできません（ Fecce の T が out である制約が効いていると解釈できる）。

OptionalをAnyに突っ込むと、Mirrorでしかnilかどうかチェックできないっていうのもあって、この間うちの人がハマってた

値型の variance 、どう考えたらいいのか難しいと思ってたけど、イミュータブルクラスに変換して、 mutating func は static メソッドに読み替えれば解釈できそう。 ↓ Array は covariant にできる

class Array<out E> { func get(_ index: Int) -> E { ... } static func set<E>(_ this: Array<E>, _ index: Int, newValue: E) -> Array<E> { ... } }

けど、 Fence は covariant にできない。

class Fence<T> { var animal: T? = nil } class Farm<out T> { let fence: Fence<T> = Fence<T>() // Fence が T について invariant なのでエラー }

CoWだから実際の動きもこれに近いですよね

4:33 AM

Fenceは

4:35 AM

class Fence<out T> { func getAnimal() -> T? { ... } static func setAnimal(_ this: Fence, newValue: T?) -> Fence { ... } }

このように定義しておけば、 Farm<out T>も成り立ちそう。

↑だと Fence が struct と等価になってしまって、最初の「不整合」なケースの前提が崩れてしまいます。逆に言えば、 Fence も struct なら struct Farm は covariant 的に振る舞っても問題ないということですね。 (edited)

4:38 AM

ちなみに、 Java の配列は variance 周りがぶっ壊れてるので、コンパイルエラーで検出できずに実行時エラーになる。

class Animal {} class Cat extends Animal {} class Dog extends Animal {} public class CovariantArray { public static void main(String[] args) { Cat[] cats = { new Cat() }; Animal[] animals = cats; animals[0] = new Dog(); // 実行時エラー System.out.println(cats[0]); } }

private extension Hoge: FugaProtocol {} こういうのできたらいいのになーって思ったことないですか

7:33 AM

'private' modifier cannot be used with extensions that declare protocol conformances

FugaProtocolの種類によってはObjCではよく思った

7:35 AM

例えば MainViewController : UITableDataSource みたいなのは、自分で持ってるTableViewに繋ぎこむだけの場合

7:35 AM

UITableDataSourceとして他のところでMAinViewControllerを使われても困るから

7:36 AM

特にそのconformanceを公開したい意図は無い

そんなかんじ

Swiftの場合もし徹底したければ、そのプロトコルを満たしたAdapterオブジェクトを作ってhas-aにするかな

やっぱそれしかないよなあ

それで外からは非対応に見える

7:37 AM

ObjCならimplementsを.mの方に書けばそうなった

7:37 AM

C++はprivate継承っていうまさにそれをやる機能があったりする

↓はどうでしょう？ fileprivate protocol Foo { func foo() -> Int } extension Int: Foo { fileprivate func foo() -> Int { return self } }

手元でのケースは、一応複数のVCに対して適合させたいプロトコルなのでプロトコル自体をfileprivateにするのはう〜んってかんじがしますね

7:39 AM

Protocol conformanceをprivateにできたらいいなあというのはそれそのものをprivateにしたいというのとは別に、「プロトコルで実装が強制されるプロパティをprivateにしたい」というのもある

7:39 AM

protocol extensionからprivateが見えないからどうにもならない感じはする

プロトコルは外から見た制約だからprivateで満たすっていうは変な感じ

プロトコル、外からどう見えるかというのもそうなんだけど、共通の実装を強制するみたいな側面もあると思っていて、そうすると外に見せる必要はないんだけど内部でこのプロパティは必要だから置いておいてねというのができたい

あーでも発想としては同じなのかな。Selfスコープだけでみたときにはselfをその型として渡せるって感じかな

今プロトコルは internal で、それをある特定のファイルの中だけで満たすよう（ fileprivate ）にしたいというニーズということですか？

共通の実装を強制するみたいな側面

うーんなんかアンチパターンを感じる

大体そうです

7:42 AM

koherさん

XxxMixIn とか XxxImplHelper みたいな形にしておいて必要部分のクロージャーを受け取るようにしてhas-aで持つとか。 (edited)

protocol Hoge {} private protocol PrivateHoge { var xxx, yyy, zzz } extension Hoge where Self: PrivateHoge { ... } (edited)

7:44 AM

こういうのじゃダメなの

xxxとyyyとzzzをその適合してるクラスのそとから見えないようにしたいんだけどできるんだっけ

あー、そっち側があったか。その xxx とかつけるの逆に考えてて（ Hoge につけるの考えてて）、だめだなぁと思ってた。 (edited)

private protocol Testable { var test: Int { get } } extension MyVC: Testable { fileprivate var test: Int { return 1 } }

7:46 AM

ここまでならいけるっぽい

要は「別ファイルにあるexntensionから見える」というアクセス修飾子があればいいだけな気がしてきた

7:48 AM

またアクセス修飾子の話になってしまった

ちょっとぐらい見えすぎても大丈夫だよ！

やっぱだめだ。

7:49 AM

private protocol をより広い protocol が継承するのは変だ。

継承はしてないっすよ

7:50 AM

広いprotocolはfunctionを定義していて、private protocolはその条件になるあれやこれやを書いていて、その両方をimplしたらメソッドが生える

7:50 AM

それだけです

7:51 AM

逆にprivate protocolがpublic protocolを条件付けしていたほうが、もっとシンプルに書けるかもしれない。

元々の要望は Hoge を色んなところで使いたくて、それをある場所では private に使いたいという話だと思うんですが、

7:51 AM

そうすると PrivateHoge から Hoge に流す部分で、

7:52 AM

それを元々 Hoge が使いたかった箇所から可視にすることができない気がします。

ああ、本当だ読み間違えていた

7:52 AM

implを中で持つしか無いなぁ

7:54 AM

class MyViewController { class ScrollViewDelegateImpl: UIScrollViewDelegate { let parent: MyViewController } lazy private (set) var scrollViewDelegate: ScrollViewDelegateImpl = { [unowned self] in ScrollViewDelegateImpl(self) }() }

SE-0104 Protocol-oriented integers がmasterにマージされたんですね。 https://github.com/apple/swift/pull/3796#issuecomment-294096066 チューニングはこれからやりますと。

New integer protocols by dabrahams · Pull Request #3796 · apple/...

Work on integers from @moiseev What's in this pull request? Resolved bug number: (SR-) Before merging this pull request to apple/swift repository: Test pull request on Swift continuous integr...

マージされて羨ましい。apple/swiftへのPRが初めてマージされそうなのに、僕の変更と関係ないところでSwift Test and Mergeが通らなくてやきもき。

1

11:55 PM

Swift Test and Merge通ってなさすぎ。 https://ci.swift.org/view/Pull%20Request/job/swift-PR-merge/

Protocol-oriented integers には Comparable の変更含まれていないのね。 (edited)

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md マルチライン文字列リテラルがレビュー入り

http://twitter.com/hiragram/status/854871991228129280

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

ほしい

欲しいなぁ

1:16 AM

webViewからjs叩くとき、こういうのが欲しい

1:16 AM

みんなどうやってんだろ

+= でがんばってるんじゃない

シェーダーを書くときに欲しい

配列でそれっぽく書いてたりしました

配列なるほど

let str = [ "hello \(name)", "world" ].joined(separator: "\n") 配列はこうかな

1

🙌🐼 (@hiragram)

addDisposableToに変わって作られたdisposed(by:)ってAppleのAPI Design Guidelineに則ってなくない？

ｗ

@hiragram これめっちゃ気に入ってるんだけどマジ？

マルチライン文字列リテラルがレビュー入り

レビュー前からされてなかった？ Accepted なのでは？

1:40 AM

The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is accepted with revisions.

@omochimetaru 則ってね～じゃんと思っていて https://swift.org/documentation/api-design-guidelines/ の "Name Mutating/nonmutating method pairs" のところ

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035923.html

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

swift-evolution-announce] [Accepted] SE-0168: Multi-Line String Literals

1:41 AM

Acceptedだった。

ガイドライン通りに読むと hogeDisposable.disposed(by: fuga) は「fugaによってdisposeされたhogeDisposable」が返るってことにならんかなあとおもって

1:42 AM

hogeArray.reversed() と同じ

bindToがbind(to:)になったならaddDisposableToもaddDisposable(to:)になるのかなと思って見たらdisposed(by:)とかいうのが追加されてたのを発見したという感じ

Accepted with revisions だから修正が必要ってこと？

disposeBagによって後で dispose される だから確かに当てはまってないね、結果的に返り値とかもでないし

// Allowed, equal to "foo\nbar" """ foo bar """ // Not allowed """foo bar """ // Not allowed """ foo bar"""

1:45 AM

- The core team also believes that underindentation or inconsistent tab/space usage within the indentation should be an error. Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.

1:46 AM

インデントを含まないなら冒頭のスペースどうすんだろうと思ったんだけど、終わりの """ をベースに考えるってことかな？妥当な気がする。 (edited)

インデント気持ち悪いと思ったけど変数代入することを考えると悪くないか。

むしろインデントが含まれちゃう系のヒアドキュメントとか気持ち悪いと思ってたから良さそう。

var x = """ hogehoge """"

1:48 AM

最後の"""は一つ落としたい感じが

これは後ろの """ を左に寄せとけば、余計な事しない？

最後の"""は一つ落としたい感じが

そうだね。で、それができると。

一番左にベタ寄せのほうがコピペ安定性が高くて好きなんだけど

これは後ろの """ を左に寄せとけば、余計な事しない？

そうじゃないかな？

1:49 AM

どっちもできるという意味で素晴らしい。

そうだと嬉しい

Kotlin みたいなキモいことしなくていいのうれしい。

// Kotlin val text = """ |Tell me and I forget. |Teach me and I remember. |Involve me and I learn. |(Benjamin Franklin) """.trimMargin()

1:52 AM

閉じ """ でコントロールっておもしろいなぁ。

"""の中なら、"はエスケープしなくても良いのかな、可読性一気に上がりそう

assert( xml == """ <?xml version="1.0"?> <catalog> <book id="bk101" empty=""> <author>\(author)</author> <title>XML Developer's Guide</title> <genre>Computer</genre> <price>44.95</price> <publish_date>2000-10-01</publish_date> <description>An in-depth look at creating applications with XML.</description> </book> </catalog> """ )

1:53 AM

提案がこうなってるし DQx2は書けるっぽい

サイコーだ

1:54 AM

それも踏まえた上での3つか

っぽい

// Allowed, equal to "foo\nbar" """ foo bar """ は "foo\nbar\n" ではなく "foo\nbar" なのか。

うん、そこがミソじゃない？

@norio_nomura 主流派とは違う感じがしますね

あ、 @omochimetaru かと思ったら @norio_nomura さんだったｗ

失礼ですぞ

失礼しましたｗ

お？

必ず最終行に """ を書かせることでインデントをコントロールできるところがミソかと。

後ろで揃える以上強制で\n入るのは微妙そうですしね

@t.ae いや、他の言語だと """aaa bbb""" これで "aaa\nbbb" になる。

1行目インデント揃えれないの辛そう

はい。それでswiftの仕様だとそれができないので

うん、なので、 Swift の閉じ """ でインデントと本文を区別させる方式なら

1:57 AM

最後に "\m" を入れるわけにはいかない。最後の "\n" を消す方法がなくなっちゃうから。

まさにそれが言いたかったことです。

let s = """ abc def """ 今の仕様ならこれで末尾 "\n" が実現できるし。

納得

Kotlin みたいな trimMargin もいらないし、これはうまい仕様だなぁ。

SwiftLintのテストケース書くのが一気に楽になる。

いちいちファイル用意しなくて済みますね

↓これどゆこと？？

- The quoted string should normalize newlines to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.

// equal to "foo\nfoo\nfoo\nfoo" """^J foo^M^J foo^J foo^M foo^M """

ソースコードの改行コードによらず \n に正規化する

^J とか ^M とか何？

^M が \r で ^J が \nのエスケープ表記かな？

ああ、どっかに書いてあるのか？

gitのdiffで見る

2:04 AM

いや、なにかの流派におけるエスケープ表現　シェル系のだと思う

2:04 AM

詳しくは知らない

あー、これを書けるようにしようというわけではなく、改行文字を表すためにここに書いてるだけってこと？

そう

2:04 AM

見えない文字を表現したくてそうなってる

vimで改行コード不揃いのファイル開いた時に見たりする。

2

なるほど。

@hiragram disposed(by:)、本当はisDisposed(by:)が正しいんだと思う。

@tarunon isつけたらBool返す系になっちゃわない？

そう、だからis抜いて意味がわからなくなった

2:09 AM

経緯見てないからわからんな

メソッド自体は Disposable を DisposeBagに突っ込む機能だよ

Disposableが何を契機にdisposeするのか、とも取れる

2:10 AM

disposeBagはdisposeを発火するための装置、であれば、まあ納得かな

ガイドラインには反してないと考える？

ガは無理して正しい英語にしなくても…みたいなの書いてなかったっけ?

2:13 AM

それならまあうん

Name functions and methods according to their side-effects / Name Mutating/nonmutating method pairs には、変更して新しい値を返すやつは受け身系にしろ、みたいに書いてあるんだけど

2:15 AM

受身形は変更して新しい値を返すやつである、っていう逆方向は明言されてないからセーフ　なんじゃないか

2:15 AM

と俺は思った。

変更されたprを探してる、iPhoneでgithub漁るの難しい

2:15 AM

あった

2:16 AM

https://github.com/ReactiveX/RxSwift/pull/1079

Add better API for Disposable when adding to DisposeBag by andyyhope · Pull Request #1079 · ReactiveX/RxSwift

Added I brought up in the Slack channel that the original Disposable API .addDisposableTo(_ bag: DisposeBag) felt out of line with the newly minted Swift API guidelines. Because an Observable retur...

@omochimetaru そこの文章ですけど

slack見に行かないと議論の内容がわからないw

mutating/non mutatingのペアの時にはそうしろって限定されてるんじゃないかと前@koherと話しました

@t.ae 片方しか無いなら命令形のまま新しいインスタンスを返しても良い？

2:17 AM

将来的な追加が予測できる以上結局ペアを想定しないといけない気がする (edited)

そうですね

2:18 AM

disposed(by: )についてはペアがでてこなそうなのでこれで良い気もする。

2:18 AM

そもそもmutatingな何かじゃないし

そもそもこの話の枠外になるよね　同意見

それはそれとして、Sequence.filterはどうするんやろ、ってずっと思ってる

2:20 AM

filtered?

なんかそこについては例外条項があるって @koher が言ってた

2:20 AM

filter みたいにあまりに有名なやつは特別

例外、なるほど

うげ〜 SwiftのコードをObjCから見たら、 Error型がNSError型に見えてる

2:41 AM

URLがNSURLに見えるのとかは整合性取れるからいいけど、 ErrorとNSErrorはおかしくねえか・・・

Error NSErrorウッ頭が

2:42 AM

全部NSErrorに変換できることになってるからまあわからんでもない

ObjC互換のための暗黙的変換だったりするんですかね

暗黙的変換(変換できるとは言っていない)ですね

2:43 AM

治ったのだろうか

2:44 AM

8.3.2で確認したけど修正されてるみたいだった

1

2:46 AM

ErrorからNSErrorに強制的にキャストがかかる例のアレは未修正だった

2:46 AM

おこ

macOSとLinuxで結果が違った(tarunonさんの検証コード)

import Foundation protocol MyCustomErrorProtocol: Error { var hoge: Int { get } } struct MyCustomError: MyCustomErrorProtocol { var hoge: Int { return 1 } } extension NSError: MyCustomErrorProtocol { var hoge: Int { return -1 } } let error: Error = MyCustomError() if let cError = error as? MyCustomErrorProtocol { print(cError.hoge) // macOS: -1, linux: 1 }

(edited)

LinuxにはNSErrorが無い？

あるよ

3:22 AM

Objective-Cが無い

なるほど

NSErrorがSwiftで実装されてる。

ほ〜！

3:24 AM

いや、そりゃ当然の帰結としてそうか

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSError.swift#L42

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

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

witness tableがいつ作られるのか気になって色々試してたら面白いのみつけた

10:56 AM

where_is_witness_table.swift

27行目は as Foo なのに FooStandardに準拠してることになってる？

FooFatalが消えた

それもそうだけど

28？

あ〜

だから

10:59 AM

subclassが噛んだ瞬間にWitness tableが崩壊してるように見えている

class Aの実装として extensionが動的に注入されてる？

15行目で、より厳しい制約があるので、FooStandardがあるかは問題じゃないはずだが

FooFatalのほうが無視されるのは

11:01 AM

静的な拡張としてしか扱われてないからなんじゃないかな

11:01 AM

これ１年前のtryswiftでたるのんが言ってたやつの仲間な気がする

11:01 AM

俺の予想だと

それは思う

class Aについては、Foo x FooStandardの組み合わせによって、 Aのメソッドとして

11:01 AM

fooが実装されてる

てか、

class Bについては、fooはオーバライドされてなくて

struct B: Foo, FooStandard, FooFatalだと、コンパイルすら通らない

FooFatalのwhere付きの静的な条件で、Bの型が見えてるときだけ

11:02 AM

静的ディスパッチでそっちが呼ばれる

extensionで実装書くとwitness tableには関係しないのかなーと

だから27行目も28行目もas Fooになった時点で、Foo型のexistanceとしてAやBのインスタンスがブリッジされてて

11:03 AM

Bの方はオーバーライドされたわけじゃないから、helloが出る

FooStandardは探せるのに、FooFatalが探せてないのが気になる

FooFatalは

11:04 AM

型がBとして確定したときしか

11:04 AM

見えない

11:04 AM

FooStandardは見つかってないんだけど

11:04 AM

Fooのfooとして読んでるだけで

11:04 AM

ただその実装がAにインストールされてる

11:04 AM

じゃないかなあ

ふーむ

11:04 AM

struct B: Foo, FooStandard, FooFatal {} こっちはコンパイル通らないし

11:04 AM

それはそれとしてなんか普通に壊れてる気がする

それだと、FooStandardとFooFatalの両方見つかる結果

11:05 AM

extensionが両方みつかって

いやいや

11:05 AM

厳しい方優先すればいいでしょ

どっちの実装をぶち込むか決められないんじゃない？

extension Foo where Self: FooStandard vs extension Foo where Self: FooFatal

11:05 AM

これならどっち優先かわからない

25行目のケースでfatalが出るってことは、

あ、ごめん

11:06 AM

privateついてるせいだった

厳しい方が優先っていうルール自体は存在してるのか

FooFatalにprivateあるせいで

11:07 AM

要らんエラー履いてた

a~

Structは通った

このprivate見てなかった

11:07 AM

てか、private protocol、この前も出てきたけど意味がよくわかってない

11:07 AM

何がprivateになるの

ファイルの中でしか使えなくなる

ファイルなんだ。

一番外側のprivateはfileprivateと一緒

1

11:08 AM

てか

11:08 AM

class Bにprivate protocol生やしても動くのは

11:08 AM

あー見えなくてもいいからか

FooFatalをprivateではなくしても

11:13 AM

結果は同じだなあ

11:15 AM

sil_witness_table hidden AAA: Foo module a { method #Foo.foo!1: @_TTWC1a3AAAS_3FooS_FS1_3foofT_SS // protocol witness for Foo.foo() -> String in conformance AAA }

作られてない?

11:17 AM

なんとなくそんな気はしたけど

AAAのFoo conformanceが↑のテーブルで、fooメソッドとして _TTWC1a3AAAS_3FooS_FS1_3foofT_SS が入っててそれが内部で、 _TFe1aRxS_3FooxS_11FooStandardrS0_3foofT_SS を呼ぶようになってる

11:18 AM

_TFe1aRxS_3FooxS_11FooStandardrS0_3foofT_SS は、 A が // Foo<A where ...>.foo() -> String のwhereを満たしてる時ようのメソッド

11:19 AM

sil_vtable AAA { #AAA.deinit!deallocator: _TFC1a3AAAD // AAA.__deallocating_deinit #AAA.init!initializer.1: _TFC1a3AAAcfT_S0_ // AAA.init() -> AAA } sil_vtable BBB { #AAA.init!initializer.1: _TFC1a3BBBcfT_S0_ // BBB.init() -> BBB #BBB.deinit!deallocator: _TFC1a3BBBD // BBB.__deallocating_deinit }

11:19 AM

AとB自体はメソッドとしては保持してなかった。

11:19 AM

あくまでAがFooとしてアップキャストされるとき用のwitness-tableにfooの実装として hello の実装が入ってる

11:20 AM

FooFatalの方のwitnessは無さそう

11:20 AM

BがFooになるときは、親のAと同じ挙動でFooのExistanceになるっぽい

1

11:21 AM

(FooFatalのprivateは外した状態で試した。わかりやすいようにAAAとBBBにリネームした。

やっぱりsubclass絡んだwitness tableは暗黒界だ

親クラスが満たすプロトコルとしてのExistanceはサブクラス側では作られないってことじゃないかな

11:22 AM

sil_witness_table hidden AAA: Foo module a { method #Foo.foo!1: @_TTWC1a3AAAS_3FooS_FS1_3foofT_SS // protocol witness for Foo.foo() -> String in conformance AAA } sil_witness_table hidden AAA: FooStandard module a { } sil_witness_table hidden BBB: FooFatal module a { }

11:22 AM

AAAのFooStandard witnessはあるけど、BBBのFooStandardはない

11:22 AM

一方BBBのFooFatalはある

むむむむ

割りと一貫したルールな気がする

11:23 AM

「あるクラスが定義される時、それが満たすプロトコル全てに対してwitness-tableを作るが、例外として、親クラスで既にそのプロトコルについてのwitness-tableが作られているときは、作られない」

11:25 AM

１年前のやつは、その時に、クラス側にもメソッド定義があれば、それがvtableエントリに入ってきて、オーバーライドが働くっていうケースも混ざってた

11:26 AM

http://qiita.com/omochimetaru/items/17cdbb5a77972c82a781

Swiftのプロトコルエクステンションの罠 - Qiita

try-swiftで知り合った @tarunon さんから面白い話を伺いました。以下、Xcode 7.2.1 (7C1002)の環境での話です。

結論

どうしたらいいかわかりません。。

本題

下記のように、エクス...

11:26 AM

↑当時のまとめ

これ確かバグ報告出した奴だっけか

11:27 AM

なんかこの辺無限に見つけてて、どれがどれかわからん

11:28 AM

これは仕様っぽかったからスルーしたんだ

11:28 AM

ちょいまっち

11:29 AM

アトラシアン

iPhoneから全く操作できない

てか、仕様が明文化されてないから

11:31 AM

コンパイラクラッシュ以外は

ああ、これのうち、後ろ2つについて報告したんだ

11:31 AM

親クラスの宣言の有無で切り替わる奴

実装が仕様なんじゃね

実装が仕様w

お返事あった？

なんかワイワイやってるっぽい

11:32 AM

https://bugs.swift.org/browse/SR-103

11:34 AM

Doug Gregor氏がこれはバグだろうけど破壊的変更だからevolutionに乗せないとなみたいなこと書いてる気がする

ほんとだ

11:35 AM

エボリューションプロセスで整理するって流れっぽい？

最後の書き込みが、「やるけど明日からバカンスだぜ」(悪意のある翻訳)に見える

11:37 AM

4でprotocol周りやるからこれと向き合わないと死体増えそうな気がするけど大丈夫なのかな

クラスに関しては open にしない限りサブクラス系の問題はモジュール内で解決できちゃうし、基本 open はよっぽどの理由が無い限り使わないように、ってことになってるので、プライオリティは低い気がしますねぇ。

継承周りはおざなりな感じありますね

今日 master から 4.0 への無条件マージの期限が 6/1 に切られたので、それ以降に source breaking な変更が4.0に入ることはなさそう。

ふむふむ

あと1ヶ月ちょいってこと考えると、厳しいと思います。

やるなら手前でやるしかないかぁ、6月1日は無理ぽ

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170417/004405.html

結局iOSでコード書くと、classと継承は避けては通れないので

11:47 AM

この手の挙動とどう折り合いを付けていってるのか凄い気になる

Swiftが最も使われてるのは間違いなくiOSアプリ開発だけど、SwiftはiOSを重要視してない感があるなぁ。値型中心の世界を作ろうとしてるし、SwiftPMはiOSサポートしてないし。

まだ見れてないままだけど↓とか気になってる。 https://developer.apple.com/videos/play/wwdc2016/419/

-emit-irを使うとメソッドにどのwitness tableが渡されてるかわかるぽい。 callFoo(B()) // hello

%112 = call { i64, i64, i64 } @main.callFoo <A where A: main.Foo> (A) -> Swift.String(%swift.opaque* noalias nocapture %111, %swift.type* %21, i8** getelementptr inbounds ([1 x i8*], [1 x i8*]* @protocol witness table for main.A : main.Foo in main, i32 0, i32 0))

class C: Foo, FooStandard, FooFatal {} callFoo(C()) // fatal

 %122 = call { i64, i64, i64 } @main.callFoo <A where A: main.Foo> (A) -> Swift.String(%swift.opaque* noalias nocapture %121, %swift.type* %118, i8** getelementptr inbounds ([1 x i8*], [1 x i8*]* @protocol witness table for main.C : main.Foo in main, i32 0, i32 0))

(edited)

Swift 4.0のCHANGELOGにこんなのが https://github.com/apple/swift/blob/master/CHANGELOG.md

SR-1529: Covariant method overrides are now fully supported, fixing many crashes and compile-time assertions when defining or calling such methods. Examples:

class Bed {} class Nook : Bed {} class Cat<T> { func eat(snack: T) {} func play(game: String) {} func sleep(where: Nook) {} } class Dog : Cat<(Int, Int)> { // 'T' becomes concrete override func eat(snack: (Int, Int)) {} // 'game' becomes optional override func play(game: String?) {} // 'where' becomes a superclass override func sleep(where: Bed) {} }

(edited)

https://twitter.com/tarunon/status/853241961670557697

swift - The Swift Programming Language

↑今でも問題なくコンパイルも実行もできる気がします・・・

なんかこれおかしくないか？

2:46 AM

Dog is Catだから、 DogのインスタンスはCatとして振る舞えなきゃいけなくて

2:46 AM

CatはsleepメソッドでNookを受け取る (edited)

2:46 AM

DogはSleepメソッドをオーバーライドしてるけど

問題ないでしょ？

2:47 AM

引数については contravariant だから。

2:47 AM

より広い値を受ける分には問題ない。

せまいですよ

2:47 AM

ああぎゃくか

2:47 AM

親のほうが広いのか

それにしても Dog: Cat ってカオスｗ

じゃあ、playがおかしくない？

2:47 AM

いや、これはいいな

String? の方が広い。

いいのか。Nook < Bed で STring < String?か

うん。

引数のオーバーライドがちゃんとcontravariantならJavaより正しいな

2:49 AM

でも、広くするってことは

これを " Covariant method overrides" っていうのは正式な用語なのかな？ Contra な引数に広いものを渡すのは - * - = + で Covariant ってこと？

親で func foo(cat: Cat) と func foo(dog: Dog)　のとき

2:49 AM

サブで func foo(animal: Animal) としたら

2:49 AM

Cat < Animal と広げたのか Dog < Animalと広げたのか

2:50 AM

曖昧になりそう。両方を同時にオーバーライド？

↑Swiftならラベルで区別されちゃうｗ

あ〜そっか。

ラベルも同じだったらどうなるんだろ。

じゃあラベル省略されてるとき。

2:50 AM

その場合はエラーでもまあ

2:50 AM

概ねラベルで分離できるなら困りはしないな

オーバーロードがあるとそこややこしいんだよね。

2:51 AM

Java だとオーバーライドで引数を広げようとしたらオーバーロードになるんだっけ？

元のissueのコードを試すと確かにクラッシュする。 https://bugs.swift.org/browse/SR-1529

import Cocoa class CrasherBase: NSView { var hasRect: Bool = false var rect: CGRect? { return hasRect ? CGRect(x: 0, y: 0, width: 50, height: 50) : nil } override func draw(_ dirtyRect: NSRect) { NSEraseRect(dirtyRect) } } class Crasher2: CrasherBase { override var rect: CGRect { return CGRect(x: 0, y: 0, width: 100, height: 100) } override func draw(_ dirtyRect: NSRect) { NSEraseRect(rect) } }

ほんとだ。クラッシュしました。

4:08 AM

あれ？↓はいける。 class Animal { var foo: Int? { return nil } } class Cat: Animal { override var foo: Int { return 42 } } (edited)

引数の反変だとoverrideでうまく動くけど返り値の共変だと死ぬのかな

4:09 AM

あー

4:09 AM

setterがあるからそんな単純な話じゃなかった

なんで↑はクラッシュしないんだ？？

そもそも@norio_nomuraさんが貼ったコードの Crasher2#drawを消したらクラッシュしないんですが

4:16 AM

いやゲッタ呼び出し段階の話かな？

NSEraseRect(rect) がミソですね

ああ、

4:19 AM

たぶん@koherと同じ勘違いしてましたね

あー、そっちなのか。

4:22 AM

↓死んだ。

class Animal { var foo: Int? { return nil } } class Cat: Animal { override var foo: Int { return 42 } func useFoo() -> Int { return self.foo * 2 } }

4:25 AM

func でもダメだ。

class Animal { func foo() -> Int? { return nil } } class Cat: Animal { override func foo() -> Int { return 42 } func useFoo() -> Int { return self.foo() * 2 } }

(edited)

class Animal { func foo() -> Int? { return nil } } class Cat: Animal { override func foo() -> Int { return 42 } } Cat().foo() * 2

↑外で呼んでもダメですね

4:28 AM

そもそもfooの呼び出しがどうやっても死ぬ

あー、確かに昔 Optional とサブタイピングについて調べてたときに踏んだ気がする。継承で戻り値狭められるから Foo は Foo? のサブタイプ扱いされてますねって話で、でもメソッド定義するだけじゃなくて使おうとしたらすぐ死んでた気が。

class Animal { func foo() -> Int? { return nil } } class Cat: Animal { override func foo() -> Int { return 42 } } let f = Cat().foo f()

↑回避できた

ｗ

Cat.foo(f)()だと行けるかと思ったけど死んだ

@tarunon さんはよく Foo が Foo? に暗黙の型変換されるのを邪悪だと言ってますが、オーバーライドで戻り値を Foo? から Foo に狭められるなら Foo は Foo? のサブタイプでないといけないわけで、それなら Foo? 型変数に Foo を代入するのは暗黙の型変換ではなくアップキャストとみなせるわけですが、それについてはどうですか？

うーん、このオーバーライド自体邪悪っぽい気がしていて

4:32 AM

いや、ダメでしょ…という感じがする

Foo と Foo? のサブタイピング自体が邪悪ってことですね。

そうです

そうなんですよねぇ・・・

4:33 AM

Swift の Optional は Tagged Union なんだから本来サブタイプじゃないはずなんですけど、サブタイプ的にに振る舞わせることで、 Untagged Union で作られた Optional みたいになっちゃってるんですよね。

Nullセーフになったのはまあそうなんですが

Ceylon とかだと Foo? は Foo|Null という (Untagged) Union になってて、当然 Foo は Foo?` のサブタイプなんですけど、

Optionalセーフ?(と言って良いのかわからないけど)の域にはたどり着けない感

Swift は Tagged Union だから Foo?? とかもできるわけだし、サブタイプ的に振る舞わせるのが微妙ですよねぇ・・・。

4:35 AM

だから、オーバーライドで Foo? を Foo に狭めるのも、代入時の暗黙の型変換も全部なしってのがシンプルな気がする。今更無理だけど。

それだなあ。 TaggedUnionだとおかしくなる

SwiftのOptionalに関しては、この暗黙のサブタイピングと

4:35 AM

uounɹɐʇ (@tarunon)

ぶっちゃけSimpleDomainErrorも、それ単体でErrorが解ればいい、でOptionalにしがちだけど、プログラムって必ず組み合わせて使うんだから単体では単純で良くても組み合わせたときのことを考慮するとErrorを吐くのが妥当、だよなぁ、って。 #swtws

4:35 AM

ここからの一連の議論の内容

4:36 AM

そこさえなんとかなれば

4:36 AM

Optionalを使うことに関して、変に気を使う必要が全くなくなる美しい世界が来ると考えていて

4:36 AM

遥か遠い理想郷

C++でOptional自作して使ってるけど、毎回 Some(x) で包むので特に不便感じない

あ、そうだ。それなんですけど、書こうと思ってて忘れてました。 Twitter に書いた方が後から見やすいかもですが、 SimpleDomainError が throws じゃダメな理由がわかりました。

4:37 AM

純粋な値がない Optional と Simple domain error が区別されることも意味がありますが、 Simple domain error が Recoverable error と区別されることにも意味がありそうです。

4:37 AM

なぜなら、

4:38 AM

struct SimpleDomainError: Error {} は、当然ですが Simple domain error なので、エラーが発生したという情報しか持たないわけです。

全ての型で同じSDE型使ったらカオスにしかならないですが、そこはextension Int { struct SDE: Error {}} とか (edited)

4:40 AM

最低でも何の型でのSDEなのかは区別するべきでは

しかし、 throws というのはエラーを合成したり伝播したりして処理するために設計されているんで (edited)

RecoverableErrorとの混同より、Optionalとの混同のほうが

4:41 AM

煩雑さが増しますよ、経験則ですが

Simple domain error を Error にしてしまうとそういう風に使うことをミスリードしてしまうわけです。

4:44 AM

Simple domain error はエラー情報を持たないためにすぐに処理しないとわけがわからなくなってしまうので

であればFatalがそもそも正しいのでは、という気がする

Error のまま取り回したり合成したりすることを推奨するのは望ましくないと。

Optionalを扱うことにベストプラクティスを議論しなくていい世界観があるはずで、そこに到れるはず

4:45 AM

今日Intのベストプラクティスを議論する人が居ないのと同じように

なので、値がないことと Simple domain error を区別するためには、 enum Failable<Value> { case success(Value) case failure } を Optional とは別に作るのがいいかもしれません。

throw SDE optionalで型分けるんですね

はい

SDEとRecoverableErrorの区別を、普遍的に人が理解できるところまで到達できれば

4:47 AM

いけそう

4:47 AM

人類進化してくれ

ただ、個人的には複雑すぎる気がするし、値がないこととオペレーションの失敗を区別できないこともある気がするので（ array.first とか dictionary[foo] とか）

紛らわしいのはオーバーロードするなりして欲しいんですよね

4:48 AM

利用者側で決定付けれるはず

4:48 AM

なので

Error か Optional のどっちに寄せるかと言われると、個人的にはすぐ処理することが強制される Optional かなぁと思います。

SDEが情報を持ってないのが前提なのも良くない気がしていて

4:49 AM

Error型がそもそも、デバッグ時には発生時のコールスタック持てるとか

4:49 AM

そういう機能を有していれば、まあそれはそれで解決できると思うんですよね

Simple domain error を一切作らずに、すべてエラー情報を持った Error にするという世界もあり得るとは思います。 (edited)

僕の理想としては、

Simple domain error を一切作らずに、すべてエラー情報を持った Error にするという世界もあり得るとは思います。

これが一番近い

値がないかもしれない Optional か、 Error で表す Recoverable error か。

4:51 AM

ただ、 array.first とか array.max とかを Optional にするなら、それで消せるのって Int.init(String) くらいな気もするんですよね。

4:51 AM

純粋な Simple domain error ってほとんどない気がするから・・・。

Int8(Int64)とかも

4:51 AM

まあ結構ありますよ

まあ、変換系ですよね。

4:51 AM

conversion の失敗くらい？

すぐ処理することが強制される Optional

4:52 AM

これがイマイチわからない

4:53 AM

Optionalは別にすぐに処理することを強制してないですよ

プロパティに保持するのはいいですが、

4:53 AM

複数の Optional を合成しちゃうと出処がわからなくなって

出処がわからなくなったら困る状況になってるのが後手ではないですか?

デバッグするときに nil じゃないはずの値が nil になっちゃったときに、どれが元々 nil なんだ？ってのを探るのが大変

前も書きましたが、複数のIntを合成して、偶数になるはずが奇数になったのでどれが奇数だったかわからなくて困る

4:54 AM

本質的にはこれと一緒の事を議論している気がしていて

4:55 AM

実際にはそれとは差がある、その差を生んでるのがロジックエラーの混入なわけです

複数の Int を足して偶数を期待する状況は稀にしかおこりませんが、

4:55 AM

nil だと起こると思うんですよ。

4:55 AM

たとえば SwiftyJSON を使って JSON をデコードすると

4:56 AM

return curry(User.init) <^> json["name"] <*> json["age"] <*> json["gender"]

4:56 AM

みたいなコードを書いて、結果が nil だった場合にどのパラメータが nil だったんだ？みたいな。

それはErrorにするべきものをOptionalにしてるだけでは

4:57 AM

Himotokiはキーパス毎にErrorが出ます、なので困らない

でも本質的には同じじゃないですか？

いや、だからOptionalにErrorを混ぜると

4:57 AM

そういう問題が起こるんです

name: String? と age: Int? と gender: Gender? があるときに

4:58 AM

それが別に SImple domain error じゃなくて

4:58 AM

別の Optional プロパティからとってきたときかもしれないですよね？

4:58 AM

DB 上任意項目の name, age, gender があって

4:58 AM

そのレコードから取得してるかもしれない

発生場所がバラバラなら、発生場所毎にデコード処理なりなんなりあるわけで

struct UserRecord { var name: String? var age: Int? var gender: Int? }

そこできっちりErrorを生成すればいい

4:59 AM

そもそもUserRecordのそれらの値が

4:59 AM

クライアントサイドの型的にもOptionalが許容されているなら

4:59 AM

合成で問題が起こるはずがない

とか、 json が json じゃなくて record という Dictionary かも。

5:00 AM

いや、なので本来的には

5:01 AM

guard let name = record["name"] else { throw ... } guard let age = record["age"] else { throw } guard let gender = record["gender"] else { throw } return User(name, age, gender)

(edited)

5:01 AM

とすべきだということです。

うーん

これが Optional をすぐに処理すべきという話。

例えばDictionaryの添字アクセスがErrorだったら

5:01 AM

その辺がもう少し書きやすくなるんで

5:01 AM

まあオーバーロードで、用途によってですね

5:02 AM

適切に使えたほうが良いなあということです

オーバーロードでというのは、↓みたいなのがほしいということですか？ extension Dictionary { subscript(key: Key) throws -> Value { ... } }

ですです、

5:05 AM

do { return try User(record["name"], record["age"], record["gender"]) } catch { throw User.Error.decodeFail(error) } (edited)

5:05 AM

こうなりますよね

5:05 AM

スッとする

5:05 AM

tryがある時にErrorになってくれて、それ以外はOptionalみたいな

5:06 AM

まあそういう機能があって、この微妙な境界線をですね

5:06 AM

サーッと解決してくれたら嬉しいなって

5:06 AM

そういう話です

そもそもUserRecordのそれらの値がクライアントサイドの型的にもOptionalが許容されているなら合成で問題が起こるはずがない

これはそうとも言えなくて、アプリ全体では User 各プロパティに nil が許されているけど、特定の機能に関してはすべて非 Optional なプロパティをもった CompleteUser が求められているかもしれないです。そういうときに User から CompleteUser を作るのも同じ話になります。

5:07 AM

僕がすぐ処理すべきと言っているのは値がない意味でプロパティに持つなということではなくて

5:07 AM

それを使う側の関数のローカルスコープで長々と保持するなということですね。

うーん

5:08 AM

まあOptionalから値取り出して使うならそうなんですが

逆に Optional をローカルで取り回したいケースってどういうときがありますか？

OptionalはOptionalとして使うから

5:09 AM

普通にNullableなモデルとして使いませんか?

プロパティを nullable にするのはわかりますが、関数ローカルで nullable なまま取り回さないといけないケースって稀だと思うんですよね。

5:11 AM

もしその nullable を合成しちゃったら結局出処がわからない問題になっちゃうし

5:11 AM

合成しないならどうぜ後で処理しなきゃいけないからすぐに処理すればいいし。 (edited)

5:14 AM

Optional な引数に渡す値を作って、可読性のために一度変数に代入したいときとか？

ヌルのまま取り回していいのは

5:15 AM

合成結果が意味的にヌルで正しい場合だけで

5:15 AM

途中で出てくる

5:16 AM

その文脈においてエラーであるはずのほうの

5:16 AM

ヌルを混ぜちゃいけない

合成結果が意味的にヌルで正しい場合

っていうのは、それを Optional としてそのまま使いたい場合、つまり、何かの引数に渡したい場合ってことであってる？

と思う

です

どういうケースがあるかなあたとえば、ユーザーがペットを持ってる時に

えっと、 Simple domain error の話はとりあえずおいておいて、たとえ「値がない」という意味の Optional であったとしても関数ローカルではすぐにハンドリングすべきというのが僕の考えで

ペット？を渡す関数に

5:18 AM

ユーザーがヌルの時もペットがヌルとしちゃっていい場合(表示とか

5:18 AM

まあこれは合成といっても?.で済むけど

@omochimetaru つまり、やっぱり引数に渡す場合ってことやんね？

たしかに？

5:19 AM

何かの引数に渡さない事ってあるか？

引数に渡す場合はあり得ると思う。

5:19 AM

nil かどうかで分岐して何か処理する場合。 < 引数に渡さない場合 (edited)

なるほど

5:20 AM

確かにそのような分岐を含んだ関数を定義する意味は無さそうだから呼び出し前の分岐になる

普通に、ユーザデータが全部入力されて、そしたらButtonが押せるようになるとかも

5:20 AM

Optionalの合成ですが特に何も考えなくて良い例ですね

分岐の中にはエラーを発生させるというのもあって、たとえ「値がないかもしれない」 Optional であったとしても、その値が nil の状態で実行するとその処理としてはエラーとして Error を throw するとかはあり得る。

でもこの場合は入力されてないのはErrorとして扱いたいな

5:22 AM

Validationに食わせる時にErrorになるか

普通に、ユーザデータが全部入力されて、そしたらButtonが押せるようになるとかも Optionalの合成ですが特に何も考えなくて良い例ですね

このまえのベストプラクティスに書いたとおり、 Optional の合成は必ずしも悪ではないと考えていますが、それにしてもその合成結果を長々と取り回す必要はなくて、 N 個の Optional を合成後すぐに処理すべきですよね？

これはそうですね、実際にはValidationでErrorが生成されているので

5:23 AM

T?ではなくT|Errorだ

5:24 AM

本質的にはその定義が良いが、UIKitのせいでT?になってるか

そう考えると、合成した場合でもすぐに処理をしたいわけで、引数に渡す目的で Optional 値を生成するという以外に、 Optional のまま値を取り回したいケースってないような気がするんですよね。

5:28 AM

引数に渡す場合でも、一度作っちゃえば後はそれを渡す以外に使わないから、他のコードとは独立してるし。

たとえば

最悪なのは↓みたいなコード

let foo: Foo? = ... ... let bar: Bar? = foo?.bar(...) ... let baz: Baz? = a.b?.c.flatMap { bar?.baz($0) } ... guard let qux = baz.map { Qux($0) } else { ... }

var onComplete: (()->Void))?

5:30 AM

みたいなプロパティは

5:30 AM

必要だと思うけど、これは、取り回す場合かつ関数に渡さない場合

5:30 AM

じゃないですか？

今話してるのはプロパティの話ではなくて、関数やメソッドローカルの話。

5:31 AM

プロパティの「値がないかもしれない」ことを表すために Optional を使うのは当然あり得ると思います。

なるほど

うーん

5:32 AM

だから、僕の一番最初に言っていたのは

5:32 AM

プロパティの「値がないかもしれない」ことを表すために Optional を使う

5:32 AM

これが本来的な使い方のはずで、それ以外をOptionalで表現されている現状

5:32 AM

ベストプラクティスを議論せざるを得ない、ということになっている

5:33 AM

っていうところですかね

5:33 AM

プロパティの値がないかもしれないを合成した結果、値がないかもしれないは当たり前で

5:33 AM

別にどれが原因だーなんて気にしなくても良いことが多いので

5:33 AM

Errorメッセージ出してくれという要求があってチェックすることはまああるっちゃあるけど

@tarunon 文字列の中から文字を探して、見つかればそのindexを返す関数は、返り値はオプショナル？

それは意図によるのでは

5:34 AM

あるかもしれない、ならOptionalだし、なければおかしい、ならErrorであるべき

じゃあ

5:34 AM

自分がそういう関数を使いたい時

5:34 AM

どっちが用意されていてほしい？

オーバーロードが理想

5:34 AM

それは上にも書いてある

どちらかを用意して簡易に変換するのは駄目？

tryを書けばErrorが出てきて、書かなければOptionalになるみたいな

5:35 AM

用意して変換するならErrorしかない、try?がある以上その選択になるのでは。

なるほど。

ただそれは面倒臭すぎるし、Error周りはまだ貧弱だから

5:35 AM

今はOptionalに打ち込まれてる、まあそれはしゃーない

いまはtry?による変換もめんどくさいよね左に書くのが嫌だわ

そうなんだよなー

うん、それはある。

5:36 AM

try（相当のもの）は右にあるべきだった。 (edited)

なるほどなあ

記号がですね

5:36 AM

implicitly unwrapに!を使ってしまったので

わり同意見だなあ

try相当が!だったら……

それをいうと Int.init(String) とかも面倒で、 string.toInt() みたいに右にある方が使いやすかった。

そもそものSDEの話は考え中

string => { Int($0) } ですかね・・・。 (edited)

エラーがあったことしかわからないエラーっていう概念を前提に考えればコヒーの意見はわかるけど、それがそもそもおかしい気がする

うん、それがおかしいという意見もありえて、 Int.init(String) 等の conversion 系は throws であるべきというのはあり得る。

5:41 AM

一方で、↑の index とか、 first, min や Dictionary.subscript がエラーなのかどうかは解釈次第だと思う。 @tarunon さんの言うようにオーバーロードも一つの解なのかもしれないけど、それを正しく使い分けられる人は少なそう・・・。

そもそもGenericsすら使いこなせない人もいるから

でもそういう解釈を記述できる方が

まあそれはそれ、使える人にフォーカスしていいとは思う

書ける人にとっては

5:41 AM

より安全で読みやすく

5:41 AM

できてよいよね

Optional to throws の簡単な方法があればいいんじゃないかな？ (edited)

変換の失敗系は、与えられた入力と、なにからなにへの変換が失敗したのかという情報をもっててほしいなー

Anyを書いたらコードレビューで殴るように、不適切にOptionalをオーバーロードしたらレビューで殴る

5:42 AM

それができれば僕は満足かな

Resultのdematerializeみたいな？

前に Erica さんが swift-evolution で Optional 用の ??? 演算子を提案してて

あーなんかそれ俺も似たメール読んだ

結局 guard でいいでしょということで終わった。

!!と二個ビックリだと例外

5:44 AM

後置ビックリね

いやー、 !! は ! より危なそうに見えるから

func f() -> String? { return "Optional<String>" } func f() throws -> String { return "String" } let a = try? f() // "String" let b: String? = f() // "Optional<String>" // ^ 型アノテーションがないと error: ambiguous use of 'f()'

オプショナル版はfOrNil()でどうか

Recoverable なエラーの throws に対して Logic failure 無視の ! より危険そうな !! を割り当てるのは微妙そう。

じゃあ！と！！を入れ替えよう

5:45 AM

いまさらンゴね

我々が使える記号がたかだか10個前後くらいしかないのが問題

オーバーロードは微妙に思える。

のむらさん、もしかしてそれ、

5:49 AM

トップレベルだから

5:49 AM

throws空間の中にいるのが

5:49 AM

関係してますかね？

5:50 AM

throwsが付いてない関数の中からの呼び出しなら

5:50 AM

かわったりする？

@omochimetaru それでも try は書かないといけないから同じじゃないかな？

あー

@koher ああ確かに。トップレベルでしか成り立たない。

今は言語レベルでサポートされてないから

5:52 AM

class C { func s() throws -> String { return "a" } func s() -> String? { return "b" } } do { let a: String = try C().s() // a let b: String? = C().s() // b } catch { print(error) }

5:52 AM

まあこうなっちゃいますね、どちらも型明記しないとコンパイルエラー

5:53 AM

オーバーロードは言語サポートが乗った上でのifの話です

struct S { func f() -> String? { return "Optional<String>" } func f() throws -> String { return "String" } func nonThrow() { let a = try? f() // "String" let b: String? = f() // "Optional<String>" // ^ 型アノテーションがないと error: ambiguous use of 'f()' } }

(edited)

そもそもこの場合

5:54 AM

オーバーロードしてるString?はtry?した場合と同じ結果で良いので

5:56 AM

構文とセットで用意されれば理想っぽい

うーん、片方から片方に簡単に変換できるのがいい気がする。

5:57 AM

やっぱ ??? があればよかったのかなぁ。

情報が減る方向しかないからエラーからOptionalが良さそう

5:57 AM

何も情報がないSDEを受け入れるなら逆も可能だが

そうなんだけど、 array.first とかが throws なのはきつい気も。

そうかなあ、そうでもないんじゃないかなあ。

あー、あと今の Swift 的な話なら、プロパティだと throws にできない問題が。

あ

むしろそれは良い気がする

これらの議論は、Error周りの進化が前提ですよ

プロパティは失敗しないべき

僕としては

いや、 first はプロパティなので

5:59 AM

とすると

get/setが同じ型でいったりきたりできる、変数みたいな特性で。

5:59 AM

あ〜〜〜〜〜〜

プロパティ版は Optional で

5:59 AM

メソッド版は throws とか？

5:59 AM

そんなオーバーロードできんだっけ？

プロパティも完全に関数のように修正するのがいいのか

6:00 AM

失敗するfirstは関数に変えるのがいいのか

6:00 AM

なやましい

いや、余計曖昧になる？ array.first が first() のメソッドリファレンスかもしれない・・・

それがあり得るので今は動かないと思います

最初の要素という意味で first というプロパティがあって、最初の値がないから nil ってのはごく自然な解釈だとも思うんだよなぁ。

今まではそう思ってたけど最近はトンチの濫用って感じの気持ち

6:03 AM

無いものは取れない

6:03 AM

「無を取得」を思い出した

それって stored な Optional プロパティも否定してない？ < 無いものは取れない (edited)

「問題ありません」

それはnilがちゃんと書き込まれてるから

あー

なんていうのかな

6:04 AM

Arrayに firstっていうフィールドがあるわけじゃない

6:04 AM

nilをストアできているのと

亜空間から.noneを生成してるということ

擬似的にnilが空間に出現するのが

6:04 AM

違う感じがする

6:04 AM

そうそう！

それはカプセル化された内部表現の話じゃないかなぁ。 < フィールドがあるわけじゃない

でも、メンタルモデルとしても

6:05 AM

最初の要素という意味で first というプロパティがあって、最初の値がないから nil ってのはごく自然な解釈だとも思うんだよなぁ。

6:05 AM

これは、内部表現としてストレージがあるイメージではないでしょう

うーん、まあたしかにそうかも？

Arrayっていうデータ構造抽象から

6:05 AM

想像する話しとしてはヒネリを感じる

じゃあ、 birthday: Date? を持ってる User 型に対して、 birthYear を取り出す処理はどっち？ (edited)

「亜空間none」っていう概念良さそう。

実際には

6:08 AM

Optional<Optional<Int>>が正しい型ですよねそれ

Optional と throws のオーバーロードが推測でうまく扱えるようになったとして、じゃあそんなメソッドを書くときは実行速度の観点から Optional 版を書いてそれを throws 版でラップする形になる？

?のお陰でネストが解消されてるだけ

それは Int? 。空としてのnoneはbirhtdayのストレージのところに実在してるから

6:09 AM

そのnoneが素通しで見えてくるだけで

6:09 AM

亜空間ではない

あ、birthYearはIntか、ややこしいな

内部構造として birthday: Date? を保持しているのか、 birthYear/Month/Date : Int? を保持しているのかはカプセル化された中の話。

6:10 AM

つまり全部 Optional ってことね。 > @omochimetaru (edited)

もちろんカプセル化されてるけど、そういう風に素直に捉えられると思う。

6:10 AM

はい。

6:10 AM

じゃあそんなメソッドを書くときは実行速度の観点から Optional 版を書いてそれを throws 版でラップする形になる？

6:10 AM

内部の実装はそのほうが速くて良さそうですね

6:10 AM

nilだったら情報乗っけたエラーを組み立てる、というコード

実際にどういう風にデータを保持しているか、動的に生成されているかには関係なく、メンタルモデルとしてそのような値そのものが存在しているように感じられるか、 first のように一段抽象度の高い概念かどうかだと。

そういうことです

6:11 AM

メンタルモデルと実装モデルが実際は真逆ってことはありえるけど

6:11 AM

APIとして見せる時に

6:11 AM

どっちのメンタルモデルをユーザーに伝えたいか、できめる。

@norio_nomura 恐らく需要の面からもguard let throwsが言語機能として提供される、という感じになると思います

6:14 AM

そういう意味だと???と同じなのか

試しに ??? を実装して使ってみるとか

struct OptionalError: Error { let file: String let function: String let line: Int } extension Optional { func `throw`(file: String = #file, function: String = #function, line: Int = #line) throws -> Wrapped { guard let wrapped = self else { throw OptionalError(file: file, function: function, line: line) } return wrapped } }

オペレーターで十分な情報を取る方法が思いつかなかった (edited)

Optionalに生やすならtryじゃなくてthrowメソッドがいいんじゃないか

6:38 AM

throwあれだったらraiseにするとか

あーそうね

6:40 AM

で、これがあると

6:41 AM

あかん、ワンライナーで書いたら全部おなじになる、ザコだなー

6:45 AM

ワンライナーはだめだけど、

do { let user = try User( name: name.throw(), age: age.throw(), gender: gender.throw() ) } catch { throw User.Error.decodeFail(error) }

こんな感じにしてサクッと特定できる世界観にはなりますね

チェインの途中でどこが nil だったか知りたいみたいなのには応えられるのかな (edited)

チェインを1行ずつ分解すればまぁ

#line で分岐とかゾッとするので、Mirror とか使うといいのかな (edited)

うーん、現行の仕様だと、Wrappedとこの3つぐらいしか情報が取れない気がしていて

6:58 AM

Mirrorって自身の変数名とか知れましたっけ?

6:58 AM

無い気がする

6:59 AM

なのでそのレベルの言語サポートが欲しいよねって感じですね

ということは ??? とは別物って感じですね。

現状は完全な再現は出来ないと思います

7:04 AM

???のプロポーサルちゃんと読んでないから誤解があるかもしれない

ああ、それは僕も読んでないやw

7:11 AM

この記事かな http://ericasadun.com/2016/04/05/dear-erica-can-i-build-a-throwing-operator/

7:12 AM

??? は出てこないけど。

あった https://gist.github.com/erica/5a26d523f3d6ffb74e34d179740596f7 (edited)

throwing.md

Error型を作って差し込む感じか

first とかも含めて SDE なんてなくして適切なエラー情報込みで throws にすべきだとして、 ??? はいるんですっけ？現実的に first とかが Optional を返すからってこと？

現実の問題としてSDEや曖昧なものが全てOptionalに寄せられていて

7:51 AM

Error型が欲しい人はguard使うけどchaining出来ないし、構文レベルでthrowsへの変換があれば満足できるのではないか、ということだと思いました。 (edited)

お、↓ならできました。

extension Array { func first() throws -> Element { guard let value = self.first else { throw EmptyError() } return value } } struct EmptyError: Error {} let array = [2, 3, 5] let a = array.first let b = try! array.first() print(a) // Optional(2) print(b) // 2

(edited)

7:58 AM

なんで array.first は ambiguous にならないんだろう？

extensionで分離しているところがポイントっぽい?

8:00 AM

あれ、ダメですね、ライブラリかな

↑のコード実行できませんでした？？

いや、自作の型で同じことをやろうとして

プロパティとメソッドのオーバーロード？

extensionに分離したけどダメだった→ライブラリでコンパイル済みの型なら通るのでは説

8:01 AM

class C { var s: String? { return "a" } } extension C { func s() throws -> String { return "b" } }

8:01 AM

これですね

ほんとだ。謎・・・。

ファイルが別でも通る可能性あるな

同じパッケージだとダメなんですかね？

なんかファイルとかパッケージとか

8:03 AM

そのあたりを分けるとコンパイラパワーが増える(?)というのは確認していて

8:03 AM

通らないはずの型が通るようになったりとかままある

なるほど・・・

逆に通らなくなるのもあったな、この間のとか

ひどいｗ

https://gist.github.com/tarunon/b653d9326f1196e126e6edfcf60f7284 ↑この間の

Swift3.1 crashes caused 2 file.

extension Array { var first: Element? { return nil } } 普通にこれが通るので

あー

8:16 AM

Arrayさんを拡張してるからですか

他モジュールのメソッドとかはオーバーライド可能ってことになっている。

モジュールか

https://github.com/apple/swift/blob/master/lib/Sema/TypeCheckDecl.cpp#L923-L925

swift - The Swift Programming Language

@rintaro

他モジュールのメソッドとかはオーバーライド可能ってことになっている。

これの影響範囲はオーバーライドした側のモジュール内にとどまるんですか？

8:32 AM

あと、 func first() throws -> Element はオーバーライドじゃなくてオーバーロードですよね？これが同一モジュールだとできないのにモジュール外だとできるのはなんでなんでしょう？？

試してないですが、 public にしたら他モジュールからも見えると思います。

// ModuleA public extension Array { public var first: Element? { return nil } } // ModuleB import ModuleA let a = [1,2,3].first

とかしたらambigousになると予想。 (edited)

8:35 AM

オーバーライドでもオーバーロードでもモジュール外の「名前」との衝突は一切考慮されないっていう実装ですね。

静的ディスパッチはいいとして、動的ディスパッチだと仮想関数テーブルを拡張しないとできないような？？

witness-table、確かライブラリ超えて拡張できなかった気がする

8:36 AM

UIViewContorllerにXCTestだけprotocol書き換えて、Environment変更しようとしたら失敗したw

試してないですが

試しました。ambigous にならずに ModuleA 実装が優先されましたw

import ModuleA してなければ元の first が実行されるんですよね？ (edited)

// ModuleA public extension Array { public var first: Element? { return nil } } // ModuleB public extension Array { public var first: Element? { return self[0] } } // main import ModuleA import ModuleB let a = [1,2,3].first

さすがにこれはambigous (edited)

8:48 AM

import ModuleA してなければ元の first が実行されるんですよね？

じゃなかったら大変

そこが import でコントロールできるんだったら、 extension メソッドにプレフィックスつけたりネームスペース切ったりするのが流行ってたけど不要？

8:49 AM

両方 import したくて衝突したときに、どっちか指定する方法がないのか・・・。

8:50 AM

foo.bar にせずに foo.rx_bar とか foo.rx.bar みたいなやつ。

importした上で元のものを使う手段が無さそう?

!!!

// ModuleA public extension Array { public var first: Element? { return nil } } // ModuleB import ModuleA public extension Array { public var first: Element? { return self[0] } } // main import ModuleB let a = [1,2,3].first

これでambigous。これはまずいんじゃ・・・

8:53 AM

// ModuleA public extension Array { public var first: Element? { return nil } } // ModuleB import ModuleA // main import ModuleB let a = [1,2,3].first

これはnil になる。まずすぎる (edited)

おお、それはまずそうですね。。。 < ambigous (edited)

8:55 AM

ここは @rintaro さんの出番では？

バグリポート上げるくらいしかできませんｗ

8:58 AM

https://bugs.swift.org/browse/SR-3908 これかな

っぽいですね。

9:00 AM

コメントｗ

Old, old bug.

struct Matrix { var elem: [[Float]] } について可 let a: [[Float]] = [[1, 2], [1.0/2 1.0/3]] _ = Matrix(elem: a) 不可 _ = Matrix(elem: [[1, 2], [1.0/2 1.0/3]])

5:24 AM

なんとかならんのでしょうか

_ = Matrix(elem: [[1.0, 2.0], [1.0/2.0 1.0/3.0]]) これもだめですかね

SwiftSandboxで警告出てましたねそこ

5:25 AM

それでもだめっぽいです

5:26 AM

ERROR at line 9, col 31: cannot convert value of type 'Double' to expected element type 'Float' _ = Matrix(elem: [[0, 1], [1.0/2.0, 1.0/3.0]]) ~~~^~~~ Float( )

nんー

XCodeの方で何故かDouble/Intの警告出てなかったです

struct Matrix { var elem: [[Float]] } _ = Matrix(elem: [[1.0, 2.0], [1.0/2.0, 1.0/3.0]])

5:27 AM

これで通りましたね、Sandbox

5:27 AM

Xcodeはインスコ中なので動かせない

なんかチャンネルふえてるな

あれ？同じ文でこちらでは通らないですね…… (edited)

Xcodeは通らない

僕の方はSwiftSandboxでも通らなかったです

おっと…

5:49 AM

Sandbox、3.0だった。

5:49 AM

3.1は通らないですね

昔は行けてたとなるとバグの可能性ありですかね？

3.0から3.1で型周りで変更結構あるので、間違いなくそれらの影響何だと思いますが、

5:54 AM

バグかと言われるとどっちだろう、という気がする

5:55 AM

でも_ = Matrix(elem: [[1.0, 2.0], [1.0/2.0, 1.0/3.0]])　これが通らないのはバグな気がする

一度[[Float]]に代入するところができますからねぇ

お

6:30 AM

/// - Parameters: /// - optional: An optional value. /// - defaultValue: A value to use as a default. `defaultValue` is the same /// type as the `Wrapped` type of `optional`. public func ??<T>(optional: T?, defaultValue: @autoclosure () throws -> T) rethrows -> T

6:31 AM

昨日の話題

6:31 AM

??オペレーター、既に???とのオーバーロードですねこれ

intOpt ?? throw HogeError() こう書けるって事？

intOpt ?? HogeError() (edited)

6:32 AM

これでおkす

それは ?? の右側のオートクロージャーの返り値の型が () -> Tじゃなくて () -> HogeErrorになってコンパイルエラーでは

いや、通る

6:36 AM

public func parse(data: Data) throws -> Any { return UIImage(data: data) ?? Error.imageNotFound }

6:36 AM

あーー

6:36 AM

Anyのせいか

_ = Matrix(elem: [[1, 2], [1.0/2 1.0/3]]) は master で -Xfrontend -propagate-constraints ていう experimental なフラグ付けたら通りました。

https://github.com/apple/swift/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aclosed%20constraint%20propagation%20 このあたりかな。そろそろ enabled by default になりそうな感じなので Swift4 では直ってるとおもわれます。

[stdlib] Give Sequence a top-level Element by airspeedswift · Pull Request #8939 · apple/swift

swift - The Swift Programming Language

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

ほう

enum Error: Swift.Error { case unavailable } let dictionary: [AnyHashable:Any] = [:] do { _ = try dictionary["unavailable"] ?? { throw Error.unavailable }() } catch { print(error) // "unavailable\n" }

(edited)

extension Error { func `throw`<T>() throws -> T { throw self } } struct MyError : Error {} let str = "hoge" do { try print(Int(str) ?? MyError().throw()) } catch { print(error) }

いやーｗ

今日一日???導入してコード書いてみたけど結構快適だった

3:42 PM

Error型にthrowでthrows->Tになるの良いですねこれ

そうか -> T にしないとダメですね。 try dictionary["unavailable"] ?? { throw Error.unavailable }() みたいに、期待される型が Any だとエラーにならない。

extension Swift.Error { func `throw`<T>() throws -> T { throw self } } extension Optional { func `else`<T: Swift.Error>(_ error: @autoclosure () -> T) throws -> Optional { guard case .some = self else { throw error() } return self } func unwrap<T: Swift.Error>(or error: @autoclosure () -> T) throws -> Wrapped { guard case let .some(wrapped) = self else { throw error() } return wrapped } enum Error: Swift.Error { case isNone(String) } func `else`(_ message: @autoclosure () -> String) throws -> Optional { guard case .some = self else { throw Error.isNone(message()) } return self } func unwrap(or message: @autoclosure () -> String) throws -> Wrapped { guard case let .some(wrapped) = self else { throw Error.isNone(message()) } return wrapped } } enum Error: Swift.Error { case unavailable, notInt } let dictionary: [AnyHashable: Any] = ["available": 1] do { let a = try (dictionary["available"] ?? Error.unavailable.throw()) as? Int ?? Error.notInt.throw() let b = try dictionary["available"].unwrap(or: Error.unavailable) as? Int ?? Error.notInt.throw() let c = try dictionary["available"].map({ try ($0 as? Int).unwrap(or: Error.notInt) }).unwrap(or: Error.unavailable) let d = try dictionary["available"].map({ try $0 as? Int ?? Error.notInt.throw() }) ?? Error.unavailable.throw() let e = try dictionary["available"].else(Error.unavailable).map({ $0 as? Int }).unwrap(or: Error.notInt) let f = try dictionary["available"].else("\"available\" does not exists").map({ $0 as? Int}).unwrap(or: "Fail converting to Int") } catch { print(error) }

https://github.com/apple/swift/pull/8939 associatedtype に where を付けられるようになって、 Sequence.Iterator.Element が Sequence.Element になるのはうれしいんだけど、 https://github.com/airspeedswift/swift/blob/8869509174859ca30eeca37001463b3b46e9f7fc/stdlib/public/core/Sequence.swift#L330-L331 associatedtype Element associatedtype Iterator : IteratorProtocol where Iterator.Element == Element こう宣言しなければいけないのは直感的ではないなー。 associatedtype Iterator : IteratorProtocol typealias Element = Iterator.Element で実現できなかった理由はなんなんだろう。

Adds an associatedtype Element to Sequence, then constrains Iterator.Element to match it.

airspeedswift/swift

swift - The Swift Programming Language

protocolの型をtypeliasで束縛するの、3.1から使えなくなっていて

4:22 AM

ネストしたGenerics型とかの兼ね合いかな～と想像してるんですが

直感的ではないなー。

そうでもない気がしてきた。 Element を起点に考えれば当然の帰結か。

whereって条件って感じだけどなんでwhereなんだろ？

うーん、 Sequence はあくまで Iterator を生成するものなんだから、やっぱ Iterator 起点なのが直感的な気が。

4:24 AM

↓ができるならそっちの方がいい気がする。 associatedtype Iterator : IteratorProtocol typealias Element = Iterator.Element (edited)

associatedtype Iterator : IteratorProtocol associatedtype Element where Element == Iterator.Element もできるのかな？ (edited)

お、できそう

4:26 AM

protocolにtypealias書けないのはまあなんとなく理解できていて

それって自由度が何もないのに associatedtype って変じゃないですか？

なのでassociatedtypeで実現しようとすると、=だとデフォルト実装になって書き換えれてしまう。

typealiasだと意味が曖昧になるケースが出るってことかな

4:27 AM

既存の用法とのカチ合いで

@omochimetaru typealias Element = Iterator.Element って既存用法と何か違うっけ？

それって、

4:28 AM

もし、Sequenceに親プロトコルがあって

4:28 AM

その親プロトコルがElementっていうassociated typeを持っている場合に

4:29 AM

それを確定させるっていう意味になるのか

そうそう

4:29 AM

そういう問題が発生し得るので

Sequence自体のネームスペースにElementっていうシンボルであるassociatedtypeを定義するのか

4:29 AM

あいまいにならない？

protocolではtypealiasは書けない、としていたほうが

ということを思い浮かんだ　多分たるのんもいっしょ

一貫性が持てそう

それか、classでのその用法と紛らわしい(厳密には衝突はしないけど紛らわしいから避けたい系 (edited)

4:30 AM

本当に今の仕様でぶつかるかは自信無い

typealias が protocol に復活したときに typealias Element = Iterator.Element いけるじゃん！みたいなので騒いでいたのは事実で https://github.com/apple/swift/pull/1610

[Parse/AST/Sema] Split parsing for typealias & associatedtype, allow typealias in protocols and generic constraints by gregomni · Pull Request #1610 · apple/swift

Split up parsing of typealias and associatedtype, including dropping a now unneeded ParseDeclOptions flag. Then made typealias in a protocol actually valid, which works great except that you can't ...

あー、 associatedtype を縛る方は typealias のままだったのか。書くことないから忘れてた。 https://twitter.com/chriseidhof/status/700305519328755712

Chris Eidhof (@chriseidhof)

In Swift 2.2, when using associatedtype, you still have to use typealias to declare an associated type instance:

1

4:36 AM

これ↑みたいに、縛る方は associatedtype Foo = Bar の方が良くないのかな？何かダメな理由あるっけ？

protocolだとassociatedtype Foo=Bar は束縛じゃなくてデフォルト実装なんですよ

4:37 AM

上書き可能

https://twitter.com/jckarter/status/700425630781825024

@chriseidhof That's probably a common enough mistake to be worth a fixit. Got time to file a bug?

マジか

associatedtype のデフォルト実装ってどんなときに使うんですか？

4:39 AM

@tarunon いや、 2.2 の頃の話なので、その後どういう話になったのかが気になります。

ある型のassociatedtypeが一般的に期待される型があり得る場合ですね、 stdlibでもそこら中にありますよ

Joe Groff のツイートはエラーメッセージに fix-it つけてわかりやすいようにすべき。って話ですね。

4:42 AM

束縛を associatedtype でやるっていう話ではない。

おお、そうなんですね。勘違いしてました。

4:45 AM

@tarunon そうなんですね・・・。 associatedtype って大体↓みたいな感じで暗黙的に解決されちゃって明示的に指定することがないんで、デフォルト実装がありがたいイメージがありませんでした。 protocol Foo { associatedtype Bar func bar() -> Bar } struct Baz: Foo { func bar() -> Int { return 42 } } (edited)

えーと

4:48 AM

一番嬉しいのはですね

4:49 AM

protocol Foo { associatedtype Bar = Void func bar() -> Bar } extension Foo where Bar == Void { func bar() -> Bar {} } struct Baz: Foo { // 書かなくてもBar==Voidが推論される }

4:49 AM

このパターンですね

4:49 AM

書けば推論されるのはその通りなんですが、デフォルト実装を持っている場合は、書かなくて推論されることが嬉しい場合が結構ある

C++だとコンテナのメモリ管理をAllocatorっていう型パラに切っておいてデフォルトではmalloc/freeのやつで埋めとくみたいなのありますね

@tarunon なるほど。

http://twitter.com/slava_pestov/status/856369805648998400

アップルの人もこのPRについてツイートしてた (edited)

Soon you'll be able to say 'T.Element == ...' instead of 'T.Iterator.Element == ...' in your where clauses: https://t.co/hjXqfTpEtY

実際にはIterator.Element==Elementでしかないのに、Elementを分けて書いたのが呪いの始まりなのでは?という気もしている

4:53 AM

横着してはいけなかった

横着ではなくない？イテレーターはそれ単体で綺麗に独立してるよ (edited)

いや

4:56 AM

SequenceがElementを持ってるのはそれはそうだけど

4:57 AM

言語機能としてElement == Iterator.ElementをSequence単体で実現するすべがない状態で

4:57 AM

ElementとIteratorを定義してしまったのはまずかったのでは、という視点 (edited)

うーん、 Sequence は Element を持ってない気がします。 Sequence は IteratorFactory にすぎない気が。

あーー

Java の Iterable<E> は E を指定して Iterator<E> を返すけど、 Swift の Sequence は Iterator の種類まで決定するという意味で違いがありそうな。

シーケンスにおけるエレメントって、ラムダ計算の自由変数なのかな

5:02 AM

プログラミングだと束縛変数しか基本出てこないからシーケンスに暗黙にTが引数として存在するような気分になるけど

5:04 AM

>ラムダ式は自由変数（ λ によって束縛されていない変数）を含むこともできる。例えば、入力に関係なく常に y を返す関数を表す式 λx. y において、変数 y は自由変数である。

5:04 AM

うまくいえない・・・

この変更でこれが通らなくなりそうです。

struct AlwaysOneIterator : IteratorProtocol { func next() -> Int? { return 1 } } struct AlwaysOneSequence : Sequence { func makeIterator() -> AlwaysOneIterator { return AlwaysOneIterator() } }

(edited)

5:16 AM

associatedtype Element が解決できないみたい。

typealias Element = Intを書かないといけないのかな

5:22 AM

associatedtype Element associatedtype Iterator : IteratorProtocol where Iterator.Element == Element // ↑これだとElementをIteratorから推論できない associatedtype Iterator : IteratorProtocol associatedtype Element = Iterator.Element where Element == Iterator.Element // ↑この書き方ができるなら、ElementはIteratorから推論可能。

5:23 AM

こういうことかな

5:23 AM

後者のほうが良さそう

どっちでも違いなさそうですね。手元のが 3,4日前のmasterなので、今 pull し直して確認中です。 (edited)

むむぅ。件のPR適用してビルドした状態で、これは通らないのに、

protocol MySequence { //associatedtype Iterator : IteratorProtocol //associatedtype Element where Element == Iterator.Element associatedtype Element associatedtype Iterator: IteratorProtocol where Iterator.Element == Element func makeIterator() -> Iterator } struct AlwaysOneIterator : IteratorProtocol { func next() -> Int? { return 1 } } struct AlwaysOneSequence : MySequence { func makeIterator() -> AlwaysOneIterator { return AlwaysOneIterator() } }

struct AlwaysOneSequence : MySequence を struct AlwaysOneSequence : Sequence に変えると通るようになる。

えw

5:41 AM

悪魔の加護かな

今、社内 Slack で Scala の拡張 for 式について話してたんですが、 @tarunon さんあたりは Swift にも Higher kinded type と Haskell の do 記法的なものがほしい派ですか？

Haskell doについては

何度も Core Team に否定されているので実現は難しそうですが・・・。

既存のdo構文が、asyncでも動くようになれば

7:33 AM

殆どの要求は満たせそう

モナドの用途はほとんどが Result と Promsie で、 throws と async があれば <- を try と await で代用できるから、それで大体 OK ってことですか？

はい

7:34 AM

用途は殆どが、というとちょっと乱暴だな

7:35 AM

ただ、多くの問題はResultとPromise、これらの複合が発生した場合に

Rx 使ってると Opservable もあるかと思いましたが、あれは色んなオペレータ組み合わせて使うし flatMap だけできてもって感じですか？

ネストがひどいことになる、それさえdo構文で解決できれば

7:35 AM

いえ、どちらかと言えば

7:36 AM

あー

7:36 AM

まあObservableはそうですね、まだちゃんと思考してないんですが

7:37 AM

組み合わせでオペレーター使いざるを得ないからdoの中で解決するのは出来ないのでは?という気がしています

なるほどー。

asyncがあれば、うまいことやれば、Observableのかなりの需要を食えるのでは?というのもなんとなく考えてます

7:39 AM

ちょっとちゃんと考えてないのではっきり言えないですが

値型のおかげでイミュータブルプログラミングの出番も少ないし、 IO モナドとかもいらないし、 Result, Promise あたりがやっぱメインですよね。

7:40 AM

Observableのかなりの需要を食えるのでは?

これ思います。実は Promise で済むケースが多そう。

Higher kinded type

こいつは欲しいんですよねぇ。これがないせいで、型消し使うシチュエーションが多すぎる

7:40 AM

Any<Sequence where>なんちゃらも、この問題を解決出来る…わけではないですよね、恐らくパフォーマンスに影響が出る

Higher kinded typeはほしいですねぇ。 Self はあるのに Higher kinded type はないのと、 associatedtype があるとプロトコル型変数作れないのに associatedtype がなければ作れるのは何か中途半端感を感じます。

@rintaro 今のmaster, SequenceにElementは定義されてないように見えます。 https://github.com/apple/swift/blob/master/stdlib/public/core/Sequence.swift

swift - The Swift Programming Language

試しているのはこのブランチです。 https://github.com/airspeedswift/swift/blob/begone-iterator.element/stdlib/public/core/Sequence.swift

airspeedswift/swift

swift - The Swift Programming Language

> Observableのかなりの需要を食えるのでは? これ思います。実は Promise で済むケースが多そう。

これ僕も思って本気でライブラリ作ってユースケース洗い出してってやっていたら (edited)

8:33 AM

やっぱりObservableが要るって結論になった。 (edited)

ダメか…

8:34 AM

Streamの合成がasync throws funcの合成と等価じゃないから

Promiseだけじゃなくて、EventEmitterとVariableは欲しいんですよね

8:34 AM

で、そいつらがObservableとして同じ基盤に乗ってないと、相互接続ができないし、

ふーむ

たとえば、

8:35 AM

マウスクリックのイベントを受けて、URLリクエストを発火する

8:35 AM

みたいなパターンを考えた時点で

8:36 AM

EventEmitterとPromiseが相互にflatMapできないと

8:36 AM

接続点でボイラープレートみたいなのがワチャワチャでてきちゃうし

結局記述量変わらなくなりますよね

EventEmitterだとmapしてEE <T> から EEつくったとき on の連鎖どうなんのとか

8:37 AM

・これもできるならあれもできないとおかしい　っていうのがどんどんでてきて

8:37 AM

それってRx.Observableの再実装が必要では？みたいになってしまった

8:38 AM

Everything is streamみたいに突き抜けたところまでいかなくても

8:39 AM

EventEmitter, Promiseの2つを使うより素朴にObservable使ったほうが同じことをよりスッキリかけちゃうなあ

8:39 AM

という感じですね

8:40 AM

最近SingleもRxSwiftに入ったから「１個」という観点での型表明も強化されたし

8:40 AM

MaybeとCompletableがある分、Promiseより強いんでは？とも思う

うーん、イベント発火する部分がシンプルなfunctionの世界になれば合成はどうにかなるかなぁと思ってたけど

それって結局Promiseからはみ出すのと

やっぱり無理か、こういうのは書かないと真に理解出来ない。

Promiseの、値一個だけっていう概念が邪魔になる

連続させるのがいちいち手間で､結局allに包ませることになるのが辛いです

Promiseだとキャンセルのしくみも自分で作り込まないといけないんで

8:45 AM

DisposeBagで全部片付けてしまえ〜　みたいな段階にいくまでの積み木が結構たいへん

DisposeBagというか

8:52 AM

Completedの概念が非常に優れているんですよね

8:52 AM

最近理解したの、Observableが持つクロージャにリファレンスカウントを増やさせることで

8:53 AM

任意の参照可能なオブジェクトにフィールドを持たせる必要すら無かった。

8:53 AM

CompletedすればObservableが破棄されるのでメモリリークも無い。

ん、でもそれはObservableがsubscriberを登録できるっていう仕組み経由でひっかけてるって話ですよね？

そうですね

8:53 AM

最終的にはDisposeBagが持っています

大域でいらないオブジェクトはオブザーバブル繋ぐメソッドのスコープに置くとかはよくやりますね

元をたどればsubscriber の配列をもっている事が、そのカスタマイズ性を提供してる

@tarunon さっき話してた、letで自己再帰するやつ、面白いのあるから書いた https://gist.github.com/omochi/945fbf77566ab507dd95783f2f64deae (edited)

higher-func-rec.swift

1

オッ

12:20 PM

Prologみたいだ

ML系では実際まさにこれな rec って言語機能があるとかないとか、そんな話を資料で読んだ

12:23 PM

面白いところだけ転載しとこう

// let + クロージャー （と小道具）で再帰 let fib3 = rec { (fib: (Int) -> Int, x: Int) -> Int in switch (x) { case 0: return 0 case 1: return 1 default: return fib(x - 2) + fib(x - 1) } }

https://developer.apple.com/videos/play/wwdc2014/404/ これを思い出した。

1

12:27 PM

38:40 くらいから

不動点コンビネータってやつですね

@ukitaka あ〜これがそれですね（いつも細かい話は毎回忘れてしまいます

この当時ってネストしたローカル関数も再帰できなかった記憶があります。

https://developer.apple.com/videos/play/wwdc2014/404/ これを思い出した。 38:40 くらいから

見てきた。メモ化高階関数も対象の関数が自己再帰を含むから同じ形になるんですね。

swift-3.1.1-RELEASE 何が変わったのか

https://github.com/apple/swift/compare/swift-3.1-RELEASE...swift-3.1.1-RELEASE deinit まわりのメモリ問題とか入っているっぽい。

swift - The Swift Programming Language

Xcode 8.3.2がSwift 3.1.1らしいから、Xcodeでも直ってるってことか。

Xcode 8.3.2 はまだ Swift3.1 だと思いますが、どうなんだろう。

でも最適化の時のバグは治ってましたね

https://swift.org/download/#releases には "*Swift 3.1.1 is available as part of Xcode 8.3.2." とあります (edited)

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

NSErrorキャストでクラッシュするのと、2重ループのメモリリーク

$ swift -version Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42) Target: x86_64-apple-macosx10.9 表記だけの問題？

動作的には明らかに 3.1.1 なんだけど #if swift(>=3.1.1) print("3.1.1") #endif これが true にならないのとか、ほんとにイケてない。

中身は3.1.1だけど表示だけ3.1だからみたいな

中身と表示一致してないのダメでは

main.swift でトップレベルで guard した場合って else ブロックに何書けばいいんでしょうか？ fatalError とかでなく正常終了したい場合。 return はできないようです。 "swift top level guard exit" とかで軽くググってみたんですがよくわからず・・・。

abort() とか？

10:00 AM

Neverなメソッドなら書けるはず

@koher さっきわかんないって言ったけどそういえばこんな例はあります https://github.com/apple/swift-package-manager/blob/master/Sources/POSIX/exit.swift

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

exit(1) abort() fatalError() らへんが使えると思うけど違いは分からない

10:01 AM

正常終了なら exit(0) ?

posix的にはそう stdlib.hの EXIT_SUCCESSを使うのがお行儀が良い

MAIN: do { // ... guard ... else { break MAIN } // ... }

育ちが悪いからexit(0)しちゃう

でもCの作法を呼べるってだけでSwiftのやりかたかといわれると微妙

うーん、たしかに exit 呼べばいい気がしてきました。 exit ってちゃんと Never になってるんですね。

@rintaro ぼくもよく func main() { } main() ってやってます

10:03 AM

@koher C向けのアトリビュートが良い感じに検出されてるっぽい

素直に func に突っ込んじゃうのが楽ですよね。

__attribute(noreturn)__ だったっけ。 (edited)

10:04 AM

C向けっていうかclang/gcc

へえー

@hiragram さん、ありがとうございます。

いえいえ

func main() { } main() ↑これは main() のコールが C とかより冗長で負けた感が・・・。 (edited)

トップレベルなんて信じてない

10:05 AM

負けた感はある

10:06 AM

(僕はrubyでもよくdef mainからはじめてる

コマンドラインのスクリプト書いてて正常終了したいんだから普通に exit(0) が素直だった。 (edited)

10:07 AM

Never になってるの素晴らしい。

exit(EXIT_SUCCESS) も呼べると思います。

お、いけました！ありがとうございます。 < EXIT_SUCCESS

↓Acceptされてる。うれしい。 https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

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

ふと気になったんですが、Optionalなクロージャを引数に作ると、@escaping 書けなくなりますよね。どういう扱いなんだろう。

func hoge(_ arg: (() -> ())?) {...} // ←みたいなことをした時に、argがエスケープされるとしてもそれを明記できない。

それは

Optionalがキャプチャするから常にescapingかな

自動 @escaping 扱いです。

ただのプロパティだから

10:44 AM

必然的に常にエスケープする

ここに書き込んだ瞬間に気がついた

Optinalはただの型だから。

Foo<() -> ()> と同じですしね。

10:46 AM

? の記号は便利だけど、こういう混乱を招きやすい・・・。

そうすると

10:48 AM

引数のクロージャを省略可能にしようとすると

10:48 AM

最適化で不利になる？

可能性はありそう。

10:50 AM

Swift コンパイラがすごく賢ければ

10:50 AM

そこも考慮してインライン化してくれたりするかもだけど。

今度試してみよ

もしかしたら

10:51 AM

func hoge(_ arg: (() -> ())?=nil) {...} func hoge(_ arg: (() -> ())={ _ in }) {...} 後者のほうが強いのかもしれない (edited)

インライン化されて完全に消える事を考えるとありえるね

呼び出しコストかかるかと思いましたが消えるんですかねこれ

llvmir出してみて

10:53 AM

たらわかる

SE-0171 ができるようになったらこんな感じかな？

let strings = ["a:2", "b:3", "c:5"] let dictionary = strings.reduce(into: [:]) { (r: inout [String: Int], e) in e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } } // ["a": 2, "b": 3, "c": 5]

(edited)

10:59 AM

=> は前話してた Kotlin の let 代わり。

できそう

e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } これの型はどこで決まるの？

rから推論できそう

=>は中置オペレータで式の評価結果はクロージャの評価結果そのもの

3:26 PM

あれ？Swiftって代入文の評価結果ってVoidじゃなかったっけ

3:26 PM

右辺値だったっけ。

あー

vogdですね

3:27 PM

void

voidか。あ、でもいいのか。 inout版のreduceは

3:27 PM

reducerは返り値voidで、inoutで固定なのか。

3:28 PM

とりあえず、 => の定義 https://github.com/koher/swiflet

koher/swiflet

swiflet - Provides => like let in Kotlin for Swift

kotlin let知ってないと目がぐるぐるする

3:29 PM

1

inoutじゃないけどvoidを返す場合を考えたけどそんなのなかった

なるほど

infix operator => public func =><T, U>(lhs: T, rhs: (T) throws -> U) rethrows -> U { return try rhs(lhs) } extension Sequence { func reduce<A>(into initial: A, _ combine: (inout A, Iterator.Element) -> ()) -> A { var result = initial for element in self { combine(&result, element) } return result } } let strings = ["a:2", "b:3", "c:5"] let dictionary = strings.reduce(into: [:]) { (r: inout [Int: String], e) in e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } }

error: cannot subscript a value of incorrect or ambiguous type e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } ^~

型推測しきれないぽい。 (edited)

呼び出し側にinto: ラベルが必要です (edited)

into: 足してもエラーは変わらず。

let dictionary = strings.reduce(into: [:]) { (r: inout [String: Int], e) in e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } }

で通りました。[Int: String] じゃなくて [String: Int] でしたね。

おお、追加のアノテーションなしでいけるんですね。

[Int: String]になってるの全く気が付かなかった

あらら

元のコード修正しました。

1:33 AM

↓も Accept されてる。 https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md

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

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

1:34 AM

おー、 42... とかもだ。 https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md

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

keyPath acceptからグッと作りやすくなったと思ってたら標準で用意されるのかー

4 月上旬の駆け込み Review 祭りの結果が続々と Accept されてる。

166,167ってまだ読んでないんですけどざっくりどんな話ですか？

1:37 AM

言語機能としてシリアライズが付く？

そう、で、json周りも標準採用

JSONもつくのね。珍しいな。

1:39 AM

そうなると細かいところがいろいろ気になるけどそれについては自分で読んでみます。ありがとう。

任意のEncoder,Decoderプロトコルを定義出来るのだけど、JSONに関しては標準的な構造が用意されてる、と言うように見える

1:41 AM

plistもあるな

(たぶん)3.1 で closure の inout まわりの inference が改善されてるんですね。 let ary1 = [1,2,3] let ary2 = ary1.reduce(into: []) { $0.append($1 + 12) } 非常によい。

1

2:11 AM

let dictionary = strings.reduce(into: [:]) { r, e in e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } } これも通った

2:14 AM

あー、これだと dictionary: [AnyHashable: Int] になっちゃうのか。

$0が Array<String> 確定するから、$0[0]がStringになって String: Intになりそうだけど、保守的な推論になっちゃう？ (edited)

うそでした。 let dictionary = strings.reduce(into: [:]) { r, e in e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } } だと [String: Int] で

let dictionary = strings.reduce(into: [:]) { r, e in print(e) e.components(separatedBy: ":") => { r[$0[0]] = Int($0[1])! } }

だと [AnyHashable: Int] single expression か否かで変わってくるみたいです。

print(e)で変わっちゃうんですか・・・微妙ですね。

// If all properties are Codable, protocol implementation is automatically generated by the compiler: これ微妙な気が。

2:27 AM

Codable だった型にプロパティ足したときに気づかずに Codable でなくなってしまう危険があるのでは？

それはコンパイルエラーになるんでは？

もし明示的に Codable をつけていれば、プロパティを足した瞬間に気付ける。 (edited)

使ってるところでCodableが期待されていてそれと衝突する

使っているのが外部のモジュールだったら？ (edited)

外部のモジュールがオブジェクトを受け取るところでCodableとして引数に受けてるから同じでは？

ライブラリ A の Foo が元々 Codable だったのを、まったく関係ない第三者が使っていて、ある日 Foo が突然 Codable でなくなるとかあり得る。

2:30 AM

しかも、最初から A の作者は Foo を Codable にするつもりはなかった、とか。

ライブラリAのFooにどうやってフィールドを追加するんですか？

: Codable 宣言してなかったら Codable にならないんじゃないですか？

え？そうなんですか？

Aの作者がFooをそうと意識せずにCodableにしている場合か。Aの内部ではCodableを使ってないなら、たしかに困る (edited)

implementation が生成されるだけで : Codable は必須ってことか。

なんだ

@omochimetaru Structural subtyping vs Interface みたいな話になるんじゃないかと思った。

まさにそれそのものですね。

enum (without associated values)が自動的に Hashable になるのとは違う気がします。

ライブラリAの作者Pがenum Eを作っていて、それをユーザーQが辞書のキーに突っ込んでいる時

2:34 AM

PがEにassoc valを付け足すと、ユーザーQのコードが壊れるのか。

それはあり得ますねー。

知らなかった

同じく知りませんでした。

未然回避した

やっぱ暗黙的に何かを満たすみたいなのはよくない気がする・・・。

2:36 AM

やるなら Structural subtyping までやっちゃう哲学じゃないとどっち付かずで中途半端感が。 (edited)

Structural Subtypingで通しても同じように崩壊するだけじゃないのかなあ。 (edited)

Go や Crystal やダックタイピングやってる言語は崩壊してるってこと？

ライブラリAのFooが何かを満たしていることを永遠に保証できない

2:37 AM

そういうことです

2:37 AM

Rubyはそれが実行時エラーになるCrystalといえるけど

2:37 AM

実際のところドキュメントで

2:37 AM

このクラスはこのインターフェースを満たすっていうのを

2:37 AM

HTMLで書いてるんですよ

いや、もちろん問題が起こる可能性はあるんだけど、それを前提にして回ってるわけで、それによって得られてるメリットもあるわけで、そっちを優先するという立場があってもおかしくはない。 Swift にはなじまないと思うけど。

あ、違うか、継承は実在するのか

2:39 AM

https://docs.ruby-lang.org/ja/latest/class/Pathname.html#S_NEW

[PARAM] path: 文字列、または類似のオブジェクトを与えます。実際には to_str に反応するオブジェクトなら何でも構いません。

2:39 AM

例えばこれとかなんですけど、これって、Swiftできちんと考えると

2:39 AM

class Pathname { init<P: ToStrProtocol>(path: P) { ... } }

2:40 AM

ようするにこういうシグネチャなんですけど

2:40 AM

今ユーザーQがライブラリAの型Fooをこれに渡してる時、

2:40 AM

このToStrProtocolは静的検査されないんで、ライブラリAがアップデートでそれを削除した瞬間に

2:40 AM

実行時エラーが潜伏することになる

2:40 AM

Crystalならコンパイルエラーになる

2:41 AM

「to_strなんか消さないだろ」みたいなコンセンサスをみんなが守ってるから壊れない。

2:43 AM

そっちを優先するという立場があってもおかしくはない。

それはそうだけど、「徹底しないといけない」理由はよくわからないです。少し入れるのも完全に入れるのも、入ってくるメリットとデメリットが同時に増大するかどうかの違いで、同じことに思います

はい、ぶっ壊れるのはわかるんだけど、それを前提に書き心地を優先して Structural subtyping をとるっていうのは、メンテナビリティと書き心地のトレードオフだから、後者を取る立場があってもおかしくはない。

2:43 AM

うーん、程度問題で、 Structural subtyping は許せないけど auto の Hashable は許せるってこと？

かき心地のトレードオフっていうのもよくわからないんですよね。このHTMLを日本語で書くの、かき心地いいのかな

2:44 AM

ドキュメント化した時点で矛盾してるような気がしています

ドキュメント化しないスクリプトみたいなのが大量に生成されてるんじゃない？

それならわかる

そういうときに implements Foo とか書きたくないと。

今回の enum (without associated values)が自動的に Hashable になるけど、 CodingKey には自動的にはならず opt in ってのは統一感ないのはありますね。

ですねー。 Swift は明示的なインターフェースを選んだ言語なわけだし、自動 Hashable は違和感がありますね。

simple enumとでも言えば良いのかな、全行読まないとそれが確定しないのユーザーにとって不便ですね

2:47 AM

C++もデフォルトでいろいろやる仕様から始まって、そのデフォルト生成挙動を把握しろっていうプラクティスが普及して、デフォルト生成を抑制する構文が追加されて、デフォルト生成を明記する構文が追加されて、カオス

2:48 AM

昔に定義された「デフォルト挙動」のせいで、「デフォルト禁止構文」と「デフォルト明示構文」が後から足されて安定した設計に至る話、複数ありそう

Swift だとそこで過去を断ち切って非互換アップデートしちゃうからｗ

特にデフォルト明示構文が使われてるときのシュールさがやばいんですよね、わかるんだけど。

@nonescaping みたいに

たしかに・・・

Swift は @objc のデフォルト挙動を無くして明示の方向に進んでるけど enum: Hashable を無くす議論はまだ無いですね。影響でかすぎるか。

いけるいける

あー誤解してた。 associated value が Hashable の場合も自動的に、なのかと思った。

enum (without associated values)が自動的に Hashable

2:53 AM

うーん、まあ associated value なしの enum がありの enum に変化するのは、ぜんぜん違うものになってる感があるし仕方ない気も。 (edited)

2:54 AM

両方 enum で書けるってのが変かも？

そもそもですねｗ

simple enum みたいな特殊キーワードとかもありかも

Tagged union は enum じゃない気がするんですよね。

2:55 AM

enumerate できないし。

2:55 AM

enum じゃなくて union とかでもよかったのかも？

unionだとunion typeじゃないのに変な感じ

2:56 AM

C言語の union { } と紛らわしいし。

でも今の状態も C の enum とかけ離れてない？

そうですねえ

開発ツールに https://github.com/apple/swift/tree/master/tools/swift-api-digester ってのがあって、モジュールのAPIを出力してくれるツールで、 stdlib の破壊的 API 変更をこれで監視しているんですが、これ的なものが SPM に組み込まれるとライブラリ開発者はなかなか助かるかもと思います。

Swift Archival & Serialization API by itaiferber · Pull Request #8124 · apple/swift

swift - The Swift Programming Language

おお

2:57 AM

それを元に自動でバージョニングしてくれるといいですね。

ほ〜〜

API に変更がなければ patch を、互換性があれば minor を、非互換なら major を上げなさい、みたいな。

↓ Swifty じゃなくないですか？引数の型は Encoder でなく T: Encoder であるべきでは？

public protocol Encodable { /// Encodes `self` into the given encoder. /// /// If `self` fails to encode anything, `encoder` will encode an empty keyed container in its place. /// /// - parameter encoder: The encoder to write data to. /// - throws: An error if any values are invalid for `encoder`'s format. func encode(to encoder: Encoder) throws }

3:08 AM

↓じゃダメ？ public protocol Encodable { func encode<T: Encoder>(to encoder: T) throws }

ジェネリックにしてしまうと、ランタイムでの差し替えが出来なくならない？プラグインとか。

ジェネリック引数でできないのって具体的にどういうケースですか？

Objective-CでのEncoder実装とか？

それはジェネリックかどうかではなく、 swiftで定義されてる Encoder protocolが、@objc 互換かどうか、によって決まると思う

Encoder にはジェネリックメソッドありますね。じゃあ想定されていないのか。

SE-0166 は Java の Serializable とは違って、シリアライズするための抽象的な仕組みを提供するだけなのか。素晴らしい。

JSONSerialization で書き出すのね。 ~~https://github.com/apple/swift/pull/8124/files#diff-97ae7c2e808a30701d6e28271b8b6073R135~~ (edited)

What's in this pull request? This PR integrates preliminary work in introducing a new Swift-focused archival and serialization API as part of the Foundation framework. This PR focuses on what is av...

SE-0167 読んでないですけど、多分 JSONEncoder は標準ライブラリじゃなくて Foundation ですよね？ (edited)

ですです。

3:31 AM

Foundation Encoders by itaiferber · Pull Request #9005 · apple/swift

This implements the JSONEncoder, JSONDecoder, PropertyListEncoder, and PropertyListDecoder types proposed by SE-0167. This pulls all Foundation-specific work out of #8124 for separate integration. ...

JSONEncoder を JSONSerialization で実装するのおもしろいですね。

レイヤー的には Himotoki とかと変わらないわけだ。

ですね。でも decode/encode のコード書かなくていいのうれしい。

3:34 AM

Realm とかもこれに準拠することになるのかな？

3:35 AM

Swift 4 出たらこれ使って、 SwiftPM 対応の軽量 DB 書いてみようかなぁ。ずっとほしいと思ってるけど、シリアライズ部分が微妙で思いとどまってる。

jsonのキーと合わせるのはkeyPathで出来るのかな

3:35 AM

capitalCaseとかsnake_caseとか、吸収してくれる感じならサイコーだ

読み込みも JSONSerialization だった。 https://github.com/apple/swift/pull/9005/files#diff-97ae7c2e808a30701d6e28271b8b6073R818

Foundation Encoders by itaiferber · Pull Request #9005 · apple/swift

This implements the JSONEncoder, JSONDecoder, PropertyListEncoder, and PropertyListDecoder types proposed by SE-0167. This pulls all Foundation-specific work out of #8124 for separate integration. ...

jsonのキーと合わせるのはkeyPathで出来るのかな

CodingKey でやらないと駄目だと思います。 caseの吸収するならコンパイラの自動生成に頼らずに自前でCodingKey型作って init(from decoder: Decoder) throws 実装しないとだめっぽいですね。

なるほど

Mirror使ってシリアライズのデフォルト実装とか少し試してたけど、SE-0166 を待ちたくなった。

Mirror 使いたいケース大分減りそうですね。

減りますね

4:22 AM

後はOptionalをAnyに入れてしまった、ぐらいだろうか

w

4:28 AM

なんで let a: Int? = 42 let b: Any = a let c: Int? = b as! Int? はだめなのに enum Box<T> { case value(T) } let x: Box<Int> = .value(42) let y: Any = x let z: Box<Int> = y as! Box<Int> はできるんですか？

as! がオプショナル周りで変なことしてるからだと思います

(x as? Foo)! 扱いとか？ (edited)

SE-166 でどうしてもわからないのがサブクラスのデコードの扱いなんですが、

class Base : Decodable { } class Concrete : Base { } struct Foo : Decodable { let obj: Base public init(from decoder: Decoder) throws { self.obj = /* ???? */ } }

どうやってデコードするのだろう。 (edited)

それは encoder 次第？

encode 時に obj のタイプ情報を一緒にエンコードしておくって事ですよね？

@koher ここらへんかなあ、Optionalが絡む as! について分岐がある Expr *visitForcedCheckedCastExpr(ForcedCheckedCastExpr *expr) { https://github.com/apple/swift/blob/3d178be169dd42b85f505ee1502232610535e4a3/lib/Sema/CSApply.cpp#L3491

swift - The Swift Programming Language

じゃないですかね〜？

4:34 AM

@omochimetaru そのコード 7780 行もあるんだけどｗ

この間の変性の話の続きなんですが

4:38 AM

Decoder<Base>にそれが必要な気がする (edited)

4:40 AM

で、Baseに関して

4:41 AM

struct Foo<B: Base> : Decodable { let obj: B public init(from decoder: Decoder) throws { self.obj = /* ???? */ } } こうするんじゃないかしら (edited)

Foo<Base> だとしても Concrete のインスタンスは持てるから、解決できない気がします。

あーー

4:45 AM

エンコード時にロストしてしまう

4:45 AM

確かに

4:46 AM

うーん、でも、それは明記された型の範囲でエンコードするのが責任の範囲な気もする

Base を open には出来ないってことですよね。

subclassを作るときに、デコード/エンコードの処理を書くことを強制させる仕組みがあれば (edited)

4:48 AM

openに出来る?

https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md#inheritance この項をみると class Base : Codable { let color: Color } class Concrete : Base { let name: String } みたいなのがあったときに { name: "FOOBAR" super: { color: "#abc109" } } みたいにエンコードされるように読めて、

Swift Archival & Serialization API by itaiferber · Pull Request #9004 · apple/swift

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

あーーー

4:55 AM

なるほど、なるほど、

container.decode(Concrete.self, forKey: .obj) じゃないとデコードできないのはあきらか。

ですね

4:56 AM

だから、エンコーダーは、型の定義がBaseの型ならBaseとしてしかエンコードしてはいけないはず。 (edited)

4:58 AM

public protocol Encodable { /// Encodes `self` into the given encoder. /// /// If `self` fails to encode anything, `encoder` will encode an empty keyed container in its place. /// /// - parameter encoder: The encoder to write data to. /// - throws: An error if any values are invalid for `encoder`'s format. func encode(to encoder: Encoder) throws }

この生え方だと、自身の宣言がBase型かConcrete型かの区別つかない気がする (edited)

5:01 AM

public protocol Encodable { /// Encodes `self` into the given encoder. /// /// If `self` fails to encode anything, `encoder` will encode an empty keyed container in its place. /// /// - parameter encoder: The encoder to write data to. /// - throws: An error if any values are invalid for `encoder`'s format. staitc func encode(to encoder: Encoder, instance: Self) throws // <- staticなら宣言されてる型から取れる }

これなら整合性が取れるかな?

5:02 AM

それとも、実際にはBase.encode: (Base) -> (Encoder) throws -> () を使っていて問題なく動くのだろうか

たぶんこんな感じになるんだけど

struct Foo : Decodable { let obj: Base public func encode(to encoder: Encoder) throws { let objType: ObjType switch self.obj { case is Concrete: objType = .concrete //... default: objType = .base } container.encode(objType, forKey: .objType) container.encode(obj, forKey: .obj) } public init(from decoder: Decoder) throws { objType = container.decode(ObjType.self, forKey: .objType) let ObjT : Base.Type switch { case .concrete: ObjT = Concrete.self // ... case .base: ObjT = Base.self } self.obj = container.decode(ObjT, forKey: .obj) } }

(edited)

これだとBaseはopenにできないですね

そうなんですよね。

5:08 AM

@objc なら NSClassFromString NSStringFromClass でなんとか.

struct Foo<B: Base> : Decodable { let obj: B public func encode(to encoder: Encoder) throws { B.encode(obj)(encoder) } public init(from decoder: Decoder) throws { self.obj = B(from: Decoder) } }

これなら、宣言の外の情報は破棄されますが、Bはopenにできそう。

マージされたらいろいろ触ってみます。

5:13 AM

class Foo { func foo() { print("Foo") } } class Bar : Foo { override func foo() { print("Bar") } } Foo.foo(Bar())() // -> "Bar"

なんで、なかなか厳しいです。

ゲーッ

5:14 AM

encodeをstaticにしないと危険だ

let obj: Foo = Bar() Foo.foo(obj)() これでもいっしょ。

class Foo { class func encode(obj: Foo) { print("Foo: \(obj)") } } class Bar: Foo { override class func encode(obj: Foo) { print("Bar: \(obj)") } } Foo.encode(obj: Bar()) // Foo: __lldb_expr_.Bar

5:16 AM

こっちですかねぇ

5:17 AM

overrideで引数のFooが書き換えられない…

5:17 AM

ダメな気がしてきた

Base が Codable でなければ、型が失われるのは必然に思える。

protocol Encodable { static func encode(obj: Self) } class Foo: Encodable { class func encode(obj: Foo) { print("Foo: \(obj)") } } class Bar: Foo { class func encode(obj: Bar) { print("Bar: \(obj)") } } Foo.encode(obj: Bar()) // Foo: Bar.encode(obj: Bar()) // Bar: func encode<E: Encodable>(type: E.Type, obj: E) { E.encode(obj: obj) } encode(type: Foo.self, obj: Bar()) // Foo: encode(type: Bar.self, obj: Bar()) // Foo:

いけるかと思ったけどダメだった

5:35 AM

変性周りが蔑ろなのなんとかしないと壁を超えられない気がする

5:36 AM

でなければ、classは割りを食うことになりそう…

あいや Base: Codable か。

5:41 AM

DerivedConformanceCodable.cpp とかあるから、コンパイラの自動生成が頑張ってくれると期待。 https://github.com/apple/swift/pull/9004/files#diff-9ceab8e46e5cb79b6cf990fe2b464e21

What's in this pull request? Now that the core types introduced by SE-0166 have been sunk into the Swift standard library, the stdlib and compiler portions of #8124 and #8125 can be combined into o...

5:42 AM

ジェネリックなサブクラスのテストケースとか見当たらないのは心配だけど。

Development Snapshotをちょっと使ってみたのだけど、

extension Sequence { fileprivate func grouped<U: Hashable>(by transform: (Iterator.Element) -> U) -> [U: [Iterator.Element]] { return reduce([:]) { dictionary, element in var dictionary = dictionary let key = transform(element) dictionary[key] = (dictionary[key] ?? []) + [element] return dictionary } } }

で

console.log error: redundant conformance constraint 'U': 'Hashable' fileprivate func grouped<U: Hashable>(by transform: (Iterator.Element) -> U) -> [U: [Iterator.Element]] { ^ note: conformance constraint 'U': 'Hashable' inferred from type here fileprivate func grouped<U: Hashable>(by transform: (Iterator.Element) -> U) -> [U: [Iterator.Element]] { ^

なんてエラーが出るようになったのね。

6:59 AM

戻り値が [U: [Iterator.Element]] だから U: Hashable は要らない。

かしこい

7:19 AM

これ今ガリガリwhere句書いてるの大幅に削れる

結局、SE-0166の public protocol Encodable { func encode(to encoder: Encoder) throws } が↓でない理由ってよくわからないままですっけ？ public protocol Encodable { func encode<T: Encoder>(to encoder: T) throws } swift-evolutionとかで聞いてみたらいいのかな？

encoderは任意のパスから任意の型を取り出せる抽象であれば良いので、ジェネリックスにする必要は無いのだと思います

1:33 AM

ああ、それはデコーダーだ

どっちでもいいならジェネリックメソッドにした方が静的ディスパッチになって速いですよね？

あーそれは確かに

Swift の標準ライブラリってあまりプロトコル型で引数をとらない印象があったので違和感を感じています。印象だけかもしれませんが。

1:35 AM

DB から大量に読み込みとか考えると繰り返し実行されるから、動的ディスパッチのオーバーヘッドが効いてきそう・・・。（それは decode だけど、同じ話として） (edited)

型消しの言語機能化入るのと関連して、protocol周りを暗黙的にGenerics扱いにする隠し球がくる、とかでしょうか

1:37 AM

高望みしすぎかなw

「型消しの言語機能化」って Generalized existentials のことですよね？

はい

1:38 AM

名前を覚えきれない

はい、僕も今ググって確認しましたｗ

1:40 AM

あれって抽象のまま保持しないといけないこともあるし、最適化できない気がするんですよねぇ。というか、最適化できるケースはジェネリック関数／メソッドでいいわけで、それじゃできないことをするときに Generalized existentials を使うことになるんじゃないですかねー？

あ、いや

という関連で、「暗黙的にGenerics扱いにする」も厳しそうな？

Genericsな引数として入ってきたprotocolを、変数に格納するときに関連がありそうだな、と

1:42 AM

素protocolで宣言された引数は、そのままGenerics扱いにしてしまっても問題なくなるかしら？と思ったのです

1:42 AM

(そんなに考えてない)

うーん、コーナーケースで問題が出そうな気も？

例えば今適当にprotocolで宣言した引数をGenericsに変更して困る事って

1:44 AM

Optionalなどのモナドに包んで推論不可能になることだと思うんですよね

1:44 AM

うーん、でもこれは関係ないか

(SomeProtocol) -> SomeProtocol みたいな型の変数に入れるためには抽象のままじゃないといけないけど、関数コールしてる箇所はジェネリック扱いすればよさそうだし、何かあるかな・・・。

返り値protocolは、受け手側が具体型じゃないんで、推論不可能

1:45 AM

あー

1:46 AM

そうか、protocolな型を受け取ってそれをそのまま渡す、

1:46 AM

あり得ますね

1:46 AM

これは困る

んーでも、 Foo: SomeProtocol があったとして、 func bar<T: SomeProtocol>(_ x: T) -> T { return x } let foo: SomeProtocol = Foo() let foo2: SomeProtocol = bar(foo) のように bar がジェネリック扱いでも問題ないですよね？

それはそうなんですが

まあ、暗黙ジェネリック化はちょっとやりすぎでなさそうな気がします。何か問題起こりそうだし。

それが可能になるためには、全てのprotocol型変数が言語機能によって、型消し相当の具体型に昇華してないといけない

1:50 AM

でもそれが可能なら、全てのprotocol型をGenerics扱いに出来そうだ

あ、↓はダメだ。ジェネリック化できない。 func foo(x: Foo<SomeProtocol>) -> Foo<SomeProtocol> { ... } (edited)

1:51 AM

func foo<T: SomeProtocol>(x: Foo<T>) -> Foo<T> { ... } にしたら、 Foo が T について covariant じゃないから戻り値の型に互換性がなくなっちゃう。

func foo<T: SomeProtocol, U: SomeProtocol>(x: Foo<T>)->Fooですよね元のものは (edited)

1:52 AM

その上で、SomeProtocolで宣言されたものが型消しになるのなら、Okだと思います (edited)

↓だとできないですね。 func foo(x: Int) -> SomeProtocol { switch x { case 0: return Foo() case 1: return Bar() case _: return Baz() } }

そう。その場合はSomeProtocolが、型消し扱いの具体型になる

1:55 AM

その扱いなら、Generics化が出来ると思います

AnySequence 的な型を使えばってことですか？

はい

1:56 AM

protocolで宣言された変数がAnyProtocolになって、

そもそもよく考えたら、↓をジェネリック化しても大丈夫と主張してるということは、それが真ならこういうケース（引数だけプロトコル型）では自動ジェネリック化も問題を起こさないはずですね・・・。 public protocol Encodable { func encode(to encoder: Encoder) throws }

そうですねw

そう考えれば自動ジェネリック化もなくはない？

1:58 AM

もしくは、↑をジェネリック化して問題が起こるケースがあるかなぁ・・・。

ちょっとまだ考えきれてないんですが、自動Generics化で、推論周りで破綻しないかな、破綻がなければ大丈夫

2:00 AM

Protocol?でnilが推論不可能なのも、AnyProtocol?.noneということにすればよくて

2:00 AM

型パラが必要で推論できない場合も、代表的な具体型を差し込めば良さそうだ

うーん、やっぱ Any よくない気がする・・・。

そして、Anyがprotocol<>の型消しに帰結する、と、しなきゃいけない

2:01 AM

うーん

値型とサブタイピングは相性悪いですね・・・。

2:02 AM

プロトコル型が witness table 使わなきゃいけないのと同じように、 Any にも気持ち悪さを感じる。

2:03 AM

プロトコル型変数も Any も禁止とかしたら、さすがに無理かなぁ。どうしても Any にせざるを得ないケースもあるしなぁ。

2:04 AM

参照型と、参照型とみなせるイミュータブルな値型なら問題ないと思うけど。 (edited)

いや、Anyがprotocol<>の型消しであると言う解釈で良ければ

2:04 AM

普通にありえますね

でも Optional と Any の問題は値型関係ないか・・・。

今思い付く限りでは、Generics化は成り立つんですが、現実的なコンパイル時間に収束するかが全く予想できない

でも、最初からジェネリック関数／メソッドだったら大丈夫なわけですよね？暗黙的にオーバーロードされてるという解釈なら問題ないのでは？

それはそうですね

2:07 AM

今ちょっと考えてるのは

2:08 AM

protocol型変数を持つ型を、Generics型に昇華出来ないか、と言うことを考えてました

2:08 AM

ちょっと厳しそう

それは難しいと思います。

protocol型引数が、inoutなのはあり得るんでしたっけ

2:09 AM

これがokだとGenerics化は破綻しそう

struct Foo { var bar: BarProtocol } を struct Foo<Bar: BarProtocol> { var bar: Bar } にしてしまうと、 extension Int: BarProtocol {} extension String: BarProtocol {} var a = Foo(bar: 123) let b = Foo(bar: "xyz") a = b の最後の行ができなくなってしまう。

ですね

2:12 AM

変数は無理と言うかおそらく意味がない、同じ理屈でinoutな引数もダメなはず

なので、変換可能なのは、純粋なプロトコル型引数のみの場合ですね。

2:12 AM

inout は引数でもあり戻り値でもあるので、戻り値の場合と同じかと思います。

そうすると、1つの型にTとUを重ねるのは無理なので

2:13 AM

これも出来ませんね、かなしい

2:16 AM

inoutを引数と返り値に分解して解釈する過程で差し込めば大丈夫なのかな

2:17 AM

それはさておき、Encoderはジェネリックスじゃないのは気になりますね

そうですねぇ。

上の方しか読んで無いけど

2:18 AM

型のパラメータでも

2:18 AM

特殊化はされると思う

2:19 AM

encodeを呼び出すときにレシーバーの型が見えてれば。

ん？特殊化されるジェネリック関数でなく、プロトコル型引数になってるのはなぜ？って話。

encodable.encodeにおいてencoder Eが

2:20 AM

encodable<E>.encodeとなるか encodable.encode<E>となるか

2:21 AM

の違いで、速度的な話なら、前者でも特殊化はされると思うから、同じだと思う

Encodableは別にEncoderを型パラとして定義はしていない

あれ？そうなのか、勘違いだ

任意のEncoderに対してencode関数が使える、というだけ。

Encoderはただのプロトコル？

y

assoc typeかと思った。

そこがミソ

あれ、じゃあ、

2:23 AM

assoc typeの無いプロトコルを

なので、Encodableなら、その瞬間にJsonもplistもprotobufも使える

ジェネリックでないアレでexistebtialでうける形になってるのか

2:24 AM

だとするとその場合でも特殊化されるのかな・・・？

それは、protocol型引数を暗黙的にGenerics化できるということ、そして上の議論

method<X:P>(x: X)と method(x:P) Pにassoc tyがない場合にはどちらでも書けるがコンパイル結果がどう変わるか

2:26 AM

というのがコアな謎か。

そうね、僕の議論はそこにさらに

うん(続きはまだ読んで無かった

Generalized existentialsがあれば、成り立つようになるのでは(直感)ってやつ

2:27 AM

associatedtypeありでも。

GEがあればアソックありでも同じ議論ができると思うよ。

func encode(to encoder: Encoder) throws は自動生成されるというのがポイントのような気がします。 (edited)

2:29 AM

PRの自動生成している箇所 https://github.com/apple/swift/pull/9004/files#diff-9ceab8e46e5cb79b6cf990fe2b464e21R407 // @derived func encode(to encoder: Encoder) throws {

Swift Archival & Serialization API by itaiferber · Pull Request #9004 · apple/swift

What's in this pull request? Now that the core types introduced by SE-0166 have been sunk into the Swift standard library, the stdlib and compiler portions of #8124 and #8125 can be combined into o...

コンパイラに自動生成タイミングがあるから、普通のやつと違って、特別に特殊化をしこむ余地とかがあるかもって事ですか？

この @derived というキーワードを apple/swift リポジトリで探すと、 enum の Equatable, Hashable, RawRepresentable 、 Errorの _nsErrorDomain などで使われてて、それらは全部ジェネリックでは無い。

2:33 AM

ジェネリックなメソッドを自動生成するのを避けているのかな？と。

ふむ。他もそうなってるんですね。

ジェネリックの方が良い悪い、ジェネリックでは出来ないケースがある、とかではなく、実装上の理由なのかな？と。

なるほど。

まあ、PRにコメント書いて聞くのが早い気がしますが。 (edited)

func encode(to encoder: Encoder) throws このメソッドって、実際には基本的に外部ライブラリであるエンコーダーから呼ばれるわけで、specialize しようがないと思うんですけど違います？

2:50 AM

encode<T: Encoder>( でだめな理由は無いけど、そうする意味もないのでは？ということです。 (edited)

1

自動生成されたencodeが、自身が持つフィールドのencodeを呼ぶことは無いのかな

2:51 AM

それがあるとGenericsにする価値がありそうです

let farm = Farm(name: "Old MacDonald's Farm", location: Location(latitude: 51.621648, longitude: 0.269273), animals: [.chicken, .dog, .cow, .turkey, .dog, .chicken, .cow, .turkey, .dog]) let payload: Data = try JSONEncoder().encode(farm)

使い方がこうだから、JSONEncoderが内部でfarmのencodeメソッドを呼ぶのか。

基本的に外部ライブラリであるエンコーダーから呼ばれるわけで、specialize しようがない

標準ライブラリのジェネリック関数は標準ライブラリ外から呼んでも specialize されますよね？外部だと specialize できないというわけでもない気が。 @_specialize とかもありませんでしたっけ？

マジか

@_specialize はライブラリ側につけるのか。

そんな謎技術があったのか。

2:57 AM

bitcodeとかってそういうところで活躍してんのか？

bitcodeは無関係かと

あら。。 (edited)

外部でも利用側からリンクするときに specialize されたバイナリを吐けばいいから原理的にはできそうな気が？ (edited)

JSONEncoderのencodeメソッドの中で、引数で受けたEncodableのencode(encoder)を呼ぶ部分はどうしようも無いですよね

ライブラリ外から呼んでも specialize されますよね？

呼び出し側をコンパイルするときはそうですが、この場合呼び出し側であるエンコーダーをコンパイルするときには何も分からないし、func encode をコンパイルするときに encoder が JSONEncoder であるか否かはわからない。 (edited)

3:01 AM

@_specialize(where T == JSONEncoder) func encode<T : Encoder>(to encoder: T) throws { ... } ってしとけばいいかもしれないけど、使っちゃ駄目

encode をコンパイルするときは specialize されてない抽象の状態でコンパイルし、呼び出し側をコンパイルするときに encode の specialize 版を生成することはできないですか？

それが出来るなら @_specialize は存在しないのでは (edited)

現段階での挙動ではなく、理論上可能かどうかという意味でです。

3:04 AM

たとえば、 encode のバイナリにリビルドするのに十分な付加情報を埋め込んでおけば（バイナリ化されたASTとか）リンク時に specialize することはできるはずです。

3:06 AM

そこまでしなくても、プロトコル型引数が抽象表現されているはずなので、それを specialize することってできそうな気がするんですが無理なんでしょうか？ローレベルに詳しくないので想像の話ですが。

つまり、stdlibとか全部を含めて whole module optimization する的な話ですか？

呼び出し側ってここで言うと例えば JSONEncoder なので func encode をコンパイルする前に既にライブラリとしてコンパイルされているという認識なんですけど、それは良いですか？ (edited)

はい、それはよいです。

3:08 AM

コンパイル済みのものを解析して、抽象表現されている部分だけを specialize するのは無理？

3:08 AM

あれ？機械語まで落ちてるのか。

3:09 AM

LLVM レベルでとまってる気がしてたけど、

MyType.encode をコンパイルするときに、 specialize 出来たとして、呼び出し側がその specialize されたメソッドをどうやって呼ぶのか想像がつかないです。 (edited)

LLVMIRのレベルでも型情報はなくなってますよ

じゃあそもそもの話として、GenericsTypeとGenericsFunctionは全然違うのか

@tarunon いや、GenericsFunctionは、外部リンクするように抽象的な版のバイナリを吐いていて、抽象的な版はその場限りなGenericsTypeを引数に受けるような挙動ではある

型パラはあるけど、中身では具体型として扱えるものではない、ということ

3:14 AM

つまり、<Foo: Protocol>(foo: Foo)においてFooは具体的な型パラだが、fooはProtocol型変数と変わらない状態?

回答を書こうとしてるけど曖昧なところが出てきたからちょいまち

specialize 云々は抜きにして、前言撤回します。 func foo<T: Encoder>(to encoder: T) の方が良い。

3:26 AM

理由書いてるけどちょっとまってくださいー

今って、標準ライブラリのジェネリック関数／メソッドについては外部からコールしても specialize されると思うんですがなぜですか？標準ライブラリだからできる芸当？

3:27 AM

public struct Foo<T> { private let array: [T] public init(array: [T]) { self.array = array } public func map<U>(_ transform: (T) throws -> U) rethrows -> Foo<U> { return Foo<U>(array: try array.map(transform)) } public var count: Int { return array.count } }

@tarunon LLVMIRではジェネリックな関数の引数は、 (x, wt, xt) な 3つの引数に展開されてて x: Catなどの具体的な型の値へのポインタ wt: xとセットで使える、Protocolのメソッド定義に準拠したwitness-tableへのポインタ xt: xの元々の型 Cat の型の型へのポインタで呼び出されるようになってる。で、wtからメソッドを引っ張ってくると、引っ張ってきた関数ポインタは、(x, xt) を受け取るようになっていて、その関数の内部で、 xに対して Cat に定義されてた本物のメソッド呼び出しがされる。

Array.map は specialize されてるっぽい

xtの使い所は、例えばプロトコル型のままコピーとかしてるときに、値のコピー自体が、xtから取り出された「コピー用の関数」に x を渡す形にコンパイルされる。これによって、Catがstructの場合は値コピー、classの場合は参照コピー + Retain , みたいな挙動が抽象化される

public protocol BAR { func foo() } public func XXXXX<T : BAR>(arg: T) { arg.foo() } public func ZZZZZ(arg: BAR) { arg.foo() }

-O -emit-ir 結果 https://gist.github.com/rintaro/8794ecd01e78e6b001fce192b07f2d7d#file-test-sil

test.sil

つまり、<Foo: Protocol>(foo: Foo)においてFooは具体的な型パラだが、fooはProtocol型変数と変わらない状態?

で、プロトコル型変数 (Existential) は、 (x, wt, xt)の 3 つのフィールドをもつ struct みたいなバイナリになるから、変わらないっちゃ変わらない

@omochimetaru wtは、Fooへのテーブル?それともProtocol全般へのテーブル?

「Fooは具体的な型だが」については、実行時においては、 xt の形で保持されてる

3:31 AM

ちょっと話題がぶつかってるので #swift-2 で。

@omochimetaru の言っている通りジェネリックな方は引数で型情報が渡ってくるので、直接その witness table にアクセス出来るけど、後者は protocol 値からいろいろ情報抜き出さないといけない分だけ手数が増える。

specialize 関係なくジェネリックな方が速いのか。

ですね。

@rintaro AssociatedTypeが無いprotocolの場合は Protocol Existential 型の値になるけど、それが結局 (x, wt, xt)の３フィールドだから、情報抜き出すところは同じだと思います。

呼ぶ側／呼ばれる側のどちらが取り出すか、の違いではない？

protocol Hogeable { func hoge() -> Int } func callHogeableHoge(hogeable: Hogeable) -> Int { return hogeable.hoge() } ↑こういうのがあるとき、LLVMIRだと、↓こういう引数になってる。 (x, xt, wt) の3タプルになっている。

%P4main8Hogeable_ = type { [24 x i8], %swift.type*, i8** } define hidden i64 @_TF4main16callHogeableHogeFPS_8Hogeable_Si(%P4main8Hogeable_* noalias nocapture dereferenceable(40)) #0 { ... }

SIL 的には open_existential_addr が入っているか否か。 https://github.com/apple/swift/blob/master/docs/SIL.rst#open-existential-addr

swift - The Swift Programming Language

protocol Fugable { typealias Element func fug() -> Element } func callIntFugableFuga<F: Fugable where F.Element == Int>(fugable: F) -> Int { return fugable.fuga() }

↑一方こういうのがあるとき、LLVM IR だと↓こうなる

define hidden i64 @_TF4main18callIntFugableFugauRq_S_7Fugablezqq_S0_7ElementSi_Fq_Si(%swift.opaque* noalias nocapture, %swift.type* %F, i8** %F.Fugable) #1 {

Existentialがないけど、結局、引数として x, wt, xt が並んでる。 (edited)

3:49 AM

あ〜たしかに

3:49 AM

xのサイズが24バイトを超えるかどうかとかで

3:49 AM

直接ペイロードがコピーされてるか、ポインタ渡しになっているかとかが変わるので

3:49 AM

そこらへんの分岐が、SILのopen_existential_addrがLLVMになる時に

3:49 AM

直接のアドレス操作バイナリにコンパイルされる感じだけど

3:50 AM

間接の場合は引数渡しより遅くなりうるかも？？

3:51 AM

あ、でも引数にバラける場合は常にopaqueポインタ渡しになるから、それと同じなのかな、うーん、わからない。

@norio_nomura

呼ぶ側／呼ばれる側のどちらが取り出すか、の違いではない？

そうなんですが、呼ぶ側は通常 existential 型で値を持っているわけではないので、generic の場合 existential 型を生成する必要がない場合がほとんどだと思うのです。

たしかに！これは同意です、cat型で保持していて、渡す時にプロトコルexistentialにアップキャストするのが代替だから、パック側のコストもありますね。

なるほど

@koher

標準ライブラリのジェネリック関数／メソッドについては外部からコールしても specialize される

stdlib は特別らしいです。 https://github.com/apple/swift/blob/master/docs/OptimizationTips.rst#advice-put-generic-declarations-in-the-same-module-where-they-are-used

Swift Archival & Serialization API by itaiferber · Pull Request #9004 · apple/swift

swift - The Swift Programming Language

だとすると Encoder のコードも Codable ごとに specialize されうるのかな。

Foundation Swift モジュールも特別扱いの対象なら可能性あるかもしれないですね。

@rintaro おお、ありがとうございます！

3:14 AM

SwiftPM でソースからビルドした場合はモジュールまたいでも specialize してくれるようになったりするとうれしいですねぇ・・・。

どうも特別扱いは -sil-serialize-all っていうオプション付きでモジュールがコンパイルされているか否かによるみたいです。この場合、実装含めた全てのSILが .swiftmodule にシリアライズされるので、caller側はcalleeのSILレベルでの実装を見通して最適化が出来ようになると。

1

3:17 AM

ためしに swift build -Xswiftc -Xfrontend -Xswiftc -sil-serialize-all でビルドしてみたら

LLVM ERROR: Invalid abbrev number <unknown>:0: error: merge-module command failed with exit code 1 (use -v to see invocation)

お、それは現時点ではできなくても将来的にはできる可能性もあるのでは？

3:20 AM

それがありうるなら encode がジェネリックの方がいい強力な理由になるんですけどね〜。

3:22 AM

そう言えば、昨日言ってた @_specialize を使うべきでないという理由はなんですか？

とりあえず encode については質問済みなので回答来たらまた。 https://github.com/apple/swift/pull/9004#pullrequestreview-35266665

What's in this pull request? Now that the core types introduced by SE-0166 have been sunk into the Swift standard library, the stdlib and compiler portions of #8124 and #8125 can be combined into o...

ありがとうございます！

@_specialize について、 _ で始まるものは本当に使わないほうがいいです。意図的にやっているのかっていうくらい頻繁に仕様が変わります。

こういう場合って、 PR でこっちの方がいいねってなったら、 Proposal と違った形で実装されたりするんですか？

実質のインターフェイスが変わらない限り evolution 通さずに変更はあると思います。

なるほど。

@_specialize は実際 Swift3 と現状の master でインターフェイス変わってます Swift3 @_specialize(Int, String) func foo<T, U>(x:T) -> U master @_specialize(where T == Int, U == String) func foo<T, U>(x:T) -> U

@_specialize のインターフェースも変わってるんですね・・・

3:38 AM

@_specialize は代替手段がないから辛いですね。

3:38 AM

とはいえ、どうせ Swift はソース互換性ないからバージョンアップ時は一緒に直してしまえばいい気もｗ

_開始は、マイナーバージョンアップですら保障されてない気がする

普通の _Foo は使わないですが、 @_specialize は特殊なのかと思ってました。

ためしに swift build -Xswiftc -Xfrontend -Xswiftc -sil-serialize-all でビルドしてみたら

これ、シングルモジュールのパッケージならビルド出来ますね。

ビルドできるが、各ソース毎の中間 .swiftmodule は大きくなるけど、パッケージのは大きくならない。

どうも特別扱いは -sil-serialize-all っていうオプション付きでモジュールがコンパイルされているか否かによるみたいです。この場合、実装含めた全てのSILが .swiftmodule にシリアライズされるので、caller側はcalleeのSILレベルでの実装を見通して最適化が出来ようになると。

ほ〜〜〜〜〜〜

PR0166い途中まで読んでるけどこれめっちゃ頭いいな

7:14 AM

あるstructが:Encodableに準拠してるとき、

7:14 AM

自動的にプロパティ名と同じcase名をもったenumが定義されて

7:14 AM

そのオブジェクトをエンコードする時のコンテナ(JSON Object)とかにあたるオブジェクト

7:14 AM

に、型パラメータとしてCodingKeyが取れるおかげで

7:15 AM

プロパティ名に対応しないキーを間違って使っちゃう可能性が排除される

7:15 AM

public struct Location : Codable { private enum CodingKeys : CodingKey { case latitude case longitude } public func encode(to encoder: Encoder) throws { // Generic keyed encoder gives type-safe key access: cannot encode with keys of the wrong type. let container = encoder.container(keyedBy: CodingKeys.self) // The encoder is generic on the key -- free key autocompletion here. try container.encode(latitude, forKey: .latitude) try container.encode(longitude, forKey: .longitude) } }

7:17 AM

Encoder の container メソッドが、 K.Type を引数で受けていて、 container の型パラに引き継がれる。 enum CodingKeysはstruct Locationのinner typeで、Locationのために自動定義されたやつだから、プロパティ名とキーが静的に結びつく

継承については親クラス部分をまとめたオブジェクトを super キーにぶら下げるみたいですね

7:59 AM

{ "a": 3, "b": 2, "super": { "c": 1 } }

0167も見てるけど、エラー型に [CodingKey] がついて無さそうに見える。

8:59 AM

JSONが壊れてる時、ルートからみてどこが壊れてるのか、デコード時にパスがトレースされるんでそれを例外に保持して、メッセージに出したい

8:59 AM

レビュー期間とっくに終わってるしオシマイ

CocoaError投げるみたいなこと書いてるなー

9:44 AM

Errorが役に立た無さそう

そのError型になんのassociated valueもないんだよねえ

9:45 AM

Encoder型自体は codingKeys: [CodingKey?] としてパスを保持してるから

9:45 AM

仕組み的にはできるはずなんだけども。

http://twitter.com/omochimetaru/status/857906332002689024

Swiftのプロパティとinout参照を組み合わせたときの挙動が面白い on @Qiita https://t.co/pBDyCv6D89

10:37 AM

かいた

https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md#the-law-of-exclusivity によりそういうコードが今後きちんと拒否されるかも。

swift - The Swift Programming Language

そうですね、オーナーシップの展開は気になっていて、参照のことが気になって試していました

10:55 AM

この場合だとcatはMainの一部だから、参照をborrowしようとすると、catのborrowの間はMainが不正な状態になっているから、メソッドが呼び出せない？

10:56 AM

Catがクラスの場合でも記事の内容は成立すると思うけど、その場合はどうなるんだろう。

どう処理するのか全然予想がつかないw

完全フロー解析すれば、updateIntにcat.ageをborrowしているケースがあるから、updateIntの中でcat.ageをリードするのは不正って事になるのかな？でも外部モジュールとか跨いでいると無理そうですよね

https://github.com/devincoughlin/swift/blob/master/test/SILOptimizer/exclusivity_static_diagnostics.swift とりあえず現状こんな感じのテストケースで実装済みです。

devincoughlin/swift

swift - The Swift Programming Language

11:00 AM

まちがえた https://github.com/apple/swift/blob/master/test/SILOptimizer/exclusivity_static_diagnostics.swift

swift - The Swift Programming Language

うお！このフォークで試せるんですか？

master で -enforce-exclusivity=checked つけると試せるです。

おお。実はちまちま探してたんだけどそれっぽい実装ロジックが見つからなくてまだお試し実装無いのかと思ってました

11:03 AM

exclusivityってキーワードだったんですねどうやって追っかけているんですか？

11:03 AM

MLのOwnershipスレだけさらってたけど見つけられず。

https://github.com/apple/swift/pulls 日常的に追っかけてるだけです

Swift Archival & Serialization API by itaiferber · Pull Request #9004 · apple/swift

swift - The Swift Programming Language

なるほど・・・

11:09 AM

ちょうどゴールデンウィークだし試してみます

都合上両側にスペースを置きたくない演算子~~(lhs: Int, rhs: Int)について 1~~-2とかやるとコンパイル通らないので ~~-演算子を定義するという糞ハック

encode(to:) の理由を答えてくれてる。なるほど。 https://github.com/apple/swift/pull/9004#discussion_r114044478

What's in this pull request? Now that the core types introduced by SE-0166 have been sunk into the Swift standard library, the stdlib and compiler portions of #8124 and #8125 can be combined into o...

なるほど、すっかり忘れてました。これが通らないってこと。

protocol P { func foo() } struct S : P { func foo() { print("S.foo") } } func foo<T : P>(p: T) { p.foo() } let obj: P = S() foo(p: obj)

あ、ですです

6:55 AM

これは通らない、通そうとすると、Pの宣言が全て暗黙的にtype-erasure相当の具体型ということにならないといけないはず

6:55 AM

或いは

6:57 AM

AnyかAnyObjectのように、Protocolのまま型パラに入れれるようにならないといけない。

6:57 AM

ところでなんでAnyとAnyObjectは型パラになれるんですか？

6:57 AM

nominaltype(でしたっけ?)と関係あるのかな。

Any に関しては <T : Any> は何も書かないのと一緒扱いなのかな？ Any = protocol<> でしたし、今もパーサー時点で Any を空のコンポジションとして AST に入れている。 AnyObject も protocol P : AnyObject が protocol P : class と同義であるみたいに、 class レイアウトであること「だけ」を強制するものとして、コンパイラでの特別扱いがあるので、その絡みだと思いますが、よく分かんないですね。 (edited)

なるほど、すっかり忘れてました。これが通らないってこと。

うーん、それはそうなんですが、まだ KeyedEncodingContainer をちゃんと読めてなくて、

public protocol KeyedEncodingContainerProtocol { associatedtype SuperEncoder: Encoder mutating func superEncoder() -> SuperEncoder ... }

にできないのかがよくわかってないです。 API 全体で existential を排除できないものなのか・・・。ちょっと時間のあるときにちゃんと読んで理解して考えます。

2:13 AM

話はまったく変わるんですが、↓みたいなのほしくないですか？

extension Array { public mutating func update(_ operation: (inout Element) throws -> ()) rethrows { for i in startIndex..<endIndex { try operation(&self[i]) } } }

struct Foo { var value: Int } var array = [Foo(value: 2), Foo(value: 3), Foo(value: 5)] array.update { $0.value *= 2 } print(array) // [Foo(value: 4), Foo(value: 6), Foo(value: 10)]

(edited)

array = array.enumerated().map { $0.0 + $0.1 } // 配列の要素の値に要素番号を足す

2:33 AM

インプレースなmapだと思うけどこういう場合に使えなさそう

2:35 AM

rubyだとmap! がありますね。(!は自己変更オーバーロードの慣習

先のinoutなreduceの絡みで、mapよりupdateが欲しい場面が出てきそう

2:37 AM

返り値がvoidである必要があるから、必然的にupdateの方が取り回しやすい

そうなんだよなあ inout reduceがあるなら、これもあっていい、っていう議論がたくさん出てきそう

あっても良いというか、メモリ効率考えると無いと困るってレベルだと思う

2:42 AM

filter, map, reduce (flatMapも?)こいつらは、自己変更のメソッドも欲しい

flatMapは無理じゃ無い？型的に

Array<T>に対して返り値がArray<T>かOptional<T>なら大丈夫じゃない？あまり考えてないけど

あ、ごめん、そうだった

mapとflatMapは基本的にはTからUだけど、自己変更はTからTしか有り得ない

flattenと間違えた

reduceが、返り値持ってるからVoidで自己変更するわけじゃなく、返り値のUに対して自己変更を強制するから

2:46 AM

こいつだけオーバーロードでも違和感がないように見える、filter, map, flatMapはVoidにしないと成り立たない、オーバーロードは地獄を見そう。名前変更が妥当だけど

2:46 AM

全部updateに詰めればいいかな？

2:47 AM

mapはinout Tで大丈夫だけどflatMapとfilterはまた違うな…

@tarunon そのあたりちゃんと整理しようとすると、例の filter と filtered みたいな話になると思うんですよね。ただ、 update は map に相当するんですが、 map は戻り値の要素の型を変更できるのに対して update はできないんで、 map / mapped は違和感がありますね。 update / updated の方がいいけど、 map → updated は弊害の方が大きそうだから、 update と map かなぁと。

5月1日時点のmasterからtoolchainをビルドして使ってみたら、想像以上に変更点が多くてちょっと怯んでる…

ビルドしたtoolchainのインストーラ欲しい人いるかな？

swift-evolutionの"[swift-evolution] [Pitch] Revamp Optional and Throws" スレッドでのJohn McCallのコメント。コアチーム（の中でもエラーハンドリング分野で一番影響力がありそうなJohn）の考えが知れておもしろい。

We've definitely considered including a Result type, but our sense was that in an ideal world almost no code would be using it. It's hard to imagine an ordinary API that ought to be returning a Result rather than throwing, and once you've defined that away, the major remaining use case is just to shift computation around, like with a completion handler. That explicit computation-shifting pattern is something we're hoping to largely define away with something like C#'s async/await, which would leave Result as mostly just an implementation detail of such APIs. We didn't want to spend a great deal of time designing a type that would end up being so marginal, especially if the changing role would lead us into different directions on the design itself. We also didn't want to design a type that would become an obstacle to potential future language changes like, say, typed throws. The downside, of course, is that as long as we lack that async/await design, computation-shifting isn't real great.

1:55 AM

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036256.html

1:58 AM

前も書いたけど、↓みたいな感じで async / await 導入されてほしい。 https://gist.github.com/koher/df007741788cb197d65b6babe2acf480

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

async / await って GCD の上に構築されるイメージ？

GCD とは直交なイメージです。 GCD は非同期処理を実行するためのもので、 async/await は非同期処理をハンドリングするためのものみたいな？

2:03 AM

僕がイメージしているのは、 throws と Result<T> は相互変換できるので、同じようにして async と Promise<T> を変換できるというものです。

2:03 AM

なので

2:04 AM

throws : async try : await Result : Promise がすべて同じ関係になるだろうと。

2:04 AM

そう考えると、 rethrows と同じように reasync という概念が必要になるんじゃないかと思ってます。

2:05 AM

let r = await [2, 3, 5].map { (x: Int) async -> Int in ... }

2:06 AM

throws なクロージャが渡された map は try しなきゃいけないように、 async なクロージャが渡された map は↑のように await しなきゃいけないようにしたいと。 (edited)

2:07 AM

reasync がないと、 map に async なクロージャを渡せなくなってしまいます。

asyncにおいて、catch相当のものってあるんですか？

catch とはエラーハンドリングの意味ですか？それとも、非同期処理において、エラー処理における catch に対応するものという意味ですか？

後者です

2:17 AM

try-catchに対してasync-???

2:17 AM

いや、await-???か

↑のGistでは do - defer （このキーワードが適切かは微妙です）で await 前のスレッドに戻ってノンブロッキングな処理を表すのがいいんじゃないかと思ってます。

2:19 AM

// `do` / `defer` for `await` outside `async` functions func onClick() { do { let selectedIndex = await actionSheet([...]) ... } defer // Non-blocking }

この場合、deferに渡される値はどういうものが来るんですか？

この場合は値は渡されません。

あと、deferの中でreturnが可能、つまりyield的な動き？

repeat - while に while ブロックがないように、 do - defer には defer ブロックがない想定です。

C#の await だと、変数間の依存関係も考慮されているみたいだけど、それも含む？

func foo(url: URL) async throws -> Foo { let data = await try download(url) let modified = await asyncConvert(data) return Foo(data: modified) }

変数間の依存関係とはどういうものを指してますか？

http://qiita.com/acple@github/items/8f63aacb13de9954c5da から引用

async Task<string> AsyncMethod2(Uri uri) { using (var client = new HttpClient()) // <- 本当はHttpClientをusingで使っちゃダメ { var response = await client.GetAsync(uri); // <- 「GETせよ」のタスクを開始し、その完了を待機する var text = await response.Content.ReadAsStringAsync(); // 「レスポンスからその本文をstringとして読み出す」タスクを開始し、その完了を待機する return text; // 読み出したtextを返す } } // という「一つのタスク(Task<string>)」を表す。

(edited)

Taskを極めろ！async/await完全攻略 - Qiita

この記事は、

Task.Runを書けばとりあえず非同期で動くのはわかる
時々なんかうまく動かなかったりするけどどうして動かないのかはよくわからない
よくわからないまま書いてよくわからないまま動いてるけどこれで大丈夫なのか...

2:24 AM

response が返ってくるのを待ってから response.Content.ReadAsStringAsync() を呼んでる？

そうなります。

2:25 AM

try や await は flatMap に対応するので

2:25 AM

（そして Promise の then は flatMap と等価なので）

2:26 AM

await を 2 回書くということは then をチェーンして繋いでるのと同じです。

tryもそうですよね、なので現状swift-doはResultに対してはHakellのdo構文と同じ

はい、そうです。

2:28 AM

なので、 async / await で、 Promise に対する（ Haskell の） do のように振る舞えるはずです。

2:29 AM

JS の Promise はエラーハンドリングまで含んじゃってて筋が悪いですが、 async / await と throws / try を組み合わせれば、純粋な非同期処理と純粋なエラー処理に分離できるはずです。

2:29 AM

async throws -> T な関数は、 Promise<Result<T>> を返すようなものですね。

C#はスレッドで実装されてるぽいけど、Swiftもスレッドでってことは無さそう。

2:31 AM

C#もキューみたいなのあった気もする。

throws tryだと、catchすることで純粋なTを取り出すことが可能ですが

あー、 Promise ベースで考えてたので、 await 以降がどこのスレッドで実行されるかは async な関数を実装する側次第と考えてましたが、 Promise を return するのと同じ自由度でそれを書くにはどうするのかよく考えてませんでしたね。

async awaitは、同等のことは可能ですか？つまり、yield的な待ち合わせの機能

2:32 AM

deferがそれかな

throws tryだと、catchすることで純粋なTを取り出すことが可能ですが

catch じゃなくて try で、じゃないですか？ catch の方は Error ですよね？

えっと、tryを使ったfuncの返り値をTにするために、catchでError処理をするなりして型を純粋なTにする

C#はスレッドで実装されてるぽいけど、Swiftもスレッドでってことは無さそう。 C#もキューみたいなのあった気もする。

これに関しては、大本の非同期化する関数自体が async になって、どれを使うかによって実現されることになると思います。

func pureInt() -> Int { do { return try throwAble() } catch { //Error処理 return someValue } }

2:37 AM

こういうの

ちがうか。↓みたいなのがあればいいのか。 func makeAsync<T>(_: ((T) -> ()) -> ()) async -> T

2:42 AM

func foo() async -> Int { return await makeAsync { emit in DispatchQueue.main.asyncAfter(deadline: .now + 5.0) { emit(42) } } }

(edited)

2:44 AM

現実的にはエラーが起こることも考えて↓かな。 func makeAsync<T>(_: ((T) -> ()) throws -> ()) async rethrows -> T

2:45 AM

@tarunon それってエラーからの回復だから、非同期処理に対応させると同期化だと思うんですよね。

2:46 AM

なので、 do - defer 相当のものは同期化というのがあり得る気がしてるんですが、現実的にはノンブロッキング化する方が必要だろうなと。

2:46 AM

もし同期化であれば

2:47 AM

↓みたいな感じになるのかな・・・。 func pureInt() -> Int { do { return await asyncInt() } wait }

2:48 AM

こっちの方が理論上は catch によく対応してるような気はします。

2:49 AM

ノンブロッキングの方は、そういう関数があればいいだけな気もしますね・・・。 func doAsync(_: () async -> ()) みたいな。 (edited)

ノンブロッキングはそもそも

2:50 AM

doの中でコールバック関数呼べば良いだけな気も

↓ということですか？ func onClick() { do { let selectedIndex = await actionSheet([...]) ... } }

2:52 AM

↑のケースは、（ throws / try と同様に） onClick が async でないとコンパイルエラーがいいと思うんですよね。

あいや

2:53 AM

話が噛み合ってない気がした、ちょっと考えます

async がついたメソッドは await 付きで呼ばなければならず、 await を呼ぶメソッドは do {} で同期化しない限り async としなければいけない。

3:01 AM

throws と try と同じ感じか。

はい、そうです。

3:03 AM

理論上も throws -> T は -> Result<T> と等価で、 try は flatMap と等価だから、 async -> T と -> Promise<T> にも同じ関係が成り立つはずなんですよね。 Result も Promise も同じくモナドなので。

await で非同期実行が始まるのは、スコープ内で await 以降に await と無関係なコードが現れた時、って感じかな。

// a(), b() は () async -> Int let a = await foo.a() let b = await bar.b() let sum = a + b ... は // a(), b() は () -> Promise<Int> foo.a().flatMap { a in bar.b().flatmap { b in let sum = a + b ... } } のような感じですね。 (edited)

3:10 AM

なので、 a に代入するところから非同期に行われます。

barはmapでは

3:11 AM

thenならオーバーロードですが

let a = foo.a() let b = bar.b() let aa = await a let bb = await b let sum = aa + bb はあるんですかね

@t.ae それはないね。

async関数がawaitできるだけなら↑ができないきがする

@tarunon sum を返しているわけでなく、後続処理があるイメージです。

3:13 AM

@t.ae それはできなくていいと思います。それができるということは、モナドなまま値を取り回すことになるので。それを避けているのが今の Swift の throws / try の構文かと。

非同期処理を複数同時に走らせられないのはなんだかなーという気分が。 Promise使えって話ですが。

確かに、簡単に複数同時に走らせる方法はほしいね。

3:16 AM

↓の場合、 a と b は独立だから、並列して走ってもいいんだけど let a = await foo.a() let b = await bar.b() let sum = a + b (edited)

bar.bではaを評価してないので、同時に走れても問題ない気がする

あえて a が終わってから b が走ってほしい場合とかもあるから

非同期だとこの手の合成問題が出てきますね、try-catchではなかった問題

（ Web API へのリクエストを同時にたくさん投げたくないとか）

3:18 AM

それを↑レベルの手軽な構文でコントロールするのは、モナドの範疇外になってしまって難しいなぁ。

それは非同期を提供するクライアント側が気にすれば良いことで、async-awaitは愚直に並列で実行して良い気がします

Promise モナドは「今は値はない、けどいずれ手に入る」を表して非同期的にイミュータブルに振る舞うだけだから、

3:19 AM

↑の例で a() と b() が並列に実行されようが順番に実行されようが結果の変わらない世界の話なんだよなぁ。

3:20 AM

@tarunon その場合、 let bar = await foo.bar() let baz = await bar.baz() だと順番に走るんですよね？

3:20 AM

結構わかりづらくないですか？

Promise.all的な関数を用意してもらえばそれで良い気がする。

asyncで生成された値を評価するなら、待ち合わせが必要

3:22 AM

ですが、それ以外は極力並列に走って貰わないと、パフォーマンスが出なさそう

値を使う瞬間に待ち合わせが発生するようにする？

そんなイメージです

分かりづらくはあるけれどそれで問題が起こるケースが思いつかないですねぇ。

値を使わない場合に問題があるなら、それは非同期関数を提供する側が制御すれば良いはず

たとえば、 Qaleidospace では Qiita の API を叩いてるんだけど、回数に制限があるから、順序関係のないコールの間でも間隔をコントロールしてて、そういうときにシーケンシャルにつながってほしいとかはある。けど、シンプルな構文でなら @tarunon さんの言うような、待ち合わせが必要な場合だけ待つ方式が良さそうですね。

それって、APIClient作って、そっち側に一定時間に何回まで叩けるみたいな

3:27 AM

Queueを内蔵してasyncはそのまま提供すれば

3:28 AM

普通に隠蔽できると思うんですよね

とすると、 // a(), b() は () async -> Int let a = await foo.a() let b = await bar.b() let sum = a + b ... は

// a(), b() は () -> Promise<Int> let a = foo.a() let b = bar.b() a.flatMap { a in b.flatMap { b in let sum = a + b ... } }

相当になりますね。

あとはawaitって書いてあるところで待ってないという気持ち悪さが残るだけですね。

let bar = await foo.bar() let baz = await bar.baz() ... の場合は foo.bar().flatMap { bar in bar.baz().flatMap { baz in ... } }

3:31 AM

あとはawaitって書いてあるところで待ってないという気持ち悪さ

たしかに

3:32 AM

まったく話は変わるんですが、 Array<Optional<T>> だけに extension 書くとかってかけます？

3:33 AM

extension Array where Element == Optional まで書いて、型パラメータが書けなくて固まった・・・

書けそう

error: reference to generic type 'Optional' requires arguments in <...> extension Array where Element == Optional { ^ <Any>

(edited)

<Any>はともかく<Wrapped>はできるんですかね？

typealias ArrayO<T> = Array<Optional<T>> extension ArrayO { func foo() -> Bool { return reduce(true) { $0 && ($1 != nil) } } }

↑は書けたけど、普通に Array の extension になってる・・・

ああ Optional の Wrapped は型指定出来無さそう

@norio_nomura 型指定というか、型を指定せずにプレースホルダーのままにしたいです・・・

ジェネリックパラメータを指定できないから無理そうですね

 1> extension Array where Element == Optional<Any> { 2. func foo() -> Bool { 3. return reduce(true) { 4. $0 && ($1 != nil) 5. } 6. } 7. } 8> let a: [Int?] = [2, 3, 5] 9. print(a.foo()) error: repl.swift:9:7: error: '[Int?]' is not convertible to 'Array<Optional<Any>>' print(a.foo()) ^

3:51 AM

うーん、辛いですね・・・

Optional<T>にextension生やしてそれを呼ぶとかでは？処理によりますが

3:53 AM

reduceか。reduceはだめそうですね

実際にやりたいのは Array ですらなくて、 Promise<Optional<T>> についてのみの extension を書きたいのです・・・

3:54 AM

せっかく where T == Foo が書けるようになって、演算子を一掃できると思ったんだけど・・・。

protocol HasWrappedType { associatedtype WrappedType } extension Optional: HasWrappedType { typealias WrappedType = Wrapped } extension Array where Element: HasWrappedType { func foo() -> Bool { return reduce(true) { $0 && ($1 != nil) } } } let a: [Int?] = [2, 3, 5] print(a.foo()) let b: [Int] = [2, 3, 5] //print(b.foo()) // error: type 'Int' does not conform to protocol 'HasWrappedType'

(edited)

1

なるほど・・・

3:57 AM

ワークアラウンドの protocol を外部に露出しないといけないですが、仕方ないですね・・・

3:57 AM

ありがとうございます！

1

String が BidirectionalCollection に変わるので joined() の型も変わってしまう。

var str = [ "Hello, playground" ].joined() type(of: str) // 3.1: String.Type, 4.0: FlattenBidirectionalCollection<Array<String>>.Type

このあたりの変換後の型を Array にするのか lazy な型にするのかって難しいですよねぇ・・・

extension Array where Element == String { public func joined(separator: String = default) -> String } より

extension Array where Element : BidirectionalCollection { public func joined() -> FlattenBidirectionalCollection<Array<Element>> }

が優先されてる。

4:11 AM

優先順位の処理、これであってるのかな。

ええっ、前者の方が specific に見えるのに、そんなことになるんですか？

昨日ビルドしたtoolchainでこうなります。

なるほど・・・

SE-0166 と SE-0167 を試そうかと。

試したいですね。

署名したインストーラ作ったけど、使ってみますか？

https://github.com/apple/swift/pull/9154

[stdlib] New overload for joined() by moiseev · Pull Request #9154 · apple/swift

Now that String conforms to the BidirectionalCollection protocol, in the expression let x = [""].joined() the best matching overload for joined is no longer the one returning String. Fixes: rdar://...

1

出来立てだw

4:19 AM

4.0 SNAPSHOT そろそろなのかなあ

署名したインストーラ作ったけど、使ってみますか？

Swift のインストーラーですか？

そそ

4:20 AM

Discordのファイル共有は50MBまでか。

SwiftJPへアップロードした。 https://slack-files.com/T047W3ARY-F57932BU4-3f5fa40e21

swift-LOCAL-2017-05-01-a.pkg

Public file shared from https://slack.com/

ありがとうございます。

warning: 'flatMap' is deprecated: This call uses implicit promotion to optional. Please use map instead. とか言われてビビる。

ええっ

ArrayのOptional flatMapですか？

ぽいです

4:37 AM

あいや、違うのかな。

4:38 AM

https://github.com/apple/swift/blob/master/stdlib/public/core/SequenceAlgorithms.swift.gyb#L733

https://github.com/apple/swift/commit/98e6cafdc8ebb75e4454f7e53cce2107957b9395

swift - The Swift Programming Language

4:39 AM

間違った使い方を指摘してくれてるぽい。

おお！

4:39 AM

素晴らしい

let a = [1,2,3].flatMap { $0 + 1 } こういうやつ。closure の返値がいったん Optional になるから、効率が ~~わるい~~ 悪かった。 (edited)

[stdlib] Adding a deprecated version of flatMap to warn misuses. (#7823) · apple/swift@98e6caf

Due to implicit promotion to optional it is possible to call flatMap with a closure, that does not return an optional. This way the code works, but is unnecessary inefficient. Such uses of flatMa...

String を + で連結するとビルドが遅くなる問題って、まだ直ってないですよね。

Linux用のテストを返すallTests の定義で throws ではないメソッドを返す時にエラーが出る様になった。

extension ResolverTests { static var allTests: [(String, (ResolverTests) -> () throws -> Void)] { return [ ("testBasic", testBasic), ("testDefault", testDefault) ] // .map { entry in (entry.0, { entry.1($0) }) } // workaround } }

… error: cannot convert value of type '(ResolverTests) -> () -> ()' to expected element type '(ResolverTests) -> () throws -> Void' ("testBasic", testBasic), ^~~~~~~~~

(edited)

SE-0166 イマイチかも…

マジすか。どこがだめですか？

お、SE-0166は気になる

1

自前の Encoder を作ろうとしての感想です。 SE-0167で実装された JSONEncoder と PlistEncoder をそのまま使うぶんには良いのかもしれません。

自前実装のどのあたりでイマイチなことになりましたか？ SE-0166 は自前 Encoder / Decoder 実装がうまくいかないと意味がないと思うんですよね。 JSON とかだけでなく、汎用的な仕組みとして作られているのがおもしろいところだと思うので。 (edited)

libYAML のラッパーである https://github.com/jpsim/Yams/ を Encoder にするにはどうしたら良いのか？を前提にコードを眺めていました。

jpsim/Yams

Yams - A Sweet and Swifty YAML parser.

なるほど。 YAML だと JSON と同じだからできそうな気がしますが、 JSONEncoder は JSONSerialization に渡すための NSMutableDictionary を生成すればいいけど、 Yams 用のインプットを Encoder の仕組みで組み立てるのが難しいとかですか？

Node っていうのが Yams での値／コンテナなのですが、これを enum と struct のペイロードで作ってしまっているので、逐次シリアライズした Node を KeyedEncodingContainerProtocol とかの内部情報として持てなくなってしまいました。

9:20 AM

JSONEncoder と PlistEncoder はどちらも内部形式は NSMutableArray と NSMutableDictionary で、入れ物を親のコンテナに入れてから参照してる。

Node を逐次シリアライズするのではなく、 _JSONEncoder が NSMutableDictionary を組み立てるのと同じように、コンテナ経由で Node を組み立てて、最後にシリアライズではうまくいきませんか？

うまくいくとは思いますが [AnyHashable: Any] を得るために、PropertyListEncoder とほぼ同じコードを再実装しないといけない感じです。

9:26 AM

PropertyListEncoder が Data ではなく [AnyHashable: Any] を吐き出す仕組みがあると、幸せになれそう。 (edited)

たしかに Encodable で表現できるデータ構造って似たようなものだから、 Dictionary 化するヘルパー Encoder みたいなのがあればその後が楽そうな気もしますね。ちょっとまだ自分で実装してないのでイメージがちゃんとできてないかもですが。 (edited)

9:32 AM

もちろん、 Dictionary を経由することでパフォーマンスを損ねるケースもあるので、 Encoder が提供しているような直接組み立てていくための仕組みは必須ですが。

まあでも、参照型の Node を作ればそれなりにいけそうな気もしてきました。

ちょっと変な方向から入ってしまったけど、SE-0166普通に使うぶんには簡単で良い感じ。

2

昨日の async / await の話、 Swift 5 についての議論が始まったら swift-evolution に投稿してみようかと思うんですが、↓みたいな感じでどう思います？わかりづらいところとか変なところとかあれば。 https://gist.github.com/koher/3e04b4f1b8adbbf0379d38c0ad83a3ea ノンブロッキング化する方法についても書いた方が良さそう。

async-await-fitting-to-swift.md

asyncとthrowsを組み合わせた時に何が起こるのかが解りにくい気がします

3:17 AM

1. 入れ子関係は固定なのか (必ずasyncが外側? 2. Errorの扱いがどうなるのか (↑の通りなら () async -> Error になっている? 3. waitとcatchの併用が可能なのか、併用したときのErrorの扱いについて

@tarunon ありがとうございます。修正してみます。

11:28 PM

2 はどういうことですか？

waitでなければ、catchのタイミングも非同期化しますよね？(あっている？

async throws な関数をコールして catch だけするとどうなるのかということですか？ (edited)

はい

そうですね。その場合は catch が非同期化されますね。

11:42 PM

Details みたいな形でそういう説明を足した方が良さそうですね。ありがとうございます。

@tarunon#5049 「waitとcatchの併用」については downloadFooSync がそうなってました。また、 nonblock について書き足し、その中で catch しかしない例を追加しました。

3:08 AM

async と throws はどの順に書いても async が外側扱いがいいんじゃないかと思っていますが、そのあたりの詳細は ML で議論されればいいのかなと思います。あまり詳細に踏み込むと読むのが大変なのでとりあえず提案を投げるにはこれくらいのボリュームがいいのかなぁと。 (edited)

なるほど、それもそうですね。

モナドの中でenumを扱うときに、flatMapでassociatedvalueを取り出したくなることありませんか？上手い方法無いのかな

5:12 AM

enum MyEnum { case foo(Int) case bar(String) } func someAction(elements: [MyEnum]) { elements.flatMap { $0.foo } // ← [Int]が欲しい }

5:13 AM

foo: Int?とか生やして誤魔化してるけど流石に増えてくると辛くなってきた

うーん、↓とかしか思いつかないですねー。 elements.map { guard case let .foo(foo) = $0 else { fatalError() } return foo }

fatalは流石に困るw

6:01 AM

computed var foo: Int? でflatMapが妥当ですかねぇ、しょうがないか

ああ、そうか。↓ですね。 elements.flatMap { guard case let .foo(foo) = $0 else { [] } return [foo] } (edited)

まあ事実上そうですね

6:04 AM

多分ほぼ全てのモナドはOptional互換ではあるはずなので

6:04 AM

enum側にOptionalのアクセサ用意するのが妥当っぽい、となると言語機能でサポートして欲しいなーとなってくる

↑って汎用Eitherがほしいって話な気がします。

汎用Eitherというかですね

6:05 AM

Viewとロジックをつなぐのに、大量にイベントエミッター書くのがだるくて

6:05 AM

enumで流してしまえ~と思って public enum Output { case dataSources([Model]) case loading(Bool) } こういうのを書くと

6:06 AM

使う側でswitch書くのがしんどくなってしまった

6:06 AM

caseは大量に増えることもあり得るので、汎用Eitherが、n個のパターンで使えればOKっぽい

うーん、n個のケースのそれぞれをflatMapで残したいとすると、やっぱり var foo: Foo? とかをそれぞれ作るしかない気がしますねー。

6:41 AM

case .foo(return) ?? nil みたいな書き方ができればいいんですが。パターンマッチング部分を抽象化できれば関数にできるんですけどね。

パターンマッチの抽象化ほしいですね

https://twitter.com/CodaFi_/status/860246169854894081

John Sergeant ≡ (@CodaFi_)

What do you mean Swift doesn’t have mixed-type arithmetic? let (x : Int, y : Double) = (3, 1) let result = Int + Double // 4

12:18 AM

これ動くの謎ですねｗ

えぇ…

ん？これって単にラベル付きタプルとして解釈されてるんじゃないですか？

12:26 AM

ラベル x と y を持った Int と Double という定数にそれぞれ 1 と 2 が代入されてて

12:26 AM

（それらの型は Int です）

12:26 AM

それが足されてるだけに見えます。

12:28 AM

↓のような意味だと思いますが、明示的に型を書くとエラーになりますね・・・。 let (x: Int, y: Double): (Int, Int) = (1, 2) let s = Int + Double

12:29 AM

1> let (x: Int, y: Double) = (1, 2) 2. let s = Int + Double Int: Int = 1 Double: Int = 2 s: Int = 3

12:29 AM

 1> let (x: Int, y: Double): (Int, Int) = (1, 2) 2. let s = Int + Double error: repl.swift:1:6: error: tuple pattern element label 'x' must be '_' let (x: Int, y: Double): (Int, Int) = (1, 2) ^

let (x:Int,y:Double)←これが型宣言ではないのがポイントっぽい

12:39 AM

でも定数名を型名と同じ宣言したらそれは弾いて欲しいですね

うーん、 let (x, y): (Int, Double) = (1, 2) が正しいんでしょうが、ラベル付きタプルを宣言して代入という構文も、何のためにラベルがあるのか意味不明なので、 let (x: Int, y: Double) = (1, 2) とできてもいい気がしますね。

そもそもこれができるのが罠ってことですねーどうしてもやりたい場合（って何だ）はバッククオートつければいいだけだし、弾いてほしいですね

それはそれとして、ラベル付きならxとyはどこへ…？というのがあって、混乱を生んでいて良くない

1:24 AM

つまり、let (x:y,z:w) =(1,1)でも通るって事ですよね

1:26 AM

フーム

1> let (a: b, c: d) = (1, 2) b: Int = 1 d: Int = 2

1:29 AM

挙動が違う？？

いや、同じですね

1:30 AM

aとcは存在しない

ああ

1:30 AM

代入の後でラベルを使おうとしてエラーですね。 (edited)

sandboxもxとzが無なので

ラベルはあくまでタプルに紐付いているはずなのでそれはいいとして、ラベルが書けるの自体がミスリーディングですよねぇ。

let Int=1 let Double=2 _=(x: Int, y: Double) 実際にはこれと等価

1:53 AM

xとyへの参照は無、IntとDoubleが残る。 tupleの型宣言 typealias Foo=(x: Int, y: Double)と混ざって混乱する

あははは

でもlintで弾くしか無さそうだ

1:56 AM

例えばネストした型としてローカルなURLを作りたいとか、それが必ずしも型であるとは限らない(メタな挙動をする変数かも知れない)なので、

1:58 AM

とは言えwarningぐらいは欲しいかなw 型名を変数で上書きしてる、と

型の上書きよりも、問題は let (foo: x, bar: y) = ... のラベルを書けることじゃないですか？コンパイルエラーでいい気が。

それはそんな気がします

2:01 AM

いやーー

2:02 AM

そうか、そうなるか

2:03 AM

let (x,y)=(1,2)これタプルじゃなくて、xとyに1と2を代入、ですね

2:03 AM

じゃあラベル付きは完全にダメだ

1

む、タプルじゃないんですね

2:16 AM

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html#//apple_ref/doc/uid/TP40014097-CH6-ID60 >If the right side of the assignment is a tuple with multiple values, its elements can be decomposed into multiple constants or variables at once: let (x, y) = (1, 2) // x is equal to 1, and y is equal to 2

2:16 AM

本当だ、左辺は、 "multiple constants or variables" ではあるけどタプルじゃないのかー

右辺はタプルで、それを平たく展開するための代入。なのでラベルが使えるのはおかしい、と言うことですね。

1

タプルとラベル関連でもう１ネタ

2:54 AM

これ、なんで制限されてるのか合理的な理由あるんでしょうかね

2:57 AM

と思ったけど自己解決そもそもrequest parametesには括弧が必要だからですね

tupleとargumentの境界は4で厳密になるんでしたっけ？今は曖昧ですよね

そこらへん関わってそうなproposalsは、 3でimplemented: swift-evolution/0029-remove-implicit-tuple-splat.md at master · apple/swift-evolution https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md swift-evolution/0066-standardize-function-type-syntax.md at master · apple/swift-evolution https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md 4での総仕上げがこれ、ですかねー swift-evolution/0110-distingish-single-tuple-arg.md at master · apple/swift-evolution https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

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

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

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

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

ようやく SE-0166 準拠の YAMLEncoder が最低限動く様になった (edited)

4

@norio_nomura おお、素晴らしいですね！

1

2:37 AM

例の async / await について Ray さんが添削してくれたんですが、めっちゃ勉強になりますね。これがネイティブの英語力かぁぁ・・・。原文がほとんど残ってないｗ https://gist.github.com/rayfix/b5429a061a0fe34fa9326fe358dfdbe7/revisions

[WIP][Experimental] Support SE-0166 Swift Archival & Serialization by norio-nomura · Pull Request #43 · jpsim/Yams

GitHub is where people build software. More than 21 million people use GitHub to discover, fork, and contribute to over 58 million projects.

表現自体が違いますねw (edited)

1

SE-0166 のEncoder & Decoderサポートのコードはこんな感じになりました。 https://github.com/jpsim/Yams/pull/43/commits/68c34b1ec8912688cfb1b0d23049e31ab9daf507 (edited)

Support SE-0166 Swift Archival & Serialization Fixes #38 This uses local built toolchain https://github.com/norio-nomura/swift-dev/releases/tag/20170501a TODOs for merging: Add text encoding dete...

1

^SE-0166 対応を一通り実装してみての感想は、イマイチな部分もあるけど Mirror とかでシリアライズを作るよりはずっとマシ、ってところかな。

この前ここで話してた SE-0171 の reduce について書きました。 http://qiita.com/koher/items/17636e95e18e529e5b9b

Swift 4の新しいreduceが素晴らしいので紹介する - Qiita

これまでの reduce は次のようなシグネチャでした。 ```swift func reduce( initial: T, combine: (T, Element) throws -> T) rethrows -...

3

パフォーマンス云々を言うなら、辞書を init(minimumCapacity:) で作るとかした方が良いと思いました。

コメントありがとうございます。キャパシティを確保しても計算量のオーダーレベルでは同じですし、 Before / After および for ループを使った場合との比較なのでキャパシティの話を混ぜるとわかりづらいかなぁと。

CoWだと辞書の元のキャパシティは維持されない様に見えるので、inoutだと再割り当てが確実に発生しないのはメリットに思えます。

4:07 AM

CoWで元のキャパシティが維持されない様に見えるのは、この辺り https://github.com/apple/swift/blob/3f68f2876ae6f859f777df638487544ddc62111d/stdlib/public/core/HashedCollections.swift.gyb#L4695

swift - The Swift Programming Language

COWでキャパシティが維持されるってどういういみですか？COWによってバッファのコピーが省略されて参照コピーになった際は、ストレージは共有されるけど、キャパシティ自体はストレージ自体に属するパラメータですよね

4:21 AM

実体のバッファコピーが起きた時に、新しく複製されたバッファにおいては、キャパシティが（例えコピー元が余裕のあるサイズになっていたとしても）それを引き継がずにリセットされる、という事？

4:22 AM

だとすると、Copy On Writeはあまり関係なくて、単純に、Dictinaryが実体コピーされたときのコストの話でしょうか

reduce へ渡す空の辞書を、生成されるであろう要素数を元に容量確保しておいても、最初のCoW発生時に辞書内の書き込み済み要素数を元に新しい辞書の容量が再計算されている様に見えます。 (edited)

4:48 AM

まあ、コピーされた時のコスト増だとも言えるかもしれませんが、コピーされないことによるメリットは最大限に享受したいなと。 (edited)

なるほど。 > メリットは最大限に享受したい

仮に CoW でキャパシティが引き継がれるとすると、ループで毎回フルサイズ（最終的なサイズ）のバッファが確保されることになるので、かえって遅くなるんじゃないでしょうか。 inout のおかげで初期値をキャパシティ指定して渡すことの意味があるというのはその通りだと思うので、その点追記しておきます。

↓連休中にレビュー入りしてた John McCall による Proposal 。 "This proposal is a core part of the Ownership feature, which was described in the ownership manifesto." らしい。 @omochimetaru が興味ありそう。 https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md

Swift 4の新しいreduceが素晴らしいので紹介する - Qiita

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

ちょうど読んでる

@norio_nomura minimulCapacity の件、追記しました！ http://qiita.com/koher/items/17636e95e18e529e5b9b/revisions/1?type=source (edited)

「Swift 4の新しいreduceが素晴らしいので紹介する」の編集履歴です。

2

struct Cat { var age: Int = 3 var po: Int { mutating get { age = 9 return age } nonmutating set { print(newValue) } } } こんな意味不明な事できた

nonmutating 、 Swift が登場してすぐのときに Array の CoW がおかしくて、その関係で調査してたときに一度だけ使ったことある。

いま初めて書いたｗ

1

これですね

http://qiita.com/koher/items/0bd95b0bc7f28e9a7830

Swiftで定数（let）のArrayの要素は変更できるけどDictionaryでは変更できない理由 - Qiita

(2014.9.3に追記) 本投稿に書かれているのはbeta 2までの古いSwiftについての情報ですのでご注意下さい。beta 3以降では、Arrayはletのときに要素が変更できなくなり、[すばらしく生まれかわり...

1

@moaible おお、よく発見できましたね！自分の古い投稿は見るのも恥ずかしいですねｗ

2週間以上DEVELOPMENT-SNAPSHOTが出てないけど、近日中に出そう。 https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170501/004540.html

9:25 AM

Swift 4.0の変更がたくさん入ってるので楽しみ。

1

↓これやっといて、 map は [Element] を返すとか一貫性なくないですか？そして、 map についても Mapped を作ろうとしたら、 higher-kinded type がないといけないという・・・。 https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md

https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-add-clamp-function.md

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

10:41 AM

最後に書かれてた。

It could be worthwhile to make a similar change to map, but this is beyond the capabilities of the current generics system because map does not preserve the element type

mapは変更後の型Tがあるのに対してfilterは必要ないから差があるのか

11:51 AM

higher-kinded typeマジで欲しいですねぇ

1

Initiate review of SE-0174: "Change filter to return an associated … · apple/swift-evolution@d1b6e34

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

1:52 AM

番号が楽しいことになってる

review 開始時に review manager が採番するはず。例: https://github.com/apple/swift-evolution/commit/d1b6e3465b6df979c31951852f6e4284c16e9a68

…type"

毎回あったのか。初めて見ました。

SE-0176は以前rintaroさんが言ってた -enforce-exclusivity=checked のやつか。

enumのassocvalueをeither的に、is-a関係を作りたい欲が高まってきた

2:47 AM

protocolとgenerics駆使すれば、現状でも似たことは出来るかしら

enumとcaseじゃなくてcaseにぶら下がってるassoc valueと？

そう

T is Optional<T>.Some と同じ事をユーザ定義したいってこと？

2:48 AM

たるのんそれ嫌いじゃなかったっけ

そうそうそう

2:48 AM

まあそうだねw

闇に堕ちたんですか

えっとですねー

2:48 AM

原初の欲求としては、assoctypeに複数値を持たせたいんですよ

昨日話してた可変長ジェネリックか

複数種類の型を定義すると、複数種類の実装のオーバーロードで実現される。

2:50 AM

これが出来るとですね、assoctypeで引数を束縛するような、2つの型の関係が

2:50 AM

1:1，1:多しか今は出来ないが

Tuple2にある機能はTuple3にも全て欲しい、みたいな？

多:多が可能になる

2:50 AM

いや、タプルとは違うな

2:51 AM

Viewから実装を引っぺがして、それをGenericsに作ることで

2:51 AM

NibとGenerics型の共存が出来ないかなと考えてるところから派生してる

2:52 AM

これ自体は上手く行きそうなんだけど、Viewと実装の繋ぎ込みがfuncになっちゃって、型を書くのが怠いから、assoctypeで縛ろうとしたが…

2:52 AM

という感じ、Viewと実装をassoctypeに持つ第三の型を作ればいい気もするけど、登場人物はなるべく増やしたくない

よくわからないけど、型Aと型Xの組み合わせのときの処理を静的に定義したい、そのペア自体を型付けしたい？

extension View: HasImpl { typealias Impl=Int } ↑これだと、Intしか実装がない。なので、IntかStringを使おうとすると↓ extension View: HasImpl { typealias Impl=Int|String } ↑こういうのが欲しくなる

2:55 AM

そうそう

(A/B/C) x (X/Y/Z) のような合成がしたいと

そう！

で、 (*) x (X) とか (A) x (X) とか (A/B) x (*) の場合における実装を定義したい？ (edited)

えーっと、そこの掛け算全部書くのは吝かではない (edited)

なるほど

2:56 AM

あー、 A / B / C とかは個別のデータモデル型とか個別のViewだから enum にならんのか

型を書くのが怠いから、推論機からポンッと出したいよね、という

2:57 AM

ABCは共通のデータモデル使うぞ

2:57 AM

データモデルの側が色々あり得る

型は違うんだよね？

そこは別に同じでも良い

2:58 AM

えっとね

ふむ。

これが出来ると、TableViewControllerを一個作っておくと、ユーザ一覧実装と、ツイート一覧実装をぶち込めば

2:58 AM

それぞれの振る舞いが出来るようになる

2:59 AM

CollectionViewControlldrに、同様にbindingの実装を加えれば、こちらにもユーザ一覧やツイート一覧をぶち込むことが可能

2:59 AM

で、そうするとですね、

3:00 AM

実装側は、モデルの型を持っているが、TableViewControllerにモデルの型を含む実装が必要。繋ぎ込むための関数をGenericsベースで作ろうとすると、多対多のassoctype宣言が必要に

3:01 AM

enumで行けないかな？→union!!!

3:01 AM

ってなった次第

GenericTableViewController < M : GenericTableViewcontrollerModelProtocol > extension TweetModel : GenericTableViewcontrollerModelProtocol { func bindToGenericTableViewController ... } こういう感じじゃ駄目なの？

View自体にGenericsを入れるのはダメ

3:06 AM

Nibは使いたい(ワガママ)

1

そこでNibが出て来るの・・・

オートレイアウト手書きはやってられない

3:07 AM

多分、どこかprotocolに落として考えれば、通る型が作れるはずだから模索してみるかな

何回読んでも超わかりにくい、端的にいうと、associatedtypeでオーバーロードがやりたいって話ですね

7:11 AM

結局unionが欲しいのと一緒だった

7:11 AM

protocol P { associatedtype AT } struct SP<T> : P { typealias AT = T } extension P where AT == Int { func po() { print("AT == Int") } } extension P where AT == String { func po() { print("AT == String") } } let intsp = SP<Int>() intsp.po() let strsp = SP<String>() strsp.po()

7:15 AM

associatedtypeでオーバーロードがやりたい

だけだと、これでできているように見える？

Generics無しだと出来ないよね

7:15 AM

つまり

7:16 AM

同一のspからIntとStringでオーバーロードされたfunctionやfieldにアクセス出来る必要がある

どっちになるかは何をもって決まるの？ (edited)

かつ、Pで束縛するときのATがIntとStringどちらでも使えないといけない

7:17 AM

外側の型で束縛される

同一のspって、そのspの式の型はPって事？associated typeがあるからそのような変数は作れない

こんな感じ？

protocol P { associatedtype AT } protocol HasStringProtocol {} protocol HasIntProtocol {} extension P where AT: HasStringProtocol { func po() -> String { return "string" } } extension P where AT: HasIntProtocol { func po() -> Int { return 1 } } struct StringAndInt: HasStringProtocol, HasIntProtocol {} struct S: P { typealias AT = StringAndInt } let s = S() let string = s.po() as String // "string" let int = s.po() as Int // 1

@norio_nomura お、近い。これでpoがPの型から見えていればいけそう

9:00 AM

でも多分それ以上は出来ないですね、今の機能で欲しいものは作れない気がしているのであきらめムードです。

protocol P { associatedtype T func hoge(t: T) } class MyClass {} extension MyClass: P { typealias T = Int func hoge(t: Int) {} } extension MyClass: P { typealias T = String func hoge(t: String) {} } func foo<MyP: P>(_ arg: MyP) where MyP.P == String {} // <- ここにMyClassを func bar<MyP: P>(_ arg: MyP) where MyP.P == Int {} // <- どっちでも入れれるようにしたい

無理ぽ

UnionTypeがあれば

9:30 AM

Int|Stringで宣言して多分思い通りのものができそう

最近Int|CountabelRange<Int>みたいなのをやろうとして、結局ContableRangeをprotocolに従わせつつ関数側で型チェックってのになってしまったので Unitonがあると嬉しいですね。

~~subscript が identifier になるらしい。~~ 間違い https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170508/004549.html ~~init みたいにメソッドとして参照できる様になるのかな。~~ ならない (edited)

びっくりしました。一瞬キーワードが変わるという意味かと思いました。

ヘッダー見ないとSubScriptあるの知れないからこれは嬉しそう

foo.subscript ができるようになるのはうれしいですね。

1:40 AM

昨日話されてた Union Type については、影響範囲が大きすぎてなかなか難しいですよね・・・。

1:41 AM

Intersection Type はいらないのか、 Union, Intersection とオーバーロードの関係をどうするか、

導入だけなら非破壊的な気がしますが

サブタイピングがめちゃくちゃ複雑化するし

1:42 AM

Union Type は以前 swift-evolution でも議論されてたけど、概ね否定的な感じでした。

1:43 AM

個人的にはほしいときはありますが、

1:44 AM

基本的には Union みたいな Non-nominal type は必要最小限に留めて使うべきで、

1:44 AM

正しい用法用量を求めるのが難しそう・・・。まあ、それを言い出したらタプルと struct もすでにあるんですが。

1:45 AM

あと、 Smart cast もないと Union Type は使い物にならない。

（昨日のたるのんの話結局いまいち目的がわからなかった

Intersection はオーバーロードと等価だから、↓みたいな問題も起こる。

func foo() -> Int { ... } func foo() -> Double { ... } // 今 let f: () -> Int = foo // () -> Int の foo が代入される // Intersection があったら let f: (() -> Int)&(() -> Double) = foo let g = foo // ↑と同じ let h: () -> Int = foo // この場合 h の実体は何？ () -> Int の foo ？それとも f や g と同じ？

(edited)

1:50 AM

あと、 Typed Throws が長い間議論されてるけど、導入するならエラー型を一つに絞るのがいいという話になってるけど、 Union Type があると func foo() throws BarError|BazError -> Foo ができるので複数エラー投げられることになってしまって台無しに・・・。

オーバーロードはintersection typeをもつ一つの型とはみなさないのが良さそう fの代入文がエラー

@omochimetaru そうかなぁ。 Intersection があるならそれがやりたい気がする。

(() -> Int) & (() -> String) って () -> (Int | String) と等価か？

Nominal なジェネリック型の型パラによる Variance も導入されてないのに、 Non-nominal な型のサブタイピングが導入されるとかきつそう。

いや、ちがうなあ

違うね。

どちらでもあるんだから () -> (Int & String) と等価か

それも違う。

1:56 AM

(Int|String) -> () と ((Int) -> ())&((String)->()) は同じに見えるけど (Int|String) -> (Int|String) と ((Int) -> Int)&((String) -> String) は違う。

(Int|String) -> (Int|String) と ((Int) -> Int)&((String) -> String) これはわかる、引数で入れた型が返り値で出てくるっていう依存性が消えてるから違う

() -> Int&String は let f: () -> Int&String = ... let r: Int&String = f() ができるけど、 (() -> Int)&(() -> String) は↓のどっちかしかできない。 let f: (() -> Int)&(() -> String) = ... let r1: Int = f() let r2: String = f()

え、でも、 r1 と r2 を合成して r が作れますよ

それは (() -> Int)&(() -> String) を 2 回コールしないとダメでしょ。

型としては外からみれば１回のコールに見せかけられるのでは

↓とか変じゃない？ let f: (() -> Int)&(() -> String) = ... let r: Int&String = f() // 2 回コールされる

2:02 AM

r が二つのインスタンスの合成というのも変

型それ自体は本当に入ってる実体の数とは関係ない気がするたとえば Int & Int & String は Int & String だから

2:02 AM

Unionが畳み込めるのと同じような話で

Union にせよ Intersection にせよ、複数のインスタンスを一つにまとめて扱うわけじゃなくて

2:03 AM

あくまで一つのインスタンスの性質の話じゃない？

2:04 AM

Intersection がある言語を使い込んだことがないけど、複数のインスタンスを一つのインスタンスのように扱えるものなの？

(() -> Int)&(() -> String) この型は () -> Int なんだから、一回呼び出せばIntが返るけど、　それと同時に () -> String なんだから、一回呼び出せば Stringが返るはずで、それは () -> (Int & String) って事じゃないのかな () -> (Int & String) なら 1回呼び出せばIntが返るとも言えるし同時に1回呼び出せば Stringが返るとも言える

2:07 AM

１つの値の性質の事だと思っているから、どちらかを呼び出すとか2回呼び出すとかいう話が出てくるほうが変な感じがする

いや、 (() -> Int)&(() -> String) はただのオーバーロード。

2:07 AM

戻り値オーバーロードだからわかりづらいだけで

2:08 AM

((Int) -> ())&((String) -> ()) だと考えてみたら自明じゃない？

2:08 AM

foo(42) か foo("xyz") ができるだけ。

((Int) -> ())&((String) -> ()) == (Int | String) -> () だと思う

((Int) -> Int)&((String) -> String) でもいいけど。

それは1つの関数型には畳み込めない

2:09 AM

僕が存在すると思ってる型変換規則は2つあって

1つの関数型には畳み込めない

このことが & はオーバーロードを表すことを示してるのでは？

いや、それはオーバーロードの概念がインターセクションと違う事を示しているだけで

2:10 AM

一般的に拡大するのは違うと思う

2:11 AM

(A -> B) & (A -> C) == (A) -> (B & C) と (A -> B) & ( C -> B) == (A | C) -> B の 2つだけが適用できる

2:12 AM

「オーバーロード == 関数型2つのインターセクション」っていう仮定が正しければkoherの意見は一貫してるけど

2:12 AM

その仮定がそもそも違って

2:12 AM

オーバーロードのほうが条件が厳しい合成の概念で

2:12 AM

それをインターセクションと考えるとおかしくなるんじゃないかと思ってる

2:12 AM

SwiftのTagged UnionがUnion Typeよりも厳しくて畳み込んだりできないのと同じように。

2:13 AM

IntersectionTypeがある言語を僕も使ったことはないけど。

そもそも二つのインスタンスを一つにまとめた存在というのがあり得るのがおかしい気がする。

あーそれは、違うと思います

2:20 AM

型の話とインスタンスの実体のかずがうんたらというのは別で

↓ができるってことでしょ？ let a: Int&String = 42&"xyz"

はい

2:21 AM

でもそれはその a が Int を要求するところや String を要求するところ　両方にかけてコンパイルできる

2:21 AM

というだけの話で

2:21 AM

たとえば

2:21 AM

struct IntAndString { var i: Int var s: String } (edited)

2:21 AM

これでも満たせる

2:22 AM

.i と .s のメンバアクセスをコンパイラが自動注入すれば

2:22 AM

式としてはそれで成立させられる

そもそも何故欲しかったのかの注釈、

protocol Receiver { associatedtype Arguments func foo(_ arguments: Arguments) } protocol Sender { associatedtype Returns func bar() -> Returns }

この二つの型を合成して使うことを考える、 Receiver.Argnumentsと、Sender.Returnsが一致していれば合成可能、故に合成関数は次の定義 func combine<R: Reciever, S: Sender>(reciever: R, sender: S) where R.Argnuments==S.Returns

Cat is Animal 則を満たす時に暗黙の調整処理が挿入されるのと同じ話だと思います

2:23 AM

ちょっと離席

Recieverの実装を持っていて、受け取れる型の幅を増やしたい、unionがあればそれを使えば済む。しかし無い場合、 Recieverの型をenumにしたとして、それはつまり、Senderの型も書き換えないと行けない。

@omochimetaru Intersection はあくまで型の合成であって、インスタンスの合成は異なる概念だと思う。

で、↑だけど、さっき朝ご飯食べてたら多分天命降りてきたんで無くても辛さ解消できるかも知れない。

↓でも Overload のことしか書いてなくて、インスタンスの合成なんて話は出てきてないように見える。

This corresponds precisely to our intended behavior for overloading

http://cs.brown.edu/courses/cs173/2012/book/types.html#%28part._.Intersection_.Types%29

2:31 AM

Union や Intersection はあくまで型の話であって、インスタンスは常に一つで、そのインスタンスがどのように振るまうかという話だと思う。 (edited)

the DeclName for subscripts is just the Identifier “subscript”

この話ですけど、今までは subscript が内部的に単なる identifier としてモデリングされていたおかげで、 TypeCheckerで obj.subscript で参照できてしまい、SILではそんなこと意図されてなかったのでクラッシュしていたのが、この修正により 'Foo' has no member 'subscript' としてエラー出せるようになるっていうだけの話なのです。 https://bugs.swift.org/browse/SR-2575

1

おおお、ほんとだ・・・。衝突した。 struct Foo { subscript(i: Int) -> Int { return i } func `subscript`(_ i: Int) -> Int { return i + 1 } }

 9> Foo().subscript(42) error: repl.swift:9:1: error: ambiguous use of 'subscript' Foo().subscript(42) ^ repl.swift:2:5: note: found this candidate subscript(i: Int) -> Int { ^ repl.swift:5:10: note: found this candidate func `subscript`(_ i: Int) -> Int { ^

 9> Foo().`subscript`(42) error: repl.swift:9:1: error: ambiguous use of 'subscript' Foo().`subscript`(42) ^ repl.swift:2:5: note: found this candidate subscript(i: Int) -> Int { ^ repl.swift:5:10: note: found this candidate func `subscript`(_ i: Int) -> Int { ^

 9> Foo()[42] error: repl.swift:9:1: error: ambiguous use of 'subscript' Foo()[42] ^ repl.swift:2:5: note: found this candidate subscript(i: Int) -> Int { ^ repl.swift:5:10: note: found this candidate func `subscript`(_ i: Int) -> Int { ^

(edited)

class Foo { func `deinit`() {} } が出来なかったのが出来るようになったりするかもしれないけど、その程度。

あれ？逆に foo.subscript は今でもできるのかと思ったけど・・・。 1> struct Foo { 2. subscript(i: Int) -> Int { 3. return i 4. } 5. } 6> Foo().subscript(42) Segmentation fault: 11

2:55 AM

 1> struct Foo { 2. func `subscript`(_ i: Int) -> Int { 3. return i 4. } 5. } 6> Foo().subscript(42) $R0: Int = 42 7> Foo()[42] Segmentation fault: 11

(edited)

この変更で `func subscript と subscript がしっかり区別されるようになり、前者は foo.subscript 後者は foo[...]` でしか参照できなくなります。

今 Segmentation fault なのも変じゃないですか？

はい、それを修正するための変更です。

あと、 foo.subscript で subscript が参照できないと、今の Foo.init とかができるのと一貫性がないような気がします。

思想的には subscript はプロパティであるっていうので現状になっている感じがします。

なるほど・・・。 Generic だけできるようになって中途半端な状態になってしまいましたね

引数はとれるし、 Generic にできるし・・・。

3:09 AM

throws もできるようしたらメソッド側に寄せられますが・・・。

evolution 洗ったけど foo.subscript できるようにするという議論された形跡みつからず

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

@koher 僕もそう思っています。 > @omochimetaru Intersection はあくまで型の合成であって、インスタンスの合成は異なる概念だと思う。

やりたいことも型合成メインでインスタンスの合成は考えてないですね

func combine<R: Reciever, S: Sender>(reciever: R, sender: S) where R.Argnuments==S.Returns

3:35 AM

これのなかみは

3:36 AM

func combine<R: Reciever, S: Sender>(reciever: R, sender: S) where R.Argnuments==S.Returns { receiver.foo(sender.bar()) }

3:36 AM

これであってる？

そう

なるほどなるほど

enumでEither作って、Sender側もEither対応したReturnsにするのが苦痛

3:37 AM

でも、EitherになったSenderを定義してオペレーターで変換して、型推論が頑張ってくれないかな？ってやったら、まあ上手く行ったw

あーー　T -> Optional<T>.Some のユーザー定義がしたいって

3:38 AM

そういうことかｗ

3:39 AM

オペレーターじゃなくても

3:39 AM

func combine<R: Reciever, S: Sender>(reciever: R, sender: S) where R.Argnuments==S.Returns { receiver.foo(convertReceiverType(sender.bar())) }

それは無理じゃない？

ようするにこういう形にして

3:40 AM

convertReceiverTypeが receiverの受け付けられる型のかずだけ

3:40 AM

オーバーロードをしておけばいいんじゃない？

combine側をオーバーロードするのか

combine自体が複数ないとだめか？

3:40 AM

試してみる

でもね、それ、combineを使ってる全ての関数がオーバーロード必要になって

3:40 AM

地獄だな

combineじゃなくてあいだにはさんでる convertReceiverTypeだけで

3:41 AM

いけないかなあ

できない

3:41 AM

それを実現するにはunionいる、あるならそもやらなくて言い

evolution 洗ったけど foo.subscript できるようにするという議論された形跡みつからず

@rintaro 間違った情報を正していただいて、ありがとうございます

結局、ここらへんが落とし所っぽい。

enum Either2<A, B> { case a(A), b(B) } class MyReciever: Reciever { typealias Arguments = Either2<String, Int> } // このままだとStringを吐き出すSenderは使えない class MySender: Sender { typealias Returns = String } // Either変換を含めた魔改造type-erasureを作る class Sender2A<R1, R2> { typealias Returns = Either<R1, R2> init<S: Sender>(_ sender: S) where S.Returns == R1 } class Sender2B<R1, R2> { typealias Returns = Either<R1, R2> init<S: Sender>(_ sender: S) where S.Returns == R2 } // 変換オペレーターを差し込む prefix operator ~ prefix func ~<S: Sender, R>(_ sender: S) -> Sender2A<S.Returns, R> { return .init(sender) } prefix func ~<S: Sender, R>(_ sender: S) -> Sender2B<R, S.Returns> { return .init(sender) } combine(MyReciever(), ~MySender()) // OK!

あ、打ち合わせしてた

4:51 AM

https://gist.github.com/omochi/e4f7c07a5948c66604a796e31241a48f

compose.swift

4:51 AM

connect(IntProvider(), IntOrStringConsumer()) { .lift($0) }

4:51 AM

↑これでどうでしょう

やっぱそういうの付けなきゃいけない

4:51 AM

combine側にそれが必要だと、combineを利用するすべての関数で作らないといけない

4:52 AM

負の連鎖になるから、引数の時点で解決したほうが良いかなぁ

tarunonがやったほうほうでも ~ をつけるんだから同じじゃない？

4:54 AM

~ は短いけど何が起きてるかあとでわからなくなりそう

いや、combineを利用して実装している関数に、機能を追加すること無く使えるのがポイント

4:54 AM

まあ~じゃなくて、.converted()でも良い

なるほど

4:54 AM

ようするにこれってモナドの.mapだよね

そうそう

4:56 AM

最近Swiftの型でサブタイピング無くて発狂したらなんでもかんでも~で解決する癖がついてきた…

4:58 AM

明示的なサブタイピングの手法と考えれば、~で大体OKだな、という気がする。

5:00 AM

お、俺は間違ってない…間違ってないはずだ…　https://github.com/tarunon/Hiyoko/blob/refactoring/viewmodel/Reactor/Sources/Either.swift#L626-L681

tarunon/Hiyoko

Hiyoko - https://www.hiyoko.co.jp, It's a sweets in Fukuoka. But this repo maybe become twitter app for iOS.

5:00 AM

改めて見ると笑うなこれ

関数を中にいれるのだと型が定まんないからだめなんだなあ

それもそうね

オーバーロード探索の前に推論が終わらないといけないのか

5:03 AM

うまくいえないが

5:03 AM

プロトコルさしまくればなんとかなりそうだけどちらかって微妙な感じ

全てをGenericsで定義していけば、多分うまくいくのだけど

5:04 AM

今回はViewControllerとViewはStoryboard/Nibを使うからGenericsダメって制限があるので

5:04 AM

そのジョーカーは使えない。

Genericsでも Int Or String が表明できないから無理じゃない？

あーーー

5:05 AM

それも、そうだ

5:06 AM

この間の返り値のタプルで推論させたのは

5:06 AM

そもそも最初がサブタイピングあるやつだ

5:06 AM

今回は無い

5:06 AM

無

つまり、言語仕様上暗黙の互換性が無いけど、コンバータを通せば渡せるようなケースで、そのコンバータを書きたくないっていうのが

5:06 AM

一般化したやりたい事なんじゃないかな

そうそう

5:07 AM

まあ暗黙的にそれを許すのはヤバなので

5:07 AM

オペレーターはかなり良い落とし所

で、たまたま今回のケースはその２者が union関係だったから、union typeがあったらよかった、ということで

5:07 AM

String と struct FilePath みたいな２者でも同じ課題があると思う

あとコンバーターが、引数に入れてinitすれば済むレベルの単純さ

@tarunon TWITTER_CONSUMER_SECRET がコミットされてるけど大丈夫ですか？ https://github.com/tarunon/Hiyoko/blame/cf0f137321ef26d20a2940dd8d76de598012d207/Hiyoko/AppDelegate.swift#L13

tarunon/Hiyoko

Hiyoko - https://www.hiyoko.co.jp, It's a sweets in Fukuoka. But this repo maybe become twitter app for iOS.

うわーっ

5:57 AM

ありがとうございますw

おｗ

5:57 AM

ツイッタークライアント作ってたのか

GW前に丼作ってて

Hiyoko R.I.P. https://github.com/tarunon/mstdn

tarunon/mstdn

mstdn - mastodonクライアントアプリ開発RTA

5:58 AM

RIPしてたｗ

アレは投げたけど実験場は欲しいのでTwitterクライアントの形で継続してる

5:58 AM

w

5:59 AM

キーとシークレットRevokeしました。ありがとうございます! @norio_nomura

1

6:00 AM

最近まで気を付けてたけどついにやってしまった、適当な.gitignoreに書いたplistから読むようにしよう

.swiftでもいいんじゃね

コンパイルエラーになってしまうのはヤの感じかなー

コンパイルエラーのほうがマシじゃん

それもそうか

plist書き忘れて何故か動かないより

丼はなんか

6:01 AM

コンシュマーキーとシークレット作り放題なんで

6:01 AM

適当にやっててそれを引き継いだのが災いした

plist の方が CI で楽できそう

CIは多分、HiyokoKitしか見ないんで

6:08 AM

Hiyoko本体がコンパイルできないのは特に問題無さそう

2週間以上DEVELOPMENT-SNAPSHOTが出てないけど、近日中に出そう。

swift-DEVELOPMENT-SNAPSHOT-2017-05-09-a パッケージングのCIが完走しそう。 https://ci.swift.org/view/Packages/job/oss-swift-package-osx/3351/console

swift-DEVELOPMENT-SNAPSHOT-2017-05-09-a きた https://swift.org/download/#snapshots

https://github.com/raywenderlich/swift-algorithm-club

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

ここで落とせるxcodeって

7:03 AM

xcode-selectでmacの中でスイッチして使える感じですか？

7:03 AM

あ、でも ownership 試す時はビルド自体のフラグを変えないといけないのかな

Xcodeの中で切り替えられます。

！？

7:11 AM

Simulattors | Documentation しかなかった 2つ以上あると Toolchains が現れるのか

ビルド時のtoolchainを切り替える方法は色々あるのですが、 xcode-select では切り替えられなかったはず。 (edited)

ふむふむ

7:13 AM

切り替える仕組みがあるなら変に混ざったりしなそうだしダウンロードしてみよ

Xcodeの場合エディタサポートかがあるため、起動しているXcode.appインスタンス全体で切り替わります。

7:14 AM

xcodebuildやxcrunは -toolchain オプションがあったり、TOOLCHAINS環境変数を使ったり。

xcrun の -sdk は割りとつかいます

$ pkgutil --pkgs|grep org.swift org.swift.3020170509a org.swift.31120170421a でインストールしてある swift.org からのスナップショットのIDを探せるので、それを TOOLCHAINS=org.swift.3020170509a swift や xcodebuild -toolchain org.swift.3020170509a … みたいにして使います。 (edited)

7:18 AM

$ xcrun -toolchain org.swift.3020170509a swift Welcome to Apple Swift version 4.0-dev (LLVM 6a9a7bf93b, Clang 288cf0b5d5, Swift 2e09c17818). Type :help for assistance. 1>

(edited)

ほ〜〜〜〜

7:21 AM

ありがとうございます。

swift-DEVELOPMENT-SNAPSHOT-2017-05-09-a 壊れまくりな感じ…

1

https://github.com/raywenderlich/swift-algorithm-club/blob/master/Fizz%20Buzz/FizzBuzz.swift

swift-algorithm-club - Algorithms and data structures in Swift, with explanations!

9:00 AM

Raywenderlichすご・・・

9:02 AM

めちゃめちゃいろんなアルゴリズムのサンプル

http://qiita.com/koher/items/74b71242a1ca3b87abcf

swift-algorithm-club - Algorithms and data structures in Swift, with explanations!

9:03 AM

おい

9:03 AM

switch pattern matchじゃない

Swiftで関数型FizzBuzz - Qiita

Swift その2 の最後の 3 日が投稿されなかったので 3 連投です。 [当初のアナウンス](http://blog.qiita.c...

if i % 5 == 0 { result += (result.isEmpty ? "" : " ") + "Buzz" }

PR投げてみようかな

3の場合と5の場合が合体してFizz Buzzになるのはそれはそれで良さがある

↑多分 @tarunon さんが求めてるもの

ですです

9:05 AM

なんかif分岐がいっぱいあるの

9:06 AM

どの場合にどこ通って最終的にどうなるっていうフローを見なきゃいけなくて

9:06 AM

辛いなって思うようになってしまった

guard があるせいで else をちゃんとかくってのはありますねぇ

var がどうなってるか覚えながら読まないといけないよね

そうそう

9:07 AM

siwtch (/*必要なもの全部ここにドーンwww*/) { case /*なんか条件いっぱい*/: return /*結果*/ /*以下繰り返し*/

9:08 AM

マジでこれ脳に優しい

3の場合と5の場合が合体してFizz Buzzになるのはそれはそれで良さがある

FizzとBuzzをそれぞれ一度しか書かなくて良いのか

@koher そう

FizzとBuzzの重複避けるにしてもまだ↓の方がいい。

func fizzBuzz(_ numberOfTurns: Int) { for i in 1...numberOfTurns { var fizzOrBuzz = false if i % 3 == 0 { print("Fizz", terminator: "") fizzOrBuzz = true } if i % 5 == 0 { print((fizzOrBuzz ? " " : "") + "Buzz", terminator: "") fizzOrBuzz = true } if !fizzOrBuzz { print(i, terminator: "") } print() } }

まあfizzbuzzはおまけで、文字列探索とかランレングスとか線形回帰とかいろんな木があってすごいって思いました

result += (result.isEmpty ? "" : " ") + "Buzz" はさすがにひどい

転する時に役に立ちそうなレポジトリですね(直喩)

カンニングはいかんぞ

ここはチェックするようにしとこ

ソースだけじゃなくて解説まで書いてあるｗ https://github.com/raywenderlich/swift-algorithm-club/tree/master/Quicksort

https://github.com/raywenderlich/swift-algorithm-club/tree/master/Strassen%20Matrix%20Multiplication

swift-algorithm-club - Algorithms and data structures in Swift, with explanations!

うん　行列のところとかカラフルだった

9:18 AM

https://gist.github.com/rintaro/a5a9d9836027d7df7a5326a3a8cf9d89

swift-algorithm-club - Algorithms and data structures in Swift, with explanations!

9:19 AM

数字の組を色とスタイルで表現してるのか

9:19 AM

優しい

9:20 AM

N社も見習ってイカにスクリーントーンいれてくれ!

おや、 @rintaro さんだ。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170508/036568.html

10:42 AM

NNNN-conditional-switch-case.md

Authors: Rintaro Ishziaki

10:43 AM

オーサーがタイポされとる

w

@rintaro 今ってまだ新しい Proposal が受け付けられてるフェーズなんですか？こういう議論の余地なしで実装ファーストなものだったら OK ？イマイチ swift-evolution の空気がよくわからない・・・。

正直ノリはまったくわかりません

おお、 rintaro さんでもわからないんですね

まったく根回しとかしてないので、どうなんでしょうねぇ

実装もあるし、内容的にもイケそうな気も。

10:53 AM

ってか、そんな仕様だったんですね。むしろバグ？

需要は間違いなくあるはず。

内容自体は OK で、今の時期に Swift 4 に取り込むのが OK なのかですよね。 (edited)

10:56 AM

まさに↓な感じ。

I hope this makes it through without generating a lot of extra discussion. I would love to have this in Swift 4, or the next regular update of xcode.

とりあえず stdlib ではいまのところ #if swift(>=4.0) で enum case 追加みたいなのがないので、微妙なんですが、 https://github.com/apple/swift/blob/master/stdlib/public/core/HashedCollections.swift.gyb#L4348-L4349 の Linux には存在しないはずの case cocoa(CocoaBuffer) の扱いをみてると泣きたくなったので実装しちゃいました。

swift - The Swift Programming Language

1

ついこの間# !TARGET_INTERFACEBUILDER出来なくて

したので凄くタイムリーだ。ありがとうございます！

1

SwiftPM の pinning なくなった

https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md

https://github.com/airspeedswift

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

10:32 PM

ちゃんと読んでないけど Carthage っぽくなるのかな？

10:34 PM

Carthage でも resolve コマンドほしいとずっと思ってた。

10:36 PM

色んな言語の Package Manager が dis られてるｗ

However, we think that a "lockfile" is a very poor name for this concept

ピンは消えたけど常にリゾルブドはできるようになる？

1:03 AM

流し読みじゃよくわからなかったからもう一度読んでみる

トップリポジトリに.resolvedが入ってれば同じ環境、ignoreしてればそれぞれその時の指定をみたす最新で解決

1:23 AM

でなんかそれとは別に個別の依存指定をみたすように修正するためにeditで編集モードに入ってなんたらかんたら

1:25 AM

これまでのpin仕様では個別にpinがあってデフォルトがpinされていて、何かやるにはunpinしたりする必要があって、混ざってややこしいから、解決したいのか完全固定したいのかの2つの要望をresolvedの有無で排他的に選択できるようにすればシンプルでいい

1:26 AM

みたいな話が書いてあるけどもともとのpinの仕様をちゃんと知らないからよくわからなかった。

昨日の @rintaro さんの Proposal 、 Apple の中の人のコメントでも↓だから、何を evolution に通すべきなのかの明確な基準はなくて、コアチームの判断に委ねられているということかな？

I'm in favor, certainly. I'd personally say this wouldn't even need to go through the full evolution process, but I'm not a core team member.

1:34 AM

Joe Groff も Seems reasonable to me. って言ってるしイケそう。

1:40 AM

Core Team メンバー自ら新しい提案を投げてるし、 swift-evolution のステータス謎。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170508/036582.html

この提案おもしろいな

1:42 AM

Characterは書記素クラスタだからUnicodeScalarの列とみなせるのか

1:42 AM

言われてみればできなきゃおかしいね

この Ben Cohen さんって新しく Core Team メンバーになったんだけど、 Airspeed Velocity の中の人だったのか。

1:43 AM

airspeedswift (Ben Cohen)

airspeedswift has 9 repositories available. Follow their code on GitHub.

Arrayをポインタで走査したい場合にCoWを走らせる方法って無いですかね？ isKnownUniquelyReferencedで分岐できると良いんですが使えないようで。

2:12 AM

var a = [Int](repeating: 0, count: 10) var b = a let p = UnsafeMutablePointer<Int>(mutating: b) p.pointee = 100 // aも書き換わる

isKnownUniquelyReferencedはArray自体じゃなくて

2:12 AM

Arrayの中にあるバッファ（これは参照型ヒープオブジェクト）

2:13 AM

のはなしだよ。

そこは分かってます。

はい

2:13 AM

あー、aとbを明示的にコピーしたいのか

その上で外側にも使えたらコピーするかの分岐をこちらでできるなと

そのコードおもしろいな。

2:13 AM

コピーコンストラクタに渡したらどうですか？

var a = [Int](repeating: 0, count: 10) var b = Array(a) let p = UnsafeMutablePointer<Int>(mutating: b) p.pointee = 100 print(a) print(b)

[100, 0, 0, 0, 0, 0, 0, 0, 0, 0] [100, 0, 0, 0, 0, 0, 0, 0, 0, 0]

2:14 AM

ん？

2:15 AM

そういえばArray(a[0..<a.count])でもコピーできてないんでした。

あれ？CCtorでもだめなのか

iterator渡してるだけだから

2:16 AM

ダメなのでは

Array(a[0..<a.count]) マジ？ARraySliceからArray化は明示的コピーのはずなのに・・・？

ArraySliceが全体を指してる場合のみの振る舞いっぽいですね

a

2:17 AM

a.withUnsafeMutableBufferPointer は？

2:18 AM

 public mutating func withUnsafeMutableBufferPointer<R>(_ body: (inout UnsafeMutableBufferPointer<Element>) throws -> R) rethrows -> R

2:18 AM

これはmutatingメソッドだからCOWが生じるはず

2:19 AM

ネストしちゃう点についてはクロージャ内の処理だけ別のメソッドに切り出すとか？

2:19 AM

このアプローチならSwiftのセマンティクスとしても変な事はしてない (edited)

UnsafeMutableBufferPointerだといけますね。ありがとうございます。

var ary = [1,2,3] ary.withUnsafeMutableBufferPointer { buf in print(ary.count) // -> 0 } この挙動おもしろいな。

！？

2:27 AM

ほんとうだ・・・

body 内でArray操作されないように一時的に self を書き換えてる。 https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb#L1758-L1773

swift - The Swift Programming Language

おー

2:28 AM

いまオーナーシップマニフェスト読んでる途中なんですけど

2:28 AM

こういうのがまさに

2:28 AM

現状のmutable参照を共有する場合に対する保守的な余計なロジックっぽい

https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb#L1085 initこれですよね、Bufferを渡すときに同型(Array)なら同じものが渡るようになってるのかしら(つまりCoWの範疇になる？)

swift - The Swift Programming Language

2:35 AM

ここを通るのかな？iPhoneだと追いづらい https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb#L1592

swift - The Swift Programming Language

Resilience(レジリエンス)について理解しないといろいろな事が深くわからないなあと最近思っていて

3:31 AM

でもあんまり話題に出ないのと、語としても見慣れない

swift-DEVELOPMENT-SNAPSHOT-2017-05-09-a 壊れまくりな感じ…

swift-DEVELOPMENT-SNAPSHOT-2017-05-10-a で直ってた。 (edited)

1

@omochimetaru Proposal の "Effect on API resilience" の Resilience ？

そこにも出てきますね

5:09 AM

最近は既存のコードえの影響とresilienceへの影響が並んでますね。

Error Handling Rationale and Proposal の方に出てた Resilience は、修正に対してどれだけ柔軟性（許容性？）があるかみたいな概念だと理解してました。

そういう一般的な概念じゃなくて、ABI互換性とかの周辺の具体的な議論な気がしている

Proposal の雛形には

API resilience describes the changes one can make to a public API without breaking its ABI. Does this proposal introduce features that would become part of a public API? If so, what kinds of changes can be made without breaking ABI? Can this feature be added/removed without breaking ABI? For more information about the resilience model, see the library evolution document in the Swift repository.

5:11 AM

って書かれてる。

5:11 AM

リンクされてるドキュメント（ "see the library evolution document in the Swift repository" ）は↓ https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst (edited)

https://github.com/apple/swift/blob/master/docs/archive/Resilience.rst

swift - The Swift Programming Language

omochi/swift-ownership-jp

swift - The Swift Programming Language

5:12 AM

アーカイブフォルダのなかにそのまんまな文書もあるけどアーカイブなのが気になる

5:13 AM

resilience model, see the library evolution document < ってかいてあるなら

5:13 AM

そこを読むのがまずは一番良さそうだ。

https://github.com/omochi/swift-ownership-jp/blob/master/ownership-manifesto.md オーナーシップマニフェストを読みました。読み飛ばさないでちゃんと読みたかったので、全文を和訳しました。まだ読んでない人は良かったら参考にしてください。あと変なところは僕も自分でよくわからなかった部分なので助けてくれると嬉しいです。

Contribute to swift-ownership-jp development by creating an account on GitHub.

6

1

これコンパイル通るんだな通らないで欲しい struct Hoge { var fuga: Int { return fuga } } let hoge = Hoge.init() print(hoge.fuga) // <- 無限ループで死

たまにやらかすけどスタックトレースですぐわかる

fuga以外のところで条件回して終端のある再起を書けるっちゃ書けるので、弾くのは難しいかしら

そっかあ

fuga自体がループしてることはフロー解析で確定できると思う

ループがエンドレスかどうかを証明するのは無理じゃね

こんなん書いてて最初なんで死ぬのか気づかなかった private let _event: PublishSubject<Event> var event: Observable<Event> { return event.asObservable() }

一般の停止性判定ができないだけで、あるケース単体について証明できる場合はあるよ

_eventあぶがないので、eventSubjectとかにした方が良い

なるほど

つまり、証明できる範囲についてコンパイルを通さない、なら可能か

そう。

でも中途半端っぽい

うん。

1:25 AM

複数のプロパティが絡んだ相互再帰とか

1:25 AM

一見無限再帰してるけど、クラスだからオーバーライドすればカットできるとか

1:25 AM

ちょっと複雑でループするケースとかしない場合があるが実行するとループになるケースとか

1:25 AM

同種のバグで潰せないものはたくさん残る

それさ

1:26 AM

証明可能なもの=人間にもすぐ見つけられる

でもhirariが踏んでる最も単純なパターンぐらいは対応してもいいかもね

だからやる意味ほぼないでは？

1:26 AM

いやこれ、これでも

1:26 AM

単純でもループしない場合あり得そうな気がしていて

1:27 AM

ん？するか

1:27 AM

眠たかった

structだからオーバーライドできないからね

眠たかったｗ

$ brew info carthege $ brew info carthego

1:29 AM

カルタゴ、スペルがわからなくなるからきらい

hageだよ

hageで覚える

そこ同じ回答来るのかよｗ

ハゲカート

ハゲカートｗ

これでおもち君は二度と忘れなくなった

そうだね・・・ｗ

1:30 AM

解決した。

carthage使う度にアイヴが脳裏にちらつく呪いをかけておこう

carthageのhageはアイブの禿か

結局カルタゴとカッセージどっちが日本では主流なの

これでcartはfor steveの意味なら完璧だな。

1:32 AM

@hiragram ハゲカート主流にしよう

気に入りすぎでしょ

はい

日本人と口頭で日本語で会話するときはカルタゴって言ってて、英語のときはカッセージていってる

1:33 AM

かーせーじかな

トマトとトメイトウ

タマゴとタメイゴウ

？

1

エッグだわ

1

1:37 AM

ちなみにさっきのコード、今気づいたけど警告出てた。

w

警告全部けそ

1:37 AM

ちゃんとなおして

コンパイラが警告してくれてたなら全部人間が悪いな

1:38 AM

滅ぼう

1

@omochimetaru https://github.com/omochi/swift-ownership-jp/pull/1

内容に直接関係のない修正 by koher · Pull Request #1 · omochi/swift-ownership-jp

主な変更内容 GitHub で見やすいように Markdown ファイルを README に変更オリジナルへのリンクを追加翻訳元バージョンのコミットへのリンクを追加ライセンスへのリンクを追加どこからが本文化わかりやすいように本文開始前の前書きの後ろに水平線を追加

お、ありがとうございました。マージした。

@omochimetaru 思ったんだけど、元の文書を initial commit にしておけば、今後のオリジナルの変更をそれに対して加えて、それをマージすることで自動的に和訳中の英文も更新できた気がする。

2:16 AM

今からでも、できる気もする。

ブランチわけっぱなしにして3点間マージを維持するのか

はい

基本的に追記しかしてないからうまくいくはずですね

original ブランチを作って、そこに原文つっこんで

2:17 AM

original → master でマージして master の今のバージョンをそのまま採用して

2:17 AM

ってやればいけそう。

おや？ swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-09-a が出てる。

2:42 AM

あいや swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-11-a だった。

Swift 4.0 でこんな変更が必要ぽいのだけど、これって SE-0110 Distinguish between single-tuple and multiple-argument function types https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md の影響なのかな？

 func run(_ options: NoOptions<SourceKittenError>) -> Result<(), SourceKittenError> { print(version) - return .success() + return .success(()) }

commit as diff from original · omochi/swift-ownership-jp@02a3eab

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

おおお、面倒だけどわかりやすくはありますね・・・。

型としての () は Void にすべき派。

1

僕もどっちかといえば空タプルよりVoidのほうが好きです > 型としての () は Void にすべき派。

自分は標準ライブラリとかだと () -> Void で定義されてるのでそっちで合わせてました

func f11(x: () -> ()) {} func f12(x: () -> Void) {} func f13(x: () -> (Void)) {} func f14(x: () -> ((Void))) {} func f15(x: () -> (((Void)))) {} func f21(x: (Void) -> ()) {} func f22(x: (Void) -> Void) {} func f23(x: (Void) -> (Void)) {} func f24(x: (Void) -> ((Void))) {} func f25(x: (Void) -> (((Void)))) {} func f31(x: ((Void)) -> ()) {} func f32(x: ((Void)) -> Void) {} func f33(x: ((Void)) -> (Void)) {} func f34(x: ((Void)) -> ((Void))) {} func f35(x: ((Void)) -> (((Void)))) {}

((Void))は悪意を感じるｗ

@koher Diffにできた https://github.com/omochi/swift-ownership-jp/commit/02a3eab7b6a32bc8d58d963ec8758a7145330df6?diff=split このリポジトリにSE0716の和訳とか後に書くキータ記事も入れようと思ってるのでファイル名はREADMEから戻しました。 (edited)

1

午前中に書いたコメントがforce pushの彼方に

すいません、何か見逃しちゃったのか

7:28 AM

あ、完全に initial からふっ飛ばしたから

7:29 AM

github上で見る方法がわからない・・・

発見 https://github.com/omochi/swift-ownership-jp/commit/f6513506af0594b63750ea4762b23844dd9747c3#commitcomment-22113100

init · omochi/swift-ownership-jp@f651350

@omochimetaru Initial からやらなくても、孤立 commit 作ってそれを merge すればよかったのに・・・。 (edited)

孤立コミットはマージできなかった。

え？できるでしょ？

7:30 AM

できないっけ？？

[omochi@omochi-MB swift-ownership-jp (master=)]$ git merge original fatal: refusing to merge unrelated histories

まあ、僕が書いた場所が悪い。

--allow-unrelated-histories つけてもダメでした？

@norio_nomura あ〜これ less .. than の形が読めてないですね　ありがとうございます

1

7:33 AM

@moaible それは知らなかったです、いかにもできそうな名前

7:37 AM

ここは一個前の require が absolute よりも predictable であることを欲するよって

7:37 AM

話っぽいな

https://github.com/koher/isolated-commit

koher/isolated-commit

Contribute to isolated-commit development by creating an account on GitHub.

7:37 AM

あ、まさにそれやって試してた

7:38 AM

$ git log --graph --all --decorate * commit 8959b3248ca9f6264f36a08d67d47e1cd1271d6f (HEAD -> master, origin/master) |\ Merge: 5494a14 773e8de | | Author: Yuta Koshizawa <koher@koherent.org> | | Date: Fri May 12 16:35:58 2017 +0900 | | | | Merge branch 'original' | | | * commit 773e8defca014cefed7d4aade63b9b22255772f5 (origin/original, original) | Author: Yuta Koshizawa <koher@koherent.org> | Date: Fri May 12 16:34:23 2017 +0900 | | Original | * commit 5494a1445902fcfa7aeaf3708a3f9c939f807647 Author: Yuta Koshizawa <koher@koherent.org> Date: Fri May 12 16:33:23 2017 +0900 Initial commit

7:38 AM

$ git diff original master diff --git a/a.txt b/a.txt index 1802a74..c4f3b1d 100644 --- a/a.txt +++ b/a.txt @@ -1,3 +1,6 @@ aaa +111 bbb +222 ccc +333

@koher --allow-unrelated-histories が必要だった？

はい。

なるほど。

7:39 AM

基本的にforce pushしても

7:39 AM

コードコメントはPRとかについてるから

コミット番号さえわかってれば、もう一度 force push して元に戻してもいいかも？ (edited)

何も失わないと思っていた

7:43 AM

@norio_nomura とりあえず、修正しました https://github.com/omochi/swift-ownership-jp/commit/95653ec66e6394b49882fdbec475a237d786f8c0

指摘を受けた修正 · omochi/swift-ownership-jp@95653ec

2

7:45 AM

@koher あとでやってみます

わかりやすい

koherのPRをマージした直後の状態からはじめて、リネームをして、オリジナルをおいて、その２つをマージして、そこから辻褄をあわせていけばいいのか

オリジナルをおいたコミットは再利用できそう

あ、たしかに。

型としての () は Void にすべき派。

いい機会だから Void に変えようと試したら、ビルドできなかった。

error: member 'success' in 'Result<Void, SourceKittenError>' (aka 'Result<(), SourceKittenError>') produces result of type 'Result<T, Error>', but context expects 'Result<Void, SourceKittenError>' (aka 'Result<(), SourceKittenError>') return .success(Void) ^

(edited)

Void はあくまで型なので、そのインスタンスは () しかだめですね。

ああ、なるほど。

8:11 AM

return .success(Void()) で通る。

知らんかったｗ

Void()できるんだ

言われてみればという感じ

あれ？ Void って typealias じゃないの？

できる。 typealias A = (a: Int, b: Int) let a = A(1,2) もできる。

おー

！？

8:12 AM

なるほど・・・

知らんかった

でも.initで推薦してくれないですよね

なんですよねー＞ .init

推薦してくれたら色々捗る

A(a: 1, b: 2) ではないんだ

@hiragram どっちもいけるよ

8:13 AM

Tuple、ただただ.initで推薦してくれないのが本当に不便で、結局.initを書く必要がある場合はStruct作れ!ってなってる

いけんのか

 4> typealias A = (a: Int, b: Int) 5> A(a: 2, b: 3) $R0: (a: Int, b: Int) = { a = 2 b = 3 } 6> A.init(a: 2, b: 3) error: repl.swift:6:1: error: type 'A' (aka '(a: Int, b: Int)') has no member 'init' A.init(a: 2, b: 3) ^ ~~~~

いけてない？

これはinitです

おー

initは無い。

 6> let createA: (Int, Int) -> A = A error: repl.swift:6:32: error: cannot convert value of type 'A.Type' (aka '(a: Int, b: Int).Type') to specified type '(Int, Int) -> A' let createA: (Int, Int) -> A = A ^

8:17 AM

.init もダメだし、変数に入れることはできないか・・・

8:17 AM

結局.initを書く必要がある場合はStruct作れ!ってなってる

タプルは用法用量を守って使うのがいい気がするから、本当に一時的なペアでない限り struct がいいと思います。 (edited)

typealias A = (a: Int, b: Int) let a = A(a: 1, 2) let b: (x: Int, y: Int) = (1,y: 2) これが出来るのとか含めて、タプルは特別扱いすぎて本当に。

とりあえずさっきのは Void に変えるのはやめよう

true や false のノリで void があってもいい気もする。 Void 型のインスタンスが () なのはわかりづらい・・・。

let void=Void()って書いておけばまぁ使えますねw

かといって、 () 型のインスタンスが () なのも、値と型の区別がつきづらいけど・・・

(良いかどうかは別として)

ですね。

8:24 AM

うーん、結局 Void のインスタンスを扱わなければならないとき（ジェネリクスの型パラを Void で埋めたときなど）は Void 型のインスタンスを扱う必要があって、そうすると Void が () の typealias であることを知っている必要があって・・・と考えると、 Void より () と書いている方がいい気がしてきました。

8:25 AM

戻り値 Void はそもそも省略できるから書かないし。

ジェネリクス型がVoidの場合に、extensionに引数を省略した関数群を提供するのは一つの手かなと思っています。 (edited)

1

なるほどー。 (edited)

https://github.com/tarunon/Instantiate/blob/master/Instantiate/Instantiatable.swift

tarunon/Instantiate

Instantiate - Type-safe Interface Builder protocols.

8:28 AM

こんな感じで。

voidで型パラ埋めてる時は Voidの値 () を無駄に取る事の無い版を付け足すのか

Swift 4 ってタプルが区別されるのは引数だけで↓はそのままなんですよね？ 6> let a: Int = (((42))) a: Int = 42 7> let b: (((Int))) = a b: (((Int))) = { _value = 42 } 8> b + 1 $R1: Int = 43 (edited)

要素数1の括弧はタプルではないのはそのままです。 (edited)

1

そうすると、 () -> () と (()) -> () は異なるのに () -> (()) は同じってちょっと気持ち悪い感じが・・・。

8:31 AM

まあしかたないですが・・・。

((( ))) -> RetTy |-----| param list |---| paren |-| tuple って感じですね。 (edited)

1

paren が入ってくるあたりにも闇を感じますね・・・

8:34 AM

タプルの括弧が () なのよくないよなぁ。やっぱ @tarunon さんの言うように人類には括弧が足りなかった・・・

{([<

8:35 AM

どう見ても足りないです本当に

<, > も演算子と共用なのがヤバイですしね。

｢｣←彼らをデビューさせましょう(ない)

お、それなら 『』, 【】 もいけますねｗ

8:38 AM

それくらいあれば戦えそうだｗ

問題は、入力可能じゃないところ。。。

ASCIIに入ってないと戦力外ですからねぇ・・・

8:40 AM

Array【Int】 とか、可読性だけならアリそう。

<<{ }>> <<( )>> <<[ ]>> みたいな合体で意味を変えて増やす

@omochimetaru 地獄の始まりでしょｗ

┗( )┛

8:41 AM

イシツブテ

ｗ

┗("o")┛　顔っぽくなるぞ

合体で意味を変えて増やす、Objcのブロック構文の二の舞いだし絶対ダメだと思う

このサイトにはお世話になりました http://fuckingblocksyntax.com/

以前どこかで初期化なしでFloat配列を作りたいって話で聞いた方法をずっと使ってたんですが今急にコピーコスト考えるとそっちのが高いんじゃと思って試してみたらやっぱり遅かった……

func testA() { let size = 10_000_000 measure { // 0.013sec let array = [Float](repeating: 0, count: size) } } func testB() { let size = 10_000_000 measure { // 0.034sec let dst = UnsafeMutablePointer<Float>.allocate(capacity: size) defer { dst.deallocate(capacity: size) } let array = [Float](UnsafeBufferPointer(start: dst, count: size)) } }

array = のところの右辺のコンストラクタ呼び出しで

9:43 AM

結局全要素をコピーしてる？

だと思います

UnsafeBufferPointerのまま

9:43 AM

それを配列的につかえば

9:43 AM

そのコストは消せそう

うーんでも

9:43 AM

deferで開放されるわけですし

UnsafebufferPointerもMutableCollectionじゃなかったっけ。

ああそういうことですか

Array型を使わないってこと。

それは一理ありますね

9:46 AM

ただUnsafeBufferPointer自体をそのまま作ることはできないので開放タイミングがどうすればいいのかさっぱり分からないという

9:46 AM

UnsafeBufferPointerの持ち主のdeinitで開放させるとかになるんですかね

/// An UnsafeBufferPointer instance is a view into memory and does not own the memory /// that it references.

9:48 AM

UnsafeBufferPointerはメモリ空間へのビューを提供するだけでそれ自身はメモリ領域を保持しないから

9:49 AM

引数で与えたポインタの所有権はいまだプログラマ側にある

9:49 AM

func testB() { let size = 10_000_000 measure { // 0.034sec let dst = UnsafeMutablePointer<Float>.allocate(capacity: size) defer { dst.deallocate(capacity: size) } let array = UnsafeBufferPointer(start: dst, count: size) } }

9:49 AM

↑さっきのコードで言えばこうするだけ

速度自体はこれが圧倒的ですねあとはメモリ管理の煩雑さを受け入れるかどうか……

自分で作ればいいんじゃない？

9:50 AM

↑の let dst = を initの中で呼び出して

9:50 AM

defer { } の中を deinit で呼び出す

9:50 AM

structを作れば

その考えはなかった

9:51 AM

それでちょっとやってみます。

あ、structにはdeinitかけないから、classでかいて structでラップする必要があるね・・・

9:51 AM

まあclassでかいて let で受けてもいいです

歴史修正？した https://github.com/omochi/swift-ownership-jp/commits/master

omochi/swift-ownership-jp

Contribute to swift-ownership-jp development by creating an account on GitHub.

10:21 AM

というわけで、SE0176も訳しました。こっちのほうがまともな日本語になっている感。 https://github.com/omochi/swift-ownership-jp/blob/master/0176-enforce-exclusive-access-to-memory.md (edited)

omochi/swift-ownership-jp

Contribute to swift-ownership-jp development by creating an account on GitHub.

@t.ae 結局クラスつかうんだったら、 ManagedBuffer のほうが良いと思いますよ。

お、そのクラスは知らない

11:02 AM

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

11:02 AM

おお〜〜

バッファが ManagedBuffer のオブジェクトの実体の直後に tail allocate されるので、ちょっとだけ効率が良いはず。

ポインタジャンプが１回少ないってことですか？

これはいいですね。ありがとうございます！

ポインタジャンプが１回少ない

のはず。

1

11:12 AM

ただ、オブジェクトの起点からテールアロケートされたところまでのポインタ計算が一回入るはずなので、そんなにパフォーマンスは変わらないかもです。

11:13 AM

最低実装だとこんな感じか。 https://gist.github.com/rintaro/861f983f759b90097aa6433ed9dbf402

BufferWithManagedBuffer.swift

オフセット計算が入るのはそうですが、ヒープアロケーション/でアロケーションが1回減るのは大きいし、アドレスが離れた場合のキャッシュ効率も変わるので結構変わりそう

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

Typical usage stores a count and capacity in Header and destroys any live elements in the deinit of a subclass.

サブクラス作ってdeinit呼ぶ必要があるのでは？

そうなんですが、 T が Float などの trivial な値だったらそのままでも大丈夫かと。

なるほど

11:17 AM

https://gist.github.com/airspeedswift/1fb7d6e3e73e53ce64f6 別の実装見つけてたんですがこっちはGenericだからですね

Array using ManagedBuffer

https://airspeedvelocity.net/2015/08/03/arrays-linked-lists-and-performance/ ですね

airspeedvelocity

Arrays, Linked Lists and Performance

Patient: Doctor doctor, it hurts when I do this. Doctor: Well, don’t do that. On twitter, I wrote: Your reminder that building arrays with reduce, while fun, is accidentally quadratic. I was surpri…

ContiguousArray 使えばいいのでは？と思ってしまう。

@norio_nomura 大本の僕の目的はArrayの初期化コストを削減したいということなのです

Array の初期化コストが hot spot なのですか？

今やってるプログラム上でコストが思いかどうかまでは検討してないです。

12:37 PM

ちょっと要点抜き出して書いて確かめてみます

12:41 PM

func testA() { let size = 10_000_000 let src = [Float](repeating: 0, count: size) var one: Float = 1 measure { // 0.020sec var dst = [Float](repeating: 0, count: size) vDSP_vsadd(src, 1, &one, &dst, 1, vDSP_Length(size)) } } func testB() { let size = 10_000_000 let src = [Float](repeating: 0, count: size) var one: Float = 1 measure { // 0.017sec let dst = UnsafeMutablePointer<Float>.allocate(capacity: size) defer { dst.deallocate(capacity: size) } vDSP_vsadd(src, 1, &one, dst, 1, vDSP_Length(size)) } }

ほとんど差ないですね

12:42 PM

これなら初期化させていいか……

15%も違うなら結構でかいのでは

12:44 PM

ただ、テスト条件が

12:44 PM

あまり現実的じゃないから

12:44 PM

ヒープアロケーションのコストとか

12:44 PM

特性が変わっちゃうのでは

12:44 PM

現実的なサイズの行列を何度も計算した時の

12:44 PM

性能を評価しないと意味なさそう

実用でここまでのサイズか微妙ですし、実際はこの他にコストが重そうなところがあるんですよね

ふむ

func testA() { let size = 10_000 let src = [Float](repeating: 0, count: size) var one: Float = 1 measure { // 0.021sec for _ in 0..<size { var dst = [Float](repeating: 0, count: size) vDSP_vsadd(src, 1, &one, &dst, 1, vDSP_Length(size)) } } } func testB() { let size = 10_000 let src = [Float](repeating: 0, count: size) var one: Float = 1 measure { // 0.012sec for _ in 0..<size { let dst = UnsafeMutablePointer<Float>.allocate(capacity: size) defer { dst.deallocate(capacity: size) } vDSP_vsadd(src, 1, &one, dst, 1, vDSP_Length(size)) } } }

これだと倍近い差が

大きいね

あれ？比較対象は ManagedBuffer を使った型ではないのね。

大体同じだと思ったんでというかそこまで気が回ってなかったです

1:30 PM

いちおう試してみましたけどほぼ同じですね

なるほど、あとは書いたデータの読み出し？

読み出し回数は比較的少なくなる予定です。

1:45 PM

のでO(1)じゃなくても書き込みほど影響は大きくないかと

1:48 PM

逆にシーケンスとかで初期化したいときのコストが気になりそうな

Instrumentsで見ると、

 var dst = ContiguousArray<Float>(repeating: 0, count: size) dst.withUnsafeMutableBufferPointer { dst in vDSP_vsadd(src, 1, &one, dst.baseAddress!, 1, vDSP_Length(size)) }

でもUnsafeMutablePointerとほぼ同じになるぽい。 (edited)

2:05 PM

measure の結果は遅くなるのに。

こちらもmeasureで遅くなりました

最近swiftのswift-4.0-branchをビルドしようとしてるんですけど下記のエラーでうまくいかないのですが、単に壊れるコミットなのか、それとも何か見逃しているんでしょうか (edited)

12:09 PM

build error

a.txt

7.71 KB

12:14 PM

あ、 !535 は 535 utils/build-script --skip-ios --skip-tvos --skip-watchos --jobs 2 --skip-test-osx true

https://ci.swift.org/view/swift-4.0-branch/ でビルドできてるコミットを使ってみるとか。 (edited)

@norio_nomura なるほど！やってみます。

あ、スナップショットが出てるから、

12:17 PM

そのタグをビルドしてみるのが良いかな。

ふむ

12:18 PM

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-11-a

12:18 PM

これか

utils/update-checkout --scheme swift-4.0-branch --tag swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-11-a でチェックアウト

gitでswiftのリポジトリをチェックアウトしたあとに utils/update-checkout でも同じですか？ (edited)

swift以外のリポジトリも同じタグをチェックアウトしないといけないです。

あら、連動してチェックアウトするのが utils/update-checkout ってわけじゃないんですね。

12:20 PM

とりあえず、そのコマンドでやってみます

オプションなしで utils/update-checkout を実行した結果がどうなるかは知らないです。

なるほど。

うーむおなじだ

1:57 PM

/Users/omochi/work/swift-source/swift/lib/Basic/Version.cpp:334:5: error: static_assert failed "getCurrentLanguageVersion is no longer correct here" static_assert(SWIFT_VERSION_MAJOR == 4, ^

$ utils/update-checkout --clone --scheme master とりあえず master 前提で進めると、これで関連リポジトリ含めて全て clone してきます。 (edited)

2:05 PM

で、今エラー出てるのは、ビルドディレクトリに変なファイルが残っちゃっているからだと思うので

2:06 PM

$ utils/build-script --clean ... のように --clean オプション付けて build-script 実行

2:09 PM

過去にビルドしたことあるなら https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170424/004482.html でアナウンスされているとおり、 --clean ビルドが必要です。

1

ああ、そのエラーどこかで見たと思ったら、そのアナウンス前後だ。

やってみます！

@rintaro cleanのおかげでビルドできました。ありがとうございます。

~~swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-13-a が来そうな感じ~~ ダメだった (edited)

class A<X> { } class B: A<B.X> { struct X {} } print(B())

9:56 AM

↑コンパイルは通るけど実行時に無限に停止する

9:56 AM

もう報告されてるかな。

デッドロックしてるぽいね。

(lldb) bt * thread #1, name = 'test', stop reason = signal SIGSTOP * frame #0: 0x00007ffff6a72a9f libpthread.so.0`__pthread_once_slow + 95 frame #1: 0x00007ffff7c7f96f libswiftCore.so`swift_once + 95 frame #2: 0x0000000000400fef test`type metadata accessor for test.B + 47 frame #3: 0x0000000000401531 test`___lldb_unnamed_symbol7$$test + 17 frame #4: 0x00007ffff6a72ae9 libpthread.so.0`__pthread_once_slow + 169 frame #5: 0x00007ffff7c7f96f libswiftCore.so`swift_once + 95 frame #6: 0x00000000004013df test`type metadata accessor for test.B.X + 47 frame #7: 0x000000000040138e test`type metadata accessor for test.A<test.B.X> + 30 frame #8: 0x0000000000401341 test`___lldb_unnamed_symbol5$$test + 17 frame #9: 0x00007ffff6a72ae9 libpthread.so.0`__pthread_once_slow + 169 frame #10: 0x00007ffff7c7f96f libswiftCore.so`swift_once + 95 frame #11: 0x0000000000400fef test`type metadata accessor for test.B + 47 frame #12: 0x0000000000400f31 test`main + 65 frame #13: 0x00007ffff6ca1830 libc.so.6`__libc_start_main + 240 frame #14: 0x0000000000400e09 test`_start + 41

@norio_nomura さんが前言っていたみたいに、自前ビルドのswiftをXcodeのToolchainsに入れるのってどうやるんですか？あと、そういう系の情報ってどの文書に書いてありますか？ build-script -h は見たけど書いてなかったのと、ビルドにも時間かかりすぎて試行錯誤ができず・・・

1:33 AM

swift-source/build/Ninja-Release/swift/bin とかにバイナリが入ってるところまではいけたんですが。 (edited)

僕は swift/utils/build-toolchain を使いました。このジョブと同じ内容。 https://ci.swift.org/view/Packages/job/oss-swift-package-osx/ (edited)

1:49 AM

ですが、 swift-nightly-install ディレクトリ内にツールチェイン一式が出来ていれば、インストーラパッケージを作れるはず。

1:50 AM

swift/utils/build-toolchain はすべてのプラットフォームのテストを実行するため、めっちゃ時間がかかります。(僕のMacで11時間以上かかった)

Job config: swift/utils/build-script --preset="buildbot_osx_package" \ install_destdir="${SWIFT_INSTALL_DIR}" \ installable_package="${SWIFT_INSTALLABLE_PACKAGE}" \ install_toolchain_dir="${SWIFT_TOOLCHAIN_DIR}" \ install_symroot="${SWIFT_INSTALL_SYMROOT}" \ symbols_package="${SYMBOLS_PACKAGE}" \ darwin_toolchain_bundle_identifier="${BUNDLE_IDENTIFIER}" \ darwin_toolchain_display_name="${DISPLAY_NAME}" \ darwin_toolchain_xctoolchain_name="${TOOLCHAIN_NAME}" \ darwin_toolchain_version="${DARWIN_TOOLCHAIN_VERSION}

1:51 AM

これらのパラメータはどうやって決めました？ (edited)

1:52 AM

swift-nightly-install というディレクトリは見当たらないです

1:52 AM

iOS向けとかをskipしてると駄目なのかな

CIログの前半に、実際のサンプルが出て来ます。 https://ci.swift.org/view/Packages/job/oss-swift-package-osx/3373/consoleText

1:54 AM

長すぎて貼れないので gist https://gist.github.com/norio-nomura/80f7de267417bdbfd9f4e7f5c9e0c4c4

https://ci.swift.org/view/Packages/job/oss-swift-package-osx/3373/consoleText から抜粋

1:55 AM

＾改行入れた

ありがとうございます、なるほど、CIの詳細を見ればいいわけですね

1:56 AM

https://ci.swift.org/job/oss-package-trigger/lastStableBuild/console

そそ。

↑こういうのはみつかったけどnorioさんがはってるやつはどこからいけるんですか？

1:57 AM

a

1:57 AM

あった

1:57 AM

「プレーンテキスト表示」か

そそ

おとなしくフルビルドしたら24時間かかりそうなんだよな・・・

で、インストーラ作成もCIログを見ればわかりますが、僕はこんなスクリプトにしてます。 https://gist.github.com/norio-nomura/185a61fd93b6a6d275f0445bcb4be6d0

swift/swift-nightly-install からインストーラパッケージを作成

1:59 AM

--skip-test-* なんとかをつけまくれば良いと思います。>テスト (edited)

2:01 AM

この辺り https://github.com/apple/swift/blob/master/utils/build-script-impl#L130-L151

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions

swift - The Swift Programming Language

ふむふむ

11時間以上は MacBook Pro (Retina, 13-inch, Late 2013) 2.6 GHz Intel Core i5 8 GB 1600 MHz DDR3 での結果。

MacBook (Retina, 12-inch, Early 2015) 1.3 GHz Intel Core M

2:05 AM

だいたいそれの4倍かかるｗ

各プラットフォームのテストが圧倒的に長いので、osxとios simulator以外をスキップすれば、かなり短縮できると思う。

なるほど。 --skip-ios --skip-tvos --skip-watchos 現状これで6時間とかです

昨日のフルビルド？

はい

2:07 AM

4時間かな？

2:08 AM

consoleText、chromeが死ぬので今テキストエディタで開きました。。

各リポジトリ間の依存が問題なければ、swiftだけ最新にして、テストもswiftだけにして、他のリポジトリのテストもスキップとかすれば良いのかも。

CIログと build-script-impl の冒頭を見比べたらいろいろできそうなのでやってみます

あ、僕の11時間はlldbのテスト含んでたので、--skip-test-lldb をつけるとさらに短縮されるかな。

skip-test-lldb とかはでかそうですね

最新のスナップショットは、lldbのテストが通らないので --skip-test-lldb で出てるはず。

そういうこともあるのか・・・

Appleのlldbチームの人が大勢やめたとかそんな話を見かけたけど、真偽未確認…

フーム

2:22 AM

テスラはSwift関係者引き抜くのやめてほしい

いや、 Apple の外に Swift が飛び出すことによって、より広い範囲で使われるようになるかもしれない。

2:27 AM

Swift が汎用メジャー言語になるためには「 Apple の言語」ではダメで、影響力のある会社が何社か iOS 以外の実案件で採用してくれないといけないと思う。テスラがそうなるかはわからないけど。

これ、こういうことがしたいんだけど書き方間違ってるか出来ないか分かる人いますか

struct Hoge<T> { } extension Hoge where T == [Any] { func fuga() -> T.Element { // <- Error: 'Element' is not a member type of 'T' fatalError() } }

答えにはならないけどその場合なら Any って書けば？

あー、

struct Hoge<T> { } extension Hoge where T: Sequence { func fuga() -> T.Iterator.Element { // <- Error: 'Element' is not a member type of 'T' fatalError() } }

これは通るね

2:36 AM

ConcreteTypeでのEquality Constraintの時には左辺値に型定義が伝搬しない・・・？

あれ、これだと例えば Hoge<[Int]> にはこのextensionだめ？

だめだと思うよ。

任意の配列を型パラに持つとき、その配列の要素の型を返すメソッドみたいなのを生やしたいみたいな感じなんだけどにゃあ…

それは型パラ付きExtensionが必要だけど今無い、って話しな気がする

2:37 AM

extension定義自体が <T> を取る必要がありそう

なるほど。

@koher 今影響力の大きい適応範囲だとサーバサイドLinuxとブラウザとAndroidっすね

where付きのextensionの中でそのTが[Any]に見えないってことなの

2:40 AM

struct Hoge<T> { } struct Nested { struct MoreNested { } } extension Hoge where T == Nested { func fuga() -> T.MoreNested { // これもだめだった。 fatalError() } }

struct Hoge<T> { } extension Hoge where T == Array<Any> { func fuga() { print("fuga!") } } let x = Hoge<[Int]>() x.fuga()

2:40 AM

Playground execution failed: error: HogeGround.playground:5:1: error: 'Hoge<[Int]>' (aka 'Hoge<Array<Int>>') is not convertible to 'Hoge<Array<Any>>' x.fuga()

2:41 AM

あーそうか、理論的にも無理だわな

[Any]と[Int]はだめか

Array<Int> is Array<Any> だけど、 Hoge<Array<Int>> は Hoge が T について Covariance でないかぎり Hoge<Array<Any>> ではない。

↑のNestedとMoreNestedのやつはなんか直感的にそれでいけるもんだと思ってたんだけど行けなかった悲しい

まー == はなんか本当に代入されるわけじゃないっぽいね。

このチャンネルで 5/2 に @koher さんがそれ的なことをやりたくて @norio_nomura さんによる workaround 出てるので、ログ見てみてください。

お、見てみます。

まじすか。全然記憶にないｗ

パーマリンク欲しいなぁ。

1

structのvarianceの話なんか過去にありましたね

たださ、Xcodeちゃん、 -> T. まで打つと NestedType を補完してくるんだよな

なめられてるね

1

2:44 AM

あー、けど @koher さんのとはちょっと違うかな。

extension Array where Element == Optional まで書いて、型パラメータが書けなくて固まった・・・

それはありましたね。それ書きたい・・・。

なるほど。

2:48 AM

やはりパラメータ付きextensionが要るのか。

@norio_nomura さんの workaround 今回のに適用すると、

protocol HasElement { associatedtype Element } extension Array : HasElement {} struct Hoge<T> { } extension Hoge where T: HasElement { func fuga() -> T.Element { // 通る fatalError() } }

(edited)

swift - The Swift Programming Language

2:49 AM

extension<T> Array where Element == T? { var someValues: [T] { var result = [T]() for opt in self { if let value = opt { result.append(value) } } return result } }

2:49 AM

そのものずばり、マニフェストで提示されてる

おお、そうなんだ。

Parameterized Extension と名付けられているようだ

よく覚えてるなあw

関連して（ないような気もするけど）↓の動向が気になってる。 extension Array where Element == Int { ... } を extension Array<Int> { ... } のように書けるようにするのには何か技術的な難しさがあるの？って質問（ちょっとニュアンス違うけど）。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170508/036599.html (edited)

その件、ソース確認したんですが、無さそうです。純粋に syntax だけの制限だと思います。 concrete type extension が許可されてなかったから。

なるほど。歴史的な経緯でこうなっているんですね。

--- Installing swift --- + env DESTDIR=/Users/omochi/work/swift-install/ /usr/local/bin/cmake --build /Users/omochi/work/swift-source/build/build-dir/swift-macosx-x86_64 -- install ninja: error: unknown target 'install', did you mean 'test/all'? utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting

7:57 AM

朝開始したやつさっきエラーで終わってた

7:57 AM

4.0branchのCI見てみよう

@hiragram structのGenericsは見えないけどprotocolのassociatedtypeは見えるから

8:09 AM

例えばこういうコードなら通る

struct Hoge<T> { let value: T } extension Hoge where T: BidirectionalCollection { func fuga() -> T.Iterator.Element { return value.first! } } Hoge(value: [1, 2, 3]).fuga() // 1

8:10 AM

って話が上の方にあった

8:10 AM

TをArrayっぽく任意のSequenceからinitしたい、みたいな感じだと

8:11 AM

Arrayのinitは、RangeReplaceableCollectionの実装だから

8:12 AM

extension Hoge where T: RangeReplaceableCollection { }と書いておけば、その中でT.initが使えるようになる

8:14 AM

BidirectionalCollectionはよく使うんだけどなんだったかな、lastが欲しいので使ってた気がする。

あ〜いけたかんじがする

8:21 AM

-- が　重要なのか

8:21 AM

$utils/build-script <options A> -- <options B> こうなってて、Aはbuild-scriptのやつ、 Bはbuild-script-implのやつか？

8:22 AM

--- Installing swift --- + env DESTDIR=/Users/omochi/work/swift-install/ /usr/local/bin/cmake --build /Users/omochi/work/swift-source/build/build-dir/swift-macosx-x86_64 -- install ninja: error: unknown target 'install', did you mean 'test/all'? utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting

だめだｗ

あ〜 --reconfigureつけたらビルドしなおしになってしまった　終わり

8:48 AM

あれ、でもなんか中途半端に xctoolchain生成されてるな

build-script へ渡すオプションの組み合わせはプリセットとして swift/utils/build-presets.ini の中に記述されています。例えば OSS - Swift Package - OS X (master) で使われている buildbot_osx_package プリセットはこれ。 https://github.com/apple/swift/blob/master/utils/build-presets.ini#L955 (edited)

11: Ownership Manifesto - Swift Unwrapped

swift - The Swift Programming Language

あーなるほど

9:05 AM

ログの

/Users/buildnode/jenkins/workspace/oss-swift-4.0-package-osx/swift/utils/build-script: note: using preset 'buildbot_osx_package', which expands to

9:05 AM

ここで、presetから実引数への展開結果が表示されてるので、展開結果のパラメータを１個ずつ見て移してました (edited)

swift/utils/build-presets.ini の代わりに自分で用意したものも --preset-file=… で使えます。 (edited)

9:11 AM

SourceKit for Linuxでのビルドにカスタマイズしたものを作って使ってました。 https://github.com/norio-nomura/swift-dev/blob/sourcekit-linux/build-presets-for-sourcekit-linux.ini

norio-nomura/swift-dev

swift-dev - Managing Swift Repositories

9:13 AM

まあ、そんな諸々よりも --dry-run を使った方が早いかもしれませんが。

なるほど

@omochimetaru Ownership Manifesto 関連 https://spec.fm/podcasts/swift-unwrapped/69191 https://gist.github.com/Gankro/1f79fbf2a9776302a9d4c8c0097cc40e

A brief overview of the complex topic of memory ownership revisions currently underway.

Swift Ownership Manifesto TL;DR

@rintaro ありがとうございます。

1:36 AM

昨日の19:30に発火したビルドが今みたらまだ終わってなかった

1:37 AM

preset自作していろいろ削らないと無理だなあ

CIで回ってるpresetを下地にオリジナルpresetでもろもろskipしてリトライ

次のSwift 4.0 DEVELOPMENT SNAPSHOTとどちらが早いか

既に過去のチェックアウトでやってるんで抜かされてるっていう・・・

2:33 AM

最終的にはまだプルリク段階の作業とかを試したいからやってます

ああ、ならばSmote Testとかで走るCIをやった方が良い気も。

PRのときになんかsmoke testって言葉出てきますね　何なのか知らないですが

テスト最低限でインクリメンタルなビルド時間が短いやつだと思ってます。

2:43 AM

https://ci.swift.org/view/Pull%20Request/

2:45 AM

どの部分へPR出すかによっても違うから、最終成果物を作成する方法を手元で再現しておくのは大事だよね

ですねえ

2:50 AM

というか、ビルド周りの情報もっとたくさんあるのかと思ってました

わからなかったらCIみろ、って感じですね。

昨日見てみて一個わからなかったのが

2:54 AM

CI summaryには変数式のスクリプトが書いてあるけど

2:54 AM

リポジトリを取ってきたり、一番最初のスクリプトを叩く行の内容とかが

2:54 AM

どこに定義されてるのかわからなかったです

2:55 AM

TravisCIとかならリポジトリの中にymlファイルが有るけど

2:55 AM

Jenkinsの側にメタデータとして書いてある感じがしてて、それを見る方法がわからなかった (edited)

2:56 AM

[oss-swift-4.0-package-osx] $ /bin/bash -e /var/folders/_8/79jmzf2142z2xydc_01btlx00000gn/T/hudson5232063434834374318.sh /Users/buildnode/jenkins/workspace/oss-swift-4.0-package-osx/swift/utils/build-script: note: using preset

2:56 AM

CIログの一番最初の、この、 hudson5232063434834374318.sh このシェルスクリプトの中身。

2:57 AM

swift/utils/build-script を叩くスクリプトだと思うけど、そのオプションとか、その前に環境変数をセットするとか、そういう作用がこのログに無い

ないですね。その辺りは非公開にしておかないとまずい部分もあるのだと想像。

なるほど・・・

3:00 AM

Travisしか触ったこと無かったので

3:00 AM

違和感がありました

3:01 AM

何か一個でも不可視の部分があるとそこの影響で何が起きるか計り知れないのでモヤモヤします

macOSのCIビルドはサードパーティーへの依存がほぼ無いので、それほど心配する必要はないと思います。

ところで、貰ったPR6に、さっきコメントを書きました。 https://github.com/omochi/swift-ownership-jp/pull/6

[storage reference] subscriptの説明を修正 by norio-nomura · Pull Request #6 · omochi/swift-ownership-jp

ぬ、コメント見えない

あら

3:07 AM

なるほど、これはまだ下書き状態なのか。

3:07 AM

すいません、使い方がわかっていなかった。

お手数おかけしました。

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-15-a 来てた

enumをstructに変更してて気づいたんですがstaticなstored propertyも.hogehogeだけでアクセスできるんですね。知らなかった。

UIColorの.redとかでも使われてますよね

static funcも返り値がSelfなら.fugafuga()で呼べます

まだ知らないことがたくさんあるらしい。

返り値Selfなら型を省略できるけど

switch color { case .red: ... は出来ないという罠。

代入先の型がprotocolだとできないことが結構ある (edited)

まあそれは網羅できないし。

RxでflatMap { .empty() }とか無理だったような(いけたっけ?

4:39 AM

代入先の型が具体的で、返り値がSelfの場合に限り、型の宣言を省略できる、かな。

.init(…) とかもよく使う。

.init使いますね、そしてタプルが使えなくてFoooooってなる

コンパイラによる実装の自動生成ブーム的な。 we propose that a type synthesize conformance to Equatable/Hashable if all of its members are Equatable/Hashable https://github.com/apple/swift-evolution/pull/706

Proposal to synthesize Equatable/Hashable for value types. by allevato · Pull Request #706 · apple/swift-evolution

↑これほしいようなほしくないような・・・。

5:23 AM

Users must opt-in to automatic synthesis by declaring their type as Equatable or Hashable without implementing any of their requirements.

5:24 AM

ああ、 Codable と同じように宣言は必須なのか。実装が自動挿入されるだけで。それならいいかも。

5:26 AM

自動生成、便利だけど判断ミスってやりすぎると取り返しのつかないものを入れてしまいそう。 Codable, Equatable, Hashable みたいな枯れた定型パターンならいいかもだけど。

5:26 AM

どうせなら public なイニシャライザの自動生成もほしい。

5:28 AM

↓こんなの。

public struct Foo { public var bar: Bar public var baz: Baz public var qux: Qux public init {} // 全プロパティを使って自動生成 }

CodableなクラスのサブクラスのCodable実装自動生成がうまくいっていないので、実装自動生成関連はまだ色々と修正が必要そう。

structならもうあると思うけど internal だから駄目って事ですか？

そうです。

なるほど。

swift-corelibs-foundationのドキュメントにはXcodeでビルドできると書いてあるけど、ci.swift.orgでXcodeによるビルドがテストされていないから、ビルドできない状態になっててもおかしく無いのかな。

ドキュメントのメンテって難しいですね・・・

なんか今日もいちにちかけたビルドが終盤のインストールでarmv7バイナリが無いとかでこけた

10:18 AM

iosのスキップした状態でパッケージさせるの無理そうなので

10:19 AM

自宅マシンをビルドサーバー化するところから出直す

swift-corelibs-foundation 最新スナップショットtoolchainでもコケますが、 Xcode で Other Swift Flags に -swift-version 3 追加したら通りました。

1

そうか、Swift 4のプロトコルを使ってる==-swift-version 4 では無いってことか。

SwiftFoundation, SwiftXCTest, TestFoundationに -swift-version 3 をつけていけました。ありがとうございます。

@omochimetaru iOSテストのスキップではなくビルドもスキップしてたのですか？

はい。

11:13 AM

macだけ動けばいいので

なるほど。

あるものだけかき集めてパッケージするような挙動に期待してた

この間ちらっと話題に上がった、クロージャを引数に取る場合にデフォルトで何もさせたくない場合にどうするかというの

2:54 PM

public func nop<T>(_ v: T) {} こういうの作って

2:54 PM

public func doOptional(_ closure: ((Int) -> ())? = nil) { closure?(1) } public func doEmpty(_ closure: @escaping ((Int) -> ()) = nop) { closure(1) }

計測してみたけど、普通にOptionalのほうが速かったw (edited)

2:57 PM

Optimizeしても似た比率の結果。引数に渡す時点でコピーが走るとか、冷静に考えたらそりゃそうかという感じ

2:57 PM

無になってはくれなかった。

なるほど

https://github.com/moshbit/Kotlift

moshbit/Kotlift

Kotlift is the first source-to-source language transpiler from Kotlin to Swift

Data class サポートしてないとかキツイですね…。

@tarunon nonescapingにしないの？

1:33 AM

ああ逆か

1:33 AM

ん？

1:33 AM

いややっぱ変だな

escapingの有無、引数に渡すものをvoid、GenericsではなくAny、全て試したが

うん

全てのケースでOptionalの方がはやい。

え〜 non-escaping ならインライン化されるから無になると思ったが・・・

引数に渡す部分が無にならない気がする

1:35 AM

コピーやAnyへのラップが発生することが、オーバーヘッドとして露出していて

1:35 AM

それらはnilチェックより高コストだった

あ、nop関数は別途名前を定義してるのか

{ _ in }こいつだと

1:37 AM

Optionalと同じぐらいのスピードになったが、明確に速いと言えるほどの差は無かった気がする、Voidでは。Intだとどうだったかな、記憶があやふやだ (edited)

最適化は有効化した？

やってるぞ

なるほど。

上のキャプは最適化は無だけど、最適化しても同程度の比率なのは確認した。

1:40 AM

まあ考えてみれば、関数を引数に直接渡してるわけではなく、クロージャにラップして渡してるはずだし

1:41 AM

クロージャが無かどうかなんて、コンパイル時に判断できないから無になるわけがなかった

関数を渡すときってラップされるんですか？

@koher Swiftのクロージャ表現にはバイナリが３種類あって

1:52 AM

環境キャプチャ（func in func)したりメソッドでない場合は

1:53 AM

ネイティブ関数ポインタになるはずですが (64bit)

1:53 AM

この例だと型パラメータがついてるので

1:53 AM

それに当てはまるか謎

func nop(_ v: Any){}でも、計測結果に差は無かった。期待される関数の型と、渡される関数の型が違う場合は全てクロージャにラップされてるのでは？と言う気がしている

その場合はthunkが作られるはずだねえ

両方Voidにして、func nop(_ v: Void){}ならOptionalに追いついた気がする

クロージャのアップキャストを表現するために包むだけのやつ

同じパッケージだとジェネリックでもspecializeされないの？

thunkになった段階で無かどうかコンパイルタイムに判断できない気がする

thunkのコード自体はコンパイラから静的に見えるからインライン展開のインライン展開を期待してた

1:58 AM

今度自分でもいろいろなパターンで実験してみる

nop<T>が最適化されないと、現実的なシチュエーションでは使いづらい感

デフォルト引数の部分には = { in } って書けないんだっけ？

書けるけど、Optionalと等速なので

2:00 AM

採用する価値がない気がする

2:01 AM

func nop<T>(_ v: T){} func foo(_ closure: (Int)->()=nop) {...} ↑undefined<T>以来のヒットだと思ったけど、残念w

パラメータ Void は warning が出るようになった。

 warning: when calling this function in Swift 4 or later, you must pass a '()' tuple; did you mean for the input type to be '()'? public typealias XCPredicateExpectationHandler = (Void) -> (Bool) ^~~~~~ ()

あら・・・・・

var fuga: Bool! let a: Int = fuga ? 1 : 2 コンパイラがセグフォでしぬ

ほんとだｗ

var fuga: Bool! = true (or false) でもしぬ

それはへいきだった

アレ？

5:45 AM

var fuga: Bool! = true let a: Int = fuga ? 1 : 2 俺はこれのつもりで言ってたけどあってる？

いや

5:46 AM

２行目は消した

(fuga==true)?1:2

5:46 AM

で

なるほど

5:46 AM

そうそう

というかBool!が出現するのはどうなんだ

ｗｗｗ

それはまあ

5:46 AM

そう。

IUOを見ると突っ込まずには居られない

絶対来ると思ったよ

5:47 AM

var fuga: Bool! let a: Int = (fuga ?? true) ? 1 : 2 IUOやめろは一旦おいておいてこれはコンパイル通るからBool!と三項演算子が良くないっぽ

なんでnilがtrueになるんや！！

それはまあ

5:48 AM

そう

w

そういう意味は無いからｗ

let だとだいじょぶ

報告しなきゃ

お

多分誰も今までBool!を?:で使ったことがないんだよ

@rintaro これであってますか？ let fuga: Bool! let a: Int = fuga ? 1 : 2

5:49 AM

通らん

5:50 AM

let fuga: Bool! = true let a: Int = fuga ? 1 : 2 これは通った。

明示的に初期化しないとだめですね。

5:51 AM

l-value expression does not have l-value access kind set エラーとしてはこれなので、 l-value 性を保ったまま ?: に突っ込むと失敗する感じ。

IUOをアンラップすると通る？ var fuga: Bool! = true let a: Int = fuga! ? 1 : 2

明示的にアンラップすればそれはただのBool or dieだし通るの納得

5:52 AM

@omochimetaru こういうのって報告するとしたらどこにどう報告するもんなんすか

https://swift.org/contributing/#reporting-bugs

https://gist.github.com/rintaro/b16f05411cfe540754285dcc0da60174

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

JIRAか

いいね https://github.com/ole/whats-new-in-swift-4

ole/whats-new-in-swift-4

whats-new-in-swift-4 - An Xcode playground showing off the new features in Swift 4.0.

one-sided-rangeはprefix/postfixなので i+1..<j-1に対して(i+1)...とか..<(j-1)とか括弧つけないとだめですよね。これも一掃できたら綺麗だと思うんですが。

class Animal { // コンパイルOK func aa() -> Self { return self } static func bb() -> Self { // コンパイルを通せるコードが見当たらない } }

7:21 AM

プロトコル定義の中 ではなく 、実際のクラスの中で Self って書くと、 self の型を意味するようなんですが

7:22 AM

こっちの具体的な型の中での Self は、フィールドや引数やクロージャ型に混ぜて使うと怒られて、この、インスタンスメソッドの返り値と、スタティックメソッドの返り値の2箇所にしか書けなくて

7:22 AM

そして、インスタンスメソッドの場合は、 self でしか満たせないように思えるんだけど

7:22 AM

スタティックメソッドの場合はどうすれば満たせるんだろう？絶対に満たせないなら、 インスタンスメソッドの返り値部分だけ に使える、って仕様で良いと思う。

7:23 AM

'Self' is only available in a protocol or as the result of a method in a class;

このようなエラーメッセージが出るけど、 result of a instance method で良いと思うんですよね。

@omochimetaru

class Animal { static func cast<T: Animal>(animal: Animal) -> T { guard let animal = animal as? T else { fatalError() } return animal } static func bb() -> Self { return cast(animal: Animal()) } }

7:24 AM

力技で通したよ

7:24 AM

Himotokiを使ってると似たようなパターンに遭遇することがあって、こんな感じでゴリ押しして押し通った記憶がある

これって Animal() as! Self って書いてるのと何が違う？まあこれは書いても怒られたんだけど、意味的には一緒？

一緒ですね

ななるほど

static func bb() -> Self { return .init() } とか？

んーコンパイルしたあとのコードは違うかも

7:26 AM

@rintaro require initにすればいけますね

あ〜〜〜

7:27 AM

うおおとおった

7:27 AM

class Animal { static func bb() -> Self { return .init() } }

initがrequireじゃなくても通るの

7:27 AM

通ったとしても、実行時に死ぬ気がする

finalクラスならrequireじゃなくてもいけそう

class Animal { init(x: Int) { } static func bb() -> Self { return .init(x: 3) } }

7:28 AM

これもいけるぞ？？？？？

requireじゃないと、サブクラスでbb呼んだ時に確実に死ぬ

7:29 AM

ってことはそれはコンパイラのバグっぽい

やってみますね

多分、本物のぬるぽを見ることはなくって、initが存在しないで死ぬ気がするけど

class Animal { init(x: Int) { } static func bb() -> Self { return .init(x: 3) } } class Cat : Animal { } func main() { print(Cat.bb()) } main() [omochi@omochi-MB stt]$ swift a.swift a.Animal

class Animal { // コンパイルOK func aa() -> Self { return self } class func bb() -> Self { return .init() } } class Dog : Animal { init(x: Int) { super.init() } func bowow() {} } let a: Dog = Dog.bb() a.bowow()

最後の行まで死なない。

Cat.bbよんだらAnimalでてきた

えーっと

7:31 AM

Catにフィールド1個足して、別のinitを定義しないと

7:31 AM

マジカ

7:31 AM

最後の行まで死なない…

a

7:32 AM

たるのんのいうとおりだ

7:32 AM

バグだ

7:32 AM

クラッシュした

7:32 AM

class Animal { init(x: Int) { } static func bb() -> Self { return .init(x: 3) } } class Cat : Animal { var name: String = "cat dayo" } func useCat(cat: Cat) { print(cat.name) } func main() { useCat(cat: Cat.bb()) } main()

7:32 AM

useCatは静的にCatの式になってて、cat.nameでプロパティアクセスさせてるけど

7:32 AM

Cat.bb()がCatを返すという静的な扱いなのに、実際にはAnimalを返してる関係で吹っ飛ぶ

7:34 AM

@rintaro このようにちょっと追記したら吹っ飛びました class Dog : Animal { var name: String = "I am pochi" init(x: Int) { super.init() } func bowow() { print(name) } } (edited)

「最後の行まで死なない」は、「最後の行で死ぬ」の意でした。

あ、なるほど。

Dog は init() 持ってないから、死ぬなら一つ前の行で死なないと。

initメソッド、というかイニシャライザは、理論的にはSelfを返す式なんですね

7:37 AM

だから、他の static func ccc() -> Self のような、Self を返すstatic methodを呼ぶのと解釈的には同じかな

7:38 AM

まあそれだと堂々巡りになっちゃうので、ほんとうの意味で Self を作れる init が特別な存在か

factory_init.swift

7:39 AM

これも Dog(type: "cat") 呼べちゃうっていう問題がきつい (edited)

catでinit定義してもうまくいかねえな

7:39 AM

required initにしたら全部うまくいった。

そう、required initはちゃんと動く

required initは class func 的なものになってそうだなあ

7:40 AM

@rintaro 絵文字ｗ

7:41 AM

え、これなにがおこってんの・・・

7:41 AM

init(factory: () -> Self) { self = factory() } まずこれがヤバ

Swift でクラスクラスタを無理矢理実現するの。

swiftでもselfって差し替えられたの・・・・

protocol の mutating func と init ではいけちゃいます。

protocol extensionにinitの実装書けるのと、その中ではselfの差し替えができてしまう、という

7:44 AM

ひどいw

7:44 AM

あれ?

7:44 AM

これは良いことを思いついてしまった

これは任意のクラスのインスタンスを差し替えられる・・・？

7:45 AM

mock的な何かに・・・？

StoryboardとNib

えっ、これおかしすぎないか・・？いいのか？？

ww

https://gist.github.com/rintaro/1668e46bc969c5f991079dd5bf530dd1 こういうユーザ側で予期しない挙動になるので、使いすぎ注意。

resettable.swift

やべぇ

mutating func ってクラスでは使えないと思ったけど

7:48 AM

protoocl の mutating経由だとできるのか・・・

Nib, Storyboardのinitに悪用できないか真面目に考えよう

あーじゃあextension経由でmutatingメソッドをvarに対して呼んでる時

7:50 AM

ちゃんとクラスでもvarのselfそれ自体の差し替えが

7:50 AM

発行されてるのか

ですね。 mutating func の self のセマンティクスは inout と同じです。

ref1.reset() この行が mutating の呼び出しだから var の値の変更をする可能性があって、それでObjectIdentifierが変わると

7:51 AM

ああ、そうですね。

これすごいな

ちょうどownership周りの文書でもそこが整理されてた。

7:53 AM

でもそれならclassでもmutating func 定義できて良い気がする、それができないのに現状でこれができるのはおかしい感じが・・・

7:55 AM

@rintaro ていうかこれどこで気がついたんですか？ｗ

stdlib のソース見てたら、 https://github.com/apple/swift/blob/master/stdlib/public/core/Integers.swift.gyb#L1141-L1143 protocol extension で self = みたいなのがあって、じゃあ出来るじゃん的なｗ

https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md

swift - The Swift Programming Language

なるほどｗ

8:00 AM

SignedNumericってだいたい継承先はstructな気がするけど、別にプロトコルなんだからもしクラスだったら？・・・って流れか

8:01 AM

そっかー selfそれ自体がinoutセマンティクスってそういうことかあ・・・

悪用しようと思ったけどletとの共存は無理っぽいし嬉しさはそんなに増えなかった

8:01 AM

それなら黒魔術使ってまでinitに固執することもないなという感

ちょうどownershipでプロトコル: struct / class 周りで理論的な整合がよくわからなかったけど、こうやって整理されるんだなあ

8:02 AM

あら。

8:02 AM

また謎のバグを見つけるオチかと思ってたけど微妙だったか

謎のバグw

8:03 AM

super.initを呼ぶか、convenience initにするしか無いのだけど、そうすると、letへの代入の順番の制約か、そもそもそれ自体ができない、ということになるので

そもそもsuper.init呼ぶの無理だった

8:10 AM

どうやってもconvenience initじゃないといけないですね

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-17-aでSequence.Element が追加されて、Sequence準拠したenumのcaseとして定義されているElementとぶつかったのだけど、これって-swift-version 3で回避できるようになる類の変更なのだろうか？ https://bugs.swift.org/browse/SR-4951 (edited)

-swift-version で回避できるとは思えないですねぇ。 -swift-version 毎のstdlibを用意するくらいしないと回避できない気がします。 (edited)

やはりそうですよね…

現状、#if swift(>=3.2)って書くと、Swift 4で-swift-version 3を指定したビルドと、Swift 3.1.1ビルドを区別できるぽい。

3:50 AM

WWDCでXcode 9にswift-3.0-branchからのSwift 3.2とSwift 4の両方が入ってくるとしたら、これも使えなくなるのかな。 (edited)

3:54 AM

Swift 4の-swift-version 3とSwift 3.xを全く同じコードで対応ってのは、どうしても無理な場合が出てくるので、区別できるようにしてほしいなあ。

let a = [""].map { $0 }.prefix(3) let b = [""].prefix(3).map { $0 } // Ambiguous use of 'prefix' [String]#prefixはArraySlice<Sequence>を返すものとAnySequence<String> を返すものがあるんですが bのみambiguousになってaはArraySlice<String>に寄るのは何でですかね？片方に寄せることが決まってるならbもやってくれても良いんじゃないかと思うんですが。 (edited)

AnySequenceのほうのprefixの定義に飛べなくて調べられない……

 1> let a = [""].map { $0 }.prefix(3) a: ArraySlice<String> = 1 value { [0] = "" } 2> let b = [""].prefix(3).map { $0 } error: repl.swift:2:9: error: ambiguous use of 'prefix' let b = [""].prefix(3).map { $0 } ^ 2> let b = [""].prefix(3) b: ArraySlice<String> = 1 value { [0] = "" } 3> b.map { $0 } $R0: [String] = 1 value { [0] = "" }

7:18 AM

@t.ae 1は間に map が入ってその戻り値は [String] しかないから型を決定しやすそう。

ArraySliceによるのはAnySequenceがより広範な定義になってるからとかですかね？（まだ定義部が分かってない）しやすい、しにくいというのならambiguous~とでてる時点で２つに絞り込めているはずなので、それをlet b = [""].prefix(3)だと判断できてるのにmapがついただけでambiguousになるのがいまいち解せないです。

2 は [""] が [String] とも決定できてないかも？

そこ一時変数置いたのも試してるんですよね。

ん？ 3 と 4 に分割したら通ったよ？？

いや

7:26 AM

let a: ["String"] = [""] a.prefix(3).map { $0 } が通らないという話です。

なるほど

7:26 AM

map は ArraySlice にも AnySequence にもあるから、後ろに map が続くという条件の元では ArraySlice 優先が消えて AnySequence と同格になってるのかも。

mapのほうから型推論しようとしてるならそうとも考えられそうですね。

extension Collection { public func prefix(_ maxLength: Int) -> SubSequence { } } extension Sequence where SubSequence : Sequence, SubSequence.Iterator.Element == Iterator.Element, SubSequence.SubSequence == SubSequence { public func prefix(_ maxLength: Int) -> AnySequence<Iterator.Element> { } } extension Collection { public func map<T>( _ transform: (Iterator.Element) throws -> T ) rethrows -> [T] { } } extension Sequence { public func map<T>( _ transform: (Iterator.Element) throws -> T ) rethrows -> [T] { } }

(edited)

7:53 AM

式の末端から型推測しようとしてるからぽい。

あー

where の制限が多いかどうか？が、末端でしか評価されていないのかな？

[""] が ArraySlice<String> の可能性を考慮してるのか。

7:55 AM

[""] が [String] だと AnySequence の方の prefix は条件に当てはまらないけど

なんとなく双方向で型推論してくれてるんだと思ってたんですがそうでもないんですね

いや、双方向で推論しても解決できないんじゃない？

[""].prefix(3)がArraySliceになるのを解決できてるとするなら、ですね (edited)

 2> let b: ArraySlice<String> = [""] b: ArraySlice<String> = 1 value { [0] = "" } 3> b.prefix(3).map { $0 } error: repl.swift:3:1: error: ambiguous use of 'prefix' b.prefix(3).map { $0 } ^ 3> b.prefix(3) $R0: ArraySlice<String> = 1 value { [0] = "" }

7:58 AM

うーん

7:58 AM

たしかに最初の 3 でも決定できないか

7:59 AM

あれ？読み間違えてた

7:59 AM

SubSequence == Sequence じゃないのか

8:00 AM

↓って何のためにあるんだろう？

extension Sequence where SubSequence : Sequence, SubSequence.Iterator.Element == Iterator.Element, SubSequence.SubSequence == SubSequence { public func prefix(_ maxLength: Int) -> AnySequence<Iterator.Element> { } }

そもそもこのwhere句が何を期待しているのかも分かりにくいですね

8:03 AM

一見Subsequenceを更にイテレートするように見えるのですが

SubSequence.SubSequence == SubSequence これが何のためかよくわかんないね。

これはSubSequenceが自分自身と同じ型という意味だと思います

それはわかるんですが、何を目的としているのかがいまいちわからず・・・。

同上

SubSequenceが自身の型なら、prefixは自明だから実装できるということでは

SubSequenceが自分自身とは違う型になるパターンがあるからでは？

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

自動実装のためってことですかね

SubSequenceが自身の型でないとprefixが実装できないですか？

AnySequenceのinitの条件がそれなのでは

ほんとだ

なるほど。そうすると、もう一つ僕がよくわからないのは、戻り値を AnySequence とした prefix のオーバーロードがほしい理由ですね。 (edited)

あー、んんー?

この制約は AnySequence の init が担保するから、 AnySequence がほしければ普通に AnySequence(foo.prefix(3)) とかでいい気が。

extension Sequence where SubSequence : Sequence, SubSequence.Iterator.Element == Iterator.Element, SubSequence.SubSequence == SubSequence { public func prefix(_ maxLength: Int) -> AnySequence<Iterator.Element> { } }

これもしかしてSubSequenceがAnySequenceであることを示唆してる気がしてきた(AnySequence.SubSequence==AnySequence) (edited)

そのExtension定義に飛ぶ方法誰か教えて

SubSequenceがAnySequenceであることは、where句に書けないかな?

そうですか？ [String]だとSubsequence == ArraySlice<String>でSubsequence.Subsequence == ArraySlice<String>だと思いますけど

いや、今 Array や ArraySlice に対してこの prefix が候補であいまいだと言われてるので、

8:12 AM

普通に Array や ArraySlice でも当てはまると思います。

extension Sequence where Self.SubSequence : Sequence, Self.SubSequence.SubSequence == Self.SubSequence, Self.SubSequence.Iterator.Element == Self.Iterator.Element {

これか

ArraySlice の SubSequence は ArraySlice だから

普遍的なTに対してSubSequence==ArraySlice<T>って書けるのかな

Sequence.prefix https://github.com/apple/swift/blame/swift-3.1.1-RELEASE/stdlib/public/core/Sequence.swift#L1272 Collection.prefix https://github.com/apple/swift/blame/swift-3.1.1-RELEASE/stdlib/public/core/Collection.swift#L1408 (edited)

swift - The Swift Programming Language

swift - The Swift Programming Language

ArraySlice の場合は T によらず SubSequence が ArraySlice<T> ですよね？

extension Sequence where Self.SubSequence == AnySequence<Self.Iterator.Element> { }

8:15 AM

これも出来るしなんだろう

当時はできなかったのでは。 (edited)

ああ、そういうことか。そういう制約の代わりに書いてるんじゃないかってことですね。

これ書けるようになったのって3以降か3.1以降な気がする、どっちだろ

8:17 AM

2で書けたかなー

でもそれだと大分意味が変わっちゃてるなぁ。素直に読んだら、このオーバーロードで AnySequence でラップする手間を減らしてあげるよってことな気も。

でも実装見る限りは、ラップしてあげますよというよりはデフォルト実装がある、というように見える

便利だからそのデフォルト実装生やしてあげますよってことじゃないですか？

8:20 AM

「 prefix の結果を AnySequence で受け取りたいときもあるでしょう？オーバーロードを作っておいてあげますよ。」ってことかなぁと。

8:21 AM

その結果、類似した型を返す prefix が二つできて曖昧になってしまったんだったらひどい話・・・

これSwiftの挙動を踏まえて考えると、SubSequence宣言しなかったらtypealias Sequence=AnySequence<Iterator.Element>に推論される気がする (edited)

8:23 AM

あーー

8:23 AM

されないか

↓であいまいになっちゃうの流石に辛い気が。でもこの prefix をなくすより型推論の優先順位をしっかり決めて、↓の prefix が ArraySlice を返すようにできたらいいのかな。 [""].prefix(3).map { $0 }

extension Sequence where SubSequence=AnySequence<Iterator.Element> これを書くとそうなる

8:23 AM

それを避けるためのワークアラウンドなのかしら

CollectionはSubSequenceを作れるsubscriptがあるけど、Sequenceには無いからAnySequenceなのでは。 (edited)

@omochimetaru 単純に prefix だけだと ArraySlice を返す方が優先されてるけど、 map が後ろにつながることで、 ArraySlice を返す prefix と AnySequence を返す prefix の優先順位が同格化されちゃってるんだと思います。 map につながりうるもの、みたいな。

8:26 AM

@omochimetaru map の後ろに prefix だったら map の時点で戻り値が [String] だから、 b.prefix(3) が解決できるのと同じなので問題なし。

8:27 AM

@norio_nomura デフォルト実装は AnySequence 版しか作れないから、ってことですか？

そそ。

extensionでassoctypeを具体型で縛って具体型を返り値に持つfunctionのデフォルト実装を書くと

8:29 AM

暗黙のうちにassoctype自体がデフォルト型を持ってしまうバグ?があって

うーん、でも結局 Sequence の具象型の側で↓は実装しないといけないですよね？デフォルト実装のうまみがあまりない気が・・・。 func prefix(_ maxLength: Int) -> Self.SubSequence

それを避けるためなのでは?という邪推

ふーむ

Sequecneの具象型でprefix定義しなくても良くないですか？

extension Sequence where SubSequence==AnySequence<Self.Iterator.Element> { ... } // これと protocol Sequence { associatedtype SubSequence = AnySequence<Iterator.Element> // これは今できないけど、仮にできたとして、等価になる。 }

@t.ae なんででしょう？

https://github.com/t-ae/ndarray/blob/master/Sources/Sequence.swift 最近書いたのですけどこれだけでAnySequenceが返るprefixが使えて

t-ae/ndarray

ndarray - Float NDArray library accelerated with Accelerate Framework

8:33 AM

んーでもちがうな

@t.ae Sequence 自体が↓を持ってるんじゃないの？ func prefix(_ maxLength: Int) -> Self.SubSequence

補完でそっちでないんでそれがAnySequenceので実装されてるのかと思ったんですがそもそもSubsequenceの型が違いますよね……

これがそのまま動くのだとしたら、SubSequenceはAnySequenceだと推論されてると思う

ああそうか、そうですね　完全に間違ってました

8:35 AM

Subsequenceを指定するかどうかで変わるのか

はい。 Array なら SubSequence が ArraySlice なので ArraySlice を返す prefix の実装が必要になります。

この挙動を避けるために、まどろっこしい書き方してるのかなと思ったけど避けれてないならさっきの憶測は関係なさそう

8:36 AM

しかし、明示しなくてもassoctypeのデフォルト型の振る舞いが出現するのはバグっぽい

Sequence準拠にprefix実装なんて必要ないですよね。

 /// Returns a subsequence, up to the specified maximum length, containing /// the initial elements of the sequence. /// /// If the maximum length exceeds the number of elements in the sequence, /// the result contains all the elements in the sequence. /// /// let numbers = [1, 2, 3, 4, 5] /// print(numbers.prefix(2)) /// // Prints "[1, 2]" /// print(numbers.prefix(10)) /// // Prints "[1, 2, 3, 4, 5]" /// /// - Parameter maxLength: The maximum number of elements to return. /// `maxLength` must be greater than or equal to zero. /// - Returns: A subsequence starting at the beginning of this sequence /// with at most `maxLength` elements. public func prefix(_ maxLength: Int) -> Self.SubSequence

8:38 AM

ある

デフォルト実装で済むから。 https://github.com/apple/swift/blame/swift-3.1.1-RELEASE/stdlib/public/core/Sequence.swift#L281-L317

swift - The Swift Programming Language

SubSequenceのデフォルト型としてAnySequenceが宣言されていないのに、デフォルト型として振る舞うのは変じゃないですか?

SubSequence が定まらないからデフォルト実装できなくないですか？

8:40 AM

あー、そういうことか。

/// Conforming to the Sequence Protocol /// =================================== /// /// Making your own custom types conform to `Sequence` enables many useful /// operations, like `for`-`in` looping and the `contains` method, without /// much effort. To add `Sequence` conformance to your own custom type, add a /// `makeIterator()` method that returns an iterator. /// /// Alternatively, if your type can act as its own iterator, implementing the /// requirements of the `IteratorProtocol` protocol and declaring conformance /// to both `Sequence` and `IteratorProtocol` are sufficient.

SubSequence が AnySequence だった場合に

普遍的なSequenceのextensionにAnySequenceが生えてるなら

8:41 AM

宣言なしならそれが推論されるのはまあわかる

デフォルト実装が不要になる？

/// Here's a definition of a `Countdown` sequence that serves as its own /// iterator. The `makeIterator()` method is provided as a default /// implementation. /// /// struct Countdown: Sequence, IteratorProtocol { /// var count: Int /// /// mutating func next() -> Int? { /// if count == 0 { /// return nil /// } else { /// defer { count -= 1 } /// return count /// } /// } /// } /// /// let threeToGo = Countdown(count: 3) /// for i in threeToGo { /// print(i) /// } /// // Prints "3" /// // Prints "2" /// // Prints "1"

条件付きextensionに生えてるなら、鶏卵問題が発生しているので違和感が激しい

なるほどー。 extension のデフォルト実装によって暗黙的に SubSequnce が AnySequence で埋められるのか。

8:42 AM

それによって makeIterator さえ実装すればカスタム Sequence が作れると。

普遍的なのに生えてるとしてもそこでSubsequenceは使えるのでAnySequenceなのはおかしいですよね？

さっきのだとSequenceの条件があってはじめて、prefixが生えてませんか?

8:43 AM

protocol A { associatedtype B func hoge(arg: B) } class C: A { func hoge(arg: String) { } }

8:44 AM

条件なしなら、これが通る理由をそのまま適用できる

鶏卵的ですが、 AnySequence はそれを満たすから SubSequence が AnySequence なら OK ってことじゃないですか？

AnySequenceならそれを満たせるから、それで初めて、SubSequenceがAnySequenceだと理解できるはずで、

8:45 AM

条件付きに関して言うとAnySequenceが無から湧いていてやばい

8:45 AM

えーっと

普遍的に生えてるのが、SubSequenceが未指定だとそれを埋めるってことになるんですかね

https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md これを読んだのですがよくわからなかかった。

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

なんか、今手元に100万円あったら将来的に1億円になることがわかっている株があるけど、未来の1億円から100万円借りてその株を買う的な気持ち悪さがある・・・。

struct Countdown: Sequence, IteratorProtocol { var count: Int mutating func next() -> Int? { if count == 0 { return nil } else { defer { count -= 1 } return count } } } let s = Countdown(count: 10).prefix(3) // AnySequence<Int>

みんなの言ってる事がよくわからない

protocol A { associatedtype B func hoge(arg: B) } extension A where B == Void { func hoge(arg: Void) { // こっちはB無しでVoidが推論されるが } } extension A where B == Void { func hoge(arg: B) { // こっちはB無しだとコンパイルFail } }

こういう挙動もあって、僕の中ではバグ説が非常に高い

8:47 AM

で、宣言なしAnySequenceの挙動は、どうも、これに準拠している気がしていて

@omochimetaru SubSequence が AnySequence だったらさっきの extension の条件を満たせて prefix を実装したことになるんだけど、そのためには prefix の戻り値から SubSequence が AnySequence であることを推測しないといけない気がしてる。

ふむふむ

8:50 AM

func f<X: Sequence>(x: X) { print(x.prefix(3)) }

8:50 AM

単純にこれがコンパイルできるのは

それは単に Sequence に prefix があるからでは。

protocol定義本体に、 AnySequenceを返るfuncがあるからで

8:51 AM

問題は、

8:51 AM

事前定義済みのその実装としては

8:51 AM

extension Sequence where Self.SubSequence : Sequence, Self.SubSequence.SubSequence == Self.SubSequence, Self.SubSequence.Iterator.Element == Self.Iterator.Element {

8:51 AM

っていう条件付きのやつしかないのに

8:52 AM

ユーザー定義Sequenceについて、これが呼ばれるようになる理由が謎ってこと？ (edited)

いや

8:52 AM

protocol定義本体はSubSequenceでしか無いんじゃない、別にそれでもprintは通る

ああそうか。本体に定義されてるのはSubSeuqneceが返るやつか。

protocol定義本体に、 AnySequenceを返るfuncがあるからで

それはなくない？本体にあるのは↓じゃない？ func prefix(_ maxLength: Int) -> Self.SubSequence

条件付きextension以下にAnySequenceが書かれているが、一体何を材料に、そのSubSequenceをAnySeuqenceと断定できるのか、という

ああ、入れ違いに。

えーっと、そうすると何が不思議なんですっけ？

8:54 AM

protocolを満たす時にSubSequenceがAnySequenceで埋まればそのextensionのバージョンが呼べるってだけじゃないのか

なので、 prefix の実装を持ってくるためには

AnySequenceで埋まって無さそうなのに、そのバージョンが呼ばれてる、事例が観察できたの？

SubSequence == SubSequence.SubSequence を満たさないといけないんだけど

8:54 AM

SubSequence が AnySequence ならその条件を満たせるけど

はい

SubSequence が AnySequence だと推論するためには prefix の戻り値が AnySequence であることが必要で

単純にprefixじゃないほかのところからAnySequenceが推定されているのでは？

その prefix を手に入れるためには SubSequence.SubSequence == SubSequence じゃないといけない

全体確かめないと断定できなそうですが

↑に例示したコードで十分鶏卵型推論が再現可能 (edited)

@t.ae でも他のメソッドでも AnySequence 返すためには AnySequence 作らないといけなくて、そのためには結局 SubSequence.SubSequnece == SubSequence が必要なのでは？ (edited)

関係ないところで、SubSequenceを返す関数がAnySequenceのデフォルト実装が無制限に書いてあるのがあって

8:57 AM

それが伝播していれば不自然は無い、という話

8:57 AM

でも、

protocol A { associatedtype B func hoge(arg: B) } extension A where B == Void { func hoge(arg: Void) { // こっちはB無しでVoidが推論されるが } }

これで再現可能なんで

8:57 AM

どうにも

@koher すいません、まだわからない点がある

extension Sequence { /// Returns a subsequence, up to the given maximum length, containing the /// final elements of the sequence. /// /// The sequence must be finite. If the maximum length exceeds the number of /// elements in the sequence, the result contains all the elements in the /// sequence. /// /// let numbers = [1, 2, 3, 4, 5] /// print(numbers.suffix(2)) /// // Prints "[4, 5]" /// print(numbers.suffix(10)) /// // Prints "[1, 2, 3, 4, 5]" /// /// - Parameter maxLength: The maximum number of elements to return. The /// value of `maxLength` must be greater than or equal to zero. /// - Complexity: O(*n*), where *n* is the length of the sequence. public func suffix(_ maxLength: Int) -> AnySequence<Self.Iterator.Element> }

1

@tarunon なるほどー・

SubSequence.SubSequence == SubseqenceならそのAnySequenceを返すextensionが有効化するのはわかったけど

suffixは無制限なのか、じゃあこれが伝播できますね

その、有効化したオーバーロードによって、 Sequence protocolが満たされる事自体は

8:58 AM

どうやって確認するの

この extension はデフォルト実装はないの？？ suffix は原理上無理か。

Sequenceを実装する型があるとき、それはSubSequenceを何かしら決めてるわけで

@koher extensionなんで実装持ちですよこれは

8:59 AM

stdlibにソースがあるはず

で、その何かしら決まったSubSequenceにたいして、SubSequence.SubSequence == SubSequence が成り立っているなら

8:59 AM

そのAnySequenceを返す版も使えるようになる、protocol Sequenceの本体定義にあったfunc prefixとは関係ない

9:00 AM

って可能性は？

あー、別に自分の SubSequence を使わなくても AnySequence 作れるのか。

無宣言SequenceがSubSequence==AnySequenceで推論されるのは、suffixの実装から伝播してる、でFAな気がする

ん？ makeIterator 使うからやっぱ無理？

9:01 AM

なんで prefix のデフォルト実装には SubSequence.SubSequence == SubSequence が必要だったのに、 suffix だとその制約がなくてもデフォルト実装が書けるんですか？

AnySequenceは、makeIteratorをラップするクロージャで実装できるから、本当のSubSequenceが何かとは関係なく、いろんなケースで作れるのでは。

AnyIteratorに包めば良さそう

@omochimetaru その AnySequence にイニシャライザに渡せる Sequence の条件が SubSequence.SubSequence == SubSequence

@t.ae さんがあげてる extension Sequence { public func suffix(_ maxLength: Int) -> AnySequence<Iterator.Element> { } } により SubSequence == AnySequence<Iterator.Element> が推測されそうだ。 (edited)

prefix は

public func prefix(_ maxLength: Int) -> AnySequence<Iterator.Element> { _precondition(maxLength >= 0, "Can't take a prefix of negative length from a sequence") if maxLength == 0 { return AnySequence(EmptyCollection<Iterator.Element>()) } return AnySequence( _PrefixSequence(_iterator: makeIterator(), maxLength: maxLength)) }

の makeIterator を AnySequence に渡すために SubSequence.SubSequence == SubSequence が必要で

9:04 AM

いや違う

9:04 AM

_PrefixSequence に渡すのに必要なのか (edited)

9:05 AM

うーん、まあ別にイテレートして取り出して適当な Sequence に入れられるんだから

9:05 AM

制約がなくても実装自体は普通に可能か。

これが制約がガバで漏れ出てるのか、意図してるのかはよくわかんないですね

ってか、 suffix だと一度全部読み出してみないと終わったかわからないから

9:07 AM

普通に Array とかに入れてそれを AnySequence にラップして返してるとかかな。

9:07 AM

とすると、本当ならそのまま Array で返してもいいのにわざわざ AnySequence としてるということは。「ガバで漏れ出てる」んじゃなくて「意図してる」っぽい気がする。

struct MyIterator<T> : IteratorProtocol { mutating func next() -> T? { return nil } } struct MySequence<T> : Sequence { func makeIterator() -> MyIterator<T> { return MyIterator() } } print(MySequence<Int>().prefix(2)) // AnySequence<Int>(_box: Swift._SequenceBox<Swift._PrefixSequence<__lldb_expr_68.MyIterator<Swift.Int>>>)

9:09 AM

とりあえず、何も書かなくてもAnySequenceを返す版が有効化してることは確かめられた

suffix は？

9:10 AM

_PrefixSequence の部分が suffix でどうなるか見たい (edited)

print(MySequence<Int>().prefix(2)) print(MySequence<Int>().suffix(2)) AnySequence<Int>(_box: Swift._SequenceBox<Swift._PrefixSequence<__lldb_expr_77.MyIterator<Swift.Int>>>) AnySequence<Int>(_box: Swift._SequenceBox<Swift.Array<Swift.Int>>)

お、やっぱ Array だ。

とりあえずこの実験で、AnySequenceのインスタンスが出てきてるってことは、さっきの SubSequence.SubSequence == SubSequence の条件のやつが有効化して、その有効化によって SubSequence == AnySequenceが確定して、 protocol Seuqnceが満たされるっていう　ループが起きたってこと？ (edited)

上でも書かれてる通り、 sufixはwhereなしextensionだよ。

ループではないけど、そう

9:12 AM

ただし

9:12 AM

そこら辺はバグがあるので、仮にsufixがwhereなしでも、同じムーブは起きる

この挙動が不思議だねって話題か。

9:12 AM

仮じゃなくてsuffixはwhere無しらしい

バグがある、は言いすぎた。バグと思わしき挙動があって

9:12 AM

いや、僕の言ってるのは、もし仮に、sufixが縛られてても

9:13 AM

全く同じ動きになるよという話

@t.ae さんが見つけた extension Sequence { public func suffix(_ maxLength: Int) -> AnySequence<Iterator.Element> { } } これで決定だと思うのだけど。

Sequenceだといろいろ生えててどこから来てるか分からないので最小で書いてみたほうがいい感

@norio_nomura とりあえず、prefixについては、そのようなシンプルなやつは無いんですよね？

suffix が where なし extension だから、そこから suffix の他の実装がなければ SubSequence が AnySequence であることが推論されて、その結果 prefix 等の extension の制約 SubSequence.SubSequence == SubSequence も満たして、 prefix 等も実装してることになると。

SubSequence == AnySequence<Iterator.Element> の仮定があればprefixも呼べるよね。

その仮定がどこから来てるかが謎って話ですよね

public func suffix(_ maxLength: Int) -> AnySequence<Iterator.Element> これ

あ！そういう話？！

Sequenceはそいつが原因ですね

9:16 AM

それはそう

@norio_nomura はい、それで決定だと思います。 prefix の実装には SubSequence.SubSequence == SubSequence を必要としたのに suffix でそれが必要ないのが不思議でしたが、前から読めばいい prefix と違って、どこで終わるかわからないから最後まで一度読み出さないといけない suffix だと _PrefixSequence みたいなのにラップしなくても Array に入れりゃいいので別に SubSequence.SubSequence == SubSequence を満たさなくても効率の良いデフォルト実装ができる。 (edited)

@tarunon さんの言うバグは最小のでないと断言しづらいですね。

見逃していた、そういう話しか

9:18 AM

条件なしのextension Sequenceに、func suffixがあって、それが AnySequenceを返しているから、それによってSubSequenceがAnySequenceに決まって、それによってprefixのほうのwhereが通る

そっちはそう、そのムーブは納得がいく

このムーブの発動条件はなんなんだ

suffixの実装

9:19 AM

普遍的なextension Sequence { func suffix -> AnySequence } の存在が、

Sequenceを実装してる型を定義する時に、その型にsuffixを定義すればそれになって、定義しなかった場合に、普遍的なextension Sequenceの方にフォールバック？

structなどの実装におけるfuncを定義してassoctypeを縛る挙動と等価

なるほど

9:21 AM

上でたるのんがあげてるVoidとか絡んだ亜空間推論ほどの事は起きてないって事ですかね

もしかして、↓の Filtered もこんな感じでデフォルトが決まるようになるのかな？ https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md

https://gist.github.com/omochi/53deae52ce3622fad56f90cba6f5e746

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

ですね

よかった、亜空間推論が仕様だったらどうしようかと思った

これまでとの整合性を考えると Filtered のデフォルトは [Element] ？ (edited)

Add a Filtered associated type to Sequence,

9:22 AM

これ多分こっちもAnySequenceでは

Selfじゃないのかね

あーArrayでいいのか

でもこれまでデフォルト実装で filter ついてきて、その戻り値は [Element] でしたよね？

無理な場合があるのか

Selfはinitできないと無理な気がする

9:23 AM

Sequenceはinitを条件に持ってないから辛そう

たしかに。そうだね

@omochimetaru Self はデフォルト実装ないなら可能だけど、現行の Swift と整合性がなくなっちゃう。 Set とか ArraySlice とかの filter も [Element] 返すし。

Arrayの場合と、LazySequence<Self>がほしい場合があるのかな

@koher ああ、Arrayに寄っちゃう挙動とも整合取れないのか

うん。

SE-0014 が実装されるまでは prefix も where なし extension だったから、今日のきっかけの問題は両方で起きていた可能性があったのかな。 let a = [""].map { $0 }.prefix(3) let b = [""].prefix(3).map { $0 } // Ambiguous use of 'prefix' (edited)

このfilter とか map とか、前から難しい問題だと思ってて、パフォーマンス考えて lazy にしたい場合と、利便性考えて [Element] 返したい場合があって、 Haskell みたいな遅延評価言語だとそのあたり全部 lazy かつ標準的なコレクションで統一されるのはいいなぁと思う。

let b = [""].suffix(3).map { $0 } これは通る

9:28 AM

whereの制約見直さないと

@t.ae 型推論の優先順位のルールがおかしいっぽいね。

9:29 AM

これおもしろいな。

基本的にwhere句の制約は、制約が厳しい方が優先されるはず

@koher Haskellのはいいですね。mapとか一通りArrayで返ってくるのが気になる

 1> [2, 3, 5].suffix(2).map { $0 } $R0: [Int] = 2 values { [0] = 3 [1] = 5 } 2> [2, 3, 5].prefix(2).map { $0 } error: repl.swift:2:1: error: ambiguous use of 'prefix' [2, 3, 5].prefix(2).map { $0 } ^

↑ Swift のヤバさをよく表してる。 (edited)

ArraySliceとAnySequenceのwhere句の制限が同じ重さだから、優先順位がつけられない

9:30 AM

suffixは宣言が無だから常にArraySliceが優先でOKっぽい

@tarunon いや、違うんですよ。

マジ

↓これはいけるんです。この場合は ArraySlice 優先。 1> [""].prefix(3) $R0: ArraySlice<String> = 1 value { [0] = "" }

あー

後ろにmap が付くと同格になってあいまいになる。

解釈がむずい

なんか、複雑な CSS セレクタ書いてるときに、どっちが優先されるかわからなくなるのと同じような気分になる。

9:33 AM

さっきから何かに似てると思ってたけどそれだ。

最小コード再現しようと思ったけどできないな

SE-0014 以前はどっちも普通に動いた。

sh-session $ /Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2016-01-06-a.xctoolchain/usr/bin/swift Welcome to Apple Swift version 2.2-dev (LLVM 3ebdbb2c7e, Clang f66c5bb67b, Swift 54dcd16759). Type :help for assistance. 1> let a = [""].map { $0 }.prefix(3) 2. let b = [""].prefix(3).map { $0 } // Ambiguous use of 'prefix' a: ArraySlice<String> = 1 value { [0] = "" } b: [String] = 1 value { [0] = "" }

(edited)

2

9:39 AM

2.2の頃は SE-0014 関係なく普通に動いていた様にも見える。

swift-akuukan-ext.swift

9:39 AM

普遍的エクステンションと亜空間推論の同時定義をいろいろやってみた。

9:39 AM

いみふめい

そうそう

9:40 AM

型推論優先ルール、束縛条件が強いほうが強いに則って、亜空間推論が普遍推論より優先されて

9:40 AM

超面白い

9:41 AM

返り値引数をassoctypeのalias名のまま書くと、亜空間推論は起きない

あー普遍的なのじゃなくても流れてくるんですね

あ〜　AT1 で書くっていう選択肢もあるのかそうか

普遍より亜空間が強いのは、制約が強いから普通じゃない？

いや、それはそう

9:43 AM

そうなんですが、亜空間推論が成り立つのがただでさえおかしいのに

9:43 AM

普遍が殺されるのは輪をかけておもしろい

なんかこんなわけのわからないやつのほうが強くて良いのかという違和感がある

亜空間推論は気持ち悪いですね。

9:44 AM

ああ、そういうことか。 < 亜空間推論が成り立つのがただでさえおかしいのに普遍が殺されるのは輪をかけておもしろい

print() に引きずられるのでは？

protocol A { associatedtype B = String func hello() -> B } extension A where B == Int { func hello() -> Int { return 1 } } class C: A { }

もっと面白いの

そうおもってhogeを切っておいたんですけどだめかな

デフォルトの宣言が亜空間推論にかき消される

これは String の場合のデフォルト実装がないからじゃないですか？

そうです、コンパイルエラーになって欲しいところですが…

指定が無い場合任意型になって任意のwhereを満たせると考えると分かりそうな気がする

さすがに String の場合のデフォルト実装があったら String が勝ちますよね？

protocol A { associatedtype B = String func hello() -> B } extension A where B == String { func hello() -> B { return "hello" } } extension A where B == Int { func hello() -> Int { return 1 } } class C: A { } C().hello()

9:46 AM

C().hello()の型はどっちでしょう

え？これ String じゃないんですか？

宣言が`hello() -> B

あー、そこが違うのか

になってるのがポイントで、これはIntが勝ちます

9:47 AM

BをStringにすると、引き分けのコンパイルエラー

9:47 AM

String優先してくれ頼む

ｗｗｗｗ

え、デフォルト設定してるのに優先されない？

9:47 AM

ひどい・・・

9:48 AM

associatedtype のデフォルトは闇が深そうだ

えっとじゃあ、ベストプラクティスとして

9:48 AM

extensionを実装する時の型名はエイリアス名のままにしておくのがよい？

間違いなく

9:48 AM

それしないとどこから亜空間推論発生して型が崩壊するかわからない

そうだよね・・・

なるほどー

面白い。

10:03 AM

@omochimetaru さんの struct MagicDog : MagicProtocol {} のgistも全部 func getAT1Value() -> AT1 と書くと結果が変わる。

AT1にすると優先されなくなりますね。

10:04 AM

そっちの挙動が僕がなんとなくそういう言語仕様だろうと思ってる方。

10:04 AM

亜空間のほうはバグなのでは？？？という気持ちが

10:04 AM

ある

亜空間は流石にバグだと思う

（しかしどちらも根拠レス）

鶏卵問題解決できるのはどう考えても

10:05 AM

どう考えてもおかしい

でも、亜空間同士の衝突は起きるから

10:05 AM

ちゃんと候補を列挙して、絞りこめるならそれを採用するっていう

10:05 AM

ロジックがちゃんと書いてある感じがして

10:05 AM

意図を感じる

うーんそれは

10:05 AM

単純に優先順位同列の推論が衝突したときの

10:06 AM

エラーがそのまま出てる気がする、別にこれ専用に意図したものでは無いんじゃないかな

じゃあ、AT1と書くか Int と書くかで、挙動が変わるのも、意図せずそうなってしまっただけ？ (edited)

その2つで挙動の差があるのはもうバグとしか思えない

エイリアスを使わなかった場合に where が1個余分に評価されている様な感じ。

Intって手書きしてる事で推論上の型変数がPolyTypeからConcreteTypeになっていて、解決済みの採用候補に間違ってぶちこまれるみたいな (edited)

where句を無視してfunctionをあると仮定、その後にwhere句を採用して枝刈りみたいな (edited)

10:07 AM

そういう動きなのでは?とか想像してる

protocol MagicProtocol { associatedtype AT1; func getAT1Value() -> AT1 } extension MagicProtocol { func getAT1Value() -> Array<Int> { return [1, 2, 3] } } extension MagicProtocol where AT1 == String { func getAT1Value() -> AT1 { return "AT1 is String" } } extension MagicProtocol where AT1 == Int { func getAT1Value() -> AT1 { return 32 } } struct MagicDog : MagicProtocol {} let dog = MagicDog().getAT1Value() // [1, 2, 3]

まともだ

ですね

これも

rotocol A { associatedtype B = String func hello() -> B } extension A where B == String { func hello() -> B { return "hello" } } extension A where B == Int { func hello() -> B { return 1 } } class C: A {} C().hello() // "hello"

そう

10:27 AM

全部assoctypeで書いておけば平和です

https://github.com/swift-script/swift-script/pull/23

Add SwiftKotlin & improve Parse by inamiy · Pull Request #23 · swift-script/swift-script

Hi

I added Kotlin support for this project which is inspired from https://github.com/angelolloqui/SwiftKotlin and obviously, JavaプログラマのためのKotlin入門 - Qiita . Sorry for pushing a large commit, but ...

12:49 PM

https://speakerdeck.com/inamiy/mang-siiswiftenziniafalsetamefalsekotlinru-men

Yasuhiro Inami

忙しいSwiftエンジニアのためのKotlin入門

Swift愛好会 vol19 (May 23, 2017) https://love-swift.connpass.com/event/55236/ Library: https://github.com/swift-script/swift-script Pull Request: https://github.com/swift-script/swift-script/pull/23

12:49 PM

いなみさん流石のムーブ

この間ちゃんとしたKotlin触ったけどContextが鬼門だったなぁ

Context？Androidの？

そう

それはKotlin関係ないやんけ

ww

鬼門なのはそれはそう・・・

12:52 PM

あれ一応意味があってすごくて

12:52 PM

同じプロセスの中で別のアプリからキックされたactivityが別画面として共存できるんだよね

12:52 PM

でもなんかいろんなテクニックとかアンチパターンとかいっぱいあって大変

やばそう

12:57 PM

いろんなテクニックとかアンチパターンあるのはUIKitも一緒やな

12:57 PM

やっぱりそれを生業にしないと真の理解は得られなさそうだ

SequenceのAnySequenceを返すメソッドをArrayへ変える実験らしい https://github.com/apple/swift/pull/9639

[stdlib][WIP perf experiment] Replace AnySequence with Array in default Sequence methods by palimondo · Pull Request #9639 · apple/swift

This is an experiment to confirm that replacing AnySequence in default methods on Sequence with Array improves performance. This is a supporting argument to SE-NNNN Sequence Cleanup. At the moment,...

@norio_nomura タイムリーですね

AnySeqと違って溜め込むから単純に性能上がるとか言えるのか、、、？

AnySeqだと動的ディスパッチで遅いとかもありますね

@koher 上のいなみさんのやつみました？

中身見てないです。

スイフトスクリプトにプルリクが来てますよ

Array にすると prefix が lazy にできないから

12:39 AM

ユースケース次第でパフォーマンス下がりそう。

ですよねえ。

その場合はSubSequenceをちゃんと指定して対処するんじゃないですか？

>The lazy computation of prefix and dropFirst methods will be moved to LazySequence.

12:42 AM

とのこと

やっぱりSubSequence型が定義されてるのに、普遍的にAnySequence(またはArray)が生えてるのは違和感があるなぁ

where SubSequence == AnySequence<Element> だったらいいですよね。 (edited)

それなら全く違和感はないですね、平和

そもそもSubSequenceってSequenceにほんとうに必要なものなんですかね？ ArrayとArraySliceはパフォーマンス上分かるけどだいたいがSubSequence = Selfで済む気がする。

Self はダメじゃない？

ArrayとArraySliceはパフォーマンス上分かるけどだいたいが

もうこれで必要性が十分確立するとおもう。

Selfだとinit持ってないと実装が出来ないとか、色々困ったことになりそう

だいたいの場合についてはデフォルト実装があれば困らないし。

2:24 AM

特定の場合について高速になるために用意するっていうのは合理的

@omochimetaru そこをSequence中じゃなくて外部に持っていけなかったのかなと

例の constraint の条件が悪いのであって、 SubSequence == AnySequence<Element> なら問題ない気が。

@t.ae そうするとprotocolとしてのうま味がなくなる (edited)

ただ、 Sequence から Iterable を剥がして、 Iterable は純粋に makeIterator のみを持つでもいい気もしてる。

それはあり得ますね

ただ iterable にしたいだけなのに、変な map とか filter とかいっぱいついてきて鬱陶しいんですよね〜

2:26 AM

特に map は Mapped がないから、戻り値 Array 版が強制で追加されるの嫌・・・

Mappedできるとしても最短で5以降ですよね、言語機能が足りてないから

ですね。

外に出すとどうなるかはパッとわからんなあ・・・

Core Team も Higher-kinded type の優先度低そうな感じだったし。

Mappedが出来れば、SequenceとOptionalの共通のベース型としてモナド型定義できないかな？と思ったけど現状Sequenceがinitできないから厳密な定義からは逸れてしまうか

昨日koherとその話をしたんだけど

2:32 AM

同じモナドを返すってところがうまくかけないんだよね

@omochimetaru @tarunon さんはそのことはわかってて

2:33 AM

Higher-kinded type が必要なことがわかってて、それが導入されるなら早くても Swift 5 だろうなぁと

2:33 AM

で、それが導入されたらモナド作れそうってことだと思います。

ですです

ふむふむ

昨日の謎推論、ざっとbugs.swift見たけど報告上がってなさそうだな、あとで報告上げるかー (edited)

うーん、なんとなくニュアンスの違いとして、挙動が違うのも理解できる気もするんですけどね。

しかし、型が確定する材料が足りてないのに確定してしまうのはおかしい(はず)なので

2:59 AM

とりあえず報告はしていいと思いました

亜空間推論の方ですか？

@tarunon どこ調べたらいいかわかんないしバグとして上げて回答貰えればそれはそれでという気持ちがある（迷惑かもしれないけど。 (edited)

@koher ですです

https://bugs.swift.org/browse/SR-4985 ざっくり、完結に、報告 done

6

$ xcrun --toolchain org.swift.4020170523a swift Welcome to Apple Swift version 4.0-dev (LLVM 351dc0fd49, Clang 9cf11ef2d0, Swift 3ea9a3bac7). Type :help for assistance. 1> struct S {} 2. let mapped = zip([S()], [""]).map { 3. ((s, string)) -> S in s 4. } error: repl.swift:3:6: error: closure tuple parameter does not support destructuring ((s, string)) -> S in s ^~~~~~~~~~~ arg0 let (s, string) = arg0;

Swift 4のタプル周りの変更、なかなか面倒だ。 (edited)

TupleとArgumentsの差が明確になる君

1:37 PM

これ、(s,string)じゃなくてtupleとして引数を取れ、と言うことですか？

そう見えますね。元々ネストしたタプルとかクロージャ式で destructure できなかったですし、それをサポートしてほしいんですよねぇ。

1:47 PM

何が嫌って、クロージャ式の冒頭で一度 destructure を入れると single expression にならなくなって、 return を書かないといけなくなったりするところですね。一つの式で同じプロパティに複数回アクセスするときに、タプルとして受けて foo.bar + (foo.baz / foo.bar) みたいに書くのも面倒ですし。

返り値は無名のタプルで引数でラベリングするサボり術が死んだ

Dictionaryのmapとかで受け取るタプルにkey,valueってラベルがついてるのが便利だと見直されるかも。

2:03 PM

$0.keyと$0.0のどちらでもいけるし。

ラベル付けて返り値作って、$0使うのが主流になるか、それはそれで良いかしら。

なるほど、ここでラベル・・・

switch tuple { case let (a, b): break default: break } こういうのもできなくなるんでしょうか？destructuring assignment とは違うかな？

上のエラー見る限りはあくまでクロージャ引数でのタプルの destructuring ができないようにみえるけどどうなんだろう…

ああ、たしかにclosure tuple parameter ~って書いてますね

swift-3.1-DEVELOPMENT-SNAPSHOT も出てる。

昨日の @norio_nomura さんの話、タイムリーに関連する話題が Swift Evolution で流れてる。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036773.html

9:20 AM

Apple の core lib チームの人（？）が SE-0110 に関連してこんな PR もらったんだけど、ほんとにこの変更（ SE-0110 ）いるの？って言ってる。

今それを言うか

9:33 AM

swift-evolution のプロセスはうまくいっていない気がするなあ。

MLでやってるからでは・・・

ほんとそれ

適したサービスを使えば、タグフォローして通知とか、ホットなスレッドとか、興味ありそうな人を巻き込んだり、いろいろできるわけで

9:37 AM

いまはかなり能動的に動かないとリーチできないから、結果的にスルーしちゃって、後で直面してから受動的に反応することになってると思う

iOS関連SlackでAppleの人が「Slack使いたいけど社内にインスタンスを立てられないと使えない」的なことを言ってたのを見かけたことがあるから、完全に外部依存のサービスは使えないのだろうなあ。 (追記: swift-evolutionとは関係ない文脈での言) (edited)

マストドンかな？

1

w

なるほど

WWDCで何か発表があるといいなあ。

「Apple製SNS、ここでなんでもできる！swift-evolutionもここでやるぜ」とか

いや、そこまで期待してないw

スラック買収しよう

10:04 AM

解決

あいや「Slack使いたい」ってのはswift-evolutionとは関係ない文脈でした。

なる

昨日の SE-0110 の件、 Core Team の Joe Groff がここで話してたのと同じこと言ってる。

Furthermore, this probably comes up most commonly with dictionaries, since they're a sequence of tuples. The element tuple for dictionaries has element labels (key: Key, value: Value), so instead of writing `{ tuple in let (key, value) = tuple; f(key, value) }`, you could use the implicit argument and write `{ f($0.key, $0.value) }`.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036788.html

そうですよね、そんな気がしてた

4:30 AM

ただどうしてもtupleを変数として宣言しないと辛いケースがままあって、そう言うときにvalとかtとかpairとかそういう変数名を付けざるを得ないのはちょい辛い

それに対する Nate Cook さんのリプライ。

Dictionaries are definitely a common case for this, but zipped sequences and enumerated() sequences are also very common, and don't have labels attached.

4:33 AM

外国人、「さん」を付けるか迷う・・・。 Chris Lattner とか Steve Jobs に「さん」を付けるのは変だけど、 try! Swift のスピーカーとか、普通に会って話すかもしれない人に「さん」を付けないのも変だし、境界があいまい・・・。

'@'は敬称ですよ

4:34 AM

と言うことにしておくと楽

ｗ

この解釈あるとめちゃくちゃ楽なんで流行って欲しい

4:35 AM

ので、意図的に@を使ってさん付けしないようにしている、でも端から見たら失礼な奴かなぁ

そうですね。でも @ ついてても「さん」付けちゃうなぁｗ

4:37 AM

あ、「そうですね」は「流行って欲しい」に対してです

おもちさんに誘われて参加しました。よろしくお願いします。

おお、 @giginet さん、よろしくお願いします。

失礼な奴と思われてもこれが正義だと信じてるんで！僕は自分の信念に従って(ry

4:39 AM

海外はMrとかMsとか面倒くさすぎるからsan楽で超良いねって聞いたけど、githubとか見てると@で済んでる場合が多い感

ビジネスとかだと面倒かもだけど、 GitHub や Twitter は @ で済みそうですね。

よろしくおねがいしますー

4:41 AM

チャットとかでも最近は @ でメンション飛ぶし @ で済ませたいですね…

@slightair よろしくお願いします。 (edited)

4:42 AM

さっきの Nate Cook さんのメールの内、 Chris Lattner への返信の部分。

The only confusion I've ever seen from users is when deconstruction didn't work enough, like if the parameter was (Int, (Int, Int)) and you couldn't destructure the nested tuple.

4:44 AM

普通にクロージャでもタプルを受けられりゃ問題解決なんだよなぁ。 dictionary.forEach { (key, value) in ... } が問題なんであって、 dictionary.forEach { ((key, value)) in ... } はできていいと思うんだけど。

それは出来て欲しいんですが、今もそれ相当の構文は書けなくて辛かった

4:45 AM

Rxでscan書いてるときにありがちですね、タプルがネストして片方をpairとか雑な名前で宣言しちゃう

なので、これまでルーズな構文に頼ってきただけで、ルーズなのが良くないってのと、↑ができないってのと二つの問題があって、ルーズな方だけ封じたから面倒になったってだけな気がする。

4:46 AM

タプルがネストして片方をpairとか雑な名前で宣言しちゃう

これ困りますよねぇ。

4:47 AM

真面目に { fooAndBar in let (foo, bar) = fooAndBar ... } とか書くのも微妙だし。

$0, $1 ... への自動デストラクトなくせばいいと思った。

4:48 AM

let dict: [String:Int] = [:] let ary1 = dict.map { ($0, $1) } let ary2 = dict.map { $0 } たしかにこれはわかりにくいし。

↓これは今回ので禁止されないんですか？ let ary1 = dict.map { ($0, $1) }

禁止されます。

ですよね。

Swift3 の状態から $0, $1 ... への展開だけなくすだけで、いいんじゃないかと。 (edited)

なるほど。

4:51 AM

まあ確かに foo.map { x in ... } と foo.map { (x) in ... } が同じ以上、 dict.map { ((k, v)) in ... } を認めてしまったら dict.map { (k, v) in ... } はそれと同じじゃないのか、ってなるのかな？

4:52 AM

タプルなのか引数なのか区別できない。

それが同じなのはギルティなんで外すのでは?

上の二つは区別されないんじゃないですか？ Swift 4 でも。

え。。。

だって foo.map { (x: Bar) -> Baz in ... } は生きてますよね？

そっちはOKで

4:53 AM

foo.map { x -> Baze in ... } こいつは殺さなきゃいけない

されないと思いますよ。 { x, y in ... } パラメータが括弧で囲まれてなかったら暗黙の括弧がつくというルール

と、思ってた

4:53 AM

Ohhh

元々は関数の引数はタプルと等価だったから、 { (x, y) in ... } の (x, y) がタプルなのか引数なのかという区別はなかったけど、それを区別したから今度は記法として区別できなくなっちゃったのか。 (edited)

4:56 AM

でも、タプルを分解したい場合は必ず {((x, y)) in ... } でいいと思いますけどねぇ・・・。

その場合に、 { ( (x: Int, y: Int) ) in を認めるのかっていう議論がでちゃいますね。 { ( (x, y): (Int, Int) ) in } のほうが正当。

後者だけで良いのでは

なるほど。そもそも現状は関数宣言時の引数のフォーマットを踏襲しているわけで、そこにタプルの分解を持ち込んだときにどういう記法とするのかは議論が必要そうですね。

5:03 AM

{ ( (x: Int, y: Int) ) in ... } にしても { ( (x, y): (Int, Int) ) in ... } にしても関数宣言の記法にない新しいものを追加しようとしてるわけですし。

5:04 AM

↓はできるんだからそれを踏襲すればいいのかな。 let (a, (b, c)) = (2, (3, 5))

5:05 AM

let (a, (b, c)): (Int, (Int, Int)) = (2, (3, 5))

5:05 AM

だからやっぱ後者がいいのかな。

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019578.html とりあえず一年前のラトナーはそれを認める気はないようです。

5:06 AM

クロージャの話ではないけど。

なるほどー。まあでも利用頻度はクロージャ式の方が圧倒的に高そうだから、クロージャ式でも絶対になしかというと微妙なところですね。

5:09 AM

let (a: Int, (b: Float, c: String)) = (2, (3.0, "5")) 的な書き方は、全く別の意味になるのでやっぱりナシですね。

5:09 AM

↑は前話してたやつで、結果は↓。 Int: Int = 2 Float: Double = 3 String: String = "5"

5:10 AM

↑の記法でラベル（ a, b, c ）が付けられてるの意味不明だけど。 (edited)

CHANGELOG より: Type annotations are no longer allowed in patterns and are considered part of the outlying declaration. This means that code previously written as: var (a : Int, b : Float) = foo() needs to be written as: var (a, b) : (Int, Float) = foo() if an explicit type annotation is needed. The former syntax was ambiguous with tuple element labels. (20167393)

これってどの Proposal で決定されたんですか？

Swift2.0 での変更なので、オープンソース前です。

ああ、 2016 年じゃないんですね。後ろが日付じゃなかった・・・。

やっと話題に追いついたｗ

6:27 AM

カッコの話題はスマホからじゃ読めねえ

6:28 AM

そもそも現状は関数宣言時の引数のフォーマットを踏襲しているわけで、そこにタプルの分解を持ち込んだときにどういう記法とするのかは議論が必要

まさにまさに

この間の @rintaro のself書き換えでNib/Stroyboardのinstantiateが書けたけど

やっぱりpropertyとしてletを置けないので価値はそこまで高くない感じ https://github.com/tarunon/Instantiate/pull/20

Instantiatable support init suger syntax by tarunon · Pull Request #20 · tarunon/Instantiate

It's work well, but I think it's a little bit tricky..

8:43 AM

8:44 AM

引用のやり方を覚えていない…

コードの左のところをクリック。

コードの左がわからなかった(´ . .̫ . `)

https://github.com/tarunon/Instantiate/blob/11ff3611af5d97094104d0af60d270e30d5b1acf/InstantiateTests/InstantiateTests.swift#L31-L35

tarunon/Instantiate

Instantiate - Type-safe Interface Builder protocols.

8:49 AM

行番号をクリック。

あいやそっちじゃないw

8:49 AM

それはわかる

8:49 AM

Discordの引用

Discordは引用が無いと思う。

8:51 AM

リプライ2種類あると思ってたらこれは、自分宛てかそうじゃないか、か

ああ、オレンジの線わかりづらいですよね。

@omochimetaru test

8:51 AM

あ〜

Discord の Slack に対するネガティブ要素は引用わかりづらいことなんですよね。

8:52 AM

最近はさっきの ML の引用みたいにコードブロックにすることも・・・。

コードブロック万能説

いや、入れ子になるとダメなので限界があります。

あー

さっきのinitでfunc呼びたい話、static funcなら安全に納得できるかな、と思ってたけどclass funcをSelfで使えないからちょっと辛い

class Cat { let a: Int let b: Int let c: Int init(){ a=1 b=a+1 c=Self.makeC(a: a, b: b)//<-だめ } class func makeC(a: Int, b: Int)->Int { return a+b } } print(Cat().c)

Cat.makeCはクラス名変更があるから嫌ってこと？

オーバーライドできないから、欲求を全て満たせない

typealias ThisClass = Cat とか

11:15 AM

ああ。

type(of: self)

今丁度それ見つけたんですが

11:15 AM

self初期化してないのに通るんですねw

type(of:) は特別ですからねー

11:16 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md これが結局実装されてないから、 Self が使えない。

Implement SE-0068: Expanding Swift Self to class members and value types by joewillsher · Pull Request #3866 · apple/swift

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

まだ4には入って来ないです？

なるほど

4 で実装される気配は今のところないです。 https://github.com/apple/swift/pull/3866 一回頓挫してから気配なし。

What's in this pull request? Implementation start on SE-0068. This does not yet implement allowing Self to refer to the dynamic type in non final classes outside of function signatures, just expan...

ぬぬぬ、そうなんですねorz ありがとうございます

やはりclassは日陰者…

structこそ至高

1

最近Viewもfinal付けて作るようになって、極力classの酷い扱いの被害を受けないように意識して立ち回るようになってしまった

そんなに継承被害があったんですか(　ﾟдﾟ)

protocolのパワーを引き出そうとすればするほど、final classにせざるを得ない…

11:28 AM

UIImage、finalじゃなくて本当に勘弁して欲しい感じなんですがどうするのが正解だろう…

11:28 AM

struct Image作ってラップした方がいいかなぁ

11:31 AM

final class Image: UIImageという天命を得たけどこれは正解か…？はて…

なるほど、final付けることで性質が変わるんですねあんまり意識したことなかったです

protocolにstatic func定義して、Selfを返してこれにデフォルト実装を持たせる、とすると、final classじゃないと実装できなくなります。これは多分上のSelfのサポートが緩いためだと思う。

11:41 AM

あとはrequired initの絡みとか、最近話題になったinitのバグ周りとか、辛い場面が多い印象です。

確にrequired initじゃないとダメなケースは遭遇した記憶、ログおってみます

UIImageはクラスクラスタじゃない？

あー、そうですね、そうだ…

11:54 AM

struct Image標準で欲しいけど、これUIKitだから無理そう

https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/_UIAnimatedImage.h#L5 https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/_UIMappedBitmapImage.h#L5 (edited)

nst/iOS-Runtime-Headers

iOS-Runtime-Headers - iOS Objective-C headers as derived from runtime introspection

nst/iOS-Runtime-Headers

iOS-Runtime-Headers - iOS Objective-C headers as derived from runtime introspection

お、 struct の Image がほしい人のための https://github.com/koher/EasyImagy

https://github.com/tarunon/Himotoki/tree/feature/init_instead_of_decode

EasyImagy - Makes it easy to deal with images in Swift

！！！

2:32 PM

欲しかった奴だ

UIImage との相互変換もできるし、CoWも効いてます。

ありがとうございます！！

2:33 PM

めっちゃいい

2:33 PM

最高だった

ただ、APIをGuideline準拠しようとして放置中なんですよねー。

なるほど

あと、 RGBA をジェネリクス化したい。

他のカラースペースで実装できるようにする、とかですかね

UInt8 だけじゃなくて Int とか Double とかとれるように。

ああ、

protocol Myself {} extension Myself { var `Self`: Self.Type { return type(of: self) } static var `Self`: Self.Type { return self } } class Foo: Myself { func bar() { Self.hoge() } static func baz() { Self.hoge() } static func hoge() { print("called") } }

rizumitaさんがこんなの薦めてくれました

Selfをシャドーしてる・・・

@takasek こっちに移しておきますね

モダンなSwiftのExtension ですけど、 UIColor.hoge は view.backgroundColor = .hoge できるけど UIColor.ex.hoge は view.backgroundColor = .ex.hoge できないってどうなんですかね？

8:48 AM

RxSwiftがやってるみたいに、extensionを .rx 以下で生やすと、それを左辺に取る代入文の右辺側で型名を省略する . 記法ができないのどう思うって話題

8:48 AM

個人的には、そもそもできたら良い気がする。

それ出来るとすると、多段にネストしてもできるのが成り立つはずで

せやね

そうすると推論が成り立たないケースも出てきそう

.hoge ってやってるときってさ、

8:49 AM

左辺の型の型名以外無いんだっけ。

8:49 AM

view.backgroundColor = .red とかやってるときって、 . の左に来るのって UIColor 以外ありえない？

型情報は左辺型に束縛されてるだけ

もしありえないなら、ドットから始まってるなら、左辺の型を置いてみるだけでよくて、その先が　.red だろうが .piyo.hoge.fuga だろうが、難しさが変わらないように思う

でもUIColorならサブクラスがあり得そうだけど

class Cat { static var mike: Cat { return Cat() } } class FireCat : Cat { static var garo: Cat { return FireCat() } } class Person { var cat: Cat? } let p = Person() p.cat = .mike // ok p.cat = .garo // error

この場合はそもそもFireCatを推測するのが不可能になってる、それは、左辺値がCatでしかないから

UIColorならサブクラスがあり得そうだけど

これをそのまま読んだ (edited)

代入するの自体は、 FireCat.mikeでもFireCat.garoでも出来て、省略は出来ない

8:55 AM

ネストした場合も一意に辿り着けるのかな (edited)

8:56 AM

動きとしては、.開始なら左辺の型を割り当てて呼ぶだけ、ということなら愚直にやって普通に動きそうだ

だよねえ、そんな気がするんだよね

ただ、今不思議に思ったのは

: T = .A.B.C のときに、 T { var A: T { get } var B: T { get } var C: T { get } } みたいに常にTのチェーンだけサポートするなら、底からから辿れば良いけど、この件含めそうではないので、 .C -> T を持つ型群を検索、その型群すべてに B がその型を返す型を検索...ってなって、推論が O(全型数^深さ) になっちゃうんじゃないかな。 (edited)

これp.catはCat?だから、普通に考えたら無理だよね、.をOptional<Cat>で埋めても、mikeは居ないはず。Optionalは特別扱い？

推論が O(全型数^深さ) になっちゃう

ここがよくわからないです。左辺が T で、 .A が来るので、 T.A を探す、見つかる　→ T.A は :T で .B が続くから T.B , -> T.Bは :T で .C が続くから T.C -> T.C は :T で代入できるのでOK と、一直線に進む気が。

ああ、 T から始まるならそうか。ですね。

1

@tarunon 例のごとくそうやろうね、この .推論について T? からのときだけ T も探すんだろう

9:07 AM

@tarunon もしサブタイプ一般に探すなら、さっきの例で FireCat も探してくれないとおかしいし。

Cat???????とかやっても通る？

class Cat { static var mike: Cat { return Cat() } } class FireCat : Cat { static var garo: Cat { return FireCat() } } class Person { var cat: Cat?????? } let p = Person() p.cat = .mike print(p)

9:11 AM

通った

通るのかww

9:11 AM

Optionalの特別扱い、再帰的な処理になってそう

9:12 AM

だから、サブタイプも含めて探すような作りだと、底から探さなきゃいけなくてめちゃくちゃ時間がかかるはずで

9:13 AM

staticなTしか成り立たないのは、頭にTを乗せて探してるだけ(OptionalはWrapped)ということ

9:13 AM

であればextension以下も探せるはず、かなぁ

それかなんか見落としてる探索要素があって、多段にすると爆発しちゃうからできないか。

底から探してるかな？と思っててextension付けちゃうと爆発しそうと思ってたけど、今の作りは頭から行ってるから

多段ありにするとめっちゃビルドが遅くなりそう。 (edited)

Swift 4のSwiftPMはPackage@swift-4.swiftというファイルがある場合、Package.swiftの代わりにそれを使う。しかしパッケージマニフェストのバージョンをPackage.swiftの1行目 // swift-tools-version:N.N (記述がなければデフォルトの3.0)から取得しそれを使ってしまうバグがある。 https://bugs.swift.org/browse/SR-5031

2:00 PM

これがファイル内で指定されたマニフェストバージョンを正しく使う様に修正されれば、Swift 3.xでビルドできる状態をPackage.swiftで維持したまま、Swift 4では拡張されたマニフェストの記述をPackage@swift-4.swiftで使える様になる。 (edited)

2:01 PM

例えばブランチ指定とか。

うちのSwift3.0.2なんですけど、こっちだとOptionalの再帰的解決ないみたいですねー。 class Person { var cat: Cat?????? } let p = Person() p.cat = .mike // error: type 'Cat??????' has no member 'mike'

クロージャ式でのタプルの分解、将来的にありえそう？↓ Core Team の John McCall 。

> Personally I agree that closures worth their own syntax and that it is important to keep closure's syntax lightweight. So, IMO we should keep {x, y in ..} syntax for closures and this should be jut equivalent for {(x, y) in ..}, i.e. one can use first or second depending on his/her style. > > I think the idea of double parentheses for tuple argument destructing in closure is the best solution as it has a relationship to introduced by SE-0066 type of function with tuple argument. I.e. : Yes, I agree. We need to add back tuple destructuring in closure parameter lists because this is a serious usability regression. If we're reluctant to just "do the right thing" to handle the ambiguity of (a,b), we should at least allow it via unambiguous syntax like ((a,b)). I do think that we should just "do the right thing", however, with my biggest concern being whether there's any reasonable way to achieve that in 4.0.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036846.html

func foo<T>(_ body: (Int) -> T) -> T { return body(42) } func foo<T>(_ body: () -> T) -> T { return body() } let result: String = foo { arg in print(arg + 12) return "test" }

今日これがXcode8.3.2 でタイプチェック通らない(ambigous)ことにムカッときたけど Swift4 では通ったので、たぶん SE-0110 の良い影響なんだと思いました。 (edited)

これ推論出来るのすごい

あ〜。<Void>にせずにちゃんと潰そうとすると曖昧になるやつｗ

Void+Intを外に定義したらambigousになりますかね

そういうの考えてくとタプル分解とかも結構罠あるのかな

SE-0110 じゃないかもしれないけど、Swift3 では (_ body: () -> T) が (_ body: (Void) -> T) と同義になっちゃっているっぽいんですよね。 (edited)

お

3:18 AM

Swift4だと()と(Void)が別になるんですか

3:18 AM

ああ、そこでタプルが出てくるのか

3:18 AM

なるほど

func testCopy_BLAS() { let stride = 2 let c = 100_000_000 let a = [Float](repeating: 1, count: c) var b = [Float](repeating: 0, count: c/stride) measure { cblas_scopy(Int32(c/stride), a, Int32(stride), &b, 1) } } func testCopy_vDSP() { let stride = 2 let c = 100_000_000 let a = [Float](repeating: 1, count: c) var b = [Float](repeating: 0, count: c/stride) measure { vDSP_mmov(a, &b, vDSP_Length(c/stride), 1, vDSP_Length(stride), 1) } }

vDSPって内部はBLASなんじゃないのと思ってたんですがベクトルコピーはvDSPのほうが速かった。 vDSPの方はストライド二倍にすると所要時間が半分になるけどBLASはそこまで行かない。

4:35 AM

vDSPはマイナスストライド使えないんですが下手するとvDSP_vrvrs呼んだほうが速いレベル

protocolの中で、static func some() -> Self と宣言するのと、 initを作るの、明らかに後者の方が強いということがわかった

7:27 AM

static funcをprotocol extensionに実装した場合、必ずstatic funcになる(class funcにできない)ので、Selfの返り値が実装を宣言したクラスに固定されて、final classであることが強制される (edited)

7:27 AM

一方でinitはrequired initの扱いになって、返り値はSelfに決定されるので、サブクラス化が可能だった (edited)

Argo ってそんな風になってなかったっけと思って見てみたら一度 associatedtype を経由してたけど、これは同じことになるのかな？ https://github.com/thoughtbot/Argo/blob/master/Sources/Argo/Types/Decodable.swift

thoughtbot/Argo

Argo - Functional JSON parsing library for Swift

protocol P1 { static func a() -> Self } class Animal { static func a() -> Self { fatalError() } }

7:30 AM

protocolの中のSelfを、conformする側でもSelfで受ければ同じ事じゃない？

いや、それだと全てのclassに実装する必要があって

7:30 AM

弱い

7:31 AM

protocol extensionで一般的な実装を提供したい

7:31 AM

Argoのassoctypeは、Swift2.

7:31 AM

Swift2.x時代の名残か、Genericsに渡すために必要かのどちらかだと思います

お、そんな制約がある／あったんですね。

Himotokiのdecode funcはもしかしたら、init(decode extractor: Extractor) に出来るかもしれない。

Unboxはinitで定義されてた記憶

protocol P1 { static func a() -> Self init() } class Animal : P1 { required init() {} static func a() -> Self { fatalError() } } class Vehicle : P1 { required init() {} } extension P1 { static func a() -> Self { return Self.init() } }

できそうでできなかった。これ P1 の a が Vehicleについて見つけてくれないのなんでだ。

protocol Decodable { static func decode(_ json: JSON) -> Decoded<Self> } こうすると、Decodableを実装した型がfinal classであることを強制されるように見えますね、そうすると既存の型を拡張できなくなる

7:36 AM

@omochimetaru Vehicleをfinalにしてみて

ほんとだ〜いけた〜・・・

そう、今回見つけたのはまさにそれで

7:38 AM

protocol Foo { static func generate() -> Self } extension Foo { init() { self = Self.generate() } } protocol Bar { init() } extension Bar { static func generate() -> Self { return Self() } }

7:39 AM

このFooとBarの差異

7:39 AM

Fooの実装はサブクラスを持てないが、Barの実装はサブクラスを持てる

7:40 AM

そこに、initであってもprotocol extensionに実装を記述することが可能、を組み合わせると

7:40 AM

✌('ω' )✌ > Swift楽しい < ✌( 'ω')✌

7:40 AM

となるわけです

なんかコンストラクタ周りのObjCとの繋ぎ込みでガチャガチャやった結果な感じがするなあｗ

w

7:42 AM

static funcがextension以下で、classであることがわかっていてもclass funcにできない、Selfが実装時の型に固定されるというのが、バギーかな、という気がしている

initであってもprotocol extensionに実装を記述することが可能

これってprotocolのみの話であってます？

protocol extensionに記述したinitは、class struct enum, そして protocolを実装したclassのsubclassで使うことが出来ます。 (edited)

8:04 AM

これはちょっといじるとまた新しいバグが見つかりそうだなw

/Users/omochi/work/sandbox/HogeGround.playground:8:5: Protocol extension initializer never chained to 'self.init'

8:06 AM

なるほど

8:06 AM

protocol extensionの中のinitは、他のself.initを呼ばないといけないんね (edited)

それか、selfに外から値をぶち込むか

出た・・・

required' initializer in non-class type 'Log (edited)

self = ...でOK

self = に代入できるのはSelf型なんだね

んだべ

おお、行けた

protocol Log: Unboxable { // ... } extension Log { required init(unboxer: Unboxer) { try! self.init(unboxer: unboxer) } }

(edited)

8:14 AM

間にTranslatorがいれば嬉しさが増すのかな

8:21 AM

final class良いですね...乱用したい

w

あー

8:30 AM

Himotokiはやっぱ、initを呼ぶ時にoptionalになっちゃってるのをErrorにうまいこと逃がすことが出来なくなってしまう、のでダメっぽい

8:31 AM

class の initがOptionalの時に詰んでしまうな。

throwsなinitでwrapすれば可能？

throwsなinitでOptional initをラップすることが出来ない、ですね

8:36 AM

これやろうとすると、protocol extensionのinitでself置換、の裏技を採用しないと作れないw

8:38 AM

tarunon/Himotoki

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

8:38 AM

URLがstructになってるから、既存のテストについてはパスするけど、

8:38 AM

classでOptional initを持ってる場合、はもうちょっと込み入った実装をしなきゃいけなくて、一概に良いとは言えない感じ

Dictionary Literal 書いてて、条件によって一部のエントリーを外したいようなことってないですか？

ある

val foo = [ "a": 2, "b": 3, "c": 5 if bar == baz ] みたいな

8:58 AM

まあ、今書いてるのは Kotlin なんですがｗ

8:58 AM

なんかいい方法ないでしょうか？

タプルの(key, value)からinit出来るDictionary extensionを書いておいて

8:59 AM

Dictionary.init( [Optionalな(key, value)].flatMap { $0 } )

8:59 AM

これがおすすめでしょうか

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

[(key, value)]からinit出来るようにしておくと、Dictionary.init(Dictionary.filter { ... })みたいな事もできて頗る捗るので

9:00 AM

超おすすめです

9:01 AM

Swift4で追加されないかな

dictionaryLiteralはなぜかありますよね

9:02 AM

ああこれもしかしてExpressibleByDictionaryLiteralからきてるのか

9:03 AM

なんで可変長だけあるんだろうと思っていました

Swift 可変長引数に Array 渡せなくて困る。なんかやり方あるんでしたっけ？

9:14 AM

↓みたいな感じでできた。この * （配列を可変長引数に展開）が Swift にもほしい。

// Kotlin mapOf(*(arrayOf( "foo" to obj.foo, "bar" to obj.bar, obj.baz?.let { "baz" to it } ).flatMap { if (it == null) emptyList() else listOf(it) }.toTypedArray()))

(edited)

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/033190.html SE-172 One-sided Ranges の絡みでsyntax についての議論がまとまらず。

可変長引数からArrayに渡すのはできるんですけどね

なるほど。 ... から離れれば良いような気も

https://www.drivenbycode.com/the-missing-apply-function-in-swift/

The Missing Apply Function in Swift

Many programming languages have some sort of Apply function, a language construct that applies a function to a list of arguments. Apply is ubiquitous in functionally-leaning languages, but it is ...

9:28 AM

func apply<T, U>(fn: (T...) -> U, args: [T]) -> U { typealias FunctionType = [T] -> U return unsafeBitCast(fn, FunctionType.self)(args) }

9:28 AM

怪しい・・・

すごいハックだw

なるほど、そっち側の変換があったか

// You can call apply with many different variadic functions apply(average, [1.5, 2.5, 5.0]) // -> 3.0 apply(sum, [1, 2, 3]) // -> 6

unsafeBitCastｗ

やーべえw

一応できてる・・・

func apply<T, U>(fn: (T...) -> U, args: [T]) -> U { typealias Fn = ([T]) -> U return unsafeBitCast(fn, to: Fn.self)(args) } let dict = apply(fn: Dictionary.init, args: ["a": 1, "b": 2, "c": 3].filter { $0.value % 2 == 0 }) print(dict) // ["b": 2]

いけますね…

9:32 AM

まじかー

これは便利

func apply<T, U>(fn: @escaping (T...) -> U, args: [T]) -> U { typealias Fn = ([T]) -> U return (fn as! Fn)(args) } let dict = apply(fn: Dictionary.init, args: ["a": 1, "b": 2, "c": 3].filter { $0.value % 2 == 0 }) print(dict)

unsafeBitCastいらんかった

あれ、キャストでいけちゃうんですね

これと

as! なのか・・・

あとなんか、@escapingつけないとダメだったのもよくわからん

↓こっちの方が好みかも。

func fix<T, U>(_ f: @escaping (T...) -> U) -> ([T]) -> U { return f as! ([T]) -> U } let dict: [String: Int] = fix(Dictionary.init)([ ("a", 2), ("b", 3), ("c", 5) ])

(edited)

let x: (Int...) -> Int? = { (a: Int...) in return a.first } typealias Fn = ([Int]) -> Int? x as? Fn // nil 謎いw

public init<S: Sequence>( uniqueKeysWithValues keysAndValues: S ) where S.Iterator.Element == (Key, Value) {

1

ほしい

swift-4.0-branchはWWDC始まるまでロックされたままかな？

4:11 AM

REPLの:type lookup Dictionaryだと、書式が違うな。 init<S>(uniqueKeysWithValues keysAndValues: S) where S : Sequence, S.Element == (Key, Value)

https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md これですね。

https://github.com/Microsoft/TypeScript/blob/master/lib/lib.d.ts#L1006-L1010

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

ですです。こんなのも

 public init<S: Sequence>( _ keysAndValues: S, uniquingKeysWith combine: (Value, Value) throws -> Value ) rethrows where S.Iterator.Element == (Key, Value) {

 public init<S: Sequence>( grouping values: S, by keyForValue: (S.Iterator.Element) throws -> Key ) rethrows where Value == [S.Iterator.Element] {

(edited)

おお

4:18 AM

便利だ

4:20 AM

昨日の話の続き、 let x: (Int...) -> Int? = { (a: Int...) in return a.first } type(of: x) // <- ((Array<Int>) -> Optional<Int>).Type

4:20 AM

型的には同じらしい

お〜〜

4:20 AM

でもまあ現バージョンがたまたまそうなってるだけの可能性があるからなあ。

let x: (Int...) -> Int? = { (a: Int...) in return a.first } typealias Fn = (Array<Int>) -> Optional<Int> print(type(of: x)) // (Array<Int>) -> Optional<Int> print(x as? Fn) // nil

4:22 AM

これが完全に解せない

w

先のapplyに入れればキャストが可能

4:23 AM

なんかありそう

↓もダメでした。

func fix<T, U>(_ f: @escaping (T...) -> U) -> ([T]) -> U { // cannot convert return expression of type '(T...) -> U' to return type '([T]) -> U' return f } func fix<T, U>(_ f: @escaping (T...) -> U) -> ([T]) -> U { // cannot convert value of type '(T...) -> U' to type '([_]) -> _' in coercion return f as ([T]) -> U }

(edited)

as!だけOKなんですよね

4:25 AM

実行時の型は同じだが、asでの変換は不可能で、素のままでやるとキャストもfailする。が、Genericsな型に変換して渡したあとならas!でキャストが可能

@tarunon さんのコードの続き print(x is Fn) // false

あーー

4:25 AM

これってもしかして

4:25 AM

暗黙の変換系のアレでは

type(of:) がおかしいだけな気も

func foo(x: Int...) { print(x) } let _foo = foo as Any as? ([Int]) -> Void _foo?([1,2,3]) いったん Any 通すと大丈夫っていう。

ええw

ｗ

ってことは

4:26 AM

type(of:)がおかしいから

4:27 AM

as?がコケてる説

そもそも as! で変換できるのに as? が nil ってありですっけ？

いや

4:28 AM

Anyを通さないとas!も失敗します

4:28 AM

AnyやGenericsパラメータを通すと、変換可能になる

ありそうな話ではある

func foo(x: [Int]) { print(x) } let _foo = foo as AnyObject as? (Int...) -> Void _foo?(1,2,3) 逆も可とｗ

仕様としてはごちゃごちゃしてるけど、そういう柔軟なやつに入れた時には型情報つきのオブジェクトになってそう

4:34 AM

...に変換するのヤバｗｗｗ

逆が生成出来るなら、[(Key, Value)]をデフォルトでおいといて(Key, Value)...に変換するほうが合理的では?と思った

4:35 AM

てか

Any じゃなくて AnyObject になったのは何か理由があるんですか？

(Key, Value)...って受け手側はArrayなんだからそのままでよい

AnyObject は、それでも通るかどうか試しただけです。

なるほどです。

4:39 AM

うーん、なんで↓は Any 介さなくても通るんだろう。 func fix<T, U>(_ f: @escaping (T...) -> U) -> ([T]) -> U { return f as! ([T]) -> U }

これは (T...) -> U がAnyと同等の役割を果たしていそう

↓コンパイル通るけど実行時に死ぬ。

let makeDict: ((String, Int)...) -> [String: Int] = Dictionary.init let dict: [String: Int] = (makeDict as! ([(String, Int)]) -> [String: Int])([ ("a", 2), ("b", 3), ("c", 5) ]) print(dict)

let foo: (Int ...)->() = { x in print(x) } let _foo = foo as Any 元がクロージャだとコンパイラクラッシュ。うーん、可変引数クロージャは触らない方が安全だ。 (edited)

4:43 AM

https://bugs.swift.org/browse/SR-2475 Jordanのコメント

可変長引数複雑すぎるから全部配列リテラルで書けばいい気がする・・・

配列リテラル用意しておいて、可変長引数はそれのシンタックスシュガーでいいと思うんですよ

4:46 AM

そっちの方が幸せな気がする

func variadic<T>(values: T...) { } で let arr = [1, 2, 3, 4, 5] variadic(arr) Tの型は何？

[Int]では

配列を可変長の１要素に書いて一包狂うやつ

4:47 AM

個人的にはスプレッドオペレータがさっさと欲しい

配列を可変長引数に変換できる様にすると、それが困ると言う投稿を読みました。 https://devforums.apple.com/message/974316#974316 (edited)

4:51 AM

$ echo "func f(a:Int...){}"|swiftc -emit-sil -|swift-demangle sil_stage canonical import Builtin import Swift import SwiftShims // main sil @main : $@convention(c) (Int32, UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>) -> Int32 { bb0(%0 : $Int32, %1 : $UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>): %2 = integer_literal $Builtin.Int32, 0 // user: %3 %3 = struct $Int32 (%2 : $Builtin.Int32) // user: %4 return %3 : $Int32 // id: %4 } // end sil function 'main' // f(a:) sil hidden @main.f(a: Swift.Int...) -> () : $@convention(thin) (@owned Array<Int>) -> () { // %0 // users: %2, %1 bb0(%0 : $Array<Int>): debug_value %0 : $Array<Int>, let, name "a", argno 1 // id: %1 release_value %0 : $Array<Int> // id: %2 %3 = tuple () // user: %4 return %3 : $() // id: %4 } // end sil function 'main.f(a: Swift.Int...) -> ()'

4:51 AM

内部的にはArrayらしい。

逆な気もしますが、可変長引数と配列を同一視すると曖昧性があるのは確かです。 func foo(_ xs: [Int]) { ... } foo([2, 3, 5]) foo(2, 3, 5) // == foo([2, 3, 5]) foo([2]) // == foo([2]) or foo([[2]]) ???

4:52 AM

なので、不便を解消するにはスプレッドオペレータを導入するか、僕はむしろ最初から可変長引数なんてなくてもいいんじゃないかという気がします。

4:52 AM

[] 書くだけだし。

4:53 AM

ただ、今の Swift からなくすのは辛いから、スプレッドオペレータが現実解な気が。

4:53 AM

でも Any 経由で変換できるのは、最悪の場合のワークアラウンドとしては良さそう？

print(1,2,3)とprint([1,2,3])の意味が違うのは嬉しい

4:54 AM

前者は3つの値を表示せよ、で、それぞれの区切り方とかはprintに任されてるけど

4:54 AM

後者は「配列を表示する」場合っていうニュアンスが入っちゃう

なるほど。別の形としてオーバーロードして

4:55 AM

意味を変えてしまうというユースケースがあると。

JavaScriptでconsole.debug(x, y, z) とかも、デバッガでその変数を表示したりするんで意味が変わる

名前を変える（ Swift ならラベルを変える）でいい気も。 (edited)

4:56 AM

まあでも、今更可変長引数取り除くのは現実的じゃないと思うんで、スプレッドオペレータがほしいのは間違いないです。

*array と ...array がメジャーですね

で、 ... はレンジとの兼ね合いで流れたって話だったから、 * か、もしくは独自のキーワードでもいいかも？

#spread(array)

それありなら #tuple(1, 2, 3)にすれば平和になるのでは

@koher たとえばこういう？ func foo(_ x: Int...) {} foo(...: [1,2,3]) func bar(baz x: Int...) {} bar(...baz: [1,2,3])

ラベル側を使うのおもしろい

5:00 AM

...: ←スネークっぽい

・が多くて見づらいｗ

5:03 AM

名前を変える（ Swift ならラベルを変える）でいい気も

ああ、受け側でオーバーロードするっていう意味ですね。呼び出し側かと思った。

可変長引数をArrayで作成したいシーンって、そんなに多い？

可変長引数を使いたいケースの方が少ないくらいです

今回の話題の発端は Dictionary Literal だから

5:05 AM

そもそもタプル配列を取るやつを用意してくれって感じ

5:06 AM

JavaScriptだと Array.concat とスプレッドオペレータを組み合わせて flatten の代わりにするというイディオムがあるけど

5:06 AM

まともな標準ライブラリならそんなシチュエーションが生じない

はい、そうです。 < オーバーロード

ならばSwift 4では不要かな。>スプレッドオペレータ (edited)

まともな標準ライブラリ

これは常に可変長版と Array 版がオーバーロードされてるってこと？

JSの例で言えばflattenがあれば良かっただけなんですが、一般的にはそうですね

（名前かラベルか変えないと曖昧性を生むから厳密にはオーバーロードでないけど）

5:11 AM

うーん、その 2 種類を用意するのはボイラープレート感あるから、やっぱり特殊構文がほしい気が。

5:11 AM

スプレッドなのか、 rintaro さんの言うような呼び出し側で切り替えるなのか。

Dictionary.init(dictionaryLiteral:) の説明文に Do not call this initializer directly. It is called by the compiler to handle dictionary literals. ってあるけど、実際困る様な事が起きたりするのだろうか。 (edited)

うーん、将来的にシグネチャが変えられる可能性があるとか？

1

swift-4.0-branchはWWDC始まるまでロックされたままかな？

6月1日にmasterから再度swift-4.0-branchが切られるから、masterブランチに注力って事らしい。 https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170417/004405.html (edited)

Do not call this initializer directly. これliteral系は全部書いてますね

7:48 AM

コンパイラの機能が成長して、stdlibに存在しなくても使えるようになって消滅する可能性がある、のかな

特に根拠となる文章やコミットは見つけられなかった。> Do not call…

ある型がSequenceに準拠しなくなったので代わりにallプロパティを使って欲しい、というメッセージをビルド時に出力する方法は無いものか。

3:58 AM

無理ぽ

素直な方法無い気がする

4:02 AM

map/filter/flatMapみたいなよく使われるメソッドに@available書いてall.map/all.filter/all.flatMapに誘導するのは出来そう

extension自体に@availableはできないんですね。

プロトコル準拠の宣言自体に@available()をつけることが出来ないですね。

Kotlin 書いてるんだけど、 var の List （タイミング問題でコンストラクタで初期化できない）と val の MutableList （ミュータブルにしたいけどインスタンス自体は差し替えたくない）と val の List を使い分けてて辛い・・・。 Swift で var と let で Array` のミュータビリティをコントロールできるのほんと素晴らしい。 (edited)

varのListは要ります？コンストラクタは常にMutableListだけにして、変数はvalだけにして

3:31 AM

Listは返り値からの推論だけにすると

3:31 AM

気楽になりそう

KotlinのMutableList、varに代入し直した時にSwiftと似たような挙動(CoW然り)になるんですか?

Kotlinのvarは単に参照がmutableというだけ。NSMutableArrayと同じよ。

インスタンスは全部同じになるのかな

イミュータブルであることを示したいけど（実際にはリードオンリーだけど）、コンストラクタのタイミングでは初期化できないから、プロパティとしては var になっちゃう。 by 使ったらうまくできんのかな？

lateinit valは？

3:36 AM

lateinitはvarにしか使えなかった・・・

@tarunon Swift とは全く違う挙動ですね。単に型がわかれてるだけで全部参照型です。 var, val は vat, let と同じです。

@omochimetaru lateinit val, めちゃくちゃなフロー解析が必要になりそう

3:37 AM

うおお

structらくちんだよなあ

全部 struct にしてプロトコル型変数も禁じたら（サブタイピングを排除したら）、 Haskell みたいな世界を築きながら、値型のミュータビリティの恩恵も受けられる。

3:40 AM

純粋値型言語。おもしろそう。

for in に case マッチ使えるの始めて知った。

enum E { case foo(String) case bar(Int) } let arry: [E] = [.foo("hello"), .bar(1), .foo("world!")] for case let .foo(str) in arry { print(str) }

ワオ

pythonみを感じるw

.map と .filter　のリスト内包表記みたい

3:47 AM

@tarunon それ

3:47 AM

右から左に修飾する宣言的記述は嫌でござる

使いどころが思いつかないｗ

これ出来るってことは、[UIViewController]から特定の型のUIViewController取り出せるかな。

それなら、 for vc in vcs where vc is MyVC { ... } でいいとおもいます。

vcs.flatMap { $0 as? HogeViewController }

whereも使えるのかw

3:53 AM

pythonみ高いなぁ

whereなら右にあるからまだ読める

Microsoft/TypeScript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

4:07 AM

JavaScriptのArray.concatが T または Array<T> の可変個の引数で、型付けが面白い

4:08 AM

他の言語のチャンネルつくっとこ

ios-developers-japan だけど他の言語チャネル作るの？ｗ

4:10 AM

iOS Developer のための、他の言語チャネルだと矛盾しないか

矛盾しないし、そもそもWebViewとかもあるから TypeScript/ JSとかは普通に使う

なるほど。

kotlinは・・・kotlin/Nativeとかあるし・・・

ｗ

4:11 AM

そのうち developers-japan になってたりしてｗ

for caseの利用例を探したらこんなのが。

open class NSMutableOrderedSet : NSOrderedSet { open func intersectSet(_ other: Set<AnyHashable>) { for case let item as AnyHashable in self where !other.contains(item) { remove(item) } } }

for item: AnyHashable in self { じゃだめなんだろうか？

NSMutableOrderedSetの中に as AnyHashableが通らない (=Hashable)でない要素が入ってる可能性があるの・・・？

4:27 AM

実際には入ってないはずだけど型保証が無くて通らないからそう書いてるのかな

で正解っぽい。

1

for item: AnyHashable in self { ?

@norio_nomura この場合はだめですね。

@available(*, unavailable) になってるスコープの中でunavailableなものを触っててもコンパイル通してほしいんだけどそういうふうに鳴らないかなあ

6:30 AM

@available(*, unavailable) struct Hoge { static var shared: Hoge = { fatalError() }() // error: 'Hoge' is unavailable }

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036452.html

6:32 AM

もっと広い範囲での提案。

same-fileか。

6:33 AM

rintaroさんシュッとpitchが出て来るのすごい…

似たような要望があったなってのを思い出しただけです。

protocol側に逃がせばコンパイルエラー出ないように出来る気がする

お？

ゴリ押し感高いけどw

@available(*, unavailable) ってどういうとき使うの @hiragram

6:34 AM

コメントアウトして全部消しちゃえ

アプリのメジャーバージョンアップとかで画面ごと無くなるみたいなときとかVCとVMをunavailableにしたりしてるけどまあ (edited)

6:36 AM

消せの気持ちはわかる。

あ〜

@hiragram

protocol UnavailableHoge { static var shared: Self { get } } extension UnavailableHoge { static var shared: Self { fatalError() } } @available(*, unavailable) struct Hoge: UnavailableHoge { }

6:36 AM

ほい

コンパイル通る状態で取っておきたいけど使ってる場所は洗い出したいのか

gitの履歴とか遡るのがだるくて、かつ前のバージョンでどう実装してたっけ〜とコードが見たくなるときはある

6:36 AM

UnavailableHoge　！！！！！！

一回コメントアウトしてからアプリをコンパイルして、エラーが大量に出るので、それを全部解決した後で、コメントインすれば？

@availableはrenamed入れておくとコンパイラの加護を得られたりして大変良いので

あとは @available(*, unavailable, renamed: "hogehoge") を結構やる

6:38 AM

そうそう

特にチームでやっててリファクタリングと機能追加がかぶったりすると

6:38 AM

やってあげると超親切、ですね

renameなるほど・・・

自分のブランチで消したら他の人が新しく呼び出したりしてそうなときとかはdeprecatedとかunavailableとかガンガンつけてやがて消すよというのをアッピルしてる

本当には消えてないほうが段階的に消せて便利なのか

単に呼び出し先が無い(unresolved identifier)とかだとマージミスったかなとかそういうことを勘ぐりはじめてしまいがち

なるほど

deprecatedでリネーム→マージしたあとでwarning掃除→unavailable/削除

6:40 AM

がおすすめ

ふむ

^⌥⌘F

Ctrl + Alt + Cmd + F

確かCLIで実行する方法の話題がSwiftJPで出たはず。

7:47 AM

https://github.com/apple/swift/blob/master/utils/apply-fixit-edits.py

https://github.com/apple/swift/pull/8380/files

swift - The Swift Programming Language

class A { class func foo(x: A) { print(x) } } class B: A { override class func foo(x: A?) { print(x) } } こいつは通るのに

9:39 AM

class A { class func foo(x: A) { print(x) } } class B: A { override class func foo(x: B) { print(x) } } こいつダメなの最高に納得がいかないw

ああ〜

あー

うーんでもどうなんだろう

サブタイプの関係が逆化

あ、ほんとだ

protocol X {} class A: X { class func foo(x: A) { print(x) } } class B: A { override class func foo(x: X) { print(x) } } でもこれもダメなんだよね

9:43 AM

Optionalだけ謎の挙動がある

A? を受ける版は Aを受けることができるけど、Bを受ける版でAは受けれないわ。

9:44 AM

でもたとえば

9:45 AM

protocol X {} protocol Y {} class A: X, Y { class func foo(x: A) { print(x) } } class B: A { override class func foo(x: X) { print(x) } override class func foo(x: Y) { print(x) } }

9:45 AM

こういうことがおきたとき、どっちでオーバーライドするか決められないし？

確かにそれはそうか

9:45 AM

Optionalはなんで通るんだ

そこのほうが気に食わない。

9:46 AM

参照型のOptionalがバイナリ互換だからかと思ったけどstructで試しても同じだった。

バグっぽい

Update CHANGELOG.md to mention covariant method overrides by slavapestov · Pull Request #8380 · apple/swift

A lot of people reported bugs in this area so it's worth mentioning that Swift now allows subclasses to override methods in a base class with a more general type.

あれ？

9:48 AM

NookとBedの例は

9:48 AM

あ〜クラスならいけるのかな？

protocol は、まだだと思います。

なるほど

class Animal {} class Cat: Animal {} class Vehicle { class func hit(_ x: Cat) {} } class Uaz : Vehicle { // 両方かくとエラー、どっちかだけなら通る。 override class func hit(_ x: Animal) {} override class func hit(_ x: Cat?) {} }

9:51 AM

↑こんな感じだった。

9:51 AM

片方にoverride,片方にoverride無し、なら、オーバライドする方を固定できるかと思ったが、「二回定義してるエラー」と「overrideついてないよエラー」が出て、ダメ。 (edited)

あーー

10:00 AM

class A { class func foo(x: A) { print(x) } } class B: A { override class func foo(x: A??????) { print(x) } } 許して貰えなかったw

ｗｗ

そこらへん闇で、一般的にはオーバーライド時に引数の型をゆるめることはできるんだけど、そもそも Swift の Foo? に Foo が代入できるのはサブタイピングじゃなくて暗黙の型変換だから、それがオーバーライドでサブタイピングっぽく振る舞うのが闇で、実装するだけならコンパイル通るけど実行するとクラッシュとかあった気が。

ひぇ

おもしろいこと発見した。まず、Swift↓は当然の結果。

// Swift var title: String = "a" class Foo { var title: String = "x" init() { title = "b" } } let foo = Foo() print(title) print(foo.title)

a b そして Kotlin 。

// Kotlin var title: String = "a" class Foo { var title: String = "x" init { title = "b" } } val foo = Foo() println(title) println(foo.title)

b x (edited)

kotlinはthisでしたっけ?

はい

明示すれば正常になるのかな

はい、なります。

なるほど~

Kotlin では常にローカル変数が優先されるようです。

6:45 AM

最初↓を試してたんですけど、

// Kotlin class Foo(var title: String = "x") var title: String = "a" val foo = Foo().apply { title = "b" } println(title) println(foo.title)

6:46 AM

apply に渡すラムダ式の中では暗黙的に this が使えるんですけど

ローカル変数が無い場合はコンパイルエラーですか?

↑のようにローカル変数があるとローカル変数に上書きされることがわかって、

6:46 AM

調査してると常にローカル変数優先だとわかりました。

6:47 AM

ローカル変数がないと↓です。 class Foo(var title: String = "x") val foo = Foo().apply { title = "b" } println(foo.title) b

これはやだなw

title が暗黙的に this.title を指します。

6:48 AM

まあ、 apply の件では明示的に宣言されているローカル変数が勝つというのがわからんでもないのと、 this. には this. を書けばアクセスできるんだからシャドーイングを考えてローカル変数優先ってことなんですかね・・・。

外を優先するのはそれはそれでいいんですが

AndroidStudioはメンバの色変わりましたっけ？ Xcodeは変わるので安心感ある。

その場合はthisの省略を許可しないでほしい

apply は this を省略できる Function Literals with Receiver って仕組みで、これはこれで便利なんですよね〜。

6:51 AM

↓を

// Java primaryStage.setTitle("Hello World!"); Button btn = new Button(); btn.setText("Say 'Hello World'"); btn.setOnAction(new EventHandler<ActionEvent>() { @Override public void handle(ActionEvent event) { System.out.println("Hello World!"); } }); StackPane root = new StackPane(); root.getChildren().add(btn); primaryStage.setScene(new Scene(root, 300, 250)); primaryStage.show();

↓みたいに書ける。

// Kotlin primaryStage.apply { title = "Hello World!" scene = Scene(StackPane().apply { children.add(Button().apply { text = "Say 'Hello World'" onAction = EventHandler<ActionEvent> { println("Hello World!") } }) }, 300.0, 250.0) show() }

(edited)

ビルダーパターンなんていらんかったんや　ってやつですね

うん

@t.ae 見逃してた。

AndroidStudioはメンバの色変わりましたっけ

どうだっけ？ Try Kotlin では変わってないから変わらなさそうな気がする。

9:10 AM

（ Try Kotlin は IDEA を踏襲してそう。で、 Android Studio も IDEA だから。） (edited)

変わった気がするけどなあ　基本的にASはEclipseの上位互換に思う

いまちょうどやってましたけど変わりますね

それに加えてshadowing warningも出ない？

おお、 Try Kotlin がしょぼいだけなのか。

@omochimetaru shadowing waringはでないっぽいですね

イニシャライザでクラスクラスタを実現できないの、swift-corelibs-foundationにとって大きな障害ぽい。

Protocol extensionで…と思ったけど、overrideできなくなるのはそれはそれで困るか

ああ、これか。 https://gist.github.com/rintaro/b16f05411cfe540754285dcc0da60174

factory_init.swift

class clusterがconvenience initになってサブクラスにpublic initが置けなくなるの、困るシチュエーションあるかな

おおお、イケるかも。

オッ

2:33 PM

そもそもclass clusterは、open classには成れない気がする。ので、多分問題がない、かな

2:33 PM

強いて言えばあやしいかもぐらい

https://github.com/apple/swift/pull/4087 放置PRですが。本体の方のFoudationオーバーレイにPR出してみた反応です。

[Foundation] Add hack enabling factory intializer by rintaro · Pull Request #4087 · apple/swift

What's in this pull request? I'm not sure this can be accepted or not. But this is convenient in some cases. Using that: Simplify copy constructor of NSSet and NSDictionary Eliminate getVaList fro...

1

将来的には、classで普遍的にSelfが使えるようになれば、そっちにシフトしていけばいいはずなんで (edited)

2:43 PM

言語機能として再現不可能な状態に陥ることは無いかな?とは思ってるけどどうなんだろ

2:43 PM

やっぱりinitが欲しいのかな

最新のスナップショットでも使えるから直されていないのね。

お、おもろいの見つけた

3:11 PM

import Foundation class Piyo<H>: NSObject { } class Hoge: NSObject { } extension Hoge { func hello() -> Piyo<String> { fatalError() } } class Fuga: Hoge { override func hello() -> Piyo<String> { // Declerations from extensions cannot be overriden yet return Piyo() } }

3:11 PM

これなんだけど、メソッドがobjcから参照可能な型なら通るっぽい

3:11 PM

import Foundation class Hoge: NSObject { } extension Hoge { func hello() -> AnyObject { fatalError() } } class Fuga: Hoge { override func hello() -> AnyObject { return "hello" as AnyObject } } Fuga().hello()

↑のでこれは通る

3:12 PM

RxSwiftにこれで通してる部分があるな

NSNumber.init(value: Bool)で__NSCFBooleanを返す様にする https://github.com/apple/swift-corelibs-foundation/compare/master...norio-nomura:nn-fix-sr-4907

Fix NSNumber.objCType crashes, make it returns same values with darwin platform version by norio-nomura · Pull Request #1025 · apple/swift-corelibs-foundation

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

めっちゃスッキリしてる

元々はNSNumber.objCTypeへアクセスしてクラッシュするバグを修正するのが目的なのだけれど、クラッシュしない場合にdarwinと同じ値を返す様にしたら、ピタゴラ的に追加修正が必要に… (edited)

_Factoryプロトコル使ったやつ、PR出してみた。 https://github.com/apple/swift-corelibs-foundation/pull/1025

Fixes SR-4907 Add TestNSNumber.test_objCType() reproducing crash Expected results are sampled from macOS Fix crash on accessing objCType property of NSNumber Change NSNumber.objCType to returning...

classのinitでselfに代入が許可されない合理性考えてるけどイマイチ答えが出て来ない

6:30 AM

convenience initならself代入が可、で良いのでは？という気持ちがある

加えて、failable initializerの場合 self = nil ではなく return nil

6:32 AM

するのもなかなか気になります

failableだとnilなのかthrowなのか一瞬解らなくなるw

6:34 AM

nilableもthrowableもありますね

6:34 AM

nilable initからthrowable initに変換したいが、class initだとどうしても出来ない、と言うのが不便 (edited)

6:35 AM

protocol extension経由したら可能ですが、それは最早何やってるか解らんですね

6:36 AM

evolution書くしか

@takasek Failable Initializerのnilは失敗したときだからreturnで早期脱出したいニーズがあるんだと思います。

10:22 AM

あー、あとnil代入できるためにはselfがOptionalじゃないといけないから、initの中でselfが使いにくくなりそうです。self?.fooってやらないといけなくなるので。

10:24 AM

return self はできてもいい気がしますけどね。成功ケースの早期脱出のために。

↑の「Optionalじゃないといけない」は、Implicitly Unwrapped Optional扱いならいい気がしてきました。

static func init() -> Self? { var self = alloc() <プログラマが書く部分> return self } (edited)

10:41 AM

こういう感じに思ってる

うん、それなら self= nil できない説明はつくけど、 return self できないのは謎。

throw Errorとreturn nilだけ出来ますねぇ

たしかに。

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/030522.html

I think assigning to ‘self’ should be permitted in all convenience initializers, even initializers defined directly classes, without the protocol extension trick. Also, we should lower this more efficiently than we do today, without creating a self ‘carcass’ that is allocated and immediately freed, to be replaced by the ‘real’ self.

classでProtocol extensionでハックすると、一瞬selfインスタンスができるってことですかね？alloc自体は走っている？

1:58 PM

あーそっか、swiftで書けるのはdeinitであってdeallocではない、前実験したときはdeinitしか見てなかった

この前の Kotlin のローカル変数とシャドーイングの話、グローバル変数なら Swift と同じ結果になった。

// Kotlin var title: String = "a" class Foo { var title: String = "x" init { title = "b" } } fun main(args: Array<String>) { val foo = Foo() println(title) println(foo.title) }

a b (edited)

2:53 AM

ローカルだとローカル優先。

// Kotlin fun main(args: Array<String>) { var title: String = "a" class Foo(var title: String = "x") { init { title = "b" } } val foo = Foo() println(title) println(foo.title) }

b x (edited)

実行コンテキストでない静的なクラス定義でグローバル変数をキャプチャされたらつらいし妥当感

2:53 AM

というか、グローバル変数ってキャプチャする必要がないな

逆に、グローバル変数って常にキャプチャされてるようなものじゃない？

まあグローバルスコープが一個あるって考える事もできますね

↓例のクロージャ式でのタプルのdestructuringについて、Chris LattnerからJohn McCallへ。

One way to split the difference here is to eliminate the splatting behavior, but keep the destructuring (irrefutable pattern matching) behavior as well. In these cases, just require an extra explicit paren for the parameter list. This would change the diff's to: Example 1 - return columns.index { (column, _) in column.lowercased() == lowercaseName } + return columns.index { ((column, _)) in column.lowercased() == lowercaseName } Example 2 : - .map { (mappedColumn, baseColumn) -> (Int, String) in + .map { ((mappedColumn, baseColumn)) -> (Int, String) in Example 3 : - .map { (table, columns) in "\(table)(\(columns.sorted().joined(separator: ", ")))" } + .map { ((table, columns)) in "\(table)(\(columns.sorted().joined(separator: ", ")))" } Example 4 : - dictionary.first { (column, value) in column.lowercased() == orderedColumn.lowercased() } + dictionary.first { ((column, value)) in column.lowercased() == orderedColumn.lowercased() } What do you think? Seems like it would solve the type checker problem, uglify the code a lot less, and make the fixit/migration happily trivial.

@norio_nomura

Sequence has an associated type Element that is equivalent to Iterator.Element. The value

of this associated type can be inferred from existing Sequence conformance. Code that already declares a type of Element may need to be altered to resolve conflicts. (32186094) https://bugs.swift.org/browse/SR-4951 に何も反応ないままこれとはｗ

まあ、予想はしてたw

3:56 AM

issueの元になったパッケージは、elementに変更してさらにSequence準拠もやめてました。

1

↓このスレッド、 SE-0110 以前（引数とタプルの区別）からひっくり返そうって言ってる・・・。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170605/037054.html

5:50 AM

As one of many who is directly affected and wants resolution, I think the discussion of re-evaluating SE-0110 most certainly expands to these earlier decisions. While Swift has moved in the direction of distinguishing tuples and argument lists in decidedly different ways, I think it's perfectly valid to consider the alternative: a simpler and equally-valid solution: flattened tuples that are isomorphic to argument lists.

それ絡みで、これは当然できないけど、 func foo(x: Int, y: String) { print(x) } foo(y: "foo", x: 12) これはできるんですよねー。 func foo(arg: (x: Int, y: String)) { print(arg.x) } foo(arg: (y: "foo", x: 12))

@rintaro えっ、ラベル付きタプルって順番ひっくり返せるんですか？！

ｗｗｗｗ

6:24 AM

そうだったのか。・・・

↓できた。 let foo: (a: Int, b: String) = (b: "x", a: 42)

...からの let (x: Int, y: String) = (y: "foo", x: 42) print(Int)

let (x: Int, y: String) = 許されてるのバグじゃないかと思ってるんですけどどうなんでしょう？

6:28 AM

このラベル x, y が活きる場所がないし。

6:28 AM

いや、ちがうのか

6:28 AM

↑の順番入れ替えで活きてるのか。

6:28 AM

ヤバイ・・・

タプルパターンにラベルが認められているのはこのためで、 let input = (y: "foo", x: 42) let (x: foo, y: bar) = input print(foo) これがやりたいから。

そのletの技めっちゃ混乱する

で、誤って (x: Int, y: String) と書いた人が死亡するとｗ

6:29 AM

let (x, y): (Int, String) = としたい人が let (x: Int, y: String) = と書いて爆死するのが見えますねｗ

https://twitter.com/UINT_MIN/status/860250431401762817

Jordan Rose @ WWDC (@UINT_MIN)

@harlanhaskins @CodaFi_ We're pretty sure it was intended for tuple shuffles.

このツイートｗｗ

6:30 AM

High on iLife‏ @CodaFi_ 5月4日 その他 What do you mean Swift doesn’t have mixed-type arithmetic? let (x : Int, y : Double) = (3, 1) let result = Int + Double // 4

1

6:31 AM

It would be great if we had some kind of community-driven process for cleaning up language edge cases like this

6:31 AM

Slava Pestov‏ @slava_pestov

6:31 AM

スラーバ氏、ツイッター担当みたいになってるな

6:31 AM

この手の話題によく反応してる

そのくせにマッチングパターンではシャッフル出来ないとか、いろいろぐちゃぐちゃですね。

func foo(arg: (x: Int, y: String)) { switch arg { case (y: let bar, x: 0..<12): // error: tuple pattern element label 'y' must be 'x' break default: break } }

(edited)

ひどい・・・

なんと、これは動く！ func foo(arg: (x: Int, y: String)) { if case (y: let bar, x: 0..<12) = arg { print(bar) } } foo(arg: (x: 4, y: "test"))

このへんって表面の見た目が同じだけで裏はぜんぜん違うものになってるんですかね

えー、それどっちもパターンマッチなんじゃないのか・・・

6:40 AM

仕様として明確に決まってなくて、実装にブレで起こってそう

@t.ae コンパイラ実装のロジックという意味ではバラバラだろうね

6:41 AM

@rintaro if case = の形とswitch-caseで違うのは驚き

完全にバグっぽいけど、現時点だとどっちの方向に直したらいいかわからないですねｗ

↓再掲 https://developer.apple.com/documentation/swift/2885064-type

9:06 AM

Swift 4 では type(of:) は関数になったので、↓ができなくなった、と。 let type = 42 type(of: type) // Int

続き変数strideがあるときにstride(~)が昔は呼べてた気がするけどラムダのせいで呼べないなら昔も呼べなかったはずではないのか。記憶が間違ってるのか。

適切に type をシャドーイングできるようになったって話です。

構文が関数の形式だったから、これは喜ばしい変更だと思う。

昔はザルだった説

ザルだった説と自分の記憶を信じたい

変数strideがあるときにstride(~)が昔は呼べてた気がする

本当にそうだったかわからないけど、それ望ましくなくないかな？ (edited)

Any はまだで、 Any という変数をつくることはできない。

@koher 望ましくなかったけどできていた記憶があるというだけです。

あー

さすが rintaro さんはパーサー周りやってるだけあってそのあたりの闇に詳しいですね。

9:09 AM

↓はできた。 let Never = 42

9:11 AM

そういえば、 Never は当初から bottom type が想定されてたことをこの前知った。 https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md#never-as-a-universal-bottom-subtype

https://github.com/apple/swift/pull/8380/files

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

9:11 AM

Never as a universal "bottom" subtype

おー

enum Never {}なのもそれ意識した作りだと思ってた

9:13 AM

激しくデジャビュ、Twitterでやった記憶ある

enum Never {} だとすべてのサブタイプになるのと整合性取れなくないですか？

union型だと、無がNeverたり得るので、enumがそこへの拡張(或いは無名enumのようなunionがありえる？)とか諸々踏まえて

9:15 AM

case無しenumはまさに！という感じ

例の func foo() == func foo() throws Never func foo() throws == func foo() throws Error と整合してる。 (edited)

9:17 AM

なるほどー。でも enum は tagged union であって untagged union じゃないから、サブタイピングが働かないのでやっぱ変な気が。

まあそれはそうw

でも、 Optional でサブタイピングになってると考えると、 Never も特別扱いもありかも？

enumにサブタイピングサポート欲しいんですよね

それは禁断の道では・・・

それはそうか

9:19 AM

union欲しさのあまり定期的に気が狂ってしまう

ｗｗｗ

Optional の暗黙の型変換でもあれだけ嫌がってる @tarunon さんらしくないｗ

Optionalの暗黙変換がいやなのは、なんか

9:20 AM

コンパイラが死ぬほど頑張って不完全で壊れやすいものを提供してるのが

9:20 AM

納得がいかない、言語仕様として定義して、その枠組みでやるならまぁ、という感じ

9:22 AM

というか！swiftはサブタイピング周りゆるゆるなので

Ceylon に入信すると幸せになれるかもｗ https://ceylon-lang.org/documentation/1.3/tour/basics/ Foo? が Foo|Null で、 TypeScript と違ってちゃんとした静的型付け言語。

あぁ、やっと言語化できた

Top Type が Anything で、その下に Null と Object があって、 Bottom Type が Nothing でキレイです。

swiftのOptional、機能的にも型的にも明らかにHaskellのMaybeじゃないですか。なのに中途半端にunion Optionalに寄せるようなことしていて、

ですよねー。 Tagged Union なのに Untagged Union っぽく振る舞わせるから混乱を招くんですよね。

はー？クソって感じがしてる。言語機能でサブタイピング提供してサブタイピング周りガチツヨな言語になって、その上でMaybeとunion Optionalとが合体した最強の型

9:24 AM

そうなってくれるなら許しがあるし最高

nil はいいとしても、 let a: Int? = 42 は禁止して let a: Int? = .some(42) を強制した方が色々問題起きなさそう。

9:26 AM

それか、これもシュガー用意して let a: Int? = 42? とか。

9:27 AM

言語機能でサブタイピング提供してサブタイピング周りガチツヨな言語になって、その上でMaybeとunion Optionalとが合体した最強の型 そうなってくれるなら許しがあるし最高

なるほど・・・。 (edited)

9:29 AM

でもなんか破綻しそうな気が・・・。

9:30 AM

union enum Foo<T> { case a(Int) case b(T) }

9:30 AM

が Int|T として振る舞えるとして

9:30 AM

Foo<Foo<String>> が Int|(Int|String) になっちゃうと

9:31 AM

Int|String と等価になってネストが消えちゃう・・・。

9:31 AM

もし、ネストが消えるのが union enum の正しい仕様だとすると、 Optional を unison にしたら、ネストできなくなってしまう。

明示的に書けば可能だけど、書かなければ最適な位置に挿入される

let a: Foo<Foo<String>> = 42 ってやると、 let a: Foo<Foo<String>> = .a(42) になるってことですか？

はい

let a: Foo<Foo<String>> = .b(.a(42)) ではなく。

外側からのマッチングで振る舞って良さそう

9:35 AM

型的にはFoo<String>とIntがスーパータイプで、Foo<String>がStringとIntをスーパータイプに持ってる

9:35 AM

protocol oriented出来てるし、イケるのでは？と思ったけど

9:35 AM

思考漏れてそうだな

↑（代入）だけなら暗黙の型変換ととらえることができるので、優先順位さえ決めれば一意に決められると思います。

9:37 AM

オーバーライドして戻り値狭めたり引数広めたりしたときにも問題ないかな・・・。

9:37 AM

あと、今は Array や Optional でしかできないけど、 Covariant な型パラメータと組み合わせて問題ないか。

あー、その辺protocolまだ動いてないんでしたね、そう言えば

protocol 動いてないってどういうことですか？

理論的には問題ない気がしています。実装が大変なのは容易に想像できますが

9:39 AM

Update CHANGELOG.md to mention covariant method overrides by slavapestov · Pull Request #8380 · apple/swift

A lot of people reported bugs in this area so it's worth mentioning that Swift now allows subclasses to override methods in a base class with a more general type.

9:40 AM

classとOptionalのサブタイピングをoveride出来るがprotocolは無理

9:40 AM

ここに理論的に障壁あるなら無理ぽ

[SR-522][SR-629][SR-4161] Allow covariance in protocol conformance. by aleksgapp · Pull Request #8718 · apple/swift

I'd like to show you my naive attempt to allow covariance in protocol conformance. I'm completely unsure if this is an acceptable solution, but it works

Let me know what do you think of it? Resol...

すごいアイコンｗ

忙しいって書いてる、頑張って

https://twitter.com/taketo1024/status/872748764204720129

Taketo Sano (@taketo1024)

@koher また質問させてください

protocol extension による継承が演算子を使った場合だけ思うように動作してないようで困ってます

Gist を見て頂けると嬉しいです

https://t.co/RMk6KZXCex

10:42 AM

これに変更を加えて色々試してたんだけど、 protocol extension とか関係なく演算子のときだけ関数やメソッドと挙動が違うっぽい。 https://gist.github.com/koher/e3886feed159599f184be5f6328ee5e1 (edited)

bug?.swift

protocol の requirement から func + はずすと意図した動きになりますね

protocol×subclassだと宣言無しだと壊れてこっちは宣言有りだと壊れる？

11:27 AM

壊れる、というか、誓約ベースでGenericsを定義したが意図通りに動かない、か

11:27 AM

これ普通のfuncだと一見動いてるように見えるが、ライブラリが分かれるとダメ、とかあったはず。

あれ？コメントアウトするの間違えてた

swift4だとどれコメントアウトしても同じ動きっぽい

バグに見える

@tarunon Addable の + をコメントアウトしても <Int> にならないってことですか？

defaultですね

より謎な方に倒れましたね・・・。

Swift 4で + コメントアウトで <Int> になるような

3:29 AM

protocol Addable { associatedtype SomeType func sayHello() static func sayHello2(_ x: Self) -> Self static func + (a: Self, b: Self) -> Self } extension Addable { func sayHello() { print("hello<default>") } static func sayHello2(_ x: Self) -> Self { print("hello<default>"); return x } static func + (a: Self, b: Self) -> Self { print("add<default>"); return a } } extension Addable where SomeType == Int { func sayHello() { print("hello<Int>") } static func sayHello2(_ x: Self) -> Self { print("hello<Int>"); return x } static func + (a: Self, b: Self) -> Self { print("add<Int>"); return a } } struct Concrete<T>: Addable { typealias SomeType = T } let a = Concrete<Int>() a.sayHello() // prints hello<Int> _ = Concrete.sayHello2(a) // prints hello<Int> _ = a + a // prints add<default> ... why?

(edited)

3:32 AM

operator func だけ where が効いてない。 (edited)

staticでextensionに入れてもダメなんですね

そう。条件を揃えてみました。

3:34 AM

operator funcだけprotocol requirementの有無で結果が変わる。

3:35 AM

Xcode 8.3.3とXcode 9 beta 1ともに同じ結果

今やったらちゃんと変わった、なんだったんだろ

この手のextensionでfunctionの動きを切り替えるの、動きそうで動かないこと結構あるし

5:41 AM

ライブラリ化したら大体意図通りに動かなくなるんでやらないほうが良い感ある

5:41 AM

operatorじゃなくっても上手く行かないことあります

落としどころとしてはこんな感じでしょうかねぇ。

protocol Addable { func adding(_ other: Self) -> Self } func + <T : Addable>(lhs: T, rhs: T) -> T { return lhs.adding(rhs) }

(edited)

1

protocol Animal { func bark() -> String } protocol Cat { } extension Animal { func bark() -> String { fatalError("abstract") } } extension Animal where Self: Cat { func bark() -> String { return "nyan" } } class AnimalImpl: Animal { } class CatImpl: AnimalImpl, Cat { } CatImpl().bark() // nyan

単一プロジェクトの中だと一見上手く動くんですが、CatImplが別ライブラリにあると上手く行かない。

アクセスコントロールは internal ？

openで再現出来ます

6:41 AM

というかopenじゃないと、CatImplがAnimalImplのサブクラスに出来ない?

extension Animal where Self: Cat { func bark() -> String これがpublicならちゃんと動く。internalだとfatalError

7:14 AM

CatImpl.zip

3.04 KB

お

7:14 AM

ありがとうございます!

operator funcの選択がprotocol requirement有無で変わるの、JIRAを探してもそれっぽいのは見つけられないな。

@norio_nomura func testBark() { let cat: AnimalImpl = CatImpl() XCTAssertEqual(cat.bark(), "nyan") } (edited)

7:19 AM

これだと死ぬ

それは仕方ないのでは…

そうなんですよね

7:20 AM

この辺の罠を踏みやすい、なるべく避けたほうが良いなぁという所感

7:21 AM

全てのクラス型の宣言がGenericsになってれば多分大丈夫なんですが、遥か遠い

コンパイラのクラッシュ見つけたので再現しようとしたら意味不明な型を作ることに成功してしまった

7:31 AM

protocol A { } protocol B: Self.X { associatedtype X: A } class C: A { } class D: A, B { typealias X = C } D.X.self D.self D()

7:31 AM

これ通るの謎いw

通ってます？こっちではクラッシュ Xcode9

Xcode8で通ってます

7:33 AM

9だとクラッシュか

7:34 AM

protocol A { } protocol B: Self.X { associatedtype X: A } class C: A { } class D<Y: A>: A, B { typealias X = Y } extension String: A { } D<String>.self

これでも通る、ヤバみ高いw (edited)

D.X = Cなのに、D is B だから D is C になってしまってるってこと？

SwiftSandboxも通らないですね

protocol B: Self.X

7:34 AM

この行がやばいw

3.1.1なのでXcode8のみ？

inheritance で Self 使えるのはやばいなｗ

そこにSelfを書こうとするのがやばいと思ったw

なんか

7:52 AM

assoctypeにDelegateを置いて、functionの引数とか返り値でDelegateを使いつつ、自分自身もDelegateに適合していることを保証したかったんです。

すごいw

ワンチャンあるかと思ったら盛大にぶっ壊れたw

ちなみに master だとエラーでした。

test.swift:5:10: error: first type 'Self.X' in conformance requirement does not refer to a generic parameter or associated type protocol B: Self.X { ^ test.swift:5:10: error: inheritance from non-protocol type 'Self.X' protocol B: Self.X { ^

メッセージの意味がちょっと不明だけど。

assoctypeは当然struct入れれるから、具体型を想定してるっぽい

https://github.com/apple/swift/pull/10053 たぶんこの commit

Error when one associated type is constrained to another. by jrose-apple · Pull Request #10053 · apple/swift

(...is constrained to be a subtype of another) Previously the compiler would just mark the entry in the inheritance clause invalid and move on without emitting any errors; in certain circumstances ...

@applideveloper 「APIのfetcherを使う時」というのがどういうコードなのか例がみたいです。僕は、推論を使いすぎると可読性が落ちるので適宜明示的な型宣言を書いたりはしますね。どのくらい明示的にするかは感覚ですが。推論自体は一般には計算量的には重くないです。しかし、一部に組み合わせ爆発するようなケースがあるので、そういうのをふむ場合は明示したほうが良いです。

クロージャ毎にコンパイル時間計測できたっけ。出来るなら時間のかかる型推論がある場合にコードを記述する拡張機能とか作れないだろうか、と思ってる。

1

@omochimetaru さん、同じ考えを持つ人がいて嬉しいです、僕が少数派かと思ったので、具体例は、以下のようなコードです。 https://github.com/applideveloper/VideoPlayer/blob/master/VideoPlayer/Model/Fetcher/VideoPlayListFetcher.swift#L36 (edited)

applideveloper/VideoPlayer

Contribute to VideoPlayer development by creating an account on GitHub.

これはかなり遅いのではw

「クロージャ」と言っているのは多分クロージャ式のことですよね？僕は↓の 3 段階くらいがあるように思います。推測しやすいケース→ $0 等推測しづらいケース→ わかりやすい引数名を付ける { image in ... } （ image の型は Image ）名前からでも推測できないケース→型も書く { images: [String: Image] in ... }

{ image in ... }これが、{ image: Image? in ... } の可能性もあるのでgit diffで確かめたくないんですよ、後ろの？でわかるんでいいんですが (edited)

12:49 PM

$0なら、いいんですが、{ images: [String: Image] in ... } 複雑で、右辺ですぐに推測できないを省略するのは好きじゃないです (edited)

Image? の場合は { image: Image? in ... } とするルールじゃダメですか？ git diff で、というのはどういうことでしょう？

{ (response: Response<[Video], NSError>) in } { response in } (edited)

12:51 PM

レビューする時です。書くのは一回で済むのですが、読むのはなんども読むので読み手にコストをかけたくないんですよ (edited)

それはチームでわかりやすいコーディング規約を決めて、それを守るのがいいと思います。

12:54 PM

array.map { $0 * $0} みたいなケースまで型を記述するのはナンセンスですし、どこかにラインを定める必要がありそうですね。

12:55 PM

ちなみに、 Xcode だったら Option + クリックで型を確かめられますよ。

12:55 PM

GitHub 上だとどうしようもないですが。

開発を止めて、git checkout させて、Option + クリックさせるのを読み手に払わせるんのがコストなんですよ (edited)

ちゃんとレビューするならビルドは通してと思わなくもない

本格的にレビューするときは変数や型、メソッドの定義元に飛べないと効率が悪いので checkout してからレビューする方が良いように思います。

self.hogehoge の self の省略とかも、IDEなら色分けされるけどただのsyntax highlightだとされないとかあるし

12:58 PM

さっきの .responseArray { (response: Response<[Video], NSError>) in とかは僕も型を書きたい部分です

さっきの .responseArray { (response: Response<[Video], NSError>) in とかは僕も型を書きたい部分です

これは僕も同意です。こういう推測不能なものは型を書いた方がいいと思います。

これに関して言うと、SwiftTaskがPromiseリスペクトなので型推論が遅い、と言うのはありそう

1:00 PM

SwiftTaskのinitにクロージャを渡してるところから型を書いた方が良いですね (edited)

型推論でどのぐらい遅くなるかってのを説明できれば、推測不能なものは型を書いてくれるようになるのかなと (edited)

case Result<[Video], NSError>.Success(let videoArray): ここは case .Success(let videoArray): にしたいけど。

.responseArray { (response: Response<[Video], NSError>) in これを書いていたら case .Success(let videoArray): これの型が人間が推測できるので、省略しても問題ないと思います。 (edited)

はい、そうおもいます

関数毎にコンパイル時間計測して、一定時間以上かかると警告出るフラグがあるので

1:04 PM

それ入れて警告出たら型書け、と言うのが良さそう

例えば、極端な例で、型書くのが1秒で、型書かないで、毎回のコンパイルで型推論に1秒かかるなら、どちらを選びますかってなるんですよ (edited)

Other Swift flagsに -Xfrontend -warn-long-function-bodies=1000 ↑を入れれば警告出るようになります

1

1:08 PM

そこは単純に決めの問題で、1000はミリ秒ですね。

1:08 PM

警告出たら書く、は非常に分かり易い指標なので、導入も楽だと思いますよ

マシンスペックによってチーム内でブレが出そう・・・

1:09 PM

まあ、組み合わせ爆発で極端に遅いかそうでないかのケースが多いから、うまいしきい値を設定すれば問題ないかな？

低いマシンスペックの人がどんどん気付かずに不幸になっていくよりは、低いマシンスペックの人が自分で気づけてPR投げれるので

1:10 PM

まだ幸せだと思います

なるほど。

僕が言っても聞いてくれないので、その辺り発言力がある人が記事を書いてくれると嬉しいなぁ (edited)

悲しい…

コンパイル時間を奪うならまだいいのですが、推測不能なケースで、書くのは1秒なのですが、毎回読むたびに1秒以上人間に推測や、調べさせるのは好きじゃないです。 (edited)

個人的にはもはやGithubだけでレビューは、レビュー自体の信頼に関わるレベルでやるべきでないと思っていて

推測不能なケースはもちろん書くべきだと思うのですが、それが当然だと受け止められない環境だということですか？

そうですね(>_<)

それは辛いですね・・・

2,3行変更しました、以外はチェックアウトして一回ビルドするようにしてる。

1:16 PM

とりあえずコンパイル時間遅いのはどうでも良くなくって、これ日々の開発効率に直結してるんで

1:16 PM

往々にして推論が遅いコードは人間が読むのも大変なので、その方向で修正していければ良いかなぁ。

そうするのですが、iOSのビルドって時間かかるので、早くしたいのですよ

以前、僕が1関数で1分コンパイルに時間がかかってしまう化物を生み出してしまって、その結果さっきのコンパイル時間で警告出すフローを導入するに至りました。

2

1:20 PM

10分ぐらいコンパイル時間かかる爆弾を埋め込んで、チーム全体をコンパイル時間改善しようというムードに持っていくのはどうだろう

10分ぐらいかかる爆弾、作るのも大変そう（昼間にコンパイル時間かかる爆弾うっかり作ってしまったらコンパイラに複雑すぎると仕事を放棄されてしまった）

確かに作るの難しいですね

その人たちの上に掛け合って自分でコーディング規約用意して推進しちゃうとかですかね

その規約が間違ってた場合どうしたいいですかね？ (edited)

現場において規約が間違うって合意形成の問題だと思っていて、ベースとして有名な規約を選んで現場に合わせてカスタムすればそんなには揉めないと思います

1:27 PM

議論するコストを抑えるためのルール作りって話しなので

1:29 PM

大体のSwiftのコーディング規約はclosureの型は明示的に書こうってなってた気がする

有名な規約にそってない場合はどうしたいいですかね？チームの多数決で負けている、というか僕一人 (edited)

そこはぶつかってみるしかないのかなーと思います、相手の言い分も取り入れつつ完全に言い負かすとかしないで、限定的にこの場合は無名変数OKとか

1:35 PM

気にしてるのが1人なのであれば尚更主導で引っ張る気持ちで、メリットを伝えてお願いするのが良いかと

1:37 PM

それでも無理なら...(ry

ぶつかって負けたけど、計測して訴えたいと思います

1

(ryの先が気になる、転ですかね

2

負けたとき一瞬考えましたw (edited)

他人を変えるエネルギーより自分の環境を変えるほうが圧倒的に楽ですねｗ

型推論でどれだけ遅くなるかの事例集のデータって需要ありそう

これいいな Other Swift flagsに -Xfrontend -warn-long-function-bodies=1000 ↑を入れれば警告出るようになります

だいたいflatMapが遅い

1:57 PM

クロージャの返り値がジェネリクスで定義されたプロトコルに準拠していてかつ、式全体の型は左辺によって決定している、みたいなの

1:57 PM

要するにこれflatMapなんですが、これがメソッドチェインすると爆発します

2

flatMapのチェインは良くやるので、やらかしてそう

個人的にはもはやGithubだけでレビューは、レビュー自体の信頼に関わるレベルでやるべきでないと思っていて

2:02 PM

本格的にレビューするときは変数や型、メソッドの定義元に飛べないと効率が悪いので checkout してからレビューする方が良いように思います。

2:02 PM

ここらへん同意がある

2:02 PM

githubだと型定義に飛べないので、ブラウザを操作している時間を積み上げていくと

2:03 PM

checkoutする手間を上回るように思う

2:04 PM

型を書く１秒をケチったことで、積み上がっていく型を読み解く１秒の積み重ねで赤字になるのと同じ発想

checkoutはしますが、そのビルドが遅くなるのと、調べる必要がないInt,Int?型とか覚えてる型だったら書いて欲しい、Doubleなのかとかで時間を奪われたくない (edited)

自分は作業用とレビュー用で分けてcloneしてきて、両方ビルド回しちゃってます

あー

2:08 PM

それ良さそうですね

マシン分けたい

なるほど

wantedlyとかは1人2台でそういう体制とってるってどこかで記事見ましたね

つよそう

新マシン届いたら旧と並べて試してみよ

2:10 PM

speee社はビルド用のimacとmbpの基本2台体制らしいで

うらやましい

github のプルリクエストのブランチチェックアウトが Xcode に組み込まれたらいいのにな。

人間がすぐに推測できない不適切なケースでの型の省略って、相手の時間を奪ってるっていう認識がないと思うんですよね

fork先のブランチチェックアウトほしいですね

「人間がすぐに推測できない」ラインの感覚のズレの問題なのか

2:15 PM

とにかく推論させられるだけさせたい、っていう根本的な考え方の違いなのか？

2:16 PM

「リーディングに時間がかかる」っていう問題意識自体はわりと賛同されやすいと思うんですけどねえ

PRブランチ取得はこれ使うとremote足さなくて済む。 https://gist.github.com/piscisaureus/3342247

Checkout github pull requests locally

2

2:21 PM

XcodeのSource Controlはチェックアウト時にサブモジュールを取得してくれないので使えない。

hubコマンドを使うと git checkout https://github.com/.../.../pulls/1みたいな感じでcheckoutできたはず

ほ〜

2:23 PM

git configのorigin/fetchがそもそも

2:23 PM

マッチングパターンで書けるから

2:23 PM

PRブランチに規約切っとけばそういうことができるのか

2:23 PM

あ、いや、ちがうな

2:24 PM

これはfetchコマンドの対象を追加してるだけか

GitHubさんが融通してくれるのです。

なるほど。gitだけの仕組みだとどうなってんだと思った。

/head の代わりに /merge を使うとマージコミットも作ってくれるのだったかな？

https://hub.github.com/ 知らなかっただす。ありがとございます！

1

http://qiita.com/kaneshin/items/1deebde685c973fda6b8 これプロジェクト名.pbxprojのコンフリクトを直してくれるので便利ですよ brew install mergepbx (edited)

pbxprojファイルのマージが便利になるmergepbxをインストールするスクリプト書いた - Qiita

まず、作ったスクリプトファイルです。 https://gist.github.com/kaneshin/40d9331941682bf46f5d

mergepbxとは

[simonwagner/mergepbx](http...

いっつも ref名わすれて、 https://help.github.com/articles/checking-out-pull-requests-locally/ 行ってた。

if let convertibleType = type.self as? IntConvertible.Type { という書き方を知った。

import Foundation protocol IntConvertible { static func convert(from int: Int) -> Self? } extension Int { func convert<T>(to type: T.Type) -> T? { if let convertibleType = type.self as? IntConvertible.Type { return convertibleType.convert(from: self) as? T } return nil } } extension Date: IntConvertible { static func convert(from int: Int) -> Date? { return Date.init(timeIntervalSinceReferenceDate: TimeInterval(int)) } } 1.convert(to: Date.self) // "2001/01/01 9:00"

assoctypeだと出来なくて憤死するやつ

そそ

これって、type-erasureが要らなくなった未来のswiftでも多分出来ないままですよね

2:47 PM

どうなるんだろ、構文的な解決も難しそうだし

2:52 PM

if let seqType = T.Type as? Any<Sequence where .Element==Int>.Type とか？ (edited)

2:56 PM

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials

Can not encode/decode an entity which has Optional property.

swift - The Swift Programming Language

2:56 PM

特に書いてないけど出来るようになる…のかな

遠そう…

https://swift.org が落ちてる？

1

復旧してた

はじめまして Codableに準拠したクラス/モデルが、Optional<URL>のプロパティを持つときにdecodeできないのですが、どなたか既に試された方はいらっしゃいますでしょうか？詳しい情報とテスト用のplaygroundをgistにあげておきます。 https://gist.github.com/ken0nek/4a84f5fb1d13e4201907ddcdcccc3cf1 お助けいただけますと幸いです。

25行目の、try container.encode(ou, forKey: .ou) decode側がdecodeIfPresentなのでこちらもencodeIfPresentにするべき?

動きました、、ありがとうございます、、！

というかOptional<Codable>は Codableじゃないのかな…

試してみましたが、いまのところダメでした (edited)

https://github.com/apple/swift/blob/master/stdlib/public/core/Codable.swift#L3235-L3254

swift - The Swift Programming Language

オッ

10:48 AM

じゃあそのうち追加されますね

10:48 AM

やった

Conditonal Conformanceがないのでランタイムチェックだけどこういう感じですね

@tarunon @ikesyo ご丁寧な対応ありがとうございました

Conditional Conformance ってずいぶん前の Proposal だったからすっかり実装済みな気分になってましたがまだだったんですね・・・。

この間ConditionalConformanceのためのコードを書こうとして寝落ちして放置してたんですが、寝て正解でした。

1

OptionalならdecodeIfPresentじゃなくてdecodeでよさそうな？OptionalのdecodeIfPresentの場合は戻り値の型がT??になるから型が合ってなさそう（上の画像）

OptionalならdecodeIfPresentを使ったほうがいいのかと思っていました、、

typeがURL?.selfだと正常値がURL?で、decodeIfPrsent使うとキーがない場合そのOptionalとしてURL??として表現されますよね。 (edited)

11:07 AM

URL.selfを使うのが文脈的に正しい

Optional<Codable>: Codableになってない今の状況だと、try values.decode(URL.self, ...)がOptional<URL>に代入可能、っていうのが少しむずかしいかもしれない

11:09 AM

ifPresentはキーの有無があり得る場合のため、ですね

そうですね、キーがあってそこから変換に失敗する場合は普通にエラーになる

11:10 AM

そのケースでも失敗にせずnilになってほしいなら

11:10 AM

decodeをtry?で使う感じになるかな

try? values.decode(URL.self, forKey: .url) ?? nil

11:11 AM

って感じですかね

将来的にdecode(URL?.self, forKey:...) が通るようになれば、誤解は減りそう

今それで通るのでは？

@Ken

init(from decoder: Decoder) throws { let values = try decoder.container(keyedBy: CodingKeys.self) self.ou = try values.decode(URL.self, forKey: .ou) self.u = try values.decode(URL.self, forKey: .u) } func encode(to encoder: Encoder) throws { var container = encoder.container(keyedBy: CodingKeys.self) try container.encode(ou, forKey: .ou) try container.encode(u, forKey: .u) }

11:11 AM

これでOKです

11:12 AM

今はまだ、URL?がCodableじゃないって怒られますね

Optional: EncodableとOptional: Decodableなのになぜ……

ew

11:13 AM

結構乱暴なことしてますねw

ランタイムチェックとはそういうことですw

11:14 AM

WrappedがEncodable/Decodableじゃなかったらランタイムエラー

なるほど

この作りなら自動導出のでいけそうに見えるんだけどな

11:16 AM

Array/Dictionaryも同じことに今なってるっぽいです < ランタイムチェック (edited)

Himotokiよろしく、Array,Dictionary,Optionalをオーバーロードするなりして、通してるのかと想像してた

自動でいけますね。

encodeで try container.encode(u, forKey: .u) が u = "https://www.apple.com";、try container.encode(ou, forKey: .ou) が ou = { relative = "https://www.apple.com"; }; だけど try container.encodeIfPresent(ou, forKey: .ou) だと ou = "https://www.apple.com"; になるの、なんだか気持ち悪い気がしました

12:42 PM

relative は URL の Codable 実装から来ていそう https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/URL.swift#L1175-L1201

swift - The Swift Programming Language

僕が書いてるYamsのYAMLEncoderだと ou: relative: https://www.apple.com u: relative: https://www.apple.com で、どっちも辞書型になる。 (edited)

1:04 PM

JSONEncoderはURLを文字列としてエンコードする様に特別扱いして、URLのCodable実装を迂回してる。 https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/JSONEncoder.swift#L691

swift - The Swift Programming Language

1:05 PM

デコード時にもURLのCodable実装を迂回する様にしないと、上手くいかないはず。 (edited)

エンコードでOptional<URL>を特別扱いできていないのに、デコードでURLを特別扱いしようとして失敗する感じか。

なるほどそんなところで特別扱いが

シリアライズ先でサポートされているデータ型の場合、Swiftの型のCodable実装ではなく、シリアライザがそれらを特別扱いしないといけない場合があります。

2:26 PM

例えば、Date.encode(to:)は自身をDoubleとしてシリアライズしてしまいますが、シリアライズ先に日付型がある場合それでは不適当。 (edited)

Optional<URL>を特別扱いできていないのは、extension Optional: Encodableの実装 https://github.com/apple/swift/blob/890c2d50159892e5160481c6882e10a2fc75e249/stdlib/public/core/Codable.swift#L3249 で直接ラップされた型のencode(to:)を呼んでるから。

 var container = encoder.singleValueContainer() switch self { case .none: try container.encodeNil() case .some(let wrapped): try (wrapped as! Encodable).encode(to: encoder) }

swift - The Swift Programming Language

URLに加えてURL?を特別扱いしないといけなかった、ということですかね

しかしコレ、try container.encode(wrapped as! Encodable) ができないな。

自動導出のだとURL?でもstring直接でencodeされたのもちょっと気になる

コンパイラは try container.encodeIfPresent(url, forKey: .url) というコード生成するぽい。

3:04 PM

それだと Optional<URL> でも特別版を呼ぶ。

3:09 PM

これで動く https://gist.github.com/norio-nomura/3129a0c86aa0f836980766063fa90a7b/revisions (edited)

http://twitter.com/hiragram/status/874795647018258432

GitHub is where people build software. More than 22 million people use GitHub to discover, fork, and contribute to over 60 million projects.

3:12 PM

URLに加えてURL?を特別扱いしないといけなかった、ということですかね

Encoderの特別版が呼ばれる様に、containerのencode(to:)を呼ばないといけないですね。

Optional:Encodableとするなら、IfPresentで特別扱いするというのは直感に反してる気がするなぁ

3:13 PM

eocodeで特別扱い出来て欲しい

protocol P {} func f<T: P>(_ p: T) {} let int = 0 f(int as! P) // error: cannot invoke 'f' with an argument list of type '(P)'

ぬうう (edited)

3:18 PM

protocol P {} func f<T: P>(_ p: T) {} func f2(_ any: Any) { if let p = any as? P { f(p) // error: cannot invoke 'f' with an argument list of type '(P)' } }

func cast<T>(_arg:Any)->T使えばいけそう

3:21 PM

あーーー

3:21 PM

AnyP的なのにしないと

3:21 PM

Genericsが具体型を知れないからコンパイル通らない

ResultのAnyErrorと同じパターンかな

Containerたちのfunc encode<T : Encodable>(_ value: T…) throws達はジェネリックじゃない方が良かったのかな…

3:23 PM

DecodableもEncodableもassociatedtype無いし。

厳しさを感じる

self.ou = try values.decode(URL?.self, forKey: .ou) 今試したらこれは通ってた

3:30 PM

@norio_nomura try container.encode(wrapped as! Encodable)これなんですが

3:30 PM

Conditional Conformance入れば多分必要無くなるはずで

3:30 PM

そこまで大きな問題では無さそう。

Swift 4に入るのですかね…

入らない可能性がある…

もし入れば確かにwrappedそのまま渡せるから問題なさそう……

そして現状でもOptional<Any>になってるようなことはなく、Wrapped型ははじめからCodable準拠な気がしていて

3:33 PM

あー

3:33 PM

JSONEncoderの実装側が困るのか

funcの中でtypealias EncodableWrapped = Wrapped & Encodableとかしてその型にキャストとかという無茶できないかな

Wrapped & Encodable は error: non-protocol, non-class type 'Wrapped' cannot be used within a protocol-constrained type になります。

そっか無理ですね

let encodableType = Wrapped.self as? Encodable.Type (edited)

3:40 PM

とか?

キャストではダメぽい。

3:46 PM

AnyEncodableを作らないといけないとすると、かなりイケてない…

AnyEncodable無し出いける方法が無い…

4:03 PM

extension Optional where Wrapped: Encodable { public func encode(to encoder: Encoder) throws { var container = encoder.singleValueContainer() switch self { case .none: try container.encodeNil() case .some(let wrapped): try container.encode(wrapped) } } } extension Optional { public func encode(to encoder: Encoder) throws { fatalError() } }

これはダメでしたっけ

4:04 PM

ダメだった気がする

先日のprotocol requirementsがあるoperator funcの解決順がおかしい件、登録されてなかったらしようと検索したら、inamiyさんが登録してくれてた。 https://bugs.swift.org/browse/SR-5181

AnyEncodableを作らないといけないとすると、かなりイケてない…

AnyEncodableを作って呼び出せたとしても、Container側でAnyEncodableの中身をチェックして特別扱いが必要な型かどうかチェックしないといけなくなる。 (edited)

1

12:34 AM

どうせランタイムで型チェックが必要ならば、やっぱりContainer.encode(_:…)はジェネリックじゃない方が良い気がする。 (edited)

ですねぇ、Genericsに出来るのはConditionalConformが必要だ

とりあえずissue登録した。 https://bugs.swift.org/browse/SR-5206

コンパイラが生成するのと同じCodable実装をXcodeが生成してくれると間違いが減りそう。

http://twitter.com/hiragram/status/874803853593530369

extension String: Error {} ってなんかやばめな香りがするんだけど何が悪いのかは説明できない

1:41 AM

https://twitter.com/omochimetaru/status/874219905482014720

何でもthrowできるのはなぜ良くないのかも僕は説明できなそう便利やんを論破できない

1:42 AM

どうなんだ

catchするときに型に準拠したパターンマッチできないから弱いのと、パラメータ持たせられなくてErrorがprotocolである良さみを殺している

1:45 AM

恐らくこれをやると、大域変数にErrorを示すがError以外にも転用可能なString変数、と言うのが出現するので、まあNotification.Nameみたいに、RawRepresentableで具体型作って、それをError準拠させましょうね、というところが落としどころではありそう。

1:46 AM

少なくともErrorの変数がStringとしても使える状況は良くない。

catchするときに型に準拠したパターンマッチできない

これは他のHogeErrorでも同じじゃない？

パラメータ持たせられなくて

文字列１個だけ持たせるErrorだったら等価じゃない？

1:47 AM

大域変数にErrorを示すがError以外にも転用可能なString変数

文脈的にエラーじゃない場合もあるのにそれがエラーとして取り回されてるとニュアンスが曖昧になるっていうのは確かに問題だ

1:47 AM

普通 HogeError って型は絶対にエラー（失敗情報）を示すデータだもんね

1:48 AM

少なくともErrorの変数がStringとしても使える状況

これは逆じゃない？ String が Error として使えるんでしょ

いや、それがErrorのための変数がStringになってる、と言う状況を生むからダメ

1:49 AM

まあレギュレーション違反をコンパイラが見つけれるようにしておこうね、という話につきると思う

なるほど

Errorのための変数がStringになってる、と言う状況を生むからダメ

納の得した

1

納の得　ってなんて読むんだ

発音不能っぽい

ナツで変換できねえ

最the高みたいなもんだから考えなくてよし

それは「サイザコウ」でしょ

おもち君、発音できないと気になるタイプだった

そうだった

初音ミクかよ

おもちミク

N A T T O K U SPACE LEFT N O , って打鍵してんのかしら

YES

納の得

そこそんなに掘り下げると思ってなかったけど全然なんも考えてないよｗ

ちょっとおもしろかったんで気になった

寒すぎてSome<T>のほうが面白いよ

1

http://qiita.com/_tid_/items/271c1973b3043f6c55cb

寒すぎてSome<T>になった

>コンパイラが生成するのと同じCodable実装をXcodeが生成してくれると間違いが減りそう。 Source Editor Extensionでいけそうな匂いしますね

4:54 AM

CodingKeyが必要になったときに自前で書くのダルいので早めに作られてほしさある

Source Editor Extension

これって、各々作れる感じなんですか?

6:20 AM

Xcode Source Editor Extensionを試す - Qiita

**サンプルを追加しました => [XcodeSourceEditorExtension-Alignment](https://github.com/tid-kijyun/XcodeSourceEditorExtension-Alig...

6:21 AM

あとで試してみよう

現在のソースファイル内しか編集できない(ファイルを跨げない)という制約あるんですが、CodingKeyならそれで問題ないですよね

6:25 AM

tib/awesome-xcode-extensions: Awesome native Xcode extensions. https://github.com/tib/awesome-xcode-extensions なおサンプルはここらへん辿れば参考になりそう

tib/awesome-xcode-extensions

awesome-xcode-extensions - Awesome native Xcode extensions.

そうすると型推論の遅い型を追記してくれるエクステンションは作れないか…

厳しそう…。

Xcode 9でSource Editor Extensionは何か変わったのかな？まだチェックできてないや。

8:02 AM

とりあえずhttp://bugreport.apple.com へはフィードバック済み。>Codable実装コードの生成機能がXcodeに欲しい (edited)

1

What's new in Xcode 的なセッションはありませんでしたねー

8:11 AM

期待してたんですけど

Xcode 9 beta 1の変更が http://github.com/apple/swift に来た。

99%くらいのSwiftプログラマーが使わないであろう演算子の話 - Qiita

swift - The Swift Programming Language

↓のコメント書きながら改めて感じたけど、 Swift が Logic failure と -Ounchecked を裏表にしてるのほんとよく出来てる。 http://qiita.com/HaNoHito/items/841e9bd112ae6cb1c9a7#comment-337a4de3d810dbcc2e43 (edited)

概要

Swiftには、オーバーフロー演算(&+, &-, &*)と呼ばれる演算がある。オーバーフロー演算を使用することで、オーバーフローの判定とエラー処理が行わずに演算を行うことができる。その結果として、通常の演...

高速化のために &+ を使うシナリオにおいては、オーバーフローに伴うバグが排除されている事が検査済みであると仮定できるはずであるから、 -Ouncheked を使う事によって、 + を高速化すれば良い　って論理ですかね？

2:35 AM

「オーバーフローに伴うバグ」と「-Ouncheked でチェックが除去されるバグ」の範囲が一致していないから、微妙に論理が間違っている気がする。

2:35 AM

オーバーフロー演算子に関してだけ、 -Ounchecked にする、みたいな、コンパイラオプションが有ると理想的だ

もし Forced unwrapping や Array の subscript の範囲チェックは残したいけどオーバーフッローのチェックだけ無効化したい場合は、その部分だけを切り出してコンパイル単位を変えるのがいいんじゃないかな。

1

Rustみたいに複雑なことまで望まないけど、共通のジェネリックメソッドシグネチャで受け取れるけど実装は型に特化したものを複数作れる、みたいなの欲しいな。

SE-0110変わることになりそうね https://lists.swift.org/pipermail/swift-evolution//Week-of-Mon-20170612/037514.html

お、最近話題の↓にも言及されてる。 let (a : Int, b : Float) = foo()

5:18 AM

これなくすって言ってるけど、この前の @rintaro さんが言ってた↓はできなくなっちゃうのか。 let (a: x, b: y) = (b: 3, a: 2) // x: Int = 2 // y: Int = 3

https://bugs.swift.org/browse/SR-5204

5:19 AM

なぜか僕に振られたので整理したのですが、

5:20 AM

CodaFi_ がプロポーザル出している通り、無くしていこうぜっていう方向なんだと思います。

すごい、こういうの得意な人として認知されてる・・・

5:22 AM

↑ができなくなってもややこしさを解消できるメリットの方が大きそうですね。

https://bugs.swift.org/browse/SR-5162 この件もありますしねー

Discussion was leaning towards allowing (at least) the parenthesized form, but more discussion is needed. これは、 dict.forEach { ((k, v)) in ... } をできるようにするってこと？

dict.forEach { (k, v) in ... } それかこっちですね。けどこれだと、どうrationalizeするのか分からないです。

それだと曖昧性残っちゃいますもんねぇ。でも for だと for (k, v) in dict { ... } って書けるのに、クロージャ式では ((k, v)) になるのも微妙ですね・・・。

クロージャーのコンテキストタイプが一つの引数しか取らないときに、クロージャが { (なにか) in だったら、パターンとして扱う。というルールで解決できるのかな？

5:37 AM

dict.forEach { (k: Int, v: String) in ... } でおかしな事になりますね。

5:38 AM

だから let (a : Int, b : Float) = foo() これの話が出てきたのかも。

ですねぇ。

5:39 AM

やっぱり 1 引数 1 戻り値モデルを崩したあたりに無理があったのかなぁ・・・。

Slava の恨み節が泣けてくるｗ https://twitter.com/slava_pestov/status/875150641269571584

My next language will avoid all of these problems by not having function arguments. Or functions, or values

w

関数の引数のないwすごいw

個人的には可変長引数は廃止でもいいけど、 inout とか @autoclosure とか考えると 1 引数 1 戻り値モデルはきついのかなぁ。

5:47 AM

別に inout や @autoclosure が型の一部を成せばいいだけ？

5:48 AM

inout がキーワードなのに @autoclosure が attribute なのも違和感を感じる。

タプルパターンのラベルを無くすのと、シャッフルを無くすのは別の話にできるということに気づいた。 let (foo, bar) : (y: String, x: Int) = (x: 12, y: "test")

なるほどー。

6:20 AM

関数型の引数にはラベル付けられなくなったのに、タプル型だとラベル付けられるのも気持ち悪い気も。

6:20 AM

関数の引数がタプルでなくなったとはいえ、イメージ的にも見た目的にも似たものが異なる挙動をするというのはややこしい・・・。

可変長引数がないと、ArrayとかDictionaryのリテラルが使えなくなる気がする (edited)

可変長で受けるのも Array で受けるのも同じじゃないですか？（リテラルについて） (edited)

[1,2,3]この表現が、可変長引数の関数を呼んでたような

appendの3重呼び出しになればいいのでは

ExpressibleByArrayLiteral の init の引数が可変長じゃなくて Array になれば良くないですか？

ExpressibleByArrayLiteralですね

いや、[1,2,3]これがArrayをinitするために可変長引数が必要なので、

3:42 AM

appendを三回呼ぶにしても要素を可変長で解釈できる仕組みがいる

でも可変長引数の実体は Array だから、どこかで Array が組み立てられてるんじゃないですか？ (edited)

MakeArray(1) => { $0.Append(2) } => { $0.Append(3) }

コンパイラが生成する中間コードだけ可変長引数サポートというのは逃げ道かも知れない

可変長引数に渡すときに作られる Array は _allocateUninitializedArray っていう関数で作られているようです。 https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb#L985-L1009

swift - The Swift Programming Language

https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb#L942-L960 ここからどうやって_allocateUninitializedArrayに繋がるのか追えなかった…(´・ω・｀)

swift - The Swift Programming Language

-emit-sil で見ただけです。たぶん String.init(_builtinStringLiteral:utf8CodeUnitCount:isASCII:) (https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L726-L729) みたいなものですね。 (edited)

swift - The Swift Programming Language

6:16 AM

可変長引数に渡す前に caller 側で呼ばれて、要素のイニシャライズまでされるので、 init(arrayLiteral:) の前段階になります。

たとえ fatalError だけ代わりの方法で対処できたとしても、その他の Universal Error （メモリが足りないとかスタックオーバーフローとか）は起こりうるので、結局それらが発生したっ場合のログは送れないですし。

Swift could support a secondary, untyped propagation mechanism using "zero-cost" exceptions. ... However, this work is outside of the scope of Swift 2.0. https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#universal-errors とあり、将来的にサポートされる可能性もあるかと。

Roll back a portion of SE-0110 by rudkx · Pull Request #10414 · apple/swift

swift - The Swift Programming Language

7:12 AM

fatalErrorのキャッチみたいな事ができるようになっても秩序は保てるのか

7:12 AM

> koher - 今日午後4時9分非検査例外が悪いわけじゃなくて、非検査例外と検査例外を同じ仕組みでハンドリングさせたことと、 Exception を RuntimeException のスーパークラスにしてしまったこと（ Logic Failure を Recoverabble Error の下位においてしまったこと）、構文がイケてなかったことあたりが相互に影響して使い勝手が悪くなってしまったと思ってます。 Java であっても Exception, Error, RuntimeException がそれぞれ Recoverable Error, Universal Error, Logic Failure の意味合いで適切に使い分けられてたら問題がないはず。(編集済)

7:13 AM

Go言語の (err, ret) タプルと panic/rescueが近いのかな

Java の標準ライブラリの切り分けも、 NumbberFormatException を Logic Failure にしてしまったこと以外はそんなにまずくないと思う。

7:16 AM

ただ、 RuntimeException は Exception みたいに try / catch 書かなくてもコンパイラに怒られないやつという、使い分けではない挙動ベースでの理解の方が広まってしまって、サードパーティのライブラリでは混乱が大きい気がする。そして、その原因を作ったのは NumberFormatException かもしれない。

たしかに

もう一つは RuntimeException extends Exception なことかな。

そこはかなり無茶苦茶ですよねえ

7:20 AM

もしSwiftにfatalErrorのハンドラが入るとしても、既存のtryがそれを捕まえないようにしないと

Effective Java ですすめられてる使い分けはほぼ Swift のエラー分類と同じようになってる。

7:21 AM

既存のtryがそれを捕まえないようにしないと

うん、これが大事だと思ってるんだけど

7:21 AM

We do not currently support propagating exceptions through Swift functions, so changing catch to catch them as well would not be a major compatibility break.

とか書かれて若干不安。

・・・

#other-lang より

class User { var id: String = "" } let users: [User] = [] let idToUser = [String: User](uniqueKeysWithValues: users.map { ($0.id, $0) })

がエラーになる

error: cannot convert value of type '(@lvalue String, (User))' to closure result type '_' let idToUser = [String: User](uniqueKeysWithValues: users.map { ($0.id, $0) }) ^

@lvalue の扱いがおかしいのかな。 let id だと問題なし。

なぜー

クロージャに返り値型を明記したら？

Swift 4 環境作っとかないとこういうときさっと試せなくて不便だ

wandboxオススメです

お、 wandbox もう 4 になってるんですか？

wandboxって最近はSwiftもいけるのか

4.0-devですが

9:08 AM

つい2、3ヶ月前かな？

1

9:09 AM

https://wandbox.org/

let idToUser = [String: User]( uniqueKeysWithValues: users.map { u -> (String, User) in (u.id, u) } ) これはいけましたね。

9:09 AM

as (String, User) でもOK

謎だー。他に推論しようがない気がするんですが・・・。

@lvalue String を RValue である String に変換しなければならないところなのですが、それができて無くてエラーになっちゃってる感じですね。 master で確認してからバグリポート投げておきます。

ありがとうございます。

9:20 AM

さっきの書いてて、普通に↓があったら便利な気がしてきた。

extension Array { func dictionarize<Key: Hashable>(by key: (Element) -> Key) -> [Key: Element] { var result: [Key: Element] = [:] for element in self { result[key(element)] = element } return result } }

// [User] to [String: User] users.dictionarize { $0.id }

たしかに稀にやりますね　その変換

9:25 AM

パット見、 {$.id} をキーにした辞書ができるってことがわからんけど、メソッド名はさておき機能としてはあったら便利そうな気も (edited)

extension Sequence { func asDict<K, V>() -> Dictionary<K, V> where Element == (K, V) { return Dictionary(uniqueKeysWithValues: self) } }

これでいいんでないかと. (edited)

でもそういうあったら便利なやつって無限にあるからなあ

9:26 AM

users.map { ($0.id, $0) }.asDictionary()

9:26 AM

これもいいですね

問題は uniqueKeysWithValues が長すぎることな気がしてきた。 _ にしてほしい。

9:29 AM

後は、 toFoo じゃなくて Foo.init で変換を行うようになってることで、処理順序と記述順が一致しない（ Dictionary( を最初に書かないといけない）辛さが。

っていうかそのものがあった。 let dict = Dictionary(grouping: users) { $0.id }

そんなのあったのか

おお、知らなかった。

あ、けど Dict<String, [User]> になっちゃうや。だめだ。

ああ、そういうことか。

あ、グルーピングってそっちか

9:31 AM

まーそっちのほうが

9:31 AM

キー重複の可能性が明示的で

9:31 AM

そこの [Users] -> User はもっかい mapするほうが

やっぱ↓くらいが落とし所な気が。 let idToUser = users.map { ($0.id, $0) } => Dictionary.init

クリアなコードかも

Dictionary の値の map ってできたっけ？

あれ、できないんだっけ

9:32 AM

そろそろ簡単にできるようになったかな、と思ってた

Dictionary.mapは[(Key, Value)]になる

仮にできたとしても Dictionary(grouping: users) { $0.id }.mapValue { $0.first! } (edited)

9:33 AM

これはさすがに理解するのに数秒いるのでは・・・。

.mapValues(transform:) ですね

2

お、あるんですね。

9:34 AM

昔からありましたっけ？なんか昔自作したような・・・。

Dictoinary(grouping: users) { $0.id } .mapValues { $0.first! }

https://developer.apple.com/documentation/swift/dictionary/2894692-mapvalues beta でございます。

型で表せないだけで id が一意なことがわかってるケースは多いはずで、 (edited)

9:35 AM

やっぱ↓の方が直接的でわかりやすいと思う。 users.map { ($0.id, $0) } => Dictionary.init

一意じゃなかったらクラッシュしてくれる仕様が良いかな？

9:35 AM

=> は反則・・・

=> 標準ライブラリにほしい。

https://developer.apple.com/documentation/swift/dictionary/2894798-init はクラッシュですね。一意じゃ無かったら。 (edited)

おお、素晴らしい。

おお

Swift 5 の議論始まったら => を Swift Evolution に提案したら通らないかなぁ。応用範囲めちゃくちゃ広いと思うけど・・・。

functionに対して変換するようなfunctionを書きたいっていうのがある

@tarunon どういうことですか？

9:39 AM

func transform<T, U, X, Y>(_ f: (T) -> U, _ t: ((T) -> U) -> ((X) -> Y)) -> (X) -> Y { ... } (edited)

9:39 AM

ってこと？？

単純に、Functionは函数の名の通り

9:55 AM

mapとかflatMapとか相応の処理をして変換出来るはず

9:55 AM

クロージャーに対してそういう変換ができるなら、=>の役割は満たせるよなという感じです (edited)

うーん、いまいちわからないです。具体的に↓のよくありそうな => のユースケースを書き換えたらどうなるイメージですか？ foo() => { $0 + 1 / $0 } vector => { ($0.x, $0.z) } users.map { ($0.id, $0) } => Dictionary.init

1

ん？あれ

10:06 AM

とち狂ってる気がしてきた

10:12 AM

foo.map({ $0 + 1 / $0 })() vector => { ($0.x, $0.z) } //関数じゃない users.(map.map(Dictionary.init)) { ($0.id, $0) }

こうなる？いやこれわからんなw

なんとなく言いたかった事はわかったｗ

関数に map 相当のものが生えてたらってことですね。

関数にメソッド生やせないのはいいとして、Callableなタイプインスタンスを作りたくなるときはあります。 (edited)

それは、関数型の値をノミナルに名前付けしたいような時ですか？

10:18 AM

匿名タプルをさけて型名Struct使いたくなるのと同様に

そういうことなのかな？ Python でいう def __call__ を定義したい。

クロージャーを避けて型名がついたクロージャーを使いたい時があるのかなと

実行可能なオブジェクト

def __call__ だとそれ自体プロパティやメソッドの機能も使えるオブジェクトが作りたいパターン ( C++ でいうファンクタ(誤用

10:19 AM

の話しにも見える

// Kotlin class Foo { operator fun invoke(): Int { return 42 } } val foo = Foo() println(foo()) // 42

KeyPath が callable だったら users.map { $0.id} じゃなくて users.map(\.id) で ID の一覧得られるのにとか。

なるほど

10:21 AM

x に対して何らかのよくやる作用Fがあるとき、 g { f($0, x) } って書くパターンを g(x) と一般に短縮できるのか

10:22 AM

言語としてオペレーターオーバーロードがあるんだから

10:22 AM

関数呼び出しオペレータがあってもいいっすねえ

うーん、複雑さが増すデメリットに対して得られるメリットが小さいような？

protocol Function { associatedtype Arguments, Returns } かな

ですねー。 function type に準拠できるオブジェクト。とはいえ複雑になるのも確かなので、善し悪しですね。

TryParsecを少しいじってた時に、 typealias Parser<In, Out> = (In) -> (Out) ってやって、Parserに対するextensionとか作れなくて残念、って思ったことがあります。 https://github.com/tryswift/TryParsec/blob/swift/3.0/Sources/TryParsec/Parser.swift#L7

tryswift/TryParsec

TryParsec - Monadic Parser Combinator for try! Swift http://www.tryswiftconf.com/

protocol Function { associatedtype Arguments, Returns func do(Arguments)->Returns }

10:39 AM

こういうのでお茶を濁すのは良いと思うんですよね

10:39 AM

良いというか、仕方ないというか

SE-0110でRxSwiftのテストケースが死体の山になってる

ｗｗｗ

Xcode 9.0のSE-0110に影響あるところの

2:42 PM

コード生成が

2:43 PM

{ (x1, x2) in x1 + x2 } // as is { let (x1, x2) = $0; x1 + x2 } // to be なのは流石に笑う

2:44 PM

Observable.zip(e0, e1).map { (a0: Int, a1: Int) -> Int in a0 + a1 } // ↓ Observable.zip(e0, e1).map { (__val:(Int, Int)) -> Int in let (a0,a1) = __val; a0 + a1 }

これどうなんだw

[swift-evolution] [Core team] Addressing the SE-0110 usability regression in Swift 4 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037616.html

11:44 PM

Therefore, we will “back out” the SE-0110 change regarding function arguments from Swift 4. (edited)

めでたい

お

1:32 AM

じゃあRxSwiftのテストケース書き換えはちょっと待った方がいいな

おー

$0.key や $0.0 とかに書き換えたのは戻さないといけなくなるのかな

それはSwift3でも動いてたので問題ないはず

そうか $0, $1 になるわけじゃないから大丈夫か。

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-19-a

11:31 PM

この修正 https://bugs.swift.org/browse/SR-5031 が入ったスナップショットがようやく出た。

11:33 PM

SwiftPMで既存の Package.swift を残したまま Swift 4 向けのマニフェストを Package@swift-4.swift として使える様になったはず。

macOSで swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-19-a を使うには Xcode 9 が必要ぽい。

あー落とさなきゃ

3:57 AM

Xcode9から落とせるようになってないんやろか

なってないです。

ないですね、いま確認しました

4:03 AM

おうちMacと会社Macに同じ環境構築するの地味に面倒だ

わかる

特にXcodeのバージョンを

4:04 AM

8.2と8.3とBetaが要るのがだるい

4:08 AM

あーw

4:08 AM

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-19-a これ使ったら、RxSwiftのswift4.0リポジトリが開くとクラッシュするようになった

4:08 AM

笑う

ｗｗ

なんで死んでるのかもわかんねぇな、後で調べよう

Playground execution failed: error: Couldn't lookup symbols: __T0s18_HeapBufferStorageCMa

5:20 AM

なんか素のプレイグラウンドも動かない、何もかも間違ってる気がしてきた

お。いけたいけた

5:29 AM

プロジェクトからPlaygroundファイルを除去してうまくいきました。

5:29 AM

Playground周りが死んでるみたいですね。

swift-3.1-branch が地味に進んでるんだけど、Swift 3.1.xのオフィシャルリリースはまだ出るのかな。

class A { static func sharedInstance<X: B>(for type: X.Type) -> A { fatalError() } } protocol B { static var a: A { get } } class C: B { static var a: A { return A.sharedInstance(for: C.self) } }

-Osでコンパイラが死

12:07 PM

実行時にCが評価されるからいけると思ったけどダメだった

再現しない

ありゃ

11:57 PM

本当だ、再現しない

12:00 AM

うーん、またあとで探してみます

1

Xcode 9 beta 2は swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-19-a 相当という認識で良いのかな

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-19-aならSE-0110のロールバックはまだですよね

だと思います。

12:10 AM

これか。 https://github.com/apple/swift/pull/10414

As described in: https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html Specifically allow an N-ary argument function to be passed as an argument in a place where a func...

次かな

Chris Lattner 退職済みなのか。

Work History Tesla VP Autopilot Software January 30 - June 20, 2017

http://www.nondot.org/sabre/Resume.html#Tesla

おお https://twitter.com/NeoNacho/status/877882343452590080

🏡 vs. 🥑🍞 - Fight! (@NeoNacho)

The Swift migrator is now open source

https://t.co/hLRtz87qpw

2

これすごい https://swift.godbolt.org

11:25 PM

https://twitter.com/Catfish_Man/status/877995997846163456

David Smith (@Catfish_Man)

Check out how frickin' cool the optimizer is:

やば

"Roll back a portion of SE-0110" を含む swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-22-a が出てる

おっ

1:01 AM

あざす

おっ、swiftenv-apiも更新しよ

let a1 = Variable<(Int, Int)>((0, 0)) // Expression type 'Variable<(Int, Int)>' is ambiguous without more context let a2 = Variable<(Int, Int)>.init((0, 0)) // 可

1:16 AM

前からこんなんでしたっけ？

Variable の定義によるのでは

RxSwiftです

いや、init省略出来てたはず

1:22 AM

普通に、Variable((0,1))でも動いてたと思うけど

そもそも何がambiguousなんだって感じなんですが

w

Playgroundでクラッシュする原因やっとわかった

3:30 AM

Debugging symbolの方落としてたからだw

3:31 AM

でもDebugging symbolじゃないとそもそも、

<unknown>:0: error: unknown argument: '-index-store-path' Command /Library/Developer/Toolchains/swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-22-a.xctoolchain/usr/bin/swiftc failed with exit code 1

こんな感じでビルドできない、かなしいなぁ

https://twitter.com/bwilson493/status/872498709224976385 この辺関係あるかな

Bob Wilson (@bwilson493)

To use a https://t.co/LG45yvGKiw toolchain with Xcode 9 in the next few days, run Xcode with “-IDEIndexEnableBoltIndex NO

それっぽそう

3:37 AM

見てみます、ありがとうございます

いけたっぽい、iOS関連はビルドできないですがMac用ならいけました

3:45 AM

ありがとうございます~

うーん

3:53 AM

Tuple→複数引数への展開は許可されたけど

3:53 AM

複数引数(無引数)→Tupleへの変換は消えたままなので

3:53 AM

例えば複数引数のクロージャを{ _ in で引数を無視しようとすると怒られる

3:54 AM

{ (_, _) in ←こうしろ、と

{ _, _ in もダメですか？

そっちはOKです

1

複数引数→タプルはなくてもしかたない気も・・・

無くなって初めて、ここが双方向に変換されていたというのを知ったという

ですね。意識的に「複数引数→タプル」で変換したことない気がします。

うーんよくわからん

4:41 AM

タプルの展開周りまだバグってる気がします

Debugging symbolの方落としてたからだw

Debugging symbolのpkgだけでは足りないものがあるので、普通のpkgインストールしてからDebugging symbolのpkgを入れてる。

7:41 AM

Debugging symbolのpkgにはswiftc(swiftへのシンボリックリンク)が無いので、Xcode添付のswiftc(swift)が使われていたのだと思う。

なるほど

あと、Playgroundだと暗黙で-swift-version 4になるけど、Xcodeプロジェクトだと設定でSWIFT_VERSIONを4.0にしないとSwift 3.1と同じ挙動になるので「あれ？」ってなったりする。

SwiftVersion、Xcode9で開いた場合は4、Xcode8で開いた場合は3みたいにしたいけど

7:46 AM

これ出来ないですよね

7:47 AM

地味にAppKitとかUIKitの変更がしんどくて、#ifで切り替えたいけど無理そう

SWIFT_VERSION =3.0でXcode 8と9をコード内で区別するには #if swift(>=3.2) を。

おお

7:59 AM

ありがとうございます、助かります

Linux版も-swift-version 3はSwift 3.2 (edited)

あれ、前は困ったなと思ってたんですが、Xcode9beta2からは

2:15 PM

Swift3.2だと古いAppKit参照してるのかな?

なんか一部だけ新しくて一部だけ古いみたいな妙な感じがする、どこか壊れてるかな

なかなか大変そう。 [swift-evolution] [Update] Updates to SE-0166 and SE-0167 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037672.html

「デーコード対象がオブジェクトグラフ内で既にデコード済みの場合は、コピーではなくその参照を返す」とか、明文化するらしい。

protocol KeyedDecodingContainerProtocol { /// Decodes a value of the given type for the given key. /// /// If the encountered value is a reference to an existing object previously decoded as part of this object graph, this will return the existing object instead of a new copy of it. func decode<T : Decodable>(_ type: T.Type, forKey key: Key) throws -> T }

YAMLには別オブジェクトの参照を表す方法があるけど、他にもあるのかな。

5:03 AM

Swiftでの型とシリアライズ先の両方が参照型に対応してないと実現できない。

JSONには参照機構は無いですねえ

4:12 AM

シリアライズモデルに参照機構がある場合、(ID, Object)のペアのデコードと、 Idを示すポインタとかハンドルをデコード先言語の参照に差し替える処理を、2パスにわけないと

4:12 AM

参照先がシリアライズ上、参照箇所より後ろに出てくる場合に対応できないので

4:13 AM

この手のデコーダでは参照は取り扱わないほうが無難だと思うけど・・・

ちなみにYAMLはこんな感じ https://gist.github.com/bowsersenior/979804

A demo of YAML anchors, references and nested values

参照を渡す場合、structだと同一ポインタを指すことになるのかな

Codableな型がclassでなければコピーするしかないですよね。

うーん、コピーするくらいなら、classじゃなければコンパイルエラーにした方が良いのでは？と言う気がする

取り出した値ツリーとしては正しいけど・・・

2:14 PM

変更しなければ等価。

2:14 PM

でも、循環がある場合は無限再帰するね

先のYAMLの例だと、デフォルト値を参照して使いまわしています。その場合、デフォルト値がSwift側でも参照として復元されなければいけないかどうか、というのは疑問があります。

yamlは参照として復元されることを保障してるわけではない、ならコピーで良さそう

2:19 PM

それならclassもコピーで良いのでは…循環か…

JSONSeiralizationがNSArray,NSDictionary,NSNumber,NSStringを中間形式として使う様に、たいていのシリアライザは一旦中間形式にしてそう。

2:20 PM

中間形式をValueTypeにしてしまってると、参照型のEncode/Decodeで参照関係も復元するとか、全く無理になってしまう。 (edited)

2:23 PM

僕が書いたlibYAMLのラッパーでも中間形式をenumにしてるので、かなり変更しないと無理だ。

あー、中間形式がclassでさえあれば参照関係は十分復元でき…でき…

2:23 PM

出来ないですよね、モデル側もclassじゃないと

できないできない

2:23 PM

うん。

2:24 PM

値型に焼き込むところで再帰する

ポインタぶち込むとかそういうマッドな事はやりたくないしなぁ

モデル、中間形式、シリアライズ形式の全てが参照型をサポートしないといけない。

indirectは型の再起についてだけだから、値型に再起構造を盛り込むものではないし

2:26 PM

内部的にはポインタだからゴニョッとやれば出来るかな？

それ無理やりやると、

2:28 PM

それを含む値をコピーしようとしたときに

2:28 PM

コピー処理が内部で再帰ループしそう

ひぁ

2:29 PM

無限に借金タワーが積み上がるやつだ

Realmのオブジェクトをシリアライズしたいとか、そんな要望があったのかなあ。

それは間違いなくありそう

extension Equatable { /// 一つ以上の同型の値を受け、そのいずれかが self と一致するか否かを返す func isAny(_ arg1: Self, _ args: Self...) -> Bool { return arg1 == self || args.contains(self) } } if intVal.isAny(53, 13, 34, 42, 12) { // something }

これを、 switch intVal { case 53, 13, 34, 42, 12: // something default: break } これと同等になるまでインライン最適化して欲しいんだけど、無理そうなので可変長引数に絶望しています。

なるほど

6:33 AM

可変長ジェネリックパラメータが入ればいけそうですね (edited)

6:34 AM

そっちなら引数の個数とそれぞれの型に応じて特殊化されるはず。

そうなんですよねー。

現状だと

6:35 AM

1引数版から5引数版ぐらいまで

6:35 AM

ジェネリックメソッドをオーバーロードしておくのが良さそう

extension Equatable { func isAny(_ a1: Self) -> Bool { return a1 == self } func isAny(_ a1: Self, _ a2: Self) -> Bool { return a1 == self || a2 == self } func isAny(_ a1: Self, _ a2: Self, _ a3: Self) -> Bool { return a1 == self || a2 == self || a3 == self } // ... 続く }

gybつかってできないですかねｗ

6:37 AM

自動展開

6:37 AM

Swiftソースのメタ生成ならgyb使うのが一番良さそう

SwiftPM がコードジェネレーション的なフェーズをサポートしてくれればいいんですけどね。

あ〜

6:38 AM

今ってユーザーシェルスクリプトを挟む余地とかもなかったですよね確か

ないですね。 swift build をラップするスクリプトを組まなきゃいけないと思います。それにしても、生成されたソースを Sources に置くとすると、 .gitignore がめんどくさいとかいろいろ問題あって、なかなか痺れます。

ウーム　早く入って欲しい。

6:41 AM

生成されたソースもコミットしちゃっても良い気はしますよ

6:42 AM

ライブラリユーザーにとってはgybいらなくて済むし

それもアリですね。

生成されたソースもコミットしちゃっても良い気はしますよ

むしろこれやらないと SwiftPM で間接的に依存性解決されるときにうまく動かなさそう。

ですね。ライブラリとして配布出来ないですね。

@koher

むしろこれやらないと SwiftPM で間接的に依存性解決されるときにうまく動かなさそう。

なのでrintaroさんが

SwiftPM がコードジェネレーション的なフェーズをサポートしてくれればいいんですけどね。

と言っているのだとおもいあｍす

ああ、もしかして現状の話じゃなくて、 gyb が使えるようになった前提でも ignore しなくていいっていう意図だったのかな？

7:26 AM

「 swift build をラップするスクリプトを組まなきゃいけないと思います。」なので現状の話かと思った。

現状は swift build ラッパー書いて前段でジェネレートするにしても、生成後コードをSourcesに入れてコミットしなければライブラリとして公開できない。 swift build がネイティブでプリビルドスクリプトをサポートしてくれれば、その苦労が要らない。

もう一つ、その同じラッパー + gyb をインストールした人にしか使えないライブラリにするという条件付きにして、生成物である.swiftはコミットせず.gybだけコミットするパターンがありえるがその場合の.gitignoreはだるい　ってパターンも考慮してるかなと思った

現状での話で言えばソースもコミットしないと SwiftPM 対応してると言えないし、将来的に gyb が組み込まれた前提だとインストールしなくても SwiftPM 自体に付属してるだろうから追加インストールは不要そう。 .gitignore もそれに合わせて生成。 (edited)

7:32 AM

最初のコメントは、現状でソースコミットしないという選択肢はないんじゃないかという意図です。

現状でソースコミットしないという選択肢はない

同意しました。

1

swift-evolution に投稿されてる↓おもしろい。 Never が bottom type になれば ! の代わりに↓ができる。 let last = array.last ?? fatalError(“array must not be empty”)

お、なるほど

で、今これをやりたきゃジェネリックな fatalError をオーバーロードすればいいよ、と。

あれ？ってことは

2:41 AM

return 文って Never 型の式なのか。 (edited)

return は Void では？

kotlinだと

2:42 AM

val last = array.lastOrNull() ?: return 3

2:42 AM

とかできるんですが

2:42 AM

return　文はその実行以降に制御を返さないので

2:42 AM

Never 型の値として型評価できるはず

2:42 AM

fatalError と同じ理屈です

ああ、そういう意味か。

式の評価が実行の中断を意味する = 値が無い = Never

returnなるほど

Kotlin の ?: return は特別扱いじゃなくて return が Nothing 型の式になってる？ (edited)

そこまではわからないですフロー解析と型チェックが合体してるイメージだったので

Kotlin は制御構文が式だから return が Nothing 型の式の可能性も十分にありそう。

なるほど。

let last = array.last ?? fatalError(“array must not be empty”) に関しては、 ! だと Ligic failure で -Ounchecked で消せるけど↑は消せなくなっちゃうから

2:46 AM

やっぱり ?? fatalError よりも専用の演算子があった方がいいと思う。

2:46 AM

コメント渡せるやつ。

guard let v=ov else { return } let v=ov ?? return Neverがbottomかつreturnの左側がNeverならguard使う頻度減る

はい。まさにそれが Kotlin でよくやるやつです。

2:51 AM

throw とかも書けます。

むしろ if文で returnしてるとIntelliJが ?: に書き換えようぜ〜〜〜って騒ぎ出す

?? って T? ?? T ですよね右辺Neverができる場合どうなるのかよく分からない

throwも左側Neverだ、たしかに

@t.ae NeverはbottomTypeだから Never is T でなんも問題ない

2:52 AM

Neverはあらゆる型であるわけ

ああ、それで評価値としてはTがとれそうだけどNeverで中断されてるから〜ってかんじですか。

そうそう。

2:53 AM

取れると思ってその先をコンパイルしても破綻しないので逆説的にいかなる型でもあると言えるって感じ

なるほど。

↓できた。 // Kotlin fun main(args: Array<String>) { val foo: Nothing = return }

何者でもありそうなAny型こそが何者でも無いので面白い

やっぱ return 式の型が Nothing なんだ。

なるほど

swiftの ?? って右辺の評価は左辺がnilであったとき初めてなんですかね

@autoclosure だからそのはず

うんだから auto closure になってるんじゃなかったかな

そうか。auto closureだから遅延するのか

auto closure が遅延評価を意味して短絡評価と対応するの面白い

&& とかも右辺値が @autoclosure で短絡評価を実現してる。

2:57 AM

実際にはクロージャ介さずに効率的に実行してるだろうけど、昔ながらの && の短絡評価を型システム的に @autoclosure で表現できてるのがおもしろい。

自前で実装する二項演算子も右辺を遅延させられるのは良いですね

2:59 AM

(この先使うかは知らない)

&& と ?? の associativity は違うっていう豆知識。 && は left、 ?? は right。

((a ?? b) ?? c) だと評価が増えるからですかね？

おお

ですね。 && が left なのは C 合わせだと思います。

考え中だけど && も短絡の最適化では？

4:05 AM

left: (a && b) && c right a && (b && c) あれ、ちがうか

4:05 AM

!a で b && c を捨てたいんだから・・・

func || (condition: Condition, val: String) -> Condition { return condition.addingOr(string: val) } condition = condition || ">= 42" || "< 12"

こういうことをしたい時に right だと出来ない。

あーなるほど

4:08 AM

そうかオペレータの結合順はオーバーロードの探索よりも先なのか

(a && b) && c で a が偽の場合、二つ目の && は実際には評価されないのだけど、それは最適化の範囲でやってるみたいです。(&& に副作用があるときは最適化されないです) (edited)

なるほどなるほど。

&& が left なのは C 合わせだと思います。

なんで C は left なんだろう？

考えたけど分からなかった。Cは演算子オーバーロードなくて、&& や || は同じ precedence の演算子は無いので、本当にどっちでもいいと思うのですが。なぜ left に決めたのか。。

right の方が自然ですよねぇ・・・。

三値論理の可能性を考慮したとか？(左結語じゃないと問題が起こるかは知らない)

LL(1) 再帰降下パースでシンプルに実装できるとかそういうのあるかしら

4:22 AM

https://ja.wikipedia.org/wiki/再帰下降構文解析

%E5%86%8D%E5%B8%B0%E4%B8%8B%E9%99%8D%E6%A7%8B%E6%96%87%E8%A7%A3%E6%9E%90

4:24 AM

Cとかだと素朴な実装上の都合だったりするのかなあと思って。

どうだろう、 right なら疑似コードで

func parseExprAnd() -> Expr { let lhs = parseExprAtom() if !consume("&&") { return lhs } let rhs = parseExprAnd() return ExprAnd(lhs, rhs) }

これで済むけど、 (edited)

4:30 AM

left だとここで畳み込みする必要があって実装的には複雑になりそうな。

たしかに。そのシンプルなパターンだとrightになるんですね。

func parseExprAnd() -> Expr { var result = parseExprAtom() while consume("&&") { result = ExprAnd(result, parseExprAtom()) } return result }

そうでもなかったｗ

あー、 bool がないのは関係あるかも？

あたまぐるぐるしてきた

Foo *foo1 = ...; Foo *foo2 = ...; Foo *foo3 = ...; Foo *foo = foo1 || foo2 || foo3; (edited)

4:37 AM

のときに foo がどうなってほしいかとか関係ある？

4:37 AM

NULL である可能性を考慮して。

4:38 AM

あれ？結合順は関係ないか？ (edited)

4:38 AM

ってか元の omochimetaru の bool 発言消されてるｗ

(foo1 || foo2) || foo3 でも foo1 || (foo2 || foo3) でも左辺優先は変わりないような。

ですね。

4:40 AM

となるとパフォーマンスを除けば副作用がある場合しか関係ないかぁ。

副作用も結合順は関係なくないですか？

短絡だからそうか

4:42 AM

単に (a || b) || c だと a が true のときに 2 回評価されるけど、 a || (b || c) だと 1 回という違いしかないのか。

let fooDefault = 12 public func foo(x: Int = fooDefault) { // error: let 'fooDefault' is internal and cannot be referenced from a default argument value }

Swift4 で public な関数の引数デフォルトに internal 以下の値が使えなくなりました (edited)

正しい感じがする

影響受けるひとそれなりに居る気がする。

逆に今までどうやって動いてたんですかこれ

呼び出し側がinternalのシンボルを実は見えていたってことですよねえ

感触としては引数なしのオーバーロードが同時に定義されてたように見えてた？

かき心地としてはそうだね

7:49 AM

でも実際にエントリポイントが作られてるわけじゃないからバイナリとしてはそうじゃないはず

ふむ。

7:52 AM

実際のところデフォルト引数が呼び出し側からアクセスできなかったとしてあんま問題ない気もするんですよね。呼び出し側の影響を受けるのは #line とかくらい？

これが導入されたコミットのコメント見ると、Swift4ではデフォルト値の扱いが変わったみたいですね。 https://github.com/apple/swift/commit/d65d1d25f9a9248ac28494070e7246e603f60c43#diff-efafad982d57180bb1e93bfb6d2cdc0dR1213

Sema: Diagnostics for @_inlineable, @_versioned and Swift 4 default a… · apple/swift@d65d1d2

…rguments model Piggybacks some resilience diagnostics onto the availability checking code. Public and versioned functions with inlineable bodies can only reference other public and internal enti...

うーん、イミュータブルな値だったら別に使えてもいい気もするけどなぁ。

private let maxN = 42 func foo(_ x: Int, max: Int = maxN) -> Foo { ... } func bar(_ x: Double, max: Int = maxN) -> Bar { ... }

そもそもデフォルト値の評価タイミングは

複数箇所で使うから 42 とハードコードしたくない場合とか。

関数実行時のタイミングだが、宣言側の文脈で解釈可能な値が出てくるみたいな

7:58 AM

そんな感じの動きだった気がする

7:58 AM

関数実行側の文脈で解釈可能な値に変わるのかな

むしろ以前はデフォルト引数は呼び出され側で評価されてた？

https://twitter.com/UINT_MIN/status/879459579666366465 いちおう Rationale

Jordan Rose (@UINT_MIN)

@DevAndArtist @slava_pestov @SmileyKeith @jckarter This restriction

allows default arguments to be inlined (eventually)
allows showing the default in the module interface (eventually)

In Swift 4 mode, default argument bodies are inlined into the caller.

そのはず

その場合 #line はどうだったんだろうってなる

そうそう、#lineと#fileとか、こいつらの挙動からCaller側判定だろって思い込んでいて、

8:02 AM

ひどいめにあった

その辺は特別扱いされていたのは確かで、

protocol Foo { static var value: String { get } } extension Foo { static var value: String { return "real" } } extension Foo { static func printValue(_ value: String = Self.value) { print(value) } } struct FooImpl: Foo { } FooImpl.printValue() // "real" protocol Test { } extension Foo where Self: Test { static var value: String { return "test" } } struct FooTest: Foo, Test { } FooTest.printValue() // "test"

8:03 AM

↑実験用コード

https://github.com/apple/swift/blob/master/include/swift/AST/Expr.h#L2820-L2825

https://github.com/apple/swift/blob/master/include/swift/AST/DefaultArgumentKind.h#L37-L46

swift - The Swift Programming Language

これをTestを別frameworkに分離させると

え、#line って呼び出し側の行数が出るんじゃないの？

挙動が変わる

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

swift - The Swift Programming Language

8:06 AM

これ以外は callee 側で初期化するっていう形だったと思います。(嘘でした) (edited)

8:07 AM

それを caller 側に統一した（したい）って事なのかな？ (edited)

ええっ、そうだったのか・・・

8:07 AM

呼び出し側では何を渡してたんだ・・・？

謎

8:08 AM

これ実際の動きと直感的なイメージが乖離していて辛いことの1つだったんで、caller側に統一してくれるのは嬉しい

1

@tarunon の書いてるのは printValueの Self.value の評価値が変わるってことかね

8:09 AM

Swift3ではTestのほうのファイルがわかれていると、callee側で評価されているから

8:09 AM

realが出ちゃったと

8:09 AM

ああ、呼び出され側で評価ってそういうことか　実行時の評価のことじゃなくて (edited)

ああ、デフォルト値を取得する関数が別で定義されていたのでした。

マジ

8:10 AM

あーまあーなるほど

8:11 AM

それならこのようなことは起こってはいなかったのか > 呼び出し側がinternalのシンボルを実は見えていたってことですよねえ

8:11 AM

デフォルト引数を埋めるためのだけのAPIが別途空いていたならおかしくはない

%operand = ... %func_print = function_ref Swift.print %func_separator = function_ref Swift.print.default.separator %func_terminator = function_ref Swift.print.default.terminator %separator = apply %func_separator() %terminator = apply %func_terminator() %result = apply %func_print(%operand, %separator, %terminator)

こんな感じか。 (edited)

おお。

やばいコード思いついた。 let a: Never = preconditionFailure() print("Hello") print(a) これ、 -Ounchecked でコンパイルしたら preconditionFailure() をすり抜けるから Never を返す関数の戻り値を使うコードが実行されてしまう。

これって preconditionFailure 自体が消えるはずですけどaはどうなるんだろう？ (edited)

ちなみに実行結果は Segmentation fault: 11

ていうか Ouncheckedのアンチェックドは

8:33 AM

そういう意味なのでは？

assert でリリースビルドだったら？

そもそも

8:35 AM

クラッシュするかもしれないし

8:35 AM

aが空ストレージになるかもしれないし

8:35 AM

aのストレージすら消えて一個下のスタックフレームの上部を見るかもしれないし

8:35 AM

もっとアグレッシブに、その先のprint自体削除するかもしれないし

8:35 AM

未定義動作っていうのは何をやってもいいって意味でもあるから。

8:36 AM

その仮定をおけるからこそ、前提条件が常に正しいことを前提に最適化がいろいろ工夫できるのだし。

assertionFailureはVoidだった

assert系のファミリーはuncheckedでも削除されないんだっけ

いや

8:36 AM

assert は -O でも削除される

8:37 AM

fatalError は削除されない

逆か

8:37 AM

削除されるからこそ

8:37 AM

脱出を前提に置けないのか

preconditionFailure っていつ使うの？よく意味わかんなくない？

8:37 AM

precondition はわかるけど

ですね。 uncheckedでしか消えないpreconditionFailureがNeverなのはうなずける

8:37 AM

@koher switch

logic failureでバグってるときじゃないスカ

@t.ae if の条件で書けないときってこと？

switchでdefault: preconditionFailure()とかやります

precondition を使わずに preconditionFailure を使うとき。確かに switch はあり得るかも。

8:39 AM

default: fatalError() より default: preconditionFailure() の方が筋が通ってるね。

8:39 AM

なるほど。

if <condition> { preconditionFailure() } の形でかけないケースですよね switchはたしかにそう

8:39 AM

↑の形になるときは precondition を普通に使えばよいから。

うん。

お、わかった

8:40 AM

Result.flatMapError { preconditionFailure() } とか。

なんで flat ？

mapErrorか

8:41 AM

Either<T, HogeError> . mapError < T -> Never > の式は Either<T, Never> になるし

8:41 AM

型的にも意味のあるロジックになる

8:42 AM

なんらかの前提条件でHogeErrorrが絶対に入ってないことがわかってるときのキャスト。

それは Either<T, Never> じゃなくて T にしてほしいねｗ

たしかにｗ

そこらへんが Union だとキレイだよなぁ

8:42 AM

T|Nothing は T になるから。

でもさっきのなら fatalError でいいのか？

絶対に実行されない文で preconditionFailure()使うメリットがあるんです?

8:43 AM

突入しないならfatalErrorでもなんでも良いのでは

fatalErrorは -Ouncheckedでも消えない？

絶対に実行されないことを明示するために preconditionFailure を書くんじゃないでしょうか。

8:43 AM

fatalError は消えない。

なるほど

ライブラリでユーザー入力の値を確認したいときとか

現実的には、消えてしまうメリットはないし

fatalErrorは、ある意味、ある条件で死ぬっていう明示的なコードなのか。

8:44 AM

preconditionFailureは、その条件は絶対に成立しない

8:44 AM

表明になる

preconditionFailure を使うべきケースではすでに条件分岐は終わってるから

万人に理解できるものではなさそうだ

削減できてうれしい理由はないし

8:45 AM

コード上、ここには絶対に到達しないということを明示するということを除けば

8:45 AM

メリットはなさそうに見える（むしろ、バグで万が一突入したときに、 -Ouncheckec で消えてしまうデメリットがある）。

@koher いや

8:46 AM

preconditionfailureは -Ouncheckedで削除されるってことは

消えてしまうために

分岐の中身が消えるから

8:46 AM

分岐自体が消えるチャンスが有る

8:46 AM

最適化で

うーん

fatalErrorは絶対に消えないってことは、fatalErrorでクラッシュする可能性を残さないといけないから分岐が削除できない

switch の default だと意味がなさそうだけど、何らかの最適化ができるケースはあり得るか。

まあでも解析できそうなif文のケースでは precondition を使えってなりそうだけど。

switchの最後に使うのか

fatalErrorに条件付きのがないのもそのせいっぽいですよね

val nonnull = nullable ?: preconditionFailure()

8:49 AM

みたいなコード（ Kotlin なのか Swift なのか）で最適化上の意味があるのか。

お

あー

implicitly系が最適化オプションで消滅したほうが良いのではという気がしないでもない

じゃあ、 Never as a bottom type

8:50 AM

ができれば

8:50 AM

let foo = fooOrNil ?? preconditionFailure() (edited)

8:50 AM

が

@tarunon !とかは -Ouncheckedできえるらしいよ

-Ounchecked で let foo = fooOrNil! と等価になるのか。

8:52 AM

それは素晴らしい！

なるほどー

ですね

8:53 AM

お？ってことは

8:53 AM

前話してた ! 使うなら理由をかけ　が

8:53 AM

できる？

うん

preconditionFailure は理由わたすところあるんだっけ

ある。

! 演算子禁止の機運がｗｗｗ

メッセージ渡せる。素晴らしい。

try! に対しては

8:54 AM

try? xxx ?? preconditionFailure(reason)

8:54 AM

これでOKか

ですね。

それだと例外に入ってる情報が消えない？

あー

8:54 AM

確かに。

try!なら例外情報出せるんでしたっけ

なんかダンプされた気がするようなしないような

むー、エラー情報と ! の理由を両立させるの難しそう。。。

!禁止、正直あんまり生産性無いなと最近思うようになってきた

8:56 AM

末尾にコメントでも書いときゃ良いんじゃねぐらいの気持ち

実際にやってみたってこと？

!禁止は前の前のプロジェクトでやってた

8:57 AM

前のプロジェクトは!はゆる～く許可してた。

! 禁止は、 forced unwrapping を禁止する意味じゃなくて

8:57 AM

forced unwrapping を使うなら理由を明記することを強制する、の意味ですね。

8:58 AM

let value: Int = Int(textField.value) ?? preconditionFailure("UI の制約で整数しか入力できないので絶対に nil にならない。")

(edited)

9:01 AM

let first: Int = array.first ?? preconditionFailure("この array は必ず空でないことが保証されている。")

コメントで良いのでは?という気がしている

デバッグ実行時にここに到達してしまったときに、メッセージが出たらデバッグしやすくないですか？

preconditionfailure + 文言が長くて一行で書ける嬉しさが減ってる感

9:03 AM

guard let ですでに実現できるんですよね

デバッガ有りで議論するなら、その行にジャンプするから別にコメントでよくねというのがあって

9:03 AM

preconditionfailureで嬉しいとすると、デバッグビルドでQAやってログに残るとか

guard let は -Ounckecked で最適化されない問題がある。

でも、QAはリリースビルドでやるべきですね

ああ、そうだった

@tarunon 言語レベルの話と、デバッガを入れたツールレベルでの話は別だと思うので、言語レベルで追跡できるのはより望ましいと思います。

!ってスタックトレース出ないんでしたっけ

あとは、 ! 禁止のコード規約を採用して ?? precondition を使えば、コメントを強制しやすいとかですかね。

9:07 AM

preconditionFailure にコメント必須じゃないのが微妙ですが。

9:07 AM

func logicFailure(_ message: String) -> Never { preconditionFailure(message) } (edited)

9:08 AM

preconditionFailure も禁止して↑を使わせれば強制できますね。

フーム

10:30 AM

private func failure<T>(message: @autoclosure () -> String) -> T { preconditionFailure(message) } infix operator !! func !!<T> (lhs: @autoclosure () throws -> Optional<T>, rhs: @autoclosure () -> String) -> T { do { return try lhs() ?? failure(message: rhs) } catch { print(error) // logging return failure(message: rhs) } } let num = Int("123") !! "絶対に数字" let data = try Data(contentsOf: URL(string: "https://www.google.com") !! "Google") !! "オフラインはあり得ない"

おお、 try もカバーですね。例のスレッドに提案してくださいｗ

どのスレですかw

10:35 AM

!をinfix operatorも可にして右に理由を書けるようにすれば良いんじゃないかな~とか思ったんですが

10:35 AM

try!がダメすぎてダメ

なるほど

これめっちゃいいですね

10:40 AM

おしゃれ

throws funcからfunc, Optional<T>からTへの暗黙変換が成り立つので

!をinfix operatorも可にして右に理由を書けるようにすれば良いんじゃないかな

これはできるんじゃないですか？カスタムの ! は作れないですが、標準ライブラリに組み込むなら。

いや

10:41 AM

tryがですね

10:41 AM

なんでこいつは左にいるんだ

try foo() ! "message" ならいいのでは？

ウーンそれはそうなんですが

10:41 AM

try!との対称性とか

try foo() !! "message" でも同じじゃないですか？

それはそう

10:42 AM

いやだから

10:42 AM

文句を言っているのはtryの場所が良くないねという話です

try の場所はダメですね。右であるべきだった。

人類がもうちょっとたくさん記号が使えれば

まあでも ! が統一されていることは重要だから、結局 foo! の形になるんじゃないでしょうか。

あとぶっちゃけ、Optionalはネストするけどthrowはネストしないとか

10:44 AM

まあそこまで対称な概念でもないしまあいいかな

ネストするんじゃないですか？

10:46 AM

// ネスト do { ... = try foo() do { ... = try bar() } catch _ { ... } } catch _ { ... } (edited)

10:46 AM

// フラット do { ... = try foo() ... = try bar() } catch _ { ... } (edited)

10:47 AM

throws -> Foo を Result<Foo> と捉えたら、前者がネストした map で後者が flatMap だと思います。

型としてネストしてないという意味です

http://qiita.com/takasek/items/f51c26a8ee6a2929bb6e

Decoder, DecodingContainerの、デコード先の型を推論させたい！明示的に指定したくない！ - Qiita

デコード先の型を推論させたいという、ヒトなら誰しもが持つ欲望

@inamiy さんのスライド [Swift 4 Codable // Speaker Deck](https://speakerdeck.com/inamiy/sw...

12:24 AM

decoder.decodeの引数にデフォルト値を入れた方が良いという話

12:24 AM

これSwift evolutionに投げれば議論できるんですかね？

できるんじゃないでしょうか。SE-0110もswift-evolutionへの投稿をきっかけに見直されましたし。

func decode<T>(_ type: T.Type=T.self, from...

12:26 AM

こうすると皆が幸せな世界になる

12:26 AM

投げるか

先日のswift-evolutionに上がってたCodableのUpdate、PRが出てる。 https://github.com/apple/swift/pull/10667

Optionality updates to Codable API by itaiferber · Pull Request #10667 · apple/swift

What's in this pull request? As laid out in a proposed update to SE-0166 and SE-0167, there are optionality updates that we wanted to introduce to the Codable API. This implements the remainder of ...

SE-0110見直しのきっかけになったのは↓ですね。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036773.html

decodeの引数にInt.Typeとかあるのちょっと

12:29 AM

冗長すぎでは、返り値オーバーロードしたくないモチベーションなのかなぁ

http://qiita.com/takasek/items/f51c26a8ee6a2929bb6e

これ、ビルド通らないよ。

Decoder, DecodingContainerの、デコード先の型を推論させたい！明示的に指定したくない！ - Qiita

デコード先の型を推論させたいという、ヒトなら誰しもが持つ欲望

@inamiy さんのスライド [Swift 4 Codable // Speaker Deck](https://speakerdeck.com/inamiy/sw...

12:34 AM

Playground execution failed: error: PlayNow-20170629.playground:3:41: error: use of unresolved identifier 'data' return try decode(T.self, from: data) ^~~~ error: PlayNow-20170629.playground:8:41: error: use of unresolved identifier 'data' return try decode(T.self, from: data) ^~~~

多分、プレイグラウンド内でグローバルスコープの data をデコードしてる。

メンション飛ばしておこう @takasek

ああ、外から見たらIntを明示してるように見えるのか

12:42 AM

okok

decoder.decodeの引数にデフォルト値を入れた方が良いという話

Decoderプロトコルにdecode()メソッドは含まれません。PR出すだけで良い気がする。

お

1:21 AM

やってみよう

自前のDecoderにさっきのエクステンションを足してみたけど、とりあえず問題なさげ。

1:25 AM

新しくなる実装ではまだ試せてない。 https://github.com/apple/swift/pull/10667

Optionality updates to Codable API by itaiferber · Pull Request #10667 · apple/swift

What's in this pull request? As laid out in a proposed update to SE-0166 and SE-0167, there are optionality updates that we wanted to introduce to the Codable API. This implements the remainder of ...

これマージされないとPR出せない気がする

JSONDecoder.decode()とPropertyListDecoder.decode()だけなら問題ない気がする。

これEncoderだけなのか

Decoderも含んでるけど、変更箇所とは関係ないかなと。

1:37 AM

*ContainerProtocolの方は微妙。

KeyedDecodingContainerProtocol、こっちもやらないと多分意味がない上に、protocolだからデフォルト引数とか出来ない気がする

かやまま

protocolならextensionに引数なしメソッド書くほうが筋が良いな

protocolの変更だとswift-evolutionに投げた方が良い気がする。

ですね、投げよう

個人的には型パラメータ必須が良いと思う。

2:35 AM

プロパティの型が変わったことに、ランタイムエラーでしか気付けなくなりそうだから。 (edited)

2:36 AM

まあ、コンパイラによる自動生成を使っていたら、どちらにしても気付けないけど。

うーん、Codableのプロパティの型を書き換えちゃう人、別にdecodeが型必須であってもコンパイルしてエラー出て修正して…ってやっちゃう気がしていて、省略してもほぼ同じなのではという気がする

2:59 AM

あれっ、なんで通らないんだろう

2:59 AM

みてみます

 func decode<T: Decodable>() throws -> T { switch T.self { case is Bool.Type: return try decode(Bool.self) as! T case is Int.Type: return try decode(Int.self) as! T …

このswitch文って、最適化で消えたりするのかな？ (edited)

これ多分効率よくないんで

@norio_nomura let data = """ { "id": 100, "text": "text", "url": "https://www.yahoo.co.jp", "option": null, } """.data(using: .utf8)! これペーストし忘れてたりしませんか？

元から型付きであるdecodeは返り値オーバーロードさせたほうが良いと思った

たしかに

@takasek extension JSONDecoder { func decode<T: Decodable>(from: Data) throws -> T { return try decode(T.self, from: data) } } ここでグローバルスコープのdataをデコードしてますよ。 (edited)

あ！本当ですね

3:06 AM

直しておきます

3:06 AM

あとは >元から型付きであるdecodeは返り値オーバーロードさせたほうが良いと思った func decode(forKey key: Self.Key) throws -> Int { return try decode(Int.self, forKey: key) } こんなですね

です

http://qiita.com/takasek/items/f51c26a8ee6a2929bb6e fixed

Decoder, DecodingContainerの、デコード先の型を推論させたい！明示的に指定したくない！ - Qiita

デコード先の型を推論させたいという、ヒトなら誰しもが持つ欲望

@inamiy さんのスライド [Swift 4 Codable // Speaker Deck](https://speakerdeck.com/inamiy/sw...

5

こんなの入ってたんだ https://github.com/apple/swift/pull/7125

Simplifying implementation of ExpressibleByStringLiteral by therealbnut · Pull Request #7125 · apple/swift

Added default implementations for ExpressibleByUnicodeScalarLiteral and ExpressibleByExtendedGraphemeClusterLiteral init(unicodeScalarLiteral value: UnicodeScalar) init(extendedGraphemeClusterLiter...

https://github.com/apple/swift/blob/master/utils/gyb.py

https://github.com/google/googletest/blob/master/googletest/scripts/pump.py

swift - The Swift Programming Language

2:49 AM

自分のC++開発でSwiftのgybを使ってみようかと思っているんですが

2:50 AM

使い方の文書が見つからない

utils/gyb --help くらいしか。。

なるほどｗ

2:53 AM

google/googletest

googletest - Google Test

2:53 AM

googleのpumpよりgybのほうが行数が多いけど(どっちもワンファイルpython

2:53 AM

後発だから何か進化があると期待している

pump.py 使ったことないからドキュメント読んでみましたが、 gyb はもっと単純な感じで、php 的なテンプレートエンジンです。

pumpもPHP的なテンプレートエンジンだと思う

3:22 AM

https://github.com/omochi/IronCake/blob/master/src/ick/function/function.h.pump

omochi/IronCake

IronCake - アイアンケーキゲームエンジン

3:24 AM

↑前つかってみたときの例

Python のすべての文法が使えるっていう意味です。

gyb は %{ }% でpythonなんでもかけるのか

3:28 AM

pumpは $(exp)で exp ::= simple_expression_in_Python_syntax だけど

3:29 AM

多分pythonでlambda文とかに与えられる制限つよい1文だけのやつっぽいな

import でも def でも何でも。 ${exp} は式であれば何でも書けますね。

なるほど。そこは大きな違いですねえ

https://github.com/apple/swift/blob/master/utils/gyb.py#L813-L865

[gyb] Add file binding · apple/swift@9e10ce0

swift - The Swift Programming Language

3:42 AM

ここ見たらオ〜ってなった

gybのhistoryみてたら @rintaro おった https://github.com/apple/swift/commit/9e10ce049ff1afe9c9a405f0374ffaf294f6c281#diff-64698c8c9555c56d43f71bd82c60e589

1

gybの % for: による展開だと

6:45 AM

x0 + x1 + x2 とか x0, x1, x2

6:45 AM

みたいな、最後の１個だけは演算子や区切り文字を出さない

6:45 AM

パターンは書けない・・・？

6:46 AM

, のケースはその中で inline で if 書くか・・・

${", ".join(array)} とかじゃだめすか？

そうなっちゃいますよね　うーんむ

6:55 AM

テキストをロジックでjoinするというよりロジックでjoinしてテキストを作る形になっちゃって微妙な気分

% for elem in arry[0:-1]: ${elem}, % end ${arry[-1]} (edited)

あ〜良さそうです

要素数が0の場合に何も出さないようにしたいけどそれだと駄目か。

なんでもpython書けるのいいな。よくなってきた

9:22 AM

pumpより良い

9:25 AM

endが無いpythonに % end を足してスコープ挟んでるのも面白い・・・

9:25 AM

なんなんだ・・・

% end がアンバランスに存在すると、それ以降何も出力されなくなるのがバグなのか未だに知らず。 % if foo: func foo() {} % end foo() % end ここ出力されない

過剰なendならエラーとか出してくれないんですかｗ

バグだったら swift リポジトリに PR のチャンス？ｗ

地味にありだな・・・gybこれ単体でいいぞ

9:29 AM

惜しむべくはpythonを書くのがつらいってことだけど・・・

9:33 AM

ヘッダーだけだけどできた。いい感じ。 Either2〜5 https://github.com/omochi/cpp-rhetoric/blob/master/src/rhetoric/either.h テンプレート https://github.com/omochi/cpp-rhetoric/blob/master/src/rhetoric/either.h.gyb (edited)

omochi/cpp-rhetoric

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

omochi/cpp-rhetoric

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

おお

gybの冒頭のここらへんがpythonへの呪詛 def join(xs, j): return j.join(xs) def ifx(c, y, n): if c: return y else: return n

9:35 AM

Swiftのメタ生成にも使いやすそうだ

https://github.com/apple/swift/pull/732#issuecomment-172595700

gyb is a necessary evil

by らとな

[SR-331] Generate fix-its for confusable characters by amackworth · Pull Request #732 · apple/swift

Addresses issue SR-331 by adding warning fix-its for possible Unicode confusions. This check only runs after either the lexer encounters an invalid character or an identifier fails to resolve. (All...

ｗｗ

コード生成は最近Sourceryをよく見る。 https://github.com/krzysztofzablocki/Sourcery

krzysztofzablocki/Sourcery

Sourcery - Meta-programming for Swift, stop writing boilerplate code.

1

はは～

8:35 AM

こいつは.swiftにコメントで注入するからソースがswiftを保てるんですね

gybやってみたけど、SPMのビルドに噛ませるのどうやったらいいんだろ

$ swift build にかませる方法が無い・・・

オワタ

a.swift.gyb と生成物 a.swift をコミットしておけばライブラリとしては配布できるけど

4:23 AM

他のコントリビュータも a.swift.gyb を編集する必要がある

4:24 AM

その前提でライブラリ作者は自分で叩くのが良い

ふーむ

4:24 AM

https://github.com/tarunon/enum-convertible

tarunon/enum-convertible

enum-convertible - Protocols for enum abstraction.

4:24 AM

https://github.com/tarunon/enum-convertible/blob/master/EnumConvertible.xcconfig

tarunon/enum-convertible

enum-convertible - Protocols for enum abstraction.

4:24 AM

ここ弄れば任意個のEnum生成できるようにしたけど

4:24 AM

spmはそもそもxcbuildじゃないからここ見てくれない

ですね

gybの生成物、###sourceLocationのパスが絶対パスなのが非常に辛いんだけど相対パスに変えられないかな

9:18 AM

おもちくんはそもそもこの行消してるのか

うん。 --line-directive "" で消してる。

お、消えた消えた

仕組み的に相対パスでうまく動くのかよくわからんしな

thx、これならコミットできるや

9:19 AM

そうなんだよね

// ###sourceLocation はコンパイラ自体には影響与えないです。(ただのコメント) なので、エラーなどは生成後のファイル名と行数で出ます。これを utils/line-directive と合わせて実行すると、 gyb のファイル名、行に直してエラーを表示してくれるようになります (edited)

2

9:30 AM

utils/line-directive はコンパイラからのエラー出力を正規表現で拾ってるだけ。

コンパイラ/デバッガの規格の外にある仕様だったんですね。

一個だけ、 // ### で始まるコメント行は無視されるっていう挙動があって、何に関係あるかっていうと /// コメント1 // ###sourceLocation(...) /// コメント2 func foo() {} だと、コメント1 とコメント2 が両方とも DocComment として有効になる。 // ### で始まらないコメントだと、そこで切れてしまうので、コメント2 だけが foo() の DocComment になります。 (edited)

あ〜　コメントは生成物で sourceLocationは生成に関する情報だから

9:39 AM

それを退避するルールが無いとコメントの中の構文（doccomment)があるときに困るのか

9:39 AM

コメントが２レイヤーある

コード生成のためにGenericsパラメータを改行して列挙するようにしてみたんだけど、俄然こっちのほうが読みやすいな。これコーディング規約に突っ込んでも良さそうだ。

9:40 AM

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

ここまで行くと改行してないと読めない

カンマ右に置こうよ・・・

右だと生成めんどくさくなるよ

左でも１個めを特別扱いしてるのは同じじゃない？

9:41 AM

１個めの左にはカンマがないっていう制御が必要

1個めは繰り返さない型パラの指定にしてる

なるほど

,が左なのはRx本体側のコードに習ってるよ

% for i in range(n): std::is_convertible<U${i}, T${i}>::value${ifx(i < n-1, " &&", "")} % end

9:42 AM

自分はこんなふうにした

9:43 AM

最後の行だけ && が出ない。 (edited)

if文イヤイヤ病だった

joinでもいけそう？

これはif文じゃなくて自作のifx関数だけどねｗ (pyhtonの３項演算子はキモい

,左のRxSwiftのコードはDelegateProxyの実装に頻繁に見られる

9:44 AM

https://github.com/ReactiveX/RxSwift/blob/0b66f666ba6955a51cba1ad530311b030fa4db9c/RxCocoa/iOS/Proxies/RxSearchControllerDelegateProxy.swift#L18-L21

http://qiita.com/shingt/items/08c726f968dd8508b1e2

RxSwift - Reactive Programming in Swift

joinだと行自体をpython側の文字列として構築することになるんで微妙なんですよね

9:44 AM

なるべく多くをテンプレートリテラルとして書きたい

9:45 AM

@tarunon きもちわるい・・

なるほど、確かにpython側でロジック入れすぎると旨味薄い感あります

MultilineStringLiteralが無かった時

9:45 AM

return "xxx" + "yyy" + "zzz" (edited)

9:46 AM

こんな感じにしてたけどこれと似たようなものだと思う

それも嫌や

俺は左のほうが好きなんだよね

そっか

return や where が左に存在していて

9:48 AM

その後改行した時に同じように左側に, や+ がある (edited)

ArrayやDictoinaryリテラルのときは？

そいつらはカンマ右だわ

9:48 AM

やべぇ

そこはちがうんかい

でも

文字列の複数行は確かにお尻が揃わないから気持ち悪い感ありつつ

[ xxx , yyy , zzz ]` これはキモい

9:50 AM

構文として、1番目の要素を改行するのが自然か否かという問題がある

9:50 AM

あとスペースの有無かな

9:51 AM

そもそもArray, Dictionaryは確か、Swiftなら末尾のペアの後ろに,いてもコンパイラ許してくれない?

ですね

9:52 AM

いちいち消すの面倒で全部つけてます

ArrayやDictionaryとreturn whereの決定的な違いは、リテラルの開始が末尾とペアか、先頭にしか存在しないか

10:32 AM

というのがあるなーと朧気に考えていた

SPMでビルド済みのC static libraryをswiftとリンクする時に

1:30 AM

ソースツリーに配置したstatic libraryを相対パスで指定することってできますか？

1:30 AM

Swift Package Manager経由でSwiftからCのライブラリを利用する - Qiita

概要

Swiftがオープンソース化されると同時にSwift Package Manager（以下SPMと略記）も公開されました。...

1:31 AM

この記事の例だとシステムにインストールされた libhiredis をリンクしているようなんですが

1:31 AM

これをリポジトリローカルでやりたい

1:32 AM

https://clang.llvm.org/docs/Modules.html#link-declaration

1:32 AM

module map の link 命令は -l オプションになるっぽいのです

1:34 AM

あ、 $ swift build に -Xlinker があるな。

#swiftpm 作ったのわすれてた。

#react-native も #xamarin あるのを最初見て幅広くてびっくりしましたｗ

まだ発言が無いですね・・・

Swift信者多めだから…

Swift で書ける Xamarin 的なものほしいですね。

C#がイケてるから技術的には可能そうですよね

技術的には可能でしょうが、メンテするのがきつそうですね

9:06 AM

それこそマイクロソフトくらい体力のある企業ならできるんでしょうが・・・。

JNI通したwrapperを毎回APIに合わせて実装してるってことですもんね

9:07 AM

常軌を逸している...

機械的にやってるのかもですが、言語的な差異もあるし難しそうですよね。人手だと気が狂いそう・・・

9:10 AM

アップルがやっても Android を利するだけでしょうし期待薄ですね・・・。 Chris Lattner がマイクロソフト入りで Xamarin が Swift 化とかに 1% くらい期待できそう？

1%高すぎでは

ｗ

Xamarinじゃないにしても、UIKitはいい加減しんどいので純正Swift UI Framework出して全てを灰燼に帰してほしい

Xamarin はともかく、マイクロソフト入くらいなら 1% くらいあるかも？

9:11 AM

純正Swift UI Framework出して全てを灰燼に帰してほしい

ほんとそれですね。

9:12 AM

来年の WWDC とかでそれ発表されたらめちゃくちゃ盛り上がりますね。

今年のWWDC予想は見事に現実路線だったので(名前はiXXではなかったけど)

OS X 10.10.3にUIKit風のAPIを提供する新UXKitフレームワークの存在が明らかに https://www.infoq.com/jp/news/2015/03/apple-uxkit-framework-found#.WVytuvFWauU.twitter

OS X 10.10.3にUIKit風のAPIを提供する新UXKitフレームワークの存在が明らかに

最近OS X 10.10.3ベータで見つかったUXKitフレームワークが，あちらこちらで話題になっている。興味深いのは，APIがiOS UIKitのものに酷似していることだ。ここから一部の開発者たちは，これら２つのプラットフォームを近付けることができるのではないか，と期待している。

9:13 AM

これが気になってる

9:13 AM

UXKitがFullSwift, iOS / MacOS クロスだったら嬉しい

UXKit、Photosがそれじゃなかったっけ

9:14 AM

大分昔の話

フム

Swiftより前だよ確か

じゃあ駄目かも

Swift UI Framework はアップルにもメリットがあると思うのでやってほしい・・・

ABIが安定するまで当分は期待できないと思うな。

たしかに。

12:49 PM

iOSに同梱して配布はできないんでしょうか？

古いOSがswiftのライフサイクルで切り捨てられる世界観にw

1:19 PM

それはそれで良いと思うけど(過激派)

ああ、確かにそうですねｗ

Range の包含関係を調べたくて↓こんな不毛なものを作ることになってしまったんですが、何か良い方法はないでしょうか。 https://gist.github.com/koher/5fd8f29a99de47457431cded99987d4f

RangeContains.swift

Range絡みは僕もベストプラクティスをしりたいです。Swift4 で one sided も入ってくるからもっと複雑になりそうですしね。

1

Swiftコンパイラ開発環境構築 by @rintaro on @Qiita http://qiita.com/rintaro/items/2047a9b88d9249459d9a

Swiftコンパイラ開発環境構築 - Qiita

Swift がオープンソースになってしばらく経ちます。コンパイラや標準ライブラリの開発に手を出してみたいけど、リポジトリを落とした後どうしていいかわからない！という方のために、まずは開発環境の構築方法をご紹介します。基本的には[RE...

11:05 AM

すばらしい！！！

ありがとございまーす

1

間違えた

ビルドディレクトリにどれくらい容量が必要か？とかの情報もあると良さげ。

1

build-toolchain は30GB超だったかな

やべぇw足りないw

34G ですねー。 build-toolchain は本当に必要ないですよ。

最近触ってたswift-corelibs-foundationのテストは3.33GBで済んでる

build-script -R なら 3G くらい。リポジトリ自体は 4G ちょっとなので、10Gあればなんとか・・・

掃除するか…

linuxビルドするためのdocker imageが831MB

12:26 PM

linuxビルドはメモリ1GBだと途中で落ちる。2GBだとリリースビルドが通る。

12:27 PM

macOSだとそんな制限はなさそう。

あ、間違えてたリポジトリ自体は 2G 無いくらいでした。

追加しました！

1

LinuxにSourceKitを標準で含める様にできてから自分でpackage buildする理由がなくなった。 (edited)

あーなるほど。SourceKitはあまり触ってないので、意識したことなかったです。

来た

[swift-evolution] [Pitch] Scoped @available

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170703/037959.html

2

1

ちゃんとメール出して偉いしstdlibを引き合いに出して説得力を増してるところがさすが @rintaro というかんじで素晴らしい・・・

3:52 AM

stdlibだけはアンスコ付きだとユーザから情報拾えなくなるの利用して、既存をエイリアスにしつつdeprecated貼って、エイリアス先のアンスコ付きを内部で使ってるんですねえ

姑息としか言い様がないｗ

stdlibだからこそ特別にやっていいことはできるだけ減らしていって、ユーザコードと同じように書かれているべきだと思います。最初は実装優先でそういうのもあっていいと思うけど、こうやって少しずつきれいな仕様に差し替えていけるとよい (edited)

1

そういうの、最近の出来事でReactiveSwiftとかNimbleのアップデートであったら便利だなという気持ちになりました

SE–0110 has been modified to allow cases for closures that were accepted in earlier versions of Swift, as described in this email announcement.

2

swift-evolution で guard / catch が提案されてる。 guard let foo = try bar() catch let error { ... } // ここで foo を使う https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9

guard-catch.md

2:34 AM

ネストしたくなく気持ちはわかる。けど、 guard let の意味が変わってしまうと過去に Chris Lattner がつっこんでる。

2:34 AM

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011491.html

これってcatchした場合必ず脱出するんですよね？それならそもそもcatchしなければ良さそうだけど、エラーを包み直したいってことですか？

いや、 return とかで早期脱出する場合です。

func nonThrowingFunction() { guard let value = try throwingFunction() catch { // handle `error` here, then leave scope print(error) // for example return } // use `value` here }

try? だとエラー情報が欠落するからそれを使いたいって話ですかね

guard let foo = try bar() が自然とみんなが思い浮かべるのは、多くの人が Optional と throws の類似性があることを感じ取ってるからと思われておもしろい。結局前の Simple domain error はいるのかみたいなところと通ずるものがある。

あー thorws が無いから再スローできないのか。 (edited)

@t.ae うん、そうだと思う。

2:39 AM

今だと、 let foo: Foo do { foo = try babr() } catch { ... }

2:39 AM

で同じことができる。

その関数としてエラーを伝搬する気が無い時点で欠落も何もって感じがするけどなあ例だと print してるけど。

guard の脱出強制がないだけですね

だね。あと書くのが少し面倒。

2:40 AM

その関数としてエラーを伝搬する気が無い時点で欠落も何も

エラーの種類で return する値を変えたいとか。

Error捕まえてどうしたいんだろう、別のErrorで包むのかな

うーむ。それなら最初から下請けの関数が enum で返しとけと思うが、まあありえるか。

Swift から外のシステムにつなぎこむときにエラーの種類に応じたエラーコードを整数で返さないといけなくて

型無しエラーから型有りの何かへの昇格したい場合かつ早期脱出・・・

guard 内があんまり複雑になるなら現状のtry catchのほうが良いかなぁと思わなくもない。 (edited)

エラーが発生したらエラーの種類に応じたエラーコードで早期脱出とか？

でも、脱出しない場合が許されないわけですよね

脱出したい場合の話をしてるんじゃない？

とっつきにくい感じがする

早期脱出してネストを避けたい。

あんまり入ってほしくないなあ・・・ catch と else が並ぶのもよくわからないし・・・

例えば、この種の処理が複数発生すると、 do / catch をネストするか、まとめて処理するか、↑に書いたみたいに let foo: Foo に後から代入するか

↑の let あとから代入が良さそうだけどあれか、型かかなきゃいけないのか

Optionalとthrowsの類似性はまあわかるけど、

だけど、手軽に早期脱出パターンを書きたいというのはわからんでもない。

try catchの場合は外側に変数定義してやるからネストはguardと同等ですよね。そこのネストが問題ならdo内で余計なことをやりすぎてることになる。

@omochimetaru うん、型書くの面倒だし、行が増える・・・。

2:44 AM

でも、 Chris Lattner の言うように guard let foo = try bar() はないから

2:44 AM

それだとうまい構文が作れなさそうだから

tagged unionとuntagged unionって型自体が違うし

やっぱ let foo: Foo に後から代入しか仕方ないと思う。

2:46 AM

tagged unionとuntagged unionって型自体が違うし

throws は Result<T, E> と等価で Optional<T> と同様 tagged union じゃないですか？

throwsのままだとuntaggedですよね

いや

guardはifの内と外が入れ替わったようなものですけど tryはcatchが強制されているというのもあるか

f() throws -> ErrorType これが書けるから Tagged　だよ

2:47 AM

Untagged Union は同じ型をくっつけたときにどっちがわかわからないデータ構造

あー

throwsのエラー側と、返り値側は常に区別されているから Tagged

でも、Result<T,Error>だとして

2:49 AM

Result<Result<T,Error>,Error>これは表現できない

あ、たしかに。

必ずResult<T,Error>になるよ

Tagged Union でも無いね。

2:49 AM

Tagged Union 未満の特別存在だ

@t.ae

do { let foo = try getFoo() do { let bar = try foo.bar() // bar を使う処理 } catch { retirm 98 } } catch { return 99 }

↑を避けて

2:50 AM

guard let foo = try getFoo() catch { return 99 } guard let bar = try foo.babr() catch { return 98 } // bar を使う処理

にしたいということかと。 (edited)

そもそも内側のdoは外側のdo内に入れるべきなのか (edited)

でもエラーの種類で区別できるとは限らない。

簡易構文があったほうがいいというのは賛成ですね

koherさんの例でしたら guard let foo = try? getFoo() else {return 99} で表現できそうな…？

@tarunon ネストは func foo() throws -> () throws -> Foo { ... } ですね。

そもそもthrowsのデザインがErrorの種類で分別するのが前提なので

@lovee たしかに。 catch でエラーの種類で分岐しないとですね。

分別できないようなのはtry?でOptionalの括りにしても問題はないのでは、という気がする

guard let foo = try getFoo() catch let error { switch error { // } } という感じですかね？ (edited)

エラー分岐について二つの話が混ざってますが、↑の getFoo と foo.bar については

@lovee それだとネストが深くできるからcatchの段階で分別できたほうがよさそうですね (edited)

2:55 AM

現行のdo catchと同じように

guard let foo = try getFoo() catch let error as QuxError { return 98 } catch { return 99 } guard let bar = try foo.bar() catch let error as QuxError { return 97 } catch { return 99 } // bar を使う処理

(edited)

やっぱりなんかこう行数がおおいと外側に変数定義する一行が増えるくらい大したこと無い気が

のように getFoo と foo.bar が同じエラーを返す場合がまとめて catch では分岐できない。

いや代入部含めて二行増えるか (edited)

あれ？それって return 98 の行に入るのはどういうときですか？

2:58 AM

ああ、catchの型でわけてるのか

どっちかと言えば発生したErrorをその行で別のErrorにラップできる構文が欲しいんじゃないのかな

書いてて思ったけど、エラーの種類で分岐よりも try? で困るのは、 catch で logger にログを書き出したいとかかなぁ。

2:59 AM

@tarunon エラーラップ構文はほしいですね。今は Typed Throws がないからルーズに素通しできるけど、 Typed Throws を導入するならラップしなおす簡単な構文がほしいです。

それがあれば、guard catchは要らなくなるかと。

本質的には Typed Throws があろうがなかろうが適切にラップしなおすべきだけど。

勿論guard catchがその機能を内包しても良いんだけど

guard catch はラップしなおしに限らないと思います。 return もあるし。

内包するという話

ただ、結局 guard let は Optional binding に割り当てられてて今の構文とマッチしないから

3:01 AM

guard let foo = try getFooOpt() // ??

↑それは今もできませんか？

3:02 AM

例外が飛んだら吹っ飛んでそれを包む関数自体が例外を投げる

do { guard try ... catch { //ここでthrowして } ... } catch { //ここで受け取る }

この構文はなくて、他にいい構文も思いつかないから、早期脱出したければ let foo: Foo do { foo = try getFoo() } catch { ... } しかないと思う。

3:03 AM

↑それは今もできませんか？

今もできるから問題で、 Optional binding なのか guard / catch なのか曖昧になるから

3:04 AM

guard / catch は構文としてあり得ないという話。

3:04 AM

throws な関数をコールするときにバインドしながら早期脱出したいニーズ自体は理解できるけど、ここで提案されてる構文はあり得ない。

catch がついてるかどうかで決まる話してるのかと思っていました。

3:06 AM

catchがついてた場合に Optional剥がしも同時に起きるのか Error剥がしだけが起きるのかはよくわかっていなかった。わかりにくいのはそうですね。

現状↓なら型を書くくらいの面倒さで済む？ let foo: Foo; do { foo = try getFoo() } catch { return }

3:07 AM

可読性低そう・・・

てかほんとうは

3:07 AM

その型省略できてほしいなあ

あと catch の中に return か throw が強制されていないのが問題なんじゃないですかね？ここでの問題点として

guard let foo = try getFoo() catch { return }

いやその文でcatch分岐しないといみないのでは

後続の単一の代入文の紐付けがされてるわけだから推論できる

並べるとやっぱ可読性は違うなぁ。

結局 do catch スコープの場合は catch 以降のコードも実行されることが予想されているので…

@lovee そもそもそうですね。

その型省略できてほしいなあ

それは思うけど Swift の型推論がこれ以上複雑なことしたら大変なことになりそう・・・。

ああそうか

3:09 AM

let foo: Foo; do { foo = try getFoo() } catch { return }

3:09 AM

これってちゃんと解析してくれるんだっけ？

3:09 AM

catchの中の return を見て、以降の fooの初期化漏れが無い事をコンパイラが理解するか

REPL 通ったことを確認済み。

なるほど。

うん。そこは大丈夫

3:12 AM

@lovee 早期脱出が強制されるのはそこまで重要じゃない気がするんですよね。早期脱出したい人は結局早期脱出するだろうし。まあ return の書き忘れくらいはあるかもですが。

@koher いや、そこは書く人じゃなくて読む人のための機能だと思います

return してればフロー解析で foo は使えるし。

書くときに自分のためにguard書いたことない　else でわかりにくいし

@omochimetaru 可読性が劣っているのは間違いない。

do let x = try ... catch {} でいいんじゃないの

3:14 AM

doの括弧がしんどいだけで、これをワンライナー許せば解決できそう

@tarunon それは Swift が式指向の言語にならないときつそうじゃないですか？

3:14 AM

それを認めだしたら if も値がほしいですし

doをオペレータにしたいってのはありそうな気がする

そうするとラムダ式と return の関係とかも見直さないと一貫性がないし

3:15 AM

（他の言語みたいに最後の式の値を戻り値として採用するのかどうか）

3:15 AM

do や if の中には return は明示的に書けないから（外の関数の return になっちゃう）

doスコープのなかのtryが全部一箇所にcatchに飛んでくるけど、一個ずつ丁寧にcatchして処理を分けたい場合に

いやこれはguardが被ってるからdoに変えただけで、式の機能は有していない

最後の式の値を採用するしかない。

3:16 AM

ああ、 do let なのか

たしかに let とかもスコープを伴わないけど式ではないね

3:16 AM

do から始まる文をかけたらいいってことよね

そう、catch句は脱出強制になる

意味的に guard だから guard じゃないものにそれを負わせるのはややこしいと思うんですよねぇ。

ですね、多分単語の意味合い的には guard は早期脱出を伴うことを教えてくれてるという意味合いがあると思います

まあぶっちゃけそこまで頻度高くなさそうだし、 guard let foo = try? getFoo() else { return } で大体は代用できそう。 (edited)

そうですね　僕はほとんどのケースがそれで済むと思っていて「再スローしない関数でcatchでわけて脱出したい」っていう前提のストーリーが狭すぎると思う

どうしてもエラーがほしかったら let foo: Foo do { foo = try? get Foo() } catch let error { logger.log(error); return }

どうしても do catch のネストが深くなりそうならもういっそのことメソッドを出してあげるのも一つの手段ですかね

そのレアケースのために構文がひとつ複雑化するのは割にあわないと思う・・

@lovee そうですね。細かく関数／メソッドに切り出すのもいいと思います。

@koher 本当そうですね…（会社の数百行を及ぶC++の関数を眺めながら（白目 (edited)

1

@lovee @mono さんが前に挙げてた、関数は 6 行（？）以内におさまるように分割すべし、みたいな考え方、現実的には難しいケースも多いけど常に心がける価値はあると思っています。と言いつつも僕も実際のコードは長すぎてぐちゃぐちゃだったりしますが・・・。

3:23 AM

細かく分割するとテストを書きやすくて、テストを書くと結局最終的にバグの発見が早くて時間的にペイすると思うんですよね。

コード片のモジュール性があがるんで変更にも強くなりますね

特に&& や || や ! を使った条件とか書いた瞬間に、そこだけでもテストしたい。

3:24 AM

そこで、いちいちテストのファイルに飛んで関数切って、とかじゃなくて

300行の関数で299行目に参照する変数が1行目に宣言されてたらもうその300行を分割するのは無理

if 文に直接テスト書き足せたりするとうれしい。

中間を切り出すことはできるのでは？

299行目に参照する変数が1行目に宣言されてたら

2 行目から 298 行目が関数になるのでは？

その間の298行の間にその変数が参照されていないことを確認しないといけない

必要なら関数の引数にするんじゃない？

3:27 AM

引数にしなかったらコンパイルエラーになるから必要なことに気づけるし。

はい、で、だいたいは、135行目でも何かが代入されていて (edited)

3:28 AM

その右辺値の式に別の変数や関数呼び出しが出てくるので

3:28 AM

どんどん芋づる式にデータフローの依存関係をたぐっていって

inout 関数や

その300行のデータ依存関係を完全に解析してはじめて

3:29 AM

やっとこさどこがロジックとして分割可能か判断できる

ああ、そういう意味で後から分割する大変さのことを言ってるのか。

300行書き下すときは、書いてる本人は、気にする部分だけ気にしながら書き下すから簡単だけど

3:29 AM

読みとく側は無限の可能性のツリーを絞り込みながらデータフローを再構築しないといけないから

3:30 AM

めちゃくちゃ手間がかかる。

ローカル関数がもっと書きやすくて、テストしやすかったら分割もしやすいと思うんだよなぁ。

クラスのメソッドはクラスというスコープでフラットに散らかってしまうという問題があって

うん。

メソッド同士の依存関係のレイヤーで同じ解析が必要になるから

3:31 AM

型を切る話が出てくるけど、ローカル関数をつかって

3:31 AM

それをできますね。

ローカル関数にするとローカル変数をキャプチャしてしまう問題とテストできない問題がある。

ローカル関数はそれを参照する範囲がクラスより狭くなるのが良い。

3:31 AM

そうですねー

今整理のために階層を切りたいだけで、本当にやりたいことはローカル関数じゃないから。

nested classがやっぱりバランスいい事が多いと思う

3:32 AM

僕はときどき「struct ComputeXxxWork」みたいに

処理フローもわかりにくくなると思うんよね。

型を切り出してます

3:32 AM

そうするとこの構造体から、outer classのメソッドには依存しないことを保証できるからいくらか解析しやすくなる

func foo() -> Foo { let bar: Bar do { // bar を組み立てる処理 ... } let baz: Baz do { // baz を組み立てる処理 ... } let qux: Qux do { // qux を組み立てる処理 ... } return Foo(bar, baz, qux) }

3:33 AM

と

参照範囲で思ったのは、Swift 4でprivateが同じファイル内の同じクラスで参照可能になったのがある意味改悪な気が…

@lovee 同じ型名のextensionからだけじゃなかったっけ

@omochimetaru そうです

3:35 AM

ようは何が言いたいかというと、今まではこの extension 内のみで参照可能にしたいやつをたくさん作ってきたので()

func foo() -> Foo { let bar = foo_bar() let baz = foo_baz() let qux = foo_qux() return Foo(bar, baz, qux) } func foo_bar() -> Bar { ... } func foo_baz() -> Baz { ... } func foo_qux() -> Qux { ... }

3:35 AM

だと、前者の方が流れが読みやすいと思う。

3:35 AM

そんなことないかなぁ。

@koher そうですね、それだとfooは読みやすくなるけど foo_barが他のところに露出してる問題がある

3:35 AM

foo_barのメンテナンスを考えた時、それを変更してもよいかどうか検証しないといけなくなってる

foo がやりたいことは読みやすいか。

3:36 AM

この foo_bar とかをわかりやすく foo に関連付けて分離できる仕組みと、

3:36 AM

書くときに分離する手間を軽減できれば良さそう。

なので・・・

sturct FooConstructWork { func construct() -> Foo private func createBar() -> Bar private func createBaz() -> Baz private func createQux() -> Qux }

3:36 AM

とやれば、いいとこどりかなと

foo がメソッドで、インスタンスのプロパティを使いたいときは？

FooConstructWork::createBar() の変更のときに気をつける行数は FooConstructWork の中身全部を読めばいいけどそれはもともとの foo と同じ量ですむ

struct に init に渡す？

その場合は、依存する入出力を FooConstructWorkのAPIとして定義する

3:38 AM

initで受けて、返り値を struct FooConstructWork::Result っていうさらなるnested typeにして

3:38 AM

もともとの fooをイカのように書き直す

func foo() { let work = FooConstructWork ( depends_field1, depends_field2 ) let ret = work.construct() self.depende_fields3 = ret.field3 }

(edited)

これ徹底しようとしたら、ほとんどのメソッドが struct になっちゃったりして萎えないかなぁ。

これやるとfooの中で変化しうるフィールドがひと目で確認できるのもよいですね。

3:39 AM

いや、メソッド自体は残しておいて

3:39 AM

その中でstruct使えばいいので。

struct にしてるから、状態変化する変数をプロパティで表せるのか。

あ、そうです。

いいかも。

関数の中で作業用につかうvarはフィールドにして

3:41 AM

メソッド間で共有変更します

イニシャライザ、 construct については一行で書けるし

3:42 AM

元のメソッドとの間で命名規則を決めておけばよさそう。

返り値を構造体で戻して、(つまりnominal tupleですね) それをcallerのフィールドに明示的に差し戻す

construct 長いし make とかがいいかな。 func foo() -> Foo に対して struct MakeFoo とか？

3:43 AM

でも任意の関数で考えたら必ずしも作るとは限らない。

まあそこは別に読むときに辿っていけば読めるので

func foo(x: Int) { RunFoo(zelf: self, x: x).run() } struct RunFoo { private let zelf: ... private let x: Int func run() { ... } ... }

(edited)

もともとのたどる範囲が広すぎる問題を解決してる事が大きい

3:46 AM

self渡しちゃうとなんでも変更されうるのでつらいですよ

3:47 AM

innner classじゃなければ private は触られないからもともとのメソッドよりマシだけど

うーん、でも重度に外部のプロパティに依存してるケースもあるしなぁ。 (edited)

3:48 AM

引数に 20 個渡すとか死んじゃう・・・

そこまでいくと分離するべきでないのでは

3:48 AM

もしくは更に細かく分離するか

20個渡してる場面では20個を5個ずつの型4ことかに整理できそう。

3:49 AM

もし分割できないのであればそれは本当に複雑なロジックってことなんで諦めるしかない

3:49 AM

大事なのは本当には複雑ではないロジックを複雑なコードにしてしまうケースをシンプルで読み解きやすいコードで表現することで

3:49 AM

本当に複雑なロジックは複雑なコードになることは避けられないと思う

3:50 AM

コロモゴロフ複雑性よりはわかりやすくできない

20個渡してる場面では20個を5個ずつの型4ことかに整理できそう。

UIViewController とか（自作でない巨大な型）の場合は？整理して返すプロパティを生やす？ (edited)

ですね。本当に20個in/outしてるシーンは少ないと思います。そのWorkの中で使うメソッドは、initializederでクロージャ受け取るようにしておくと

3:52 AM

使うメソッドも表明できます

3:53 AM

プロパティで戻さなくても例えば・・・

3:55 AM

FooWork ( getUserName: { return self.user.name }, setLabel: { self.label.text = $0 }, setImage: { self.imageView.image = $0 } ) , present: { self.presentViewController($0} )

3:55 AM

こういう感じにすると、UIViewControllerの中で、FooWorkによって起こる副作用のバリエーションを

3:55 AM

使うところで表明できる

3:55 AM

selfを渡すよりはぐっと絞り込まれる。

3:56 AM

まああとはそもそも複数のViewの塊をcomponentとして切るとかもできる事が多そう

self が値型の場合は？

というと？

4:01 AM

同じようにキャプチャしてメソッド呼び出しもできるような。

値型で let で受けておくと副作用がない

それならそもそもだいぶマシですね

4:04 AM

FooWorkの中から書き換えられることがないわけだし

4:04 AM

FooWork::Result から結果を書き戻すコードが絶対必要になるから

4:05 AM

そこだけ見ればデータフローが全部見通せる状態にできる

議論追えてないですが、上のほうで @koher が記述してた do {} catch {} のネストはバグ有りなので、少なくとも現状やらない方が安全です。 https://bugs.swift.org/browse/SR-5339

バグってるのかw

4:53 AM

あー

4:54 AM

なんかネストさせたときに変なところにError飛んで困ったことあったけどそれかな

まさかそんなことがｗ

あ、 catch 内に do を書くときだけか。 do { do { は大丈夫かも

4:56 AM

do { } catch { do { throw } catch { } } で内側の catch が呼ばれずに下まで抜けてしまうっていう問題だったと記憶してます。 (edited)

1

まさにそれ踏んでました。

4:56 AM

どこだったかな

4:57 AM

https://github.com/tarunon/Hiyoko/blob/master/APIClient/Sources/Request.swift#L39-L45

tarunon/Hiyoko

Hiyoko - http://www.hiyoko.co.jp, It's a sweets in Fukuoka. But this repo maybe become twitter app for iOS.

4:58 AM

ここで素直にthrowしようとすると変なことになって死んだ

2

↑確か、内側のcatchは内側doのtryのErrorを捕まえるはずだが、throwのErrorも捕まえてこの野郎！ってなった記憶がある (edited)

3:27 PM

そもそもdo内でthrowしたものはcatchに行くのが正？

do内でthrowしたものはcatchに行くのが正？

これはそうだと思います。 SR-5339 素直にやると再現しないので、書かれている通り Swift ではなく Foundation の問題みたいですね。

#swiftpm から。

https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md を revert するのはハードル高いっすねぇ。

これ知りませんでした。

https://cpprefjp.github.io/lang/cpp14/generic_lambdas.html

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

↑読んだ記憶はあった

1:43 AM

順番入れ替えが一部できるのはキモいみたいな話

なんか struct のデフォルトの init だとできるとかなかったっけ？？

ラベルが強制されてる分kotlinとかよりは良さそうな気が

Swift の命名ともマッチしないし、引数が多くなると型でまとめるが正しいアプローチなのかな。

1:44 AM

昨日の、引数 20 個とかとも通ずる話な気が。

そもそもkotlinが引数入れ替えできたか覚えていなかった pythonほ引き合いに出すほうが良かったですね

pythonは辞書じゃなかったっけ

1:46 AM

rubyもそう

引数が多いと順番わからなくなる→引数が多すぎることが原因→型でまとめれば良い

辞書じゃないのも指定できるっぽいです

1:46 AM

In [4]: def hoge(a, b): ...: print(a, b) ...: In [5]: hoge(a=1, b=2) 1 2 In [6]: hoge(b=2, a=1) 1 2 (edited)

@koher 思ったんですけど、普段はxcodeがひな形出してくれるから順番は覚えて無くても困らない

Foo([ \.name: "Jason" \.age: 20 ]) みたいなのが型安全でできればいいな、と。

@t.ae じゃあ常にラベル付け呼び出しもできるのかｗ

kotlinは引数入れ替え出来た気がする

↓と並び替えは相性悪そう。 func foo(a: Int, a b: Int, a c: Int) -> Int { return a + b + c } foo(a: 2, a: 3, a: 5)

ラベルが被ることがあるのか。

そもそもメソッドの命名が

swiftってラベルかぶり許されてたのか

func foo(with x: X, with y: Y) みたいなのが有り得るから

ラベル周りの複雑さは Swift にとってネガティブ要因だと思う。 Obj-C に引っ張られすぎ・・・。 (edited)

そうですかねえ

1:51 AM

他の言語だと4引数ぐらいになってくるともう何渡してるかわからなくなるので

Python くらいの感じがいいんじゃないかな。

1:51 AM

英語として読ませるのとかも無理が出て来るし・・・。

まあたしかに。pythonなら呼び出し側で明示できるから、いいのか。

Python は Python で、ラベル付けるのが正当なのか、フラットに渡すのが正当なのか迷うので、微妙なんですよね。

なるほど

大半の言語がそうですけど関数呼び出しでどの引数が何なのか一見で分からないのはストレスになりますね。swift慣れしすぎたんでしょうが

そう。そのストレスすごいわかる。

1:53 AM

ラベル付けする代わりに、ローカル変数で一回組み立てて変数名をラベルの代わりにしたりしてるよ。

書くときは面倒なのでラベルつけたくないけどあとで読み直すと分からないというのがよくある

ラベル強制でもいいけど、ラベルの重複は認めない、順番は自由、英語として読ませない、くらいでよかった。

ラベル付けする代わりに、ローカル変数で一回組み立てて変数名をラベルの代わりにしたりしてるよ。

これやればいいんですけどね

@t.ae 同じ関数を２回呼んでるときに詰む

あーpythonスコープきれないから・・・

C++ならスコープ切れるんだけどしんどいんだよなあ　ボコボコするし行数伸びるし

まぁpython書く時は使い回し上等でやってるんですが

定数指向諦めちゃうよね

>> ラベル付けする代わりに、ローカル変数で一回組み立てて変数名をラベルの代わりにしたりしてるよ。

これやればいいんですけどね

これはよくやる。引数たくさんあるときに、コール時に計算して渡すと可読性悪くなるし。

1:56 AM

そして、この場合、ラベルが冗長な感じに・・・。

swiftでやると２重になっちゃうのは確かに。

Kotlin の run とか、無名スコープが戻り値を返すとかだとやりやすい。

// Kotlin val foo: Foo = run { val bar = ... // 複雑な計算 val baz = ... // 複雑な計算 val qux = ... // 複雑な計算 Foo(bar, baz, qux) }

@koher これって、 bar baz quxは1行では済まない感じなんですかね

2:01 AM

var foo = Foo( bar: ... // 複雑な baz: ... qux: ... ) 大体いつもこう書いてる

2:02 AM

必要なら各パラメータでクロージャ立てればOKかなと (edited)

無名スコープでネストすることを考えるとインデントも同じですよね

2:02 AM

ラベルがむちゃくちゃ長い時は分けたくなりますが

@tarunon 例えばbazの値の構築にbarの値を再利用する場合や、bazとquxで共通の途中計算値を使う場合に、それだと困る

それは引数の設定間違ってないかw

@tarunon ラベルがないとどの引数に何を渡しているのかがわからない→一度変数に代入すればわかる、という流れでの話でした。

ああ、なるほど

run があるとクロージャ代わりになるのは便利ですね。 let foo = { ... return Foo(...) }() let foo = run { ... return Foo(...) }

前者これコンパイル通ります?

Kotlin は run とか apply とか、 ?: return とか、そのあたりの小道具が便利なんですよねぇ。

let foo: Foo にしておかないとしんどそう

@tarunon その通りでした。

2:07 AM

すごい、コンパイラの気持ちがわかってるｗ

え、マジ？？

2:08 AM

returnからクロージャの型わかんないの

まあ、引数に渡すときは大丈夫そう。

run作ればコンパイル通る気がしてきた

 1> struct Foo { 2. var a: Int 3. var b: String 4. } 5> let foo = { 6. let a = 42 7. let b = "xyz" 8. return Foo(a: a, b: b) 9. }() error: repl.swift:5:11: error: unable to infer complex closure return type; add explicit type to disambiguate let foo = { ^ () -> Foo in

2:09 AM

5> let foo: Foo = { 6. let a = 42 7. let b = "xyz" 8. return Foo(a: a, b: b) 9. }() foo: Foo = { a = 42 b = "xyz" }

2:09 AM

10> func bar(foo: Foo) {} 11> bar(foo: { 12. let a = 42 13. let b = "xyz" 14. return Foo(a: a, b: b) 15. }()) ↑OK (edited)

Foo であることまではわかってるのか……

@tarunon すげえな・・・

 16> func run<T>(_ f: () -> T) -> T { return f() } 17> let foo2 = run { 18. let a = 42 19. let b = "xyz" 20. return Foo(a: a, b: b) 21. } error: repl.swift:17:16: error: unable to infer complex closure return type; add explicit type to disambiguate let foo2 = run { ^ () -> Foo in

2:11 AM

run もダメでした。

あら…残念…

わかっているけど明示しろってことですね。

こういう型推論周り、できないのが仕様なのか実装の問題なのか・・・。

クロージャに返り値以外で型の明示必要なのは

2:12 AM

lazy varとかで頻出な気がします

踏んだ時は明示してるんだけど、「ふざけんな」としか思ってないから

2:13 AM

どういうときにそうなるか身についてない

お、 Kotlin だとできた。

data class Foo(val a: Int, val b: String) fun main(args: Array<String>) { val foo = run { val a = 42 val b = "xyz" Foo(a, b) } print(foo) }

Foo(a=42, b=xyz)

swiftもrunが1行ならいけるはず

2:46 AM

mapがOkでrunがダメなの解せないなー

↓もいけた。

// Kotlin data class Foo(val a: Int, val b: String) fun main(args: Array<String>) { val foo = { val a = 42 val b = "xyz" Foo(a, b) }() print(foo) }

kotlinはわりと普通になんでもできて、swiftみたいなアレ？？って事が起きないんですよね。

その代わり、型推論があっさり諦めることも多い印象。

2:48 AM

Swift は「え？それもできんの？」って思うことと、「え？これもできないの？」って思うことがある。

ｗｗ

アプリカティブの推論とかよくできてるなと思わない？

kotlinできないんでしたっけ？

いや、 Kotlin でもできるけど、なんかできなくなる条件があったような・・・。

ふむ

2:50 AM

HM型推論を勉強・ちょっと実装した経験があるから

2:50 AM

直感的には、まあできるだろうって思う事が多い

2:51 AM

サブタイピングとかオーバーロードが絡んでるところはよくわからなくて、すごいって思うけど

2:51 AM

アプリカティブの連続適用とかはそういう意味では素直

なんというか、ジェネリックな curry とジェネリックな戻り値型推論の組み合わせとか Swift でうまくいくイメージがわかないけどうまくいってる。

2:54 AM

Kotlin のアプリカティブは↓でうまくいってるけど、式を複雑にしたらダメだった気がする。 val person: Result<Person, JsonException> = curry(::Person) mp firstName ap lastName ap age https://github.com/qoncept/kotres

qoncept/kotres

kotres - Provides the Result class for type-safe error handling in Kotlin

2:55 AM

Swift も <*> の数がある数を超えると急にダメになったような？ (edited)

ジェネリクスも本質的には左辺値の推論と同じなんだと思います

2:57 AM

let x = exp() の式を左から舐めていって x をpolytype　で仮埋めしていて、それがexpとunificationされて確定することと

2:57 AM

exp( x: Box<Int> ) に makeEmptyBox() -> Box<T> をわたして exp ( makeEmptyBox() ) という形にときに

2:58 AM

makeEmptyBox() の型変数が Box < polytype > になっていて

2:58 AM

型パラメータ T が埋まっていない状態っていうのは

2:58 AM

推論機にとって、左辺値が不定な状態と同じ枠組み

2:58 AM

で扱える

2:59 AM

似たような話で C++14 が

2:59 AM

逆方向に話が展開しているのが面白くって

3:00 AM

いまは Swift において、ジェネリック型は型推論の枠組みに収まるって言ったんですけど

3:00 AM

C++14 で、ラムダの引数の型を auto 型、つまり、推論させろっていう設定でラムダ式が書けるんですが (edited)

3:00 AM

ジェネリックラムダ - cpprefjp C++日本語リファレンス

ジェネリックラムダ(generic lambdas)は、C++11のラムダ式を拡張して、パラメータにテンプレートを使用できるようにした機能である。

run のクロージャ式が 1 行だとたしかに通った。 @tarunon さんすごい・・・。

 1> func run<T>(_ f: () -> T) -> T { return f() } 2> struct Foo { 3. var a: Int 4. var b: String 5. } 6> let foo = run { Foo(a: 42, b: "xyz") } foo: Foo = { a = 42 b = "xyz" }

これは逆に、ジェネリックラムダは、テンプレート機構とみなされる

3:01 AM

つまり、型推論のようなことをやらせるために、テンプレートを使う

3:02 AM

もちろん厳密にはテンプレートの型解決ルールはHM型推論よりは弱いのでC++だと苦労する場面はあるんですが、この挙動で結構、高階関数がちゃんと使える

これって structural subtyping 的な考え方なのでは？

それて、テンプレートの型パラメータが決まってない状態で式展開していって、最終的に具象型で解決する処理の流れが、HM型推論がpolytypeで仮置きしながら推論を進めていく動きと、よく似ているなあと最近思った

https://github.com/apple/swift/blob/master/docs/TypeChecker.rst

Swift limits the scope of type inference to a single expression or statement

推論を single expression closure までに絞っているのは一応はポリシーってことかと。

swift - The Swift Programming Language

structural subtyping の概念がわかってないからなんとも。あれってメンバのある無しを縛っていく話かと思ってました。

おお、そうなんですねー。

3:06 AM

@omochimetaru a と b の型は + できることから決まるという意味で。 (edited)

TypeChecker.rst今度読んでみよ

3:10 AM

@omochimetaru a と b の型は + できることから決まるという意味で。(編集済)

話のつながりがよくわからなかったです

C++ のテンプレートと Swift のジェネリクスは、後者は型パラメータに制約を記述するして縛るという意味でちょっと違うような？ってこと。 (edited)

あーいま制約のことは置いていました

Swift のジェネリクスとは関係なく C++ のジェネリックラムダが型を解決する仕組みが型推論と似てるって言ってるだけ？

Swiftの方は制約の無い struct A < T> を想定して考えていました。

3:16 AM

でも制約もオーバーロードされてなければ最後にチェックするだけだと思うんで

3:16 AM

あまり関係ない気がしますね

3:17 AM

つまり僕がいいたいのは

3:17 AM

Swiftの推論機がジェネリックな型パラメータを解決する部分は

3:17 AM

普通に左辺値の推論をするのと

3:17 AM

同程度の難易度のタスクだから

3:18 AM

そこができるからすごい、というふうには感じない、ということです

3:18 AM

C++の例は、型パラメータを解決する部分と左辺値推論が似ていることの補強のひとつです

3:19 AM

制約が満たされるかどうかの決定方法は C++ が Structural subtyping的で、Swiftが宣言的なのはそうだけど

3:19 AM

そこは推論フェーズには関係ないと思う。

3:19 AM

オーバーロードしたところで推論の道筋が分岐→１つのオーバーロードを仮定して推論を全部埋める→埋まったあとで、制約が満たされているかをチェックする→満たされていなければ次のオーバーロードを試す

3:20 AM

多分こういう挙動。で、制約が満たされているかをチェックする部分が、structural か、宣言的かは、「ジェネリックな型が推論に統合されている」話とは、別のフェーズで、どっちでもいい。

まあ、そりゃできてるんだし本質的な難しさはないんだけど、もっと感情的に、 Swift の型推論は予想しないところでダメだったりする割に、 https://github.com/thoughtbot/Argo/blob/master/Sources/Argo/Types/Decoded/Applicative.swift#L18-L20 と https://github.com/thoughtbot/Curry/blob/master/Source/Curry.swift と https://github.com/thoughtbot/Argo/blob/master/Sources/Argo/Operators/DecodeOperators.swift#L16-L18 みたいなのを複雑に組み合わせても意外とちゃんと動くんだなぁとおどろいたという気持ちです。

thoughtbot/Argo

Argo - Functional JSON parsing library for Swift

thoughtbot/Argo

Argo - Functional JSON parsing library for Swift

thoughtbot/Curry

Curry - Swift implementations for function currying

なるほど。

3:29 AM

applicativeがすごく見えるのってすごい見せかけの問題って感じがする

3:29 AM

curry自体は curry ( function ) で完結するから簡単で

3:30 AM

<*> <| を展開して関数呼び出しに書き下せば

3:30 AM

納得というか。

3:30 AM

通してみると迫力はある。

あとはアプリカティブに触れたのが左辺値型推論に慣れてない時期だったからというのもあるかも？

今試したらmapもワンライナーじゃないとダメだった。

ほんとだ。

3:42 AM

なんかおかしい気がする。

わりといつも１行で済ませられててあまり困ってないってことかね

3:44 AM

https://github.com/apple/swift/blob/master/docs/TypeChecker.rst > Swift limits the scope of type inference to a single expression or statement 推論を single expression closure までに絞っているのは一応はポリシーってことかと。

https://github.com/apple/swift/blob/master/docs/SIL.rst#id87

swift - The Swift Programming Language

3:45 AM

mapなんて死ぬほど使ってるのに、「え？そうだっけ？」感があるし。

今試したらmapもワンライナーじゃないとダメだった。

実際にはですね

3:45 AM

map/flatMap/filter

3:46 AM

こいつらChainingで使ってるから、一番外側の左辺型から順番に伝播していて、書かなくてもなんとかなってるのでは、という気がしている

最終的に左辺値の型が決まっているところに突っ込めればなんとかなりますね。

func run<T>(_ f: () -> T) -> T { return f() } struct Foo { var a: Int var b: String } let foo = run { let a = 1, b = "str"; Foo(a: a, b: b) }

これもいけたw

3:48 AM

これは

だな

えっ

3:49 AM

セミコロンつなぎだから single expression 扱いってこと？

return がないから () -> () 扱い (edited)

w

邪悪な・・・ｗ

warning出るね

Constant 'foo' inferred to have type '()', which may be unexpected

Voidにしろ~ってやつかな

セミコロン区切り文の評価型は最後のセクションじゃなくて全体がVoid？

ああ本当だ、Voidになってる

return 書いたら Void じゃなくなるっぽいですよ

return書いたら型を書けと怒られたw

4:06 AM

やはりここは protocol Factory の出番かな

4:06 AM

protocol Factory { init(_ f: () -> Self) } extension Factory { init(_ f: () -> Self) { self = f() } } extension Foo: Factory { } let foo = Foo { let a = 1 let b = "2" return Foo(a: a, b: b) }

4:06 AM

よさ味

Foo２回かいてるのが嫌

その点はkotlinのapplyみたいのができれば良さそうですね

applyじゃmutableなクラスじゃないと駄目じゃない？

そこがちょっと微妙なところですが

@omochimetaru 減らしたで。 let foo = Foo { let a = 1 let b = "2" return .init(a: a, b: b) }

ｗｗｗ

文字数増えてる

これの本当に微妙なところは差し替えられるselfが実はallocだけされていること、であってるかしら

ネームドタプルを返してイニシャライザ呼び出しは外でやらせれば

そうだね > alloc

4:13 AM

ClassだとallocだけどStructはどうなんだろう?

structもallocだけなんじゃないかな

4:14 AM

あーいや、どうなんだろう

4:14 AM

そもそもクラスの場合も、暗黙のゼロ初期化initは呼ばれてるんじゃないだろうか

4:16 AM

えっと、代入文のコンパイル結果って、左辺のメモリが未初期化(uninitialized)であればinitだけでいいんだけど、初期化済みである場合、既存の値の破壊(参照型なら参照カウンタ減らしたり)を正しくやらないといけなくて

複数引数funcにnamed tuple渡せなくなったから微妙かな @t.ae

でもSwiftって引数なしinitを持たない型も作れるよね・・・？

4:17 AM

引数なしinitな型に対して initializedなself を自動生成できない気もするし、型システムが限定されてるから無理やり作れる気もする・・・

4:20 AM

alloc済みだけどuninitedなストレージ : でたらめな数値が入ってるから破壊処理(ポインタ辿ったり)はできない / してはならない alloc済みでinitedなストレージ: その型の値として正常な状態、上書きされる場合はその前に破壊処理が必要 ( やらないとメモリリークなどが起きる ) さっきの Factory protocol で、 self = f() の左辺値の self の状態は ↑ のどっち？ initedだとすると、そのinitedな値を作るためのイニシャライザはどうやってコンパイラは呼び出した？

https://gist.github.com/norio-nomura/0b7e38b114e03464d15d428c46257d4a (edited)

Factory.init.sil

おっ・・・

4:28 AM

Generalize factory patterns for use outside of NSValue by phausler · Pull Request #1095 · apple/swift-corelibs-foundation

swift - The Swift Programming Language

4:28 AM

except that copy_addr may be used even if %0 is of an address-only type. The copy_addr may be given one or both of the [take] or [initialization] attributes: [take] destroys the value at the source address in the course of the copy. [initialization] indicates that the destination address is uninitialized. Without the attribute, the destination address is treated as already initialized, and the existing value will be destroyed before the new value is stored.

4:29 AM

SIL命令copy_addr にオプションがつけられて、takeなら破壊、initializationなら初期化

4:30 AM

@norio_nomura の貼ったSILコードを抜粋すると (edited)

4:30 AM

... copy_addr [take] %6 to [initialization] %3 : $*Self, loc "<stdin>":4:14, scope 3 // id: %8 ... copy_addr %3 to [initialization] %0 : $*Self, loc "<stdin>":5:5, scope 3 // id: %10 ...

(edited)

4:31 AM

%0はメソッドのレシーバ、%3はローカル変数のself、%6はf()の戻り値の格納先なので

4:32 AM

f()は完全なオブジェクトを返して、それを破壊しながらローカル変数のselfに初期化代入、つまりムーブそのselfを、レシーバの真のselfに初期化代入、そのあとdesstroy_addrで%3を破壊してるんで、ここはコピー

4:33 AM

結論として、allocはされてるけど、initはされてない形で全部回ってますね

4:33 AM

ちゃんとコンパイラはわかっているっぽい

extension Int: Factory {}でIntに特化されたやつ

// thunk sil shared [transparent] [reabstraction_thunk] @reabstraction thunk helper from @callee_owned () -> (@unowned Swift.Int) to @callee_owned () -> (@out Swift.Int) : $@convention(thin) (@owned @callee_owned () -> Int) -> @out Int { // %0 // user: %3 // %1 // user: %2 bb0(%0 : $*Int, %1 : $@callee_owned () -> Int): %2 = apply %1() : $@callee_owned () -> Int, scope 7 // user: %3 store %2 to %0 : $*Int, scope 7 // id: %3 %4 = tuple (), scope 7 // user: %5 return %4 : $(), scope 7 // id: %5 } // end sil function 'reabstraction thunk helper from @callee_owned () -> (@unowned Swift.Int) to @callee_owned () -> (@out Swift.Int)'

store %2 to %0 で普通にコピーですね

4:35 AM

まあIntはtrivialなんでそもそもinitedかどうかとかが無い

4:35 AM

無駄は無い

4:35 AM

個人的に気になるのはprotocolの汎用版のまま struct について実行されるケース。

これの本当に微妙なところは差し替えられるselfが実はallocだけされていること、であってるかしら

-O つけると普通に無駄な alloc/dealloc 無くなっているので気にしなくて良い方向になってきた。

おお

マジか

-O付きも載せました https://gist.github.com/norio-nomura/0b7e38b114e03464d15d428c46257d4a

Factory.init.sil

struct Factory<T> { func `init`(_ f: () -> T) -> T { return f() } } let foo = Factory { let a = 1 let b = "2" return Foo.init(a: a, b: b) }

こっちはダメだった

文字列つかったらsilが5000行ぐらいになるな

4:46 AM

ああ printもやばい 800行ぐらいふえる

#linux-swiftへ少し書いたけど、swift-corelibs-foundationのprotocol Factoryを使った書き換えの範囲がかなり広がって来てます。 https://github.com/apple/swift-corelibs-foundation/pull/1095

-O のやつがよくわからない・・・

4:53 AM

selfを書き換える挙動が無くなっちゃってるように見える（見落としている

5:00 AM

うーむ。いろいろ試してみたけど、-Oで最適化されすぎちゃって、よくわからなかった。

Factory書き換えのPRの一部を眺めた https://github.com/phausler/swift-corelibs-foundation/blob/e2f4b859a109adcaa91e3f0ebd4336a2e29c9fcb/Foundation/NSString.swift#L497

phausler/swift-corelibs-foundation

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

5:13 AM

URLがファイルじゃなかったらData読んできて2バイトだけみて UTF16 BOM検出して、 CFStringの関数で初期化して、最後に self.init(factory: _unsafeReferenceCast(cf, to: NSString.self)) で、 CFのオブジェクトで差し替え

5:14 AM

CFStringを _unsafeReferenceCast とやらで無理やりキャストしつつ、selfを差し替えるから

5:14 AM

Toll-Free Bridgeがここで仕込まれる

5:14 AM

よくうごくなあ・・・

5:19 AM

https://github.com/phausler/swift-corelibs-foundation/blob/01ac7af46bc353083dea8b9056a70d92576cfbb3/Foundation/NSString.swift#L1302

phausler/swift-corelibs-foundation

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

5:19 AM

そのパッチを当てる前の実装は謎だ

 guard let enc = enc, let cf = CFStringCreateWithBytes(kCFAllocatorDefault, bytePtr, readResult.length, CFStringConvertNSStringEncodingToEncoding(enc.pointee), true) else { throw NSError(domain: NSCocoaErrorDomain, code: CocoaError.fileReadInapplicableStringEncoding.rawValue, userInfo: [ "NSDebugDescription" : "Unable to create a string using the specified encoding." ]) } var str: String? if String._conditionallyBridgeFromObjectiveC(cf._nsObject, result: &str) { self.init(str!) } else {

(edited)

5:20 AM

cfのオブジェクトを作ったあと、_conditionallyBridgeFromObjectiveCで CFStringを Swift.String にキャスト？して

5:20 AM

self.init(String) に渡してる

cf._nsObject

5:21 AM

ここがNSObjectへのキャストでは

5:21 AM

NSObjectをどうにかしてStringのポインタにぶち込んでる

internal init(_ string: String) { _storage = string } 最終的にどうやってToll Free Bridgeを成立させてたんだ？

5:22 AM

open class NSString : NSObject, NSCopying, NSMutableCopying, NSSecureCoding, NSCoding { private let _cfinfo = _CFInfo(typeID: CFStringGetTypeID()) internal var _storage: String

5:22 AM

物理的にやってる気配がする

https://github.com/apple/swift-corelibs-foundation/blob/e6babea2ba061d329cbb9e00e176f78379d3b187/Foundation/String.swift#L27

https://developer.apple.com/documentation/swift/string/1641523-init

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

open class NSString : NSObject, NSCopying, NSMutableCopying, NSSecureCoding { public static var supportsSecureCoding: Bool = true

ということは、NSStringを作るためにNSStringからStringを抽出してNSStringをまた作って…とやっていたので

新しい版だとそれがなくなってる

確かにそれならFactoryでalloc一回ぐらい多くてもどうとでもなる、というのはわかるw

@tarunon

} else if type(of: source) == _NSCFString.self {

この分岐みてるんだけど

5:26 AM

CFStringの中身をコピーしてSwift.String作ってる？

5:27 AM

中身コピーなくなってるならめちゃめちゃパフォーマンスが上がるよねこれ・・・

33行目の分岐如何によってはコピーしそう

5:28 AM

String(cfString:)はコピーするのかな

result = String(cString: str!)

5:29 AM

cfString:じゃなくてcString:だね

てかここはif let 使ってないのはなんでだ

C文字列のポインタコピーだと誰かが所有権を持たないといけないけど

5:32 AM

Swift String reference

5:32 AM

5:32 AM

Swift.Stringの init(cString:)は中身コピーだね

5:33 AM

33行目はどっちにいっても中身コピーだと思う。

5:35 AM

initの中でselfが書き換えられる事がわかったことで

5:35 AM

toll-free-bridgeをバイナリレイアウト互換でやっていたのを

5:35 AM

本当にNSStringとしてCFStringのポインタを返すやりかたに

5:35 AM

変更できたんだとすれば

5:36 AM

めちゃめちゃ大きい成果だと思う・・・

NSNumber のバグフィックスPRに protocol Factory を使った甲斐があったw

そこがきっかけなんですか？

そう

おお・・・

最初書いてたPRだと上手くいかないパターンを見つけて、Factoryを使う様に書き直したのです。 https://github.com/apple/swift-corelibs-foundation/pull/1093

Use CFNumberCreate() as factory initializer on NSNumber by norio-nomura · Pull Request #1093 · apple/swift-corelibs-foundation

This replaces #1025 by further utilizing the Factory Initializer Method (SR-5255). Use CFNumberCreate() as factory initializer on NSNumber.init(value:) Change NSNumber.init(value:) to returning i...

なるほど

最終的にどうやってToll Free Bridgeを成立させてたんだ？

メモリレイアウトが同じになる様、プロパティを配置しているはずです。

open class NSString : NSObject, NSCopying, NSMutableCopying, NSSecureCoding, NSCoding { private let _cfinfo = _CFInfo(typeID: CFStringGetTypeID()) internal var _storage: String 物理的にやってる気配がする

5:57 AM

そうみたいでした。

5:58 AM

http://qiita.com/omochimetaru/items/a520387d2b2e63f8efb5

SwiftのToll-Free Bridgeの実装を読む - Qiita

SwiftのToll-Free Bridgeの実装を読む

Toll-Free Bridgeとは

Objective-CにはToll-Free Bridgeという仕組みがありました。これは、C言語のライブラリであるCore...

でNSNumberの場合、CoreFoundationでの実装を見る限り固定長ではなくなってて、Swift側のメモリレイアウトが完全には互換になってなかった。 (edited)

昔NSDataについては調べたけど、これがもう古くなりますね

それを互換にするにはFactoryを使ってCoreFoundationで初期化するのがベストという結論になったです。

でNSNumberの場合、CoreFoundationでの実装を見る限り固定長ではなくなってて、Swift側のメモリレイアウトが完全には互換になってなかった。

あ〜〜〜〜〜

6:01 AM

型識別子とunionみたいな事をやっていたからか

6:02 AM

NSNumberというかNSValue由来？

CFNumberのTypeによってサイズが違う。 https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/NumberDate.subproj/CFNumber.c#L450

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

6:09 AM

16バイトになる場合があったけど、考慮されてなかった。 https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/NumberDate.subproj/CFNumber.c#L1291

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

うわ、ビット指定子だ

6:10 AM

なるほど〜

6:10 AM

CFNumberの中だけでこういうバイトサイズ最適化とかやってたんですね

6:11 AM

てか kCFNumberSInt128Type って128bit signed intか・・

6:12 AM

C++ stdに無いと思ったらlow/highにしてある。ひえー。 https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/NumberDate.subproj/CFNumber.c#L172

[Foundation] Add hack enabling factory intializer by rintaro · Pull Request #4087 · apple/swift

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

そう、NSNumberの動きを調べると色々CoreFoundationへ丸投げされてるので、Swiftでも同様に丸投げするのが近道。

add128とかある。

6:13 AM

なるほどです

Swiftの仕様がそれを妨げていたけど、protocol Factoryの抜け道で可能になった。

6:15 AM

ここでprotocol Factoryの話をしていなかったら、起きなかったことですよ

1

たしか @rintaro さんが self 書き換え術について紹介してて、 @rintaro さん自身がそれを知ったのは Swift の stdlib のどっかで見たって話だったんで、

6:18 AM

めぐりめぐっている

紹介されてからの、「なんだこれ、ヤベェ」→「いっちょやるか~」の動きはアグレッシブで好き

https://github.com/apple/swift/pull/4087/files @norio_nomura この PR 引き継ぎません？今だったらマージされるかも。

What's in this pull request? I'm not sure this can be accepted or not. But this is convenient in some cases. Using that: Simplify copy constructor of NSSet and NSDictionary Eliminate getVaList fro...

その辺りのクラスもほとんど含まれるんじゃないですかね？ https://github.com/apple/swift-corelibs-foundation/pull/1095/files#diff-fcd654c959279bc33608e36afcf6b430R352

Generalize factory patterns for use outside of NSValue by phausler · Pull Request #1095 · apple/swift-corelibs-foundation

6:29 AM

NSPredicateとNSExpressionが無いな。

Apple版 SDK オーバーレイの方なんです。

あああ、なるほど。

6:40 AM

チームが違うからphauslerさんもそのPRの存在も知らないのか。

swift-corelibs-foundationの方を引き合いに出すことになって、やぶ蛇になりそうな気がしなくもない…

その可能性は大いにあるｗ

1

とりあえず、マージされてなくても困っていなかったものであるなら、swift-corelibs-foundationでもう少し既成事実が出来上がるのを待ちたいw

1

政治だ…w

PR4087では

6:54 AM

このself書き換えって今後安定性どうなのよって

6:54 AM

話の流れになってるんですね。2016年8月に。

既成事実化→壊せなくなった→安定性保証されたから問題ない

6:55 AM

まあそれはそれとして、

おもしろいな・・・ｗ

convenience initでself代入出来るようにしたほうがはやいんとちゃう、っていうのは思う

6:56 AM

既成事実化した後でこっちのほうが筋が良いよって話になるのが良いのかな

ですね

-O のやつがよくわからない・・・ selfを書き換える挙動が無くなっちゃってるように見える（見落としている

7:35 AM

呼び出されるときに %0 がアロケートされたメモリを差すポインタになってて、それをそのまま apply %1(%0) でクロージャへ渡してる。

// Factory.init(() -> A) -> A sil hidden @(extension in main):main.Factory.init (() -> A) -> A : $@convention(method) <Self where Self : Factory> (@owned @callee_owned () -> @out Self, @thick Self.Type) -> @out Self { // %0 // user: %4 // %1 // users: %4, %3 bb0(%0 : $*Self, %1 : $@callee_owned () -> @out Self, %2 : $@thick Self.Type): debug_value %1 : $@callee_owned () -> @out Self, let, name "f", argno 1, loc "<stdin>":3:12, scope 2 // id: %3 %4 = apply %1(%0) : $@callee_owned () -> @out Self, loc "<stdin>":4:18, scope 3 %5 = tuple (), scope 3 // user: %6 return %5 : $(), loc "<stdin>":5:5, scope 3 // id: %6 } // end sil function '(extension in main):main.Factory.init (() -> A) -> A'

(edited)

そうなんですけど、それだとインスタンスが差し替わるパターンに対応できないですよね

7:36 AM

実際のインスタンスが何の型になってるかは、 %1のクロージャの返り値次第です

あいや、selfはポインタのポインタなのか。

あ〜

呼び出し側

 alloc_global @main.foo : Swift.Int, loc "<stdin>":9:5, scope 1 // id: %2 %3 = global_addr @main.foo : Swift.Int : $*Int, loc "<stdin>":9:5, scope 1 // user: %11 … %11 = apply %4<Int>(%3, %10, %6) : $@convention(method) <τ_0_0 where τ_0_0 : Factory> (@owned @callee_owned () -> @out τ_0_0, @thick τ_0_0.Type) -> @out τ_0_0, loc "<stdin>":11:1, scope 1

7:40 AM

https://github.com/apple/swift/blob/master/docs/SIL.rst#global-addr

NSNumber.init.sil.terminal.sh-session

swift - The Swift Programming Language

7:41 AM

Creates a reference to the address of a global variable which has been previously initialized by alloc_global. It is undefined behavior to perform this operation on a global variable which has not been initialized.

直前のalloc_globalと連動しているのか

ごめんなさい

-O つけると普通に無駄な alloc/dealloc 無くなっている

これは嘘だったぽい結論

呼び出し前にallocされてるのが無駄になるってことですね

7:44 AM

ただ、さっきのgistで使ったIntの例だと、-OでFactory.init(_:)の呼び出し自体が無くなってる。

ポインタのポインタになってます？

a reference to the address of a global variableですね (edited)

7:47 AM

最適化でクロージャ自体が無くならない様な例にしないと…

ただ、さっきのgistで使ったIntの例だと、-OでFactory.init(_:)の呼び出し自体が無くなってる。

ああ、ですね。

そう、なので -O だとジェネリックな実装が呼ばれないので、無駄なalloc/deallocって無いような気がする。

はい、ただ、ライブラリ側で Factory.init(_:) を提供していて　別のリンク単位からそれを使う場合は

7:53 AM

その最適化はできないので

7:53 AM

その場合にどうなるかですね・・・

Factory.init(_:) と extension NSObject: Factory を提供するだけのライブラリ作って、Kotlinパワーを手に入れるぞ!!とか考えてた

swift-corelibs-foundationではFactoryはinternalになってますね。

swift-corelibsで CF差し替えとかで使ってる限りはその部分はこのようにインライン化されてそうですね。

あいや、swift-corelibs-foundationの場合は無駄になってますね。 (edited)

あら？

Factory.init を使う public convenience init の呼び出し前に alloc されちゃうので

7:56 AM

少なくとも現状は無理ぽい。

一番外側でFactory.initなら無駄がない?

全部Swiftで完結しててFactoryがinternalなら無駄は ~~無くなりそう。~~ 無くならない。 (edited)

ふむふむ

public initの中でFactory.init(_:)を使っている場合、Standard Libraryのメソッドならインライン化されて無駄にならないのかな？

8:01 AM

Standard Libraryは特別にインライン化される仕組みでしたよね、確か。

https://gist.github.com/rintaro/b56487baafcfde7767c21193c540ffce これでも alloc/dealloc 走っているので、 convenience init 使ってる限りだめっぽいです。

1_test.swift

なるほど

// makeBase(a : Int) -> Base sil @main.makeBase (a : Swift.Int) -> main.Base : $@convention(thin) (Int) -> @owned Base { bb0(%0 : $Int): %1 = alloc_ref $Base, scope 6 // users: %6, %7 %2 = alloc_ref $Base, scope 16 // users: %8, %5, %4, %3 debug_value %2 : $Base, let, name "self", loc "<stdin>":10:15, scope 23 // id: %3 debug_value %2 : $Base, let, name "s", argno 1, loc "<stdin>":4:10, scope 29 // id: %4 debug_value %2 : $Base, let, name "s", argno 1, loc "<stdin>":4:10, scope 29 // id: %5 %6 = value_metatype $@thick Base.Type, %1 : $Base, loc "<stdin>":15:10, scope 32 // user: %7 dealloc_partial_ref %1 : $Base, %6 : $@thick Base.Type, loc "<stdin>":15:10, scope 32 // id: %7 return %2 : $Base, loc "<stdin>":20:3, scope 4 // id: %8 } // end sil function 'main.makeBase (a : Swift.Int) -> main.Base'

scope 6がBase.init()でscope 16がBase.init(_:)で、それぞれで alloc_ref が動いてる。

NSNumberをkCFBooleanFalseに差し替え、当然__ObjC.NSNumberのallocは無くならない。 https://gist.github.com/norio-nomura/1632926c9163ea03e4d9ff701b1fac51

Ruby の 1..2 は Swift の 1...2 で Ruby の 1...2 は Swift の 1..<2 で ... の意味が逆・・・

最初出た頃思いましたｗ

3:36 AM

いや、最初は揃ってたんだっけ...うる覚え

今のSwiftの状態は覚えやすくて良い。 . が数直線の端にうった　●　の事だと思うと 1...2 の左の点と右の点は　含むよって意味にとると筋が通る

なら半開区間は..。か・・・

白丸の代わりが < で。

3:39 AM

将来的に左を含まないやつが出るときには 1<..2 と 1<.<2 になってくれると嬉しい (edited)

なるほど、たしかに右辺左辺両方表現できて良さそう

1<..2欲しい…

どんなときにほしいと思ったんですか？

switch 文の範囲指定の時ですね

3:43 AM

今ですと、例えば1より大きい時の範囲を描く場合は case let x where x > 1 を書くか、case 1 ... .max の前に case 0 ... 1 を書かないとダメなので

~=でも

なるほど。たしかに不等式でswitchしたい時に大なりが取りたくなるとそうなのか。

最終的には case .min ..< 0: case 0: case 0 <.. .max だけで網羅性確認済みにして欲しい

たしかにif文で if (x < 0) { } else {} って書くより switch でそう書けて、網羅検査されたほうが、両方のパターンが明記されて嬉しいな

3:48 AM

if で網羅しようとすると最後の else に条件が書けないか、条件を書く + 空のelseになるから switch - case にしたくなる時がある

ですよね

めっちゃほしくなってきた

何よりif else文よりswitch case文の方がスマートに見える（）

if (a) { } else if(b) {} else {} だとb時点でaでないってことを頭に入れながらelseも考えないといけないから実は読みづらかったり

そうそう

でもそれswitch文でも同じですね、case b: の時点では case a: でないということ

3:52 AM

さっきの例ですとまさに case 0 ... .max で書いた時は仮にもしその前に case 0: があったら0の時に case 0 ... .max に入ることはないということ

確かに

最終的には case .min ..< 0: case 0: case 0 <.. .max だけで網羅性確認済み

ここで網羅性まで抑えてくれてdefault書かなくて良くなったら最高ではあります

作るかw

3:59 AM

switch case文で使える ~= だけに対応するやつなら多分作れるんじゃないかと

話の流れと関係ないけど let a = [1,2,3] a[...] // -> [1,2,3] これの実現をしているコードがすごい

4:04 AM

https://github.com/apple/swift/commit/4dee6ead#diff-ef421a80a004f996d47697e4c2074790L931 (edited)

[stdlib] Provisional c[...] syntax while we await language features · apple/swift@4dee6ea

a[...] こんなのありましたっけ

あれ、 https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md に含まれてないのか (edited)

https://github.com/el-hoshino/Eltaso/tree/master/Eltaso/Eltaso

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

+// FIXME: replace this with a computed var named `...` when the language makes +// that possible. +public enum UnboundedRange_ { + public static postfix func ... (_: UnboundedRange_) -> () { + fatalError("uncallable") + } +} +public typealias UnboundedRange = (UnboundedRange_)->() + public subscript(x: UnboundedRange) -> SubSequence { + get { + return self[startIndex...] + } + set { + self[startIndex...] = newValue + } + }

4:07 AM

あっ、これ、そういうことか？

4:08 AM

... は演算子で、形式的に UnmoundedRange_ を引数１個取って消化する関数で

4:08 AM

subscript は、 UnboundedRange_ を消化する関数を受け取るオーバーロードなのか。

4:09 AM

お、このテクニックで、好きな演算子を、演算子単体で存在する型として取り回すことができるな。

ダメだ、< で始まる演算子が作れないorz

なるほど...dummyの演算子を置いてってことなんですね

しかもそこで 0 case enum を使って　実際にその値が作れないようにしていますね

作れませんか？

. を含む operator は . が最初になければいけない言語仕様。

1

魔力高い

読めない英語のメッセージが出た

.<. と .<< 作るか

@tarunon が好きそうだからリプライ送っておこう

<===とかは作れる

なんにゃ

Swift定義済みのPrecedence一覧ってどっかないですかね？

@tarunon ちょっと↑にある array[...] っていうコードの実現方法がトリッキー。 ... は省略じゃなくてどっと３つのコード (edited)

なんだこれw

確認するときは import Swift 打って Cmd + クリックしちゃいます。＞ Precedence一覧

おおお流石！ @rintaro

. を含む operator は . が最初になければいけない言語仕様。 これがボディーブローのように効いてるような気がする

4:17 AM

上界と下界が閉じてる開いてるの違いを表現するのに、1つめと3つめの.を変化させるのが絶対に理解しやすいと思うんだけどな

1

4:19 AM

..., ..<, <.. <.<で4通り、意味もパット見で即理解できる

4つめは <..< のほうがいいきがしてきた

意味さえわかればそれでおk

4:20 AM

... は 演算子で、 形式的に UnmoundedRange_ を引数１個取って消化する関数で subscript は、 UnboundedRange_ を消化する関数を受け取るオーバーロードなのか。 お、このテクニックで、好きな演算子を、演算子単体で存在する型として取り回すことができるな。

4:20 AM

これがテンション高い

↑それを見てほしかった

pythonのarray[:]みたいなのができそう

関数を受け取る関数を作ってそこにオペレーターをぶち込めるの、脳汁湧きますね

4:21 AM

世界が広がった

0 case enum をつかってそれの直接利用も封じてある

ため息が出る

Xcode9 で _ 打つと UnboundedRange_ が補完されるのがうざいｗ (edited)

なるほどなるほど~~~

1

@rintaro 本当だ

myObject.hello(+, x) と myObject.hello(-, x)で別の関数を呼ぶとか出来ますね

4:24 AM

しかしこれ、中二病心を擽るけど実用したら他の人死んじゃうのでは

それはそう

あーー

4:25 AM

結構便利な利用シーンは思いついた

4:25 AM

あとで試してみよう

4:26 AM

これoperatorならではのハックなんですかね?普通の関数名でやりたい

4:26 AM

dataSource(reload, ....) と dataSource(animated, ....) を分離出来るのは思いついていて

普通の関数だと () つけないといかんのでは？グローバル変数使えばいけるかな

グローバルに関数を置くのは忍びないな

4:27 AM

まあ引数が存在しない0 enumなら許せるか

よし最低限の実装書いたった

.<< にしたんですね .<.. とかはどうでしょう？

.<< と .<. にしてました

なるほど

やっぱり <.. と <.< 使いたいんですよね

4:34 AM

さてこれEltasoの中に入れとくべきか別フレームワークにすべきか悩む

4:35 AM

（まあ使う人そんなにいないでしょうからEltasoに入れるのも悪くない気がしないでもないがなんかEltasoがだんだん何でも屋になってきて微妙

el-hoshino/Eltaso

Eltaso - This is a framework that contains some convenient methods and extensions for myself

4:36 AM

いろいろありますねえ

色々ありすぎて自分のプロジェクトに大体これインポートしてるので依存性がやばい気がする、特に引き継ぐ人にとって

全部入りは何かとしんどそう

こういうの作りたくなる気持ちはめっちゃわかる

SwiftCoreLibとFoundation、それからUIKitぐらいは区切ってもいいと思いました

4:40 AM

拡張元のモジュールごと、ですね

Matrix<T> とかは？

FoundationExはSwiftCoreLibExをimportするんじゃないかな

Eltaso最初作った時はあんまり深く考えてなかったんですよね、最初の頃はただ単にハッカソンやっててこういうの欲しいなって思ったやつをとりあえず入れといてみただけのフレームワークですけど、やがて仕事にもこれ使い始めて気づいたらやばいことにw

ｗｗ

Matrix<T>はさすがにそろそろ出してもいいじゃないかと思ったり

Matrixはサイズを型に持たせて安全にしたくある

https://github.com/el-hoshino/Eltaso/blob/master/Eltaso/Eltaso/Matrix.swift#L148-L166 このパターン楽なんですけどtranspose()のほうが実装を持ってtransposedがそれを使うほうが速度的にはいいよなといつも思う (edited)

el-hoshino/Eltaso

Eltaso - This is a framework that contains some convenient methods and extensions for myself

速度的にはそっちの方が早いですね

4:46 AM

ただなるべく直接自分自身をいじらないようにしてますので、いじる時は必ずバックアップとってバックアップの方をいじって自分自身をバックアップにするというスタンスを取ってますので（）

4:47 AM

特にMatrixみたいなやつだといじってる途中で落ちたりしたらめっちゃ怖い気がw

swift書いてるとだいたいletで取り回すんで自分自身を書き換えるほうが主になると変な気分になりますよね (edited)

ですね

ご飯食べてたら乗り遅れた・・・

5:12 AM

<.. と <.< 、前にここで話してたときに作ろうとしてコンパイラに阻まれて諦めた・・・

やはりすでに屍、じゃなかったパイオニアが

でもそれも実現したら Swift4 の Range 系の型が爆発してヤバそう・・・

5:14 AM

1... とかもできたし、 Countable もあるし

<.. と <.< はさすがに起点がないから Countable は作れないと思いますね

5:15 AM

なので多分 Strideable には作れないと思います

整数なら数えられませんか？

5:16 AM

one sidedなら無理ですが

今の Countable って条件は要素が Strideable だっけ？

let a: CountableRange<Int> = 1..<10 // OK (edited)

public struct CountableRange<Bound> : RandomAccessCollection where Bound : Comparable, Bound : _Strideable, Bound.Stride : SignedInteger {

(edited)

public struct CountableRange<Bound> : RandomAccessCollection where Bound : Comparable, Bound : _Strideable, Bound.Stride : SignedInteger

ふむふむ

_Strideable は実質的に Strideable です。

Striderableに始点が必要なのか Striderableで左開区間なら左辺値の次が取れるはずなんでCountableにできそうな (edited)

左辺値の次の値で取るって仕様って実際どうですかね？それかけるなら次の値わかる気がしないでもないような…

5:20 AM

あるとすれば数字が一致させられることに意味があるなのかな？

(0, 10].count == [0, 10].count - 1

@lovee 色々ありすぎて自分のプロジェクトに大体これインポートしてるので依存性がやばい気がする、特に引き継ぐ人にとって

@tarunon 全部入りは何かとしんどそう @omochimetaru こういうの作りたくなる気持ちはめっちゃわかる

僕もこういうのほしくなるんですが、細かく分割して、全部 dependencies に突っ込んだライブラリ一個作って、自分が使うときはそれを使えば全部引っ張ってこれるんじゃないかと考えてます。ついでに、全部入りの方で typealias 作りまくったら、全部入りの一つ import したら全部使えそう。試してないんで落とし穴があるかもですが。

マイクロフレームワークアーキテクチャですね

ただ、困るのは分割した A と B の両方を組み合わせた機能をどうするかなんですよね。

組み合わせた機能を提供する C を作るか、 A -> B か B <- A のどちらかで依存を規定するか

でも問題は結局のところ、自分のプロジェクトを引き継ぐ人が依存されてるライブラリーをわかってないと辛いってところですね

内部的に使うとかなら片方に依存でいいんですが、 AとAのextension的なBがあったときが悩ましい

まあ引き継ぐ時と自分が作る時、どっちに負担を寄せるかっていうのはどっちかを選ぶしか無いから

それはBにimport Aですかね？

自分が楽に作れる方に寄せといて、引き継ぐ時に必要ならライブラリを分割するとか剥がすとか教えるとかしたらいいんでは

5:26 AM

それはもう本来的に回避できない引き継ぎコストなんだと思う

組み合わせた機能を提供する C を作るか、 A -> B か B <- A のどちらかで依存を規定するか

A と B はシンプルに保ちたいから依存はしたくなくて、でも C を作り出すと組合せ爆発する。

ある程度作って丸投げ納品するみたいなあとで引き継ぐ予定がはっきり決まってるときはおいといて、だいたいはあとのことは不確定だから今のことを有線した方がいい

例えば、 Promise と Result のライブラリがあって

演算子はなんか行儀悪いって思ってしまう、そんなこと言ったらRxなんかどうなるだって話ですけど

組み合わせてエラー処理を含んだ Promsie<Result<T>> についての extension を作って

5:27 AM

一方で Runes の演算子使ったとき用の拡張を作りたくて、 Promise+Runes, Result+Runes ができて

5:28 AM

（演算子は衝突するので元のライブラリから分離しておきたい）

import funcで頑張る案

じゃあ Promise+Result+Runes もほしくて、とか。

ライブラリ単位で依存グラフ作っていくとややこしくなるので

5:29 AM

本当は　「このライブラリを一緒に使っているなら有効化される」　っていう仕組みがあったらいいのかな？

うん。そういうのがほしい。

依存じゃなくて連携機能。

弱依存みたいな。

5:29 AM

あったら使えるけどなかったら消える。

C/C++だとmakefileでそこらへんを検査してマクロスイッチでコントロールしたりできますね

5:29 AM

なんなら依存先ライブラリを切り替えたりもする

5:30 AM

Swiftにも #if があるから Package.swift での制御とか組み合わせたらそういうことをやる余地あるかな (edited)

共通のプロトコルを同じ分野のライブラリで協定結んじゃった方がって気も... さすがに用途一緒だからってスイッチできる仕組みを考え出すと大変そう

C -> A, B のときに、 A のビルド時の #if で C が B にも依存していることを検知して切り替えるのは難しそう。

ライブラリ単位で依存グラフ作っていくとややこしくなるので

本当は　「このライブラリを一緒に使っているなら有効化される」　っていう仕組みがあったらいいのかな？欲しい

#if is_spm_include("B") (edited)

共通のプロトコルを同じ分野のライブラリで協定結んじゃった方がって気も...

うーん、でも Result は antitypical/Result を使いたいとかもありますし、Runesも代わりのOperadics があるし、自由な組み合わせで使えるようにしたいんですよねぇ。 (edited)

5:35 AM

で、これを抽象化した ResultType プロトコル作って、使う側で extension Result: ResultType すれば OK にしようとしたら、 Higher-kinded type がないのでアウト

単純にライブラリ提供側が実装大変だなーとは思ったんですよね、絶対便利だからあった方がいいと思う自分もいつつ同じ用途だと言ってA1にはこの機能あるけど、A2にはない、そしてライブラリ提供のために足りないA2を自前で補填しなきゃ...的なことを考えてました

5:38 AM

使ってもらうことを考えたらそれぐらいの苦労は問題ないかもですが

大変でもそれがやりたいときがあるっていう前提じゃないですかね

そうですねー。 A と B1 を組み合わせたら便利だけど、他との依存関係の問題で B2 を使わざるを得ないときに、 A と B2 でも使えるよ、とかですね。 (edited)

大変でもそれがやりたいときがあるっていう前提じゃないですかね

確かに、それができるってことが大きいとは思います

5:40 AM

（ライブラリ作ってて非同期ライブラリの選定にいつも悩むので切実に欲しいです）

1

↑の UnboundedRange がほしいのって、 subscript(_ f: (Element, Element) -> ClosedRange<Element>) -> SubSequence だと ... 以外が入れられるから？

その定義では ... が入れられなくないですか？

let a: (Int, Int) -> ClosedRange<Int> = (...) // OK (edited)

6:00 AM

func foo<T: Comparable>(start: T, end: T, _ f: (T, T) -> ClosedRange<T>) -> ClosedRange<T> { return f(start, end) } foo(start: 1, end: 10, ...) // OK

やるなら Element じゃなくて Index のほうが良いと思いますが、 ClosedRange 型を使いたくなかったからだと予想。

やっと言ってることがわかった ... 演算子自体の型をうけとけば ... が渡せるってことか。

extension Collection { subscript(_: (Index, Index) -> ClosedRange<Index>) -> Int { return 1 } } let res: Int = [1,2,3][...]

で通るので、出来なくはない。 (edited)

extension Array { public subscript(_ f: (Int, Int) -> ClosedRange<Int>) -> ArraySlice<Element> { return self[startIndex..<endIndex] } }

6:04 AM

Swift 3.1 でできた。 (edited)

6:04 AM

let ns = [2, 3, 5] ns[...] // [2, 3, 5]

それだと型が一致してるクロージャでも呼べちゃうしシグネチャ見てなんだこりゃってなりそう

<.. とか <.< とか作ろうとしたときに↑もしようとしてた。

UnboundedRangeって言葉が出て来るのと、 ... 演算子である事が必須になるので、そっちのほうが望ましいと思う

ClosedRange 型を使いたくなかったからだと予想。

これは Closed の部分じゃなくて、意味の異なるものを使いたくなかったってことですよね？

1

6:08 AM

なんで UnboundedRange の ... は infix じゃなくて postfix なんだろう？

6:09 AM

フリーで存在する後置演算子ってあまり見かけないから変な感じがする。

1...

6:09 AM

こいつでは

CountablePartialRangeFrom<Int>(lowerBound: 1)

6:10 AM

ほんとだ。

ああ、 UnboundedRange_ 。↓のこと。 https://github.com/apple/swift/commit/4dee6ead#diff-ef421a80a004f996d47697e4c2074790R935

[stdlib] Provisional c[...] syntax while we await language features · apple/swift@4dee6ea

オーバーロードにぶち込む幽霊型のためなので、1引数だけで良くって、1引数だとinfixはないから (edited)

6:11 AM

大きな理由は特に無い気がする

@tarunon [...] のためだけに使う（コールしない）ので、 infix でも postfix でも同じじゃないですか？

6:11 AM

ああ、入れ違った

6:12 AM

最小限にとどめたら 1 引数になったってことなのかな。

6:14 AM

numpy みたいに、 array[:, 2, 3, :, 5] のように書けるようにするには、 ... が nominal でないのが辛いなぁ。

6:14 AM

Union があれば解決するんだけど・・・。

ゲッそんなの出来たのかw

6:17 AM

随分昔にちょろっと触っただけなので全容を把握してない > python

extension Tensor { subscript(indices: Int|Range<Int>|ClosedRange<Int>|PartialRangeUpTo<Int>|PartialRangeThrough<Int>|PartialRangeFrom<Int>|UnboundedRange...) -> Tensor

6:17 AM

こうしたい・・・

6:18 AM

Countable も。

6:18 AM

..<10 もできるようになるのか。 Swift 4

6:19 AM

UnboundedRange 以外は nominal だから

numpyの場合array[..., 1]の...はそこまでの次元全てを示すからまた意味がずれる

extension Int: Indexing {} extension Range: Indexing {} ... とかして、 extension Tensor { subscript(indices: Indexing...) -> Tensor } でいいけど、 UnboundedRange だけはどうしようもなさそう・・・。

6:21 AM

Swift で tensor[..., 2, 3, ..., 5] やりたい・・・。

...の型にプロトコルつけられないからか。

はい。

6:22 AM

tensor[1..., 2, 3, ..<4, 5] まではできる。

特別な型と、その定数を用意するのが良い気がしますねぇ

6:23 AM

np.newaxisみたいに

@t.ae それって ... 使えなくない？

UnboundedRange <- こいつをGenericsにしてIntの場合にoperator生やすとかで誤魔化せませんかね

@koher なので記号をどうするかが問題ですね numpyに合わせて:使えたら良かったんですけどもちろん使えない

@tarunon ↓ですからねぇ・・・ public typealias UnboundedRange = (UnboundedRange_)->() https://github.com/apple/swift/commit/4dee6ead#diff-ef421a80a004f996d47697e4c2074790R939 (edited)

[stdlib] Provisional c[...] syntax while we await language features · apple/swift@4dee6ea

オレオレで作れば行けるのでは、と思ったけど

... を演算子としてしか使えない以上どうにもならなさそう・・・

unicode使えるんだからなんか適当なのを使えば良い気もする入力は置いといて

@t.ae 記号を当てるのはもちろんできるけど、それだと array[...] とかとの一貫性がなくなっちゃう・・・ (edited)

ああ、そういうことか

6:27 AM

union欲しいの意味がわかった

有限個なら書き下せるんだけど、パターンが無限なので書き下せない・・・ (edited)

gybで10個ぐらいの組み合わせを生成すれば良いのでは

ですね。

どうせ2, ..., ..., 5みたいなのは弾かないといけないから厳密にはunionもダメ出し

10 はちょっとやばい。 2 ^ 10 = 1024 にｗ

w

tensor[2, ..., ..., 5] はできますよ。

Okなんすか…

tensorswiftに入れてましたっけ？僕が別で書いたのはあります https://github.com/t-ae/ndarray/blob/master/Sources/Indexing.swift

t-ae/ndarray

ndarray - Float NDArray library for Swift, accelerated with Accelerate Framework

@t.ae そもそもまだ TensorSlice の PR を取り込んでない気がする。

たしかに

@tarunon

import numpy as np a = np.array([[[[1, 1], [2, 2]], [[3, 3], [4, 4]]], [[[5, 5], [6, 6]], [[7, 7], [8, 8]]]]) a.shape # (2, 2, 2, 2) b = a[0, :, :, 0] b.shape # (2, 2) c = a[0:1, :, :, 0:1] c.shape # (1, 2, 2, 1)

(edited)

6:37 AM

N 次元超立方体を考えて、 : の次元は残して、インデックス指定してる次元での断面を求めてるイメージ (edited)

6:38 AM

>>> print(b) [[1 2] [3 4]] >>> print(c) [[[[1] [2]] [[3] [4]]]]

ああなるほど、根本から誤解していた

なるほど、普通の list だと思ってたってことですね。

6:49 AM

そっちは

>>> a = np.array([2, 3, 5, 7]) >>> a[0, 2, 3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: too many indices for array

はできませんが >>> a[[0, 2, 3]] array([2, 5, 7]) はできます。 (edited)

6:49 AM

↓はできないです。 >>> a[[0, 2:4]] File "<stdin>", line 1 a[[0, 2:4]] ^ SyntaxError: invalid syntax

深さ5の32個オーバーロードで現実的には足りそう

↓はできるかと思ったらできませんでした・・・。

>>> a[[0, range(2, 4)]] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: too many indices for array

深さ5の32個

One sided rangeとか入ってくると増えますよ

Python の i:j は [] の中でだけ有効な記法なので、 [[0, 2:4]] とかはそもそもあり得ないんですが、 [[0, range(2, 4)]] もだめでした・・・。

6:52 AM

@t.ae ... 以外はプロコトルでまとめるので大丈夫。

なるほど。

... とそれ以外の 2 通りの 5 乗。

だめだぁ、 ... とリテラルがどうしてもつながらない。

6:53 AM

enum MyIndex { case value(Int) case range(Range<Int>) case closedRange(ClosedRange<Int>) case partialRangeUpTo(PartialRangeUpTo<Int>) case partialRangeThrough(PartialRangeThrough<Int>) case unbound } prefix func + (x: Int) -> (MyIndex.Type) -> MyIndex { return { _ in .value(x) } } func ..< (x: Int, y: Int) -> (MyIndex.Type) -> MyIndex { return { _ in .range(x..<y) } } func ... (x: Int, y: Int) -> (MyIndex.Type) -> MyIndex { return { _ in .closedRange(x...y) } } prefix func ..< (x: Int) -> (MyIndex.Type) -> MyIndex { return { _ in .partialRangeUpTo(..<x) } } prefix func ... (x: Int) -> (MyIndex.Type) -> MyIndex { return { _ in .partialRangeThrough(...x) } } postfix func ... (_: MyIndex.Type) -> MyIndex { return .unbound } func foo(_ indices: (MyIndex.Type) -> MyIndex...) { print(indices.map { $0(MyIndex.self) }) } foo(..., 0..<12, +12)

+ は ExpressibleByIntegerLiteral にできそう。

リテラルがつながらないってどういうことです？

(MyIndex.Type) -> MyIndex が ... のために必要なので、 ExpressibleByIntegerLiteral にはできないのです。 (edited)

6:57 AM

「リテラルとRangeファミリー」もしくは「Rangeファミリーと ...」を受けるものは作れるけど、「リテラルとRangeファミリーと...」を全部受けるのは出来ないって言う意味です。

やっとわかってきた・・・

7:00 AM

関数型に寄せてるんですね。おもしろい・・・。

autoclosureにできたりしないかな

@autoclosure だと強制になっちゃうから

可変長の個々だから無理か・・・

@autoclosureable みたいなのがあればいいのかも・・・

7:04 AM

まず↓ができなかった

 1> func sum(_ fs: (@autoclosure () -> Int)...) -> Int { 2. return fs.reduce(0) { $0 + $1() } 3. } error: repl.swift:1:18: error: @autoclosure may not be used on variadic parameters func sum(_ fs: (@autoclosure () -> Int)...) -> Int { ^

SE-0157: Support recursive constraints on associated types https://github.com/apple/swift/pull/10940

SE-0157: Enable recursive protocol constraints by default. by DougGregor · Pull Request #10940 · apple/swift

We don't know if they work in general, but specific cases of recursive protocol constraints are working, and enabling them doesn't break anything.

^ Standard Libraryの変更はまだ含んでいなくて、recursive protocol constraints出来る様にするPRだった。

protocol Sequence { associatedtype Filtered: Sequence associatedtype SubSequence: Sequence } こうなるのかな

Mapped ができるのはいつのことやら・・・

高階型が出来たとして、Sequenceの上位にMonadとかFunctorとか整備されるのか微妙に気になるw

今の感じだとされなさそうですね。 Core Team はそういう方向に進むのにネガティブっぽいです。

5:52 AM

ただ、 map の結果を型によって lazy にしたいというニーズはありそう。 (edited)

今Lazyのmapってoverloadでしたっけ？

今どうなってるかわからないですが、 Filtered は確かそんな理由で導入されてましたよね？

/// A sequence containing the same elements as this sequence, /// but on which some operations, such as `map` and `filter`, are /// implemented lazily. /// /// - SeeAlso: `LazySequenceProtocol`, `LazySequence` public var lazy: LazySequence<LazySequence<Base>> { get } /// Returns a `LazyMapSequence` over this `Sequence`. The elements of /// the result are computed lazily, each time they are read, by /// calling `transform` function on a base element. public func map<U>(_ transform: @escaping (Base.Iterator.Element) -> U) -> LazyMapSequence<Base, U>

5:54 AM

overloadですね

↑見て思ったんですが、 filter も @escaping になるから型が変わりそうな気が

あーそっか

5:55 AM

そもそも引数のクロージャが @escaping になるかどうかという違いがあるから

Sequence の filter は @escaping で、 Array とかはそれを @nonescaping として上書きするんでしょうか？

Sequenceの範疇にLazySequence入れるのがそもそも悪手な気もする

@escaping (T) -> U は T -> U のサブタイプ（？）だから、一応まとめられそう？

5:59 AM

引数のオーバーライドは反変だからスーパータイプで引数が @escaping (T) -> U だったのを (T) -> U でオーバーライドできるはず。

throws rethrowsってLazyだとどうするべきなんですかね

あー

6:01 AM

rethrows はできないですね。

将来的にasync reasyncも入れるとして

6:01 AM

まあそういうの含めて

async / await がないと。

SequenceとLazySequenceは分けて考えたほうが良さそうで

6:02 AM

Sequence側にflatMap経由のLazySequenceへの変換と、LazySequenceにSequenceへの変換があれば

6:02 AM

すっきりすると思うんですよね

protocol Sequence { associatedtype Filtered func filter( _ isIncluded: (Iterator.Element) throws -> Bool ) rethrows -> Filtered } extension RangeReplaceableCollection { func filter(_ isIncluded: (Iterator.Element) throws -> Bool) rethrows -> Self { var result = Self() for element in self { if try isIncluded(element) { result.append(element) } } return result } }

6:04 AM

Lazy じゃなかった？

6:04 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md

https://developer.apple.com/documentation/swift/set/2905721-map

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

RangeReplaceableCollectionは別にLazyではないのでは

Lazy のためにほしかったと勘違いしてました。

やっぱりどう考えてもLazyをFilteredとかの範囲だけで解決するのは無理で

6:05 AM

SequenceとLazySequenceを分離したほうが最終的に平和な気がする…

6:06 AM

というかですね

6:06 AM

@escaping (T) -> U は T -> U のサブタイプ（？）だから、一応まとめられそう？ 引数のオーバーライドは反変だからスーパータイプで引数が @escaping (T) -> U だったのを (T) -> U でオーバーライドできるはず。

6:06 AM

これから導かれる結論は

6:06 AM

protocol Sequence: LazySequence {

6:06 AM

なわけで。

そうですね。

6:07 AM

map は Array 返すけど filter は Self 返すんですね・・・。 https://developer.apple.com/documentation/swift/set/1688238-filter

6:10 AM

Set の map に Beta ってついてる・・・。なぜ？？

6:10 AM

protocol Sequence: LazySequence は割りと無理があった

6:18 AM

Set.mapがBetaなのは将来的にSetにしたいってことでは?という妄想

Xcode 9.0+ になってるけど、昔から使えましたよね？？ https://developer.apple.com/documentation/swift/set/2905183-map

Setが生まれたときから生えてると思いますよ

6:21 AM

↑の二つ何が違うんだろう？？？

Set: Collectionなので、

6:26 AM

Collectionのデフォルト実装のmapとSetのmapの実装の両方が見えてるのかな

シグネチャが全く同じでも上書きじゃなくて共存するんですっけ？？ドキュメント生成ツールの都合上？

後者だと思います、witness-tableに登録されるしどうやってもSetでCollection.mapは呼べないと思う

1

6:52 AM

Set.mapとCollection.mapのDocComment見るとだいたい納得できそう

6:52 AM

多分2つあるmapの差分と同じ差分があると思います。

それが確認できたらほぼ確実ですね。

二つの違いはわかりませんが、 Beta なのは Self.Iterator.Element が Self.Element になったからだと思います。シグネチャ変わってしまったので。

なるほど。

9:23 AM

確かに Array も Beta になってました。 https://developer.apple.com/documentation/swift/array/2907114-map

enumのassociatedvalueにNever入れたこと無いから意識してなかったけど、Never入ってるcaseは無視してもコンパイル通るようになって欲しいかなとか思った

12:25 PM

enum Enum2<T0, T1> { case case0(T0) case case1(T1) } func just<T>(_ x: T) -> T { return x } func just<T>(_ x: Never) -> T { fatalError() } func foo(x: Enum2<Int, Never>) -> Int { switch x { case .case0(let x): return just(x) case .case1(let x): return just(x) } }

12:27 PM

NeverがBottomなら気にしなくても済むのかな

KotlinのNothingはBottomなんでしたっけ、これは通ってそう？ fun alwaysFail(): Nothing { throw RuntimeException() } fun <T> nothingCheck(nothing: Nothing): T { return alwaysFail() } (edited)

Neverは本来発生しない値なので、Bottom型として扱えるなら、↑で書いたjustみたいな回りくどいことはしなくてよくなるけど

12:51 PM

そもそもその論調で行くならcase自体存在しないはずですよね、ということです。

12:51 PM

kotlin NothingはBottomでしたっけ、

ボトムですね < Kotlin

12:52 PM

Bottom Never の実験するとき Kotlin 使ってます。

12:53 PM

まあSwiftじゃないので完全に同じじゃないですが。

なるほど、Neverの定義がある場合はBottomかつデフォルトのNever値が呼ばれるなら確かに推論でどうにかなりそう (edited)

Neverなcase、無視できたら良さそうですね〜。

enum Enum2<T0, T1> { case case0(T0) case case1(T1) } func foo(x: Enum2<Int, Never>) -> Int { switch x { case .case0(let x): return x } }

9.0 beta3 でこれは通ります。

1

おお

また String 周りの微修正が来てる。 https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md

Makoto Kinoshita (@mkino)

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

12:43 AM

StringProtocol なるものが追加されたの初めて知った。

Stringを引数に取る関数と拡張を、Substringでも使いたい、と

みたいですね。

あーそれほしいやつですね

@Biacco42 Swift4使ってるの？？

@koher いや、まだ使ってないですけど、将来的に来るなら嬉しいなってやつです (edited)

1

この間作ったenum-convertible、実際にはcase数NのEnumに対するtype-erasureなので

10:36 AM

AnyEnumとかのほうが良い気がしてきた

AnySequence みたいに case 数 N の enum を渡せるんですっけ？

convertible定義すれば、ですね

変換用の init を extension で足すということですか？

extensionでasAnyEnumみたいなの書く感じですね

うーん、それだとやっぱりちょっと AnySequence とは違う気もしますね〜。

機能と目的は同じですが、生成方法が著しく違いますね

AnySequence はラッパーなのに対して convert しているという構造上の違いが AnyEnum と呼ぶのにちょっと違うかなぁと感じますね。

なるほど

それに、 AnySequence みたいに型名も AnyEnum3 とかにすると長くなっちゃうし。

1:45 AM

今、「パッケージ名 EnumN とかだと短くて良かったかもですね」と言おうとして検索したら前にも言ってた

思考回路変わってない・・・。

AnySequenceはSequenceプロトコルを満たす型をなんでも変換してAnySequenceにできて、それ自身Sequenceとして使える、という型で、その際にSequenceのassociated typeをAnySequenceの型パラメータに移している。AnySequenceから個別のSequenceに戻すときにはコピーをする。 @tarunon が作っているのは(なんでもEnumと仮称)、「case数とcaseごとのassociated valueの型」が同一であるenum型をなんでも変換できる型で、個別のEnum型がもっていたassociated valueの型を、なんでもEnumの型パラメータに移す(個数は型名自体に移す)、個別のEnum型に戻すときはコピーをする。 (edited)

1:49 AM

できていることは同じに思うけど、そもそも「case数とassociated valueの型が同じEnum型同士」はプロトコルではないし、表現方法が同じだけで本質的に互換性は無いもの同士なので、どこで使うんだろう？

そもそものモチベーションは、case数とassocvalueの型が保障されたprotocolが欲しい、と言うところで、それを取り扱うためには具体型としてのEnumNが必要だった、という感じ

1:52 AM

enumを定義するのはライブラリ提供者ではなく利用者だが、ライブラリ提供者は指定されたcaseとassocvalueを実装したenumを作って欲しい、と。

1:53 AM

もうちょっと掘り下げると、Equatable準拠とかライブラリ提供者側で出来ないから、定義を利用者に投げたいということ。

enumをAPIにしたいけどライブラリ側で定義するのだとユーザ側でライブラリを使うときに変換を用意しないといけないから、ライブラリがEnumNで組んでおくと、ユーザーはEnumNへの変換をセットアップすれば楽に使える？ (edited)

そんな感じやね

1:55 AM

ライブラリ側はEnumNConvertibleを引数に取るから、利用者はコンバート関数だけ作ればAPI使うときはコンバートもしなくて良い。

1:55 AM

EnumNはほぼ、switchの安全とコンバートを保障するためだけの具体型

APIから戻ってくるときは？ EnumN -> ユーザ定義enum への変換

それは特にないなぁ

2:00 AM

相互互換持たせるprotocolにする、単にinitを定義すれば、いけるとは思いますが

ユーザ定義enum -> EnumNへ変換する EnumNConvertibleを実装するときは、中身は switch case で普通に書くの？

そう

だとすると、仮にライブラリAが、 enum LibAEnum を持っていたとしても、 protocol LibAEnumConvertible を定義していたら

2:02 AM

ユーザ定義enum -> EnumN の変換のために EnumNConvertible を書くのとユーザ定義enum -> LibAEnum の変換のために LibAEnumConvertible を書くのは

2:02 AM

ユーザ側の手間は同じ？

一緒やと思う

じゃあ、 EnumNConvertible -> EnumN のところが事前用意されているからライブラリ実装側が楽、という事？

Convertible があるなら型名さえ AnyEnum3 等にすれば AnySquence とのアナロジーとしていいような気がしてきた。 (edited)

2:03 AM

前話したときも Convertible について話してたのに存在を忘れてた。

protocolを引数に取れば良くなるからその通りかな？

2:04 AM

あとは、mapKとか、unwrappedとか、そういう便利関数を丸っと定義できるのも

ふむふむ

unwrappedのNever対応計画は120万行のコードを残して霧散したけど

2:10 AM

確かに、EnumN→Covertibleの実装への変換も、あった方が良いな。追加しよう。

それって Convertible に init(_ x: Enum3<T0, T1, T2>) とかを足すってことですか？ (edited)

そうです

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-07-20-a

いつのSNAPSHOTからかわからないけど、Xcode 9でIDEIndexEnableBoltIndex NOが不要になってた。 (edited)

var a: Int32 = -3 var b: UInt32 = UInt32(a) // EXC_BAD_INSTRUCTION var c: Int64 = Int64(Int32.max) * Int64(10) var d: Int32 = Int32(c) // EXC_BAD_INSTRUCTION

素晴らしい

7:39 AM

でも、例外やオプショナルじゃなくていいのかな・・・

7:40 AM

これがC++だと変な値になったまま動作を続けるので結構怖いバグを生みます。

なんだっけ

7:41 AM

コンパイルオプションでImplicitly unwrapとか無視して突き進むやつ

7:41 AM

あれやったらどうなるの

-Ounchecked?

そうそれ

[omochi@omochi-iMac int]$ swift -Ounchecked a.swift -3 4294967293 21474836470 -10

7:43 AM

var a: Int32 = -3 print(a) var b: UInt32 = UInt32(a) print(b) var c: Int64 = Int64(Int32.max) * Int64(10) print(c) var d: Int32 = Int32(c) print(d)

precondition相当ですね

C++と同じ挙動か？

これは Logic Failiure で適切だと思う。 (edited)

うーむ？

12:08 PM

String to Int は Optional で、 Int64 to Int32 は Logic Failure であることに

12:08 PM

理由付けできるんでしょうか

12:08 PM

相対的なレベル感としては感覚的には納得できるけど。 (edited)

基本的に桁あふれは起きないってスタンスだと思うんよね。

12:09 PM

桁を意識しないといけないのは特殊な状況で

Int64を使う時点で当たり前のように起きるような？

それの責任を持つのはプログラマ側。

Int32 to UInt32 も、In32に負の数が入っていることもよくあると思う。

init?(exactly:) があるんで、お好きな方をってことじゃないでしょか。

Int32.max + 1 が Logic failure なのと同じな気が。

おお、 exactly: は知らなかった。いいですね (edited)

12:11 PM

Int32.max + 1 が Logic failure なのと同じな気が。

それはなかなか起こらない気がするんだよな。Int32の中だけの出来事だから

exactly （知らなかったけど）や &+ は用途に応じてそういう手段が提供されていて、標準ではオーバーフロー系は Logic failure で統一されてるんじゃないかな？ (edited)

12:13 PM

Int(String) との比較で言えば、 conversion だと思えば同じに見えるかもしれないけど、 parse だと思えば異なるものな気が。

ふーむ

12:14 PM

まあいいのか、どこからがlogic failureになるかはAPIごとの決めの問題でしかないか (edited)

完全な正解はないから、ユースケースに応じて一番多そうなものに合わせて、後は他との類推が効きやすいように一貫線を持たせて決めるしかないと思う。

12:16 PM

String からのパースとの類推が聞きにくいという意味で少し微妙だったと。

12:17 PM

明確な線引がないという点では、 Array の subscript とかだって、番兵とかを考えると Optional であってほしいという考えはあるけど、 Logic failure としてしまった方が適切なケースが多いという決めの問題でしかないと思う。

Objective-Cに書き直した方が速いものって何だろう？ https://twitter.com/mkino/status/890102457992437761

Swiftでプログラム書く。 Instrumentsでパフォーマンス計測。ホットスポットをObjective-Cで書いて高速化。の流れ、ほんと好き。SwiftからObjective-Cへのダウンスケールが楽チンなのが素晴らしい。

7:28 AM

多次元配列操作とかかな。

C/C++の多次元配列相当のものはstructで作れそう。

そういえばなんでコレやってないんだろうと思って検索したら出てきたネタ。 https://bugs.swift.org/browse/SR-4007 (edited)

9:19 AM

現状 String は64bit環境で24バイトだから、22バイトくらいまでだったらバッファ確保せずに String の struct に格納出来るようになって欲しいな。

tagged pointerのおかげでObjective-Cの方が速いものがある？

NSNumberとかで使われてるんですね。そういうケースなら普通に値型の数値使えば良さそうだし、この人の想定がどういうものなのかは聞いてみないとわからなさそう。

1:54 PM

SSOは効果ありそうだし、String使いやすくするやつ達成した後ぐらいに入りそうだ。

そういえばswitch case 文で取ったら値をさらにもう一回アンラップすることって可能ですか？例えば

enum A { case a(Int?) } let a = A.a(1) switch a { case .a(let a) where case .some(let unwrappedA) = a: //do something default: break }

みたいな

case .a(.some(let x)): かな？

おお！ありがとうございます！！

case .a(let x?):でもっと楽にいけませんか

1

@tarunon は let 内側派なの

内側派だわ

ワイ case let 主義派 (edited)

それ二変数だとどうなるの？書いてないから知らないんだけど

僕も内側はですね

二変数もできたはず

二変数でlet一回なら乗り換える

enum EE { case a(Int, Int) case b } let ee = EE.a(7, 9) switch ee { case let .a(x, y): print(x, y) default: break } /* output 7 9 */

(edited)

乗り換えよう、ありがとう

いまplaygroundでチェックした。

3:22 AM

乗り換えさせてしまったｗ

case let は変数がある場合とない場合 case let . と case . が混在するのが微妙に気持ち悪くて…ｗ

常にcase .で揃えたくて内側という人はいそう。僕は外側派です

1

3:23 AM

let何回も書きたくない派ですね

気持ちはわかる、だから if case let . は外側で書いてますｗ

僕は「変数を作るんじゃい！」って大事なことだから目立ったほうがいいという感じ（後ろの方はぼやけて見えない

case .a(let .some(a)): これもできたので揃えつつ省略はできそう

中間派きた

let x = 12 switch ee { case let .a(x, y): print(x, y) default: break } みたいなときに x が何を指しているのか不安になるので内側派。 (edited)

tab vs spaceじみてきた

シンボルの宣言がどれなのか分かりにくいってのはありますね

宗教戦争

@rintaro それは不安だ・・・

内側派 rintaroさんの意見にしっくりきました

お内側派の仲間増える？

まあ最近は別にぶれててもええやろと思ってます。適材適所と、チームの人による。

3

「マッチしたのはこのケースだよ」「使うのはこの変数だよ」って順番が整然としてたほうが個人的には好き

rintaroさんの例に「そんな変数名使うな」という意見が出ない不思議。

変数名の問題というより、実際バインディングではなく外側の値にマッチさせたい場合に case .foo(x, let y) と書かなければいけないので、最初から内側で統一しておいたほうが楽かなと思うのです。

あああ、なるほどです。

6:34 AM

よくわかっていませんでした、ありがとうございます。

6:39 AM

caseで変数とマッチさせる書き方って、あまりやった記憶がないな。

6:43 AM

where使っちゃう。

逆にこの挙動をわかってて、変数にマッチさせない、もしくは where 使うっていうルールがあるなら、外側 let で統一して let 忘れを防ぐっていう考え方もありかと。

あと、バインドとマッチを混ぜるという発想がなかったです

caseで変数とマッチさせる書き方って、あまりやった記憶がないな。

これ＋もう片方に変数使いたいのがあるってかなりレアケースになりそうな

実際 let a, b : Int a = 1 b = 2 できるから case .foo(let a, b): も両方バインディング扱いだろうと思っちゃうと、 b が外側にあったときにバグに気づけなくて悲劇が起こりそう。外側 let のほうが良い気がしてきたｗ

そうか、こんな書き方できるのか。 enum EE { case a(Int, Int) } let ee = EE.a(12, 1) if case let .a(12, y) = ee { print(y) }

let a, b : Int のときは letが "a, b"にかかるけど case .foo(let a, b): のときは letが aだけにかかるということか

1

無駄にバインドとマッチを混ぜて使ってみたくなる。

バインドとリテラルへのマッチは混ぜて使ってた。

7:07 AM

変数へのマッチがなかった。

do { let x = true let y = false enum Foo { case hoge(Bool) case fuga } let foo = Foo.hoge(x) switch foo { case .hoge(x): print(x) case .hoge(y): print(y) case .fuga: print("fuga") } } /* error: MyPlayground.playground:6:5: error: switch must be exhaustive switch foo { ^ MyPlayground.playground:6:5: note: add missing case: '.hoge(_)' switch foo { ^ */

変数へのマッチで思いついたけど、流石にこれは面倒見てくれないかw

それね、BoolとIntの網羅性チェックがまだ完璧じゃないんですよな…

このへんって変数でも網羅チェックしてくれるのが良いんですかね？ var x, yだったりしたら大変そう。

x,yは微妙だけど、xと!xはやって欲しいかな。試してないけど出来るかしら

2:44 AM

varはやらなくてよさそう。letだけで良いと思う。 @t.ae

以前の..<0, 0, 0<..もですけど評価しないと網羅性の保証ができないのはどうなんだろうと思います。

リテラルだって評価は評価だから

確かに。

まあでもenumは網羅性チェック簡単だからできるとして、実際Intの網羅性チェックってどうやって実現できるでしょ？

C++11ではそういう用途のために constexpr っていう仕組みが入った

流石に64bit全パターンチェックするわけには行かないでしょうし

コンパイル時に計算することを保証させる型

2:47 AM

constexpr は constexpr な式からしか構築できないようになってて

2:48 AM

コンパイル時に定数扱いになる

それだとx, !xはできなそうですね

2:49 AM

xによるか

Boolの x と !x による網羅はできないね

2:50 AM

1 - 0 か 0 - 1か不確定だけど網羅されることは保証できるっていうのはもっと難しいタスクになるね

2:51 AM

@lovee 範囲で切っていけば ..<0 , 0 <.. は全然できると思うよ

@omochimetaru まず <.. 演算子を作ることからですね(ry

ｗ

網羅性チェックで思い出したけど、分野は全然違うけどAuto Layoutの制約をコードで描くときもAmbiguousチェックできてないですよね今、あれもクソだと思う

実行時にも曖昧だとログでないですっけ？

実行時は出ます

ああ。

でもコンパイル時に出して欲しい。

2:57 AM

まあ俺Auto Layout使わないから別にどうでもいいけど（）

structのすべてのプロパティが一致するときにequalであるとしたいときにEquatableに適合するために==オペレータを定義してその中で全部のプロパティ同士を比較するみたいなことをやるとあとからプロパティが追加されたときに==オペレータにそれの比較が漏れがちというのを仕組みで防ぐ方法ってなんかないでしょうか〜

あーそれね・・・無さそう・・・

1:28 AM

Codableなら自動で全プロパティを舐められるから、Codable使ってJSONにして、JSON文字列同士の完全一致で比較すると、一応そのミス自体は防げそう。 JSONだと重いからなんらかのバイナリフォーマットのほうがいいかもしれんけど、実際 == 演算子並べるほうのがベスト

EquatableもCodableよろしくある程度自動生成してほしい

それってJSONでなくてもCodable使ってできない？

はい、できるので、なんらかのバイナリフォーマットのほうがいいかもしれないけど

1:30 AM

大体の場合でJSON化はAPI連携都合ですでにあったりするので

全propertyがEquatableなら省略可、ぐらいで

とりあえずやるならJSONが楽かなと。

protocol AutoEquatable: Codable, Equatable って作れないかな？

あ、シリアライズするんじゃなくて、

1:31 AM

Codableの機構をそのまま使えないかってこと？

うん、そう。

1:32 AM

あー、でも全プロパティが Equatable であることが保証されてないから難しい？

1:33 AM

https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad

NNNN-value-equatability-and-hashability.md

https://github.com/apple/swift-evolution/pull/706

Proposal to synthesize Equatable/Hashable for value types. by allevato · Pull Request #706 · apple/swift-evolution

1:36 AM

あまり盛り上がってない https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036822.html

1:39 AM

これは Codable を使うのではなく、実装を Codable の様に生成させるやつだった。

言語機能としてはそっちのほうが本命ですね

> Hmm, I can see the appeal of automatically deriving Equatable and Hashable conformance, but I'd like that to be opt-in. That is, types should declare that they are Equatable or Hashable to begin with. It wouldn't have to take extra syntax, as compiler magic could effectively synthesize default implementations for == and/or hashValue when all members are themselves Equatable or Hashable, respectively. With such a scheme, consideration can be made to accommodating classes too. Completely agreed. -- Chris Lattner

1:40 AM

Please follow the precedent of the Codable proposal as closely as possible. If you’d like this to be successful for Swift 4, you should look to scope it as narrowly as possible. Because it is additive (with opt-in), it can always be extended in the future. -- Chris Lattner

あ、この返信見たの思い出してきた

Codable 的 Equatable なら通りそう？

1:42 AM

PR も

1:42 AM

そうなってるのかな？

実装のPR もある https://github.com/apple/swift/pull/9619 (edited)

Synthesize Equatable/Hashable for complex enums, structs by allevato · Pull Request #9619 · apple/swift

This is the implementation of the yet-to-be-merged/reviewed evolution proposal to synthesize Equatable/Hashable for enums with payloads and for structs (apple/swift-evolution#706). I'm offering thi...

swift-evolutionの方のPR ざっと見る限り Codable と同じようにデフォルト実装の生成になってて良さそうな気がするんですけどなんで放置状態なんでしょう？

1:53 AM

Codable の自動生成を認めた以上、これも問題なさそう。

http://twitter.com/mitsuse_t/status/891852650085359617 http://twitter.com/mitsuse_t/status/891857788174966785

みつせ (@mitsuse_t)

protocol で let 強制したいなあ.

みつせ (@mitsuse_t)

@tarunon @omochimetaru var get, readonly であって immutable ではないというのはそうなんですけど, immutable なのを強制したいなあという話でした.

3:12 AM

Swiftのprotocolだと readonly な getter を宣言できるけど、 immutable な getter (フィールド？) を宣言する機能がほしいなあという話題があった

それより protocol をネストできるようにして欲しい

3:14 AM

いつもいつも XxxxxxxxxDelegate みたいな名前になってクッソ長すぎ

個人的にも欲しいと思ったことはあるけど、なんとなく、それができちゃいけない気もするが、理論的に整理できてない

3:15 AM

@lovee プロトコルがネストできる構文にしようとすると、 static func とかと整合性を取りにくいんですよね

仮に出来ると仮定してprotocolにprotocolをネストした場合は何が起こるべきなのか

@lovee　さんが求めているのは単に名前的な階層化なんだろうけど

rustのgenerics traitみたいになるべきなのか

static func との一貫性を考えると、「conformanceする型に対するネストタイプをもつべきという制約」

3:15 AM

に見えちゃって微妙なんだよね

そうですね、 protocol をネームスペースに入れたいっていうのが大きな理由ですかね

structやclassの中にprotocolを宣言できるとして、直感的には高階型と似た枠組みになる気がしている (edited)

3:19 AM

いや似てないか

今って struct の中の protocol も駄目なんですね

3:20 AM

protocol の中の protocol のことを考えてました。

protocol のなかに protocol はまあ面倒そうですね

struct HogeView { protocol Delegate { ... } } class Cat : HogeView.Delegate { ... } これすら駄目と

ダメです

3:21 AM

そこが辛い

確かにつらい

3:21 AM

(完全に話題フォークしたな)

struct Hoge<Foo> { protocol Delegate { //ここはFooが使えるべきだが… } } (edited)

3:22 AM

こういうことになるので今は無理かと

その場合は

3:23 AM

Hoge<Int>.Delegate と Hoge<String>.Delegate は完全に独立な別々の型ってことでいいんじゃない？

あとまあ DataSource プロトコルにビューを隠蔽したい気持ちもある protocol XxxViewDataSource { func numberOfCells(in view: XxxView) -> Int } ではなく protocol XxxViewDataSource { protocol Sender: class { } func numberOfCells(in view: Sender) -> Int } みたいな感じにしたい

protocol HogeIntDelegate と protocol HogeStringDelegate が定義されているものと考えればよし

うーん

3:26 AM

class My {} extension My: Hoge<String>.Delegate extension My: Hoge<Int>.Delegate こういうことになるわけだけど

3:26 AM

rustのtrait相当の操作も可能になる、ということ？

メソッド名が完全に衝突する？

3:26 AM

事実上RustのGeneric Traitと同じ事になるね

3:26 AM

今ってメソッド名が衝突するプロトコルってどうなんだっけ

型が違えばオーバーロード、同じで2つ存在したらambiguousでコンパイルエラーかな (edited)

protocol P1 { func aa() -> Int } protocol P2 { func aa() -> Int } class Cat : P1, P2 { func aa() -> Int { return 33 } } Cat().aa()

3:27 AM

普通に動くんやな

3:28 AM

別々の実装を用意することができない、のか。

今でも普通に extension Array が使えるから別に問題ないじゃないかと…？

extension Arrayはメソッドは定義できるけど

3:31 AM

その内側にプロトコルは定義できないから

3:31 AM

これがプロトコル定義できるとなると話が広がっていきますね

@omochimetaru いいえ、 extension My: Hoge<String>.Delegate の話です

3:32 AM

多分それは普通に extension My: Hoge.Delegate でも問題ないんじゃないかと、associatedType で使えるはずなので

この場合のassociated typeとgenericsは別であるべき、だと思います

3:36 AM

それはそれとして、3.0時代までgenericsはネストした型が作れないとかあったんで、generics無しの場合だけprotocol作れる、と言う時期があっても良いかもしれない。

My: Hoge.Delegate がもしできちゃうとすると、 struct Hoge<T> { protocol Delegate { func a() -> T } } extension My: Hoge.Delegate { func a() -> ??? { ... } } ってなってたときに、 T がわからなくて困るよ。 (edited)

Tはassoctypeと見做せるでしょ、という話

埋めた型が Hoge<T> の Tに逆伝搬するってことか。

ただ、現状のネストしたgenerics型の振る舞いから予想すると、assoctypeにはなれない気がする

Genericsは型の生成で、protocolのassociatedtypeはすでに生成されている型のマッチングで、意味が違うと思う

Chris Lattner が興味深いこと↓を言ってる。

I tend to prefer that exploration in this space happen in order of points above, and would prefer not to get to a generalized macro system for a couple of years - just to give Swift more time to mature and develop without it. Other languages have gotten macro systems too early in their development, and become too reliant on it. Perhaps if C didn’t have one it would have ended up with a proper import mechanism. Perhaps if Rust didn’t have one, some of its decisions would have been different. etc.

"constexpr" for Swift 5のスレですね

英語難しい・・・　CやRustはマクロを入れるのが早すぎてそれに頼りすぎて微妙になった、Swiftにはまだ早い　って言ってる？

このちょっと前に I’m a fan of eventually adding a very general, but still hygienic, macro system at some point ってのがあって、マクロ自体はあったらいいと思うけど Swift には時期尚早だと。

8:00 AM

早い段階でマクロを入れるとマクロに依存しすぎるから、言語が成熟するまで待った方がいいと考えてる。くらいの意味合いかと思います。 (edited)

その意見は完全に同意です

8:08 AM

マクロに頼らずとも言語機能でできることを少しずつ決めていって、できればそれで済ませて、

8:09 AM

どうしてもはみ出すことだけマクロでやるようにしないと

うん。

黒魔術が氾濫していろいろつらくなる

8:09 AM

Rustはtry-catch的なものとかprintlnまでマクロですね

↓も興味深い。

4) The macro system should eventually support unstructured compile time expansion, along the lines of what people do with Gyb and Sourcery with all the tradeoffs they bring.

コード生成機能がコンパイラに乗って、gybが無い世界が理想だけどそれをやるにはまだはやい

gyb が要らない世界楽しみ。

多分後方互換性が手に入った後が妥当なんじゃないですかね

ですね。今は ABI ですら安定していない・・・

ABI安定前にmacro導入は死の香りしかしないw

むしろマクロはソース生成レベルの仕組みだから

8:15 AM

ABIは関係ないのでは

8:15 AM

言語仕様レベルで互換性が取れてれば。

うん、論理的には直交してると思う

言語機能として何が足されるか、何が消えるのかが見えてない状態でmacroがあると

8:16 AM

死んだコードの山になる気がしている

ただ、ステップとしては、まず ABI 安定化して、それから構文を固めていこうって流れなのでは。

まあ死ぬのはどっちにしても、か

ああ、なるほど。

8:16 AM

可変長引数ジェネリクスとかまさにそうだね

そうそう

まあ手で書いててもゴミになってしまうのは同じやね (edited)

8:17 AM

っていうかCodableが完全にソレか

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038452.html

お！MLスレだ

まだすぐには進まなさそうだけど、完全無視状態よりは前進か。

ML (Mailing List, Machine Language, Machine Learning) でどれだ!ってなる

6:53 AM

Swiftだと高確率でMailing Listかなw

MLをフォーラムに移行する話題

してほしいですね

6:56 AM

https://github.com/discourse/discourse

discourse/discourse

discourse - A platform for community discussion. Free, open, simple.

6:56 AM

これ使うのか

サードパーティーのEncoderとDecoderがOptionalなCodableをうまく扱えない不具合の回避方法を見つけて修正してもらったのですが、もうSwift 4.0リリースには入れられないと言われてしまった。 https://bugs.swift.org/browse/SR-5206 (edited)

4

えぇ…

2:09 AM

Swift4.1待ちの流れ

Conditional Conformance も Swift 4 に入らないんですか？

2:12 AM

↓ Accepted のまま。 https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md

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

入らないかと。

入るのかと思ってました・・・。辛い・・・。

辛い…

じゃあ↓もできないままなんですね・・・。 extension Optional: Codable where Wrapped: Codable {} (edited)

2:14 AM

実行時に弾くまま・・・。

件のissueもConditional Conformanceがこないと回避できないという認識だったのですが、せっかく回避できたので、もう一度Swift 4.0に入らないか質問してはみました。

2:19 AM

もっと早くにCoderの実装を最新へ追随させる作業をしていたなら、回避方法も早くに見つけていてSwift 4.0へも入っていたかもしれず、ちょっと後悔。

[swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038522.html Codableのinitializerについての話。スレッドを追うとFactory initializer要るよね〜な話にもなっていく。 (edited)

Codable入れるの時期尚早だったのではと言う気がしてくる

3:01 AM

どうしても、Conditional Conformanceありきだと思ってしまう

Codable より先に Conditional Conformance やってほしかった・・・

SE-0166 Swift Archival & SerializationはImplementedになってるけど、SE-0167 Swift EncodersはまだImplementedになってないですね。

まだ実装されてないものがあるんですか？単なる更新し忘れ？

前に Range 同士の contains を実装してここで書いたやつ間違えてた。↓の条件が複雑だった。 let a: ClosedRange<Int> = 2...7 let b: Range<Int> = 3..<8 a.contains(b) // true let a: ClosedRange<Float> = 2...7 let b: Range<Float> = 3..<8 a.contains(b) // false

8:24 AM

↓こんな実装になったけど https://github.com/koher/EasyImagy/blob/442f34637d9326d1d17ad9e443ea3761a7b5c5ba/EasyImagy/Range.swift#L4-L82 特に↓が例外的 https://github.com/koher/EasyImagy/blob/442f34637d9326d1d17ad9e443ea3761a7b5c5ba/EasyImagy/Range.swift#L69-L71

EasyImagy - Makes it easy to deal with images in Swift

EasyImagy - Makes it easy to deal with images in Swift

8:29 AM

↓ gyb で生成した contains のテスト。 https://github.com/koher/EasyImagy/blob/674bad6a884c60625d422868c063ca5a53dbc3b6/EasyImagyTests/RangeTests.swift

https://github.com/apple/swift-package-manager/blob/master/Package.swift

EasyImagy - Makes it easy to deal with images in Swift

テスト自体をgybで吐き出してるのか、なるほど

テスト吐き出してひっかかって実装がまずいことに気づきました。テストの大事さが身にしみる・・・。

8:32 AM

テスト吐く場合はそのロジックが間違えてないことが重要ですが、書き下されたものを一応目視でチェックしました。

テストをgybで作るとなると、生成コードの方の妥当性が気になってしまう

俺もそう思ったけど

なんか

まあ両方間違える可能性は

8:33 AM

片方しかない場合よりだいぶ低いから

帰納法的な証明ができればそれで良いのかなと思ったり

実装かテストのどっちでミスしてれば何かしら気がつけると思った

最小ケースと、任意のnが正しい時にn+1が正しければ

8:34 AM

全てが正しいことを証明できるので、そんな感じのテスト

8:34 AM

任意のnが正しいという仮定をどうやって表現するか、かな

任意のnが正しい時にn+1が正しければ

これは内部のロジックを検査しないといけないから結局網羅的になるんじゃないか

8:35 AM

n = 3のときだけバグる、みたいな可能性が残る

↑は境界チェックがメインですが、型の数が 4x4 で膨大なのでそれでもパターンが多すぎてとても手で書けません。

8:36 AM

満たしてほしい性質を記述することはできるから、それを書いて組み合わせ分を生成しています。

8:36 AM

逆に手で書こうとすると絶対にどこかミスってテストがバグると思います。

8:36 AM

もちろん生成コードがバグってる可能性はあるので

8:37 AM

吐き出されたコードを眺めて自分の思い描いていた条件を再現できているかはチェックが必要です。

8:40 AM

もし 2<..5 とか 2<..<5 とかも追加されたら地獄だ・・・。

containsは便利そうだし実装もそれなりにでかいので単体ライブラリにしても良い気がしますがどうでしょう？

evolutionにproposalでも良いのではとか思った

@t.ae 切り出してもいいと考えてますが、 EasyImagy に依存性は作りたくないので EasyImagy はこのままですね。

8:41 AM

evolution はありですね。

依存性は微妙なところですよね……

@koher も依存性は作りたくないという気持ちあったんだ

なにせこの contains は internal に使ってるだけだからね。

8:43 AM

internal な dependency を記述できたらいいのになぁ。ライブラリをすべて internal 扱いで読み込めて衝突も避けられるような。

あーそれはよく思います

8:45 AM

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

8:45 AM

SPMはめちゃめちゃターゲット切ってますよ

SwiftPM って自身を SwiftPM で管理してるんだ・・・

ですね

8:46 AM

ただ現状だとターゲット名がSwiftのパッケージ名になっちゃってて、パッケージ内パッケージ名ではないので

Swift 自体もいつかセルフホスティングな言語になるのかな？

import Basic とか書いてあって

8:47 AM

どーなのそれは・・・　って気持ちになる

切り出してみた。 https://github.com/koher/range-contains

koher/range-contains

Contribute to range-contains development by creating an account on GitHub.

結局そうなるんですね

いや、 EasyImagy はこれに依存させないです。 (edited)

9:24 AM

swift-evolution に投げるための説明資料。

おお。

あれ？ Array とか ArraySlice の subscript の ClosedRange 等（ Range 以外）をとるバージョンがドキュメントで見つからないんだけどどこ由来なんだろう？

let a = [0, 1, 2, 3, 4, 5] let b = a[2...4] let r: CountableRange<Int> = 2..<5 a[r] // OK: [2, 3, 4] b[r] // OK: [2, 3, 4] let r2: ClosedRange<Int> = 2...4 a[r2] // OK: [2, 3, 4] b[r2] // OK: [2, 3, 4]

(edited)

9:49 AM

実装も見つけられない・・・。

9:51 AM

↓とかにもなさそう。 https://github.com/apple/swift/blob/master/stdlib/public/core/Collection.swift https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb

swift - The Swift Programming Language

swift - The Swift Programming Language

https://github.com/apple/swift/blob/master/stdlib/public/core/Range.swift.gyb#L1177-L1188 たぶんこれですねー

swift - The Swift Programming Language

いや、ちがうか？ swift-3.1-branch にはそれっぽいのが無い。

https://github.com/apple/swift/blob/swift-3.1-branch/stdlib/public/core/CollectionAlgorithms.swift.gyb#L468-L563 3.1 はこれですな。

https://feedback.discordapp.com/forums/326712-discord-dream-land/suggestions/16428421-specific-message

swift - The Swift Programming Language

bugs.swift.org へコメント書こうと思ったら swift.org メンテナンス中だった。

@rintaro おおっ、ありがとうございます！

1:16 AM

typealias Indexable = _Indexable で、 _Indexable 等の underscored な型はドキュメントに記載がないからドキュメント上で subscript(bounds: ClosedRange<Index>) 等が抜け落ちてしまってる？？ https://developer.apple.com/documentation/swift/indexable

Collection.Indexの記述がどこにもなくて、Indexを引数に取る幾つかの関数が、良く解らないものを引数に取ってるみたいなの

1:18 AM

あった気がする

1:19 AM

4月3日にちょっとだけ話題に出してます

日付指定で遡れるんですっけ？ Discord

Collectionで検索して、4月3日を探すしかないと思う

tarunon Collection における不可視の `Index` と似た何かな？と思ったって確かにありますね。

その辺ですね

Discord の検索、結構優秀ですよね。パーマリンクがないのは辛いけど。

パーマリンクは欲しいですねw

1:23 AM

検索は優秀

YoYo-Pete

specific message

Allow linking directly to a message. If someone posts something good... allow to get a link that will take the client directly to that message.

1:39 AM

これかなあ？

ぽい

1:40 AM

Voteしとこ

公式フォーラムに要望掲示板があってVOTE機能がある

http://twitter.com/hiragram/status/894740752885989377

https://github.com/cookpad/styleguide

コーディング規約は全社で共通のがドン❗とあるよりプロジェクトごとにある程度散ってたほうが規約に対してコミットしやすいしなんとなくいい気がするけど確信がないから試しにこのプロジェクトではこう書いてみよっかみたいな小さな導入ができるのでいいと思うんだけどだめかなあ

でたなキュレーター

全社ドンが良い部分と、pj毎にやった方が良い部分があるのでハイブリッドが良さそう

同じ意見で、プロジェクトごとにいろいろやってみたいそこから知見を保守的に抽出して全社基準は作っといたらいいけど

tab vs spaceとかブロックの改行とかは全社で揃えた方が良い

それはそう、全社で共通して使われるべきベースみたいなのはあるべき

2:07 AM

そうか、そこはちゃんと書いてなかったけど、あくまで全体である程度統一されたルールはあるべきと思っているが、規約をちょっと変えてみようと思ったときにコミットする先がいきなり全社で使ってるルールだとハードル高いよね、だったらまずは手元のプロジェクトにだけ適用してよさげだったら全社のにフィードバックするみたいなのがいいよね、という意見

規約にpr投げれる環境があった方が良いのはあるだろうなぁ

2:08 AM

社の規約があってpjはforkしてて、たまに社の規約にpr投げれるのが理想って事？ @hiragram

社のやつにどうフィードバックするかは正直どうでもいいかなって気がしていて、最大公約数的な全社の規約に縛られた結果いろんなプロジェクトが微妙なスピードになるくらいだったら、うちのプロジェクトはこう書くのが効率がいいっていうのをどんどん取り入れていって、他のプロジェクトにも還元できるならあとで全社のに追加すればいいんでね、って感じ

規約がリポジトリになってれば、 fork して改造、運用後よければ PR というフローがいけいそう。

2:10 AM

GitHub とか GHE 使ってる想定で。

@koher それって各プロジェクト用のコード規約が独立したリポジトリにいる感じになりますか？

それはそうなっちゃいますね。

それもまたコミットへのめんどくささという障壁になる気がしていて、だったらアプリのソースのリポジトリにmarkdown1個コミットしちゃえばいいんでね派です

サブモジュールでプロジェクト用のリポジトリには入れられるかもｗ

「コミットしやすくするのは大事だが、そんなに全社のにガンガンフィードバックしまくるようなものでもないでしょ」というダブスタっぽい感じになってしまった

cookpad/styleguide

styleguide - Cookpad's coding style guides

2:12 AM

たしかクッパ社は全社のを外部に公開している (edited)

有名なのは↓もあるよ。 https://github.com/github/swift-style-guide

github/swift-style-guide

swift-style-guide - Style guide & coding conventions for Swift projects

うちもだしてるお

http://qiita.com/susieyy/items/f71435cc962e70d81b37

Swiftコーディング規約@Wantedly - Qiita

はじめに

Swiftのコードは多様な記述の仕方ができるので柔軟でかつ表現力もありますが、チームで開発を行うとどうしても記述の仕方が統一できず可読性も上がりません。弊社（[Wantedly](https://www.wante...

@hiragram アドレスはって

「ちょっと規約いじりたいな」ってなっているときに他のプロジェクトのことを気にしなくていいほうが嬉しい、というのがあのツイートの発端

2:13 AM

はる

2:14 AM

http://tech.vasily.jp/entry/ios-coding-style-guide

vasilyjp

開発にもっと優しさを - iOSアプリの実装規約について - VASILY DEVELOPERS BLOG

こんにちは。iOSエンジニアの遠藤です。今回はiOSチームでの実装規約について紹介したいと思います。 Swiftのコーディングについてだけではなく、実装する上での細かい約束事をまとめました。参考になれば幸いです。

https://github.com/vasilyjp/style_guide/blob/master/ios-style-guide.md

vasilyjp/style_guide

Contribute to style_guide development by creating an account on GitHub.

2:15 AM

こっちかな

repoはそれ

あー

結構みんな独自にゴリゴリ書いてるんだね　同じ項目も多いけど

protocolの実装をextensionにわける、共感あるんだけど、これSwift4で死にそう

2:17 AM

extensionでoverrideできなくなるので

コーディング規約のフォーマット自体がバラバラなのが気持ち悪く感じてきたｗ

エッジケースで死ぬ

(規約そのものの話をしたかったわけじゃないんだけどなw)

規約の内容じゃなくて規約を記述した文書のフォーマットね。

各社が自慢のコーディング規約を公開する統一フォーマットQiitaみたいなのがほしい

そうそう。

2:19 AM

それで、機械的に差分が出たりしたら

2:19 AM

とても参考になりそうだ

お、コーディング規約を投稿するサービスを作ればいいのでは

2:19 AM

各種言語の

どうせならLintまでやって欲しいんだよなぁ

でも Python とか PEP8 か

Swiftだけでいいよ

guardの中身のreturnを同じ行に書く企業　で絞り込めたりしたら面白そう

即 return なら 1 行で書くなぁ。 < guard

guard 改行しなかったことない

僕は開業しますね

2:20 AM

改行

規約はlintと存在理由のコメントのペアの文書で表現して、コンパイラに食わせたら全部やって欲しい

改行無しの{}はクロージャっぽく感じる (edited)

2:21 AM

でも defer 一行は改行しないなぁ (edited)

lint 用の制約として変換できる読みやすいフォーマットがいいのかも

lint もいいけど、もっと進んでまともな formatter が Xcode にインテグレートされて欲しい。

サーバーサイドSwiftで作るSwiftコーディング規約サイト

もっと進んでまともな formatter が Xcode にインテグレートされて欲しい。

ほしい

2:23 AM

SSSSCSSじゃん (Server Side Swift Swift Coding Style Site) (edited)

CSSを地獄ほど拡張したやつっぽくてなんか嫌

ｗｗ

みんなSwiftLint使ってるのかな？

僕はノッてきたら使ってます

開幕podに入れてる

ある程度できてきたらそろそろきれいにするか〜みたいな

ルールが用意されてれば使う、独自の規約をLintルールにするところまでは全然やってなそうな印象

swiftlint lint --sssscss-identifier githubみたいな

アプリは使うけどライブラリは使ってないな

sssscss-identifier❗

2:44 AM

なるほどそういうことかｗ

swiftlint lint --config https://github/github/swift-style-guide.swiftlint.yml みたいなことが出来れば良さげ。

2:51 AM

lint もいいけど、もっと進んでまともな formatter が Xcode にインテグレートされて欲しい。 これが育っていけばいずれは… https://github.com/apple/swift/pull/11320

[WIP] [Syntax] [Do Not Merge] Swift libSyntax API by harlanhaskins · Pull Request #11320 · apple/swift

️ Do Not Merge

️ This patch is an initial implementation of the Swift libSyntax API. It aims to provide all features of the C++ API but exposed to Swift. It currently resides in SwiftExperimental...

お〜

サマーインターンとはいえ、彼らが使う予定の無いもの作らせるとは思えないから、SwiftでlibSyntax使ってエディタエクステンション作れるようになる布石としか思えないですよね。 (edited)

[swift-evolution-announce] Swift 5: start your engines ... Now it is time to turn our attention to Swift 5.

1

4:26 PM

https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

Fix contains for when an empty range is passed by koher · Pull Request #1 · koher/range-contains

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

requiring that all proposals have an implementation before they are officially reviewed by the Core Team まあ妥当

8:58 PM

every evolution proposal will need a working implementation, with test cases, in order to be considered for review. そのページだとこっちか。

早速この前の range.contains(anotherRange) について書いてみました。↓みたいな感じで投げてみようかと。

[Pitch] range.contains(anotherRange) Hi, Recently I needed to implement `contains` methods to check if a range contains another range. I think those are basic operations and suitable for the standard library. Although it may seem easy to implement such `contains` methods whenever we need them, their precise specifications are too complicated to do so. e.g. let a: ClosedRange<Int> = 2...7 a.contains(3...5) // `true` a.contains(3...7) // also `true` a.contains(3..<8) // still `true` because all values contained in `3..<8` are also in `a` a.contains(3..<9) // `false` let b: ClosedRange<Float> = 2...7 b.contains(3...5) // `true` b.contains(3...7) // `true` b.contains(3..<8) // `false` because { x | 7.0 < x < 8.0 } is not contained in `a` let c: Range<Float> = 2..<7 c.contains(3...5) // `true` c.contains(3..<7) // `true` c.contains(3...7) // `false` because 7.0 is not contained in `a` My experimental implementation is here: https://github.com/koher/range-contains What are your thoughts about them?

よさそう

~=対応もあったらswitchでつかえて楽しくなりそう

それは別の話にしておかないとそっちでけられたときにcontainsも入らなくなりそう。

まぁそうですね

追加要素として検討の価値はありそう。一般的な（他の言語の）パターンマッチで range の包含関係ってどう扱われるんだろう？

これ作ってて思ったんだけど、 Conditional Conformance が導入されたら CountableXxxRange と XxxRange は統合できるのかな？

2:09 AM

ああ

2:09 AM

Conditional Conformance 関係ないか

2:09 AM

ってか、今でももしかして extension でできる？？

2:10 AM

やっぱ Conditional Conformance か？

最大値最小値はどれでも取れたと思うのでrightOpenプロパティをつければいける？

↓みたいな extension Range: RandomAccessCollection where Bound: Comparable&_Strideable, Bound.Stride: SignedInteger { ... } (edited)

なんか変に改行されてしまった・・・ https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038672.html

For consistency, the name for this function would be `isSuperset(of:)`, and it would be equally interesting to have `isStrictSuperset(of:)`, `isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all currently available for types that conform to `SetAlgebra`.

というフィードバックがあって、さらに

It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks the required initializers. Is there anything that can be done about this? Actually, it makes me wonder whether those initializers should even be a part of SetAlgebra — why must something implementing SetAlgebra be able to be initialized as empty or from a finite sequence?

という意見が。確かになんで↓等のイニシャライザを持ってるんだろう？ SetAlgebra が集合のオペレーションを規定するものであれば、イニシャライザは余計な気が。 https://developer.apple.com/documentation/swift/setalgebra/2908139-init (edited)

単純なコレクションとしての集合しか想定していなかったのでは？

5:36 AM

Required. Default implementation provided.

5:36 AM

あれ、デフォルト実装がある？？

5:37 AM

空のinitも困った存在ですね、空を許す型しかこれにconformできないのか

うん。

まあRangeならたまたま空が表現できるけど。

ClosedRange はできない。

あれ、マイナスにできないんですっけ？

5:38 AM

1...0

5:38 AM

みたいにして。

できないはず。

fatal error: Can't form Range with upperBound < lowerBound

5:38 AM

本当だ、実行時エラーになった。

@koher 上のサンプルですけど

5:41 AM

let a: ClosedRange = 0...1 a.contains(0..<0) // true a.contains(1..<1) // true a.contains(2..<2) // true <- ?

5:42 AM

そもそも空のcontainはどうするべきなのか

Rangeは空にならないでしょう

5:43 AM

長さが０なだけでlowerboundの点を含む

5:43 AM

なんていえばいいんだ？

その場合は true

5:43 AM

空集合だから

[1, 2) は大きさはもたないけど1の点は含む

↓の挙動とも一貫性がある。 1> let a = [0, 1] a: [Int] = 2 values { [0] = 0 [1] = 1 } 2> a[2..<2] $R0: ArraySlice<Int> = 0 values

え、 2..<2 は空集合じゃなくて

5:44 AM

2の点だけを含むんじゃないんですか？

a.contains(3..<3) // false

おー、実装ミスだ

2..<3 のときは、2の点と、3より小さな実数「すべて」だけど

5:44 AM

2..<2 のときは「２」は含みますよね。

いまのロジックが漏れてるだけですが

集合として。

2...2 は 2 を含むけど

5:44 AM

2..<2 は 2 を含まない (edited)

ええ？？

(2..<2).map(print)したら何も出なくないですか？

それは別に関係ないでしょ

5:45 AM

.map の振る舞いの話だから

ん？

いや、 2 を含むなら表示されるはずでは？

そうですよね？

あーそういうもんなのか？

(2..<2).forEach { print($0) }

(2...2).map(print)なら当然2がでるので

↑は何も表示しない。

mapは確かにおかしかった

1> (2..<2).count $R1: Int.Stride = 0

5:46 AM

↑からも空集合とわかる

countってプロパティ名わかりにくいですよね

5:55 AM

Int型のRangeならそれでいいけど

Countable じゃないと count ないよ

そもcountはCountableRangeにしか生えていないのでは？

実数の [1.0 , 2.0) を考えたときには個数は無限にあるし。

5:56 AM

あ、そうなのか

5:56 AM

あーでもそうか、 (2..<2) は [2] じゃなきゃおかしいな。

2..<2 は [] では？

よくわからなくなってきた

5:59 AM

Range は Half Open だから lower を含んで upper を含まないけど

6:00 AM

( x | l <= x , x < u ) と考えると、 2..<2 は空集合でよくて

6:00 AM

「2 だけを含む」集合が、 Range ではそもそも表現されない？

それは2...2

Countable Range だと、 2...2 として表現できる 2 <= x, x <= 2 で。

lower を含んで upper を含まないというのがそもそも矛盾を内包していて

2..<2 は数学的に書くと [2, 2) となって意味不明になっちゃうのでは？ (edited)

2..<2ってあり得る？

Swift 的にはありえます。

[2, 2)　ですよね

あ、そうです。

6:01 AM

修正しました。

数学的には [2, 2) == () ? (edited)

な気がする。

数学で [a, b) という表記が b <= a に対して許されているのかがわからない。

のはず

6:02 AM

b<aについてはswiftも許してないですね

2か2より大きくて、2より小さい　ってことですよね

(forall x | 2 <= x, x < 2 ) (edited)

↑それは余裕で空集合かと。

数学の [a, b) 表記は　↑のエイリアスかと思ってた

数学の場合は空集合が必ず一意だから[a, a)という記法を用意する必要がないとか？ (edited)

まあ、記法については厳密には決まってないのかも？コンパイルするわけじゃないし。

let a: ClosedRange = 0...1 a.contains(2..<2) // true <- ? 結局これは正しそう。 (edited)

6:05 AM

[0, 1] は [] のスーパーセットだから

集合の定義的にもそうですね

6:06 AM

最初にa.contains(3..<3) // falseを指摘すればよかった (edited)

今 3..<3 は false になってるのか

空集合のみ特別にロジックが要るはずですね

ああ、範囲の判定で書いてるから

6:08 AM

空のときだけその書き方でうまくいかなかったのか。

ただし、a = b のとき、(a, a), [a, a), (a, a] は何れも空集合を表し、[a, a] は一点集合 {a} を表す。また a > b のときは、四種類ともふつうは空集合を表すものと約束する。

http://bit.ly/2vkBLBP (edited)

2vkBLBP

2

6:09 AM

数学でも Swift と同じだ。 (edited)

あ、さっきの内包表記に対して := とされているんですね

1

リンクがうまく貼られなかったので修正

6:11 AM

ちゃんと集合の表記のエイリアスになってるっぽい

6:12 AM

ISO 31-11 で定められてるらしいｗ

↓直した。 https://github.com/koher/range-contains/pull/1

(2...7).contains(11..<11) must return true.

(isEmptyしたほうが良いと思った)

7:17 AM

数学でも Swift と同じだ。

a > bはクラッシュするので同じとは言えないような気もしますね

7:21 AM

レビューに書いとこう

あれ？ Range<Int> でも isEmpty 使えるんだね。 Countable だけかと思ってた。

7:33 AM

count もできる。

7:34 AM

これは Conditional Conformance が入ったら Countable を非 Countable に統合する布石？

empty判定はupperBoundとlowerBoundだけでできますからね

ん？ Range<Float> でも isEmpty できるのか。

1...0 が禁止されているのに

ん？countもできるんですか？

CountableRangeにisEmptyメソッドがあるんですか？

 /// A Boolean value indicating whether the range contains no elements. /// /// Because a closed range cannot represent an empty range, this property is /// always `false`. public var isEmpty: Bool { get }

/// always false.

7:36 AM

お、おう

Range<Int> は count もできる。

ほんとだ

7:36 AM

collectionと無関係につけてるだけか

7:37 AM

/// Unfortunately, we can't forward the full collection API, so we are /// forwarding a few select APIs.

@mono さんが前に Range についてまとめてたけど、 Range<Int> が count できたり、 Conditional Conformance が入ったら Countable と統合できるのかとか、何か知らないかな？

1

7:39 AM

we can't forward the full collection API

これって Conditional Conformance のことを言ってるのか、それとも実現不可能な API があるってことを言ってるのか。後者なら Conditional Conformance が入っても統合できない？

few selected APIでcount以外無い気がするのでそれならconditional conformanceでいけそう

7:40 AM

いやちがうのか

7:41 AM

精査すべきはcollection側か

@t.ae 修正した https://github.com/koher/range-contains/pull/1/commits/fddba76878b1c07f31cfd9a6fdc3e8ec4177ebe0

Fix contains for when an empty range is passed by koher · Pull Request #1 · koher/range-contains

(2...7).contains(11..<11) must return true.

1

7:44 AM

@t.ae が Reviewer になってるけど、権限のないリポジトリに自分で自分を Reviewer に指定するとかできるんだっけ？

レビューしたら勝手につくみたいですね

7:45 AM

なんか×ついたままだし改めてapproveしないとなのか

あ、 approve されたｗ

SetAlgebra には insert, update, remove もあるのか。

SetAlgebra を Range に適用するのは全然だめだ

8:02 AM

union とかも Self を返すので無理だ。

そもそもRangeって暗黙に順序が規定されてるようなものなのでSetAlgebraには向かない気がしますね

8:04 AM

Range<Int>とかがCollectionに従うのはいけそう

順序は規定されてないのでは？ Countable なやつだけで。

ああRangeってSequenceにも従ってなかったのか

え、そうなの、

Countableしかまともに使ってなかったのでそこが抜けてました。

Sequenceだから for in できるのかと思ってた

0..<1 とかででできるのはCountableRangeなので

あーなるほど

let a: Range<Int> = 0..<1 for i in a { print(i) }

Playground execution failed: error: MyPlayground.playground:76:10: error: type 'Range<Int>' does not conform to protocol 'Sequence' for i in a { ^

だいたいよく使ってるのは実はCountableRangeだったのか

Rangeを何に使うのかよく分からない

辞書順文字列の範囲とか。

8:08 AM

辞書順文字列はある２つの文字列の間に含まれる文字列が無限にあるから

8:08 AM

countableにならないけど

8:08 AM

ある文字列がその範囲にあるかどうか判定することはできる

なるほど。

っていうかそれこそ FloatのRangeもuncountableなのかな？

8:09 AM

実際にはビット表現の都合でcountableだけど。

Floatを有限集合と見なすかどうかで変わってきそう

ですね

実際CountableRange<Float>はつくれないですし

Bound : _Strideable

8:11 AM

これで決まってるのか

さらにBound.Stride : SignedIntegerがあってここは超えられないはず

ほんとだｗ

8:12 AM

それかなりきつい制約な気がする

8:12 AM

SignedIntegerではないがcountableなものってある気がする

うん、 "a"..."z" とかね。

UInt32とか

@koher コメントが全部 "contained in a" になってる。メールやtestExample()で。

_ = b.contains(3..<8) // `false` because { x | 7.0 < x < 8.0 } is not contained in `a` … _ = c.contains(3...7) // `false` because 7.0 is not contained in `a`

(edited)

1

おお、ありがとうございます。

@t.ae FloatはStridableだった。

そこまではSignedNumberだからいけるんですね

https://developer.apple.com/documentation/swift/float ここだと直接conformanceある

まあ、いま何らかの都合で SignedInteger になってても、緩める方向には互換性を保ってできそう。

そうですね

0.0..<1.0とかストライドいくつなのか不明ですしStrideToでやれって話になりそうな

8:17 AM

Intは最小単位があるからいいんですけど

func advanced(by: Self.Stride) Returns a Self x such that self.distance(to: x) approximates n. Required. Default implementation provided.

8:18 AM

Stridableのadvancedでいくつすすむかは型によるのかな

8:18 AM

いや、byか

8:19 AM

気になってきた

8:20 AM

BinaryIntegerに T: BinaryIntegerを取るコンストラクタがあるから

8:20 AM

CountableRangeはBound: SignedIntegerを規定しているので

8:20 AM

普通に Bound(1) とかやってそう。

Strideable って前は一つずつ進められる型だと思ってたんだけど、どうも一次元的に並べられる程度の意味っぽいよね。

8:26 AM

Comparable と表現している概念に違いはあるのかな？？

Comparableは比較可能性だから

8:27 AM

間の刻みは関係ないんじゃないですかね

Strideable も刻みの話をしてなくない？

さっきの辞書順文字列とか

https://developer.apple.com/documentation/swift/strideable

「一つ次」が何かも定まらないです

8:27 AM

さだまるか？

8:28 AM

Stridableは Stride分すすめる/もどれるだから

1つではなく、任意の距離が存在する、という話に見える

Conforming types are notionally continuous, one-dimensional values that can be offset and measured.

8:29 AM

offsetが進んだり戻ったりでmeasuredは距離が測れるってことかな

さっきの文字列はComparableですけどStrideableではありえないですよね？

Strideableではある気がしてきて考え中。

8:30 AM

xxxxxx の次は必ず xxxxxa なんじゃないかな

でもさ、 Strideable.Stride を二点で表せるくない？

無限にaが伸びていくので b が無限に遠くにあるけど。 (edited)

文字列はどうだろう

"aaa" と "xxxxx" の距離は ("aaa", "xxxxx") で表せないかな？

文字ならStrideableとできる気はするけど

8:31 AM

aaaとxxxで距離が無限になるから厳しそう

あー

8:31 AM

+= Stride とかができなきゃいけないのか。

たしかに。 "bbb" にたいして　距離 ("aaa", "xxxxx") を足す、って

8:31 AM

結果がわからないですね

8:32 AM

"aaa" に距離 ("aaa", "xxxxx") をたしたら "xxxxx" になることだけは言えるけど。

そうすると、 Strideable で表現している概念と Comparable の差分は、 2 点間の距離を規定することができる（その距離による増減は任意の点に対して適用可能である）ってことなのかな？

だと思います

8:34 AM

( Stridable なら Comparable ではありそう、と思ったら、そう書いてあった。 (edited)

距離はStride型なので、Selfである必要は必ずしも無い

TimePoint型のStrideはTimeInterval型、とかできそう。

数が Strideable を満たすのは当然なんだけど、他にどういう例があるんだろう？

@taketo1024 さんってここには居ないんだっけ・・・ (edited)

Character は厳しいけど（複数コードポイントを含むから）

居ない

アルファベット型とか作れば Strideable なのかな？

その他の Strideable なものですか？

charがstrideableじゃないですか？

8:38 AM

というか順序集合は実質整数みたいなものだし考えても意味無さそう

アルファベットみたいに、実質的に Int にエンコードできる型は全部そうですよね (edited)

8:38 AM

そうじゃない系があるかなあ

@t.ae Swift の Character は書記素クラスタなので複数のコードポイントを含むので Strideable にできないよ。

いやcのcharです

UnicodeScalar が Strideableかな

整数や数値にエンコードできるものって言ったら、実質的に Strideable == Stride になっちゃっておもしろくなさそう。

8:40 AM

たしかに、数学の世界でもっと特殊なやつがありそうな・・・ < @taketo1024 さんってここには居ないんだっけ・・・

omochimetaru - Today at 5:11 PM ほんとだｗ それかなりきつい制約な気がする SignedIntegerではないがcountableなものってある気がする koher - Today at 5:12 PM うん、 "a"..."z" とかね。 omochimetaru - Today at 5:12 PM UInt32とか

↑だけど、 Stride が Int ならいいだけだから問題なさそう。

public struct CountableRange<Bound> : RandomAccessCollection where Bound : Comparable, Bound : _Strideable, Bound.Stride : SignedInteger {

 1> let a: UInt32 = 1 a: UInt32 = 1 2> a.advanced(by: 1) $R0: UInt32 = 2 3> UInt32.Stride.self $R1: UInt32.Stride.Type = Int

Boundの条件じゃなくて Bound.Strideの条件か。

struct NS { @available(*, unavailable) init() {} static func a() -> Int { return 99 } } NS.a() こうやってイニシャライザを潰せばネームスペース代わりのstructを値として使うことを防げると気がついた (edited)

NSKeyedArchiverとNSKeyedUnarchiverにCodable対応のメソッドが追加されてたのね。 https://developer.apple.com/documentation/foundation/nskeyedarchiver/2924373-encodeencodable?changes=latest_beta https://developer.apple.com/documentation/foundation/nskeyedunarchiver/2924375-decodetopleveldecodable?changes=latest_beta

@omochimetaru 前にそれ、 @rintaro がcase無しenumが良いよって言ってなかったっけ

あ〜、あった

switch-caseによる let as は as? ができるときと違って、評価対象の式とcaseの型に親子関係が無いといけないのと、Arrayにcovarianceが無いことが組み合わさって、以下のような挙動になっているけど納得がいかない。

class Animal {} class Cat : Animal {} var animal = Animal() var cat: Cat? = animal as? Cat // OK switch animal { case let animal as Cat: // OK print(animal) default: break } var animalArray = [Animal]() var catArray: [Cat]? = animalArray as? [Cat] // OK switch animalArray { case let animalArray as [Cat]: // Compile error !!! print(animalArray) break default: break }

そもArrayのasは厳密にはArrayに対するcastじゃない気がする

3:58 AM

ArrayとOptionalは特別扱いの塊できもい

特別扱いがあることはまあいいとしても、その特別扱いが as? のときと switch case let as のときと、両方で同じように発動しないと変じゃない？ (edited)

実装漏れてるのかなとは思うけど、特別扱いじゃなくて言語仕様として確立して欲しいな

var animalArray: [Animal] = Array<Cat>([Cat(), Cat()]) print(animalArray) // [__lldb_expr_132.Cat, __lldb_expr_132.Cat] print(type(of: animalArray)) // Array<Animal> var catArray: [Cat]? = animalArray as? [Cat] print(catArray) // Optional([__lldb_expr_128.Cat, __lldb_expr_128.Cat])

4:06 AM

これって全要素の実行時型チェックしてるよね・・・

switch animalArray as Any { case let catArray as [Cat]: これだと通る…

class Animal {} class Cat : Animal {} var animalArray: [Animal] = Array<Cat>([Cat(), Cat()]) switch animalArray as Any { case let catArray as [Cat]: print(catArray) break default: print("default") break }

本当だ、いけますね (edited)

4:36 AM

class Animal {} class Cat : Animal {} class Dog : Animal {} var animalArray: [Animal] = Array<Cat>([Cat(), Cat()]) animalArray.append(Dog()) switch animalArray as Any { case let catArray as [Cat]: print(catArray) break default: print("default") break }

こう書き換えたら default って出力に変わった。やっぱり全部見ている。

var animalArray = [Animal]() switch animalArray { case is [Cat]: // Compile error !!! print(animalArray) break default: break }

のエラーがいかれてる。

error: TempGround.playground:10:22: error: downcast pattern value of type '[Cat]' cannot be used case let animalArray as [Cat]: // Compile error !!!

4:50 AM

このエラーメッセージから逆に推測すると、switch + is の時はダウンキャストの形じゃないといけないのだと思いました。 [Animal] と [Cat] はお互いにどちらも親子関係に無いからこのエラーがでる

4:51 AM

あ、そうか、 as Any つけておくと、 Any と [Cat] は親子関係があるからダウンキャストパターンに合致する・・・？

そもそも var catArray: [Cat]? = animalArray as? [Cat] ができてしまうことが変な気が。

5:44 AM

これって var catArray: [Cat]? = sequence(animalArray.map { $0 as? Cat }) と等価なのか。

Dogが混ざっていたときの挙動が違うのでは？

5:49 AM

sequenceはSomeのTだけあつめる関数ですよね

5:49 AM

as? は Dogが混ざっていると変換自体が失敗になった

そもそも後者は型が違う

5:49 AM

[Cat?]になってる

いや、sequenceで [Cat?] -> [Cat]? になる

あ、sequenceで潰してるのか

sequence は一つでも nil なら全体が nil になるはず。

ただ潰し方が as? とは違うのでは？ってこと

5:50 AM

あれ、そうだっけ

@omochimetaru の言ってるのは flatMap では？

sequenceとflatMapって同じじゃなかったですっけ、OptionalのflatMapが無いときにsequenceを使えば、みたいな話があった気が

その場合戻り値の型は [Cat] になる。

5:51 AM

sequence は標準ライブラリにないのでそんな話にはならない気が。

いまのOptionalを潰せるflatMapがArrayにSwfift2.3?ぐらいで追加される前に

5:52 AM

sequence の話をしてた

5:52 AM

対象が Maybe モナドの場合、次のような結果となりわかりやすい。失敗するかもしれない文脈 を除いた値をリストにしている。 sequence [Just 5, Just 100] -- Just [5,100] sequence [Just 5, Nothing, Just 100] -- Nothing ( Nothing から値を取ろうとして fail が呼ばれる )

5:52 AM

http://qiita.com/rooooomania/items/5e668b52966e28cd0ffa

リストに sequence を適用する、とは - Qiita

リストに sequence を適用してみた結果に混乱したので整理しておく。 sequence [[1], [2], [3]] -- [[1,2,3]] はて、果たして、sequence 関数は何をやっ...

5:53 AM

ほんとだ

map して sequence は rethrows に対応していて

5:56 AM

func cast<T, U: T>(_ x: T, _ type: U.Type) throws -> U { ... } があれば var catArray: [Cat]? = try? animalArray.map { try cast($0, Cat.self) } とできる。

なるほど

モナドパズルを解かなくていい。

covariance周りのproposalとか上がってないのだろうか

前に @rintaro さんが言ってた、 struct でも covariant にできないケースとかありましたよね？

7:01 AM

値型だと参照型と違って mutating func の引数に型パラメータを使っても covariant にできる場合もあるし（ Array とか）

7:02 AM

どういう条件になるんですっけ？前に話したような気も・・・。

"Farm が struct だった場合に" で過去ログ検索して出てくるあたりの話かな？

1

https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L79

[SR-5671] Emit diagnostic in place of collection downcast in pattern by CodaFi · Pull Request #11441 · apple/swift

swift - The Swift Programming Language

https://github.com/apple/swift/pull/11441 case let catArray as [Cat]: の件、 issue 出しておいたら、とりあえず未サポートってことになりましたｗ

For switch statements like the following class Animal {} class Cat : Animal {} class Dog : Animal {} func check(_ arry: [Animal]) { switch arry { case is [Cat]: () case let dogs as [Dog]...

1

HogehogeImporterにimportメソッドを作りたいけど予約語なので `func import()` している (edited)

3:45 AM

（バッククォートがクォートできねえ

`func import()`

!

``func `import`()``

お〜〜〜できた

class Animal {} class Cat : Animal {} class Dog : Animal {} let animals: [Animal] = [Cat(), Cat(), Dog()] print(Set(animals.map { type(of: $0) }))

5:38 AM

このプログラムコンパイルするとコンパイラがセグフォになるの俺だけ？

Animal.TypeがHashableでないからでは？

コンパイルエラーじゃなくてコンパイラが吹っ飛ぶ。

test.swift:6:7: error: cannot invoke initializer for type 'Set<_>' with an argument list of type '([Animal.Type])' print(Set(animals.map { type(of: $0) })) ^ test.swift:6:7: note: expected an argument list of type '(Source)' print(Set(animals.map { type(of: $0) })) ^

と思ったけどセグフォはおかしい気が。

クラッシュはしないです。

ふむ

5:41 AM

$ swift -v Apple Swift version 4.0 (swiftlang-900.0.59 clang-900.0.34.2)

beta 5 でデグレ？ Apple Swift version 4.0 (swiftlang-900.0.54.11 clang-900.0.31)

https://swift.sandbox.bluemix.net/#/repl

IBM Swift Sandbox

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

5:44 AM

Dev. 4.0 (Aug 4, 2017) にしたら、クラッシュした。

5:45 AM

それはそうと、 uniq したいだけのときってどうするのがいいんですかね

5:45 AM

Setにいれるのだとこの通りHashableじゃない場合にダメだ。

ObjectIdentifierって

5:46 AM

型を引数にできなかったっけ

それはポインタライクなやつでは？

5:46 AM

今は配列の中に入ってるインスタンスの型をみたいんだよね

5:46 AM

まあ、 typeName: String を生やしてあるから手元の問題は解決してるんだけど・・・ (edited)

Set(animals.map { ObjectIdentifier(type(of: $0)) }) は通るけど、元に戻せないから微妙。

記憶が正しければ、class型の値と、任意の型はObjectIdentifierでハッシュ化できる

type metadata って

5:49 AM

同じ型に対して一つのインスタンスしか存在しないことが

5:49 AM

保証されてる？

A unique identifier for a class instance or metatype. だから.Typeならいける

5:49 AM

のでは?

なるほど instance or metatype　ってかいてあるし、metatypeはそういうもんなのか

同じ型に対して一つのインスタンスしか存在しないことが保証されてる？

その認識です。

じゃあとりあえず type(of: ) を uniq するなら、 ObjectIdentifierをkeyにしたdictにするのがよさそうか。

最近RxSwiftのDelegateProxyがSwift4で死んだのを復活させるのにObjectIdentifierを型のハッシュ化目的で使ったから

5:51 AM

まさに、という感じだった

let types: [Animal.Type] = [Cat.self, Cat.self, Dog.self] print(types.reduce(into: [:]) { (d, x) in d[ObjectIdentifier(x)] = x })

5:55 AM

なるほど > ObjectIdentifierを型のハッシュ化目的で使った

5:55 AM

↑できた。　ありがとうございます。

デバッグ実行時にArrayを使うと、Time Profilerで調べるとストレージのヒープアロケート/デアロケートが結構重いので

8:17 AM

スタックアロケートなAPIや型が使いたいんだけど、Swiftに無いですよねえ

8:17 AM

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035830.html [swift-evolution] [Pitch] Swift needs fixed-size array こんなスレもあった。

@omochimetaru Swift は最適化なしだと色々と重いから、最適化した状態で問題になるかが重要なんじゃないかな？

ところが Swift Compiler と Optimizationが無効だと(デバッグビルドでもデフォルト有効なんですけど)

8:19 AM

変数の値とかもデバッガから見れないので

8:20 AM

デバッガが使えるけどそこそこの速度で動くって状態にしないと

8:20 AM

快適に作業できない。。

8:21 AM

Apple LLVM 9.0 - Code Generation / Optimization Level は、デフォルトがDebugで -Ononeなんですけど

8:21 AM

Swift Compiler - Code Generation / Optimization Level は、デフォルトで Debug で -O なんですよね。

8:21 AM

あ、フレームワークターゲットの場合ですけど。

@omochimetaru

% for i in range(17): public struct Array${i}<Element> { % for j in range(i): var element${j}: Element % end public init( % for j in range(i): % if j == i - 1: _ element${j}: Element % else: _ element${j}: Element, % end % end ) { % for j in range(i): self.element${j} = element${j} % end } public subscript(index: Int) -> Element { get { switch index { % for j in range(i): case ${j}: return element${j} % end default: preconditionFailure("Out of bounds: \(index)") } } set { switch index { % for j in range(i): case ${j}: element${j} = newValue % end default: preconditionFailure("Out of bounds: \(index)") } } } public var count: Int { return ${i} } } % end

@koher OpenGLに渡すんですけど、

8:41 AM

Swiftのstored property は、フィールドレイアウトが上から下に並ぶ保証が無いので

8:41 AM

それは使えないんですよ。

stored property をタプルにするとか

タプルでも同じじゃないですかね

8:42 AM

stored property の並びがどうなるか保証は無いよって話は Ownership Manifesto に出てきた。

じゃあ、↑のように定義した上で self を UnsafeMutablePointer<Element> として使うという黒魔術は？ｗ

え、っと、なので、それが、レイアウト保証がないから、

8:43 AM

0バイト目から4バイトずつfloatが並ぶ保証がないんです。

レイアウトの保証がなくても Element × N 個以上の領域が確保されているのは保証されるのでは？

あー、フィールドを気にせず使うという意味か。

self をポインタ化すればレイアウト関係なく頭からアクセスできそうだけど、最適化の関係とかでぶっ壊れそう。

それはありですね、 MemoryLayout<Float>.alignment と MemoryLayout<Float>.stride も考慮して

8:44 AM

アドレスをオフセットする必要はあるけど

ちゃんと rebound すれば問題ないのかな？

UInt8をフィールドにひたすら並べたstructさえあれば、それ自体はたしかにスタック上のメモリチャンクとして使えますねｗ

黒魔術っぽいけどｗ

typedef struct FixedFloatArray16 { float elements[16]; } FixedFloatArray16; float * FixedFloatArray16GetElementsPointer(FixedFloatArray16 * array);

9:01 AM

// Matrix4x4 public func withUnsafePointer<R>(_ f: (UnsafePointer<Float>) throws -> R) rethrows -> R { var array = FixedFloatArray16() array.elements.0 = e00 array.elements.1 = e01 array.elements.2 = e02 array.elements.3 = e03 array.elements.4 = e10 array.elements.5 = e11 array.elements.6 = e12 array.elements.7 = e13 array.elements.8 = e20 array.elements.9 = e21 array.elements.10 = e22 array.elements.11 = e23 array.elements.12 = e30 array.elements.13 = e31 array.elements.14 = e32 array.elements.15 = e33 return try f(FixedFloatArray16GetElementsPointer(&array)) }

(edited)

9:01 AM

これでうまくいった。

9:01 AM

FPS17がFPS18になったｗ

久しぶりのスナップショット swift-4.0-DEVELOPMENT-SNAPSHOT-2017-08-15-a

お

↓みたいな初期化orアンラップのパターンをもっと簡単に書く方法ってないでしょうか？

class Foo { private var bar: Bar? func baz(qux: Qux) { let bar: Bar // bar が nil なら初期化したい if let b = self.bar { bar = b } else { bar = Bar(qux: qux) self.bar = bar } // ここで bar を使う } }

5:01 PM

↓みたいなのがあれば

func unwrap<T?>(_ value: inout T?, with initialize: () throws -> T) rethrows -> T { if let v = value { return v } let v = try initialize() value = v return v }

↓にできそう。

class Foo { private var bar: Bar? func baz(qux: Qux) { let bar: Bar = unwrap(&self.bar) { Bar(qux: qux) } // ここで bar を使う } }

lazy varにするのは？

5:01 PM

nilに戻ることもあると違うか

Bar のイニシャライザが qux に依存してるからできなくない？ (edited)

引数見落としてました

func baz(qux: Qux) { let bar = self.bar ?? { self.bar = $0; $0 }(Bar(qux: qux)) // ここで bar を使う } 微妙・・・ (edited)

短いけど可読性がｗ

しかも return 抜けてるので、そんなに短くもない

5:16 PM

let bar = self.bar ?? { self.bar = $0; return $0 }(Bar(qux: qux))

プロパティへの代入を二行目に毎回やるようにすれば

5:18 PM

let bar = self.bar ?? Bar(qux) self.bar = bar

なるほど。

5:19 PM

これって、 Dictionary の新しい subscript と同じパターンな気がする。

func setget(x : inout T, y)->T{ x = y; return y }があれば

5:21 PM

let bar = setget(&self.bar, self.bar ?? Bar(qux))

5:21 PM

こういう時評価値付きの代入文が欲しくなりますね

extension Optional { mutating func unwrapped(default: @autoclosure () throws -> Wrapped) rethrows -> Wrapped { if let val = self { return val } self = `default`() return self! } }

5:30 PM

Dictionary の新しい subscript と同じパターンな気がする。

Dictionary は、読むだけでは mutate しないからちょっと違う感じ

mutating func がselfのinoutである事を利用した別解だ

Dictionary は、読むだけでは mutate しないからちょっと違う感じ

set の方のイメージでしたが、その後使う部分はないですね。

http://qiita.com/omochimetaru/items/6dd98c70b61701334379 かきました

Swift の class の mutating func とは何か - Qiita

導入

Swift には struct と class があります。 struct のメソッドには func ( nonmutating func の省略表記 ) と mutating func がありますが、 cla...

7

おお、面白い

ありがとうございます

class Cat { init() { print("Cat init(\(ObjectIdentifier(self))") } deinit { print("Cat deinit(\(ObjectIdentifier(self))") } func newCat() -> Cat { return Cat() } } func f0(_ x: Cat) { print("f0") } func main() { print("a") f0(Cat().newCat()) print("b") } main()

1:40 AM

出力

a Cat init(ObjectIdentifier(0x00007fba7251c800) Cat init(ObjectIdentifier(0x00007fba725179b0) Cat deinit(ObjectIdentifier(0x00007fba7251c800) f0 Cat deinit(ObjectIdentifier(0x00007fba725179b0) b

1:41 AM

あまり意識してなかったけど、メソッド呼び出しされてる Cat() は newCat() の呼び出し前に破棄される。

f0 前だけど newCat 後じゃない？

それはそう

それはイメージ通りな気がする。

1:44 AM

Obj-C の retain/autorelease から言うと早いけど。

僕は関数呼び出しが終わるまでは引数部分の評価結果は全部スタックに積まれていく気がしていた

スタックに積まれるのは渡すものだけじゃないの？

結論から言うとそう

そもそも全部乗せるためには、引数部分で評価される文について特別扱いしなきゃいけなくなるから、あんまり効率良く無いと思った

OwnershioManifestoで、ストレージのリファレンスを関数の返り値として返す機能についての議論があって

1:48 AM

もし、さっきの newCat() のメソッドが、 &self.age みたいに、自身の stored property への storage reference を返すような関数だったとすると

1:49 AM

この挙動によって、レシーバの Cat() が、メソッド呼び出し直後の f1 投入前に死んでるから

1:49 AM

何らかの仕組みが必要　って話が出てきて

1:49 AM

この挙動のことちゃんと認識してなかったから何日もウーンってなってたｗ

&self.ageが評価されるのはnewCat()内でinitされるときじゃないの？、

class Cat { func ageRef() -> inout Int { return &self.age } var age: Int = 0 } f1(Cat().ageRef())

1:51 AM

↑これがうまくいかないって話

inout Intがリファレンスカウンティング増やさないのかそれ

1:52 AM

増やさないとダメでしょ

inout Int はただのポインタだから、

1:52 AM

Catのアドレスはわからないし

1:52 AM

Catのプロパティとは限らないから

1:52 AM

そんなことはできないのと

1:52 AM

Catがもしstructだったら

1:53 AM

カウンタを増やして延命という概念がそもそも使えない

1:53 AM

増やす方はできても減らす方を inout Int 型の値からは適切にできない。

1:53 AM

この例なら ageRef が self のフィールドを参照することまでわかってるから無理やりできても

コンパイル後にinout Intを何かしらの型にラップするとか

Catが外部コンパイルされてたら無理だし。

1:55 AM

そうだね

1:56 AM

まあなんかいろいろ実装上の工夫が必要になるのと、参照型の導入はそもそもパフォーマンスだから

1:56 AM

trivialでない仕組みはあんま入れたくないねみたいな話もあり

1:57 AM

とりあえず関数の返り値としては参照型は返す仕様は無しって方針が書いてある

1:58 AM

「関数の返り値としては」であって

そもそも Cat.ageをinoutな引数で受ければ同じ事起きるんじゃ

あ、いい指摘だね、それは

1:59 AM

テンポラリ変数での呼び出しと

1:59 AM

呼び出し後の再代入に

1:59 AM

分解される。

2:00 AM

class Cat { init() { print("Cat init(\(ObjectIdentifier(self))") } deinit { print("Cat deinit(\(ObjectIdentifier(self))") } var catProp: Cat { get { return Cat() } set { print("catProp setter: \(ObjectIdentifier(self))") } } } func f1(_ x: inout Cat) { print("f1 begin") x = Cat() print("f1 end") } func main() { print("b") f1(&Cat().catProp) print("c") } main()

2:00 AM

b Cat init(ObjectIdentifier(0x00007fd899434f90) Cat init(ObjectIdentifier(0x00007fd899424d70) f1 begin Cat init(ObjectIdentifier(0x00007fd899434d50) Cat deinit(ObjectIdentifier(0x00007fd899424d70) f1 end catProp setter: ObjectIdentifier(0x00007fd899434f90) Cat deinit(ObjectIdentifier(0x00007fd899434d50) Cat deinit(ObjectIdentifier(0x00007fd899434f90) c

2:00 AM

↑の出力で、f1の呼び出し前に破棄されるCatがなくなっていることと

2:01 AM

setterの呼び出しがf1 end の後になっていることがポイント

俺の言いたいのはfunc f2(_ x: inout Int)に、Cat().ageをぶち込むという話なんだけど

2:01 AM

これでも同じか

computed property じゃなくて stored property の場合ってこと？

んだべな

class Cat { init() { print("Cat init(\(ObjectIdentifier(self))") } deinit { print("Cat deinit(\(ObjectIdentifier(self))") } var catProp: Cat { get { return Cat() } set { print("catProp setter: \(ObjectIdentifier(self))") } } var age: Int = 0 } func f1(_ x: inout Cat) { print("f1 begin") x = Cat() print("f1 end") } func f2(_ x: inout Int) { print("f2") x = 33 } func main() { print("b") f2(&Cat().age) print("c") } main()

2:03 AM

b Cat init(ObjectIdentifier(0x00007fb96d095a80) f2 Cat deinit(ObjectIdentifier(0x00007fb96d095a80) c

2:03 AM

stored propertyは挙動が調べられないという問題がｗ

これはなんだ、内部的には最初のCatのポインタが渡ってると言う解釈で良いのか (edited)

どっちなんだろう

2:05 AM

computed propertyとの一貫性で言えばテンポラリ変数で受けてから呼び出し後に代入してると思うけど

2:05 AM

stored propertyであることがわかってるからレシーバのCatを延命してる可能性もあるね

https://gist.github.com/omochi/0784cf73c95460bd461416e4834be0cd#file-a-txt-L159-L198

a.txt

#Cat.age!materializeForSet.1

やたらややこしい

2:20 AM

materializeForSetの返り値を渡してるね %8 -> %9 -> %10 -> %12 -> %15

実際にはinstance methodが渡っているように見える

2:20 AM

あー返り値なのか

materializeForSetは%8でロードされて%9で呼びされてる

2:21 AM

 #Cat.age!materializeForSet.1: (Cat) -> (Builtin.RawPointer, inout Builtin.UnsafeValueBuffer) -> (Builtin.RawPointer, Builtin.RawPointer?) : _T01a3CatC3ageSifm // Cat.age.materializeForSet

2:22 AM

なんともいえん materializeForSetは、Catと、ポインタ2つを引数にとって、ポインタ2つを返す・・・

2:22 AM

引数のポインタ2つは%4と%5で確保した謎のバッファーと Int

2:23 AM

stored property のあるコードをコンパイルするとだいたい materializeForSet ってメソッドが生成されるんだけどこれ謎だ

https://github.com/apple/swift/blob/master/test/SILGen/materializeForSet.swift

[refactoring] Upstreaming the implementation for Swift local refactoring by akyrtzi · Pull Request #11568 · apple/swift

swift - The Swift Programming Language

SIGLENのテストコードってこんなふうになってるんだｗ

2:28 AM

返してるポインタの１つ目はCat.ageのフィールドのアドレスで、2つ目は関数ポインタだ

2:34 AM

Law of Exclusivity が入ってるから、

2:35 AM

stored propertyのアクセス終了通知用の関数が返ってくるのかも

2:36 AM

Catをstructにするとコンパイルエラーだわ

a.swift:10:8: error: cannot pass immutable value as inout argument: function call returns immutable value f2(&Cat().age) ^~~~~~

ほー

2:36 AM

ああ、Cat()だけだとimmutableだもんね

2:36 AM

それはそう (edited)

さっきのclass CatのやつはmaterializeForSetを通じてCat.ageのアドレスを取ってきて渡してた Catの生成とそのアドレスの取得はf2の呼び出し前にやって、呼び出し後にCatを破棄 (edited)

特別扱いっぽい

materializeForSetはポインタ2つを引数に (フィールドのアドレス, 片付け関数) のタプルを返してたけど、引数の方のポインタ１つめは使われてないし、2つ目は begin_unpaired_access [modify] [dynamic] 命令がSIL.rstに書いて無くて用途が謎

2:48 AM

片付け関数の中に end_unpaired_access があって、これとペアになっていて、なんかメタ情報をやり取りしてるけど謎だ

https://github.com/apple/swift/pull/11568 リファクタリングがオープンソース化

これってコンパイラがリファクタリング機能を持って、コマンド経由で実行できるようになるってことですか？

まだよく見てないんですが、Xcode9 のリファクタリング機能だと思います。 SourceKit に機能追加されている。

https://github.com/akyrtzi/swift/blob/e75ade9e43619b8d427812490e18b6d2e62e5cdc/include/swift/IDE/Refactoring.h

akyrtzi/swift

swift - The Swift Programming Language

swift-refactor っていうコマンドラインツールもありますね。

↑がメインの機能かな？

1:32 AM

コマンドからできるようになると色々発展がありそうですね。

1:32 AM

Swift の API があればそれもよりいいですが・・。 (edited)

https://swift.org/blog/swift-local-refactoring/

Swift Local Refactoring

Xcode 9 includes a brand new refactoring engine. It can transform code locally within a single Swift source file, or globally, such as renaming a method or property that occurs in multiple files and even different languages. The logic behind local refactorings is implemented entirely in the compiler and SourceKit, and is now open source in the swift repository. Therefore, any Swift enthusiast can contribute refactoring actions to the language. This post discusses how a simple refactoring can be implemented and surfaced in Xcode.

1

"Cursor-based Refactoring" って DB のカーソルみたいなデータ操作の話かと思ったら本当の UI のカーソルだった・・・。

これを使うとCot EditorにSwiftのリファクタリング機能をつけたりできるのかな。

1:51 AM

単一ファイルで完結する系の事だけ。

それほしい。

Xcode9 beta5で、Xcode自体をCmd+Qで殺さないといけなくなったから

1:51 AM

作業プロジェクトとは別に、ちょっと.swift開きたいときに

1:51 AM

別のエディタを使う必要があるので

ああ、ここに 1024jp さんいなかった・・・

そういうときにちょっとリファクタリングがついてるとよい

↓社内Slackで @omochimetaru と話していたこと。

Swift に sealed class がほしい
そのまえに abstract class が必要では？
いや、ほしいのは sealed protocol だ
enum に（共通の） stored property を持たせられたら解決するのでは？
case は型じゃないからパターンマッチのときにプロパティをバラさないといけなくて辛い
case が型でないのが問題なのでは？ ←今ココ

3:30 AM

あ、でもenumが値型だから妙なことになるのかな。

値型に継承があっても値のメモリレイアウトを変更しないなら問題ない気がする。

いや、そもそもSwiftのenumはassociated valueがいろいろあるからメモリレイアウトは違うんですよね。 (edited)

前から、純粋にメソッドや computed property 足して型として区別できる struct の継承ほしいと思ってる。 (edited)

どれでも入れられるサイズになってる

3:31 AM

UnitTypeみたいなことですか？

うん、どれでも入れられるという意味でメモリレイアウト

struct Dimension : Int

case サブタイプのレイアウトは異なってもいいか。

みたいな。

そうそう < Dimension

それ欲しいですよね　has_aで作ったらまあメモリサイズ的には実際それにちかいけど

struct Path: String とか。

3:33 AM

has_a だと、メンバを実装し直さないといけないのが辛い。

あ、なるほど

あと、アップキャストが明示的になるのが。

var base: Int

3:33 AM

があれば良い気もした。

3:34 AM

明示的にはなる。

うーん・・・

3:35 AM

話がそれた。case を型にするのはどうなんだろう？

なんかそれは欲しい人いっぱいいる気がするんだよな

でもそうすると case を小文字にした弊害がｗ

@ikesyo や @hiragram も会った時言ってた気がしなくもない

型なら Optional.some じゃなくて Optional.Some であってほしい。

もっかい大文字に直そう

1

なんだなんだ

@hiragram caseに個別の型ほしくない？

ほしい。

3:36 AM

言った。

そうすると、小文字だと困るよね

この流れどこから読めばいいですか

koher - 今日午後12時29分

から

caseに型をっていうのは enum Hoge { case fuga case piyo var data: ??? { ... } } ???がcaseごとに違う型返せる　って認識でよかですか

enum Foo { let a: Int let b: String case Bar case Baz(c: Float) case Qux(d: Bool, e: Double) } ↑ができて case が型になればやりたいことは大体できそう。 (edited)

たとえば、 case fuga のときだけ使えるメソッドを定義するとか。 (edited)

switch foo { case let bar as Bar: ... case let baz as Baz: ... case let qux as Qux: ... } (edited)

3:43 AM

@omochimetaru extension Foo.Qux { var ee: Double { return e * e } }

Bar Baz Quxはそれぞれcaseってことですよね？

3:44 AM

ああ、書いてあったわ

http://twitter.com/hiragram/status/900202136046358532

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032534.html

foo bar bazの次がquxってことを今知った

1

話題の本質と違うからここに書かなかったのにｗ

↓もできるイメージ switch foo { case .Bar(let a, _): ... case .Baz(let a, _, let c): ... case .Qux(let a, _, let d, _): ... }

[swift-evolution] Treating an Enum's Cases as Its Subtypes

3:47 AM

おお

3:48 AM

2017年2月

I think there are definitely places where having cases be a subtype of an enum make sense, but I don't think it makes sense for *all* cases to be subtypes. For example, with "biased" containers like Optional and Result, it makes sense for the "right" side to be a subtype and the "wrong" side to be explicitly constructed, IMO. If the types of cases overlap, it would also be *ambiguous* which case ought to be constructed when the payload is converted to the enum type—remember that enums are sums, not unions, and that's important for composability and uniform behavior with generics. I would be fine allowing enum subtyping with some opt-in attribute, e.g.: enum Optional<Wrapped> { sub case some(wrapped) case none } enum Result<Wrapped> { sub case ok(wrapped) case error(Error) // not a subtype } enum JSON { // OK for these to all be sub-cases, since they don't overlap sub case string(String), number(Double), array([JSON]), object([String: JSON]), null } enum Either<T, U> { // Error: sub cases potentially overlap sub case left(T), right(U) } -Joe

3:51 AM

なんかちょっと言ってることと違う気がする。

noneやerrorに型がついちゃってると困るケースがわからない

enum E { case Foo { func fooMethod() { ... } } case Bar { func barMethod() { ... } } } みたいな proposal もあった気がするんだけどみつからない。

ちょっとしばらく考えてたんですが

8:27 AM

RawRepresentableのRawValueにProtocolを定義できるようになれば、やりたいことは実現可能なのでは。

8:27 AM

enum E: RawRepresentable { typealias RawValue = MyProtocol case x = MyProtocolImpl1() case y = MyProtocolImpl2() } こんな感じで

お・・・

それだとすべての case が同じ型になりませんか？

ん、コンパイル時にE.xとE.yは区別ついてないとこまるのか

8:30 AM

ふーむ・・・その要求だとRawRepresentableはムリですねぇ

Rawvalueは全case共通か。

そうそう、

8:31 AM

e.rawValue こいつがProtocol型になることを想定している

理想はプロトコルじゃなくて各caseごとに任意の具体型が直接とりだせたらいいなあ

完全にRawRepresentableの役割の外だなぁ

8:33 AM

それさ

8:33 AM

enumじゃなくてネストした型にしたほうがいいんでない?

8:33 AM

コンパイル時に網羅性もチェックしたいのか

今はそうしてる。

8:33 AM

網羅性は一旦目をつぶっている。

その網羅性問題のために @omochimetaru と相談して Switcher なるものを作ることにしました。

1

@koher と一緒に考えたアイデアによって

8:37 AM

継承と網羅性を両立できる

8:37 AM

デザインパターンがある

おっ

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029966.html 見つけたので一応。

enum AnimalTypeSwitcher { case cat(Cat) case dog(Dog) } class Animal { var switcher: AnimalTypeSwitcher { fatalError("unimplemented") } } class Cat : Animal { var nya: Int = 3 override var switcher: AnimalTypeSwitcher { return .cat(self) } } class Dog : Animal { var wan: Float = 1.2 override var switcher: AnimalTypeSwitcher { return .dog(self) } }

class Base { ... var switcher: Switcher { fatalError("abstract") } enum Switcher { case foo(Foo) case bar(Bar) case baz(Baz) } } class Foo: Base { ... override var switcher: Base.Switcher { return .foo(self) } } ...

8:40 AM

書くの負けた・・・ｗ

Animalから型によって分岐したいときに、 switch animal.switcher って書く。

8:40 AM

Animal / Cat / Dogは普通の継承関係だからオーバライドとかも自由に使えるよ。

本当は↑の Base を protocol にしたいけどそうすると nested type がつくれないから Switcher を外出ししないといけない。

@koher Switcherをnested typeにするのか。そのほうがいいっすね。

@omochimetaru みたいに外出しするなら protocol で OK だと思う。

8:42 AM

sealed class 的な網羅性を保証するためのワークアラウンドですね。

8:42 AM

まさに今日これに助けられて新しい型を追加したときに網羅チェックで分岐の漏れを見つけられた。

やりたいことは実現できてよさげですが、いっぱい書かないといけないですねｗ

うん。なので、 enum の case に型がついてればよかったのにね、って主張になる。

Switcher.swift.gyb

ｗ

8:44 AM

gyb でできるかな？

これのポイントは

8:44 AM

えーっと

たしかに、var switcher の実装は Animal側によせちゃってもいいので

8:44 AM

ありかも。

継承しているclass側に直に書かなくてもいいので

var switcher を extentionでかいてもいいから

8:44 AM

gybでファイル分割してても問題ないね

extension Base { enum Switcher { ... } }

8:44 AM

そり

8:45 AM

引数にBase型と継承型を列挙したら吐き出すことはできるはずだ

おもしろい

Visitor パターンの switch 版っぽい味わい。

コード生成コストもO(n)で問題はないぞ

8:50 AM

ああああああああああああ

8:50 AM

ダメだ

8:50 AM

Swift4からextensionに書いたメソッドをoverride出来なくなりました

8:50 AM

ちーん

extensionに書いたメソッドをoverrideって具体的にどういうことだっけ

extension UIViewController { var myNantokaField: Int { return -1 } } extension MyViewController { override var myNantokaField: Int { return 1 } } // Clompile Error.

8:52 AM

これです

それって動的ディスパッチできないんじゃなかったですっけ？

あー。親のextensionをってことね

RxSwiftで

8:54 AM

死んだのを思い出した

let vc1: MyViewController = ... let vc2: UIViewController = vc1 print(vc2. myNantokaField)

いや、オーバーライドする必要なくって

↑が -1 になるんだと思ってる。違ったっけ？ (edited)

Swift3.xまでは動的ディスパッチっぽかった気がするけど

class Animal { var switcher: AnimalTypeSwitcher { switch self { case let cat as Cat: return .cat(cat) case let dog as Dog: return .dog(dog) default: fatalError("invalid") } } }

あー

8:55 AM

全部あるからそれでいいな

8:55 AM

それを生成するだけでいいからいけるわ

8:55 AM

賢い。

class Animal { } // gyb extension Animal { var switcher: AnimalTypeSwitcher { switch self { case let cat as Cat: return .cat(cat) case let dog as Dog: return .dog(dog) default: fatalError("invalid") } } }

8:55 AM

最終形はこうかな

Switcherはネストしてる方がお好き

賢い。

さっきその点を話してると思ってた。

架空の俺が賢かったということでここは一つ。 (edited)

tarunon - 今日 午後5時44分 継承しているclass側に直に書かなくてもいいので omochimetaru - 今日 午後5時44分 var switcher を extentionでかいてもいいから gybでファイル分割してても問題ないね

Swift4からextensionに書いたメソッドをoverride出来なくなりました

extension のメソッドが @objc なら出来ると思います。

9:32 AM

import UIKit extension UIViewController { @objc var foo: Int { return -1 } } class MyViewController : UIViewController {} extension MyViewController { override var foo: Int { return 1 } } MyViewController().foo // → 1

QQ

キュッキュッ？

ザハ先生ごめん…

9:36 AM

目玉飛び出してるAA

9:36 AM

台湾のかな？

9:36 AM

:eyes:

でもGenerics入れると@objc無理だし仕方が無い…仕方がなかったんや！

protocol P0 {} protocol P1 : P0 {} func f0<X: P0>(_ x: X) {} func f1(_ x: P1) { f0(x) // compile error } func f2<X: P1>(_ x: X) { f0(x) }

それはそうな気がする

マジ？

10:39 AM

existential が継承してる protocol を満たさない・・・

Genericsな関数はconcrete typeが定まらないと

10:40 AM

使えんじゃんね

でも f1(_ x: P1) は制約じゃないよ

10:40 AM

f2のほうは制約だけど。

f2におけるXは具体型になる

10:41 AM

f1はダメ

プロトコル型の変数を作れるときは具体型としても振る舞うのかと思ってたけどそうじゃないんだなあ

AnyP1/AnyP0にすればいけるよ。

10:42 AM

そりゃそうだけど

いま手元で Array<P1> なプロパティがあって、 Array<X : P0> を受け取る関数に渡したいんだよね

ArrayにProtocolをいれるのをやめろ!

10:43 AM

type-erasuresに詰めてください

1

自前のオブジェクトもしくは Int や Float 、みたいな型グループを取り回そうとしていた

それenumの方が良くないか？と一瞬思ったけど

拡張したいんよね

まあprotocolでもいいか

10:44 AM

erasures最強erasures最強erasures最強！

まあenumにするならどうせenumに詰めるアップキャストを明示的に書くからErasure用意するのとあんまかわらんか

10:44 AM

あしたやろ　どうもでした。。

protocol型のままArrayにつめるとか変数作るとか、出来ることは出来るんだけど変性周りで事故るから

1

10:45 AM

erasureするのを強くおすすめしている。

https://swift.org/blog/swift-local-refactoring/ のコンテキストメニューに "Add Missing Abstract Class Override" っていうのがあるんだけど、abstract クラスの前兆か？

Swift Local Refactoring

Xcode 9 includes a brand new refactoring engine. It can transform code locally within a single Swift source file, or globally, such as renaming a method or property that occurs in multiple files and even different languages. The logic behind local refactorings is implemented entirely in the compiler and SourceKit, and is now open source in the swift repository. Therefore, any Swift enthusiast can contribute refactoring actions to the language. This post discusses how a simple refactoring can be implemented and surfaced in Xcode.

マジ！！

11:23 AM

2

文明だ

Xcode9 beta6 で実際にメニューにあるのは確認したんだけど、OSSリポジトリにその実装は無いのも確認しました。

1

配列の中からダウンキャストできる最初の要素を取ろうとして

animals.flatMap { $0 as? Cat }.first // キャストが全要素にかかって効率が悪い animals.first { $0 is Cat }.map { $0 as! Cat } // 効率的だけど冗長だし無駄な `!`

@omochimetaru animals.lazy.flatMap { $0 as? Cat}.first

3:20 AM

↓最後まで回ってないことの確認 animals.lazy.flatMap { animal -> Cat? in print("a") return animal as? Cat }.first

1

なるほど

LazySequence の map に rethrows がないのも（当然なんだけど）おもしろい。 https://developer.apple.com/documentation/swift/lazysequence/2905499-map (edited)

あ〜

3:22 AM

確かに。

3:22 AM

transformも @escaping になるわけか。

うん。

ひーぷひーぷしてるから flatMapFirst を自作したほうがパフォーマンス的には理想的か

3:23 AM

計算量的には .lazy 作戦で最適だし特に自作しなくて良いのが楽で良いですね

うーん、どれくらいパフォーマンスのボトルネックになってるか次第かな。

3:23 AM

よほどボトルネックでない限り lazy で良さそう。

まあそういう意味では他の処理の方が全然支配的なので最初に書いた効率の悪い方式にしました・・・

画像処理の多重ループの中とかだと自作がいいだろうけど。

3:24 AM

まあでももはや自作じゃなくて for ループ書けばいい気もするけどｗ

取り出した要素をフィールドに格納したいのでforループだと微妙。

as によるキャストが失敗したときに例外が飛んで欲しい guard と as? を組み合わせて書き下す事はできるけど、何箇所も出てくるなら部品化したい関数にしてしまうと、 exp as Type の左から右の流れが cast(exp, to: Type.self) のほうにカッコ閉じされてしまう

2:10 AM

=> を使って、 try exp => { try cast($0, to: Type.self) } にするというのがとりあえずの案だけど

2:11 AM

良い案は無いものか

==>

as の代替ってわかりにくいですね

func ==><T, U>(lhs: T, rhs: U.Type) throws U { guard let value = lhs as? rhs else { throw ... } return value } みたいな。

2:16 AM

==> という記号のわかりにくさをあきらめるか、 (edited)

2:16 AM

左から右の流れをあきらめるか、

2:16 AM

try exp => { try cast($0, to: Type.self) } の複雑さをあきらめるか、

2:16 AM

毎回 guard を書く面倒さをあきらめるか、

2:16 AM

どれかかな。

それだと => 採用だなあ

これ一つで LT できそうだｗ

2:18 AM

その前に => の話が必要か。

castを(Type)->(value)->castedにしたら=>で使いやすいのでは？

exp => cast(to: Type.self) こうですか

try exp => cast(to: Type.self) にできる (edited)

ブレースが消えるしtryが一個減る・・・

なるほど〜

ってか @autoclosure つけたらブレース無くせる？

2:23 AM

@autoclosure の中で $0 が書けなくてだめか

2:23 AM

それはいい案だけど単体のカリー化された cast 関数の何こいつ感がすごいな・・・

できた。

2:30 AM

struct CastError: Error {} func cast<T, U>(to type: U.Type) -> (T) throws -> U { return { value in guard let value = value as? U else { throw CastError() } return value } } infix operator => : SwifletPrecedence precedencegroup SwifletPrecedence { higherThan: AssignmentPrecedence associativity: left } public func =><T, U>(lhs: T, rhs: (T) throws -> U) rethrows -> U { return try rhs(lhs) } let a: Int = 42 let b: Any = a print(try! b => cast(to: Int.self)) // 42

(edited)

2:31 AM

関係ないけど、なんで higherThan って higherthan じゃないんだろう？

その Than ちょっと気になりますよね

↑の cast 頭いいなぁ。黒魔術度は上がってるけどｗ

@t.ae はクロージャリテラルの { } を除去するの好きよね

キャストのpostfix operator作って左辺値型推論させるのも綺麗にできそうですね

infix operator じゃ？

型を書かないから、じゃない？

let value = 0.0 let a: Int = try! value !!! (edited)

2:34 AM

こんなんできたら良いなと

なんだと・・・ｗ

try はいるんじゃない？

tryは要りますね

=> のオーバーロードとして

operatorである分かりにくさが問題

2引数の関数をうけたら

2:35 AM

いや、だめか

2:35 AM

いや、できるか？

その前に => を標準ライブラリに入れたい

カリー化機能を => の方に持たせられれば

例の Range のやつ止まってるけど、あれが終わったら提案してみよう。

=> の重要性を説得するの難しそう

kotlinの先例があるし分かる人は多そうですが

kotlinはあんまりSwiftMLでも見ないよ

プログラミングで頻出パターンだと思うけどなぁ。

2:37 AM

単に、ある式の結果を一つの式の中で複数回使いたいってことでしょ？

kotlinユーザーが多いってことじゃなくて kotlinで採用されて便利だってことが認知されているということです

それだけなら関数で良いと思う

let square = x() => { $0 * $0 }

中置演算子にするからパーレンネストがなくせて見やすいところがだいじ

↑がやりたいことなんてよくあると思うけど。 (edited)

2:38 AM

ああ、関数じゃないところか。

func apply(x, f) = f(x) ではだめなんですよ

まず、中置の重要性についてコンセンサスがとれてないといけないからなぁ。

あ、いやまあ、束縛するそれだけでも価値はありますけどね

ここではコンセンサスがとれてるけど。

2:39 AM

Swift は中置がそれほど重視されていないからなぁ。

そうですかね

Int(string) とか try foo() とか。

?. とかは、中置が重要って根っこでは思ってるから (edited)

2:39 AM

あるんじゃないですかね

うーん、それを意識した構文設計なのか、それとも単に他言語で便利だったから持ってきたのか。

2:43 AM

まあ、 ns.map { $0 * $0 }.filter { $0 < 42 }.map { "\($0") } と map(filter(map(ns) { $0 * $0 }) { $0 < 42 }) { "\($0)" } や map({ "\($0)" }, filter({ $0 < 42 }, map({ $0 * $0 }, ns))) を比較して見せるだけで十分伝わる気もする。

2:44 AM

中置を採用するかどうかで可読性が違いすぎる。

たしかに。

で、左から右に流れるように書きたいっていう意見の元で

2:45 AM

string => Int.init とかもできることも言えるし

2:46 AM

それはかえってネガティブかな？Int(string) 派との分裂を招くか？

左から右に流れるから読みやすいというより

2:46 AM

カッコがネストしてると、一個一個カッコの左と右の数を数えないと

2:46 AM

読み取れないことがつらい

2:47 AM

よく、 f(g(h(x), a)) と書くべきなのに f(g(h(x)), a) と書いてしまってコンパイルエラーになったりする。

読みやすさだけじゃなくて書きやすさもあるかも。左から右に書けないと思考順と異なるから左に戻って書き足さないといけないのがめんどくさい。

たしかに。カッコで包むために←→をおすのが大変 (edited)

左から右に読めることで関数名と合わせて文章的に理解できるのが良いんですよね

2:50 AM

メソッドチェーンで{}を少なくしたい理由もそこにある

{} はクロージャ式？

はい。

↑と矛盾するようだけど、クロージャ式はチェーンしない方がいいと最近思ってる。

クロージャ式をチェーンとは？

一段ずつ名前つけて変数（定数）に格納していかないと可読性が低すぎる。

すべてひっくり返しましたね

さっきの例で言えば↓みたいな感じ。 let squares = ns.map { $0 * $0 } let filtered = squares.filter { $0 < 42 } let strings = filtered.map { "\($0") }

2:53 AM

まあこれくらいの処理なら連ねてもわかるけど

2:53 AM

もう少し複雑になるととたんにわからなくなる。

2:53 AM

特に型の変換が入ってると (edited)

それと同じ話で、array.map { $0+1 }.map { $0+2 }と array.map(addOne).map(addTwo)だと後者のほうが全体でどのような変換をしているのか文章的に理解できる

それやると、そういう処理が2つあったときに途中変数の名前がぶつかるまあやるなら do { } かな

今、引数で受けてるのが何型なのかも考えないとわからない。

2:54 AM

そういう意味か < 関数名と合わせて文章的に理解できるのが良い

mapじゃなくて=>だとよりわかりやすくなりますね

=> は map じゃないから代わりには使えないけどね。

array.map { addOne($0) }.map { addTwo($0) } でもそんな変わらない気がするけどな

それにしてもなんか今日はここが社内 Slack 化してるな

1

=>だと someInteger => addOne => addTwoみたいにできて良さげ

いや、それはさすがに someInteger + 1 + 2 でしょｗ

無論もっと複雑な変換ですよ本当は

なんか Array と Optional のときだけそうやってかけるのに

2:58 AM

モナドに入ってない時だけ

2:58 AM

できないっていうのが

2:59 AM

=> が無いといけないって気持ちになるとき。

bar(foo(x)) が x => foo => bar にできるってこと？

（無意味にSomeに入れて.mapをつなげるのは無し

@koher yes

3:00 AM

それで一連の変換を文章として読解できる

でもたいていは x.foo().bar() なんじゃないかなぁ。

3:00 AM

あんまフリーの関数作らない気がする。

レシーバが違うってことはありますよ

ジェネリック関数とか

3:02 AM

さっきのキャストなんかはAnyのextensionができないですしね

うん、なので順番として、

3:02 AM

普通は extension 作ればいいんだけど

 hogehoge = try tag.mustFirstTag(name: "Hogehoge").mustFirstTag() => { try loader.mustResolveObject(tag: $0) => { try Hogehoge.from($0) } }

ちょうど手元のコード

Any に extension 生やせないから => が要るねって流れのはず。

最初の2処理は型が変わらないからメソッドチェーンだけど

3:03 AM

次の処理はloaderのメソッドになってるからチェーンにならない

3:03 AM

のでアローを使う

3:03 AM

その次も初期化系で同じく。

他のインスタンスのメソッドってのはいい例ですね

やっぱり変数に途中代入しておかないと可読性が・・・

マジすか？↑はめちゃめちゃ読みやすいと思っているんだけどなあ

読めるけど、構造の理解にワンステップかかるから、少し理解が遅くなる。

3:06 AM

絶対↓の方が可読性高いと思う。

let fuga = try tag.mustFirstTag(name: "Hogehoge") .mustFirstTag() let hogehoge = try loader.mustResolveObject(tag: fuga) => { try Hogehoge.from($0) }

(edited)

現実的には、これって、デコーダ的な処理なので

3:07 AM

このパターンが３つぐらい繰り返しているので

3:07 AM

名前衝突が生じてしまうのをさけるために

3:07 AM

let hogehogeTag = try tag.mustFirstTag(name: "Hogehoge") .mustFirstTag() let hogehoge = try loader.mustResolveObject(tag: hogehogeTag) => { try Hogehoge.from($0) }

3:08 AM

こうやってprefixで変数郡をグルーピングするか

3:08 AM

do { } スコープに閉じ込める必要が出るのと

そこは↑で言ってたみたいに do ブロックで囲むか

この途中変数を、後段で参照される可能性が出て逆に読みづらくなる。

もしくは個々を関数に切り出すのがいいんじゃないかなぁ。

3:09 AM

do で囲んでおくか関数に切り出せば「後段で参照される可能性」はなくなるよ。

そうですね

do で囲むの大好き派。

3:09 AM

それで、できるだけローカルな短い名前を使う。

doは外に書く変数宣言が気に入らない派

あとはdoにすると

3:09 AM

行数が間延びしちゃって

@t.ae Kotlin みたいにしたくなるよね。

パット見がダラダラ長くて全体構造が読み取りづらい

逆にdoでくくればxcodeの折りたたみがつかえて気に入ってるよ

doは外に書く変数宣言が気に入らない派

これは、doが式じゃないからってことだよね？

val foo: Foo = run { val bar = ... val baz = ... Foo(bar, baz) }

doはそのdoによって発生する副作用がなんなのか

3:10 AM

わかりにくいのが問題なんだよね

3:11 AM

関数切り出しはわりとこれらの観点において全部クリアしているのでありだけど

3:11 AM

単純にタイピングが多すぎてだるい。

3:11 AM

@koher doよりはrunがいいですね、僕は。

runはいいですね kotlinのとずれますが

そいつなら副作用は明確。

あと型書かなくていいのが◎

run でもキャプチャして書き換えられるのでは？

それはただのクソコードｗ

それあるね。 < あと型書かなくていいのが◎

素直に読めばrunの返り値を作りたいんだなって感じるはずです

3:12 AM

doだと、わかんないんですよ、それが。

じゃあ run を作れば解決では？

一番最後の行にあらわれるから

func run<T>(_ f: () throws -> T) rethrows -> T { return try f() }

3:13 AM

run なら Swift でもできる。

3:13 AM

non-local return はできないけど、それは求めてないはず。

run + 中で let 分断代入はバランスいいと思います (edited)

Swift だと最後に return 書かなきゃいけないのがちょい面倒。 (edited)

そこはkotlinのほうが分かりにくいと思ってますがｗ

まあ return ある方が可読性は高いかもしれない。

逆にdoでくくればxcodeの折りたたみがつかえて気に入ってるよ

↑これは・・・

swiftの一行クロージャはreturn不要くらいがバランス良い気がします

一旦未実装にしとくブロックに1行だけfatalError()って書いといたらreturnを省略したと思われたのかNeverを返すなって言われてreturn必須でもいいんじゃねーのって気になっている

個人的には↓でも意図は十分明確だと思うけどなぁ。 let foo: Foo do { ... foo = Foo(...) }

1文クロージャがvoid返り値にならずに変なことになるのあるある

そこは _ =

それならrun使いますね・・・

十分明確だと思うけどなぁ。

僕も普段違和感なくこういうの書いてますね

スコープの中で何か変更しちゃうのも、 run でも起こりうるし。

fooを2回書くのと、fooの右の型:Fooを書くのが冗長

3:17 AM

最後の行の foo = まで確認しないと、本当にlet foo がその下のdoで代入したいものなのかわからないし。

foo を 2 回書くは run でも return 書いてるよ。

てことは、doを読む前にfooを覚えておかないといけない。

3:18 AM

たしかに・・・ > return

3:18 AM

いや、ちがうな returnは

3:18 AM

名前の同一性を考える必要はないです

型を書くのが面倒、意図が明確ってのはあるけど

ただの共通の制御命令なので。

3:18 AM

let do パターンは、一つ目のfooと2つめのfooの名前同一性の確認が必要です。

3:18 AM

あ、わりとあるのは、コピペして、それを2回やったときに

非標準のものを導入することで初見殺しになるのと天秤にかけたら、まあ do でもいっかなってなる。

2こめのletと最後のところの foo を baz に書き直したりする時に

3:19 AM

渋い気持ちになる。

なるほど。コピペ面倒はあるかも。

run なら return は共通だし、型も推論されるから、冒頭の左辺の変数名だけの修正でいい

letならコンパイルエラーなるし修正漏れてバグることは無いはずだし良いと思うけどなー　治すのが面倒なのはそうかも

標準ライブラリに run があればそれ使えばいいだけの話なので、提案して通して下さい

非標準のものを導入することで初見殺しになるのと天秤にかけたら

初見さんはちゃんとそのプロジェクトで使ってるユーティリティは最初に学ぶべきだと思ってるなあ例えばその理論だとRxとか使えなくなっちゃうし。

3:21 AM

それが1箇所だけとかならいいけど、何度も出てきて効用が大きくなってくるなら導入しちゃったほうが

3:21 AM

初見殺しコストよりメリットが大きくなる

3:21 AM

runは別に標準になくてよくて、internalで定義するからいいんですよね

3:22 AM

=> は

3:22 AM

演算子が internal にならないから

3:22 AM

標準に欲しい。。

最近実は internal になるような気もしてるんだけど、真相はわかってない・・・

3:23 AM

import しないと演算子使えないよね？そしたら同じ演算子 import しなければ

3:23 AM

異なる precedence でも共存できたりしない？

3:23 AM

もちろん、一つのファイルで衝突したらダメだけど。 (edited)

最初そう思ったら @koher がいや演算子は駄目で、、、って言ってたからそう思ってたけど検証はしてないのでよくわからない

プロジェクトローカルであればカスタム演算子作っても全然いいと思うけどね。 run 作るのと変わらなさそう。

operator 宣言自体は常に public ですね。

なんかいけるっぽいぞ。

ただ、たとえば https://github.com/thoughtbot/Runes を import したモジュールを import しても Runes の演算子はつかえない。

thoughtbot/Runes

Runes - Infix operators for monadic functions in Swift

https://github.com/omochi/swift-operator-isolation-verify

omochi/swift-operator-isolation-verify

Contribute to swift-operator-isolation-verify development by creating an account on GitHub.

そういえば Swift のパッケージの間接的な import ってどう働くのかよくわかってないです。 Foo を import してる Bar があったとして、 Bar を import しても Foo は使えないと思ってるんですが、 Obj-C との兼ね合いで（？） UIKit を import したら Foundation も使えるとかありますよね？

@_exported import Foundation とか。

おお、そんなのがあるんですね。

@_exported つけると、Bar で @_exported import Foo してたら、 Bar だけ import すれば Foo も使えます。 (edited)

1

3:54 AM

あと extension まわりだと https://bugs.swift.org/browse/SR-3908 バグもあり、ちょっと混乱しますよね。

3:55 AM

// ModuleA public extension Array { public var first: Element? { return nil } } // ModuleB import ModuleA // main import ModuleB let a = [1,2,3].first // -> nil

っていう問題。

↑これヤバイですね。

@_exported でできるのか

3:57 AM

C / Clang 系の modulemap だとexport制御があるけど

3:57 AM

Swift言語上だとそれらの機能いろいろ足りないよなと思っていた

3:58 AM

https://github.com/omochi/swift-operator-isolation-verify ↑ @koher ライブラリごとのオペレータ制御に特に問題なく独立importできるように見える

omochi/swift-operator-isolation-verify

Contribute to swift-operator-isolation-verify development by creating an account on GitHub.

3:59 AM

Animalライブラリでinfix => と prefix => を定義してて、 Materialライブラリでも infinx => と prefix =>　を定義してて

3:59 AM

Appアプリのmodule0.swiftでimport Animalとmodule1.swiftでimport Materialで

3:59 AM

それぞれ違う動作する

4:01 AM

なのでSPM環境ならSwiflet を取り込めばいいし、コピペでソース取り込みでも、普通のクラスや関数と同じように、特に問題ない気がする

precedence 変えたりしてもちゃんと動くのかな？

やってみるか

前に動かなかったのは Runes と同じように設定して両方読み込んで動かなかったのかも。

operator 宣言とその演算子の実装 public func が別モジュールにあるといろいろ混乱する気がする。

operator の宣言自体は重複しても問題はないんですか？

これってhigherThanだけだとだめか？

あ、あと関係ないんですけど、さっき話してたんですけど higherThan が higherthan じゃない理由とか知ってたりします？他のキーワードと一貫性がない気が。

@omochimetaru App で Material と Animal を両方 import するファイルだとどうなります？

ちょっとまってて・・・

4:05 AM

/Users/omochi/github/omochi/swift-operator-isolation-verify/Sources/app/module0.swift:3:10: error: adjacent operators are in unordered precedence groups 'SwifletPrecedence' and 'AdditionPrecedence'

↓ここにもない https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md#possible-syntax-variations

https://github.com/omochi/swift-operator-isolation-verify

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

camelCase なのはどうしてかっていう話ですよね？

[omochi@omochi-iMac swift-operator-isolation-verify (master *%=)]$ swift run Compile Swift Module 'app' (4 sources) /Users/omochi/github/omochi/swift-operator-isolation-verify/Sources/app/module2.swift:4:10: error: ambiguous operator declarations found for operator print(1 => 2 + 3) ^ <unknown>:0: note: found this matching operator declaration <unknown>:0: note: found this matching operator declaration /Users/omochi/github/omochi/swift-operator-isolation-verify/Sources/app/module2.swift:4:10: error: operator is not a known binary operator print(1 => 2 + 3) ^ /Users/omochi/github/omochi/swift-operator-isolation-verify/Sources/app/module2.swift:4:10: error: ambiguous use of operator '=>' print(1 => 2 + 3) ^ Animal.=>:1:13: note: found this candidate public func =>(a: Int, b: Int) -> Int ^ Material.=>:1:13: note: found this candidate public func =>(a: Int, b: Int) -> Int ^ error: terminated(1): /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-build-tool -f /Users/omochi/github/omochi/swift-operator-isolation-verify/.build/debug.yaml app.exe

4:07 AM

両方importするとエラーですね

camelCase にしない複合語のキーワードは他の識別子と衝突しないから筋がいいと思うんですが、ここだけ higherThan なのが謎・・・

omochi/swift-operator-isolation-verify

Contribute to swift-operator-isolation-verify development by creating an account on GitHub.

4:08 AM

できた

4:08 AM

Precedenceが違っても特に問題ない

4:08 AM

両方importしてる場合は、 => の呼び出しで、オーバーロードが曖昧ってエラー (Source/App/module2.swift) (edited)

おお、素晴らしい

あと、Precedenceは、higherThanだけだと、混ぜて使ったときにエラーになることがわかった

<unknown>:0: note: found this matching operator declaration <unknown>:0: note: found this matching operator declaration このエラーはだめだー

swifletにlowerThanも書いたほうが良さそう。

混ぜて使ったときにエラーになる

何と混ぜて？

+と。

4:10 AM

再現きるのでまってて

ああ

4:11 AM

+ とはあえて優先順位をつけてない

precedence をグラフ化したときに、合流していない枝にある演算子同士を混ぜるとエラーになる。 (edited)

infix operator => : SwifletPrecedence precedencegroup SwifletPrecedence { associativity: left higherThan: TernaryPrecedence } // alias multiple public func =>(_ a: Int, _ b: Int) -> Int { return a * b } print(3 => 2 + 1)

(edited)

let r = x() => { $0 * $0 } + y() => { $0 * $0 }

a.swift:14:9: error: adjacent operators are in unordered precedence groups 'SwifletPrecedence' and 'AdditionPrecedence' print(3 => 2 + 1) ^ ~

↑みたいなのがあったときに

4:12 AM

=> と + のどっちが早いかは感覚的にも自明でないので

4:12 AM

明示的に () を付けさせる。

precedence をグラフ化したときに、合流していない枝にある演算子同士を混ぜるとエラーになる。(編集済)

難しい・・・

4:13 AM

どういうことだ・・・？？？

そもそも、そんなに複雑な式で使うと可読性を損ねる

オペレータ同士の強弱が1本のルールに並んでないってこと？？

↓にすればいい let r = (x() => { $0 * $0 }) + (y() => { $0 * $0 })

4:13 AM

うん

マジか

それが Swift の今の precedence のいいところ

いいところなのそれ・・・

元々並んでたのを

4:14 AM

あえて並ばないようにした。

てっきり、整数で定義するのだとややこしいから、 > で定義しただけかと

4:14 AM

おもってた

それによって、関連性のない複数の演算子間で

一つの並びですらなくなってしまったのか

無理やり優先順位を決めなくて良くなった。

4:14 AM

そういう直感に反するものは

4:14 AM

混ぜて使うとコンパイルエラーとして検出できて

4:14 AM

書いている人の意図に合わせて () を付けて解決する。

4:15 AM

これによって、演算子の優先順位が想定外なことによる

4:15 AM

バグを防ぐことができる。

そうすると

4:15 AM

precedencegroup SwifletPrecedence { associativity: left higherThan: TernaryPrecedence }

4:15 AM

この定義微妙？

+ と * とか、当然関連があってほしいものには優先順位が決められるけど

?: Ternary conditional Right associative TernaryPrecedence

4:16 AM

Ternaryって?:ですけど

4:16 AM

lowerThan: AssignmentPrecedence

4:16 AM

にして

4:16 AM

a = b => c 形式だけ定義したほうがいい？

それ @omochimetaru の改造でしょ？

いや、 ?: との関連なのに、代入文と混ぜられる理由がわからなくなってきた

本家は↓ https://github.com/koher/swiflet/blob/master/Sources/Swiflet.swift

koher/swiflet

swiflet - Provides => like let in Kotlin for Swift

ああ本家はASsignmentなのか

あ、ちなみに↑の優先順位の決め方の利点は、 Proposal 読んでないけどおそらくそういうことだろうと予想しているだけなので、確証はないです。

HigherThan Ternaryで　= とは一緒に使えるのに

4:18 AM

+ とは一緒に使えないのは

4:18 AM

うーん、グラフの図がないとどこに枝がわかれてるのかようわからんな

4:19 AM

あー

4:19 AM

いや、わかってきた

+ も => もより優先順位が高いだけで

4:20 AM

どっちが高いのか決まらない。

=> >> ?: >> = だけど + >> ?: でもあるから、 => と + の関係が不明なのか。

4:21 AM

Swift言語組み込みの既存のオペレータは、全部繋がってるんですかね？

4:21 AM

下位互換あるはずだから多分そうだよな

三項演算子の左オペランドの式に+ を書くことなんてないから三項演算子と + の間では優先順位が決められてないかと思ったけど決められてた。 func +(lhs: Bool, rhs: Bool) -> Bool { return lhs || rhs } true + false ? 2 : 3 // 2

4:22 AM

@omochimetaru 下位互換がないのが Swift のメジャーアップデートでは？ｗ

まあそうだけどここでやってたら死体が多すぎそう

a | / \ b c | | d | \ / | e こういうグラフだと a-b-d-e もしくは a-c-e は使えるけど b-c とかは使え無い。

4:23 AM

precedence をグラフ化したときに、合流していない枝にある演算子同士を混ぜるとエラーになる。

↑ちょっと違いました。

a higherThan b と定義するのと b lowerThan a と定義するのは等価ですか？

そこで矛盾するとどうなるんだろう？

4:24 AM

後に出てきた方しか先の方を参照できないのかな？

どうなるんだろう。。

Swift 以外にこういう演算子の順序付けしてる言語あるのかな？

infix operator +++ : PikaPlusPrecedence infix operator *** : PikaStarPrecedence precedencegroup PikaPlusPrecedence { associativity: left higherThan: PikaStarPrecedence } precedencegroup PikaStarPrecedence { associativity: left higherThan: PikaPlusPrecedence }

4:26 AM

[omochi@omochi-iMac sw-op-def]$ swift a.swift a.swift:11:5: error: cycle in higherThan relation: PikaStarPrecedence -> PikaPlusPrecedence -> PikaStarPrecedence higherThan: PikaPlusPrecedence ^

error: cycle in higherThan relation: B -> A -> B

賢いな・・・

4:26 AM

infix operator +++ : PikaPlusPrecedence infix operator *** : PikaStarPrecedence precedencegroup PikaPlusPrecedence { associativity: left higherThan: PikaStarPrecedence } precedencegroup PikaStarPrecedence { associativity: left lowerThan: PikaPlusPrecedence }

4:27 AM

[omochi@omochi-iMac sw-op-def]$ swift a.swift a.swift:11:16: error: precedence group cannot be given lower precedence than group in same module; make the other precedence group higher than this one instead lowerThan: PikaPlusPrecedence ^ a.swift:4:17: note: precedence group declared here precedencegroup PikaPlusPrecedence { ^

4:27 AM

冗長に逆方向も定義しようとしたら怒られた

4:27 AM

同じモジュールの中の演算子同士のlowerThanは定義できないよ、代わりにhigherThanで定義してね　とのこと (edited)

へぇ、そうなんだ。

ようできとるな

4:28 AM

柔軟だし定義したことだけ動くし定義不足ならそれで困ることが起きるときにエラーになる (edited)

ほんと最近の Swift は細かいところがよくできてるなぁと思う。

4:29 AM

higherThan の camelCase だけ謎。 (edited)

associatedtype とかも小文字だしなあ　本当にそれだけか

もしかしてみんな見逃してしまったまま通っちゃったんじゃあ・・・。

4:29 AM

camelCase にすると識別子と衝突しかねないから良くないと思う。

precedencegroup内にしか書かないからそういうことは無さそうですが……

まあ Swift は予約語にして外でも使用禁止にしないから大丈夫か？

@discardableResult

それでも一貫性はない

アットマークがついてるからセーフか？

@omochimetaru それは Attriute だから

4:31 AM

キーワードでは他に camelCase はないと思う。

4:31 AM

associatedtype, typealias, precedencegroup, ...

4:33 AM

識別子としては普通に使えそう func higherThan<T: Comparable>(_ x: T, _ y: T) -> Bool { return x > y } higherThan(3, 2) // true

https://github.com/apple/swift/blob/master/include/swift/Syntax/TokenKinds.def

https://github.com/apple/swift/blob/87d31e7c3dd0568dda41332072a28634c069e1c9/lib/Parse/ParseDecl.cpp#L6098

swift - The Swift Programming Language

4:33 AM

ここか？

@omochimetaru yes

さがしてた

4:34 AM

higherThanがない

precedencegroup 内だけなので higherThan はキーワードではなくて、いったん identifier としてトークン化されてパーサーで特別扱いです。

なるほど。

4:36 AM

識別子なら camelCase でも自然なのか

https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html

swift - The Swift Programming Language

4:37 AM

居た

4:39 AM

higherThan、カンマで並べられたのか

しらなかったー

infix operator +++ : PikaPlusPrecedence infix operator *** : PikaStarPrecedence precedencegroup PikaPlusPrecedence { associativity: left higherThan: PikaStarPrecedence, AssignmentPrecedence } precedencegroup PikaStarPrecedence { associativity: left }

4:40 AM

コンパイルできた。

4:41 AM

 do { if (!Tok.is(tok::identifier)) { diagnose(Tok, diag::expected_precedencegroup_relation, attrName); return abortBody(); } auto name = Context.getIdentifier(Tok.getText()); auto loc = consumeToken(); relations.push_back({loc, name, nullptr}); } while (consumeIf(tok::comma));

ここの最後の行見てわかったｗ

4:48 AM

infix operator <-= : AssignmentPrecedence func <-= <T> (_ lvalue: inout T, _ rvalue: T) -> T { lvalue = rvalue return lvalue } var x: Int = 1 let y = x <-= 3 print("x=\(x)") print("y=\(y)")

4:48 AM

[omochi@omochi-iMac sw-op-def]$ swift a.swift x=3 y=3

4:48 AM

代入結果を返す代入演算子作れる！！

4:48 AM

これを使えばこの前のkoherのパターンが

<= じゃダメ？

4:49 AM

すでにあるっけ？

<= Less than or equal None ComparisonPrecedence

4:49 AM

それあるんだよな・・・

あれ？そうか

ww

4:49 AM

いや絶対めっちゃ使用経験ある

4:49 AM

if i <= 2 { return }

=< とか？

代入系は全部一番右が = だからそれに習ってみた

<==

:=ができたらいいんですけどね

<-

<-はよさそう

Luaかな

Haskell 的にはモナドを剥がして束縛だけどね

var cache: Int? let v = (cache <-= cache ?? 3)!

4:53 AM

こいつをつかうと、キャッシュが無かったら初期化してキャッシュとして保存しつつその結果を保持、が、1発で書けるよ。

4:53 AM

! が必要だけど・・・

あえて Swift が禁止した = の戻り値を復活させるなんてｗ

見た目が = じゃないからOK

willSet didSet が動いちゃう問題

private var にして stored property にするしかないですね

4:55 AM

いや、いずれにしても、2回目以降の代入が無駄か

func f0(_ f: ( (Int) throws -> (), Int) ) rethrows -> Int // error (edited)

6:17 AM

rethrowsは、throwsが引数に直接ついてないとだめなんですね

6:20 AM

あれ！

6:20 AM

func add(_ x: Int, _ y: Int) -> Int { return x + y } print((1, 3) => add) これできるのか

6:20 AM

関数の引数をタプルとして扱える仕様なくなったと思ってた

6:21 AM

public func =><T0, T1, R>(_ x: T1, _ f: ((T0, T1) -> R, T0)) -> R { return f.0(f.1, x) } print(3 => (add, 1)) (edited)

6:21 AM

@t.ae こんなのはどうかな (edited)

外で部分適用するわけですか

うん。演算子にタプルを取る版を組み込むことで、圧倒的に短く書ける

6:22 AM

カリー化版を用意するという気持ち悪さを回避

6:23 AM

ただrethrowsができないのでthrows版を作らないといけないけど、まあgybでつくるので問題なし

cast に限って言えばカリー化で十分な気が。

一般的に使えたら便利かなと　=> が、関数を中置にする一般的な道具となる

/とか左右同じ型だけど非可換のとき分かりにくいかも？

どっちが部分適用されてるのかよくわからんってことだよね

そうです

それは思った。。

まぁ左から右と思うようにすればいいですけど

この場合 1 + 3 になっているので

6:26 AM

逆だねｗ

確かにｗ

まあたしかに、第一引数だけ左に出したって考えるほうがわかりやすいか

6:27 AM

print(4 => (sub, 1) ) // 3 (edited)

6:27 AM

これで 4 sub 1 の並びになるしね

うーん、ちょっと複雑すぎな気が

6:28 AM

4 => { $0 - 1 } で十分そう。

hakellみたいに4 `sub` 1ができたら良いんですけどね

あ、subは例なので、もっと複雑な何行もある処理を想定 (edited)

6:28 AM

4 => { sub($0, 1) }

複雑な処理だとしたら、クロージャ式じゃなくて関数渡す話？

そうですね

それとも non-trailing なクロージャ式を渡すの？

ん？

6:29 AM

あーそういうことか

4 => { foo($0, 1) } でも全然いい気がする。

6:30 AM

try があると面倒なのか

いやなんか、 1引数のときだけ 4 => twice が書けるのが気持ち悪くて。

6:30 AM

あ、そうですね、右側の try が消せるっていうメリットもある。

try 4 => { try foo($0, 1) }

2引数のときも同じ形式が書けるのでなければ、1引数のときだけ { } を消すのは嫌で

6:30 AM

逆に2引数のときに { } を消せたらいいなと思って考えていた

1引数のときだけ 4 => twice が書けるのが気持ち悪くて。

そのために導入するには複雑すぎる気がするなぁ。

6:32 AM

4 => { foo($0, 1) } は何やってるかひと目でわかるけど、 4 => (foo, 1) はちょっと考えてしまいそう。

6:32 AM

foo のコールがないから関数なのもわかりづらいし・・・

4 => foo これもひと目ではわからないと思う

それだったらカリー化の機能を => に持たせて

6:33 AM

(4 => foo)(1)

6:33 AM

の方がまだいいかも。

4 => { foo($0, 1) } は、fooのコールも { } も普通だから、だいぶわかりやすいですね

6:33 AM

4の左にカッコを書きたくない・・・

6:33 AM

適用は見えてるからわかりやすいけど

4 => foo は => を使うために最低限知っているべきことな気が。

(4 => foo)(1) これ自体は演繹的なのはいいですね

6:34 AM

もともとの挙動と一般化して考えられる

大体、そういうパターンも考え出すと↓みたいなのがほしくなるんじゃないの？

6:35 AM

(x(), y()) => foo

それはすでにできるんですよ

6:35 AM

驚いたことに

6:35 AM

さっきそれで驚いた。

ああ、それなら

6:36 AM

いやちがうな

6:36 AM

それできるのって正しいんだっけ？

僕もいろいろあって消えた概念だと思ってた

そのあたりグダってたから一時的に復活してるだけでは？

マジ？

クロージャ式で受けるときにタプル展開できないと辛い話が再燃して

6:37 AM

一時禁止されてたのを戻そうということになったけど

6:37 AM

決着ついてるんだっけ？

func apply<T, R>(_ x: T, _ f: (T) -> R) -> R { return f(x) } func sub(_ x: Int, _ y: Int) -> Int { return x - y } print(apply((4, 1), sub))

6:39 AM

IBM Swift Sandbox だと、 3.0, 3.1, 3.1.1, 4.0 で動きます

6:50 AM

これとは逆なので、微妙なところかも

これって引数をタプルで受ける話で

6:50 AM

引数にタプルを当てる話しは

6:51 AM

関係ない？

func foo(x: Int, y: Int) { } let a: ((Int, Int)) -> Void = foo これが成立しちゃうのは、たしか SE-110 が revert される前でも起きていて、SE-110 が議論中だったので報告迷った覚えがあります。

なるほど

https://bugs.swift.org/browse/SR-5130 バグとして扱われている

let b: ((Int, Int)) -> Int = add // OK, but why isn't it an error? これがバグとされるなら、さっきのもバグっぽいですね

https://github.com/apple/swift/blob/0ebf95b8ac7b231636b08f863091b3eb0a7926eb/stdlib/public/core/OutputStream.swift#L365

UnsafeMutableRawPointer から UnsafeMutablePointer にキャストする方法 - Qiita

swift - The Swift Programming Language

8:02 AM

Swiftの中で if case let 使ってるとこみつけた

8:02 AM

珍しい

8:03 AM

この行ラトナだ

if case let printableObject as CustomStringConvertible = value { か。↓にしてしまいそう。 if let printableObject = value as? CustomStringConvertible {

なぜ if let ... = ... as? .. { にしなかったんだろう。っていうか switch のほうが良い気がする。

ですね、僕もそう書く > as? (edited)

8:08 AM

switch case だと一番最初の

8:08 AM

if _isOptional(type(of: value)) {

8:08 AM

このパターンは case にできなそう？

でも if let foo = foo は Swift の構文の失敗だと思うから使いたくない気持ちはわかる。

ｗｗｗ

8:09 AM

2年前のラトナーもそう考えていたのか・・・？

swift-evolution のどこかで、今なら違う構文にするって言ってたような？

2年前に if let as? あったっけ

8:10 AM

Chris Lattner committed on 10 May 2015

if let foo = foo { より if case let foo? = foo { の方が好き。

8:11 AM

書くときは前者で書いちゃうけど。

8:12 AM

let 書いたらパターンマッチとして case 省略とかできないのかな。

8:12 AM

if let foo? = foo { これ↑だといいんだけどなぁ。

8:13 AM

Optional binding は = の左右で型が変わってるのが気持ち悪い・・・。

2年前に if let as? あったっけ

これは 1.0 より前からありました。

なるほど、じゃあラトナーがあえて if case let を選択してるわけですね

スマートキャストがあったらif case foo? {とかよさそう

途中で追加されたのは as? じゃなくて as! か。

8:14 AM

try は try! が先で try? が後。

8:15 AM

スマートキャストは納得できない理由で否定されてた気が。

8:15 AM

定義にジャンプで型が確認できなくなるから、とか。

8:15 AM

そんなんだった気がする。

8:16 AM

スマートキャストされたところにジャンプしてくれれば済む話のはず。

isのスマートキャストはともかくOptionalのアンラップにとんでも何だこれってなりそう

1, 2 ヶ月に 1 回くらいスマートキャストほしくなる。

ちなみにどっちの構文でも silgen 結果はまったく変わらなかったです。

なるほど。

おお、そうなんですね。じゃあ何かの最適化のためとかでもなく、単純な構文の好みということですね。

あれ？ Double.pi はあるけど Double.e はないんだっけ？

8:53 AM

M_E ってどうやってとるんだっけ？

8:54 AM

M_E にするしかない？？

warningでおしえてくれそう (edited)

https://developer.apple.com/documentation/swift/floatingpoint 無さそうですねえ

8:56 AM

ジェネリックな sin 関数とかもないですよね

8:56 AM

eってpowとかlogから取り出せないんだっけ

sinはFoundationにはいってたような

これ謎なんだよなオーバーロードされてるやつ

変なの

9:01 AM

とりあえずアプリの extension の中にいれておくか < e

sin と sinf が見えてるのは、math.hからきたやつだとおもうんですけど

9:01 AM

sin の doubleとfloatのオーバーロードもあるんですよね

いつも Unsafe(Mutable)Pointer<T> を Unsafe(Mutable)Pointer に変換する方法を忘れてしまう・・・

bindMemoryですか？

9:46 AM

ちょうど昨日間違った情報にツッコミをいれました http://qiita.com/codelynx/items/64dd046f61267e9905e2

UnsafeMutableRawPointer から UnsafeMutablePointer にキャストする方法をずっと悩んでいましたが、やっとわかったので、ここにメモしておきます。わざとらしいコードですが、一旦 ...

一度 RowPointer を介して bindMemory するんだっけ？

https://developer.apple.com/documentation/swift/unsafemutablepointer/2428492-withmemoryrebound

9:46 AM

介さないでいけますよ

9:47 AM

let uint64Pointer: UnsafeMutablePointer<UInt64> = fetchValue() let isNegative = uint64Pointer.withMemoryRebound(to: Int64.self) { ptr in return ptr.pointee < 0 }

(edited)

withMemoryRebound のクロージャ式は何のためにあるの？

その中でしかそのポインタを使ってはいけないです

あー

9:55 AM

なるほど

The closure’s pointer argument is valid only for the duration of the closure’s execution

↑のコード capacity なくない？

func withMemoryRebound<T, Result>(to: T.Type, capacity: Int, (UnsafeMutablePointer<T>) -> Result)

9:58 AM

capacity引数ありますよ、↑はdefault=1かな

default がついてないように見えるんだけど。

本当だ

9:59 AM

じゃあこのドキュメントは古いですね

10:00 AM

これめっちゃ最近提案されてたやつだと思います capacity = 1

そうなんだ。

https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md

10:01 AM

消えてるｗ

w

https://github.com/apple/swift-evolution/blob/b159d48bf5a05e5dcfa83e2e7dbb2f64c15ada27/proposals/0184-improved-pointers.md

https://github.com/ReactiveX/RxSwift/blob/master/RxCocoa/Traits/SharedSequence/ObservableConvertibleType%2BSharedSequence.swift#L20

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

10:01 AM

これの Detailed Designのところ (edited)

10:02 AM

--- func withMemoryRebound<T, Result>(to:T.Type, count:Int, _ body:(UnsafeMutablePointer<T>) -> Result) +++ func withMemoryRebound<T, Result>(to:T.Type, count:Int = 1, _ body:(UnsafeMutablePointer<T>) -> Result)

(edited)

10:02 AM

デフォルト1が付け足されるらしい。

10:02 AM

いや、逆かな？最初はcountがなくて、ドキュメントが書かれて、途中でcountが増えて、これで改めてdefault = 1になったのかも？

↑、コアチームじゃない人が突然swift-evolutionに追加してたからよくわからなかったんだけどその関係で消された？？

前に Int(string) が string.toInt() より優れているのは型が明確だという話があったけど（ Swift.Int 以外の Int があっても区別できる）、一方で左に戻って書くのは面倒なときがあって => があれば string => Int.init ができるという話で、いくらなんでも => は可読性が悪いので、ふと思いついて↓を作ってみた。 let s = "42" // instead of `Int(s)` let a: Int? = s.to(Int.self) https://github.com/koher/righto

koher/righto

Contribute to righto development by creating an account on GitHub.

左辺値型推論にしたいけどメソッドチェーンとかオーバーロードの引数に渡す時が使いにくくなっちゃいますね to<Int>()ができればいろいろよさげなのに

2:16 AM

ジェネリックにできないからこれもだめなのかな

protocol FromA があれば A.to<B: FromA>() -> B でジェネリックにはできるんじゃない？

それがたくさん生えすぎるなぁと

@koher の ↑ righto はたくさん生えてるよ

swift4のNumricで数値周りは整理されるんで楽になりそうだなぁとおもっていますが

そもそもが変換用イニシャライザだからたくさん生えてるし。

それはそうなんですがｗ

負担は変わってないと思う

2:19 AM

いや、少し楽になるんじゃない？

2:20 AM

Swiftの明示的型パラが無いのは悩ましいよね

2:20 AM

返り値推論が取り回しづらい場合にそなえて f(type: T.Type) を取るパターンが多いけど

2:21 AM

typeを引数取るべきか返り値推論に頼るべきかの設計上のコンベンションがよくわからない

2:21 AM

みなさんどうしてるのかな

func f<T>(type: T.Type=T.self)->T こう

そんなんできんの

左辺の型で推論できるなら省略可能

2:31 AM

推論できないときは引数に入れる。便利よ

func f0<T>(type: T.Type = T.self) -> T? { return nil } let a: Int = f0() ?? 0 let b = f0(type: Int.self)

2:32 AM

ほ、ほんとだ、できた・・・

righttoだと分かりにくいのが問題になりそう

convert(to: ) とかのほうがいいかもね

2:33 AM

でもとりあえずこれでrighttoの引数が推論省略可能にできるな

2:33 AM

そこまでいくと変換コンストラクタより圧倒的にいいな・・・

2:34 AM

Swift std の public func unsafeBitCast<T, U>(_ x: T, to type: U.Type) -> U とかデフォルト引数ついてないから

2:34 AM

推論した後でデフォルト式の評価できると思ってなかったわ

2:34 AM

知見が深い

RxSwiftのSharedSequenceで使われているテクニックだベ

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

RxSwift - Reactive Programming in Swift

2:37 AM

ほんとだ

2:38 AM

じゃあSwiftに明示的型パラが無くても末尾引数に = T.self つけとけば

2:38 AM

一般論として明示可能になるのか・・・

そうだな

T.Type=T.selfのテクニック、結構有用だしstdlibでも使って欲しいだけどevolutionかな

class Base : ExpressibleByArrayLiteral { required init(arrayLiteral: Int...) { } } class Sub : Base { } let _: Sub = [1,2,3]

なんとランタイムエラー fatal error: use of unimplemented initializer 'init(arrayLiteral:)' for class

やっぱ class は複雑すぎるので廃止しよう

variadic 引数を含む initializer は自動継承できないっていう制限なんだけど、TypeCheckerがそれを認識できてないですね。

なるほど。

なんで可変長だと自動継承できないんだ・・？

5:52 AM

その制限要るのかな・・・ (edited)

initializer の自動継承は、実際にはサブクラスに initializer を synthesize して super.init を呼び出しているのですが (edited)

あ〜！！

5:53 AM

なるほど。

5:54 AM

super.initを呼び出すところでコーリングコンベンション的に困ったことになりますね

AST で variadic 引数への splat を表現できないのです

ああ、型システム的にもすでにArray化されちゃってるから、構文的には可変長引数へのspreadが必要なんですね。

2月だ

なるほど・・・。構文は後回しにして spread のASTノードだけ先に作るとかでもいい気も。

ASTノードだけ先に作っても実際の呼び出しのところが問題になるのでは

自動生成はできのでは？

あ、違うのか？Swift的には呼び出し側で配列を作ってるのかな

AST で variadic 引数への splat を表現できないのです

C言語仕様の可変長引数呼び出しにした上で、自動生成されたサンク関数で配列につめてから、実装を呼んでるのかと思ったけど

6:13 AM

そもそもが見た目だけの問題でSwift上では配列でパッシングしてるなら、ASTだけの問題ですね

6:17 AM

func f0(_ xs: Int...) { } f0(11,22,33,44)

6:18 AM

// f0(_:) sil hidden @_T01a2f0ySaySiGd_tF : $@convention(thin) (@owned Array<Int>) -> () { // %0 // users: %2, %1 bb0(%0 : $Array<Int>): debug_value %0 : $Array<Int>, let, name "xs", argno 1 // id: %1 release_value %0 : $Array<Int> // id: %2 %3 = tuple () // user: %4 return %3 : $() // id: %4 } // end sil function '_T01a2f0ySaySiGd_tF'

6:18 AM

普通にArrayだった。

とはいえ、その spread の ASTノードに対応した SILGen 対応は必要ですけどね。

最近まで Array.forEach は存在しないほうが良いと思ってて for in でできるだけ書いていたんですけどよくよく考えてみれば、 for in 文は break continue return などの様々な制御命令が含まれる可能性があるので、読み手がそれに注意しないとフローを読み解けないのに対して、 .forEach はそれらの制御ができないから、 .forEach で書きたいことが書ける場合にはできるだけ .forEach を使ったほうが読み手に優しいため望ましいと思い始めたんだけどどうだろう

let aa = [(0, 1)] for (a, (b, c)) in aa.enumerated() { } // aa.forEach { a, (b, c) in // 不可 // // } という特殊例 (edited)

8:19 AM

書いてて初めてforだとdestructuring assignmentできることに気付きました

3> aa.enumerated().forEach { (a, bc) in 4. let (b, c) = bc 5. print(a, b, c) 6. } こうしなきゃいけないのか

8:22 AM

最近見直されてるやつ

一重タプルができてただけで二重以上のタプルはもともとできませんでしたね。

あ、そうなのか。

forEach はイテレーション毎に関数呼び出しが入るから、 -Onone 時に遅そう。

それを言っちゃうと .map とかも for + var array: [Int] + array.append() にせよ、って話しになりそう。

ごもっとも

最近 -Onone が遅くて困ってそれを実際にやった・・・ removeAll(keepCapacity: true) は良いぞ

forEach はシンタックスハイライト上の問題で見づらいのと、 break や continue があるかはシンタックスハイライトでひと目でわかる（逆にわからないほどの巨大スコープを書くべきでない）ので for でいいんじゃないかなぁ。後から break なくなったから forEach に書き換えようとか逆も辛い・・・。

8:39 AM

Trailing Closure 使ったら制御構文のようにシンタックスハイライトされるなら話は別。

逆にあとからフィルタ追加したい時、 foreach だから filter にしとこう->for+continueより効率悪とかもあるかも？ (edited)

breakしたい時も可能ならば prefix(where) を使って

filter みたいに戻り値が必要なケースはまた別では？

continueしたい時も可能ならば filterを使う。

filter+foreach < for+continueって話です

「後からbreakしたくなるかもしれない」なものと、「後からbreakしたくはならなさそう」なものがあると思う。 (edited)

8:42 AM

そういう見通しの違いが表せるかなあと

8:42 AM

あと、「ひと目でわかる」より「全く見なくてもわかる」ほうが望ましい。

8:43 AM

for だけピンクで目立つけど forEach だと他のメソッドと同じように紫に見えてしまうっていうのは確かにデメリットですね (edited)

for in 使わずに map, filter や forEach ばっかでコード書くってのは昔試して、可読性悪すぎて死んだので個人的にやりたいとは思わないです。

8:44 AM

で、主な原因はシンタックスハイライトの違いという結論に落ち着いた。

8:44 AM

制御構文はまさに制御のためのもので、コードの制御構造を表していて、それがハイライトされて可視化されてるのは大きい。

うーんそうなのか

で、大体の Trailing Closure は制御のためのものだと思うから、 Trailing Closure を同じようにハイライトしてくれれば全然違うんじゃないかと思ってる。

でもその制御が特定のパターンの場合に map みたいな名前がつけられるわけで

逆にfor in 普段つかわない

けど、そういうものを見たことがないから確証はない。

全部読み解くより map とか filter で表せるときはそっちを使ったほうが、意図が明確なコードになりそう。

map や filter は使い方によっては読みやすいし、使うよ。 forEach はほぼ使わない。

8:47 AM

forEach(foo) とできるときか、長くても forEach { foo($0) } みたいなときで

8:47 AM

すべての要素に対してこれを実行したいという意図が強いときかなぁ。

@hiragram その理由は？俺が言ったのと同じ？

8:47 AM

forEach はほぼ使わない。

ほぼでいうと、僕は、絶対に使わない主義だったんで

8:48 AM

僕の「使えるときは使っていく」が、 @koher の「ほぼ使わない」よりも、たくさん使う状態なのかどうかはまだわからない

8:48 AM

すべての要素に対してこれを実行したいという意図が強いとき

イメージとしてはこれですね

map や filter は let ys = xs.map { foo($0) }.filter { bar($0) } くらいの感じなら連ねて書くし、

breakがあとから入れたくなりそうなときはそもそも制御を意識していると思う。

おもちの理由どれだ

17:15のやつ (edited)

クロージャ式の中身が複数行になったり、メソッドチェーンが長くなったりするときは式を区切って変数に代入して名前を付ける。

8:50 AM

それで、何のための処理かと、型が一目瞭然になるので可読性が高まる。

8:51 AM

特に、 map や flatMap の後は型を明示的に記述しておいた方が読みやすい。

それはそうですね

だいたい同じ

最近まで Array.forEach は存在しないほうが良いと思ってて for in でできるだけ書いていたんですけど よくよく考えてみれば、 for in 文は break continue return などの様々な制御命令が含まれる可能性があるので、読み手がそれに注意しないとフローを読み解けないのに対して、 .forEach はそれらの制御ができないから、 .forEach で書きたいことが書ける場合にはできるだけ .forEach を使ったほうが 読み手に優しいため望ましい と思い始めたんだけどどうだろう

8:52 AM

forEachはそのブロックが全ての要素に対して1回実行されることだけ考えればいい(forEachの外にある変数触ってたりすると別だけどそれはやらないようにしてるから問題なし)

.forEach で書きたいことが書ける場合

これって、 break や continue, return 等を含まないとき全部では？

その時含んでいないかというより、後にも含みそうにないか、ですね

僕の「使えるときは使っていく」が、 @koher の「ほぼ使わない」よりも、たくさん使う状態なのかどうかはまだわからない

使えるときはすべて使っていこうという積極的な姿勢に思えたけどそうではない？

8:55 AM

5 行も 6 行も処理が書かれたクロージャ式自体が（特に制御目的だと）微妙な気がしてる。

あーどうなんだろう、長い時こそ forEachの優位性が高まる気もする・・・

8:56 AM

そもそも長くするなというのはある。

continue は forEach だと return で代用「できちゃう」から、視認コスト的には大して変化しないんじゃないか。

ああそうか。

8:56 AM

違うのは break と return だけですね。

8:57 AM

for 内部に continue があるかどうか見なきゃいけないのと forEachに return があるかどうか見なきゃいけないのは同じだ

forEach で return はトラップになりそうだ・・・。

「as, as?, as! をoperatorにしよう」という話があるらしい。 (edited)

12:39 AM

キャストの挙動をそれぞれの型で定義できる様に。

ユーザー定義ってことですか？

そそ

もしそうなったら、castやtoIntなどではなく

12:44 AM

as対応として変換を提供する選択肢も出て来ますね

興味深い

12:55 AM

asが定義できるとして、暗黙になるかどうかは議論がありそう

Optionalの変換とか、asde

1:17 AM

asで定義されていることになって、ユーザ側でもそういうの追加できるようになると良いな。

subscript のオーバーロードってSwift3だとambiguosになるんですね…… swift4だと治ってるようなのでそれ待ちか

ジェネリックと型固定がある場合か。

これは4.1に入るのだろうか? https://twitter.com/olebegemann/status/903362839380975619

Ole Begemann (@olebegemann)

Coming soon to a Swift compiler near you!

(Thanks @CodaFi_ for implementing an old proposal, accepted May 2016!) https://t.co/D4jP5eaGUJ

#if os(macOS)とかよりは良いですね

12:54 AM

watchOSとかtvOSとかはどうすればいいのかわからないことが多いので

canImportめっちゃよい

1:02 AM

良さ高い

おーこれは良いね

#if canImport(WebKit)とかもできるだろうか

2:03 AM

少し違いそう

2:03 AM

なんかコレコレimportしたらこの機能が追加される〜みたいなのが欲しいという話

これってサードパーティのフレームワークも OK ？

2:11 AM

それなら、前に話してた、パッケージを細かく分割して、

2:11 AM

でも A と B を同時に使う場合だけの extension を足したいみたいなのも実現できそう。

そうそう

2:12 AM

APIKit+RxSwiftでRxAPIKit入れるみたいなそう言う拡張が

2:12 AM

import RxAPIKitと書くのはしんどいなが解決できる可能性がある

それができたら素晴らしい

テストを見る限り任意のモジュールでできそう https://github.com/apple/swift/pull/11613/files#diff-cef9f57a4c8714bfa701eabcd4c34730R7

Implement SE-0075: CanImport by CodaFi · Pull Request #11613 · apple/swift

This implementation required a compromise between parser performance and AST structuring. On the one hand, Parse must be fast in order to keep things in the IDE zippy, on the other we must hit the...

2

おお〜

http://twitter.com/__gfx__/status/903417787074232320

http://twitter.com/hiragram/status/903444373018296320

こういうの見ると、何でもinterpolateできるようにしたのはSwiftの設計ミスだよなーと思う。StringInterpolatableみたいなプロトコル必須にすればよかったのに。 https://t.co/dudcbIeIgG

2:41 AM

http://twitter.com/__gfx__/status/903444946362875904

僕はSwiftの設計ミスというよりOptional型のdescriptionが良くなかっただけじゃないかなーという気がする

2:41 AM

http://twitter.com/omochimetaru/status/903446261369409536

@hiragram debug文字列の取得とinterpolationを同一視するのが間違いだったと思ってます。Javaでもこのあたりは同様なんですが、Javaは20年前の設計なのでなにもそれを真似する必要はなかった。

2:41 AM

ありがとう抽選王 (@omochimetaru)

@gfx @hiragram 本来はデバッグ用の表現より文字列用の表現が優先するんですが、Optional型だけはデバッグ用の表現を優先するみたいです https://t.co/MmfUmkuDN5 https://t.co/q4SMb1Lfvj

2:41 AM

http://twitter.com/omochimetaru/status/903446603280728064

ありがとう抽選王 (@omochimetaru)

@gfx @hiragram 優先度は TextOutputStreamable > CustomStringConvertible > CustomDebugStringConvertible > リフレクションによるダンプ

2:42 AM

http://twitter.com/__gfx__/status/903446607605055488

https://gist.github.com/omochi/078e3f3830147db6bcbe29dc9fbfc33c

@omochimetaru @hiragram 工ｴｴｪｪ(´д｀)ｪｪｴｴ工 _isOptional で分岐してるんですか…。なんということでしょう。

"\(foo)"に関してはfooがCustomStringConvertibleじゃなければ遍く警告で良いと思うんだよな〜

swift-optional-as-check.swift

今ってOptionalだけ警告だっけ?

うん。

2:51 AM

print("\(Cat())") // "__lldb_expr_31.Cat\n" (edited)

2:55 AM

"(foo)"に関してはfooがCustomStringConvertibleじゃなければ遍く警告で良いと思うんだよな〜

たしかにこれはあるかも。 CustomDebugStringConvertible の結果がほしいときは、明示的に .debugDescription と書けと。

2:55 AM

CustomDebugStringConvertible もついてなくて、Mirrorの結果がほしいときは、現状と同じく String(describing: expression) で良いしなあ

swift-evolutionで提案して・・・

なんかわりと良い提案な感じがする

2:56 AM

なんか過去に議論されてた気がするんですよね

https://github.com/apple/swift-evolution/blob/master/CONTRIBUTING.md

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

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

でもさっきevolutionちらっと見たときは見つけられなかった (edited)

https://bugs.swift.org/browse/SR-1882

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

2:57 AM

そういうときに Gmail 検索できるように全部受信しておくと便利

途中から登録したら見付けられなくてしぬ

なんかもっと前は、 Optional でも警告無しで文字列化できていた

そろそろevolution書いていかないとだ

@omochimetaru https://twitter.com/_mono/status/903426120401305600

🐶 mono  (@_mono)

Swift 3.1からは警告指摘対象になって、こういうミスしにくくなった(　´･‿･｀) https://t.co/RJ2CnFgqiK https://t.co/y84AjhJFlJ

SR-1882：文字列補間（String interpolation）にOptional型を直接用いると警告が出るように

2:59 AM

SRってなんだっけ？SEはevolutionですよね

3:00 AM

3:02 AM

コントリビューションガイド読んでみるかあ

Swiftが名詞を関数／メソッド名にしてしまったことで変数名と衝突して困ることとかないですか？↓みたいにしたいときとか。 let foo = foo(from: ...)

右を self.foo にすればいけません？

メソッドじゃなくて関数のときに困る・・・

ModuleName.foo

ローカルな関数くらい getFoo 的な名前を付ければいいのかもだけど。

この名前衝突するの結構前からありますけど解決しないんですかね？

あんまり関数は作らないからたまたま困ってなかった

Foundation.stride使うときに変数をstrideにしておいて衝突するのがよくある

いや、いま func makeTranslation 作ってるな

self. をつければいいというのも、本当にそれでいいのかというのもある。

これコンベンション間違いか

6:52 AM

左辺が var mat = だからギリセーフだけど

6:52 AM

ちゃんとやったら踏みそうな気がしてkチア

今 let texturePaths = texturePaths(in: ...) ってやりたくて辛い目に・・・。

6:53 AM

左辺を texpaths とかにするのも考えたけど不細工だし・・・。

https://github.com/jpsim/SourceKitten/blob/master/Source/sourcekitten/main.swift

jpsim/SourceKitten

SourceKitten - An adorable little framework and command line tool for interacting with SourceKit.

3:52 AM

DispatchQueue.global(qos: .default).async { let registry = CommandRegistry<SourceKittenError>() registry.register(CompleteCommand()) registry.register(DocCommand()) registry.register(FormatCommand()) registry.register(IndexCommand()) registry.register(SyntaxCommand()) registry.register(StructureCommand()) registry.register(RequestCommand()) registry.register(VersionCommand()) registry.register(HelpCommand(registry: registry)) registry.main(defaultVerb: "help") { error in fputs("\(error)\n", stderr) } } dispatchMain()

3:52 AM

dispatchMain() 　って関数に突入させれば

3:52 AM

DispatchQueueのメインループを最上位に持つプロセス作れるんだね

@norio_nomura コミットだー https://github.com/jpsim/SourceKitten/commit/3b1c8a907475f6b19e40f4981dac8bc22b92b31e

Use sourcekitd_set_notification_handler() · jpsim/SourceKitten@3b1c8a9

sourcekitd_set_notification_handler() set the handler to be executed on main thread queue. So, we vacate main thread to dispatch_main().

その前のコミットだと、CommandantのCommand.mainに突入するだけだったのが

3:57 AM

dispatchMainの中で改めてCommand.mainに入るようになってますね

3:57 AM

https://github.com/Carthage/Carthage/blob/master/Source/carthage/main.swift

Carthage/Carthage

Carthage - A simple, decentralized dependency manager for Cocoa

3:58 AM

CarthageのmainはCommand.mainに突入するだけ

3:58 AM

https://github.com/Carthage/Commandant/blob/ab80aa4d28224d7d6308f455f406355f98836b52/Sources/Commandant/Command.swift

Carthage/Commandant

Commandant - Type-safe command line argument handling

3:58 AM

Command.mainはまっすぐ進むだけで特にRunLoopとかも構築してないけど

3:59 AM

Carthage内部での並列処理とかどうやってんだろう

3:59 AM

コマンドレベルでのプロセス切り離しと待機しかしてないのかな。

ReactiveSwiftが入ってるからそっち側で何かあるのかな

ReactiveSwift側でdispatchQueueでバックグラウンドに投げることはできたとして

4:00 AM

メインにキューが無いとmainQueueに戻せないから

4:01 AM

疑似メイン＋BGみたいな構成になりそう

4:01 AM

@available(OSX 10.6, *) public func dispatchMain() -> Never

4:01 AM

当然だけどNever

お？

dispatchMain 知らなかったけどこれは良いものを知った

sourcekitd_set_notification_handler を使うのに必要でした。

/// Lazily and singly computed Void constants to initialize SourceKit once per session. private let initializeSourceKit: Void = { sourcekitd_initialize() }() private let initializeSourceKitFailable: Void = { initializeSourceKit sourcekitd_set_notification_handler { response in if !sourcekitd_response_is_error(response!) { fflush(stdout) fputs("sourcekitten: connection to SourceKitService restored!\n", stderr) sourceKitWaitingRestoredSemaphore.signal() } sourcekitd_response_dispose(response!) } }()

1

4:10 AM

グローバル変数のletをVoid型に宣言してlazy関数にしてる・・・

initializeSourceKitはjpsimが書き直してたはず

4:13 AM

CarthageはGCDで色々並列化していたはず。

なるほど

ReactiveCocoa(後のReactiveSwift)で複数スレッドの終了待ち通知を組んでたけど、通知時点のコールスタックが深すぎて、メインスレッドが終了する前に通知したスレッドが終了しきれずにクラッシュする不具合を直したことがある。

まだその仕組み残ってるな。 https://github.com/Carthage/Carthage/blob/master/Source/carthage/Extensions.swift#L54-L61

Carthage/Carthage

Carthage - A simple, decentralized dependency manager for Cocoa

ReactiveCocoaで通知してdispatch_groupで終了を待つ https://github.com/Carthage/ReactiveTask/blob/master/Sources/Task.swift#L44-L46

Carthage/ReactiveTask

ReactiveTask - Flexible, stream-based abstraction for launching processes

おー

4:41 AM

ややこしい感じになってますね

↓のメソッドって encoding が .utf8 で失敗することってあるんでしょうか？おそらく、表現できない文字が含まれていたときに nil になるんでしょうが、 Swift の String の文字列の内部表現が UTF-16 なので、 encoding が .utf8 なら Unicode のコードポイントの表現の変換だけだから失敗することがないように思います。 https://developer.apple.com/documentation/swift/stringprotocol/2923420-data

3:42 AM

あー、 String は内部表現が UTF-16 だけど、 StringProtocol はその限りではないか。

3:42 AM

↑は、 String の data(...) を呼ぶとして、 .utf8 で失敗し得るか。今、 ! を付けたい。 (edited)

StringProtocol が var utf8: Self.UTF8View を必須としているので、なんらかのUTF8表現は返すことは保証されていますね。

3:50 AM

associatedtype UTF8View : Collection where Self.UTF8View.Element == UInt8

3:52 AM

けど、このメソッドは単純に ObjC Foundation にフォワードしているので、

おお、ほんとですね。

3:52 AM

じゃあ StringProtocol であっても

Foundation 実装次第ではあります。

foo.data(using: .utf8) が失敗することはなさそうですね。

3:55 AM

ええっ・・・、これって Foundation 依存なんですね・・・。 String.Encoding が Foundation なのおどろきです・・・。 https://developer.apple.com/documentation/foundation/string.encoding (edited)

3:56 AM

Swift パッケージは閉じていない？？

3:57 AM

↑の .utf8 の変換自体は、現実的には失敗は考慮しなくていいでしょうが。それとは別の話題として Swift パッケージは何にも依存していないと思ってました。

3:58 AM

 1> let a: String.Encoding = .utf8 error: repl.swift:1:15: error: 'Encoding' is not a member type of 'String' let a: String.Encoding = .utf8 ~~~~~~ ^ 1> import Foundation 2> let a: String.Encoding = .utf8 a: String.Encoding = { rawValue = 4 }

3:59 AM

iya

3:59 AM

いや、あたりまえか

3:59 AM

そもそも Data が

3:59 AM

Foundation だから。

4:00 AM

謎なのは↓が Foundation じゃなくて Swift 下に書かれていることか。 https://developer.apple.com/documentation/swift/stringprotocol/2923420-data (edited)

4:01 AM

ん？おかしいのは URL だけ？

ああ、とりあえず大丈夫そうです。流れとしては、 1. StringProtocol 2. String.CharacterView(str) で CharacterView に変換 3. String(charView) で String に変換 4. _bridgeToObjectiveC() で NSString に変換 5. data(using:)

1

4:02 AM

最悪のケースですね。実際には普通の String の場合はショートカットあります。

ページ上部のパスはちゃんと Foundation になってました。 URL はその型の元のパッケージに依存するってことですかね・・・。

4:03 AM

@rintaro ありがとうございます！

Data(str.utf8) は遅いかもしれないけど Swift の Foundation オーバーレイに閉じてて Objective-C に一切渡らず non-failable。

@koher https://twitter.com/inamiy/status/905114092662349824

Yasuhiro Inami (@inamiy)

Awesome new Swift formatting live demo using libSyntax by @harlanhaskins !!! #tryswiftnyc

1:35 AM

libSyntax C++ https://github.com/apple/swift/tree/master/lib/Syntax

swift - The Swift Programming Language

1:36 AM

SwiftSyntax https://github.com/apple/swift/tree/master/tools/SwiftSyntax

swift - The Swift Programming Language

1:38 AM

https://github.com/apple/swift/blob/master/tools/SwiftSyntax/SwiftSyntax.swift SwiftSyntaxにはparseがある

https://github.com/apple/swift/blob/master/tools/SwiftSyntax/SwiftcInvocation.swift#L128

swift - The Swift Programming Language

1:39 AM

swift - The Swift Programming Language

1:40 AM

SwiftSyntaxは $ swiftc を使ってパースする > https://github.com/apple/swift/blob/master/tools/SwiftSyntax/SwiftcInvocation.swift#L128

https://github.com/omochi/SwiftSyntax/issues/1

swift - The Swift Programming Language

SwiftPM版がほしい。

↑のツイートで @inamiy さんに聞いたところ公式もいろいろやる気っぽいけど、とりあえず使えたら楽しそうだからまとめてみようかなと思ってる

1:44 AM

現状の実装がめちゃくちゃ微妙で、 libSwiftSyntax.dylib が配置されてるところからの相対パス ../../../bin/swiftc を叩くので (ちなみにここで #dsohandle というマニアックな言語機能が使われている )

1:44 AM

普通にシステムの swiftc を叩くようにしたら良さそうと思ってる

1:44 AM

でも多分そこで SwiftSyntax と swiftc のバージョン互換性問題が出るｗ

SPMが .swiftを自動でみつけてコンパイルしてくれるように、 .swift.gyb をみつけたら自動でやってほしいのう

Swiftc shipped with Xcode9 beta6 does not support -emit-syntax API · Issue #1 · omochi/SwiftSyntax

SwiftSyntax.ParserError.swiftcFailed(1, ":0: error: unknown argument: '-emit-syntax'\n")

4:28 AM

とりあえずパッケージ化して $ which -a swiftc に対応させてみたんだけど

4:28 AM

swiftc -emit-syntax っていう機能が Xcode9 beta6 同梱版にはついてなくて

4:28 AM

動かなかった・・・

4:29 AM

SwiftSyntaxのコード自体は特に変わった依存先も無くて普通にコンパイルできた。

4:33 AM

うーん、どうしよ。

4:34 AM

xcode9beta7とかでふってこねえかな

自前ビルドしたswiftcの管理ってどうやるのが主流なんでしょう xcodeの中でツールキットを切り替えるやつを前提に考えるのが良いのかな

ツールチェーンビルド build-script -R だと、前述したとおり Xcode にインストールできるパッケージにはなりません。 Xcode にインストールするには、ツールチェーンというものをビルドしなければならないのですが、一番簡単な方法は、 utils/build-toolchain スクリプトを使用する事です。

5:15 AM

http://qiita.com/rintaro/items/2047a9b88d9249459d9a

Swiftコンパイラ開発環境構築 - Qiita

Swift がオープンソースになってしばらく経ちます。コンパイラや標準ライブラリの開発に手を出してみたいけど、リポジトリを落とした後どうしていいかわからない！という方のために、まずは開発環境の構築方法をご紹介します。基本的には[RE...

5:15 AM

これか

5:16 AM

あ、スナップショットはDLできるんだった

Swift4.0ブランチの09/07スナップショットには入ってないけど無印の方の09/07には入ってた

5:53 AM

そういうこともあるのか・・・

4.0 には載らない機能ということですね。

無印のほうって、4.0より先を見てるってことですか？

はい、無印は master なので。

なるほど。

5:55 AM

Xcode無印は3系を配布しててbetaが4系だから、 4.0系のブランチのほうが先をみてるほうかと思っっていました

https://github.com/apple/swift/blob/swift-DEVELOPMENT-SNAPSHOT-2017-09-06-a/include/swift/Option/FrontendOptions.td この0906snapshotで　-emit-syntax が追加されているのに

swift - The Swift Programming Language

6:18 AM

落として入れた swift-DEVELOPMENT-SNAPSHOT-2017-09-06-a-osx.pkg からだと -emit-syntax に対応していない

6:18 AM

何か見落としていそう・・・

あ！！！

6:27 AM

あ〜　やらかした

6:28 AM

[omochi@omochi-iMac bin]$ ./swiftc -frontend -emit-syntax <unknown>:0: error: this mode requires at least one input file

6:28 AM

いけそうになってきた

6:30 AM

xcode-selectで切り替えて $ swift に通るパスは、Xcode同梱のものにすぎなくて

6:31 AM

Xcodeがtoolchain設定でビルド時に使用するものを切り替える挙動は、システムの $ swift を差し替えるわけではないんですね

6:31 AM

なんか前に @norio_nomura さんが書いてた・・・環境変数があったような・・・

xcrun --toolchain swift で toolchain指定した swift 起動できません？一番それがお手軽かと。

あーーいけました　ちょうど辿りつつあった。 https://github.com/apple/swift-package-manager/blob/master/README.md#managing-swift-environments SPMのとこにヒントが

https://github.com/omochi/SwiftSyntax/blob/master/README.md

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

6:45 AM

--toolchain swift-latest とか --toolchain swift-DEVELOPMENT-SNAPSHOT-2017-09-06-a とか

6:45 AM

ためしてたんですが

6:45 AM

--toolchain swift ←なんで・・・

6:47 AM

$ xcrun --toolchain swift --find swift でいけそうです、ありがとうございます

6:52 AM

できた！！

6:52 AM

できたぞ〜〜

omochi/SwiftSyntax

Contribute to SwiftSyntax development by creating an account on GitHub.

7:02 AM

import Foundation import SwiftSyntax func main() throws { let args = Array<String>(CommandLine.arguments.dropFirst()) if args.count < 1 { fatalError("not specified file") } let path = args[0] let source = try Syntax.parse(URL(fileURLWithPath: path)) print(source) } try main()

7:02 AM

↑パースしてプリントするだけの何もしないサンプルが動いた

7:03 AM

ASTに空白文字とかコメントの情報もくっついてるから

7:03 AM

テキストとしてパススルー

README 見て一瞬 executable なのかと思ったらちゃんとパッケージになってた。

Library targetのほうが SwiftSyntax って名前になってる。

ややこしいから executable なくてもいいかも？特にコマンドとして強化するわけじゃなかったら。

まあたしかに。

testExample に入れとけば十分そう。

使用例を提示したいだけです

↑の testExample は使用例の話ね。

7:08 AM

ライセンスは Swift に準ずることになるのかな？ https://github.com/apple/swift/blob/master/LICENSE.txt

https://github.com/omochi/DebugReflect

swift - The Swift Programming Language

そうですね

// comment import Foundation class Cat { var name: String = "mike" }

7:37 AM

[0] process type: SourceFileSyntax [1] process type: SyntaxCollection<DeclSyntax> [2] process type: UnknownDeclSyntax [3] process type: TokenSyntax text: import leading: Trivia(pieces: [// comment, ]) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: Foundation leading: Trivia(pieces: []) trailing: Trivia(pieces: []) [2] process type: UnknownDeclSyntax [3] process type: TokenSyntax text: class leading: Trivia(pieces: [ ]) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: Cat leading: Trivia(pieces: []) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: { leading: Trivia(pieces: []) trailing: Trivia(pieces: []) [3] process type: TokenSyntax text: var leading: Trivia(pieces: [ , ]) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: name leading: Trivia(pieces: []) trailing: Trivia(pieces: []) [3] process type: TokenSyntax text: : leading: Trivia(pieces: []) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: String leading: Trivia(pieces: []) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: = leading: Trivia(pieces: []) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: "mike" leading: Trivia(pieces: []) trailing: Trivia(pieces: []) [3] process type: TokenSyntax text: } leading: Trivia(pieces: [ ]) trailing: Trivia(pieces: []) [1] process type: TokenSyntax text: leading: Trivia(pieces: [ ]) trailing: Trivia(pieces: [])

7:38 AM

トークンに対して leadingTrivia と trailingTrivia として、コメントとかスペースとか、意味のない系の文字列がついてくる

7:39 AM

TriviaはTriviaPieceの配列で、TriviaPieceは空白とか行コメントとかブロックコメントみたいな単位で型付けされてる(enum)

7:39 AM

使いやすそうな雰囲気

TypealaisDeclやStructDeclはあるのにImportDeclやClassDeclはなくてUnknownDeclとやらになる・・・

未対応ってことですー。

なるほど

class DefaultCat { var name: String = "mike" } // yahho @objc public class PublicCat {}

11:10 AM

$ swift run format-example Resources/a.swift

11:10 AM

fileprivate class DefaultCat { var name: String = "mike" } // yahho @objc fileprivate public PublicCat {}

11:10 AM

↑試しにクラス定義に fileprivate をつけるプログラムを書いてみた。

xcrunを使うとmacOSでしか動かないよ。

1

あ、なるほど。 https://github.com/omochi/SwiftSyntax/blob/master/Sources/SwiftSyntax/SwiftcInvocation.swift#L152 ここの中身だけ #if したほうがよさそうですね (edited)

omochi/SwiftSyntax

Contribute to SwiftSyntax development by creating an account on GitHub.

1:04 PM

もともとの実装に対して swiftc の探索を追加しているだけなので、空にしたらよさそう。

macOSにおいては環境変数TOOLCHAINSを設定して使った方が良いかと。

あーそうですね SPMもそうだし、そのほうが切り替えが効くか・・・

2:23 AM

ところでどういうルールにもとづいて

2:23 AM

TOOLCHAINS=swiftにしたときに

2:24 AM

/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain から /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-09-06-a.xctoolchain に切り替わるんですか？

2:24 AM

TOOLCHAINS=swift-DEVELOPMENT-SNAPSHOT-2017-09-06-a とかなら理解できるんですが

protocol P0 {} extension Array where Element : P0 { func aaa() {} } var xs = Array<P0>() xs.aaa() // error: using 'P0' as a concrete type conforming to protocol 'P0' is not supported

1

4:13 AM

protocol P0 {} extension Array where Element : P0 { func aaa() {} } extension Array where Element == P0 { func aaa() {} } var xs = Array<P0>() xs.aaa() // compile ok

2

ディスパッチの問題とかですかね？ where Element: P0 の場合は Array<P0> とは限らないので静的ディスパッチできないとか

Element: P0 が Array<P0> として扱えないのはまあわかるんですが、逆方向の Array<P0> が Element : P0 として扱えても良いと思う

4:20 AM

concrete typeとして使う時のprotocolって、ようはコンパイラが自動生成した AnyP0 と同じ機能をもつと思うので。

protocol P0 { } struct Type: P0 { } extension Array where Element: P0 { func test() { print("P0") } } extension Array where Element == Type { func test() { print("Type") } } let type = Array<Type>() type.test() // Type let p0 = Array<P0>() p0.test() /* iOSPlayground.playground:9:7: note: found this candidate func test() { ^ iOSPlayground.playground:15:7: note: found this candidate func test() { ^ */

2

それ曖昧なのか・・・

4:24 AM

ええ？なんで？ｗ

何でやp0の時Type関係ないやろ

どう考えても片方しかマッチしないやろ

protocolをgenericsに入れるの、この手の不可解な動きが多すぎるので

4:44 AM

@objc protocol以外は絶対に入れないようにしてる

omochi/DebugReflect

DebugReflect - Debug dump support for Swift

7:16 AM

デバッグダンプ用のライブラリを作ったんだけど

7:18 AM

このような方法で、 https://github.com/omochi/DebugReflect/blob/master/Sources/DebugReflect/Util.swift#L25 Anyやconcrete protocolが保持している値が struct なのか class なのか判定できる事がわかったんで、こうやってクラスに関して循環訪問するのをふせいでる https://github.com/omochi/DebugReflect/blob/master/Sources/DebugReflect/DebugReflectWriter.swift#L21-L27

omochi/DebugReflect

DebugReflect - Debug dump support for Swift

omochi/DebugReflect

DebugReflect - Debug dump support for Swift

7:20 AM

Any や Concrete Protocolは内部的には参照型のポインタ共有か、値型を保持するヒープ上のボックスへのポインタだから

7:20 AM

常に as AnyObject は成功してしまうんだけど

7:20 AM

type (of: any) is AnyObject.Type だと判定できるのだ

Mirrorとどっちがいいだろうか

命名の話？ Swift標準の Mirror に乗っかる話？

後者

後者だと、ツリー構造において weak var parent を無視したいとか

7:21 AM

そういうのでめんどくさそうなんだよね

あーそっちの意味もあるか

7:22 AM

えっと

7:22 AM

type(of: any)のとこをMirrorで見分けることができるかなと

あ、そっちか

7:23 AM

できそうだけどMirrorは使わないで済むなら使わないほうがいいやつだと思う

7:24 AM

let subjectType: Any.Type

7:24 AM

結局このプロパティをみることになって Mirror(reflecting: x).subjectType と書くのと type(of: x) と書くのが同じ意味になりそう。

ふむ

ツリー構造において、親の存在はせいぜいn階層に対してnで爆発はしないから

7:44 AM

Mirror使った実装でいい気もしてきた

それはライブラリ自体の仕組みの話？

sou

まあ現状でも

7:46 AM

デフォルトエクステンションとして

7:46 AM

Mirrorによる実装を注入しておくとかは

7:46 AM

可能なんだよね

7:46 AM

Mirror実装の振る舞いが困る人は手で実装すればいいって形にできる

TOOLCHAINS=swift-DEVELOPMENT-SNAPSHOT-2017-09-06-a とかなら理解できるんですが TOOLCHAINS=swiftは省略形で、複数バージョンのtoolchainがインストールされている場TOOLCHAINS=org.swift.3020170906aと書きます。 Xcode 7.3からかな？ https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW233

To use an alternative toolchain with command-line tools, use `xcrun --toolchain swift` and `xcodebuild TOOLCHAINS=swift`. You can provide either the abbreviated or the full identifier for the toolchain, for example, `xcrun --toolchain swift` or `xcrun --toolchain org.swift.20151231a`.

1

11:59 PM

インストールされているtoolchainのidはインストーラパッケージのidにも使われているので、 $ pkgutil --pkgs|grep -i org.swift org.swift.3020170908a とかするとみつけられます。

12:02 AM

ちなみに/Library/Developer/Toolchains/ から削除してもパッケージデータベースには残るので、過去にインストールした分も出てくるかと思います。その場合 $ sudo pkgutil --forget org.swift.3020170908a Password: Forgot package 'org.swift.3020170908a' on '/'. でパッケージデータベースから削除できます。

なるほど！ファイル名じゃなくてpkgutil系のエントリが作られているんですね！

identifier自体は/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-09-08-a.xctoolchain/Info.plistにCFBundleIdentifierとして記述されているものをチェックしてるのだと思います。

本当だ。Aliasesとして swift とも指定されていますね。

var foo: Bool { switch x { ... } } ↑こういうの、別にクラスの中だけじゃなくて、適当にその辺にも書けるんですね。funcも書けるから考えたら当たり前だけど認識の外にあったから使えてなかった。

使えるけど使いたいとは思わない系のものですかね

let foo: Bool switch x { case ...: foo = true case ...: foo = false ... } (edited)

6:58 AM

これとの比較ですが、ブロックにしまっちゃいたい感情

それならどうせならクロージャーにまとめたい感情 let foo: Bool = { switch x { case ...: return true default: return false } }()

クロージャだと補完が厳しいのと、直感に従えばコンパイル後はクロージャと同じになる気がしていて

run派 let foo: Bool = run { switch x { case ...: return true default: return false } }

タイプ数の差も優秀

でも let 使える

見た目だけの違いで同じですよ

7:02 AM

var x { get } なので再代入不可能

たるのん式だと foo を3回書くのがね

でも実行時によって値の変化の可能性あり

あ、var { get } にしたい元の書式の話か

7:03 AM

var { get } にすると都度計算されちゃうから同一値保証が無いね

元のリソースを書き換えるのを考慮してなかった

7:04 AM

基本全部letで書いていきたいですね

前出てた @_export、 vaporプロジェクトの redisモジュールで使われてる (edited)

11:11 AM

https://github.com/vapor/redis/blob/master/Sources/Redis/Exports.swift

vapor/redis

redis -

️Pure Swift Redis client built on top of vapor/sockets.

11:11 AM

@_exported import Core @_exported import Node

11:12 AM

CoreとNodeは vapor/core と vapor/node https://github.com/vapor/redis/blob/master/Package.swift

vapor/redis

redis -

️Pure Swift Redis client built on top of vapor/sockets.

複数のSwift Toolchainがインストールされている時、Xcodeで使うやつを切り替えても、 xcrun --toolchain swift で使われるものはそれと連動して切り替わらないみたいなんですが、 Xcodeで指定してるツールチェインを取る方法について知りませんか？ @norio_nomura

xcrun --toolchain swiftはどこで呼ばれるの？

僕が改造した SwiftSyntax の内部です https://github.com/omochi/SwiftSyntax/blob/master/Sources/SwiftSyntax/SwiftcInvocation.swift#L151

omochi/SwiftSyntax

Contribute to SwiftSyntax development by creating an account on GitHub.

7:30 AM

Apple通常配布版のSwiftだと -emit-syntax の機能が使えないから、swift org から落としてきたデイリースナップショットをインストールしてもらって、 SwiftSyntaxはそれを叩く必要がある

子プロセスを起動する時に環境変数TOOLCHAINSを引き継がないとダメじゃないかな？

あーそういう意味だとそもそも、普通に単体でシェルで xcrun --toolchain swift をやったときの結果も

7:46 AM

xcodeと連動していないので困っています

xcrun --toolchain `defaults read com.apple.dt.Xcode DVTDefaultToolchainOverrideIdentifer` --find swift これが一番手っ取り早い気がする。

お、xcodeの設定が反映されてる。

そもそもSwift Package Managerからの起動で、XcodeがGUIで選択しているtoolchainは取得できないよね。

あー

7:48 AM

そうか、SPM開発においてはそもそも、TOOLCHAINSを設定するものか

そう。なので、環境変数TOOLCHAINSを子プロセスに引き継いだ上で、単純にswiftcを叩けば良いと思う。

7:49 AM

$ swiftc --version Apple Swift version 4.0 (swiftlang-900.0.65 clang-900.0.37) Target: x86_64-apple-macosx10.9 $ TOOLCHAINS=swift swiftc --version Apple Swift version 4.1-dev (LLVM 0ccf92e239, Clang f2b194a275, Swift 110c8437f9) Target: x86_64-apple-darwin17.0.0

(edited)

7:50 AM

xcrunなんて使う必要ない。

TOOLCHAINSの適用は普通のswiftコマンドでも自分で面倒みて切り替わってくれるんですね

7:51 AM

swiftコマンド自体がswiftコマンドをdispatchするの便利だな

7:51 AM

納得です、この流儀を前提に見直します。 @rintaro もありがとうございました。

TOOLCHAINS 環境変数設定しても、Xcodeで選んだやつにならなくないですか？

Xcodeで選んだやつにするっていう発想が間違っていたと思いました

この場合、多分Xcodeで選ぶ必要はないのです

古いdevelopmentスナップショット入っていると、そっちが選ばれてしまって

あ、Xcodeで実行する時は必要。

-emit-syntax 無くて怒られる。 (edited)

export TOOLCHAINS=org.swift.3020170906a

7:53 AM

=swift だとだめなので、 ↑この形式のピンポイント指定ですね

ピンポイント指定するしかないみたいですね。

XcodeのschemeのrunアクションにはTOOLCHAINSを指定して、ビルドに使うツールチェインにはスナップショット使う必要ないのでは。

7:56 AM

ああ、Swift Package ManagerでのビルドにはTOOLCHAINSを使うことで、4.0リリースと最新スナップショットの両対応テストのフローが出来るかな。 (edited)

8:02 AM

子プロセスを起動する時に環境変数TOOLCHAINSを引き継がないとダメじゃないかな？ これは勝手に引き継がれるね。

8:04 AM

$ TOOLCHAINS=swift swift run format-example Package.swift Compile Swift Module 'SwiftSyntax' (16 sources) Linking ./.build/x86_64-apple-macosx10.10/debug/format-example -- debug -- [0] process type: SourceFileSyntax [1] process type: SyntaxCollection<DeclSyntax> [2] process type: UnknownDeclSyntax [3] process type: TokenSyntax text: import leading: Trivia(pieces: [// swift-tools-version:4.0, ]) trailing: Trivia(pieces: [ ]) [3] process type: TokenSyntax text: PackageDescription leading: Trivia(pieces: []) trailing: Trivia(pieces: []) [2] process type: TopLevelCodeDeclSyntax [3] process type: CodeBlockSyntax [1] process type: TokenSyntax text: leading: Trivia(pieces: [ ]) trailing: Trivia(pieces: [])

↑現在の実装だとxcrun --toolchain swift で見つけたものを使っちゃうのでテストにならないです

これではダメなの？

$ TOOLCHAINS=swift xcrun --toolchain swift --find swiftc /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-09-18-a.xctoolchain/usr/bin/swiftc

むむ？

多分 Process に渡す swiftc を指す URL が必要なんだと思うけど、/usr/bin/which swiftcで返ってくる/usr/bin/swiftcをそのまま使えばいいんじゃないかな？

$ /usr/bin/swiftc --version Apple Swift version 4.0 (swiftlang-900.0.65 clang-900.0.37) Target: x86_64-apple-macosx10.9 $ TOOLCHAINS=swift /usr/bin/swiftc --version Apple Swift version 4.1-dev (LLVM 0ccf92e239, Clang f2b194a275, Swift 110c8437f9) Target: x86_64-apple-darwin17.0.0

(edited)

ですね

8:12 AM

現状から locateXcrunSwiftc() を削除するだけっぽい

SPMでもXcodeでも環境変数TOOLCHAINSを使うのは避けられないと思うので。

8:16 AM

プロジェクトのビルドはSwift 4.0だけど-emit-syntaxは最新のスナップショットで、ってのが将来必要になるのならば、format-exampleコマンド自体に--toolchainオプションを持たせるとかしないとダメかな。 (edited)

まあその場合も TOOLCHAINS=org.swift.xxxx swift run format-example ... で

それだと最新のスナップショットでのビルドがswift runで走っちゃうよ。

あーそゆことか

ビルド済みモジュールのtoolchainバージョンと起動しているtoolchainのバージョンが違うと、リビルドされてしまうから。 (edited)

8:21 AM

swift-DEVELOPMENT-SNAPSHOT-2017-09-18-aはSwift 4.1を名乗るってことは、-emit-syntaxはSwift 4.1に入るのかな？

8:22 AM

だとすると4.0と最新スナップショットの違いに神経質になる必要はないのかも。

swift.orgでダウンロードできるやつだと

8:23 AM

Swift4.0branchのスナップショットもあって

8:23 AM

そっちだと駄目なんですよね (edited)

swift-4.0-RELEASEタグついた。 https://github.com/apple/swift/releases/tag/swift-4.0-RELEASE

https://swift.org/blog/swift-4-0-released/

swift - The Swift Programming Language

Swift 4.0 Released!

Swift 4 is now officially released! Swift 4 builds on the strengths of Swift 3, delivering greater robustness and stability, providing source code compatibility with Swift 3, making improvements to the standard library, and adding features like archival and serialization.

9

[6/24] Generating C:/Users/qoncept/work/swift-build/build/./lib/swift/windows/x86_64/MSVCRT.swiftmodule FAILED: lib/swift/windows/x86_64/MSVCRT.swiftmodule lib/swift/windows/x86_64/MSVCRT.swiftdoc cmd.exe /C "cd /D C:\Users\qoncept\work\swift-build\build\stdlib\public\Platform && "C:\Program Files\CMake\bin\cmake.exe" -E remove -f C:/Users/qoncept/work/swift-build/build/./lib/swift/windows/x86_64/MSVCRT.swiftmodule && "C:\Program Files\CMake\bin\cmake.exe" -E remove -f C:/Users/qoncept/work/swift-build/build/./lib/swift/windows/x86_64/MSVCRT.swiftdoc && C:\Python27\python.exe C:/Users/qoncept/work/swift-build/swift/utils/line-directive @C:/Users/qoncept/work/swift-build/build/stdlib/public/Platform/fDmbf.txt -- C:/Users/qoncept/work/swift-build/build/./bin/swiftc -emit-module -o C:/Users/qoncept/work/swift-build/build/./lib/swift/windows/x86_64/MSVCRT.swiftmodule -target x86_64-unknown-windows-msvc -resource-dir C:/Users/qoncept/work/swift-build/build/./lib/swift -O -I C:/Users/qoncept/work/swift-build/build/./lib/swift/windows/x86_64 -module-cache-path C:/Users/qoncept/work/swift-build/build/./module-cache -no-link-objc-runtime -swift-version 3 -autolink-force-load -warn-swift3-objc-inference-complete -D_USRDLL -Fsystem //System/Library/PrivateFrameworks/ -Xfrontend -autolink-library -Xfrontend oldnames -Xfrontend -autolink-library -Xfrontend msvcrtd -module-link-name swiftMSVCRT -force-single-frontend-invocation -parse-as-library @C:/Users/qoncept/work/swift-build/build/stdlib/public/Platform/fDmbf.txt" C:/Users/qoncept/work/swift-build/swift/stdlib/public/Platform/msvcrt.swift:13:19: error: no such module 'ucrt' @_exported import ucrt // Clang module

12:27 PM

https://github.com/apple/swift/blob/master/docs/Windows.md を参考にWindowsでSwiftをビルドしようとしてるんですが、 MSVCRT.swidtmodule のビルドがうまくいかない

swift - The Swift Programming Language

12:29 PM

https://github.com/apple/swift/tree/master/stdlib/public/Platform msvcrt.swift, ucrt.modulemap, visualc.modulemap は同じディレクトリに入ってるけど、 modulemap から Framework とかを作らずにそもまま swift から import するのってできるんですっけ？ (edited)

https://github.com/apple/swift/pull/5904

swift - The Swift Programming Language

コマンドラインで試してるけど、 -I オプションで渡したディレクトリ群の中に module.modulemap があると、 import できるようになる感じだなあ

1:44 PM

ucrt.modulemap を、module.modulemap にリネームした上でライブラリのあるところにコピペして

1:44 PM

-I にパスを追加すればいいんだろうか

↑それで突破できました。

WindowsネイティブでSwiftを使う動機が何なのか気になりました。

iOS向けに実装したコードをwindowsで動かしたかった。

11:46 PM

bash on windowsでよかったんだけど

11:47 PM

特定のマシンでブルースクリーンが多発していて

11:47 PM

どうもHyperVが壊れている・・・

あらら、なるほど。

いろいろ弄ってかなりあと一歩まで来た

11:48 PM

[10/24] Linking CXX shared library bin\swiftSwiftPrivate.dll FAILED: bin/swiftSwiftPrivate.dll lib/swift/windows/i686/swiftSwiftPrivate.lib cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll --intdir=stdlib\private\SwiftPrivate\CMakeFiles\swiftSwiftPrivate-windows-i686.dir --manifests -- C:\PROGRA~2\MICROS~1.0\VC\bin\link.exe /nologo stdlib\private\SwiftPrivate\windows\i686\SwiftPrivate.obj /out:bin\swiftSwiftPrivate.dll /implib:lib\swift\windows\i686\swiftSwiftPrivate.lib /pdb:bin\swiftSwiftPrivate.pdb /dll /version:0.0 /machine:X86 /INCREMENTAL:NO -LIBPATH:C:/Users/omochi/work/swift-source/build/swift/./lib/swift/windows/i686 -LIBPATH:C:/Users/omochi/work/swift-source/build/swift/./bin/../lib/swift/windows/i686 -LIBPATH:C:/Users/omochi/work/swift-source/build/swift/./bin/../lib/swift/windows -LIBPATH:C:/Users/omochi/work/swift-source/icu/lib/icuuc.lib -LIBPATH:C:/Users/omochi/work/swift-source/icu/lib/icuin.lib -LIBPATH:C:\Users\omochi\work\swift-source\build\llvm\.\lib lib\swift\windows\i686\swiftCore.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ." ライブラリ lib\swift\windows\i686\swiftSwiftPrivate.lib とオブジェクト lib\swift\windows\i686\swiftSwiftPrivate.exp を作成中 SwiftPrivate.obj : error LNK2001: 外部シンボル "__T0s16TextOutputStreamMp" は未解決です。 bin\swiftSwiftPrivate.dll : fatal error LNK1120: 1 件の未解決の外部参照 LINK failed. with 1120

11:48 PM

Add support for building Swift on Windows with clang-cl and MSVC by hughbe · Pull Request #5904 · apple/swift

Caveat Please note: this PR on its own does not constitute actual support for building on Windows upon merging this PR. For this, apple/swift-clang#45 and apple/swift-llvm#33 will have to be merged...

11:48 PM

↑このマージ済みのプルリクで

11:49 PM

_TMps16TextOutputStream のシンボルが見つからなくてlibSwiftPrivate.dllがビルドできない問題残ってるからこれはいつか直そう

11:49 PM

って書いてあるんですけど

11:49 PM

まさに今そこに到達した（Swift Manglingが少し変わって __T0s16TextOutputStreamMp だけど）

11:50 PM

ただこれが解決してるか誰かのパッチが転がってない限りここで詰みそう

11:55 PM

実際これかなり謎で、リンカ入力の lib\swift\windows\i686\swiftCore.lib をdumpbinで調べると、ちゃんと __T0s16TextOutputStreamMp は入ってるんですよね

SwiftをWindowsでビルドするCIとか、誰か動かしてるのかな？

11:57 PM

無ければあっという間に壊れそうだ。

手元でも、6/29のスナップショットに、masterと、未マージのパッチを個別に当てて

11:59 PM

やっとここまで来たので、めちゃ不安定だし

11:59 PM

そもそも先人がどこまで到達できているのか謎

11:59 PM

自分のステータスはswift.exeはビルドできるけど、stdlibはビルドできない、という状態で

12:00 AM

うーん。

12:02 AM

https://github.com/tinysun212/swift-windows

tinysun212/swift-windows

swift-windows - Swift for Windows (cygwin, msvc, mingw)

12:03 AM

Win nativeじゃなくてmingw環境だとこれが進んでますね

12:03 AM

リリースが今年の6月でとまってるけど (edited)

12:09 AM

こっちも試してみるか～・・・インストーラついてるみたいだし

swift-4.0-RELEASEはswift-4.0-DEVELOPMENT-SNAPSHOT-2017-08-04-aへチェリーピックを足したものらしい。

$ git tag --merged swift-4.0-RELEASE|grep swift-4.0|tail -2 swift-4.0-DEVELOPMENT-SNAPSHOT-2017-08-04-a swift-4.0-RELEASE

2:06 AM

https://github.com/apple/swift/compare/swift-4.0-DEVELOPMENT-SNAPSHOT-2017-08-04-a...swift-4.0-RELEASE

https://github.com/SwiftForWindows/SwiftForWindows/issues/3

swift - The Swift Programming Language

Building DLLs · Issue #3 · SwiftForWindows/SwiftForWindows

Thanks for all your work helping to bring Swift to Windows. Do you plan to support building a DLL instead of an executable? This would help a lot for those of us interested in using Swift to write ...

5:56 AM

なるほど分割ビルドができない

Swiftにコントリビュートする時の温度感を知りたい

2:43 AM

どこからevolutionでどこまでPRでいいのか、とか。

新API追加はswift-evolutionだと思います。

2:44 AM

バグフィックスとかはPRでいいかと。

tarunon - 2017/09/01 "\(foo)"に関してはfooがCustomStringConvertibleじゃなければ遍く警告で良いと思うんだよな〜

2:45 AM

これを試してうまく行ってる感あるので

微妙ラインな気がしますね。

ですよね

PR投げてみて、swift-evolutionの方がよかったらProposal作るよ、みたいなコメント入れとくとか？

なるほど

@rintaro さんに聞いてみるのが一番よさそう・・・。

りんたろさんたすけてくれ~~

プルリク見てると

コミッターに投げる

それはswiftdevMLで話し合った方がいいみたいなレスがついて

2:47 AM

そのあとで、いやこれはコアデザインだ、

2:47 AM

って別の人がレスしてるの

2:47 AM

きのうみた

とりあえずPR投げてみて適切なところにForwardingしてもらうのが良いかしらね

なるほど。それなら曖昧なものはとりあえず投げてみても良さそうな気も。

幸いコードはあるから

遅くなりました。evolutionになるにしても最早実装は必須なので、とりあえずPR投げちゃえばいいと思いますよ。

1

waiwai

3:13 AM

あざます

FileManagerのメソッドがだいたいStringなの気持ち悪い

3:50 AM

URLがいい

てか Path 型がほしい。

FileURLだと不足ですか？

1

自作のFilePath はよくつかってる

4:00 AM

あ、モアイさん復活した

（ようやくdiscordみれました）

FileURL って　URL型のコンストラクタですよね

4:01 AM

schemeとかportとか余計なプロパティがついてるから型としてはちょっと広いんですよね

4:01 AM

Stringよりはマシですが

4:02 AM

ただ自作のファイルぶち込む可読性の低下と悩んでURLで我慢することもある

たしかに内部では file:// で無理やりURLに当てて表現されてしまうのはありますね、完全に適してるかというと微妙なのはありそうですが

うっかりabsoluteStringつかうと file://ついてきたり。

あるあるです

まあ、そのまま動くこともあるけどｗ

↓こういうの辛い ((... as NSString).deletingLastPathComponent as NSString).appendingPathComponent(...)

なるべく早期にURL型にしておくと NS を見ないで済むｗ

たまに URL から戻さないといけないときない？

（でも今FileManagerにextensionをはやそうとしてるからSTringでうけてURLで処理してStringで戻すハメに・・・

4:07 AM

なるべくその瞬間に url.path ですね

そう、そういうの。

API界面だけでStringが出現するようにしてできるだけ型を保ちたい

EasyPathを作るか・・・

https://github.com/apple/swift-package-manager/blob/master/Sources/Basic/Path.swift

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

struct Path { private var string: String ... } let path: Path = "/foo" let foo = path["bar"] // /foo/bar

@rintaro お。しぶい。AbsとRelを型付けしてる！

実装もインターフェイスも詳しくみてないけど、だいたい機能は揃っているんじゃないかな

SPMのソースは他のBasic/*.swiftにも依存してそうでなあ

Windows 対応とかされてなさそう？

Abs / Rel は型付けるか実行時エラーに逃がすか悩むんだけど実例はじめてみた

\ にも対応したい

Path.swift は単なる文字列操作ですね。

var driveLetter

FileSystem.swift にファイルシステムが絡む実装がある。

なるほど

ふむふむ https://github.com/apple/swift-package-manager/blob/master/Sources/Basic/FileSystem.swift#L418

https://github.com/kylef/PathKit

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

// FIXME: We only support macOS right now.

4:13 AM

FIXMEだ

4:14 AM

 /// Helper method to recurse and print the tree. private func recurse(fs: FileSystem, path: AbsolutePath, prefix: String = "") throws { let contents = try fs.getDirectoryContents(path) for (idx, entry) in contents.enumerated() { let isLast = idx == contents.count - 1 let line = prefix + (isLast ? "└── " : "├── ") + entry print(line) let entryPath = path.appending(component: entry) if fs.isDirectory(entryPath) { let childPrefix = prefix + (isLast ? " " : "│ ") try recurse(fs: fs, path: entryPath, prefix: String(childPrefix)) } } }

4:14 AM

楽しそうなのある

kylef/PathKit

PathKit - Effortless path operations in Swift

あのアスキーアート実装したこと無い　結構簡単に書けるのか・・・

public extension Int { func double() -> Int { return self * 2 } } extension Int { public func triple() -> Int { return self * 3 } } print(1.double()) print(1.triple())

public どっちに付けてる？

内側派。

外側につけた場合、内側が無指定の場合のvisibilityを意味していて、外側と内側の両方につけた場合は、外側 >= 内側でないとコンパイラ警告が発生して、内側だけに付けた場合は、内側の指定が常に有効・・・両方とも付けない場合は暗黙のinternal になって、外側がついていない場合の暗黙のinternal は外側 >= 内側ルールは生じない (edited)

外側につけてコンパイルエラーになったことがある気がするんだけどあれは何だったんだろう？

エラーですか？

5:14 AM

外 < 内だと警告は出るみたいです

5:15 AM

protocol conformanceを記述する場合はまた話が変わるのかなコレ

conformanceは外側必須だった気がする

public protocol P0 { func pp() } public extension Int : P0 { public func pp() {} } 1.pp() error: TempGround.playground:5:1: error: 'public' modifier cannot be used with extensions that declare protocol conformances public extension Int : P0 { ^~~~~~~

5:17 AM

むしろ外側に付けられない・・・？あれ？

5:18 AM

@koher の言っているエラーになった話はこれかなあ

かも？

暗黙的にprotocolのvisibilityが適応されますよということか

ああそういうことなのか。

確かに extension Foo: PublicProtocol, InternalProtocol {

5:24 AM

これは困る

publicなprotocolを、ローカルにconformすることは

5:24 AM

できないのか。

そうそう、それはできない。

なるほど、まあ確かにできても意味ない。

5:28 AM

public protocol PP0 { func pp0f0() } internal protocol IP0 { func ip0f0() } extension Int : PP0, IP0 { public func pp0f0() {} func ip0f0() {} }

5:28 AM

これはできるんだなあ

internalだからな

でもそうか conformanceするときには結局メソッドにpublicを明示しないといけないから

5:30 AM

そのパターンと統一しようとすると

5:30 AM

extension自体につけることはなくなってきそう

Recursive Protocol Constraintsが入ると、Standard Libraryのプロトコル階層がシンプルになる。 https://github.com/apple/swift/pull/11923/files (edited)

[WIP] [SE-0157] Standard library uses of Recursive Protocol Constraints by DougGregor · Pull Request #11923 · apple/swift

This pull request implements the standard library part of SE-0157: Recursive Protocol Constraints, which includes: Make the SubSequence associated type have the same capabilities as its enclosing ...

例えばCollectionだと、現在は非表示になってる_Indexableを使わずに済む様になり、associatedtype Elementやvar startIndex: Indexの定義がCollectionへ移り、それらがCollection準拠に必要なものだということが判りやすくなる。 https://github.com/apple/swift/pull/11923/files#diff-1e8313acf545a6c1b6fbb71978690ff6R348

[WIP] [SE-0157] Standard library uses of Recursive Protocol Constraints by DougGregor · Pull Request #11923 · apple/swift

This pull request implements the standard library part of SE-0157: Recursive Protocol Constraints, which includes: Make the SubSequence associated type have the same capabilities as its enclosing ...

recursive protocol constraintsは4に入ってましたっけ？

よくわからないですね。 https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md

https://blog.waft.me/2017/08/01/swift-type-system-01/

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

Playgroundで触った感じ入ってなさそう

「ビルドパフォーマンスが落ちた」とかでrevertされたところまでは覚えてた。

ビルドパフォーマンス落ちるのは残当感ある

2:59 AM

コンパイラと戯れるときのデバッグプラクティスが知りたいんですがいい方法無いですか

3:02 AM

PrintExpr使ってprint debugできるっぽいけどコンパイル終わらないケースがあってなかなかつらい

どのフェーズを触るかにもよるかもしれないけど、swift -frontend に便利コマンドがたくさんあるイメージ

Swiftの型システムを読むその1

今年はTaPLを割と読み進められていて、型推論をSwiftで実装したり、存在型についてSwiftで考えてみたりしている。そろそろ実際の言語の型システムも読めそうな気持ちになってきたので、なんか読んでみようと思い、一番よく使うSwiftか一番好きなScalaか一番興味があって型システムもイケてそうなRustあたりで迷って、結局Swiftを読んでいる。これは読みながら書いたメモ。

3:08 AM

これでいけるやろうか

3:08 AM

やったこととしてはwarningの追加で、起きていることはParseErrorを押し退けてwarningが出てしまっていてやばい

ちゃんとParserErrorになってるな、うーん、ギョーム終わったら続きやるか

ここまでのあらすじ from: #zatsu

UIViewController.viewをoverrideしてdidSetしたらStackOverflowすることに気がついた @hiragram#0393 lazy varにdidSet使えないことと関係あるのではと推論するがlazy varはoverrideするとdidSet使えることに気がついてもう大変

(edited)

11:01 AM

@hiragram @Yuta Saito @_ha1f

11:02 AM

@Kishikawa Katsumi

議論の対象はlazy varをoverrideするとdidSet使えちゃうのおかしいのでは、という話かな？

ちなみにoverride lazy var didSetは初回のlazy setでは呼ばれなかった

11:04 AM

まあ両方ここでしていいんじゃね

StackOverflowするやつはやっぱobjcのブリッジ絡みなのかしら。 (edited)

objc-runtimeで絶対いらんことしてるという確信に近い直感がある

11:06 AM

lazy var overrideのこれ、使えるなら

11:06 AM

いつぞやのlazy var fatalErrorでIUO使うのをやりたくないワークアラウンドがかなり使いやすくなる

11:06 AM

クラス階層一個増えるのだるいけど

たるのん先生的にはlazy varでdidSetが封じられてるのはどうしてなのかしら

前までは何か理由があるのかなと思ってたけど、override触った感じ正しく動いてると感じるし

11:07 AM

ただのサボりではという気持ちになってきた

草

https://gist.github.com/tarunon/6e63b708140392564418eb80ac64e899

lazy var fatalError is a solution that instead of ImplicitlyUnwrappedOptional

11:08 AM

lazyvarfatal定期

class A { lazy var hoge: Int = 1 } class B: A { override var hoge: Int = 1 { didSet { print("didSet") } } } こうすると error: variable with getter/setter cannot have an initial value って言われるから lazy varを overrideするとswift側でもcomputed property扱いになるんじゃないかと思った (edited)

あー

11:17 AM

class Foo { lazy var _bar : Int = 0 var bar: Int { set { _bar = newValue } get { return _bar } } } 確かにこうすればwillSet, didSet相当の処理は書けますね

11:22 AM

propertyのoverride気持ちを考えるとlazy didSetは使えないがoverrideは使えるはそれはそれで正なのではという気がしてきた

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Inheritance.html#//apple_ref/doc/uid/TP40014097-CH17-ID196

Overriding Property Observers You can use property overriding to add property observers to an inherited property. This enables you to be notified when the value of an inherited property changes, regardless of how that property was originally implemented. For more information on property observers, see Property Observers.

regardless of how that property was originally implemented

11:42 AM

正規の動きだ

UIViewControllerの方はこれかな https://bugs.swift.org/browse/SR-1000

なるほど

11:56 AM

親クラスのプロパティにwillSet/didSetを差し込みたいからオーバーライドする、というのはオーバーライドの正しい使い方ってことね

それはそう

なるほど

UIViewControllerに関しては随分と前からぶっ壊れてたみたいだね

だから親のやつがstoredだろうが、はたまたlazyだろうが、関係なくoverrideしたものにはオブザーバーがつけれると

1000番だし

UIViewControllerはもうね。

11:57 AM

ね。

Xcode7から

11:58 AM

まあこっちはUIKitクオリティってことで

最小のコード量で押すとぶっ壊れるツボを見つけるみたいなの一周回って最近楽しくなってきたわ

StackOverflowするやつはやっぱobjcのブリッジ絡みなのかしら。 1. didSet 呼び出し前にoldValue (view)が必要 2. -[UIViewController view] 3. -[UIViewController loadViewIfRequired] 4. -[UIViewController setValue:forKey:] 5. 1へってなってますね。 (edited)

didSetのスコープでプロパティ触った場合ってdidSetに来なかったですよね

12:54 AM

あ、これはdidSetの前でswift関係なく無限ループしてるのか

https://twitter.com/pathofshrines/status/912381388875337728

John McCall (@pathofshrines)

If anybody's looking for a relatively straightforward Swift starter design/implementation task, here you go: https://t.co/E1Li3BtxnA

1:00 AM

まさにこの問題ぽいのですが、シンクロすごい。

1

これっすね

実際オブザーバー付いてると、現状 mutate な操作でも無条件でコピーされてしまうから早く実装されて欲しいです。 (edited)

なるほど swift didSetがoldValueを要求↔objcがcurrentValueにアクセスここを無限に繰り返してる

なるほど

ナルホディウス

https://gist.github.com/omochi/844f68cd6f44bf8d8c3537c2c81e4577

swift-protocol-class-mutating.swift

9:31 AM

へんなのふんだ

PC1.aaa デフォルト実装は class 制約がついていないから PC0.aaa を満たせないっていうことなのか。

var は func と違って、 mutating を指定することはできないけど

9:36 AM

内部的には mutating 付きの struct 向けの var set と、 class 向けの nonmutating な var set が

9:36 AM

区別されている気がします。

9:37 AM

で、 PC0 は : class ついてるから nonmutating set が要求されるようになっていて、 PC1 はついてないから mutating set を実装していて、噛み合わない。

public protocol A { var aaa: Int { get set } } extension A { public var aaa: Int { get { return 1 } set { () } } } public protocol B: class { var bbb: Int { get set } } extension B { public var bbb: Int { get { return 1 } set { () } } }

で sil 出すと

9:45 AM

// A.aaa.setter sil @_T04test1APAAE3aaaSifs : $@convention(method) <Self where Self : A> (Int, @inout Self) -> () { // %0 // user: %2 // %1 // user: %3 bb0(%0 : $Int, %1 : $*Self): debug_value %0 : $Int, let, name "newValue", argno 1 // id: %2 debug_value_addr %1 : $*Self, var, name "self", argno 2 // id: %3 %4 = tuple () // user: %5 return %4 : $() // id: %5 } // end sil function '_T04test1APAAE3aaaSifs' // B.bbb.setter sil @_T04test1BPAAE3bbbSifs : $@convention(method) <Self where Self : B> (Int, @guaranteed Self) -> () { // %0 // user: %2 // %1 // user: %3 bb0(%0 : $Int, %1 : $Self): debug_value %0 : $Int, let, name "newValue", argno 1 // id: %2 debug_value %1 : $Self, let, name "self", argno 2 // id: %3 %4 = tuple () // user: %5 return %4 : $() // id: %5 } // end sil function '_T04test1BPAAE3bbbSifs'

9:45 AM

ABIが違う。

@inout Self はまさに mutating func の self渡しですね

@inout vs @guaranteed

@guaranteed はよくわかっていない。 Ownership Manifesto だと nonmutating func な self は shared渡しになるって書いてあるけど、SILでは名前が違うんかな。

僕も @guaranteed の意味よく知らないです。けど class つけるとリファレンス値の値渡しになるのかと思います。

9:52 AM

public protocol B : class { var bbb: Int { get set } static var initial: Self { get } } extension B { public var bbb: Int { get { return 1 } set { self = Self.initial } } }

test.swift:9:16: error: cannot assign to value: 'self' is immutable set { self = Self.initial } ~~~~ ^ class 付いてないと通る。

ああ、書いてなかったｗそうなんですよ！ｗ

classついてないこのprotocolをclassに実装したらどうなるんですか

それ自体はできる

self置換できる

public protocol B { var bbb: Int { get set } static var initial: Self { get } } extension B { public var bbb: Int { get { return 1 } set { self = Self.initial } } } final class C : B { static var initial: C { return C() } } var c = C() print(ObjectIdentifier(c)) c.bbb = 1 print(ObjectIdentifier(c))

ObjectIdentifier(0x00007fe1f5e04930) ObjectIdentifier(0x00007fe1f5d113b0) (edited)

finalじゃないと怒らるのはinitialの型か

出たｗ

9:57 AM

let c だと b.ccc = 1 が呼び出せないやつ

let ns = (0..<10).map { $0 } let ps = ns[2, 3, 5, 7] 仮に↑こんなことができるとして、 ps[2] // 2 ps[3] // 3 ps[4] // エラー ps[5] // 5 のようになる Collection って標準ライブラリにないですよね？ ArraySlice のすごいやつみたいな。

Dictionaryにして []! で取り出すと同じ？

整数の index に対して index が飛び飛びになるような Collection (edited)

6:49 AM

ArraySlice は startIndex は 0 とは限らないし、 endIndex は count とは限らないけど、間は詰まってることが保証されている。

6:49 AM

Dictionaryにして []! で取り出すと同じ？

同じといえば同じかもしれないけど、 index で表されてるからちょっと違う。

ArraySliceとくらべて保持するデータが多いしあんまり有用そうでは無さそうな……

@t.ae Optionalにして埋めて持てばデータ量はArraySliceとほぼおなじかも

6:51 AM

↑の例だと元々のArrayがあるみたいだから

6:52 AM

全部埋めたメモリサイズはそもそも許容される

Optionalにして埋めて持てば

よくわからないですけどインデックス一覧は保持する必要ありますよね？

いや

6:52 AM

内部的に Array<Int?>

6:52 AM

nilならクラッシュさせる

元のArrayのサイズXとして ArraySliceだと総合してもX+aですみますけどこれだと2Xになっちゃうよなぁと思ったんですが

↓みたいなことができたらいいなぁと考えてた。 users[where: { $0.birthday == today }].update { $0.age += 1 }

6:54 AM

前話してた update メソッドがあればコレクションの要素の更新ができるんだけど、

2Xにはなるね。

SQL で WHERE で絞って更新みたいなのができない。

6:54 AM

値型だと。

それぼくは何か中間データ型おいて似たようなことやらせるのかきましたよ

WHERE が遅延しないといけないっすね

6:55 AM

C# の LinQ みたい。

もちろん users.update(where: { $0.birthday == today }) { $0.age += 1} ならできるけど不細工なので。

LinQでもできない気がするな・・・

で、飛び飛びインデックス Collection があれば、 subscript(where:) にすることでできないかと思って。

あーそれって結局

6:56 AM

.update を受ける型が

6:56 AM

いまいった特殊なやつにすり替わるってことですよね？

そこがミュータブルじゃないから update が無理かな？ (edited)

コレクションのsubscriptをつくって頑張ればできるはず https://github.com/t-ae/Swim readmeに書いてる例がそれっぽいかも image[col: 2] += 1

t-ae/Swim

Swim - Image library for Swift

.where で

6:57 AM

絞り込み条件と元のArrayを保持した型にさしかえて

6:58 AM

update のところで where のフィルタを処理するとできそう

@t.ae それは↑に書いた 2 引数 update と同じだから、 where で一度絞り込んだ上で update を実行したい。

6:58 AM

本当は filter でできれば一番いいんだけど・・・。

6:58 AM

参照型だと簡単なんだけど、値型だと難しい。

image[col: 2].red += 1 みたいなのもできます

6:59 AM

あーでもちょっと違うかな

あー inout型をプロパティに保持できないと

6:59 AM

メソッド一回しか

6:59 AM

先送りできないのか。

そんな感じ

さっき言ってたインデックスなやつがあったとしても

7:00 AM

もともとのArrayに代入する文が必要になっちゃう。

ん？そこの一段目は subscript の set で戻すんだけど

あ〜なるほど

二段目の mutating func である update が

7:00 AM

呼べない気がしてきた。

subscript だから = になるのか

上に張った僕のはsubscript setを定義して +=とかを実装してますね

subscriptで変な型にして、変な型に対してmutating funcかけて

7:02 AM

変な型として元のarrayに戻す

7:02 AM

って手順だとできるのか。。

そうですね。

7:03 AM

users[where~] = users[where~].update {}という形になるので mutating funcである必要はないかも？

ちょっとやってみるか

その再代入はしたくない

7:09 AM

それを subscript にすることで避けられないかと。

7:09 AM

extension Array { mutating func update(_ modify: (inout Element) throws -> ()) rethrows { for i in 0..<count { try modify(&self[i]) } } } extension ArraySlice { mutating func update(_ modify: (inout Element) throws -> ()) rethrows { for i in startIndex..<endIndex { try modify(&self[i]) } } }

mutating funcである必要はないかも？

は大嘘でした

var ns = (0..<100).map { $0 }

7:10 AM

↓これはできるし ns.update { $0 += 100 }

7:11 AM

↓これもできるけど var ms = ns[50..<60] ms.update { $0 += 100 }

7:11 AM

↓これはできなかった。 ns[20..<30].update { $0 += 100 }

そもそもsubscriptにクロージャとれますか？

7:12 AM

いまそこでつまづいた

え？とれない理由があるの？？

TempGround.playground:28:2: note: overloads for 'subscript' exist with these partially matching parameter lists: (Int), (Range<Int>), ((Element) -> Bool), (Range<Self.Index>), (R), ((UnboundedRange_) -> ()) s[wh: { (x: Int) -> Bool in x % 2 == 0 }] ^

7:14 AM

なんか書き方をミスってるのかな

7:15 AM

あ、できた、ラベルつけちゃいけない？？？

subscript は subscript(wh where: (Element) -> Bool) みたいにラベル明示しないと。

1

あ、２個かくのか。

それ地味に分かりにくいですよね

var s = [0, 1, 2, 3, 4] print(s) s[`where`: { $0 % 2 == 0 }].update { (x: inout Int) -> Void in x += 100 } print(s)

Dictionary.Value コレクションの var dict:[String: [Int]] = ["foo": [], "bar": [1,2,3]] dict.values[dict.index(forKey: "foo")!].append(42) なんかは、stdlibならではのかなり特殊なことやっているので、やりたいこと実現するのはなかなか厳しいかも。

[0, 1, 2, 3, 4] [100, 1, 102, 3, 104]

7:17 AM

できた (edited)

7:18 AM

https://gist.github.com/omochi/b40e344ebad0b34a87b6792b5b772d01

swift-lazy-query-array.swift

7:18 AM

実用性は無いしsubscriptのsetにバグがあるけど

7:18 AM

とりあえず見かけ上実現してみたｗ

なるほどー

subscript特有の振る舞いを利用したトリックとしては面白いですね

7:21 AM

Playground execution failed: error: TempGround.playground:28:38: error: passing value of type 'Int' to an inout parameter requires explicit '&' s[`where`: { $0 % 2 == 0 }].update { $0 += 100 } ^ &

7:21 AM

↑これっていま推論できないんです？

7:21 AM

エラーメッセージも意味不明

おお、まさに var dict:[String: [Int]] = ["foo": [], "bar": [1,2,3]] dict.values[dict.index(forKey: "foo")!].append(42) みたいなことですねやりたいの。

.values[] ここ何が

7:25 AM

https://developer.apple.com/documentation/swift/dictionary/2894304-values

dictionary.valuesがdictionaryをmutatingできるのイミフすぎる

これ、内部でもってる参照型のstorage本体を操作してる？

ですです。

1

あー

ずる

set,getなcomputed propertyなら一応動きを再現するものは作れるか

https://github.com/apple/swift/blob/8e39886610ec3e25e8cd7c36a92b93b313a56527/stdlib/public/core/HashedCollections.swift.gyb#L2449-L2456

https://gist.github.com/omochi/76e781ebd927a0ed927f89fd94718d53

swift - The Swift Programming Language

パフォーマンスはさておき

 /// A view of a dictionary's values. public struct Values : MutableCollection { public typealias Element = Value internal var _variantBuffer: Dictionary._VariantBuffer internal init(_ _dictionary: Dictionary) { self._variantBuffer = _dictionary._variantBuffer }

7:27 AM

getのほうも内部参照コピーだな

7:28 AM

同じようなアプローチでやるとどうなるんだろ　なんとかなるきもする？

@tarunon そうなんです。それが値型をコレクションを where, update とつないで更新できないかと思った出発点です。

subscriptなら引数取ってmutatingにできる、なるほど確かに

作れたら面白いと考えてるのは（実際に作るかはさておき）値型データベースライブラリで、 where して update するにはこういう技が必要だろうなと。その場合は自作型になるから↑の Dictionary がやってるような技も使えそう。 (edited)

7:35 AM

そうすると、クエリーの結果が値型コレクションで返ってくるんだけど、トランザクションによって分離されることを値型が状態を共有しないことで表現できればおもしろそう。

swift-indices-map-where.swift

1

7:41 AM

Dictionaryでindexもつ版

本当は users.filter { $0.birthday == today }.update { $0.age += 1 } が出来たらいいんだけど値型には無理。

UnsafeMutablePointer で無理矢理。。

values のトリックは computed var なら戻してこれるのか・・・？

いけるはず

やってみる

7:50 AM

https://gist.github.com/omochi/110d239a80f8cea109225a58018fc6cd

swift-indices-where-wrapper.swift

7:51 AM

できた

7:51 AM

旧 s[where: { $0 % 2 == 0 }].update { (x: inout Int) in x += 100 } 新 s.where[{ $0 % 2 == 0 }].update { (x: inout Int) in x += 100 }

(edited)

w

7:51 AM

var filterは出来ないんだっけ

結局 [{ }] が出てきてださいなあ

まあそこはsubscriptの制約がね

7:52 AM

functionのreturn valueにinout Tが使えたらなぁ

7:52 AM

でも崩壊するか

うん

7:52 AM

それはやめとこうや、って書いてある

s.where[] { $0 % 2 == 0 } ...

2

ｗｗｗ

7:53 AM

いけたｗｗｗ

7:54 AM

subscript後置できたんだ・・・

草

知らなかった・・・

7:55 AM

さすがに [] は省略できない？

7:55 AM

() みたいに

whereにくっついちゃってダメっぽい

そりゃむりか

https://github.com/apple/swift/pull/11933/files

[stdlib] Make all the stdlib APIs @_inlineable by moiseev · Pull Request #11933 · apple/swift

This change in theory should allow us to remove a special stdlib-only sil-serialize-all compilation mode. rdar://problem/34138683

1:40 AM

気になるスレ　ひたすら @_inlineable が追加されるdiff

正確なところはわかないけど、 sil-serialize-all しなくても @_inlineable で .swiftmodule に実装SILが埋め込まれるようになるから、 --sil-serialize-all 要らなくなるって話なのかなと。

あーなるほど、それで1コメが「This change in theory should allow us to remove a special stdlib-only sil-serialize-all compilation mode.」なんですね

1:44 AM

rdar://problem/34138683 ←これの内容の見方をおしえてください @rintaro

rdar は Apple 内部のバグトラッキングシステムなので、外からは見えません。 https://openradar.appspot.com にバグ登録者が登録していれば見えるけど、これはたぶん内部登録なので、わからないですねー

なるほど。

最近Swiftリポジトリをwatchしてみたんだけど、プルリクに動きがあると思ったら、botに「テストしてくれや」って話しかけてるだけの事が多くてアレ

gmailでフィルターしてゴミ箱にぶち込んでる

githubのウェブの右上の通知アイコン使ってるんだよね

それはきびしい

ははは

githubからの通知メールをGmailで開くと https://github.com/notifications でも既読になるから、Gmailでざっと見て必要ならgithubのwebへ、って感じにしてる。

GitHub is where people build software. More than 24 million people use GitHub to discover, fork, and contribute to over 67 million projects.

えっ、そうなんですかそんな謎技術あるのか

本当だ・・・

1:47 AM

[swift-evolution] Idea: Public Access Modifier Respected in Type Definition

1:48 AM

public struct Coordinate { /// Should default to public. let latitude: Double /// Should default to public. let longitude: Double /// Should default to public init?(latitude: Double, longitude: Double) { guard validate(latitude: latitude, longitude: longitude) else { return nil } … } } internal extension Coordinate { /// Convenience initialiser to me used internally within the module. init(coordinate: CLLocationCoordinate2D) { … } }

1:49 AM

struct/class と extension で visibility がメンバにも適用されたりされなかったりするのわかりにくいからstructの挙動を↑に変えないか？ってメール

1:49 AM

この前もextensionで混乱したし一理あると思ったｗ

いいかも。

賛成メールを送ってみた

async, awaitについてのswift-evolutionでの議論、量が多くて早々に追っかけるのをやめてしまったのですが、今どうなってるか知ってる人いますか？

最初追ってましたが、メールが多すぎたのと、先月後半から忙しくなって追えてません。

話題としてReactiveStreamingがちらほら出てきてるのは見てたんですが中身は追いかけれてない

僕は func beginAsync(_ body: () async throws -> Void) rethrows -> Void の throws と rethrows はいらないだろうと思ってます。それは書いたけど、把握してた範囲では返事なしでした。

ここをチェックしておけば良さげ？ https://gist.github.com/lattner

https://github.com/airspeedswift/swift-evolution/blob/0f4a24d6ded2ab7cb39c1a68e0f92705a7615d73/proposals/NNNN-RemoveWhere.md

GitHub is where people build software. More than 24 million people use GitHub to discover, fork, and contribute to over 68 million projects.

1

その二つですね。

async await欲しい

Swiftのasync/await、他の言語と比べても最高だと思うんですよね。

2:27 AM

特にthrows/tryとの組み合わせが素晴らしい。

結局、非同期処理の前にerrorが出ても型としてはasync throws () -> Tですよね

@tarunon ですね。

beginAsyncのthrow rethrowが要らないのがぱっと理解できない

2:30 AM

あ、勘違いだ、これはcallbackをasyncにする奴ではなく

非同期発火前のthorwsについてはどうせrethrowsできないから

2:31 AM

そこのハンドル漏れが出るよりは

処理を投げっぱなしにする奴か。rethrowsだとErrorの時に待つみたいな意味不明なことになる

非同期発火前も含めて禁止したほうがマシではって意見

待つんじゃなくて

待つんじゃなくて無視だったかクラッシュだったか、とにかく、別扱い

非同期突入前の

callbackをasync化する話と混ざってました

Error を rethrow ですね。

しかも非同期突入前のthrowsについてはどうせbeginAsyncの手前に持ってこれるから困らないはずなんだよなあ

この機能って提供する必要あるのかな (edited)

単に Core Team が見落としてるだけな可能性もあるんだけど、スレッドが長すぎて

2:33 AM

書いたとしても読まれるかわからない

2:33 AM

ってか一度書いた

throwsのところは置いといて提供自体は必要だと思う

do { _ = await foo() } つまりこれと同じでしょ?

いや

2:34 AM

えっと

それは提案されてなくない？

まず do { await } はまだないのと

1

2:35 AM

仮に導入するならそれはブロックじゃないと整合性がとれないです。

無いのか…

beginAsync はノンブロッキングなやつだから

んー

2:36 AM

末尾にblock書く/ないで、blockingとnon-blocking区別できそうだけども

それだと意図しないただの do ブロック（普通の言語の無名スコープ相当）の中に await 書いたら変な挙動になっちゃいます。

2:37 AM

末尾に nonblock とか書くことはできますが、

2:37 AM

あまりキレイじゃないと思うんですよねぇ。

2:37 AM

標準ライブラリに関数として beginAsync 追加すれば対応できることですし。

doの無名スコープとしての用法があるのか。いつだったか、async { await }にしようみたいなのもありましたね

一方で、 do { await } block は do { try } catch と対応するのでキレイなんですよね。

ところで

2:40 AM

_ = await foo() これだけでもノンブロッキング感あるんですが

やっと見つかった。早く移行してほしい・・・。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/039024.html

そこはどうなってんだろ

それだとその関数が

2:41 AM

async必須になっちゃいます。

なっちゃうのか

で、どこまでもasyncが連鎖してしまうので

そうか…

根本で囲う必要があって

2:41 AM

それが beginAsync ですね。

2:42 AM

コールバックを async 化するのが suspendAsync

beginAsyncって、逆にコールバック化する関数で、クロージャのデフォルトにnilだと良いと思ったんですがそう言う提案はないですかね？

2:46 AM

そうすると、throwsとそうじゃないのでbeginAsyncをオーバーロードして、結果も全部綺麗になりそうだけど

どういうシグネチャにするイメージですか？

func beginAsync<T>(_ f: () async -> T, callback = ((T) -> ())? = nil) func beginAsync<T>(_ f: () async throws -> T, callback = ((T?, Error?) -> ())? = nil)

こうかな (edited)

async, throws の位置が変な気が・・・

iPhoneなので赦されたし

1

2:50 AM

なおした

2:51 AM

まあこれでやりたいこと全部出来るはず

2:51 AM

suspendの逆でもあるし、解りやすくて良い

うーん、まず beginAsync に throws な関数を渡したいっていうのがよくわからないんですよね。

それはthrows渡せないと、beginAsync使えなくなるのでは

beginAsync { let foo = try foo() await bar(foo) }

2:52 AM

みたいなケースは

2:52 AM

let foo = try foo() beginAsync { await bar(foo) }

2:52 AM

に書き換え可能だと思うんですよ。

awaitの中でthrowは無理くないですか？

それは非同期的に発生するから

2:53 AM

beginAsync では無理です。

というか、async throws組み合わせて使える言語設計なのに、そこだけ自力で頑張れっていうと、ちょっと違う気がする

2:53 AM

さっきのoverloadingなbeginAsyncではいけるのでは？

beginAsync { do { await try foo() } catch { ... } }

2:54 AM

beginAsync の throws/rethrows を封じれば↑が強制されるんですよね。

2:54 AM

これで十分かと。

tarunonのアイデアはわかったけど

func startRequest(_ request: Request, success: (Response) -> Void, failure: (Error) -> Void) { beginAsync { do { success(await try startRequestAsync(request)) } catch let e { failure(e) } } }

2:54 AM

↑あまりに簡単に自分で書けるからそこはいらないのでは

簡単に書けるから要らない、ならそもbeginAsync自体が

あと、asyncフェーズの中では、途中の結果とか、途中のエラーとかもあるから

2:55 AM

「ok1個 | 失敗1個」のシグネチャに制限するのも

2:55 AM

ある特定のシナリオにフォーカスしすぎてると思う

2:56 AM

言語側で用意するのは「結果を捕まえずにasyncを発火する」っていう最小限の機能だけで良いと思う

それはErrorの型とパターンマッチでなんとかするって話じゃないの

コールバックが嫌だから async 化したいわけで、コールバック化できてもうれしいことはないような？

簡単に書けるから要らない、ならそもbeginAsync自体が

beginAsync自体は他の機能で代替できないと思う

そして、 beginAsync の中で try したいときは発火前については外だしできるはずで

「non async な func の中から async な処理を開始する」にはなんらかの言語サポートが必要

ああ、beginAsync自体は必須なのか、そうか

beginAsync に throws なクロージャを渡せる必要性がよくわからない・・・

で、現状の提案のbeginAsyncから throws と rethrows を取り除くアイデアは僕も賛成で、なぜならそれは必須な部分じゃないという理由がここにもマッチする

2:58 AM

必須じゃないのはそのエラーを投げる処理だけbeginAsyncの前にかけるから。

async throws組み合わせて使える言語設計なのに、そこだけ自力で頑張れっていうと、ちょっと違う気がする

僕はこれを考えていて

さらに、非同期関数の多くは async throws になるだろうから、 beginAsync { try await foo() } にコンパイラのチェックが働かなくて、エラーハンドリングがタイプセーフでなくなってしまう。

@koher 最初のawaitまでのタイミングでthrowsになっていることと、それ以降でthrowsになることをシグネチャとして区別できれば良かった Result<Promise<T>> と Result<Promise<Result<T>> と Promise<Result<T>> の区別。

いやーそれきつくない？

でもそれはややこしいから Result<Promise<T>> と Result<Promise<Result<T>> は無いってことになってしまって

3:01 AM

Promise<T> と Promise<Result<T>> だけでいこうって

3:01 AM

方針

3:02 AM

うん、僕も問題が起きるのはbeginAsyncだけだと思うから、これでいいと思う

func beginAsync(_ body: () throws async throws -> Void) rethrows[0] -> Void

3:02 AM

みたいなことしないといけない・・・

beginAsyncが現状の提案のまま破綻しない世界線に行くとしたら何があったかという仮定の話

throws が複数あるときに選択的に rethrow する話はどこか（多分 Error Handling Rationale ）に書いてあった。

3:03 AM

今は実装しないけど、って。

nonblocking化とErrorハンドリングをスッとやるなら、コールバック化が一番良いと思うんだけどな

↓だめですか？ beginAsync { do { await try foo() } catch { ... } }

3:04 AM

可読性も高いし do/try/catch 使えるし。

あー、中でやれと言う話になるのか

3:04 AM

それはそっちのほうが良さそうですね

あと並列タスク発行とかの目的であれば提案されてる Future があれば十分じゃない？

beginAsync から throws/rethrows を取り除けば、↑のエラー処理が（必要な場合は）強制されていい感じになるんですよねぇ。

func processImageData1a() async -> Image { let dataResource = Future { await loadWebResource("dataprofile.txt") } let imageResource = Future { await loadWebResource("imagedata.dat") } // ... other stuff can go here to cover load latency... let imageTmp = await decodeImage(dataResource.get(), imageResource.get()) let imageResult = await dewarpAndCleanupImage(imageTmp) return imageResult }

↑これの、dataREsourceとimageResourceは並列発火されて、それぞれ .get() のところで(awaitで)待つ。 (edited)

3:06 AM

Futureのコンストラクタ呼び出しで見れば non-blocking化されてる。

Cross-module inlining and specialization https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040061.html

12:51 AM

stdlib なみの最適化がサードパーティモジュールでも可能になる

4

おおおおお

12:58 AM

プロポザルの形だ読むぞ！！

これは良さそう

1:02 AM

でもライブラリのコードが@inlinableだらけになりそう

読んだ

1:26 AM

どうでもいいけどinlineableじゃなくてinlinableなんだな

Strideableがどんどん気になる

こっちは辞書にのってますしねぇ

inlinableにしない場合のメリットは、ソースが秘匿できる、おそらくコンパイルが早くなる、privateメソッドが呼び出せる

1:27 AM

inlinableなpublicメソッドの内部では、privateなメソッドが呼び出せないし、ローカルな型が定義できないとのこと

1:30 AM

あとライブラリが変更されたときにユーザ側のリビルドをしないと古いコードを取り込んだままになる、とかもあるね

inlinableなprivateメソッド（そんなもの作れるのか知らないけど）も呼び出せないの？

作れないです

1:30 AM

inlinableはpublicにしか付けられないって書いてある

うーん、それ結構イマイチだなぁ。

もしできるなら理屈としてはできますね。

別に秘匿したいわけじゃないけど

1:31 AM

APIとしては公開しても意味がないので公開したくないってありそう

ライブラリとしては提供したくないあまり保守性の高くないメソッド

うん

ドキュメントプライベート的な小道具

1:31 AM

そうですよね。

そうそう

internalならいいんですかね？内部はともかく外向きはあんまり問題にならないならいいんですが

わかる

1:31 AM

internalもだめ

ええ

ようするにコードが

1:32 AM

ユーザ側に展開される。

大体インライン化したいものってそういう小道具な気がするんだけどなぁ。

inlinable declarations can only reference other public declarations. This is because they can be emitted into the client binary, and are therefore limited to referencing symbols that the client binary can reference.

1:32 AM

can only reference other public.

1:32 AM

そこらへんの話題はブチこんでみたほうがいいかもしれんなあ

1:32 AM

スレに

あと、 @inlinable でないとインライン化は絶対されないの？

されないですね

1:33 AM

コードが出荷されない

あー、えっと

1:33 AM

一つのモジュールの中でも

1:33 AM

それはされるのか。

いや、モジュールの内部であれば

1:33 AM

internalやprivate

1:33 AM

全部からめて

1:33 AM

アグレッシブなインライン化は起きるって

1:33 AM

冒頭に書いてある。

1:33 AM

それはいままでもそう。

なるほど、モジュールをまたいだインライン化を制御するためのものなのか。

そうですね

今のところ自前で最適化を書いていくほうが実行効率は良いってことですかね

今のところ？とは？

うーん、それにしても EasyImagy みたいなのでオープンソースだし秘匿したいものは何もないけど、冗長なコードを排除するために internal な小道具をいっぱい作ってるケースでは微妙そうだ・・・

今後これが改善されるとして

@koher 現状できる方法だと @avaiable　を駆使してpublicだけど使わせないようにするとか。

そんなことできるっけ？

それ内部でも警告出ません？

@hiragram がよくやってる

なるほど

それ内部でも警告出ません？

出そうｗ

よばれた

そこなんとかならんかな。

1:37 AM

@hiragram publicだけど使わせないようにする@availableの技って自分で使うところも警告出ちゃう？

わしがしってるのはアクセスレベル関係なく

1:37 AM

警告出したければdeprecatedでエラーにしたければobsoletedにしている

Private @inlinable functions are useful. For example, you might want a helper function to be inlined into a public @inlinable function for performance, but you don't want that helper function to be called by outside clients directly.

ないぶでもでる

スレにその話題投げてる人おるな

1:38 AM

内部でも出ちゃうか、じゃあ、この場合はダメだなあ

1:38 AM

deprecatedじゃなくてobsolatedってのもあるんだ。

それぞれ非推奨と廃止だね

廃止なら消せよって気もする

unavailableもあるけどそれはだいぶ大雑把に使用不能にする感じで、deprecatedとobsoletedはバージョン指定してそれ以降のバージョンで警告やエラーになる

あーなるほど

1:40 AM

たとえばiOS SDKのiOS11では存在しない関数をつかっていても、obsoletedしておけばコンパイルできるのかな？

特にルールは決めてないけど広く使われてるAPI変えるときはまずdeprecatedつけて、移行先が用意できたらobsoletedにして、ある程度経過したら消す

1:41 AM

あ、バージョンっていうのはアプリやフレームワーク自体のバージョンね

1:41 AM

Swift側からUIKitとかのヘッダみるとたまに@availableついてるきがする

あ、なるほど

That’s what @_versioned is currently for. You can define a function as @_versioned @_inlineable and reference it from other public inlinable functions, without making it visible to AST-level lookup.

(edited)

1:50 AM

うーん、 @_versioned @_inlineable をつければそれはできるけど @_versioned 周りは将来別のプロポザルとしてやりたい

1:50 AM

みたいな流れになっているけどよく意味がわからん

廃止で消しちゃうと、代わりにこのメソッド使えみたいな案内出せなくなるからね

obsoleted はそうか

1:53 AM

あ、versionedの話は、private なメソッドを呼び出す話です

これとは別に、availabilityにアクセス修飾子つけたいみたいな話を @rintaro がしてなかったっけ？

1:55 AM

現状は中だけで使えて外側には使わせないみたいなのは無理だと思う

[swift-evolution] [Generics] [Pitch] Dependent Types

このスレも気になるな

Re-pitch: remove(where:)

これも気になってる

1:57 AM

airspeedswift/swift-evolution

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

え、それって気になるやつなんですか

1:58 AM

何をそんなに話してるんだろうと思ってた

1:58 AM

extensionでよくつくってるけどstdlib側につけてくれってだけの話ではない？

filterのinout版ですよねこれ

1:58 AM

inout reduceがあるのでその中で使う需要がある

inout もそうだし

1:59 AM

filter と判定基準が逆だから

あ、逆だ、確かに

どう折り合いをつけていくのかを話してる感じ (edited)

ふむふむ

このまえの update の話にも通ずる (edited)

2:01 AM

というか、このスレを見かけて思い出してこの前書いた。

2:02 AM

Swift が値型中心である以上 inout は重要なキーになると思ってて、これまで標準ライブラリに reduce(into:_:) がなかったことからもその可能性が見過ごされてたんじゃないかなぁ。

2:02 AM

inout な高階関数なんか考えたことなかったし。

2:03 AM

（見過ごされてたというか、できなかったのもあるけど）

—> MI<2>: {0, 1}, where 1 + 1 = 0. —> MI<3>: {0, 1, 2}, where 1 + 1 = 2, and 2 • 2 = 1 —> ... and so on.

2:04 AM

DependentTypeってGenericsのところに値を入れられる概念のことかな

2:05 AM

don’t we need something like this for Fixed Size Arrays™ too?

FixedArray<3> とかも言及されてる

C++み

2:06 AM

欲しい場面は結構ある

だから @taketo1024 さんがiOSDCでも Depdendency Type が欲しいって言ってたのかな。

2:06 AM

「ある多項式で除算した体の空間」みたいなアレが型にできるんか

行列とか、これ有るのと無いのとでは世界が違う

2:06 AM

それ出来るね

2:07 AM

今はなんか、次数を限定して、struct _1, _2, _3...と作ってextension大量に生やして誤魔化せば、それっぽい物が作れるなぁ、ぐらい

そのアプローチだと加算とかは作れるけど、 == とかが作れなそう

2:11 AM

Equal<_1, _1> == _1 Equal<_2, _2> == _1 Equal<_1, _0> == _0 (edited)

2:11 AM

こういうことができないと型で構成した数の中で繰り返し計算とかができないから

2:11 AM

掛け算の結果とか除算の結果とかひたすら無限に全部の組み合わせを定義することに

2:12 AM

ん、足し算すら無理か？

そうそう、無限に定義しなきゃいけないよ

eventually we will have something like the current @_versioned attribute, where internal (or even private, as some have suggested) functions can be “public ABI”. For example, @_versioned func myInternalDetails() { // … } @inlinable public func myPublicFunction() { myInternalDetails() // I can reference this from an inlinable function, but users can’t call it directly }

7:44 AM

やっぱり現状の@_versionedをつけた関数はインライン可能関数の中から呼べるらしい

7:44 AM

publicになったわけではないから直接は呼べない

versionedについての記述見つからず。。インライン可するときのバージョンを記録しておいて、ライブラリが更新されたときに、リンクしてるそれが変更されたことを検知できるようにするとか、そういう意味でこの名前かな

let data = (0..<2*3).map { UInt8($0) } let a = data.map { $0 + 1 } let b: [UInt8] = data.map { $0 + 1 }

/swift-execution/Sources/main.swift:3:32: warning: '+' is deprecated: Please use explicit type conversions or Strideable methods for mixed-type arithmetics. let b: [UInt8] = data.map { $0 + 1 } ^

Strideableの+(UInt8, Int)との絡みだと思いますがなぜbだけ警告されるんでしょう？

警告出なかった・・・

あれ？

swiftc で。

7:02 AM

$ swift --version Apple Swift version 4.0 (swiftlang-900.0.63.10 clang-900.0.36) Target: x86_64-apple-macosx10.9

swift sandboxでSwift4では出てます。 Xcode9でももちろん出ててます

7:03 AM

たしかにswiftcだと出ないですねぇ

謎だね

playgroundsでも出ないですけどこれはもともとそういうもんなんでしたっけ？

REPLとかPlaygroundsは色々違いそう

Swift 3.1.1だと再現する。Swift 4.0だと再現しない。

Protocol oriented Integer入ったら再現しなくなる?

あーxcodeのほう3.2に設定されてました。

ひどいｗ

swift sandboxのほうはなんだろう？

https://swift.sandbox.bluemix.net/#/repl

IBM Swift Sandbox

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

7:58 AM

これ？

7:58 AM

Swift Ver. 3.1.1 (Release)

4.0選べますよ

たしかに4でも出る

sandboxとXcodeのSwift4がバージョン違うのでは…

単純にそれですかね

もしかしてLinuxだと出るとか？

8:02 AM

出なかった

8:02 AM

$ swift --version Swift version 4.0 (swift-4.0-RELEASE) Target: x86_64-unknown-linux-gnu

8:02 AM

$ swift --version Swift version 4.0 (swift-4.0-RELEASE) Target: x86_64-unknown-linux-gnu

8:03 AM

Sandboxなんでリリース版じゃないんだ・・・ Swift Dev. 4.0 (Sep 5, 2017)

8:03 AM

IBMやる気なくなってきたのかな・・・

ンゴw

8:03 AM

キトラで天下取れないと踏んだんですかね

1

Latest 選択すると 3.1.1 になるし

releaseまでに修正されたんですねぇ

わずかな間だね、Sep 5だと。

IBMSwift、4系の選択がなかなか増えなくて最近不便。

普通にBluemixをアップデートするのが大変で止まってるだけかも

8:07 AM

Google App Engine とかずっと Java 7 / Python 2 系で止まってたし

Java7やPy2のノリでSwift3が延命しないでｗ

Appleは容赦なく切り捨てるけど、IBMはAppleじゃないからｗ

8:09 AM

Apple界隈、開発者がよく訓練されてて、みんなすぐに最新に追従するのすごいと思う。

古いバージョン使ってると文字通り人権無くなりますからね

ｗ

RxSwift4もSwift3.x丸ごとバッサリ切ってて笑う

まさに今日僕のライブラリもSwift3切ってたらクレームがｗ

8:11 AM

おっと、そろそろ Mobile Act に出かけないと。↓で Swift と Kotlin について話してきます。 https://mobileact.connpass.com/event/65935/

Mobile Act OSAKA #1 (2017/10/04 18:55〜)

# 開催概要 Mobile Act OSAKA はフェンリル大阪メンバーが開催するモバイルアプリ開発勉強会です。「関西でモバイルアプリ開発関連の情報共有や交流の機会をもっと増やしたい」という思いから、勉強会を開催させていただくこととなりました。フェンリルでは、1年ほど前から名古屋メンバーによって Mobile Act NAGOYA を開催してきました。今回の大阪での勉強会開催にあたり、同じ Mobile Act の名を冠して実施したいと思います。 Mobile Act OSAKA は今後も継続的に開催していく予定です。今回はその第1回となります。 # 発表者募集 5分間の...

1

旧バージョン使ってな^^と返しましょう

あーxcodeのほう3.2に設定されてました。 Swift 4.0のREPLに-swift-version 3をつけても再現しなかった。

REPLはwarningが違うことがあるような気がしてますがそんなことないですっけ？

8:13 AM

たとえば（当然ですが）↓だとwarning出ないですし。

Welcome to Apple Swift version 4.0 (swiftlang-900.0.63.10 clang-900.0.36). Type :help for assistance. 1> let a = 42 a: Int = 42

Swift 3.1.1だとエラーになります。

$ docker run --privileged -it --rm norionomura/swift:311 swift -I /usr/lib/swift/clang/include Welcome to Swift version 3.1.1 (swift-3.1.1-RELEASE). Type :help for assistance. 1> let data = (0..<2*3).map { UInt8($0) } 2. let a = data.map { $0 + 1 } 3. let b: [UInt8] = data.map { $0 + 1 } error: repl.swift:3:32: error: ambiguous use of operator '+' let b: [UInt8] = data.map { $0 + 1 } ^

(edited)

swift sandboxでもそれは確認してました。 swift3.2もリリース前に同時に修正されたんじゃないでしょうか

元はwarningなので、正確には再現できていないですね。

ん？でも修正されてるならxcodeで出てるのがおかしいのか

warningメッセージはSwift 4.0のSwift 3互換モードで追加されてるぽいですね。 https://github.com/apple/swift/commit/8de33b4824458fa341a2e1e30f5f0ce176205b70#diff-2d29b0c9185b7446d0812f8c3b400dbcR84 (edited)

Overloads for +/- on Strideable for Swift 3 compatibility mode · apple/swift@8de33b4

~~IBM Swift SandboxのDev. 4.0 (Sep 5, 2017)の挙動は、swift-4.0-DEVELOPMENT-SNAPSHOT-2017-09-05-a付近の挙動とも違う。~~ (edited)

8:41 AM

あいや、あってるか。

8:45 AM

-swift-version 3つけてもREPLだと出ない。-swift-version 3つけててソースをファイルから読み込んだ時だけwarningが出る。macOS, Linux共に。

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040061.html

1:13 AM

モジュール跨ぎインライン化のスレが伸びてる

1:14 AM

ラトナが @inlinable じゃなくて @fragile にしようって言ってて

1:15 AM

@fragile は struct の方のスレでも出てきてて、キーワード増やさないほうがいいし、って言ってるんだけど

1:16 AM

全然違う話に見えるし同じキーワードになる意味がようわからん

1:17 AM

あと @_versioned が付くと private でも見えるようになるらしいんだけど

1:17 AM

このままだとライブラリ作者が @inliable と @_versioned を付けまくる未来になりそうで

1:17 AM

むしろその２つデフォルトでいいんじゃないかと思うんだけどそういう話題は無し

それデフォだと何か問題あるんですかね？ビルド時間？

コンパイル時間が増えるのとバイナリサイズが増えるのがあるはず

1:19 AM

でも @inlinable は「必ずインライン化しろ」って意味でも無いんだよなあ

1:19 AM

@inlinable な関数自体はユーザモジュールごとにコンパイルされて実体を持つけどそれが更に呼び出しユーザのところにインライン展開されるかどうかはその先のコンパイラの判断っぽいような。

バイナリサイズはそんなに増えるんですかね？手動スペシャライズするよりはましに思えますが

1:20 AM

ユーザー側の話かな

そもそも手動スペシャライズは用意した型にしかできないでしょ

そうですね

Obsevable<Int> とかみたいに

1:20 AM

ジェネリクスが絡むと型の種類数は無限にあるから

1:21 AM

ユーザ定義型ももちろんだけど

デフォルト @inlinable でいいと思うけどなぁ。

お

1:24 AM

@inlinable @_versioned がデフォルトでついててよくてソースを見せないための @hiddenSource みたいな指定があったらいいような気がする

まあオープンソースじゃなかったらその @hiddenSource を付けまくることになるか？

まとめて指定する方法は欲しそうですよね

1:25 AM

コンパイラオプションでモジュールレベルでやるとか。

1:25 AM

それだとちょっとしたミスでソースが流出しそうで微妙かな・・・

1:30 AM

C++のビルドが遅いのは具象化されるからなのか、それともテンプレート展開のSFINAEテクニックでの分岐が多すぎるからなのか

1:30 AM

後者が重い気がしてて前者は本質じゃないと思ってて、それならビルドはいけそうだよなあ

うーん、モジュールまたぐときだけの話だからデフォルトじゃなくていい気がしてきた。

結構言及されちゃってるけど @_versioned は次スレでって事になってるし

1:36 AM

@_versioned のほうのデフォルト化の話はするとしたらそのときか

extensionの中のprivateって実質 file private なんですね

2:32 AM

extension Cat { private func f() -> Int { return 333 } func bb() -> Int { return f() } } extension Cat { private func f() -> Int { return 555 } func cc() -> Int { return f() } }

2:32 AM

↑これワンファイルだとf() が衝突してコンパイルできないけど、それぞれ別ファイルにすると動く

それは確か、privateのスコープ変更するよ〜〜って奴では

これもその話？

extensionのprivateはCatの外からは触れないと思うよ

その同じファイルに定義した別の型からは見えないんじゃない？

あ〜

たるのんが言ったのと同じ

fileprivateなら同じファイルの中からなら見えるはずだからってことか

fileprivateならみえる

じゃあfileprivateではないけど

2:34 AM

ファイルをわけないとだめってことは、型の中でfileprivate的な感じ？

2:35 AM

いや、ちがうのか privateはつねにファイルの中からしか見えない・・・？

privateは同一スコープ+同じファイルにある同じ型から見えると思ってるけどちがうかな

いまためしたけどそうっぽい

2:37 AM

クラス本体のprivateは別ファイルのextensionから見えない

2:37 AM

同じファイルのextensionは

2:37 AM

あーいける

2:37 AM

なるほど

本当にextensionの中だけで使うprivateにしたければファイル分けろって感じかね

privateの定義が「同ファイルの同型のスコープ内」に掛かってる。swift4から

さっきのinlinableスレで言及されてるんだけど

2:38 AM

privateなメソッドはファイル名を含むシンボルにコンパイルされてるんだとさ

Private access restricts the use of an entity to the enclosing declaration, and to extensions of that declaration that are in the same file.

2:39 AM

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID3

なるほどねえ

_TA2HelloFprivateMethod ファイル名含むシンボルってこげな奴でしょ、見る見る

任意のenumがあるときに、特定のケースのassociatedvalueを取り出したい enum Some { case foo(Foo) case bars([Bar]) case piyoOrNil(Piyo?) } func getBars(from: Some) -> [Bar]? { /* ??? */ } このOptionalへの変換、サクッとする方法ないですよね、

if case .bars(let x) = from { return x } else { return nil } switch x { case .bars(let x): return x; default: return nil }

↑しかない。

無いから Someにextensionで bars: [Bar]? を生やすかな

だよなー

5:58 AM

gybの出番か

手で書いたほうが早そう

いや、この手のenumを無数に作る事を考えていて

switch - case - default だし。

5:59 AM

無数ｗ

毎回やるのは苦痛すぎる

Unionタイプが欲しかった系の感じがする

enum-convertibleでもいいかな

6:00 AM

でもfoo.case0とかで生えててもあんま嬉しくないなぁ

6:01 AM

可読性ゴミだ

ああ

6:01 AM

gybのいいところはそういうところでシンボル名生成できるところだよな

6:01 AM

ジェネリックなライブラリでやろうとしても hoge0 hoge1 ... って用意しておくしかない

gybじゃないなぁ

6:02 AM

なんかソースコード中にあるその目的のEnumを抽出して勝手にExtension生成してほしい

6:02 AM

静的解析+コード生成か

Sourceryとかのほうが相性良さそう

1

良いものないすかね

6:03 AM

いけそう

本質的にやりたいのは、モナドの中のenumに対して外側でswitchが使いたいという欲求だった

enum MyEnum { case case1 case case2 case case3 } let e = Optional<MyEnum>.some(.case1) switch e { case .some(.case1): print("case1") case .some(.case2): print("case2") case .some(.case3): print("case3") case .none: print("none") }

6:34 AM

こう？

Optionalはそれが出来る

6:34 AM

ArrayとかObservableでは出来ない

実装がenumになってるモナドならできるね

つまりー

だいたいは .map { switch ... } とか .flatMap { switch ... }

6:35 AM

だよね

そうそう

6:35 AM

でもそれすると、switchの網羅性が消滅するので

6:35 AM

外側でやりたいという欲求があった

6:35 AM

さっきのOptional変換は、flatMapにOptional食わせればいいやというワークアラウンドなのだけど、そこ楽になっても網羅性保証出来ない

ん？ stream.map { switch $0 { } } は $0はMyEnum　なら網羅性は残ってない？

ほしいのはそれぞれのassociatedvalueの型のモナドなので

あーなんとなくわかった

let c0s = stream.flatMap { $0.case0 // Case0? } let c1s = stream.flatMap { $0.case1 // Case1? } ... 多分こうなる

enum Value { case .int(Int) case .str(String) } で、 Array<Value> から Array<Int> になったり Array<String> になったりしたい？

そう

6:38 AM

Array<Int>とArray<String>、それぞれの処理を書いてないとコンパイルエラー

extension で Value に .intValue を生やしてやれば、その実装をするときには網羅性が効いてうまくいく？ (edited)

いや

6:39 AM

駄目だと思う

6:39 AM

Array<Value>自体がEnumっぽく振る舞えばいけそう

あーーー

えーっと本質的にはなんだ

その続きを分岐して書きたいのか

Enumの外と内を分解して入れ替えたい

Intの場合だけ続きを書きたいんじゃなくて。

Array<Either<A, B, C>> -> Either<Array<A>, Array, Array<C>>

6:40 AM

こうだ

なるほど

これやりたいならenum-convertibleが一番良い気がしてきた

そう考えるとenumをswitch-caseで分岐してるときって

6:41 AM

その分岐コンテキストをモナドとして値に保持できないから

6:41 AM

try-catchにResultが無いのと同じように

6:42 AM

switch-caseにも対応するモナドが無いんだな

6:42 AM

だから外側と内側を入れ替えたデータ構造を簡易に構成できない（その場でswitch-caseのフローを書き下すまでしかできない）

やりたいことが見えてきてしんどくなってきた(´・ω・`)

このEither<Array<A>, Array, Array<C>> を case0 みたいな味気ない名前じゃなくやりたいねえ

extension Observable where E: EnumConvertibleX { func sequence() -> EnumX<Observable<E.Case0>, Observable<E.Case1>, ....> }

こうか~~~

6:45 AM

これがあると

6:46 AM

es.bind { (es) -> Disposable in switch es.sequence() { case .case0(let c0s): return c0s.subscribe(c0sTarget) case .case1(let c1s): return c1s.subscribe(c1sTarget) case .case2(let c2s): return c2s.subscribe(c2sTarget) ... } } .disposed(by: db)

こんな感じになるかな (edited)

6:48 AM

RxSwiftのbindがネストできたの忘れてた

6:50 AM

Sourceyで自動生成しようとすると、MyEnumに対してMyEnumArrayとかMyEnumObservableみたいなのを生成することになる

6:50 AM

それはそれで良いのかもしれない

6:51 AM

ん…?なんかおかしい気がしてきた

6:51 AM

ArrayもObservableも中身を配分するんだからswitchじゃねーな

2つのprotocolを同時に実装するときに、両方のassociatedtypeの名前がかぶってると、それぞれを違う型で埋めることって一切出来なくなりますよね

5:04 PM

protocol A { associatedtype X func fa(_ x: X) } protocol B { associatedtype X func fb(_ x: X) } class C: A, B { // できない func fa(_ x: Int) { } func fb(_ x: String) { } }

できないですね。

typeerasure作ってAConvertibleとBConvertible作るしか無いか…

https://gist.github.com/omochi/a6dde71489ab118727eeed8c717d2c90

swift-type-erasure-pattern.swift

7:19 AM

AnyHogehogeパターンでジェネリックメソッドの部分ってどうすればいいんだろ？

7:20 AM

↑のソースでいう _cast のところがうまく書けない

7:25 AM

/Users/omochi/temp/swany/Sources/swany/main.swift:31:15: Cannot invoke 'cast' with an argument list of type '(to: (Any.Type))' /Users/omochi/temp/swany/Sources/swany/main.swift:31:15: Expected an argument list of type '(to: T.Type)'

あー

7:28 AM

これ面倒くさそう

何か見落としてる凡ミス？それともこの川・・・深いっ？

かわいそうだけど

7:29 AM

型パラを持つクロージャは作れない。の制約があって

まあ、それはそうだよね　変数に保持する時点で<T>が露出しちゃうし

このままだと駄目なので

<T>が決まるのは呼び出しのたびだし

ちょっとしたワークアラウンドがあったはず

7:29 AM

あれ、できるか?

https://gist.github.com/koher/fdddb76694ea9e7cc270e9710b4b0ef3/revisions

https://gist.github.com/omochi/a6dde71489ab118727eeed8c717d2c90

GitHub is where people build software. More than 24 million people use GitHub to discover, fork, and contribute to over 68 million projects.

7:37 AM

String.Type nil

7:38 AM

Any.Type じゃなくて String.Type ってでるのは existential だから？？

実行時に型パラ渡す方法が無いから無理っぽい

7:40 AM

ええーっと

7:40 AM

これあれだ

7:40 AM

GenericsパラメータにProtoocl.self入れられない問題でハマる

7:40 AM

Anyがprotocolだから無理

でもこれやりたいんだよね

7:44 AM

クラスや継承でやっているパターンを

7:44 AM

structとprotocolとTypeErasureでやろうとしたときに

7:45 AM

as! でのダウンキャストに相当する部分が残ってしまって

7:45 AM

それがこの func cast<T>() なんだよね

cast式をProtocol内部に書かなきゃいけない理由は?

Any で保持して as? でキャストするアプローチだと

//global func cast<T: CatProtocol, U: CatProtocol>(from: T, to: U.Type=U.self) -> U?

7:53 AM

こう

AnyCat が AnyCat を包んでいる場合とかで穴があく

AnyCatのcastを種から生成したい、か

swift-type-erasure-pattern.swift

7:56 AM

castメソッドだけ existential が使えるprotocol に切り分けたら一応いけた

7:57 AM

でもこれだとあれだね、「ジェネリックかつ (associatedtype または Self) が絡む func」には対応できない (edited)

associatedtype が無いなら、素直に内包すれば良いと思うんだけど、そういう話ではない？ (edited)

7:58 AM

https://gist.github.com/rintaro/f90726a51e8371807667a5fc7ebdab07

cat.swift

private var base: CatProtocol ↑これできます？ clone() -> Self があるけど

assoctype持つ場合は無理、が解決できないのが厳しい

あれ、いけるな

8:00 AM

Selfはあってもいいのか。

AnyCat1(base.clone()) が必要だけど。

素直に内包すれば良い

var base 方式とクロージャ方式の特性について調べていたので

8:02 AM

これはこれでそれだけの話かもしれません

8:02 AM

Selfが絡むとvarにできないと思ってたけどできますね。associatedtypeがある場合が問題か。

8:03 AM

Selfが絡むとダメだった記憶あるけどなんだったっけ・・・

Equatable?

protocol Eq { func eq(_ x: Self) -> Bool } func f(_ a: Eq, b: Eq) -> Bool { return a.eq(b) } /Users/omochi/work/playground/TempGround.playground:5:13: Protocol 'Eq' can only be used as a generic constraint because it has Self or associated type requirements

8:04 AM

本当だ。

8:05 AM

protocol Eq { func eq1() -> Self func eq2(_ x: Self) } func f(_ a: Eq) { }

8:05 AM

eq1はあってもOK、eq2があるとダメ

サブクラス方式なら associatedtype の問題は解決できるかな？

https://gist.github.com/omochi/a6dde71489ab118727eeed8c717d2c90

swift-type-erasure-pattern.swift

8:10 AM

associatedtype つけてみました。 CastProtocol 方式ならまだいける

CastProtocol側がassoctypeで汚染されないおかげで変数として確保出来るから

これでまだ解決しないパターンは、 func cast みたいなジェネリックメソッドそれ自体が associated type の絡んだシグネチャを持つことか

ところで castはデフォルト引数あったほうが <T>(_ type: T.Type=T.self) -> T? (edited)

8:13 AM

左右どちらからも型推論出来るようになってお得です

ああ、たしかに。出たその技

お得だけど、protocolの宣言でデフォルト引数書けないのがつらいですね

8:14 AM

かきたい

func difficult<T>(to: T.Type, food: Food, me: Self) -> Self

8:17 AM

追加した。どうすんだこれ。

func difficult1<T>(to: T.Type, food: Food)

8:31 AM

これだけで無理みがある

https://gist.github.com/rintaro/c240100472967973de3f42e16080dfa1 とりあえず通った。

cat.swift

すげえ

とっくに諦めてたのにすごい執念だ・・・

あれえ・・・シンプルすぎて何がどうなってるのかわからん・・・

8:52 AM

いったんclassでBox作ったのがポイントか・・・？

assoctypeをGenerics型に閉じ込めたところですかね

AnyCatBox<Base: CatProtocol> ここか・・・

8:57 AM

これってAnyCatBaseとAnyCatBoxの2つ必要なんです？

8:57 AM

いま自分でもいじってるけど

必要、Generics型にAssoctypeを閉じ込めるという必要がある

あーFoodが焼いてあるのか

そこを書き換えるのにoverrideもいる

8:58 AM

これ似たようなことstdlibでもやってるんですか?

AnySequence とかはこの方式ですね。

これマスターしないとSwift書けねえな

1

Sequenceのmapどうやってんだって考えてて、じゃあ中身はClassとか詰まってるんですね

ちょっと実行速度遅いですけど。

純粋値型Swiftの実態は涙ぐましいclassを使ったworkaroundですっていうのが現代御伽噺

あーなるほど・・・

9:04 AM

var _box: AnyCatBase<Food> の時点では捕まえるCatProtocolの真の型がわからないからこれが必要で

9:05 AM

initで<Base> が来て初めてそこでサブクラスのジェネリクスのとこに焼きつつ代入して保持するのか

パターンは覚えたので次から使えるぞ、やったぜ

まだ咀嚼できてない

@tarunon

純粋値型Swiftの実態

純粋値型Swiftはexistentialもtype erasureも許さないので問題なしです

むしろ、こういうややこしい問題をなくしたいから使いたくないって感じですね。

わかってきた

1. Protocolにあるassociatedtypeを全部型パラに詰めたClass(A)にassociatedtypeが関わる関数を全て実装、中身は空でOK 2. Protocolを型パラに取るAのサブクラスBを実装、プロパティに型パラのProtocol、Aの型パラと全部結びつけてすべての関数をOverride 3. TypeErasureにAのプロパティを置いてBを代入しその関数を呼ぶ。 (edited)

サブクラスに隠すところがコツだな〜

9:12 AM

ですねですね

9:16 AM

いやこれいいな、なんでも var base の形で保持できるわけだし

ちょっとabstract class実装しないのん…ってなるけど、Generics manifestが完成したらabstract classは無用の長物になるのかしら

struct + protocolでいけるから？

そう

たしかに・・・？

9:26 AM

AnySequence読んで復習する https://github.com/apple/swift/blob/24821ccb08832e5d6ef5d21d6730b51f93d9d210/stdlib/public/core/ExistentialCollection.swift.gyb#L751

swift - The Swift Programming Language

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials これさえあれば型消しいらなくなるし、classもそこまで重要なものでもなくなると思っていて

https://github.com/apple/swift/blob/24821ccb08832e5d6ef5d21d6730b51f93d9d210/stdlib/public/core/ExistentialCollection.swift.gyb#L781-L891

swift - The Swift Programming Language

9:27 AM

少なくともどうしてもabstract classじゃないと駄目なんだ!っていうのはほぼ無くなると思う

% for Kind in ['Sequence', 'Collection', 'BidirectionalCollection', 'RandomAccessCollection']: extension Any${Kind} {

9:28 AM

めちゃくちゃ無理やりでワロタ

めちゃくちゃしやがる

検索しづらいからこう書いて欲しいンゴね

% for Kind in ['AnySequence', 'AnyCollection', 'AnyBidirectionalCollection', 'AnyRandomAccessCollection']: extension ${Kind} {

Kindってそこ以外で使われてないの?

swift - The Swift Programming Language

9:29 AM

この20行の範囲に Any${Kind} がたくさんでてくる

9:30 AM

かならず Any${Kind} の形で出てきてるように見えるね。

Swift側でKindだけほしいケースがないので

9:30 AM

PRチャンスでは?

これの修正？ｗ

検索ビリティが低いぞって言って暴れる

9:30 AM

いやーやらないな

う、うーんｗ　まあ益はあるのか・・・？

class _AnySequenceBox<Element> { internal func _makeIterator() -> AnyIterator<Element> { _abstract() } } final class _SequenceBox<S> : _AnySequenceBox<S.Iterator.Element> { internal override func _makeIterator() -> AnyIterator<Element> { return AnyIterator(_base.makeIterator()) } } struct AnySequence<Element> : Sequence { public init<S : Sequence>(_ base: S) where S.Element == Element { self._box = _SequenceBox(_base: base) } internal let _box: _AnySequenceBox<Element> }

9:51 AM

さっきの @rintaro さんのパターンと同じ構造なのを確認した。

9:51 AM

学びがあった・・・

9:52 AM

おまけ

internal func _abstract( file: StaticString = #file, line: UInt = #line ) -> Never { fatalError("Method must be overridden", file: file, line: line) }

便利

KeyedEncodingContainer, KeyedDecodingContainerとかも同じ仕組み。 https://github.com/apple/swift/blob/master/stdlib/public/core/Codable.swift#L422

https://qiita.com/taketo1024/items/733e0ecf12da359db729

swift - The Swift Programming Language

本当だ。こいつはAny的な名前じゃないんですね。そしてプロトコルの方にはProtocolサフィックスがついてる。

UnkeyedEncodingContainer, UnkeyedDecodingContainerと名前に一貫性を持たせるためですね。

Standard LibraryがRecursive Protocol Constraintsを使った実装になって最初のスナップショット swift-DEVELOPMENT-SNAPSHOT-2017-10-06-a が出てる。

Swift 4 の Numeric で EasyImagy の自作 NumericType から解放されると思ったら ExpressibleByIntegerLiteral 付いてて使えない・・・

3:36 AM

ほしいのはもっとシンプルに「群・環・体」みたいなプロトコルなんだけどなぁ。

3:36 AM

Swiftで代数学入門〜 2. 群・環・体の定義 - Qiita

どうも、佐野です。前回の記事で整数は「環」、有理数・実数・複素数は「体」であるという話をしました。今回は「群・環・体...

それがついてるとなんでダメなんですか？

たとえば RGBA に対して Numeric を適用する場合、整数リテラルから生成できるようにしないといけなくなる・・・

RGBA型を、ですか？

今　+ が定義されていることを保証したいだけなので Numeric が過剰すぎる・・・

3:38 AM

うん。 RGBA 同士の足し算ができるようにしたい。

なるほど、たしかにそれは変だ

https://developer.apple.com/documentation/swift/numeric

3:39 AM

Inherits From Equatable, ExpressibleByIntegerLiteral

0xFf000000から

3:39 AM

8bitずつRGBAを読み取る、とか、

3:39 AM

稀にあるけどw

RGBA<T> とかもあるし

どんどん無理になるな

↑は今回の話とは別にリテラル導入すると便利かどうかで検討したけど保留中で、 Numeric のために導入するのはあきらかに手順がおかしいｗ

3:41 AM

せっかく自作 UnboundedRange から解放されて次は Numeric だと思ったのに・・・

3:47 AM

Associated Types に Index がない・・・。型が _ プレフィックスとかかな？ https://developer.apple.com/documentation/swift/collection

3:48 AM

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

https://swift.org/blog/swift-4-1-release-process/

swift - The Swift Programming Language

3:48 AM

あれ？普通だ。なんでリファレンスから漏れたんだろう？

肝心のstartIndexがなくなあ？

3:49 AM

なくない？

3:49 AM

型もないけど

ほんとだ

3:50 AM

Swiftのリファレンス使い物にならないな・・・

基本役に立たないよねw

3:51 AM

ソース見る > Xcodeから飛ぶ > ドキュメント見る

メソッドの戻り値が一覧で省略されてるのとか、型パラメータが下までスクロールしないと出てこないのとか

Collection.Indexとか startIndex とかは swift-DEVELOPMENT-SNAPSHOT-2017-10-06-a でようやく Jump to Definition 先で見られる様になりました。

7:38 AM

それ以前は、Recursive Protocol Constraintsがなかったせいで非公開のプロトコルで定義されていました。

7:39 AM

ドキュメントはそれを元に生成されているらしく、それらは未記載。

そういうことなんですね

なるほど

/Let it be/ func() -> @discardable Bool {} /Rather Than/ @discardableResult func() -> Bool {}

このスレわろた

2:03 AM

func() -> @discardable Bool func getBool() → async Bool func foo() -> discardable Bool func x() -> Bool @ throws disguardableResult public async mutating public async mutating throwing func foo() -> discardable Bool

2:03 AM

一つ目のやつがスレの提案で、これも関数名の打ち忘れでカオスなんだけど

2:04 AM

便乗して他の人が他の話してて

2:04 AM

4番はひどい

asyncとthrowsは式の型で、他のアノテーションとか修飾子の類とは全然違うんじゃないの

うん、async Bool に関しては、型だけの問題じゃなくて関数全体に影響する話だからそりゃ違うよって突っ込まれてる

w

4番目のやつは

2:06 AM

なんか途中までの流れで、 @discardable が関数のほうに付くのはCっぽくてSwiftっぽくない

2:06 AM

って話に便乗して

2:06 AM

それでいうと名前の左側につけるもの全部右にすべき、みたいな。

2:07 AM

5番目のやつは4番目のやつに対して、もっと英語っぽくしようぜ、って言って書いてる・・・・

more Englishかな？ちょっとワロタ

make it more English :) (edited)

2:07 AM

って書いとるね。

var a: Int = 3 print(a) // 3 print(a is AnyObject) // true print(type(of: a) is AnyObject.Type) // false var b: AnyObject = a as AnyObject print(b) // 3

先週の型の互換性と is as の振る舞いが一致しない件、そういえばこんな例もある

4:01 AM

あとswiftにおける頻出がこれ var s: String = "" print(s is NSString) // true print(type(of: s) is NSString.Type) // false

グエー

10:53 AM

この辺のキャストを全部Lintで弾くしか

10:53 AM

[Cat]を[Animal]に入れたらmap使えみたいな警告出したい

10:54 AM

let x: Int? = 1 も警告、.some使えと出てくる。

as演算子がそのための明示的なオペレータなんじゃない？暗黙の変換と比べると。 as?と違って失敗しないわけだし

10:55 AM

.some()は暗黙だねw

as明示で型が書き換わるなら、それはもう暗黙の変換してはいけないというのが

10:56 AM

自論なわけで、これに基づくとOptional, Arrayの共変性なんかは特に。

10:56 AM

明示でのみ書き換わるのは正義

この間のヤバイキャストのバグ報告done https://bugs.swift.org/browse/SR-6126

ｗｗ

10:06 AM

let a = x as Int?? let b = (x as? Int??)! let c = Int?.none as Int?? let d = (Int?.none as? Int??)! let e = (y as [Int??]).first! let f = (y as? [Int??])!.first! let g = ([Int?.none] as [Int??]).first! let h = ([Int?.none] as? [Int??])!.first!

10:06 AM

これは笑う

網羅的にチェックしただけだよ

とりあえずこれで回答出れば何が設計仕様で何が謎挙動なのかわかるね

んだべな

ウォッチ設定しとこ

10:08 AM

投票ってのはなんだ

ところで僕が報告したIssue一個もクローズされなくて涙目なんだけど

10:08 AM

解決しろってプレッシャーかけるやつでは

結果は気になるしポチっとこ

efghの挙動見るに完全にバグなんだけど

10:09 AM

どっちを仕様として寄せるのか気になる

10:09 AM

Int? as Int?? が .noneになる世界なら俺はRustに移住するわ

お、↑にコメントが。 Jordan Rose added a comment - 11 hours ago cc Joe Groff

JordanRose氏、bugsに張り付いていて担当者を召喚してくれる人というイメッジがある

トリアージ担当なのかな

class Escaper { func take(_ f: @escaping () -> Void) {} } class Cat { var a: Optional<(() -> Void) -> Int> func f(escaper: Escaper) { a = { (handler: () -> Void) -> Int in escaper.take(handler) return 0 } } }

7:13 AM

Playground execution failed: error: TempGround.playground:4:26: error: passing non-escaping parameter 'handler' to function expecting an @escaping closure escaper.take(handler) ^ TempGround.playground:3:16: note: parameter 'handler' is implicitly non-escaping a = { (handler: () -> Void) -> Int in ^ @escaping

7:14 AM

プロパティで持ってる関数の型には @escaping がつけられないけど、それが、関数の引数になってる関数にも適用されるせいで、関数からうけた関数をescapeすることができない・・・？

class Escaper { func take(_ f: @escaping () -> Void) {} } class Cat { var a: Optional<(@escaping () -> Void) -> Int> func f(escaper: Escaper) { a = { (handler: @escaping () -> Void) -> Int in escaper.take(handler) return 0 } } }

(edited)

あれ、いけた

@omochimetaru

プロパティで持ってる関数の型には @escaping がつけられないけど

プロパティで持ってるクロージャは @escaping のはず。

7:21 AM

そうじゃないとおかしい。

そこまでやろうとしてうまくいかなかったけど別の問題にひっかかってたみたいでした。ありがとうございます。

↓シンプルな例（ lazy だから map は @escaping 必須） struct Foo { var bar: (Int) -> Int } let foo = Foo(bar: { $0 * $0 }) [2, 3, 5].lazy.map(foo.bar) // OK

あれ、新しいStringってIndexの型が混ざったの？

Viewとは別にString自体がIndex持ってるべ

typealias String.UTF8View.Index = String.Index typealias String.UTF16View.Index = String.Index

6:02 AM

ウオオ

6:02 AM

エンコード別のインデックスの型安全性はなくなってしまったのか

ん、これどうやってエンコード別のindexみわけるの

7:28 AM

あーエンコード毎にIndex受け取ったときの処理が違うのか

見分けられなくなったように見える。

7:29 AM

だから、String.Indexのコンストラクタで、第二引数で指定して、エンコード付きからString用に変換するんだけど

あくまでIndexはpositionからのdistanceというだけの存在で、それを受け取ったView(或いはStringProtocolの具体型自身)がどうにか解釈すると

7:29 AM

もしかして

7:30 AM

String.*ViewもStringProtocol?

init?(_ sourcePosition: String.Index, within target: String.UTF8View) https://developer.apple.com/documentation/swift/string.index/2922824-init (edited)

ンンンw

String.Index を扱うときに、それが、String 用なのか、 String.UTF8View 用なのか String.UTF16View 用なのか

7:31 AM

意識して扱わないといけなくて

7:31 AM

String.UTF8View 用の String.Index を String 用の String.Index に変換するのが↑のinit (edited)

ん？意識する必要ありますか？utf8の中途半端な位置のインデックスを String につかっても、それなりの値は返ってくるとおもいますが。

7:54 AM

let str = "こんにちは！" str[str.utf8.index(str.startIndex, offsetBy: 0)] // こ str[str.utf8.index(str.startIndex, offsetBy: 1)] //　こ str[str.utf8.index(str.startIndex, offsetBy: 2)] //　こ str[str.utf8.index(str.startIndex, offsetBy: 3)] //　ん

outofrangeとか?そこはoptionalになるから問題ないのか

out of rangeはすべてのViewで out of rangeになります。

str[str.utf8.index(str.startIndex, offsetBy: 2)] これは動くってだけで、意味のないコードだと思いますけど・・・

7:57 AM

いや、あれ、ん？？？

7:57 AM

2回誤変換してるのか。

str[str.utf8.index(str.startIndex, offsetBy: 2)] これを動くようにするのは議論の余地はあったんだと思うけど、0 と 3 がきちんと動くので、普通に使っている分には変換する必要がなくなったというだけだと思っています。 (edited)

内側の、 utf8.index(_, offsetBy:) には String.UTF8View.Index を渡すべきだけど、 typelias だから String.Index も渡せちゃっていて、外側の str[] には、 String.Index を渡すべきだけど、 typealias だから String.UTF8View.Index が渡せちゃっている

8:02 AM

3 がきちんと動く

これは、3バイト目へのアクセスとして使えてるってことですか？ Stringの内部メモリがUTF8で保持さていることって保証仕様なんでしょうか

いいえ、このインデックスが有効なのは、あくまで元の String が一緒の時だけです。

8:03 AM

Stringによって、バッファ上のバイト表現は違うので、 (edited)

8:06 AM

現在の String.Index はその String のバッファ上のバイトオフセット + α を持っている感じですね。

Stringの内部メモリがUTF8で保持さていることって保証仕様

仕様が決まってるかはわからないけど実装はUTF16だった気が。

いま確認していて一つ勘違いしていたのが、 utf8.index(_, offsetBy: 1) は、「1つ次のUTF8文字」に行くと思ってたけど、そうじゃなくて、1バイト進む、なんですね・・・

8:08 AM

let str = "こんにちは！" let u8str = str.utf8 u8str[u8str.index(u8str.startIndex, offsetBy: 0)] // 227 u8str[u8str.index(u8str.startIndex, offsetBy: 1)] // 129 u8str[u8str.index(u8str.startIndex, offsetBy: 2)] // 147 u8str[u8str.index(u8str.startIndex, offsetBy: 3)] // 227 u8str[u8str.index(u8str.startIndex, offsetBy: 4)] // 130 u8str[u8str.index(u8str.startIndex, offsetBy: 5)] // 147

＞　実装はUTF16だった気が ASCII で表現できるときは ASCII のときもあると思いますよ。

いいえ、このインデックスが有効なのは、あくまで元の String が一緒の時だけです。

なるほど。さっきのりんたろさんの例がどのように動作しているかはとりあえず理解できました。

8:11 AM

UTF8上でユニコードで1文字進んだ場所のバイトオフセットが知りたい場合は、unicodeScalarsのViewを経由してIndexを変換してくるべきなのか。

let str = "𩸽だいすき！" let idx = str.index(str.startIndex, offsetBy: 1) str.utf8.distance(from: str.startIndex, to: idx) // 4 str.utf16.distance(from: str.startIndex, to: idx) // 2 str.unicodeScalars.distance(from: str.startIndex, to: idx) // 1 str.distance(from: str.startIndex, to: idx)

8:13 AM

＞ unicodeScalarsのViewを経由してIndexを変換してくるべきなのか。変換という考え方を捨てて、View上でのIndexの位置を調べる、と考えると良いと思います。

let str = "こんにちは！" let u8Str = str.utf8 let ucStr = str.unicodeScalars // ユニコードスカラとしての2文字目の位置のUTF8表現のバイト値を求めるコード let ucIndex2: String.UnicodeScalarView.Index = ucStr.index(ucStr.startIndex, offsetBy: 2) let strIndex2: String.Index = String.Index(ucIndex2, within: ucStr)! let u8Index2: String.UTF8View.Index = strIndex2.samePosition(in: u8Str)! let u8ByteOffset2: Int = u8Str.distance(from: u8Str.startIndex, to: u8Index2) print(u8ByteOffset2) // 6 print(u8Str[u8Index2]) // 227 <- 答え // 確認 print(str[String.Index(u8Index2, within: u8Str)!]) // に

(edited)

8:17 AM

僕が「意識しないといけない」と思っているのは、この、 strIndex2, u8Index2 への代入文の右辺の within: と in: に、正しいものを入れないとちゃんと動かないからです

8:19 AM

あ〜

8:19 AM

変換という考え方を捨てて、View上でのIndexの位置を調べる、と考えると良いと思います。

8:21 AM

(String.Index と UTF8View.Index)、(String.IndexとUTF16View.Index)、それぞれの間での distance は正しく動く・・・？

8:23 AM

根っこのバイト表現上でのIndexになるから、 (UTF8View.IndexとUTF16View.Index) でも正しいってこと・・・？

上げてもらった例でいうと、

let strIndex2: String.Index = String.Index(ucIndex2, within: str)! let u8Index2: String.UTF8View.Index = strIndex2.samePosition(in: str)!

within: in: にどのViewいれても同じ結果になると思います。 (edited)

within: in: にどのViewいれても同じ結果になると思います。

ほ、ほんとだ・・・

8:28 AM

 public func samePosition( in utf8: String.UTF8View ) -> String.UTF8View.Index? { return String.UTF8View.Index(self, within: utf8) } public func samePosition( in utf16: String.UTF16View ) -> String.UTF16View.Index? { return String.UTF16View.Index(self, within: utf16) }

8:29 AM

oh...

samePosition(in:) とかは、

let str = "こんにちは！" let u8Str = str.utf8 let ucStr = str.unicodeScalars let idx1 = u8Str.index(str.startIndex, offsetBy: 1) let idx2 = idx1.samePosition(in: ucStr) // nil

こういうView間で完全に同一の位置の有無を調べるくらいしか用途ないんでないかな？

within: が何かはやってるのか

8:32 AM

 public init?( _ sourcePosition: String.Index, within target: String ) { guard target.unicodeScalars._isOnGraphemeClusterBoundary(sourcePosition) else { return nil } self = target.characters._index( atEncodedOffset: sourcePosition.encodedOffset) }

8:38 AM

let str = "こんにちは！" let u16Str = str.utf16 let u8Str = str.utf8 str[u16Str.index(u16Str.startIndex, offsetBy: 0)] let i1: String.Index = u16Str.index(u16Str.startIndex, offsetBy: 1) str[i1] // ん u8Str[u8Str.index(i1, offsetBy: 0)] u8Str[u8Str.index(i1, offsetBy: 1)] u8Str[u8Str.index(i1, offsetBy: 2)] let i2: String.Index = u8Str.index(i1, offsetBy: 3) print(str[i2]) // に

8:38 AM

なるほど・・・どうなってんだ・・・

str.utf16でsubscriptは使えないの

使えるけどUInt16だから→ u16Str[i1] // 12435

8:53 AM

u8Str[u8Str.index(i1, offsetBy: 0)] // 227

 internal init(encodedOffset o: Int, transcodedOffset: Int = 0, _ c: _Cache) { _compoundOffset = UInt64(o << _Self._strideBits | transcodedOffset) _cache = c }

9:03 AM

2bitシフトして、 (UTF16でのインデックス, 0...3) のタプルになっている

9:04 AM

現在のUnicodeが21bitでUTF8で4バイト文字までしか存在しないから

9:05 AM

UTF8での位置は、 UTF16でvalidな位置 + 0〜3のオフセット

9:05 AM

で、常に表現できるってことか？

9:06 AM

（ユニコードでの位置+UTF8ずらし分)的なデータ構造じゃないと辻褄が合わないと思ってて、こんなの出てきたからそうっぽいけど・・・

9:06 AM

extension String { /// A position of a character or code unit in a string. @_fixed_layout // FIXME(sil-serialize-all) public struct Index { @_versioned // FIXME(sil-serialize-all) internal var _compoundOffset : UInt64 @_versioned internal var _cache: _Cache internal typealias _UTF8Buffer = _ValidUTF8Buffer<UInt64> @_versioned internal enum _Cache { case utf16 case utf8(buffer: _UTF8Buffer) case character(stride: UInt16) case unicodeScalar(value: Unicode.Scalar) } } }

9:07 AM

String.Index型自体は内部に enum _Cache で、どの種類のビューのIndexなのかを保持しているから、適宜変換も可能と

Swift 4.1 Release Process

This post describes the goals, release process, and estimated schedule for Swift 4.1.

Conditional Conformance は 4.1 で入らないのかな？

1:03 AM

The vast majority of sources that built with the Swift 4.0 compiler (including those using the Swift 3 compatibility mode) should compile with the Swift 4.1 compiler.

ってことだけど、 Conditional Conformance が入ったら Countable 系の Range は不要になるので色々とソース互換性に影響が出そう。

後方互換で残すのはあるのでは？

Swift は後方互換よりも美しさ（？）を優先しているような印象があるけどなぁ。 (edited)

1:05 AM

typealias で残すとかはあり得る？

https://github.com/apple/swift/pull/11929

sema for conditional conformances. by huonw · Pull Request #11929 · apple/swift

Currently just removes restriction and adds some basic recording of conditionality, and feeds that information through to the GSB and constraint solver and anywhere else that needs it. This doesn't...

1:05 AM

作業は進んでるみたいですよ

でも、それでも Range と CountaleRange に extension で同じメソッド生やしてたら衝突するからソース互換性はないな。 (edited)

3.xでは大幅な切り捨てありましたっけ？ Range は基本 ..< ばっか使ってるので Countable がなくなっても困らない可能性はある

Semaは型推論とかのものが入ってるとこ

huonw changed the title from [WIP] sema for conditional conformances. to sema for conditional conformances. 7 days ago

オアズケか(´･_･`)

1:09 AM

assoctypeに自身を指定できる奴(SubSequenceのアレ)は流石に入るかな？

↑の PR 、 WIP がとれたということは近々取り込まれるかもしれない？

これが全てなのか関連作業が他にもあるのかはよくわかってない

sema だけじゃなくて標準ライブラリの作業とかもありそう。

たるのんのゆってるのはリカーシブプロトコルだっけ

1:10 AM

たしかに。

1:10 AM

過去のライブラリをめちゃめちゃ見直さないと。

Codable の Array や Optional 直したり、↑の Range のやつ直したり。

その差分は勉強になりそうだな

assoctypeに自身を指定できる奴(SubSequenceのアレ)は流石に入るかな？ masterには入ってるから、4.1には入りますね。

1:14 AM

October 18, 2017 (initial branching): The swift-4.1-branch will be initially cut from master. なので。

大きな機能はその initially cut from master 以降はマージされない方針ってことですか？

October 18, 2017 (initial branching): The swift-4.1-branch will be initially cut from master.
Approximately every two weeks, master will be merged into swift-4.1-branch until the final branch date.
November 27, 2017 (final branching): The swift-4.1-branch will have changes merged from master one last time. After the final branch date there will be a “bake” period in which only select, critical fixes will go into the release (via pull requests).

(edited)

1:20 AM

final branch dateまでにmasterへマージされれば入るかと(revertされなければ)

Approximately every two weeks, master will be merged into swift-4.1-branch until the final branch date.

なるほど。

Conditional Conformancesは流石に無理じゃないかな。

1

リカーシブなんとか、そう。それだけでも入るなら御の字かな

1:28 AM

そこら中に生えてたwhere句を駆逐できるから

Swift 5 で async/await と Conditional Conformance が入ったらめちゃくちゃ快適な言語になりそう。

まだHigherKindedType無いし変性はメチャクチャですよ

RustのGeneric Traitはうらやましい

1:33 AM

HigherKindedTypeも欲しいンゴね

SequenceとLazySequenceも根っこから分離したい、これはプロポーザル書くか

HigherKindedType は諦めてます。

1:33 AM

変性は正直あんま必要にならないんですよねぇ。

1:34 AM

そもそも値型の範囲だとサブタイピングがないし。

依存型とOwnership関係と外部モジュールspecializeが早く欲しい

怪しげな変性が無くなればそれはそれで良いんですよ、今は中途半端だ

型理論系はRustに足りて無くて、動作速度系はC++に足りてない。

1:35 AM

怪しげな変性問題ね・・・

Ownership と言えばちょっと思ったんですが、 Ownership あったら ARC じゃなくても GC でいいとかないですかね？

どういうこと？

1:36 AM

Ownershipを入れるのとGCを入れるのは真っ向から真逆のアプローチだと思う。

GC ダメって言ってたのって、システム言語の領域を目指すには GC のパフォーマンスは許容できないとかいう理由だったと思うけど

1:37 AM

本当にパフォーマンス必要なとこは Ownership で解決して

Ownershipの有無に関わらずGCあると世界は停止しそうですが

アプリレイヤーとかは GC とかできないかな？

D言語はGCの有無をスイッチできるようにしたけどライブラリの世界が2つに分断してつらそうってラトナーが言ってた

最近だと循環参照嵌まりがちなのは専らクロージャ周りなんで値のキャプチャ周りが賢く出来れば良さそうと言うのがあって (edited)

1:41 AM

極端な話 [* foo]みたいにして明示的にキャプチャしないとコンパイルエラー、みたいな感じにすれば大分マシになる仮説を持ってるんだけどどうですかね

あとシステム領域でもオブジェクトの共有パターンは出て来ると思うのでARCが無いとつらそう

= (strong, weak, unowned)

指定しなければstrongなのがだめってこと？

そう

変わるかなあ

1:42 AM

あるとしたら、 self が何もしなくてもキャプチャされることとかが問題だと思ってる

無指定でキャプチャ出来るのが見えにくくなってる元だと考えている

ローカル変数とか。

1:43 AM

strong性のほうじゃなくて、名前自動キャプチャのほうが問題

それはローカル変数キャプチャするとselfつけろって言われない？

self. つけなさいは言われるね。

あークロージャの代わりにメソッド渡したときの挙動も、そうか

GCじゃなくてもARCにしても、Memory Ownershipの世界ではリファレンスカウントの操作すらパフォーマンス的に許容できないのでは？

1:47 AM

なので世界を住み分けることになるのかなと思ってるんですが。

えーっと、それはそうだけど、できるだけ排除する話と

1:47 AM

デザインパターンとしてARCが無理になる負担を強いる話しは別だと思う。

GCじゃなくてもARC+サイクルコレクターとかでもいいけど、住み分けたアプリ側の世界では循環参照気にしなくていいようにできないかな？

あと

1:48 AM

C++の参照の場合は一級参照だから、実体はどっかにあって、他のところからは参照/ポインタで共有し続ける事できるけど

1:49 AM

SwiftのOwnershipで入る参照は生き続けられないから

1:49 AM

その話の方向でいくなら一級参照がはいる方向に強化する必要がでてくる

1:50 AM

ようするに stored propertyの型を参照にはできない

1:51 AM

循環参照気にしなくていいようにできないかな？

これもできないと思ってて、循環が解決できるトレーサーが、入れないところがあると、そこからリークしちゃう

1:52 AM

メモリ参照グラフにおいて、あるオブジェクトはGC対象ではない、とされているとき、 GC対象オブジェクト→GC外オブジェクト→GC対象オブジェクトって参照がつながってるときに、最後のやつがどうしてもマークスイープできない

1:52 AM

途中のGC外のオブジェクトから先をトレーサが見れないから。

ん？リークじゃなく逆にまだ使いたいのに破棄されちゃうわけではなく？ (edited)

えーっと、それは設計で両方ありえて

1:54 AM

GC外からretain(というかルート参照登録)させる方法が無いとするなら、

1:55 AM

ユーザサイドで別の配列とかにいれて持っておいてねってことになるけど

1:55 AM

今度はそれの解放をユーザサイドでやるのがキツくて

1:55 AM

コールバッククロージャーとかですら大変面倒なことになりますよ

GC/ARCの世界からそうじゃない世界に入る場合には明示的に何らかの方法でretainさせるしかないような気が。

1:55 AM

今でもそうなんじゃないかな？ UnsafePointer の世界を挟むときとか。

例えばJavaやJSだと

1:56 AM

C++のコードから、VMに対して、VM内オブジェクトを作らせてから

1:56 AM

それをルート参照に追加するAPIがある

1:57 AM

だから、Managed側から受け取ったオブジェクトを、Native側で、そのAPIで登録しておけば

1:57 AM

Native側からmallocしたようなイメージですね　対応するルート解除をしない限りSweepされなくなる

1:58 AM

今というかちょっと前のObjectiveC なら、 ARCがないMRCのモジュールの中から明示的にretainメソッドを呼ぶのに近いかも

Ownership の世界って基本閉じてて本当にパフォーマンスが重要な部分にしか使われないイメージなんだけど、境界だけ気にしていればいいからそんなに複雑なことにならなくないかな？

2つの構造体が、1つの構造体をポインタ経由で共有する、というデータ構造が作れないとつらくないですか？

どういうこと？

例えば class Cat { var toy: Toy? } と class Dog { var toy: Toy? } が class Toy {} を共有してるっていうのが今のARCだとできますよね

2:06 AM

Ownership で導入されるのは、 shared 参照とmoveonly structですけど、 ARCが無いってことは、classが無いので、↑みたいな構造が作れないです struct Cat { var toy: Toy? } struct Dog { var toy: Toy? } struct Toy {} とやってしまうと、これは共有じゃなくて、Toyの実体が2つになるので、データ構造としては意味が違う。

2:07 AM

struct Cat { shared var toy: Toy? } ←こういうことはできない、一級参照じゃないから

2:08 AM

struct Cat { var toy: UnsafePointer<Toy>? } ←こういうことならできますけど、これはUnsafePointerのじてんでOwnership Systemの保護から外れるので、C言語に戻ってるだけで、安全性が0

2:11 AM

SwiftのOwnership Systemは、↑のような、「共有したい状況」では何ら状況を改善するものではなくて、

2:11 AM

オブジェクトの所有者が明確な、「専有所有する状況」（とそれの貸出と移動)においてはいろいろ改善できるってだけなので、

2:12 AM

既存のclass ARC はまず前提にあって、その中で共有が要らない部分で一部の処理を最適化するためにあるって位置づけ

なるほど。 Rust だとどうなってるの？ first class な参照があるってこと？

Rustの参照はfirst classなんですけど、関数の呼び出しをまたいで追跡したりする場合、ジェネリクスの型パラメータとして、寿命範囲を静的に追跡させるので、ファントムタイプみたいなイメージで

2:24 AM

↑みたいな例で動的な場面では多分参照では解決できないと思う

2:24 AM

Rustにも Rc<T> と Arc<T> があるので

2:25 AM

↑の例はそれらの参照カウンタコンテナ（スマートポインタ）を使うことになると思います

なるほど。 Swift の class は Arc<struct> を強制したようなものか。

そうです。 structにしてUnsafePointerだけで取り回せば、C言語に戻れます。

ARCならミクロに実現できるけど、GCやサイクルコレクターだとマクロに参照グラフをたどれないといけないからOwnershipの世界を挟むときついのか。 (edited)

Ownershipの世界にARCが全く無いってことになるとそこを挟むところが厳しいですね

2:31 AM

あくまでベースとしてARCは普遍的に使われていて、その繋がったグラフの端っこだけOwnershipで済ませる　みたいな感じ。

この前の Erasure のパターンの知識、結構応用が効く

3:47 AM

型パラメータをサブクラスで持って、親クラスではもたないと、型パラメータ部分を消せる

3:48 AM

その２者関係をBoxと名付けて外側の型を作ると、メソッド呼び出し時点のメソッドの型パラメータをボックスに焼きこんで保持するみたいな感じになる

型パラメータをサブクラスで持って、親クラスではもたないと、型パラメータ部分を消せる

ちょうどKeyPathのクラス階層がそんな感じな気がする。ルートがAnyKeyPathで、そこからPartialKeyPath<Root>, KeyPath<Root, Value>みたいな。

1:49 PM

https://developer.apple.com/documentation/swift/key_path_expressions

Observableの実装もそうなのかなぁ

2:08 PM

Mapとか

SinkがBox相応の働きしてるならそうなんだろうけどあれは実装が別々だから違うな

おもしろい https://twitter.com/olebegemann/status/920715831302152192

Ole Begemann (@olebegemann)

[Poll] A Swift quiz: let a: [Float] = [1, .nan] let b: [Float] = [1, .nan] let copy = a a == b // (1) a == copy // (2) What’s (1) and (2)?

やばそう

let e: Float = .nan let f: Float = .nan e == f // false

.nanがcomputed valueで生成結果が毎回違う、かな

ああaとcopyがおなじなのがおかしいんですか

ナンとナンは==取るとfalseになるもの

そういうものなのか

はい

同じインスタンスだったらequalというのが間違ってる。

本当だ

それを使ってナン判定ができます

Float.nan == Float.nan // false let a = Float.nan let b = a a == b // false

これ。 // Test referential equality. if lhsCount == 0 || lhs._buffer.identity == rhs._buffer.identity { return true } https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb#L2195-L2196

https://github.com/apple/swift/pull/12503

swift - The Swift Programming Language

これどう修正するんだろ

1:06 AM

ここのif文取っ払えば治るのは治るけどパフォーマンスに影響出そう

==(lhs: Array<Float>, rhs: Array<Float>) をオーバーロードとか？

Double.nan

自分自身と等しくないのが無限に湧きますよねぇ

そもEquatable定義して必ずfalse返すカスタムオブジェクトが破滅するから

1:09 AM

これは取っ払うしかないな

1:12 AM

let a: [String: Float] = ["a": .nan] let a2 = a a2 == a こっちもだめ、Optionalは正しかった。

1:12 AM

Setもダメだな

1:13 AM

ボロボロだ

ああ、falseになると思いきや、

Buffer持ってる構造全滅滅滅じゃない

アレイの実装によってtrueになっちゃうのか

1:13 AM

スイフトクイズ的だ

Buffer持ってる=CoWが効く構造は

それってどっちかというとFloatがNaNに関して同値性の伝播則を持たないことによるから

1:14 AM

Floatが壊れてるのでノーカンでよいよ

定義されたEquatableの挙動を、CoWの実装の有無によって踏襲する/しないが生まれるのは微妙じゃない？

例えばHashableは

1:16 AM

Equalならhashが同じじゃないといけない

1:16 AM

って規約を持つわけで

1:16 AM

Equatableの特性を厳密化すれば

1:17 AM

Arrayの責任ではなくなる。

1:18 AM

NaNは < も > も falseを返すので、ソート結果が安定しないのと同じ。

twitterでも「Float, DoubleがEquatableのルールを破ってるのが悪い」という話になってる。

1

ふむ

ヤバ。両方 false にならないといけないのに、バッファが同じだったときに省略するコードが走ってんのかな？

1:53 AM

あれ？

1:53 AM

続きがロードされてなくて周回遅れのコメントをしてしまった

時空が歪んだ

1

それってどっちかというとFloatがNaNに関して同値性の伝播則を持たないことによるから Floatが壊れてるのでノーカンでよいよ

これも同じ主旨のこと書こうとしてたｗ

1:57 AM

IEEE 754のNaN関連どうにかしてほしい

まあでもFloatはどんな言語でもIEEE754準拠になっていてマシ

1:58 AM

負の整数のあまりつき除算とか、言語によって微妙に振る舞いが違ったりしてしんどい

Java のラッパークラスの NaN 比較は壊れてる。

public class NaN { public static void main(String[] args) { Double a = Double.NaN; System.out.println(a.equals(a)); // true } }

やば

2:01 AM

doubleとDoubleで結果が違うってこと？

久しぶりに Java 書いたけど、指が自然に public static void main(String[[ args) と動くからすごい。

2:02 AM

うん < double と Double

↑そういいながら [[ に typoしてますね

w

[WIP] Accommodate exceptional values for array comparison by xwu · Pull Request #12503 · apple/swift

Array.== tests for referential equality and returns true if the underlying buffer is shared between two instances. This provides for unexpected behavior in the case of comparisons involving floatin...

2:03 AM

この件についてのプルリクが立ってるんだけど。

ヤバイことに気づいた。

2:04 AM

var dict = [Double: String]() dict[.nan] = "a" dict[.nan] = "b" print(dict) // [.nan: "a", .nan: "b"]

2:05 AM

これを防ぐために Java の Double は↑のような仕様になってた気がする。 (edited)

 if lhsCount != rhs.count { return false } + if lhsCount == 0 { + return true + } // Test referential equality. - if lhsCount == 0 || lhs._buffer.identity == rhs._buffer.identity { + if lhs._buffer.identity == rhs._buffer.identity + && !Element._containsExceptionalValues { return true }

2:06 AM

これAnyの配列とかAnyObjectの配列の場合に中身にfloatがあるケースとかで全部このコンサバなフローになっちゃうと思うんやけど・・・

2:08 AM

Anyとかの場合は == が使えないのか。

2:08 AM

@koher それ、値が取り出せないってことですかね？

2:11 AM

var d = [Float: String]() d[Float.nan] = "aaa" print(d[Float.nan]) // nil

2:11 AM

取り出せないですね

2:11 AM

ウケる。

うん。取り出せない。

2:11 AM

無限に突っ込める。

Float.nan.hashValueは同じだから

2:12 AM

毎回衝突してるなｗ

2:12 AM

草ｗ

Double と Float は Hashable やめた方がいいのでは？

NaN以外ではうまく動くしちょっとぐらい壊れてもいいよ

↓の最後もちょっと納得いかないんだよなぁ。

 14> let nan = Double.nan nan: Double = NaN 15> nan < nan $R8: Bool = false 16> nan > nan $R9: Bool = false 17> nan == nan $R10: Bool = false 18> nan != nan $R11: Bool = true

@ikesyo の ---

型パラメータをサブクラスで持って、親クラスではもたないと、型パラメータ部分を消せる

ちょうどKeyPathのクラス階層がそんな感じな気がする。ルートがAnyKeyPathで、そこからPartialKeyPath<Root>, KeyPath<Root, Value>みたいな。 https://developer.apple.com/documentation/swift/key_path_expressions --- これ、ウェブだとよくわからなかったのでXcodeからコピペ↓

public class AnyKeyPath {} public class PartialKeyPath<Root> : AnyKeyPath {} public class KeyPath<Root, Value> : PartialKeyPath<Root> {} public class WritableKeyPath<Root, Value> : KeyPath<Root, Value> {} public class ReferenceWritableKeyPath<Root, Value> : WritableKeyPath<Root, Value> {}

2:18 AM

@koher < と > が反射しないのに == と != は反射するのよくわからないですよね

NaNをFloatingPointから外したほうが

2:19 AM

struct NaN

外すと 0/0 で困る

Python の↓どうなってんだ？

$ python Python 3.6.1 (default, Apr 19 2017, 14:30:24) >>> from math import nan >>> d = dict() >>> d[nan] = "a" >>> d[nan] = "b" >>> d {nan: 'b'} >>> nan == nan False

2:20 AM

まさか Dict に突っ込まれる度に nan チェックしてんのかな？

idenitty equalをまず見てるんじゃないですか？

ボクシングされるってこと？値じゃないの？

そもそもオブジェクトかも

Floatの除算をthrowsにすればstruct NaN: Errorでいけるのでは

除算をthrowsにしちゃったら

2:22 AM

めちゃくちゃおそくなっちゃうよ

ふむー

floatの利用シーンがおそおそになる

2:22 AM

やるとしてIntのoverflowケースみたいにクラッシュさせて

2:22 AM

NaNが産まれる除算は &/ にするとか？

Int(0)/Int(0)はクラッシュやね (edited)

うむ。

NaNを許容する除算と許容しない除算を分けてNaNをError型にして許容しない方はクラッシュ、かなぁ

あと C Interop も考える必要あるね

2:24 AM

/// The C 'float' type. public typealias CFloat = Float /// The C 'double' type. public typealias CDouble = Double

2:24 AM

いまはこう。

うげうげのうげ

float周りは高速計算領域の話題だから、まともなFloatを用意するなら完全に別の型体系にしたほうがいいんじゃないかな〜

struct CFloat { init(_ source: Float) init(_ source: NaN) }

2:25 AM

こうなっちゃいますね

いまのFloatをまともなやつにして速いコードはCFloatでやってね、もありか。

昔デデキント切断による実数型を作れないか考えたことある。

それはそれでありだと思う

struct FiniteFloat とか

2:26 AM

+infと-infはあってもいいんだろうか・・・

今のFloatをCFloatにしてNaNを含まないFloatを新設、とかありえそう

実数型を作る話だ

Float.infinity こいつもいるのか

うん。

2:27 AM

あともっというと +0 と -0 がある。

実数型作るなら inf はいらないのでは。

Float.infinity == (Float.infinity * 2) // true おお~~~~

2:27 AM

ホンモノぽいw

単純な実数型の外に

クソみたいな小細工がいろいろ仕込まれててウケるよ、Floatの変なやつら

無限も扱える体系を作るのがよさそう

2:29 AM

あとその前に有理数を分離しなきゃ。

print(Float(1) / Float.infinity) // 0.0 print(Float(-1) / Float.infinity) // -0.0

2:30 AM

https://ja.wikipedia.org/wiki/超実数

超実数の全体 *R は実数体 R の拡大体であり、 1 + 1 + ⋯ + 1 1+1+\cdots +1 の形に書ける如何なる数よりも大きい元を含む。

%E8%B6%85%E5%AE%9F%E6%95%B0

https://ja.wikipedia.org/wiki/%E6%8B%A1%E5%A4%A7%E5%AE%9F%E6%95%B0

%E6%8B%A1%E5%A4%A7%E5%AE%9F%E6%95%B0

なんかこういうのを形式的に実装するのかな

https://www49.atwiki.jp/aniwotawiki/pages/11249.html

…ここからが本題の超実数の話。先程、我々は実数体Rに∞と－∞を追加した集合である拡大実数を得た。 注意深い読者なら気付いただろうが、この集合は拡大実数「体」ではない。つまり、これは体ではない。 我々はまず自然数全体の集合Nから始め、Nが元々持っていた構造(足し算や掛け算、大小関係)を壊さないように慎重に拡張してきたのだが、 Rに∞と－∞を追加したことでその構造が壊れてしまったのである。 拡大実数を構成する際、 「限りなく大きくなる」代数的数の列は「∞に限りなく近づく」代数的数の列 だという拡大解釈を行ったが、 これが失敗だった 。 「限りなく大きくなる」代数的数の列として挙げた{1,2,3,4,…}と{2,4,6,8…}は確かに両方とも「限りなく大きくなる」代数的数の列であることは間違いない。 しかし{1,2,3,4…}という列に比べ{2,4,6,8…}という列は2倍の勢いで大きくなっていく。 この事実を無視し、単純に両方を∞という同じ数に近づく列だと考えてしまったのが原因でおかしなことになってしまったのである。 この問題を解消するには、「異なる勢いで大きくなる列」には「異なる∞」を対応させればよい。 この方法を用いれば、Rの体構造を保ったまま∞と－∞を追加することができる。これを超実数「体」と呼ぶ。

超実数 - アニヲタWiki(仮) - アットウィキ

登録日：2010/09/05(日) 15:45:19 更新日： 2017/09/30 Sat 14:10:34 所要時間：約 4 分で読めます ▽タグ一覧ためになる項目ためになる項目←理解...

2:35 AM

taketo1024 さんに作ってもらおうｗ

Swift.Floatが壊れてるのはしかたないのでまともなFloatを作ってそれを使うというスタンス

$ kotlinc Welcome to Kotlin version 1.1.2-2 (JRE 1.8.0_131-b11) Type :help for help, :quit for quit >>> val nan = Double.NaN >>> nan == nan false >>> nan === nan false >>> val map = mutableMapOf<Double, String>() >>> map[nan] = "a" >>> map[nan] = "b" >>> println(map) {NaN=b}

===がfalseなのが謎だな

お、おもしろいの発見した

2:46 AM

>>> fun <T> eq(a: T, b: T): Boolean { return a == b } >>> nan == nan false >>> eq(nan, nan) true

あ、unboxされてるのか

2:46 AM

その場合は Genericなコードになるから == が <T> のboxのidentityになってるんですね

Kotlin には普段見えないラッパーが見える

=== の場合はstaticなDoubleのコードだからunboxされて == と同じ処理になると

identity じゃなくて同値性だけど、 Double の equals は前述の Java の通りだから。

あー JAvaのDoubleのequalsも踏まえないといけないのかｗ

返り値が Optional版や throws 版を作る時、suffixやprefixで表現する時、どうしてます？最近はこんな感じにやってるんだけど↓

// prefix func mayGetCat() -> Optional<Cat> func mustGetCat() throws -> Cat // suffix func getCatOrNone() -> Optional<Cat> func getCatOrThrow() throws -> Cat

throwsだけ作って利用者側がtry?すればいいじゃんと思ってるけど

それだとパフォーマンス上不利だから利用者が try? するぐらいなら Optional版も用意したい

なるほど

3:12 AM

オーバーロードするとしんどいんだっけ

例えば複数行クロージャの中で使うと推論が効かないのでちょっと不便な場合が出てくる (edited)

3:13 AM

名前でわけておくとreturnのところでオーバーロード曖昧性がないのでそこから型が確定できる

3:15 AM

まあ明示すれば解決するから、同じ名前でオーバーロード流派もそれはそれでありだと思う

3:16 AM

↑の例で個人的に気になってるところは、 OrNone vs OrNil OrThrow vs OrError

struct May { private init() {} static let may = May() } struct Throw { private init() {} static let `throw` = Throw() } func getCat(_ o: May = .may) -> Cat? { return Cat() } func getCat(_ o: Throw = .throw) throws -> Cat { return Cat() }

引数で明示できるようにしてみた

3:16 AM

getCat(.may)ならOptionalに確定

おお〜　短い名前と、必要なときの明示を両立するのか　おもしろい

3:17 AM

それだと英語が変になるから、 .orNone と .orThrow のほうが好きかな getCat(.orNone)

まあそれはどちらでも

3:17 AM

着想としては[1,2,3][...]ベースかな。

3:22 AM

tryと?が演算子扱いならgetCat(?)とgetCat(try)が使えた気がする

3:22 AM

実際は違うのでムリ

なるほど

@omochimetaru メソッド名につけるならOrNilとOrThrowがすきかなあ

3:24 AM

OrErrorだとthrowされるのかクラッシュするのかなんか怖そう

3:24 AM

普段はオーバーロード+型明記派になってる

たしかに OrThrowならどう考えてもthrowだよな

3:25 AM

OrNilじゃなくてOrNoneだと思うんだよね、 nil が .none になるのであって nil 自体は返ってきてない

3:25 AM

Swiftにnilなんていう値は存在しないのだ

3:26 AM

リテラルの型としては存在するけど実行時の型は .none などになる

それで言うと取れる値としては.noneかErrorかどっちかという話なので

3:27 AM

orNone, orErrorがいいのでは

Either < T , Error >だったら orError だと思うんだけど

3:27 AM

「値が返る」ことと「throwされる」ことを

実態はthrows () -> Tだから、というはなしか

別と捉えると、 OrThrowの方がより明確かな〜って

OrNone, OrError, OrDie

クラッシュ系はどれがいいのかな〜 > OrCrash OrNever OrDie

3:31 AM

perl だと or die イディオムありますよね。

orDieは省略したくないなw

orDie だけデフォルト引数設定しないとか？

struct OrNone { private init() {} static let orNone = OrNone() } struct OrError { private init() {} static let orError = OrError() } struct OrDie { private init() {} static let orDie = OrDie() } func getCat(_ o: OrNone = .orNone) -> Cat? { return nil } func getCat(_ o: OrError = .orError) throws -> Cat { throw Cat.Error.fail } func getCat(_ o: OrDie) -> Cat { fatalError() }

3:34 AM

ということで

3:35 AM

補完バッチリ効いてるのいいすね

オシャレだな・・・

3:35 AM

推論効けば短く書けるし明示するときは指定できるのか・・・

推論効くときは効かせるスタイルもっとはやってほしい

3:36 AM

左辺vs右辺とか不毛だし両立できるよっていう認識広まるとうれしいですね

https://github.com/apple/swift/pull/12520

[WIP] [stdlib] changes to remove _Strideable protocol. by xedin · Pull Request #12520 · apple/swift

ABI work to remove unnecessary _Strideable protocol and use Strideable everywhere instead, which already conforms to Comparable. Initial changes are done by @airspeedswift.

2:52 AM

あの怪しい _Strideable が消えそう

protocol Animal {} protocol Cat: Animal {} class Dog: Animal {} Dog.self is Animal.Type // true Cat.self is Animal.Type // swift 3.2 true, swift 4.0 false

10:48 AM

これって話題になりましたっけ

Swift4で違うの！

10:48 AM

俺は初耳

10:49 AM

っていうかfalseなのか・・・

あれこれ出来たはずなのに死んだわおっかしいなと思ったら

2

こういうことやりたいんですが、なんかいい感じのオペレータとかあるんでしょうか？

intStream .map(ensuredPositiveIntString) .catchErrorJustReturn("マイナスだよ") .subscribe... // 👈 エラー来てもnext扱いで死なないでほしい enum Error: Swift.Error { case isNegative } func ensuredPositiveIntString(i: Int) throws -> String { if i < 0 { throw Error.isNegative } return String(i) }

ensuredPositiveIntString は Result<String, Error> を返すより、単純な throws にしたいんですが

flatMapの中でやる

こういうことです？

intStream .flatMap { do { return try Observable.just(ensuredPositiveIntString(i: $0)) } catch { return Observable.just("マイナスだよ") } }

ensuredPsitiveを、IntかErrorが出るObservableにすると解りやすいかも

intStream .flatMap(ensuredPositiveIntString(i:)) .subscribe... // 👈 エラー来ても死なない func ensuredPositiveIntString(i: Int) -> Observable<Int> { if i < 0 { return Observable.error(Error.isNegative) } return Observable.just(String(i)) }

(edited)

intStream.flatMap{ ensurePositive($0) .catchError { エラー処理 } } .subscribe(メイン処理)

8:34 AM

こうです

なるほど

8:36 AM

うーん、できればensuredPositiveIntStringはRx関係ないpure swiftな世界にしたいのだけれど、それは既存の仕組みでは難しいですか

throws Tをラップするオペレーターがあれば楽かなぁ

8:38 AM

結構オレオレで作るんですよね

8:39 AM

Observable.from(throws: @escaping () throws -> T)

死なないという条件的には微妙ですがretry使えるならそれでもいいのでは

こんなかんじかな

extension ObservableType { static func from<U>(_ f: @escaping (Self.E) throws -> U) -> ((Self.E) -> Observable<U>) { return { (e: E) in do { let u = try f(e) return Observable.just(u) } catch(let e) { return Observable.error(e) } } } }

8:41 AM

お、retry実は使ったことないので探ってみます

8:45 AM

ここまであったほうがいいか

extension ObservableType { static func from<U>(_ f: @escaping (Self.E) throws -> U, catch: (Error) -> U) -> ((Self.E) -> Observable<U>) { return { (e: E) in do { let u = try f(e) return Observable.just(u) } catch(let e) { return Observable.just(catch(e)) } } } }

んーなんか違う

8:46 AM

引数無しで返り値はEです

8:47 AM

throws () -> TをObservable<T>にしたいので

イメージ涌ききれてないけど多分そっちのほうが正解だと思うので、動くもの使って弄ってみますー

@t.ae 失敗したり成功したりする処理ならretryは有効だけど、何度やっても失敗する場合はretryは使えないのでは、と思いました

あーソースがPublishSubjectのときに使ってるパターンなのでそれだけ考えてました……

throwsで殺さないやつ、自分が考えるとこういうやりかたに行き着くんですが、 @tarunon 的にはどういうのイメージしてたんでしょう

単純に、エラーが流れるとdisposeなんで、flatMapの中でsubscribeを毎回作れば都度disposeされても問題ないという話です。

11:13 AM

stream.map(someThrowableFunc).catchError().subscribe() // これだとエラーが流れた時点でおしまい stream.flatMap { Observable.from(someThrowableFunc($0)).catchError() // Errorでdisposeになるのはこのsubscription }.subscribe() // 従ってこちらには影響しない

11:13 AM

これはcompleteが流れる場合も同じように (edited)

11:14 AM

で、retryはErrorが流れてきた場合はsubscribeしなおす、というものなので、源流でreplayがついてる場合はErrorを無限に繰り返すことになる

なるほど Observable.from(throws: @escaping () throws -> T) の使いどころがよくわかってなかったんですが把握こういうことですね

それだけなら何もしなくても、これでも長くないし別に困らない感

Observable.from([1, 2, 3, -1, 4, 5]) .flatMapFirst { Observable.just($0) .map(ensuredPositiveString) .catchError { _ in .just("つづく") } } .subscribe(onNext: { print($0) })

(edited)

昨日の #swtws での @omochimetaru さんの発表を見て、 SwiftyAlgebra の行列計算が遅すぎて悩んでいることについて何かヒントを頂けたらと思い、質問させていただきます。 https://github.com/taketo1024/SwiftyAlgebra/blob/master/Sources/Matrix/Matrix.swift 元々は行列の積を

public static func * <p>(a: Matrix<R, n, m>, b: Matrix<R, m, p>) -> Matrix<R, n, p> { return Matrix<R, n, p>(rows: a.rows, cols: b.cols) { (i, k) -> R in // 積の (i, k) 成分を返す. // a の i 行と b の k 列の積和を計算. return (0 ..< a.cols) .map({j in a[i, j] * b[j, k]}) .reduce(0) {$0 + $1} } }

のように書いていたのですが、これがサイズ 200x200 ぐらいでも 7 秒近くかかってしまい、これを次のように書き換えたところ 7秒 → 0.2 秒に改善されました。

 public static func * <p>(a: Matrix<R, n, m>, b: Matrix<R, m, p>) -> Matrix<R, n, p> { // 行列の1次元グリッドを生成して Matrix を作る var grid = Array(repeating: R.zero, count: a.rows * b.cols) var p = UnsafeMutablePointer(&grid) for c in 0 ..< a.rows * b.cols { let (i, j) = (c / b.cols, c % b.cols) var (q, r) = (UnsafePointer(a.grid), UnsafePointer(b.grid)) q += a.gridIndex(i, 0) r += b.gridIndex(0, j) var x = R.zero for _ in 0 ..< a.cols { x = x + q.pointee * r.pointee q += 1 r += b.cols } p.pointee = x p += 1 } return Matrix<R, n, p>(rows: a.rows, cols: b.cols, grid: grid) }

できればこういうポインタ丸出しのコードは書きたくないので（そっち方向でやるなら言語を変えた方が良さそうという気持ち）、なんとか上のような書き方のまま改善したいと思っているのですが、上の書き方がこんなにも遅い理由は思い当たるものありますか？ init に渡す closure の中で行列 a, b にアクセスしてることから、丸ごとコピーされちゃったりしてるのかなと疑っています…

Thanks in advance

(edited)

taketo1024/SwiftyAlgebra

Contribute to SwiftyAlgebra development by creating an account on GitHub.

1

今ちゃんと読めてないですがspecializeの問題とかあるかも？また後で見てみます。

1

Submodules/Eigen のチェックアウトが全然終わらない

あれれ、Submodule 外してたと思ったんですが

/.gitmodules にエントリがありますね

ありゃりゃ、それは失敗しました、消しときます

4:45 AM

そのままでも動くはずです。

了解です

1

まず、クロージャがaとbをコピーしてるというのは無さそうです。nonescapeなクロージャはスタック上の値をポインタ参照するので。で、TimeProfilerで調べてみたら、Matrix.initに渡してるクロージャの中のmapとreduceが、CountableRangeに対するprotocol witness呼び出しをしていたんで、そこらへんがインライン化されてないっぽいです。 Matrix.multiply自体はSpecializeされているぽいけど、Matrix.initのクロージャの中身が最適化されてない (edited)

5:54 AM

試しに Matrix.initの中身だけ手動で書いたら、 swifty(1): 9.03 pointer(2): 0.18 に対して、 forloop(3): 1.93

5:54 AM

 public static func multiply3<p>(a: Matrix<R, n, m>, b: Matrix<R, m, p>) -> Matrix<R, n, p> { assert(a.cols == b.rows, "Mismatching matrix size.") return Matrix<R, n, p>(rows: a.rows, cols: b.cols, type: (a.type == b.type) ? a.type : .Default) { (i, k) -> R in var x = R.zero for j in 0..<a.cols { x = x + a[i, j] * b[j, k] } return x } }

5:55 AM

50倍ぐらい差があるところを10倍差ぐらいまで追いついた。

18.37 s 96.2% 458.00 ms closure #1 in static Matrix.multiply3<A>(a:b:) 17.16 s 89.9% 1.09 s Array.subscript.getter 5.11 s 26.7% 696.00 ms _ArrayBuffer._checkInoutAndNativeTypeCheckedBounds(_:wasNativeTypeChecked:) 4.92 s 25.7% 725.00 ms swift_bridgeObjectRetain 3.62 s 18.9% 3.62 s _swift_release_ 819.00 ms 4.2% 737.00 ms Array._getElement(_:wasNativeTypeChecked:matchingSubscriptCheck:) 503.00 ms 2.6% 503.00 ms _swift_isClassOrObjCExistentialType 441.00 ms 2.3% 441.00 ms swift_bridgeObjectRelease 360.00 ms 1.8% 360.00 ms __swift_memcpy8_8 137.00 ms 0.7% 137.00 ms swift_release 95.00 ms 0.4% 0 s <Unknown Address> 43.00 ms 0.2% 0 s 0x7fff5d2ef24f 17.00 ms 0.0% 17.00 ms swift_retain 214.00 ms 1.1% 214.00 ms _swift_isClassOrObjCExistentialType

6:05 AM

次に支配的なのが subscript.getter で、これ、Matrix.subscript内部で grid に indexを与えて値を取り出すところなんですけど、ここで型がspecializeされてなくて、Ring型のexistentialになっちゃってるせいでただのDoubleを出し入れするだけなのにヒープ化されちゃってる。 swift_bridgeObjectRetainと_swift_release_のコスト。

6:07 AM

93%がArray.subscriptで、積和の計算は7%しか時間がかかってない

@t.ae もこれよく困ってるよねジェネリック<T>型が内部で持つ Array<T> が existential 化(boxing)されてクソ遅いやつ

お！きた！

6:35 AM

ポインタ版より２倍はやくできたぞ

1

ぬぉッ…！めっちゃやってくれてる

@_inlineable つけるっていう裏技を使った・・・

なんと…！！！

とりあえずプロジェクト共有します

感謝です…！！！

https://github.com/omochi/SwiftyAlgebra/tree/inlineable ↑この inlineable ブランチで /Workspace/Sandbox/SwAlSandbox.xcworkspace に、Mac用コマンドラインアプリとしてビルドしていて

omochi/SwiftyAlgebra

Contribute to SwiftyAlgebra development by creating an account on GitHub.

6:40 AM

@Taketo Sano のポインタ実装のmultiply2と、インライン化させたmultply4を100x100行列の掛け算1000回をやって秒数が出力される。

6:40 AM

問題はインライン化させるためには経由する関数呼び出しと参照するstored propertyが全部 public かつ inlineable で無ければならないので、

6:40 AM

grid とかが internal から public になってしまっているので実用性が無いということ・・・

6:43 AM

multply4はもともとのバージョンを forループに書き直したバージョン( initの中にもmapがあったんでこれも initを増やした

@_inlineableはズルだわw

まあずるなんだけど、遅い原因が existential にあるってことがわかった。

ジェネリック<T>型が内部で持つ Array<T> が existential 化(boxing)されてクソ遅いやつ

これはどういうことなんです？

はやく公式な機能になって欲しいね

えーっと、 Array自体は Double を直列にメモリで持ってるんですけど

6:46 AM

Matrix.subscript は、 R としてコンパイルされた実装しかもってないから

6:47 AM

subscriptを呼び出すときに、gridへのアクセスが、ナマの [Double] じゃなくて [R] 扱いで、

6:47 AM

DoubleからRにラップして取り出して、

6:47 AM

取り出してきた側でまたDoubleに戻す、となっちゃってて

6:47 AM

そこでヒープ上にboxしたりunboxしたりしてクソ重い

なんぞ

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040061.html

6:48 AM

インライン化の正式機能化がちょうど議論中だから

6:49 AM

待ってれば言語が改良されて解決するかも・・・

6:49 AM

ただ、現状のディスカッションだと、 internal な stored property が絡んでるとやっぱりインライン化されないので

6:49 AM

このままだと微妙ですねえ

なるほどです…！ Double というのは R=Double とした場合ってことですよね（Int なら Int 型で、subscript で無駄に box/unbox されるという理解であってます？）

あ、もちろん、そうです。

1

6:50 AM

なので、これを、回避する裏技として

6:51 AM

@t.ae が https://github.com/t-ae/Swim/blob/master/Sources/Swim/Specialization/FloatingPointSpecialize.swift

t-ae/Swim

Swim - Image library for Swift

6:52 AM

Image<T, P> に対して、実装をwhere付きのextensionのオーバーロードを用意したり・・・

6:53 AM

@koher も同じようなことやっている https://github.com/koher/EasyImagy/blob/master/Sources/EasyImagy/ImageTyped.swift

add Matrix mul performance test code. · taketo1024/SwiftyAlgebra@7543dfc

EasyImagy - Makes it easy to deal with images in Swift

6:53 AM

でも、 @Taketo Sano のMatrixは要素の型だけじゃなくて、 ColNum と RowNum も型パラメータに入ってるから、

6:53 AM

特定の型について事前に用意しておくこの方針は無理そうだなあ

なるほど…

これは絶対に質問しないと分からなかった…

6:54 AM

コードも後で見てみます！（いま新幹線なので

）

スペシャライズに期待しないで型パラメータが特定の型のときの実装を明示的に書いておくと、特定の型のときは必然的にスペシャライズされた実装が使われる裏技だけど、事前に用意した型にしか効かないし、型パラメータが多いとその組み合わせになって現実的に無理ってことですね

@koher さんの言ってた specialize の問題ってこれだったんですね

ですね

要素アクセス以外の関数は一回の処理で何万回も呼ばれるようなことはないはずなので、ひとまずはそこだけインライン化できれば僕のケースでは問題なさそうです！

7:01 AM

これで掃き出しも相当早くなりそう

✨

なんか微妙だったのが、var grid のwillSetで

7:02 AM

clearCacheが呼ばれていて、smithNormalFormCacheを参照していたので

7:02 AM

この２つもpublicにする必要がありました。

willSet もまた重い原因っぽかったんで、消そうと思ってます（clearCache はユーザ（僕しかいないが）の責任で呼ぶ方向で）

なるほど。

あ、そうか、privateなものが絡んでもinline化したい話についても、話題は進んでた。使用提案としては別文書になる予定みたいだけど

7:12 AM

そのうち何もかもいけそうやな

(0 ..< n).reduce みたいなことも generic 型が絡む場合やらない方がいいんですか？かなりこのパターン多用してます。

そのパターンでもちゃんとインライン化できるから大丈夫だと思いますただ、どういうときにインライン化されてどういうときにされないのか、僕も完全にはわかってないので、いったん検証のためにforループにしました

何もかも publicにしなくても、 @_versioned をつけておくと internal に保っておけるので少し改良しました

おぉw 知らないアノテーションがたくさんw

これ系は正式仕様じゃないのでSwiftのアップデートでいきなりぶっ壊れたりコンパイラのバグを引き出したりする可能性があるので注意です。 (edited)

7:31 AM

ただ、標準ライブラリの内部では多用されています。

7:32 AM

元のバージョンと forloopのバージョンだと差が出るのでもうちょっと調べ中・・・

1

うーん、最適化が絡んでシンボルが消えちゃうので何が起きてるのかはっきりとはわからないんですが、 genericsは関係なく、普通に range.map.reduce が重い感じがしますね

7:42 AM

クロージャの呼び出しのたびに、 mapの返り値としてArrayが生成/破棄されているコストが重そう・・・

なるほどなるほど

Matrixのinitializerのほうは multiply1回につき1回なんで

7:43 AM

こっちは let grid = (0 ..< rows * cols).map { (index: Int) -> R in let (i, j) = index /% cols return g(i, j) }

7:43 AM

これで問題ないと思うんですけど

7:44 AM

行列要素ごとの↓が苦しい return (0 ..< a.cols) .map({j in a[i, j] * b[j, k]}) .reduce(0) {$0 + $1}

7:45 AM

10.12 s 96.2% 659.00 ms specialized closure #1 in static Matrix.multiply1<A>(a:b:) 3.70 s 35.1% 3.70 s _swift_release_ 2.27 s 21.6% 375.00 ms swift_bridgeObjectRetain 1.91 s 18.1% 0 s 0x7fff5dcb674f

retainとreleaseで50%ぐらいかかってて、多分この正体が map の返り値。

なんか色々解決されてた。

なるほどなるほど。

map と reduce の mutating 版を作ったらパフォーマンス改善しないかな？

大量に呼ばれるケースでは Range map はやらない方がよさそうですね。

8:01 AM

自前でそういう Sequence を作るってことです？

extension で生やすとかですね。思いつきですが、生成破棄の問題なら無駄な生成と破棄を減らせそう。

なるほどなるほど

 @_inlineable public static func multiply3<p>(a: Matrix<R, n, m>, b: Matrix<R, m, p>) -> Matrix<R, n, p> { assert(a.cols == b.rows, "Mismatching matrix size.") return Matrix<R, n, p>(rows: a.rows, cols: b.cols, type: (a.type == b.type) ? a.type : .Default) { (i, k) -> R in var x = R.zero for j in 0..<a.cols { x = x + a[i, j] * b[j, k] } return x } } @_inlineable public static func multiply4<p>(a: Matrix<R, n, m>, b: Matrix<R, m, p>) -> Matrix<R, n, p> { assert(a.cols == b.rows, "Mismatching matrix size.") return Matrix<R, n, p>(rows: a.rows, cols: b.cols, type: (a.type == b.type) ? a.type : .Default) { (i, k) -> R in sigma(0 ..< a.cols){ j in a[i, j] * b[j, k] } } }

8:23 AM

@_inlineable public func sigma<I, T: AdditiveGroup>(_ range: CountableRange<I>, _ f: (I) -> T) -> T { var s: T = T.zero var i = range.startIndex while i != range.endIndex { s = s + f(i) i = range.index(after: i) } return s }

8:23 AM

これでも10倍ぐらい遅い

8:23 AM

Σを関数化すれば map, reduce がなくなって Array を使わないのでいけると思ったけど駄目だった (edited)

お手上げだ

8:37 AM

これ以上は単純化してLLVMIR見比べてみないとわからん・・・

すいません、ありがとうございます！

教えて頂いた方法で自分の方でも対応してみました。 https://github.com/taketo1024/SwiftyAlgebra/commit/7543dfc0d0e667a7f2babe937419422c07452f58 subscript を @_inlineable にして、従来通り／命令型に書き換え／ポインタ版で速度を比較して見ましたが、 original : 5.456 sec. imperative : 1.812 sec. pointer : 186.214 msec. となって、やはりポインタ版が圧倒的に速いようです。何かやりたりていないことがあるのかな…？

10:57 AM

https://github.com/taketo1024/SwiftyAlgebra/commit/7543dfc0d0e667a7f2babe937419422c07452f58#diff-18279c97851c8cf84888ab45024eb25c このテスト関数で３つの処理時間を比較できるようになってます。

add Matrix mul performance test code. · taketo1024/SwiftyAlgebra@7543dfc

チェックアウトしてそのまま(Debugビルド) original : 6.072 sec. imperative : 2.023 sec. pointer : 334.983 msec. Release Build に変更 original : 5.486 sec. imperative : 1.306 sec. pointer : 102.905 msec. (edited)

12:30 PM

mul2を @_inlineable, Release original : 5.773 sec. imperative : 54.375 msec. pointer : 113.603 msec. (edited)

12:31 PM

mul2とmul3を @_inlineable、Release original : 5.599 sec. imperative : 49.306 msec. pointer : 57.74 msec. (edited)

1

12:33 PM

mul2とmul3を @_inlineable, Debug original : 6.505 sec. imperative : 2.068 sec. pointer : 201.69 msec. (edited)

12:37 PM

おそらく、そもそもsubscriptアクセスを行う関数(ここではmul2とmul3)自体がインライン化されないと、その先のsubscriptのインライン化もされないです。 subscriptだけinlineableであっても、mul2をコンパイルする時点ではジェネリックなRとして取り扱うコードしか生成しようがないからです。利用時に Int を渡してmul2をインラインコンパイルするときに初めて、その先のsubscriptまで具象型Intが与えられたバージョンが生成されます。

12:41 PM

それと、Releaseビルドで、Optimizationオプションが -O で有効になっていないとだめで、Debugビルドではinlineableであってもインライン化はされないみたいですね。 (edited)

なるほど！

12:48 PM

演算子の関数も inline 化できるのかな？（後でやってみます）

できますよ。 func * に @_inlineable をつけた original : 3.683 sec. imperative : 47.842 msec. pointer : 55.317 msec. func * と、 sum に @_inlineable をつけた original : 786.015 msec. imperative : 51.296 msec. pointer : 53.369 msec.

12:54 PM

で、ここまでやって、まだ originalとimperativeに15倍の差が出ているのが、謎・・・

うーむ…しかし元の7秒から実に10倍も早くなりましたね

あー、 Matrix.init に @_inlineable をつけたけど、かわらないですねえ original : 763.616 msec. imperative : 48.467 msec. pointer : 50.94 msec.

12:58 PM

そこでインライン化が止まっちゃって、Matrixの要素ごとにクロージャを呼び出す形は変わらなくって、遅いのかもしれないです。

@inline(__always) や @transparent なんてのもあるんですね。どういう違いがあるかご存知ですか？

transparentは忘れちゃったけどドキュメントはここにあります https://github.com/apple/swift/blob/643d913ffce313238132e0e90ccb8bb2e93fc826/docs/TransparentAttr.rst @inline() は、とりあえず、 @inline(never) でインライン化絶対拒否は正規仕様で、 @inline(__always) は忘れました。ここで、正規じゃないから文書は無いよって回答がある・・・ https://bugs.swift.org/browse/SR-182

https://github.com/apple/swift/blob/master/docs/Generics.rst#specialization

swift - The Swift Programming Language

2:34 AM

@specialize だかなんだかそんなんもありますね

2:35 AM

似たようなのがいろいろあるので、それぞれちゃんと調べれば、もっと状況を改善できるかもしれないな。

Matrixもそうですけど型じゃなくて型が持つ値のみを使う場合にいい感じの書き方無いですかねえ。スペシャライズはどうも面倒……

@omochimetaru こちら再現できました！ original : 649.904 msec. imperative : 54.653 msec. pointer : 54.364 msec. かなり前進した感

✨✨✨✨✨✨

おお。

2:46 AM

@t.ae > スペシャライズはどうも面倒…… < これは手書きスペシャライズのこと？

ちゃんと追えてないんですが、↓って map の中の計算を reduce の中に持って行ったら問題ないんじゃないでしょうか？ return (0 ..< a.cols) .map({j in a[i, j] * b[j, k]}) .reduce(0) {$0 + $1}

2:49 AM

mutating func 化は的外れだった。そもそも map する時点で mutating じゃないし。 (edited)

でもそうすると積和っぽくなくなりません？式を書き下す感じになってしまう

2:49 AM

書き方を工夫して早くするという観点では、 forループにすれば良いってことはわかっているので

2:50 AM

↑のswiftyな書き方のまま、同等の性能を出したいというのが残課題です

reducd を for にするよりはわかりやすそうな気も？

sigma はどうですか？ (edited)

2:50 AM

和を取るって意味を関数名に退避することで + を書かなくて済むのでより明確になるし数式に近くなる

@omochimetaru 手書きも@_specializeも網羅が面倒ですね。

@t.ae ああ、アノテーションを付けて回るのが面倒ということか。

@omochimetaru sigma の実装が for じゃなくて while なのはなぜ？ (edited)

https://github.com/apple/swift/blob/master/docs/Generics.rst#specialization

swift - The Swift Programming Language

@koher 最初 for でやったんだけど全く速度が変わらなかったから書き換えてみたけどそれでもだめだった。

2:54 AM

swift - The Swift Programming Language

2:54 AM

@_specialize にもドキュメントがあった

sigma の層があってもいいけど、 reduce で同じパフォーマンスが出るんだったら sigma の実装が reduce でもいいかも。

return Matrix<R, n, p>(rows: a.rows, cols: b.cols, type: (a.type == b.type) ? a.type : .Default) { (i, k) in (0 ..< a.cols).sum { j in a[i, j] * b[j, k] } }

今こういう感じに書くようにしてみてて、 sum も @_inlineable にすると、 original : 325.293 msec. imperative : 56.286 msec. pointer : 50.375 msec. これぐらいまで差が縮まりました。この 250 msec の差は、200 x 200 回 closure を関数として呼び出してる分のオーバーヘッドなのかなとか想像してます

(edited)

@koher ああ、それはそうですね、前提として reduceの前のmapが悪いのかと思って。

map で無駄な Array が生成されるのが問題なんだったらそこは回避できそう。 (edited)

@koher あー言ってるのはreduceに全部書く方式か。それでもよいかと。 (edited)

2:56 AM

200 x 200 回 closure を関数として呼び出してる分のオーバーヘッド

そうなんですよね〜　そこが最後の壁、そこも init の中に展開してほしいんですけどね。

sum の中で Array を生成せずに imperative な書き方してます。

public extension Sequence { @inline(__always) public func sum<G: AdditiveGroup>(mapping f: (Element) -> G) -> G { // MEMO reduce is slow. var res = G.zero for e in self { res = res + f(e) } return res } }

(edited)

2:58 AM

ちなみに @inline(__always) と @_inlineable の違いはなんだろうと思って調べてみたんですが、ここを見ると一個の関数に両方ついてるのがたくさんあって謎でしたw https://github.com/apple/swift/blob/master/stdlib/public/core/BridgeStorage.swift

koher/reduce-performance-test

swift - The Swift Programming Language

2:59 AM

@_inlineable // FIXME(sil-serialize-all) って書いてあるんで、いずれは消える予定？

どっちかは自身のことでどっちかは自身の内部の話とか、かなあ？あとableってついてるし可能性を保証するやつと絶対やらせるやつなんでしょうねえ

// MEMO reduce is slow.

これはなんでなんでしたっけ？スペシャライズされれば変わらなさそうな気も。

それを書いた時点では reduce が遅いのが原因かと思ってそう書きました。

3:00 AM

今ちょっと書き直して調べてみます。

3:02 AM

public extension Sequence { @inline(__always) public func sum<G: AdditiveGroup>(mapping f: (Element) -> G) -> G { return self.reduce(G.zero){ $0 + f($1)} } }

before: 325.293 msec. after: 293.025 msec. おぉ、なんか速くなりました

w (edited)

おお

@inline(__always) public init(rows r: Int? = nil, cols c: Int? = nil, type: MatrixType = .Default, @inline(__always) generator g: (Int, Int) -> R) {

こういう風に引数の closure に inline つけられないかやってみたけどダメでしたw

↓単純な例での reduce と for の比較やってみました。 https://github.com/koher/reduce-performance-test

Contribute to reduce-performance-test development by creating an account on GitHub.

grid を作る処理を init から外に出して

let grid = Matrix.generateGrid(a.rows, b.cols) { (i, k) in (0 ..< a.cols).sum { j in a[i, j] * b[j, k] } } return Matrix<R, n, p>(rows: a.rows, cols: b.cols, type: (a.type == b.type) ? a.type : .Default, grid: grid)

ってしてみましたが変わらずでした（ generateGrid も @inline 化してある） (edited)

 func testReduce() { measure { XCTAssertEqual(ns.reduce(0) { $0 + $1 * $1 }, squareSum) } } func testForLoop() { measure { var result: Int64 = 0 for n in ns { result += n * n } XCTAssertEqual(result, squareSum) } } func testMapReduce() { measure { XCTAssertEqual(ns.map { $0 * $0 }.reduce(0) { $0 + $1 }, squareSum) } }

(edited)

このreduce、inout版ですか？

あー、違いますね

3:18 AM

ただ、結果が Int64 なので

影響ないか

$ swift test -c release ... <unknown>:0: Test Case '-[ReducePerformanceTests.ReducePerformanceTests testForLoop]' measured [Time, seconds] average: 0.001, relative standard deviation: 45.967%, values: [0.002224, 0.000979, 0.000871, 0.000871, 0.000845, 0.000793, 0.000698, 0.000720, 0.000719, 0.000733], performanceMetricID:com.apple.XCTPerformanceMetric_WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100 ... <unknown>:0: Test Case '-[ReducePerformanceTests.ReducePerformanceTests testMapReduce]' measured [Time, seconds] average: 0.003, relative standard deviation: 55.466%, values: [0.007914, 0.002837, 0.002468, 0.002463, 0.002313, 0.002383, 0.002317, 0.002413, 0.002338, 0.002334], performanceMetricID:com.apple.XCTPerformanceMetric_WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100 ... <unknown>:0: Test Case '-[ReducePerformanceTests.ReducePerformanceTests testReduce]' measured [Time, seconds] average: 0.001, relative standard deviation: 5.212%, values: [0.000704, 0.000692, 0.000675, 0.000674, 0.000674, 0.000674, 0.000674, 0.000701, 0.000608, 0.000594], performanceMetricID:com.apple.XCTPerformanceMetric_WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100

(edited)

3:20 AM

average の有効桁数が足りない・・・

3:23 AM

↑見づらいので↓

$ swift Welcome to Apple Swift version 4.0 (swiftlang-900.0.63.10 clang-900.0.36). Type :help for assistance. 1> extension Array where Element == Double { 2. var mean: Double { 3. return reduce(0) { $0 + $1 } / Double(count) 4. } 5. } 6> [0.002224, 0.000979, 0.000871, 0.000871, 0.000845, 0.000793, 0.000698, 0.000720, 0.000719, 0.000733].mean // testForLoop $R0: Double = 0.00094530000000000015 7> [0.007914, 0.002837, 0.002468, 0.002463, 0.002313, 0.002383, 0.002317, 0.002413, 0.002338, 0.002334].mean // testMapReduce $R1: Double = 0.0029779999999999997 8> [0.000704, 0.000692, 0.000675, 0.000674, 0.000674, 0.000674, 0.000674, 0.000701, 0.000608, 0.000594].mean // testReduce $R2: Double = 0.00066700000000000006

3:23 AM

おお、単純ケースでも reduce の方が速い。

素晴らしい

UnsafeMutablePointer 使ったらどうなるだろう？

3:25 AM

お、 Range じゃなくて Array にしたら testForLoop の方が速くなった？

3:25 AM

若干だけど。誤差かなぁ。

3:26 AM

measure ってサンプル数増やす方法あるのかな？

中でfor文回す？

@tarunon それはできればやりたくないです

3:27 AM

いずれにしても map → reduce は大分遅そうですね。

n = 1_000_000 ← この数を増やすんではダメ何です？

for と reduce は大して変わらなさそう (edited)

Range じゃなくて stride だとどうです？

n = 1_000_000 ← この数を増やすんではダメ何です？

オーバーフローします

あ、なるほどw

3:28 AM

lazy.map.reduce だったら Array 作り直さずに済んで速くならないかとさっき思いました。

演算の速度調べるだけなら &+ と &* にしてオーバーフローさせちゃってもいいんですけどね。

3:29 AM

... や ..< は Array が作られてないんで大丈夫だと思いますよ。

3:29 AM

lazy より余計な処理が少なくて速そう。

3:30 AM

ああそうか、今 Range なんだから UnsafeMutablePointer もないな・・・。

そう思ってlazy.map.reduceはためしたけど少しは早くなりますよ (edited)

3:35 AM

Any calls to a function marked @_transparent MUST be inlined prior to doing dataflow-related diagnostics, even under -Onone. This may be necessary to catch dataflow errors.

3:36 AM

transparentはmust inlineで-Ononeでも効く・・・？

強い

3:36 AM

subscript とかはそうしちゃって良さそう。

そう思ってlazy.map.reduceはためしたけど少しは早くなりますよ

え、ほんとに？

はい。 @inlineable つけない状態での話しかも

ああ

3:37 AM

lazy.map.reduce か

map.reduce vs lazy.map.reduce

読み違えてた

3:37 AM

足してみます

ただクロージャがガシガシつながる感じになるから、結局命令形ループには絶対届かないと思うんで、あまり深く追わなかった

3:40 AM

@inline(__always) Force inlining (at least at -O for now).

3:40 AM

https://github.com/apple/swift/blob/643d913ffce313238132e0e90ccb8bb2e93fc826/docs/proposals/UnsupportedOptimizationAttributes.rst

https://github.com/koher/reduce-performance-test

swift - The Swift Programming Language

3:42 AM

@inline は本当にドキュメントが少ない・・・

$ swift Welcome to Apple Swift version 4.0 (swiftlang-900.0.63.10 clang-900.0.36). Type :help for assistance. 1> extension Array where Element == Double { 2. var mean: Double { 3. return reduce(0) { $0 + $1 } / Double(count) 4. } 5. } 6> [0.007428, 0.000827, 0.000812, 0.000774, 0.000730, 0.000669, 0.000670, 0.000671, 0.000672, 0.000674].mean // testForLoop $R0: Double = 0.0013927 7> [0.001285, 0.001151, 0.001017, 0.001008, 0.000957, 0.000841, 0.000824, 0.000814, 0.000818, 0.000849].mean // testLazyMapReduce $R1: Double = 0.00095639999999999993 8> [0.008967, 0.003619, 0.003361, 0.003240, 0.003070, 0.003096, 0.003307, 0.003079, 0.003139, 0.003077].mean // testMapReduce $R2: Double = 0.0037955000000000003 9> [0.001513, 0.001253, 0.001021, 0.000973, 0.000968, 0.000928, 0.000814, 0.001816, 0.001165, 0.000897].mean // testReduce $R4: Double = 0.0011348

3:42 AM

有意差あるのかわかんないけど確かに lazy.map.reduce が速い

3:43 AM

これなら lazy.map.reduce 使うことで無駄に Array も生成せず、 reduce の中にごちゃっと式を書く必要もなく、最高のパフォーマンスも得られるってことで最高なのでは。

入力が毎回違うのはなぜ？

↑は swift test で計測された時間をコピペしたものです。

3:44 AM

swift test のままだと有効数字が足りなくて

meanの性能を測ってるのかと思った。

3:44 AM

そゆことか。

テストコードは↓。

 func testReduce() { measure { XCTAssertEqual(ns.reduce(0) { $0 + $1 * $1 }, squareSum) } } func testForLoop() { measure { var result: Int64 = 0 for n in ns { result += n * n } XCTAssertEqual(result, squareSum) } } func testMapReduce() { measure { XCTAssertEqual(ns.map { $0 * $0 }.reduce(0) { $0 + $1 }, squareSum) } } func testLazyMapReduce() { measure { XCTAssertEqual(ns.lazy.map { $0 * $0 }.reduce(0) { $0 + $1 }, squareSum) } }

lazyだと無駄な関数呼び出しは発生するから sigma の中に命令ループを書くのが一番良いと思います

でも↑だと for より速いよ？ (edited)

謎ですね。

nsはなんですか？

自前ループより、標準ライブラリは最適化された何かになってるとか。

3:46 AM

private let n: Int64 = 1_000_000 private let ns = Array(0..<n) private let squareSum: Int64 = 333332833333500000

3:46 AM

あれ？ Array にしたままだった

ふむ

Range に戻してみよう

えーっと、デバッグビルドだと

3:47 AM

Rangeの場合だとなんですけど

3:47 AM

for - in を実行するために

3:47 AM

Sequence に対する protocol witnessがかかって

3:47 AM

next() の呼び出しで

3:47 AM

オーバーヘッドがあるんですよね

swift test -c release です。

リリースビルドでもそうなのかも。

3:48 AM

Sequeneに対してはmakeIteratorだから正確にはその返り値のIteratorProtocolに対するnext()

でもさっきやったときは Range でも for より reduce が速かった。

.map だとArrayに最適な内部表現になるということはありえる

そのときは lazy を試してなかった。

それだけ小さいコードでも差が出て来るのであれば、

3:49 AM

LLVMIRを見てみるか

3:49 AM

なんか良いスニペットできたらください

koher/reduce-performance-test

Contribute to reduce-performance-test development by creating an account on GitHub.

ちなみにこちらで

 var grid = Array(repeating: R.zero, count: a.rows * b.cols) for l in (0 ..< a.rows * b.cols) { let (i, k) = (l / b.cols, l % b.cols) var x = R.zero for j in 0 ..< a.cols { x = x + a[i, j] * b[j, k] } grid[l] = x }

 var grid = Array(repeating: R.zero, count: a.rows * b.cols) for l in (0 ..< a.rows * b.cols) { let (i, k) = (l / b.cols, l % b.cols) grid[l] = (0 ..< a.cols).sum{ j in a[i, j] * b[j, k] } }

を比較すると 1: 53.226 msec. 2: 348.296 msec. となって、for を使った方が全然速い感じです。

nsがArray/Range か , ループが for in か、 map.reduceか、lazy.map.reduce か、reduceだけか、があるのかな？

(sum は sigma で、中で Range.reduce 使ってます)

@Taketo Sano 僕の検証でもそうでした。Matrixのケースだと要素の型がジェネリック型になったりしてるんで、そのへんで状況が違う可能性はあるんですよね。

なるほどなるほど。

3:52 AM

とりあえず今のコードあげます。

@omochimetaru はい、その四つです。

https://github.com/taketo1024/SwiftyAlgebra/commit/2ee39ed340ceef5574b092fb906994bfea034f91 こちらです。

. · taketo1024/SwiftyAlgebra@2ee39ed

3:59 AM

Array の map の実装ってみれたりするんですかね？ここでは見当たらなかった https://github.com/apple/swift/blob/master/stdlib/public/core/Arrays.swift.gyb

https://gist.github.com/omochi/93d94ac3654f55633dc2403267e19d77

swift - The Swift Programming Language

@omochimetaru > nsがArray/Range かああ、これはどちらかだけです。 CountableRange で作ってて、たまたま Array にしてみて試してたら lazy 付けたときに戻し忘れただけです。

（一旦抜けます

）

僕と @omochimetaru もちょうど今から社内会議ですね。

なるほどw お疲れ様です

色々とありがとうございます

1

@omochimetaru ちなみに TimeProfiler で計測したときは、計測用に実行可能なアプリを作って繋いだんですよね？ (edited)

そうです、macアプリで。 https://github.com/omochi/SwiftyAlgebra/tree/inlineable/Workspace/Sandbox/SwAlSandbox.xcworkspace

omochi/SwiftyAlgebra

Contribute to SwiftyAlgebra development by creating an account on GitHub.

了解です、ありがとうございます

~~ヤバすぎる・・・~~ (edited)

5:11 AM

~~さっきの @koher のやつを試したんだけど~~ (edited)

5:11 AM

~~最適化をかけると、コンパイラーが、 lazy.map.reduce 版の実装を~~ (edited)

5:11 AM

~~forループ版の実装の呼び出しに差し替える。~~ (edited)

1

5:11 AM

01-swift-join-lzmr-for.swift

5:11 AM

define hidden swiftcc void @_T01a17testLazyMapReduceyyF() local_unnamed_addr #0 { tail call swiftcc void @_T01a11testForLoopyyFTm(<2 x i64> <i64 ptrtoint ([18 x i8]* @4 to i64), i64 17>) #0 ret void }

5:11 AM

define i32 @main(i32, i8** nocapture readnone) local_unnamed_addr #0 { entry: store <2 x i64> <i64 0, i64 10000>, <2 x i64>* bitcast (%Ts14CountableRangeVySiG* @_T01a2nss14CountableRangeVySiGv to <2 x i64>*), align 16 store i64 100000, i64* getelementptr inbounds (%TSi, %TSi* @_T01a4loopSiv, i64 0, i32 0), align 8 call swiftcc void @_T01a11testForLoopyyFTm(<2 x i64> <i64 ptrtoint ([12 x i8]* @0 to i64), i64 11>) tail call swiftcc void @_T01a13testMapReduceyyF() call swiftcc void @_T01a11testForLoopyyFTm(<2 x i64> <i64 ptrtoint ([18 x i8]* @4 to i64), i64 17>) ret i32 0 }

5:12 AM

~~main関数は、ループ版、mapReduce版、ループ版の呼び出しになる。~~ (edited)

5:13 AM

~~副作用として表示される文字列が違うが、その切替のための引数が追加されてなんかうまくやっている~~ (edited)

ってことは lazy で実装しとけば Matrix も早くなることが期待できる!?

ループ版があったからこうなったのかわからないが、lazy.map.reduceがループにコンパイルされる可能性があるってことですね。。。

5:14 AM

$ swiftc -emit-ir -O a.swift > ir.txt ビルドは←

5:18 AM

計算自体が消去されちゃったのかな、副作用ありで書いてみる

5:20 AM

あー、ちょっと変えたら分離されたんで、忘れてください

1

https://gist.github.com/omochi/0e823119a114f8412c04e708da03d5a8

swift-lazy-map-reduce-to-loop.swift

5:31 AM

ForLoopとLazyMapReduceはほぼ同じ性能で、

5:31 AM

IRを見てみると

5:31 AM

_T01a17testLazyMapReduceyyF ラベル: 30 -> 122 -> 128 -> 133 -> 140 -> 145 -> 35 -> 41 -> 46 -> 140 (edited)

5:31 AM

ラベルジャンプでのループに展開されている (edited)

5:32 AM

Intのオーバーフローチェックがガシガシ挟まってて見かけの分岐数がおおいｗ

@_specialize について調べてます。 Matrix で大規模な計算をしたいのは今の所 R=Int, _n=Dynamic, _m=Dynamic のケースなんですが、 mul をこれに特化させることはできるんでしょうか？

https://github.com/apple/swift/blob/master/docs/Generics.rst#specialization

struct S<T> { var x: T @_specialize(where T == Int, U == Float) mutating func exchangeSecond<U>(_ u: U, _ t: T) -> (U, T) { x = t return (u, x) } }

できますね。

Implement SE-0075: CanImport by CodaFi · Pull Request #11613 · apple/swift

swift - The Swift Programming Language

あ、こうか @_specialize(where T == Int, U == Float)

7:00 AM

やってみます！

swift4でその丸括弧の中の記法が変わったとかいう噂もあるんで、コンパイル通らなければ標準ライブラリの中身をgithubで検索したりして真似ると良いかも。

ktkr

original : 55.067 msec. imperative : 56.907 msec.

おおｗ

@_specialize(where R==Int, n==Dynamic, m==Dynamic, p==Dynamic) これで行けました！

7秒かかってた3次元トーラスのホモロジー群が0.7秒で出るようになった

数学が捗る

誠に感謝です

1

7:30 AM

各成分の積和の演算を Metal に投げて並列で計算させるというのもアリかと考えたりしました。

7:30 AM

全く generic でなくなりますが。

MetalもあるしAccelerateもありますね https://developer.apple.com/documentation/accelerate

7:32 AM

where付きのextensionで、特定の型パラメータの場合だけ別の実装を与えることができるんで、

前調べたときは確か Int 型の行列は対応してなかったような

Floatだったらその手のアクセラレータを使うっていうのはできます

7:32 AM

ああ、Intは無いかも・・・？

@t.ae と僕で作ってる TensorSwift では Float に限定して Accelerate を使ってますね。 https://github.com/qoncept/TensorSwift

qoncept/TensorSwift

TensorSwift - A lightweight library to calculate tensors in Swift, which has similar APIs to TensorFlow's

7:35 AM

BLAS に投げてる部分↓ https://github.com/qoncept/TensorSwift/blob/master/Sources/TensorNN.swift#L137-L152

qoncept/TensorSwift

TensorSwift - A lightweight library to calculate tensors in Swift, which has similar APIs to TensorFlow's

前に Qiita に書いてた奴ですね

↓で切り分けてて、 BLAS がない Linux 環境では通常の計算をしています。 https://github.com/qoncept/TensorSwift/blob/master/Sources/TensorNN.swift#L104

qoncept/TensorSwift

TensorSwift - A lightweight library to calculate tensors in Swift, which has similar APIs to TensorFlow's

なるほどなるほど

これのもっといいやつが swift-evolution で議論されてて

7:37 AM

どれだっけな・・・

importできるかどうかでifになるやつですね

前話してた import 可能化で

7:40 AM

そう、それ

ああ、OSじゃなくてか。

https://github.com/apple/swift/pull/11613 canImport? 8月末実装済みなのでたぶん4.1で入るかと。

This implementation required a compromise between parser performance and AST structuring. On the one hand, Parse must be fast in order to keep things in the IDE zippy, on the other we must hit the...

1

おお、それです。

7:42 AM

4.1 で入るんですね。うれしい。

7:43 AM

↓だった。 https://twitter.com/olebegemann/status/903362839380975619

Ole Begemann (@olebegemann)

Coming soon to a Swift compiler near you!

(Thanks @CodaFi_ for implementing an old proposal, accepted May 2016!) https://t.co/D4jP5eaGUJ

Likes

197

これは便利そう

7:44 AM

iOS と mac の universal 化捗りそう

4.1ってリリース春でしたっけ？

7:44 AM

https://swift.org/blog/swift-4-1-release-process/

Swift 4.1 Release Process

This post describes the goals, release process, and estimated schedule for Swift 4.1.

2018前半ってざっくりｗ

w

7:45 AM

Swift 4.1 is intended to be released in the first half of 2018.

7:45 AM

これか。

7:46 AM

まあ、 Swift 5 のことも考えたら春頃ですかね？早く canImport 使いたい・・・。

Javaみたくでるでる詐欺になる未来が

これってそんなに古い Proposal だったんだ。新しい Proposal 眺めてても見つからなかったはずだ・・・。 https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md

https://github.com/apple/swift-evolution/commit/087d3fa5034719e3c3e5076bcec9af80af04c319

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

7:49 AM

ちゃんと 4.1 で入りそう。

[SE-0075] Implemented (Swift 4.1)

[SE-0075] Implemented (Swift 4.1) · apple/swift-evolution@087d3fa

*

7:50 AM

ああ、 Status も Status: Implemented (Swift 4.1) になってた。

2016年末に一度実装されたんですが、もろもろ問題が発生して revert されたんです。https://github.com/apple/swift/pull/5778

SE-0075 Implement canImport by CodaFi · Pull Request #5778 · apple/swift

SE-0075 requests that we offer a build-time check for the importability of modules. This check, however, is particularly expensive so we can no longer resolve every condition statically. Conditio...

なるほど。↓あたりですね。 https://github.com/apple/swift/pull/5778#commitcomment-20196408

SE-0075 Implement canImport by CodaFi · Pull Request #5778 · apple/swift

SE-0075 requests that we offer a build-time check for the importability of modules. This check, however, is particularly expensive so we can no longer resolve every condition statically. Conditio...

7:57 AM

パッケージ A を import したときだけ使えるパッケージ B の機能とかもできるなら複雑そう・・・。

8:03 AM

@Taketo Sano そういえば、SwiftyAlgebraはSwiftPM対応したライブラリにはしないんですか？

@koher 最近の Swift 事情に疎くて…w 作り方知らないんですw

めっちゃ簡単ですよ。パッケージ名のディレクトリ作って swift package init ってやればひな形が完成します。

やってみます

Xcode 用のプロジェクトは swift package generate-xcodeproj でできるんですけど、

8:06 AM

ポイントは .gitignore されてることで、リポジトリには含まれず、冪等になってることですね。

8:07 AM

Xcodeのややこしい色々な設定がignoreされてるんで、いつでも generate-xcodeproj でプロジェクトを作り直せばソースだけからキレイな状態を作れます。 (edited)

8:08 AM

（厳密には冪等になってなくて上書き時に変になったことがあった気がしたんで、僕はプロジェクト消してから作り直してますが）

おそらくxcodeproj自体は作り直されているんだけど（だからxcode上で開いてたフォルダツリーが閉じ直されてだるい)

ふむふむ、ちょっとやってみます。

xcodeのビルド生成物の方がクリアされなくて

8:09 AM

前の構成のビルドの残骸が次のビルドで悪さをすることが起こってるような感じがしている

8:10 AM

安心と信頼のDerivedData全消し

なるほど。 swift package clean もイマイチキレイになってないことがあったので .build 消してる。

8:10 AM

@Taketo Sano ビルドは swift build で走って swift test でテスト走らせられます。 Xcode からもできますが。 (edited)

8:11 AM

後は GitHub にコミットすれば SwiftPM で簡単に import できるようになります。コマンドラインから使うときとか便利。

8:12 AM

公式ドキュメントは↓ですね。 https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageDescriptionV4.md

https://gist.github.com/omochi/0e823119a114f8412c04e708da03d5a8#file-z02-ir-txt-L348

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

了解です、やってみます！

1

8:22 AM

とりあえず一連の行列演算の高速化については、 1. map.reduce は一つの関数にまとめて @_inlineable 2. subscript は @_transparent 3. mul を @_inlineable, かつ R==Int の場合 @_specialize で対応することにしました。元の > 7,000 msec から 55 msec まで高速化して感動です、ありがとうございます

https://github.com/taketo1024/SwiftyAlgebra/commits/master (edited)

taketo1024/SwiftyAlgebra

Contribute to SwiftyAlgebra development by creating an account on GitHub.

3

8:24 AM

一人じゃ絶対無理だったので助かりました

100倍以上、すごい

Xcode 上で -Ounchecked でビルドすることってできるんでしょうか？

Project->BuildSettings->Optimization Level で出来たと思います

11:21 AM

ありゃ、選択肢に無いな

//:configuration = Debug //:configuration = Release //:completeSettings = some SWIFT_DISABLE_SAFETY_CHECKS

11:22 AM

Disable Safety Checks が

11:22 AM

これのことな気がする？未調査

おぉ、それっぽいですね

SWIFT_OPTIMIZATION_LEVEL (Optimization Level )にテキストで -Ounchecked と入れたらいいですよ。 (edited)

おっ、ありがとうございます

念のため、配列の外にアクセスしてみてクラッシュしなければ効いています。

無視されるようになるのは配列外参照, !, preconditionでしたっけ、他にあるかな

as!とかtry!とかもかなあ

それはなんか!の範疇のイメッジ

@Kishikawa Katsumi SWIFT_OPTIMIZATION_LEVEL = "-Owholemodule"; がはじめから入ってるんですが、別のフラグだったりしませんか？

-Oxxxx の仲間が何種類かあります

並べて書けばいいのかしら？

多分。

11:43 AM

xcodeのビルドログのところに個別のコンパイルコマンドが出ているので

11:43 AM

そこに -Ounchecked が含まれて入れば成功です (edited)

オーバーフローも無視されるようになります。

ダメっぽいですw

11:44 AM

Int のオーバーフローチェックを計算のたびやってるのがオーバーヘッドになっちゃいないかと疑ってみまして。

それはどれか１つしか書けないです。 -Owholemodule を上書きします。

そうすると whole module optimization が無効になったりはしないんです？

11:46 AM

55msec が 3.457 sec になってしまいましたw

$ swiftc -whole-module-optimization -Ounchecked -O a.swift

11:48 AM

↑これが通るので、その欄のところはそのままにして

11:51 AM

あ、ながすぎてコピペできねえ

11:51 AM

Disable Safety ChecksをYESにしたうえで

11:51 AM

Releaseビルドなら

11:51 AM

-Ounchecked が挿入されました。

おぉ

User definedに SWIFT_WHOLE_MODULE_OPTIMIZATION = YES でもOK

11:52 AM

^ SWIFT_OPTIMIZATION_LEVEL は -Ounchecked

11:53 AM

それで swiftc -incremental -whole-module-optimization -module-name TargetApp -Ounchecked -DDEBUG -D ... こうなるところまで確認しました。

おぉ、ありがとうございます。

11:55 AM

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc -incremental -module-name SwiftyAlgebra -Ounchecked -whole-module-optimization

↑ @omochimetaru さんのやり方で -Ounchecked 入りました

11:55 AM

55msec が 44msec になりました

w

結構減りますね

11:56 AM

足し算と掛け算のたびに分岐してるからか

計算の度に分岐してたらもっと減りそうだけど、それくらいしか減らないのか

分岐予測が効いてそう

if文入れるとかよりはオーバーヘッドが小さい？

12:38 PM

分岐予測ってそんなに効くのか…。

swift-lazy-map-reduce-to-loop.swift

12:38 PM

普通のbrですけど

12:39 PM

@koher 分岐予測は、分岐先の未来を投機的に計算するので

12:39 PM

予測が当たっていて、メモリアクセス待ちとかで追いつく場合だと

12:39 PM

時間的ロスが無いはず

なるほどー、待ち時間の空きで計算しておくのか。

分岐予測が失敗して無駄になった時間は、パイプラインのフェッチステージから実行ステージまでの段数に等しい。最近のマイクロプロセッサではパイプラインは非常に長く、分岐予測が失敗した場合の遅延は10から20クロックサイクルとなる。パイプラインが長くなるほど、分岐予測の精度が要求されるようになる。

1:07 PM

https://ja.wikipedia.org/wiki/分岐予測

%E5%88%86%E5%B2%90%E4%BA%88%E6%B8%AC

1:09 PM

CPU自体がパイプライン化されているから

1:09 PM

１クロックあたりの性能ってもうよくわからなくなってて

1:09 PM

スペックとかは統計的な話だったはず

https://github.com/apple/swift/pull/12531#issuecomment-338811792

[WIP] IRGen for conditional conformances by huonw · Pull Request #12531 · apple/swift

The last commit is me kinda sorta maybe guessing at what substitutions/ProtocolConformances need to be glued together, in a way that works in some cases... but doesn't even compile the standard lib...

1:56 AM

CondConfそろそろかしら

はやく！

I would like to propose the following change to the standard library: deprecate `Sequence.flatMap<U>(_: (Element) -> U?) -> [U]` and make this functionality available under a new name `Sequence.filteredMap(_:)`.

5:59 AM

Optional版のflatMapをfilteredMapに改名しようってメール来てる

6:00 AM

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040609.html

6:04 AM

struct Person { var age: Int var name: String } func getAges(people: [Person]) -> [Int] { return people.flatMap { $0.age } }

6:04 AM

mapと間違えてflatMap使いつつ Optionalアップキャストして動いちゃう話

うーん、 map と flatMap 間違えるというのは・・・ (edited)

6:06 AM

わかりづらいというのはわかる。

func getNames(people: [Person]) -> [String] { return people.flatMap { $0.name } } (edited)

6:07 AM

StringがCollectionだから↑が正当って話しも出てくるけどこっちについては英語の意味が取れなかった。。

6:12 AM

レスは賛成が多い。

map と flatMsap は使い間違えないけど、二つの flatMap がわかりづらいというのはわかるから、変更するのはなしじゃないとは思う。

これがflatMapだってわかったときはすごくわかった感があったけど

6:14 AM

すごくわかった感がある時点でわかりにくい話ではある

Optionalの暗黙キャストやめればええんやで

1

6:27 AM

レスポンスしてみようかな

それは影響範囲が大きすぎて受け入れられなさそうな気が・・・

受け入れられないのは承知の上ですが、そういう議論があるというのを認知してもらえるのが目的なので (edited)

暗黙変換絶許マンと化した @tarunon (edited)

Optional の暗黙キャストが多くの問題を招いているのは間違いないですからねぇ・・・

議論出して、同調する人がどれくらいいるのかも気になる

これが filteredMap になる場合

6:30 AM

高階型の道からは完全に外れるよね

6:30 AM

flatMapのほうはdeprecatedになるらしいし。

もう一つは

6:31 AM

Sequence.from(optional Element?)って言う変換オペレーター作って

6:31 AM

明示的に変換していくのはありだと思う

1

一旦Arrayを通すってことね

そう

$0 ? [ $0! ] : [] ←これだよね (edited)

それはちょっとあれだけどまあそう

$0.map { [$0] } ?? [] ？

そっちのほうが好き

びっくり消せた

6:33 AM

ウーム

エイヤ

とんできた

これが filteredMap になる場合高階型の道からは完全に外れるよね

これなんで？

高階型を使うことで、 OptionとArrayとみなして ArrayとArrayのflatMap みたいに実装をまとめられるんじゃないかと思ってるんだけど違うかな

7:17 AM

Array.flatMap( T -> U?)と、Array.flatMap ( T -> [U]) を、そもそも一つにできるのかなあと

7:17 AM

でも名前が変わっちゃうならまとめようがないから。

Array がモナドとすると flatMap の transform の戻り値は Array のみでないといけない（任意の Sequence や Collection ではいけない）と思う。 (edited)

うーんたしかに Promiseが戻ってきた場合とかどうにもならないなあ

今も Array に限ってないのか。

はい。いまはOptional返せる版のオーバーロードがあるよねっていうのが

7:23 AM

そもそもの話。

func flatMap<SegmentOfResult>(_ transform: (Self.Element) throws -> SegmentOfResult) rethrows -> [SegmentOfResult.Element] where SegmentOfResult : Sequence

https://developer.apple.com/documentation/swift/sequence/2905332-flatmap

7:23 AM

Array じゃないといけないのかと思ってた。

7:23 AM

戻り値が Array なだけか。

任意のElementが同じ型のSequenceなら変換可能で、その括りで行くとOptionalも変換可能なはずだ、という発想だと思う (edited)

OptionalをSequenceにしてしまえば…

やばそう

なるほどｗ

7:53 AM

Tは暗黙でT?になるから暗黙でSequenceに

map とかがヤバイですね。

@tarunon

Instead, I think Nobuo Saito is right, and that a renaming to filteredMap is only fighting symptoms, and not the cause (but I’m not that sure if there’s a good way to tackle the cause).

o

1:38 AM

嬉しい反応

symptomsって症状でcauseって原因だから、対処療法的であって根本治療ではない　って言ってる感じか

1:41 AM

nilを取り除くのに flatMap なんて名前付けるのはおかしいだろって意見に対して、↑の人が、Optionalは要素1のArrayとみなせるからなんだよって言っている

I tried to avoid renaming: https://github.com/apple/swift/pull/7823/ but then https://github.com/apple/swift/pull/9390.

一回警告出るようなパッチ当てたけど外したとのこと。

[stdlib] Adding a deprecated version of flatMap to warn misuses. by moiseev · Pull Request #7823 · apple/swift

Due to implicit promotion to optional it is possible to call flatMap with a closure, that does not return an optional. This way the code works, but is unnecessary inefficient. Such uses of flatMap ...

https://github.com/apple/swift/pull/9397

GitHub is where people build software. More than 25 million people use GitHub to discover, fork, and contribute to over 69 million projects.

1:56 AM

これはflatMap(E->T)をオーバーロードしてdeprecatedつけてるね。かしこそう。

[stdlib] Removing the deprecated flatMap overload by moiseev · Pull Request #9397 · apple/swift

The following code behaves incorrectly due to the presence of this overload. let a: Int = 1 let b: Int? = 2 let c: Int? = nil let result: [Any] = [a, b, c].flatMap { $0 } Fixes: rdar://problem/3191...

2:00 AM

やっぱり外した話がよくわからんのだけど、左辺が [Any] なのが関係あるんかな

左辺がAnyで推論されて

2:01 AM

それが伝搬して[Int?].flatMap { $0 } じゃなく [Any].flatMap { $0 }になってしまったものと思われる

2:01 AM

これに関しては一貫してArrayの暗黙キャストが悪だと訴えたい

2:02 AM

とはいえ[Int, Int?, Int]のArrayならキャスト無しなら正しくは[Any]になるはずか。

[Any].flatMap { $0 } これは、 Any から Any? へのアップキャストが生じるってこと？

いや

2:02 AM

多分このオーバーロードが存在することで

2:03 AM

[Int?].flatMap { $0 } -> [Int]これが期待される場面で、[Any].flatMap { $0 } -> [Any]が優先されるようになってしまったんだと思う

ああなるほど

2:07 AM

.someへの昇格に警告を入れてるんじゃなくて、mapのシグネチャの flatMap ( E -> T ) -> [T] を警告用に足すアイデアだったから

2:07 AM

そっちが余計に選ばられるケースが稀に存在するのか

2:07 AM

しんどいな・・・

本当だ、Optionalへの暗黙変換よりExistentialへの暗黙変換のほうが優先されるんですね〜 https://github.com/apple/swift/blob/master/lib/Sema/ConstraintSystem.h#L446-L449

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

swift - The Swift Programming Language

こんなふうになってるんですね

2:29 AM

Score::operator < で、↑のenumの若い順に優先比較している

Optionalへの暗黙変換よりExistentialへの暗黙変換のほうが優先

型システム上の辛みがありそう・・・。

2:31 AM

Any はあらゆる型のスーパータイプなので自然なアップキャストだけど、 Optional は暗黙の型変換だから、どちらが優先されるべきか議論の余地がありそう。しかも、 Swift の Optional はスーパータイプ的に振る舞うから・・・。

2:32 AM

↓ができるとことか。 let a: () -> Int = { 42 } let b: () -> Int? = a // OK (edited)

僕の議論はそれはダメでしょ警告だそうよというところ

↑も禁止して暗黙の Optional 変換も止めてしまった方がシンプルなのは間違いない。

flatMap vs map confusingもこいつが原因

Optional を tagged union で実現したのに、 untagged union のように振る舞わせるというところのヤバさ・・・。

2:35 AM

そりゃどこかに歪みが出る。

昔の言語で 1 + "2" ができて便利だと思ったけど現代では否定されているように

うん

Evolutionに突撃してくれ！

この手の型システムも硬い方がいいじゃんって話になっていきそうな気がした

やっぱこういう場当たり的な便利そうなのはやらない方がいいんだなぁ。この前の async と throws を分離しておいた方がいいのと同じように。

たるのんが突撃するんじゃないの〜

1

もうしただろ!!!

2:36 AM

でもこの場合って、Evolutionの実装作るルール的には僕がOptinonal警告作ることになるのかな

いや、この議論は、Swift6を見据えた長期計画として根本的にスレ建てして

仮に通ったとして

2:36 AM

あー

関連する全問題点を叩きつける感じじゃないと

2:37 AM

いまさら変えられないと思うよ

なるほどね

一個のトピックだけだと泥沼にしかならないと思うし、全体としての調和の問題もあるから・・・

かなり望み薄だけど、 Swift 6 を逃したら半永久的にできなさそう。

2:38 AM

暗黙の Optional 変換の廃止というトピックで。

2:38 AM

ついでに if let の構文も変えてほしいけど。

パワのあるトピック名だ

そうなんですよね if let がなんか変

ちょっと纏めてみるか

おお

てかこういうのはScala民の方が得意なんじゃないですかね @Biacco42 @ukitaka

2

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions

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

2:41 AM

よくあるリジェクト

Use pattern-matching in if let instead of optional-unwrapping:

2:41 AM

これ該当してるかな if letの話

2:42 AM

Optional implicitly promotion の話はここには乗ってないっぽそう

Use pattern-matching in if let instead of optional-unwrapping:

って、リジェクトというか普通にできるくない？ let n: Int? = 42 if case let n? = n { print(n) // 42 } (edited)

あ、リンク先のメールを見たら

↑が一番マシな unwrapping だと思うけど、 case がめんどい・・・。 (edited)

[swift-evolution] Obsoleting if let

2:45 AM

> Data point (which Chris brought up already, I think?): We tried this* and got a lot of negative feedback. Optionals are unwrapped too often for people to be comfortable writing "if let name? = optionalCondition”. Yes, I even implemented this and it was in the compiler for awhile, then later ripped it back out. You can find the history in git. I would guess that this all happened in ~March 2015. -Chris

2:46 AM

昔は if let name? = hoge という書式が書けたけど

2:46 AM

取り除いたよ　ギットの歴史で2015年以前にあるよ　クリス

2:47 AM

この話はあくまで if let とパターンマッチの並用であって、 if case let は別の話っぽいですね。

なるほど。

2:49 AM

まあ if let は if case let foo? = に入信すればいいんだけど、暗黙型変換は取り除いた方が将来のためではあると思う。その代わり初心者にはやさしくなくなるかなぁ。↓できなくなるし。 let a: Int? = 42 // NG let a: Int? = .some(42) // OK

let a: Int? = .some(42) // OK になった瞬間に null安全アンチ派がアップを始めそうだな (edited)

でも前者を許しちゃってるから最初混乱したし、やっぱ暗黙の型変換が諸悪の根源な気がする。

邪悪さにレベルがあって

2:51 AM

関数の暗黙変換が一番邪悪なので、こいつだけは絶対頃す

null安全アンチ派がアップを始めそう

Kotlinとかみたいな untagged union による null safety だったら問題にならないけどね。

()->T => ()->T?と、(T?)->() => (T)->()

union type なのか ADT なのかフワフワしてんのがいかんのかな

確かに関数の暗黙変換だけなら潰せるかも。

この二つは差し違えても頃す

それは自分でクロージャ書いて変換しろってこと？

クロージャ書くか、asで明示

なるほど。

でなければ警告

警告でいいのか

ぶっちゃけ警告で良いとは思っていて

なんかそれのせいでコンパイル遅そうだよね

2:53 AM

モナドチェーン的な時。

まあ段階踏むべきって言う話

2:53 AM

最初は警告、次にエラー

ｗｗ

2:53 AM

その次はコンパイラクラッシュで

警告に民が慣れて書かなくなってきたら廃止する

2:53 AM

それはコンパイラが負けてるからダメ

民いうなｗ

2:54 AM

はい

おや？↓はコンパイルエラーになってる。 class Animal { func foo() -> Int { return 42 } } class Cat: Animal { override func foo() -> Int? { return nil } }

2:55 AM

ああ逆か？

@objcでは

逆では？

2:55 AM

それだとAnimalとしてあつかったときになぜかnilが出る

逆だった。

逆か

返り値については継承して狭められる

class Animal { func foo() -> Int? { return nil } } class Cat: Animal { override func foo() -> Int { return 42 } }

2:56 AM

普通に通った。

2:57 AM

関数の暗黙の型変換潰すならこいつも潰さないと・・・。

継承については明示変換ができないからなあ

そもそもその継承、ウソなので殺したい

class AnimalSpawner { func spawn() -> Animal } class CatSpawner : AnimalSpawner { func spawn() -> Cat } 嘘ではないよ (edited)

↓これもいけた。

class Animal { func bar(_ x: Int) -> () { print("Animal") } } class Cat: Animal { override func bar(_ x: Int?) -> () { print("Cat") } }

お、Javaではできないやつですね

いや、 Optional はスーパータイプじゃないから嘘。

引数側コントラバリアンス

2:59 AM

あ〜そういういみか。

T?がTのサブタイプがウソなので継承は出来ないという論調

なるほど。

T?がTのサブタイプがウソ

これにつきる

3:03 AM

逆？

TがT?のサブタイプなんじゃね

ですね

ウソがウソになってる

すまん

ややこしい

にしても T? と T は別の型なのでどう考えてもおかしい

プロポーザル書こう

殺すなら Optional 暗黙変換すべて殺すほうがという気持ちなので厳しい…

3:08 AM

nullability っぽい振る舞いとごちゃまぜなんだなぁ

@Biacco42 その通りなんだけど、 Kotlin 等の言語では T? が T のスーパータイプは正しいんよね。で、 enum になっててネストできるとこと、スーパータイプでアップキャストで代入できるとこと、両方のいいとこ取りをしようとしたから歪みが出てる。

3:10 AM

nullability っぽい振る舞いとごちゃまぜなんだなぁ

同じこと言ってた

3:11 AM

Kotlin の Any? が Any のスーパータイプなのも闇を感じるけど・・・

1

ですね

Ceylon だと T? は T のスーパータイプだけど Anything がトップタイプ（すべてのスーパータイプ）になっていて素晴らしい。

3:13 AM

Anything が sealed でサブタイプが Object or Null に限定されていて、 T? は T|Null のシュガーだから、 Anything? == Anyhing|Null == Anything になる。

Ceylon は Union type あるのかそういえば

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

Array<Array<Element: Equatable>> に対する extension って書けないですか？

最近思ってたけどそれ書けない気がする。

仕組み上できるかどうかより、構文が足りてない気がする。

extension A where E == String {} はできるけど extension A where E == Array<T> {} ができない

9:46 AM

== の右辺に、ジェネリック型を書けない。

extension Array where Element: Equatable これとは違うんですか？

extension A where E == Optional<T> とか。でも、プロトコルにしてやればいけるから、 @koher のケースは Element : Sequence じゃだめ？

extension の構文って変で、↓のようであるべきな気がする。 extension Array<T> where T: Equatable { ... }

ジェネリックパラメータ付きエクステンションは Generic Manifesto に乗ってますよ。

9:48 AM

実装待ち・・・

@Kishikawa Katsumi あ、これそのものがやりたかったというわけではなく、似たようなケースの extension が書きたくて、一般的にこういうことってできなさそうだなぁと。

あ、そうじゃないのか、それは Array自体の<T>か。

9:48 AM

その表記だと <T> 冗長じゃないですか？ Array < >の型パラは .Element でアクセスできるから

// 今 extension Array where Element: Equatable { ... } // 望ましい形 extension Array<T> where T: Equatable { ... } じゃないかと。

9:49 AM

↑ができるなら

9:49 AM

extension Array<Optional<T>> where T: Equatable { ... }

9:49 AM

とかもできる

そういうふうに直さなくても

9:50 AM

extension Array where Element == Optional { }

9:50 AM

これで既存構文と調和した仕様にできる

あと、この記法の良いところは型パラメータ名が変更されてもコードの修正が必要ないこと。

swift - The Swift Programming Language

9:51 AM

↑Parameterized ExtensionとしてGeneric Manifestoに出てくる。

Swift 1 から 2 のとき（だっけ？）に Optional<T> から Optional<Wrapped> に変更されて死体の山が。

うーんでもそれだと

9:51 AM

型パラ5つとるジェネリック型において

9:52 AM

第2型パラにしかconstraintで言及しない場合に

なるほど

9:52 AM

確かに。

第1, 3, 4, 5が冗長で

9:52 AM

SwiftのプロトコルvsJavaのジェネリクスの初期の議論に戻る気がする。

extension Array where Element: Sequence, Element.Element: Equatable { }

@norio_nomura それでいけますよね

Optional だとダメですよね？

ただ、 Sequence プロトコルは書けるけど、 Array にはできない

9:53 AM

Optionalもプロトコルじゃないからだめで

今本当にやりたいのは自作のジェネリック構造体なので・・・。

OptionalProtocol ハックが必要

9:53 AM

自作のジェネリック構造体のケースならそれのプロトコルも定義すればいけますよ

そうするとライブラリにそのためだけの不要なプロトコルが増えてしまう・・・

なるほど。

9:55 AM

その場合extensionを諦めてトップレベル関数で・・・

Parameterized extensions を待つしかないか・・・

9:56 AM

すべて gyb で解決したくなってきてよくない。

今の話しGYB役に立ちます？

現実的な組み合わせが列挙できる場合は

あ〜

9:57 AM

Uを焼くのか。

プロトコルの制約やめてすべて書き下してしまえばいい

typealias NestedArray<T: Equatable> = Array<Array<T>> extension NestedArray { static var test: String { return "test" } } NestedArray<Int>.test // "test

？！

10:03 AM

これ裏技では？

ウッソｗｗｗｗｗｗ

↑ができるなら Parameterized extensions すぐ実現できそう・・・

え、なにこれは

typealias OptionalArray<T> = Array<Optional<T>> extension OptionalArray { func filterNil() -> Array<T> { // use of undeclared type 'T' return flatMap { $0 } } }

10:06 AM

だめだ〜

10:06 AM

typealiasの左辺についてる型パラメータがルックアップできない

typealias OptionalArray<T> = Array<Optional<T>> extension OptionalArray { func flatten() -> Array<Element.Wrapped> { return self.flatMap { $0 } } }

10:07 AM

だめだった

alias右辺の型名も拾えないのか

10:07 AM

惜しいっ・・・

Sequenceだとinitが生えて無くてArrayにできないけど

10:24 AM

Arrayを構成してるprotocolのうちのどれかがinit定義してるんで、それで縛れば生成可能になる

話がみえない

ただ 、 Sequence プロトコルは書けるけど、 Array<U> にはできない Optionalもプロトコルじゃないからだめで

10:26 AM

これだけ見てinitがしたいのかなって思った

なるほど

10:28 AM

Array ってのは

Array<Array<Element: Equatable>> に対する extension って書けないですか？

の内側のArrayのことで、具体的に何がしたかったのかは気にしていなかった

なるほど

Array < Array <> > の場合ならSequenceでいいけど、koher が聞きたかったのはそもそも Arrayの話じゃなくて、一般系としてArrayをあげただけだった

typealias NestedArray<T> = Array<Array<T>> where T: Equatable コンパイル通るけどwhere句働いてないな

なんやそれw

typealiasにwhere句書いても働かない、単純に書いても通るのはバグか

パーサーがガバく拾ってるだけみたいなやつかな

ぽい

Tへの制限にはなってますね。

let a = NestedArray<Array<Int>> // error: type 'Array<Int>' does not conform to protocol 'Equatable' // let a = NestedArray<Array<Int>> // ^

生成時だけか

11:39 AM

え

11:43 AM

typealias NestedArray<T> = Array<Array<T>> where T: Equatable extension NestedArray { var hello: String { return "hello" } } [[(), ()], []].hello // OK!! let x: NestedArray<Void> = [[(),()],[]] // compile error

11:43 AM

草

なるほどw

NestedArray<Void>は存在できないが、extensionは正常に判定されていない

11:46 AM

ん

11:46 AM

typealias NestedArray<T> = Array<Array<T>> where T: Equatable extension NestedArray { var hello: String { return "hello" } } [1, 2, 3].hello // OK!! [[(), ()], []].hello // OK!!

11:46 AM

オイオイオイオイ

11:47 AM

これはとんだ嘘つきextensionですね、

11:47 AM

typealiasのextension書けるのがバグっぽいな

11:51 AM

つまり、

11:52 AM

extension NestedArray // これはウソでコンパイラはextension Arrayと解釈していて where Element.Element: Equatable // 当然ArrayはElement.Elementなんて持ってないのでコンパイルエラー

ということか (edited)

夕食食べて風呂入りながら↑使ってもしかして Conditional Conformance もどきができないかと夢見てたのに完全に打ち砕かれてた。

1

これが動くならParameterized extensionsも動いてるはずだよね

ですよね。

↓ってなんでできるんですっけ？ (+)(2, 3) // 5 今って+ って関数じゃなくて static func ですよね？

()で括るとinfixが消えてただの二引数関数になる？

逆に Int.+(2, 3) とか Int.(+)(2, 3) とかできないんですが、明示的に型指定して static func な演算子にアクセスする方法ってありますか？

(+) as ((Int, Int) -> Int)

2:09 PM

これかな？

2:09 PM

ちょっと手元に手頃なコンパイラがない

はい、 infix func を () で囲んで識別子化は Swift 1 の頃から出来たんですが、

2:09 PM

static func になった今でもできるのが不思議なのと、逆に static func っぽくアクセスする方法が見つからないのと。

嘘つきエクステンションわろた

↓はできました。一応これで指定できるのか。釈然としないけど・・・。 ((+) as (Int, Int) -> Int)(2, 3)

オーバーロードした関数/変数をそれとしてアクセスするときにasで明示できるので、応用できそうだと思ったけど正解だった

(Int, Int) -> Int な + は↓これだと思うんだけど、演算子は static func として宣言されても global な funcのように振る舞うのかな？よく考えたら 1 + 2 だってどうやって static func として解決されてるのかよくわからないし。 https://developer.apple.com/documentation/swift/numeric/2884921

operatorはstaticになってもglobal扱いぽいですね

2:14 PM

コンパイラが頑張って展開してそう

2:15 PM

Equatableが中外どちらでも書けるので、両方統一して解釈してるのかなーと思いました

昔、 global から static func に変える Proposal ありましたよね、確か。

ジェネリックなときに少しタイピング量が減るのかな

型パラを共通化できるから減る

そういう意図で書いた↑

ネストした型と同じメリットだ

使うときの名前解決がトップレベルと変わらないなら定義するときにちょっと便利ってぐらいだよなあ

でこの延長線上に、recursive constraintがありそう

書いたンゴ http://twitter.com/omochimetaru/status/923205730064220161

SwiftのOptionalのベストプラクティス - Qiita

#swtws の発表内容を記事にしました。 > Swift に導入予定の Ownership 機能の紹介 by @omochimetaru on @Qiita https://t.co/6BZVoKs1mg

5

Swift って a -1 ってエラーになるのか。

$ swift Welcome to Apple Swift version 4.0 (swiftlang-900.0.63.10 clang-900.0.36). Type :help for assistance. 1> let a = 42 a: Int = 42 2> a -1 error: repl.swift:2:2: error: consecutive statements on a line must be separated by ';' a -1 ^ ;

2:00 AM

a - 1 じゃないといけない。

a-1 はいけませんか？

prefixにかぎらず二項演算はぜんぶそうですね。

a-1 はいけると思う。

ですよね

いけた。 2> a-1 $R0: Int = 41

a -1 は実際、 a と -1 が、演算子無しで並べられているように見えるし、良いルールだと思ってる (edited)

そうだね。

2:01 AM

今 typo でスペース入れ忘れたのが検出された。

obj-c - (void)setupCellWithEntry:(id)object isRegistered:(BOOL)isRegistered labelTitle:(nullable NSString *)labelTitle labelSizeText:(NSString *)labelSizeText {

cell.setupCell(withEntry: entry, isRegistered: isEntryRegistered, labelTitle: labelTitle, labelSizeText: labelSizeText) どうでもいいことだけど、SwiftよりもObj-Cの方が好きな数少ないところの一つは関数を引数ごとに改行するときに、Obj-Cは : の場所を合わせてくれるのがいいと思うんですよね、Swiftの左寄せよりは

あー、 : が揃うのは僕も好きだった

第一引数より前で改行した方が好き

2:50 AM

インデントが揃う

そう言うXcodeのプラグインとかないかね

(と第一引数の間に改行

cell.setupCell( withEntry: entry, isRegistered: isEntryRegistered, labelTitle: labelTitle, labelSizeText: labelSizeText) こんな感じ？

後ろの括弧も改行っすね

なるほど

他のIDEだとそういう改行ポリシー結構カスタマイズできたりするけどね

引数にクロージャ入れたときに、クロージャの閉じ括弧のインデントが揃えばかなり綺麗なんだけど、そこだけ汚くなるから手で治しがち

メソッドの. の前で改行するといいかんじになるよ (edited)

UIView.animate( withDuration: duration, delay: 0.0, options: .curveEaseInOut, animations: { self.alpha = 0.0 }, completion: { _ in self.isHidden = true } )

本当はこうしたい

2:56 AM

これ.前で切ってもクロージャの閉じ括弧は崩壊する

クロージャが短ければワンライナーで終わらせる（）

まあそれはw

2:57 AM

UIView.animate( withDuration: duration, delay: 0.0, options: .curveEaseInOut, animations: { self.alpha = 0.0 }, completion: { _ in self.isHidden = true } )

なおXcode君激オシのインデントはこれ

2:57 AM

ちょっと。。。ね。。。

import UIKit let duration = Float(1.0) UIView.animate( withDuration: duration, delay: 0.0, options: .curveEaseInOut, animations: { print(1) }, completion: { _ in print(2) })

XcodeのSwift用Editorは本当バカな子だよな

こうやって、クロージャの綴じカッコを、最後の文にくっつけると

2:58 AM

きれいになるよ。

ないっしょw

いやでも、このルールのもとなら

2:58 AM

そもそも閉じてるかどうか気にする必要ない

2:58 AM

インデントがきれいなら閉じてるってことだから。

なるほどな

僕も開きカッコ後と閉じカッコ前改行派だなぁ。

Xcode君のインデントにコントリビュート出来ないかな

Xcodeのインデントきれいになるには↑みたいなコツがいくつかあるけどマスターすると結構いい感じ

3:02 AM

コピペすると自動インデントされたりするから、手でスペース入れて直したりしてもそういうので壊れちゃうから

3:02 AM

もうXcodeに魂をうることにした

えー

3:02 AM

Xcode のインデントは耐えられない。クロージャ周りひどいし。

わかる >クロージャ周り

AppCodeってそのへんどうなんですかね

3:03 AM

idea見てる限りだと期待できそうですが

そういえばみなさん guard の条件文が長くて改行するときのインデントってどうしてますか？

長くしない方法考えてる

例えば guard let a = a, let b = b, let c = c else { doSth() } みたいな

guard let xxxx, let xxxx, fooIsEnabled else { .... } こんな感じ (edited)

3:07 AM

else忘れてたわ

var a: Int? = nil var b: Int? = nil var c: Int? = nil func main() { guard let a = a, let b = b, let c = c else { print(2) return } }

3:09 AM

いまいじったらこうなった

なるほど

3:11 AM

guard 文もなかなか改行が難しいよな…

２行以上の文のときは { を冒頭に持ってくる派

最近は guard let a = a, let b = b, let c = c else { return } のようにしてます

3:12 AM

let 揃えるべきかなやむｗ

悩ましいですね。 guard が 3 文字だったらよかったのに・・・。

3:19 AM

guard の後で改行とか？

なんかそこまで行っちゃうともはや神経質なレベルなんじゃないかと思って()

そんなあなたに guard let a = a , let b = b , let c = c else { print(2) return }

ww

guard let a = a , let b = b , let c = c else { print(2) return } これで完璧！ｗ (edited)

↓とかもできるし、 guard 後改行でもいい気が。 let a = 42 let b = 99 if a >= 0, a < 100, a != b { print(a) }

3:23 AM

惜しいのは、最後のa != b の後に , が書けないこと。

3:23 AM

↑の前カンマ、マジレスすると if let がダメ・・・。

前カンマは割りとアリで、型パラのcondition書くのにも使ったりする

3:31 AM

class Foo<X, Y>: SuperFoo where X: Sequence , Y: Collection ... { ... }

3:31 AM

こんな感じ

カンマ後ろでインデントはダメですか？

前カンマの方がXcodeの破壊レベルが低かった気がする

class Animal {} class Cat<X, Y> : Animal where X: Sequence, Y: Collection, X.Element == Y.Element {}

3:33 AM

↑オートインデント

ありゃ、結構ちゃんとしてますね

class Animal {} class Cat<X, Y> : Animal where X: Sequence, Y: Collection, X.Element == Y.Element {} where出すとこんな感じ

guard 後改行いい気がしてきた。 let a: Int? = 2 let b: Int? = 3 guard case let a? = a, case let b? = b else { fatalError() } print(a + b) // 5

3:38 AM

初めて case let 複数書いた。

実際そういうケースだとどっちがnilだったのか fatalErrorのメッセージとか、デバッガの停止位置でわかりやすいから、guard自体分けちゃう事が多い

3:39 AM

まとめて書いておくといざそこにヒットしたときに、さてどっちがコケたんだっけってなって面倒だ

そもそもguard でfatalErrorはアンチパターンなので葉という気がしている

3:40 AM

それなら!使ったほうがマシ

いや、今 fatalError は

3:40 AM

別に return とかでもいいんですが

でもfatalERrorのほうがメッセージが仕込めるよ

optInt !! "xxxx" これがあればいいな

ああ、そうだねｗ

3:41 AM

それは賛成。

トップレベルだったのでそうしただけで意味はないです。

何もしないで脱出する場合でも

3:42 AM

なぜか何も起こらない→バグで早期脱出に流れてそう

3:42 AM

っていうデバッグ作業は生じるので同じ気もするけど、メッセージとかは無いから処理は共通化したい度は高いな

"複数のOptionalをまとめて処理したくなったら要注意" https://qiita.com/koher/items/8b6156c8263b9b23c43c#%E8%A4%87%E6%95%B0%E3%81%AEoptional%E3%82%92%E3%81%BE%E3%81%A8%E3%82%81%E3%81%A6%E5%87%A6%E7%90%86%E3%81%97%E3%81%9F%E3%81%8F%E3%81%AA%E3%81%A3%E3%81%9F%E3%82%89%E8%A6%81%E6%B3%A8%E6%84%8F

それでは、『SwiftのOptionalのベストプラクティス』というタイトルで発表します。...

↑全部書いてあったｗ (edited)

// の後の絵文字がイタリックになってるの超ウケるんだけどｗｗｗｗｗ

1

// :thinking:

絵文字のイタリックあるんだｗ

4:06 AM

↑の投稿で自分で書いたコードが↓になってた。 guard let a = ..., let b = ... else { ... } let sum = a + b

4:07 AM

まあ、発表（投稿）のためだから、コードがぱっと見でわかりやすいためにはこのインデントも仕方ないけど。 (edited)

えー、↓これできないの？

struct Foo<T> {} extension Foo where T == Int { typealias A = Int64 } extension Foo where T == Float { typealias A = Double }

え、できないですっけ？

4:45 AM

typealiasのところ？

error: repl.swift:8:15: error: invalid redeclaration of 'A' typealias A = Double ^ repl.swift:4:15: note: 'A' previously declared here typealias A = Int64 ^

redeclarationだ

Aをassociatedtypeにしてそれぞれのsubprotocol作って…となりそう

最初のSwift 4.1スナップショットswift-4.1-DEVELOPMENT-SNAPSHOT-2017-10-25-aが出た (edited)

@koher

protocol FooParameterProtocol { associatedtype X } extension Int: FooParameterProtocol { typealias X = Int64 } extension Float: FooParameterProtocol { typealias X = Double } struct Foo<T: FooParameterProtocol> { typealias A = T.X }

↑同じ事考えてた

辛いｗｗ

5:30 AM

↑ができるのになんで元のはできないんだろう？

typealias が定義できる場所が型ネームスペース的な場所になってしまっているんでしょうね

5:31 AM

extensionスコープにはなっていない

それって Sema がそうなっているというだけで対応することに特に問題はない？ (edited)

む、もしかして別ファイルだと出来たりします？＜ extension毎typealias

別ファイル・・・やってみます。

それって Sema がそうなっているというだけで対応することに特に問題はない？

いや、後者の例だと、FooはどんなTでも T.A があることになっているけど

5:33 AM

前者の例ではあくまでIntとFloatの場合だけの話しで、 String のときに T.A があるかはかわらないから

5:34 AM

意味も違う話だと思う。

違いがあるのはその通りだけど、できないのが意図的なのかがわからない

そうですね。

複数ファイルダメでした。 https://github.com/koher/experiment-alias-in-extension

koher/experiment-alias-in-extension

Contribute to experiment-alias-in-extension development by creating an account on GitHub.

1

public struct Foo<T> {} extension Foo where T == Float { private typealias A = Double } extension Foo where T == Int { private typealias A = Int64 }

private だと別ファイルと同ファイルで挙動がちがう。これは SE-0169 の副作用っぽいです。 https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

https://bugs.swift.org/browse/SR-6234

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

private だと互いに不可視だからエラーにならなくていいんじゃないですか？ (edited)

6:12 AM

可視のときにエラーになるのが意図的なのかがよくわからないです・・・。

https://bugs.swift.org/browse/SR-5392 意図が違うかもだけど、一応似たようなイシューとしては登録されているみたいです。 (edited)

6:23 AM

（母体にも同名のtypealiasがあるパターンだから違う）

ありがとうございます。ちょっと違うけど、これ考えるときについでに考えるかもしれませんね。

Swift 4.1にはswift formatとか付いてるのね。

$ TOOLCHAINS=org.swift.4120171025a swift format --help OVERVIEW: Swift Format Tool USAGE: swift [options] <inputs> OPTIONS: -help Display available options -in-place Overwrite input file with formatted file. -indent-switch-case Indent cases in switch statements. -indent-width <n> Number of characters to indent. -line-range <n:n> <start line>:<end line>. Formats a range of lines (1-based). Can only be used with one input file. -o <file> Write output to <file> -tab-width <n> Width of tab character. -use-tabs Use tabs for indentation.

2

マジ！

Xcodeとはちょっと違うインデントになるぽい。

それはどうなんだｗ

ゴゴゴ

9:45 AM

Xcodeがそれ参照してくれるのが平和への道

だね

Xcode も iOS も SwiftPM の世界では二級市民だから・・・（ iOS は三級か？）

これXcodeのBuildScriptに差し込んで

9:47 AM

無限にformat直させ合うか

Xcodeつかうのやめたほうがかしこそう

#if swiftとかで条件が外れる箇所のインデントが崩れるのはXcodeと同じみたいだから、常用するのは難しそう。

9:50 AM

#ifでインデントが深くならないのがXcodeとの最大の違いかな。 (edited)

xcodeでも

クロージャ式の閉じ } が気になる

importはインデント深くなるけど

9:51 AM

classの中のfuncとかはインデント変わらないような気がする

9:51 AM

#if os(iOS) import UIKit #endif class Cat { #if os(iOS) func nya() { } #endif }

9:51 AM

//xcodeだとこうなる↑

#if os(iOS) import UIKit #endif class Cat { #if os(iOS) func nya() { } #endif } (edited)

9:54 AM

行をまたいだフォーマットはしないぽい。

9:55 AM

まあ、気になる人はスナップショットswift-4.1-DEVELOPMENT-SNAPSHOT-2017-10-25-a出てるから試して。 (edited)

7種類の@conventionのうち、.swiftで使えるのは3種類だけでした。

let thin: @convention(thin) () -> Int = { 1 } //let thick: @convention(thick) () -> Int = { 1 } // error: convention 'thick' not supported let block: @convention(block) () -> Int = { 1 } let c: @convention(c) () -> Int = { 1 } //let objc_method: @convention(objc_method) () -> Int = { 1 } // error: convention 'objc_method' not supported //let method: @convention(method) () -> Int = { 1 } // error: convention 'method' not supported //let witness_method: @convention(witness_method) () -> Int = { 1 } // error: convention 'witness_method' not supported

1

使えるというか

2:48 AM

methodとかは cat1.eat

2:48 AM

とかで取り出せるんじゃないですかね？

2:48 AM

ラムダ式に明示する形で生成できるかっていう視点だと条件が変わってしまっていると思う。

そうですね。

結局取り出そうとしたらまさかのコンパイラが死んだか・・・

1

レポートがめちゃシンプルで良い・・・

ちなみにfuncをdumpするとシンボルとか見られる

 1> struct S { func f() {} } 2> dump(S.f) - (Function) $R0: (S) -> () -> () = 0x00000001000fca30 $__lldb_expr4`partial apply forwarder for reabstraction thunk helper from @escaping @callee_owned (@in __lldb_expr_1.S) -> (@out @escaping @callee_owned (@in ()) -> (@out ())) to @escaping @callee_owned (@unowned __lldb_expr_1.S) -> (@owned @escaping @callee_owned () -> ()) at repl3-18ad44..swift

ほー

こんな古くからあるバグだったとは… https://bugs.swift.org/browse/SR-75 (edited)

そもそも P.method(object) みたいなのも出来ないですよね

oh duplicateついてた

3:47 AM

JIRAって「ウォッチしてる課題一覧」ってどこで見れるんですか？

https://bugs.swift.org/browse/SR-6234?filter=10506

このクエリは複雑すぎるためベーシックモードでは表示できません・・・

ぬぬ

ああいや、表示自体はできていますが

3:50 AM

アドバンスモードでこのクエリーを手打ちするしかないってことでいいですか？

3:51 AM

norioさんはいまこの watcher = currentUser() ORDER BY updatedDate DESC を手打ちしたんですか？それともどこかにリンクある？

⭐ つけるとFAVORITE FILTERSに載ってくる

お。

filter自体はPopular Filters https://bugs.swift.org/secure/ManageFilters.jspa?filterView=popular で見つけた (edited)

なるほど。

3:52 AM

ありがとうございます、とりあえずこれで自分は助かります。

3:52 AM

そこにあって人気ってことは、基本的に一度はカスタムで作るのか・・・すごい不便なウェブアプリだなあ

https://twitter.com/slava_pestov/status/923752360299528192 古ーいバグはもはや仕様と割り切れと。

https://qiita.com/omochimetaru/items/5d26b95eb21e022106f0

@griotspeak It should say “fixing long standing bugs in the compiler is not a priority; enjoy these new features instead

1

ひどいw

ちょっと意味違うかｗ

ツイッター上でめっちゃ話続いてるなあ

Swift の Type Erasure の実装パターンの紹介 - Qiita

Type erasure

swift では protocol を使うのが人気です。ある protocol を満たす複数の型があるとき、それらのどれでも代入できる互換性のある型が欲しくなることがあります。そのような型を type ...

1

8:12 AM

この前の話題の件をまとめました

8:12 AM

この記事の内容は Discordのみなさん と、特に @rintaro#5593 に教わりました。ありがとうございました。

(edited)

8:12 AM

謝辞も書きました。

最終的に全部 class にしているのは、クロージャ方式が大きくなりすぎるから？

それもひとつです。 structだとそれ自体が強参照ポインタのように振る舞うので、weakで使いたい場合を考えると面倒なのと、 structだとprotocolのmutating指定も絡んで複雑になるのでシンプルにしたかった。

なるほど。

class だと「シンプルプロトコル」で existential でないといけない理由がわかりづらいような・・・

1

8:47 AM

Java の interface と class のノリで考えてしまいそう。

でないといけない、とは？

8:50 AM

シンプルプロトコルの場合は載せてる方式の3つのどれでもいけますよ

Java のノリだと interface は型でただの interface 型の変数はただのポインタだから、一番最初の説明で AnimalProtocol に Cat 入れるの見て、前知識がない人だと existential って何？ interface と違うの？ってなりそう。

8:52 AM

struct だとそのまま抽象的に扱えないから interface との違いに気付くきっかけがある。

こんなことしないでclass Animalでええやん、って話か。

// Java interface Animal {} class Cat implements Animal {} Animal animal = Cat(); ↑と同じように見えてしまうってこと。 (edited)

そのレベルの人にTEの必要性や利便性を説得することは目的としていなくて、実装しようとして困った人にむけてた(過去の自分

8:56 AM

２つ前のトライSwiftでエニーポケモンがさんざんバズったし、、、

8:56 AM

もうそこはいいかなって。

他の言語には習熟してるけどこれから Swift を始める人とかは？

8:59 AM

いやまあ、どこで線を引くか次第だからそれでもいいんだけど、これだと Swift プログラマの数%（ここに参加してる人が母数なら数十 % になるだろうけど）以外は最初でコケちゃいそうだなぁと。

8:59 AM

まあ、 struct にすることで気付きが得られるのもわずかかもしれないけど・・・

最近 @hiragram と話してて指摘されたんだけど

はい

初心者 is 何問題か

そもそも「他の言語は習得してるけどswiftは初心者」

9:00 AM

っていう初心者像自体かなりバイアスだって

9:00 AM

話があって

9:01 AM

「まともにやり始めたのがswift、Javaとかしらん」っていう (edited)

9:01 AM

人がたくさんいると思うって話もあり・・・

1

9:03 AM

Javaの常識からSwiftのモダンパラダイムへって論の流れだと逆にハードルが上がって余計わからなくなる説がある

func spawn() -> Self { return type(of: self).init() } これ return Cat() じゃダメなんだっけ？

final class Catならそれでオーケー

9:06 AM

もしくはstruct

ああ、なるほど。

9:07 AM

だから required なのか。

classだとrequired initと合わせてそうなる

9:07 AM

もしくはreturn selfでもいいけどspawnの例としては変なのでそうなった

あれ？ Self.init() ってダメだったっけ？

あ、それは試してないです。後で試してみます。

TempGround.playground:8:16: note: did you mean 'self'? return Self.init() ^~~~ self

そか、protocol extension内でしか使えないか。

1

MLにスタッククラスという機能の話題が出てて、それって moveonly struct じゃダメなんかな、と思いつつ眺めてたら、 John McCall がそう返信してた。

Move-only struct types will be able to provide deinit. See the ownership manifesto.

1

2:01 AM

[swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics ラトナの返信

In short, I think we should build a simple Swift/Python interop story.

 let np = Python.import(“numpy”) // Returns a value of type Python.Object. let a = np.array([1, 2, 3]) print(type(a)) // Whether we want to support type(x) or use the Swift equivalent would be up for discussion of course! print(a.shape) print(a[0], a[1], a[2]) a[0] = 5 print(a) let b = np.array([[1,2,3],[4,5,6]]) print(b.shape) print(b[0, 0], b[0, 1], b[1, 0])

Swift の += 等の左オペランドが inout だけど & が要らないのってなんでなんですっけ？演算子の場合は & 不要？ (edited)

var a = 1 a += 1 (+=)(&a, 1)

8:47 AM

演算子で省略してくれるんじゃ

左オペランドのみ？

のみとは？

右オペランドが inout だとどうなるんだろう？

http://blog.sorausagi.org/2017/10/swift-objective-c.html

Swift と Objective-C どっち選ぶ？

なぜ多くの開発者が今なお Swift よりも Objective-C を好むのかの記事を読んだ。私は、言語にあまりこだわりがある方ではなく、使えればなんでもいいやタイプ。そんな私でさえ、「あー、そうよなー」と共感してしまった所があった。 WWDCのセッションで...

8:48 AM

今後、Swiftライブラリをアプリに含めなくても良くなる (= Objective-Cと同等レベルの言語として格上げされる) 予定があるのか？ないのか？をホント、知りたい。

公表してくれると嬉しいが、オトナの事情もあるだろうし難しいんだろうな....。

これは予定はあるんじゃないですか？

^ ABIが安定してしばらく経ったら必要なくなるよと教えてあげたいけど、コメント書けないっぽいし、コンタクト先もわからない。

ABI安定化すれば。

誰か知ってる人いないかなー、っていう。

infix operator +=+ func +=+(lhs: Int, rhs: inout Int) { rhs += lhs } 1 +=+ a

Swift の += 等の左オペランドが inout だけど & が要らないのってなんでなんですっけ？演算子の場合は & 不要？(編集済)

そう

@t.ae おお。

もしそこが厳格なら通常の代入文も・・・

あ、flaskappの人か。じゃあ知り合いがいた。

右がinoutってできるんだ

@omochimetaru いや、そうなんだけど、どこかに名言されてたかなぁ？とふと思って。

じゃあ += にかぎらず一般のオペレーターで inout 自動付与か

オペランドの右左も関係なさそうだね。

8:51 AM

演算子でラベルがいらないのと同じ特別扱いか。

両方inoutでも両方省略できました。

8:52 AM

ユースケースが思いつかない

ラベルも付けれない。

 1> infix operator +- 2. func +-(lhs: Int, rhs: Int) -> Int { 3. return lhs + rhs - 1 4. } 5> (+-)(2, 5) $R0: Int = 6 6> (+-)(lhs: 2, rhs: 5)

8:54 AM

 1> infix operator +- 2. func +-(lhs lhs: Int, rhs rhs: Int) -> Int { 3. return lhs + rhs - 1 4. } error: repl.swift:2:9: error: operator cannot have keyword arguments func +-(lhs lhs: Int, rhs rhs: Int) -> Int { ^~~~ error: repl.swift:2:23: error: operator cannot have keyword arguments func +-(lhs lhs: Int, rhs rhs: Int) -> Int { ^~~~

8:57 AM

@Kishikawa Katsumi 見つけました。 https://twitter.com/aqubi

Hideko Ogawa (@aqubi)

IOS App Developer. co-founder of http://flaskapp.com/. I love gadget, rabbit, making new things.

Tweets

12356

Followers

1087

@koher すばらしい。ありがとうございます。

1

ABIの安定化ってそんなに難しいのかな全然中身を知らないからわからない

基本的にはヒープ上の関数呼び出しのときの型のメモリレイアウト、例外仕様とかですね

1

1:37 AM

最適化したときの挙動と、モジュール跨いでも安全な冗長な挙動あとはasyncとかオーナーシップとか、言語本体機能が定まらないと、それのABIも決まらないから

1:38 AM

「この機能はABIに影響与えるから早く話し合いたい」ってだいたいの提案に書いてありますよ・・・

なるほど

1:38 AM

まだその辺のベースが定まらないってことなのか

1:39 AM

定めちゃうと変更できなくなるし

そうですね。やることリストはこれ https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

https://github.com/apple/swift/pull/12500#discussion_r147789502

swift - The Swift Programming Language

[WIP] [IRGen] Improvements to function type metadata by xedin · Pull Request #12500 · apple/swift

Currently only single 'inout' flag has been encoded into function metadata, these changes extend function metadata to support up to 32 flags per parameter.

2:01 AM

↑関数型のmetadata（多分metatypeのこと？)の改善PRとかWIPだし多分これもABI周り

2:02 AM

Conditional conformanceとかもあるか。その条件付きwitness tableをシリアライズしないといかんし

ABI stabilityの状況はこっちの方がわかりやすい？ https://swift.org/abi-stability/

dump ConventionAnyObjectExample.swift

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

お、これは良いですね。前見たけど忘れてた。

Any型の値があるときに、それがclass型なのか値型なのか判別する方法

8:47 AM

class Cat {} struct Dog {} let cat = Cat() let dog = Dog() func checkIsClassValue(_ arg: Any) -> Bool { return (arg as AnyObject) === (arg as AnyObject) } checkIsClassValue(cat) // true checkIsClassValue(dog) // false

こういうの考えてるんですが、もうちょっと効率いい方法無いですかね

8:47 AM

Mirror使えばいけるかな。

8:51 AM

func checkIsClassValue(_ arg: Any) -> Bool { return Mirror(reflecting: arg).displayStyle == .some(.class) } こっちのほうが上品っぽい

1

後者の方が良さそうですね。前者は checkIsClassValue(1) が true 。たぶんFoundationのせい。

ゲゲーッ

8:54 AM

ありがとうございます

8:54 AM

やば

public func castIfClass(_ x: Any) -> AnyObject? { guard type(of: x) is AnyObject.Type else { return nil } return x as AnyObject }

良さそう

9:04 AM

値だとautoboxing走って困ってた、型ならboxingされない、は確かに

そうそう。

一つだけ気になるのはこの関数はutilなんでinternalかな

まあそこはご自由に・・・

func checkIsClassValue(_ arg: Any) -> Bool { return type(of: arg) is AnyClass }

1

AnyClassはAnyObject.Typeのエイリアスですね

ほんとだ public typealias AnyClass = Swift.AnyObject.Type

なるほど。エイリアスがせっかくついてるしそっちのほうがオシャレだな

面白いのみつけた

11:23 AM

let a: @convention(block) () -> Int = { 42 } type(of: a) // @conversion(block) () -> Int (a as AnyObject) === (a as AnyObject) // true let b: Any = a type(of: b) // @conversion(block) () -> Int (b as AnyObject) === (b as AnyObject) // false

1

11:23 AM

型は変わってないけど as AnyObjectの挙動が変わる

Anyにするときにboxingされとるのかな？

Any boxingありそう

2:07 PM

Optionalのキャスト周りで2から3の時も似たようなのがあった気がする

2:09 PM

あー

2:10 PM

Anyでboxingが発生してるのではなく、キャスト前の型によってasがオーバーロードしてる方がありそう？

2:10 PM

中間コード見るのがはやそう

とりあえずdumpしてみました https://gist.github.com/moaible/b0ca6be9d4240f8b64f74db377f61bbc

2:39 PM

見る場所合ってるか怪しいけどこの辺り？

(var_decl "a" type='@convention(block) () -> Int' interface type='@convention(block) () -> Int' access=internal let storage_kind=stored) (var_decl "b" type='Any' interface type='Any' access=internal let storage_kind=stored)

https://github.com/apple/swift/blob/a05cd35a7f8e3cc70e0666bc34b5056a543eafd4/stdlib/public/core/BridgeObjectiveC.swift#L167

swift - The Swift Programming Language

3:30 PM

これかなー

3:32 PM

ここのisClassOrObjCExistentialがGenericsParameterからT.selfと取っているので、

1

3:32 PM

コンパイル時の型で判定だね

3:32 PM

@convention(block) () -> Intなら(@convention(block) () -> Int).selfと同値だし、

3:32 PM

Anyになっていると、Any.Protocolになります。

3:33 PM

バグならprチャンス？

なるほど、ここで型変数から受け取ったkindで比較してるからコンパイル時の型になるわけですね https://github.com/apple/swift/blob/bcb9571079cd86cbd6e7baa68e7e414460532a8f/stdlib/public/runtime/Casting.cpp#L2632-L2651

swift - The Swift Programming Language

func typeOfCompileTime<T>(_ x: T) -> Any.Type { return T.self } これで確認できますね

ふむふむ

import Foundation func typeOfCompileTime<T>(_ x: T) -> Any.Type { return T.self } let a: NSNumber = 1 typeOfCompileTime(a) // __ObjC.NSNumber.Type let anyA: Any = a typeOfCompileTime(anyA) // -> Any.Protocol

(edited)

3:46 PM

ここを見るとvalueも取ってそうなのに、Tだけしか見てないのは何か意図がありそう？ https://github.com/apple/swift/blob/bcb9571079cd86cbd6e7baa68e7e414460532a8f/stdlib/public/runtime/Casting.cpp#L3190

https://github.com/apple/swift/blob/a05cd35a7f8e3cc70e0666bc34b5056a543eafd4/stdlib/public/core/BridgeObjectiveC.swift

swift - The Swift Programming Language

let a: @convention(block) () -> Int = { 42 } print("a") dump(a) print() type(of: a) // @conversion(block) () -> Int (a as AnyObject) === (a as AnyObject) // true print("a as AnyObject") print(type(of: a as AnyObject)) dump(a as AnyObject) print() let b: Any = a print("b") dump(b) type(of: b) // @conversion(block) () -> Int print() (b as AnyObject) === (b as AnyObject) // false print("b as AnyObject") print(type(of: b as AnyObject)) dump(b as AnyObject) print()

1:22 AM

a - (Function) a as AnyObject __NSMallocBlock__ - <__NSMallocBlock__: 0x608000243390> #0 - super: __NSMallocBlock - super: NSBlock - super: NSObject b - (Function) b as AnyObject _SwiftValue - (Function) #0 - super: NSObject

1:25 AM

Any経由からAnyObjectにするところで、 _SwiftValue にboxingされてるのが原因？

1:25 AM

a as AnyObject の結果は NSMallocBlock だから、ラップはされてない感じだね

多分、SwiftValueが発生するのが、

2:05 AM

_bridgeAnythingNonVerbatimToObjectiveCの中ではという気がしている

それはグローバル関数？

2:07 AM

xcodeでブレークポイントをシンボル指定で貼ればわかるかな

https://github.com/apple/swift/blob/master/stdlib/public/runtime/SwiftObject.h

swift - The Swift Programming Language

2:08 AM

この辺、議論はちょい上

NSMallocBlock は関係なくて、シンプルに Any から AnyObjectへのキャストの話で、 ObjCブリッジ関係は関係ない気がする

dumpすると_bridgeAnythingToObjectiveCっていうのが出てくるよ。 (edited)

2:14 AM

で、これがどうも型パラとって動いてるから切り替わるならこの中か、@_inlinableとかやってそうだなと思ったので掘り下げた

これって -dump-ast？

1

そうだと思う。僕も-dump-astで似たような結果は確認した。

たしかに。 let c: AnyObject = 3 as AnyObject これだけで、 (declref_expr implicit type='(Int) -> AnyObject' decl=Swift.(file)._bridgeAnythingToObjectiveC [with Int] function_ref=single) がでてきた。

2:18 AM

import Foundationなくてもそうだ。

2:19 AM

ASTの時点でこんな書き下されてるの違和感あるな

2:21 AM

てことはAnyObjectって結構内部では ObjectiveCオブジェクトって概念なのか？

これちゃうかな

2:24 AM

Go2 Advent Calendar 2017 - Qiita

swift - The Swift Programming Language

1

めっちゃこれっぽい

てっきりimport Foundationしたらこれにすげ変わるのかと思ってたけどしなくてもこいつなのか

すでにObjCオブジェクトなのに自分で isaメンバ書いてる・・・

因みに

#if __has_attribute(objc_root_class) __attribute__((__objc_root_class__)) #endif SWIFT_RUNTIME_EXPORT @interface SwiftObject<NSObject> { @private Class isa; SWIFT_HEAPOBJECT_NON_OBJC_MEMBERS; }

2:26 AM

objc_root_classってのをつけると、標準生成のisaとかが消えて、手書きできるんかな・・・

2:26 AM

もしかして、Linux版だと、さっきの、 _bridgeAnythingToObjectiveC　が出てこなかったりする？

import Foundation class Cat{} (Cat() as AnyObject).superclass でこいつにたどり着く

__ObjC.SwiftObject.Type

2:28 AM

え、その superclassなに

2:28 AM

import foundationしたら出て来るのか

import FoundationしたらAnyObjectがNSObject互換になるマジック

でもObjCランタイム環境では、import Foundationが無くてもObjCオブジェクトではあるっぽいね

2:30 AM

NSObjectはFoundationからくるけど

import Fondationしないとこの辺のメソッド参照できないっぽいんだよね

うむ

これはズルなので、やめようね！という提案が最近evolutionに上がってた

あーあったね

2:32 AM

なんかもっとAnyObjectをきれいにしようみたいなやつ

そうそう

綺麗なAnyObject

"きこりの泉"が必要だ

きこりの泉があったら Optional も is も as も Variance も入れなきゃいけないものが多すぎる・・・

1

きこりの泉「きれいな○○」製造機。女神さまも大変。

Mirror使ってsuperclassの型取れませんでしたっけ

きこりの泉だと汚いものも一緒に返ってくるか一切無くなるかの二択なのでは

struct S {} class C {} S.self is AnyObject // false C.self is AnyObject // true この挙動を初めて知ったという雑ネタ

~~意外です (りんたろさんが知らなかったのは~~ (edited)

asで通ればis trueと思ったら例外いっぱいある

え、マジ？ as と is は揃ってると思ってた

あれ

8:52 AM

あ、上のはas通らないやつか

8:52 AM

functionどうなってたっけなと思ったら通った

8:53 AM

func x() -> Int { return 0 } x as AnyObject x is AnyObject

S.self as AnyObject === S.self as AnyObject // false っていうね。 (edited)

これですらtrueなんですね

8:53 AM

これはboxingですね (edited)

ですねですね

8:54 AM

ん？

8:54 AM

あ、 .self か

8:55 AM

S.self はメタタイプだから最初からヒープオブジェクトかと思いきや

8:55 AM

メタタイプも値的にboxingされるのか？

1

よく考えたら明示してたらautoではない

これなんでなの？ S.self is AnyObject // false

8:58 AM

なんでというのは、何のため？

スタティックに存在するはずだから、 reference タイプで問題ないはずっていう疑問ですよね？

僕もそう思いました。

はい。

9:00 AM

C.self が AnyObject なのに S.self が AnyObject であってほしくない理由がよくわからないです・・・。

9:00 AM

両方とも AnyObject でないならまだわからんでもないけど。

S.selfがどうやってもObjective-C側から観測不可能だから?

struct S {} S.self === S.self // Binary operator '===' cannot be applied to two 'S.Type' operands

AnyObject は ObjC と不可分なんですっけ？

ObjC の Class タイプと互換性とるためか？

純粋な Swift 的には（ Linux では）関係がない話な気も？

9:03 AM

！！！

9:03 AM

↓ Ubuntu 上で。

$ swift Welcome to Swift version 4.0 (swift-4.0-RELEASE). Type :help for assistance. 1> struct S {} 2> S.self is AnyObject $R0: Bool = false 3> class C {} 4> C.self is AnyObject $R1: Bool = false

うは！

かわるんか〜〜〜い

ww

何か自分が間違えてないか疑いたくなるレベルｗ

Xcode9.1でSwift4.0.2が入ったんですが、

12:02 PM

ここからString.charactersがdeprecatedですかね?

4.0からdeprecatedにはなってなかった・・・？

4.0なってましたっけ

12:05 PM

SwiftProtobufが.charactersつかってるのと警告をコンパイルエラーにするコンボが入っていて

12:05 PM

CarthageでSwiftProtobufを4.0.2でビルドするときだけ失敗するという状態になっている

1

4.0.2対応ブランチとかないんですか

リリースしか見てなかったらからワンちゃん

1

12:06 PM

なかったです

1

12:08 PM

これは普通にPR投げるのがかしこいな

protobuf使うような人たちならbeta追いかけて対応してそうなもんなのにね

12:09 PM

マスターでビルドコケて草

12:09 PM

なおしますね

12:11 PM

/// A view of the string's contents as a collection of characters. @available(swift, deprecated: 3.2, message: "Please use String or Substring directly") public var characters: String.CharacterView

あれ?3.2からだっけ…

ｗｗ

Xcode 9.1 betaでwarningが出る様になりましたね。

Xcodeで変わったってことはSwift側じゃなくてstdlib側か。。。

1

QiitaのAdvent Calendar出遅れてもうSwiftカレンダー埋まっちゃった

一瞬だった

すぐ埋まりましたね。 Swift2を作ってもいいかも？

1:49 AM

↓みたいな感じで。 https://qiita.com/advent-calendar/2017/go2

Goのアドベントカレンダー(その2)です！登録後にキャンセルされる場合、書く予定だったが書けなくなった、などは Twitter で @mattn_jp にご連絡下さい。 予定日を過ぎても投稿がない場合、お伝えする事なく他の方にエントリして頂きます。ご了承ください。 [その1](https://qiita.com/advent-calen...

1:49 AM

https://qiita.com/advent-calendar/2017/swift2

Swift その2 Advent Calendar 2017 - Qiita

Swift4が出ましたが、このカレンダーのURLはswift2です(　´･‿･｀) どうぞご自由にSwiftに関して投稿ください

1:49 AM

すでにあった。

1:49 AM

ってか @lovee さんも登録済みだった。

はい、とりあえず登録しておいてからここに書き込みましたｗ

なるほどｗ

1:51 AM

Goがすでに3になっててすごい https://qiita.com/advent-calendar/2017/go3

Go3 Advent Calendar 2017 - Qiita

Goのアドベントカレンダー(その3)です！登録後にキャンセルされる場合、書く予定だったが書けなくなった、などは Twitter で @mattn_jp にご連絡下さい。 予定日を過ぎても投稿がない場合、お伝えする事なく他の方にエントリして頂きます。ご了承ください。 [その1](https://qiita.com/advent-calen...

1:52 AM

@mono その2にリンクしてあげるといいかもです。埋まってた人のための導線として。 https://qiita.com/advent-calendar/2017/swift

Swift Advent Calendar 2017 - Qiita

Taylorじゃない方のSwiftです(　´･‿･｀) ---

Swift Advent Calendar 2014 - Qiita
[Swift Advent Calendar 2015 - ...

余談ですがAdventarにも結構いろんな面白いAdvent Calendarがあって面白い（語彙力皆無 https://adventar.org

https://adventar.org/calendars/2158

1:57 AM

これとかねｗ

1:57 AM

退職者 Advent Calendar 2017

あ、退職者カレンダーにすでに登録済みです（）

1

毎年、色々なジャンルのAdvent Calenderを見るのが楽しみなのですが、投稿者選抜ってジャンルによってはこんなに壮絶だったのですね。

FD_SET などのC言語マクロが Swift から呼び出せないからそれをブリッジするだけのObjectiveCソースを追加する必要があって残念

https://developer.apple.com/documentation/swift/array/2884646-removefirst

4:15 AM

Array.removeFirst、最初の要素をreturnしつつ削除してくれるんだけど

4:15 AM

Optionalになってなくて空だとクラッシュなのが

4:15 AM

.first との対応として違和感がある

1個目の取得と1個目の削除っていう2つの機能が1個になってる感じがしてきもちわるめなので使わないようにしてるから気づかなかった。

わりとよくやるのが while let first = array.first { someCleanup(first) array.removeFirst() }

4:40 AM

こうやって先頭から一個ずつ片付けるときとかで、

4:40 AM

while let first = array.removeFirst() { someCleanup(first) }

arrayからは消したいのね

こう書けたら良かったのになあ。ってなる。

4:40 AM

うん。

それってforEachぶん回したあと空配列代入するじゃだめなの

someCleanupの内部でこの配列に要素が増えたりする可能性がある

ゲー

4:42 AM

オレオレremoveFirst作ってoverloadしたら

まあこのパターン自体はどうとでも道具は作れるからいいんだけど removeFirst の API は変じゃないかって話

forEachの途中で要素増えたらどうなるんだろう

if let のときはOptionalが優先される気がする

for - in 中の変更って許されてたっけな

forEachの中で要素増えてもそのforEachには影響なかった

4:47 AM

増える前の配列でforEach終わった

それはforEachメソッド？

class Hoge { var array = [0,1,2,3,4,5,6,7,8,9] func fuga() { array.forEach { [weak self] in print($0) self?.array.append($0 * 10) } } } let hoge = Hoge.init() hoge.fuga()

4:47 AM

0 1 2 3 4 5 6 7 8 9

structのmutatingはコピーと同義じゃないの

func fuga() { for e in array { print(e) array.append(e * 10) } }

4:49 AM

これも同じ挙動やな

つまりarray.forEachしたときのarrayとappendされたarrayは別物になるはず

んだ

4:49 AM

コピーだべさ

そこ ownership で変わる可能性あって

4:51 AM

https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md#non-mutating-iteration

https://developer.apple.com/documentation/swift/array/1539777-poplast

swift - The Swift Programming Language

4:51 AM

現状の実装だとイテレーターがコピーしてる（COWだから実コピーはされない可能性が高いけど）

4:51 AM

んだけど

4:51 AM

for shared employee in company.employees { if !employee.respected { throw CatastrophicHRFailure() } }

4:51 AM

shared イテレーションになると、コピーしないで直接参照できるようになる

1

したらループの中で毎回appendしてたら終わらんくなるの？ (edited)

いや、それで、sharedイテレーションのレシーバ(Collection)は、for - in の呼び出しが nonmutating func の呼び出し期間扱いになるので

4:52 AM

読み込み参照として保護されていて

コンパイルエラーにできるのか (edited)

appendしようとすると書き込み参照と衝突して落ちる（か、静的エラー)

素晴らしい

だから、禁止されるってことだね

ほっほー

Collectionに対するshared iterationはデフォルト挙動になって、普通の for in がそうなる

4:53 AM

Programs can explicitly request an iteration over a copy of the value in that storage by using the copy intrinsic function on the operand.

従来挙動は明示的に for x in copy(array) { ... } コピーしましょうねとか書いてある (edited)

4:54 AM

で、もしそれが実装された場合

4:54 AM

mutating generator iterateMutable() -> inout Element { var i = startIndex, e = endIndex while i != e { yield &self[i] self.formIndex(after: &i) } }

イテレーションされている間の処理を記述するメソッドが　コルーチンになって yield が必要だよねという話が出てくる

func copy<T>(_ arg: T) -> T { return arg }

(これまでの makeIterator() と next() との整合性はよくわからん・・・

4:55 AM

copy copy is a top-level function in the Swift standard library: func copy<T>(_ value: T) -> T { return value } せやな

4:56 AM

move The Swift optimizer will generally try to move values around instead of copying them, but it can be useful to force its hand. For this reason, we propose the move function. Conceptually, move is simply a top-level function in the Swift standard library: func move<T>(_ value: T) -> T { return value }

4:56 AM

move はコンパイラマジックになるので↑うさんくさいことに

4:57 AM

とまあ、そういう将来の話があるので、現状の for in 中の変更についての挙動は単なるツナギというかなんというか。

胡散臭すぎて笑うw

話戻るけど、 removeFirst は前からおかしいと思ってた。 Optional 返すべき。

お

5:10 AM

一応 removeAt(0) が空ならクラッシュする方に合わせてるんだとは思うんですけどね

もしかすると popFirst が必要なだけかも。 (edited)

5:10 AM

5:10 AM

これの先頭版がほしくなる。

そんなのあったのか

5:11 AM

なんでlastだけあるんだｗ

いや

popFirst は O(n) になるから？

返すべき値が無いという意味なら返り値はOptionalが良いと思うけど、無いのにremoveはやっぱりクラッシュしたほうがいいんじゃないかという気持ちがあるんですが

removeAt(0)はsubscript(0)との対なのでクラッシュはわかるけど (edited)

5:11 AM

removeFirstが落ちるのはやっぱりおかしい

別にええやんけ removeFirstもO(n) だし

remove は落ちるのがいいと思うけど

なるほどね remove: 落ちそう + first: 落ちなそう

removeFirst は実質的にほしいのは popFirst であるケースが多くて

5:12 AM

今の removeFirst や removeLast はいらない。

5:14 AM

まあ、 removeLast が popLast で Optional に包むオーバーヘッドを避けるためにあるというのはまだわからんでもないけど、 removeFirst は意味不明。

5:15 AM

removeFirst は O(n) のはずだし、それと比べたら Optional に包むオーバーヘッドなんて微々たるものだからほしいのは popFirst だ。

5:15 AM

ただ、そうすると Array をキューとして使い出す人が出て来るから

5:15 AM

そのために popFirst を封じてるんだったらまだわかる。

5:15 AM

でもそれなら removeFirst もいらないと思う。

5:16 AM

ArraySlice なら O(1) だから、 ArraySlice に popFirst があれば良い？

5:16 AM

https://developer.apple.com/documentation/swift/arrayslice/1687956-popfirst

5:16 AM

あった

struct Queue: Sequence がstdlibにいればArrayをQueue代わりに使うみたいなのは封じれるんじゃ

やっぱそういう意図で Array では封じられてるのか？

5:17 AM

なので、一度 ArraySlice に入れれば良さそう。

5:18 AM

var slice = array while let first = slice.popFirst() { someCleanup(first) }

5:18 AM

someCleanup が slice をキャプチャできないか。

5:18 AM

まあ、最初から slice でもっておけば OK 。

5:20 AM

@tarunon Queue を入れると Stack も、ってなるし、どこで線引きするか難しい気がするんですよね。 Deque もほしくなるし。

というかQueueとStack、structよりclassの方が効率良いなという気がしてきた

stackのfirstとlastがどっちなのかってめちゃ混乱しそう

mutable前提の構造だし (edited)

@hiragram 後ろのイメージだけど Java の push, pop は先頭で操作してた気が。

(First/Last) in (First/Last) out な組み合わせが

5:21 AM

ん

5:22 AM

First in (First/Last) outか

https://docs.oracle.com/javase/7/docs/api/java/util/LinkedList.html#push(E) inserts the element at the front of this list.

5:23 AM

@tarunon それややこしいｗｗ FIFO キューは Last に要素を Insert すると。 First-in だけどｗ

StackがSequenceになったときdropFirstしたらどこがドロップされるのかみたいな

キューの前後と時刻の前後・・・

ややこくなってきた

というか厳密にはStack/QueueはSequenceには属さなさそう

だね

そもそもpush/popしか操作が許されてないから群ではあるけどSequenceではないね

Sequence ではないですね。取り出さないと要素が得られないし。

@mono その2にリンクしてあげるといいかもです。埋まってた人のための導線として。

https://qiita.com/advent-calendar/2017/swift done

(edited)

Swift Advent Calendar 2017 - Qiita

Taylorじゃない方のSwiftです(　´･‿･｀)

その2: Swift その2 Advent Calendar 2017 - Qiita
サーバーサイド: [Server Side Swift...

2

Result<T>の提案 https://github.com/apple/swift-evolution/pull/757

[Proposal]: Add Result To Standard Library by jshier · Pull Request #757 · apple/swift-evolution

Add a proposal for adding Result.

通らないやつだ。

Standard Library内で活用するのが難しそうなまま通ることはなさそう。

↓かつてばっさりやられたやつです。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012545.html

また is 周りで面白いの見つけてきた。

11:37 AM

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

typeCheck.swift

11:37 AM

長いのでGistに

パッケージのビルド要件をSwift 3.2以降としてしまった場合、Swift 3.2モードでビルド出来ることを維持する理由ってありますかね？

↑のResultのスレにいなみさんがポエムと称して長文を投稿してる

どれ？

inamiy commented 2 days ago

I wrote a short poem for why I prefer typed error if you are interested: https://gist.github.com/inamiy/e3f5f7524f1bcdc582c2ff8dbbba58dd

Swift Poem: Why I prefer typed error (for https://github.com/apple/swift-evolution/pull/757)

1

1:36 AM

MLじゃなくてPRスレッド

↓こんな書き方できるの知らなかった。 import enum Result.NoError https://github.com/ReactiveCocoa/ReactiveSwift/blob/38aeae5a46b634808d951c107fdb986666e1e152/Sources/UnidirectionalBinding.swift#L3

ReactiveCocoa/ReactiveSwift

ReactiveSwift - Streams of values over time

NoErrorがtyped errorの最たるモチベーションなのは解るんだけど、それ故にNoErrorの実現のためにResultを導入するのはなんかなという気がする

俺も話しが拡大されてるように思った

RxSwiftが引き合いに出されてるけどあれもthrows closureの有無でちゃんとやれば、Errorの有無をコンパイル時に〜というのは不可能ではないはず

いなみさんが言ってるのは、 Result 導入するなら typed error が、って話であって、 Result が良い悪いではないのでは？

今はできてないけど…

1:44 AM

typed errorに関しても、モチベーションの最たるところがNoErrorなので

1:45 AM

それはthrowの有無をちゃんとやれば良いだけなのではというお気持ち

うーん、それは Result を直交概念から独立させれば良いのでは派。 Foo<Result<T>> // エラーが起こり得る Foo<T> // エラーが起こり得ない

Observable<Event, Failable: bool = true> Observable<Int> // may emit error Observable<String, false> // never error typealias NoErrorObservable<T> = Observable<T, false> NoErrorObservable<String> // never error

依存型があればこういう風にもできそう

1:50 AM

直交概念から独立させれば良いのでは派

Promiseならそれでいいけど、Observableだと、エラーだったら購読を切る、とか、制御自体が変化するから微妙じゃないですかね

1:51 AM

そういう場合だと、Resultを入れた場合で、かつ、それがエラーになったときだけ、特定の動作をする、っていう仕様は、隠し仕様っぽい感じでわかりにくくなりそう

generic extension があればできない？

@omochimetaru 依存型はまさにそうで、そこにthrowsの有無を組み込めばやりたいことはできる

実装は特殊化があればできるとは思います

1:52 AM

ユーザー側に型パラメータから道具の振る舞いが伝わりにくそうってこと

実際そこはRxSwiftのAPIの問題なので

1:52 AM

型エラーの優位性の議論の引き合いに出せるレベルじゃないから

まあ、正面から NetworkFailure と InvalidJsonFormat を読み分ける話じゃないと、不足だよね

その用途で現行のパターンマッチを超える話ならいけそう

1:54 AM

NoError軸は無理だと思う

typealias FailableFoo<T> = Foo<Result<T>> なら見栄えの問題は解決するか

ネストした map 等の煩わしさはあるけど、それも generic extension があれば一度に二重アンラップは用意できるはず。

まあそこは現行でもワークアラウンドあるしなんとかできそう

is こわれた import Foundation @objc protocol D {} class C: D {} C.self is D

すげえな、４行目

6:00 AM

Cast from 'C.Type' to unrelated type 'D' always fails

6:00 AM

always fails って言いながら true になった顔

まじか

6:01 AM

C.init() is Dは？

それはtrue

おかしいのは

6:01 AM

ふつうは C.self is D.Type

import Foundation @objc protocol D { func hello() } class C: D { func hello() { print("hello") } } C.self is D (C.self as? D)?.hello()

うん

さてこれは

file:///Users/omochi/work/playground/TempGround.playground: error: Playground execution aborted: error: Execution was interrupted, reason: signal SIGABRT. The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.

6:02 AM

死んだ

アーメン

1

そういえば ObjectiveC のときって

6:05 AM

self.class がメタクラスだけど、 self.class.class はループしてそれ自身を返さなかったっけ？

6:05 AM

そこらへんの絡みでなんかコンパイラ実装をミスってそう

https://bugs.swift.org/browse/SR-6304

https://github.com/apple/swift/blob/f53826afd9bb384990b42399ef948afae208811c/lib/Sema/TypeCheckConstraints.cpp#L3291-L3877

https://github.com/ahoppen/introduction-to-compilers

swift - The Swift Programming Language

6:28 AM

この関数な気がする

6:30 AM

3342行目で、 always fails のメッセージが出る > diagnose(diagLoc, diag::downcast_to_unrelated, origFromType, origToType)

6:30 AM

いや、むしろこっちは良くて、生成されるキャストが実行されたときの動きが変なのか

Resultのプルリクの件、同じ日にMLも投下されてた。

ahoppen/introduction-to-compilers

Contribute to introduction-to-compilers development by creating an account on GitHub.

10:07 AM

これすごいｗ

10:08 AM

playground上で swiftのコンパイル後のバイナリを可視化する仕組みを作って

10:09 AM

その上でインタラクティブなplayground book形式のコンパイラ解説？記事？になってる

10:12 AM

あ、これ言語は swift っぽく見えるけど超サブセットっぽいな

10:14 AM

Parser, IRGen, Executor が入ってる。

これは嬉しい https://github.com/apple/swift/pull/12779

Add key encoding strategy to JSONEncoder by parkera · Pull Request #12779 · apple/swift

Adds a "strategy" for handling snake and camel case conversions for JSONEncoder and JSONDecoder. Proposal is available here: apple/swift-corelibs-foundation#1301

12:11 AM

オレオレエンコーダにも追加しよう。

https://github.com/parkera/swift-corelibs-foundation/blob/aa7680103cb6c039a3000fde276907cd9da90deb/Docs/Proposals/0001-jsonencoder-key-strategy.md

parkera/swift-corelibs-foundation

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

1:03 AM

なるほどーこれは欲しい人多そう

もしかしてCodable側で制御できた方が嬉しいのかも。

それちょっと考えてました

1:07 AM

これはデコーダー側だから他のデコーダーには効かないですよね

キーの命名規約がエンコード先によって決まる事が多いなら、この提案の様にCoder側で解決した方が良いか。 (edited)

そうすると元々の機能の CodingKeys で別の文字列を定義するやつはなんなんだろうという気もします

確かに…

デコードするフィールド名をリストする、という観点ではあらゆるシリアライズ先に共通だけど

1:32 AM

フィールドに対応する文字列を指定できるところは、共通でエンコーダー側に逃がすほうが一貫性がある気も。

1:32 AM

まあこういうのは使いやすければ細かいことはいいんだよ系な気もするけど・・・

MLに投げた。

Codable側にあったほうが良くない？側で投稿したんですね、なるほど

Codableとは関係ないenumのrawValue自動生成メカニズムへと話が発展しそうな気がしなくもない。

あ、String rawvalueなenumって、codableだけの特別生成かと思っていましたが、

1:43 AM

もしかして自分でもそれできるんですか。

1:44 AM

Codableが特別なのは stored property にもとづいてCodingKeysのcaseリストを生成するところか。

そう。

1:46 AM

そうなると、snake_caseだけでなく、スペース区切りとかそういったバリエーションも考えられる。

camelCase と PascalCase とかもありますね。

Swift.Errorのエラーメッセージとか簡単になったりする>スペース区切り。

なるほど。

class Cat { init() { print(1) self.age = 3 // didSet呼ばれない print(2) self.age = { self.age }() // didSet呼ばれない print(3) self.refreshAge() // didSet呼ばれる print(4) self.age = { self.age }() // didSet呼ばれない ( これがちょっと変な感じ ) } var age: Int { didSet { print("age:did set") } } func refreshAge() { self.age = { self.age }() } } Cat()

1

2:31 AM

2番の時点でそもそも呼ばれると思ってた。(selfが完成するから)

2:31 AM

そしたら呼ばれなかったし、3の後の4も呼ばれないのはちょっと違和感

3 は呼ばれるのに 2 と 4 呼ばれないのヤバめな感じが。 (edited)

むしろなんで3は呼ばれるのか

これは意図した挙動なのかなぁ？

単純に、「init からの呼び出しなら、 didSetは呼ばない」っていうルールが実装されていると思う

@lovee 3が呼ばれないとセットアップ後に複雑なメソッド呼んだときにぶっ壊れる気がします。

2:34 AM

メソッド実装するときは普通 didSet 呼ばれる前提で書いているから、呼ばれない場合もあるというのは危険そう。

2:35 AM

セットアップ後はメソッド呼べるルールなんだから、セットアップ後は didSet も呼ばれるでもいい気もするんだけどなぁ。この仕様はどうなんだ？ (edited)

単純に、「init からの呼び出しなら、 didSetは呼ばない」っていうルールが実装されていると思う

そう自分もそう思ってましたから3が呼ばれるのがすごい違和感というかなんというか

↓みたいな構文の方がいい気がしてきた。

init(foo: Foo, bar: Bar) { // プロパティのセットアップ self.bar = bar } super(foo: foo) { // その後の初期化処理 }

お、C++っぽい

C++ と違ってセットアップ部分に文が書けるのがいいところ。

そう自分もそう思ってましたから3が呼ばれるのがすごい違和感というかなんというか

そうですね、 init 「から」の、から、は、完全にダイレクトな意味で、呼び出しネストは考慮されない。

2:44 AM

破壊できそうな気がしてきた

2:49 AM

う、うーん、なるほど・・・

2:49 AM

stored property ( didSetを持つ ) 場合は、その property が override されていても、 initから直代入だと親の方は呼ばれない

2:50 AM

computed property ( get , set を持つ ) 場合は、override されていると、 init から代入すると親の方が呼ばれる

2:50 AM

一見不可解な挙動は生じるけど決定的に壊れるようなことは起こらない・・・↑の延長で説明できる事が起きた

2:51 AM

（もうちょっと破滅的な事が生じるなら報告してみようと思ってた

init() { defer { print("defer") self.age = { self.age }() // didSet呼ばれる }

defer ｗｗｗ

2:58 AM

ん・・・？

2:58 AM

defer を末尾にかけば、その　init制限空間から抜け出せるわけか。

2:58 AM

裏技だ・・・

この挙動はバグだ／バグじゃないとか、そんな話を最近読んだ。

なんとなくだけどクロージャ書いてその中でsetしてクロージャ実行しても回避できそう

@tarunon それが @omochimetaru の 2 じゃないですか？

class Cat { init() { defer { print("defer") self.age = { self.age }() // didSet呼ばれる } print(1) self.age = 3 // didSet呼ばれない print(2) self.age = { self.age }() // didSet呼ばれない print(3) self.refreshAge() // didSet呼ばれる print(4) self.age = { self.age }() // didSet呼ばれない ( これがちょっと変な感じ ) print(5); { self.age = self.age }() // didSet呼ばれる } var age: Int { didSet { print("age:did set") } } func refreshAge() { self.age = { self.age }() } } Cat()

3:01 AM

クロージャ正解

2はメソッドだったので

なんとクロージャの中だと右辺をラップしなくてコンパイルできる

おっと、これまで読み間違えてた・・・。 2 と 4 はクロージャ式の外で代入か。

defer の中と func の中は右辺のラップが必要。

っていうか、didSetがあるときに

3:11 AM

self.age = self.age が棄却されるのは

3:11 AM

論理的におかしい気がしてきた

3:11 AM

副作用があるんだから。

3:12 AM

そこだけ報告しようかな

この挙動はバグだ／バグじゃないとか、そんな話を最近読んだ。 Twitterだった。この辺り https://twitter.com/jckarter/status/926459181661536256

Basic SIL representation support for coroutines by rjmccall · Pull Request #12789 · apple/swift

@johnsundell That’s a bug that’ll be fixed soon. The more reliable way to do it is to call a method that sets the property.

Joe Groffがバグじゃ〜って突っ込んだらSlavaがいやいや、って突っ込んでるのかｗ

結論は良くわからない（最後まで追ってない）けど、とりあえず使わないでおこうと思った。

3の挙動が正しいってのは一致してそう。

3 は正しいと思います。

3:46 AM

僕は 2 と 4 も didSet 呼ばれて、↓も呼ばれてもいいと思います。 print(1.5) self.age = 4

initの中で self が使えるようになった以降と以前でその挙動を変えるべきってことですよね

はい。

たしかに、僕もそもそもはそれを期待していた。

3:47 AM

あー、やるならそのレベルの意見提案としてML投下が一番いいか・・・

ただ、 super.init や self.init がないと可読性がヤバイので、メソッド呼ぶには self.init() が必須とかの方がいいかも？

initの中で self. init 呼んだら無限ループ風にみえます

そうだねー

3:48 AM

何かいい記法があればいいんだけど。

問題は、現状didSet呼ぶルートに流すのはSemaだけど、Sema時点では self が完成しているか分からないので、やるなら大工事が必要ってことですね。

class Cat { init { selfが使えない } didInit { selfが使える } }

3:51 AM

スコープが切れちゃうからコンストラクタ引数とか困るな・・・

現状でもイニシャライザで self のメソッド呼べるかチェックされてるのに、同じようにチェックはできないんでしょうか？

3:51 AM

@omochimetaru うん、スコープ切れる問題さっき考えてた。

1

3:53 AM

super.init() を書かないといけないとかだと無限ループ問題はなくなるかも。 struct だと何これ？ってなるけど。

3:53 AM

暗黙のスーパータイプ Any

現状でも self 完成を明記する記法は結構欲しいんだよな

3:54 AM

書いたときの気持ちをコードに残しておきたい

それ系のチェックはSILでコントロールフロー作ってからやってるので、通常のアサイメントに流すか、ストレージにダイレクトに格納するかをSIL以降に決定する必要がある。

うん、ほしい。

新しい記法作らないと source breaking になっちゃうので、新記法で縛った方が通りやすいかもですね。

それでも didSet 呼ばれるようになったら source breaking ですよねぇ

例えば新しい inited(self) とかを導入した上で、 Swift4 では、 inited(self) が書いて無ければ、これまでどおりの挙動＋警告、 inited(self) が書いてあれば新しい挙動、 Swift5では、 inited(self) が必須

3:59 AM

とやれば、既存のコードは inited(self) を書いていないので、移行期間の下位互換は取れる (edited)

なるほど。そういうことか。

super.init と inited(self) の両方を書きたくないなあ・・・

うん・・・

条件分岐中のinited(self)とかあるとめんどくさいので、didInit {} の方がいい気がするけど、特定のイニシャライザだけで後処理したい時にめんどくさそう。

あー分岐かあ・・・

didInit は init に付随するイメージでした。

4:05 AM

でも、コンストラクタ引数が渡せないの辛そう。

4:06 AM

ネストすればいいのかな？

普通にメソッド作った方が良さげ

@norio_nomura 確かに、初期化完了後の処理をすべてメソッドに切り出すというワークアラウンドはありますね。 (edited)

4:07 AM

ってか、クロージャ式でいいのか。

メソッドだとinit以外から呼ばれる可能性が生じちゃうのですよね

4:07 AM

インナーfunc とかがいいかな。

init(...) { self.foo = ... super.init(...) { // self を使う処理（ didSet も有効） }() }

4:10 AM

やっぱり run がほしくなるな。 func run(_ operation: () throws -> ()) rethrows { operation() } (edited)

↑それ、 super.init と後ろのクロージャがくっついちゃうから

4:10 AM

super.initの右に ; が必要かも

ひどいｗ < くっついちゃう

runがあれば解決。

init(...) { self.foo = ... super.init(...) run { // self を使う処理（ didSet も有効） } }

runが無いと単発即時クロージャが直前の関数呼び出しにくっついちゃう問題があるんですよね

=> と run がほしい。

init(....) { init { ... } didInit { ... } } プロパティの構文に似せてみた

4:48 AM

initの中で記述するのがポイントかしら

そうですねぇ。その構文ならイニシャライザ引数が使えるのがいいけど、 init が異なる意味で二箇所で使われてしまうのと、 init {} と didInit {} で変数を共有できないあたりが微妙でしょうか。

didInit欲しい

7:19 AM

というか UIView にも UIViewController の viewDidLoad と同等なものが欲しい

addToWindow でフラグつかって1回だけやるとか

xib使うなら awakeFromNib だとおもうけどloveeさんだとどうかはわからない

2

awakeFromNibとviewDidLoad微妙にタイミングが違うからなー

async/awaitの根っこの

10:13 AM

coroutine 機能の実装が、 SILレベルで進んでる

10:13 AM

https://github.com/apple/swift/pull/12789 このテストコードが雰囲気わかりやすい https://github.com/apple/swift/pull/12789/files#diff-71c7042d12a9c10aee4e857f4086aff6

10:13 AM

ていうかSILレベルだとcoroutine展開されないんですね。

お、早めに beginAsync の rethrows の件ポストしないと。

https://github.com/omochi/gysb

why-does-beginasync-rethow-errors.md

gysb - Generate your swifty boilerplate

4

5:59 PM

Swift実装のgybを作った！テンプレートコードはSwiftで書けるので型エラーとか出る。

beginAsync の rethrows の件書いてみました。いかがでしょう？（ swift-evolution 未投稿です） https://gist.github.com/koher/bcb0ac8c05a4e43b6c5a40bcac041285 (edited)

いいですね。

In following cases, beginAsync just has to crash the program when foo throws an error.

のくだりのあとぐらいに、「rethrowsが含まれるコードのコンパイルが通っているのにクラッシュする可能性が残るというのはSwiftの検査例外の安全な世界を破壊してしまうし」ってもうひと押しあると良いと思いました。あと、

If beginAsync does not rethrow errors

に「つまり、引数のbodyがthrowsで無いならば」を付け足したほうが正確だと思います。 beginAsyncはrethrowsではないがbodyはthrowsという状態もシグネチャだけで言えばありえるからです（その場合、キャッチされた例外は全てクラッシュになるので今より悪くなるだけだけど）

なるほど。修正して投稿します。

投稿しました。 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/041008.html

1

返事があった。

FWIW, I also still think it would be better if we allowed for async void functions instead of requiring beginAsync in the first place. If I had my way then we would have async void, but an async void would not be allowed to throw.

これについては Swift においてはおかしなことになると思う。 () async -> Void をやりたいケースが普通にあるはずだし。

この英文は beginAsyncが無くても () async -> Void な関数をいきなり呼べるようにしたらええんちゃうって意見であってますか？ (edited)

5:53 AM

Swiftでそれやったら、 await 忘れてうっかり呼び出しちゃってるケースと

5:53 AM

曖昧になって残念すぎる

5:53 AM

かといって、async Void のときに await つけたら、それこそ意味不明な見た目になるし。

そうだと思います。 C# だと async で戻り値 void だと await できないから。

5:55 AM

かといって、async Void のときに await つけたら、それこそ意味不明な見た目になるし。

ん？別に問題ないのでは？ beginAsync { await foo() await bar() }

5:55 AM

今の try も同じだし。

beginAsyncが無い話ですよね？

5:55 AM

↑はbeginAsyncがついてるから普通。

ああ、 beginAsync なくしたときに await 付けて代わりに直接呼べるようにしたらって話か。

そうです。

それはアウトだね。外側が async じゃないとコンパイルエラーになってほしいし。

投稿した

1

filterMap の mutating 版を考えてたんだけど、 inout 使うなら↓とかかな？ mutating func updateOrRemove(_ f: (inout Element?) -> Void)

7:53 AM

inout なしなら↓だけど。 mutating func updateOrRemove(_ f: (Element) -> Element?)

7:53 AM

map の mutating 版は↓。 mutating func update(_ f: (inout Element) -> Void)

クロージャ内で= nil したら消える？どんな実装になるんでしょう？

クロージャ内で= nil したら消える？

そう。だけど効率考えたら微妙そうだね。 (Element) -> Element? の方が良さそう。

7:55 AM

でも、 map の mutating 版は inout になると思うんだよなぁ。

mutating版は型の制約がついて使いにくい感じありますけどねぇ用意してもらわなくてもいいかな？と

WWDC のビデオでも↓が出てくる。 < inout になると思う mutating func modifyEach(_ body : (inout Element) -> ()) (edited)

7:57 AM

map よりもパフォーマンス良くなるからニーズはあると思う。 < 用意してもらわなくてもいい (edited)

パフォーマンス求めるならforで書きますけどインライン化されたら同等ならあったほうがいいかな？

for で書いてもインデックスでアクセスするから遅いんじゃない？

7:59 AM

ポインタでアクセスしたときと同等にできるんじゃないかなぁ。

あーforを飛ばしてポインタと同等までに行ける可能性もあるか

うん。それってパフォーマンスと利便性を兼ね備えた素晴らしい API だと思うんよね。

8:00 AM

mutating func update(_ f: (Element) -> Element) でもいいかもしれないけど。

それだとreturn後の代入が必要なわけですよね

はい。最適化でクロージャ式がインライン化されて同じにならないかな？ (edited)

elementを弄った後return elementするのが嫌な感じが

あー、確かに element のプロパティの一部を書き換えるとかだとそうだね。やっぱ inout がいいか。

8:04 AM

うーん、やっぱ↓を考えると一貫性持たせるの難しいな・・・。 mutating func updateOrRemove(_ f: (inout Element?) -> Void) mutating func updateOrRemove(_ f: (Element) -> Element?)

[Element]に(inout Element?) -> Voidを呼んだ場合の実装がやっぱりよく分からない

8:08 AM

一度[Element?]を作るなら明らかにパフォーマンス悪いですよね

そうだね。一度 Optional に入れてから戻すとかでパフォーマンス悪そう

8:08 AM

ってか、 mutating 版自体がおかしいか？

8:08 AM

削除を考えてると作り変えて差し替えた方がパフォーマンス良さそう

8:08 AM

なので filterMap さえあればいいかも。

extension Array { mutating func updateOrRemove(f: (inout Element?)->Void) { withUnsafeMutableBufferPointer { var src = $0.baseAddress! var dst = $0.baseAddress! for _ in 0..<$0.count { var e: Element? = src.pointee f(&e) if let e = e { dst.pointee = e dst += 1 } src += 1 } } } }

これ＋カウント書き換えならそこそこかな？ (edited)

8:10 AM

なんかarray縮めるやつありますよね

array 縮めるって O(N) じゃないの？

そこはよく知らないですね……

隙間を埋めるならinplaceで前に寄せればいいからO(N)

↑の実装だとarrayの後ろの方を消すだけですね

やっぱ filterMap の mutating 版はないな。 O(N^2) になっちゃう。

8:14 AM

filterMap なら O(N)

8:15 AM

もちろん、 filterMap を内部で使って自身を差し替えで O(N) にはできるけど、それなら filterMap 使って自分でやればいいし、メソッドになってる意味がない。

8:16 AM

ただ、　Array にとってはナシだけど、 LinkedList なら有用。

var ary = [1,2,3,4,5,6,7] for var elem: Int? in ary { print(elem) } 破壊した

8:38 AM

※無限ループ注意

手遅れだったｗ < 無限ループ

1

え、なにそれ・・・ｗ

8:41 AM

next()の返り値が格納できちゃうって感じ？

Iteratorの吐く Int?.noneをInt??にキャストするときに

: Int? が書けることが邪悪だー

違うか、Int??すら出てきてなさそう

8:45 AM

var elemn: Int? = iterator.next() as? Int? // 当然成功する こうかな (edited)

っぽいですね。

ほんと Int is Int? は封じないとヤバイ気がしますね。 (edited)

8:50 AM

型システムがぶっ壊れてる・・・。

ボクじゃない誰かがボクの代わりにOptionalManifestを書いてもいいと思います

8:50 AM

まだ事案まとめぐらいしか出来てない

inout 版はクライアント側の使い勝手が微妙ですねぇ。

// (inout Element?) -> Void 版 extension Array { mutating func updateOrRemove(_ f: (inout Element?) -> Void) { var writeIdx = startIndex for readIdx in indices { var elem: Element? = self[readIdx] f(&elem) if let elem = elem { self[writeIdx] = elem writeIdx = self.index(after: writeIdx) } } removeLast(distance(from: writeIdx, to: endIndex)) } } var ary = [1,2,3,4] ary.updateOrRemove { (elem) in if elem! % 3 == 0 { elem = nil return } elem! *= 10 } print(ary)

Optional は暗黙の型変換は許す、サブタイピングは許さない、がちょうど良い着地点な気がする。

型変換というか

8:51 AM

暗黙の.someラッピングですね、それだけ許して後は封印

こっちの方がいい

// (Element) -> Element? 版 extension Array { mutating func updateOrRemove(_ f: (Element) -> Element?) { var writeIdx = startIndex for elem in self { if let elem = f(elem) { self[writeIdx] = elem writeIdx = self.index(after: writeIdx) } } removeLast(endIndex - writeIdx) } } var ary = [1,2,3,4] ary.updateOrRemove { (elem) in if elem % 3 == 0 { return nil } return elem * 10 } print(ary)

あーそういうことか。

8:53 AM

それなら確かに O(N) でできる。 @t.ae のもそうなってるのか。読めてなかった。

8:55 AM

うーん、 inout 版も悪くないような気が。 return が微妙ってことですか？ < inout 版はクライアント側の使い勝手が微妙ですねぇ。

渡ってきた Element? をいちいちアンラップしないと値が読めないのはきついと思います。

ああ、確かに。 ! 付いてますね。

8:57 AM

しかし、そうなると inout 版の update がほしいのに filterMap だけ inout 版にならないのイマイチですねぇ

(inout Element!) -> Void っていう手もありますが、嫌ですよねｗ

それはそれでヤバげだけど、意外と問題がない気も。

Optionalのmap/flatMapにinout版があれば済みますよ

その Element! 、かなり特殊な使い方ですね〜。おもしろい・・・。

というかinout reduceは他の構造のメソッド全部inout版作ってからが本番なので

二重 update するのか・・・ < Optionalのmap/flatMapにinout版があれば済みますよ

var x: Int! = 12 x += 12 // error: binary operator '+=' cannot be applied to operands of type 'Int!' and 'Int' っていう問題もあり。

↓こう？ < Optionalのmap/flatMapにinout版があれば ary.updateOrRemove { (elem) in elem.updateOrRemove { $0 = $0 % 3 == 0 ? nil : $0 * 10 } }

そんな感じ!

これは可読性ヤバそうｗ

$0使わなければ

9:05 AM

ary.updateOrRemove { (x) in x.updateOrRemove { (elem) in if elem % 3 == 0 { elem = nil } else { elem *= 10 } } } 普通に読めると思う (edited)

9:05 AM

インデント崩壊した

うーん…

extension Array { mutating func updateOrRemove(_ f: (inout Element, _ remove: inout Bool) -> Void) { var writeIdx = startIndex for readIdx in indices { var remove = false f(&self[readIdx], &remove) if writeIdx != readIdx { self[writeIdx] = self[readIdx] } if !remove { formIndex(after: &writeIdx) } } removeLast(distance(from: writeIdx, to: endIndex)) } } var ary = [1,2,3,4] ary.updateOrRemove { (elem, remove) in if elem % 3 == 0 { remove = true return } elem *= 10 } print(ary)

レトロ感

removeを関数にするとか・・・

Optionalでラップするとサブスクリプトの最適化が効かない気がするんだよね

http://twitter.com/omochimetaru/status/928264127591485441 書きました。みなさんの gyb 情報を引用させていただきました。

https://github.com/apple/swift/blob/master/validation-test/Python/gyb.swift

Swift で書けるメタプログラミング向けのテンプレートエンジン gysb を作った by @omochimetaru on @Qiita https://t.co/eVAaY12b1W #swift

なぜか全員ここの住人やね

それ

テストが欲しいね>gysb

gybのテスト真似したら良いのかな

apple/swiftの場合、swiftのビルド自体がgybのテストみたいなもので、gyb単体でのテストはなさげ？

doctest は一応動かしているはずです。

1:57 AM

swift - The Swift Programming Language

1

最低限だw

テスト欲しいですねテンプレートコンパイルの周りはふつうにSwiftPMで書けるけど、 gysbコマンド自体のテストは一個外側の仕組みが必要ですね

@omochimetaru ↓参考にならないかな？ https://github.com/kylef/Commander

kylef/Commander

Commander - Compose beautiful command line interfaces in Swift

あーでもまあコマンドの直下までは普通に書けるか

@koher 普通にモジュール単位でSwift内部でテストしてるように見えます

実際にテスト用のコマンド作ってそれを実行するテストがあったりするのかと思ったけどそういうわけではない？

そういう実用レイヤのやつは無さそうスマホでちょっと見ただけだから見落としたかもしれません。

長らく新規 Proposal が動いてなかったのに昨日から急に動き始めた。 https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md

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

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

protocol ASTNode : CustomStringConvertible { func accept<V: ASTVisitor>(visitor: V) -> V.VisitResult } protocol ASTVisitor { associatedtype VisitResult func visit(nop: NopNode) -> VisitResult func visit(text: TextNode) -> VisitResult func visit(code: CodeNode) -> VisitResult func visit(subst: SubstNode) -> VisitResult func visit(macroCall: MacroCallNode) -> VisitResult func visit(macroStringLiteral: MacroStringLiteralNode) -> VisitResult func visit(template: Template) -> VisitResult }

(edited)

3:23 AM

Visitorパターンの素体を protocol で組めて、 associatedtype で返り値の型もジェネリックにできて、ここまでは良かったんだけど

3:23 AM

throws / rethrows が適用できない事に気がついた・・・

3:24 AM

もし Node に渡す Visitor が例外を投げうるVisitor であれば、 Node.acceptは throws になってほしい。

3:25 AM

ASTThrowableVisitor protocol を定義して accept をオーバーロードすればいけるか・・・？

3:25 AM

全部のノードに accept の実体を２倍かかないといけないけど。

3:26 AM

https://github.com/omochi/gysb/blob/master/Sources/gysb/AST.swift https://github.com/omochi/gysb/blob/master/Sources/gysb/ASTVisitor.swift

gysb - Generate your swifty boilerplate

https://github.com/swift-script/swift-script/blob/master/Tests/SwiftParseTests/NodeEquatable.swift#L121 その例

gysb - Generate your swifty boilerplate

型をわける

3:28 AM

理論上は() throws -> T の特殊な状態として () ->T があると定義できるので

3:29 AM

ASTThrowableVisitor protocol を定義して accept をオーバーロードすればいけるか・・・？

これやね

struct TextNode : ASTNode { var text: String func accept<V: ASTVisitor>(visitor: V) -> V.VisitResult { return visitor.visit(text: self) } var description: String { return "Text(\(escapeToSwiftLiteral(text: text)))" } }

(edited)

3:30 AM

こういう、個別のNode型から visitor.visit の呼び戻しを書く必要があるんだけど

3:30 AM

これ全部 ThrowsableVisitor 用も必要になるよね。

そうやね

3:30 AM

ASTVisitor

3:30 AM

これを単なる関数として定義すれば

3:30 AM

throws - rethrowsで書けそうだけど

型ごとにいっぱいメソッドがある Visitor だから

3:39 AM

単なる関数にはならんのだよね

https://github.com/swift-script/swift-script/blob/master/Sources/SwiftAST/Visitors.swift これで throws じゃない Visitor もconform できたけど、そういう話じゃない？

返り値VisitResultだから引数enumにしたらいけそうなもんだけど

@rintaro これだと、実際にはthrowsしないVisitorにおいても、throwsしちゃうから、 try 必要ですよね

3:41 AM

まあ throws しない Visitor なんて無いやろって感じもあるけど・・・

swift-script/swift-script

Contribute to swift-script development by creating an account on GitHub.

3:43 AM

ああ、そうですね＜ try 必要ですよね

3:43 AM

try! をかける必要がありました。https://github.com/swift-script/swift-script/blob/master/Tests/SwiftParseTests/NodeEquatable.swift#L32

swift-script/swift-script

Contribute to swift-script development by creating an account on GitHub.

ですよね〜

とはいえ、クライアントが Visitor を生で使うことはあまり考えられず、普通はラッパ関数通して使うし、ラッパ関数はその Visitor が実際に throw するか否かは分かると思うので、いいかなという気がする。 (edited)

たしかに・・・

3:48 AM

それはめっちゃそうな気がしてきた

3:49 AM

throwsつけちゃお

3:49 AM

ありがとうございます

1

3:50 AM

extension ASTNode { func print() { // Printer never fail try! accept(visitor: ASTPrinter()) } }

3:50 AM

こういうわけですね。

3:51 AM

コメントだとあれだからアレしとこ

fails では？

英語？

英語

たしかに。

gysbくらいの規模のASTならいっそenumにしてしまって、Vistorパターン使わずパターンマッチ使うという手もあるかもですね！そしたらthrowするしないも使う側で適当に決めれますし

たしかに・・・

4:04 AM

きれいなVisitorパターンをやってみたかったという動機が大きいです

1

protocol ASTNode : CustomStringConvertible { func accept<V: ASTThrowsVisitor>(visitor: V) throws -> V.VisitResult } extension ASTNode { func accept<V: ASTVisitor>(visitor: V) -> V.VisitResult { return try! accept(visitor: visitor) } }

これでさ、

4:08 AM

protocol ASTVisitor: ASTThrowsVisitor { associatedtype VisitResult func visit(nop: NopNode) -> VisitResult ... } extension ASTVisitor { func visit(nop: NopNode) throws -> VisitResult { return visit(nop: nop) } }

こうしたらいけないかね

4:09 AM

protocol ASTThrowsVisitor { associatedtype VisitResult func visit(nop: NopNode) throws -> VisitResult .... } これ忘れてた

あ〜

4:09 AM

投げない側がサブタイプなのか

理論上は() throws -> T の特殊な状態として () ->T があると定義できるので

4:10 AM

サブタイプ扱いにしてしまえばなんとかなるかな?と

accept 呼び出すところで、型がキツイ方のオーバーロードが優先されるはずだから

4:10 AM

うまくいく気がする！！

1

4:15 AM

あれか、 ASTVisitor を実装するときに、例外を投げちゃいけない事を、静的に強制できない？

ん?あー

4:19 AM

できない。。。かも

あと、 extension ASTNode { func accept<V: ASTVisitor>(visitor: V) -> V.VisitResult { return try! accept(visitor: visitor) } }

4:19 AM

ここで怒られた、名前解決が同じやつになっちゃって

ありゃー

accept例外投げんぞ？tryいらんで

4:19 AM

っていわれたので

4:19 AM

まあメソッド名を変えました

だめか

4:20 AM

available駆使して、throwついてる方の呼び出しをどうにか禁止できれば

4:20 AM

まあそれっぽくなるかなと思ったけどまだavailableにアクセス修飾子漬けれないしムリくさい (edited)

まあ完璧ではないけどかなり良い感じ

やべえ

6:38 AM

enum case の let 先置き派として

6:38 AM

気がついてしまったんだけど

6:39 AM

switch x { case let . // ← let があるとここでドットを入力しても補間が出ない・・・

よし、先置き辞めよう

6:39 AM

これでようやく心を入れ替えれるね

case かいてドット打って補間してから　 ←に戻って let を打たないといけない・・・

letは中、いいね？

なんてこったい

おお？

print(["ab", "cd"].flatMap { return $0 }) // ["a", "b", "c", "d"] print(["ab", "cd"].flatMap { $0; return $0 }) // ["ab", "cd"]

https://twitter.com/gregheo/status/928787861507207168

Greg Heo (@gregheo)

Swift observer effect at work:

print(["ab", "cd"].flatMap { return $0 }) // ["a", "b", "c", "d"] print(["ab", "cd"].flatMap { $0; return $0 }) // ["ab", "cd"]

ぉおー、後者はクロージャの return type が Any とかに infer されてるのかな？

1:39 AM

ちがうか、(String) -> String? として扱われてて、呼び出される flatMap が違う。

やはり

1:47 AM

型として変性が認められるもの(クラスなど)と、値としてのみ変性が認められるもの(Optionalなど)にわけて、前者だけ関数・ジェネリクスの変性に使えるようにすれば

1:47 AM

大分平和になりそうだなというのを朧気に考えていた

前者は

Sequence.flatMap<SegmentOfResult: Sequence>(_ transform: (String) throws -> SegmentOfResult) rethrows -> [SegmentOfResult.Element]

後者はCollection.flatMap(_ transform: (String) throws -> String?) rethrows -> [String]

https://github.com/omochi/gysb/blob/master/Sources/GysbKit/Config.swift#L23-L47

https://developer.apple.com/documentation/foundation/thread

gysb - Generate your swifty boilerplate

1:44 PM

Codableが、 Optional ならキーの省略を none と扱うように、 Array の場合にもキーの省略を空配列として扱ってほしかったが、エラーになるので、キーが省略されたら空配列としてデコードできるように↑のように書いたんだけど、もっと記述量少なく、やる方法ってありますか？

素直にinit(from:)を書いた方が良いのでは。

decodeIfPresent と ?? [] か・・・

あれ？自分でやる場合、KeyedContainerの nestedUnkeyedContainerを呼び出すんですよね？

2:47 PM

あ、普通にdecodeIfPresentに[Stone].self とかわたせばいいのか

#if os(Linux) class A #else @objc class A : NSObject #endif { }

4:41 AM

これがコンパイルできないんですけど良い方法ありますか？

4:42 AM

Foundation.Threadを使おうとしているが、Macの場合は init(target:selector:) を使う必要があるので @objc が必要

4:42 AM

Linuxの場合は init (block:) でいけるので不要

これは２つ書くしかないんじゃなかったかな。

4:42 AM

#if os(Linux) class A { } #else @objc class A : NSObject { } #endif

ンゴ・・・

4:43 AM

了解です、今そうなっちゃってるんですが、とりあえずそのままで。。

将来的にはわからないけど、 #if はCのプリプロセッサみたいに何かの途中で、とかはできなかったです。

ある程度構文上の制約があるんですね

4:46 AM

まあそのほうが、IDEとか安定しそう。

NSBlockOperationとか使って共通化出来ない？

お・・・

4:48 AM

やりたいことできるかわからんけど https://developer.apple.com/documentation/foundation/blockoperation

スレッドはどうしても立てる必要があるんだよね

GCDじゃダメなんです？ (edited)

別プロセスからパイプを読み出したい

4:49 AM

あ〜

4:50 AM

よくわかっていないんですけど、DispatchQueueって、

4:50 AM

すぐに終了しない、ブロックする関数を投げてもうまく動くんですか？

4:50 AM

細切れで何度も再入するようなタスクにしてやらないと

4:51 AM

キュー達に対する下請けの実ワーカースレッドの割当スケジューラが

4:51 AM

詰まっちゃう気がしています

4:52 AM

言い換えると、キュー一本に専用のスレッドが一個確保されることを保証したモードはあるか、という事

１つのキューがずっと同じスレッドかどうかの保証はなかったと思います。

4:55 AM

もともとやろうとしてることは１つのNSThreadで待つつもりなんですよね？

そうですね

同じようにGCDのクロージャで待てばいいと思いますよ。

なるほど

4:57 AM

あー、足りなければスレッドが生まれて、遊んでれば再利用みたいな制御なのかな・・・？

4:57 AM

固定数のスレッドプールがあるわけではなくて。

私の言いたいことは、NSOperationはNSThreadよりも高級だけど、GCDとNSThreadと同等なので、今はNSThreadを直接使うということはしないんじゃないかなということです。

まあ原則はそうですよね

5:03 AM

https://github.com/apple/swift-package-manager/blob/d9e8e8b7180e7fca034b0f727c02abe00e933d43/Sources/Basic/Process.swift#L330

https://github.com/apple/swift/pull/12868/files

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

5:03 AM

SwiftPMの内部で、外部プロセス立ち上げて、stdoutを吸い出すのにスレッドを立てているんですが、単にDispatchの実装を待ってられないから独自に用意したんだろうか

5:04 AM

こういうところでたまに見るので、逆に生スレッドのほうがいいユースケースがあるのか、それともどんなユースケースでも絶対に上位互換になるのか

5:04 AM

そのへんの境界が正確にわかっていなくて、

5:05 AM

よくわからない場合はできるだけシンプルな道具を使ったほうがいいと思っているので悩みます。

5:07 AM

もともとの質問にあった NSThread が二重定義になってしまう問題については、継承して func main をオーバーライドするパターンなら共通コードにできることに気がついて解決しました。ありがとうございました。

[Don't merge] Use conditional conformances to implement Equatable for Optional, Array and Dictionary by huonw · Pull Request #12868 · apple/swift

7:05 AM

+extension Optional : Equatable where Wrapped : Equatable { + /// Returns a Boolean value indicating whether two optional instances are + /// equal. + ///

7:05 AM

↑いい感じ！

3

4.1に含まれてほしい！

2

別プロセスからパイプを読み出したい こんな感じにしてる https://gist.github.com/norio-nomura/90a374d33c5178fdbc336b1e50cf74dc

execute.swift

PipeがFoundationのやつじゃなくて自作なんですね。 DispatchIOだ。使ったことない。

Foundationのものはクローズが判らなかったので、自作したと記憶。

クローズした場合長さが0の Data が来ると思っていました。

8:04 AM

思っていた、っていうか、今そういう前提で書いています。

8:04 AM

 let stdoutPipe = Pipe() let stdoutThread = Thread { while true { let chunk = stdoutPipe.fileHandleForReading.availableData if chunk.count == 0 { break } stdout(chunk) } } stdoutThread.start()

今のはそう動きますね。以前のは違ったらしい。

↑こう

8:04 AM

ああ、なるほど。

8:05 AM

readabilityHandler が実装されてればそもそもスレッドもいらんかったんですが

8:05 AM

Linux版はまだ NSUnimplemented になっていました

あ、Linuxで動くかどうかは確認していないです。

8:09 AM

単純に出力全部を最後に取得するだけなら、こんなのは必要なかった。

8:10 AM

リアルタイムで外部へ流しながらキャプチャするために作った。

ああ。僕もまさにその目的です。

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/041142.html

4:44 AM

クリスラトナーが、他の動的言語とブリッジするための仕組みの、Swift側のシグネチャについてのプロポーザルを投下してめちゃめちゃ盛り上がってる具体例としてはPythonをそのままSwiftコードとして呼び出す事を想定している。

4:45 AM

Joe Groffが、その前に静的な Callable Object について整備したほうがいいって言ったり、 Slava Pestov が、関数呼び出しの種類がもう一個増えるのは厳しい、って言ったり

4:52 AM

SwiftML読んでて思うけど大筋反対の意見に対してもその中にあるアイデアを拾ってそれは大事だね！みたいな感じで紳士的に進んでいくのすごい

https://twitter.com/clattner_llvm/status/929221571964628992 ちょっと場外戦に発展しちゃってる。

Chris Lattner (@clattner_llvm)

@jckarter @slava_pestov @JadenGeller I love working in open and inclusive communities which are friendly and encouraging towards open source contributors. I hope swift will get one someday.

Likes

119

おや。合間合間に読み進めているのでまだスレ追いつけてないｗ

↑のツイートきえてた。

1:46 AM

スレでもツイートでも　すまなかった　みたいな感じになってて良かった

LazySequenceProtocolがSequenceを継承しているの辞めたほうが良いのではと思ってるんですがどうですかね

@tarunon 問題点はどこですか？

Sequence.FilteredSequenceとか高階型が出来たとして

1:24 AM

それらの結果がLazySequenceの類であるためには、

1:24 AM

引数のクロージャが@escapingでなければならない、 (edited)

1:25 AM

現状も全部オーバーロードしていて、あまりよろしくないのでは、という気がしています

今って https://developer.apple.com/documentation/swift/lazysequenceprotocol/2905213-flatmap と https://developer.apple.com/documentation/swift/sequence/2905332-flatmap ってどうやって見分けられてるんですっけ？

1:28 AM

どちらかというと、問題は Sequence にデフォルト実装されてるメソッド群だと思うんですよね。純粋に makeIterator を持つだけの型がほしい。

それはそうですね

1:28 AM

だから、makeIteratorを持つだけの型をベースに

1:29 AM

SequenceとLazySequenceをその継承として再設計、というイメージでした

1:29 AM

えーっと見分け方は、基本的には条件が厳しい方が優先なので

1:29 AM

LazySequenceなら特に外から制約が加わらない限りは、LazySequenceのオーバーロード群が優先されそうです。

問題は Sequence にデフォルト実装されてるメソッド群

どれもmakeIteratorから機械的に生成できるものをSequenceの場合に最適化版を生やしているだけじゃないんですか？

1:30 AM

なぜそれが問題になる？

それはLazySequenceにとっては邪魔なのでは?という点です

1:31 AM

LazySequenceのprefixにArray/AnySequenceが存在するのはおかしい

makeIteratorがある時点で一緒では

let a: [Int] = [2, 3, 5] let b = a.lazy let c = b.flatMap { [$0, $0] } print(type(of: c)) LazyCollection<FlattenBidirectionalCollection<LazyMapBidirectionalCollection<Array<Int>, Array<Int>>>>

1:32 AM

これって @escaping じゃない Sequence の flatMap 呼ぶのはどうすればいいんですっけ？

as Arrayとかやればよさそう

ｗ

@nonescaping をクロージャの型に明示できないっけ

1:32 AM

@nonescaping を @escaping に変換することはできないから自然といけそう

let a: [Int] = [2, 3, 5] let b = a.lazy let c: [Int] = b.flatMap { [$0, $0] } print(type(of: c)) Array<Int>

https://developer.apple.com/documentation/swift/lazysequence/1689962-prefix

1:35 AM

LazySequenceのこの手のメソッドが一通りSequence版とLazy版があって

1:35 AM

オーバーロード解決でSequence版を踏んだところでlazyになってた要素が巻き取られる

1:36 AM

というのが現状か

そう

@nonescaping をクロージャの型に明示できないっけ

できるっけ？やり方わからない・・・

個人的には明示的にメソッド呼んでlazy解除がいいと思う

「巻き取る」ことを明示的に「.asSequence」とかで変換するほうが

そうそうそうそうそう

ずっとlazyであることが確実になるね。

1:36 AM

まーたしかにどうせどこでSequenceになるかを意識して書かないといけないのだから

1:36 AM

明示的に変換させるほうがマシな気もするな。

今の状態はぱっと見たときにどこからlazyじゃなくなったのかわからん (edited)

これもまた暗黙のキャスト系の話しだな・・・

てかね

1:37 AM

Sequence.Filteredとか高階型のMapped導入しても

どうなんだろう今の状態じゃないと効率的じゃないパターンがあるのかも

@escapingの有無が解決できない以上LazySequenceは完全にSequence protocolの上に乗ることが出来ない

それはぱっと思いつかないけどなぁ < 効率的じゃないパターン

あれ？ @nonescaping なくなった？

それは2までかな

lazy → nonlazy 変換は現状で↓でできるから、 makeIterator を持った protocol を分離して（ Iterable とか）、 LazySequenceProtocol はそれを継承して、 Array が Iterable を受けるイニシャライザを持てば OK そう。 let a: [Int] = [2, 3, 5] let b = a.lazy let c = Array(b) print(type(of: c))

error: TempGround.playground:3:9: error: @escaping attribute may only be used in function parameter position var b: @escaping () -> Void = a ~^~~~~~~~~

1:40 AM

func f(a: @escaping () -> Void) {} var a: () -> Void = {} f(a: a)

1:40 AM

勝手に @escaping になっちゃうしローカル変数だと表明できないのか

ローカル変数は無理でしょ

1:40 AM

変数に入った時点で @escaping では？

その変数が他のescapingなクロージャから参照されるとかでエスケープしていないなら (edited)

1:41 AM

大丈夫そうだけど

1:41 AM

@nonescaping をクロージャの型に明示できないっけ

まあこれは無理でした

もし↓こんなのできたら意味不明じゃない？ func foo() -> @nonescaping () -> Int { return { 42 } }

そこに書けたらおかしいですね。

うーん、戻り値で返せないならローカル変数に書けても問題は起こらない？

shared と inout は、ローカル変数には書けるようにする提案がありますよ

1:44 AM

その変数宣言以降の行を即時クロージャに包んで引数にそのmodifierをつけるのと

1:44 AM

実質的に同じだからです

1:44 AM

今は無理だけど。 (edited)

1:46 AM

func f() { var a: Int = 3 var refA: inout Int = a refA = 4 } ↑コレは今は無理だけどできていいよねって話で

1:46 AM

func f() { var a: Int = 3 func f2(refA: inout Int) { refA = 4 } f2(refA: &a) } ↑なぜならこれができちゃうからです

1:46 AM

同じような事が @escaping にも言えないかなと思っていた。

nonescaping は引数にしか現れないけど（デフォルトだから修飾子はいらないけど）、↑の原理で言えばいけそうな気がするね。 (edited)

1:49 AM

でもそれって escaping と nonescaping のオーバーロードがあるときにしか役に立たなそう・・・

1:51 AM

escaping は nonescaping のサブタイプだから、 nonescaping への変換は問題にならないし、ローカル変数に代入されたクロージャでも実質的に nonescaping で良いものだったら最適化でインライン展開とかまでされそう。 escaping のオーバーロードがない限り。

ん

1:52 AM

nonescapingがescapingのサブタイプじゃないですかね?

1:52 AM

あれ?

いや、あってると思う

あかん、ねむすぐる

escapingなものを nonescaping に渡せるけど逆は無理

@tarunon US 時刻なんでしたっけ？ｗ

たしかにだからそもそもlazy版が呼べるシチュエーションでは通常版がどうせ呼べちゃうな。

US時刻は問題ないんですが機内で寝てないので

1:53 AM

さながら徹マン明けで実験する大学生の状態です

@tarunon たまたま目が覚めて夜中のツイートリアルタイムに見たんですが、ここで参加すると寝れなくなると思ってスルーしましたｗ

w

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

uounɹɐʇ (@tarunon)

US来て一番辛いの、ディスコにネタ投げたいのに現地時間午前4時で誰も反応しないところだ

それ

投げて１日待って

それTwitterに書いたときは未だ遠慮する気持ちが微塵ほどはあったんですが、堪えきれなかった

ｗ

RxSwiftのcombineLatestはオリジナルなテンプレート言語を実装していた簡単なテキスト処理で swift に変換してる。 https://github.com/ReactiveX/RxSwift/tree/master/Preprocessor https://github.com/ReactiveX/RxSwift/blob/master/Preprocessor/Preprocessor/main.swift#L69

RxSwift - Reactive Programming in Swift

RxSwift - Reactive Programming in Swift

combineとzipは組み合わせになるからそうやね

現状のジェネリクスの範疇で作れないから、生成はしてると思ってたけど、どんなツールでやってるかは調べてなかった。

新しい Proposal 。 https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md

https://twitter.com/tkremenek/status/930975883027820545

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

7:06 AM

妥当な気がする。

Ted Kremenek (@tkremenek)

Starting the process of moving https://t.co/05nHDp8DmE’s mailing list to Discourse, see: https://t.co/frAPh1hHr5

3:04 AM

ボランティア募集らしい

To help with this, I am looking for 3-4 volunteers from the Swift community to create a workgroup to discuss and create a plan for the structure for the Discourse-based forums.

https://github.com/apple/swift-corelibs-foundation/pull/1301 Foundation、swift-evolutionとは別のパブリックなプロポーザル制になったのかな？ (edited)

Add SCLF-0001: JSON Key Strategies by parkera · Pull Request #1301 · apple/swift-corelibs-foundation

Add a proposal for handling snake and camel case keys in JSONEncoder.

While we have no formal process at this time for proposals of changes to Foundation-only code, I would still like to post one that we have run through our internal process here for additional public comment.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040959.html

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

この後Foundation-onlyのプロポーザルプロセスの続報はあったのかな？

2017 LLVM Developers’ Meeting: “Implementing Swift Generics ” https://youtu.be/ctS8FzqcRug @YouTubeさんから

LLVM

2017 LLVM Developers’ Meeting: “Implementing Swift Generics ”

11:33 PM

Slava pestovとJohn maccallがSwiftのジェネリックコードのコンパイルについて説明する動画 (edited)

11:34 PM

前半のSlavaが Value Witness Table で、後半のJohnが Protocol Witness Tableに言及してて、とてもよくわかる

2

11:34 PM

クロージャのthunk変換とかも出てくる

11:35 PM

2年前にこの動画が見たかったｗ

コメントって範囲に対して書きたくなりませんか？ /* ○○の処理 */ { foo() bar() baz() } みたいな。 (edited)

なるけどできないからだいたいこうする // xxの処理 foo() bar() baz() // yyの処理 (↑の空行がxxの処理の終わり感を出す) (edited)

do 使うのは？

1:34 AM

変数宣言絡むとあれですけど

そうだね。いつも do で書いてる気がしてきた。

1

1:35 AM

↓みたいなの作ったらどうかと思ったけど正気を失ってた。 func *(lhs: String, rhs: () -> ()) { rhs() } "○○の処理" * { foo() bar() baz() }

do にコメント統合できると文章的に理解できて良い気がする do something { ~~ }

do /* これでいいのでは？ */ { }

処理: do { // ... } も大抵はいけるｗ (edited)

@omochimetaru それでいいですけど囲うの面倒でだいたい末尾に//で書いてます

同じく do { // something } (edited)

1:39 AM

もしくは // ○○の処理 do { }

実際 PREPARE: do { } PROCESS: do { } FINALIZE: do { } みたいなのはたまに使います。

ラベルがあるとラベルジャンプを使うのでは？って読者が無駄に警戒してしまいませんかね

1:45 AM

二重returnぐらいでしか使わないからパット見みつからないし大丈夫かな

なるほど、そういう心配か。抜けるには break PREPARE などラベルを明示しないと抜けられない＋ラベルくらいしか全大文字使わないので目立つ。ので問題無いと思っています。

swiftのラベルはループ周りだけなんですかね？だとしたらdoについてるのは実質無意味として見られそう

PREPARE: do { guard let foo = foo else { break PREPARE } } とか動きます。

便利そうだな

1:50 AM

見落としてるだけでうまく使えるところがありそう

1:51 AM

https://github.com/omochi/gysb/blob/master/Sources/GysbKit/Parser.swift#L85

gysb - Generate your swifty boilerplate

doがbreakできるんですか。 guardの中だけかな

↑これとか、 while { switch { } } の形で、whileを抜けたいからローカルfunc 作ってreturnしてるんだけど

1:52 AM

ラベルにできそうだ。

guard じゃなくてもbreakできますよ。

さっきコンパイル通らなかった気がしたんですが普通に実行できました

ラベル break は Java とかでもある気がする。

// Java public class LabelBreak { public static void main(String[] args) { FOO: { System.out.println("A"); if (Math.random() < 0.5) { break FOO; } System.out.println("B"); } } }

ちなみに、 continue で redo 的なこともできるんだけど、これが正式にサポートされているかは不明。 PREPARE: do { if !finished { continue PREPARE } }

えっ、かっこいい

2:03 AM

一番下に書けばwhileもどきになりますね。

パーサ書くとき等に便利な場面もあるんですけどね。 (edited)

ありそう > パーサ

gysb自分で使ってみたけどいい感じテンプレート https://github.com/omochi/ReactiveEmitter/blob/master/Sources/ReactiveEmitter/Operator/Combine.swift.gysb 生成物 https://github.com/omochi/ReactiveEmitter/blob/master/Sources/ReactiveEmitter/Operator/Combine.swift gyb使ったときに比べてよかったのは

静的チェック (変数名の typo が検出できた )
三項演算子が便利 (例: ${ i < n-1 ? ",": "" })

ReactiveEmitter - Lightweight observable in Swift seen from EventEmitter in JavaScript.

ReactiveEmitter - Lightweight observable in Swift seen from EventEmitter in JavaScript.

1

3:28 AM

joinedが [String] のメソッド (pythonだと separator.join([s0, s1, s2])

RangeReplacableCollectionのreplaceSubrangeメソッドが、レンジとして RangeExpression というプロトコルを渡すようになっていた https://developer.apple.com/documentation/swift/rangeexpression

2:08 PM

{Countable}{Closed}Range の4種類がこれを満たしていて

2:09 PM

RangeExpression.relative(Collection) で Range に変換できるみたいで

2:09 PM

@koher のよく言ってる4種類のレンジのオーバーロードの話って、これで解決する？

2:10 PM

https://developer.apple.com/documentation/swift/rangereplaceablecollection/2853454-replacesubrange ドキュメントだと Range<Index> を取っていて、 RangeExpression になってないのだけど。

2:12 PM

同時にもう一個気になった事があって、 Protocol Extensionで提供されたメソッドが mutating のとき、conformしてる型がclassだと、 var でないとメソッドが呼び出せない。自分でconformするときは nonmutating func でconformできるのに。このおかげで、本当は replaceSubrange だけ実装すればいい場面で、 append やら、なにもかも、デフォルト実装の恩恵がうけられない。

やりたかったこと https://github.com/omochi/ReactiveEmitter/blob/master/Sources/ReactiveEmitter/ArrayProperty.swift 残念な結果 https://github.com/omochi/ReactiveEmitter/blob/master/Sources/ReactiveEmitter/RangeReplaceableCollectionClass.swift (edited)

ReactiveEmitter - Lightweight observable in Swift seen from EventEmitter in JavaScript.

https://github.com/apple/swift/pull/13012/files

ReactiveEmitter - Lightweight observable in Swift seen from EventEmitter in JavaScript.

public protocol RangeReplaceableCollectionClass : class, RangeReplaceableCollection {} にしたかったって事？

そうですね。appendとかを、RangeReplaceableCollectionのデフォルト実装で済ませたかった。

なるほど。

4:53 AM

where self: immutable みたいなのが欲しくなるね

mutatingだけじゃなくて、initの制約もあるから、今回の目的だとそれだけでもダメそうでした

4:57 AM

initでプロパティの実体を参照して、変更時にイベントを流そうとしてるけど、プロパティの実体を受け取らないinitを持たなきゃいけないので、

4:58 AM

あくまで様々な変更操作を自動定義する部分だけ欲しかった

RxDataSorcesに、自身を引数に取るinitをrequiredにすることで、擬似的にmutableっぽい挙動を実現させてる実装があるからワンチャン参考になるかも (edited)

なるほど。後でみてみる

[swift-evolution] Python Interop with Swift 4+ by Chris Lattner https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171113/041463.html (edited)

PyTuple_New とかなんで使えるのかと思ったら

2:28 AM

冒頭で import Python してますね

2:28 AM

そもそもそんなパッケージがOSX SDKに入ってるのしらんかった。

2:29 AM

let d = np.call(member: "array", args: Python.array(6, 7, 8), kwargs: [("dtype", "i2")]) proposalが通れば↑の呼び出しがSwiftの通常関数呼び出しのように書けると (edited)

import Python ってどこ？

2:30 AM

ああ

2:31 AM

PythonGlue

PythonInterop.playground/Source/PythonGlue.swift

↓ない。 https://developer.apple.com/documentation/python

/System/Library/Frameworks/Python.framework

同じとこにRuby.frameworkなんてのもある

ヘッダーを見ればいいのか

2:36 AM

Jump to Definition うまくいかないけど、 Swift で展開されたインタフェースがみたい・・・

Playgroundで import Python って書いたら飛べました

2:37 AM

iOSじゃなくてMacOS Playgroundにして。

お、できた

いきなりPythonGlue.swiftを開くのではなく、PythonTutorialの中でPython.importとかからJump to Definitionした先から行くとひらけます。 (edited)

1

なるほど

2:41 AM

ARC 化してる・・・

 public init(borrowed: UnsafeMutablePointer<PyObject>) { state = borrowed Py_IncRef(state) } public init?(borrowedNullable: UnsafeMutablePointer<PyObject>?) { if let borrowed = borrowedNullable { state = borrowed Py_IncRef(state) } else { return nil } } public convenience init(python: PyVal) { self.init(owned: python.ownedPyObject) } deinit { Py_DecRef(state) }

2:41 AM

owned と borrowed と区別してるのか

2:42 AM

もうちょっと上があった。

public final class PyRef : PyVal { private var state : OwnedPyObject public init(owned: OwnedPyObject) { state = owned } public init?(ownedNullable: OwnedPyObject?) { if let owned = ownedNullable { state = owned } else { return nil } } public init(borrowed: UnsafeMutablePointer<PyObject>) { state = borrowed Py_IncRef(state) } public init?(borrowedNullable: UnsafeMutablePointer<PyObject>?) { if let borrowed = borrowedNullable { state = borrowed Py_IncRef(state) } else { return nil } } public convenience init(python: PyVal) { self.init(owned: python.ownedPyObject) } deinit { Py_DecRef(state) } public var borrowedPyObject : UnsafeMutablePointer<PyObject> { return state } public var ownedPyObject : OwnedPyObject { Py_IncRef(state) return state } }

Add generic associatedtypes, generalized supertype constraints and conditional default arguments by anandabits · Pull Request #13012 · apple/swift

This PR adds a few items to the generics manifesto. The first two were discussed briefly on Twitter where @DougGregor requested a PR to add them. I plan to followup with a pitch to Swift evolutio...

7:30 AM

この PR で、 Generic Manifesto に「Generic assciated types」の節が追加されるんですが

7:30 AM

+Associatedtypes could be allowed to carry generic parameters. + +Swift +protocol Wrapper { + associatedtype Wrapped<T> + + func wrap<T>(_ t: T) -> Wrapped<T> +} + +Generic associatedtypes would support all constraints supported by the language including where clauses. + +Note: generic associatedtypes address many use cases also addressed by [higher-kinded types](#higher-kinded-types) but with lower implementation complexity.

(edited)

7:32 AM

備考: generic associatedtypes は高階型で取り扱う(address) 多くのユースケースを取り扱う (edited)

7:32 AM

って書いてあって気になる。

これ高階型とどこが違うのな

7:39 AM

ぱっと見理解できない

俺も Swift の protocol が高階型と違う点を自分なりに考えた時、　ジェネリックな型 F<T> を名前 X で受けた時に、 X を F と T でばらして扱えるかどうかだと思って

7:40 AM

この定義なら Wrapped<T> , Wrapped , T でバラせるから同等な能力な気がする

これ使ってモナドプロトコルってどうやれば作れる？↓とか？

protocol Monad { associatedtype Value associatedtype Generated<T>: Self where T == Value func flatMap<T>(_ transform: (Value) -> Generated<T>) -> Generated<T> }

あー、 Self からガワのモナドだけ取得する必要がありますね

Haskell では flatMap だけ抜き出すと↓。 class Monad m where (>>=) :: m a -> (a -> m b) -> m b

9:01 AM

↓ Functor class Functor f where fmap :: (a -> b) -> f a -> f b

koher の例だと Optional<T> : Monad をみたそうとすると、 T -> U の flatMap で Generated : Optional<T> って制約になっちゃってできなそう？

1

今の Swift の Self って特殊すぎると思う。

Haskell class Eq a where (==) :: a -> a -> Bool class Monad m where (>>=) :: m a -> (a -> m b) -> m b (edited)

9:15 AM

Swift

protocol Equatable { static func ==(lhs: Self, rhs: Self) -> Bool } protocol Monad { ??? // どんな記法が馴染む？ }

9:20 AM

つまり、 Haskell では（ Swift の言葉で言うと）プロトコルを一度別の記号 a や m に読み替えているから自然に書けるけど、 Swift ではそれを Self で表しているのでジェネリックにしたときにどう書いていいのか。 Self が Haskell の Monad の m じゃなくて m a を表してしまっているので m b をうまく書けない・・・。

Monadは表現できないっぽいですね、あくまでArrayかLazyかを明記するためのものに感じる

protocol A { associatedtype E } protocol B { associatedtype E } struct C: A, B { typealias A.E = Int typealias B.E = String }

これはムリ。困った。仕様?実装上の都合?

例のごとく深い意図があるのかたまたまそうなのかわからない系やな・・・ドキュメントで明確に言及してるものを見た記憶は無し

@tarunon AとBにそれぞれのEを返すメソッドなりプロパティなりがあって、typealiasを省略できる書き方にしたらどう？

駄目です

だめかあ

これに関しては考えつく限り全てのワークアラウンド試して全滅しました

3:34 AM

因みにさっきのひらりの例は、ambitiousと出てコンパイルエラーになる気がします

ambiguous

EをAとBそれぞれのメソッドから型が推論出来るが制約レベルが同一なため決定できない→ambitious

3:36 AM

これ困ってる理由は、ObserverとObservableTypeで

ambitious なコンパイルエラーｗ

3:36 AM

大志を抱いてる

Eの型を変換させながらバイパスしたいときに、ObserverTypeとObservableTypeを準拠できないんですよ

https://bugs.swift.org/browse/SR-3329

アンビシャス

あw

草

綴りが悲しいことに

3:38 AM

まあ良いや通じるっしょ

ｗｗ

@rintaro こういうのってどうやって検索してるんですか？

すでに投稿されてるんですね、スレ読んでみる

https://bugs.swift.org/browse/SR-5473?jql=text%20~%20%22associatedtype%20same%22 とか？

This kind of disambiguation has been discussed on the Swift evolution list a few times, but no single proposal has gotten traction yet.

@koher ですです。今回は "associatedtype same name"

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

残念ながら仕様だしMLにも過去に出てきたと

コンパイラコミッターならではの知識データベースができあがってるのかと思ってました

SR-3329自体はConditionalConformanceが来れば何かしらのカタチで落ち着きそうだ

https://github.com/github/swift-style-guide 気づいたらGitHubのSwift Style Guideがアーカイブされちゃったけどなんでだろ

github/swift-style-guide

swift-style-guide - Archived Style guide & coding conventions for Swift projects

https://github.com/github/swift-style-guide/commit/0d559eec3ed5375ba4320154b99e5051e5cfbcda#diff-04c6e90faac2675aa89e2176d2eec7d8

RIP · github/swift-style-guide@0d559ee

8:26 PM

誰も触らないからサヨナラということらしい

8:30 PM

ConditionalConformance以降、 extension Array: MyProtocol ってやった場合って、Array全てがextension持つ(暗黙的にArray<Any>ではない)ってことになるのかしら

8:31 PM

あー

8:32 PM

extension Array: MyProtocol where Element: Any こう解釈出来ますね、そして全てOKになる

↓がやけに長い associatedtype 名になってるのって、この前話した衝突回避のためなのかな？

protocol DynamicCallable { associatedtype DynamicCallableArgument associatedtype DynamicCallableResult func dynamicCall(arguments: [DynamicCallableArgument]) throws -> DynamicCallableResult }

https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d

DynamicCallable.md

1:44 AM

この DynamicCollable 、 Python の import に限らず純粋に Swift の範囲でも使えそう。これまで何度か値を callable にしたくなったことがあった気がする。 Codable のときもそうだったけど、 JSON のデコード楽にしたい→汎用的な仕組みを導入の流れ、いい。

1:44 AM

ただ、引数が [DynamicCallableArgument] は動的型付け言語にひっぱられすぎな気も？

Swiftの範囲で使うと型が死にますよ

↓じゃダメだったのかな？

protocol DynamicCallable { associatedtype DynamicCallableArguments associatedtype DynamicCallableResult func dynamicCall(arguments: DynamicCallableArguments) throws -> DynamicCallableResult }

(edited)

それだとPyValのときどうなります？

1:46 AM

引数を構築するラッパーが毎回必要になりそう。

typealias DynamicCallableArguments = [PyVal] じゃダメ？

pythonはラベルごとに渡せるから

1:47 AM

配列ではダメですね

じゃあ typealias DynamicCallableArguments = [String: PyVal] は？

1:48 AM

typealias DynamicCallableArguments = [(String, PyVal)] でもいいけど。

そうすると、呼び出しのときに毎回辞書作る感じになりますよね

1:49 AM

swiftのラベルつき呼び出しをシームレスに渡したくてそうなってるみたいです

typealias DynamicCallableArguments = [(String, PyVal)] なら変わらないのでは？

長いassoc名はそうですね、スコープになったほうがよさそう

1:51 AM

今の提案は

1:51 AM

obj.method(a: 1, b: 2)

1:52 AM

って書くと、 [(“a”, 2), (“b”, 3)]が dynamicCallに渡る

1:54 AM

あれ？さっきのちょっと違うな ~ protocol DynamicCallable { associatedtype DynamicCallableArgument associatedtype DynamicCallableResult func dynamicCall(arguments: [(String, DynamicCallableArgument)]) throws -> DynamicCallableResult } ~ (edited)

1:57 AM

[swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

1:57 AM

このメールに書いてあるやつです

1:57 AM

途中で変わったのかな

1:59 AM

protocol DynamicCallableWithKeywordsToo : DynamicCallable { func dynamicCall(arguments: [(String, DynamicCallableArgument)]) throws -> DynamicCallableResult }

[swift-evolution] [Pitch #2] Introduce user-defined dynamically "callable" types

の方を見てる。

新しい提案で型が分割されていたのですね https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d

DynamicCallable.md

古い方追ってなかったからどういう議論があって変わったのかは知らない。

2:03 AM

うーん、これは Callable にするものというより、純粋に DynamicCallable と捉えた方がいいのか。

2:03 AM

それなら当然型はないし N 個の引数でも当たり前か。

新しい方でも配列の要素の型が単一化されちゃうから

2:04 AM

一般のCallableには遠いですね

あまりにもざっくりとしか読んでなかった。

なんか、色々すっ飛ばして、パイソンバインディングしよう！ってのがまず考えられてて

2:05 AM

それでスレも若干荒れてました

2:08 AM

JavaScriptはラベルつきが無かったはずだから前者だけやればいいのかな

#beginner-help-archived のやつ、 #if で else if 消すことができなかったから、コードの重複を消すために gyb で制御して #if を生成するという闇コードに・・・。

extension Image where Pixel == ${pixel_type} { public init(uiImage: UIImage) { % for core_image_available in [True, False]: % if core_image_available: #if os(iOS) || os(tvOS) % else: #else % end if let cgImage = uiImage.cgImage { self.init(cgImage: cgImage) % if core_image_available: } else if let ciImage = uiImage.ciImage { let context = CIContext() // This `guard` can be replaced with `!` if you are sure that the `createCGImage` below never fails. guard let cgImage = context.createCGImage(ciImage, from: ciImage.extent) else { fatalError("Failed to create a `CGImage` from an internal `CIImage` object from this `UIImage` instance: \(uiImage)") } self.init(cgImage: cgImage) % end } else { // This `gurad` can be replaced with `assert` if you are sure that the `size` is always equal to `.zero`. guard uiImage.size == .zero else { % if core_image_available: fatalError("The `size` of this `UIImage` instance (\(uiImage)) is not equal to `.zero` though both `cgImage` and `ciImage` of the instance are `nil`.") % else: fatalError("The `size` of this `UIImage` instance (\(uiImage)) is not equal to `.zero` though `cgImage` of the instance is `nil`.") % end } self.init(width: 0, height: 0, pixels: []) } % if not core_image_available: #endif % end % end }

メソッドでラップすれば良いのでは。

init なので切り出すのが微妙なのと（できなくはないですが、 UIImage が特定条件のときだけ呼ばれる private init は可読性低そうなので）、たとえ切り出しても条件分岐のコード自体は多重になってしまうんですよねぇ。

init でしか呼べないメソッドみたいな仕組み欲しいですよね、イニシャライズが複雑になりがちなclassに

stored propertyを全部タプルで固めてstatic funcで取り回せば、なんとかなることがあるよ

4:24 AM

self.initだと制約がキツくてなんともならないことがままある

class以下の要素について複雑さをひとまとまり毎に型を作ってそれぞれのinitで表現すればいいんじゃないの

今やりたいのは↓なので

init(uiImage: UIImage) { if let cgImage = uiImage.cgImage { self.init(cgImage: cgImage) } else if let ciImage = uiImage.ciImage { ... self.init(...) } else { guard uiImage.size == .zero else { fatalError(...) } self.init(width: 0, height: 0, pixels: []) } }

4:28 AM

この } else if let ciImage = uiImage.ciImage { ... self.init(...) の部分が watchOS では CoreImage が使えない関係でエラーになってしまうので除去したいけど #if でここだけ除去できないので

4:31 AM

共通部分をくくりだすにしても

イニシャライズはしないといけないのでメソッドにはできない
例えば else { } の中イニシャライザにしようとすると型で区別できない→特殊なラベル名を持ったイニシャライザを作ることになるけど、 UIImage がサイズ .zero のときにしか呼んではいけないとかわかりづらすぎる
その側の if/else if/else の条件分岐の条件は括り出しようがない

のでコードジェネレーションで共通化しました。

@koher watchOSの場合だけ UIImage に ciImage メソッドをextensionで足すのはどうですか？実装としてはnilを返すだけにしておく。 (edited)

2

private な extension にするのか。それはありかも。

nil返すだけExtension割とやる

下側のレイヤーで吸収する

4:32 AM

上側だとこのように制御が絡んでつらい

4:33 AM

ちょうど最近 @ikesyo も同じようなアレをextensionを併用して畳み込んでました

CIImageという型自体が存在しない場合は、適当な偽の型を作って吸収できるかな?

4:34 AM

typealias CIImage = Never とか

空のclass定義しちゃえばええと思う

空のclassだとinitできちゃうからNever aliasの方が良くないかな

Neverつかうとこの行実行されないっすよのwarningいっぱい出ない？

あーそれうざいね

CIImage だけじゃなく CIContext も作ることに・・・

引数にNeverを取るinitだけ生やせば生成されないことは保証できるからそれが良いかな?空enumはオレオレで作れたっけ

空のclassだとinitできちゃう

initを @available で潰そう

やるやる

まあ private なのでそこはいいかと。

空enum作れるからそれが一番良さそう

それNeverとして働くんじゃないっけ

警告は出ないNever

Never として働くはず。

で使えるんじゃ

4:38 AM

あれ、出るのか

警告出ないんですっけ？

4:38 AM

記憶が定かでない・・・

空enum=Neverなの

4:39 AM

知らなかった…

出ないっぽい

4:39 AM

空enum、偽型とかネームスペースにも使えて便利だ

4:40 AM

そういえば最近ネストprotocolのevolution上がってた気がする(タイトルだけ見た)

空enumを返すメソッド、guardの中から離脱するやつとしても使えるってこと？

@hiragram Never のような振る舞いはするけど型としては別です。 1> enum Nothing {} 2> Nothing.self == Never.self $R0: Bool = false 3> Never.self == Never.self $R1: Bool = true

ふむ

コンパイラの諸々の加護もないから警告も出ないよ

空enum便利そう

guard let hoge = fuga else { piyo() // <- 空enumを返すメソッド } これコンパイル通るん

4> func foo() -> Nothing { 5. fatalError() 6. } 7> guard false else { 8. foo() // OK 9. }

うおーまじか

今回の件に関してだと、 enum だと : AnyObject を満たさないので、 CIImage が : AnyObject であることに依存したジェネリックなメソッドが他にあったりするとうまくいかないかなと思ってた

局所的に使うだけだから空 enum でもいいかも

CIImageってAnyObjectだっけ?

まあ、初期化部分だけの問題だから他のメソッドは全部 #if で消せば大丈夫かな

4:43 AM

@tarunon ObjCのオブジェクトは全部そうなんじゃないか

うおクラスだ

局所的に使うだけだから空 enum でもいいかも

現実的にはそうかも

open class CIImage : NSObject, NSSecureCoding, NSCopying {

4:44 AM

CFStringとかCGImageもclassなんすね

4:44 AM

めっちゃstructだと思いこんでた

てかそうじゃないといろいろ無理じゃない？

4:45 AM

もともとObjC側でクラスインスタンスとして振る舞ってretain/releaseされるやつらだから。

Obj-Cだからね

Data とかは Swift側で明示的に定義された struct で、内部で class NSData を保持するだけのCOWだよ

CoreGraphicsとかCoreImageとかUIKitとかいつになったら完全にSwift化されるんだろうな…（遠い目

なぜか as NSData できるから一見 toll free だけど中のフィールドが飛び出してくるだけ

enumにNSObjectProtocolをconformさせようとすると失敗する話

4:46 AM

NSObjectProtocolの定義はclassって書いてないのにclassじゃないとコンパイル通らないの感情が厳しい

CGImage 等に限らず、他の言語でも大抵は画像の型を作ろうとすると参照型になってしまうので、 Swift の特性を活かして値型の画像型作ったらおもしろそうという意味もあり EasyImagy 作ってます。

@objc enumで書かないとダメかな？

実際には暗黙的にclass強制なのでどうやってもダメッポ

@lovee それってむしろ Int になりそう？

4:48 AM

associated value つけられなくなったような

ダメだった

4:53 AM

https://developer.apple.com/documentation/objectivec/1418956-nsobject?language=objc 公式ドキュメント読んだらそもそもNSObjectってObj-Cではプロトコルで定義されてそれがSwiftにはNSObjectProtocolとしてブリッジされてるだけのようで…

 public init(uiImage: UIImage) { func cgimage(from uiimage: UIImage) -> CGImage? { #if os(iOS) || os(tvOS) return uiimage.cgImage ?? { guard let ciImage = uiImage.ciImage else { return nil } let context = CIContext() guard let cgImage = context.createCGImage(ciImage, from: ciImage.extent) else { fatalError("Failed to create a `CGImage` from an internal `CIImage` object from this `UIImage` instance: \(uiImage)") } return cgImage }() #else return uiimage.cgImage #endif } if let cgImage = cgimage(from: uiImage) { self.init(cgImage: cgImage) } else { // This `gurad` can be replaced with `assert` if you are sure that the `size` is always equal to `.zero`. guard uiImage.size == .zero else { fatalError("The `size` of this `UIImage` instance (\(uiImage)) is not equal to `.zero` though both `cgImage` and `ciImage` of the instance are `nil`.") } self.init(width: 0, height: 0, pixels: []) } }

(edited)

ここまでくると結構読みにくいですよねイニシャライザ

gyb使うよりはマシな気がしますよ。

gyb は別の理由で元々使ってるので

4:56 AM

extention 作戦でシンプルにできました

https://github.com/koher/EasyImagy/commit/75ea73121c7afbd6d3540dbdeb197233b5020448

Simplify the implementation of Image(uiImage:) · koher/EasyImagy@75ea731

1

なるほど、複数登場するのですね。

登場箇所は１回だけどそれがgybの中だから

4:57 AM

.swiftとしては何回も出てきている？

なるほど、複数登場するのですね。

そうなんです。 Conditional Conformance が導入されれば gyb 消せるところもありそうですが・・・。

4:59 AM

登場箇所は１回だけどそれがgybの中だから .swiftとしては何回も出てきている？

extension は .swift でも 1 回だけど、それを使うコードを複数回です。

1

4.1でconditional conformanceちゃんとリリースされそうな流れですね。標準ライブラリ側も込みで。 https://github.com/apple/swift-evolution/pull/769

[SE-0143] Amend to include adoption of conditional conformances to Equatable by DougGregor · Pull Request #769 · apple/swift-evolution

As discussed in this thread, amend SE-0143: Conditional conformances to include the adoption of conditional conformances for Equatable by Optional, Array, and Dictionary. Implementation available a...

3

スケジュールもそれに合わせてきてる感じ [swift-dev] Final re-branch for Swift 4.1 pushed out to December 4 https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171127/006036.html (edited)

なるほど。感謝祭からちょっと後の方が確かに良い気もする。

Conditional Conformance に関連して CountableRange 等の廃止の話を見た記憶がないんですが、それはされないんでしょうか？

詳しく見てないですが、それくらい大きい変更はSwift 5になるのではと勝手に思っています (edited)

ソース互換性はなくなっちゃいますもんねぇ。 typealias を作っておけば大丈夫なのかな・・・。

RangeExpressionでオーバーロード4重化は回避されてるけど、CCを使ってそれ無しに同じことができるんですか？

1:14 AM

いまはPartial系があるから4重じゃなくて、いくつあるんや・・・

@omochimetaru RangeExpression は必要なんじゃないかな？でも Countable 系は Conditional Conformance があれば不要なはず。

Indexの型でRangeの条件付き系になるのか

うん

protocol P { var p: Int { get } } extension P where Self: A { var p: Int { return self.p * 2 } } class A {} extension A: P {} let instance = A() print(instance.p)

12:40 AM

これ、コンパイルエラー出せないんですかね

classだけでも自身のプロパティ参照してループ作れる

なるほど・・・

最終的に結果が出るループと出ないループの区別が難しい、みたいな話を聞いた気がします

12:42 AM

pとq作ってお互いに参照したらそれもループだけど

12:43 AM

この手のやつ判定しようとするとO(2^フィールドの数)になるんじゃないかな

12:44 AM

単純なやつでも、サブクラスまで見ないといけないというのもあるから難しいかも。

う〜んたしかにpだけでも再帰で収束させられるし仕方ないのか

↓では？ https://ja.wikipedia.org/wiki/%E5%81%9C%E6%AD%A2%E6%80%A7%E5%95%8F%E9%A1%8C

%E5%81%9C%E6%AD%A2%E6%80%A7%E5%95%8F%E9%A1%8C

プログラムが停止するかどうかを一般的に判定するプログラムを作ることはできません（数学的に証明されています）。特定の問題について考えても、ちょっとしたプログラムでも停止するかどうかを考えるのはとても難しいです。たとえば、↓のプログラムが停止するかを効率的に判定できるプログラムを書けるなら、それでフェルマーの最終定理が解けてしまいます。

outer: for i in 3... { for n in 3...i { for x in 1...i { for y in 1...i { for z in 1...i { if x ** n + y ** n == z ** n { break outer } } } } } }

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

 let yPlaneBuffer = CVPixelBufferGetBaseAddressOfPlane(pixelBuffer, 0) yPlaneData.withUnsafeBytes { (data) in yPlaneBuffer!.copyBytes(from: data, count: yPlaneData.count) }

2:11 AM

これコンパイル通るのなんでだろう

2:12 AM

yPlaneData は Data 型で、 withUnsafeBytes は

 public func withUnsafeBytes<ResultType, ContentType>(_ body: (UnsafePointer<ContentType>) throws -> ResultType) rethrows -> ResultType

2:12 AM

で、copyBytes は public func copyBytes(from source: UnsafeRawPointer, count: Int)

2:12 AM

だから

2:12 AM

クロージャの (data) の推論が

2:13 AM

UnsafePointer<ContentType> と UnsafeRawPointer でぶつかって解決できないように思う

https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-ID146

When a function is declared as taking an UnsafeRawPointer argument, it can accept the same operands as UnsafePointer<Type> for any type Type.

(edited)

なるほど、じゃあ、引数渡すときに UnsafePointer< XXX > は UnsafeRawPointerに暗黙キャストできる

2:17 AM

具体的に XXX は何にになっているんでしょ・・・

UnsafePointer<()> になっているっぽいです。

マジか・・・

2:24 AM

/Users/omochi/work/playground/MacGround.playground:1:8: UnsafePointer<Void> has been replaced by UnsafeRawPointer

2:24 AM

いまって UnsafePointer<Void> つかうとワーニングでるのに。

2:24 AM

それってどうやってわかりました？ > なっている型

PlaygroundのQuick Help Inspectorで見えますね。

お。アプリの方でやってたけど、No Quick Help になってました。

closureのパラメータじゃなくて、copyBytes(from:count:) に渡しているほうの data だと出ません？

おお！！

2:27 AM

出ました。なるほどーありがとうございます。

2:27 AM

どっちでも同じ結果になるとおもいこんでいました

closure パラメータの Quick Help が出ないのはバグっぽいですよねー。

なるほど

2:28 AM

なんか結構、なんだ出ないやんけってスルーしてる事があるきがするけど

2:28 AM

使ってるところでやってみるのがよかったのか。 (edited)

https://bugreport.apple.com お願いします＞＜

どっちがいいんでしょう

2:30 AM

bugs.swift.orgと

SourceKitレベルで情報を取れない事が確認できるならば bugs.swift.org がいいのでは。確認できないなら bugreport.apple.com かな？

1

あ〜なるほど・・・そういうふうに動いているのか

2:34 AM

あとで報告しておきます

ちなみに、typecheck 結果の確認は -dump-ast でも出来ますよ。

SOURCEKIT_LOGGING=3 /Applications/Xcode.app/Contents/MacOS/Xcode でログをみた感じでは、SourceKitが返した情報をXcodeが表示していないだけぽい。

https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md Swift 5 で breaking な変更が入ります。 (edited)

Merge pull request #12834 from jrose-apple/restrict-cross-module-stru… · apple/swift@8f8f000

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

3:22 AM

もし引っかかると場合によってはマイグレーション不可案件なので、お知らせまで。

structでモジュールを跨いでオレオレinitを作れなくなる?

はい、4.1でワーニング出るようになると思います。

masterにはマージされてるけど、含んだスナップショットはまだ出てないのね。 https://github.com/apple/swift/commit/8f8f00012a391b7c254e2056ef382c768ca7671a

…ct-initializers-2 Implementation of SE-0189 "Restrict cross-module struct initializers to be delegating" rdar://problem/34777878

Swift で書けるメタプログラミング向けのテンプレートエンジン gysb を作った - Qiita https://qiita.com/omochimetaru/items/422ddd04e95c55dd3833

Swift で書けるメタプログラミング向けのテンプレートエンジン gysb を作った - Qiita

メタプログラミングとテンプレートエンジン

プログラミングにおいて、そのプログラミング言語の機能だけではプログラムを書くのが大変だったり難しいときに、外部のツールなどを用いて、「プログラムを出力するプログラム」を作成して対応するこ...

昨日のXcodeがクラッシュしたコード、

1:51 AM

多分、Playgroundに貼るとクラッシュ

1:51 AM

ですね、Swiftのバージョンは関係なかった

ううむ、どうも再現しないんですよねー

むむむ

init(throws x: String) throws { // この中でOptionalなsuper.init(convenienceでself.init)を呼んでnilならErrorを出したい }

↑protocolワークアラウンド無しで解決する方法が欲しい

ベースが自前クラスならそっちもfailableじゃなくて throws にすべきでは？と思いますね

なんだっけ

5:48 AM

これ困ったのNSURLだった気がする

5:48 AM

NSURL(string: String) これをthrowsにしたい、できないおわた

じゃあだめだー

という感じ

5:48 AM

でも今はstruct URLになって困らなくなりました。

5:48 AM

UIImageで未だ困ることがある

protocolワークアラウンドって例のself代入ですか

そうです

5:49 AM

一旦optional initを適当な変数に受けてguard unwrap throwsしてselfに代入

まぁそれしかないですよね。

class Child: Base { init(b: String) throws { super.init(a: b) ?? { throw NSError() }() } } ↑こういうのやりたいですね

そり

無理やりだけどこういうのはどうですかね？

class Child: Base { static func `init`(b: String) throws -> Child { guard let child = Child(a: b) else { throw NSError() } return child } }

えっとそれは厳密にはinitではない

それってChild(b: "") で呼べるんですかね

返り値の型がSelfにならないので

まあ見た目上では（）

6:14 AM

それってChild(b: "") で呼べるんですかね

それが呼べるんですよ

1

Childの更にサブクラスを使うと崩壊です。 (edited)

1

呼べるのか……

あ、throwsがあると呼べないっぽい？

protocol workaroundだとSelf型でいけるんですが、あれはあれでまぁoptional initがrequiredでないと死亡とか結局詰んでる気はする

4.1-dev は今日 master から最終 re-branch されたので、今はほとんど master と同じです。

ほう

https://swift.org/blog/swift-4-1-release-process/

Swift 4.1 Release Process

This post describes the goals, release process, and estimated schedule for Swift 4.1.

なるほど > December 4, 2017 (final branching)

いまフラグ無しでcond conf使えるってことはやっぱ入れることになった可能性もあるかも？

それっぽいPRは無さそうな気がする

1

[omochi@omochi-iMac swhash]$ cat b.swift struct Box<T> { let value: T } extension Box: Equatable where T: Equatable { static func == (lhs: Box, rhs: Box) -> Bool { return lhs.value == rhs.value } } [omochi@omochi-iMac swhash]$ swift --version Apple Swift version 4.1-dev (LLVM c698959a5c, Clang dff0a814ae, Swift 9fef06e59c) Target: x86_64-apple-darwin16.7.0 [omochi@omochi-iMac swhash]$ swift b.swift b.swift:6:1: error: conditional conformance of 'Box<T>' to 'Equatable' depends on an experimental feature (SE-0143) extension Box: Equatable where T: Equatable { ^ [omochi@omochi-iMac swhash]$ swift -enable-experimental-conditional-conformances b.swift [omochi@omochi-iMac swhash]$ echo $TOOLCHAINS org.swift.3020171204a

9:24 AM

やっぱりオプション入れないとダメでした 12/04版

9:25 AM

Hashableの生成について

9:25 AM

https://github.com/apple/swift/blob/124251cf2c4b45225c15667a705d4441effe0d8b/stdlib/public/core/Hashing.swift#L198

https://github.com/apple/swift/blob/97ac580384b7989f6f6e0b8ee3943fd3f5675f46/lib/Sema/DerivedConformanceEquatableHashable.cpp#L956-L968

swift - The Swift Programming Language

9:25 AM

@_transparent public // @testable func _mixForSynthesizedHashValue(_ oldValue: Int, _ nextValue: Int) -> Int { return 31 &* oldValue &+ nextValue }

9:25 AM

31倍しながら足すようになってた。

structは31倍しながら足せばOKなのはわかる

9:26 AM

enumってどうなるかわかります?

enumは多分case番号を最初に混ぜ込むんじゃないかなあ

9:29 AM

enum Zoo : Hashable { case cat(Cat) case dog(String) }

9:29 AM

// Zoo.hashValue.getter sil hidden @_T01a3ZooO9hashValueSivg : $@convention(method) (@guaranteed Zoo) -> Int { // %0 // users: %4, %3, %1 bb0(%0 : $Zoo): debug_value %0 : $Zoo, let, name "self", argno 1 // id: %1 %2 = alloc_stack $Int, var, name "result" // users: %131, %126, %88, %85, %75, %72, %63, %25, %22, %12, %9, %134 retain_value %0 : $Zoo // id: %3 switch_enum %0 : $Zoo, case #Zoo.cat!enumelt.1: bb1, case #Zoo.dog!enumelt.1: bb6 // id: %4

9:29 AM

other-swift flagsに何か入れてません?

1

// %5 // users: %66, %15, %6 bb1(%5 : $Cat): // Preds: bb0 debug_value %5 : $Cat, let, name "a0" // id: %6 %7 = integer_literal $Builtin.Int64, 0 // user: %8 %8 = struct $Int (%7 : $Builtin.Int64) // user: %10 %9 = begin_access [modify] [static] %2 : $*Int // users: %10, %11 store %8 to %9 : $*Int // id: %10 end_access %9 : $*Int // id: %11

// %68 // users: %129, %78, %69 bb6(%68 : $String): // Preds: bb0 debug_value %68 : $String, let, name "a0" // id: %69 %70 = integer_literal $Builtin.Int64, 1 // user: %71 %71 = struct $Int (%70 : $Builtin.Int64) // user: %73 %72 = begin_access [modify] [static] %2 : $*Int // users: %73, %74 store %71 to %72 : $*Int // id: %73 end_access %72 : $*Int // id: %74 %75 = begin_access [read] [static] %2 : $*Int // user: %76 end_access %75 : $*Int // id: %76

9:32 AM

ちゃんと追ってないけど冒頭で分岐したジャンプ先に0と1がそれぞれあるからこれな気がする

9:33 AM

6ケースまで増やしたらこの箇所が2,3,4,5と増えてった

9:37 AM

@かっくん試したのってSwift 4.1 Developmentのスナップショットですか？

9:37 AM

僕が試したのは Trunk Development (master) なのでそこの違いかもしれません。

@omochimetaru そうです！

の2番目の画像のスナップショットです！

あ、なるほど、 Swift 4.1 Snapshot になっていますね。こっちでは Swift Development Snapshot になっていました。

1

9:40 AM

ダウンロードできたら試してみます

9:43 AM

https://github.com/apple/swift/blob/97ac580384b7989f6f6e0b8ee3943fd3f5675f46/lib/Sema/DerivedConformanceEquatableHashable.cpp#L992-L1038

swift - The Swift Programming Language

9:44 AM

structのhashValueジェネレータ (edited)

9:45 AM

https://github.com/apple/swift/blob/124251cf2c4b45225c15667a705d4441effe0d8b/stdlib/public/core/Hashing.swift#L123-L129

swift - The Swift Programming Language

9:46 AM

ここにコメントで全部書いてあったわ

9:48 AM

https://github.com/apple/swift/blob/97ac580384b7989f6f6e0b8ee3943fd3f5675f46/lib/Sema/DerivedConformanceEquatableHashable.cpp#L839

swift - The Swift Programming Language

var result: Int result = _mixForSynthesizedHashValue(result, 1) 初期値無いように見えるけど

最後に謎のシャッフルがかかってる

enumのほう

9:48 AM

これは初期値0の誤植かな

ほんとだ

PRチャンスでは!!?!?!?!?

たしかに・・・

これそもそも最初にresultと1を_mixForSynthesizedHashValueに入れる必要もないよね

9:51 AM

0&*31&+1になるんでしょ、1じゃん

swift - The Swift Programming Language

9:51 AM

実際のenumの生成はここで、この行がcaseごとのループ

9:52 AM

そのforループより上にvar result の生成はある

じゃけcase毎にresult作る、AssocValuesをループする前に0,1,2,3...で初期化される、ということでいいんじゃない

9:54 AM

そうすると result = _mixForSynthesizedHashValue(result, 1) // 🙅 result = 1 // 🙆 ってことだよね

だね

おもち、じゃんけんだよ

で、 associated value があったら

9:54 AM

payloadVar (associvalues) についてのループで

9:54 AM

_mixForSynthesizedHashValueでの足し込みが生成される

9:55 AM

ジャンケンとは

1

9:59 AM

俺は別にプルリク出したいとは思ってないので出したければどうぞ

swift-4.1-DEVELOPMENT-SNAPSHOT-2017-12-04-aはConditional Conformanceのビルド通るね。

struct Box<T> { let value: T } extension Box: Equatable where T: Equatable { static func == (lhs: Box, rhs: Box) -> Bool { return lhs.value == rhs.value } } Box(value: 1) == Box(value: 2)

Playground execution failed: error: PlayNow-20171205.playground:7:15: error: ambiguous use of operator '==' Box(value: 1) == Box(value: 2) ^ PlayNow-20171205.playground:2:17: note: found this candidate static func == (lhs: Box, rhs: Box) -> Bool { ^

使えそうには無いけど。

左様で

[omochi@omochi-iMac swhash]$ export TOOLCHAINS=org.swift.4120171204a [omochi@omochi-iMac swhash]$ swift --version Apple Swift version 4.1-dev (LLVM cdc9836644, Clang f0e38d2044, Swift 7a0598c7dd) Target: x86_64-apple-darwin16.7.0 [omochi@omochi-iMac swhash]$ swift b.swift

10:02 AM

こちらも今確認できました。

10:02 AM

[omochi@omochi-iMac swhash]$ export TOOLCHAINS=org.swift.3020171204a [omochi@omochi-iMac swhash]$ swift --version Apple Swift version 4.1-dev (LLVM c698959a5c, Clang dff0a814ae, Swift 9fef06e59c) Target: x86_64-apple-darwin16.7.0 [omochi@omochi-iMac swhash]$ swift b.swift b.swift:6:1: error: conditional conformance of 'Box<T>' to 'Equatable' depends on an experimental feature (SE-0143) extension Box: Equatable where T: Equatable { ^

10:02 AM

この２つの違い、 $ swift --version だとほとんどわからんですね。

https://github.com/apple/swift/releases/tag/swift-4.1-DEVELOPMENT-SNAPSHOT-2017-12-04-a は最終ブランチ前なので、ちょっと古かったです。

[SE-0143] Put conditional conformances behind an "experimental" flag. · apple/swift@b59c30c

swift - The Swift Programming Language

どっちも4.1-devを名乗る

10:04 AM

-enable-experimental-conditional-conformances の実装が取り込まれてないってことですか？ > @rintaro (edited)

です。https://github.com/apple/swift/commit/b59c30c1afe2ae29ee20f14328b3ecb012fc02d6 が入ってない。

Conditional conformances aren't quite ready yet for Swift 4.1, so introduce the flag -enable-experimental-conditional-conformances to enable conditional conformaces, and an error when one declare...

[omochi@omochi-iMac swhash]$ cat b.swift struct Box<T> { let value: T } extension Box: Equatable where T: Equatable { static func == (lhs: Box, rhs: Box) -> Bool { return lhs.value == rhs.value } } print(Box(value: 1) == Box(value: 1)) print(Box(value: 1) == Box(value: 2)) print(Box(value: Box(value: 1)) == Box(value: Box(value: 1))) print(Box(value: Box(value: 1)) == Box(value: Box(value: 2))) [omochi@omochi-iMac swhash]$ swift -enable-experimental-conditional-conformances b.swift true false true false

10:07 AM

masterのほうは動いた。

10:07 AM

[omochi@omochi-iMac swhash]$ swift b.swift b.swift:11:21: error: ambiguous use of operator '==' print(Box(value: 1) == Box(value: 1)) ^ b.swift:6:17: note: found this candidate static func == (lhs: Box, rhs: Box) -> Bool { ^ Swift.Equatable:149:24: note: found this candidate public static func == (lhs: Self, rhs: Self) -> Bool ^ b.swift:12:21: error: ambiguous use of operator '==' print(Box(value: 1) == Box(value: 2)) ^ b.swift:6:17: note: found this candidate static func == (lhs: Box, rhs: Box) -> Bool { ^ Swift.Equatable:149:24: note: found this candidate public static func == (lhs: Self, rhs: Self) -> Bool ^ b.swift:13:33: error: ambiguous use of operator '==' print(Box(value: Box(value: 1)) == Box(value: Box(value: 1))) ^ b.swift:6:17: note: found this candidate static func == (lhs: Box, rhs: Box) -> Bool { ^ Swift.Equatable:149:24: note: found this candidate public static func == (lhs: Self, rhs: Self) -> Bool ^ b.swift:14:33: error: ambiguous use of operator '==' print(Box(value: Box(value: 1)) == Box(value: Box(value: 2))) ^ b.swift:6:17: note: found this candidate static func == (lhs: Box, rhs: Box) -> Bool { ^ Swift.Equatable:149:24: note: found this candidate public static func == (lhs: Self, rhs: Self) -> Bool

10:07 AM

4.1のほうはたしかにダメですね。型定義は通るけど == の呼び出しが死んじゃった

swift-DEVELOPMENT-SNAPSHOT-2017-12-03-a 以降ですよね。>-enable-experimental-conditional-conformances (edited)

 // var result: Int // switch self { // case A: // result = 0 // case B(let a0): // result = _mixForSynthesizedHashValue(result, 1) // result = _mixForSynthesizedHashValue(result, a0.hashValue)

に関しては、実装は _mixForSynthesizedHashValue 一回なので、コメントだけの問題かな？

はい、コメント上のコードが間違ってるって話と思ってます

10:11 AM

https://github.com/apple/swift/pull/13273

Improve sample code of deriveHashable_hashValue by tarunon · Pull Request #13273 · apple/swift

This pr is improvement of comment. Seems SomeEnumWithAssociatedValues implements require result initial value.

10:11 AM

早い

はい

2

10:14 AM

somke testってなんですか

https://github.com/apple/swift/blob/master/docs/ContinuousIntegration.md 基本的にはインクリメンタルビルドで、macOS で iOS とかのテストを行わないテストです。

https://en.wikipedia.org/wiki/Smoke_testing_(software)

swift - The Swift Programming Language

1

Smoke testing (software)

In computer programming and software testing, smoke testing (also confidence testing, sanity testing, build verification test (BVT) and build acceptance test) is preliminary testing to reveal simple failures severe enough to (for example) reject ...

smokeが動詞だと思っていた……

この記事英語むずい・・・

10:18 AM

smokeのニュアンスがいまいちよくわからん

10:19 AM

もともとのスモークテストの意味は「水道管に煙を流し込んで漏れがないかをチェックすること」です。それが転じて、マザーボードの新しいものを使って電気を通して煙が上がらないかチェックすることをスモークテストというようになり、さらに転じてソフトウェアの基礎的なテストをスモークテストというようになりました。

https://heartsn.com/management/web-consulting/it-glossary/su-line/smoke_test/

KawaiYasuko

スモークテストの意味と使い方をマスターしよう！

1

10:19 AM

だそうです

ほー

10:20 AM

物理的な話だった

特にテスト領域の指定にけむりモクモクのニュアンスがあるわけじゃなかったのね。

10:20 AM

そのまんま煙でテストしてた話だった。

今もやってんのかな

最初煙が出るくらい回しまくるっていうニュアンスで、ストレステスト的なのかと思ってた。 (edited)

ガスの元栓を閉めて屋内配管に圧力をかけて、圧力が下がっていかないかチェックするテストがガス設備の法定点検になってますね。 (edited)

10:22 AM

圧力が下がっていくならどこか漏れているので、そこで場所を特定するために煙入れそう。

あ〜なるほど

10:23 AM

穴が見つけられるのか・・・まさに・・・

ガス管だといつでも煙を入れられそうだけど、水道管だと一度水を入れてしまった後に煙を入れるのは難しそうだから、最初に水を入れる前のテスト的な感じになるのかな。

この挙動は知らなかった https://oleb.net/blog/2017/12/dictionary-codable-array/

うーん、keyがIntでもStringでもないDictionaryはエラーになってくれるのがうれしそうだけど

（Conditional Conformance以降は非Codable化）

KeyedContainerがString, Int以外をキーとして使えるかどうか、ってのは本来 Encoder, Decoder 次第だと思うんだけどな。

まあそれは仕方ないとしても、KeyがRawRepresentable なモノはKeyedContainerへ入れて欲しい。

本来 Encoder, Decoder 次第

それだとコンパイル時にチェックして型エラーにできなくないですか？共通の枠組みがあるからこそ型として縛れるのかと。

12:29 AM

Codable に DictionaryKey みたいな associatedtype があって、デフォルトで String とかだといいのかな・・・。

12:29 AM

String|Int であってほしいけど。

CodableってJSONとその仲間(Yaml)を意識したものなのか

12:29 AM

JSONより柔軟なシリアライザの場合も見据えたものなのか

KeyがRawRepresentableなモノはKeyedContainerへ入れて欲しい。

これは Int と String はそうしてほしいですね。

よくわかってないけど、それによりそう

12:30 AM

jsonは完全な方式だと思ってたけど辞書のキーがたしかに文字列しか取れないという縛りがあるんだなあ

@omochimetaru 扱える範囲が狭いほど型としての安全性が高まって、その範囲で汎用性が高いほど実用的なんじゃないかな？という意味では JSON はとても良いバランスだと思う。 (edited)

でもそれなら名前をJSONCodableにするべきだと思う

いや、 JSON っていうのは文字列のフォーマットで

12:32 AM

今はデータ構造を

12:33 AM

Number String Boolean Array Dictionary Null で汎用的に表す話をしてるから

12:33 AM

JSON ではないと思う。

12:33 AM

Dictionary は実際には [String: Value]

そのディクショナリーにそのしばりがあるのが

より正確に書くと

json由来の不自然なしばりにみえる

12:34 AM

辞書のキーはHashとEqがあればいいから、その枠組みでもArrayがキーになれてよい

Number: Value String: Value Boolean: Value [Value]: Value [String: Value]: Value Null: Value

はい、その表現能力をとるなら、それってJSONCodableって概念にしておいたほうがよいような気がする。

うーん、たしかに [Value: Value] でもいいかも？ちょっとまだ確信が持てない。

たとえばバイト列がもてないし、逆にブールやナンバーがない体型もありえるので

別に JSON に限った話ではないと思うんよね。

12:39 AM

DB のレコードを Codable で表すこともできるんじゃない？

EquatableだったらキーになれるというのはSwiftの中だけの話なのでシリアライゼーションの仕様としては難しいんじゃないかな。

12:41 AM

文字列の同値性もそこまで自明ではないけど。

たとえばバイト列がもてないし、逆にブールやナンバーがない体型もありえるので

この部分は JSON よりも広げてもある程度は問題なさそう。たとえばバイト列を JSON 化するときには文字列化すればいいわけだし。

12:45 AM

EquatableだったらキーになれるというのはSwiftの中だけの話なのでシリアライゼーションの仕様としては難しいんじゃないかな。

たとえば、 JSON で表せる値なら比較可能だと思うんですよね。 JSON value をキーとして許容する拡張された JSON 仕様を考えることはできそうな・・・。

まあCodableがJSONの扱いを便利にするように寄ってる感じなのはそうかな。

12:53 AM

難しいと書いたけど、なんでもキーにできるというのもアリだとは思います。ただその場合例外ケースを考えていくのがすごく大変になるんじゃないかな。

タイプセーフにしようとすると、 Codable が DictionaryKey を持ってて、 JSONEncoder は func encode<T>(_ value: T) throws -> Data where T : Encodable, T.DictionaryKey == String|Int みたいなことができないとダメな気がしてます。

仕様としてYAMLはキーに辞書も配列も使えるけど、各言語での実装がそうなってるとは限らない。

3:17 AM

キーが文字列だけというのは、まあ妥当な妥協点だとは思います。

3:21 AM

Conditional Conformanceが来てもDictionary: Encodable whereにKey : Encodableは付いて欲しく無い気はする。

3:24 AM

もう付いてた https://github.com/apple/swift/pull/13178/files#diff-b586e10e3c5fa7f2feb8cee6482b6e95R4243

[Coding] Make Codable conformances for Optional and collections conditional. by DougGregor · Pull Request #13178 · apple/swift

Array, Set, Dictionary, and Optional all provide unconditional conformances to Encodable & Decodable that dynamically check whether their type arguments are Encodable/Decodable. Now that we have co...

おお、↓なんですね・・・ extension Dictionary : Encodable where Key : Encodable, Value : Encodable

Codableはそうするしかなくて

6:08 AM

Dictionaryのエンコード成功/失敗はErrorで初めてわかる、としかならないのでは

これはコンパイルできる

protocol EventSinkProtocol { associatedtype Event func send(event: Event) } extension EventSinkProtocol { func asEventSink() -> EventSink<Event> { return EventSink.init() } } class EventSink<Event> : EventSinkProtocol { func send(event: Event) {} }

9:45 AM

これがコンパイルできない

protocol EventSinkConvertible { associatedtype Event func asEventSink() -> EventSink<Event> } protocol EventSinkProtocol : EventSinkConvertible { func send(event: Event) } extension EventSinkProtocol { func asEventSink() -> EventSink<Event> { return EventSink.init() } } class EventSink<Event> : EventSinkProtocol { func send(event: Event) {} }

9:46 AM

これはコンパイルできる

protocol EventSinkConvertible { associatedtype _Event func asEventSink() -> EventSink<_Event> } protocol EventSinkProtocol : EventSinkConvertible { associatedtype Event = _Event func send(event: Event) } extension EventSinkProtocol { func asEventSink() -> EventSink<Event> { return EventSink.init() } } class EventSink<Event> : EventSinkProtocol { func send(event: Event) {} }

9:47 AM

これもコンパイルできる

protocol EventSinkConvertible { associatedtype Event func asEventSink() -> EventSink<Event> } protocol EventSinkProtocol : EventSinkConvertible { func send(event: Event) } extension EventSinkProtocol { func asEventSink() -> EventSink<Event> { return EventSink.init() } } class EventSink<E> : EventSinkProtocol { typealias Event = E func send(event: E) {} }

えっと

「３段構成＋型パラとassocitype名が同じ」ときにうまくいかない

9:48 AM

RxSwiftでは３段構成だったが protocol の方は E で型パラは Event にして回避してた。でも Swift の Array と Sequence はどっちも Element だから名前は同じにしたいけど無理なんかな

assoctypeとGenerics parameterは同名であってもマッチしないのは前からそうだね

ん、それだと例1 が通るのが変じゃない？

1はフィールドでマッチングできる

9:49 AM

フィールドでマッチングした場合のみtypealiasの記述が省略可能

2の場合は間接的だからダメなのか

protocol extensionにフィールドがある場合はprotocolをconformした側は情報が皆無なのでダメ

2の場合に、名前が同じだから typealias をしようとしても左辺と右辺が同じになってしまってできない

それなーー

9:50 AM

僕はもうGenericsParameterの名前付けを諦めた

protocolのほうをきれいな名前にした？

そう

RxSwiftとは逆だね

あっ

9:51 AM

しまったな、DelegateProxyはGenerics側がDとPなんだよね

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041831.html

9:52 AM

このスレってこの話題かな（読んでない

9:56 AM

とりあえず型パラを汚くすっか

因みにProtocolにconformしてしまえば、中でもProtocolのassoctype名で使えるから

あ、たしかに

9:57 AM

最初のtypealiasぐらいか？悲しいの (edited)

僕はGenericsを汚くする派です

9:57 AM

そね

なるほど！

↑のメールはまた違う話題だったけど

11:59 AM

現状のassoc type推論を整理して新しいルールにして、わかりやすくする提案だった

お、この前 EasyImagy の Image と ImageSlice に ImageProtocol を導入しようとして同じ問題踏んだかも。なんで Array と Sequence でできてるのに、って思った。

2:23 PM

でも最終的にできてるな。確か大分 ImageProtocol 側の API を削って。その前はコンパイルエラーになって、その後セグフォになって、仕方なく色々削って通ったんだった。なので別の問題か？ https://github.com/koher/EasyImagy/blob/dev-0.4.0/Sources/EasyImagy/ImageProtocol.swift

SwiftOptional四方山話 - Qiita

EasyImagy - Makes it easy to process images in Swift

エスパーするとassociatedtypeにconstraintつけるとちょこちょこセグフォ出ることあったんでそれですかね？

2:06 AM

Recursive Constraint以降は改善するかなと予想してます

うーん、何が原因だったのか思い出せません

https://qiita.com/tarunon/items/844958accc4391097d97 の件、とりあえず↓だけでも禁止してほしいです。 class A { func foo() -> Int? { return nil } } class B : A { override func foo() -> Int { return 42 } }

はじめに

SwiftのOptionalを取り巻くあれやこれやについて考えを整理しつつ書きます。多くの人にとっては役に立たない雑多な話題かもしれません。差し当たりSwift EvolutionのDraftのDraftぐらいの話でし...

これも問題なんですよね

これの邪悪なのは、暗黙の型変換じゃなくて、 T is T? のサブタイピングが成り立ってしまってるとこです・・・。

これとGenericsに関しては成り立っちゃってるんで

7:28 AM

完全に仕留めないと

↓の邪悪だけどギリ暗黙の型変換と解釈できる・・・。 let f: () -> Int = { 42 } let g: () -> Int? = f

functionの引数返り値がGenericsの範疇みたいな解釈だとアウト

でも var a = 0 let f: () -> Int = { a += 1; return a } let g: () -> Int? = f

7:31 AM

として

7:32 AM

f() // 1 g() // 2 なのでアウト？

7:33 AM

↓と解釈すればインスタンスを共有してるわけではなく OK か。 let g: () -> Int? = { f() }

実際には多分、let: g () -> Int? = { .some(f()) } なんですよね (edited)

7:34 AM

今考えてるのは、

7:34 AM

Optional wrap operatorみたいなのがあって、TとT?の共変性は全部廃止!っていうのが

7:34 AM

普通に一番筋が良いのではというの(過激派並みの発想)

7:34 AM

とりあえず?を使うとして、

僕はオブジェクトは共有されてて、代入時にラップされてるだけなんじゃないかと思ってます。

let intOptional: Int? = 1?

7:35 AM

こう

気持ちはわかりますが、実現性は厳しいんじゃないかと思います・・・。

デスヨネー(´・ω・`)

あと、 foo?.bar のパースが・・・。

7:36 AM

foo?.bar はこれまで通りで、 (foo?).bar とかかな。

そこは区別つくだろうとは思っています

とりあえず、サブタイピングを始末するくらいなら現実味がある気がするんですよね。

7:37 AM

暗黙の型変換はさすがにもう厳しいんじゃないかと思います・・・。

Array/Optionalをオーバーロードして普通のは別名っていうユースケースが

7:38 AM

暗黙の型変換を倒さないと安息は得られなくてここが厳しい

「普通の」ってなんですか？ map みたいなこと？

map/flatMapがその代表

7:39 AM

Qiitaにも書きましたが、RxのObservable.just/Observable.fromもそれです (edited)

7:41 AM

モナドはこの関数、値はこの関数、っていう括りがOptionalの変換で破壊されてしまうので心中穏やかになれないんですよね

第三のOptionalを提案するとか

8:12 AM

暗黙的変換の許されないOptionalで、関数の引数や返り値として使うことを意図しています

8:13 AM

ダメだ、nullのある言語にOptional追加しましたみたいなことになる未来が見える

暗黙の型変換は諦めて、型システムをぶっ壊してしまってるサブタイピングだけは許容しないという方向で行くのが現実的じゃないですかね〜。

ですね

8:17 AM

とりあえず外堀を埋めて

8:18 AM

民草が慣れてきたら次です

これ変更してCoWに影響でてパフォーマンス変わるか?と懸念していて確かめてみたけどパフォーマンスには影響しなさそう。

import Foundation class Animal {} class Cat: Animal {} protocol Plant {} class Dandelion: Plant {} func address(of object: UnsafeRawPointer) -> String { let addr = Int(bitPattern: object) return String(format: "%p", addr) } let cats = [Cat()] let animals: [Animal] = cats address(of: cats) address(of: animals) // CoWが働いているのでcatsとアドレスは同じ let dandelions = [Dandelion()] let plants: [Plant] = dandelions address(of: dandelions) address(of: plants) // Plantは存在型なのでCoWは働かない? let ints = [1, 2, 3] let oints: [Int?] = ints address(of: ints) address(of: oints) // OptionalでラップするのでCoWは働かない

(edited)

final re-branch後最初のスナップショットが出てた swift-4.1-DEVELOPMENT-SNAPSHOT-2017-12-07-a

internal protocol FactoryInitializable { init(factory: () -> Self) } extension FactoryInitializable { init(factory: () -> Self) { self = factory() } } public protocol DisposerProtocol { func dispose() } public class Disposer : DisposerProtocol, FactoryInitializable { internal init(void: Void) {} public convenience init<X: DisposerProtocol>(_ base: X) { self.init(factory: { Disposer.init(void: ()) }) } public func dispose() {} } public class EventEmitter<Event> { private class Unsubscriber : Disposer { public override func dispose() {} } }

8:40 AM

↑ $ swift -O だとコンパイラが戻ってこないコード

8:41 AM

CPU使用率が99%に張り付く。

FactoryInitializableをextensionに隔離したほうが良さそう

でも snapshot org.swift.3020171206a だと大丈夫。

なんだっけ、extension含めアクセス修飾子がconfuseだからなんとかすっぺみたいなProposal

うーん、何の問題で何がどうして解決したのかわからん

メタプログラミングの勉強にSwiftSyntaxを使ってPower Assertのライブラリを作ってみました。まだすごく不安定で、対応してない式の方が多いし、ちょっと書き方を変えると動かなくなったりして実用には難しいですが、よかったら見てください。また手伝ってくれる方がいたらとても嬉しいです。 https://github.com/kishikawakatsumi/SwiftPowerAssert

kishikawakatsumi/SwiftPowerAssert

SwiftPowerAssert - Power Assert in Swift. Provides descriptive assertion messages.

2

やっぱり、コードインジェクションできるフックはあった方がいいのですねー。

SwiftSyntaxってもう標準でimportできるようになったんですね

4.1 toolchainが必要じゃないかな。

あ、はい、「もう」というか、「4.1では」ですね

2:58 AM

標準っていうとたしかにxcode同梱リリースのことをさしてしまいますね。。

masterブランチが標準の皆さん

自前ビルドしないでswift.orgからtoolchainsで入れられるものはもう標準気分

標準 #とは

標準でビルドプロセスにフックできる仕組みが提供されると夢が広がりますね。

それ欲しいですね〜

5:33 AM

swiftpmにプロポーザルとか過去にあったんかな

野良アトリビュートが氾濫しちゃう世界になり得るという心配がある。

間違いなくそうなるでしょうね。

あ、言語側の拡張も含めた話ですか

5:35 AM

単純に swift build に前処理挟みたい

5:35 AM

xcodeでいう run script

野良アトリビュートが氾濫する世界はそれはそれで悪くないですが、SwiftのFeaturesと同様にコミュニティで標準に組み込むものを決めるようにしたらいいんじゃないかと思っています。

swift build に Run script phase欲しいわかる

5:38 AM

コンパイルの手前でコード生成したい

コード生成をさせる方に進むのかコード生成が必要なくなる方に進むのか、どっちになるんだろ

5:39 AM

今は進んでないから仕方なくコード生成してるとして

5:40 AM

そもそも言語機能が揃ってないからどんなマクロが必要なのかもわからない、だった気がする

とりあえずまだまだGenericManifestoにテーマは残ってるから

5:40 AM

そういうのはどんどん実装されて、それに該当するメタプロはどんどん不要になると思うけど

5:40 AM

実装されないラインがどっかで引かれて

5:40 AM

その時まだメタプロしたいシナリオが残ってれば

5:40 AM

それだけは自動生成になると思う

5:41 AM

combineLatestとかは

5:41 AM

可変長引数ジェネリクスがあれば自動生成は不要で

そうだね

C++は実際それがテンプレートでできるんで、自分はわりと不要になりそうだけど

5:42 AM

API定義からモデルの自動生成〜とかは

5:42 AM

Swift言語機能の枠組みを超えてる感がある

わしはそう

5:42 AM

なのでコード生成のニーズはなくならないと思う。

EquatableとかHashableの自動生成は言語機能側で最近対応されて

5:43 AM

Sourcelyのニーズが１つ減ったね。

ProtobufとかSwaggerのモデルのコードが欲しいのは、API側で変更されるものであって、必ずしもswift buildに必要という感じでは無さそう

5:44 AM

SSSだと話は別か

SSSの場合はAPI定義書がSwiftの型定義そのものになってほしいね。

5:46 AM

一個モデル書いてCodable準拠しとけばサーバクライアント両方実装終わりってできると思う

ソースファイルを生成されるものは私はまあ必要悪だと思うので、CodableやHashableのようにSwiftの標準機能でサポートされるのはいいと思います。

5:48 AM

それとは別にPowerAssertのようにAssertメソッドのインストルメントしたいという場合や、指定したメソッドにロギングやトラッキング・パフォーマンス計測のコードを挿入したいとかあると思うんですよね。

ロギングとパフォーマンス計測については

5:50 AM

TypeScript の Decorator みたいな言語機能で整理できるかも・・・？

そうですね。TypeScriptのそれはよく知らないですが、名前からしてコンパイラプラグインのようなものですかね。

https://www.typescriptlang.org/docs/handbook/decorators.html

5:51 AM

function f() { console.log("f(): evaluated"); return function (target, propertyKey: string, descriptor: PropertyDescriptor) { console.log("f(): called"); } } function g() { console.log("g(): evaluated"); return function (target, propertyKey: string, descriptor: PropertyDescriptor) { console.log("g(): called"); } } class C { @f() @g() method() {} }

5:52 AM

クラスCのメソッドmethod にデコレータfとデコレータgを適用している例まあ、JSの動的性に依存した実装ですけど。

5:52 AM

PowerAssertはかなり自由なフックが必要そうですねえ〜

5:53 AM

AngularJS2がこのデコレータを活用してて初めて見た時ひっくりかえった。

と、書いてると、確かに仕組みが公開されたら野良アトリビュートが氾濫するというのは避けられないけど、本当に必要なケースはさっき書いたのとシリアライズくらいだから案外うまくいくかもしれない。

5:57 AM

静的にコード生成するしかなくて、そっちに比重がよりすぎるよりはいい気がします。

decorator に似た話だと、 https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md ってのも有りましたね。

https://kotlinlang.org/docs/reference/delegated-properties.html#lazy

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

！！！こんな提案あったのか

あ、Property Behavoour。ありましたね。

KotlinのDelegated Propertyに似てますね　これ欲しいんだよな・・・

Realmでもこれをうまく使えないか議論した記憶があります。

Python 知っている方は、 Python のディスクリプタみたいなものと思ってください＜ property behavior

↑の提案で Delayed Initialization も触れられてますね

6:03 AM

This can avoid the need for implicitly-unwrapped optionals in multi-phase initialization

6:03 AM

これあると IBOutlet の場合の IUO不要にできる

6:03 AM

Status: Deferred

6:03 AM

お

6:03 AM

先送り

IBOutletのIUO不要はアツい

tarunon自分で実現してなかったっけ、 lazy undefined みたいな技で (edited)

それはObjC互換がないのでIBOutletで使えない (edited)

あ、なるほど。

6:05 AM

Review入りしてDeferredになったくだりだけあとで読んでみよう。

func undefined<T>() -> T { fatalError() } class Foo { lazy var foo: Int = undefined() }

6:06 AM

これね

それほんとウケる

6:06 AM

天才

これ使うとIBOutlet以外のIUO全部消える

IUOは「nilを再代入できる」機能があるのでそれを使ってない、初期化遅れの場合の話しやね

nilを再代入出来るのがイヤイヤのイヤだったのでこれを作った

↑の undefined おもしろいですね。

巧妙ですよねｗ

Never が bottom になれば↓ができるのに。 func undefined() -> Never { fatalError() }

なるほど

なんなら return すらできる。

6:17 AM

func undefined() -> Never { return fatalError() }

6:18 AM

↑（ Never を return ）は今でもコンパイル通るけど、 Never が botton type じゃないから、任意の型に代入するとこができない。

return強制したほうがきれいな気もするな。

最後の式が return になる言語だとキレイなんだけどね。

6:19 AM

throw とかも考えると return 強制も変だし。

なるほど

Kotlin では throw 式が Nothing を返すはず。 (edited)

a ?: throw Exception とかできるんでそのはずですね

うん

perlの a or die を思い出す

そこで botton type が利いてるのおもしろい。

Scalaもまさにそんな感じですね

6:20 AM

https://github.com/scala/scala/blob/2.13.x/src/library/scala/Predef.scala#L284

scala/scala

scala - The Scala programming language

多分 Scala がそうで、 Kotlin がそれを採用した流れですよね。

??? can be used for marking methods that remain to be implemented.

メソッド名ｗ

あんま関係ないけど、 Kotlin が ?: 採用したのに三項演算子廃止したのよくわからない・・・。

?: は2項だからセーフ？

ところでいつになったら↓は Proposal が出されるんだろう？

Never as a universal "bottom" subtype An uninhabited type can be seen as a subtype of any other type--if evaluating an expression never produces a value, it doesn't matter what the type of that expression is. If this were supported by the compiler, it would enable some potentially useful things, for instance using a nonreturning function directly as a parameter to a higher-order function that expects a result (array.filter(fatalError)) or allowing a subclass to override a method and covariantly return Never. This can be considered as a separate proposal. Moving from @noreturn to -> Never is not a regression here, since the compiler does not allow an arbitrary conversion from @noreturn (T...) -> U to (T...) -> V today. The most important use case, a nonreturning function in void context, will still work by the existing (T...) -> U to (T...) -> Void subtyping rule.

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

%E3%82%A8%E3%83%AB%E3%83%93%E3%82%B9%E6%BC%94%E7%AE%97%E5%AD%90

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

6:25 AM

@omochimetaru ?: は x ? y : z の省略形で x ?: z == x ? x : z 的に考えたら自然な演算子だけど（ Nullable を Boolean のように使えればだけど）、 x ? y : z を廃止して ?: だけ採用したからよくわからない記法になってしまった感が。

6:25 AM

if (x) y else z でやれというのもわからんでもないけど。 (edited)

それは c ? t : f からの c ?: f を知ってる前提なのでは。ちなみにC言語にも ?: は実装されてますよ、標準だったか拡張だったかわすれたけど

ほんとだ。

#include <stdio.h> int main(int argc, char *argv[]) { int a = 1; int b = 0; printf("%d\n", a ?: 42); printf("%d\n", b ?: 42); return 0; }

1 42

6:33 AM

やっぱり ?: だけ残ったのは気持ち悪い感が。

6:34 AM

Swift も flatten が joined になったけど flatMap だけ残っちゃったけど。

そうですかねえ、僕はSwiftの ?? の方が、唐突な感じがします

6:34 AM

特に前例無いし。

いや、?: が悪いんじゃなくて、三項演算子なくなさなくても良かったんじゃないの？と。

ああ。

Swiftの??、ネストしたOptionalでやるとオエーってなりそう、やってないからわからんけど

6:35 AM

また壊せそうな気がしてきた

↓ @tarunon さんが怒り狂いそうなコード。 let a: Int? = nil let b: Int? = a ?? nil // nil

あーそれややこしいですよね・・・

6:38 AM

?? は必ずしも右側でOptional剥がさなくてもいいんですよね

6:38 AM

thenみを感じる

??は右側はOptional<T>/Tのオーバーロードなので

(thenみ　というのは mapとflatMapが同じシグネチャになる現象の事)

let a: Int?? = nil let b: Int? = nil let c = a ?? b とかやると脳みそがスタックオーバーフローです

6:39 AM

この場合は.some(.none)になりそうだな

https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%AB%E3%83%93%E3%82%B9%E6%BC%94%E7%AE%97%E5%AD%90

エルビス演算子をサポートした言語では以下のように記述すると、xにはf()結果がtrueと判定される場合にはその結果を、それ以外ではg()がセットされる。

println(false ?: true) // -> false (edited)

.none: Int? ではなく？

6:40 AM

お 1> let a: Int?? = nil a: Int?? = nil 2> let b: Int? = nil b: Int? = nil 3> let c = a ?? b c: Int? = nil

6:41 AM

よくこんな例ぱっと思いつきますね・・・

1

剥がすオーバーロードが優先なのね

なるほど

?? の右オペランドが Optional になるのは Haskell の <|> に相当しそう。 http://hackage.haskell.org/package/base-4.10.1.0/docs/Control-Applicative.html#v:-60--124--62-

let a: Int?? = nil let b: Int? = nil let c = a ?? b // Int?.none let d: Int?? = a ?? b // Int??.some(.none) (edited)

6:43 AM

まあ一応整合性は取れてはいるか

取れてるけど、やっぱ ?? のオーバーロードはダメな気がしてきました。

6:44 AM

??? にすればいいのに。

オーバーロードとサブタイプが絡まりあって人間にもコンパイラにも理解できなくなる例がありそうだ

↑まあそういう例において ??? と使い分けてたら読み解けるのかって疑問はあるけど

6:45 AM

マシではあるか・・・

読み解けなくても間違えて書いたときにコンパイルエラーにできる？

あー　シンプルな例でもクサビになるのがいいですね。

Never は、↓が盛り上がらなかったのが残念・・・ https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170508/036629.html

6:50 AM

何がうれしいって、 foo ?? fatalError("message") が書けるようになるのがうれしい。↓作ればいいという話もあるけど。 func fatalError<T>(_ message: String) -> T { fatalError(message) }

omochimetaru - Today at 3:34 PM そうですかねえ、僕はSwiftの ?? の方が、唐突な感じがします特に前例無いし。

C#にありますけどいつからあるんだろう？

@koher これ多分、Swift.fatalError(message)にしないとシャドーイングで優先されて無限ループになりますよ

fatalError よりも preconditionFailure や assertionFailure かな。 ?? と一緒に使いたいのは。

どっちにしても落ちますけどw

どっちにしても

ww

fatalErrorの実装としてスタックオーバーフローさせるのめちゃめちゃ行儀悪いなｗ

@koher precondition とか assert だと最適化オプションによってはノーチェックになるので ?? と併用するのそもそも無理そうな気がするんですがその辺ってクリアできるものなんですか

6:55 AM

Neverとして扱えなそう

assertionFailure は戻り値が Void ですが、 preconditionFailure は Never なのでできますね。

6:55 AM

型の上では。

お、 preconditionFailure はNeverなのか

preconditionFailureはコンパイラで無視されるとそこから先の動きが保証されない

@hiragram そこ面白くてpreconditionは消えないことになってて

implicitly unwrapで未定義に突入したのと同じになる

-Oundefinedで消える件については爆発する

6:56 AM

assertはOで消えるから消える事が考慮された型になってる。

6:56 AM

precondition: 建前上消えない assert: 建前上消える

あー、そこがassertとpreconditionの違いになるのか。

最近は fatalError の使い所って稀な気がしてて、↑のように assertionFailure 使いたいけど戻り値が Never じゃないから使えないケースで代わりに使うパターンが一番多い気がしてます。

-O までは建前上正しい型システムで、 -Oundefined になると適当になる

なんとなく「どの最適化レベルで消えるかが違う奴ら」というイメージしかしてなかった。

型システム上の扱いで分けて考えるとスッキリするよね。

お、そういえば precondition と assert についてはタイムリーなちょうどいい投稿がありますよｗ https://qiita.com/koher/items/ca7f388ab2a4e6747339

Swiftのpreconditionとassertの使い分け - Qiita

precondition と assert は似ているので、どういうケースでどちらを使うべきか意識してないと不適切な使い方をしてしまいます。本投稿では、 precondition と assert をどのように使い分け...

2

1

↑よみました。

@omochimetaru > -Oundefinedで消える件については爆発するこれはundefinedじゃなくてunchecked?

あ、uncheckedか。

ok

6:58 AM

@koher めちゃタイムリーでした。読みます。

てっきりそれ読んだ上で話題にしたのかと思った。

iOSDCで時間がなくて紹介できなかった宿題と (edited)

6:58 AM

Mobile Act OSAKA #2 と

fatalError よりも preconditionFailure や assertionFailure かな。 ?? と一緒に使いたいのは。

これしかみてなかった @omochimetaru

Qiita の Advent Calendar を

6:59 AM

全部一度に片付けましたｗ

効率だ・・・

assertとpreconditionの使い分け、自分はデバッグで落ちて欲しいけどリリースで落ちて欲しくない＆どうにかカバーできるときはassert使ってるかな、そうじゃないときはprecondition

そういうのは明示的に例外throw+catch+リカバリロジック+ログにしておくほうが良さそう

最適化で assert が消えて素通りして落ちないのは意図しない挙動を引き起こすのでよくないと思います。

privateメソッドの先頭で引数のバリデーションするのにassertつかってるくらいだなあ

「カバーできる」事が明示的にコードで示せないのが気になります。

throwはどっちかというとロジック的に問題ないけど予定外のことが起きたとき（JSONがデータが思ってたのと違う）とかに使ってるイメージ

-Ounchecked の precondition も同じですが、最適化でチェックが消えるのは、本来落としたいけど結果的に落ちなくなるだけなので、復活させたいなら Optional か Error で対処するのがいいと思います。

「カバーできる」事が明示的にコードで示せないのが気になります。

基本 guard との組み合わせで使ってるのでカバーは else 内で書いてますから一応ルート的に明示できてるはず

@lovee guardとassertを組み合わせると今度は return を書かないといけなくなってしまいません？

@omochimetaru だから「どうにかカバーできる」んですよ？

むむむ

7:31 AM

assertが書いてあるのはguardで分岐したelse節の中ってことですか？

例えば

let dictionary = [String: Int]() guard let value = dictionary["value"] as? Int else { assertFailure("needs value") return 0 } return value

的な

カバーという言葉が意味するものが二人の間で違う

いや、同じだね

あれ、そうなの

return dictionary["value"] ?? 0 ロジックとしてやりたいことは↑だけど右辺値の場合はデバッグモードでは死にたいのか。 (edited)

@omochimetaru です

デバッグで死にたくてリリースでは通したいシーンってぱっと思い浮かばないな

ロジック上では dictionary には "value" あるはずなので

とにかくクラッシュしてほしくない場合こうなっていきそうではある > @hiragram

7:35 AM

リカバーする動作、設計が先に想定されていて (edited)

7:36 AM

でもリカバーする場面は減らしたいから開発中は検知したい・・・

func assertDefault<T>(_ message: String, _ defaultValue: T) -> T これで良さそう

rx_fatalErrorみたいなのもこんな感じだったっけ

rxのfatalErrorはそのまんまfatalError軒がする

デバッグビルドだと落ちるよね確か

7:37 AM

リリースビルドだと警告出るだけじゃなかったっけ？

error bindingのところは違う関数だったかな

func bindingError(_ error: Swift.Error) { let error = "Binding error: \(error)" #if DEBUG rxFatalError(error) #else print(error) #endif }

呼び出し側か。チェックは

@tarunon まあそのケースはそういうのでもいいけど

7:38 AM

一般論としてありえる気がする

7:38 AM

ようするになんかフローがあるんだけどDebug時は通らない立て札を立てるようなイメージ

なるほど。確かにこれはあり得るかも？

assert自体はフロー制御には介入して無くて

7:40 AM

むしろReleaseで消えるからNeverで無い事が

7:40 AM

必要になってる

ふむ

なんか発想の根本が逆向きというかなんというか。

7:41 AM

例えば好ましい前提ではないけど、他人が作った不安定なモジュールがあるとして、ドキュメントとかもフワフワしているようなときに、

7:41 AM

ユーザサイドからみて仮定したい条件があるんだけど、もしかしたら成り立たないかもしれなくて、リカバリが可能な場合

7:41 AM

リカバー分岐ありで実装した上でassertionFailureを差し込んでおく

7:42 AM

というのはやりたいことがありそう。

RxSwiftのここ、いやアサートでいいやんけ、っていうのはしばしば思ってるんだけどなんでそうなってるのか聞いたこと無いなそういえば

うーん、でもよく考えたらリカバーコードが正しく動作することを検証できないから良くないような？

7:44 AM

リリースしたプロダクトに望む挙動は開発時にテストしたいのでは？

開発時でもReleaseビルドにはできますよ

まあそれはそうなんだけど。

というか、「Debugビルドしか動作テストはしない」って正しいんですかね・・・？

7:45 AM

別の次元の問題だけど、Releaseビルドのほうがフレームレートが上がるから、ReleaseビルドじゃないとUXのチェックができないとか

7:45 AM

そういうのはよく踏む。

正式リリース前のバージョンは一応リリースビルドで確認しますよね…？

それはそうなんですが、どのみちエラーフローは実装しているわけで、ログさえ吐いておけばあえて落とす必要もない気も？

7:56 AM

うーん、複雑なフローだと落ちた方がわかりやすいとかあるかもですが・・・。

プロダクトにもよりますが、ログだけしかないとログが長すぎて見逃しちゃった可能性も（）

わかる > ログ見逃し

ログを人間が見るのが悪いのでは

いくら派手にログメッセージ書いても気づいてくれないから殺したれってよく判断する

ログを人間が見るのが悪いのでは

確かにこれはあるかもしれない

確かにエラーメッセージを表示するとかではなく、正常フローと似た挙動をするときは気づかないかも？ (edited)

ややあって「ほら！そこにログが出てるでしょ！」って至るよりは、「なんか落ちたんだけど」って持ってきてもらったほうが話が早いのよな。

確かにテストしてる人が実装した人とは限らないのでそっちの方が早いか。

ここまで書いてログ発行のタイミングで自分のマシンに通知パケットが飛んでくれば最強な気がしてきた

FabricにNon-fatal issueのシグナル投げておくみたいなことは結構やる

7:59 AM

クラッシュレポートと同じ情報としていろいろ通知来るし

なるほど

あとゲームに限った話かもしれないが、例えば画面エフェクトを実装してそれをスクリプト側で呼び出す、んでスクリプトが間違った時に落ちて欲しい、でも何かの間違いでプレイヤー側では思った通りのものにならなかった時にせめてゲームエンジン自体は動いて欲しい、画面エフェクトだけなくてもアプリとして一応動くから、と言ったものもassertの方が向いてる気がする（何かの間違いは一体なんなのかはさておき

ちょっと話変わるけど↓変じゃないですか？ Never じゃないからフロー殺せないし。

Use this function to stop the program, without impacting the performance of shipping code, when control flow is not expected to reach the call—for example, in the default case of a switch where you have knowledge that one of the other cases must be satisfied.

https://developer.apple.com/documentation/swift/1539616-assertionfailure

@lovee そういうのはスクリプトの実行をする関数がthrowsになってれば良いと思います

8:04 AM

てか最近のゲームよく落ちますよね

@koher どのへんがおかしいですか？(ざっとよんだけどわからなかった)

そんな低リスクの想定外の動作のために throws ばっかり使って do catch があっちこちに散らかってるのあまり好きじゃないかな

@hiragram switch で return してる場合とか、戻り値 Void だから default で assertionFailure できなくないですか？

ゲームエンジンとして絶対壊れちゃいけないBehavior Loopの根っことかで do - catch するイメージでした。

8:07 AM

んで、catchしたときは Behaviorのくっついてるオブジェクトの型情報とか読み込んでたスクリプトのログが出るような感じ。

それはそれであらゆるメソッドが throws になってあらゆる呼び出しが try になって逆に try #とはって気持ちに

なので、そういうケースでは本当は Logic failure からの復帰がほしくて

それより上のレイヤーだともう多分どうしようもリカバリできないし、下のレイヤーだといろいろ呼び出しが相互に合わさるしスクリプトも差し込まれるからうまく切れなそう

Java で言えば RuntimeException を catch して処理したいんだけど

あらゆるメソッドが throws になってあらゆる呼び出しが try になって

そこはそうですねえ・・・

Swift ではそれが欠けてるんですよねぇ。

8:09 AM

actor の Proposal まだ読んでないけど、 actor が導入されたらその単位で殺したりできるようになるのかな？

@koher それはそうですね。でもその英文はassertFailureをフローコントロールに用いるような感じの話じゃないんじゃないかと。「絶対そのcaseやdefaultに落ちないはず、みたいなコードパスに置いてね」くらいの意味と受け取りました (edited)

「switch文のdefaultとかに使ってね」って読んだけど誤読なのか。

直訳するとdefaultか

for example, in the default case of a switch where you have knowledge that one of the other cases must be satisfied.

「たとえば、その他の case の一つが必ず満たされると知っているような場合の default case で」じゃないですか？ (edited)

「switch文のdefaultとかに使ってね」には preconditionFailure じゃないとリカバリコード書かないと通らないからどうなのよって話ですよね？

です。

はい。

単にその英文がswitch以降も処理がいろいろある(=case句の中でreturnしない)ケースしか想定されずに書かれただけだと思うけどなあ

あ、たしかに

8:14 AM

switch x { default: assertionFailure("bug") } hoge() fuga()

8:14 AM

これなら問題ないか。

そうそう

8:14 AM

それを説明したかった英文なんだとおもっていたけど

8:14 AM

。

1

なるほど。副作用のある処理とかならありえますね。

ですね、これで何か予想外だけど致命的ではない問題が発生しても少なくともリリースビルドにはなんとかクラッシュせずに生き残れます、でもデバッグビルドではそれは検出できます

8:19 AM

致命的なものならpreconditionですが

https://github.com/apple/swift/pull/13361

Implement the DynamicMemberLookupProtocol proposal. by lattner · Pull Request #13361 · apple/swift

This is the second cut at implementing the DynamicMemberLookupProtocol proposal. Changes from PR13076 include: Incorporating @slavapestov's awesome code review feedback. Retroactive conformance t...

9:40 AM

もうPRきてた

9:40 AM

Pythonブリッジとかの下地のやつ。

↑これめっちゃやる気満々だな。

ですね

これ通ったら、 Python で書いてる機械学習系のコード全部 Swift で書けるようになるのでは？ (edited)

構文がSwiftなだけのPythonになって型もないし別に嬉しく無さそうなのが・・・

いや、データの前処理とか全部 Swift に持ってきて、そのまま TensorFlow とか scikit-learn とかにつっこめないかな？

あっ、でもリスト内包表記とかラムダとかpythonの不満点は全部解消するか

9:57 AM

そういうのはできそうですね。

Chris Lattner が今の部署にいる限り、 TensorFlow が動くのは第一目標だろうから、少なくともそこは使えるようになりそう。

9:59 AM

機械学習自体のコードよりも、付随コードが多くて辛いから、それが全部 Swift で書けるようになったらとてもうれしい。

なるほど・・・

Python 以外にも、↓の JSON の例おもしろいよね。 SwiftyJSON を単純化したようなのが（ ["foo"] じゃなくて .foo で）書けるようになる。 https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#example-usage

DynamicMemberLookup.md

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171211/006158.html やっときたー

1

we propose starting the transition on the afternoon (US Pacific time) of Thursday, Dec. 14, and completing the transition by Dec 18 (Monday).

おおおお

1:57 AM

↓こんな感じになるのか（リンク先はプロトタイプ）。 http://swift.trydiscourse.com/

Swift Forums

1:59 AM

↓たまたまプロトタイプの Evolution の上の方に。 Markdown で書いてたからシンタックスハイライトされてる。 http://swift.trydiscourse.com/t/question-why-does-beginasync-rethrow-errors/6986

[Question] Why does beginAsync rethrow errors?

Although I posted about this topic before, let me post this again because I think it is important and I have received just few replies. Sorry if I missed some discussion about it. In the proposal ( https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 ), beginAsync has the following signature. func beginAsync(_ body: () async throws -> Void) rethrows -> Void However, I think it is better to forbid body to throw errors, that is to say, to change its signature to the followi...

おーいいっすね

2:37 AM

githubでログインしようとしたら404だったwまだなのかな

まだですね。

テストのやつはログインできないってかいてあった

Also note, we’re currently not supporting logins on the prototype site as we’re in the process of changing configurations.

enum JSONNullable<T> : Codable { case value(T) case null func encode(to encoder: Encoder) throws { var sc = encoder.singleValueContainer() switch self { case .value(let anyValue): if let encodableValue = anyValue as? Encodable { // sc.encode(encodableValue) // だめ } else { // throw error } case .null: try sc.encodeNil() } } }

6:12 AM

JSONに noneのときにキーが無くなるのではなくて null を吐く Optionalを作ろうとしてるんですが

6:13 AM

↑ // だめのところってどうやって書いたらいいんでしょう？

6:13 AM

https://stackoverflow.com/questions/47266862/encode-nil-value-as-null-with-jsonencoder/47268112

Encode nil value as null with JSONEncoder

I'm using Swift 4's JSONEncoder. I have a Codable struct with an optional property, and I'd like this property to show up as null value in the produced JSON data when the value is nil. However,

6:13 AM

case .some(let wrapped): try (wrapped as! Encodable).__encode(to: &container) SOでヤバそうなコードは見つけたんですけど。

6:14 AM

enum JSONNullable<T> : Codable { case value(T) case null func encode(to encoder: Encoder) throws { switch self { case .value(let anyValue): if let encodableValue = anyValue as? Encodable { // sc.encode(encodableValue) // だめ try encodableValue.encode(to: encoder) // } else { // throw error } case .null: var sc = encoder.singleValueContainer() try sc.encodeNil() } } }

6:14 AM

↑これで良いのか・・？

↓はダメ？ enum JSONNullable<T : Codable> : Codable { case value(T) case null ... }

あ〜　まあ今はそれでもいいか・・・

6:19 AM

できれば、 T : Encodable なら : Encodable、 T: Decodable なら :Decodable が、うれしいですけど。

CondConfが無いときのStdlibのOptionalの実装を真似したらできそう

6:24 AM

バグがあったりして @norio_nomura が治してたりしてたからここのログにあるんじゃないかな

AnyEncodable だったりして

stdlib内部だと内部だけの裏技とかもあったから・・・

@norio_nomura さんがやってたのは YAML のサードパーティライブラリだったような？ < 内部だけの裏技

6:26 AM

本体も直してたか

いえ、stdlibも直してましたｗ

本体にパッチ送ってましたね

あ、あと、stdlibの場合は

6:28 AM

キーが無くなるんですよ

6:29 AM

JSONの。今やりたいのはキーはなくさずに、 null を書きたいから

6:29 AM

まあでも他にヒント無いし見てきます

今見た感じおもちのやりたいことで引っかかってるのはValueある方で引っかかってるように見えたから

6:29 AM

Optional見たら解けるでしょって思った

6:31 AM

@omochimetaru https://bugs.swift.org/browse/SR-5206

https://github.com/apple/swift/blob/33de34bc383c3e1532b9c6d89b27993ea7b4915f/lib/Sema/DerivedConformanceCodable.cpp#L636

swift - The Swift Programming Language

6:37 AM

Optionalの場合は、自動生成だと、

6:37 AM

encodeIfPresentを呼び出しているようだった。

6:39 AM

OptionalもArrayも直接Decode/Encodeするわけじゃないから

6:39 AM

ギリギリ問題にならないのか

6:40 AM

もうちょっとでConditional Conformanceが来るのに・・・

struct E : Error {} enum JSONNullable<T> : Codable { case value(T) case null init(from decoder: Decoder) throws { var sc = try decoder.singleValueContainer() print(71) if sc.decodeNil() { self = .null return } print(72) if let decodableType: Decodable.Type = T.self as? Decodable.Type { print(73) self = .value(try decodableType.init(from: decoder) as! T) } else { print(74) throw E() } } func encode(to encoder: Encoder) throws { switch self { case .value(let anyValue): if let encodableValue = anyValue as? Encodable { try encodableValue.encode(to: encoder) } else { throw E() } case .null: var sc = encoder.singleValueContainer() try sc.encodeNil() } } }

6:49 AM

@tarunon T = String でも print 74 にいっちゃうんだけどなんか前こんな分岐やってたよね

あーこれは

6:49 AM

これはこれは。。。。

6:49 AM

ダメですね

はい

Swift4以降ダメになった気がする

そんな話だった

6:50 AM

その時なんか知見あった？回避の。 (edited)

回避は出来なかった気がする

ふむ

これ諦めてEncodable, Decodable, Codableで3種類型作ったほうがいいんじゃない?CondConfが来るまでのつなぎでしょ

encodeは期待した挙動になったけど init (From decoder) がダメそうだな

6:52 AM

うんまあつなぎっちゃつなぎなんだけど

6:52 AM

動的にやる場合はどうなるのか/できないのか

6:52 AM

がよくわかってないのは気持ち悪くて。

Encodableもうまく動いているように見えて、JSONのエンコードルールに従わないみたいな残念なバグが発生しそう?

目前の課題としては T : Codable で一応大丈夫

6:53 AM

Encodableのほうはとりあえずはうごいたよ

URLいれてJSONでやっても動くのかな

URLは入れない方針で・・・

それは動いてるとは言わない

1

6:55 AM

これ近いことやったのいつだったかな

6:55 AM

DelegateProxyあたりかな?

6:57 AM

あ

6:57 AM

これあれだ

6:57 AM

ウソのisの結果が帰ってくるから回避不能回避不能回避不能!!ってなったやつ

6:57 AM

諦めましょう

6:57 AM

今は無理です

草

DelegateProxyにあったウソのコードも消しました

だめそうかあ。<T: Codable> にします、ありがとう。

Playgroundで <# aaa #> って入力すると半クラッシュする (edited)

半クラッシュ #とは

上手く言えないのでやってみて

半チャーハンみたいな?

なんか明らかに処理系がクラッシュしてるんだけどXcodeレイヤーはセーフ

ピンピンしてる

7:15 AM

Toolchainかな?

Xcode9.2

7:15 AM

純正

error: Execution was interrupted, reason: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0). The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.

7:15 AM

ちゃんとこれが出る

ああ、それそれ。

てっきりSourceKit瀕死の方かと思った

もはやこの程度は何も問題ないみたいな

ちゃんとメッセージ出てるからセーフ

Playground execution aborted Group file:///Users/omochi/work/playground/iOSGround.playground: error: Playground execution aborted: error: Execution was interrupted, reason: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0). The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.

7:17 AM

うん・・・　でも何も悪い事してなくない？

7:17 AM

正常な異常動作とでも言えばいいのか

7:17 AM

レポートしなくてもまあいっか、みたいな・・・

thread return -x 見すぎて脳みそが勝手によしなに解釈するようになってしまった

Fatal error: attempt to evaluate editor placeholder: file MyPlayground.playground, line 2 出てますよね？

ss

Int("")! とかもそうですけど、コンソールに加えて余計なエラー出ますね。

そっちはまあ、プログラム実行時点でクラッシュするからわかるんですけど

7:37 AM

<# aaa #> の入力だけだったら、普通にコンパイラで型エラーが見つかった時と同じような程度なのが正しい気がしてて

7:37 AM

（実際コマンドラインからやるときはそうなる）

7:38 AM

EXC_BAD_INSTRUCTIONが飛び出したメッセージが出てるのはApple的に期待されてない挙動なようなきもするし

7:38 AM

Xcode側は無事だから期待通り何かがハンドリングされた挙動なようなきもするし

7:38 AM

なんともいえない・・・

https://github.com/apple/swift/blob/4c2d55d0134bd4fdb4e68eaf59bc9db0ceb1e220/lib/Parse/Lexer.cpp#L1882-L1888 意図的にエラーにしていないのは確かなんですが、その理由は僕は知らないのです。

swift - The Swift Programming Language

お、Lexer.cppだ。

7:41 AM

これ昨日読んでいてこのいたずらを思いついた。

7:42 AM

ここだけ見る限り普通にDiagnoticsが流れるだけになりそうですよねえ。

7:42 AM

実際CUIならそうなるし、なんかXcodePlayground固有の何かが生じてそう

diag::lex_editor_placeholder が ERROR として定義されていて、 diag::lex_editor_placeholder_in_playground は WARNING なので、

7:44 AM

Playgroundの場合 Warning 出して identifier としてトークン化されて素通りっていう流れですね。

Fatal error: attempt to evaluate editor placeholder: file iOSGround.playground, line 1 WARNING(lex_editor_placeholder_in_playground,none, "editor placeholder in source file", ()) https://github.com/apple/swift/blob/12e7caf5d71d441b95faeeae649d5afbbd57ab60/lib/Sema/CSApply.cpp#L3744

swift - The Swift Programming Language

7:49 AM

diag::lex_editor_placeholderが出そうとするメッセージは editor placeholder in source file"だけど

7:49 AM

今でてくるのは↑のCSApplyの中に書かれた

7:50 AM

な、なんだこれ、// Synthesize a call to _undefined() of appropriate type.

7:50 AM

クラッシュするコードにコンパイルされているのか

7:50 AM

あっ、そういうこと？

7:50 AM

ERRORが出ればそこで止まるけど

7:50 AM

WARNINGの場合はコンパイルまで進むようになっていて

7:50 AM

この部分がコンパイルされると死ぬコードになって

7:50 AM

Playground上で実行されて死ぬ

1

7:51 AM

だから Int("")! と同じような見た目になるのか。

https://github.com/apple/swift/blob/4c2d55d0134bd4fdb4e68eaf59bc9db0ceb1e220/stdlib/public/core/AssertCommon.swift#L234 assertionFailure() 扱い。

Swiftのpreconditionとassertの使い分け - Qiita

swift - The Swift Programming Language

おお、Fatal error: って見出しはここで書き足されてますね。

enum Animal : Int { case cat = 2 case dog = 3 } func f(_ animal: Animal) {} // ok f(Animal.init(rawValue: 3)!) // error: iOSGround.playground:7:21: error: type of expression is ambiguous without more context f(.init(rawValue: 3)!)

8:22 AM

これ最近困ってるんですよね。そういうもんだっけ。

この .init 可読性悪くない？ｗ

まあそれはおいといて・・・

AppCode人間いるかな

8:25 AM

わかりにくい.initの左側に型が補完されて見えるかな?と思ってるけど

enum Material { case fire case water init(_ x: Int) { self = .fire } } func g(_ material: Material) {} g(.init(3))

8:25 AM

↑こっちは、いけるから

8:25 AM

やっぱり rawValue enum 特有のバグではなかろうか？？

いや

8:26 AM

Optional initから推論出来てない気がする

あ〜

8:26 AM

enum Material { case fire case water init?(_ x: Int) { self = .fire } } func g(_ material: Material) {} // error: iOSGround.playground:19:11: error: type of expression is ambiguous without more context g(.init(3)!)

8:26 AM

ほんとだ。

あー、なるほど

じゃあいいのか。

たまたま Optional のケースを raw value で踏んだだけなのか〜

enum Material { case fire case water init?(_ x: Int) { self = .fire } init(_ y: String) throws { self = .water } } func g(_ material: Material) {} try g(.init(""))

8:30 AM

throwsのほうが推論通しやすいわけか

JSONNullableは解決したのかな？

enum JSONNullable<T: Codable> : Codable { case value(T) case null 諦めてこれで対処しました

1

@koher https://qiita.com/koher/items/ca7f388ab2a4e6747339 <= この使い分けについて、preconditionの失敗はメソッドやAPIの使用者側の問題（責任）で、assertは提供者（作る側）の問題（責任）という理解で合ってますか？

precondition と assert は似ているので、どういうケースでどちらを使うべきか意識してないと不適切な使い方をしてしまいます。本投稿では、 precondition と assert をどのように使い分け...

はい、そうです

ありがとうございます。とても腑に落ちました。例などがとてもわかりやすかったです。

1

お役に立ててよかったです

preconditionの失敗はメソッドやAPIの使用者側の問題（責任）で、assertは提供者（作る側）の問題（責任）

なるほどこの切り分け方いいですね

メタタイプの配列って[Any]としかできないのかな？

let dateTypes = [Date.self, NSDate.self] // Heterogeneous collection literal could only be inferred to '[Any]'; add explicit type annotation if this is intentional

↓こうなりました。

 1> class Animal {} 2. class Cat : Animal {} 3. class Dog : Animal {} 4. 5. let a = [Cat.self, Dog.self] a: [Animal.Type] = 2 values { [0] = Cat [1] = Dog }

(edited)

共通するのはCodableである、だけなのですよね。 import Foundation let dateTypes = [Date.self, NSDate.self] as? [Codable.Type] dateTypes?.count // nil

protocol はダメみたいですね。

 1> protocol Animal {} 2. class Cat : Animal {} 3. class Dog : Animal {} 4. 5. let a = [Cat.self, Dog.self] error: repl.swift:5:9: error: heterogeneous collection literal could only be inferred to '[Any]'; add explicit type annotation if this is intentional let a = [Cat.self, Dog.self] ^~~~~~~~~~~~~~~~~~~~ as [Any]

12:27 AM

existential だから、普通のサブタイピングとはちょっと違うとは思うんですよね。

メタタイプを表す型が欲しかったのだけど、無さげ。

なるほど、そういう意味ですか。

12:29 AM

お、↓はできました。

 1> protocol Animal {} 2. class Cat : Animal {} 3. class Dog : Animal {} 4. 5. let a: [Any.Type] = [Cat.self, Dog.self] a: [Any.Type] = 2 values { [0] = Cat [1] = Dog }

お、

Foo.Type.Type is Any.Type.Type はもちろん、 is Any.Type も成り立つみたいなので、メタタイプ一般を Any.Type で表せそうです。

 1> protocol Animal {} 2. class Cat : Animal {} 3. class Dog : Animal {} 4. 5. let a: [Any.Type.Type] = [Cat.Type.self, Dog.Type.self] 6. let b: [Any.Type] = [Cat.Type.self, Dog.Type.self] a: [Any.Type.Type] = 2 values { [0] = Cat.Type [1] = Dog.Type } b: [Any.Type] = 2 values { [0] = Cat.Type [1] = Dog.Type }

12:32 AM

ってか、もはや Animal いらないですね。

12:32 AM

 1> let a: [Any.Type.Type] = [Int.Type.self, String.Type.self] 2. let b: [Any.Type] = [Int.Type.self, String.Type.self] a: [Any.Type.Type] = 2 values { [0] = Int.Type [1] = String.Type } b: [Any.Type] = 2 values { [0] = Int.Type [1] = String.Type

ありがとうございます！

1

Any は型じゃないみたいなのあった気がするんですが、 Any.Type があるということは型になったんでしたっけ？

12:36 AM

↓もできるし別にいいのかな？？実行できてるけど謎のエラーが出てるけど。

 1> let a: (Int, String).Type = (Int, String).self a: (Int, String).Type = (Int, String) error: could not fetch result -- error: Couldn't apply expression side effects : Couldn't dematerialize a: corresponding symbol wasn't found

12:36 AM

nominal type じゃないってだけだったかな？？

ノミナルじゃないだけで型ではあると思う

: Any って書けるからそりゃそうか。 nominal かどうかという話と混同してたみたい。

メタクラスの根っことしてのAny.Typeは結構使います

https://github.com/apple/swift/pull/11869

Diagnose Infinite Recursion by CodaFi · Pull Request #11869 · apple/swift

Extend the mandatory unreachable diagnostic pass to cover naive infinite recursion. The algorithm used is roughly the one from Clang with Swift-specific modifications and some minor simplification...

2:22 AM

時々話題に出てくる循環呼び出しによるスタックオーバーフローをコンパイラで検出する機能のプルリクが立ったよ

2:23 AM

+func a() { // expected-warning {{all paths through this function will call itself}} + a() +} + +func b(_ x : Int) { // expected-warning {{all paths through this function will call itself}} + if x != 0 { + b(x) + } else { + b(x+1) + } +}

2:24 AM

+// Doesn't warn on mutually recursive functions + +func e() { f() } +func f() { e() } とりあえず相互再帰はだめみたい

相互再起はできないだろうなぁw

これ系は一般系が無理なだけで

2:24 AM

特定のパターンの検出器を作る事はできるから

2:25 AM

２つまでとか限定してならできるんじゃないか

2:26 AM

eを検査するときに出てくる呼び出しがなんだったか1つまで覚えておいて（この場合fを記憶するそのfの中で必ずeに突入するか検査するってかんじで。

これがあると、同名の関数をオーバーロードしてエイリアスを作ったと思っていたら優先順位が自身の方が高くて死亡、というケースが稀にあってそれが助かる (edited)

どうだろうオーバーロードがあっても動くかはまだわからんｗ

2:26 AM

シンプルなケースだけという実装の可能性も

2:26 AM

(コミットされてるテストケースではオーバーロードされてるパターンは無い）

function見てるだけだからオーバーロードはあんまり関係ないと思った

2:28 AM

オーバーロードは人間が認知するときだけの問題でコンピューターから見たら他の関数の差と大して違わないと思う

オーバーロードの呼び出しとかが解決した後の後段での検査なら関係ないか。

2:29 AM

Resolves SR-626, SR-677, SR-2559, and SR-4406 Has implications for SR-3016, SR-5224.

2:29 AM

この記事について

この記事は Swift Tweets 2017 Fall での発表内容を記事の形で再編したものです。 [togetterまとめはこちら](h...

1:23 AM

この swapAt 的なものが型（もしくはプロトコル、 swapAt は Collection に実装されている）ごとに個別に必要なのかぁ。うーん。

そうですね　subscriptアクセスはindexを引数に取るcomputed propertyのようなものなので、内部ではメモリ干渉が起きてないんだけど外側からはわからないから保守的に配列全体を保護しようとして衝突する

inout / mutating つながりで↓おもしろい。 https://github.com/chriseidhof/swift-evolution/blob/287dde8bb8c1a3432014c9bd45663ece8f113589/proposals/nnnn-bool-toggle.md

chriseidhof/swift-evolution

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

これ欲しいですね、昔から欲しくて自作ライブラリーに negate() 実装したことある

5:27 AM

https://github.com/el-hoshino/Eltaso/blob/feature/Swift_3.0/Eltaso/Eltaso/Bool.swift

el-hoshino/Eltaso

Eltaso - This is a framework that contains some convenient methods and extensions for myself

値型である Bool でこれができるのが Swift っぽいですよねぇ。

5:28 AM

↓これやりたい。 myVar.prop1.prop2.enabled.toggle()

:sorena:

5:30 AM

Discordにカスタム絵文字欲しいｗ

60個まで追加できるんでしたっけ

サーバ管理者がサーバにカスタム絵文字追加して、 Nitroユーザがそれを使える感じなのかな。 (edited)

:discordlove:

5:41 AM

ナンダッテー

サーバー内のカスタム絵文字ならNitroユーザじゃなくても使えますよ別サーバーのカスタム絵文字を使う時はNitroユーザーじゃないといけませんが

1

rintaro先生はNitroユーザーですか

お世話になってるので、何がメリットなのかよく知らないけど課金してみました。

1

サーバー絵文字は画像ファイル置いてくれれば設定しますよ。

6:21 AM

#zatsu に移動してた

1

2

Swift で↓をやりたいときどうしますか？

struct Foo { let a: Int var b: Int } var foos = [Foo(a: 2, b: 3)] foos[0].a = 99 // NG foos[0].b = 99 // OK foos[0] = Foo(a: 99, b: foos[0].b) // OK → これを NG にしたい

Fooをクラスにしてfoosをletにする

7:43 AM

(not swiftyの絵文字がほしいと思った)

Foo をクラスにするのは共有オブジェクトの問題がややこしいので避けたい、という前提だとどうですか？

その前提だとそもそもできるんですかね (edited)

単純にはできないので、ワークアラウンドとして何かいい方法はないのかなと。 (edited)

7:44 AM

let foos: [var Foo] みたいなのほしい・・・

Arrayをラップしたのを作ってsetB(value: index:)を生やす……

@t.ae プロパティが N 個だと死にませんか？

subscript setつかってfoos.bs[i] = 99みたいな形にもかけそう

7:45 AM

死にますね

内部状態としてはArray asと Array bsの2つがあって、アクセス時にFooとしてreadonlyにすればなんとかなるかな?

7:48 AM

ただしfoos[0].b = 99みたいなのはできなくなる

foos[0].b = 99 はやりたいとして、ですね。

foos.bs[0] = 99 こっちで妥協できませんか?w

それはトリッキーすぎて辛いですし、プロパティの数だけ生やさないといけないので・・・。

まあそっすね

7:50 AM

classだな

7:51 AM

ArrayはletでFooはclass、aとbをそれぞれlet/varにすればいける

↓みたいな構文があればいいのかな・・・。 : の右の let や var を省略時は let ならすべて let 、 var ならすべて var 。 var foos: let [var Foo] = ... (edited)

7:52 AM

@tarunon

Foo をクラスにするのは共有オブジェクトの問題がややこしいので避けたい、という前提だとどうですか？

使いまわす時にstructに変換噛ませば良いのでは (edited)

7:53 AM

Classだと共有オブジェクトの問題が発生するのはそのとおりですが、それに対しては共有しない、が正解だと思う

var foos1 = ... var foos2 = foos1 foos1[0].b = 99 // foos2[0].b も変更される ← これを避けたい

Arrayのコピー時にstructに変換してclassに再変換すれば良いので

7:54 AM

まあ一番外側の構造はオレオレで作らなきゃいけないですが

~~foosに追加するインターフェースをstructにすればいいのでは？~~ (edited)

7:56 AM

あ、違うこと考えてました。

[swift-evolution] Reminder: Discourse transition starts tomorrow https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180115/042917.html (edited)

アプリあるやん、と思ったけど

4:54 AM

https://itunes.apple.com/jp/app/discourse-app/id1173672076?mt=8 未読管理だけで中身はWebAppだった

Discourse Appを App Store で

「Discourse App」のレビューをチェック、カスタマー評価を比較、スクリーンショットを確認、詳細情報を入手。Discourse Appをダウンロードして iPhone、iPad、iPod touch で利用。

http://twitter.com/inamiy/status/952020019252158464

Yasuhiro Inami (@inamiy)

My "Algebraic Data Type in Swift" slide @TokyoiOSMeetup is now up! https://t.co/E2hwsx8zLz

Likes

146

2:35 AM

おもしろかった

わかりやすい

https://swift.org/blog/forums/

Swift Forums Now Open!

We are delighted to announce that the Swift project has completed the process of migrating to the Swift Forums as the primary method for discussion and communication! The former mailing lists have been shut down and archived, and all mailing list content has been imported into the new forum system.

4

http://forums.swift.org/t/proposal-introducing-nonconformingtype-strategies-with-encoder-decoder/8066 任意の型に対するencoding/decoding strategyを入れられるようにしたいとProposal上げたけど、「考慮の上外してるよ、カプセル化を壊してしまうからね」とのこと

[Proposal] introducing NonConformingType strategies with Encoder/Decoder

Current Encoder/Decoder has a problem that most types (except for Date, Data and Float) have no way to modify encoding/decoding strategies. I want to give them the way. Proposed solution for example of Decoder, struct NonConformingTypeDecodingStrategies { subscript(type: T.Type) -> NonConformingTypeDecodingStrategy? } public enum NonConformingTypeDecodingStrategy { /// Throw upon encountering non-conforming values. This is the default strategy. case throw /// Assume ...

1:40 AM

なるほどと思いつつ、それならinit(from:)の決め打ち実装が現状ちょっと多すぎるんじゃないかなと思った例に挙げたCGPointとか、デフォではCodableに適合させず、extensionでユーザーにinit(from:)を書かせるほうがよいのでは、という気がします

自分でPointとか型を作った方が結局楽な気がする

うーん、カプセル化に違反するってのが本当なのか？という気がします。

1:51 AM

デコードについては、イニシャライザがあってそのパラメータがあるんだったら、そのパラメータ相当のデータから生成できて良いのでは？

オレオレ型のほうが楽なのは間違いないけど、それは現状追認であって理想じゃないなと

で、そのパラメータを取り出せるんだったらエンコードもできそう。

例えば座標をFloat配列で出してくるようなAPIがあったとして

というか、そもそも単純なデータ構造以外のものを Codable にするのが微妙そう。

それはそういう型を作ってCGPointに変換した方が安全だし、元々の型も保存できる

仮にある型の実装者が内部構造を考慮した上でエンコード／デコードメソッドを実装できるとして、それが内部構造を知らないと実装不能なデータ構造にエンコード／デコードするなら、それはカプセル化されて隠蔽されたものを外部に露出してるような気が。

@tarunon 具体的なデメリットがピンとこないけど何かあります？

バイト列にシリアライズ／デシリアライズは OK なら同じかなぁ・・・。

@koher プロパティに直接入れるとカプセル化壊れるけど、それは https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md で直るから気にしなくていいはず、ってことですかね

あと、今日DiscordのSwiftチャンネルでの本題「URL?型に空文字を与えるとdecodeでエラーになるのどうするか」、色々方法出たけど、俺的にはここが結論。 #CodePiece

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

ちょっと議論がずれますが、この手のクソAPIはエンドポイント毎に振る舞いが変わってたりして、Codableでは吸収しきれないというのがあります

1:57 AM

そもそもデバッグ時に生の値が欲しい、というケースは往々にしてあって、Pointは単純なのでいらないかな？と思うかもしれませんが

1:58 AM

例えばURLでURL/Path/空文字列/nullなんてこともあり

その現実は確かにある

そんなものを素直にCodableに詰めて隠蔽すると明晩にはデバッグはできなくなる

2:00 AM

URLは本当にひどい、クエリ部がデコード済みとか、punycodeがデコード済みとか、その組み合わせも

2:01 AM

なんでAPIがクソならちゃんと型作って対処するのが、後々安全だと思います

@takasek

プロパティに直接入れるとカプセル化壊れるけど

イニシャライザでってことですか？ SE-0189 で禁止されるようなものは元々アンチパターンだと思います。

クソAPIは専用の型でも作ってinit(from:)を頑張って書く必要あるのはわかるんですが、ああそうだ、URL?で空文字が入ってきたときerrorでなくnilにするくらいはstrategyくらいのレベル感で対処できたほうが嬉しいよなと思ったんだった (edited)

2:13 AM

@koher はい、それが今まで出来てしまってたけど、できないようになるので、という文脈での「デコードについては、イニシャライザがあってそのパラメータがあるんだったら、そのパラメータ相当のデータから生成できて良いのでは？」ですよね、という確認です

そこまで考えてませんでしたが、そもそもアンチパターンなのでできたとしても気にしなくて良いのでは？ということでした。オリジナルで提供されてるイニシャライザを使う限り問題にならないはずですし。

そうですね、納得ですー

APIレスポンスによって構造が違う場合、Codableでは吸収しきれないのでオレオレ型を仲介しなきゃいけない ←わかるすべてのAPIレスポンスで構造は揃ってるけど、Swift Standard LibraryのCodableの想定の構造とは違うので、オレオレ型を仲介しなきゃいけない ←なんで？こっちで構造決めさせてほしいというのが自分のモチベーションの根っこだと考えてたらわかりました

CGPoint を { "x": 2.0, "y": 3.0 } としたいか [2.0, 3.0] としたいかだけでもブレますしねぇ。

2:35 AM

まあ、 CGPonit に限って言えば僕は CoreGraphics や CGFloat に依存するのが気持ち悪いんでオレオレ Point を作りますが・・・。

話のポイントは、 koherさんの仰る「最終的に提供されてるinitを使うのならカプセル化に違反はしないのでは」はあって、そこを良しとしても、ぼくの

の話があって、あとはtarunonさんの「rawValueを残したい」って話は現状のワークアラウンドでできること（そういえば前に https://gist.github.com/takasek/36af17cca297ef73f8bcc1463f9e50c1 でまとめたの思い出した）って感じですね

2:42 AM

CoreGraphic

そこは…そのとおりですねー

あ、いや、今日tarunonさんが言ってるのはRawRepresentableに限った話ではないのか元の構造がstructのパターンもある

koherさんの仰る「最終的に提供されてるinitを使うのならカプセル化に違反はしないのでは」はあって、そこを良しとしても、ぼくの

の話があって、

はい、なのでイマイチ forum の返信がピンと来ないです。

2:55 AM

まあ結局 API を写し取った層を作ってそこからさらに変換とかになることも多いですが（そして、その方が柔軟性は高いですが）、ボイラープレート的でイマイチ感はありますね・・・。

どういった形にエンコードされるか、というのを外側から観測してその振る舞いを外側から変えられるようにする、という行為がカプセル化を壊しているという話なんじゃないですかね。

3:01 AM

観測できてしまうのは仕方ないとして（これは @koher さんも書いてるけど）

カプセル化されて隠蔽されたものを外部に露出してる

そこが疑わしいと思ってて、僕らはイニシャライザを通してインスタンスを組み立てるわけですが、 JSON をデコードしてイニシャライザを通してインスタンスを組み立てるのと、プログラム中の値からイニシャライザを通してインスタンスを組み立てるのは同じなんじゃないかという気がしてます。 (edited)

3:04 AM

これって、型自身を拡張して Codable にするから違和感があるだけで、 Factory 的なものを介して生成するんだったら違和感がないと思うんですよね。

3:05 AM

あと、そもそも構造が外部に見えるようなシンプルな型（ Kotlin で言う data class 的なもの）以外を Codable にするのがアンチパターンな気がしてます。

むしろ、型自身が Codable だから、その振る舞いを変えるというのがカプセル化を壊しているように思うんですけど（型の責務を、外から変えてる）。

いや、違うのかなぁ。僕のイメージが JSON とか YAML とか DB とかに偏りすぎてるのかもしれません。

3:06 AM

シリアライズの道具と考えると、また違って見えてきますね。

ああ、確かに forum を見たときに、シリアライズの道具としてのCodableと考えてるんだなとぼくは思いました。

むしろ、型自身が Codable だから、その振る舞いを変えるというのがカプセル化を壊しているように思うんですけど（型の責務を、外から変えてる）。

これって Comparable をソートするときの挙動を↓でカスタマイズするのと同じじゃないですか？ https://developer.apple.com/documentation/swift/array/2296815-sorted

シリアライズの道具としてCodableが作られたけど、実際によく使われるシーンとしてはJSONのような汎用の形式との相互交換が多く、むしろそっち方面で人気があるから、ややこしいことになってる気がする。

これめっちゃ思う。

3:09 AM

Encoder/Decoderのインターフェースはデータ構造にたいして抽象的に設計されているのに、結局JSONの事考えながらやってるから、

3:09 AM

余計に抽象化されててAPIがわかりにくいって感じることが多い

3:09 AM

この前 JSONの配列に1:1対応する型を作ろうとして、 singleValueContainerにたいして decode([Hoge].self) みたいに書いてて

3:09 AM

全然わからなくてワロタ

うーん、やっぱカプセル化うんぬんは変な気がして、 Encoder/Decoder は最終的なフォーマットによらない抽象構造との間の動作を規定するので、その抽象構造の先の具象構造が [x, y] だろうが {"x": x, "y": y} だろうが構わないはずなので、そこをカスタマイズしてもカプセル化は壊れない気が。 (edited)

Coparableのカスタマイズの方は、Arrayに生やしたメソッドだから、別にカスタマイズできていいんじゃないですか。Comparableなオブジェクト自体の比較動作を変えたりはしてないので。

3:14 AM

あ、そうか。たしかに、Encoder/Decoderの振る舞いを変える提案なんだから、Codable自体の動作は変わらないですね。言われてみれば確かに。

3:15 AM

カプセル化されているのが何なのかよくわからなくなってきました

1

本当にシリアライズの道具だとしたら、dateDecodingStrategyとかも本来許してはいけなくて、シリアライズ方法ごとに型を作って対処すべきですよねこの間、UserDefaultsにdateをもつ型をエンコードして突っ込んで、それをデコードしたらstrategyが違って危うくバグるところでした forumに特別扱いの理由は書かれていましたが、やっぱり中途半端な感じがします

dateDecodingStrategyとかも本来許してはいけなくて、

この部分については

3:33 AM

「JSONEncoder」固有だから良いんだ　って言ってました

3:34 AM

（よくわかってないけど）

僕が英語をちゃんと読めてないのかもしれませんが、カプセル化が Codable な型のことを言っているのであれば、別に JSONEncoder/Decoder のレイヤーでカスタマイズできてもカプセル化には問題ないような気がしますね。 (edited)

ああ、混乱してましたそう、シリアライズの道具なのはCodableであってCoderではない…から…えーっと、もう一度forum読んできます…

We did this for Dates and Data specifically because they are 1. Incredibly common types, which are likely to have the same representation across your entire payload, because 2. Specific format requirements are likely controlled by whatever software is running on a server, and for those very integral types, the server is likely opinionated/has specific requirements いまいちよくわからない「DataとDateに特別にstrategyが許されるのは、全payloadでサーバの統制の元、同じ表現が使われがちだから」って意味であってますか？であれば、それはstrategyではなく、init(from:)の決め打ち実装をなくしてユーザーにextensionで書かせるべきなのでは

payload全体を通して同じ表現が使われがちだから、ということでしょうね（ほんとにそうなの？という疑問はありますが）

4:49 AM

あと、Incredibly common typesだから、というのも重要なのかも。

~~ああ、なんとなくわかってきたかもしれません。~~ ←いや、わからなくなってきた

(edited)

彼らの言い分に納得できたわけではないですが、なんとなく言い分がわかってきた気がします。

6:24 AM

Proposalの方法では例えば CGPoint の表現を変えることができるけど、それは内部で CGPoint を持っている別のstructの表現にも影響を与える。でも、そのstructは CGPoint が配列表現でエンコードされているという想定で実装されているかもしれないので外から挙動を変えるのはよくない（←ここ、どういうときにそんなことがあるのかぼくは今ひとつ納得いかない）。だからそういうのは認めたくない。

6:25 AM

だけど「JSONでは」日付とデータの決まった表現がないにも関わらず、現実的にはかなり一般的に利用されていて、表現のブレを吸収できる何かを用意しないと JSONDecoder が使えない物になるから、例外的にそれを提供した、ということかと思いましたがどうでしょう。 (edited)

でも、そのstructは CGPoint が配列表現でエンコードされているという想定で実装されているかもしれないので外から挙動を変えるのはよくない（←ここ、どういうときにそんなことがあるのかぼくは今ひとつ納得いかない）。

ひとつの JSON 等の中で同じ型にデコードされるものが別の形式で表現されてるのはどうにもならない気が・・・。

6:39 AM

たとえば、 struct Line { var point1: CGPoint var point2: CGPoint } を作ったとして、 Line と CGRect で内部の CGPoint の表現を一つの JSON 上で変えようというのはさすがに JSON が壊れすぎかと思います。 (edited)

6:41 AM

↓とかはひどい気が。

{ "rect": { "origin": [2.0, 3.0], "size": [100.0, 200.0] }, "line": { "point1": { x: 0.0, y: 0.0 }, "point2": { x: 100.0, y: 100.0 } } }

(edited)

It’s common to include types which are not your own in payloads

それに関しては外部システムからの JSON をそのまま要素として含んでるということがよくある。というのがそれに対する反論みたいですが、 Date こそその可能性が多いような気がします。 (edited)

抽象レベルが違っていて、サーバー側では別の構造だけどiOSでは同一の構造に丸めたい、とか有り得そう

対象のフォーマットによっては、 <Point x=1, y=2> と <Line x1=1, x2=2, y1=3, y2=4> みたいにしたいとかあると思います。

なんかそもそもプリミティブの値を適当な構造に変換したいっていうのが業だよなぁという気がしている

Swift上のstored propertyのツリー構造と、シリアライズ先のデータ構造が対応取れない事もありえる。

6:43 AM

シリアライズしたい話しと、特定のフォーマットに書き出したい話が混ざっちゃってるんだとは思う。

外部システムからの JSON をそのまま要素として含んでるということがよくある

なるほど。これは辛い、けどもうカプセル化うんぬんの話じゃなくて、それは別の型にマッピングしないとどうしようもない気がします・・・。

いずれにしても、トップダウン(root要素から) デコードしていくので、デコーダー全体のデフォルトとしての strategy を設定できるのは個人的には良いと思いますけどね。

6:44 AM

例外的なのがあるなら、一つ上の親要素のデコーダで吸収すれば良いし。

@omochimetaru

対象のフォーマットによっては、 <Point x=1, y=2> と <Line x1=1, x2=2, y1=3, y2=4> みたいにしたい

これは単にそういう風に Line のデコード／エンコードを実装すれば良いのでは？

ああ、同じ型だけど文脈で変えたいという話なのか

@rintaro そうですよねぇ。

ぼくも、そもそものリジェクト理由のカプセル化うんぬんのところが納得いかないんですよ。

みんなの意見が概ね同じな気がしますね。

覆すには親要素の init(from:) で吸収できない、または著しく不便になる例を示すしかないでしょうねぇ。

今ってその型自体のストラテジーを変えたいってことなんじゃないですか？

6:55 AM

親で吸収しようとしても、 CGPoint がたくさんの型で使われていて、そのデフォルトの挙動と違う風にデコード／エンコードしたいときに全部親側で吸収はさすがに不便かと。

あ〜それもめちゃめちゃ困る時がある

6:56 AM

CGPointだけ変えたいんだけど、他にも var name: String, var age: Int みたいに

6:56 AM

デフォルト戦略でいい（自動生成で良い）stored propertyの部分まで

6:56 AM

encodeとdecodeのボイラープレートを書かないといけなくなっちゃう。

6:57 AM

（しょーがないからその型用のCGPointをラップした型を作って getter/setterでCGPointに見せかけることになる (edited)

the recommended approach ... is to write an adapter type which does have the format you’d like to use ... Is there a use-case that this approach doesn’t meet, though?

なんで、面倒な例を示してあげないと議論が進まない状態と思います。

import Foundation var json = """ { "a": "/home/omochi/temp" } """ struct Config : Codable { var a: URL } let decoder = JSONDecoder.init() let config = try decoder.decode(Config.self, from: json.data(using: .utf8)!) print(config.a.path) print(config.a.isFileURL) let encoder = JSONEncoder.init() encoder.outputFormatting = .prettyPrinted let j2 = try encoder.encode(config) print(String(data: j2, encoding: .utf8)!) var b = URL.init(fileURLWithPath: "/home/omochi/temp") print(b.isFileURL) print(b)

7:04 AM

今手元で踏んでるのがこれ

7:04 AM

config.a.isFileURL が true になってほしいけど false になっちゃう。 b は true だけど file:/// 形式だから嫌。

7:07 AM

（本題のフォーラムの方はまだ読んでないです、ずれてたらすいません） (edited)

その例は URL じゃなくて独自型作ってラップしようって言われて終わっちゃいそう

Thank you for your reply!

they have built-in assumptions about how their types are represented

Yes, they have assumptions about the payload structure. However, sometimes it differs from built-in structure provided by Swift standard library, like the example of CGPoint .

Dates and Data specifically because they are ... likely to have the same representation across your entire payload

I agree. Not only Date and Data , but also all types are likely to have same representation across entire payload. The types indicate their only one representation by conforming to Codable . The current problem is that, when it differs from assumption, there is no way to adopt "really" assumed format instead of built-in format. So I realized that introducing strategies is not the best way for my motivation. A better way is to

remove built-in Codable conformance from some types ( Data , Date , CGPoint and more).
let developers define their own extension Foo: Codable to conform their "real" format.

What do you think of this idea?

8:23 AM

返事を考えたけどStrategyの話ではなくなってしまった

8:24 AM

（見当違いなこと言ってないでしょうか…）

元々の要件は任意のプロパティにDateみたいに変換ロジックを簡単に（initのオーバーライドよりも。全部のマッピングを変更したいわけじゃないので）提供したい、っていうことだと思ってたんですけどあってます？

8:27 AM

あってるかっていうのは私の認識がそれであってるか、という質問です。

strategyとして提供する場合はそういう要件になりますね

8:28 AM

自分のモチベーションとしては、 APIレスポンスによって構造が違う場合、Codableでは吸収しきれないのでオレオレ型を仲介しなきゃいけない ←わかるすべてのAPIレスポンスで構造は揃ってるけど、Swift Standard LibraryのCodableの想定の構造とは違うので、オレオレ型を仲介しなきゃいけない ←なんで？こっちで構造決めさせてほしいという点のほうが強いですが (edited)

それは要求としては理解できますし、そういうことがあれば便利な場面があるのも理解できます。（私の意見としては標準ライブラリに入れるほどではないと思うんですが、ただその線引きはDate/Data/Floatは入っていた方が便利と判断されて入ってるので、どっちにもたおれうると思います）、

8:29 AM

とすると、

8:29 AM

remove built-in Codable conformance from some types ( Data , Date , CGPoint and more).

8:29 AM

この辺の話に広げるとたぶん

8:29 AM

話が違う方向に行っちゃうんじゃないでしょうか。と思いました。

- let developers define their own extension Foo: Codable to conform their "real" format.

だと、デコーダ毎からタイプ毎（つまりアプリケーション毎）になって範囲が変わってしまうので

8:30 AM

なかなか難しいですね。

私がこの話をするなら、　> 線引きはDate/Data/Floatは入っていた方が便利と判断されて入ってるので

なるほど。やるとしたら別スレッドで議論すべきこと、ですね

^ まずはここを広げていくところから始めると思います。

8:31 AM

URLはできた方がいい、Decimalを扱えた方がいい、

8:31 AM

などというのはけっこう理解してもらいやすいと思います。 (edited)

8:33 AM

例えばPoint型とかはそれよりはちょっと離れていて、かつ、あまり実感として他の人に便利さが伝わりにくいので議論するならいいけど、要求を通すにはまとまりにくそう、と思います。Point型に近いところだと緯度経度とかの方がまだ伝わるかと。

8:35 AM

URLはカスタムできないけどJSONDecoderでサポートされているマッピング型なのでまたややこしくなっちゃうかな。。。

8:39 AM

ともかく、CodableやJSONDecoderを入れるか入れないかという時期の話ではないので、具体的な問題から出発してDate/Data/Floatに許されてる部分を他の型にも広げるのがいいんじゃないですかね。一旦広がったら、そのあとうまくいってるから汎用的な仕組みを入れてもいいんじゃないか、という提案に繋げると。

そうですね、forumの返信でも特定のユースケースを求めているし、個別の型ごとに議論を進めていくのがよさそうですね。

私としてはさっきの議論でもそこそこ色々な話が出たので、リモートかつ英語のコミュニケーションというのを考慮して、XXXというほとんど基本型といってもいい型についてxxxDecodingStrategyというのを追加するというのはアリなのかナシなのかというところをまず話した方がいいと思うんですよね。

8:48 AM

そこにあまり乗り気でないとするとそのままで要求を通すのは難しいので別のアプローチが必要になります。

話のしかたを色々考えてみましたが、とりあえず最初には皆が引っかかってた「カプセル化違反」について確認して、求められてた「面倒な例」をひとつ挙げるだけにとどめ、forumにリプライ投げました。皆様ありがとうございますー。

xxxDecodingStrategyというのを追加するというのはアリなのかナシなのか

についての提議は話が膨らみすぎそうなのでまだ触れないでおきましたが、もし気が向いたタイミングで助太刀していただける方いらっしゃったら嬉しいかもです

(edited)

あと夕方の @omochimetaru さんのやつは、こういうんじゃ嫌なんですか？

struct FileURL: Codable { let url: URL init(from decoder: Decoder) throws { let container = try decoder.singleValueContainer() let path = try container.decode(String.self) guard path.first == "/" else { throw DecodingError.dataCorruptedError(in: container, debugDescription: "絶対パスにすること") } url = URL(fileURLWithPath: path) } func encode(to encoder: Encoder) throws { var container = encoder.singleValueContainer() try container.encode(url.path) } } struct Config : Codable { var a: FileURL } let decoder = JSONDecoder.init() let config = try decoder.decode(Config.self, from: json.data(using: .utf8)!) print(config.a.url.path) print(config.a.url.isFileURL)

@takasek 実際、それになってるけど a.url をいちいち書くのが面倒です

:sorena:

var a を private にしつつ URL の computed property を生やす方法もあるけどそれも面倒だし、メモリや計算効率的にも無意味なオーバーヘッドがある。(最適化で消えている可能性はあるけど) (edited)

私はこの例は単純にStringで受けて適宜使うタイミングでURLにする方がいいと思うんですよね。JSONDecoderのURLはファイルURLを想定してないと思います。

1

11:00 AM

URLクラスの問題ともいえるけど。文字列からFoundationのURLへのマッピングは自明ではないので、無理にマップしようとしない方がいいと思います。 (edited)

文字列型を露出させるとその変換をサボって文字列のまま取り扱う恐れがあるのが嫌なんですよね URL型じゃなくてFilePath型があったらいいので、自作したものとかもあるんですが、 Foundationに入ってるのは楽なので使いたくなる・・・

厳格にしたいとか誤操作を防止したいという目的にはFilePath型を使うのが正解だと思いますね。FoundationのURLにしてもそんなに効果ありますかね？とりあえずStringで持つことについてはSwiftのStringはNSStringと違ってパスを操作するメソッドとか無いので、普通は適宜URLを使わないですかね。

11:13 AM

どっちかだと思います。なんとかしてURLで保持しようというのは問題を難しくしてると思います。

appendingPathComponentとかpathExtensionとか便利ですね都度変換はめんどくさくなって、直接 + “/temp” とかやっちゃって、そのうちスラッシュの取り扱いポリシー間違えて死ぬのを過去に何度かやったので、常にパス用の型で見えるようにしたいです。 Stringで保持してプロパティで都度変換するのがバランス良いかもと思えてきました

11:20 AM

プロパティの都度変換だとjsonのキーとプロパティ名の対応がズレるのを諦めるかか、CodingKeysを手動定義するか、そのどちらかの苦しみがあるんだった。迷う・・・

JSONや外部のデータとネイティブオブジェクトのマッピングは、できるだけマッピングを素直に保って自明な状態にしておく方がおそらく良いと思ってるんですよね。

DTOとして割り切って、Modelにはそこからさらに変換かけるイメージでしょうか？

はい。Swiftだとたいていは適当なfunctionで最初はよくて、大きくなってきたら適当なPrivateのStructにして、もっと進んだら独立したデータ型にしてファイルも分けてテストを書いて、って感じですかね。

僕も実際はコードベースが育ってくるとそうやって分けてますね

11:49 AM

Swiftだとpropertyの初期化の網羅チェックが入るから、そういう変換を書く時にフィールドの渡し漏れなどが無いので助かる

CodingStrategyの話って、もしかして https://github.com/norio-nomura/ObjectEncoder/pull/11 が元になってるのかな？

Add coding strategy by norio-nomura · Pull Request #11 · norio-nomura/ObjectEncoder

Add ObjectEncoder.EncodingStrategy and ObjectDecoder.DecodingStrategy that creating strategy Add ObjectEncoder.encodingStrategies and ObjectDecoder.decodingStrategies th...

おお、nomuraさんも似たことをやってらした

あ、似てただけですか。失礼しました。

いえいえ

12:30 PM

ObjectIdentifier型、知りませんでした標準であるんですね

僕のは、DataもDateも全部ひっくるめてのStrategy実装になってます。 (edited)

12:31 PM

var encoder = ObjectEncoder() encoder.encodingStrategies[Date.self] = .iso8601 let encoded = try encoder.encode(Date(timeIntervalSince1970: 1000)) encoded == "1970-01-01T00:16:40Z" // true var decoder = ObjectDecoder() decoder.decodingStrategies[Date.self] = .iso8601 let decoded = try decoder.decode(Date.self, from: encoded) decoded == Date(timeIntervalSince1970: 1000) // true

extension ObjectEncoder.EncodingStrategy where T == Date みたいな形でメンバ生やしてるんですね

JSONEncoder, JSONDecoderに備わってるStrategiesのスーパーセットにしてたはず。

ちょっと確認なんですが、 @takasek さんの提案は、 JSONEncoder / JSONDecoder に対する機能追加ってことですよね？それとも、 Encoder/Decoder 一般の話として提案してますか？

2:31 AM

ぼくは前者（JSONだけ）と思ってたんですが、forumをよく見たらJSONはただの例にも見えたので。

現在の PropertyListDecoder には（必要なかったからというのもあるでしょうが）strategy系のプロパティはないので、strategy系のやつはJSONをpayloadにする場合のオプションだと思います。本来、日付やデータはJSONには入れられないはずなので、原則的には、例えば日付ならDate型の init(from:) に任せるべきなんだと思います。

2:52 AM

そこを例外的に認めているのは、たぶん、世の中に存在するJSONが日付を扱っていて、サーバーサイドでも日付型を変換してJSON化する方法が一般的に取られていて、その例外を認めてあげないと、Swiftとしての魅力がなくなってしまうからかなあと思いました。だから、一般的に使われている代表的な変換方法をstrategyとして提供しているのだろうと。

2:57 AM

もしこの想像が合ってるなら、JSONで対応してあげないとSwiftの魅力が半減するような「一般的な」型を例としてあげないと、納得してくれないように思いました

AとBがあって、それぞれnilの可能性があるが、両方同時にnilであることは有り得ない

7:31 AM

↑を表現する一番スッキリする方法

7:32 AM

enumで3ケース書く方法しか思いつかなかった。

３値論理だ

7:32 AM

ちょっと違うか

AとBがあって、どちらか存在する、ならenumで超すっきりなんだけど、

7:33 AM

↑↑↑の例はなんかモヤ感がある

enumのOptional？

7:33 AM

あ、ぎゃくか。

7:33 AM

両方nilは無いのか。

素直にenumで表現するとこう enum X<A, B> { case both(A, B) case a(A) case b(B) }

7:34 AM

やっぱこれしかないかなぁ

素直に struct にして両方nilも出ちゃうけど諦めよう

ええーーー

素直に structにしてinitで制限したらいいんじゃないかなあ。

使う側で両方nilのケースには fatalError("never this")

private プロパティにしてアクセサ付けるのが素直だと思います。

これ考えてる理由としては、Errorの合成なんですが(実際にはプロダクトではもう必要なくなったけれども興味で)

7:36 AM

処理Xと処理Yを合成する時に、それぞれ並列で走らせた結果として、それぞれのエラーを合成する時に

7:36 AM

合成が発生するからにはどちらか一方は必ず発生しているという状況になって

7:36 AM

あーーー

7:37 AM

ErrorをOptionalにすれば素直にOptionalの掛け算でいいんかな (edited)

それだとnil nil があるんじゃ？

Optionalの掛け算だと

7:38 AM

errorAorNil.flatMap { x in errorBorNil.map { x * $0 } } これでerrorAorNilかerrorBorNilがnilだと消えちゃう (edited)

7:39 AM

@rintaro

private プロパティにしてアクセサ付けるのが素直だと思います。

これはstruct enum どっち前提ですか?

Errorの話だと、 ErrorA , ErrorB, CompositeError<ErrorA, ErrorB>

7:42 AM

みたいにできそうだけど・・・

これはstruct enum どっち前提ですか?

struct です。

残念ながら今Result文化圏に住んでいまして。。。

結局そこで3択enumが必要になるか。

エラーが発生しても後続の処理は続行して行い、全てのエラーを合成するという処理が必要になって

7:45 AM

合成可能なエラー型を作ったはいいが、これを合成するいい方法を思いつかなかった。結局コレ自体はいらなくなったけど

7:45 AM

ベストプラクティスを今に至るまで思いつかないのでここに来た、って感じす

素直に struct にして両方nilも出ちゃうけど諦めよう

これがありなら Either<T, U> を (T?, U?) で表せばいいよねっていうのを認めることになってしまう気が。

1

それは Eitherの文脈で TかつU を許容してるので

7:47 AM

罪の数が２倍多い

7:47 AM

今回なら罪状１件で済む

ワイ潔癖症一寸の罪も許さず

(T?, U?) | | T | N | |:-:|:-:|:-:| | U | o | o | | N | o | o | (edited)

7:50 AM

Either<T, U> | | T | N | |:-:|:-:|:-:| | U | | o | | N | o | |

7:50 AM

今作りたいもの Foo<T, U> | | T | N | |:-:|:-:|:-:| | U | o | o | | N | o | | (edited)

あー

そうそう、罪状の数はそういうこと

Optional2引数の合成関数を作るのは、綺麗な世界じゃないけどそれなりに欲しいものは出来る気がしてきた

7:51 AM

flatMap, ?? のいずれも出来ない事を実現する関数

7:53 AM

extension Optional { func merge(with other: Optional, f: (Wrapped, Wrapped) -> Wrapped) -> Optional { if let x = self, let y = other { return .some(f(x, y)) } else { return self ?? other } } }

7:53 AM

これだ!

ああ、何を言いたいかわかった

Either は sum type だけど or じゃなくて xor なのか。

「両方ある」のは一瞬でよくて、すぐ畳み込んでも大丈夫なケースなのね。

そう

今作りたいのは xor じゃなくて or

いや今回はたまたまそうだったけど常にそうとは限らない

@tarunon どっちの返信がどっちに向けたものでしょう？？ (edited)

1

両方おもちあてです

1

常にそうとは限らないならやっぱり一般論としては3case enumがいるよね

とりあえず3case enumを作るしか無さそうだというのは理解してきた。それって一般的な構造として名前ついてるのかな。

Either<(A, B), Either<A, B>>

聞いたこと無い。いなみせんせいを呼ぼう。

Either<(A, B), Either<A, B>>、Typealiasがほしいw

8:02 AM

確かにそうだ

8:02 AM

其の型であってるんですよ、それだ、それはスッときた

Either3<(A, B), A, B>

8:03 AM

Either3<A, B, C> は Either<A, Either<B, C>> と同型

Either<(A, B), Either<A, B>> 、 sum type と product type が組み合わさって↓な世界だ。 https://speakerdeck.com/inamiy/algebraic-data-type-in-swift

Yasuhiro Inami

Algebraic Data Type in Swift

Tokyo iOS Meetup (Jan 13, 2018) https://www.meetup.com/ja-JP/TokyoiOSMeetup/events/245521284/

↑これ本当にメンタルモデルが一回り整理されて良かった

@inamiy

8:04 AM

(来てくれるかな…)

scalazだとTheseって名前でありますね https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/These.scala

scalaz/scalaz

scalaz - An extension to the core Scala library for functional programming.

1

おお〜 this, that, both

処理Xと処理Yを合成する時に、それぞれ並列で走らせた結果として、それぞれのエラーを合成する時に合成が発生するからにはどちらか一方は必ず発生している

ただscalaだとこういうケースであればNonEmptyListっていうのを使うことが多い感じします。(もちろんErrorAみたいな具体的な型はなくなってしまうけど。。) http://eed3si9n.com/learning-scalaz/ja/Validation.html

関連して雑談的に思ったんですが、 T|U は T か U のどちらか一方しか許さないのに、 t|u は t と u の両方を許容していて、 T|U はむしろ t^u 的で T^U なんじゃないかという気が。

^ は指数記号じゃなくてXOR記号？

うん

9:10 AM

自然言語の or って曖昧さがあるよなぁと思ってたけど、これまで T|U にそんなことを考えたこともなかったってことは、頭が自然言語に相当毒されてる・・・。

たしかに

代数的データ型の sum type は排他的だけど論理和は排他的でない？そこは xor と対応しなくて良い？？

和集合って考える時に

9:12 AM

タプルにならなくないですか？

集合じゃなくて論理の方

データ型の線形代数的に考えてる時は集合論がベースにあるんじゃないですかね

∪じゃなくて∨

9:14 AM

それはそうとして、論理和と排他的論理和と和集合とsum typeの関係はどうなってるんだろう？と。 (edited)

ふーむ

なんか数学的な関係がありそうだけど、 sum type は排他的なのが気になる

9:17 AM

また @Taketo Sano さんの意見が聞きたいけど、最近ここにいなさそう

正月明け以降しばらくは全体的に過疎ってた感

英語だと sum type だけど日本語だと直和型だから、その「直」の部分に意味があるのかな？

9:23 AM

和型でないのは。

9:26 AM

↓聞いてみました。 https://twitter.com/koher/status/956458037929127937

koher (@koher)

@taketo1024 突然質問すみません。Discordのios-developers-japanで話してたんですが、直和型と論理和と排他的論理和の数学的な関係がどうなってるかご存知でないでしょうか？Either<T, U>がTとUのどちらかしか許さないのは、論理和よりむしろ排他的論理和に近い気がするのですが。

1

うーん、Eitherは（排他的論理和じゃなく）論理和でいいんじゃないかなあと思いました。その理由 https://gist.github.com/hironytic/9cb2f09d22a615dd26c043589c7a4b31

Eitherは論理和でいいと思う理由

どうもです

‍♂️ (edited)

2:21 PM

「代数的データ型」の代数構造について何も知らないのでちゃんとしたことは言えませんが、直和・直積は圏論による定式化があって、考える圏によって定義は色々と変わります。 (edited)

2:22 PM

例えば集合の圏だと、直和は非交和 X ∪ Y で直積は X×Y。 (edited)

2:23 PM

有限次元ベクトル空間の圏だと直和と直積は同じで X × Y（無限次元になると別） (edited)

2:27 PM

半順序集合自体を一つの圏と見ることもできて、この場合の積は ∧、和は ∨。ブール代数（ブール束？）との関連はこの辺りにあるんだろうと思います（詳しいことは知りません） (edited)

2:28 PM

代数的データ型も恐らく何らかの方法で圏と見なすことができて（型を対象、関数を射と見るのかな…？）、そこでは enum が直和、struct が直積に対応するものになるのだろうと思います。 (edited)

2:30 PM

なので数学的関係については「圏論の和・積」を通してあることになるんだと思います。もっと直接的な関連もあるのかも知れませんが分かりません

‍♂️ (edited)

2:52 PM

これが「積」の定義で、

2:53 PM

2:54 PM

これが「和」（または「余積」）の定義です。

3:00 PM

例えば整数全体を整除関係（a が b を割り切る ⇔ a ≦ b）によって半順序集合と見なした圏では、a, b の「和」がその最小公倍数、「積」が最大公約数になります。 (edited)

@taketo1024#1158 ありがとうございます！圏論についての知識がなさすぎてすぐには理解できなさそうですが後でちゃんと読みます

1:35 AM

#math でやればよかった

1

#math に移動しました。

https://forums.swift.org/t/pitch-result-t-enum/8945

[Pitch] Result enum

We all love enums! Every time when I am adding Result to project, I wonder why it is not included in stdlib. enum Result { case success(T) case failure(Error) public init( value: T) { self = .success(value) } public init( error: Error) { self = .failure(error) } } This is very powerful type while using it with Swift pattern matching operators like switch or if-case .

10:22 AM

繰り返す・・・

今までの何か違うのかと思ったけど、シンプルな提案だな。。。 (edited)

Typed Throws のステータスってどうなってるんだろう？

3:17 PM

async/await に Future 的なものがないと並列実行ができないから、それとの絡みで Result も結局必要になる気がしてる。

Futureはラトナーの提案で実装例が示されてますよ

うん、それ見て Result も必要そうだなと思った。

3:21 PM

あの Future の例だと失敗しない Future が作れない（ようになってたはず）。 (edited)

Future<T>とFailableFuture<T>を作るのではなくて、Future<T>とFuture<Result<T>>で表すためにってことですか？ (edited)

はい。 extension<T> Future where Value == Result<T> ができれば↓みたいに便利メソッドは生やせるので。 extension<T> Future where Value == Result<T> { func get() async throws -> T { return try await get().get() } } （↑のままだと get がオーバーロードになってしまうのが微妙ですが。）

1

今更ながら見たんですが、LLVM Developoer's MeetingでChris Lattnerが発表したSILの動画がかなり分かりやすくまとまっていて素晴らしい資料でした https://www.youtube.com/watch?v=Ntj8ab-5cvE

LLVM

2015 LLVM Developers’ Meeting: Joseph Groff & Chris Lattner “Swift's High-Level IR: A Case Study..."

1

見よう

LLVMの会のほうで結構Swiftのコアな情報が発表されてるの最近まで気がついてなかった、この動画は未チェックだったので見ます

今までSwiftのドキュメント見て頑張って理解しようとしてたけど、こっちのほうが断然分かりやすいw

2:57 PM

あとMacアプリでASTとかSIL出力できるのを見つけて、手元で簡単なコードを試す分には結構便利かも https://github.com/alblue/SILInspector

alblue/SILInspector

SILInspector - An application for experimenting with Swift's Intermediate Language

https://www.youtube.com/watch?v=ctS8FzqcRug

LLVM

2017 LLVM Developers’ Meeting: “Implementing Swift Generics ”

3:01 PM

ジェネリクス, Value Witness Table, Protocol Witness Tableあたりのコード生成についてはこれが良い↑

ほーそろそろSIL上でVtable, Witness Tableらへんの挙動を調べようと思ってたので助かります！

masterはconditional conformanceをランタイムチェックできるようになったぽい。 https://github.com/apple/swift/pull/14368

[Runtime] SE-0143: Evaluate conditional conformances at runtime. by DougGregor · Pull Request #14368 · apple/swift

When evaluating whether a given type conforms to a protocol, evaluate the conditional requirements and pass the results to the witness table accessor function. This provides the ability to query co...

1

もどかしいさんがSwift Compilerについて細かい説明を書くプロジェクトを見つけました。ブログ記事自体は皆見れるけど、記事中のソースコードとか重要なとこはパトロンしかアクセス権無いという面白い仕組みでした。とりあえず課金しちゃった https://www.patreon.com/modocache/posts

modocache is creating in-depth guides to the Swift compiler | Patreon

Become a patron of modocache today: Read 14 posts by modocache and get access to exclusive content and experiences on the world’s largest membership platform for artists and creators.

2

7:31 AM

ブログ記事はこちら https://modocache-io.herokuapp.com

func < を定義したときに <= とか > が使えるようになるのって Comparable なときだけか。 Optional<Cat> に < を定義する時とか、 Conditional Conformance があると楽になるね。

Comparableのデフォルト実装ですね

なるほど

https://github.com/apple/swift/blob/db5c967c49a6b929f6b812cf6613adff55a7587d/stdlib/public/core/Comparable.swift#L176-L220 このへんか

haskell-like-func-def.swift

swift - The Swift Programming Language

もうちょっとでCC来るからこのタイミングで <= の自前定義するの萎えるｗ

haskellみたいにどれか一個定義したら残りも使えるのだとかっこいいのに

ハスケルのそれってどうやってんだ

8:04 AM

うまい構文が無いと循環したりしそうだ

関数と型のセットで内部的には別の型を割り振ることでextensionを切り替える、とか出来るのでは?と思った

ハスケルライクにできるのか試していたらillegal hardware instructionとかいう不吉なエラーで死んだ... https://gist.github.com/ukitaka/a995c8821ad5a831f675c8954ff1b713

2

odd evenのほうは行けてるみたいですけど次の問題はどちらか片方は実装という制限が付けられないことですね

片方は実装という制限が付けられない

これがないなら今の方がマシそうですねぇ。

tarunon - 今日 午後5時4分 関数と型のセットで内部的には別の型を割り振ることでextensionを切り替える、とか出来るのでは?

これは現在のSwiftの話ではなく、理論上はという意味でし

OddableとEvenableに分けるしか

ですね〜

9.3 beta ではクラッシュは再現しませんでした。

1

9:01 AM

extension のデフォルト実装間で無限再帰っぽいですね。4.1で挙動が変わったということか。

extension MyInteger where @implemented(isOdd) { var isEven: Bool { return !isOdd } } こういう感じのがあれば出来るが…

9:02 AM

いやーこれはw

昨日 https://vapormeetuptokyo.connpass.com/event/77789/ の @noppoman の発表で、 SwiftPMで作ったdylibにたいして、 ld で(当然、マングルされている)シンボル引っ張ってきてそれを dlopen でリンクして、 NodeJSからSwiftがネイティブブリッジ呼び出しできるよっていうワイルドな話があって面白かったんですが、実際このアプローチなら C <- Swift だけでなく Swift <- C , Swift <- C++, Swift <- Python, Swift <- Ruby みたいなブリッジが可能なので、 C/C++でやってた事がSwiftに置換できる余地があって良さそう

Vapor Meetup 1st in Tokyo（Server-side Swift） (2018/02/06 19:00〜)

## イベント概要 # VaporMeetupTokyo Vapor meetup in Tokyo 1st. Youtubeで配信します！19:00 スタート https://www.youtube.com/channel/UCQSdXXHq6tvvTDA58EqcfEQ/live Swiftはバージョン3以降OSSとなり、LinuxやAndroidなどのAppleプラットフォーム以外での利用シーンも広がってきています。サーバサイドでSwiftを使うことも選択肢の一つになってきています。日本ではまだあまり有名になっていないサーバサイドSwiftの代表的なフルスタックMVC...

オーディエンスの反応がイマイチだったのでつまんない話してるのかなーって心配してたんですが、面白いと言ってくれてホッとしました

資料上げてシェアしますね。

1

おもちが一人で爆笑してたｗ

http://twitter.com/d_date/status/960831542317662208 http://twitter.com/hiragram/status/960832531409940481

Daiki Matsudate (@d_date)

おもち爆笑してるw

本質 (@hiragram)

おもち一人だけ笑ってて変なやつやぞ

2:46 AM

あれは笑うところでしょ。

レベル高すぎて追いつけませんでした

資料読み直したいです！

そこらへんのCライブラリ互換性は、Rustがパパーっと先に進んじゃったから、Swiftのフロンティアが若干食われちゃった

（シンボルとか普段全く触らないからな…（白目

ネイティブバインディングからサーバーサイドSwift初めてみるのはありかと思いますねー

現状の道具だとRubyエンジニアにはそのブリッジするところのハードルが高すぎると思うんで、そこの面倒見てくれるツールキットやボイラープレートジェネレータを作ったりするといいのかなとちょっと思いました。

たしかに。ブリッジのハイレベルなインターフェースを提供できる仕組みの開発は検討してみます。

@noppoman ちなみに、Swift開発チームでは今、逆方向で、 Swift -> Python のブリッジの導入をすすめてます https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658

SE-0195 — Introduce User-defined "Dynamic Member Lookup" Types

The review of “SE-0195 — Introduce User-defined “Dynamic Member Lookup” Types” begins now and runs through January 29, 2018. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager direct...

サーバーレスでモバイルエンジニアが簡単にWebアプリ作れちゃうみたいなのも目標の１つではあるので、サーバーレスが提供している言語で提供すると使ってくれる人がいるかも？

 // import pickle let pickle = Python.import("pickle") // file = open(filename) let file = Python.open(filename) // blob = file.read() let blob = file.read() // result = pickle.loads(blob) let result = pickle.loads(blob)

こういうの。

2:59 AM

なるほど > サーバーレス

この逆方向のやつ、Swiftからの他言語の実行方法が気になりますね

Python, Ruby, JSについては、処理系のC APIですね。

3:14 AM

https://docs.python.jp/3/c-api/refcounting.html

3:14 AM

こういうやつ。

あーなるほど！

↑の提案は、Swiftの式に対するメソッド呼び出しにたいして動的にフックできる言語機能を追加するだけで、Pythonとかの個別言語との実際のバインディングは、そのフックのところで、C APIを呼ぶようにライブラリとして用意する感じですね

3:19 AM

なので、noppomanさんがおそらく考えてる、JSプログラマがSwiftもちょっと入れてみるっていう合流の方向とは逆で、 SwiftプログラマがPythonのライブラリ資産をつまみぐいで使える、みたいな方向ですね

https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md こっちみて使い方わかりました！なるほどですねー機能としては面白いけど、そんなヘビーに使われなそうw

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

3:23 AM

言語ラップ以外にも使い方はあると思いますが

ああ、JSONの例とかも載ってますね。

1

#server-side 　のほうに資料upしましたー

1

ちなみに、昨日話していたアトリビュートは @_cdecl です。 @_cdecl("foobar") public func foobar(_ x: Int32) -> Int32 { return x + 1 } こんな感じで書いておくと、 int32_t foobar(int32_t x); としてシンボルが出来るので、Swift の Mangling に依存する必要が無くなりますよ、と。

ありがとうございます。早速使ってみます

Undocumented なので将来仕様変更の可能性は高いですが、 swift の ABI 追うよりはマシだと思います。

4:28 AM

$ swiftc -emit-objc-header -emit-library MyLibrary.swift みたいにすると、 MyLibrary.h が生成されて、 C からどう呼べるのか分かると思います。ただ、この生成されたヘッダーファイルは Linux でも Obj-C に依存する余計なものがいっぱい吐かれるので、そのままでは使えないとおもいますが。

1

僕としては機械学習で Python が避けられない現状なので、そのコードを Swift で書けるようになるのはうれしいですね。↑は一般的な言語仕様として提案されてますが、（提案者の） Chris Lattner の今のポジションから考えてもそこがメインターゲットだと思います。

Conditional Conformanceってジェネリックパラメータによって実装を変える事が出来ないのね。

protocol P {} extension Optional: P where Wrapped == Int {} // error: redundant conformance of 'Optional<Wrapped>' extension Optional: P where Wrapped == String {}

あ〜なるほど。

IntとStringなら一括りにするプロトコルを使えば

protocol WrappedP {} extension Int: WrappedP {} extension String: WrappedP {} extension Optional: P where Wrapped: WrappedP {}

とか出来るけど、タプルがラップされてる場合に使えない。

AnyまたはIntとかもダメですよね

8:42 AM

Existentialもダメなのでは?

8:42 AM

ExistentialはCondConfにできなくね

8:43 AM

extension Optional: P where Wrapped: Animal { ... } で、Optional<Animal>はPにならないですよね

Animal が protocol の場合ってことですね？

そうでうs

Optional<Cat> is P だけど Optional<Animal> is P ではないと。

そのはず

8:51 AM

そしてOptional<Animal> is Pにする手段が存在しないのでは

8:51 AM

LTネタ膨らみすぎて5分に収まらないなぁ

ややこしすぎるので existential 禁止にしてほしい・・・。

8:53 AM

それか Any<FooProtocol>

それがExisitentialになる感じです?それとも自動生成のType-erasure?

Optional<Any<Animal>> が Optional<AnyAnimal> と等価なイメージなので後者ですが、これも existential なのでは？ (edited)

私はExistentialはAnimalではないが、Type-erasureならAnimalであるという理解です

ああ、現状ではそうなんですが、

8:55 AM

↓の文脈では existential も Animal になるのかなと。 https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials

https://forums.swift.org/t/generalized-existentials-type-erasers/5046

swift - The Swift Programming Language

8:56 AM

typealias AnySequence<Element> = Any<Sequence where .Iterator.Element == Element> とするためには、 Any<FooProtocol> is FooProtocol じゃないとダメかと思います。

フーム

8:58 AM

Generalized Existentialってまだ全然議論されてないですよね、これが来た時に

8:59 AM

Existentialの名を冠するのか、別の名前になるのかが気になる

全然議論されてない

なんか、重要なテーマは実は2, 3年前に話されてて、MLに埋もれてる事がまあまあある

掘らなきゃいかんかー

フォーラムになったし検索してみたら出てくるかも。

Generalized Existentials / Type Erasers

Hi swift-evolution, I was wondering if anything more detailed has been written about generalized existentials / type erasers. I noticed that AnyCollection only delegates a number of methods to its wrapped value, but often doesn't. For example, all the conditionally inherited items aren't being delegated (e.g. min()). This behavior was surprising to me (but makes sense once I thought about it longer). How would this work with generalized existentials? Are generalized existentials in scope...

9:01 AM

あった

フォーラムになってアイコンでかすぎる・・・

www

9:02 AM

Swift4入るんか?入らんぞって感じに見えるな

9:03 AM

https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#nested-typealias-existential

austinzheng/swift-evolution

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

9:03 AM

こっちか

9:03 AM

言語サポートとしてはExistential推しだから、is Animal == trueな未来は来ないんじゃなかろうか

9:10 AM

https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#generics

austinzheng/swift-evolution

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

9:10 AM

ここ見るといけるようになる事を考えてる気がする

これが来た時に Existentialの名を冠するのか、別の名前になるのかが気になる

AnySequence とか個別に実装するの辛い問題はあるので、 existential と呼ぶかどうかはおいといて自動 type erasure はほしいですね。

isがtrueじゃないとこうはならない

9:11 AM

あ

9:11 AM

読み違えてた

9:14 AM

https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#existential-opening-using-as

austinzheng/swift-evolution

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

9:15 AM

X.SelfがGenericsに渡せる状態、つまりis Xな型として振る舞えるようになっているということかな (edited)

9:16 AM

Exisitential opening って書いてあるからまさにそれっぽい

このevolution通れば互換性のためのAny<FooProtocol> is FooProtocolを捨てて、Genericsに渡す際には明示的にopenさせる方向に進むっぽいですね〜正しい進化ではある

typealiasを都度宣言させるのも良さそう

9:38 AM

可能ならwhereなしでもtypealiasの宣言後初めて使えるぐらいにした方が、認知はずれないと思う

Swift CompilerをSwiftで書いたやつとか、LLVMのSwiftラッパーとかあって面白いですね https://github.com/yanagiba/swift-ast https://github.com/harlanhaskins/Kaleidoscope-Swift https://github.com/llvm-swift/LLVMSwift

yanagiba/swift-ast

swift-ast - A Swift AST parser and visitor that is written in Swift.

harlanhaskins/Kaleidoscope-Swift

Kaleidoscope-Swift - A compiler for the Kaleidoscope sample project, written in Swift

llvm-swift/LLVMSwift

LLVMSwift - A Swift wrapper for the LLVM C API (version 5.0)

SILのテストコードがどこにあるか知っている方いますか？SwiftParseTestsとかSwiftASTTestsは見つけたけど、それのSIL相当が見つからない... (edited)

swift/test/SIL SILGen SILOptimizer sil-func-extractor sil-llvm-gen sil-nm sil-opt sil-passpipeline-dump

12:33 PM

ここらへんじゃないですか？中は読んでないですが

すみません、言われてみればリポジトリから探せば普通にあった。ビルド時に生成されたXcodeプロジェクトから見つからなかっただけでした.. ありがとうございます！ (edited)

テストは基本的にtest以下とvalidation-test以下にまとまってて、テストを回す専用のスクリプト機構で流すようになってます xcodeからだとそのスクリプトを叩く発火用のターゲットしか見えないですね。一部のユニットテストだけはxcodeでも素直に見えてる。

よくよく見たらTestingのドキュメントにちゃんと書いてありました。テスト用のスクリプトも目を通してみます。

1

https://github.com/apple/swift/pull/14546

Implement SE-0195, which introduces "Dynamic Member Lookup" Types by lattner · Pull Request #14546 · apple/swift

This is a dusted off and updated version of PR13361, which switches from DynamicMemberLookupProtocol to @dynamicmemberlookup as was requested by the final review decision. This also rebases it, up...

1:14 AM

テストのswiftソースのインデントが2だ・・・

swiftのソースってそこら中インデント2じゃないっけ

マジ？気づかなかっただけか

Xcodeで書くとデフォルトのインデントが4なのとプロジェクト単位で切り替える手段が無いらしくブチ切れ

それクソ不便だよねw swiftのcxxが2だからシコシコ切り替えてる

Xcodeはプロジェクト単位でインデント設定できるよ

プロジェクト単位で切り替える手段が無い

Project Navigator でプロジェクト選んで、Utilitiies でプロジェクト毎のデフォルトインデント設定できるとおもいます。 (edited)

1

お！

プロジェクトファイル（青いやつ）を選択して右ペインのText Settings

ありがとうございます。ファイル単位とXcode単位のしか見つけれてなかった

ファイル単位でもいけたような

！！！！！！！！！こんなところに！！！！！

1:34 AM

ファイル単位そういうことか

1:34 AM

同じ場所にあった　マジか・・・　ありがとうございます

まあ普通わかるはずないUIだと思う。

1:36 AM

ファイル単位はまあJSとHTMLみたいな混合のときに使うんだろうけど、ほとんど使われないだろうし。

僕はつい最近までプロジェクト単位知らなくて、偶にあった2スペースインデントのプロジェクトではファイル単位でシコシコ設定していました

前rintaroさんが諦めてるみたいなの言ってたの覚えてて同じく諦めてた

プロジェクト単位のはわかりにくいけど、設定してコミットしておけば基本的に違うインデントやタブが混ざったりするのを防げる。

https://forums.swift.org/t/add-operators-for-working-with-unary-predicates/9919

Add operators for working with unary predicates

I frequently find myself wishing for more expressivity when using predicate functions, and so I end up defining these operators so I don’t have to create cluttered little closures: func && ( lhs: @escaping (Element) -> Bool, rhs: @escaping (Element) -> Bool ) -> (Element) -> Bool { return { lhs($0) && rhs($0) } } func ( lhs: @escaping (Element) -> Bool, rhs: @escaping (Element) -> Bool ) -> (Element) -> Bool { return { lhs($0) rhs($0) } } prefix func ! ...

6:17 AM

Bool関数を合成するオペレータを定義してこういうの書きたいってスレ

var a = 1...10 a.filter(isEven) // [2, 4, 6, 8, 10] a.filter(!isEven) // [1, 3, 5, 7, 9] a.filter(isEven && isMultipleOfThree) // [6] a.filter(isEven && !isMultipleOfThree) // [2, 4, 8, 10] a.filter(isEven || isMultipleOfThree) // [2, 3, 4, 6, 8, 9, 10] a.filter(!(isEven || isMultipleOfThree)) // [1, 5, 7]

6:17 AM

// current a.filter({ isEven($0) && isMultipleOfThree($0) }) // pitched a.filter(isEven && isMultipleOfThree)

@ukitaka

1

@t.ae 好きそう

いいですけど述語をたくさん定義するのが微妙な気もしますね

6:23 AM

filter以外で便利になるケースがいまいち思いつかない気もしますし

removeとか。

これが出来るなら関数合成ももっと楽にできて欲しい

6:24 AM

(S) -> T と (T) -> Uとか

However, the thought occurs to me, is it possible to make this more general? As in, given two functions f and g, where the return value of g matches the input to f, can we make something like f(g) or f.g resolve to the closure { f(g($0) } or equivalent?

where系のは全部行けるか。 firstとかindexとかも行けると考えると役立つかもですね

デスヨネ

Nevinさんのレスがそれかな？ (edited)

Ben_Cohen

>9h

>Oh, also +1 for also adding f • g

thumbs upしとこ

guardでの早期脱出は一種のフィルタなんだけど、フィルタを抜けると同時に型変換が生じるから、こういうふうには合成できなそうだなあ

import UIKit class Cat {} func f1() -> ObjectIdentifier { let cat = Cat() return ObjectIdentifier(cat) } func test1() { var a = Set<ObjectIdentifier>() for _ in 0..<10000 { let id = f1() if a.contains(id) { print("conflict") } a.insert(id) } } test1()

3:06 AM

異なるオブジェクトに対して同じObjectIdentifierが生成される可能性がある実証↑

やばそう

ObjectIdentifierが引数で受けたオブジェクトを内部で弱参照で保持し続けていれば

3:07 AM

弱参照はフィールドは解放するけどオブジェクトスペースは保有しつづけるので、同じヒープアドレスが使われることがなくて、この現象は起こらないんだけど

3:07 AM

そうなってなかった。

あー

3:07 AM

class型だとそうなるか

3:08 AM

Typeの場合はそもそも確保され続けるから安全なはず(どちらかと言えばTypeに使う用途が多い)

Typeをキーにした辞書を作るために使うパターンなら問題ないね。

ことこれに関しては自分でHasshable作るのが良いねとなるかなぁ

3:09 AM

Hashable.hashValueが自動生成されるのはいつからだっけ (edited)

3:09 AM

4.1でくる?

4.1じゃなかったっけ？もう待ちくたびれた

4.1できてなかった

3:10 AM

Xcode9.3b2

インスタンスのObjectIdentifierをキャッシュのキーにしててコンフリクトする不具合を踏んだ事がある。

おお・・・

5:23 AM

気づかないと踏みそうです、発生率も微妙な感じなので厄介

5:23 AM

知らぬ間にキャッシュのキーが衝突して上書き、だと、上書きした後古い方を読んだ時に不整合が出るので、かなり厄介なタイプのバグだ

https://github.com/realm/SwiftLint/pull/837

Fix SourceKitCrashTests randomly failed by norio-nomura · Pull Request #837 · realm/SwiftLint

Sometime ObjectIdentifier(self) might collide between tests in SourceKitCrashTests. The collision caused fail on testAssertHandlerIsNotCalledOnNormalFile. Reproduced log with printing cacheKey: Tes...

SwiftLint！ｗ

5:25 AM

（あれっ、この話し前聞いた気がしてきた）

ありそうw

1

発生率も微妙な感じなので厄介 これもswiftlintの実行では発生せず、テストでしか発生しませんでした。

== の比較はコンパイルできるけど!=だとBinary operator '!=' cannot be applied ...と言われるプロトコルがあって、なんでかなと思ったら、==のオーバーロードだけ定義されてた。 (edited)

ObjectIdentifier提案した悪い子僕だったのでは…w

僕も最近そのルール知りました != や > は Equatable や Comparable に準拠してないと自動定義されない

!= や >って自動定義なんです？プロトコルエクステンションで ==や>を使って定義されてるんじゃないですかね。 (edited)

自動定義というか、エクステンションで生えていて、 == や < の呼び出しになる

ありがとうございます。

Tupleに生えなくて辛いことがあったりしますね

11:23 AM

Pair<A, B>ができる

@tarunon Tupleで、っていうのはどういう場合ですか？

[(Int, Int)] 同士の == が取れないとか？

ネストした系に困って、==をoverloadで定義しても、!=は生えない

11:30 AM

!=

11:30 AM

を使いたいならそっちもoverload

== だけ定義されてたら警告でFixitで!=を作ってくれるといいな。

そのプロトコルをEquatable準拠とするべきなのでは。

まあそうだと思うんですけど、==だけ定義するっていうのはなんか理由があるんですかね。 (edited)

Tupleはnon nominal typeなので

11:46 PM

Equatable準拠できない

Tupleはそうですね。今のところ要素数の数だけ==と!=をオーバーロードするしかない。

タプルも6要素まではstdlibで定義されてるはず。

Yes.

入れ子がキツい

SwiftSyntaxでコード整形ツール作ってみました。 https://github.com/kishikawakatsumi/swiftfmt 例によって完璧には遠いんですけどまあまあ動きそうな感じ。ただもっとキレイに実装できそうなのと、将来的にはSwiftSyntaxのデータ構造のまま扱えるようにしたいのでどこかの時点で書き直すと思います。

kishikawakatsumi/swiftfmt

swiftfmt - Format Swift code

2

昨日==だけが定義されてたコードはSwiftSyntaxの https://github.com/apple/swift/blob/master/tools/SwiftSyntax/Syntax.swift#L157-L160 この部分です。

[SwiftSyntax] Make Syntax nodes structs instead of classes by harlanhaskins · Pull Request #14122 · apple/swift

swift - The Swift Programming Language

興味深いのは（もしかしたら変わるのかもしれないけど）乗算に使われる*と@available(*, unavailable, deprecated)の*はSyntaxの段階ではトークンとしては同じもの、String Interpolationの"...\(...)..."開きカッコはLeft parenthesisだけど閉じカッコはStringInterpolationAnchorっていう特別なトークンだったということ。 (edited)

Syntax が protocol になったのが最近 https://github.com/apple/swift/pull/14122 で、 != が必要になった人が今までいなかっただけだと思います。

This patch, more in line with how I hoped we could structure the API, moves from a class-based model with Syntax as a superclass to a protocol-based model where each struct conforms to Syntax. This...

これSyntaxがEquatableじゃないのは

8:29 AM

FooSyntaxとBarSyntaxを比較するからか

Syntax を existential として扱いたいからだと。

中身が===なのも面白いな

8:32 AM

ExistentialをProtocolに適合させるようなサムシングが欲しくなってくるな

8:33 AM

そうするとExistentialがProtocolのまま表記されてるのがconfuse過ぎて死ぬか。

libswiftSwiftSyntax.dylib はXcode 9.3 betaに入ってないのね。リリース版にも入らないのかな？

swift-4.1-DEVELOPMENT-SNAPSHOT-2018-02-22-aとかには入ってるのに。

あら、9.3で確かめようと思ってHighSierraにする準備をしてたのに。

11:04 AM

File Vaultの解除に１週間くらいかかった。

READMEに Swiftfmt requires Swift 4.1 toolchains. って書かれてるけど、swift-4.1-branchではなくmasterのスナップショットが必要ぽい？>swiftfmt

swiftfmtはtrunkのスナップショットがいります。

11:06 AM

README直し忘れですね。ちょっと前に作ったものからコピーしたので。

11:06 AM

4.1snapshotとtrunkのsnapshotでだいぶ機能が違うんですよね

11:07 AM

対応してるシンタックスがダンゼン多い。

11:07 AM

最初は4.1snapshotで作ってたのでlibSyntax自体は使えると思うんですよね。Xcode 9.3

linuxだとswift-4.1-DEVELOPMENT-SNAPSHOT-2018-02-22-aにも入ってないぽい。

-emit-syntaxがあるならSwiftSyntaxはそれをデコードしてるだけ。

11:08 AM

swiftc -frontend -emit-syntax fileって失敗します？ (edited)

/Users/norio/github/swiftfmt/Sources/swiftfmt-core/AlignmentFormatter.swift:9:8: error: no such module 'SwiftSyntax' import SwiftSyntax ^

11:09 AM

swiftc -frontend -emit-syntax は動きます。

なるほど。libSwiftSyntaxがないのかな。

無いです。

そうなんですね。

11:11 AM

実は4.1スナップショットだとちょっと辛かったので-emit-syntaxを自分でデータ構造に変換したバージョンとかあるのでそれならもう少し幅広く使えますね。 (edited)

Swift 4.1には標準でswift formatってのが含まれてるぽい。

$ TOOLCHAINS=org.swift.4120180222a swift format --help OVERVIEW: Swift Format Tool USAGE: swift [options] <inputs> OPTIONS: -help Display available options -in-place Overwrite input file with formatted file. -indent-switch-case Indent cases in switch statements. -indent-width <n> Number of characters to indent. -line-range <n:n> <start line>:<end line>. Formats a range of lines (1-based). Can only be used with one input file. -o <file> Write output to <file> -tab-width <n> Width of tab character. -use-tabs Use tabs for indentation.

これ4.1からだったのか。もっと前からあるもんだと思ってました。

あいや、Xcode 9.3には含まれてないぽい。

swift-formatの仕組み自体はもっと前からあったけど、シンボリックリンクがちゃんと作られる様になったのが4.1からぽい？

SILに詳しい人に質問です。この記事の Eq.sil ケースをコンパイラへの最適化フラグ (-O) ありなしで結果が変わるのは、!= オペレータの関数を実行するために一時的に使用する値にわざわざalloc_stack使う必要ないという最適化が効いているからですか？ https://qiita.com/Kuniwak/items/cbf6b88db249838895b5#補足-最適化をしない場合の比較 (edited)

Swift のパフォーマンス比較を正しくできますか？ SIL で知るパフォーマンス比較 - Qiita

Swift におけるパフォーマンス比較を、nil 判定を例に解説します。なお、パフォーマンスを比較する上で、コンパイル時の最適化[^1]の様子を観察することはとても重要です。この記事では、最適化の様子を中間生成物を通して観察する方法に...

予想ですけど、インライン最適化とSSA依存解析で、右辺値の構築が削除されるのではないでしょうか

10:12 AM

https://ja.wikipedia.org/wiki/静的単一代入

%E9%9D%99%E7%9A%84%E5%8D%98%E4%B8%80%E4%BB%A3%E5%85%A5

10:13 AM

「ある計算の答えを出すために必要な事前の計算は何か？」というのがグラフ構造にできるんですけど、それをやる前処理として変数を削除して定数だけにした形式のSSA があって、SILはSSAなのでそうした最適化も入っているはずで

10:14 AM

!= の実行の部分をインライン展開すると、最終的に、比較してる右辺を組み立てる部分グラフが完全に要らないってことが

10:14 AM

解析できるはず・・・

10:16 AM

正確な答えを知るためにはコンパイラの中の最適化を有効化する部分をちょっとずつ減らして（LLVMライブラリが最適化の機能ごとにセットアップできる設計になっているから）どれを入れてくと最終的に同じ状態まで最適化される、というのを調べないといけなそう

これがSSA依存解析なのか。SSAは未使用の変数を探すぐらいに使うものだったと思ってたけど、コントロールフロー内の部分グラフにも適用できるんですね。完全に勘違いしてました...

細かいところで、依存解析をすると、計算の順序を入れ替えられる場所が見つかったりします。 (たとえば a + 1 == b + 1 の両辺はどっちから構築しても同じ結果になる) それで、メモリ上の変数の値は一度レジスタに置かないと計算ができないんで、命令の順番を入れ替えてなるべくレジスタに同じ値を長くおいておければ、メモリへの退避書き込みと読み出しの回数を減らせて早くなるとか、そういう話を聞いたことがあります (edited)

10:24 AM

あ、でもこれはCPUに依存した話だからLLVM-IR以降のアセンブラ生成時の最適化だからSILは関係ないですね

それって定数伝播・畳み込みというやつですか？

↑のwikiのページだと「レジスタ割り付け」ですね

これがレジスタ割り付けか

定数伝搬と畳込みは、定数式をコンパイル時に事前に計算しちゃって、その計算結果をちょくせつコードに埋めておく

10:30 AM

あ、でも、そうか、右辺側のnilは定数ですね。

なるほど、だからレジスタ割り付けはSILの最適化の説明には出てこないのか。今このへんのコンパイラ最適化の手法について勉強中でまだはっきりと違いが分かってなかったので、雰囲気だけ分かりました

僕も雰囲気しかわかってないです

コンパイラの本読んで出直して来ます。まだまだSILOptimizerのGeneric specializationに辿り着くまで先は長い... Guaranteed optimizationsだけでも難しい

最適化は一つ一つが個別のトピックだから大変そう・・・　Guaranteed optimizationsってなんですか？

-emit-silgen から -emit-sil の間です。 https://github.com/apple/swift/tree/master/lib/SILOptimizer/Mandatory

https://github.com/apple/swift/blob/master/docs/SIL.rst#guaranteed-optimization-and-diagnostic-passes

swift - The Swift Programming Language

10:47 AM

-emit-silgen から -emit-sil の間です。

んー、ちょっと違うか。とにかく -Onone でも実行されることが保証されている SILOptimizer のパス群。 (edited)

swift - The Swift Programming Language

ああ、なるほど、絶対やるって意味でGuaranteedか

このドキュメントで見ました！ Rintaro大先生がおっしゃってるように -Ononeでも走る最適化です

10:49 AM

そうそう

10:51 AM

こっちは逆に -Ononeの時は実行されないはず https://github.com/apple/swift/blob/master/docs/SIL.rst#general-optimization-passes

https://github.com/apple/swift/blob/master/lib/SILOptimizer/Transforms/SILMem2Reg.cpp#L13-L17

swift - The Swift Programming Language

1

10:51 AM

いやものによるのかな

最適化の過程dumpしてみました、上のalloc_stackが消えてる件はMem2RegってPassっぽいですね〜 https://gist.github.com/ukitaka/b7f554b1ba99a93c0808a2a2effc7b48#file-eq-sil-swift-L1060-L1183

Eq.sil

このPass探してたところです！ありがとうございます。

もしかしてこれが-Oの時に走るMemory Promotionのことなのか

おおおパスごとにダンプできるのか〜

"This pass promotes AllocStack instructions into virtual register references." なるほど、そうっぽいですね

11:13 AM

Swiftの中間言語SILを読むその4 - sil_optコマンドの使い方

swift - The Swift Programming Language

このPassは面白いなー。最適化って感じする

LLVMにも最適化フェーズでmem2regあるんですね https://peta.okechan.net/blog/archives/3019

peta_okechan

7.3. LLVMにおけるメモリ

https://blog.waft.me

iOS開発とかのメモ

5:47 AM

@ukitaka さんの進捗がすごい進んでた

最近ちょいちょいやってますね

最適化の個別のパスごとに実行できる仕組みが整っているんですね、たしかにユニットテスト作るためにこういう機構が用意されてるはずなんですねえ https://blog.waft.me/2018/02/02/swift-sil-4/ (edited)

特定の最適化Passのみを有効にする術を見つけたのでメモ。

ですね〜だいたいこれを使ってテストケース走らせてみてどんなことやってるか雰囲気掴みつつ勉強してます

swiftc -emit-silとswift -frontend -emit-silで出力違うの知りませんでした...

protocol Animal { func speak() } func callSpeak<T: Animal>(_ t: T) { t.speak() } class Cat : Animal { func speak() { print("nya") } } let cat = Cat() callSpeak(cat)

4:56 AM

↑ -Osize でスペシャライズ版が生成されるかどうかを調べるために、そもそも -O でスペシャライズすることを期待したが、うまくいかなかった・・・

4:56 AM

CC: @kitasuke

メモ: struct にしたら出来た

protocol Animal { func speak() } func callSpeak<T: Animal>(_ t: T) { t.speak() t.speak() t.speak() t.speak() t.speak() t.speak() t.speak() t.speak() t.speak() t.speak() t.speak() t.speak() } struct Cat : Animal { func speak() { print("nya") } } let cat = Cat() callSpeak(cat)

5:08 AM

t.speakが1回だとスペシャライズされない

structだとされる、final classだとされる、classだとされない

5:31 AM

あ、で、 -Osize にしても callSepak T == Cat のspecializeは発生した。

5:32 AM

一方、specialized callSpeak where T: Animal とか一部が削除された。

型パラ持ってる型も同じ雰囲気で実装増やせば最適化されるのかな？

今やってみたけどできなかった

8:07 AM

a

8:09 AM

// specialized SpeakInvoker.invokeSpeak() sil shared @_T01a12SpeakInvokerC06invokeA0yyFAA3CatV_Tg5 : $@convention(method) (@guaranteed SpeakInvoker<Cat>) -> () {

8:09 AM

でてきた

それできてなかったら前にgybで生成したスペシャライズ用の大量のメソッドが全くの無駄になる所だったので危なかった。

https://gist.github.com/omochi/07dc59b0ab616d382b5530f8ea6991ee

swift-specialize-test.swift

やっぱそうかーーー

8:12 AM

それができればな

@t.ae のやったやつって @_specialize(where T == Int) ではだめなんだっけ

できるか試してないんですよねそれ

8:15 AM

モジュール跨いでどうなるかが分からなかったり

なるほど

あとinlinable来るなら待とうかなと

inlineableはインライン化だから特殊化とかまた違う気が

あれ？何か混ざってますね……

特殊化の標準仕様化の提案はまだ無いはず

インライン化は関数呼び出しのオーバーヘッドが無くなるやつ

インライン化の過程でジェネリクスはどうなるんでしたっけ？多分その辺で混同しちゃったんだと思うんですが

スペシャライズはGenericsパラメータのメソッド呼び出しのテーブル参照がなくなる方

8:31 AM

witnesstableの参照はインライン化しても残ってる、気がする

そうだね

8:31 AM

// specialized SpeakInvoker.invokeSpeak() sil shared @_T01a12SpeakInvokerC06invokeA0yyFAA3CatV_Tg5 : $@convention(method) (@guaranteed SpeakInvoker<Cat>) -> () {

8:32 AM

↑の方見ればわかるけど、SpeakInvoker<T>のTがCatであることが確定した状態のメソッド実装が生成されてるから、TへのアクセスでCat前提のロジックになるからディスパッチが一個減る

8:33 AM

ただCat is Animal(protocol) のwitness呼び出しのディスパッチはその中で発生する

それなー

8:33 AM

そこがなんとかなればもう一段加速出来るんやが

8:33 AM

今はまだ

後段のcallSpeakもスペシャライズされたのができるとかじゃなかったですっけ何か根本的に認識が誤ってる気がしてきました (edited)

t.ae のシナリオは型パラメータに protocol制約がかかってないんじゃない？

ああ、いまcallSpeakは別の話でしたね

 %3 = open_existential_addr immutable_access %2 : $*Animal to $*@opened("5DF3A8B4-1D27-11E8-8379-DCA9048BCDF8") Animal // users: %5, %5, %4 %4 = witness_method $@opened("5DF3A8B4-1D27-11E8-8379-DCA9048BCDF8") Animal, #Animal.speak!1 : <Self where Self : Animal> (Self) -> () -> (), %3 : $*@opened("5DF3A8B4-1D27-11E8-8379-DCA9048BCDF8") Animal : $@convention(witness_method) <τ_0_0 where τ_0_0 : Animal> (@in_guaranteed τ_0_0) -> () // type-defs: %3; user: %5 %5 = apply %4<@opened("5DF3A8B4-1D27-11E8-8379-DCA9048BCDF8") Animal>(%3) : $@convention(witness_method) <τ_0_0 where τ_0_0 : Animal> (@in_guaranteed τ_0_0) -> () // type-defs: %3

8:37 AM

これってCatがstructなんだから呼び出し削除できそうだけど・・・

できてほしいよね〜〜〜

8:38 AM

わかるわ〜〜〜

コントリビューションチャンス

一ヶ月ぐらいここでハマってたから死ぬほどわかる

ast

8:44 AM

改行が消えちゃった

破壊した

@tarunon http://twitter.com/ukitaka_/status/969385860532617216

ukitaka (@ukitaka_)

@omochimetaru まだちゃんと追ってないんですけど、witness_methodのdevirtualize自体はあるはずなんでこのケースは最適化されてもおかしくないんですよね〜class_methodの場合はupcast命令辿っていってインスタンスがわかれば直接呼び出しになりますし、同じようにできるような気はする https://t.co/ANCH4PKgll

なに

昨日の17:35のやつ

この辺ですね https://github.com/apple/swift/blob/master/lib/SILOptimizer/Utils/Devirtualize.cpp#L725-L774

Swiftの中間言語SILを読むその3 - class_methodのDevirtualization

swift - The Swift Programming Language

https://blog.waft.me/2018/01/31/swift-sil-3/ ←この記事で vtableのdevirtualizeの解説がされてるから

最近は別のことをやっていてあまりSwiftに触ってなかったのだけど、気分転換に最適化を1つ読んでみる。

1:51 AM

これを参考にwitness tableのdevirtuaizeの実装を読んだり、ユニットテストを見たりすれば

関数は出来るけど型はまだ難しそうっていうのが

なんかいけるきがする

だから関数の実装を型の方に持ってくると

1:51 AM

コントリビュートチャンスなわけだ

さっきのケースなら型については T= Catはもう解決してるから

1:52 AM

Cat is Animal Protocol のスコープローカルな upcast なので、↑の記事で書かれてるupcast stripping で同じようにできそうなんよな (edited)

それさ

1:53 AM

単一の関数内で出来るのは理解できるんだが

1:53 AM

ある型に含まれるプロパティについて

1:53 AM

同じようにできるという直感が生まれないんだ

1:53 AM

なんか引っかかりが有る

すでにinvokeSpeakはT=Catについてspecializeされてるから

1:54 AM

更にその中で単一の関数としてやるだけじゃ？

それは関数の話だよね?

うん

Invoker<A: Animal> みたいな型があって

1:54 AM

そのプロパティが let animal: A で、その中の関数でanimal is Catをスペシャライズ出来るのか?っていうのが

1:54 AM

まだわかってない

あ〜

1:55 AM

animalはあくまでself.animalなのが違うってことか

そう

1:55 AM

その最適化は、関数レベルじゃなくて

たしかに、再代入されてたり、オーバライドで返る値が変わる可能性があるな？

型のレベルでメモリサイズも含めて最適化しないといけない気がしていて

1:55 AM

ちょっと難しいですね感

いや、ないか、struct Cat だから

1:56 AM

でもたしかに最適化パスが適用されないのはそこの違いがありそう

1:56 AM

で、一般のgetterの場合はオーバーライドがあるから駄目だわ

1:57 AM

もしかしたらそこが未実装なんじゃない？今回のケースはそれでもstruct Catだから他の可能性はないはず

口頭で話したまとめ self.animal は T としてBox(: Animal)された型で保存されてるはずだから、たとえ T == Cat に specialize されたメソッドの中であっても、self.animal を読む時は Cat 型としては取り出せない実際SILを見ても取り出されてる型は Animal existential で、そこからopenするから Cat は介入してない (edited)

2:36 AM

これを解決するためには Box<Cat> が生成されてないといけない

@rintaro +0 系のコミットってこれが最初ですかね？タグがブレててよくわからない・・・ https://github.com/apple/swift/commit/503db5fc653c92c350d302ac8a771ee9d38bf65e

[all-+0] Add the ability to toggle the "normal parameter convention" … · apple/swift@503db5f

…of DefaultConventions to guaranteed. This is implemented by introducing an enum called NormalParameterConvention, enum class NormalParameterConvention { Owned, Guaranteed }; When one construc...

3:35 AM

https://github.com/apple/swift/pull/13024

Normal Guaranteed Argument Support by gottesmm · Pull Request #13024 · apple/swift

This PR contains support for enabling via the frontend option enable-guaranteed-normal-arguments for normal parameters to be emitted at +0 instead of +1. rdar://34222540

3:36 AM

このPRからっぽいかな・・・

タグはブレてるけど rdar://34222540 でも追跡できそう

class My { func get() -> Int?? { return 1 } } class MyMy: My { override func get() -> Int? { return 2 } } MyMy().get() おもちと議論しててOptionalのアレを見つけてしまった cc @koher @rintaro

これはひどい・・・

3

改めてみたら説明が足りなすぎる ↑のコードはオーバライドできない、ってコンパイルエラーになる。でも、もし親が Int で子が Int? ならオーバライドできるので、法則が乱れてるね、という話です (edited)

https://bugs.swift.org/browse/SR-7111

@rintaro もう帰りましたか？

いますよ。畳エリア。

protocol AppViewController { var disposeBag : DisposeBag { get } } extension AppViewController where Self : UIViewController { } // OK extension UIViewController where Self : AppViewController {} // NG

こういうもんだっけ。難しい。

あるある

ヒラリ術を使うと protocol AppViewController where Self: UIViewController { var disposeBag: DisposeBag { get } } って宣言できる

9:40 AM

いつから出来るようになったか知らない

あ、そうやるのか、thx

↑それでもextension内で例えばself.viewをいじろうとしたらselfはletだから書き換えられないよ〜〜〜みたいなことを言われたのでprotocol ~~~ class where: UIViewController にしたよ

9:41 AM

class無くてもself.view書き換えられてほしいけど

VCの.view書き換えはちょっと野蛮じゃないか?

あいや

9:42 AM

addSubviewも怒られた気がする

マジ?

9:42 AM

それはいけた気がする

mutating扱いなのかな？とか思ったけど勘違いかも。

フーム

viewじゃなかったかも。titleとかだったかも。

それはありそう

とにかくselfはletのconstantだから書き換えられませんって言われてclassを足したのは確かだと思う

AppViewControllerのextension funcでself.view = nil かいてもコンパイルできた

野蛮だ

class ナシでも？

9:46 AM

あれー

うん

かしこい

where付ける前の事なんじゃない？

じゃーなんか勘違いしてたかなあ

9:46 AM

うーん。そうかも。

9:46 AM

わすれてくれ

わすれた

チャンミス

Xcode 9.3 beta 4で-Ouncheckedが無くなって-remove-runtime-assertsってのが出来た？

ほほう

SWIFT_DISABLE_SAFETY_CHECKS=YESで-remove-runtime-assertsがつく (edited)

↓の UnsafeMutablePointer を UnsafePointer 型の引数に渡せるのってなんでなんでしたっけ？ var a = 42 let p = UnsafeMutablePointer(&a) func foo(_ p: UnsafePointer<Int>) { print(p.pointee) } foo(p)

2:58 PM

↓これはできないのに。 let p2: UnsafePointer<Int> = p

暗黙のアップキャスト

2:59 PM

関数呼び出しの引数部分に関して

2:59 PM

UnsafePointer族にはいろんな変換がある

UnsafePointer 系に特有の言語仕様？

一般のアップキャストじゃなくて引数評価時だけの特別なやつ

3:00 PM

はい StringはUnsafePointer<CChar>になったりしますよ

なるほど。ありがとう

https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-ID146

1

https://talk.objc.io/episodes/S01E90-concurrent-map に出てきたconcurrentMap

extension Array { func concurrentMap<B>(_ transform: @escaping (Element) -> B) -> [B] { var result = Array<B?>(repeating: nil, count: count) let q = DispatchQueue(label: "sync queue") DispatchQueue.concurrentPerform(iterations: count) { idx in let element = self[idx] let transformed = transform(element) q.sync { result[idx] = transformed } } return result.map { $0! } } }

これq.sync {}を使う必要なかったりしないのかな？ 間違った実装を引用していたのを修正 (edited)

Concurrent Map

We implement a concurrent version of the map method for arrays.

transformを外でして、result[idx]に詰めるとこだけsyncの中でよさそうな気はします

ああ、間違った実装のものを引用してました。

1:14 AM

修正しました。

1:16 AM

で、やっぱりq.sync{}は必要なかったりしないのかな。 subscriptセットはmutableだから実装がどうなっていようとも排他処理するべきなのかな。

Arrayのsubscriptアクセスは排他処理しないといけないです

1:35 AM

OwnershipManifestoに、ハマりポイントとして引用されてますｗ

OwnershipManifesto通りだと、subscript getも排他処理しないといけないような。

The most important consequence of this is that two different array elements cannot be simultaneously accessed.

はい、そう思います

Arrayの代わりにUnsafeMutableBufferPointerとか使えば排他制御不要？

extension Array { func concurrentMap<B>(_ transform: (Element) -> B) -> [B] { var result = ContiguousArray<B?>(repeating: nil, count: count) return result.withUnsafeMutableBufferPointer { buffer in DispatchQueue.concurrentPerform(iterations: buffer.count) { idx in buffer[idx] = transform(self[idx]) } return buffer.map { $0! } } } }

ContiguousArrayに変更 (edited)

そうですね

そうか、Arrayの場合 q.sync {} が無いと cow が起きてしまうのか。

はい、中でいろいろとロジックが。

struct S { class C { init() {} } var c = C() } var s = S() DispatchQueue.concurrentPerform(iterations: 100) { idx in print(s) // `s`を使うとnot uniqueになる。 if !isKnownUniquelyReferenced(&s.c) { print("not unique") } }

(edited)

syncなしはこうなった。

extension Array { func concurrentMap<B>(_ transform: (Element) -> B) -> [B] { var result = ContiguousArray<B?>(repeating: nil, count: count) return result.withUnsafeMutableBufferPointer { buffer in DispatchQueue.concurrentPerform(iterations: buffer.count) { idx in buffer[idx] = transform(self[idx]) } return buffer.map { $0! } } } }

https://forums.swift.org/t/unit-tests-on-windows-windows-state-part-ii/10732

Unit Tests on Windows (Windows State Part II)

The standard library and the compiler is now fully buildable on Windows against just the Windows SDK. In order to ensure that we flush out all the issues and ensure that we don’t regress in the future, the next large goal is to get the full test suite working on Windows as well. I have part of the tests working already. The last run with a number of my changes has us at around 80%, though I would like to decrease the number of unsupported tests (but that requires investigation into why they a...

3:03 AM

swift標準ライブラリがwindowsでビルドできるようになったそうな

3:07 AM

この辺の作業ず〜っとこのコンプナードさんとトーマスさんがやってたんだけど

3:07 AM

C++コンパイル通すところまでは良いとして

3:08 AM

Windowsのlibファイルとかdllファイルにどうやってバイナリを入れていくか、みたいな議論があって

3:08 AM

なるほど全くわからんという感じだった

先週ここで話してた@inlineableとスペシャライズの話ですけど、改めてプロポーザル読んでみたらそもそもタイトルからスペシャライズって書いてあった。 https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md

Returns Xcode.Project from generate() by giginet · Pull Request #1517 · apple/swift-package-manager

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

3:22 AM

The name @inlinable is somewhat of a misnomer, because nothing about it actually forces the compiler to inline the declaration; it might simply generate a concrete specialization of it, or look at the body as part of an interprocedural analysis, or completely ignore the body. However, nothing seemed to read as well as @inlinable.

specializeももちろん関連するけど

3:24 AM

inlineableはモジュール呼び出し側がインライン化できるように、ソースコード（AST?)をライブラリに（見えないバイナリとして）埋め込んで、

3:24 AM

呼び出し側が呼び出しコードを自分のモジュール内に生成するという話で

3:24 AM

もちろんコードが外から見えるようになるのでスペシャライズにも使えるんだけど (edited)

3:25 AM

specialize修飾子のほうは、モジュール跨ぎとかじゃなくて、そのモジュール内でコンパイルする時に、ジェネリックパラメータを具象化したバージョンを生成するって

3:25 AM

いう、コンパイラ命令な気がする。

3:26 AM

それとも、specializeは不要になって、inlieableでのAST公開と、ユーザサイドでの特殊化した版の生成だけに

3:26 AM

一本化するというアプローチもあるのかな・・・？

3:26 AM

(C++はそういう言語やね)

先週の文脈だと、僕のコードが手書き特殊化オーバーロードをたくさん用意してるって話だったのでそれをそのまま再現するなら@_specializeで書くのが正しいですね。

うん、あーあと、ジェネリッククラスの特殊化は、また別な気がする。

including full and partial specialization of generic functions

クラスは対象外かも？

今ってそれはコンパイラもやってない気がするんだよね。

3:30 AM

taeの手動生成は型をまるごと書き出してるから、クラスが別に生成されて、stored propertyの型も T じゃなくて具体型なので

3:30 AM

そこが一番パフォーマンスに効いてるはず

そうですね。そこが効かないなら中途半端になってしまいそう

ジェネリックなTに入れるところでboxingされちゃうオーバーヘッドがどうやら大きいよ。 (edited)

3:32 AM

そういえばコンパイラ生成のExistentialは24バイトで小さい値型ならスタック化できてるけど、TはAny等価なアプローチな気がするな

3:33 AM

落ち着いたらIRGenを見てみたい。

この前SPMにだしたPR、LGTMされたけど、この人はコミッターではないｗ？ https://github.com/apple/swift-package-manager/pull/1517 @ikesyo

Motivation I'd like to test generated Xcode Project on XcodeprojTests. Currently, Xcodeproj.generate returns only its path. So we can't investigate contents of the project. Description I refactored...

https://github.com/apple/swift-package-manager/commits?author=ViktorSimko

https://swift-ast-explorer.kishikawakatsumi.com/

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

5:04 AM

コミット無いね

5:05 AM

コミット権無くてもReviewsの欄に入れたのか。

なるほど･･････

spmはあまり活発じゃないのかな・・・？

6:43 AM

勝手にApprove出来る気がする

Swift AST Explorer

6:55 AM

^ ちょっとパワーアップして、libSyntaxの出力と元のソースコードの対応がわかる機能をつけた。

6:56 AM

libSyntaxで何か作ろうという時に結構便利になった気がする。

早くenum実装しろよ。っていう圧力かと思いました

これは単純にサンプルが悪いです。。。

けど素晴らしい！

空白やコメントがlibSyntaxの出力に残っていて、かつこんな風にトークンの前後にくっついている、という部分を撮ろうと思って、あまりSyntaxのノード名は気にしてなかったです

(edited)

たしかに。API使う時に、どういうのが来るのか試して確認するのめんどいから便利そう。

いや、これはねえ正直に言ってめっちゃ便利ですよ。

1

7:02 AM

しかしWebのUIを作るのは難しいですね。UI作るのSwift側の10倍くらい時間かかった。PR歓迎なので得意な人手伝ってほしいです。

@omochimetaru >> Arrayの代わりにUnsafeMutableBufferPointerとか使えば排他制御不要？

そうですね

これって何がソースですか？

@koher https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md

Remove DispatchQueue.sync from Array.parallelMap by norio-nomura · Pull Request #2090 · realm/SwiftLint

swift - The Swift Programming Language

8:08 AM

Subscripts Much of this discussion also applies to subscripts, though in the language today subscripts are never technically stored. Accessing a component of a value type through a subscript is treated as accessing the entire value, and so is considered to overlap any other access to the value. The most important consequence of this is that two different array elements cannot be simultaneously accessed. This will interfere with certain common idioms for working with arrays, although some cases (like concurrently modifying different slices of an array) are already quite problematic in Swift. We believe that we can mitigate the majority of the impact here with targeted improvements to the collection APIs.

8:09 AM

↑このセクション自体にはUnsafePointerを使えば良いとは書いてないですが

8:11 AM

大丈夫だとわかっているから排他則とか無視したい場合には究極的にはUnsafePointerを使えばいいよただしなるべく保護の元でいろいろできるようにしていきたいねみたいな話が書いてあります

8:11 AM

一般的な話として。

8:12 AM

あーあとは、 Rust のsubscriptなら要素がメモリごとにわけて配置されて相互に干渉しないけどSwiftのArrayはcomputed propertyでしかないのでそういう保証はやりようがない、みたいな話が合わせて書いてあるので

8:13 AM

逆説的に、メモリごとへの直接的なアクセスがコントロールできるならそういう事もできる、と理解しました。（これによらずとも、C/C++で一般的な事)

8:14 AM

あ、もちろん、UnsafePointerの同一アドレスへのアクセスは排他が必要ですよ。

8:16 AM

ウーンそういう意味ではどこに書いてあるというよりCプログラミング的な基礎知識という感じもしてきました。

SwiftLintに入れました>UnsafeMutableBufferPointer使った実装。 https://github.com/realm/SwiftLint/pull/2090

DispatchQueue.sync was required to avoid CoW on calling subscript from multiple copied instances of Array. Since UnsafeMutableBufferPointer does not cause CoW on same situation, DispatchQueue.sync ...

この場合、排他制御が無いとどうなるかを知る方が早いかな。

12:12 PM

import Foundation let count = 10000 var array1 = [Int?](repeating: nil, count: count) DispatchQueue.concurrentPerform(iterations: count) { idx in array1[idx] = idx } print(array1.flatMap({ $0 }).count == count) // false var array2 = [Int?](repeating: nil, count: count) let queue = DispatchQueue.init(label: "test") DispatchQueue.concurrentPerform(iterations: count) { idx in queue.sync { array2[idx] = idx } } print(array2.flatMap({ $0 }).count == count) // true

なるほど、queueで縛らないと詰め漏れが出てきちゃうんですね [Optional(0), Optional(1), Optional(2), Optional(3), Optional(4), nil, Optional(6), Optional(7), nil ...] (edited)

なんでそうなるんだろうなあ

1:25 PM

内部でストレージオブジェクトの参照カウントが2になって、コピーが起きて、コピー前のストレージに書きこむスレッドの作用が捨てられる？

1:26 PM

もしそのようなコピーが起きてるならその意味でもめちゃ効率悪い

ああ、排他制御不要ってスレッドセーフって意味かと捉えてたけど、マルチスレッドの話じゃなくてオーナーシップの話で、しかも「不要」というのはセーフの意味じゃなくてアンセーフを前提としてるってことか。

内部でストレージオブジェクトの参照カウントが2になって、コピーが起きて、コピー前のストレージに書きこむスレッドの作用が捨てられる？

そう。

正確には、コピー後のストレージに書き込まれてコピー後のストレージごと捨てられる。ですね。

あ、前と後だとそうですね、元と先が言いたかった。

この結果を見ると、isKnownUniquelyReferenced()って排他制御が無いとあてにならない？

import Foundation struct S { class C { var name: String init(name: String) { self.name = name print("init: \(name)") } deinit { print("deinit: \(name)") } } var c: C init(name: String) { c = C(name: name) } var name: String { get { return c.name } set { if isKnownUniquelyReferenced(&c) { print("unique: \(c.name) -> \(newValue)") c.name = newValue } else { print("not unique: \(c.name) -> \(newValue)") c = C(name: newValue) } } } } var s = S(name: "初期値") let queue = DispatchQueue(label: "keep unique") DispatchQueue.concurrentPerform(iterations: 10) { idx in // queue.sync { s.name = "\(idx)" // } } print(s.name)

init: 初期値 unique: 初期値 -> 0 unique: 初期値 -> 1 unique: 初期値 -> 2 unique: 初期値 -> 3 unique: 1 -> 4 unique: 1 -> 5 not unique: 5 -> 6 init: 6 deinit: 5 unique: 6 -> 7 not unique: 6 -> 8 init: 8 not unique: 7 -> 9 init: 9 deinit: 7 deinit: 8 9

(edited)

おーバグりまくる

なるほど https://github.com/apple/swift/blob/master/docs/ARCOptimization.rst#copy-on-write-considerations

https://github.com/apple/swift/pull/13788

swift - The Swift Programming Language

3:02 PM

1. An operation taking the address of a variable is allowed to replace the reference held by that variable. The fact that is_unique will not actually replace it is opaque to the optimizer. 2. If the refcount is 1 when the reference is replaced, the referent is deallocated. 3. A different source-level variable pointing at the same referent must not be changed/invalidated by such a call. 4. If such a variable exists, the compiler must guarantee the refcount is > 1 going into the call.

IRGen support for coroutines by rjmccall · Pull Request #13788 ·...

Implement basic IRGen support for coroutines and enough optimizer support to actually generate optimized and unoptimized code from the SIL test cases in this patch. Optimization seems to break it s...

3:48 PM

コルーチンの下回り進んでた

コルーチンって正式な Proposal になってないけど、表面的なシンタックスは別として何かしら導入する方向なのは既定路線ってことなのかな？

そう見えますね

それは楽しみだ。 Swift 5 は無理かなぁ？

5はしばらく来なくて4.Xを引っ張る気がする

年 1 回メジャーリリースする方針なわけではないのか。

リリースサイクル的な話はなかった気がするなあ

最近、 inout 的に @escaping なクロージャ式の中からアクセスできないようにするけど、特に out したいわけじゃないというのを表せるものがあればいいんじゃないかという気がしてるですがどうでしょう↓の asyncAfter のクロージャ式から p にアクセスするのを防ぎたい。

import Foundation func foo() { let a = [2, 3, 5] a.withUnsafeBufferPointer { p in DispatchQueue.global().asyncAfter(deadline: .now() + .seconds(3)) { print(p[0]) } } } foo() Thread.sleep(forTimeInterval: 5)

エスケープさせたくないってことですか？

↑だと a が解放された後にそのバッファのポインタ p にアクセスしちゃってるよね？

そうですね、これはだめ

↓だと inout だからコンパイルエラーになる。

import Foundation func foo() { var a = [2, 3, 5] a.withUnsafeMutableBufferPointer { p in DispatchQueue.global().asyncAfter(deadline: .now() + .seconds(3)) { print(p[0]) } } } foo() Thread.sleep(forTimeInterval: 5)

あ〜、なるほど、inout的にってそういう意味か。

withUnsafeBufferPointer はクロージャに渡される引数がそのクロージャ式のスコープの中でのみ有効なのに、せっかく @escaping を区別してるのにコンパイラがそれを強制する術がない。 (edited)

え、もう一個のケースでも、pはinoutじゃないのでは？

1:53 AM

普通の引数で型がUnsafeMutableBufferPointerですよね

それが inout なんですよ。意味わかんないんだけど。

1:53 AM

あれ？違う？？

public mutating func withUnsafeMutableBufferPointer<R>(_ body: (inout UnsafeMutableBufferPointer<Array.Element>) throws -> R) rethrows -> R

1:54 AM

ほんとだ、あれ？なにこれ。

いや、あってた。

1:54 AM

https://developer.apple.com/documentation/swift/array/1538652-withunsafemutablebufferpointer

1:54 AM

なんで inout なのかもよくわかんないんだけど、とりあえずそれのおかげで↑の asyncAfter に渡すのはコンパイラが防いでくれる。

1:54 AM

で、この inout の out の除いたようなものがほしいなぁと。

1:55 AM

あと、↓みたいなのも防げるかと。

fooAsync { [weak self] in guard let zelf = self else { return } zelf.foo(...) barAsync { [weak zelf] in // ←この [weak zelf] を忘れないようにしたい guard let zelf = zelf else { return } zelf.bar(...) } }

クラッシャー

func after(_ fn: @escaping () -> Void) {} func with(_ fn: (inout Int) -> Void ) {} func test() { with { p in after { [p] in } } }

(edited)

@rintaro それは明示的だから仕方ないですｗ

2:08 AM

明示的にしかできなくできたらいいかなと。

ときどき話題に出てくるCodableとJSONの話で、JSON表現用の型とモデルの型をわけて・・・ってパターン、こうやると少し楽になると気づいた https://gist.github.com/omochi/dec3e819ec7a485e33d43bcdd0c0d84a

codable-inner-json.swift

assoctypeにtypealiasじゃなくてstruct定義でもいいんですね。言われてみりゃそりゃそうだって感じですけど使ったことなかった。

いや、これは暗黙的に推論されてると思う (edited)

メソッドのほうからかな？

そう

試そうとしたんですが最近playgroundsが開かない

7:51 AM

protocol Init { init() } protocol Proto { associatedtype JSON: Init } extension Proto { func hoge() -> JSON { return JSON() } } struct Hoge: Proto { struct JSON { } }

こう書いたらtypealias書けって言われますね

1

7:52 AM

あ、Hoge.JSONがInit適合してないからだ

してないかな

: Initつけたら怒られないですね

お、そこはそうだ

protocol Init { init() } protocol Proto { associatedtype JSON: Init } extension Proto { func hoge() -> JSON { return JSON() } } struct Hoge: Proto { struct JSON: Init, CustomStringConvertible { var description: String = "Hoge.JSON" } } print(Hoge().hoge()) // Hoge.JSON

7:54 AM

こうかな

7:55 AM

hoge()が挿入されて推論されるのかJSONが先にあるのか分からない (edited)

protocol Foo { associatedtype Bar } struct Piyo: Foo { struct Bar { } } ありゃ、これ通るから

7:56 AM

動きますね、すごい。昔はこれができなかったような気がします

ん？

それだけだとassoctypeのBarとPiyo.Barが同一視されてるか微妙だなぁと思ったんですが

え、結局、名前でマッチしてた？

そうっぽい

8:01 AM

@t.ae 同一視出来ていないとコンパイルが通らないのでこれはOKなきがします

あーない場合はtypealias無いって言われますねそういえば

8:01 AM

そんな基本的なことを忘れて長いコードを書いてしまった

本題どっか行った

encodeToInnerJSONの部分隠蔽できないんですかね

隠蔽とは？

UserCredentialをそのままJSONEncoderとかにわたせるように

なってるよ

8:04 AM

Codableだから

あれ？

8:05 AM

ああ一番上から来てるのか

そうか、エンコード・デコードのサンプルも書かないとだめだった。

@tarunon 完全にこれが欲しくなってきた https://forums.swift.org/t/automatically-derive-properties-for-enum-cases/10843

Automatically derive properties for enum cases

I wanted to circle back to this comment from @Joe_Groff: Has there been any recent discussion about this? I’d love for enums to be a bit more ergonomic via optional-chaining. Key path support would be a nice, free bonus! I can imagine it work...

12:48 PM

https://gist.github.com/tarunon/06e153b4e7c11630826eadcbd8f6462d ↑これの ifCase0 に相当するものを自動でつくる

ObservableEnumConvertibleExtensions.swift

わかる~~

この提案みたときは、そんなん必要なときにちょちょいと定義すればええやんけ、って思ったけど・・・

苦痛やろ

enumを、「A, B, C, Dのどれか」として使おうとしていて、

12:50 PM

Observableでもなんでもいいけど、モナドMにそのenumが入ってるときに

12:50 PM

M<A?> に簡単にmapしたいという需要はあるね

12:51 PM

enumそのまま制御してるときはswitch-caseでいいけど、ヨリ分けてその先別個に何かやるみたいなパターンがあるんだな。

なんかまだはっきりとわからないんだけど

12:58 PM

より分けてその先で使いたいパターンっていうのが

12:58 PM

本当にEnumである必要があるのか、について吟味したほうがいいかもしれない。

そこはそうだと思うけどねえ

@lovee こんなのできた

public func recover<R>(_ f: () throws -> R, ifError: (Error) -> R) -> R { do { return try f() } catch let error { return ifError(error) } } public func recover<R>(_ f: () throws -> R, ifError: (Error) throws -> R) throws -> R { do { return try f() } catch let error { return try ifError(error) } }

7:12 AM

この前言っていたguard + tryみたいなパターンは、R をOptional にして使えば guard let x = recover (...) else { return } の形で書けるし、２つめのオーバーロードを使えば、リカバリできないエラー型の場合はそのまま更に上まで飛んで行く。

7:13 AM

使用例

 guard let modelScene = recover({ () -> SCNScene? in try SCNScene(url: url) }, ifError: { error in self.handleError(error) return nil }) else { return }

ふむふむ、だいぶ長くなってしまうところ以外は良さげですね

うん、あとOptional推論がうまくいかないから明示しているんだよね

7:16 AM

名前ちょっと変えてかならず Optional になる仕様のほうが使いやすいかも

もしかすると ifError のところと最後のところの戻り値は Optional<R> にすべきだったり？

あ〜 recover 自体を try? でたたむ手があるな

7:20 AM

 guard let modelScene = try? recover({ try SCNScene(url: url) }, ifError: { error in self.handleError(error) throw error }) else { return }

できた

import SceneKit public func recover <R> (_ f: () throws -> R, ifError: (Error) -> Optional<R>) -> Optional<R> { do { return try f() } catch let error { return ifError(error) } } func test() { let url = URL(fileURLWithPath: "http://www.google.com") guard let _ = recover({ () -> SCNScene in try SCNScene(url: url) }, ifError: { error in print(error) return nil }) else { return } }

(edited)

これだと型ヒントは消せる (edited)

ファイル名対応してないんだDiscord

そのパターンでもクロージャの型ヒント消せそう。

7:22 AM

 guard let modelScene = recoverToOptional({ try SCNScene(url: url) }, ifError: { error in self.handleError(error) return nil }) else { return }

7:23 AM

行数短くしたいですねえ。

7:24 AM

guard let modelScene = recoverToNone({ try SCNScene(url: url) }, ifError: self.handleError) else { return }

よし、ここまで書けた

import Foundation public func recover <R> (_ f: () throws -> R, ifError: (Error) -> Void) -> Optional<R> { do { return try f() } catch let error { ifError(error) return nil } } struct Test { let url: URL enum InitError: Error { case unknown } init(urlString: String) throws { guard let url = URL(string: urlString) else { throw InitError.unknown } self.url = url } } func test(_ string: String) { guard let test: Test = recover({ return try Test(urlString: string) }, ifError: { print($0) }) else { return } print(type(of: test)) } test("http://www.google.com") // Test test("") // unknown

try TEst のところのreturnいらなそう

7:34 AM

僕はそのrecoverはrecoverToNoneって名前にした

まあ1行だけならね

nits 第一引数に @autoclosure つけるといいかも

↑を読みながら @autoclosure が良さそうだなと思って最後まで読んだら先に言われてた

autoclosureもありだけど個人的には何が起きてるかわかりにくくなりそうなので微妙だなあ

用途を考えると single-expression closure になることが多いだろうからまさに @autoclosure の出番だと思うけどなぁ。

まあ特に標準提案したいというほどの気持ちは無いのでお好みで (edited)

多分なんですが

8:19 AM

throwsの値を使って何かするみたいなfunction書くときはそもそもそれをthrowsにして、非throwsとの境界をそこに設定するのが良いのではと思った (edited)

8:21 AM

func doSomething() { return try? doSomething() ?? /* 何か */ } func doSomething() throws { let x = try throwableFunc1() let y = try throwableFunc2() ... }

こんなイメジ

↑それだとtry?でnilになるから「throwsの値」(飛んでくるエラーオブジェクトの事だよね)が使えない

あーー

10:23 AM

ハマり

10:23 AM

たしかにそうだ

エラーを使いながらもthrow伝搬を止めて値に畳み込みたいときに、簡単に書くことができないんだよね。do - catch だと式じゃないから式の中に埋め込めないし。 (edited)

https://twitter.com/__gfx__/status/974531889817006080 https://twitter.com/omochimetaru/status/974537101004832768 を見て func foo() -> Int { print("Int"); return 1 } func foo() { print("Void") } foo() // error: ambiguous use of 'foo()'

Rubyで「そのメソッドがvoid contextで呼ばれた否か」がとれるといいんだが…（Perlだととれる）。

https://github.com/apple/swift/pull/15306

返り値返さない版を用意したらええのでは・・・（そんなことはわかってるだろうからなんか理由があるんやろうな

返り値オーバーロードだ

7:59 AM

なるほど・・・ｗ

Void のコンテキストなら下ので確定できたら便利なのかな？ (edited)

func foo() -> Int { print("Int"); return 1 } func foo() { print("Void") } foo() // error: ambiguous use of 'foo()' _ = foo() // error: ambiguous use of 'foo()' () = foo() // Void

最後の記法がちょっとおもしろい

ほほー

！ｗ

8:03 AM

_ = foo() なら Void 優先してほしいね。

8:03 AM

いや？それもへんか。

8:03 AM

捨ててるんだからなんかあるのか。

それは返り値握りつぶしてる感あるのでむしろIntが呼ばれてそうにみえますね

1

そうですねえ・・・

() = ... とかできるのか。 foo() は void と解釈してほしいかも。

8:18 AM

@discardableResult との兼ね合いをよく考えないといけなさそうだ。 (edited)

8:19 AM

@discardableResult func foo() -> Int { print("Int"); return 1 } func foo() { print("Void") } foo() // どっちになってほしい？

(edited)

fooだから分かりにくいですけどガイドラインに従ってればappendとappendingとかみたいになるんであんまり問題起こらない気がしますね。

8:22 AM

mutating funcの場合に限るかそれは。

今はそもそもがオーバーロードしたときに見分けてくれた方がいいかという前提の話なのでは？

うんまぁそうですが

実際には問題になるケースが少ないから

8:24 AM

ambiguous でいいんじゃないかってことか。

処理内容が同様ならdiscardableResultだけでいいし、処理内容が異なるならオーバーロードするのが間違っている気がします

コンパイルエラーで全然いいんだけどエラーメッセージをわかりやすくしてほしいと思っています。

たぶん元コンテキストのモチベーションとしては、 @discardableResult func foo() -> Int { print("Int"); return 1 } が既にありそれを使っているプロジェクトなんだけど、返値の生成にそれなりの負荷があるので、 func foo() でオーバーロード出来れば、軽量化出来る可能性があると。

あと元コンテキストはRubyですね。

戻り値の型によるオーバーロードを使ったAPIを提供しているSDKをメンテしていた経験でいうと。

返値の生成にそれなりの負荷がある

そういうケースはありますね……

はい、Ruby はとりあえず無視でｗ

Swiftだったら別に普通に呼び出してる箇所全部リファクタリングできるから別名でオーバーロードで解決しそう・・・

書き換えが許されるならオーバーロードを作って呼び出し元で戻り値の型を区別するのでもSwiftなら一緒じゃないですか？

8:28 AM

別名をつけなくても。

8:28 AM

どっちがわかりやすいとかは別として。

あー、それはそうですね。

discardableResult外してVoid overloadでいいじゃん、みたいな気がした

9:13 AM

あ、だめなのか

流転してる

ぉ、{ [weak self] in guard let self = self else { ... } を認める流れ。

2:36 AM

[Parse] Enable self rebinding (to self) by dduan · Pull Request #...

As discussed in this thread, this patch allows "self" to be an identifier bound to self (see added tests for examples), and is useful in closures where self is weakly captured to avoid re...

backtickなしで使える様になるのか。

良いね

これって一般的なローカル変数として self を使えるようになるわけではない？

1:45 AM

+struct T { + var mutable: Int = 0 + func f() { + // expected-error @+2 {{keyword 'self' cannot be used as an identifier here}} + // expected-note @+1 {{if this name is unavoidable, use backticks to escape it}} + let self = self + } +}

1:48 AM

そうすると、この前話してたキャプチャ禁止を変数にまで拡張したとして、 class Foo { func bar { @noncaptured let self = self baz { self.qux() // Error } } } みたいなことができない。まあ、それが欲しくなったときに認めればいいのか。

実装していてパフォーマンスに難があったので何かViewの組み方等でアドバイスをいただければ幸いです。。。今Swiftでエディターを作っていて、Wordみたいなページ区切りがあるものを実装しています。ただ、このページは入力に応じて高さを拡げていくようにしたい（＝文字数の入力制限がない）っていう要求があります。なので、下記構成で作ってみました。・UITableView

UITableViewCell
- UITextView

UITableViewCell
- UITextView

UITextViewを拡げていくように作りたいので isScrollable = false にして、入力に応じて動的に拡げていっています。ただ、TextViewへの入力が5000文字とか10000文字になってくると、入力に遅延が発生するようになりました（キーボードをタップして1＝2秒後に文字が表示される感じ）。なんとかここをクリアして要求を満たしたいのですが、何か策はありますでしょうか？

ScrollView（UITableViewやUITextView）は表示されている部分以外を計算しないことによってパフォーマンスを稼いでいます。UITextViewの入力文字が多くなると遅くなるのであれば、何らかの理由により、表示されていない部分も含めた全体の大きさに対して計算が起こっているのだと思います。

何らかの理由により、表示されていない部分も含めた全体の大きさに対して計算が起こっている

なるほど、、、これはTextViewのスクロールを禁止しているために、本来のTextViewのパフォーマンスが発揮できていない気がしますね。今のViewの組み方だとできなさそうですね。。。

5000文字か一万字で高さがどれくらいになるのかわからないですけど、UITableViewで１つのセルが画面の高さより高くなるのであれば、それは速度に大きく影響します。

8:08 AM

UITableViewの手法で計算を省こうとしても画面の大きさ以上の計算をすることになるので。

TextViewの中身が増えて画面の縦幅に到達したら、その時点で isScrollable = false をやめて true にして、 TextView自体のサイズは固定したら、見た目にはわかんないけど速度は改善したりしないですかね。

8:11 AM

あーでもテーブルがスクロールする時に通り抜けたりして面倒な事になっちゃいそうだなあ。

5000文字か一万字で高さがどれくらいになるのかわからないですけど

画面の高さの10倍でも足りないくらいになったりしますね。。。

8:12 AM

僕もその方法を考えたんですが、おっしゃる通りTableのスクロールの上にTextViewのスクロールがあってすごい使いにくくなっちゃって。どうしたものかという感じです。

UITextViewに複数のUITextContainerとNSLayoutManagerを使う方法を調べてみるといいと思います。私が実装するならまず上記の組み合わせで「ページ」という概念が表現できないかやってみます。でおそらくUITableViewは使わないと思いますが、結果的にUITableViewを使うことになってもUITextContainerとNSLayoutManagerで描画を分割することは必要になると思うので、それは無駄にはならないはずです。

1

まず、 UITextView を UITableView から分離して、単体で（ isScrollable = false で）パフォーマンスの問題が起こるのかを検証した方が良い気がします。 (edited)

UITextViewに複数のUITextContainerとNSLayoutManagerを使う方法を調べてみるといいと思います。

なるほど、調べてみますありがとうございます！

UITextView を UITableView から分離して、単体で（ isScrollable = false で）パフォーマンスの問題が起こるのかを検証した方が良い気がします。

単体でもパフォーマンスが下がってしまいます。。。 (edited)

それだと UITextView 以外の方法（何がいいかわかりませんが）で実装することができれば UITableView と組み合わせても問題が起こらないかもしれないですね。 (edited)

8:28 AM

たとえば、 UIWebView に <textarea> を入れるとかでどうにかできるかもしれません。（それもパフォーマンス低下するかもしれませんし、 view の高さを変更する部分が大変そうな気がしますが） (edited)

WebViewのなかでページという概念を表現するイメージですか？それとも上記の構成上のUITextViewをWebViewに置き換えて作るほうですかね？

UITextView 相当の、長文でスクロール禁止でもパフォーマンス低下しないものを自力実装するより、 UIWebView に textarea を入れた方が簡単そうだなと思った思いつきです。ブラウザで長文書いてもそんなにパフォーマンス悪くならない気がしたんですが、あれもスクロール可能だからな気がしますね

思いつきでもとてもありがたいです！WebViewも見えてない部分は計算しないみたいなのをやってそうなので、うまく行かなさそうな気がしますね。。

現在ある情報から推測すると、速度が遅くなるのはビューの大きさのせいだと思います。せっかくなので問題の切り分けをはっきりされると良いと思いますが、UITextViewの isScrollable = falseでビューの大きさが200x200とかで確かめてみるといいと思います。

8:35 AM

^ これは遅くならないはず。

さきほど、画面にFitさせる形でTextViewをおいて、そのなかの文字数を10000文字くらいにして、isScrollable = falseでやってみたんですが、遅くなってました〜。。。

（ UITextView ではなく自力実装するなら）原理的には、スクロールの可否に関係なく表示されている領域のみ再描画すれば良いはずだと思うので、スクロールしなくても遅くならないようにできそうな気がします。ただ、長文の途中に文字を挿入すると高さを計算するのにその後の全文字列の大きさを計算しないといけないので重いですかね？

デバイスはiPhoneですか？iPad?

iPhoneです！

view の高さを計算する部分を表示されたときに lazy にできるなら、原理的にはスクロールと同じにできそうなので、長文でも遅くならないものを実装できそうに思います。

iPhoneの画面と同じ大きさのUITextViewなら数万文字を格納したくらいで遅くなることは考えにくいですね。ちょっと検証したコードを見せてもらえませんか？

賢いアルゴリズムなら長い文字列は行区切り表現でもっておいて、行ごとにレイアウト情報をキャッシュしておいて、編集が発生した箇所よりも上はキャッシュから確定、編集箇所より下にかけて再計算、行が途切れるところで中断して残りはキャッシュから確定

8:40 AM

ってなりそうだしUITextViewならなってそうだけど

8:41 AM

リアクティブプログラミングになっていて編集イベントからテキスト全文をUITextView.textに再流入させてしまっているとか？

そもそも5000文字も1万文字も入力できるスペックを、フルでTableViewに乗せるのはまずい

import UIKit class TextViewVC: UIViewController, UITextViewDelegate { @IBOutlet weak var textView: UITextView! override func viewDidLoad() { super.viewDidLoad() setupKeyboardAccessoryView() textView.textContainerInset = UIEdgeInsets(top: 30, left: 30, bottom: 30, right: 30) textView.delegate = self textView.isScrollEnabled = false var message = "" for i in 1...10000 { message += "\(i)\n" } textView.text = message } private func setupKeyboardAccessoryView() { let kbToolBar = UIToolbar(frame: CGRect.zero) kbToolBar.barStyle = UIBarStyle.default kbToolBar.sizeToFit() let spacer = UIBarButtonItem(barButtonSystemItem: UIBarButtonSystemItem.flexibleSpace, target: self, action: nil) let close = UIBarButtonItem(title: "閉じる", style: .done, target: self, action: #selector(closeKeyboard(sender:))) kbToolBar.items = [spacer, close] textView.inputAccessoryView = kbToolBar } @objc func closeKeyboard(sender: Any) { self.view.endEditing(true) } }

(edited)

8:43 AM

Storyboard使ってますが、接続さえすればそのまま動くかと思います。動作確認は実機のiPhoneXでやっています。

8:44 AM

リアクティブは今のところ取り入れていません

1

↓ 4 万文字ほどになってそうですね。 for i in 1...10000 { message += "\(i)\n" }

8:45 AM

改行があるから 5 万か。

私がすぐに確認できるのは

8:45 AM

 textView.textContainerInset = UIEdgeInsets(top: 30, left: 30, bottom: 30, right: 30) textView.delegate = self var message = "" for i in 1...10000 { message += "\(i)\n" } textView.text = message

この部分だけですけど、これだけだと特に遅くはならないみたいです。

とりあえずTableViewの方は、3行まで+末尾…とかで実装して、タップしたら別画面のフルスクリーンのTextViewの画面に遷移するのがおすすめです。画面遷移のアニメーションを工夫すれば、ストレスも少なくて済む

あ、すいません、isScrollEnabled = falseをStoryboard上からやってしまっていました。 (edited)

多分、TableViewCellに載せる事を考えるより、画面遷移のアニメーションを作ったほうがトータルで安いと思います

^ 上記のテキストを表示しても入力や文字の削除などの操作はストレスなくできます。isScrollable = false/trueにかかわらずです。

確かに、要件次第ですが、一般的にはそちらの方が UX も良さそうですね。 < タップしたら別画面のフルスクリーンのTextViewの画面に遷移

多分、TableViewCellに載せる事を考えるより、画面遷移のアニメーションを作ったほうがトータルで安いと思います

このへんもデザイナさんと検討中ですが、できれば実現させたいなと思い相談させていただいてました

8:48 AM

上記のテキストを表示しても入力や文字の削除などの操作はストレスなくできます。isScrollable = false/trueにかかわらずです。

for i in 1...10000でもでしょうか？？

今僕もまるまるコピペで試してみましたけどサクサク動きますね。iPhoneSEです。

時間かかってるの

iOSすげえな。(内心動かないと思ってた) (edited)

@moga そうですね。全選択とかカーソル動かしたりとかしてみましたけど。UITextViewの大きさ変わってません？

多分 tableView.beginUpdate / tableView.endUpdate なんで

いや、まあ私としては文字数が原因でないことは確信があって聞いています。

こちらだと上記のコード動かしたら、遅くなってるんですが、なぜだ。。。

僕の方は UITextViewのレイアウトは Top Left Bottom Right 全部 Parent = 0 でやりました。

同じくです

8:51 AM

DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + 5) { print(textView.frame) } ^のような感じで適当に遅らせてtextViewの大きさを出したらどうなりますか？

cs

(0.0, 44.0, 375.0, 685.0)

8:52 AM

でした

（違うのはSafeArea + iPhoneX ・・・ (edited)

何でしょうね。サンプルプロジェクトを共有してもらったほうがいいかも。

どうしてもやりたい場合の話ですが、巨大なコンテンツを一枚のScrollViewでなんとかする場合

ひとまずiPhone8で試してみます

8:54 AM

共有は色々余分なViewが混ざっているので少々お待ちいただければ助かります。

最も大きくなる可能性のあるコンテンツをベースに考えると良くって、そうするとTextViewベースに…みたいな話になってきそう。実装時間考えるとあんまり現実案ではないですが。後はWebViewとか。

1

共有は色々余分なViewが混ざっているので少々お待ちいただければ助かります

(これを剥がしてシンプルにする過程で症状が解消すると良いな)

たしかにｗｗｗ

元の要件を考えるとテキストビューにページ区切りの概念ということなので、１つのTextView+ページごとのTextContainerでスッとできると思います。

すいません、＋αで、ページの間ごとにViewを挟み込んでButtonとか起きたい感じです。。。

普通に置けると思います。

9:00 AM

ページ単位でビューにするのはまあページ単位のテキストが少ない場合にはシンプルだと思いますけど、１ページの文字数はいくらでもサポートしたいという今回の話だと、結局同じ問題が出てくるので、

こちらに置きました。 https://github.com/SeiyaMogami/TextViewTest

SeiyaMogami/TextViewTest

Contribute to TextViewTest development by creating an account on GitHub.

ページ区切りが入力されるまで適当にTextContainerを広げていって、ページ区切りが入力されたら、ページの大きさを確定して下にいくつかのボタンと新しいTextContainerを作る、とかになるんじゃないですかね。

1

Simulatorで試しましたが遅かったです。

重いｗ

遅いですね

9:04 AM

何が違うんだろう。delegateは関係なかったです。

本当に何が違うんですかね。。。。。

SafeAreaでも無いな

isScrollEnabledは影響しますね。しかし私たちの検証結果との不一致が説明できない。

textView.textContainerInset = UIEdgeInsets(top: 30, left: 30, bottom: 30, right: 30)

これは

関係なさそうです。

試しましたが変わりませんでした。

Storyboardのせいっぽいな。

isScrollEnabled を trueにしたらはやくなった

すいません、僕は isScrollEnabled = false を入れたら同じ重さになりました

@omochimetaru Storyboardをやめてみてもらえません？

override func viewDidLoad() { super.viewDidLoad() let textView2 = UITextView(frame: view.bounds) textView2.isScrollEnabled = false var message = "" for i in 1...10000 { message += "\(i)\n" } textView2.text = message view.addSubview(textView2) }

最初コピペしたときは

 setupKeyboardAccessoryView() textView.textContainerInset = UIEdgeInsets(top: 30, left: 30, bottom: 30, right: 30) textView.delegate = self var message = "" for i in 1...10000 { message += "\(i)\n" }

こうだったはず

さっきのプロジェクトをこう変える。

なるほど

@omochimetaru すいません、Storyboardで設定してしまっていたのを失念して編集してました

岸川さんのコードはAutolayoutの制約がなくなるってことですか?

ていうかAutoSizingよね

9:11 AM

@Kishikawa Katsumi 軽くなりました。

なるほど、AutoLayoutのビュー自体のサイズを求める処理が影響していると。

9:12 AM

それですね、すばらしい。

なるほど、、、

isScrollEnabled = falseだとコンテンツの量＝ビューの大きさになるから、かな。

これ本コードのほうでやってみますが、結局TableViewにこんな大きいコンテンツを載せるのはそもそもよくないですよね、、、

AutoLayoutが効いている場合、例えそれが親ビューの4点固定でレイアウトしているから最終的に関係ないとしても、内部コンテンツのサイズをいったん計算するフローが入ってそこが重い AutoLayoutが無い場合、それが入らなくて軽い、という事ですかね？？ (edited)

9:16 AM

マジかコレ

マニュアルで制約つけてみたけどうまく再現しないですね。

あ〜、やってみます。

textView = UITextView() self.view.addSubview(textView) textView.translatesAutoresizingMaskIntoConstraints = false textView.topAnchor.constraint(equalTo: view.topAnchor).isActive = true textView.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true textView.trailingAnchor.constraint(equalTo: view.trailingAnchor).isActive = true textView.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true

こういうことですか？やってみましたがダメでした。 (edited)

@Kishikawa Katsumi

 override func viewDidLoad() { super.viewDidLoad() let textView2 = UITextView(frame: view.bounds) textView2.isScrollEnabled = false var message = "" for i in 1...10000 { message += "\(i)\n" } textView2.text = message view.addSubview(textView2) func makeCS() { textView2.translatesAutoresizingMaskIntoConstraints = false self.view.addConstraints(NSLayoutConstraint.constraints(withVisualFormat: "|[v]|", options: [], metrics: nil, views: ["v": textView2])) self.view.addConstraints(NSLayoutConstraint.constraints(withVisualFormat: "H:|[v]|", options: [], metrics: nil, views: ["v": textView2])) } makeCS() }

9:19 AM

重くなりました。

9:19 AM

激重で笑うコレ

警告は出ないけど、多分外側から大きさ決める部分と、コンテンツから大きさ決まる部分の優先度の解決で問題がある気がする

9:19 AM

Autosizingだとそんなの関係ないからセーフ

これは遅すぎるな

9:21 AM

上下左右のAnchorをSafeAreaとBottomに付けたときは変わらなかったです。

translatesAutoresizingMaskIntoConstraints=falseを忘れてないですか？

9:22 AM

AutoSizing, AutoLayoutに変換されてるだけだと思ってたけど、ショートパスあるなら使う意味あるな (edited)

AutoLayoutしか使ったことない新参者なんですが、AutoSizingって、制約つけないで、flexibleWidthとかってやるやつですよね？

そうです

@omochimetaru それでした。ありがとうございます。たぶん同じ現象が再現できたはず。

9:25 AM

 textView2.translatesAutoresizingMaskIntoConstraints = false textView2.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor).isActive = true textView2.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor).isActive = true textView2.trailingAnchor.constraint(equalTo: view.trailingAnchor).isActive = true textView2.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true

上下左右のマージンのとり方を、親ビューに対して、固定するかしないかでフラグが4つ、widthとheightを固定するかしないかでフラグが2つ

1

念のため、Storyboardの方でAutoLayoutのOffなども試したので原因は確定かと思います。

TextView+ScrollEnabled=falseでAutolayoutの場合、ContentSizeの計算が入るけど (edited)

9:26 AM

Autoresizingの場合はContentSizeの計算は無いのでそもそも動きが違う気がする (edited)

9:27 AM

フェアにするならtextDidChangeでsizing毎回呼ぶとフェアになる気がするよ

AutoResizing使って実現できないか試してみます、みなさん色々Try＆Adviceありがとうございました！！

もしかしてAutoLayoutやめたらTableViewを使った方法でも速度出るのかな。

それを今試すだけ試してみようと思っています

ContentSize都度計算+tableView.beginUdate/endUpdateで遅くなりそうな予感がしてます

9:33 AM

TableViewCellの高さがTableViewの高さ超えた時にしんどさがあった記憶があるんですが、夢だったかもしれない。

9:33 AM

それはCollectionViewCellの方だったかな…

TableViewCellの高さがTableViewの高さ超えた時にしんどさ

その通りですね。TableViewのパフォーマンスを稼ぐ手法が役に立たなくなるので。CollectionViewも同様の理由で

‍♂️。 (edited)

昨晩たまたまメルカリを使っていて気づいたんですが、出品ページの説明文のところに1万文字とか入れても重くなってなくてすごいってなりました。TableViewCellの中にスクロール禁止のTextViewが入ってる感じに見えるんですが、Autolayout使ってないのかな

1

swiftc勉強会を開催します。興味ある人は是非参加してください！ https://iosdiscord.connpass.com/event/82436/

わいわいswiftc #1 (2018/03/30 19:00〜)

# わいわいswiftc わいわいswiftcは、Swift Compilerとその周辺技術に関する勉強会です。初心者・上級者を問わず、情報交換とディスカッションの場として機能することを目的としています...

8

ガチ勢無料...

protocol Foo { associatedtype Bar func foo<T: HasB>(t: T) where T.B == Bar } protocol HasB { associatedtype B } struct C<E>: Foo { typealias Bar = [E] }

この状態でCにfooを補完させると func foo<T>(t: T) where T : HasB, [E] == T.B { } というコンパイルの通らないコードが補完される (edited)

5:10 AM

これってどこにissue投げたらいいんですかね

bugs.swift.org かな?

投げてみます

最小ケースを見つけると良さそう

5:15 AM

なんで通らないんだ?と思ったらT.B == [E]なら通るのかw

そうなんですよ

5:15 AM

そこで順番が逆になるのがおかしい

extension Array { func hoge() -> String { return "Default" } // ① } extension Array where Element == S { func hoge() -> String { return "Subtype" } // ② } extension Array where Element: P { func hoge() -> String { return "Protocol" } // ③ } extension Array where Element == P { func hoge() -> String { return "Existence" } // ④ }

[S()].hoge() で②が呼ばれるのって、ここの優先順位が理由ってことで合っていますか？ https://github.com/apple/swift/blob/2f6ca48c75cd5482df594496b0be83e7379f2a77/lib/Sema/CSSimplify.cpp#L1830

swift - The Swift Programming Language

5:10 AM

[S()].hoge() を swift -frontend -typecheck -debug-constraints に掛けてみると Constraint restrictions: Array<S> to Array<S> is [deep equality] と出ました

debug-constraintsの出力みてみると、オーバーロードのどの候補を使うかの比較自体はこの辺りでやってそうな雰囲気ありますね https://github.com/apple/swift/blob/master/lib/Sema/CSRanking.cpp#L387-L725

swift - The Swift Programming Language

なるほど、それを利用してる https://github.com/apple/swift/blob/fca77b36598ce1022be09b1d7a23b089a948335f/lib/Sema/CSRanking.cpp#L727-L729 でスコアをつけていって、最終的に "more specific" なoverload が選ばれるみたいですね https://github.com/apple/swift/blob/7e68e02b4eaa1cf44037a383129cbef60ea55d67/docs/TypeChecker.rst#comparing-solutions

swift - The Swift Programming Language

http://twitter.com/slava_pestov/status/976698121760620544

swift - The Swift Programming Language

http://twitter.com/jckarter/status/976824192694763520

When this lands, generic type aliases will be done - almost - except there’s one more corner case with expression checking: https://t.co/90wKRt8Isc

2:15 PM

https://forums.swift.org/t/ownership-annotations/11276

@slava_pestov Release Notes Swift 4.2 is the first compiler version to implement Swift 3.0

2:15 PM

At present, the new type node is mainly useful in preserving type sugar for diagnostics purposes, as well as being reflected in other tools (indexing, code completion, etc.).

2:17 PM

ここでも話題に上がってたGenericパラメータを持つTypeAliasの表現を保持するやつができたっぽいコード補完でも使えるって言ってるね

1

#swift-2 で話題のバグと組み合わせると盛大に壊れそうでワクワクする (edited)

1

Ownership Annotations

Hello Swift Evolution, Over the course of summer of 2017, I was tasked with exploring the implementation of ownership annotations for the Swift language. The goal at the time was to release this proposal at the end of my time and un-underscore ...

6:45 AM

shared 指定子とかのPitchきた

6:51 AM

Grammatical Changes The Swift language will be amended to support the addition of the borrow and consume type annotations. GRAMMAR OF A TYPE ANNOTATION type-annotation → : attributes(opt) inout(opt) type +type-annotation → : attributes(opt) borrow(opt) type +type-annotation → : attributes(opt) consume(opt) type In addition, the grammar of function declarations will be amended to support the consuming attribute. -mutation-modifier → mutating | nonmutating +self-ownership-convention → mutating | nonmutating | consuming

6:52 AM

sharedじゃなくてborrowとconsumeで来た

ErrorからNSErrorへのキャスト、Macだと常に成功してLinuxだと失敗することもあるんやな・・・ https://github.com/ReactiveX/RxSwift/blob/master/RxCocoa/Foundation/URLSession%2BRx.swift#L142-L146

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

RxSwift - Reactive Programming in Swift

多分暗黙変換の有無でキャストが常に成功しないことになるのかな

Linuxの場合は本当にNSError型のときしか通らない普通のダウンキャストではないかな

1:36 PM

NSError の domain が NSURLErrorDomain のとき、Foundation.URLError 型として扱えるし、なんだか謎が多い

protocolをclassに準拠させるの、もしかしてprotocolのassoctypeの制約をwhereで書くようになってからできるようになったのかな

]

#waiwai-swiftc とeventの音声チャットでで「わいわいswiftc」にオフライン参加できます。

オンラインですね

そうだ。私たちがオフラインだ。

Chris Lattner (@clattner_llvm)

Swift for @TensorFlow Talk video and announcement are up! Check it out: https://t.co/3B4127kbFZ and join the conversation: https://t.co/dNIpVzphLO

Likes

183

4:01 AM

@koher fyi 中身は見てないけど

1

https://forums.swift.org/t/introducing-swift-for-tensorflow/11550

Introducing Swift for Tensorflow

Yesterday we announced Swift for TensorFlow, which applies Swift to the domain of machine learning. The intro video is here: The only additional details available are in a post to our community list, and I encourage ...

https://forums.swift.org/t/introducing-unwrappable-a-biased-unwrapping-protocol/11232

Introducing Unwrappable, a biased unwrapping protocol

Draft here: https://github.com/erica/swift-evolution/blob/unwrappable/proposals/XXXX-unwrappable.md Previous discussions: Auto Unwrapping Of Optionals [Pitch] Introducing Unwrappable protocol guard let x = x Introducing an Unwrappable prot...

3:13 AM

これめっちゃ良さそう if letで中身取り出せるのをUnwrappedプロトコルにして、Optionalだけじゃなくてユーザー型でも可能にする案

ザーッと流し読みしたら最後の方にしれっとHigherKindedTypeあってワロタ

これおもろいね

3:19 AM

Mapped == Selfって制約を足せば

3:19 AM

いわゆるファンクターになるんかな？

Selfとは…ってかんじやけど

既存の仕様でできないのはassoctypeがパラメタ化してるところだけ

Unwrappedだけならいいけど、これが型強制も追加しようとなってくるといよいよやばい

スレはif letの事だけど?.とかについても途中で議論されとる

3:22 AM

ああそうか、Self自体は自身のパラメータも含むから

3:22 AM

==Selfたとちょっと変だな

conditional conformance は protocol を一気に二つ上がるとエラーになるっぽいです（？）

protocol A { } protocol B: A { } protocol C: B { } struct X<T>: A { } extension X: C where T: Equatable { } // error X<T> does not conform to protocol 'B'

protocol A { } protocol B: A { } protocol C: B { } struct X<T>: A { } extension X: B where T: Equatable { } // これを入れる extension X: C where T: Equatable { } // OK

(edited)

@swiftbot protocol A { } protocol B: A { } protocol C: B { } struct X<T>: A { } extension X: C where T: Equatable { }

@Kishikawa Katsumi,

/usercode/main.swift:6:1: error: type 'X<T>' does not conform to protocol 'B' extension X: C where T: Equatable { } ^ /usercode/main.swift:3:10: note: type 'X<T>' does not conform to inherited protocol 'B' protocol C: B { } ^ Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu

そんな機能がw

さっき作りました。

便利すぎる

typealias も where つきで書けるんですね、便利

public typealias AlgebraicExtension<K, p: _IrreduciblePolynomial> = QuotientRing<Polynomial<K>, PolynomialIdeal<p>> where K == p.K

3:21 PM

conditional conformance を上手く使うとこれまで別の型として定義してたものをただの別名にすることができて気持ちいいですね

ですねえ〜〜

この機構って他の言語でもあったりするんですか？

どうなんだろう・・・

3:26 PM

そもそもconditionalの前にprotocol後付自体が珍しいんですよね

3:29 PM

https://rustbyexample.com/generics/where.html

Where clauses - Rust By Example

A description

3:29 PM

Rustがいけるっぽい。 impl <A, D> MyTrait<A, D> for YourType where A: TraitB + TraitC, D: TraitE + TraitF {} YourType型が where以下の条件をみたすときに MyTrait<A, D> を conformする

3:30 PM

しかもこの例はGeneric TraitだからSwiftではできない事もしている。

generic trait とはどのようなものなんです？（trait が概ね protocol と思うので良い？）

Rustにおけるgenericでない通常のtraitは Swiftにおけるprotocolだと理解して良いと思いますが

3:34 PM

RustのTraitはGenericにできるのに対してSwiftのprotocolはできない

3:34 PM

ここでいうGenericっていうのはジェネリクス型のように型パラメータを取るということで

3:34 PM

↑の例だと <A, D> の部分です。

3:34 PM

Swiftのprotocolには associatedtype という機能がありますが

あぁ、なるほど。

これは、あるプロトコルPに適合する型Tが、その適合の過程においてTにおいて関係する型Uを持つことをPの定義として宣言できるというもので

3:35 PM

プロトコルPそれ自体がパラメータをもっているわけではないんですね

はいはい。

https://doc.rust-lang.org/std/convert/trait.From.html

std::convert::From - Rust

API documentation for the Rust From trait in crate std.

3:36 PM

ある型Tがジェネリックトレイト Fromに適合しているとき、 from(U) という関数から T が構築できるっていうのがstdlibにあるんですが (edited)

3:37 PM

これはSwiftだと表現できないんですよねえ。

3:38 PM

Fromトレイトを作ろうとしても、associatedtypeとして一つの型しか示す事ができないから、 Intからも構築できるしStringからも構築できる、みたいにバラバラにできなくて、 SwiftだとFromInt protocol、 FromString protocol って感じで個別に書き下す形になっちゃう。

ふむふむ。

3:40 PM

強い

2

↑のA,B,Cの一段飛ばしでCをconformするのは、できないのがただしそうです

おっ

「Aにconformする」と「Bにconformする」が別で…あれ…

3:42 PM

あれれ、いけるような気もしてきた

@swiftbot protocol A {} protocol B : A {} struct S {} extension S : B {} print(S.self is A.Type) print(S.self is B.Type)

Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu true true /usercode/main.swift:8:14: warning: 'is' test is always true print(S.self is A.Type) ^ /usercode/main.swift:9:14: warning: 'is' test is always true print(S.self is B.Type) ^

@swiftbot

protocol A {} protocol B : A {} protocol C : B {} struct S {} extension S : C {} print(S.self is A.Type) print(S.self is B.Type) print(S.self is C.Type)

Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu true true true /usercode/main.swift:9:14: warning: 'is' test is always true print(S.self is A.Type) ^ /usercode/main.swift:10:14: warning: 'is' test is always true print(S.self is B.Type) ^ /usercode/main.swift:11:14: warning: 'is' test is always true print(S.self is C.Type) ^

conditionalじゃない場合は一気にいける

condconfに限り無理なのか

3:46 PM

@swiftbot

protocol A {} protocol B : A {} protocol C : B {} struct S<T> {} struct K: A {} extension S : C where T: A {} print(S<K>.self is A.Type) print(S<K>.self is B.Type) print(S<K>.self is C.Type)

Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu /usercode/main.swift:8:1: error: type 'S<T>' does not conform to protocol 'B' extension S : C where T: A {} ^ /usercode/main.swift:3:10: note: type 'S<T>' does not conform to inherited protocol 'B' protocol C : B {} ^ /usercode/main.swift:12:17: warning: 'is' test is always true print(S<K>.self is C.Type) ^

チケット切っても良さそう

ン

3:48 PM

@swiftbot

protocol A {} struct S<T> {} struct K: A {} extension S : A where T: A {} print(S<K>.self is A.Type) print(S<S<K>>.self is A.Type) print(S<S<S<K>>>.self is A.Type)

Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu true true true /usercode/main.swift:8:17: warning: 'is' test is always true print(S<K>.self is A.Type) ^ /usercode/main.swift:9:20: warning: 'is' test is always true print(S<S<K>>.self is A.Type) ^ /usercode/main.swift:10:23: warning: 'is' test is always true print(S<S<S<K>>>.self is A.Type) ^

すごい

げげげｗ

Equatableいけるからいけるのわかってるけど、いざやってみて通ると嬉しさがある

停止しないパターンは無いのかなあ〜

昨日言ってたprotocolを直接拡張するwayがあると、非停止なコンパイルができそう

https://twitter.com/kenmaz/status/979995040297570304

kentaro matsumae (@kenmaz)

Tensorflow for Swift ではなく Swift for Tensorflow 。自動微分機能やPython相互運用性などを言語自体に組み込むために、コンパイラをforkして別に作るみたい https://t.co/dtfxZkam2B

1:41 AM

Relation to the Swift project This project includes Swift compiler and language changes, which are in a copy of the Swift compiler sources. We think that some of these changes will be interesting to the broader Swift community, including language-integrated automatic differentiation support, a constant expression model, and improved interoperability with Python (and other dynamic languages).

1:41 AM

アップルのSwiftとグーグルのSwiftがどちらもラトナ牽引で分裂するのなんか凄いね・・・

1

これがオッケーならSwift for Android作って欲しい

@Taketo Sano

この機構って他の言語でもあったりするんですか？

遅レスですが、 Haskell だとできますね。

おぉ、なるほど。

Swiftbotこれオープンソースですか？どこで動かしてるんですか

4:50 AM

弊社も導入してみようかな･･････

4:52 AM

おもむろにNSTaskとかFileManagerとか呼んでみるとヤバそう

@swiftbot contribute

https://github.com/kishikawakatsumi/swift-playground

kishikawakatsumi/swift-playground

Contribute to swift-playground development by creating an account on GitHub.

4:54 AM

https://github.com/kishikawakatsumi/swift-compiler-discord-bot

kishikawakatsumi/swift-compiler-discord-bot

Contribute to swift-compiler-discord-bot development by creating an account on GitHub.

ソースコード見たらだいたいわかると思います。

おお、まさに必要としていたものだ。弊社でもAWSとかにデプロイしてみます〜

コンパイルと実行はdockerに閉じ込めていて、時間制限もあるので大した悪事はできないと思います。しかし何か見つけたら速やかに教えてください。

大した悪事はできないと思います

やるなよ、絶対にやるなよ

dockerfileの名前を決め打ちにしてあるので、それだけ準備が必要です。たぶんあとはそのままいける。

snaphost自動更新の仕組みは欲しいですね

4:59 AM

swiftenvとかで新しい奴持ってきてdocker buildする仕組みが

floor 使って切り捨てやってたんですけど、以下の結果になるのって Swift 的には正しいんですかね？ @swiftbot

let x = 9.9499 * 100.0 print("\(x) -> \(floor(x))") // 意図通り let y = 9.95 * 100.0 print("\(y) -> \(floor(y))") // 995.0 になって欲しい

(edited)

10:06 AM

994.99 -> 994.0 995.0 -> 994.0

@swiftbot

let x = 9.9499 * 100.0 print("\(x) -> \(floor(x))") // 意図通り let y = 9.95 * 100.0 print("\(y) -> \(floor(y))") // 995.0 になって欲しい print(y < 995.0)

Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu

10:19 AM

/usercode/main.swift:2:18: error: use of unresolved identifier 'floor' print("\(x) -> \(floor(x))") // 意図通り /usercode/main.swift:5:18: error: use of unresolved identifier 'floor' print("\(y) -> \(floor(y))") // 995.0 になって欲しい

@swiftbot

import Foundation let x = 9.9499 * 100.0 print("\(x) -> \(floor(x))") // 意図通り let y = 9.95 * 100.0 print("\(y) -> \(floor(y))") // 995.0 になって欲しい print(y < 995.0)

Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu

10:19 AM

994.99 -> 994.0 995.0 -> 994.0 true

@daccchan 正しいです、

10:19 AM

995.0って表示されてるけど

10:20 AM

これ本当は994.999999999 みたいな数字で

10:20 AM

見やすいように切り上げて995.0って出てるけど、内部的には995未満の値なので。

10:20 AM

この現象が起きるのはそもそも「0.95」が2進数であらわせないからです

なるほど

10:27 AM

小数点2位以下を切り捨てて、四捨五入しい場合だと、 . で切り離して、少数部分の1文字目だけを取得して再計算するとかっていう方法を取ろうかなんて考えてたんですが、良い方法ってありますか？

FloatとDoubleは2進数なので 9.95 は正しく扱えないので、 10進少数のDecimal型を使うのが良いです https://developer.apple.com/documentation/foundation/decimal (edited)

10:30 AM

@swiftbot

10:30 AM

@swiftbot import Foundation let a = Decimal(string: "9.95")! * Decimal(string: "100")! print(Decimal(string: "995")! == a)

Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-unknown-linux-gnu

10:31 AM

true

定数を初期化するときは文字列経由でやらないと、途中でFloatを通ると意味が無いので注意です

なるほど Decimal を使うんですか。ちょっと試してみます。ありがとうございますー

cond. conf. で protocol を二つ以上上がれない問題は、継承の順序通りに書けばいけることが分かりました。 @swiftbot

protocol A { } protocol B: A { } protocol C: B { } struct X<T>: A { } // extension X: C where T: Equatable { } // これだとエラー extension X: B, C where T: Equatable { } // これなら OK

(edited)

Swift version 4.1 (swift-4.1-RELEASE)

2:28 AM

/usercode/main.swift:8:41: error: invalid character in source file extension X: B, C where T: Equatable { }　 // これなら OK

@swiftbot

class X { var a: Int init(a: Int) { self.a = a } } protocol A { var b: String { get } } extension A { var b: String { return "hello" } } extension X: A { } class Y: X { init() { print(b) super.init(a: 1) } }

Swift version 4.1 (swift-4.1-RELEASE)

7:20 AM

/usercode/main.swift:22:15: error: 'self' used before 'super.init' call print(b) ^

@swiftbot --version 4.0.3

class X { var a: Int init(a: Int) { self.a = a } } protocol A { var b: String { get } } extension A { var b: String { return "hello" } } extension X: A { } class Y: X { init() { print(b) super.init(a: 1) } }

Swift version 4.0.3 (swift-4.0.3-RELEASE)

7:20 AM

/usercode/main.swift:22:15: error: 'self' used before super.init call print(b) ^

アレ

7:20 AM

4.0.3だと通ると思ったが…

@swiftbot

enum AA { case aa(p1: Int, p2: String) } let a = AA.aa(p1: 1, p2: "p2") switch a { case .aa(p3: let str): print(type(of: str)) }

Swift version 4.1 (swift-4.1-RELEASE)

9:44 AM

(p1: Int, p2: String)

ラベル付きタプルに対するパターンマッチのときのラベル部分に意味はない・・・？

無い気がする

数があってるときは怒られるな

9:46 AM

1個だけ書いたときが変な挙動

@swiftbot (p1: Int, p2: String).self is (p3: Int, p4: String).Type

Swift version 4.1 (swift-4.1-RELEASE)

9:47 AM

/usercode/main.swift:1:28: warning: expression of type 'Bool' is unused (p1: Int, p2: String).self is (p3: Int, p4: String).Type ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

print忘れてた

9:47 AM

@swiftbot print((p1: Int, p2: String).self is (p3: Int, p4: String).Type)

Swift version 4.1 (swift-4.1-RELEASE)

9:47 AM

false

あれーまじか

@swiftbot

enum AA { case aa(p1: Int, p2: String) } let a = AA.aa(p1: 1, p2: "p2") switch a { case .aa(p3: let x, p4: let str): print(type(of: str)) }

Swift version 4.1 (swift-4.1-RELEASE)

9:48 AM

/usercode/main.swift:8:10: error: tuple pattern element label 'p3' must be 'p1' case .aa(p3: let x, p4: let str): ^

2個かいてるときはラベルもちゃんとしないとだめ

なるなるほどほど

9:50 AM

てかそれは、AssociatedValueが複数の時に変なのでは

case側がAssoc1個のときは

tupleへの変換が走って謎のラベルが許されてるように見える

常にガバガバ？

そっちはtupleへの変換起きないから怒られるのではと思う

1個と2個で動き違うの面白い

10:43 AM

パターンマッチの方ではラベル書かない派です。それはバインドする変数名で説明すればいいと思う。

それだとcaseにassociated valueが追加されたり順番が入れ替わったときに

10:44 AM

変更が検知できないのが気になる

10:45 AM

(1個から2個の場合、↑であげた謎挙動のせいでマッチは成功する、その先で型が壊れるので止まるが)

なるほど？

10:46 AM

謎挙動そこで影響してくるか

もともとそれで気づいたのです・・・

10:46 AM

まあ、たとえば、Intが2個の場合に、定義順入れ替えは検出できないですよね。

普段そこまで考えてないな……

でも case .image(url: let url): は冗長でダサいのはそうなんですよねえ。

順番入れ替えとか気にする必要があるならstructにしちゃうのが確実か

確かにstruct1個持ったcaseにすると確実ですね

僕はinner struct推しですね、諸々トータルで良い塩梅

この記事が良かったので @hachiware さんをここに勧誘しました。 https://qiita.com/creaaa/items/4297bf60d222d661498f

Swiftのextensionは3パターンだけ〜そして条件付き適...

Xcode 9.3 正式版が一向にリリースされないため、しびれを切らして投稿します。 (追記) -> 翌日にリリース来ました。念願のSwift 4.1や。**Swift 4.1の次はSwift 4.2で、その次はSwift ...

7:34 AM

記事中で @Kuniwak の「CCなくて不便」って記事が参照されていて、そんな記事あったっけ〜と思って読みにいったら、 2016年12月に、自分が「Acceptedしてるから待とう」ってコメントしてたｗ 16ヶ月後、そこには元気なCondConf搭載のXcodeちゃんが配信されていたのでした・・・

来週の Swift Tweets の発表内容と大分被ってるなｗ

7:43 AM

まあでも今更内容変更して準備するのは無理だし、説明の仕方は色々あってもいいのでそのままのテーマでいきます。

1

おおもうすぐ

7:44 AM

cond-confのテーマなんですか、Xcode配布と合わせてタイミング予測が完璧ｗ

本番までに 4.1 出ないんじゃないかとヒヤヒヤしたｗ

ｗ

@swiftbot

class _Foo { class func get() -> _Foo { return _Foo() } } class Foo<X>: _Foo { override class func get() -> _Foo { return Foo() } } protocol Bar {} extension Foo where X: _Foo, X: Bar { static func make() -> Foo { return get() as! Foo } }

Casting always failって出るけど嘘のパターン見つけた

Swift version 4.1 (swift-4.1-RELEASE)

10:09 AM

/usercode/main.swift:12:22: warning: cast from '_Foo' to unrelated type 'Foo<X>' always fails return get() as! Foo ~~~~~ ^ ~~~

conditional extensionでconditionにclassとprotocolを制約付けたGenerics型とのキャストで発生する

10:14 AM

@swiftbot --version=4.0.3

class _Foo { class func get() -> _Foo { return _Foo() } } class Foo<X>: _Foo { override class func get() -> _Foo { return Foo() } } protocol Bar {} extension Foo where X: _Foo, X: Bar { static func make() -> Foo { return get() as! Foo } }

Swift version 4.0.3 (swift-4.0.3-RELEASE)

10:14 AM

/usercode/main.swift:12:22: warning: cast from '_Foo' to unrelated type 'Foo<X>' always fails return get() as! Foo ~~~~~ ^ ~~~

ありゃー前からだったか(´・ω・`)

https://medium.com/@slavapestov/behind-the-scenes-improvements-in-swift-4-1-269dd56e30c2 Swift 4.1 でのリリースノートに載っていない変更などを Slava が解説しています。

Behind-the scenes improvements in Swift 4.1 – Slava Pestov – M...

Swift 4.1 has been released, and as you can see from the release announcement, there are many important user-visible improvements…

1

Classes conforming to protocols with default implementations

12:35 AM

static funcでSelf返すデフォルト実装を持っていても、final classにしなくてよくなったのかな

12:36 AM

4.0以前でもinitならokだった

その記事読んでちょうど今試してた。 (edited)

あれ？それ何かおかしなことにならないのか。

大丈夫と思うよ

protocolのweak varのweakいらなくなったのもSwift4.1か

https://engineering.linecorp.com/ja/blog/detail/227 ↑これのことです？

Swift 4.1+ : LINE Engineering Blog

こんにちは、AIプラットフォームClova開発チームのezuraです。この記事はLINE Advent Calendar 2017の14日目の記事です。みなさん、今年のSwift...

あ、それだ。

3:44 AM

なんかとっくに無くなった気がしていたんだけど、最近書いてみたら書けたので、あれ？って思ってた。

3:44 AM

4.0まではweakつけられたんやなと

3:45 AM

さっきxcode新しくしたら警告が出たから4.1だったのかーと。

https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md

https://github.com/apple/swift/blob/master/lib/Sema/DerivedConformanceCodable.cpp

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

5:57 AM

めちゃめちゃ話し合ってた乱数APIがレビュー入りしてた

自然で使いやすそう

3

@swiftbot

protocol P { associatedtype X = Int func f(_ x: X) } extension P where Self == S { func f(_ x: X) {} } struct S: P { func f(_ x: X) {} }

Swift version 4.1 (swift-4.1-RELEASE)

12:33 PM

/usercode/main.swift:13:17: error: reference to invalid associated type 'X' of type 'S' func f(_ x: X) {} ^

@swiftbot protocol P { associatedtype X = Int func f(_ x: X) } extension P { func f(_ x: X) {} } struct S: P { func f(_ x: X) {} }

Swift version 4.1 (swift-4.1-RELEASE)

@swift403 --versions=latest

protocol P { associatedtype X = Int func f(_ x: X) } extension P where Self == S { func f(_ x: X) {} } struct S: P { func f(_ x: X) {} }

exit status: 1, error output: <unknown>:0: error: unknown argument: '--versions=latest'

@swiftbot --version=latest

protocol P { associatedtype X = Int func f(_ x: X) } extension P where Self == S { func f(_ x: X) {} } struct S: P { func f(_ x: X) {} }

Swift version 4.2-dev (LLVM 8a97de0e52, Clang 3c973cd6c1, Swift e0c091a012)

12:36 PM

/usercode/main.swift:13:17: error: reference to invalid associated type 'X' of type 'S' func f(_ x: X) {} ^

壊れた

12:37 PM

where Self == Sで何が変わるんだろう

@swiftbot

protocol P { associatedtype X = Int func f1(_ x: X) func f2(_ x: X) } struct S: P { func f1(_ x: X) {} func f2(_ x: X) {} }

Swift version 4.1 (swift-4.1-RELEASE)

7:12 AM

/usercode/main.swift:11:18: error: reference to invalid associated type 'X' of type 'S' func f2(_ x: X) {} ^

デフォルト型を持つassoctypeをシグネチャに持つやつを２個実装するとダメ？ (edited)

これですかね？ https://bugs.swift.org/browse/SR-6516

それっぽいですね

8:56 AM

witness table周りがバグってる？

SR-6516 は associatedtype が他の associatedtype を参照している時の話なので、ちょっと違うと思います。これはこれでバグ報告しておいた方が良さそうです。

1

なるほど、ありがとうございます！バグ報告投げようと思います。

CodableのkeyDecodingStrategy,

11:45 AM

これとCodingKeyを組み合わせて、

11:45 AM

CodingKeyを明記する方にsnake_caseを混ぜるとデコードに失敗して、その時のエラーメッセージがキーが見つからないよ~としか出てこないので1時間近くハマりがあった

11:46 AM

camelCaseにするとデコード成功するけどこれはなかなか

CodableをGenericsでやろうとすると、OptionalがGenericsの有無で、キー無しが通るかどうかの挙動が変わる事を発見した

6:03 AM

発見したくなかった…

6:04 AM

struct X<T: Codable>: Codable { var t: T }; typealias A = X<Int?> struct A: Codable { var t: Int? } この2つの挙動が違う (edited)

なるほど・・・

CondConfは半ば適応されていてこいつはまだちゃんと動かないということかな

assoctypeのフィールド由来のtypealias省略マッチング、個数に限界があって限界を超えるとコンパイルが終わらなくなることがわかった

6:55 AM

30個ぐらいやると無限にコンパイルが終わらない

swift-4.2-DEVELOPMENT-SNAPSHOT-2018-04-23-aが出てる。

Codable絡みのコンパイラのバグ見つけた

4:13 AM

あとで @t.ae が投稿します

// OK struct Var: Codable { static var name: String { return "namae" } var name: String init(name: String) { self.name = name } } // NG struct Property: Codable { static let name: String = "namae" var name: String init(name: String) { self.name = name } }

@swiftbot struct Property: Codable { static let name: String = "namae" var name: String init(name: String) { self.name = name } }

1

Swift version 4.1 (swift-4.1-RELEASE)

4:49 AM

swift: /home/buildnode/jenkins/workspace/oss-swift-4.1-package-linux-ubuntu-16_04/llvm/include/llvm/Support/Casting.h:255: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = swift::MetatypeType, Y = swift::TypeBase]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. /usr/bin/swift[0x3f24d54] /usr/bin/swift[0x3f25096] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f3c457f8390] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f3c43f37428] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f3c43f3902a] /lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7f3c43f2fbd7] /lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f3c43f2fc82] /usr/bin/swift[0x5f332c] /usr/bin/swift[0xc6c474] /usr/bin/swift[0xc80ca8] /usr/bin/swift[0xc77e4c] /usr/bin/swift[0xc6eff8] /usr/bin/swift[0xcf6b1a] /usr/bin/swift[0xcf74c6] /usr/bin/swift[0xcf620a] /usr/bin/swift[0xcf55ab] /usr/bin/swift[0xcf4e80] /usr/bin/swift[0xce08fc] /usr/bin/swift[0xcdf3dc] /usr/bin/swift[0xc74274] /usr/bin/swift[0xc78307] /usr/bin/swift[0xc6f45b] /usr/bin/swift[0xcc12b1] /usr/bin/swift[0xcc106e] /usr/bin/swift[0xc8fec5] /usr/bin/swift[0xc33515] /usr/bin/swift[0xc32021] /usr/bin/swift[0xc3221d] /usr/bin/swift[0x4c27c4] /usr/bin/swift[0x4beecc] /usr/bin/swift[0x4778c4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f3c43f22830] /usr/bin/swift[0x475179] Stack dump: 0. Program arguments: /usr/bin/swift -frontend -interpret /usercode/main.swift -disable-objc-interop -I /usr/lib/swift/clang/include/ -I /vendor/SwiftyMath/.build/release/ -I /vendor/swift-package-libbsd/ -module-name main -ldSwiftyMath 1. While silgen emitFunction SIL function "@_T04main8PropertyV6encodeys7Encoder_p2to_tKF". for 'encode(to:)' in module 'main' Aborted (core dumped)

XCodeと違う壊れ方してますね

@swift-4.1.3 struct Property: Codable { static let name: String = "namae" var name: String init(name: String) { self.name = name } }

exit status: 134 with stderr:

swift: /home/buildnode/jenkins/workspace/oss-swift-4.1-package-linux-ubuntu-16_04/llvm/include/llvm/Support/Casting.h:255: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = swift::MetatypeType, Y = swift::TypeBase]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. #0 0x0000000003f24d54 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x3f24d54) #1 0x0000000003f25096 SignalHandler(int) (/usr/bin/swift+0x3f25096) #2 0x00007f63ee8e4390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007f63ed023428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #4 0x00007f63ed02502a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #5 0x00007f63ed01bbd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7) #6 0x00007f63ed01bc82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #7 0x00000000005f332c (/usr/bin/swift+0x5f332c) #8 0x0000000000c6c474 swift::Lowering::SILGenFunction::emitRValueForStorageLoad(swift::SILLocation, swift::Lowering::ManagedValue, swift::CanType, bool, swift::AbstractStorageDecl*, swift::Lowering::RValue, llvm::ArrayRef<swift::Substitution>, swift::AccessSemantics, swift::Type, swift::Lowering::SGFContext, bool) (/usr/bin/swift+0xc6c474) #9 0x0000000000c80ca8 (anonymous namespace)::NominalTypeMemberRefRValueEmitter::emit(swift::Lowering::SILGenFunction&) (/usr/bin/swift+0xc80ca8) #10 0x0000000000c77e4c swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xc77e4c) #11 0x0000000000c6eff8 swift::Lowering::SILGenFunction::emitRValueAsSingleValue(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xc6eff8) #12 0x0000000000cf6b1a (anonymous namespace)::ArgEmitter::emit(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) (/usr/bin/swift+0xcf6b1a) #13 0x0000000000cf74c6 (anonymous namespace)::ArgEmitter::emitExpanded

stderr.txt

https://file.io/hbSezR

@swift-4.2.4 struct Property: Codable { static let name: String = "namae" var name: String init(name: String) { self.name = name } }

exit status: 134 with stderr:

swift: /home/buildnode/jenkins/workspace/oss-swift-4.2-package-linux-ubuntu-16_04/llvm/include/llvm/Support/Casting.h:255: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = swift::MetatypeType, Y = swift::TypeBase]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. #0 0x00000000040df5b4 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x40df5b4) #1 0x00000000040df8f6 SignalHandler(int) (/usr/bin/swift+0x40df8f6) #2 0x00007fcd0eafc390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007fcd0d23b428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #4 0x00007fcd0d23d02a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #5 0x00007fcd0d233bd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7) #6 0x00007fcd0d233c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #7 0x00000000005fecaf (/usr/bin/swift+0x5fecaf) #8 0x0000000000c98bc7 swift::Lowering::SILGenFunction::emitRValueForStorageLoad(swift::SILLocation, swift::Lowering::ManagedValue, swift::CanType, bool, swift::AbstractStorageDecl*, swift::Lowering::RValue, llvm::ArrayRef<swift::Substitution>, swift::AccessSemantics, swift::Type, swift::Lowering::SGFContext, bool) (/usr/bin/swift+0xc98bc7) #9 0x0000000000cb3a6b (anonymous namespace)::NominalTypeMemberRefRValueEmitter::emit(swift::Lowering::SILGenFunction&) (/usr/bin/swift+0xcb3a6b) #10 0x0000000000caa3f0 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xcaa3f0) #11 0x0000000000c9b8a8 swift::Lowering::SILGenFunction::emitRValueAsSingleValue(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xc9b8a8) #12 0x0000000000d283ed (anonymous namespace)::ArgEmitter::emit(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) (/usr/bin/swift+0xd283ed) #13 0x0000000000d28e34 (anonymous namespace)::ArgEmitter::emitExpanded

stderr.txt

https://file.io/F00CkH

@swiftbot

import Foundation struct User: Codable { static var name: String { return "user" } var name: String } let u = User(name: "hoge") let a = try! JSONEncoder().encode(u) print(String.init(data: a, encoding: .utf8))

1

Swift version 4.1 (swift-4.1-RELEASE)

2:28 AM

/usercode/main.swift:10:7: warning: expression implicitly coerced from 'String?' to Any print(String.init(data: a, encoding: .utf8)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usercode/main.swift:10:14: note: provide a default value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ?? <#default value#> /usercode/main.swift:10:14: note: force-unwrap the value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! /usercode/main.swift:10:14: note: explicitly cast to Any with 'as Any' to silence this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ as Any swift: /home/buildnode/jenkins/workspace/oss-swift-4.1-package-linux-ubuntu-16_04/swift/lib/SILGen/RValue.cpp:533: void swift::Lowering::RValue::forwardInto(swift::Lowering::SILGenFunction &, swift::SILLocation, swift::Lowering::Initialization *) &&: Assertion `isPlusOne(SGF) && "Can not forward borrowed RValues"' failed. /usr/bin/swift[0x3f24d54] /usr/bin/swift[0x3f25096] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f582f9c3390] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f582e102428] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f582e10402a] /lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7f582e0fabd7] /lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f582e0fac82] /usr/bin/swift[0xcd7ac0] /usr/bin/swift[0xccee92] /usr/bin/swift[0xc5450f] /usr/bin/swift[0xccf200] /usr/bin/swift[0xcf6d60] /usr/bin/swift[0xcf55ab] /usr/bin/swift[0xcf4e80] /usr/bin/swift[0xce08fc] /usr/bin/swift[0xce8a68] /usr/bin/swift[0xca1799] /usr/bin/swift[0xc9dd66] /usr/bin/swift[0xc79460] /usr/bin/swift[0xc6eff8] /usr/bin/swift[0xcf6b1a] /usr/bin/swift[0xcf74c6] /usr/bin/swift[0xcf620a] ...

2:28 AM

stderr.txt

2.76 KB

あれ？手元では以下の出力でしたが Optional("{\"name\":\"user\"}")

@swiftbot

import Foundation struct User: Codable { var name: String } let u = User(name: "hoge") let a = try! JSONEncoder().encode(u) print(String.init(data: a, encoding: .utf8))

1

Swift version 4.1 (swift-4.1-RELEASE)

2:29 AM

Optional("{\"name\":\"hoge\"}")

2:29 AM

/usercode/main.swift:9:7: warning: expression implicitly coerced from 'String?' to Any print(String.init(data: a, encoding: .utf8)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usercode/main.swift:9:14: note: provide a default value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ?? <#default value#> /usercode/main.swift:9:14: note: force-unwrap the value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! /usercode/main.swift:9:14: note: explicitly cast to Any with 'as Any' to silence this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ as Any

@swiftbot

import Foundation struct User: Codable { static var name: String { return "user" } var name: String } let u = User(name: "hoge") let a = try! JSONEncoder().encode(u) print(String.init(data: a, encoding: .utf8))

1

Swift version 4.1 (swift-4.1-RELEASE)

2:30 AM

/usercode/main.swift:10:7: warning: expression implicitly coerced from 'String?' to Any print(String.init(data: a, encoding: .utf8)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usercode/main.swift:10:14: note: provide a default value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ?? <#default value#> /usercode/main.swift:10:14: note: force-unwrap the value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! /usercode/main.swift:10:14: note: explicitly cast to Any with 'as Any' to silence this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ as Any swift: /home/buildnode/jenkins/workspace/oss-swift-4.1-package-linux-ubuntu-16_04/swift/lib/SILGen/RValue.cpp:533: void swift::Lowering::RValue::forwardInto(swift::Lowering::SILGenFunction &, swift::SILLocation, swift::Lowering::Initialization *) &&: Assertion `isPlusOne(SGF) && "Can not forward borrowed RValues"' failed. /usr/bin/swift[0x3f24d54] /usr/bin/swift[0x3f25096] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fc32e218390] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7fc32c957428] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc32c95902a] /lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7fc32c94fbd7] /lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7fc32c94fc82] /usr/bin/swift[0xcd7ac0] /usr/bin/swift[0xccee92] /usr/bin/swift[0xc5450f] /usr/bin/swift[0xccf200] /usr/bin/swift[0xcf6d60] /usr/bin/swift[0xcf55ab] /usr/bin/swift[0xcf4e80] /usr/bin/swift[0xce08fc] /usr/bin/swift[0xce8a68] /usr/bin/swift[0xca1799] /usr/bin/swift[0xc9dd66] /usr/bin/swift[0xc79460] /usr/bin/swift[0xc6eff8] /usr/bin/swift[0xcf6b1a] /usr/bin/swift[0xcf74c6] /usr/bin/swift[0xcf620a] ...

2:30 AM

stderr.txt

2.76 KB

同名のstatic varがあるとCodableが壊れまくるな

やばい

@tarunon 昨日のはこれで init の網羅検査が壊れる話だったんだけど

2:30 AM

そっちはcomputed propertyにすれば解決したんだが

Vaporがstatic let nameを要求しつつDBにもnameというカラムがあるのでやばひ

今度は今日、encodeするときにstaticなcomputed propertyで上書きされるので

2:31 AM

どうにもならない、Linuxにおいては実行時クラッシュ

2:31 AM

@swift-4.0.3

import Foundation struct User: Codable { static var name: String { return "user" } var name: String } let u = User(name: "hoge") let a = try! JSONEncoder().encode(u) print(String.init(data: a, encoding: .utf8))

stderr:

main.swift:10:7: warning: expression implicitly coerced from 'String?' to Any print(String.init(data: a, encoding: .utf8)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ main.swift:10:14: note: provide a default value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ?? <#default value#> main.swift:10:14: note: force-unwrap the value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! main.swift:10:14: note: explicitly cast to Any with 'as Any' to silence this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ as Any TYPE MISMATCH IN ARGUMENT 0 OF APPLY AT expression at [<invalid loc> - <invalid loc>] argument value: %1 = argument of bb0 : $User // user: %3 parameter type: $@thin User.Type #0 0x0000000003ae91b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/swift+0x3ae91b8) #1 0x0000000003ae98f6 SignalHandler(int) (/usr/bin/swift+0x3ae98f6) #2 0x00007f92b5289390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007f92b39c8428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #4 0x00007f92b39ca02a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #5 0x0000000000c648e5 swift::Lowering::SILGenFunction::emitApply(std::unique_ptr<swift::Lowering::ResultPlan, std::default_delete<swift::Lowering::ResultPlan> >&&, swift::Lowering::ArgumentScope&&, swift::SILLocation, swift::Lowering::ManagedValue, llvm::ArrayRef<swift::Substitution>, llvm::ArrayRef<swift::Lowering::ManagedValue>, swift::Lowering::CalleeTypeInfo const&, swift::Lowering::ApplyOptions, swift::Lowering::SGFContext) (/usr/bin/swift+0xc648e5) #6 0x0000000000c66f09 (anonymous namespace)::CallEmission::apply(swift::Lowering::SGFContext) (/usr/bin/swift+0xc66f09

stderr.txt

https://file.io/eAxWMe

4.0もだめか

最近モデル周りガチャガチャやってるから

う〜む

エンコードもテスト書いておくか、あぶねー

普通はinstance propertyしか使わないから気づかなかったが

2:32 AM

class/static propertyとの絡みがヤバそうだ

2:32 AM

vapor がそれでモデルのテーブル名とかをコントロールしてて

2:32 AM

テーブル名APIとしてのnameと、カラムのnameがぶつかってるんだよねｗ

1

ハハァ

2:33 AM

死ぬじゃん

死ぬｗ

てかテーブル名をnameは衝突するからやめれ

いや、

vaporが

static var name { "user" } var name = "tarunon"

2:33 AM

こういうこと。

vaporのapiがわるい

そうかなあｗ

static var nameはあかんやろ

nameが一般的すぎないかとはちょっと思ってましたが

でも型.nameだからまさにそうだと思うんだけどな

テーブル型とCodable用の型わけるしかないねぇ

そうするとVaporのクエリ発行機能が死ぬね

マジかよ

RonRのActiveRecordみたいなもんだから

そういう仕組みかぁ

それ諦めちゃったらINSERTとかシコシコ書く状態になるだけ

何とかできないかなァ

まあ一番簡単なのは

static varをcomputeにしたらどうなる

テーブルのカラム名を name から name_ にするとかね

もうやってたわ

static varをcomputeにすると、encode結果になぜかstaticの方が来る

2:36 AM

storedにするとinitができない。

protocol extensionに追い出す

struct User: Codable { static var name: String { return "user" } var name_: String var name: String { return name_ } }

2:38 AM

こうやってテーブルのカラム名を name_ にすれば

2:38 AM

衝突回避できそう。

敗北感高い

コンパイラが直るまでの処置やな

static varをprotocol extensionに切り出して

2:38 AM

tablenameを定義するprotocolを作る

1

UserProtocolを追加するってこと？

そう

@swiftbot

import Foundation protocol UserProtocol { static var name: String { get } } extension UserProtocol { static var name: String { return "user" } } struct User: UserProtocol, Codable { var name: String } let u = User(name: "hoge") let a = try! JSONEncoder().encode(u) print(String.init(data: a, encoding: .utf8))

1

Swift version 4.1 (swift-4.1-RELEASE)

2:39 AM

Optional("{\"name\":\"hoge\"}")

2:39 AM

/usercode/main.swift:17:7: warning: expression implicitly coerced from 'String?' to Any print(String.init(data: a, encoding: .utf8)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usercode/main.swift:17:14: note: provide a default value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ?? <#default value#> /usercode/main.swift:17:14: note: force-unwrap the value to avoid this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! /usercode/main.swift:17:14: note: explicitly cast to Any with 'as Any' to silence this warning print(String.init(data: a, encoding: .utf8)) ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ as Any

勝ち

草

感謝してもいいのよ

hogeが出てるからencodeもあってるな

2:41 AM

このバグを回避するためにprotocolが一個増えるの・・・

カラム変えるよりはマシ

微妙なラインだ

2:41 AM

カラムは別に見えないしマイグレーションで管理できるんや

あとあと修正されて切り戻しを考えるとテーブルまで変更が及んでないほうが楽だと思いますね

Optionalの待避と似たようなもんや

2:44 AM

ビジビリティ気になるならアンスコスタートにしとけばok

まあそうだね、UserProtocolとして何か適切に抽象化してるわけじゃないただの回避だから

@swiftbot struct DBUser: Codable { static var name: String = "user" var name: String }

1

Swift version 4.1 (swift-4.1-RELEASE)

_User とかがよさそうだな。

2:47 AM

@swift-4.0.3 struct DBUser: Codable { static let name: String = "user" var name: String }

exit status: 134 with stderr:

swift: /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/llvm/include/llvm/Support/Casting.h:236: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = swift::MetatypeType, Y = swift::TypeBase]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. #0 0x0000000003ae91b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/swift+0x3ae91b8) #1 0x0000000003ae98f6 SignalHandler(int) (/usr/bin/swift+0x3ae98f6) #2 0x00007f6080f25390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007f607f664428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #4 0x00007f607f66602a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #5 0x00007f607f65cbd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7) #6 0x00007f607f65cc82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #7 0x000000000054b72c (/usr/bin/swift+0x54b72c) #8 0x0000000000bf54a5 swift::Lowering::SILGenFunction::emitRValueForStorageLoad(swift::SILLocation, swift::Lowering::ManagedValue, swift::CanType, bool, swift::AbstractStorageDecl*, swift::Lowering::RValue, llvm::ArrayRef<swift::Substitution>, swift::AccessSemantics, swift::Type, swift::Lowering::SGFContext, bool) (/usr/bin/swift+0xbf54a5) #9 0x0000000000c08a02 (anonymous namespace)::NominalTypeMemberRefRValueEmitter::emit(swift::Lowering::SILGenFunction&) (/usr/bin/swift+0xc08a02) #10 0x0000000000c00bc6 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xc00bc6) #11 0x0000000000bf7a5c swift::Lowering::SILGenFunction::emitRValueAsSingleValue(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xbf7a5c) #12 0x0000000000c7c137 (anonymous namespace)::ArgEmitter::emit(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) (/usr/bin/swift+0xc7c137) #13 0x0000000000c7d6eb (anonymous namespace)::ArgEmitter::e

stderr.txt

https://file.io/JrxRVV

static let だとコンパイルできないけどstatic varはいけるのか。

encodeはやっぱりこわれてますけどね

二個報告しました https://bugs.swift.org/browse/SR-7536 https://bugs.swift.org/browse/SR-7537

2

とりあえず当面は @tarunon さんの方法で回避できそうです。ありがとうございました。

1

@t.ae ↓これじゃダメ？ @swiftbot

import Foundation struct DBUser: Codable { static let name: String = "user" var name: String init(name: String) { self.name = name } private enum CodingKeys : CodingKey { case name } init(from decoder: Decoder) throws { let container = try decoder.container(keyedBy: CodingKeys.self) let name = try container.decode(String.self, forKey: .name) self.init(name: name) } func encode(to encoder: Encoder) throws { var container = encoder.container(keyedBy: CodingKeys.self) try container.encode(name, forKey: .name) } } let u = DBUser(name: "hoge") let a = try! JSONEncoder().encode(u) print(String.init(data: a, encoding: .utf8)!)

1

Swift version 4.1 (swift-4.1-RELEASE)

3:27 AM

{"name":"hoge"}

init(from Decoder)を手書きする方で避けるのか。

うん、多分これって自動生成が壊れてるだけだから

たしかにいけるけどめんどくさいですね

（そうじゃなかったら Codable にとどまらない問題があるだろうし）

修正後も変更が不要という意味ではいいですね

治ったら自動生成部分消すだけでいい。

あ〜

まぁ別にprotocol切っても修正は不要か。

いや

3:29 AM

protocol切る場合はstatic varの実装をコピペして戻す必要はある

3:29 AM

消すだけよりは手間がかかる (edited)

3:30 AM

でもfromDecoderとencodeは徹底して書かないようにしてるからCodingKeysからやるのめんどそうだなと思った

3:30 AM

でも変な事はしてないという意味では良いですね

3:30 AM

手書きしてるだけで。

同じ自動生成でも↓はできた。興味深い。 @swiftbot

import Foundation struct DBUser: Equatable { static let name: String = "user" var name: String } let u1 = DBUser(name: "hoge") let u2 = DBUser(name: "fuga") print(u1 == u2)

(edited)

2

Swift version 4.1 (swift-4.1-RELEASE) (edited)

3:32 AM

false (edited)

それってuserとhogeのどっちで見てるんでしょう？

static のほうで比較してたりして

u == u だとわからなくないですか？

swift-DEVELOPMENT-SNAPSHOT-2018-04-18-a Swift version 4.2-dev (LLVM d14a2b25f2, Clang da1edea3f7, Swift ac061632b2)

3:33 AM

true

3:33 AM

swift-DEVELOPMENT-SNAPSHOT-2018-04-18-a Swift version 4.2-dev (LLVM d14a2b25f2, Clang da1edea3f7, Swift ac061632b2)

3:33 AM

false

修正してみた。

falseになったからちゃんと動いてるか。

Codable と Equatable の自動生成周りのコード見比べてみたらおもしろいことがわかりそう。

Equatableの場合は全件比較の可能性もないですかね？ Codableの場合は名前衝突してstaticのほうだけのこってしまってるとか

https://github.com/apple/swift/blob/master/lib/Sema/DerivedConformanceEquatableHashable.cpp

swift - The Swift Programming Language

3:35 AM

そこらへんはあまり抽象化されてないから

3:35 AM

フィールドのイテレーションロジックは

3:35 AM

生成器ごとに手書きされてるよ

3:35 AM

https://github.com/apple/swift/blob/master/lib/Sema/DerivedConformanceCodable.cpp#L878

swift - The Swift Programming Language

3:36 AM

型のDeclContextからメンバを拾ってイテレートするところで

3:37 AM

static fieldかどうかのチェックを忘れてる箇所があると予想

3:42 AM

https://github.com/apple/swift/blob/master/include/swift/AST/Decl.h#L2451

swift - The Swift Programming Language

3:45 AM

https://github.com/apple/swift/blob/master/include/swift/AST/Decl.h#L4707

swift - The Swift Programming Language

3:47 AM

swift - The Swift Programming Language

3:47 AM

こっちか。

3:47 AM

class VarDeclに .isStatic() がある

対応してるのかわからないけど、↓だと stored property だけとってる？ https://github.com/apple/swift/blob/master/lib/Sema/DerivedConformanceEquatableHashable.cpp#L512

[codable] When generated encode for a property, distinguish in bet...

swift - The Swift Programming Language

auto storedProperties = structDecl->getStoredProperties(/*skipInaccessible=*/true);

3:50 AM

おお。

3:51 AM

ああそうか

3:51 AM

CodableはCodingKeysをベースに回してるから

3:51 AM

ちょっとスタイルが違うのか。

3:52 AM

getStoredPropertiesの中身を見れば、何に気をつければいいかわかりそうだ。

Enumを生成勝手に出来ないようにする方法って無いですよね

7:02 AM

structはinitをpublicにしなければ勝手に生成出来ないけど

無さそう

フーム

7:10 AM

enumをwrapするstructを作ってそれのinitを隠蔽して外側のstructのみが証明されたものという扱いにしないといけないか

7:11 AM

availablityに修飾子つけれるようになればcase自体をdeprecatedとか出来るのかしら

enum A { case hoge(String) } protocol AP {} extension AP where Self == A { static var hoge: (String) -> Self { fatalError() } } extension A: AP {} A.hoge("aa")

7:16 AM

生成できなくなった

同名static funcでshadowだと・・・

これenumの中に定義しようとするとredeclarationで弾かれるんですけど、protocol exだとできるんですよね

@swift-4.1.3

enum A { case hoge(String) } protocol AP {} extension AP where Self == A { static var hoge: (String) -> Self { fatalError() } } extension A: AP {} A.hoge("aa")

exit status: 1 with stderr:

main.swift:14:1: error: ambiguous use of 'hoge' A.hoge("aa") ^ main.swift:2:10: note: found this candidate case hoge(String) ^ main.swift:7:16: note: found this candidate static var hoge: (String) -> Self { ^

staticのはちょうどこれが直してるところかな https://github.com/apple/swift/pull/16143

…n static/instance properties. Previously, we just took the first match so: We would try to emit a metatype lookup of the property but had prepared an instance lookup. Could get the wrong type if ...

1:15 AM

4.2で直りそう

1

class Class { static lazy var value: Int = { preconditionFailure() }() } とするとalready-lazyと怒られたので

10:11 AM

class Class { static var value: Int = { preconditionFailure() }() } Class.value = 1 こんな感じで定義したのですが、どうも代入前にpreconditionFailureが呼ばれているようなのですがこれはどうしてなのでしょう…？

10:11 AM

valueのsetterで代入前に初期化しているような挙動になってしまう

クロージャで囲ってるのはNeverがBottom Typeじゃないからか。。。

なるほど

10:14 AM

Swiftのグローバル・Static変数のlazy化は

10:15 AM

あくまで最適化の範疇で勝手にやっていることであって

10:15 AM

メンタルモデルとしては忘れて良いもので

10:15 AM

という意味では、 Class.value = 初期値 は

10:15 AM

実行されていることになるんじゃないですかね？

10:16 AM

だから、 Class.value への最初のアクセスが発生した時点で、初期値の代入処理が実行、 (この場合 preconditionfailure) その後で実際のアクセス（この場合1の代入 )

10:17 AM

lazyをつけた場合は、これは、readするときに実行されるものって決まってるので、若干意味が違うと思う

10:17 AM

意味が違うから書き分ける事に合理性があるのに、already lazyってエラーになっていることがおかしいように思う。

コンパイラエラーのalready lazyは所謂@lazyとは意味合いが違うということですね、なるほど

10:21 AM

ちょっとこの辺り気になって上記のvalueをxxxxxxxxxxとリネームした状態でSILを吐いてみたのですが、

// static Class.xxxxxxxxxx.setter sil hidden [transparent] @_T04main5ClassC10xxxxxxxxxxSivsZ : $@convention(method) (Int, @thick Class.Type) -> () { // %0 // users: %8, %2 // %1 // user: %3 bb0(%0 : $Int, %1 : $@thick Class.Type): debug_value %0 : $Int, let, name "value", argno 1 // id: %2 debug_value %1 : $@thick Class.Type, let, name "self", argno 2 // id: %3 // function_ref Class.xxxxxxxxxx.unsafeMutableAddressor %4 = function_ref @_T04main5ClassC10xxxxxxxxxxSivau : $@convention(thin) () -> Builtin.RawPointer // user: %5 %5 = apply %4() : $@convention(thin) () -> Builtin.RawPointer // user: %6 %6 = pointer_to_address %5 : $Builtin.RawPointer to [strict] $*Int // user: %7 %7 = begin_access [modify] [dynamic] %6 : $*Int // users: %9, %8 assign %0 to %7 : $*Int // id: %8 end_access %7 : $*Int // id: %9 %10 = tuple () // user: %11 return %10 : $() // id: %11 } // end sil function '_T04main5ClassC10xxxxxxxxxxSivsZ'

%5 = apply %4() : $@convention(thin) () -> Builtin.RawPointer // user: %6 ここで代入前に初期化(preconditionFailure)されてしまっているということなのでしょうか…？ SIL全然読めないのでついていけなくなったらすいません

public func undefined<T>(file: StaticString = #file, line: UInt = #line) -> T { fatalError("undefined", file: file, line: line) } class Class { class StaticStorage { lazy var value: Int = undefined() static let shared = StaticStorage() } static var value: Int { get { return StaticStorage.shared.value } set { StaticStorage.shared.value = newValue } } } // 代入前にreadするとクラッシュ // print(Class.value) Class.value = 3 print(Class.value)

(edited)

10:22 AM

とりあえずやりたいことはできた↑

10:27 AM

ですね

10:27 AM

こっちでもSIL吐いて読んでみたんですけど

10:30 AM

セッター _T01a5ClassC5valueSivsZ ストレージを取得する関数 _T01a5ClassC5valueSivau この中に、 "once" ってbuildinコマンドの呼び出しがある そのonceに渡されている関数。 globalinit_33_EFF83A1F47B777EA672D48C97C71346F_func0 その中で呼ばれてる関数 _T01a5ClassC5valueSivpZfiSiycfU_ この中に、preconditionFailureの呼び出しがある。 _T0s19preconditionFailures5NeverOSSyXK_s12StaticStringV4fileSu4linetFfA_

(edited)

10:32 AM

マングリングの Sivau で検索してみたら、 lazy とか global とか書いてあるのがいろいろでてきた。 https://github.com/apple/swift/search?utf8=✓&q=Sivau&type=

ありがとうございます、追えました。確かにpreconditionFailureがbegin_access前に呼ばれていました。（Sivauがちょっと何ものなのかまだ分かってないですが…）

11:11 AM

%4 = function_ref @_T04main5ClassC10xxxxxxxxxxSivau : $@convention(thin) () -> Builtin.RawPointer // user: %5 %5 = apply %4() : $@convention(thin) () -> Builtin.RawPointer // user: %6 %6 = pointer_to_address %5 : $Builtin.RawPointer to [strict] $*Int // user: %7 %7 = begin_access [modify] [dynamic] %6 : $*Int // users: %9, %8

代入先のアドレスを取得するために初期化しているような感じなんですね

https://github.com/apple/swift/blob/c8b886fd7d3f6e19d078adf31b10b0e2f90e1d11/docs/ABI/Mangling.rst

https://github.com/apple/swift/blob/master/include/swift/AST/TypeNodes.def#L108-L122

swift - The Swift Programming Language

1

11:17 AM

Sivauはここ読めば解読できるかも。

i Int v variable a mutable addressor u unsafe addressor っぽい。

11:28 AM

Sがわからーん

11:31 AM

any-generic-type ::= 'S' KNOWN-TYPE-KIND

11:31 AM

このSだろうか？

11:32 AM

でもジェネリックって書いてあるし関係なさそう

any-generic-type ::= 'S' KNOWN-TYPE-KIND // known nominal type substitution KNOWN-TYPE-KIND ::= 'i' // Swift.Int Sは単なる組み込み型の接頭文字だと思われます。

12:04 PM

AST でいうところの AnyGenericType は全ての NominalType の親なので、非常に範囲広いです。

なるほどなるほど

Support synthesis of protocol conformances (including conditional ...

swift - The Swift Programming Language

ジェネリクスの方のgenericじゃなくてそのままの意味か

これそもそも、setter呼んでるだけなのに値代入されるのなぞですよね。意図した動作なのか、意図してないけど妥協されている動作なのか、どちらでしょう。未定義なのかどうかだけでも気になる。

文書は見かけてないけど、普通のローカル変数と対比して考えれば、 (1)の代入が(2)より先に発生するのは自然だと思います。 var a: Int = { preconditionFailure() }() // (1) a = 3 // (2)

lazyなインスタンス変数なら、クロージャの中身は呼ばずにsetterを呼び出せるので、仕様上lazyであるstatic変数だと出来ない仕様になっているのは謎だなぁ、と思いまして… ローカル変数はlazyじゃないですしね… class Hoge { lazy var a: Int = { preconditionFailure() }() } let h = Hoge() h.a = 1 print(h.a) (edited)

意味が違うから書き分ける事に合理性があるのに、already lazyってエラーになっていることがおかしいように思う。

これに同意で、とりあえず bugs.swift.org にイシュー投げて反応見るっていうのが良いと思いますよ。

@malt03 はい、なので「static変数がlazy化される」ときのlazyと、構文として lazy を書いた時のlazyの概念は別物だと思います。

10:43 AM

別物なのに、同時指定が怒られるコンパイラがおかしい、と考えるか、同時指定ができない同じものなのに、挙動が違うのがおかしい、と考えるかは、2択ありますけど (edited)

10:45 AM

static変数のlazy化は、見た目には普通の初期値代入なので、初期済み変数への代入よりも事前に、初期値の構築の際に生じる副作用が生じていないと、おかしいと思うので、現在の振る舞いが正しいと思います。

初期値の構築の際に生じる副作用が生じていないと、おかしいと思う

ただしいつ起きるかは undefined という。

構文としてのlazyは「最初のread時に値が構築される」で、 static変数のlazy化は「初期値の代入がギリギリまで遅延される」かなと。

undefined というよりは unpredictable か。 (edited)

似たような、スタティックスコープの初期化順の問題は他の言語にもあって、

10:50 AM

C++だとmain突入前に全て実行、main終了後に全てdestruct Javaだと、クラスファイルロード時にそのクラスファイルに関して全て実行だった気がする。

10:51 AM

Swiftの場合その変数ごとになってるっぽいのでそのどちらよりも遅延しえて、たとえロードされたパッケージに定義されていたとしても、アクセスされない変数がアプリケーション終了時まで一度も初期化されない、可能性がある気がする。例のごとく規格とかは厳密に決まって無さそうだけど。 (edited)

bugs書こうと思ったけどこのマシンがまだローシエラだ・・・

https://bugs.swift.org/browse/SR-1178 既存発見した。

11:16 AM

This is currently by design, but it might be worth changing the design.

となると Evolution 案件ですね。 (edited)

https://github.com/apple/swift/pull/16376 Extension で Codable の諸々自動生成が効かない問題が解決されそうです。

This works for Equatable, Hashable, Encodable, Decodable (and thus Codable), and CaseIterable. For instance, struct Foo<T> { var x: T } extension Foo: Equatable where T: Equatable {} Fix...

2

https://bugs.swift.org/browse/SR-6803 同一ファイル内に限り、ですかね。 (edited)

この前 @Taketo Sano さんが困ってた自作型の Conditional Conformance & Codable 自動生成はできるようになりそうですね。

init(from decoder: Decoder) の private var に対する assign がエラーになりそうな予感。

2:52 AM

https://github.com/apple/swift/pull/16376/files#diff-01a6eb231899c107eafd479a7ffe09f7R376 シンプルな enum に対する Equatable,Hashable だけは別ファイルでもいけるっぽいですね。 (edited)

Support synthesis of protocol conformances (including conditional ...

This works for Equatable, Hashable, Encodable, Decodable (and thus Codable), and CaseIterable. For instance, struct Foo<T> { var x: T } extension Foo: Equatable where T: Equatable {} Fix...

2:57 AM

ってその辺は元々暗黙でconformしているやつか。

おぉ…！

Swift の Bool が enum じゃなく struct なのって何か理由があるんでしたっけ？↓で良さそうなのに。 enum Bool { case true case false }

昔はcaseは大文字だったから enum Bool { case True, case False } になるのかな

にしても、 ExpressibleByBooleanLiteral （昔の BooleanLiteralConvertible ）で true, false からマッピングすればいいだけだったはずだからなぁ。

enumになってたほうが

4:30 AM

フラグの組み合わせをswitchで網羅できたりして便利？

4:30 AM

なってない理由は無くて誰も気がついてないような気がする（論点として見たことがない

switch網羅はいまもできないですっけ？

できるんだっけ、なんでできるんだ？

https://github.com/apple/swift/blob/master/docs/archive/LangRefNew.rst#bool-true-false 議論されたことが無いということはないようです。

swift - The Swift Programming Language

Bool, true, false // Bool is a simple enum. enum Bool { true, false } // Allow true and false to be used unqualified. var true = Bool.true var false = Bool.false

4:32 AM

お

@swiftbot

let a = false let b = true switch (a, b) { case (true, true): break case (true, false): break case (false, true): break case (false, false): break }

1

t.ae

let a = false let b = true switch (a, b) { case (true, true): break case (true, false): break case (false, true): break case (false, false): break }

Version:

swift-4.1.1-RELEASE

Output:

Error:

なんかbotがオシャレになってるｗ (edited)

4:34 AM

@swiftbot

let a = false let b = true switch (a, b) { case (true, true): break case (true, false): break case (false, true): break }

1

omochimetaru

let a = false let b = true switch (a, b) { case (true, true): break case (true, false): break case (false, true): break }

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:4:1: error: switch must be exhaustive switch (a, b) { ^ /usercode/main.swift:4:1: note: add missing case: '(false, false)' switch (a, b) { ^

網羅性検査はされるのか。

4:35 AM

enumだったら、 case (.true, .true): ？

特別扱いなんじゃない？

Bool は特別扱いですね。

うーんまあいいのか、Intも特別扱いがそのうちされたら嬉しいし。

https://github.com/apple/swift/blob/d3f2e3816afdd05d679919271a3fdb79c092e93c/stdlib/core/Bool.swift oneof っていうのが存在した時代。

Adjust test cases. · apple/swift@fad8747

swift - The Swift Programming Language

でたonenof

4:38 AM

しかも最初はoneofだったのか！

なんで enum じゃなかったんだろう？？

ADTを意識してた？

enum とは別物？

ってかこのconstructor() { } ってのkotlinっぽいな。

Rust にインスパイアされたって話からすると enum が自然そうなのに。

func __equal__(rhs: Bool) -> Bool { pythonみたいなやつある・・・ (edited)

この後このmassiveなコミットでガッと書き換えられたので、経緯は追えないですね。 https://github.com/apple/swift/commit/fad874708e05cff56aec5587a4b0f49cdadc6d11

Swift SVN r17964

1

https://github.com/apple/swift/pull/16376

Support synthesis of protocol conformances (including conditional ...

This works for Equatable, Hashable, Encodable, Decodable (and thus Codable), and CaseIterable. For instance, struct Foo<T> { var x: T } extension Foo: Equatable where T: Equatable {} Fix...

1:07 AM

Equatableの自動実装が条件付きエクステンションでもできるようになった

1:08 AM

最近Codableでこれを踏んだような気がする本体に付けないとダメなのかーって

https://forums.swift.org/t/amendment-to-se-0185-synthesis-of-conformances-declared-on-same-file-extensions/12530

Amendment to SE-0185: Synthesis of conformances declared on same-f...

The core team has approved an amendment to SE-0185 "Synthesizing Equatable and Hashable conformance to allow synthesis of conformances declared on same-file extensions. For example, the following is now well-formed, and will synthesize a conditio...

10:56 AM

朝のやつ、仕様変更したぜってアナウンス来てた。

10:57 AM

プロポザルレビューのタグがついてるけど

↓解決された

https://bugs.swift.org/browse/SR-7120

Equatableの自動実装、エクステンションだと再帰的になってるとできないの惜しい (edited)

1:02 PM

@swiftbot --version=latest indirect enum A { case a(A) } extension A: Equatable {} (edited)

1

(edited)

kateinoigakukun

indirect enum A { case a(A) } extension A: Equatable {}

Version:

swift-4.2-DEVELOPMENT-SNAPSHOT-2018-05-08-a

Output:

Error:

/usercode/main.swift:5:1: error: implementation of 'Equatable' cannot be automatically synthesized in an extension extension A: Equatable {} ^

@swiftbot --version=latest indirect enum A: Equatable { case a(A) } (edited)

1

(edited)

kateinoigakukun

indirect enum A: Equatable { case a(A) }

Version:

swift-4.2-DEVELOPMENT-SNAPSHOT-2018-05-08-a

Output:

Error:

これはできるのか

ところでその A 無限再帰してインスタンス作れなくないですか？

あー、確かにそうですね

2:15 PM

@swiftbot —version=latest enum A { case a([A]) } extension A: Equatable {} (edited)

1

(edited)

kateinoigakukun

enum A { case a([A]) } extension A: Equatable {}

Version:

swift-4.2-DEVELOPMENT-SNAPSHOT-2018-05-08-a

Output:

Error:

/usercode/main.swift:5:1: error: implementation of 'Equatable' cannot be automatically synthesized in an extension extension A: Equatable {} ^

@swiftbot —version=latest enum A: Equatable { case a([A]) } (edited)

1

(edited)

kateinoigakukun

enum A: Equatable { case a([A]) }

Version:

swift-4.2-DEVELOPMENT-SNAPSHOT-2018-05-08-a

Output:

Error:

a([A]) だと indirect 要らなさそうですね

1

AがEquatable自動実装できるかどうかを調べる中で、aのAがEquatableか調べる必要があって〜、、、って感じで無限に続きそうですけど、これどうやって通してるんですかね (edited)

A : Equatable だから [A] : Equatable で case a([A]) も Equatable で、すべての case が Equatable なので A : Equatable を満たすので自動生成、ですかね？

最初のA : Equatableだから〜の部分は仮定ですか？ (edited)

はい。その仮定が正しいかを検証しているからその仮定の元で仮定が真であることが示されるみたいな？

数学的帰納法っぽい感じかな？

実際にコンパイラがどのような手順でやってるかは知らないので想像ですが・・・

ちょっと興味湧いてきたので読んでみます

1

https://forums.swift.org/t/string-interpolation-revamp-design-decisions/12624

1:09 AM

文字列展開をビルダーパターンにコンパイルする案バッファサイズ予測を付けて、個別のString結合するより速くなる

すでにそうなってるもんだと勝手に思ってました

気持ちはわかりますwJavaとかそうですしね。

ということは、今は単純に + で連結するのと同じ感じで動いているんですかね。

1:15 AM

文字列型に変換するところは別にして (edited)

1

1:17 AM

これか。 https://github.com/apple/swift/blob/a7ff0da33488b9050cf83df95f46e5b9aa2348d5/stdlib/public/core/StringInterpolation.swift#L28-L35

swift - The Swift Programming Language

まんまですね

@swiftbot extension String : Error {} func hoge() { do { throw "aaa" } catch { print("catch error: \(error)") } } hoge()

1

omochimetaru

extension String : Error {} func hoge() { do { throw "aaa" } catch { print("catch error: \(error)") } } hoge()

Version:

swift-4.1.1-RELEASE

Output:

catch error: aaa

Error:

catchって単体で書くと error って変数にエラーが入るの・・・・・・

@swiftbot

struct MyError: Error {} do { throw MyError() } catch is MyError { print("my error: \(error)") } catch { print("\(error)") }

1

t.ae

struct MyError: Error {} do { throw MyError() } catch is MyError { print("my error: \(error)") } catch { print("\(error)") }

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:5:24: error: use of unresolved identifier 'error' print("my error: \(error)") ^~~~~ Swift.Error:1:17: note: did you mean 'Error'? public protocol Error { ^ Swift.Mirror:1:15: note: did you mean 'Mirror'? public struct Mirror { ^

こっちにもいれてほしい

ごもっとも。

Swift 4.2 で導入される標準の Random って seed を与えられない？ https://github.com/apple/swift/blob/master/stdlib/public/core/Random.swift#L133-L157

https://forums.swift.org/t/se-0202-amendment-naming-of-the-standard-library-random-number-generator/12155

swift - The Swift Programming Language

RandomはRandomGeneratorってprotocolを満たす簡単実装のひとつにすぎないから

3:48 AM

端折られてても違和感は無いですね

3:48 AM

安全な乱数の場合シードできないので。

うん、そうなんだけど、標準で seed 与えられるものが提供された方が便利そう

3:48 AM

テストとかで再現させるのに、いちいち実装が必要だと大変

えっと、ランダムジェネレータって大きく２つあって

3:49 AM

CSPRNGなやつと、高速で再現性のあるやつ

3:49 AM

シードを与えられるのは後者で、セキュリティ目的で望ましいのは前者

3:49 AM

それで、「デフォルトのRandom」をどっちにするかって議論があって

3:50 AM

なんかいろいろ話されてるんだけど、名前ちゃんとつけようぜ、っていう別の提案議論も並行して今やってるので

3:50 AM

ちょっとどうなるかわかんない

なるほど。いずれにしても両方ほしい気が。

２つの両方の保守的な性質を満たすもの（安全でもないし再現性も取れない）

3:50 AM

にするってパターンもありえるかも？

3:51 AM

いずれかの性質が欲しい時は明示的にそのようなジェネレータを使う。

3:51 AM

はい、RndomNumberGeneratorはプロトコルだから (edited)

3:51 AM

具体的な型としてそれぞれ提供されるはず。

3:52 AM

public struct Random : RandomNumberGenerator {

3:52 AM

SE-0202 Amendment: Naming of the standard library random number ge...

The accepted proposal to add Random API to the standard library defines a single random source in the standard library. Users can create their own random sources by writing types that conform to the RandomNumberGenerator protocol. For convenience...

3:52 AM

このスレッド。

1

3:57 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md

https://gist.github.com/omochi/d674c2f6d2ecbf3ebf1cd63d6f1c0dd6

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

3:57 AM

The aspiration is that this RNG should be cryptographically secure, provide reasonable performance, and should be thread safe.

3:58 AM

cryptographically secureが should be って無意味に思う・・・

3:59 AM

must be じゃないなら、「稀にsecureでない」セキュリティバグを産みうるだけ

RC4がセキュアでなくなったようにセキュアの基準が変わる事があるので、must beは難しいのだと思います。

またその次の文にもあるように、そもそもセキュアな発生器を提供出来ないプラットホームに移植する可能性も考えて、その制限をつけられないという判断。

RandomNumberGeneratorという基本のプロトコルがmust beにできないという点は同意で、 should be といわずにばっさり not secure って定義しちゃうほうが事故がないと思いまして。

プロトコルじゃなくて、そのデフォルト実装である Random の話ですよね？定義が中途半端なのは同意します。

いえ、さっきの should be の文は Proposed Solution の Random Number Generator について述べられたセンテンスで、 Randomについてはそれのデフォルト実装だよ、としか書いてないような。

Random Number Generator の最初の文が "To kick this off, the standard library will provide a default RNG" なので、このセクション自体がデフォルト実装に関する話だという理解です。

なるほど

lldbについて質問です。Xcode上でswiftcのc++コードをデバッグしたいんですが、pコマンドを実行すると下記のエラーが出ます。Xcodeで開いているswiftcは--release-debuginfo -xでビルドしていて、実行時には-gオプションを付けて実行しています。swiftcを--debugでビルドすればlldbでデバッグできますか？

(lldb) p OutputFile error: Couldn't materialize: couldn't get the value of variable OutputFile: no location, value may have been optimized out error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression

はい、 RelWithDebInfo はデバッグ情報は保持されますが (edited)

10:51 AM

最適化自体は実行されてしまうため、しっかりデバッグしたいときは、デバッグビルドのほうがいいです。ただ、全部をデバッグビルドすると非常に遅いので、

10:53 AM

--release-debuginfo --debug-swift でstdlibや、llvmやclangなどの依存ライブラリは最適化しつつ、 swift/swiftc だけデバッグビルドに出来るので、そっちのほうがいいかもしれません。 (edited)

10:55 AM

この場合、ビルドディレクトリは build/Ninja-RelWithDebInfoAssert+swift-DebugAssert になります。

そうか、--debug-swiftがあるのか。ありがとうございます、さっそく試してみます！

なるほど、元の質問の答え自体は、デバッグはできる状態だけどリリースビルドではあるからデバッグできないシンボルが出る事はあるよ、って話か。

--debug-swiftでビルドしたXcodeプロジェクトならlldbでデバッグ出来るようになりました！これは革命だ！ありがとうございました。

当方Swift初心者なのですが、 NSRegularExpression にextensionでfailable initializer生やしたいだけでハマったのですが、これはできない？ protocol Foo { init?(string: String) } extension NSRegularExpression: Foo { // ??? }

7:15 AM

@objc のconstructorムズすぎで未だに雰囲気

init?(string: String)を書けば行けるんじゃないですか？

7:18 AM

あーrequiredとかで怒られるやつですか

ObjC関係ない気がする。

protocol Foo { init(string: String) } class Cat { init() {} } extension Cat : Foo { convenience init(string: String) { self.init() } }

↑できない。

7:24 AM

protocolで制約されるinitは、サブクラスにも生えている必要があるから

7:24 AM

required initとして実装する必要があるけど

7:25 AM

extensionにはrequired initをかけないので(なんでだっけ)

7:25 AM

final class + extension { convenience init } の形でしか通せない？ (edited)

7:26 AM

(final classならサブクラスは無いからそのクラスでinit呼べる事が保証できる)

protocolで制約されるinitは、サブクラスにも生えている必要があるから

required initとして実装する必要があるけど

7:28 AM

なるほど

間違ってる気もする。init自体はサブクラスにも暗黙に存在してるっけ？

NSObjectProtocol 継承してそうだから (edited)

7:29 AM

init自体は存在してるはず

7:30 AM

単に NSObject か

一般の話しでした。

class Animal { init(aaa: Int) {} } class Cat : Animal { init(bbb: Float) { super.init(aaa: 0) } } Cat.init(aaa: 0) // コンパイルエラー

7:31 AM

やっぱり、ただのinitは継承先で消えますね。

なるほどなー

class Animal { // requiredだと子にも定義が必要になる required init(aaa: Int) {} } class Cat : Animal { // これが必要 required init(aaa: Int) { super.init(aaa: 0) } init(bbb: Float) { super.init(aaa: 0) } } Cat.init(aaa: 0) // 当然OK

ですね

なのでそこから考えると、 protocol Foo は Animal が満たせば暗黙に Cat も満たされるわけだから、 Fooのinitを実装する側はrequiredでなければならない。 (edited)

明示的にrequiredで再実装したら行けるか見てみるか

それをやろうとすると

7:33 AM

extensionではrequired initはかけませ〜ん　ってエラーが出た。

うーん

サブクラスは外のモジュールで実装される事もあるから

7:34 AM

extensionで追加したinitがサブクラス側で考慮されない事はありえるから

7:34 AM

エラーになる理屈はわかるけどシンプルにやりたいことができない感じでモヤモヤしますな

NSRegularExpression を継承したクラスでラップしたらいけた

僕はどっちにしろ使いにくいのでRegexはラップしちゃってます。

7:36 AM

swift-regex.swift

protocol Foo { init?(string: String) } class SubRegExp: NSRegularExpression { override init(pattern: String, options: NSRegularExpression.Options = []) throws { try super.init(pattern: pattern, options: options) } convenience init?(string: String) { try? self.init(pattern: string, options: .caseInsensitive) } required init?(coder aDecoder: NSCoder) { fatalError("init(coder:) has not been implemented") } }

(edited)

7:37 AM

できた

7:37 AM

まじかよ

それはrequired initがextensionじゃなくてclass本体に書いたからOKですね

7:38 AM

required initだから SubRegExpのさらなる子どもたちは全員そのinitを持つからOK。

あ、Fooないじゃん

7:38 AM

protocol Foo { init?(string: String) } class SubRegExp: NSRegularExpression, Foo { override init(pattern: String, options: NSRegularExpression.Options = []) throws { try super.init(pattern: pattern, options: options) } convenience required init?(string: String) { try? self.init(pattern: string, options: .caseInsensitive) } required init?(coder aDecoder: NSCoder) { fatalError("init(coder:) has not been implemented") } }

7:38 AM

こうか

7:38 AM

なるほど〜

7:39 AM

うーん、こういうものなのか。勉強になりました

ああそうか、convenience requiredになるのか。他のinitを呼びたいから。

7:40 AM

@objc protocol Foo { optional init(string: String) } これでいけないかと思ったけど

error: iOSGround.playground:4:5: error: 'optional' cannot be applied to an initializer

optional init(string: String)

最近ライブラリ作って、 Foo に相当するプロトコルを提供してるんだけど、staticメソッドでやるか、initializerでやるかなやんで、initializerの方が良いか、と思ってこういうインターフェイスにしたら使えない場合が判明して困った

ああなるほど。

protocol Foo { static func decode(string: String) -> Self? } (edited)

7:43 AM

おとなしくこれにしておいた方が良い

static funcだと何が変わるんだろ　子にも生えるからか？

7:44 AM

required initはextensionにかけないのにstatic funcはextensionに書けるのも矛盾を感じる

うーん、でもやはりこれでも無理そう

それはそれで Self 周りの取扱でややこしくなりがち

protocol Bar { static func decode(string: String) -> Self? } extension NSRegularExpression: Bar { static func decode(string: String) -> NSRegularExpression? { return try? NSRegularExpression(pattern: string, options: .caseInsensitive) } }

error: method 'decode(string:)' in non-final class 'NSRegularExpression' must return Self to conform to protocol 'Bar' static func decode(string: String) -> NSRegularExpression? {

7:53 AM

めっちゃシンプルだから行けそうに見えてダメだにゃんだな〜

そうすると class SubRegex : NSRegularExpression { } があった場合に

7:54 AM

SubRegexには static func decode () -> SubRegex が生えてないといけないのに

そういう事なんでしょうね

実際にはNSRegularExpressionから継承された NSRegularExpression { static func decode() -> NSRegularExpression } になってて駄目なんですよね

意外と当然できるでしょ、と思ってた挙動が書いてみるとできないと言うことが判明した･･････

7:55 AM

まだまだ知らないことばかりだ

実装側の static func decode(string: String) -> NSRegularExpression? を -> Self にすると定義できるんだけど

理屈を聞けば納得

Self 型の式をreturnするのが難しい。self.init() などになる。 (selfはメタクラス)

7:57 AM

HimotokiとかArgoとかの同種のライブラリは

7:57 AM

decodeの返り値をSelfじゃなくてassociatedtype Decodedにすることで

7:57 AM

継承先であっても親の型としてデコードさせるように制限することで成り立たせてるけど

7:57 AM

それはそれで面倒なwhere句がそこらじゅうに必要になるのであった

@swift-4.1.3

import Foundation protocol Bar { static func decode(string: String) -> Self? } extension NSRegularExpression: Bar { static func decode(string: String) -> Self? { return try? .init(pattern: string, options: .caseInsensitive) } } let bar = NSRegularExpression.decode(string: ".*") print(bar! is Bar)

(edited)

truestderr:<stdin>:14:12: warning: 'is' test is always true print(bar! is Bar) ^ (edited)

いけてそう。なるほどなあ

8:17 AM

ありがとうございました

1

↓の message のデフォルト引数が "" じゃなくて String() になってるのってなんででしょう？ ExpressibleByStringLiteral 経由だと無駄な処理が走るから？

public func fatalError( _ message: @autoclosure () -> String = String(), file: StaticString = #file, line: UInt = #line ) -> Never {

https://github.com/apple/swift/blob/master/stdlib/public/core/Assert.swift#L193

https://github.com/apple/swift/blob/master/stdlib/public/core/StringObject.swift#L144

swift - The Swift Programming Language

とりあえず -O で同等の SIL が出力されることは確認しました。理由分からず。

1

6:30 AM

あ、うそ SIL 違いました

6:33 AM

= String()

// default argument 0 of DEFAULT_CONST(x:) sil non_abi @$S4test13DEFAULT_CONST1xySSyXK_tFfA_ : $@convention(thin) () -> @owned @callee_guaranteed () -> @owned String { bb0: // function_ref implicit closure #1 in default argument 0 of DEFAULT_CONST(x:) %0 = function_ref @$S4test13DEFAULT_CONST1xySSyXK_tFfA_SSyXAfu_ : $@convention(thin) () -> @owned String // user: %1 %1 = thin_to_thick_function %0 : $@convention(thin) () -> @owned String to $@callee_guaranteed () -> @owned String // user: %2 return %1 : $@callee_guaranteed () -> @owned String // id: %2 } // end sil function '$S4test13DEFAULT_CONST1xySSyXK_tFfA_' // implicit closure #1 in default argument 0 of DEFAULT_CONST(x:) sil shared [transparent] [thunk] [always_inline] @$S4test13DEFAULT_CONST1xySSyXK_tFfA_SSyXAfu_ : $@convention(thin) () -> @owned String { bb0: %0 = integer_literal $Builtin.Int64, -2305843009213693952 // user: %1 %1 = struct $UInt (%0 : $Builtin.Int64) // user: %2 %2 = value_to_bridge_object %1 : $UInt // users: %8, %3 %3 = struct $_StringObject (%2 : $Builtin.BridgeObject) // user: %6 %4 = integer_literal $Builtin.Int64, 0 // user: %5 %5 = struct $UInt (%4 : $Builtin.Int64) // user: %6 %6 = struct $_StringGuts (%3 : $_StringObject, %5 : $UInt) // user: %7 %7 = struct $String (%6 : $_StringGuts) // user: %9 strong_retain %2 : $Builtin.BridgeObject // id: %8 return %7 : $String // id: %9 } // end sil function '$S4test13DEFAULT_CONST1xySSyXK_tFfA_SSyXAfu_'

6:33 AM

= ""

// default argument 0 of EMPTY_LITERAL(x:) sil non_abi @$S4test13EMPTY_LITERAL1xySSyXK_tFfA_ : $@convention(thin) () -> @owned @callee_guaranteed () -> @owned String { bb0: // function_ref implicit closure #1 in default argument 0 of EMPTY_LITERAL(x:) %0 = function_ref @$S4test13EMPTY_LITERAL1xySSyXK_tFfA_SSyXAfu_ : $@convention(thin) () -> @owned String // user: %1 %1 = thin_to_thick_function %0 : $@convention(thin) () -> @owned String to $@callee_guaranteed () -> @owned String // user: %2 return %1 : $@callee_guaranteed () -> @owned String // id: %2 } // end sil function '$S4test13EMPTY_LITERAL1xySSyXK_tFfA_' // implicit closure #1 in default argument 0 of EMPTY_LITERAL(x:) sil shared [transparent] @$S4test13EMPTY_LITERAL1xySSyXK_tFfA_SSyXAfu_ : $@convention(thin) () -> @owned String { bb0: %0 = string_literal utf8 "" // user: %4 %1 = integer_literal $Builtin.Word, 0 // user: %4 %2 = integer_literal $Builtin.Int1, -1 // user: %4 // function_ref specialized String.init(_builtinStringLiteral:utf8CodeUnitCount:isASCII:) %3 = function_ref @$SSS21_builtinStringLiteral17utf8CodeUnitCount7isASCIISSBp_BwBi1_tcfCTf4nnnd_n : $@convention(thin) (Builtin.RawPointer, Builtin.Word, Builtin.Int1) -> @owned String // user: %4 %4 = apply %3(%0, %1, %2) : $@convention(thin) (Builtin.RawPointer, Builtin.Word, Builtin.Int1) -> @owned String // user: %5 return %4 : $String // id: %5 } // end sil function '$S4test13EMPTY_LITERAL1xySSyXK_tFfA_SSyXAfu_'

なるほど、じゃあやっぱりパフォーマンスのためなんですかね？

パフォーマンスを気にするなら "" を書いてはいけないってのはちょっと嫌だな・・・

-emit-ir までいくと完全に同等に。

; Function Attrs: norecurse nounwind readnone define hidden swiftcc { i8*, %swift.refcounted* } @"$S4test13DEFAULT_CONST1xySSyXK_tFfA_"() local_unnamed_addr #0 { entry: ret { i8*, %swift.refcounted* } { i8* bitcast ({ %swift.bridge*, i64 } ()* @"$S4test13DEFAULT_CONST1xySSyXK_tFfA_SSyXAfu_" to i8*), %swift.refcounted* null } } define linkonce_odr hidden swiftcc { %swift.bridge*, i64 } @"$S4test13DEFAULT_CONST1xySSyXK_tFfA_SSyXAfu_"() #1 { entry: %0 = tail call %swift.bridge* @swift_bridgeObjectRetain(%swift.bridge* inttoptr (i64 -2305843009213693952 to %swift.bridge*)) #2 ret { %swift.bridge*, i64 } { %swift.bridge* inttoptr (i64 -2305843009213693952 to %swift.bridge*), i64 0 } } ; Function Attrs: norecurse nounwind readnone define hidden swiftcc { i8*, %swift.refcounted* } @"$S4test13EMPTY_LITERAL1xySSyXK_tFfA_"() local_unnamed_addr #0 { entry: ret { i8*, %swift.refcounted* } { i8* bitcast ({ %swift.bridge*, i64 } ()* @"$S4test13EMPTY_LITERAL1xySSyXK_tFfA_SSyXAfu_" to i8*), %swift.refcounted* null } } define linkonce_odr hidden swiftcc { %swift.bridge*, i64 } @"$S4test13EMPTY_LITERAL1xySSyXK_tFfA_SSyXAfu_"() #1 { entry: %0 = tail call %swift.bridge* @swift_bridgeObjectRetain(%swift.bridge* inttoptr (i64 -2305843009213693952 to %swift.bridge*)) #2 ret { %swift.bridge*, i64 } { %swift.bridge* inttoptr (i64 -2305843009213693952 to %swift.bridge*), i64 0 } }

おお。

6:39 AM

-2305843009213693952 これなんだろう？空の文字列を現すシングルトンのアドレスかなにか？

6:40 AM

固定配置できるのか・・・？

ビットパターン E000_0000_0000_0000 なので https://github.com/apple/swift/blob/master/stdlib/public/core/StringObject.swift#L393 ?

6:52 AM

楽しい感じになってる。

ちなみに僕の結果は4.2なので、4.1だと全然違うと思います。

StringGutsとかなんかゴリゴリやってますもんね

6:54 AM

なるほど

6:56 AM

var smallUTF8Count: Int の実装を見ると、5..8ビットが文字列の長さ 4bitだから 0..15

6:57 AM

E000.... だから、smallUTF8Count = 0 なので

6:57 AM

空文字列か。

この辺りか。 https://github.com/apple/swift/commits/7764f64cf87b51d59eddd41e0cd6b13bd0cf5da3/stdlib/core/Assert.swift.gyb

8:37 AM

https://github.com/apple/swift/commit/7764f64cf87b51d59eddd41e0cd6b13bd0cf5da3#diff-3de648a1087356b522601f7eb52ba304

slavaが面白そうなツイートしてたから翻訳した。 https://twitter.com/slava_pestov/status/1001648778841964544 https://gist.github.com/omochi/e5cb7421679b122e551946864ec8d577

slava-tweet_2018-05-30.txt

So if a class conforms to a protocol with an init requirement, the corresponding init in the class must be required - unless the class is final

2:57 AM

まだ完全に理解していないのでコードで検証する。

convenience initが、required init以外のinitを使えるのが悪いんじゃないかな

2:58 AM

required initだけ使えるようになっていればこの問題は起きないと思う (edited)

問題が起きるコードがわからない・・・

3:06 AM

protocol P0 { init(string: String) } class Animal { init() {} convenience init(string: String) { self.init() } var str1: String = "" } final class Cat : Animal, P0 { var str2: String = "" } func createP0<X: P0>() -> X { return X.init(string: "apple") } let cat: Cat = createP0() print(cat)

↑特に問題なし

3:08 AM

直接聞いてみるか。

3:13 AM

https://twitter.com/slava_pestov/status/1001662447374163968

@omochimetaru It works in 9.3. I think some refactoring I did on master broke it

3:13 AM

Xcode9.3は大丈夫っぽい。

5/29スナップショットで再現できた。

治ったらしい http://twitter.com/slava_pestov/status/1001703511426502658

Turn on ‘as’ bridging on Linux. by millenomi · Pull Request #...

@pteasima Fix: https://t.co/IyNJcw1DoP

protocolに定義したassoctypeのconditionを無視してもコンパイル時に発見されず実行時クラッシュが発生するパターンを発見しました。最小コード探すよ。 (edited)

これおかしくない？

// プロトコルその1, EuclideanRing public protocol EuclideanRing { var eucDegree: Int { get } } // プロトコルその2, Field // そしてFieldならばEuclideanRingである public protocol Field: EuclideanRing {} // それを実現するための実装 extension Field { public var eucDegree: Int { return 0 } } // ジェネリックな型 public struct Complex<R> {} // これはOK //extension Complex: Field {} // これがコンパイルエラー //extension Complex : Field where R == Float {} // error: iOSGround.playground:12:1: error: type 'Complex<R>' does not conform to protocol 'EuclideanRing' // これはOK //extension Complex : EuclideanRing, Field where R == Float {}

4:55 PM

一度話した気もするな。 condconf経由だと間接conformができない

それはあれだ、前提になるやつ書かないとエラーになる話

4:55 PM

既出

それってそうあるべきで結論になったんだっけ

いや、バグでしょって話で、bugsには既存であった、だったかな？そこは覚えてない

それともbugsあげたんだっけ

4:56 PM

ふむ

型がぶっ壊れるやつはbugsにあげたの覚えてる

cond-confのwhere、 == と : の同時定義もだめなんだなあ

値型からAnyObjectへ as でboxingできるのが、 ObjectiveC Runtime環境だけで、Linux Swiftではできないのって、なぜなんですっけ。別に Swift ランタイム側で Swift ネイティブな class に boxing することはできると思う。 (edited)

__SwiftObjectかな

それをLinuxでも用意できるでしょ？

なんやろ

class AnyObjectBox { let value: Any }

5:07 AM

↑これでいい

5:08 AM

String と NSString のブリッジングとかは個別に定義されてるし、それ自体はObjCと関係ない struct と AnyObject の関係が、ObjCかどうかで変化する必要性が思い当たらない。

https://github.com/apple/swift/pull/16022 と https://github.com/apple/swift-corelibs-foundation/pull/1526 でちょうど解決されそうな話題？4.2にもバックポート済み

See https://forums.swift.org/t/bridging-for-swift-corelibs-foundation-on-linux/11994/1 for a full rationale. This is a work-in-progress patch to enable 'as', 'as?', 'as!' br...

Adopt ‘as’ bridging on Linux. by millenomi · Pull Request #15...

This patch adopts 'as' bridging on Linux. It requires apple/swift#16022 — see that PR for more details.

bridging arbitrary Swift values to opaque (_SwiftValue) reference types and vice versa (with struct X {}: ([X(), X(), X()] as NSArray) as! Array<X>).

6:24 AM

まさにこれだ (edited)

6:25 AM

フムー

6:27 AM

じゃあできるようになる方に統一されるんですね

6:28 AM

そうするともう一個疑問があって、AnyObjectで保持する場合と、Anyで保持する場合で、振る舞いの違いって何があるんだろ

Any は値型として振る舞い AnyObject は参照型として振る舞うんじゃないかと思ったけど、 Any や AnyObject に入れたインスタンスのプロパティを変更する方法がなさそう。

そうなんですよね、その振る舞いの違いが顕在化するコードはどうなるか試してみたけど、変更を書き戻せないので実際に違いが出せなくて。

単に何が入れられるかの違いでは？ @swiftbot

let i: AnyObject = Int(19) let f: AnyObject = { (a: Int) -> Int in a * 2 } enum E { case none } let e: AnyObject = E.none

1

masakihori

let i: AnyObject = Int(19) let f: AnyObject = { (a: Int) -> Int in a * 2 } enum E { case none } let e: AnyObject = E.none

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:1:20: error: value of type 'Int' does not conform to specified type 'AnyObject' let i: AnyObject = Int(19) ^~~~~~~ as! AnyObject /usercode/main.swift:2:20: error: value of type '(Int) -> Int' does not conform to specified type 'AnyObject' let f: AnyObject = { (a: Int) -> Int in a * 2 } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ as! AnyObject /usercode/main.swift:7:22: error: value of type 'E' does not conform to specified type 'AnyObject' let e: AnyObject = E.none ~~^~~~ as! AnyObject

@masakihori

値型からAnyObjectへ as でboxingできるのが、 ObjectiveC Runtime環境だけで、Linux Swiftではできないのって、なぜなんですっけ。

じゃあできるようになる方に統一されるんですね

という文脈での話ですね。

9:40 AM

@swiftbot let a: Int = 42 let b: AnyObject = a as AnyObject print(b) print(b as! Int)

1

koher

let a: Int = 42 let b: AnyObject = a as AnyObject print(b) print(b as! Int)

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:2:22: error: 'Int' is not convertible to 'AnyObject'; did you mean to use 'as!' to force downcast? let b: AnyObject = a as AnyObject ~~^~~~~~~~~~~~ as!

↑は Bot は Linux なのでエラーになりますが

9:41 AM

Mac だと↓の結果になります。 _SwiftValue 42

AnyはそもそもprotocolなのとAnyObjectはclass型で全然違うような

値型の existential は値のように振る舞うのと、イミュータブルクラスは値のように振る舞うのと、値型を AnyObject に入れるとイミュータブルなのとが組み合わさって、挙動が同じように見えるということかと。

メモリレイアウトとか違いそう

うーん逆に言うと現状だと

10:08 AM

typealais Any = AnyObject 的にコンパイルされていてもわからないのでは？ってこと。

10:08 AM

as AnyObjectでboxingしたときに関して。 (edited)

値型に関しては、だね。

classを入れても同じことになりませんか？

いや、参照型も同じか

AnyObjectに入れたときも参照共有、Anyに入れたときも参照共有（Anyとしてのコピーのときにインスタンスクローンされない）

$ swift Welcome to Apple Swift version 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2). Type :help for assistance. 1> import Foundation 2. 3. var str = "Hello, playground" 4. let a = str as AnyObject 5. let selector = Selector("description") 6. if a.responds(to: selector) { 7. print(a.perform(selector).takeUnretainedValue()) 8. } Hello, playground str: String = "Hello, playground" a: _NSContiguousString = "Hello, playground" selector: Selector = "description"

読みたらない上に勉強不足でした

11:18 AM

値型に as AnyObjectがすんなり通るのを知りませんでした

11:20 AM

そうなると確かに AnyとAnyObjectをわける必要性がよくわからないですね

@norio_nomura なるほど、 AnyObjectならperfomeSelectoeが使えるという違いはありますねw

AnyObjectに明示的にキャストすると幾つかのメソッドがチラ見できる

11:24 AM

@swiftbot

import Foundation func foo<T: Any>(x: T) { print(x) } func bar<T: AnyObject>(x: T) { print(x) } foo(x: "") // bar(x: "") // 🙅 bar(x: "" as AnyObject)// 🙆

(edited)

1

(edited)

tarunon

import Foundation func foo<T: Any>(x: T) { print(x) } func bar<T: AnyObject>(x: T) { print(x) } foo(x: "") // bar(x: "") // 🙅 bar(x: "" as AnyObject)// 🙆

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:13:11: error: 'String' is not convertible to 'AnyObject'; did you mean to use 'as!' to force downcast? bar(x: "" as AnyObject)// 🙆

あれ

か

11:25 AM

ちゃうちゃう

最新ならいけるんじゃない？

11:25 AM

さっきのやつマージされてるから

謎文字が入っとった

4.1はリナックスはだめよ

なるほど

11:26 AM

↑で言いたいのは、

11:26 AM

GenericsにAnyとAnyObject指定すると型としての違いが露出するから面白いって話

nightlyにもまだ入ってません。

11:34 AM

GitHubのマージコミットページににタグが表示されるかどうかで分かります。 apple/swiftではNightlyに入ってる。 https://github.com/apple/swift/commit/6e5605aee8a230c7f81f3dd1aad716e50e24059b apple/swift-corelibs-foundationではNightlyに入ってない。 https://github.com/apple/swift-corelibs-foundation/commit/1da6fc8ccbce77bfc4cc4fffa6de260ee8589708 (edited)

Merge pull request #16022 from millenomi/LinuxAsBridging · apple/...

Turn on ‘as’ bridging on Linux.

Merge pull request #1526 from millenomi/LinuxAsBridging · apple/s...

Adopt ‘as’ bridging on Linux.

11:35 AM

なるほど、これ見たら良いのか

@swift-main @swift-4.2.4

import Foundation func foo<T: Any>(x: T) { print(x) } func bar<T: AnyObject>(x: T) { print(x) } foo(x: "foo") // bar(x: "") // 🙅 bar(x: "bar" as AnyObject)// 🙆

(edited)

foo bar (edited)

stderr:

<stdin>:13:11: error: 'String' is not convertible to 'AnyObject'; did you mean to use 'as!' to force downcast? bar(x: "" as AnyObject)// 🙆

foo bar (edited)

なるほど、キャストする過程は違いますね

6:59 AM

そのままでいいか、asがいるか

6:59 AM

https://twitter.com/millenomi/status/1002595280619880454

✾ Lily, Lady whom 💖 (@millenomi)

My contributions landed last night in Swift 4.2 as well. Many casts now work on Linux as well — no more #if os(Linux) for going from NSArray to Array<_>, and JSON parsing will be able to return numbers whose type you don’t have to guess. https://t.co/fLngqlMY3i

7:00 AM

このパッチのオーサーのツイ流れてきた

linuxでas? NSObjectが動く様になった事で、今までObjectEncoderのテストがlinuxで期待した通りに動いていなかったことが判明した…

(edited)

1

幸い、DateFormatter.Style.fullの結果がmacOSとLinuxで違ってるのが検出できていない程度で済んだ。 @swift-4.1.3

import Foundation func format(_ date: Date) -> String { let formatter = DateFormatter() formatter.dateStyle = .none formatter.timeStyle = .full formatter.locale = Locale(identifier: "en_US_POSIX") formatter.timeZone = TimeZone(identifier: "GMT") return formatter.string(from: date) } print(format(Date(timeIntervalSince1970: 1000))) // macOS: "12:16:40 AM Greenwich Mean Time" // Linux: "12:16:40 AM GMT"

(edited)

12:16:40 AM GMT (edited)

@swiftbot --version=3.1.1 func foo(block: (Int, Int) -> Int) {} foo { $0.0 } (edited)

1

(edited)

kateinoigakukun

func foo(block: (Int, Int) -> Int) {} foo { $0.0 }

Version:

swift-3.1.1-RELEASE

Output:

Error:

@swiftbot --version=4.1 func foo(block: (Int, Int) -> Int) {} foo { $0 } (edited)

1

(edited)

kateinoigakukun

func foo(block: (Int, Int) -> Int) {} foo { $0 }

Version:

swift-4.1-RELEASE

Output:

Error:

/usercode/main.swift:3:5: error: contextual closure type '(Int, Int) -> Int' expects 2 arguments, but 1 was used in closure body foo { $0 } ^ ,<#arg#>

swift4で引数がタプルに変換されなくなってから、最初の引数を$で取りたい時どうしてますか？

$0.0 じゃないですかね。

@swiftbot --version=4.1 func foo(block: (Int, Int) -> Int) {} foo { $0.0 }

1

kateinoigakukun

func foo(block: (Int, Int) -> Int) {} foo { $0.0 }

Version:

swift-4.1-RELEASE

Output:

Error:

/usercode/main.swift:3:5: error: contextual closure type '(Int, Int) -> Int' expects 2 arguments, but 1 was used in closure body foo { $0.0 } ^ ,<#arg#>

タプルに変換されないので.0の記法が使えない？

どうしても $ で取りたい理由がわかりませんが、 { ($0, $1).0 } とかじゃないと無理かと。

コンパイラは$0が１つ目の引数を表しているということを決定できません？

技術的に可能かと言われれば可能だと思いますが、現状はそれはやってないですね。

10:17 AM

現状の仕組みとしては、クロージャ内で使われている $n の最大値を使って、例えば { $2 } だとすると、 { ($0, $1, $2) in $2 } と暗黙的に宣言されるようなイメージです。 (edited)

10:18 AM

なのでこの場合 { $0 } はダメだけど { $1 } なら動く。

結局$nの最大値が引数の数と一致しないとコンパイル出来ないので、$nの最大値に関わらず引数の数だけ宣言しても問題なくないですか？

@swiftbot --version=3.1.1,4.1 let a = { $0 }(1,2,3) print(a)

1

rintaro

let a = { $0 }(1,2,3) print(a)

Version:

swift-3.1.1-RELEASE

Output:

(1, 2, 3)

Error:

Version:

swift-4.1-RELEASE

Output:

Error:

/usercode/main.swift:1:18: error: extra argument in call let a = { $0 }(1,2,3) ^

$0 を単純に第一引数であり、他の引数は無視されると仮定すると、3とそれ以降で同じソースが、エラーも警告も出ずに違う結果を返すことになってしまう可能性があるので、 (edited)

10:31 AM

3 のソースをサポートしている限りはその仕様変更は難しいのだと思います。

なるほど！完全に納得できました

1

swift のドキュメントが swift.org に移動した様ですね。 https://docs.swift.org/swift-book/

3

お、Using Swift with Cocoa and Objective-Cはどこへ移動したのだろう？

大幅に書き換えられてLanguage Interoperabilityに置かれてたぽい。 https://developer.apple.com/documentation/swift#2984801 (edited)

1

struct Stone {} let a: Stone.Type = Stone.self let b: Any.Type = a print(MemoryLayout.size(ofValue: a)) // 0 print(MemoryLayout.size(ofValue: b)) // 8

2:11 AM

昨日 @noppe さんと話してて知った↑ゼロバイトの型。

↑補足すると、

struct Sample {} // ng unsafeBitCast(Sample.self, to: UnsafeMutablePointer<Int>.self) // ok let type: Any.Type = Sample.self unsafeBitCast(type, to: UnsafeMutablePointer<Int>.self)

みたいなコードがあって、コード的に同義じゃないのかなという話からunsafeBitCastのsrc/dstのサイズが実は両者違うという結論の中で出た話です

(edited)

protocolのconformで仕様の壁に当たって困ったことになった (edited)

1

2:01 AM

extension PublicClass: PublicProtocol { associatedtype ProtocolCondition = InternalClass } これができない

ああ

めちゃくちゃ困った

protocolにinternalにconformすることができないから

2:02 AM

protocol経由でいろいろ丸見えになるやつ？

全てpublicにしないとconformできない

2:03 AM

しかし、そのprotocolを利用した動きはフレームワークに閉じてるのでそんな滅茶苦茶されるのは困る

2:04 AM

protocolか型の片方はinternalにできるが、assoctypeだけをinternalにできない、そこの非対称性で困ってるって感じですね (edited)

あるなあそれ

2:06 AM

できるかわからんけど一回イレイジャ挟む形にすれば隠蔽はできるんじゃないか

それはまあそうなんだけど、使い勝手が悪い

外向きプロトコルと内部で使うようのプロトコルをわけて定義して、外向きは内部用へのディスパッチとして実装内部のやつはAnyHogehogeで包んで実装隠蔽

2:06 AM

だよねえ

使い勝手が悪いのは全てpublic太郎に勝てなくなることを意味する

俺はむちゃくちゃするやつが悪い！ってことで深く考えない事にした

2:07 AM

シンボルが見えてるからって呼び出しちゃだめなんだ基本

いや今困ってるのは

2:08 AM

フレームワーク間の繋ぎ混みを神モジュールでprotocolで表現したときに、モジュールAをモジュールBでimportして繋ごうとすると世界が崩壊したやつなので

2:08 AM

これはどうしようもない

ふーむ

https://github.com/apple/swift/pull/17044

Add a compact() shorthand for Sequence.compactMap (SE-0187) by zou...

The accepted and implemented SE-0187 says “…we will add Sequence.compact() when it is possible to do so.” It seems to be possible now, and the shorter syntax for a common operation (filtering nils ...

1:33 PM

これできなかった気がするんだけどいつのにかできるようになった・・・？

昼間のpublic話、もし仮に出来るとぶっ壊れるケースが有ることがわかって困った

あ、かぶった

1:34 PM

Filtering nil elements from the Sequence is very common, therefore we also propose adding a Sequence.compact() function. This function should only be available for sequences of optional elements, which is not expressible in current Swift syntax.

1:34 PM

やっぱできなかったよね？

1:34 PM

これはflattenも例のハック不要になったか？

やっぱRustライクにprotocol conforming自体をoverloadできるようになりたいなぁ

1:38 PM

GenericProtocolほしい

Parameterized Extensions がなくてもできた？ @inlinable public func compact<T>( ) -> [T] where Element == Optional<T> { return _compactMap { $0 } } (edited)

これ変な生え方してるのでは

↓が必要だと思ってたけど必要なかった？ extension<T> Sequence where Element == Optional<T> { public func compact() -> [T] { ... } }

僕が壊れてなければこれは壊れてると思います

www

↓の where 変な気がしたんだけど、できなかったのか自信がなくなった。 public func compact<T>( ) -> [T] where Element == Optional<T> (edited)

Elementに制約がないのであらゆるArrayに生えてるように見えるが使えない不完全なものになる (edited)

制約ついてるよ

外側でついてない

うむ、内側でついてるね。

extension側の宣言がが無法地帯では

2:17 PM

内側でつけると壊れる

なんか最近内側でつけるの他のとこでも見て、そのときもこんなのできるんだっけ？？って思った。

残念ながら

最近見てたのだから、 KeyPath か SceneKit か ARKit かだと思う。 KeyPath がありそう。

前書いたことあるんですが、型推論の全く効かない妙ちくりんになりますね。

@swiftbot

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return _compactMap { $0 } } } let a: [Int?] = [nil, 2, 3, nil, 5] let b: [Int] = a.compact() print(b)

1

koher

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return _compactMap { $0 } } } let a: [Int?] = [nil, 2, 3, nil, 5] let b: [Int] = a.compact() print(b)

Version:

swift-4.1.1-RELEASE

Output:

[2, 3, 5]

Error:

普通にできる・・・

2:21 PM

内側で型パラメータを縛るという発想がなかっただけ？？

@swiftbot

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return _compactMap { $0 } } } let a: [Int?] = [nil, 2, 3, nil, 5] let b: [Int] = a.compact().compact() print(b)

1

tarunon

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return _compactMap { $0 } } } let a: [Int?] = [nil, 2, 3, nil, 5] let b: [Int] = a.compact().compact() print(b)

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:8:28: error: generic parameter 'T' could not be inferred let b: [Int] = a.compact().compact() ^

お

ちゃんとエラーにもなってますね・・・

以前はこれで壊れてましたね

2:22 PM

後はコード補完が壊れるやつが改善してればまぁ…という感じ、ケータイでは試せない

@swift-4.0.3

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return _compactMap { $0 } } } let a: [Int?] = [nil, 2, 3, nil, 5] let b: [Int] = a.compact().compact() print(b)

exit status: 1 with stderr:

<stdin>:3:16: error: use of unresolved identifier '_compactMap' return _compactMap { $0 } ^~~~~~~~~~~ <stdin>:8:28: error: generic parameter 'T' could not be inferred let b: [Int] = a.compact().compact() ^

@swift-4.0.3

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return compactMap { $0 } } } let a: [Int?] = [nil, 2, 3, nil, 5] let b: [Int] = a.compact() print(b)

(edited)

exit status: 1 with stderr:

<stdin>:3:16: error: use of unresolved identifier 'compactMap' return compactMap { $0 } ^~~~~~~~~~ <stdin>:2:17: note: did you mean 'compact'? public func compact<T>() -> [T] where Element == Optional<T> { ^

(edited)

@swiftbot

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return _compactMap { $0 } } } let b: [Int] = [] print(b.compact)

1

tarunon

extension Sequence { public func compact<T>() -> [T] where Element == Optional<T> { return _compactMap { $0 } } } let b: [Int] = [] print(b.compact)

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:7:9: error: generic parameter 'T' could not be inferred print(b.compact) ^

まちがえて _compactMap 呼んでた・・・

2:25 PM

てか、 Swift 4.0.3 だと compactMap がないのか。

2:27 PM

@swiftbot

extension Sequence { public func flatten<T>() -> [T] where Element : Sequence, Element.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

1

koher

extension Sequence { public func flatten<T>() -> [T] where Element : Sequence, Element.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

Version:

swift-4.1.1-RELEASE

Output:

[2, 3, 5]

Error:

@swift-4.0.3

extension Sequence { public func flatten<T>() -> [T] where Element : Sequence, Element.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

[2, 3, 5]

普通にできるぞ・・・

4.0.3でもいけるの！？

@swift-4.0.3

extension Sequence { public func flatten<T>() -> [T] where Element : Sequence, Element.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b) print(b.flatten())

exit status: 1 with stderr:

<stdin>:10:7: error: ambiguous reference to member 'flatten()' print(b.flatten()) ^ Swift.Sequence:27:17: note: found this candidate public func flatten() -> FlattenSequence<Self> ^ <stdin>:2:17: note: found this candidate public func flatten<T>() -> [T] where Element : Sequence, Element.Element == T { ^ Swift.Collection:27:17: note: found this candidate public func flatten() -> FlattenCollection<Self> ^ Swift.BidirectionalCollection:27:17: note: found this candidate public func flatten() -> FlattenBidirectionalCollection<Self> ^

さっきのプロポーザルにも今のSwiftじゃ無理って書いてあったし

できない方（ b.flatten() ）もちゃんとコンパイルエラーになった。

2:29 PM

やっぱ、みんな Parameterized Extensions がないと駄目だと思ってた？

いや、できなかったはず、内側法も思いついて試したぞ

4.0.3 でできてるのはなぜ？？

https://stackoverflow.com/questions/28190631/creating-an-extension-to-filter-nils-from-an-array-in-swift

Creating an extension to filter nils from an Array in Swift

I'm trying to write an extension to Array which will allow an array of optional T's to be transformed into an array of non-optional T's. e.g. this could be written as a free function like this: f...

2:32 PM

54点の回答のやつ。

Wandbox の Swift 3.1.1 で↓動いた。

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

2:36 PM

Element のままだと動かなくて Iterator.Element にしないとエラーになったから、ちゃんと Swift 3 だと思う。

なんてこった

これできるなら Parameterized Extensions いらないのでは？

@swiftbot --version=3.1.1

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

1

kishikawakatsumi

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

Version:

swift-3.1.1-RELEASE

Output:

[2, 3, 5]

Error:

プロトコルコンフォーマンスは無理そう

下は3.0.1まで入ってる。

あ、そうか、 --version で指定できるんでしたね。

Compactableみたいな。

Compactable 、 Parameterized Extension でも書けなさそう。

2:43 PM

protocol Compactable : Sequence where Sequcne.Element == Optional<???> { func compact() -> [Element.Wrapped] }

>> 型推論周りが壊れる

2:50 PM

これにつきるんですが、Sequence全体にメソッドが生えているように見えるので

2:50 PM

使い勝手は頗る悪いです

そこはコンパイラが賢くなれば・・・

厳しいのでは

2:51 PM

Compactable自体は型パラ一個増やせばできますね

2:52 PM

protocol Compactable : Sequence where Element == Optional<Wrapped> { associatedtype Wrapped func compact() -> [Wrapped] }

まあConformでコケますけど

associatedtype をそっちに持っていけるんですね。 Element も書けるから当たり前か。

@swiftbot --versions

@swiftbot versions

2018-05-29-a 2018-05-08-a 2018-05-02-a 2018-04-25-a 2018-04-23-a 4.1.1 4.1 4.0.3 4.0.2 4.0 3.1.1 3.1 3.0.2 3.0.1

すまぬ。

また間違えたｗ

2:59 PM

細かいお作法を忘れがち

これはBot側で吸収するようにしよう。

@swiftbot --versions=3.0.1,3.0.2,3.1,3.1.1

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

1

omochimetaru

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

Version:

swift-4.1.1-RELEASE

Output:

[2, 3, 5]

Error:

理解

3:00 PM

@swiftbot versions=3.0.1,3.0.2,3.1,3.1.1

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

1

omochimetaru

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

Version:

swift-4.1.1-RELEASE

Output:

[2, 3, 5]

Error:

あれ？

3:00 PM

あ〜〜〜

オプションの場合は--version

@swiftbot --version=3.0.1,3.0.2,3.1,3.1.1

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

1

omochimetaru

extension Sequence { public func flatten<T>() -> [T] where Iterator.Element : Sequence, Iterator.Element.Iterator.Element == T { return flatMap { $0 } } } let a: [[Int]] = [[2, 3], [5]] let b: [Int] = a.flatten() print(b)

Version:

swift-3.0.1-RELEASE

Output:

Error:

0 swift 0x0000000003350548 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 swift 0x000000000334ed46 llvm::sys::RunSignalHandlers() + 54 2 swift 0x0000000003351076 3 libpthread.so.0 0x00007fd48f4d8390 4 swift 0x0000000001154f30 swift::TypeBase::getDesugaredType() + 32 5 swift 0x0000000001018bf5 swift::ArchetypeBuilder::resolveArchetype(swift::Type) + 21 6 swift 0x000000000101882b swift::ArchetypeBuilder::PotentialArchetype::getType(swift::ArchetypeBuilder&) + 1915 7 swift 0x000000000101d575 swift::ArchetypeBuilder::getArchetype(swift::GenericTypeParamDecl*) + 53 8 swift 0x0000000000f0c29f swift::TypeChecker::finalizeGenericParamList(swift::ArchetypeBuilder&, swift::GenericParamList*, swift::DeclContext*) + 191 9 swift 0x0000000000ee0f39 10 swift 0x0000000000ed15ed 11 swift 0x0000000000edd06b 12 swift 0x0000000000ed14a0 ...

Version:

swift-3.0.2-RELEASE

Output:

Error:

0 swift 0x00000000035c3c08 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 swift 0x00000000035c4367 2 libpthread.so.0 0x00007f1c9a644390 3 swift 0x00000000011be630 swift::TypeBase::getDesugaredType() + 32 4 swift 0x000000000107ab85 swift::ArchetypeBuilder::resolveArchetype(swift::Type) + 21 5 swift 0x000000000107a598 swift::ArchetypeBuilder::PotentialArchetype::getType(swift::ArchetypeBuilder&) + 1400 6 swift 0x000000000107f6e7 swift::ArchetypeBuilder::getArchetype(swift::GenericTypeParamDecl*) + 167 7 swift 0x0000000000f6c87f swift::TypeChecker::finalizeGenericParamList(swift::ArchetypeBuilder&, swift::GenericParamList*, swift::DeclContext*) + 191 8 swift 0x0000000000f4173c 9 swift 0x0000000000f301a9 10 swift 0x0000000000f3d70b 11 swift 0x0000000000f3003b 12 swift 0x0000000000f2ffbd swift::TypeChecker::typeCheckDecl(swift::Decl*, bool) + 157 ...

Version:

swift-3.1-RELEASE

Output:

[2, 3, 5]

Error:

Version:

swift-3.1.1-RELEASE

Output:

[2, 3, 5]

Error:

3:00 PM

stderr-3.0.1.txt

1.92 KB

3:00 PM

stderr-3.0.2.txt

1.85 KB

3.0属がクラッシュしたぞ

複数与えるのは後から入った仕様。これもBotで吸収しよう。

1

3.1世代でできるようになっていたのか・・・？

3:02 PM

マジ・・・？あれえ・・・

いくらなんでも compactMap の Proposal が書かれる前だね・・・

https://github.com/apple/swift/pull/17044

Add a compact() shorthand for Sequence.compactMap (SE-0187) by zou...

The accepted and implemented SE-0187 says “…we will add Sequence.compact() when it is possible to do so.” It seems to be possible now, and the shorter syntax for a common operation (filtering nils ...

3:03 PM

今入れ違いでclosedになってるｗ

3:04 PM

Hm, according to this Evolution thread we would better wait for the real deal (extension Sequence where Element : Optional), since going with the temporary generic solution now would cause problems with ABI stability later.

かなしい・・・

This function should only be available for sequences of optional elements, which is not expressible in current Swift syntax.

3:05 PM

proposalのこれは、

3:05 PM

外側につけることはできないって話だったのか・・・？

どうせ ABI 安定化してないんだから別に暫定でこれでもいい気もするけど・・・

たしかにｗ

これが駄目だったら、 Codable が Codable でない Array サポートしてたのとか、 Equatable でない Array の == とかもっとひどい気が。

まあ、残念なflattenは手元の案件で自前ではやしてたから、ましな書き方になおせるな。

3:07 PM

たしかに。

3:08 PM

型制約がなんとなくそれっぽいだけの代替品が仮実装されてたことは

3:08 PM

過去にたくさんありますね。

Because it cannot later be removed after ABI stability. As you demonstrate, you can use it yourself with minimal fuss if you wish.

この意見だけで閉じられちゃってるけど、もっと違う判断もありえたような・・・。

このスレこの数時間で開いて決着したのか。

3:12 PM

なんかモヤモヤしますね。

個人的には型推論壊れるメソッド追加は無しかなぁという感

3:13 PM

それが理由じゃないのはうーんって感じ

壊れるっていうのはどういうこと？

追加してIntのArrayに.flatまで打ったらわかる

3:14 PM

補完がぶっ壊れる

3:14 PM

ここが壊れるってことはほかに壊れる要素はありそう

error: iOSGround.playground:3:3: error: generic parameter 'T' could not be inferred a.compact()

3:15 PM

ああ、出ないべきなのに出るのね

3:16 PM

うーんでも、それはそっちを直すべきなはなしで

3:16 PM

それ言ったら tableView.rx.items だって

3:16 PM

存在しちゃいかんしなあ

野生のライブラリとStandardLibraryはちゃうやろw

なるほど・・・？

3:17 PM

標準ライブラリにはいまのところ

3:17 PM

確殺パターンは無いのか。

個人的にはCodableの妥協追加は最悪の出来事だった

ｗｗ

あれ（ Codable ）と比べたら型的には壊れてないしいいのではという気持ちになる

Conditionくぐらせていくと何処かで崩壊する境目がありそうですけどね

3:20 PM

Dictionary勝手にネスト事件を思い出した

あった

そういえば最近も勝手にネスト踏んだ。

コメントしてみた。 https://forums.swift.org/t/can-the-compact-shorthand-for-compactmap-0-be-implemented-now/13315/14

Can the compact() shorthand for compactMap { $0 } be implemented now?

Me too. I had believed that it was impossible to implement compact() without parameterized extensions. @xwu Because ABI stability has not done, if there are no other problems, is it no good to have the proposed implementation of compact() for now and replace it when paramet...

おお

Will parametrized extensions be available before Swift 5? I realize Swift 5 was delayed a bit, but I didn't think that anyone was even working on implementing parameterized extensions yet.

8:09 AM

Parameterized extensions を実現するのに ABI に手を入れる必要はないのかな？

追加的だから大丈夫そうな気はする

8:11 AM

extensionとかのメタデータが拡張可能な形式になってれば。

8:12 AM

あ、でも、parameterized かつ conditional conformance みたいになると

8:12 AM

実質的にgeneric protocolがあるようなもんだから

8:12 AM

今のメタデータ形式からはみ出そうな気も

なるほどー。 ABI に手を入れないといけないけど、後方互換性は保たれるのか。

このPRは@_inliableと@_versionedがエラーになるんですか？ https://github.com/apple/swift/pull/17091

Minor @inlinable improvements [4.2] by slavapestov · Pull Request...

Allow @usableFromInline on typealias declarations, but don't enforce it yet. Enforcement is coming in #16586 Don't produce a warning for the old spelling of @_inlineable and @_versioned exc...

-swift-versionに関係なくワーニングとなっていたのが、-swift-version 4はワーニング無し、-swift-version 4.2はワーニング、になるのだと思います。

9:37 PM

SwiftNIOを4.2コンパイラでビルドすると、大量のワーニングが出てて不便だったので。

そういうことか。SwiftNIOでビルドするとワーニング出るのは確かに不便

@swift-4.2.4 -swift-version 4 @_versioned func f() {}

no output

@swift-4.2.4 -swift-version 4.2 @_versioned func f() {}

stderr:<stdin>:1:2: warning: '@_versioned' has been renamed to '@usableFromInline' @_versioned ^~~~~~~~~~ usableFromInline

usableFromInlineで決着してたんですね。

4:43 AM

わかりやすい名前だ・・・

https://github.com/apple/swift/blob/master/docs/ABI/TypeMetadata.rst#common-metadata-layout Common Metadata Layoutのkindはclass以外はTypeのポインタから-1した箇所から9byte目を参照すればいいのでしょうか…？

https://github.com/apple/swift/commit/84994dc786f5d092eaded40cfc4b3601730d40b6

swift - The Swift Programming Language

11:55 AM

enum Kind {} func dumpMemory(_ p: UnsafeRawPointer, _ size: Int) { let addr = unsafeBitCast(p, to: Int64.self) let p = p.bindMemory(to: UInt8.self, capacity: size) for i in 0..<size { if i % 8 == 0 { if i != 0 { print() } print(String(format: "[0x%016lx](\(i/8))", addr + Int64(i)), terminator: "") } print(String(format: " %02x", p[i]), terminator: "") } print() } var type: Any.Type = Kind.self let base: UnsafeMutablePointer = unsafeBitCast(type, to: UnsafeMutablePointer<Int64>.self) let metadataPointer = base.advanced(by: -1) let p = UnsafeMutableRawPointer(metadataPointer) dumpMemory(p, 16)

struct: 01 enum: 02 protocol: 0c なのでそれっぽい値は出ているのですが、検証として正しいのか…

The kind field is a pointer-sized integer that describes the kind of type the metadata describes. This field is at offset 0 from the metadata pointer.

12:14 PM

なので先頭っぽいですけどねぇ、

12:15 PM

struct Struct { } enum Enum { } protocol Protocol { } func kind(_ type: Any.Type) ->  Int { return unsafeBitCast(type, to: UnsafeMutablePointer<Int>.self).pointee } print(kind(Struct.self)) // 1 print(kind(Enum.self)) // 2 print(kind(Protocol.self)) // 12

(edited)

確かにこれkind見るだけならvalue witness tableポインタ分考えなくていいので0から見る方がシンプルですね！

Enable large loadable types by default · apple/swift@84994dc

9:00 PM

11ヶ月前からLoadableByAddressというSILpassが必須になっていて

9:02 PM

https://github.com/apple/swift/blob/a1a797e1fa80aff532d0ea7970f73cf6da583e45/test/IRGen/big_types_tests.sil

swift - The Swift Programming Language

9:02 PM

このテストを見ると、

9:03 PM

SILからIRになるところで、値のコピー渡しから、ポインタ渡しに書き換わっているように見える

9:04 PM

でかい値型はポインタ渡ししてコピーコストを抑えるようになってるんだろうか？

9:07 PM

このパスはSILpassなんだけどIRGenステージの開幕で行われる特殊なやつ https://github.com/apple/swift/blob/477d43ef1c92d6352cd0f819bfd5367cfc785d64/lib/IRGen/IRGen.cpp#L711

swift - The Swift Programming Language

9:08 PM

このパスだけで、2800行もある。。

CPUのABI的な制限もあった気がする。

どういう制限ですか？

4:05 AM

関数呼び出し前後の引数と返り値の受け渡しはスタック経由だから特に無さそうな気もする

4:06 AM

てか、LLVMIRの段階だとその辺も曖昧な気が。

LoadableByAddress の中からも呼ばれてる https://github.com/apple/swift-clang/blob/21dc66dd/include/clang/CodeGen/SwiftCallingConv.h#L79-L90 この辺で、

apple/swift-clang

Contribute to swift-clang development by creating an account on GitHub.

4:27 AM

target 毎に https://github.com/apple/swift-clang/blob/stable/lib/CodeGen/TargetInfo.cpp の shouldPassIndirectlyForSwift() で定義されているっぽいです。

apple/swift-clang

Contribute to swift-clang development by creating an account on GitHub.

4:29 AM

ちょっとコード追っただけなので、何か勘違いしている可能性は高いですが

LoadableByAddress.cpp で shouldPassIndirectly を呼んでる場所、検索したけど見つからず。

4:34 AM

これは LLVM-IR からアセンブリに変換する段じゃないですかね？

4:35 AM

swift-clangとswift-llvmの役割の違いもよくわからないな〜 swift-clangはObjCなどのブリッジで使われてるはずだけど CallingConventionまでここにあるのか。

4:35 AM

ビルドするときは一緒になっちゃうし。。

https://github.com/apple/swift/blob/master/lib/IRGen/LoadableByAddress.cpp#L108 の nativeParameterValueSchema に潜ってみてください。

Swift with a hundred engineers

swift - The Swift Programming Language

どうもです

なってますね、なるほど

けど、元のモチベーションはコードサイズの削減みたいですね。 https://bugs.swift.org/browse/SR-3876

requiresIndirect()は、LoadableByAddressとは関係なく、GenCall.cppの中からも参照されたりしているので

4:48 AM

ABI起因のindirectionはもともと普遍的に行われていて、

4:48 AM

LoadableByAddressは最適化の観点で追加されつつ、発生条件を満たすからそっちにも組み込まれた、と予想

4:49 AM

でもなんでポインタ渡しにするとコードサイズが減るんだろ。

もともと struct 使うとコードサイズが増えちゃうよねっていう話があって、 https://www.skilled.io/u/swiftsummit/swift-with-a-hundred-engineers Uber が Swift の話したときに話題になった。

Tuomas Artman shares the good and the bad from Uber's rewrite

4:50 AM

Binary size の節。

ほ〜〜

有効化されたときのテスト差分 https://github.com/apple/swift/pull/11295/files#diff-0f2be7d6654e94788d454c9676e2251b 元々要素一つ一つ取り出してたのを、ポインタ先からの memcpy 一発にしてる。小さくはなりそうだｗ

Enable large loadable types's IRGen pass by default by shajrawi ·...

radar rdar://problem/28680453 re-enable the new calling conventions by default. The new improved module pass adds support for return types and init()s There might be room for further optimizations ...

本題とそれますが、これはあれか、CHECKにキャプチャ機能があるのか？

https://llvm.org/docs/CommandGuide/FileCheck.html#filecheck-variables ですです。

なるほどなあ

5:03 AM

元のコードだとstructのコピーがメンバごとのコピーに展開されてるんですねえ

5:04 AM

元の状態だとレジスタ割当になる可能性があってmemcpyにはできないってことかな。

ローレベルだとC言語っぽい

↑のテストケース (test/IRGen/value_buffers.sil) は、 SILからLLVM-IRへのコンパイルのテストソースで、テストの入力のSILソースと、テストの出力のLLVM-IRソースが、同時に書いてあります。

8:49 AM

出力については SIL から見るとコメント文になっていて、テストランナーがそのコメントの中にある CHECK や CHECK-NEXT といったテストコマンドを読み取っていて、そのCHECKの右側にあるのが、出力を期待されているLLVM-IRコードです。

HelpHiddenなオプションが swiftc 経由だと使えなくて swift -frontend 経由だと使えるのはどういう制御なんじゃ？

12:22 PM

[omochi@omochi-iMacPro s4]$ swiftc -emit-ir -disable-llvm-optzns a.swift <unknown>:0: error: unknown argument: '-disable-llvm-optzns' [omochi@omochi-iMacPro s4]$ swift -frontend -emit-ir -disable-llvm-optzns a.swift (OK)

NoDriverOption フラグが付いたオプションは Driver は認識しないのです。 https://github.com/apple/swift/blob/master/include/swift/Option/FrontendOptions.td#L17

Swift コンパイラのアーキテクチャ - Qiita

swift - The Swift Programming Language

あ、HelpHiddenじゃなくてそっちが効いてるのか、ありがとうございます。

12:28 PM

ほんとうだ、 -primary-file とかも swiftc じゃ使えないのか。

12:29 PM

-primary-file使えないとほぼまともにビルドできない気がする・・・

-primary-file は swiftc が swift -frontend を起動するときに使うための物なので、そのようになってますね。

この前ビルドの流れ調べてたんですが、 -emit-moduleを-primary-fileとその他のファイルと一緒に使ってそれぞれのファイルをpartial moduleにしたあと、 -merge-modulesで1個にする、って感じだったから。

12:30 PM

ふむ・・・

12:30 PM

swift -frontendはswiftcのエイリアス的な存在かと誤解していました

12:31 PM

swift -frontendが一番ローレベルなインターフェースなのか。

https://qiita.com/rintaro/items/3ad640e3938207218c20#バッチモードこの辺にちらっと書いてます。バッチモード == Driver == swiftc

Swift のコンパイラの開発に手を出してみたい方向けに、コンパイラの全体構成がどうなっているのかを、大まかに説明します。コードリーディングの参考になればいいなと。

Swift コンパイラの構成

僕は...

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

12:36 PM

実行せずに、コマンドだけを表示したいなら -driver-print-jobs です。

これいいですね

12:39 PM

前述の通りバッチモード( swiftc ) でのコンパイルも、実際にはフロントエンドモードをサブプロセスとして実行しています。

12:39 PM

最近この辺追っかけてたんですが

12:39 PM

厳密にはこのコマンドの再入の処理が、 execvp の直接呼び出しで実装されてて

12:39 PM

fork していないので

12:40 PM

「サブプロセス」では無いかも。 (edited)

あれ、そうなんですか。

https://github.com/apple/swift/blob/master/lib/Basic/Program.cpp#L24

https://forums.swift.org/t/pure-bikeshedding-raw-strings-why-yes-again/13866

swift - The Swift Programming Language

12:41 PM

最初のmainからまっすぐここに突入する

12:44 PM

 // If we don't have to do any cleanup work, just exec the subprocess. if (Level < OutputLevel::Parseable && !ShowDriverTimeCompilation && (SaveTemps || TempFilePaths.empty()) && CompilationRecordPath.empty() && Jobs.size() == 1) { return performSingleCommand(Jobs.front().get()); }

12:45 PM

jobが1つの場合の最適化なのかも。

っぽいですね。今ちょうどそこ見てました。

exec生で使うプログラムはじめて見た。

forkせずに。っていう事ですか？

はい。

12:48 PM

だいたいはfork+execでサブプロセス開くところまでを1セットにしてライブラリ化されていると思います (edited)

コマンドラインだとたまにやる時ありますね。 argv の調整だけして argv[0] を再度 exec するとか。 (edited)

なるほど

Pure Bikeshedding: Raw Strings (why yes, again!)

The Need for Raw I write a lot of code generation apps. Because of this, I could really use some raw strings in my life. Raw strings aren't uncommon in other programming languages. Swift needs to implement them in a way that feels cromulently Swifty. If you don't remember, t...

2:11 AM

Ericaさん、良いスレ立てるなあと思う

ドッグバートアイコン見慣れてしまった

https://ameblo.jp/nozotuba/entry-10459447116.html

『DILBERT（ディルバート）ってご存知ですか？』

こんにちは(^o^)丿　ってご存知ですか全世界で１．５億人の読者がいると言われている、アメリカの新聞の４コマ漫画（４コマじゃないけど）です。数年前から、　にて…

2:13 AM

へえーこれ既存キャラだったのか

おすすめですよ http://www.itmedia.co.jp/enterprise/subtop/dilbert/

ITMediaで日本語版が掲載されてるのかｗ

let myString: @raw String この記法だと型がrawに見えてしまうような

2:20 AM

#rawStringのほうが良さそう

↓の構文ってパースできる？ ) とか " が足りないときとか。 let codeValue = #rawString("let value = "\(coreName): \(coreValue)"")

4:15 AM

#rawString("a") + #rawString("b") は ab になるのか a") + #rawString("b になるのか。

開き側の (" を見た時点で閉じる側が ") になり最短マッチで探すんじゃないですかね

4:17 AM

不足してる場合はファイル末尾に到達してsyntax error

4:17 AM

２つ目のケースは ab になる

4:17 AM

だと思います

そうすると ")" という文字列を #rawString で作ることはできない？

スレでも書かれてるけど、RawStringの場合はエスケープが不可能なので（エスケープがある時点でRawでないから）

4:19 AM

開き側のオペレータをカスタムできる仕様にすることが多いと思います。

4:19 AM

開き側を表したいコンテンツと衝突しないオペレータにすることで任意のコンテンツを表現できます。

なるほど〜。何かの言語もそうだった。

だから「 ")" という文字列」をつくれる

4:20 AM

僕も個別の言語がどういう仕様だったかまでの記憶は曖昧・・・

https://twitter.com/inamiy/status/1009777485641158658

Yasuhiro Inami (@inamiy)

本日の #potatotips の「Swiftで高カインド多相」スライドです！ https://t.co/Exm3lrCP8r ライブラリ：https://t.co/N3H11CW9jS

1

1:15 PM

面白かった。

Existential自体をprotocolに適合させたいという業が発生しがちになってきた

https://forums.swift.org/t/status-of-generalized-existentials/13982/8

Status of generalized existentials

If you do pursue this you might want to start by revisiting the draft @Austin wrote a couple years ago: https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md and subset out the relevant parts.

2:16 AM

またその話題のスレ立ったけどABI固定の前にやるからまってて、とのこと

2:16 AM

and we know we'll need to migrate some standard library type erasers to proper existentials

existentialがunstableである限り、abi安定できない状態が続く

AnySequenceの定義変更もやはりあるようだね

@objcも含めて相当闇が深いけどどう落としどころつけるのかめちゃくちゃ気になる

早く大枠を発表してほしいなー Condconf級の重要な進化になる

Yes, we know we aren't going to implement generalized existentials before ABI stability, and we know we'll need to migrate some standard library type erasers to proper existentials at some point in the future when we do properly support them.

2:28 AM

ABI 安定化の前には やらない じゃない？

ほんとだ！w

エッ

2:29 AM

大丈夫なのか

思い込みで誤読したか

ABI に影響しそうだけどしないのか。

2:32 AM

func foo<S: Sequence>(_ sequence: S) where S.Element == Int { ... }

2:32 AM

↑ができて、スペシャライズされないケースがあるんだから

2:32 AM

ABI レベルではすでにサポートされてる？

どういう意味ですか？

3:11 AM

Generalized Existentialはまだ存在しないのと、Existentialはそれが抱えるプロトコル自身にconformしないので、↑の関数にはいずれにせよ渡せないです

スペシャライズされない場合、この関数の内部では sequence は existential として扱われてるんじゃないの？

この関数の内部での表現はありますね

それがすでに実現されているということは、 ABI レベルではすでに generalized existential はサポートされていて、 generarized existential のために ABI に新たに何かを追加する必要はないのかと思ったんだけど、 AnySequence 等を使ってる標準ライブラリの ABI は変わってしまうから stable ではないのかな？

3:18 AM

まあでもそれは API の変更の一種のような気も。

「ABI レベルではすでにサポートされてる」というのは、実行時にその概念が取り扱えている　って意味で書いたんですね

3:20 AM

ABI安定化の議論のときにいつも出てくるのが

Generalized Existential を言語仕様に追加するために、 ABI 仕様を変更する必要があるかどうかという意味でした。

コンパイル済みのバイナリを言語バージョンまたいでてもリンクできるか

3:21 AM

という点で

3:21 AM

ただそれで言うと、GenExで実装されなおされたAnySequenceと

3:22 AM

昔のAnySequenceに互換性が無さそうなので

3:22 AM

よくわからなくなってしまう

そうなんだけど、 API はまだ安定化しないって言ってるんだから、それって API 変更の範疇な気もする。

3:22 AM

struct から existential に変更。

あー

3:23 AM

言語レベルで変更があった場合は

3:23 AM

API変更だから許されるのか

3:23 AM

つまり、言語レベルでは何も変わっていない場合には (edited)

3:23 AM

バイナリレベルでも互換性を保つ　というのがABI安定を達成した、ということで

3:24 AM

言語レベルで変化があるのであれば、当然バイナリ互換性も壊れてよい。

3:24 AM

確かにABIに対してはあるとしても追加的変更だけで達成できそうですね。

でもよくわかってないのが、 ABI 安定化されたら標準ライブラリはアプリにバンドルされずに OS にバンドルされたものを使うことになると思うんだけど、そうするとそういう型レベルでの変更があった場合ってぶっ壊れる気がするんだけどどうなるんだろう？

その場合はだめなんじゃないですかね・・・

それって実行するまでわからなくない？

やるとしたら、OS側に、Swift Stdlibのバージョンを何世代も持っておく必要がありますね。

3:29 AM

std ver1でビルドされたアプリは、std ver1とリンクしないと動かない

古い iOS で実行したら死亡では？ (edited)

そっちに関してはdeployment targetで守れると思います。

3:30 AM

deployment targetを下げた場合は、OSにstd ver1すらない環境を想定するので、stdlib をアプリにbundleする

3:30 AM

OSにstd ver1があるバージョンをdeployment targetにした場合は、アプリにはstdlibをbundleしないで良い（ただし、std ver1を使う、という情報はメタ情報に書いておく）

つまり、 Generalized Existential サポート後も、古い iOS を Deployment Target に指定してビルドすると、AnySequence は existential じゃない AnySequence としてビルドされる？

ABI安定化前のiOSをターゲットにしてる場合は

3:31 AM

stdlibをバンドルすればよいので

3:31 AM

最新の挙動になります

3:31 AM

ただしアプリサイズが増える。

ABI 安定化後で GenEX サポート前をターゲットとした場合 (edited)

iOS 12 : std 無し iOS 13 : std v1 プリイン iOS 14 : std v1 と v2 をプリイン iOS12向けアプリ: stdをバンドル → バンドルしてるからどこでも動く iOS13向けアプリ: std無し、v1想定、アプリサイズ縮小 → iOS13も14もv1を持ってるから動く iOS14向けアプリ : std無し、v2想定、アプリサイズ縮小→iOS14はv2を持ってるから動く (edited)

3:33 AM

理屈ではこういう構造になると思います

ということは、やっぱり Deployment Target を変更するだけで AnySequence が struct か existential か変わるってことやんね？

いや、↑のパターンだと、どれもexistentialになってる想定です。

3:37 AM

こういう想定でした > std v1 : AnySequenceはexistential, std v2: AnySequence は existential

3:39 AM

ではかりに std v1: AnySequenceはstruct , std v2 : AnySequenceはexistential の場合を考えると

3:39 AM

そうですね、iOS13向けに開発するときは、 v1想定で開発することになるから、structになるってことですね。

3:39 AM

現状でいうと、MacOS SDKとかiOS SDK を古いやつを使ってアプリを作るのと同じ状態ですね

3:40 AM

MacOS SDK、あるバージョンでは struct Nib.Name だったのが、あるバージョンでは typealias Nib.Name = String になっていて、まさにそのようなことがおきた。 (edited)

なるほど。

iOS SDKとSwift Stdlibの両方がカスタマイズ可能だとややこしそうだから

3:43 AM

iOS SDKのあるバージョンにSwift Stdlibのあるバージョンが内包される

3:43 AM

という形にすることで

3:43 AM

これまでの開発体験とあまり差をうまずに実現できそうな気がしてきた。

これまでは Swift 3 サポートとかもあったし、組み合わせになるのでは？

あーたしかに・・・

https://github.com/google/swift/pull/72/files

Implement case indent level equals switch by atamez31 · Pull Requ...

11:25 AM

グーグルは自分達のコーディングコンベンションをフォークしたswiftの中のswift formatコマンドに実装していってるのかな？

5月以来の動きですね。Harlan が進めてたと思ったけど、引き継いだのかも？

値型と参照型を同じ protocol でまとめることに無理を感じる・・・。 @swiftbot

protocol Foo { var a: Int { get set } } struct SFoo : Foo { var a: Int = 1 } class CFoo : Foo { var a: Int = 1 } func bar(_ foo: Foo) -> Int { var foo2 = foo foo2.a += 1 return foo.a + foo2.a } let sFoo = SFoo() print(bar(sFoo)) let cFoo = CFoo() print(bar(cFoo))

1

koher

protocol Foo { var a: Int { get set } } struct SFoo : Foo { var a: Int = 1 } class CFoo : Foo { var a: Int = 1 } func bar(_ foo: Foo) -> Int { var foo2 = foo foo2.a += 1 return foo.a + foo2.a } let sFoo = SFoo() print(bar(sFoo)) let cFoo = CFoo() print(bar(cFoo))

Version:

swift-4.1.1-RELEASE

Output:

3 4

Error:

参照だった場合と値だった場合で代入文の意味が変わるのを両方のケースを考慮しながら書くの無理がある感

3:46 AM

だいたいはprotocolで定義されたメソッド呼び出して終わりみたいな程度で、そこの差は踏まなかったりもするけども

デフォルトイニシャライザ、 struct S { var a: Int? var b = 1 var c = "" } ならばinit()ではなくinit(a: Int? = nil, b: Int = 1, c: String = "")にして欲しい。 (edited)

1

二つのモジュールで同名の型があるときに、片方がunavailableならambiguous出て欲しくないな〜と思った

4:35 AM

関数のオーバーロードで似た話があった気がする、RxSwiftで踏んだやつかな

swtwsのexistentialの話、FixedWidthInteger.randomもそうだったなと思って調べたんですが https://github.com/apple/swift/blob/master/stdlib/public/core/Integers.swift.gyb#L2545-L2548

C# Online Compiler | .NET Fiddle

swift - The Swift Programming Language

3:56 PM

@swift-4.2.4

func testA(a: RandomNumberGenerator) { } func testB(a: inout RandomNumberGenerator) { print(a.next()) } var r: Random = Random.default testA(a: r) // OK testB(a: &r) // error: cannot pass immutable value as inout argument: implicit conversion from 'Random' to 'RandomNumberGenerator' requires a temporary

exit status: 1 with stderr:

<stdin>:13:10: error: cannot pass immutable value as inout argument: implicit conversion from 'Random' to 'RandomNumberGenerator' requires a temporary testB(a: &r) // error: cannot pass immutable value as inout argument: implicit conversion from 'Random' to 'RandomNumberGenerator' requires a temporary ^~

RandmNumberGenerator指定するとよくわからんエラーに

3:57 PM

a,

3:58 PM

型指定Randomになってた。RandomNumberGeneratorにしたら通りますね。 inoutだと渡せない？

今更なのですがこの挙動を知りませんでした。@swiftbot

class Pen { func write() -> String { preconditionFailure("Must be overridden!") } } class GreenPen: Pen { override func write() -> String { return "Green Inks" } } var pen: Pen = GreenPen() print(pen.write()) // => "Green Inks" が返る。 // 僕は preconditionFailure("Must be overridden!") が実行されると思ってました。。

1

Ohta

class Pen { func write() -> String { preconditionFailure("Must be overridden!") } } class GreenPen: Pen { override func write() -> String { return "Green Inks" } } var pen: Pen = GreenPen() print(pen.write()) // => "Green Inks" が返る。 // 僕は preconditionFailure("Must be overridden!") が実行されると思ってました。。

Version:

swift-4.1.1-RELEASE

Output:

Green Inks

Error:

@n.0939 これはサブタイプポリモーフィズムと呼ばれる（単にポリモーフィズムと呼ばれることが多い）挙動ですね。

これができると、↓のようにコードを抽象化できます。 @swift-4.2.4

class Person { let firstName: String let lastName: String var fullName: String { fatalError("Override this.") } init(firstName: String, lastName: String) { self.firstName = firstName self.lastName = lastName } } // 西洋人 class WesternPerson: Person { override var fullName: String { return "\(firstName) \(lastName)" } } // 東洋人 class EasternPerson: Person { override var fullName: String { return "\(lastName) \(firstName)" } } let people: [Person] = [ WesternPerson(firstName: "Albert", lastName: "Einstein"), EasternPerson(firstName: "秀樹", lastName: "湯川"), ] // 西洋人と東洋人が混ざっていても姓と名を正しい順に表示 for person: Person in people { print(person.fullName) }

Albert Einstein 湯川秀樹

（すみません。中座してました。ふむ。。）

6:07 AM

（へー！）

6:11 AM

例えばC#で上記のコードをリライトしてみると、 (edited)

6:13 AM

pen2は実際はGeenPen Typeですが Pen Typeだよ、とコンパイラに？伝えているので、Pen Typeの write() メソッドが呼ばれているようです。（ここのオンラインコンソール https://dotnetfiddle.net 使ってます） (edited)

Test your C# code online with .NET Fiddle code editor.

https://wandbox.org/permlink/uwjaTQhMncBLqTbr

[C#] mcs HEAD 5.15.0.0 - Wandbox

// This file is a "Hello, world!" in C# language by Mono for wandbox. using System; namespace Wandbox { class Program { static void Main(string[] args) { Pen pen1

6:15 AM

C# の場合は、↑のように、親クラス側では virtual をつけて、子クラス側では override をつけます。

6:15 AM

親クラス側で virtual をつけないと、そのように静的ディスパッチになります。

6:16 AM

言い換えると、 Swiftの仕様は C# の仕様で見ると常に virtual が付いているようなものです。

1

@koher @omochimetaru おー！ありがとうございます。

6:20 AM

（今更ながらの恥ずかしい質問でしたが、して良かった。ありがとうございますー） (edited)

@n.0939 C++の流れを組むカプセル化・継承・ポリモーフィズムによるオブジェクト指向については昔説明を書いたので、もしお役に立ちそうだったらどうぞ↓。 https://qiita.com/koher/items/6878c80014992900add7

15分でわかるかんたんオブジェクト指向 - Qiita

最近オブジェクト指向[^1]について説明する機会が多く、これからもっと多くなりそうなので、文章にまとめることにしました。オブジェクト指向とは何かという説明はたくさんありますが、 __何のために...

1

https://github.com/apple/swift/pull/18156/files

Implement generalized accessors using yield-once coroutines by rjm...

For now, the accessors have been underscored as _read and _modify. I'll prepare an evolution proposal for this feature which should allow us to remove the underscores or, y'know, rename th...

1

1:10 AM

オーナーシップマニフェストで提案されている、コルーチンによる新しいプロパティアクセサ readとmodifyの実装が出た

1:15 AM

struct SimpleModifyのテストみたいに、セッター(modify)の下請けを参照でとおせるので、

1:15 AM

デリゲートされたプロパティの読み書きでコピーコストがかからない

1:16 AM

var temp = backingX のテストみたいに、実行コンテキストがコルーチンとして維持されているので、

1:17 AM

ローカル変数の参照を返すことが出来る C++だとdanglingになってしまうような見た目のコードがかける

or, y'know, rename them to purple and lettuce

なにこれ？ジョーク？

アンダースコア名はEvol通して直すよってことに付随したジョークだと思った

purple と lettuce という組み合わせがジョークに使われるほど定番の何かなのかかと思ったけどよくわからない・・・ (edited)

2

https://github.com/apple/swift/pull/17767 unowned が Optional を保持できるようになるそうで。これは嬉しい！

Enable optional unowned/unowned(unsafe) references by davezarzycki...

@rjmccall okayed this change in a comment on GitHub pull request: #16237

ほう。 @swift-4.2.4 @swift-main

import Foundation protocol Protocol : class { func noop() } class SwiftClassBase : Protocol { func noop() { print("noop") } } class SwiftClass : SwiftClassBase { override init() { print("SwiftClass Created") } deinit { print("SwiftClass Destroyed") } } func printState(_ x : SwiftClassBase?) { print((x != nil) ? "is present" : "is nil") } func testSwiftClass() { print("testSwiftClass") // CHECK: testSwiftClass unowned var w : SwiftClassBase? printState(w) // CHECK-NEXT: is nil var c : SwiftClassBase = SwiftClass() // CHECK: SwiftClass Created printState(w) // CHECK-NEXT: is nil w = c printState(w) // CHECK-NEXT: is present c.noop() // CHECK-NEXT: noop c = SwiftClassBase() // CHECK-NEXT: SwiftClass Destroyed } testSwiftClass()

testSwiftClass is nil SwiftClass Created is nil is present noop SwiftClass Destroyed

exit status: 1 with stderr:

<stdin>:28:15: error: 'unowned' may only be applied to class and class-bound protocol types, not 'SwiftClassBase?' unowned var w : SwiftClassBase? ^

weak var w: SwiftClassBase? と何が違うんです？

@swift-main

class C {} func test() { var owner: C? = C() unowned var consumer: C? = owner print(consumer) owner = nil print(consumer) } test()

exit status: 134 with stdout:Optional(main.C)stderr:

<stdin>:6:9: warning: expression implicitly coerced from 'C?' to 'Any' print(consumer) ^~~~~~~~ <stdin>:6:9: note: provide a default value to avoid this warning print(consumer) ^~~~~~~~ ?? <#default value#> <stdin>:6:9: note: force-unwrap the value to avoid this warning print(consumer) ^~~~~~~~ ! <stdin>:6:9: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(consumer) ^~~~~~~~ as Any <stdin>:8:9: warning: expression implicitly coerced from 'C?' to 'Any' print(consumer) ^~~~~~~~ <stdin>:8:9: note: provide a default value to avoid this warning print(consumer) ^~~~~~~~ ?? <#default value#> <stdin>:8:9: note: force-unwrap the value to avoid this warning print(consumer) ^~~~~~~~ ! <stdin>:8:9: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(consumer) ^~~~~~~~ as Any <stdin>:5:15: warning: variable 'consumer' was never mutated; consider changing to 'let' constant unowned var consumer: C? = owner ~~~ ^ let Fatal error: Attempted to read an unowned reference but object 0x6f92c80 was already deallocatedCurrent stack trace: 0 libswiftCore.so 0x00007f03c10ce84d <unavailable> + 3971149 1 libswiftCore.so 0x00007f03c10cea22 <unavailable> + 3971618 2 libswiftCore.so 0x00007f03c10cff70 swift_unownedRetainStrong + 98 5 swift 0x0000000001041bae <unavailable> + 12852142 6 swift 0x0000000001045cd2 <unavailable> + 12868818 7 swift 0x00000000004fa1d2 <unavailable> + 1024466 8 swift 0x00000000004e0104 <unavailable> + 917764 9 swift 0x00000000004db2ec <

stderr.txt

https://file.io/jzZVzy

開放されてたら nil にならずにトラップしてくれる。正直使いどころは限られてはいますが、僕は何度か欲しかったことがありますね。

式の型はnon optionalなのですね

10:43 AM

ん？

10:44 AM

式の型はoptionalだけど、someの場合の参照先が解放された場合は、クラッシュするのか。

@swift-main

class Cat { func nya() -> String { return "nya" } } unowned var a: Cat? = nil print(a?.nya() ?? "nil") var b: Cat? = Cat() a = b print(a?.nya() ?? "nil") b = nil print(a?.nya() ?? "nil")

(edited)

exit status: 134 with stdout:nil nyastderr:

Fatal error: Attempted to read an unowned reference but object 0x820d200 was already deallocatedCurrent stack trace: 0 libswiftCore.so 0x00007f0abfb4384d <unavailable> + 3971149 1 libswiftCore.so 0x00007f0abfb43a22 <unavailable> + 3971618 2 libswiftCore.so 0x00007f0abfb44f70 swift_unownedRetainStrong + 98 4 swift 0x0000000001041bae <unavailable> + 12852142 5 swift 0x0000000001045cd2 <unavailable> + 12868818 6 swift 0x00000000004fa1d2 <unavailable> + 1024466 7 swift 0x00000000004e0104 <unavailable> + 917764 8 swift 0x00000000004db2ec <unavailable> + 897772 9 swift 0x000000000048aa28 <unavailable> + 567848 10 libc.so.6 0x00007f0ac238b740 __libc_start_main + 240 11 swift 0x00000000004886e9 <unavailable> + 558825 #0 0x0000000004102324 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x4102324) #1 0x00000000041001b2 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x41001b2) #2 0x00000000041024d2 SignalHandler(int) (/usr/bin/swift+0x41024d2) #3 0x00007f0ac3c61390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f0ac23a0428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #5 0x00007f0ac23a202a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #6 0x00007f0abfb43852 (/usr/lib/swift/linux/libswiftCore.so+0x3c9852) #7 0x00007f0abfb43a22 (/usr/lib/swift/linux/libswiftCore.so+0x3c9a22) #8 0x00007f0abfb44fd2 swift_unownedRetainStrong (/usr/lib/swift/linux/libswiftCore.so+0x3cafd2) #9 0x00007f0ac40904f2 #10 0x0000000001041bae llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) (/usr/bin/swift+0x1041bae) #11 0x0000000001045cd2 llvm::ExecutionEngine::runFunctionAsMain

(edited)

stderr.txt

https://file.io/rjAMHH

.some, .none, .some(released) の 3状態あるのかあ。

一応外側はsomeの扱いになるんです？

扱いという意味では調べようとした瞬間に落ちるからどちらとも言えないんじゃない？

4:15 PM

内部的には「解放済みのオブジェクト」を参照してるからSome、というかポインタが入ってるはずだけど。

ああそうか、実行時はポインタになるから一緒か

4:15 PM

some/none/fatal な感覚だった

弱参照というのは解放されてるとnilになるけど内部的には開放された領域を指すアドレスを持っているので。

4:16 PM

型理論的には fatal = Never だから 2 + 0 でやっぱり 2状態Eitherとisomorphicなのかな。おもしろいね。

1

全然関係ないけど最近Mirror使ってて、Mirrorから見たlazy propertyはOptionalになってるのを確認した

それはlazy propertyの裏にあるbacking fieldが見えてるのかな？Mirrorってcomputed propertyは見えないよね

おあ、勘違いしてる可能性ありそう

4:20 PM

@swift-4.1.3 class Cat { lazy var name: Int = 1 } print(Mirror(reflecting: Cat()).children.count) (edited)

1 (edited)

空で書いたらだめだった

4:21 PM

こうなるの

4:21 PM

countが見えてて

4:22 PM

@swift-4.1.3 class Cat { lazy var name: Int = 1 } print(Mirror(reflecting: Cat()).children.first!) (edited)

(label: Optional("name.storage"), value: nil) (edited)

もしかして

何間違えてるかわからんくなった

lazyって解決するときに関数を再代入してる？

4:24 PM

分岐が以後なくなるように。

参照されて初めて後置のautoclosureを展開してるように見えていて

いや、ちがうか？ expression type '(_) -> _' is ambiguous を見てそうおもったけどなんかコンパイルエラーになってる？

コンパイルエラーはそう

4:25 PM

なんかミスってる

type of Mirror になってて変だな。

きたきたこれこれ

4:27 PM

Mirror経由でfoo.storageにアクセスできて

4:27 PM

そこがOptionalになってるんですよ

name.storage、それっぽい

そしてnilだと後置のautoclosureが展開される

4:28 PM

即ち！謂わばweak,unownedと逆っぽい動きだねって話でした

逆？

丁度対照的な動きをしてる直感的にそんな

4:29 PM

昔ひらりがweakとlazy組み合わせられないのはなんでじゃと言っていたが、この辺の動きを垣間見るに現状は難しいんだなぁと言うのが腑に落ちた

//a.swift class Cat { lazy var name: Int = 1 } swiftc -emit-sil a.swift //a.sil class Cat { lazy var name: Int { get set } @sil_stored final var name.storage: Int? init() deinit }

4:30 PM

SILにしたらわかりやすかった↑

後なんか、IBOutletもstorageついとったような気がする

4:33 PM

@swift-4.1.3

class Cat { lazy var name: Int = 1 } class Dog { weak var name: AnyObject? } print(Mirror(reflecting: Cat()).children.first!) print(Mirror(reflecting: Dog()).children.first!)

(label: Optional("name.storage"), value: nil) (label: Optional("name"), value: nil)

weakがstorageになるかと思ったがそうでもなかったの

import Foundation @objc class Cat : NSObject { @IBOutlet var name: Cat? } @objc class Cat : NSObject { @sil_stored @IBOutlet var name: Cat? { get set } @usableFromInline override init() deinit }

4:33 PM

IBOutletはそのままっぽい

見間違いぽい

ほほー。 @swift-main -Xfrontend -emit-sil class Cat { unowned var parent: Cat? }

sil_stage canonical import Builtin import Swift import SwiftShims class Cat { @sil_stored unowned var parent: @sil_unowned Cat? { get set } init() deinit } // main sil @main : $@convention(c) (Int32, UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>) -> Int32 { bb0(%0 : $Int32, %1 : $UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>): %2 = integer_literal $Builtin.Int32, 0 // user: %3 %3 = struct $Int32 (%2 : $Builtin.Int32) // user: %4 return %3 : $Int32 // id: %4 } // end sil function 'main' // Cat.parent.getter sil hidden [transparent] @$S4main3CatC6parentACSgXovg : $@convention(method) (@guaranteed Cat) -> @owned Optional<Cat> { // %0 // users: %2, %1 bb0(%0 : $Cat): debug_value %0 : $Cat, let, name "self", argno 1 // id: %1 %2 = ref_element_addr %0 : $Cat, #Cat.parent // user: %3 %3 = begin_access [read] [dynamic] %2 : $*@sil_unowned Optional<Cat> // users: %4, %6 %4 = load %3 : $*@sil_unowned Optional<Cat> // user: %5 %5 = copy_unowned_value %4 : $@sil_unowned Optional<Cat> // user: %7 end_access %3 : $*@sil_unowned Optional<Cat> // id: %6 return %5 : $Optional<Cat> // id: %7 } // end sil function '$S4main3CatC6parentACSgXovg' // Cat.parent.setter sil hidden [transparent] @$S4main3CatC6parentACSgXovs : $@convention(method) (@owned Optional<Cat>, @guaranteed Cat) -> () { // %0 // users: %12, %6, %2 // %1 // users: %4, %3 bb0(%0 : $Optional<Cat>, %1 : $Cat): debug_value %0 : $Optional<Cat>, let, name "value", argno 1 // id: %2 debug_value %1 : $Cat, let, name "self", argno 2 // id: %3 %4 = ref_element_addr %1 : $Cat, #Cat.parent // user: %5 %5 = begin_access [modify] [dynamic] %4 : $*@sil_unowned Optional<Cat> // users: %9, %8, %11 %6 = ref_to_unowned %0 : $Optional<Cat> to $@sil_unowned Op

stdout.txt

https://file.io/Ne3JAF

#beginner-help-archived から移動。

4:48 AM

えー

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language. In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).

4:49 AM

そのわずかな差をがんばるために Memory Ownership とかやってるんじゃないの？

4:49 AM

それとも分岐予測が優秀で本当に差がない？

安全な言語を目指すゴールとは反する -O と比べてそんなに差がなかった

(edited)

これを捨てて C++ や Rust と戦えるのかな？

&+ なり unowned(unsafe) なり使って、プログラマ自身が頑張れってことなのか。

まあMemoryOwnershipはコピーコストの回避が主で、 uncheckedは分岐削除が主かなあ

4:51 AM

分岐予測が当たればほぼ大丈夫で安全側に予測するからって大丈夫って感じかなあ。

たとえば、 image[x, y] みたいなのでピクセルごとにループしてて、毎回 precondition があったらたとえ分岐予測あってもきつくないかな？

So if we replace Ounchecked with an option -unsafe-remove-checks (similar to -assume-single-threaded), as Johannes suggested, this is more like a “at your own risk” thing (regarding performance). For example, it might happen that users see perf regressions from one release to another, using this option.

4:53 AM

-unsafe-remove-checks ってフラグは残るのかしら。 (edited)

4:54 AM

I would suggest going further and removing the code for -unsafe-remove-checks altogether. Even untested code has a cost in terms of maintainability.

4:54 AM

Slavaはそれも消せって言ってたｗ

えー

ラトナーは懐疑的っぽいですね

4:55 AM

I don’t necessarily agree. -Ounchecked isn’t “bad”. It is a feature in service of a few specific use cases. If you’d like to remove it, then you should publicly advertise that, and justify it based on the lack of users. Don’t cast value judgements against it and claim it should be removed on moral grounds.

4:55 AM

It is a feature in service of a few specific use cases.

↑僕もこう考えてた

4:56 AM

ラトナ: まあEvolだしてねスラバ: コンパイラオプションってEvolなの？

4:56 AM

このスレおもろいな。

コマンドのオプションの変更は UI の変更だから evolution 通してねというやりとりを前にも見た気が。

ほー

SwiftPM だっけ。

I don’t think there is an official policy, but IMO, all major new user visible features are in scope for evolution.

4:57 AM

ラトナーの意見であってオフィシャルポリシーは無いらしいｗ

ｗ

4:58 AM

-Ounchecked なくなったらいやだなぁ・・・。

スレでは完全に合意形成されたわけではないっぽいですね

それなのにベンチマークから消したのか？先走り過ぎじゃない？

概ね廃止派が主流という感じでベンチマークはなくなったけど。

4:59 AM

コンパイラのロジックとしては -unsafe-remove-checks がある限りありそう。

-unsafe-remove-checks があるならいいと思う。

4:59 AM

最適化の有無とは直交した概念な気も。

そうですね。

PM追えてないから分からないけど、 swift run を PM に明け渡した時は evol 通しましたよね。

でしたね。Evol出てたの覚えてる。 (edited)

5:01 AM

あ、こんな細かいのもわざわざやるんだ・・・って思った。

まあ、最適化しないのに -unsafe-remove-checks したいケースというのも思いつかないけど

あれ、structのletフィールドってEncoderに反映されるようになったんでしたっけ

9:04 AM

@swift-4.0.3 @swift-4.1.3

import Foundation struct Foo: Codable { let a = 1 } let encoder = JSONEncoder() print(try String(data: encoder.encode(Foo()), encoding: .utf8))

(edited)

Optional("{\"a\":1}")stderr:

<stdin>:7:7: warning: expression implicitly coerced from 'String?' to Any print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <stdin>:7:11: note: provide a default value to avoid this warning print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ?? <#default value#> <stdin>:7:11: note: force-unwrap the value to avoid this warning print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! <stdin>:7:11: note: explicitly cast to Any with 'as Any' to silence this warning print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ as Any

(edited)

Optional("{\"a\":1}")stderr:

<stdin>:7:7: warning: expression implicitly coerced from 'String?' to Any print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <stdin>:7:11: note: provide a default value to avoid this warning print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ?? <#default value#> <stdin>:7:11: note: force-unwrap the value to avoid this warning print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! <stdin>:7:11: note: explicitly cast to Any with 'as Any' to silence this warning print(try String(data: encoder.encode(Foo()), encoding: .utf8)) ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ as Any

(edited)

@swift-4.1.3

import Foundation struct HaveCahceObject: Codable { private class Cache: Codable { var cachedString: String? init(from decoder: Decoder) throws { } func encode(to encoder: Encoder) throws { } init() {} } var int: Int { didSet { cache.cachedString = nil } } private let cache = Cache() var string: String { get { if cache.cachedString == nil { cache.cachedString = "\(int)" } return cache.cachedString! } } init(int: Int) { self.int = int } } let object = HaveCahceObject(int: 1) let encoder = JSONEncoder() let decoder = JSONDecoder() print( try decoder.decode(HaveCahceObject.self, from: """ {"int": 123} """.data(using: .utf8)!).string ) print( try String(data: encoder.encode(object), encoding: .utf8)! )

エンコ時にちょっとしたゴミが入るけど消す方法無いかな (edited)

exit status: 134 with stderr:

swift: /home/buildnode/jenkins/workspace/oss-swift-4.1-package-linux-ubuntu-16_04/swift/lib/IRGen/MetadataLayout.h:173: const swift::irgen::ClassMetadataLayout::StoredMethodInfo &swift::irgen::ClassMetadataLayout::getStoredMethodInfo(swift::SILDeclRef) const: Assertion `it != MethodInfos.end()' failed. #0 0x0000000003f25074 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x3f25074) #1 0x0000000003f253b6 SignalHandler(int) (/usr/bin/swift+0x3f253b6) #2 0x00007f9eb908d390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007f9eb77cc428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #4 0x00007f9eb77ce02a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #5 0x00007f9eb77c4bd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7) #6 0x00007f9eb77c4c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #7 0x0000000000614484 swift::irgen::ClassMetadataLayout::getMethodInfo(swift::irgen::IRGenFunction&, swift::SILDeclRef) const (/usr/bin/swift+0x614484) #8 0x00000000005460bc swift::irgen::emitVirtualMethodValue(swift::irgen::IRGenFunction&, llvm::Value*, swift::SILType, swift::SILDeclRef, swift::CanTypeWrapper<swift::SILFunctionType>, bool) (/usr/bin/swift+0x5460bc) #9 0x00000000005dce62 swift::SILInstructionVisitor<(anonymous namespace)::IRGenSILFunction, void>::visit(swift::SILInstruction*) (/usr/bin/swift+0x5dce62) #10 0x00000000005d6242 (anonymous namespace)::IRGenSILFunction::emitSILFunction() (/usr/bin/swift+0x5d6242) #11 0x00000000005d3d3b swift::irgen::IRGenModule::emitSILFunction(swift::SILFunction*) (/usr/bin/swift+0x5d3d3b) #12 0x00000000004e641b swift::irgen::IRGenerator::emitLazyDefinitions() (/usr/bin/swift+0x4e641b) #13 0x00000000005ad837 performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, std::unique_ptr<swift::SILModule, std::default_delete<swift::SILModule> >, llvm::StringRef, llvm::LLVMContext&, swift::SourceFile*, llvm::GlobalVariable**, unsigned int) (/usr/bin/swift+0x5ad837) #14 0x00000000005abfdd swift::

(edited)

stderr.txt

https://file.io/J1srLc

あれ…

@omochimetaru 省略するにはデフォルト値が必要らしい。そりゃそうだ。

case自体を省略するとエンコード・デコードされない。この時、Decodableにするにはdefault valueが必要。

https://qiita.com/_ha1f/items/bf1aad5ea3e927f59f9d

Codableについて色々まとめた[Swift4.x] - Qiita

はじめに

Swift 4対応の一つ、Codableについていくつか疑問点を実験しつつ、日本語でまとめました。元記事は以下ですが、たぶん元記事よりも補足しています。 [Encoding and Decoding Custom...

9:49 AM

@swiftbot struct Foo: Codable { private enum CodingKeys: CodingKey { case a } var a: Int private var _b: String = "" }

1

koher

struct Foo: Codable { private enum CodingKeys: CodingKey { case a } var a: Int private var _b: String = "" }

Version:

swift-4.1.1-RELEASE

Output:

Error:

caseから除去してデフォルトを与えとけばいいのかｗ

前にletがエンコードされないとか話題になってなかったでしたっけ

そんな話ありましたっけ？？

夢の可能性が高くなってきた…

1

2:27 PM

codable+letで過去ログ検索するとデコード時の挙動について出てきたのでこれが混濁してますね、 (edited)

2:29 PM

さし当たり、 1. Cacheを型に纏める 2. Cacheを除いたCodingKeyを定義すると言うのが手っ取り早そうです

デフォルト値付きletはエンコードされるけどデコードされない、って話かな？

そうっぽい

@swift-4.1.3

import Foundation struct S: Codable { var p1: String let p2 = 1 } let encoder = JSONEncoder() encoder.outputFormatting = .sortedKeys let json = String(data: try encoder.encode(S(p1: "p1")), encoding: .utf8) print(json == """ {"p1":"p1","p2":1} """) // true let s = try JSONDecoder().decode(S.self, from: """ {"p1":"p1","p2":2} """.data(using: .utf8)!) print(s.p2 == 2) // false

1

true false

@swiftbot

struct Foo { var foo: Int var bar: Int var buz: Int init(foo: Int, buz: Int) { self.foo = foo self.bar = foo*3 guard foo < bar && bar > 0 else { fatalError() } self.buz = buz } }

1

t.ae

struct Foo { var foo: Int var bar: Int var buz: Int init(foo: Int, buz: Int) { self.foo = foo self.bar = foo*3 guard foo < bar && bar > 0 else { fatalError() } self.buz = buz } }

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:10:28: error: variable 'self.buz' captured by a closure before being initialized guard foo < bar && bar > 0 else { ^

謎エラー

guardって脱出を想定してるから

&& の右辺が autoclosure でラップされるので

buzの初期化前に脱出できない？

あーautoclosure

&&の右だけ self.bar なのか。

7:18 AM

じゃあ、カンマ区切りの構文で書いたら、回避できる？

でもbuzが云々言われるのはおかしい気が

buzが初期化されてないのにselfをキャプチャしたっていうエラーでしょ

7:18 AM

文言はちょっと変だけど

self がキャプチャされてて、そのプロパティが未初期化っていうエラーですね。

ああそうか。buz自体がキャプチャされたみたいに読んでました

7:19 AM

カンマ区切りだと回避できますね

カンマ区切りと&&の本質的な違いだ

||使いたいときはどうしようもなさそう？

not のカンマにして if 使う？

ド・モルガンだ

let _bar = bar とかで一度変数に逃がして || _bar > 0 などするのが解決方法ではありますが、めんどくさいですね。 (edited)

self キャプチャって nonescaping でもダメなんだっけ？

なるほどカンマ前で逃がせばキャプチャ回避できるのかｗ

7:22 AM

賢い・・・

ダメなのか。 @swiftbot struct Foo { var a: Int var b: Int init() { a = 2 b = [2, 3, 5].reduce(0) { $0 + $1 + a } } }

1

koher

struct Foo { var a: Int var b: Int init() { a = 2 b = [2, 3, 5].reduce(0) { $0 + $1 + a } } }

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:7:33: error: variable 'self.b' captured by a closure before being initialized b = [2, 3, 5].reduce(0) { $0 + $1 + a } ^

selfがだめなのはまぁ理解できますね

7:25 AM

autoclosureじゃないならaを明示的にキャプチャすればいけるのかな

@swiftbot struct Foo { var a: Int var b: Int init() { a = 2 b = [2, 3, 5].reduce(0) { [a] in $0 + $1 + a } } }

1

koher

struct Foo { var a: Int var b: Int init() { a = 2 b = [2, 3, 5].reduce(0) { [a] in $0 + $1 + a } } }

Version:

swift-4.1.1-RELEASE

Output:

Error:

明示キャプチャは OK

7:27 AM

nonescaping なら未初期化 self キャプチャしても良さそうな気もするけどなぁ。

7:27 AM

autoclosure の問題というより、そっちの問題のような気が。

7:28 AM

もちろん↑で self.b へのアクセスはアウトですが、（ nonescaping なら） self.a へのアクセスは許してほしい。 (edited)

複雑なことしたいならローカルに同名の変数用意して最後にまとめて代入がわかりやすそう

callerから見るとnonescapingなクロージャにわたす行為は

7:30 AM

0回以上のクロージャ呼び出しと等価だから

7:30 AM

while ループがそれと同じだから

7:31 AM

Definitive Initializationの機構としては対応できそう

7:31 AM

あとはキャプチャ機構の方だけど

7:31 AM

nonescapingのときに必ず参照キャプチャになっているなら

7:31 AM

selfが値型だろうが

7:32 AM

不完全selfのコピー方法がわからない問題は回避できるから

7:32 AM

理論上はいけそうですね、実装は大変そうだけど

7:32 AM

キャプチャがコピーキャプチャになるケースが存在するなら、selfが不完全だとそれができないから、ダメそう

うん、↓だからそれで許されてることは許してほしい。

0回以上のクロージャ呼び出しと等価だから while ループがそれと同じだから

7:37 AM

一方で、↓もできると便利だけど、 1 回以上実行であることが保証できない（ 0 回の可能性がある）からこれは許容できない。 func run(_ f: () -> ()) { f() } var a: Int run { a = 42 } print(a)

それ、ほしいですよね

7:38 AM

@invokeExactlyOnce @invokeOnceOrMore

let だと 1 回であることを保証しないといけない

7:38 AM

うん、そういうのがあると便利だと思う。

前回のwaiwaiswiftcで松本さんともその話した

7:39 AM

この辺の話ってasync/awaitでコルーチン入るときに強化されるのかなあ

そのフロー解析はできそうな気がしてるけど、停止判定みたいなことにならないよね？

awaitしながらinitしたいですよね

7:39 AM

停止判定問題にはならないですね

7:39 AM

少なくとも確実という場合を保証するだけだから。

普通にフローたどって、クロージャーの再帰呼び出しがあっても

7:39 AM

それも再帰的にたどるだけでいけるかな。

https://forums.swift.org/t/guaranteed-closure-execution/1233

Guaranteed closure execution

Hello, I’d like to discuss the opportunity to let functions declare that a closure argument is guaranteed to have been executed when the function has returned. For example: func f(@noescape(executed) closure: () -> ()) { closure() } The expected ad...

そうやって条件を拡張していくとだんだん難しくなりそうですね

7:40 AM

2016年！ｗ

7:41 AM

Please, don’t bump threads from years ago like this.

Clearly, you’ve got some thoughts in mind about the topic and it’s fresh on your mind, but by doing this you’re putting the onus on everyone to re-read 60 messages before they can even begin to comment

7:41 AM

最後のコメントが、これめっちゃあるなあと思った。

7:42 AM

60ならまだ軽い方で、200ぐらいある1年前の過去スレから始まるともう気持ちが折れる

現在の議論の状態をまとめてくれる人がいないと辛いよね。

7:43 AM

日本語でも辛いのに、英語だと・・・

でもそれはそれで中立性がな・・・

まあ、そこで中立性が崩れても、足りないのは漏れてると思う人が補えば良いわけで、

まあ何もないよりは良いか。

これを読んだ人じゃないと新たな議論ができないというのはきつい。

7:44 AM

ただ、誰も全体像を把握してないというのが一番有り得そう・・・

あと元の @autoclosure 問題は https://bugs.swift.org/browse/SR-7990

3

@omochimetaru やっぱ前から話してるような議論プラットフォームが必要だと思う。

7:48 AM

@omochimetaru

awaitしながらinitしたいですよね

これできるなら mutating で async な func もサポートすることになるのでは？

7:48 AM

できたらうれしいけど原理的にきつい気がするんだけど・・・。

ならないとおもいます

7:49 AM

メソッドはすでに存在するオブジェクトに対して実行しないといけないから

7:49 AM

スタックにある場合にコルーチンコンテキストに退避できないけど

7:49 AM

initの場合はallocから async init とわかって呼ばれるから

7:50 AM

static func が Promise<Self> を返す場合と同様で　対応できるはず

うーん、たしかに init ならできるか？

https://nshipster.com/never/

Never

Making a claim that something will never be the case can feel like an invitation for the universe to prove otherwise. Fortunately for us, Swift lives up to this higher standard thanks to the unlikeliest of types.

11:37 AM

Result<String, Never>だとswitchでcase . failure書かなくても良いのか。 @swift-main

import Foundation enum Result<Value, Error: Swift.Error> { case success(Value) case failure(Error) } func alwaysSucceeds(_ completion: (Result<String, Never>) -> Void) { completion(.success("yes!")) } alwaysSucceeds { (result) in switch result { case .success(let string): print(string) } }

2

yes!

Swift 4.2でArrayに生えたshuffled(using:)を試しているのですが、型にProcotolを書くと通らない...

import Foundation class A: RandomNumberGenerator {} var a: RandomNumberGenerator = A() [1, 2, 3].shuffled(using: &a) // error: argument passed to call that takes no arguments // [1, 2, 3].shuffled(using: &a) var b = A() [1, 2, 3].shuffled(using: &b) // Success

3:12 PM

shuffledと似たような関数を自分で書くと

3:13 PM

import Foundation func shuffled<T>(using generator: inout T) -> [Int] where T : RandomNumberGenerator { return [] } class A: RandomNumberGenerator {} var a: RandomNumberGenerator = A() shuffled(using: &a) // error: in argument type 'inout RandomNumberGenerator', 'RandomNumberGenerator' does not conform to expected type 'RandomNumberGenerator' // shuffled(using: &a) ^

3:13 PM

'RandomNumberGenerator' does not conform to expected type 'RandomNumberGenerator'ってなんだ...

3:16 PM

~~これ関係あるかも~~ 関係なさそうだった https://bugs.swift.org/browse/SR-7918?jql=text%20~%20%22RandomNumberGenerator%22 (edited)

これって a の型が実際にはExistentialになっているからっていうやつ？

ですね

10:51 PM

Existentialで拡張したいときは

10:51 PM

extension Array where Element==Existentialにします。:だと具体型が通る

10:52 PM

@swift-4.2.4

import Foundation func shuffled(using generator: inout RandomNumberGenerator) -> [Int] { return [] } class A: RandomNumberGenerator {} var a: RandomNumberGenerator = A() print(shuffled(using: &a))

どうやろか (edited)

[] (edited)

ンゴゴ

意味がわからない

そもそもTにしなくていい

10:54 PM

ほい

そうすると、 Array.shuffled(using:) がなぜTを使っているのかという疑問が湧いてきました

具体型がほしいからですよ

逆にTを使わないと、どういう問題が出るんですか？

この場合はinoutで渡してるので、existentialだと実行時のメモリ周りで問題が出てくることになりそう、パフォーマンスが悪い、とか。直感ですが…

Tを使うとspecializeされて、ってこと？

existentialでmutatingやるのは効率悪そうだなーという雰囲気を感じている

11:09 PM

でもRandom...のprotocolの制約にはmutatingとは書いてないですね、なんでだろう

ん？ next() が mutating なんじゃないですか？

あれ、そうなんですか。ドキュメント読んでるんですが書いてない

https://developer.apple.com/documentation/swift/randomnumbergenerator/2996532-next

かいてある！

11:14 PM

https://developer.apple.com/documentation/swift/randomnumbergenerator

一覧の方には書いてないのか！

ここから見ると見えない

11:15 PM

ひどひどのひどだ

1

@swift-4.2.4

import Foundation func shuffled(using generator: inout RandomNumberGenerator) -> [Int] { return [] } class A: RandomNumberGenerator {} var a = A() print(shuffled(using: &a))

(edited)

exit status: 1 with stderr:

<stdin>:10:23: error: cannot pass immutable value as inout argument: implicit conversion from 'A' to 'RandomNumberGenerator' requires a temporary print(shuffled(using: &a)) ^~

Tを使わないと、existentialになったものしか渡せなくなるんですね

inoutだとそういう縛りが出るのか、それは知らなかったです

罠だ。。。

11:41 PM

暗黙的にexistentialを作って渡すことになるけど、そうすると作ったexistentialがvarにはならないからってことですね。

暗黙生成のexistentialから元のvar具体型へのフィードバックができないからっぽいですね

11:42 PM

メモリ共有されないのか

@hironytic @tarunon なるほど！やっぱり具体型なのか... ありがとうございます！genericsで渡さないようにしてほしい...

暗黙生成のexistentialから元のvar具体型へのフィードバックができない

これ意図した挙動なんですかね？

1

2:08 AM

@swift-4.2.4

protocol Animal {} struct Cat: Animal {} var cat = Cat() var animal: Animal = cat func updateAnimal(_ animal: inout Animal) {} updateAnimal(&animal) updateAnimal(&cat) // エラー

exit status: 1 with stderr:

<stdin>:10:14: error: cannot pass immutable value as inout argument: implicit conversion from 'Cat' to 'Animal' requires a temporary updateAnimal(&cat) // エラー

@Nonchalant 僕は Swift ではできるだけ Existential （プロトコル型変数や引数）を使わないのをオススメします。パフォーマンスも悪いし。 (edited)

1

@koher なるほど...型の依存関係を解決する関係でパフォーマンスが悪いってことですよね... existentialの関係でサブクラスよりパフォーマンスが悪いのかな

Existential container に詰め込まれるからですね。実行時にはそれを展開しなおして処理されますし、メソッドコール等も動的ディスパッチになってしまいます。

1

2:17 AM

ジェネリック関数で型パラメータが特殊化されたらコンパイル時に静的に解決できるので速いです（必ず特殊化されるとは限りませんが）。

なるほど...知らなかったです...

‍♀️

2:17 AM

ありがとうございます！

1

ぼくもちゃんと理解できているか怪しいのですが、ukitakaさんのこの記事で細かく説明されています

https://qiita.com/ukitaka/items/8bcff4348c79d820ba32

Swiftでprotocol型の値がそのprotocol自身にconformして...

iOSのDiscordで定期的にあがる話題として「protocol型の値がそのprotocol自身にconformしていないのはなぜ？」というものがあります。例えば以下のようなコードです。 ```swift protocol An...

暗黙生成のexistentialから元のvar具体型へのフィードバックができない

一応コンパイルエラーになってるってことは認知された問題で防がれている、ぶっ壊れる系ではない

意図的にコンパイルエラーにしているならそうですが、普通に作ったらエラーになって、穴を開け忘れてる可能性もあるのかなと。値型を existential container に入れてもインスタンス共有されないとかはがんばってるのに、 inout はできないというのにちょっと違和感を感じたので。

Cat 型の変数をinout で渡して Dog が代入されたら困るからじゃないかな。

protocol Animal { mutating func eat() } struct StructCat : Animal { var weight: Int = 1 mutating func eat() { weight += 1 } } func feed(animal: Animal) { var animal = animal animal.eat() dump(animal) } feed(animal: StructCat())

3:46 AM

mutating func の呼び出しはできるから、できてもいいじゃないかと思ったんだけど・・・

3:46 AM

もし、できるとすると

3:46 AM

protocol Animal { mutating func eat() mutating func copyFrom(_ other: Self) }

3:46 AM

↑代入は Self を取る mutating func と等価だから、 Selfを使っちゃって、Existentialが使えなくなる

Cat 型の変数をinout で渡して Dog が代入されたら困るからじゃないかな。

たしかにこれまずそう。

3:56 AM

inout に existential を渡してるなら Cat が Dog に変えられてもいいけど、 Cat を渡して暗黙的に変換された existential に Dog が書かれたら Cat に書き戻せない。

なるほど。existentialの問題というより、単純にvarianceの問題なわけですね。

4:50 AM

@swift-4.2.4 import Foundation class Animal { } class Dog: Animal { } func foo(_ animal: inout Animal) { } var inu = Dog() foo(&inu)

exit status: 1 with stderr:

<stdin>:9:5: error: cannot pass immutable value as inout argument: implicit conversion from 'Dog' to 'Animal' requires a temporary foo(&inu) ^~~~

普通、Animal型の変数にはDogが代入できるけど、この場合は実体があるから、書き込みがcontravarianceなのね

mutating funcでself書き換えて悪さできないかしら

Cat の mutating func の self は Cat だから別の Animal に書き換えれないので無理そう？

@swiftbot

protocol AnimalProtocol {} extension AnimalProtocol { mutating func replace(with obj: Self) { self = obj } } class AnimalBase : AnimalProtocol {} class Cat: AnimalBase {} class Dog: AnimalBase {} var cat: AnimalBase = Cat() cat.replace(with: Dog()) print(type(of: cat))

a

1

rintaro

protocol AnimalProtocol {} extension AnimalProtocol { mutating func replace(with obj: Self) { self = obj } } class AnimalBase : AnimalProtocol {} class Cat: AnimalBase {} class Dog: AnimalBase {} var cat: AnimalBase = Cat() cat.replace(with: Dog()) print(type(of: cat))

Version:

swift-4.1.1-RELEASE

Output:

Dog

Error:

草

ああ、これはOKか。

class変数のmutating funcがvar変更になるやつだ・・・

7:24 AM

でもextensionだと引数にSelfが使えるの穴開きそう

@swiftbot

protocol AnimalProtocol {} extension AnimalProtocol { init(_with obj: Self) { self = obj } } class AnimalBase : AnimalProtocol { convenience init(with obj: AnimalBase) { self.init(_with: obj) } } class Cat: AnimalBase {} class Dog: AnimalBase {} var cat: Cat = Cat(with: Dog()) print(type(of: cat))

1

rintaro

protocol AnimalProtocol {} extension AnimalProtocol { init(_with obj: Self) { self = obj } } class AnimalBase : AnimalProtocol { convenience init(with obj: AnimalBase) { self.init(_with: obj) } } class Cat: AnimalBase {} class Dog: AnimalBase {} var cat: Cat = Cat(with: Dog()) print(type(of: cat))

Version:

swift-4.1.1-RELEASE

Output:

Dog

Error:

闇が深いのはこっちだ。

protocol AnimalProtocol {} extension AnimalProtocol { mutating func replace(with obj: Self) { self = obj } } struct Cat: AnimalProtocol {} struct Dog: AnimalProtocol {} var cat: AnimalProtocol = Cat() cat.replace(with: Dog()) print(type(of: cat)) /* error: iOSGround.playground:6:1: error: member 'replace' cannot be used on value of protocol type 'AnimalProtocol'; use a generic constraint instead cat.replace(with: Dog()) ^~~ ~~~~~~~ */

7:28 AM

セーフだった。

@swiftbot

protocol AnimalProtocol {} extension AnimalProtocol { init(_with obj: Self) { self = obj } mutating func replace(with obj: Self) { self = obj } } class AnimalBase : AnimalProtocol { convenience init(with obj: AnimalBase) { self.init(_with: obj) } init() {} } class Cat: AnimalBase {} class Dog: AnimalBase {} var cat: Cat = Cat() print(type(of: cat)) cat.replace(with: Cat(with: Dog())) print(type(of: cat))

1

tarunon

protocol AnimalProtocol {} extension AnimalProtocol { init(_with obj: Self) { self = obj } mutating func replace(with obj: Self) { self = obj } } class AnimalBase : AnimalProtocol { convenience init(with obj: AnimalBase) { self.init(_with: obj) } init() {} } class Cat: AnimalBase {} class Dog: AnimalBase {} var cat: Cat = Cat() print(type(of: cat)) cat.replace(with: Cat(with: Dog())) print(type(of: cat))

Version:

swift-4.1.1-RELEASE

Output:

Cat Dog

Error:

組み合わせて後から置き換えもできる

ｗｗ

9:34 AM

これはまあ replace自体は壊れてないんじゃない？

そうね

9:35 AM

その手前で壊れてる

Catとしてやってきたdogの時点でバグってる

やっぱり Self （というか、それを許容しているプロトコル）と継承を許すクラスは相性が悪いと思うなぁ。

9:40 AM

参照型自体は使いたいケースはあるとして、クラスの継承はやめた方が良いのでは。

extension AnimalProtocol { init(_with obj: Self) { self = obj } } class AnimalBase : AnimalProtocol { convenience init(with obj: AnimalBase) { self.init(_with: obj) } }

おかしいのは、ここで self.init(_with: ) が呼び出せてしまうことじゃないですか？

9:44 AM

AnimalProtocolが引数に受けてる Self は、 AnimalBase が final で無いのだから

9:44 AM

何かのサブクラスである可能性があって（たとえばCat ) なのに、 obj: AnimalBase を渡せてしまっている

今 Self は AnimalBase だから、 AnimalBase 絡みて init(_with:) が呼び出せるのはおかしくないんじゃない？

それでいうと、 AnimalBase で定義された convenience init(with:) が、 Cat で呼び出せるのがおかしい、とも言える。

それ呼び出せなかったらサブクラスがサブタイプでなくなるよ。

9:47 AM

まあ init はともかく、一般的なメソッドでも Self については言える話だから。

一般的なメソッドではSelfはこの手の制限をちゃんと判定していると思います。

9:48 AM

ついでにいうとstatic methodでも。

9:49 AM

サブタイプでなくなることもにないとおもう、ある型Aのインスタンスがある時、型Aのinitやstaticmethodは、Aのインスタンスのサブタイプ互換性とは関係ないはず

9:49 AM

型自体の static method や init を考慮したメタタイプ？同士のサブタイプ関係の話にはなってくると思うけど

9:50 AM

コンパイラ側の議論でも型的におかしいことはわかっているんだけど

9:50 AM

現状放置されているのは

9:50 AM

ObjectiveCのクラスクラスターパターンを動かすためにこれを悪用していて

9:50 AM

外すと互換性がなくなるうんぬんで

9:51 AM

機能を整理しないといけない (factory init などのアトリビュートを追加するとか）

↓は許容されていて、 Self はサブクラスには波及しない。

protocol Animal { func foo(_ x: Self) } class Cat: Animal { func foo(_ x: Cat) {} } class Siamese: Cat { } let siamese = Siamese() siamese.foo(Cat())

ってステータスじゃなかったっけ

これに関しては

convenience init(with obj: AnimalBase) { self.init(_with: obj) // <- ここがSelfチェックなはずのにAnimalBaseが通るのがおかしい }

だと思っていて、型として問題があるわけではないと思う

↑それは、 self が AnimalBase じゃない Cat である可能性があるからだよね？

そう

（ここで self はいつものインスタンスselfじゃなくてクラスそれ自体の方

9:53 AM

僕が最初に言ったのもその視点。

9:53 AM

koher が言ってるのは、その行単体でみれば AnimalBase だからおかしくない、って話で

9:53 AM

その視点の場合は、継承先で同じ convenience init が実行されてることがおかしいって言い方になる。

9:54 AM

@koher そのケースは、Selfが引数部だから contravariance が効いていて、 Siamese.foo(x: Siamese) が実装されていると考えることができる。

9:54 AM

なぜなら(というか直感的説明では）、 Cat をうける foo は Siamese も受けられるから。 (edited)

9:55 AM

@koher Self を返り値に使うケースでは covariance が効くのだけどそれだとどうしてもおかしなことになる関係でコンパイラがエラーを出します

@swiftbot

protocol Animal { func foo() -> Self } class Cat: Animal { func foo() -> Cat { return Cat() } } class Siamese: Cat { } let siamese = Siamese() let cat = siamese.foo()

1

koher

protocol Animal { func foo() -> Self } class Cat: Animal { func foo() -> Cat { return Cat() } } class Siamese: Cat { } let siamese = Siamese() let cat = siamese.foo()

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:6:10: error: method 'foo()' in non-final class 'Cat' must return `Self` to conform to protocol 'Animal' func foo() -> Cat { return Cat() } ^

うーん、それで問題ないのか。

これだとコンパイル通る

protocol Animal { func foo() -> Self } class Cat: Animal { func foo() -> Self { return self } } class Siamese: Cat { } let siamese = Siamese() let cat = siamese.foo()

10:02 AM

return self 以外にも、 type(of: self).init() などで Self 型の値が作れる。

swift-corelibs-foundationのfactory initializerパターンへの書き換えは、随分前に止まっちゃいましたね。

このケースだと、Siameseのfooメソッドを呼んだ時は、インスタンスが Siamese なので Self が返ってきてて OK

10:05 AM

@norio_nomura あれ？書き換えってとっくにおわってなかったでしたっけ？

10:05 AM

結局まーじされなかった？

https://github.com/apple/swift-corelibs-foundation/pull/1095

Generalize factory patterns for use outside of NSValue by phausler...

1

NSNumber問題かな

ほんとだ・・・

最後にrebaseやってくれーと書いてあるw

https://github.com/apple/swift/pull/4087

[Foundation] Add hack enabling factory intializer by rintaro · Pu...

What's in this pull request? I'm not sure this can be accepted or not. But this is convenient in some cases. Using that: Simplify copy constructor of NSSet and NSDictionary Eliminate getVa...

10:08 AM

slavapestov commented on 13 Aug 2016 I don't think assignment to self in a protocol extension initializer is a bug. Now we do want to change the ABI to make factory initializers more efficient, but the language feature is fine.

10:08 AM

~~2年前のslavaの見解はバグ~~ （誤読) (edited)

10:09 AM

~~でもこれはあれだね、extensionのほうの self = factory() の式をバグっていっているので~~ (edited)

10:09 AM

~~さっきの俺とtarunonの考えとはまた違うね。~~ (edited)

フーム

(self代入はOK, それを呼び出すconvenience initがダメ

「バグではない」という見解ですよ

あ

10:10 AM

dontか。

これ日本人的にはI think .... isn't a bug って書きたくなる

ナンカ前も冒頭のnot読み飛ばして真逆になったんだよな・・・

英会話教室でそれは普通使わないって言われました。think ... isn't

Swift5が出そうになってきたしこの辺決着つけてほしいなあ

全体的な書き換えが止まっただけで、factory initializerパターン自体はまだ残ってますね。 https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSNumber.swift#L675

https://forums.swift.org/t/proposal-factory-initializers/609

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

ああ、　PR #1095は > Generalize factory patterns for use outside of NSValue NSValue以外のやつらにもやるってPRなんですね。 (edited)

そそ。

10:16 AM

Foundationのソースを見られるappleの中の人が、書き換えをしてくれる事を期待したのだけど、ダメだった。

[Proposal] Factory Initializers

Recently, I proposed the idea of adding the ability to implement the "class cluster" pattern from Cocoa (Touch) in Swift. However, as we discussed it and came up with different approaches, it evolved into a functionality that I believe is far more beneficial to Swift, and sub...

10:21 AM

この辺かなあ

10:24 AM

Discourseってレスとレスの間にめっちゃ日にちが立ってると 9 MONTHS LATER みたいに出るのいいね。

@swiftbot

protocol Assignable { mutating func assign(from other: Self) } extension Assignable { mutating func assign(from other: Self) { self = other } } class Animal : Assignable { func speak() { fatalError() } } class Cat : Animal { override func speak() { print("にゃー") } } class Dog : Animal { override func speak() { print("わん") } } var cat: Animal = Cat() cat.assign(from: Dog()) cat.speak()

1

omochimetaru

protocol Assignable { mutating func assign(from other: Self) } extension Assignable { mutating func assign(from other: Self) { self = other } } class Animal : Assignable { func speak() { fatalError() } } class Cat : Animal { override func speak() { print("にゃー") } } class Dog : Animal { override func speak() { print("わん") } } var cat: Animal = Cat() cat.assign(from: Dog()) cat.speak()

Version:

swift-4.1.1-RELEASE

Output:

わん

Error:

いや、これはいいのか。

Self引数をクラスに実装したときに

11:41 AM

extension経由だとその時点のクラスに畳まれる、ここが壊れ

https://forums.swift.org/t/value-ownership-when-reading-from-a-storage-declaration/15076 John McCallが新しいオーナーシップ付きのプロパティをどういう文法にしよう？ってピッチを投げてる

Value ownership when reading from a storage declaration

Background: Ownership Manifesto As part of preparing the Swift ABI for getting locked down in Swift 5, I am changing some aspects of the implementation strategy for storage accesses in Swift 5. A lot of this is purely implementation-level and has no effect on the language, ...

3:04 AM

このピッチの中で、秘密のアクセサの materializeForSet について解説されているのも面白い

3:06 AM

materializeForSet は Swift で setter のある property を作ると生成される第3のアクセサで

3:07 AM

ストレージのポインタを取得できる関数。 property が stored property で実装されている場合に、それが inout T を取る関数などに渡される場合に、

3:07 AM

stored property の実メモリのポインタを materializeForSet を使って取得してやることで、

3:07 AM

getter / setter のオーバヘッドを回避できるっていうハックなんだけど

3:10 AM

これが modify アクセサとして再設計されるとのこと。 materializeForSet はポインタ参照先が死んでいることが無いように、ユーザは直接使えないけど、 modify アクセサは言語機能として搭載されるコルーチンを使った実装になるので、言語仕様として見えるようになる。

1

https://forums.swift.org/t/plan-for-module-stability/14551

Plan for module stability

As you can probably tell, I've been saving a lot of discussions, waiting for Swift 4.2 to be in a pretty good place before we jump all in on Swift 5. This one's one of the main things I plan to be working on in the next year or so, so I wanted to make sure you all had the big...

4:13 AM

興味深いスレッド。Swift5でのABI stabilityをどうすすめるかの話。

4:13 AM

.swiftinterface っていうライブラリのヘッダとして使われるテキストファイルを新しく導入するアイデアらしい。

4:13 AM

.swiftinterface は .swift から自動生成される。

4:14 AM

あと「ABI Stability」について定義されてる。

4:21 AM

(なんかスレは virl って人がめっちゃ暴れてるな・・・

勘違い諭されて静かになってる

https://forums.swift.org/t/isnotempty-on-array/15228/25 これオシャレで良いなあと思いました。

isNotEmpty on Array

As you might surmise, I don't have any specific generic algorithm an Emptiable protocol would enable. I find it interesting for two reasons: Clarity: I find "isInhabited" to be much clearer and easier to reason about than "isEmpty == false" & "!isEmpty" (& even "isNonEmpty...

12:13 PM

@inverse(isNotEmpty) var isEmpty: Bool { ... } ^ ここのところ。

12:14 PM

https://twitter.com/ericasadun/status/1029519538390540288 Ericaさんから。

ericasadun (@ericasadun)

Love @inverse: https://t.co/FazRa9uVD4

オシャンですが個人的にはBoolを特別扱いしすぎでウーンって感じがします

3:01 PM

この手合いのことをやるならJavaのアノテーションみたく一般化するべきかなぁとは思うのですがその先は地獄だし

これすごい悩ましい。 isXxx全てに対してisNotXxxを考えることができるのでキリが無くなる。でもisEmptyがわかりにくいのはわかる。

3:02 PM

isNotXxx実装する路線でいくなら実装ミスが無いアノテーション作戦は良い

3:03 PM

メソッドに付与することでメソッド実装を静的に自動生成するコンパイル時高階関数であると考えれば、 TypeScriptなんかのデコレータって言語機能に相当すると思う。

やるなら一般化するべき&しかしabuseされて地獄になる未来、の両方が見えてる

このスレでも出てくるんだけど NonEmptySequence 型よさそうで

それはほしいわかる

firstやlastが T? じゃなくて T になる型

3:05 PM

Sequenceにたいして、 var nonEmptySequence: NonEmptySequence? を提供してやると

3:05 PM

guard let _ = array.notEmptySequence

3:06 PM

と書けるってのはどうだい、みたいなレスもあった。

高階kindなしでやると

そうだねえｗ

そもそもNonEmptySeqはProtocolじゃなくていいはず

3:06 PM

structでSeqの実装でfirst/lastがnon optional実装なだけでいい (edited)

元のコレクションに対応したNonEmpty版の型を返すべきだがそれうまくprotocolにならなそう

それは高階kind必須

3:08 PM

いや？

3:08 PM

取って置きのワークアラウンド思いついたわ

3:09 PM

struct NonEmptySeq<S>: Sequence where S: Sequence { typealias Element=S.Element }

3:09 PM

なんかこんな感じでなんとかなるやろ

3:10 PM

何チャラIndexがこんな感じの実装になってませんでしたっけ

Iteratorとかがそんなんだったような

だよねだよね

3:11 PM

でも脳に優しくないからやっぱ高階kindほしいわ

https://forums.swift.org/t/implement-nonempty-collections/14246/11

Implement "NonEmpty" collections

This is not a problem at all if you store the underlying collection in a single property rather than separating the first element from the rest.

3:11 PM

NonEmptyスレ

3:12 PM

@inverse の人も書き込んでるね

便利は便利だけどやりすぎかなーみたいな気がしてきた

3:20 PM

これって結局UIntだけじゃ満足できませんってんでNonZeroUInt入れましょうって言ってるのとそんなに変わらん (edited)

https://forums.swift.org/t/even-and-odd-integers/11774

Even and Odd Integers

Even And Odd Integers DISCLAIMER: This is not a proposal, just an idea Several times recently I have been forced to identify even elements for the purposes of analyzing an array or other, similar groupings of data. After the second time I simply extended Int and added an is...

3:21 PM

整数じゃ満足できなくなって奇数・偶数が欲しい人↑

じゃけん7の剰余で7個の型作りましょうね

3:22 PM

いやーないでしょ

証明言語とかだとできそうだけどね

3:22 PM

型パラメータの代わりに値の制約式みたいなのが書けるやつ。 (edited)

数値を型にできるやつなら

これおもしろいのがさ

Mod<A,N>でいい

@inverse(isOdd) var isEven: Bool

3:23 PM

なんだよねｗ

あれれー

isXxxのinverseがisNotXxxじゃない稀な例 (edited)

いやそんなこといったら

3:24 PM

別にisEmptyの対もisNotEmptyじゃなくてもいいでしょ

ruby on rails だと present? ですね

そっちの方が分かりやすいじゃん

3:26 PM

二重否定が許されるのは日本語だけだぞ

presentとemptyがあったらこれらが本当に単に逆の意味なのか、微妙にすれ違って同軸上に無い概念なのか心配にならない？

流石にcollectionでそれは無いのでは

3:28 PM

IntでisPlusとisMinusがあったら死人は出そうである

それうけるなｗ

isPlus contains zero(出展はCS)

3:29 PM

盛り上がって参りました

enum Sign { case plus; case zero; case minus }

Floatだと+0と-0って明示できないかな、ちょうど0になるんでしたっけ？

3:32 PM

https://ja.m.wikipedia.org/wiki/IEEE_754における負のゼロ

IEEE_754%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E8%B2%A0%E3%81%AE%E3%...

3:32 PM

こんなのみつけた

Floatはカオスよ

なるほどなー

Floatのせいで Equatable は @inverse(!=) func == にできません

nanがいるからだっけ

うん。

non empty collection 、値型だとうまくいかない気がする。

1:29 AM

Ceylon が 1.0 のときは non empty collection を持ってたけどいつの間にかなくなってた気がする。

中身見てないですけど、スレッドにはライブラリ実装が投稿されてますよ

実装はできるけど、↓になるという意味。 let nonEmpty = [42] let maybeEmpty: [Int] = nonEmpty // コンパイルエラー

なるほど

それはArray優先じゃないですかね

NonEmptyList を List のサブタイプにできない。

明示したときだけNonEmptyにするべきだし、サブタイプ関係は無いです

うーん、 non empty をわざわざ扱えるようにするなら↓はできてほしい気が。 let a = [2, 3, 5] print(a.first + 1)

明示するべきです

あと、 NonEmptyArray を Array 型の引数に渡せなくなって、全部オーバーロードするとかになりますし、

NEAとArrayのサブタイプ関係は嘘と直感が囁いている

1:48 AM

ちゃんと考えてないけど、それを認めるとOptionalと同様の崩壊を引き起こすと思います

NonZeroUInt とかも、サブタイピングがあれば別にいいと思うんですよね。

1:49 AM

数学的には自然数は整数だし、整数は実数だし、実数は複素数だし。

Optionalが崩壊してるのは二重にできることとArrayの空配列が互換性がある事のまわりだけなきがする

1:50 AM

NonEmptyはArrayに1度だけくっつく属性だから違いそう（任意のTをつつめる型ではない

NEA<Array<Int>>.flatten()とか

1:51 AM

Array<NEA<Int>>.flatten()とか

1:52 AM

この辺がヤバそう

1:52 AM

これはNEA<NEA>だけがNEAになれるはずだが、

いずれにせよ現状の型システムだとサブタイピングはできないからコンパイラサポートがいりそう

なので、 NEA<NEA> のときの conditional なオーバーロードを作ることになると思います。

まあ現状だと、

1:53 AM

appendしたあとで first! って書くのにくらべたら

1:53 AM

明示的な変換があってもNonEmptyな型があったら

1:53 AM

便利だなと思う

@omochimetaru それはそれで微妙で、 Array と ArraySlice とか、あえて明示的に変換するのが Swift の（というか値型の？）スタイルだから、暗黙変換は Swift になじまないと思う。 < サブタイピングはできないからコンパイラサポートがいりそう (edited)

1:55 AM

まあ、プロトコルレベルで継承関係作ってれば、それなりに便利かも？

いややっぱこれ、高階カインド無しにはやるのはちょっと…って感じしますね

protocol NonEmptySequence: Sequence { ... } func max<S: Sequence>(_ sequence: S) -> S.Element? where S.Element: Comparable { ... } func max<S: NonEmptySequence>(_ sequence: S) -> S.Element where S.Element: Comparable { ... } let a: [Int] = [2, 3, 5] max(a) // Optional(5) let b: NonEmptyArray<Int> = [2, 3, 5] max(b) // 5

1:58 AM

max や min で non optional になるのはうれしいなぁ。

あと、そもそもappendはArray自体のmutable funcで、

2:03 AM

mutable funcで型を書き換えるのは厳しい

2:03 AM

そもそもそれで複雑性が増すよりも適切にIUO使う方が良いと思いますね

Array自体にemptyかnon emptyかを表す型パラメータがついたphantom typeになるような状態だと思う

型は書き換わらないでしょ

それにしたってmutating funcじゃ無理だね (edited)

var a=[] if foo a.append(1) これで終わる

2:05 AM

appendedみたいにやるなら良いかもしれない

2:06 AM

でもやっぱり複雑性マシマシで嬉しい事が少しあっても、それ以上に辛い場面が増えると思います

2:12 AM

証明系の言語で、型に値を入れ込むことが出来るなら、アリだと思いますが、現状のswiftの型システムにはマッチしなさそうかなという感じ

あと、そもそもappendはArray自体のmutable funcで、 mutable funcで型を書き換えるのは厳しい

これは型は変わらないと思ってます。

2:12 AM

Int? に 42 を代入しても Int にならないのと同じで、 empty になれる型かどうか。

2:12 AM

remove は問題になりそう。

2:15 AM

数値のように全プロパティ let 扱いだと簡単だけど（ RealNumber と NonNegativeRealNumber だったら func -(lhs: NonNegativeRealNumber, rhs: NonNegativeRealNumber) -> RealNumber でいいけど）、 mutating func はちょっとややこしそうだ。

2:16 AM

現状 Array の popLast は死なないメソッドだけど https://developer.apple.com/documentation/swift/array/1539777-poplast

2:16 AM

NonEmptyArray の popLast は Logic failure を起こすようにするしかない気が。それとも要素が一つしかないときに popLast したら nil を返す？

実行効率も良く無さそうだなー

popLast をなくして、 logic failure 前提の remove 系に統一もいいかも。

NonEmptyArrayを返すかクラッシュするものと Arrayを返すものの2つ、別名メソッドとか。

2:18 AM

あ、removeは要素を返すのかｗ

@omochimetaru うんｗ

1

2:19 AM

remove はいいんだけど（ logic failure としてクラッシュさせればいいから）

2:19 AM

現状 logic failure が起こらない pop がまずそう。

うーん、appendしてNonEmptyになるなら

2:19 AM

removeしてArrayにもどるほうがいいんだけどな

append して NotEmpty にはならないでしょ

2:20 AM

関数型言語みたいにイミュータブルコレクションで append がコレクション返すならできるけど。

appendingとremovingか。

参照型、イミュータブル、サブタイピング中心の世界はそれはそれでうまく機能してキレイだけど、 Swift はそのやり方はできないからうまくいかなさそう。

2:22 AM

append で non empty 保証できないというのも、参照型・イミュータブルな世界と比べて non empty 導入のメリット薄そう。

2:23 AM

そうかー。値型があればイミュータブルの代わりになると思ってたけど、更新系の操作で型を変えられるというのはイミュータブルにしかない利点なのか。

この前の↑、やっぱりサブタイピング＆ Smart Cast と相性良さそう。

let array: Array<Int> = [2, 3, 5] guard !(array is NonEmptyArray<Int>) else { return } // ここでは `array` を `NonEmptyArray<Int>` として扱える

Swiftだとスマートキャストは無いから何かしらlet束縛するような形になりそうですね

Smart Cast はサブタイピングと相性の良い仕組みだから、そもそも Swift に馴染まなさそう。

なるほど

Smart Cast って抽象的な型で扱ってる場合にほしくなるわけだけど、 Swift だと基本的には型が定まってるから Smart Cast したいケースそのものが多くなくて、

6:41 AM

「何かしらlet束縛するような形になりそう」はそのとおりだけど、その前提があまり発生しなさそう。 (edited)

https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md

Fix the issue any packages for watchOS couldn't be built on Xcode ...

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

2:02 AM

生文字列のレビュー始まった

2:02 AM

面白い仕様に着地してる

2:03 AM

生文字列の構文を追加するんじゃなくて、既存の文字列のデリミタを変更できるようにすることで

2:04 AM

エスケープシーケンスが文字列コンテンツと一致しないようにして

2:04 AM

普通の文字列リテラルを生文字列にも使えるようにする

↓ただの raw string じゃなくて、↓できるのおもしろいな。 #"This string has an \#(interpolated) item"# ####"This string has an \####(interpolated) item"####

2:27 AM

しかも、 multi-line string literal にも拡張されてる。 #""" a raw string containing \r\n """#

Lexerの実装負荷も比較的小さくできそうでオシャレだと思いました

multi-line string literal も良かったけど、これも入るとますます文字列リテラルの使い勝手の良い言語になりそう。

2:31 AM

Example, 言葉での説明よりも、リテラルと結果を表にしてくれた方がわかりやすいのに・・・。

たしかに。

でも、一度差し戻されてるからなのか、提案書自体は頑張って書かれてるなあと思いました

1

どこに書けばいいかわからないからここに書くけど、Carthageのバグ潰したつもり　　　 https://github.com/Carthage/Carthage/pull/2561 Carthage、Xcode 6.4との互換のコードが残されていたのだけど、無視して7以降でしか動かないようにしてしまった。Carthageのバージョンポリシーってあるんですかね？ @ikesyo

Problem When I Built watchOS packages on Xcode 10 beta 6, It would be failed with following error: $ carthage update --platform watchOS --verbose --- xcodebuild: WARNING: Unable to open project fi...

ikesyoさん体調悪いと書いていたのにコメントくれた

@swift-4.1.3 @swift-4.0.3 let a = Int?.none let b = Int??.none print(a == b) print([a] == [b]) (edited)

false false (edited)

exit status: 1 with stderr:

<stdin>:3:9: error: binary operator '==' cannot be applied to operands of type 'Int?' and 'Int??' print(a == b) ~ ^ ~ <stdin>:3:9: note: expected an argument list of type '(T?, T?)' print(a == b) ^ <stdin>:4:11: error: binary operator '==' cannot be applied to operands of type '[Int?]' and '[Int??]' print([a] == [b]) ~~~ ^ ~~~ <stdin>:4:11: note: overloads for '==' exist with these partially matching parameter lists: (Any.Type?, Any.Type?), ((), ()), (Bool, Bool), (Character, Character), (Character.UnicodeScalarView.Index, Character.UnicodeScalarView.Index), (CodingUserInfoKey, CodingUserInfoKey), (OpaquePointer, OpaquePointer), (AnyHashable, AnyHashable), (UInt8, UInt8), (Int8, Int8), (UInt16, UInt16), (Int16, Int16), (UInt32, UInt32), (Int32, Int32), (UInt64, UInt64), (Int64, Int64), (UInt, UInt), (Int, Int), (AnyKeyPath, AnyKeyPath), (Unicode.Scalar, Unicode.Scalar), (ObjectIdentifier, ObjectIdentifier), (String, String), (String.Index, String.Index), (UnsafeMutableRawPointer, UnsafeMutableRawPointer), (UnsafeRawPointer, UnsafeRawPointer), (UnicodeDecodingResult, UnicodeDecodingResult), (_SwiftNSOperatingSystemVersion, _SwiftNSOperatingSystemVersion), (AnyIndex, AnyIndex), (ContiguousArray<Element>, ContiguousArray<Element>), (ArraySlice<Element>, ArraySlice<Element>), (Array<Element>, Array<Element>), (T, T), (T?, T?), (T?, _OptionalNilComparisonType), (_OptionalNilComparisonType, T?), ((A, B), (A, B)), ((A, B, C), (A, B, C)), ((A, B, C, D), (A, B, C, D)), ((A, B, C, D, E), (A, B, C, D, E)), ((A, B, C, D, E, F), (A, B, C, D, E, F)), (ClosedRangeIndex<Bound>, ClosedRangeIndex<Bound>), (LazyDropWhileIndex<Base>, LazyDropWhileIndex<Base>), (EmptyCollection<Element>, EmptyCollection<Element>), (Self, Self), (FlattenCollectionIndex<BaseElements>, FlattenCollectionIndex<BaseElements>), (FlattenBidirectionalCollectionIndex<BaseElements>, FlattenBidirectionalCollectionIndex<BaseElements>), (Set<Element>, Set<Elemen

(edited)

stderr.txt

https://file.io/1hKQNz

ンゴゴゴ

12:09 PM

これいつの間にか治ってますね

https://twitter.com/xge_apple/status/1035017364851445760

Xi Ge (@xge_apple)

SwiftSyntax has been moved to its own repo as a SwiftPM package! Check it out here: https://t.co/hpqUec0qR5

お

5:38 AM

あれ？

5:38 AM

でもこれStdlibにも含まれてますよね

5:38 AM

update-checkoutに追加されたのかな

5:39 AM

https://github.com/apple/swift/pull/19064/files

[4.2] Move SwiftSyntax to its own repository by ahoppen · Pull Re...

This PR sets up the infrastructure to build SwiftSyntax from its own repository for the swift-4.2-branch. For this it does: Add the new swift-syntax repository to update-checkout Add a build-scrip...

5:40 AM

やっぱりbuild-scriptも更新されるんですね

5:41 AM

https://github.com/apple/swift/pull/19061

[master] Move SwiftSyntax to its own repository by ahoppen · Pull...

This PR sets up the infrastructure to build SwiftSyntax from its own repository. For this it does: Add the new swift-syntax repository to update-checkout Add a build-script option to build and tes...

5:41 AM

引っ越して削除するPRはこっちか (edited)

apple/swiftのディレクトリと隣り合ってないとビルドできないみたい。 (edited)

gybの処理に必要なだけで、生成後は単体でビルド可能だった。

6:05 AM

テストはmacOSでしか通らないみたい。 (edited)

https://github.com/apple/swift-evolution/blob/master/proposals/0204-add-last-methods.md で

The name changes to index(of:) and index(where:) are easily migratable, and will be deprecated in Swift 4.2 before being removed in Swift 5.

って書かれてるけど、Swift 4.2ではindex(of:)とindex(where:)のどちらもdeprecatedになってなくて、5.0でdeprecatedなのね。 https://github.com/apple/swift/commit/e8b6091755fc87241341e82845a29043361e8e9f

[stdlib] Deprecate Collection.index(of:) and index(where:) (#19071...

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

This should have been done for Swift 4.2 according to SE-0204, but better later than never. Deprecating these methods as of Swift 5.0. Also modfying the tests to check for the deprecation messa...

https://github.com/apple/swift/pull/19116

[WIP] Default implementation in protocols by Azoy · Pull Request ...

Refer to: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols- Forum Post: https://forums.swift.org/t/default-implementation-in-protocols/15794...

5:56 AM

https://forums.swift.org/t/default-implementation-in-protocols/15794

Default Implementation in Protocols

Hello Evolution, I've been working on implementing Default Implementation in Protocols and I have a working early implementation of the feature. Current Implementation: https://github.com/apple/swift/pull/19116 Refer to: https://github.com/apple/swift/blob/master/docs/Gene...

5:56 AM

protocol本体にデフォルト実装かけるようにする話

オッ

Azoyって乱数まわりやってる17歳じゃなかったっけ

5:57 AM

ドラゴンボールだったのが実写になっておる

https://forums.swift.org/t/un-requiring-required-initializers/15815

Un-requiring required initializers

In Swift, although we try to provide a sound, total type system as the default environment for the most part, we provide reasonably easy explicit ways to poke holes where the type system isn't a perfect fit, such as ! for unwrapping optionals known to never be nil, as! for ca...

9:02 AM

SlavaのPitch、 required initのオーバーライドをサボって required! initって書けるようにしようぜ、とのこと。利用例 init(coder: Coder)

親クラス側で required! init って書くと、派生クラス側でサボれるってことなんですね。個人的にはなんか変な気がする。

従来も、Xcodeで自動補完されて、 fatalErrorするものが吐かれていたので、それの略記とも考えられます

サボる側に書くのならいいと思ったんですけどね。親クラス側でサボっていいよってやってると、サボる気のない派生クラスの方で忘れる可能性が。

protocol FantasyCoding { init(coder: FantasyCoder) } class FantasyView: FantasyCoding { required! init(coder: FantasyCoder) { } } class MyView: FantasyView { var x, y, z: Int // ok not to override init(coder:) here } extension FantasyURL: ExpressibleByStringLiteral { // OK to add a required! initializer in an extension required! init(stringLiteral: String) { .. } }

3:41 AM

required! を書くのはサブクラス側ですよ。

ん？ FantasyView が親ですよね？

init(coder: ) は FantasyCoding で要求されているので

3:43 AM

FantasyView でサボっていて

3:43 AM

MyViewは孫だから、サボりを受け継ぐ。

あ、FantasyViewではサボらず、MyViewでサボれるのかと思ってた。ちょっと読み直してみます。

MyView <- FantasyView (required! ) <- FantasyCoding 親子どちらでもあるので話が混ざってしまった。

3:49 AM

ひろんさんの言ってる事も正しいですねえ。

3:50 AM

通常なら孫にもrequired initの実装が伝搬するけど

3:50 AM

required! すると、そこで止まるんだ。

うん、だから、UIViewのinit(coder:)をこれにしたいってとこだと思うんですよね。モチベーション的には。（お昼誘われたのでちょい退出。またあとで）

あ、各自が自分のサブビューでやるんじゃなくて、UIViewをそもそもこれにしてしまうのか、その発想は無かった。僕も読み直してきます。

うん、やっぱり required! init には { ... } となってて処理が書けるから、その時点ではサボりはしないで、特に必要のないサブクラスでサボることを許容するんだと思います。で、そうすると、個人的にやっぱりイヤ。

@hironytic たしかにそれだと微妙そうですね。明示的に楽にサボれるのならいいんですが・・・。 Equatable 自動生成とかみたいな。 (edited)

4:35 AM

まだ Pitch のようなので、是非 forum でご意見を

1

ぼくには個人的にヤだなという感情しか浮かばなくて、なぜイヤなのかを言語化できてなかったけど、forumでcukrさんがバッチリ言語化してくれてた

https://forums.swift.org/t/un-requiring-required-initializers/15815/5

Un-requiring required initializers

I'm not a fan of this pitch. If I subclass UIView I would like to be reminded by a compiler that I am supposed to provide that init. Notice that every hole-poking tool you mentioned is used in the place that doesn't fit. ! for unwrapping optionals is used when you are sure ...

1

zip()のパラメータ、a,b,tどれか一つだけ@escapingが無くても良い。 @swift-4.1.3 @swift-4.2.4

func zip<A,B,T>( _ a: @escaping ((A) throws -> T) throws -> T, _ b: @escaping ((B) throws -> T) throws -> T, _ t: @escaping (A, B) throws -> T ) rethrows -> T { return try a() { _a in return try b() { _b in return try t(_a, _b) } } } let xs = ["x", "s"] let ys = ["y", "s"] let totalByteCount = try zip(xs.withUnsafeBytes, ys.withUnsafeBytes) { x, y in x.count + y.count } print(totalByteCount) // "64\n"

(edited)

96 (edited)

どの@escapingが無くても良い。

64

4.1と4.2で結果が違うのか。

新しいバグを見つけた気がする

11:11 AM

structをobjcに一回投げて_SwiftValueにすると、_SwiftValue -> ExistentialへのCastがFailする

11:11 AM

@swift-4.1.3

import Foundation protocol Animal {} struct Cat: Animal {} print((Cat() as! AnyObject) as? Animal) print((Cat() as! AnyObject) as? Cat)

(edited)

exit status: 134 with stderr:

<stdin>:4:7: warning: expression implicitly coerced from 'Animal?' to Any print((Cat() as! AnyObject) as? Animal) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <stdin>:4:29: note: provide a default value to avoid this warning print((Cat() as! AnyObject) as? Animal) ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ ?? <#default value#> <stdin>:4:29: note: force-unwrap the value to avoid this warning print((Cat() as! AnyObject) as? Animal) ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ ! <stdin>:4:29: note: explicitly cast to Any with 'as Any' to silence this warning print((Cat() as! AnyObject) as? Animal) ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ as Any <stdin>:5:7: warning: expression implicitly coerced from 'Cat?' to Any print((Cat() as! AnyObject) as? Cat) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <stdin>:5:29: note: provide a default value to avoid this warning print((Cat() as! AnyObject) as? Cat) ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ ?? <#default value#> <stdin>:5:29: note: force-unwrap the value to avoid this warning print((Cat() as! AnyObject) as? Cat) ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ ! <stdin>:5:29: note: explicitly cast to Any with 'as Any' to silence this warning print((Cat() as! AnyObject) as? Cat) ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ as Any Could not cast value of type 'main.Cat' (0x7fe4e571b100) to 'Swift.AnyObject' (0x7fe4e03ad260). #0 0x0000000003f25074 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x3f25074) #1 0x0000000003f253b6 SignalHandler(int) (/usr/bin/swift+0x3f253b6) #2 0x00007fe4e52eb390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x00007fe4e3a2a428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #4 0x00007fe4e3a2c02a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #5 0x00007fe4e0288fd3 (/usr/li

(edited)

stderr.txt

https://file.io/4ycq2H

AnyObjectのキャストがLinuxだとあれか

https://developer.apple.com/jp/xcode/

新しいコードを追加すると、追加した行のみ再コンパイルされます。

最近コンパイラに、部分指定してパースとかがちょこちょこ追加されていたんだけど、↑これってその成果なのかな

Xcode - Apple Developer

Xcodeには、iPhone、iPad、Mac、Apple Watch、Apple TV向けの優れたアプリケーションを作成するために必要なあらゆる機能が用意されています。

koher05/07/2018 この前 @Taketo Sano さんが困ってた自作型の Conditional Conformance & Codable 自動生成はできるようになりそうですね。

これかなり便利ですね

新しいコードを追加すると、追加した行のみ再コンパイルされます。

この件は、Xcode Playground の話なので、たぶん違いますね。最近の on demand parsing は、インクリメンタルビルドにおいての高速化のためです。

Playgroundで追加した行だけ再コンパイルするのは、元からあったREPLの仕組みの方ってことですか？

Xcode 10 で Playground で逐次実行ができるようになったので、それの事だと思います。

あ〜

6:32 AM

https://developer.apple.com/videos/play/wwdc2018/402/

Getting the Most out of Playgrounds in Xcode - WWDC 2018 - Videos ...

Discover major advancements in Xcode playgrounds. Learn advanced tips and techniques, hear about new and often overlooked workflows, and...

6:32 AM

再生ボタンみたいなやつが出てくれないなあ

新規playgroundだと出るな。

6:33 AM

！

6:33 AM

いや、そのメニューが出ない

▼が無いですか？

▼はあるけど、ポップアップメニューが出ないです

長押しででません？

新規作成したplaygroundは、ステップ実行する○→は機能しました。

6:35 AM

長押しで出た・・・！！！！

6:35 AM

おー、前からあるやつでも、いけました。ありがとうございます。

6:36 AM

なんで長押し・・・

6:38 AM

Comparison / Authors / Log のボタンも同じコンポーネントですね、すでにボタンが凹んでるときは短クリックでポップアップが出るから、気づいていなかった。

結構Appleの、ボタンの横にちっちゃい▼ついてるのは長押し意味してるのがそこら中にあるよ

知らなかった・・・

7:12 AM

なんか押しにくいって感じてる事があったのはそういうことか

XcodeのRun/Buildとかもそうじゃないかな、Instrumentをそこから出せるはず

ほんとだ〜〜〜〜〜〜

7:14 AM

これは長押ししないとほんとうに押し込んじゃうね

7:14 AM

全く気づいてなかった

OptionSetってHashableになってても良い気がしているんですがなってないんですね

7:05 AM

https://github.com/apple/swift/blob/7c56af08a719ebd50955c556b4a76ec2d4dc8f13/stdlib/public/core/OptionSet.swift#L86

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

7:05 AM

昨日気付いた

7:05 AM

どうなんだろう

RawValue に何も制限設けてないのでむずかしいんじゃないかな。 extension OptionSet : Hashable where RawValue: Hashable は標準であってもいい気はしますが、普通の OptionSet は var rawValue: RawValue しか持っていないので RawValue == UInt8 とかなら struct MyOptions : OptionSet, Hashable って宣言するだけで Hashable に準拠できるので、敢えて追加するモチベーションは低くなりそう。 (edited)

RawRepresentableって

7:42 AM

自前のプロパティの追加って禁止されるんでしたっけ。

そんなことないですが、 init(rawValue:) でコンストラクトできる必要があるので、他のプロパティが同値性に影響を与えるのは不自然でしょうね。

なるほど

7:45 AM

そもそも SetAlgebra.Element : Equatable がついてて、 OptionSet だと Element == Self なので、Equatableは要請されているのか

7:47 AM

Hashableに限らず、すべてのプロトコルに関して、 RawRepresentable.RawValue が conform してるプロトコルは、本来的に Self も conform できるはず　って話とかといって、特にHashable をOptionSetにおいて特別視する理由がないと思った。

一応 SetAlgebra 自体 Equatable 要求ありますよ。

あ、ほんとだ。

7:49 AM

SetAlgebraの実装においては、ElementがHashableのほうが、内部実装をハッシュテーブルにできて有利、みたいな話は別途ありそうだけど・・・

OptionSet.Element == Self は標準ではあるけど、要求ではないです。

あーこれはassociatedtypeのデフォルト値か。

7:51 AM

 /// The element type of the option set. /// /// To inherit all the default implementations from the `OptionSet` protocol, /// the `Element` type must be `Self`, the default. associatedtype Element = Self

(edited)

7:53 AM

このコメントの must be はどういう意味です？

https://github.com/apple/swift/blob/7c56af08a719ebd50955c556b4a76ec2d4dc8f13/stdlib/public/core/OptionSet.swift#L199 この実装を継承するためには、 Element == Self でなければならない。

Add Xcode version information to VersionFile by giginet · Pull Re...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

なるほど。特にmust beじゃ無さそう・・・

extension Set: RawRepresentable where Element == Int { public typealias RawValue = Set<Int> public var rawValue: Set<Int> { return self } public init(rawValue: Set<Int>) { self = rawValue } } extension Set : OptionSet where Element == Int {}

むりやりだけど、 Element == Self じゃない例。

RawValue に何も制限設けてないのでむずかしいんじゃないかな

8:02 AM

なるほど

8:03 AM

ちゃんと読んでなかったけどOptionSet、UIntの場合はHashableで良さそうなのにHashableになってなかったからなんでだー、みたいな気持ちでした

8:03 AM

OptionSet.Element取れるなら確かに難しそう

@ikesyo iOSDCの時に教えてもらったcarthage-verify試してみてPR送ってみました

https://github.com/Carthage/Carthage/pull/2585

Motivation & Context I want to use carthage-verify on workflows to skip duplicated builds. However, current .Package.version file doesn't contains Xcode version information. So we can't...

10:36 AM

#carthage ほしくなってきた

作った

最高

ソート位置はスマホからいじれんので後で直します

protocol extensionよりもextensionの実装が優先されるのって仕様ですか？不定だけど動作上今は優先されているだけですか？

@swiftbot

protocol Proto { func test() } extension Proto { func test() { print("Proto") } } struct Impl: Proto { func test() { print("Impl") } } let a = Impl() a.test()

こういうやつですか？

1

t.ae

protocol Proto { func test() } extension Proto { func test() { print("Proto") } } struct Impl: Proto { func test() { print("Impl") } } let a = Impl() a.test()

Version:

swift-4.1.1-RELEASE

Output:

Impl

Error:

Impl内にtest()書くのじゃなくて更にextensionに書く場合にすべきか

ですです、これがSwiftのアップデートでProtoの方が呼ばれるようになってしまうリスクはあるのかなと

具体型として見た場合とExistentialとして見た場合とで挙動が変わる場合がある

5:59 AM

cc @omochimetaru @Yuta Saito

呼ばれた

1. protocolのrequireとしてfuncが記述されているかどうか 2. protocolをimplしたsuperclassに実装があるかどうか

6:00 AM

この条件で挙動が変わります

6:01 AM

Documentにも明記されていない以上、いつ変わってもおかしくないと思いますね。

requireされるとwitness tableに乗るので動的にディスパッチされるんですけど、ない場合は常に静的にディスパッチされます

1で変わるのは仕様と思いますが、2 はとても怪しいですね

protocolをimplしたsuperclassに実装があるかどうか

現状witness tableが作られるのはprotocolへの準拠ごとなので、クラスを継承した場合に新しいwitness tableが作られず、サブクラスのメソッドが呼ばれないやつですね

6:06 AM

サブクラスで補完が効いてしまうのが厄介

6:10 AM

サブクラスを作ったときにwitness tableを作らないのは設計上の問題なのかとか、知ってたりしますか？ @omochimetaru

呼ばれた

（一旦protocol extensionよりもextensionの実装が優先されるのは変わりうる可能性があるのは理解しました！、ありがとうございます）

そこの優先関係についてはextensionのほうが優先されるのが普通じゃないかと思うんですが変更されうるんですかね

@Yuta Saito そこはよくわかんないっていうかiOSDCで俺が君に聞いたやつじゃんｗ

1

6:17 AM

でも親でwitnesstableもって子の呼び出しはvtable経由にしないと、子のインスタンスが親としてアップキャストされているときに

6:17 AM

挙動が変わっちゃうのは継承ベースOOPとしては変な感じがするから

6:17 AM

意図的な気がする

6:18 AM

最近の傾向だとドキュメントされてない怪しい挙動でも、広く使われている場合、下位互換性を壊さないように注意される感じだから、

そういやそうでしたねw あー、確かにキャストして挙動変わるのはまずそう。

将来的にも壊れないと思ってよさそうだけど

1

protocol extensionで定義したメソッドをvtableに載せれば期待する挙動になりそうですけど、罠がありそう

extensionは

vtableに乗せちゃうかfinal扱いにするか

パッケージの外で定義された場合の考慮が必要で (edited)

どちらかの仕様がほしいよなぁと思う

vtableはクラスごとにプロセスに１つしかないから

あー、なるほど、モジュール外でprotocol extensionが生やせるのかー。

6:24 AM

無理そう

open classにprotocolを生やした場合に、強制的にvtable作るのはダメですかね

6:28 AM

subclassは明示的にoverride書く必要が出てきて

6:28 AM

extension overrideは4で封じられたので問題ないはず

その場合、強制的に作られたvtableに入っているフィールドは何になりますか？

error: iOSGround.playground:35:10: error: overriding non-@objc declarations from extensions is not supported

6:44 AM

@tarunon パッケージX、パッケージY、パッケージZにおいて、パッケージXにclass Animalとclass Cat : Animalが定義されていて Animalのspeakメソッドが定義されていて、Catでは特にオーバライドされていないときにパッケージYでCatのextensionとしてspeakを実装したら、パッケージXの中のコードでAnimalのspeakメソッドを呼び出しているところで、そのYで与えた実装が走って欲しいって話だよね？

extensionの中でoverrideは言語仕様として明確に禁止するべきと考えています

あれ、じゃあ、どういう話をしてるんだ？ > open classにprotocolを生やした場合に、強制的にvtable作るのはダメですかね

open classの定義がパッケージXにあって、パッケージYにサブクラス定義がある場合

6:47 AM

パッケージXでprotocol extensionによって実装されたfunction群をパッケージYでoverrideができないのが困る

// package X protocol AnimalProtocol { func a() } extension AnimalProtocol { func a() { print("X.AnimalProtocol.a") } } open class Animal : AnimalProtocol { } // package Y import X class Cat : Animal { func a() { ... } }

6:49 AM

こういう形？

そう

6:50 AM

これがoverrideではなく、あやふやな状態になるのがね

あやふやじゃなくて、今だと、Cat.aの定義自体が禁止されるっぽい

マジ？

error: iOSGround.playground:35:19: error: overriding non-@objc declarations from extensions is not supported

ほほー

6:50 AM

それはそれでいいね

あ、ごめん、ちょっとまって。少し状態が違った

1

あやふやな状態さえ消えれば私はなんでもいいよ

↑のエラーが出るのは extension Animal { } の場合だった。定義できちゃうな。

ムッ

なるほど言いたいことを理解した

@swift-4.2.4

protocol AnimalProtocol { func a() func c() } extension AnimalProtocol { func a() { print("AnimalProtocol.a") } func b() { print("AnimalProtocol.b") } func c() { print("AnimalProtocol.c") } } class Animal : AnimalProtocol { func a() { print("Animal.a") } func b() { print("Animal.b") } } class Cat : Animal { override func a() { print("Cat.a") } override func b() { print("Cat.b") } func c() { print("Cat.c") } } func invokeA<X: AnimalProtocol>(_ x: X) { x.a() } func invokeB<X: AnimalProtocol>(_ x: X) { x.b() } func invokeC<X: AnimalProtocol>(_ x: X) { x.c() } var cat1: Cat = Cat() invokeA(cat1) invokeB(cat1) invokeC(cat1)

Cat.a AnimalProtocol.b AnimalProtocol.c

a: witness tableエントリあり、vtable親あり、vtable子あり、Catが呼ばれる b: witness tableエントリなし、vtable親あり、vtable子あり、AnimalProtocolが呼ばれる c: witness tableエントリあり、vtable親なし、vtable子なし、AnimalProtocolが呼ばれる

6:56 AM

tarunonが言ってるのはcのパターンだな。

6:57 AM

cのパターンにおいて、望み通り子で処理を差し替えたければ、 Animalにfuncを書いてaのパターンにするべきだけど、 protocol extensionをAnimal以外でも使ってるから、 funcを書きつつsuperみたいにprotocol extensionの実装を呼び出すことができないから、それはやりたくない、と。

モジュール内でrequirementを満たす必要があるので、モジュール外でprotocol extensionされる可能性を考慮しなくて良くなりそう

protocol AnimalProtocol { func a() func c() func d() } extension AnimalProtocol { func a() { print("AnimalProtocol.a") } func b() { print("AnimalProtocol.b") } func c() { print("AnimalProtocol.c") } func d() { defaultD(self) } } func defaultD<X: AnimalProtocol>(_ obj: X) { print("AnimalProtocol.d") } class Animal : AnimalProtocol { func a() { print("Animal.a") } func b() { print("Animal.b") } func d() { defaultD(self) } } class Cat : Animal { override func a() { print("Cat.a") } override func b() { print("Cat.b") } func c() { print("Cat.c") } override func d() { print("Cat.d") } } func invokeA<X: AnimalProtocol>(_ x: X) { x.a() } func invokeB<X: AnimalProtocol>(_ x: X) { x.b() } func invokeC<X: AnimalProtocol>(_ x: X) { x.c() } func invokeD<X: AnimalProtocol>(_ x: X) { x.d() } var cat1: Cat = Cat() invokeA(cat1) invokeB(cat1) invokeC(cat1) invokeD(cat1)

7:07 AM

Cのパターンを書き換えてAのパターンにしつつ、デフォルト実装を使い回すために実装を外に出したのがDです。これはまあまあ実用的なんじゃないか @tarunon

これは実用的

Cの挙動についても、今の理解だと、不便なのはわかるけど、特にあやふやな点は無いと思った。

いや

Catでconformしたように見えてしまうと、謎挙動に感じられる？ (edited)

(foo as Subclass).method() と (foo as Existential).method()で挙動が変わるのがよろしくない

7:09 AM

つまり実質的には

ああ、なるほど。

「同名同型のオーバーロード」であるのだけど

7:09 AM

それを理解できる言語仕様でないのが問題

7:10 AM

そこが理解できるなら別にいいんじゃないのんって感じ、でも

7:10 AM

Protocolの定義にあるメソッドを、自前でConformしたつもりが

7:10 AM

できていないケースがあります、はやっぱりしんどいと思う

実はAnimalの時点で、用意しないでデフォルトを使う、ということが固定されてるのがわかりにくいね。

7:11 AM

conformしてるメソッドに明示的にアトリビュートをつけるっていう提案があった気がする

1, witness tableへ乗るImpl 2, vtableへ乗るimpl 3, 同名同型のoverloadになるimpl（罠） (edited)

7:11 AM

このうち

@_implements ってそれなのかな

2はoverride明記だからいいけど、1,3が区別つかないのがやばい

7:12 AM

3を言語仕様的に存在を許さないようにするのが一番いいと思うのだけど

7:12 AM

手段は問わない、コンパイルエラーにしてもいいし、強制的に2に乗るようにしてもいい

コンパイルエラーはできそうだね

7:13 AM

現状で静的にわかるしエラーにする分には面倒な事は減る

7:16 AM

@_implements は別名メソッドでconformする謎の機能だった。

↑の話を追えてないけど、

同名同型のoverloadになるimpl（罠）

に関しては vtable 関係なく↓とかもありませんか？ @swiftbot

protocol P {} extension P { func foo() -> String { return "P" } } struct S: P { func foo() -> String { return "S" } } let s: S = S() let p: P = s print(s.foo()) print(p.foo())

1

koher

protocol P {} extension P { func foo() -> String { return "P" } } struct S: P { func foo() -> String { return "S" } } let s: S = S() let p: P = s print(s.foo()) print(p.foo())

Version:

swift-4.1.1-RELEASE

Output:

S P

Error:

これはwitness tableが絡んでないので幾分かマシです

7:30 AM

witness tableがある状態で似たようなことが起きるのが問題で、殊これに関してはただの静的呼び出しなので問題はなさそう

なるほど、↑ちゃんと読んでみます。 (edited)

もちろん、それが理解できる言語仕様の方が良いなあとは思います

7:32 AM

Protocolに適合する実装のときにアノテーション明記するの方が実はいいんじゃないかなと思い始めた

慣れちゃったけど多分よくないよなあ・・・

7:32 AM

わかんないよなあ

↓のような話をしてるのか。 @swift-4.2.4

protocol P { func foo() -> String } extension P { func foo() -> String { return "P" } } class C: P { } class SC: C { func foo() -> String { return "SC" } } let sc: SC = SC() let c: C = sc let p: P = c print(sc.foo()) print(c.foo()) print(p.foo())

SC P P

@swift-4.2.4

protocol P { func foo() -> String } extension P { func foo() -> String { return "P" } } class C: P { func foo() -> String { return "C" } } class SC: C { override func foo() -> String { return "SC" } } let sc: SC = SC() let c: C = sc let p: P = c print(sc.foo()) print(c.foo()) print(p.foo())

SC SC SC

https://twitter.com/omochimetaru/status/1044497430643798016 まとめました @noppe @tarunon @Yuta Saito

Swift 5.0 Release Process

Discordに出てきた話をまとめた > Swiftで継承とプロトコルとprotocol extensionが絡んだ時のメソッド呼び出し https://t.co/3kxEDqVQaX

@koher Override書いてる時は普通なのです。問題がない。

1つ目の override がない場合の挙動の話ですよね？

desudesu

↓の useP が specialize されてもインライン展開されても P が表示されるのか。まさに「同名同型のoverloadになるimpl（罠）」だ・・・。

protocol P { func foo() -> String } extension P { func foo() -> String { return "P" } } class C: P { } class SC: C { func foo() -> String { return "SC" } } func useP<T: P>(_ p: T) { print(p.foo()) } func useSC(_ sc: SC) { print(sc.foo()) } let sc: SC = SC() useP(sc) // P useSC(sc) // SC

常識的に考えると同名同型のoverloadなんて存在しないですからね、無意識のうちに候補から外してしまう

8:34 AM

例えばoverloadは関数にあるという先入観があるだけで、変数についても同様にoverloadが存在しうることを失念してしまいます。 (edited)

これって foo が同名で同じ型でオーバーロードされてるというわけじゃないんですか？ p.foo が sc.foo と別のメソッドを示しているわけではなく？

sc.foo()がprotocol extensionのfoo()に対して、事実上overrideではなくoverloadになっている (edited)

この「仕様」の理由としては、「親クラスの extension 上の decl は override できないのと同様に」ということらしいのですが、それなら警告なりエラーなり出すべきだというのは同意です。

11:04 AM

class Base {} extension Base { func foo() {} } class Derived : Base { override func foo() {} // error: overriding non-@objc declarations from extensions is not supported }

モジュールの外でextensionされる可能性があるから、エラーにはできなさそうな気が

@tarunon 変数についてのoverloadというのがよくわからず。

struct A { var url: String } 通常変数はoverloadはできないのですが、protocol extensionを使えばこのAにURL型の変数を生やすことが可能です

https://swift.org/blog/5-0-release-process/ 正式来ましたー

This post describes the goals, release process, and estimated schedule for Swift 5.0.

5

November 16, 2018 (final branching)

1:38 AM

意外とハヤイ

final branching までに async/await はまとまりそうにないなぁ。 (edited)

2

1:44 AM

↓このあたりも気になるところ。 https://forums.swift.org/t/opaque-result-types/15645

Opaque result types

Hello all, Here's a proposal I've been thinking about for a while (I blame Rust), but which came up again due to the review of SE-0222. Now seems like a fine time to pitch it. EDIT: The proposal has been significantly revised since this initial posting. The most up-to-date ...

CondConfやEquatable自動生成が4.1で来たみたいに、 asyncは5.1の目玉になりそう

↓これ終わらなかったら辛い。 https://github.com/apple/swift/pull/16980

[WIP] Implement dynamically callable types (@dynamicCallable). b...

This proposal introduces the @dynamicCallable attribute, which enables nominal types to be "callable" via a simple syntactic sugar. This is the implementation of the Swift evolution propo...

asyncレベルの変更を...と思ったけどcondconfはデカかった

確かに cond conf の前例があるから、 5.1 で async/await もワンチャンあるな。

そうだdynCallまだかw

condconf入ってないのに先行してcodable出ちゃった前例もあるから

この PR のスレッド、ずーっとやりとりしてる。 < @dynamicCallable (edited)

型落ちasyncがはみ出してくる可能性もありそう

型落ち async って何ですか？

modifyアクセサがそれな気がしてる

フル機能揃ってなくてとりあえず出しだけみたいな

下請けがコルーチンだし。

actor とかいつになることやら・・・。

非同期には使えないが。

cancel出来ないasyncだけこんにちはみたいな展開もあり得る

1:49 AM

ないかw

「同名同型のoverloadになるimpl（罠）」と「通常変数はoverloadはできないのですが、protocol extensionを使えばこのAにURL型の変数を生やすことが可能です」をあわせると↓みたいになるのか。 @swift-4.2.4

protocol P { var a: Int { get } } extension P { var a: Int { return 1 } } class C: P {} class SC: C { var a: Int = 2 } let sc: SC = SC() let c: C = sc print(sc.a) print(c.a)

2 1

そうですねw

2:04 AM

これを利用してMockingできないかと考えたことがありましたが、ヤバすぎたのでやめました

2:04 AM

犯罪に近い

それはヤバそう

結局sharedをやめて素直にinitの引数に入れるのが一番良かった

Swift 4.2のマイグレータが追加するDictionaryの型を変換するヘルパーメソッドはセンスがイマイチ。結局全部消した。

@swift-4.2.4 var iterator = [].enumerated().makeIterator() iterator.next()

stderr:<stdin>:2:10: warning: result of call to 'next()' is unused iterator.next() ^ ~~

@swift-4.1.3 var iterator = [].enumerated().makeIterator() iterator.next()

stderr:<stdin>:2:10: warning: result of call to 'next()' is unused iterator.next() ^ ~~

Xcodeの最新betaまだ見てないんですが、

のコードをXcode 10.0 (10A255)のPlaygroundで書いたらコンソールにこんなの出ました

SWIFT RUNTIME BUG: unable to demangle type of field '_position'. mangled type name is '5IndexSlQz'

https://bugs.swift.org/browse/SR-8354

@swift-4.2.4 let l = (0...40).lazy.filter({ _ in true }) Mirror(reflecting: l).children.forEach { print($0) }

(label: Optional("_base"), value: ClosedRange(0...40)) (label: Optional("_predicate"), value: ())stderr:

warning: the Swift runtime was unable to demangle the type of field '_predicate'. the mangled type name is 'Sb7ElementSTQzc'. this field will show up as an empty tuple in Mirrors

お、でてきた

@swift-4.2.4 [1, 2, 3].forEach { print($0) }

1 2 3

1

let num = 10 let other = 12 // 🤔 網羅的に書けないし、くどいし、ロジックに不安がある if num < other { print("small") } else if num > other { print("great") } else { print("same") }

こういう「<, ==, > それぞれのケースを網羅的に処理する」コードってどうやって書いてますか？

import Foundation // 代替案1 extension Comparable { func comparisonResult(with other: Self) -> ComparisonResult { if self < other { return .orderedAscending } if self > other { return .orderedDescending } return .orderedSame } } // 🤔 網羅的なのはいいけど、非直感的… // asc, desc のどっちがどっちなのかいつも思考が止まる[IMO] switch num.comparisonResult(with: other) { case .orderedAscending: print("small") case .orderedSame: print("same") case .orderedDescending: print("great") } // 代替案2 // 新しいenumが欲しい enum Comparison { case greater, same, smaller } extension Comparable { func comparison(with other: Self) -> Comparison { if self < other { return .smaller } if self > other { return .greater } return .same } } // 👍 網羅的！直感的！ switch num.comparison(with: other) { case .smaller: print("small") case .same: print("same") case .greater: print("great") }

#swift-contrib に持っていきたいやつかなと思ったけど、（ちゃんと読んでないですが）突き詰めるとComparableの設計そのものの話になってめんどくさそう…？ https://forums.swift.org/t/proposal-formalized-ordering-take-2/3540 https://forums.swift.org/t/pitch-comparison-reform/5662/6 (edited)

[Proposal] Formalized Ordering, take 2

Since we're running short on time, and the previous discussion thread diverged, here's my attempt to fix the Comparable protocol. Pull request: https://github.com/apple/swift-evolution/pull/464 TL;DR: 1. Equatable remains unchanged, while Comparable bloats a bit to support...

[pitch] Comparison Reform

Getting this sorted out is definitely a worthwhile effort. I do have thoughts about this proposal: I continue to have reservations about an identical spelling (e.g. ==) giving two different answers with the same values of the same type, depending on the generic context....

@takasek .less, .equal, .greater が良いように思います。

2:06 PM

ところで、 @swift-4.2.4

let a = 42.0 let b = 0.0 / 0.0 if a < b { print("a < b") } else if a > b { print("a > b") } else if a == b { print("a == b") } else { print("😇") }

2

😇

なるほど、 .less !

2:21 PM

@swift-4.2.4

import Foundation let c = NSNumber(value: Double(42)) let d = NSNumber(value: Double.nan) switch c.compare(d) { case .orderedAscending: print("asc") case .orderedSame: print("same") case .orderedDescending: print("desc") }

desc

@takasek 元の話については、僕は特に↓で問題を感じてないですね。

// 🤔 網羅的に書けないし、くどいし、ロジックに不安がある if num < other { print("small") } else if num > other { print("great") } else { print("same") }

Perl とかにある宇宙船演算子もいいかも。 @swift-4.2.4

infix operator <=> enum Comparison { case less case equal case greater } func <=> <T: Comparable>(lhs: T, rhs: T) -> Comparison { if lhs < rhs { return .less } else if lhs > rhs { return .greater } else { return .equal } } let a = 2 let b = 3 switch a <=> b { case .less: print("a < b") case .equal: print("a == b") case .greater: print("a > b") }

(edited)

a < b (edited)

class SomeViewController: UIViewController { ... override func viewDidLoad() { super.viewDidLoad() ... var parameters = SomeStruct() { didSet { someMethod(parameters: parameters) } } ...

^ これは循環参照ですよね？

あれ？それコンパイル通りますか？

8:04 AM

代入文の左辺値を右辺値でキャプチャできなかったような？

8:04 AM

あ、読み間違えた。

これの循環を切る場合は、

class SomeViewController: UIViewController { ... override func viewDidLoad() { super.viewDidLoad() ... var someClosure: () -> Void = {} var parameters = SomeStruct() { didSet { someClosure() } } someClosure = { [weak self] in self?.someMethod(parameters: parameters) } ...

8:05 AM

こんな感じでsomeClosure()で包む、以外にスマートな方法ありますか？

8:06 AM

元のコードを書き換えるときにミスってるかもしれないので良くわからない場合は言ってもらえればコンパイルできるやつを書きます。

確認ですけどviewDidLoadのローカルスコープでcomputed propertyを定義してるんですよね？(インスタンスのプロパティではなく

viewDidLoadのローカルスコープで、ローカル変数を定義しています。 override func viewDidLoad() { var parameters = SomeStruct() ... }

8:14 AM

^ これが override func viewDidLoad() { var parameters = SomeStruct() { didSet { someMethod(parameters: parameters) } } ... }

8:14 AM

^ こうです。

@swiftbot

struct Stone {} class Cat { init() { print("init cat") } deinit { print("deinit cat") } func nya() { print("begin nya") var stone = Stone() { didSet { self.mofu(stone) } } stone = Stone() print("end nya") } func mofu(_ stone: Stone) { print("mofu") } } func main() { var cat = Cat() cat.nya() } main()

1

omochimetaru

struct Stone {} class Cat { init() { print("init cat") } deinit { print("deinit cat") } func nya() { print("begin nya") var stone = Stone() { didSet { self.mofu(stone) } } stone = Stone() print("end nya") } func mofu(_ stone: Stone) { print("mofu") } } func main() { var cat = Cat() cat.nya() } main()

Version:

swift-4.1.1-RELEASE

Output:

init cat begin nya mofu end nya deinit cat

Error:

/usercode/main.swift:32:9: warning: variable 'cat' was never mutated; consider changing to 'let' constant var cat = Cat() ~~~ ^ let

@Kishikawa Katsumi didSetのコードブロックはselfをキャプチャしないので最初のコードでも循環してないと思います。↑に試してみたけど、deinitが呼ばれています。

お、ありがとうございます。じゃあ他のコードが影響しているのかな。あとで再現できるプロジェクトの形にしてみます。

1

@swiftbot

struct Stone {} struct Wall { var onChanged: () -> Void = {} } class Cat { var wall = Wall() init() { print("init cat") } deinit { print("deinit cat") } func nya() { print("begin nya") var stone = Stone() { didSet { self.mofu(stone) } } wall.onChanged = { print(stone) } print("end nya") } func mofu(_ stone: Stone) { print("mofu") } } func main() { let cat = Cat() cat.nya() } main()

1

kishikawakatsumi

struct Stone {} struct Wall { var onChanged: () -> Void = {} } class Cat { var wall = Wall() init() { print("init cat") } deinit { print("deinit cat") } func nya() { print("begin nya") var stone = Stone() { didSet { self.mofu(stone) } } wall.onChanged = { print(stone) } print("end nya") } func mofu(_ stone: Stone) { print("mofu") } } func main() { let cat = Cat() cat.nya() } main()

Version:

swift-4.1.1-RELEASE

Output:

init cat begin nya end nya

Error:

@omochimetaru 直接の原因？はexcapedなクロージャがあって（上ではonChanged）それがstoneをキャプチャしてるとCatが解放されないというものでした。

3:34 PM

ただ、これでCatが解放されないのがイマイチわからない。

@swiftbot

class Cat { init() { print("init cat") } deinit { print("deinit cat") } func nya() -> () -> Void { print("begin nya") var stone = Int(2) { didSet { // (1) print("set stone") // (2) // print("set stone, \(self)") } } print("end nya") return { print(stone) } } } func main() { var cap: (() -> Void)? = nil do { print("---1---") let cat = Cat() print("---2---") cap = cat.nya() } // end of `cat` print("---3---") cap = nil print("---4---") } main()

1

omochimetaru

class Cat { init() { print("init cat") } deinit { print("deinit cat") } func nya() -> () -> Void { print("begin nya") var stone = Int(2) { didSet { // (1) print("set stone") // (2) // print("set stone, \(self)") } } print("end nya") return { print(stone) } } } func main() { var cap: (() -> Void)? = nil do { print("---1---") let cat = Cat() print("---2---") cap = cat.nya() } // end of `cat` print("---3---") cap = nil print("---4---") } main()

Version:

swift-4.1.1-RELEASE

Output:

---1--- init cat ---2--- begin nya end nya deinit cat ---3--- ---4---

Error:

/usercode/main.swift:30:9: warning: variable 'cap' was written to, but never read var cap: (() -> Void)? = nil ^

@Kishikawa Katsumi ↑のコードで、(2)のコメントアウトを解除すると、出力結果が変わって、 deinit cat が ---3--- の後になりました。

3:48 PM

ここから推測するに、 didSet に self が含まれていて、かつ、そのcomputed propertyがescapeしているときは、 escapeしてるcomputed propertyが、そのdidSetで見ているselfをキャプチャしているっぽいですね。

^ 現状の整理としては正しいと思います。

岸川さんのコードだと、 Cat -> Cat.wall -> Cat.wall.onChanged -> self (Cat) でサイクル

3:50 PM

昼に書いた

didSetのコードブロックはselfをキャプチャしないので

↑これは条件付きで間違いだったみたいです。

いや、私もそう思ってたんですけど、昨日調べてるときにはdidSetのメソッド呼び出しがなかったら起こらないことが先に見つかったので、didSetはキャプチャするんだっけと、私もよくわからなくなっていました。

3:53 PM

現実的にはdidSetはselfをweakキャプチャする手段がたぶんないから、中身をselfを参照しない形に直す必要がある、というのが昨日の段階ですね。

// (1) print("set stone") // (2) // print("set stone, \(self)") この状態だったらサイクルしなかったので、 weak var wself = wself var stone = Int(2) { didSet { < wself を使う > } } (edited)

3:55 PM

↑こうすればいける気もします。クロージャのキャプチャリストの形式ではダメそうですね

なるほど。そっちの方がシンプルですね。

@swiftbot

class Cat { init() { print("init cat") } deinit { print("deinit cat") } func nya() -> () -> Void { print("begin nya") weak var wself = self var stone = Int(2) { didSet { guard let self = wself else { return } print(self) } } print("end nya") return { print(stone) } } } func main() { var cap: (() -> Void)? = nil do { print("---1---") let cat = Cat() print("---2---") cap = cat.nya() } // end of `cat` print("---3---") cap = nil print("---4---") } main()

1

omochimetaru

class Cat { init() { print("init cat") } deinit { print("deinit cat") } func nya() -> () -> Void { print("begin nya") weak var wself = self var stone = Int(2) { didSet { guard let self = wself else { return } print(self) } } print("end nya") return { print(stone) } } } func main() { var cap: (() -> Void)? = nil do { print("---1---") let cat = Cat() print("---2---") cap = cat.nya() } // end of `cat` print("---3---") cap = nil print("---4---") } main()

Version:

swift-4.1.1-RELEASE

Output:

Error:

/usercode/main.swift:26:9: warning: variable 'cap' was written to, but never read var cap: (() -> Void)? = nil ^ /usercode/main.swift:12:23: error: pattern matching in a condition requires the 'case' keyword guard let self = wself else { ^ case /usercode/main.swift:12:27: error: expression pattern of type 'Cat' cannot match values of type 'Cat?' guard let self = wself else { ^~~~ ?

@swift-4.2.4

class Cat { init() { print("init cat") } deinit { print("deinit cat") } func nya() -> () -> Void { print("begin nya") weak var wself = self var stone = Int(2) { didSet { guard let self = wself else { return } print(self) } } print("end nya") return { print(stone) } } } func main() { var cap: (() -> Void)? = nil do { print("---1---") let cat = Cat() print("---2---") cap = cat.nya() } // end of `cat` print("---3---") cap = nil print("---4---") } main()

---1--- init cat ---2--- begin nya end nya deinit cat ---3--- ---4---stderr:<stdin>:26:9: warning: variable 'cap' was written to, but never read var cap: (() -> Void)? = nil ^

一応これでサイクルしないようです

私も確認しました

didSetの中でも wself => self の再代入、うまくうごくんですねえ。

3:58 PM

（もしかしてバグを引き当てるんじゃないかと思ったけど）

そこにdidSet書けたのか〜と思ったんですけど、なるほどfunc定義するのと同じですね。確か関数内関数を定義してself参照したその関数をどこかに渡すとリーク作れたと思います。

もうちょっと細かい挙動を調べてintendedかどうか聞いてみようかと思います。

確か前にここでCodableで20個フィールド越えると問題があるって誰か言ってませんでしたっけ？問題を踏んだのかまだ調べつつなんですが、空オブジェクトになってしまう

20個超えてさらにあえてズラすとかじゃないっけ

それでMac壊したの私ですかね

2

7:10 AM

Generic+20個+ズラす

7:10 AM

=> メモリ破壊

あえてズラす

ズラさなければ関係ないのか...じゃあ違う事象っぽいのでもう少し調べて見ますんorz

↓みたいなパターンマッチしたい・・・。 switch keyPath { case \Foo.bar[let i].baz.qux[let key]: ... default: .... }

1

https://forums.swift.org/t/se-0231-optional-iteration/16737

SE-0231 — Optional iteration

The review of SE-0231 — Optional Iteration begins now and runs through October 12, 2018. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to...

2:50 AM

https://forums.swift.org/t/se-0230-flatten-nested-optionals-resulting-from-try/16570

SE-0230: Flatten nested optionals resulting from try?

The review of SE-0230 — Flatten nested optionals resulting from try? begins now and runs through October 8th, 2018. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your fe...

2:50 AM

２つのSEがレビュー中

2:50 AM

// Swift 4: 'Int??' // Swift 5: 'Int?' let result = try? database?.countOfRows(matching: predicate) // Swift 4: 'String??' // Swift 5: 'String?' let myString = try? String(data: someData, encoding: .utf8) // Swift 4: '[String: Any]??' // Swift 5: '[String: Any]?' let dict = try? JSONSerialization.jsonObject(with: data) as? [String: Any]

2:50 AM

let array: [Int]? = nil for? element in array { ... } // Equivalent to if let unwrappedArray = array { for element in unwrappedArray { ... } }

2:51 AM

try? の挙動変更と、 for? 文の追加

for element in array? の方が馴染みそう。 if case let foo? = foo とかを考えると。

3:04 AM

try? は ?. の挙動と合わせて提案されてる挙動で良いと思うけど、そもそも try? を使うことがほとんどないなぁ。

例外が飛んだ時にデフォルト値を使う時に、 try? + ?? をよく使う

3:05 AM

例えばJSONをストレージとして使ってるときに、初回インストール時はファイルが無かったりするので読み込めないんだけど

https://github.com/apple/swift-evolution/blob/master/proposals/0231-optional-iteration.md#imitating-optional-chaining

https://forums.swift.org/t/se-0231-optional-iteration/16737/29

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

3:06 AM

Imitating optional chaining A syntactically less disruptive approach, the idea of which is denoting an optional iteration by following the sequence expression with ?: let array: [Int]? = [1, 2, 3] for element in sequence? { ... }

このくだりが読めない・・・

Although Swift clearly has better alternatives to check for nil, this special case of optional pattern usage is very important in relation to the alternative currently discussed. The same tendency can be seen in for element in sequence?, but since binding the unwrapped sequence would effectively almost never be required, we omit the case let _? = part preceding sequence? as a rule of thumb.

3:13 AM

てか、この代替案が棄却された理由を述べてるわけじゃない？

わからん・・・

3:16 AM

Although Swift clearly has better alternatives to check for nil

Swift は nil をチェックするための明らかにより良い選択肢を持っているけれども

3:17 AM

これは Optional Binding とかのことを言ってる？

その上でサンプルコードがたくさんあるので、if caseとかfor caseのことっぽい。

this special case of optional pattern usage is very important in relation to the alternative currently discussed.

この Optional パターンの特別なケース（ if case let foo? = foo のことと思われる）は、今議論している選択肢（ for element in sequence? のことと思われる）との関係の面でとても重要だ。

3:18 AM

ここまでは意味わかるんよね。

3:19 AM

あー、でもこのあと

The same tendency can be seen in for element in sequence?,

だから、 the alternative currently discussed は for element in sequence? じゃない？

unwrapした左辺値が必要ないから省略したのが for element in seq? という書き方なんだぞ

3:20 AM

って話？だとすると、代替案がダメな理由がやっぱ書いてないですよね。

The same tendency can be seen in for element in sequence?,

同様の傾向は for element in sequence? でも見られる

そのtendencyがよくわかんないんだけど、if case let と同じようなスタイルでイケてるって言いたいんですかね。

"very important` な傾向じゃないかなぁ？

あ、なるほど。

自信はない

3:24 AM

but since binding the unwrapped sequence would effectively almost never be required

しかし、 unwrapped sequence のバインディングは事実上ほぼ必要とされないので

3:25 AM

この unwrapped sequence のバインディングっていうのは for case let element? in sequence? みたいなことを言ってる？？

それはforループの内側で、sequence? から取り出した sequence を使える必要はないって言ってるんだと思う

3:25 AM

sequence? -> sequence -> element っていう2段階取り出しにおいて。

ああ

3:27 AM

最初の

Although Swift clearly has better alternatives to check for nil

は if case let _? = optionalInt { ... } のことか。

3:27 AM

そこから読み違えてた。

3:28 AM

このパラグラフは if case let _? = optionalInt { ... } を上の一覧に入れなかった理由を説明してるだけなのか。

if case let _? = optionalInt { ... }

we omit the case let _? = part preceding sequence? as a rule of thumb.

特に反対意見は述べられてない気がするなぁ。

omitしたのは左辺の部分って意味じゃない？

3:30 AM

特に反対意見は述べられてない気がするなぁ。

まあ結局そこですよね

うん、単に if case let _? = optionalInt { ... } を↓に挙げなかったよって言ってるだけかと。

let array: [Int?] = [1, 2, nil] // Match using an optional pattern. for case let element? in array { ... } // Match using an enum case pattern. for case let .some(element) in array { ... } let optionalInt: Int? = 0 // Match using an optional pattern. if case let unwrapped? = optionalInt { ... } // Match using an enum case pattern. if case let .some(unwrapped) = optionalInt { ... } // Match using optional binding. if let unwrapped = optionalInt { ... } // Match against .some using an optional pattern switch optionalInt { case let unwrapped?: print() case nil: print() } // Match against .some using enum case pattern switch optionalInt { case let .some(unwrapped): print() case nil: print() }

3:31 AM

なんで for element in sequenc? が less disruptive なのにそれを採用しなかったんだろう？？

3:33 AM

A terminating ? sigil here can be thought of as bringing the for loop into the optional chain with the sequence and mirrors the force-unwrapping case (sequence!). On the other hand, this alternative sytactically has a lot in common with optional patterns that are used as sugar for pattern-matching .some(value). The following examples are equivalent per statement type:

最初、これ↑の On the other hand 以降で反対意見述べてんのかと思ったけど、これって単に前半で Optional chaning や Forcen unwrapping との関係を、後半でパターンマッチングとの関係を述べてるだけやんね？ (edited)

3:34 AM

tkrajacic What is your evaluation of the proposal? +1 but with a strong preference for the for element in elements? {…} syntax

3:34 AM

まったく同じ気持ちだ。

スレッドのほうですか

3:34 AM

コメント100超えてる・・・

SE-0231 — Optional iteration

I am a +1 on this proposal (except for the ? location). It is fairly common to get a sequence from a dictionary or optional chaining, and a lightweight syntax for handling it that fits with the many other uses of ? would be appropriate. You could make the same argument abou...

3:37 AM

Ben Cohen も for element in sequenc? を推してる？

3:38 AM

ざっと見たところ ? は後ろにすべき派が多いように見える。

なるほどｗ

3:38 AM

AltConsは普通に選択肢になってることもあるのか。

3:39 AM

必ず論破してからproposalになるんだと思いこんでた。

? を後ろにした方が、↓のような構文の可能性も残すと思うんよね。 let a: Int? = foo(x?) // foo の戻り値の型は Int

3:40 AM

↓よりわかりやすいと思う。 let a: Int? = x.map { foo($0) }

それな〜

3:41 AM

メソッドだったら ?. でシュッと書けるのに、引数だと map になるの、

3:41 AM

微妙な気持ちになるんですよね。

パターンパッチングや Optional Chain も含めて、 foo? はラップされてる値とラップしている Optional を分離する記法という意味で統一感がある。

かといって foo(x?) はどうなんだと思うところもあるけども・・・

3:42 AM

if let x = foo(a?, b, c?) { ... } みたいな

foo(x?) で foo が Optional を返す場合は flatten してほしいね。

3:43 AM

let number: Int? = Int(string?)

お、そのflattenはまさに、try? の話と同根かな

?. がそういう挙動だから、 try? も含めてそうなるのが自然だと思うんよね。

そうか確かに。

3:45 AM

?. でメソッドの型がoptionalの時、式の型はflattenされて1重か。

↓は OK なのに

struct Bar {} struct Foo { func bar() -> Bar? { return Bar() } } extension Int { func foo() -> Foo? { return Foo() } } let x = 42 let bar: Bar? = x.foo()?.bar() // ✅ OK

3:49 AM

↓はエラーなのは変だと思う。

struct Bar {} struct Foo { func bar() -> Bar? { return Bar() } } extension Int { func foo() throws -> Foo { return Foo() } } let x = 42 let bar: Bar? = try? x.foo().bar() // ⛔ NG

3:50 AM

↓こうしろということかもしれないけど。

struct Bar {} struct Foo { func bar() -> Bar? { return Bar() } } extension Int { func foo() throws -> Foo { return Foo() } } let x = 42 let bar: Bar? = (try? x.foo())?.bar() // ✅ OK

(edited)

確かにthrowsは . で素通しできても良さそうですね。

3:52 AM

どうせtryは式木全体にかかるんだから

3:53 AM

メソッドチェーンのどこがthrowsなのかの明示は必須でなくても良い。

3:53 AM

たまにそれ踏んで3番目のパターンを書く事あるので

3:54 AM

proposal機運あるレベル (edited)

for element in sequence? で通るなら、今後の Optional 便利構文の可能性を開くという意味でいい気がする。

4:02 AM

for? はきつい。

@swiftbot

struct RGBA<Channel> { var red: Channel var green: Channel var blue: Channel var alpha: Channel } let rgbaArray = [RGBA(red: 255, green: 127, blue: 0, alpha: 255)] rgbaArray.withUnsafeBufferPointer { rgbaPointer in print(rgbaPointer[0]) rgbaPointer.withMemoryRebound(to: UInt8.self) { uint8Pointer in print(uint8Pointer[0]) } }

1

koher

struct RGBA<Channel> { var red: Channel var green: Channel var blue: Channel var alpha: Channel } let rgbaArray = [RGBA(red: 255, green: 127, blue: 0, alpha: 255)] rgbaArray.withUnsafeBufferPointer { rgbaPointer in print(rgbaPointer[0]) rgbaPointer.withMemoryRebound(to: UInt8.self) { uint8Pointer in print(uint8Pointer[0]) } }

Version:

swift-4.1.1-RELEASE

Output:

Error:

Fatal error: Current stack trace: 0 libswiftCore.so 0x00007fc6d3c55750 _swift_stdlib_reportFatalError + 171 1 libswiftCore.so 0x00007fc6d39c3ad6 <unavailable> + 1366742 2 libswiftCore.so 0x00007fc6d3bfe383 <unavailable> + 3703683 3 libswiftCore.so 0x00007fc6d39c3ad6 <unavailable> + 1366742 4 libswiftCore.so 0x00007fc6d3b2fd80 <unavailable> + 2858368 5 libswiftCore.so 0x00007fc6d3af7ded <unavailable> + 2629101 6 libswiftCore.so 0x00007fc6d3af7c20 UnsafeBufferPointer.withMemoryRebound<A, B>(to:_:) + 42 10 libswiftCore.so 0x00007fc6d39bde30 Array.withUnsafeBufferPointer<A>(_:) + 172 12 swift 0x0000000000fed1ce <unavailable> + 12505550 13 swift 0x0000000000ff1692 <unavailable> + 12523154 ...

9:21 AM

stderr-4.1.1.txt

2.36 KB

とりあえず

9:21 AM

Intになってそう

↑これ死ぬのなんでかわかります？ withMemoryRebound の使い方間違えてる？

9:22 AM

あれ？

RGBA<Int>(red: 255, green: 127, blue: 0, alpha: 255)

手元でやると一つ目の print 実行されるのに

9:24 AM

@omochimetaru それはミスだったけど、 UInt8 にしてもクラッシュするし、 Int でも動くはずでは？ @swift-4.2.4

struct RGBA<Channel> { var red: Channel var green: Channel var blue: Channel var alpha: Channel } let rgbaArray = [RGBA<UInt8>(red: 255, green: 127, blue: 0, alpha: 255)] rgbaArray.withUnsafeBufferPointer { rgbaPointer in print(rgbaPointer[0]) rgbaPointer.withMemoryRebound(to: UInt8.self) { uint8Pointer in print(uint8Pointer[0]) } }

exit status: 4 with stderr:

Fatal error: Current stack trace: 0 libswiftCore.so 0x00007f9ac2b0f120 _swift_stdlib_reportFatalError + 168 1 libswiftCore.so 0x00007f9ac2866d0a <unavailable> + 1502474 2 libswiftCore.so 0x00007f9ac2aa419e <unavailable> + 3850654 3 libswiftCore.so 0x00007f9ac2866d0a <unavailable> + 1502474 4 libswiftCore.so 0x00007f9ac29ff0d9 <unavailable> + 3174617 5 libswiftCore.so 0x00007f9ac29d7d56 <unavailable> + 3013974 6 libswiftCore.so 0x00007f9ac29d7c90 UnsafeBufferPointer.withMemoryRebound<A, B>(to:_:) + 42 10 libswiftCore.so 0x00007f9ac2861280 Array.withUnsafeBufferPointer<A>(_:) + 97 12 swift 0x0000000001043efe <unavailable> + 12861182 13 swift 0x0000000001048022 <unavailable> + 12877858 14 swift 0x00000000004f8b42 <unavailable> + 1018690 15 swift 0x00000000004df0bb <unavailable> + 913595 16 swift 0x00000000004da3f0 <unavailable> + 893936 17 swift 0x000000000048a348 <unavailable> + 566088 18 libc.so.6 0x00007f9ac54b3740 __libc_start_main + 240 19 swift 0x0000000000488009 <unavailable> + 557065 #0 0x000000000410b054 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410b054) #1 0x0000000004108ee2 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108ee2) #2 0x000000000410b202 SignalHandler(int) (/usr/bin/swift+0x410b202) #3 0x00007f9ac6d89390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f9ac29ff0e1 $Ss18_fatalErrorMessage__4file4line5flagss5NeverOs12StaticStringV_A2HSus6UInt32VtFTf4nnddn_n (/usr/lib/swift/linux/libswiftCore.so+0x3070e1) #5 0x00007f9ac29d7d56 $SSr17withMemoryRebound2to_qd_0_qd__m_qd_

stderr.txt

https://ptpb.pw/4jCK.txt/text

archetype を UInt8 に rebound しようとして拒否されている感じですかねぇ。

9:27 AM

-O だと specialize されるので通る。

これは、本来は正しく rebound されるべきという理解で間違ってないですか？

9:27 AM

あーなるほど。 specialize でうまくいくのか。

Unsafe なのでグレーだと思います。

https://github.com/apple/swift/blob/master/stdlib/public/core/UnsafeBufferPointer.swift.gyb#L608

https://developer.apple.com/documentation/swift/unsafemutablebufferpointer/2949522-withmemoryrebound

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

9:28 AM

ここで落ちてる気がするけどなぜかメッセージが空なんですよね

9:28 AM

CommandLineSandbox`merged Swift.UnsafeMutableBufferPointer.withMemoryRebound<A, B>(to: A1.Type, _: (Swift.UnsafeMutableBufferPointer<A1>) throws -> B1) throws -> B1:

9:28 AM

↑スタックトレース

グレーなのか。でもこれできなかったら画像処理とか辛い・・・。

@swift-4.2.4

struct RGBA<Channel> { var red: Channel var green: Channel var blue: Channel var alpha: Channel } print(MemoryLayout<RGBA<UInt8>>.stride) print(MemoryLayout<UInt8>.stride)

(edited)

4 1 (edited)

アウトだ。

9:30 AM

BufferPointerを使わなければよいのでは？

9:30 AM

生のポインタの方でやってみたらいけそう。

RGBA<Int> じゃなくて RGBA<UInt8>

9:31 AM

が本来やりたいこと。

BufferPointerは配列的なメモリを扱うやつだから、strideがあってて [0]は[0], [1]は[1]にマップするものなのかも

9:32 AM

リリースビルドで通るのはこのチェックが > _debugPrecondition(MemoryLayout<Element>.stride == MemoryLayout<T>.stride) (edited)

なるほど。

debugPreconditionだからリリースのときは無いんじゃないか？

The type to temporarily bind the memory referenced by this buffer. The type T must have the same size and be layout compatible with the pointer’s Element type.

9:32 AM

9:32 AM

ほんとだ。

@swift-4.2.4

struct RGBA<Channel> { var red: Channel var green: Channel var blue: Channel var alpha: Channel } let rgbaArray = [RGBA<UInt8>(red: 255, green: 127, blue: 0, alpha: 255)] rgbaArray.withUnsafeBufferPointer { (rgbaBufferPointer: UnsafeBufferPointer<RGBA<UInt8>>) in rgbaBufferPointer.baseAddress!.withMemoryRebound(to: UInt8.self, capacity: rgbaBufferPointer.count * 4) { (uint8Pointer: UnsafePointer<UInt8>)in print(uint8Pointer[0]) print(uint8Pointer[1]) print(uint8Pointer[2]) print(uint8Pointer[3]) } }

255 127 0 255

これで期待通り

9:35 AM

(要素0のときクラッシュしそうなので ! のところは直して

@omochimetaru なるほど。ありがとう。 Array から UnsafePointer を取る一番スマートな方法って、↑か withUnsafeBytes で baseAddress をとることかな？

他に無い気がします

9:40 AM

withUnsafeBytesが返すのも結局 UnsafeRawBufferPointer なのか。 (edited)

うん。

9:41 AM

mutable だったら引数に渡すときに & でとれるのに、どういう API の整理なんだろう？

9:41 AM

あれ？引数にはそのまま渡せるんだっけ？

内側の withMemoryRebound のcapacityの計算が簡単だから型付きのBufferのほうを使うのが良さそうです

↓これはできるんだった。 @swift-4.2.4 func foo(_ p: UnsafePointer<Int>) { print(p.pointee) } let a = [2, 3, 5] foo(a)

2

var rgbaArray = [RGBA<UInt8>(red: 255, green: 127, blue: 0, alpha: 255)] func constF(_ p: UnsafePointer<RGBA<UInt8>>) {} func mutableF(_ p: UnsafeMutablePointer<RGBA<UInt8>> ) {} constF(rgbaArray) mutableF(&rgbaArray)

9:43 AM

こうですね

9:43 AM

UnsafePointerはshared referenceだからそのまま渡せる。 UnsafeMutablePointerは inout reference だから、inout引数のときと同じく & をつける

9:44 AM

func constF(_ p: UnsafePointer<RGBA<UInt8>>) {} // 心の目 func constF(_ p: shared RGBA<UInt8>) {} func mutableF(_ p: UnsafeMutablePointer<RGBA<UInt8>> ) {} // 心の目 func constF(_ p: inout RGBA<UInt8>) {}

(edited)

9:44 AM

shared referenceはまだ無いけど。

心の目ｗ

9:46 AM

withUnsafePointer がほしい・・・。

extension書くとか！

9:47 AM

@swift-4.2.4

struct RGBA<Channel> { var red: Channel var green: Channel var blue: Channel var alpha: Channel } var rgbaArray = [RGBA<UInt8>(red: 255, green: 127, blue: 0, alpha: 255)] func constF(_ p: UnsafeBufferPointer<RGBA<UInt8>>) {} func mutableF(_ p: UnsafeMutableBufferPointer<RGBA<UInt8>> ) {} constF(rgbaArray) mutableF(&rgbaArray)

exit status: 1 with stderr:

<stdin>:11:8: error: cannot convert value of type '[RGBA<UInt8>]' to expected argument type 'UnsafeBufferPointer<RGBA<UInt8>>' constF(rgbaArray) ^~~~~~~~~ <stdin>:12:10: error: '&' used with non-inout argument of type 'UnsafeMutableBufferPointer<RGBA<UInt8>>' mutableF(&rgbaArray) ^~~~~~~~~~

こっちはできないのおかしいやろｗ

9:47 AM

ArrayのAPIはBufferPointerでのアクセスしか許してないのに、コンパイラの自動変換は単体ポインタだけで、BufferPointerには行かない・・・

9:48 AM

あ〜 C Interop が目的の機能だからかな〜

9:48 AM

でもそれならそれで C から import された関数に対してだけ、変換されるべきって木もするなあ

let rgbaArray = [RGBA<UInt8>(red: 255, green: 127, blue: 0, alpha: 255)] rgbaArray.withUnsafeBytes { (buf) in for x in buf.bindMemory(to: UInt8.self) { print(x) } }

UInt8 列として取り出すだけならこれが一番簡単なような。

C/C++ で書かれた画像処理ライブラリにポインタとして渡すのが目的なので、ポインタで取り出す必要があります

(edited)

そのときは length も同時にわたすのですか？

そうですね。

9:53 AM

今のケースでは、 C++ のクラスのコンストラクタに width, height の情報と一緒に渡します。

9:54 AM

（ C API 経由で） (edited)

RGBA<UInt8> のメモリレイアウトが変わったらオシマイだから心配だ・・・ (edited)

9:56 AM

特にそういう機運は無いけれども。

アライメント的な話で？

9:58 AM

とりあえず動くようになりました。ありがとうございました。 > @omochimetaru @rintaro

アライメントとストライド、フィールドの敷き詰め方などなど。ジェネリクスも絡んでるし。

RGBA<UInt8> が単純な 4 バイトでないメモリレイアウトになったら辛いなぁ。

10:01 AM

今そこを前提に他の言語では実現しづらいいい感じの API が作れるので・・・。

@swift-4.2.4 -frontend -repl

struct RGBA<Channel> { var red: Channel var green: Channel var blue: Channel var alpha: Channel } MemoryLayout<RGBA<UInt8>>.stride // 4 MemoryLayout<RGBA<UInt8>>.offset(of: \RGBA<UInt8>.red) // 0 MemoryLayout<RGBA<UInt8>>.offset(of: \RGBA<UInt8>.green) // 1 MemoryLayout<RGBA<UInt8>>.offset(of: \RGBA<UInt8>.blue) // 2 MemoryLayout<RGBA<UInt8>>.offset(of: \RGBA<UInt8>.alpha) // 3

(edited)

// r0 : Int = 4 // r1 : Int? = Optional(0) // r2 : Int? = Optional(1) // r3 : Int? = Optional(2) // r4 : Int? = Optional(3)

(edited)

@swift-4.2.4 let a: [Int]??? = [1] let c: Int = a???.count ?? 0 print(c)

exit status: 2 with stderr:error: unable to invoke subcommand: /usr/bin/swift-swift (No such file or directory) ```

@swift-4.2.4 let a: [Int]??? = [1] let c: Int = a???.count ?? 0 print(c)

1

?. のハテナの数増やせるの知らなかった（そして数が正しくないと動かない）

おお、知らなかった・・・ < ??.

John_McCall 4h We've seen repeated requests for things like x?.count + 1, yes. I don't think there's a way to "clean up the concepts" here that could possibly lead to something like let x = y? meaning anything that wouldn't introduce its own much more serious complexity and compatibility problems.

(edited)

x?.count + 1 はなしだけど、↓はやりたいんだよなぁ。 let foo: Foo = Foo(x?) ?? Foo("foo") (edited)

8:28 AM

x? を使わないと↓になってしまう。 let foo: Foo = x.map { Foo($0) } ?? Foo("foo")

引数部分だけとかが良いのかな

8:28 AM

昨日出てきた配列をUnsafePointerとして渡せるみたいなやつも

8:28 AM

func(array) が array.withUnsafePointer { func($0) } になってるわけだから

基本的に Optional はそのままで取り回すべきじゃなくてすぐにハンドリングすべきで (edited)

8:29 AM

そう考えると ?. が一番使いたいのって ?? との組み合わせだと思うんよね。

func(x?) が x.map { func($0) } になるって範囲なら同種の仕組みだ。

そう考えると、 x?.count + 1 も (x?.count + 1) ?? 1 にするんなら (x?.count ?? 0) + 1 にできるからできなくていい。

8:31 AM

ただ、演算子も関数であることを考えると x?.count + 1 も +(x?.count, 1) だからできるはずなんよね。

これが出来る不思議ってのもありますよね。 var x: Int? = 1 x? = 1

x.map { $0.count + 1 } なのか (x.map { $0.count } ?? 0) + 1 なのかとか

8:32 AM

@rintaro なんだこりゃ！ｗ

@rintaro えー、それできるんですか？ Swift 1 の頃の名残ではなく？

たしかに実行できるｗ

8:32 AM

草

たしか Swift 1 の頃は末尾 ? が使えたはず。

x が non nil のときだけ代入される。

@swift-4.2.4 var x: Int??? x = 1 print(x) x? = 2 print(x) x?? = 3 print(x) x??? = 4 print(x)

Optional(Optional(Optional(1))) Optional(Optional(Optional(2))) Optional(Optional(Optional(3))) Optional(Optional(Optional(4)))

stderr:

<stdin>:3:7: warning: expression implicitly coerced from 'Int???' to 'Any' print(x) ^ <stdin>:3:7: note: force-unwrap the value to avoid this warning print(x) ^ !!! <stdin>:3:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(x) ^ as Any <stdin>:5:7: warning: expression implicitly coerced from 'Int???' to 'Any' print(x) ^ <stdin>:5:7: note: force-unwrap the value to avoid this warning print(x) ^ !!! <stdin>:5:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(x) ^ as Any <stdin>:7:7: warning: expression implicitly coerced from 'Int???' to 'Any' print(x) ^ <stdin>:7:7: note: force-unwrap the value to avoid this warning print(x) ^ !!! <stdin>:7:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(x) ^ as Any <stdin>:9:7: warning: expression implicitly coerced from 'Int???' to 'Any' print(x) ^ <stdin>:9:7: note: force-unwrap the value to avoid this warning print(x) ^ !!! <stdin>:9:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(x) ^ as Any

ウケる

8:33 AM

ハテナが多すぎるとエラーだ。

昨日、 for element in sequenc? を許せば将来許容できる構文に x? = 1 みたいなのもあり得るって書こうとして、いつ使うんだ？と思って止めたけどまさかすでにできたとはｗ

8:35 AM

ちゃんと↓で更新されないｗ @swift-4.2.4 var x: Int? = nil x? = 42 print(x)

nilstderr:

<stdin>:3:7: warning: expression implicitly coerced from 'Int?' to 'Any' print(x) ^ <stdin>:3:7: note: provide a default value to avoid this warning print(x) ^ ?? <#default value#> <stdin>:3:7: note: force-unwrap the value to avoid this warning print(x) ^ ! <stdin>:3:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(x) ^ as Any

var x: Int??? x = 1 print(x) x? = 2 print(x) x?? = 3 print(x) x??? = 4 print(x)

8:35 AM

最初に1を入れたから動いたのか。

@omochimetaru

ハテナが多すぎるとエラーだ。

それは警告では？

8:36 AM

print したときの。

@swift-4.2.4 var x: Int??? x???? = 4 print(x)

exit status: 1 with stderr:

<stdin>:2:5: error: cannot use optional chaining on non-optional value of type 'Int' x???? = 4 ~~~~^ <stdin>:3:7: warning: expression implicitly coerced from 'Int???' to 'Any' print(x) ^ <stdin>:3:7: note: force-unwrap the value to avoid this warning print(x) ^ !!! <stdin>:3:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(x) ^ as Any

errorです

ああ、数がそろってないと、って意味？

以下なら大丈夫。

8:36 AM

何段目のsomeで判定するかが変わってるのか・・・？

変わってそう

8:37 AM

確か Swift 1 の頃に、右辺値でもこれあったんよね。

@swift-4.2.4

func check1(_ x: Int??) { var x = x x? = 2 print(x as Any) } func check2(_ x: Int??) { var x = x x?? = 2 print(x as Any) } var x1: Int?? = .none var x2: Int?? = .some(.none) var x3: Int?? = .some(.some(1)) check1(x1) check2(x1) print("--") check1(x2) check2(x2) print("--") check1(x3) check2(x3)

(edited)

nil nil -- Optional(Optional(2)) Optional(nil) -- Optional(Optional(2)) Optional(Optional(2)) (edited)

変わった。

struct S { var prop: Int } var s: S? s?.prop = 1 とかだと、結構つかってる人いるんじゃないかな？

あ〜

8:42 AM

それの .prop が無い状態ってことか〜〜

@swift-4.0.3 let a: [Int]??? = [1] let c: Int = a???.count ?? 0 print(c)

Usage: @swift40 [SWIFT_OPTIONS] ``` [Swift Code] ```

@swift-4.2.4 let a: [Int]??? = [1] let c: Int = a???.count ?? 0 print(c)

Usage: @swift42 [SWIFT_OPTIONS] ``` [Swift Code] ```

トリプルバッククォートで囲むとできますよ

すみません笑ありがと！

4:57 PM

@swift-4.2.4 ''' var x: Int? = nil x? = 42 print(x) '''

Usage: @swift42 [SWIFT_OPTIONS] ``` [Swift Code] ```

4:58 PM

var x: Int? = nil x? = 42 print(x)`

4:58 PM

大丈夫笑

4:59 PM

@swift-4.2.4 var x: Int? = nil x? = 42 print(x)

nilstderr:

<stdin>:4:7: warning: expression implicitly coerced from 'Int?' to 'Any' print(x) ^ <stdin>:4:7: note: provide a default value to avoid this warning print(x) ^ ?? <#default value#> <stdin>:4:7: note: force-unwrap the value to avoid this warning print(x) ^ ! <stdin>:4:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(x) ^ as Any

@swift-4.2.4 ´´´ let a: [Int]??? = [1] let c: Int = a???.count ?? 0 print(c) ´´´

Usage: @swift42 [SWIFT_OPTIONS] ``` [Swift Code] ```

@swift-4.2.4 let a: [Int]??? = [1] let c: Int = a???.count ?? 0 print(c)`

1

@swift-4.2.4

public struct Foo { @usableFromInline private var a: Int = 42 @inlinable public mutating func f() -> Int { a += 1 return a } }

exit status: 1 with stderr:

<stdin>:3:5: error: '@usableFromInline' attribute can only be applied to internal declarations, but 'a' is private @usableFromInline private var a: Int = 42 ^~~~~~~~~~~~~~~~~~ <stdin>:5:9: error: var 'a' is private and cannot be referenced from an '@inlinable' function a += 1 ^ <stdin>:3:35: note: var 'a' is not '@usableFromInline' or public @usableFromInline private var a: Int = 42 ^ <stdin>:6:16: error: var 'a' is private and cannot be referenced from an '@inlinable' function return a ^ <stdin>:3:35: note: var 'a' is not '@usableFromInline' or public @usableFromInline private var a: Int = 42 ^

@swift-4.2.4

public struct Foo { @usableFromInline internal private(set) var a: Int = 42 @inlinable public mutating func f() -> Int { a += 1 return a } }

no output

↑、 @usableFromInline が private だとダメなのに、 private(set) で a += 1 があるのに通るのは大丈夫なんでしょうか？見えてはいけないものが公開されてない？

バグだと思います。

10:15 PM

@swift-main

public struct Foo { @usableFromInline internal private(set) var bar: Int { get { return 42 } set { print(newValue) } } @inlinable public mutating func f() -> Int { bar += 1 return bar } }

exit status: 134 with stderr:

SIL verification failed: function_ref inside fragile function cannot reference a private or hidden symbol: (SingleFunction && RefF->isExternalDeclaration()) || RefF->hasValidLinkageForFragileRef() Verifying instruction: -> // function_ref Foo.bar.setter %16 = function_ref @$s4main3FooV3barSivs : $@convention(method) (Int, @inout Foo) -> () // user: %17 %17 = apply %16(%15, %7) : $@convention(method) (Int, @inout Foo) -> () In function: // Foo.f() sil [serialized] @$s4main3FooV1fSiyF : $@convention(method) (@inout Foo) -> Int { // %0 // users: %20, %7, %1 bb0(%0 : @trivial $*Foo): debug_value_addr %0 : $*Foo, var, name "self", argno 1 // id: %1 %2 = metatype $@thin Int.Type // user: %14 %3 = metatype $@thin Int.Type // user: %6 %4 = integer_literal $Builtin.Int2048, 1 // user: %6 // function_ref Int.init(_builtinIntegerLiteral:) %5 = function_ref @$sSi22_builtinIntegerLiteralSiBi2048__tcfC : $@convention(method) (Builtin.Int2048, @thin Int.Type) -> Int // user: %6 %6 = apply %5(%4, %3) : $@convention(method) (Builtin.Int2048, @thin Int.Type) -> Int // user: %14 %7 = begin_access [modify] [unknown] %0 : $*Foo // users: %18, %17, %9 %8 = alloc_stack $Int // users: %19, %15, %14, %12 %9 = load [trivial] %7 : $*Foo // user: %11 // function_ref Foo.bar.getter %10 = function_ref @$s4main3FooV3barSivg : $@convention(method) (Foo) -> Int // user: %11 %11 = apply %10(%9) : $@convention(method) (Foo) -> Int // user: %12 store %11 to [trivial] %8 : $*Int // id: %12 // function_ref static Int.+= infix(_:_:) %13 = function_ref @$sSi2peoiyySiz_SitFZ : $@convention(method) (@inout Int, Int, @thin Int.Type) -> () // user: %14 %14 = apply %13(%8, %6, %2) : $@convention(method) (@inout Int, Int, @thin Int.Type) -> () %15 = load [trivial] %8 : $*Int

stderr.txt

https://ptpb.pw/Rxd6.txt/text

なるほど。 nightly での↑はコンパイルエラーになっているわけじゃなくてコンパイラがクラッシュしてる？？

SIL verification failedはそうですね

1:44 AM

SILが生成された後（optimizeされた後？）にSIL verificationステージがあって

1:45 AM

コンパイラの前段にバグがあってもここで検出して死ぬようになってる

Logic failure だ・・・。

nightly だからというか、verification ステージが効いているかどうかだと思います。Xcode 付属のものは何もしないので。

えっ、そうなんですか。

@swift-4.2.4

public struct Foo { @usableFromInline internal private(set) var bar: Int { get { return 42 } set { print(newValue) } } @inlinable public mutating func f() -> Int { bar += 1 return bar } }

exit status: 134 with stderr:

SIL verification failed: function_ref inside fragile function cannot reference a private or hidden symbol: (SingleFunction && RefF->isExternalDeclaration()) || RefF->hasValidLinkageForFragileRef() Verifying instruction: -> // function_ref Foo.bar.setter %16 = function_ref @$S4main3FooV3barSivs : $@convention(method) (Int, @inout Foo) -> () // user: %17 %17 = apply %16(%15, %7) : $@convention(method) (Int, @inout Foo) -> () In function: // Foo.f() sil [serialized] @$S4main3FooV1fSiyF : $@convention(method) (@inout Foo) -> Int { // %0 // users: %20, %7, %1 bb0(%0 : $*Foo): debug_value_addr %0 : $*Foo, var, name "self", argno 1 // id: %1 %2 = metatype $@thin Int.Type // user: %14 %3 = metatype $@thin Int.Type // user: %6 %4 = integer_literal $Builtin.Int2048, 1 // user: %6 // function_ref Int.init(_builtinIntegerLiteral:) %5 = function_ref @$SSi22_builtinIntegerLiteralSiBi2048__tcfC : $@convention(method) (Builtin.Int2048, @thin Int.Type) -> Int // user: %6 %6 = apply %5(%4, %3) : $@convention(method) (Builtin.Int2048, @thin Int.Type) -> Int // user: %14 %7 = begin_access [modify] [unknown] %0 : $*Foo // users: %18, %17, %9 %8 = alloc_stack $Int // users: %19, %15, %14, %12 %9 = load [trivial] %7 : $*Foo // user: %11 // function_ref Foo.bar.getter %10 = function_ref @$S4main3FooV3barSivg : $@convention(method) (Foo) -> Int // user: %11 %11 = apply %10(%9) : $@convention(method) (Foo) -> Int // user: %12 store %11 to [trivial] %8 : $*Int // id: %12 // function_ref static Int.+= infix(_:_:) %13 = function_ref @$SSi2peoiyySiz_SitFZ : $@convention(method) (@inout Int, Int, @thin Int.Type) -> () // user: %14 %14 = apply %13(%8, %6, %2) : $@convention(method) (@inout Int, Int, @thin Int.Type) -> () %15 = load [trivial] %8 : $*Int // user:

stderr.txt

https://ptpb.pw/_EDl.txt/text

出荷版には直ってるはずだからverificationはスキップするのか。

バグで nightly でも解消されてないということは、類似の報告がなければバグレポ出しておいた方が良さそうですね。

そうですね。ありがとうございます！

ちょっと今立て込んでるので夜にでも類似レポがないか調べて出しておきます

WWDCで言ってた #if hasTargetEnvironment(simulator) ってまだ使えないんですかね

10:55 AM

怒られる。

hasいらなくないでしょうか

10:56 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0190-target-environment-platform-condition.md

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

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

10:56 AM

targetEnvironment()

10:57 AM

4.1実装なのでXcode 9.3から使えるはずです

あら、本当だ。スライドが違うのか。 https://developer.apple.com/videos/play/wwdc2018/401/?time=1825

Hear about the latest advancements in Swift, the safe, fast, and expressive language. Find out about improvements to build times, code...

わーおそんなとこ間違ってることあるんですね……

2

いけました。ありがとうございます！

@usableFromInline の件、作りました。 https://bugs.swift.org/browse/SR-8969

2

https://www.raywenderlich.com/5357-what-s-new-in-swift-4-2

What’s New in Swift 4.2?

Swift 4.2 is finally out! This article will take you through the advancements and changes the language has to offer in its latest version.

https://forums.swift.org/t/new-lsp-language-service-supporting-swift-and-c-family-languages-for-any-editor-and-platform/

New LSP language service supporting Swift and C-family languages f...

Hey all, At Apple we are making it a priority to support high-quality tooling for all Swift developers, including those working on non-Apple platforms. We want to collaborate with the open-source community and focus our efforts on building common infrastructure that can be s...

7

ウオォと思って貼りにきたらノムラさんがもう貼ってた！w

2:18 AM

SwiftのLSP対応のプロジェクトが開始するそうです。これができればVSCodeなどで快適にSwift開発できるようになります。Windowsサポートとかも見据えてるのかな？

コンテキストはよくわからないですけど、最近 Facebook 勢が SourceKit for windows パッチ投げまくってたので、SourceKit が動けば LSP サーバ自体は Swift なのでいけるようになるんじゃないかと思ってます。

よく見たら「開始する」じゃなくて「1ヶ月前から始まった？」

2:27 AM

ほう、Facebook勢というのは、いつもの2,3人とは別の人達ですか？

2:27 AM

compnerdさんとか。

いつものですねｗ

ああ。彼らはFacebook勢だったのか。

こんばんははじめまして、松本です #general で少し話しましたが、突然ですが一つ提案がありますシェルスクリプトのSwift版、swiftShellを作りたいです

1:20 PM

要するに、せっかくターミナルのREPLでインタプリタの使い方ができ、ファイルシステムがこれだけ標準で充実してるのだから、シェルスクリプトでやっていることを全てSwiftで実用できるようにしよう！というものです

@Harutaka Matsumoto 今でもシェルスクリプトの代替としてSwiftを使うことはできますが、作ろうとしているのはどういうものですか？

はいしかし、FoundationのFile Systemをそのまま使うと、コードが不必要に長くなってしまうと思いますそれをlist(of:)だとか、makeDirectory(at:)だとか、シェルの表現を踏襲しかつswiftyな名前で実装することで、シェル経験者の移行がスムーズ、かつ初心者でも簡単に使えるものにしたいのです

ああ、なるほど。それはよいアイデアだと思います

また、C言語でいうpopen関数がにあたるものがSwift APIにありませんこれを実装することで、gnuplotだとかqdpだとかheasoftなどの学術で使われるCUIアプリケーションの中までコマンドを届かせることができ、シェルの完全なる代替となります

https://github.com/kareman/SwiftShell 既存のものだと同名で同じようなコンセプトのプロジェクトがありますね。このプロジェクトもう少しプリミティブな機能セットでおっしゃってるほどリッチなものではないようですが。

kareman/SwiftShell

A Swift framework for shell scripting. Contribute to kareman/SwiftShell development by creating an account on GitHub.

おおー同名であったのですね知りませんでした

多分入出力周りをやった感じですかね？

1:44 PM

あとbashのrunに皮をかぶせたあたり？

そうですね。IOと外部コマンドの実行を簡単に扱えるAPIを提供しているようです、今のところ。

とりあえずそうですね、もっとリッチにやりたいです

1:45 PM

そしてコンパイラ的なSwiftとシームレスに利用できるように

良いですね、僕も同じような事を考えたことがあります

2:20 PM

SwiftPMでコマンドラインツールは作れますが、現状の課題としては、ライブラリを使うためにPackage.Swiftが必要なために、ワンファイルで済ませられないのが使いにくい点だと思ってて

2:22 PM

コメント文とかで依存ライブラリを定義しておけば、裏でPackage.swiftを生成してくれて、SwiftPM経由で実行してくれる、発火用のコマンドを提供するみたいな仕様だと良いのかなあと思ってます

https://github.com/JohnSundell/Marathon

JohnSundell/Marathon

Marathon makes it easy to write, run and manage your Swift scripts

- JohnSundell/Marathon

2:22 PM

これが近そうですね

マラソンとかミントとかも目的は近いんですけど、なんかそのツール自体が根っこにある感じで、個人的にはしっくりきていないです

コメント文とかで依存ライブラリを定義しておけば、裏でPackage.swiftを生成してくれて、SwiftPM経由で実行してくれる、発火用のコマンドを提供する

これを実現するにはマラソンなどのビルドツールが根っこに無いと難しくないですか？ (edited)

https://github.com/omochi/gysb

HarutakaMatsumoto/swiftShell

Generate your swifty boilerplate. Contribute to omochi/gysb development by creating an account on GitHub.

2:26 PM

↑を作った時にやったのでやればできます

2:27 PM

こっちはコメントじゃなくてgysb.jsonで依存ライブラリを定義できる。

2:27 PM

SwiftPMのビルド中間物のキャッシュが効くようにテクってるところはある。

あ、 > ツール自体が根っこにある感じこれは外部のよく分からんビルドシステムに乗るのが気持ち悪いっていう話か

それプラス、スクリプトというか、コマンドラインツールのダウンローダー？を含めたパッケージマネージャみたいになってませんか？

まあ、ダウンローダーは過多な気がしますね

「インストールされているもの一覧」がある、のか、違う感じというか。ファイル単体で完結して再配布性もあるのがスクリプトの魅力かなと思ってます

2:37 PM

どちらかというとマラソンとかが解決してるのは、Carthageみたいなしっかりしたツールを作るときに、インストーラーの実装をサボれるのが価値に感じます

↑のシェルスクリプトを作る話だと、標準ライブラリに無いAPIを提供するライブラリとPackage.swiftを生成するビルドシステムを分けたほうが良さそうですね。

同意ですあともう一つ観点があって、Xcodeのフルサポートが欲しいんですよね〜

xcodeprojの生成の話ですか？

ですね

マラソンはそこらへんをうまくやってくれます

なるほど。

#generalより …Swiftで書かれたshellがあっても面白そうですよね… 「Swiftで書かれたshell」と「Swiftで書けるshell」では随分違うね。

そこ自分が口頭で話してたときに意図を汲み取れてなかった可能性が @Harutaka Matsumoto さんの話の流れからSwiftで書けるshellの方が正しそうです

おはようございます皆さん反応ありがとうございます

9:58 PM

えーとですね、とりあえず雛形のリポジトリを作りましたhttps://github.com/HarutakaMatsumoto/swiftShell/blob/master/README.md

This is the shell script language of Swift. It's swifty, and you can use it with existing codes seamlessly. - HarutakaMatsumoto/swiftShell

10:01 PM

ここのREADMEの完成イメージにもある通り、SwiftのREPLで主に使えるような、シェルコマンドの代替となる関数をサポートするライブラリーを作ろうということです

10:04 PM

今までの反応を見ると少し誤解があるようなのですが、これで伝わりましたかね？

REPLモードをシェルとして使いたいって事だったんですね

そうですそうです

地道にやっていきますが、オプションやマイナーなコマンドは正直手に余るので、皆さんのお力添えを頂けると嬉しいです

@Harutaka Matsumoto wow! 面白いね

5:25 PM

私はこれに取り組んでいます

↓壊れた。本当は async の中の_foo の呼び出しがコンパイルエラーでないといけないと思う。 @swift-4.2.4

import Dispatch struct S { var a: Int = 42 mutating func foo() { func _foo() { if a == 0 { return } a -= 1 print(a) DispatchQueue.main.async { _foo() } } foo() } } var s = S() s.foo()

exit status: 134 with stderr:

Argument must be @noescape function type: %62 = copy_block %61 : $@convention(block) () -> () // users: %72, %70 A partial_apply with @inout_aliasable may only be used as a @noescape function type argument. UNREACHABLE executed at /home/buildnode/jenkins/workspace/oss-swift-4.2-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/DiagnoseStaticExclusivity.cpp:883! #0 0x000000000410b054 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410b054) #1 0x0000000004108ee2 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108ee2) #2 0x000000000410b202 SignalHandler(int) (/usr/bin/swift+0x410b202) #3 0x00007f24e55b8390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f24e3cf7428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #5 0x00007f24e3cf902a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #6 0x00000000040a3fed llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) (/usr/bin/swift+0x40a3fed) #7 0x0000000000dcac45 checkStaticExclusivity(swift::SILFunction&, swift::PostOrderFunctionInfo*, swift::AccessSummaryAnalysis*) (/usr/bin/swift+0xdcac45) #8 0x0000000000d53bb3 swift::SILPassManager::runPassOnFunction(unsigned int, swift::SILFunction*) (/usr/bin/swift+0xd53bb3) #9 0x0000000000d546b1 swift::SILPassManager::runFunctionPasses(unsigned int, unsigned int) (/usr/bin/swift+0xd546b1) #10 0x0000000000d555e4 swift::SILPassManager::execute() (/usr/bin/swift+0xd555e4) #11 0x00000000005c1648 swift::SILPassManager::executePassPipelinePlan(swift::SILPassPipelinePlan const&) (/usr/bin/swift+0x5c1648) #12 0x0000000000d5c615 swift::runSILDiagnosticPasses(swift::SILModule&) (/usr/bin/swift+0xd5c615) #13 0x00000000004de5ef performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) (/usr/bin/swift+0x4de5ef) #14 0x00000000004da3f0 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*,

stderr.txt

https://ptpb.pw/Y1KT.txt/text

あれ？

10:01 AM

Linux だから？

10:01 AM

実行時エラーには変わりないけど、まだマシなメッセージが出てる。

いえ、macOSでもmasterで同エラー再現しました。

手元で実行したら

10:02 AM

無限再帰呼び出しになった

10:02 AM

foo()の末尾でfoo()呼んでるのが辺じゃないですか？

あれ？ _foo じゃないとダメだ

やりたかったのはfoo()の末尾で_foo()を呼ぶコード？

あー、しかも async を main で呼んだらダメだな。 (edited)

rintaroさんが試したのはmasterでコンパイラクラッシュの事か。

10:04 AM

Xcode10ではコンパイルはできた。

元のはアプリ中のコードだったので。

10:05 AM

これ、でもコンパイル通るのはいいのかな？まあ、 inout とかでも複雑なケースで実行時エラーだしいいのか？？

10:06 AM

@swift-4.2.4

import Dispatch func run(_ body: @escaping () -> Void) { body() } struct S { var a: Int = 42 mutating func foo() { func _foo() { if a == 0 { return } a -= 1 print(a) run(_foo) } _foo() } } var s = S() s.foo()

exit status: 1 with stderr:

<stdin>:14:13: error: nested function with an implicitly captured inout parameter can only be used as a non-escaping argument run(_foo) ^

@swift-4.2.4

func run(_ body: @escaping () -> Void) { body() } struct S { var a: Int = 3 mutating func foo() { func _foo() { if a == 0 { return } a -= 1 print(a) run { _foo() } } _foo() } } var s = S() s.foo()

(edited)

exit status: 134 with stderr:

Argument must be @noescape function type: %53 = partial_apply [callee_guaranteed] %52(%0) : $@convention(thin) (@inout_aliasable S) -> () // users: %56, %55 A partial_apply with @inout_aliasable may only be used as a @noescape function type argument. UNREACHABLE executed at /home/buildnode/jenkins/workspace/oss-swift-4.2-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/DiagnoseStaticExclusivity.cpp:883! #0 0x000000000410b054 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410b054) #1 0x0000000004108ee2 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108ee2) #2 0x000000000410b202 SignalHandler(int) (/usr/bin/swift+0x410b202) #3 0x00007f2ef3166390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f2ef18a5428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #5 0x00007f2ef18a702a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #6 0x00000000040a3fed llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) (/usr/bin/swift+0x40a3fed) #7 0x0000000000dcac45 checkStaticExclusivity(swift::SILFunction&, swift::PostOrderFunctionInfo*, swift::AccessSummaryAnalysis*) (/usr/bin/swift+0xdcac45) #8 0x0000000000d53bb3 swift::SILPassManager::runPassOnFunction(unsigned int, swift::SILFunction*) (/usr/bin/swift+0xd53bb3) #9 0x0000000000d546b1 swift::SILPassManager::runFunctionPasses(unsigned int, unsigned int) (/usr/bin/swift+0xd546b1) #10 0x0000000000d555e4 swift::SILPassManager::execute() (/usr/bin/swift+0xd555e4) #11 0x00000000005c1648 swift::SILPassManager::executePassPipelinePlan(swift::SILPassPipelinePlan const&) (/usr/bin/swift+0x5c1648) #12 0x0000000000d5c615 swift::runSILDiagnosticPasses(swift::SILModule&) (/usr/bin/swift+0xd5c615) #13 0x00000000004de5ef performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) (/usr/bin/swift+0x4de5ef) #14 0x00000000004da3f0 swift::performFrontend(llvm

(edited)

stderr.txt

https://ptpb.pw/2Gjz.txt/text

おや、手元の Mac では普通に 2, 1, 0 が表示されて、 Linux だとクラッシュ。いずれにしても、 run(_foo) はコンパイルエラーなのに run { _foo() } がコンパイルエラーでないのはまずい気が。

structのselfキャプチャってどうなるのか調べてみたら

どうなってるのかというか、本来コンパイラがエラーにしておくべきなんじゃないかな？

普通にやると > Closure cannot implicitly capture a mutating self parameter (edited)

10:12 AM

それで、 [self] でキャプチャすると > > Cannot assign to property: 'self' is an immutable capture

10:12 AM

クロージャ { } で書いてるとそうなんだけど、 func 形式でクロージャを作ったときに

10:13 AM

この辺のチェックがもれて変な事になっているきがする

先にローカル func を return したりして試したんだけど、

10:13 AM

使うだけなら non escaping になって

あ、でも違うエラーになるんだな > Nested function with an implicitly captured inout parameter can only be used as a non-escaping argument

return しようとすると escaping になったから

10:14 AM

チェックは働いてるけど↑のパターンが漏れてる気がする。

本来は _foo がエスケープ使用されると、キャプチャモードに昇格するみたいなイメージっぽいですね。 (edited)

クロージャ式は再帰できないけど、ローカル関数だと再帰できるのが漏れてる原因かも

_foo の昇格が _fooの中で生じた場合がみそかな

バグっぽい？ならバグレポしとこうかな。

import Dispatch func indirect(_ f: @escaping () -> Void) { f() } struct S { var a: Int = 42 mutating func foo() { func cl() { a = 50 indirect { cl() } } cl() print(a) } } var s = S() s.foo()

10:16 AM

↑いろいろなところをちょっと変えるだけで正しくコンパイルエラーになるｗ

1

master だとクラッシュしちゃってるし、完全にバグですね。

この辺の実装大変そうだなあ

10:17 AM

Visitorパターンだらけで読みづらいし・・・

じゃあバグレポしときます。

1

10:18 AM

@omochimetaru indirect { cl() } 見て、え、そんな未知の構文あったの？って思ったら関数だったｗ indirect が enum のでハイライトされるから。

あｗ

10:18 AM

紛らわしい名前だった。

https://bugs.swift.org/browse/SR-9043

This code creates two classes, Address and Person, and it creates two instances to represent Ray and Brian.

class Address { var fullAddress: String var city: String init(fullAddress: String, city: String) { self.fullAddress = fullAddress self.city = city } } class Person { var name: String var address: Address init(name: String, address: Address) { self.name = name self.address = address } } var headquarters = Address(fullAddress: "123 Tutorial Street", city: "Appletown") var ray = Person(name: "Ray", address: headquarters) var brian = Person(name: "Brian", address: headquarters)

` Suppose Brian moves to the new building across the street, so you update his record like this: brian.address.fullAddress = "148 Tutorial Street" What's going on here? What's wrong with this?

Brian and Ray share the headquarters instance. brian.address.fullAddress = "148 Tutorial Street" This also updates Ray's address

1

@swift-main protocol P{} extension P{ func a(){ P.a(self)() } } (edited)

exit status: 134 with stderr:

not existential UNREACHABLE executed at /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-16_04/swift/lib/SILGen/SILGenConvert.cpp:1008! Stack dump: 0. Program arguments: /usr/bin/swift -frontend -interpret - -disable-objc-interop -I /Libraries/.build/x86_64-unknown-linux/debug -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOZlib/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOHTTPParser/include -I /Libraries/.build/checkouts/swift-nio-ssl-93eb7dfa/Sources/CNIOOpenSSL/include -I /Libraries/.build/checkouts/crypto-36ec1aea/Sources/CCryptoOpenSSL/include -I /Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBcrypt/include -I /Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBase32/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOSHA1/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOAtomics/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIODarwin/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOLinux/include -I /Libraries/.build/checkouts/SwiftBacktrace-fcbf89ea/Sources/CSwiftBacktrace/include -I /Libraries/.build/checkouts/SwiftBacktrace-fcbf89ea/Sources/Clibunwind/include -module-cache-path /Libraries/.build/x86_64-unknown-linux/debug/ModuleCache -D DEBUG -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOZlib.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOHTTPParser.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOOpenSSL.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CCryptoOpenSSL.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBcrypt/include/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBase32/include/module.modulemap -Xcc -fmodule-map-fil

(edited)

stderr.txt

https://ptpb.pw/hKl-.txt/text

正しく壊れた

P.aじゃなくてSelf.aじゃないと参照できなさそうな気がした

@swift-main protocol P{} extension P{ func a(){ Self.a(self)() } }

stderr:<stdin>:4:10: warning: all paths through this function will call itself func a(){ ^

おー、ちゃんと警告まで出してくれるのか

7:29 AM

@swift-main protocol P{} extension P{ func a(){} func b() { P.a(self)() } }

exit status: 134 with stderr:

not existential UNREACHABLE executed at /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-16_04/swift/lib/SILGen/SILGenConvert.cpp:1008! Stack dump: 0. Program arguments: /usr/bin/swift -frontend -interpret - -disable-objc-interop -I /Libraries/.build/x86_64-unknown-linux/debug -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOZlib/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOHTTPParser/include -I /Libraries/.build/checkouts/swift-nio-ssl-93eb7dfa/Sources/CNIOOpenSSL/include -I /Libraries/.build/checkouts/crypto-36ec1aea/Sources/CCryptoOpenSSL/include -I /Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBcrypt/include -I /Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBase32/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOSHA1/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOAtomics/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIODarwin/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOLinux/include -I /Libraries/.build/checkouts/SwiftBacktrace-fcbf89ea/Sources/CSwiftBacktrace/include -I /Libraries/.build/checkouts/SwiftBacktrace-fcbf89ea/Sources/Clibunwind/include -module-cache-path /Libraries/.build/x86_64-unknown-linux/debug/ModuleCache -D DEBUG -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOZlib.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOHTTPParser.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOOpenSSL.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CCryptoOpenSSL.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBcrypt/include/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/checkouts/crypto-36ec1aea/Sources/CBase32/include/module.modulemap -Xcc -fmodule-map-fil

stderr.txt

https://ptpb.pw/FMWO.txt/text

aの中でaを呼び出してるからクラッシュするのかと思ってたんですけど、P.aがまずかったのか

https://bugs.swift.org/browse/SR-75 古ーいバグなんです。

1

2桁の時代のバグ…

https://forums.swift.org/t/swift-as-a-cross-platform-language-and-windows-support/12547/39?u=omochimetaru

Swift as a cross-platform language and Windows support

FWIW, the Swift for TensorFlow team is actively looking to hire an engineer to work on Swift for Windows and help drive surrounding ecosystem efforts but are struggling with finding someone who is interested and able. If you know of anyone who could be a good fit, please get...

2:39 AM

SwiftForTFチームで、Windows対応ニキも募集してるけど人が見つからねえって

2:39 AM

ラトナーが書いてる！

2:42 AM

少なくともグーグル資本でSwiftのWindows対応モチベがあるってことでアツい

これ Google の力で Windows 対応されたら Apple 以外に広がってる感があっていいね。

MSのコンパイラエンジニアがラトナーみたいに転職してくれたらいいな

2:45 AM

機械学習分野ってWindowsユーザー居なそうなイメージだけど

2:46 AM

エコシステムを広げるためって書いてるし広げたいんですね

Windows ユーザー自体は多いから、 Windows で機械学習しようとしたときに Swift ならサポートされてて簡単に始められるよって状況を作りたいのかな？

https://forums.swift.org/t/comparable-and-floatingpoint-types/16886/67

Comparable and FloatingPoint types

Completely agree with this point. FWIW, I consider #1 to be the default option that we should go with unless there is something clearly better. We have had this behavior for years now and (as you say) it is highly precedented in other languages. I agree it is suboptimal, ...

6:36 AM

FloatがComparable壊れてるスレなんだけど

6:36 AM

Introduce an new/additive <=> operator, returning less/greater/equal/unordered

6:37 AM

この案良さそう

6:38 AM

こっちを使ったsortとかが優先オーバーロードされたら結構な問題は解決

この前話してた宇宙船演算子だ。コンテクストは違うけど。 https://discordapp.com/channels/291054398077927425/291054454793306112/495628056321458196

6:54 AM

<=> の結果に .unordered があると <=> を活用するの面倒そうだけど、基本は < を使って sort とかだけが <=> を使えばいいのかな？

https://ja.m.wikipedia.org/wiki/順序集合#前順序・半順序・全順序

%E9%A0%86%E5%BA%8F%E9%9B%86%E5%90%88

7:01 AM

したがって有限半順序集合は閉路を持たない有限な単純有向グラフと自然に同一視できる。

7:01 AM

これに対応してそう・・・？

グラフって分断された孤島ができてもいいんだっけ？って思ったけど、↓の定義だと良さそう。 https://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%A9%E3%83%95%E7%90%86%E8%AB%96#%E5%BD%A2%E5%BC%8F%E7%9A%84%E3%81%AA%E5%AE%9A%E7%BE%A9

%E3%82%B0%E3%83%A9%E3%83%95%E7%90%86%E8%AB%96

12:55 PM

NaN が孤立するよね？

特に駄目な気はしないです

12:57 PM

そこからいろんな議論ができるし

12:58 PM

https://ja.m.wikipedia.org/wiki/連結グラフ

%E9%80%A3%E7%B5%90%E3%82%B0%E3%83%A9%E3%83%95

12:59 PM

連結グラフ（れんけつグラフ, connected graph）は、グラフ上の任意の2頂点間に道が存在するグラフのことである。

「道が存在する」って、向きは考慮しなくてもいいのかな？ある頂点を起点として任意の頂点に到達できるという意味ではなく？ (edited)

1:02 PM

形式的な定義が載ってなくてよくわからない

1:03 PM

A → B ↓ C の B と C の間にも「道が存在する」と言っていいのかな？

1:04 PM

とりあえず Float や Double の比較は有限半順序集合になりそう。

無向グラフを前提にしてますね (edited)

1:07 PM

有向グラフはおもちさんが貼ってくれたリンクの有向グラフと連結度って項目が詳しいですね

1

Hi please how make a request GET with swift 4 , method get not work on my projet my data is array of json object [{}, {}, {}] .

I have my API that always returns [{}, {}, {}] an array of Json, how can I decode it with swift 4.2, if someone has already had this case I'm listening. my method taps on on GET request.

You mean about Codable? struct Empty: Codable {} ... JSONDecoder().decode([Empty].self, from: data) I think this way can work well.

@JohnLight The following code is runnable one. @swift-4.2.4

import Foundation struct Empty: Codable, CustomStringConvertible { var description: String { return "{}" } } let json = "[{}, {}, {}]" let decoded = try! JSONDecoder().decode([Empty].self, from: json.data(using: .utf8)!) print(decoded)

[{}, {}, {}]

@JohnLight You can get the JSON data in the following way, although I do not recommend it because it contains a synchronous networking operation. If you do it in a GUI app, it is better to use URLSession instead of Data(contentsOf:) to get JSON data from a server.

import Foundation struct Empty: Codable {} let url = URL(string: "https://...") // Set an appropriate URL let jsonData = try! Data(contentsOf: url) let decoded = try! JSONDecoder().decode([Empty].self, from: jsonData) print(decoded)

(edited)

2:10 AM

@koher

2:10 AM

look at this ^^

Sorry, fixed my code.

2:12 AM

decode([Empty].self, ...

Okay ^^

2:18 AM

I have the same error

2:18 AM

@koher

@JohnLight You failed to decode the JSON.

2:20 AM

Maybe there is some mismatch between Utilisateur's implementation and the JSON file.

yes i think so .

It seems that Utilisateur has a property named solde and the JSON lacks it.

2:22 AM

[{}, {}, {}] does not have solde in {}

2:25 AM

Please show me your implementation of Utilisateur.

@swiftbot

import Foundation let json = """ [ { "id": 1, "solde": { "id": 1 } }, { "id": 2, "solde": { "id": 2 } }, { "id": 3, "solde": { "id": 3 } } ] """ struct Utilisateur: Codable { let id: Int let solde: [Solde] } struct Solde: Codable { let id: Int } let jsonData = json.data(using: .utf8)! let decoded = try! JSONDecoder().decode([Utilisateur].self, from: jsonData) print(decoded)

1

koher

import Foundation let json = """ [ { "id": 1, "solde": { "id": 1 } }, { "id": 2, "solde": { "id": 2 } }, { "id": 3, "solde": { "id": 3 } } ] """ struct Utilisateur: Codable { let id: Int let solde: [Solde] } struct Solde: Codable { let id: Int } let jsonData = json.data(using: .utf8)! let decoded = try! JSONDecoder().decode([Utilisateur].self, from: jsonData) print(decoded)

Version:

swift-4.1.1-RELEASE

Output:

Error:

Fatal error: 'try!' expression unexpectedly raised an error: Swift.DecodingError.typeMismatch(Swift.Array<Any>, Swift.DecodingError.Context(codingPath: [_JSONKey(stringValue: "Index 0", intValue: 0), CodingKeys(stringValue: "solde", intValue: nil)], debugDescription: "Expected to decode Array<Any> but found a dictionary instead.", underlyingError: nil)): file /home/buildnode/jenkins/workspace/oss-swift-4.1-package-linux-ubuntu-16_04/swift/stdlib/public/core/ErrorType.swift, line 184 Current stack trace: 0 libswiftCore.so 0x00007f2b8b1475c0 _swift_stdlib_reportFatalErrorInFile + 221 1 libswiftCore.so 0x00007f2b8aeb63dc <unavailable> + 1369052 2 libswiftCore.so 0x00007f2b8b0f0222 <unavailable> + 3703330 3 libswiftCore.so 0x00007f2b8b0f1689 <unavailable> + 3708553 4 libswiftCore.so 0x00007f2b8aeb5ad6 <unavailable> + 1366742 ...

2:56 AM

stderr-4.1.1.txt

1.71 KB

あー、わかった

2:58 AM

@JohnLight The type of Utilisateur.solde must be Solde instead of [Solde].

ok just that

3:01 AM

@koher

3:02 AM

i try but , i have the same error

3:02 AM

struct Utilisateur: Codable { let id: Int let solde: Solde let soldecrypto: Soldecrypto

@JohnLight The JSON lacks some properties of Utilisateur. If they are optional, you need them as Optionals.

import Foundation struct Utilisateur: Codable { let id: Int let solde: Solde let soldecrypto: Soldecrypto let nom: String let prenom: String let adresse: String? let ipadresse: String let codepostale: String? let ville: String? let reference: String let cgv: Int let genre: String let telephone: String let password: String let password_reset: String let password_updated: String let email: String let username: String let active: Int let iban: String? let bic: String? let load_identite: String? let load_justificatif_domicile: String? let validated: Int let roles: String let datenaissance: String let created: String } struct Solde: Codable { let id: Int let solde: Double let solde_old: Double let updated: String } struct Soldecrypto: Codable { let id: Int let bch_solde: Double let btc_solde: Double let eos_solde: Double let etc_solde: Double let eth_solde: Double let ltc_solde: Double let xrp_solde: Double let zec_solde: Double let updated: String } let url = URL(string: "https://preprod.cryptizy.com/test_bs78wazerty1235436ujYH/users")! let jsonData = try! Data(contentsOf: url) let decoded = try! JSONDecoder().decode([Utilisateur].self, from: jsonData) print(decoded)

(edited)

3:07 AM

For example, I changed the type of adresse from String to String?.

3:07 AM

I have no idea about if the JSON is corrupted or those properties are really optional.

ok i try with optional ,

Good it works

1

3:21 AM

@koher

3:22 AM

i try with URLSession instead of Data(contentsOf

2

3:26 AM

✌

Thanks @koher

1

@swift-4.2.4

// @escaping だけど同期的にクロージャが実行されるだけの関数 func run(_ body: @escaping () -> Void) { body() } // 値型を非同期的に更新するための機能を提供 struct Updater<Object: AnyObject, Target> { let object: Object let keyPath: ReferenceWritableKeyPath<Object, Target> func update(_ body: (inout Target) throws -> Void) rethrows { try body(&object[keyPath: keyPath]) } } // 値型、これの状態を @escaping をまたいで更新したい struct FooState { var a: Int = 0 mutating func incrementA<Object: AnyObject>(with updater: Updater<Object, FooState>) { run { // @escaping なのでこの中では `self` を更新できない updater.update { state in // Updater を使って更新 state.a += 1 } } } } // FooState を保持する参照型 class Foo { var state: FooState = FooState() { didSet { print("didSet: \(state.a)") } } func bar() { state.incrementA(with: Updater<Foo, FooState>(object: self, keyPath: \Foo.state)) } } let foo = Foo() foo.bar() print(foo.state.a)

(edited)

didSet: 1 didSet: 0 0 (edited)

@omochimetaru @takasek 前に話してた Updater が↑のようなパターンだと機能しないことがわかりました。

9:09 AM

state の didSet をなくせばちゃんとインクリメントされますが、 didSet を付けると incrementA を抜けたタイミングで値が書き戻されるようになって incrementA のスコープでの状態（ a = 0 ）で上書きされてしまいます。 (edited)

なるほど。

9:24 AM

didSetがついてない場合にうまく動くのは、call by copy-restore が

9:24 AM

参照渡しに最適化される副作用ですね

9:24 AM

かつ、そういうパターンはLoEで実行時クラッシュになるはずなんだけど動いてしまうなあ？

9:25 AM

Simultaneous accesses to 0x100c02a20, but modification requires exclusive access.

9:25 AM

あいや、うごかないっすね。良かったよかった。

9:26 AM

state の didSet をなくせばちゃんとインクリメントされますが

どうやって確認しましたか？こちらでは手元のXcodeと #swiftbot-sandbox で動かない(クラッシュ)ことを確認できました。 (edited)

@escaping またいで値型を更新したいってどういう状況ですか？

9:31 AM

withoutActuallyEscaping(_:do:) では対応できないです？

@omochimetaru おや、 REPL に貼り付けたときだけ動くっぽい。

1

9:45 AM

@rintaro 値型のメソッド内で非同期処理を行って、その結果を受けて自身を更新したいようなケースです。できないんですが、自身を保持している参照型インスタンスを引数に渡すことで、その参照型インスタンスを通して自身を更新できるという。

9:46 AM

withoutActuallyEscaping は初めて見たので今見てます。

@swift-4.2.4

import Foundation struct Foo { var a = 0 mutating func bar() { func increment() { a += 1 } withoutActuallyEscaping(increment) { increment in DispatchQueue.main.async(execute: increment) } } } var foo = Foo() foo.bar() print(foo.a)

exit status: 134 with stderr:

Argument must be @noescape function type: %7 = begin_borrow %6 : $@callee_guaranteed () -> () // users: %12, %10, %9 A partial_apply with @inout_aliasable may only be used as a @noescape function type argument. UNREACHABLE executed at /home/buildnode/jenkins/workspace/oss-swift-4.2-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/DiagnoseStaticExclusivity.cpp:883! #0 0x000000000410b054 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410b054) #1 0x0000000004108ee2 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108ee2) #2 0x000000000410b202 SignalHandler(int) (/usr/bin/swift+0x410b202) #3 0x00007fa146bad390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007fa1452ec428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #5 0x00007fa1452ee02a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #6 0x00000000040a3fed llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) (/usr/bin/swift+0x40a3fed) #7 0x0000000000dcac45 checkStaticExclusivity(swift::SILFunction&, swift::PostOrderFunctionInfo*, swift::AccessSummaryAnalysis*) (/usr/bin/swift+0xdcac45) #8 0x0000000000d53bb3 swift::SILPassManager::runPassOnFunction(unsigned int, swift::SILFunction*) (/usr/bin/swift+0xd53bb3) #9 0x0000000000d546b1 swift::SILPassManager::runFunctionPasses(unsigned int, unsigned int) (/usr/bin/swift+0xd546b1) #10 0x0000000000d555e4 swift::SILPassManager::execute() (/usr/bin/swift+0xd555e4) #11 0x00000000005c1648 swift::SILPassManager::executePassPipelinePlan(swift::SILPassPipelinePlan const&) (/usr/bin/swift+0x5c1648) #12 0x0000000000d5c615 swift::runSILDiagnosticPasses(swift::SILModule&) (/usr/bin/swift+0xd5c615) #13 0x00000000004de5ef performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) (/usr/bin/swift+0x4de5ef) #14 0x00000000004da3f0 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, vo

stderr.txt

https://ptpb.pw/UtzY.txt/text

@rintaro withoutActuallyEscaping は @escaping でない関数を型の上では @escaping だけど同期的に実行される箇所で @escaping 化するためのものという理解で合ってますか？ (edited)

~~あれ？逆じゃないですか？~~ (edited)

ああ、途中で日本語が変になってた。

本来、 @escaping ではないクロージャーは、 @escaping を求めている引数には渡せないけど

10:00 AM

コレを使うと escaping性についてハードキャストできる

とはいえ、理解はあっていると思います。withoutActuallyEscaping 外に実際にエスケープされるなら使うべきでは無いです。

今回のケースは本質的に @escaping じゃないといけないのでだめそうですね。

10:04 AM

↓みたいにすればいいのかな・・・。

struct Updater<Object: AnyObject, Target> { let object: Object let keyPath: ReferenceWritableKeyPath<Object, Target> func update(_ body: @escaping (inout Target) throws -> Void) rethrows { DispatchQueue.main.async { try body(&object[keyPath: keyPath]) } } }

https://forums.swift.org/t/accepted-se-230-flatten-nested-optionals-resulting-from-try/17376

[Accepted] SE-230: Flatten nested optionals resulting from try?

Hello, Swift Community. The review for SE-0230: Flatten nested optionals resulting from try? ran from September 29th through October 4th, 2018. You can find the review thread here. There was a lot of discussion about this proposal. Many people find the current behavior in...

3

1:09 AM

try? の仕様変更の提案が採択された

1:09 AM

下位互換壊すやつは珍しいですね

1:11 AM

こういうのが通るとワクワクする

たまに(try ? poo())?.foo()って書いててなんでじゃ！ってなるよな

そうそうw

これは良い変更ですね。

CocoaPodsのPodspecでswift_versionは指定しなくても実行した環境のSWIFT_VERSIONが採用されるからOKと思っていたけど、プロジェクトに統合しないオプションを指定したときに（プロジェクト設定を変えずにビルドだけさせる）SWIFT_VERSIONが決められなくて困るんですね。。。

作りました: https://qiita.com/advent-calendar/2018/swift

Swift Advent Calendar 2018 - Qiita

Taylorじゃない方のSwiftです(　´･‿･｀) ---

Swift Advent Calendar 2014 - Qiita
[Swift Advent Calendar 2015 - ...

11

コンパイラのバグみつけた

import UIKit protocol HogeProtocol where Self : UIViewController {} protocol FugaProtocol : HogeProtocol {} extension FugaProtocol { func fuga() { print(self.parent) } } func foo(_ fuga: FugaProtocol) { fuga.fuga() } class ViewController: UIViewController, FugaProtocol { @IBOutlet var textView: UITextView! override func viewDidLoad() { super.viewDidLoad() } @IBAction func onButton() { foo(self) } }

6:41 AM

@swift-4.2.4

class Animal { func bark() { } } protocol HogeP where Self : Animal {} protocol FugaP : HogeP {} extension FugaP { func fuga() { self.bark() } } func foo(_ fuga: FugaP) { fuga.fuga() } class Cat : Animal, FugaP { } let cat = Cat() foo(cat)

(edited)

exit status: 134 with stderr:

TYPE MISMATCH IN ARGUMENT 0 OF APPLY AT expression at [<stdin>:13:5 - line:13:15] RangeText="fuga.fuga()" argument value: %2 = open_existential_addr immutable_access %0 : $*FugaP to $*@opened("6E5774C4-DE6A-11E8-B850-46984C01C748") FugaP parameter type: $@opened("6E5774C4-DE6A-11E8-B850-46984C01C748") FugaP #0 0x000000000410ac94 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410ac94) #1 0x0000000004108b22 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108b22) #2 0x000000000410ae42 SignalHandler(int) (/usr/bin/swift+0x410ae42) #3 0x00007f057ca93390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f057b1d2428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #5 0x00007f057b1d402a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #6 0x0000000000d18138 swift::Lowering::SILGenFunction::emitApply(std::unique_ptr<swift::Lowering::ResultPlan, std::default_delete<swift::Lowering::ResultPlan> >&&, swift::Lowering::ArgumentScope&&, swift::SILLocation, swift::Lowering::ManagedValue, llvm::ArrayRef<swift::Substitution>, llvm::ArrayRef<swift::Lowering::ManagedValue>, swift::Lowering::CalleeTypeInfo const&, swift::Lowering::ApplyOptions, swift::Lowering::SGFContext) (/usr/bin/swift+0xd18138) #7 0x0000000000d1ad49 (anonymous namespace)::CallEmission::apply(swift::Lowering::SGFContext) (/usr/bin/swift+0xd1ad49) #8 0x0000000000d19cc4 swift::Lowering::SILGenFunction::emitApplyExpr(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xd19cc4) #9 0x0000000000cad75d swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xcad75d) #10 0x0000000000cbcc26 void llvm::function_ref<void (swift::Expr*)>::callback_fn<swift::Lowering::RValue swift::Lowering::SILGenFunction::emitOpenExistentialExpr<swift::Lowering::RValue, (anonymous namespace)::RValueEmitter::visitOpenEx

(edited)

stderr.txt

https://ptpb.pw/WnTm.txt/text

@swift-4.2.4

class Animal { func bark() { } } protocol HogeP where Self : Animal {} protocol FugaP : HogeP {} extension FugaP { func fuga() { self.bark() } } func foo(_ fuga: FugaP) { fuga.fuga() } class Cat : Animal, FugaP { } let cat = Cat() foo(cat)

exit status: 134 with stderr:

TYPE MISMATCH IN ARGUMENT 0 OF APPLY AT expression at [<stdin>:13:5 - line:13:15] RangeText="fuga.fuga()" argument value: %2 = open_existential_addr immutable_access %0 : $*FugaP to $*@opened("7DC7DDB8-DE6A-11E8-9C56-46984C01C748") FugaP parameter type: $@opened("7DC7DDB8-DE6A-11E8-9C56-46984C01C748") FugaP #0 0x000000000410ac94 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410ac94) #1 0x0000000004108b22 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108b22) #2 0x000000000410ae42 SignalHandler(int) (/usr/bin/swift+0x410ae42) #3 0x00007f90afabc390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f90ae1fb428 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35428) #5 0x00007f90ae1fd02a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a) #6 0x0000000000d18138 swift::Lowering::SILGenFunction::emitApply(std::unique_ptr<swift::Lowering::ResultPlan, std::default_delete<swift::Lowering::ResultPlan> >&&, swift::Lowering::ArgumentScope&&, swift::SILLocation, swift::Lowering::ManagedValue, llvm::ArrayRef<swift::Substitution>, llvm::ArrayRef<swift::Lowering::ManagedValue>, swift::Lowering::CalleeTypeInfo const&, swift::Lowering::ApplyOptions, swift::Lowering::SGFContext) (/usr/bin/swift+0xd18138) #7 0x0000000000d1ad49 (anonymous namespace)::CallEmission::apply(swift::Lowering::SGFContext) (/usr/bin/swift+0xd1ad49) #8 0x0000000000d19cc4 swift::Lowering::SILGenFunction::emitApplyExpr(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xd19cc4) #9 0x0000000000cad75d swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) (/usr/bin/swift+0xcad75d) #10 0x0000000000cbcc26 void llvm::function_ref<void (swift::Expr*)>::callback_fn<swift::Lowering::RValue swift::Lowering::SILGenFunction::emitOpenExistentialExpr<swift::Lowering::RValue, (anonymous namespace)::RValueEmitter::visitOpenEx

stderr.txt

https://ptpb.pw/5EqC.txt/text

@swift-main

class Animal { func bark() { } } protocol HogeP where Self : Animal {} protocol FugaP : HogeP {} extension FugaP { func fuga() { self.bark() } } func foo(_ fuga: FugaP) { fuga.fuga() } class Cat : Animal, FugaP { } let cat = Cat() foo(cat)

exit status: 1 with stderr:

<stdin>:6:22: error: constraint with subject type of 'Self' is not supported; consider adding requirement to protocol inheritance clause instead protocol HogeP where Self : Animal {} ^

むむ　手元のXcode10.1ではコンパイルできて実行時エラー

6:44 AM

そもそも Self 制約がついてるのに Existential 化　できる時点でおかしい感じになっている

https://github.com/apple/swift/pull/19844 最近再サポートされたっぽい。

Sema: Allow protocols with 'Self' constraints again by slavapestov...

This sort of worked in 4.2, then I banned it but it broke source comaptibility. Now that protocol superclass constraints are fully supported, let's allow this again, with some minor refactoring...

So both of these are equivalent and should work correctly: protocol P : SomeClass {} protocol P where Self : SomeClass {}

4:25 AM

お。良かった。

Hi how make Table View swipe with swift4 ? I have try but it didn't work

Swift 5ではStringをUTF-16ではなくUTF-8で保持する様になるらしい。 https://twitter.com/jckarter/status/1059586744083988482

https://gist.github.com/koher/d5d2c665cf03dcce81e7defd0bd73283

Thanks to @Ilseman's tireless work, Swift 5's String will use UTF-8 as its native representation, with great performance improvements! https://t.co/CYeCToAKUf

正確には、ASCII or UTF-16で保持していたものをUTF-8にまとめた、という事か。 https://forums.swift.org/t/string-s-abi-and-utf-8/17676

String’s ABI and UTF-8

String’s ABI and UTF-8 We just landed String’s proposed final ABI on master. This ABI includes some significant changes, the primary one being that native Swift strings are stored as UTF-8 where they were previously stored either as ASCII or UTF-16 depending on their cont...

もともとutf8じゃ無かったんですね

12:46 AM

最近CSVパーサを書いたのだけどこれの恩恵を受けられそう

メモリ確保に関して知りたいのですが、staticな値を宣言するときに static var hoge: Int { return 0 } の場合と static let hoge: Int = 0 では、前者はメモリを呼び出し時にだけ確保されるような挙動になるのでしょうか？

5:43 AM

多めにstatic letを宣言したいケースに出くわしていて、var { get }で書くべきかletで書くべきか考えていてちょっと気になりました

最適化でどちらも呼び出し側に展開されて同じになりそうな気もしますね。

前者は呼び出したときに値ができるだけで後者はストレージがずっと確保されると思います

internal で利用箇所がすべてインライン化されてもストレージは消えない？

その型のオブジェクトに対するkeyPathによる動的なアクセスができるから

6:39 AM

他のアクセスが無いことを静的に保証できない気がする

なるほど。

あれ、だめだ、MetaTypeにはkeyPath使えないっぽい

let.swift struct Foo { static let bar: Int = 42 } print(Foo.bar) var.swift struct Foo { static var bar: Int { return 42 } } print(Foo.bar)

最適化の余地はありそうか

LLVM IR の diff 貼ろうとしたらデカすぎて貼れなかった。 (edited)

ん〜 Mirror でも出てこないですね、 static property

class C { static var FOO: Int { return 1 } static let BAR: Int = 1 } public func getFoo() -> Int { return C.FOO } public func getBar() -> Int { return C.BAR }

diff let.ll var.ll

diff let.ll var.ll. GitHub Gist: instantly share code, notes, and snippets.

; Function Attrs: norecurse nounwind readnone define swiftcc i64 @"$S4test6getFooSiyF"() #0 { entry: ret i64 1 } ; Function Attrs: norecurse nounwind readnone define swiftcc i64 @"$S4test6getBarSiyF"() #0 { entry: ret i64 1 }

最適化オプションは -O

6:47 AM

@rintaro そこはそうなっても、 BAR のストレージが残ってる可能性はありますよね？ (edited)

ストレージは残りますね。

S1a3FooV3barSivpZ

6:49 AM

↑これがストレージっぽい。

ということは @noppe さんのケースでは、 let でも var でも最適化で実行効率は変わらないけど、メモリ効率は var の方が良いって結論で良いんでしょうか？

1

LLVM-IRの時点では少なくとも残ってますね

1

6:50 AM

その先で消える可能性はまだあります。

なるほど。

assembly でも残ってるので、残ると思いますよ。

これって Int だから var でもいいけど、イニシャライザ呼んでたりすると var だと効率悪いですよね。値型で単純に引数をプロパティに格納するくらいのイニシャライザなら、それもインライン化されたら変わらない？ (edited)

_$S1a3FooV3barSivpZ: .quad 42

参照型絡むと、そもそも意味が違ってくるので、使い分けする必要がありますね。 (edited)

値型で、値型のプロパティしか持たないケースですね。メンバーの葉まで全部値。

6:55 AM

イニシャライザで特殊な処理は存在せず、全部ただ引数をプロパティに入れてるだけ。

最適化を考えない場合は initに引数を渡して呼び出してstored propertyにコピー、その後完成したオブジェクトをreturnだから、構築分のオーバーヘッドがあると思います最適化を考えた場合はインライン化されて同じだと思います

全部インライン化できるかどうかでしょうね。最適化でインライン化できるなら computed property のほうがメモリ的に有利だとは思います。

7:02 AM

あと、static let の不利な点としては、lazy 扱いなのでコンパイラの判断によって、アクセスの度に初期化済みか否かの分岐が入る可能性がある、はず。 (edited)

define hidden swiftcc i8* @"$S1a3FooV3barSivau"() #0 { entry: %0 = load i64, i64* @globalinit_33_EFF83A1F47B777EA672D48C97C71346F_token0, align 8 %1 = icmp eq i64 %0, -1 br i1 %1, label %once_done, label %once_not_done once_not_done: ; preds = %entry call void @swift_once(i64* @globalinit_33_EFF83A1F47B777EA672D48C97C71346F_token0, i8* bitcast (void ()* @globalinit_33_EFF83A1F47B777EA672D48C97C71346F_func0 to i8*), i8* undef) br label %once_done once_done: ; preds = %once_not_done, %entry %2 = load i64, i64* @globalinit_33_EFF83A1F47B777EA672D48C97C71346F_token0, align 8 %3 = icmp eq i64 %2, -1 call void @llvm.assume(i1 %3) ret i8* bitcast (%TSi* @"$S1a3FooV3barSivpZ" to i8*) }

7:04 AM

↑-Ononeでの、その分岐

7:05 AM

@"$S1a3FooV3barSivpZ" = hidden global %TSi <{ i64 42 }>, align 8 define hidden swiftcc i8* @"$S1a3FooV3barSivau"() local_unnamed_addr #0 { entry: ret i8* bitcast (%TSi* @"$S1a3FooV3barSivpZ" to i8*) }

7:05 AM

↑-Oでその分岐の削除

7:06 AM

ストレージの初期値をLLVMのconstantにできるなら分岐削除できるっぽいから

7:06 AM

koherの言ってる完全struct treeなら

7:06 AM

消えそう。

7:08 AM

でもその場合はインライン化もされそうだな、インライン化はされないけど同期は消える場合はどういうのだろ、モジュール跨ぎ？

@inlinable ってプロパティには付けられないっけ？ (edited)

モジュール跨いだら、イニシャライザに副作用があるかの判断ができないから、同期せざるを得ない気がします。

イニシャライザも全部 @inlineable 想定で。

あ、またぐのは Cat.foo を呼び出す側で、 Cat.foo の初期化は Catのあるモジュールのビルド時に完結しますよね

7:10 AM

inlineableは

7:10 AM

インライン化することを保証しなくないです？

保証しないのはモジュール内も同じじゃない？

インライン化しない場合の話だから

7:11 AM

@inlineableをつけなければ、しないかも。

7:12 AM

class Cat { static let a: Int = 42 } にたいして、Cat.aのgetter関数が生成されていて、同期ロジックはgetterの内部で作られていて

ああ、分岐が消えるか消えないかについてか。

Catと違うモジュールにあるコードから Cat.a を読むコードを書いた場合

7:18 AM

Cat.aの関数呼び出しをして、でもその先では同期が無い

7:18 AM

って状態になるかなあと。

メモリ的にはcomputed propertyにしたいところですが、staticに宣言しようとしているところがOpenGLESのGLenum周りなので効率もきになるところです

と言っても1drawあたりで20~30コールくらいなので結局computed propertyで宣言しちゃおうと思います！ありがとうございます

@hiragram

public protocol DecodableByJSON : Decodable { associatedtype JSON : Decodable init(from json: JSON) throws } extension DecodableByJSON { public init(from decoder: Decoder) throws { let json = try JSON(from: decoder) try self.init(from: json) } } public struct GenericVector3<T> { public var x: T public var y: T public var z: T public init(_ x: T, _ y: T, _ z: T) { self.x = x self.y = y self.z = z } } public typealias GenericVector3JSON<T> = Array<T> extension GenericVector3 : DecodableByJSON /*(これが必要) , Decodable*/ where T : Decodable { public typealias JSON = GenericVector3JSON<T> public init(from json: GenericVector3JSON<T>) throws { guard json.count == 3 else { fatalError() } self.init(json[0], json[1], json[2]) } }

7:13 AM

ConditionalConformanceでは間接的にProtocolを適用できないんですね（ここでは「DecodableByJSONを満たさせると自動的にDecodableを満たす」ことを指して「間接的」と呼んだ

それどういうエラーになる？

#swiftbot-sandbox でbotに投げたらいいじゃない。 (edited)

Codable系はそもそもextensionから付けられないみたいな制約があるのでcondconf一般の話なのかCodableの話なのか判別つかないなう

なるほど？

7:16 AM

Codable系はそもそもextensionから付けられない

それ自体はでも今はできるよ。Swift4.2で入った。 (edited)

decodeなどのメソッドを生成するときにextensionだと困るみたいなエラーでない？

7:16 AM

へー入ったのか

fixitの差し込むコード面白いなｗ

7:26 AM

初めてみたｗ

2択でDecodableのextensionが産まれるんだけど

7:31 AM

そのFixItをベースにしてもコードを完成させられなくて

7:31 AM

: DecodableByJSON のところを : DecodableByJSON, Decodable とするのが正解

redundant conformanceでないのかそれ

ConditionalConformanceでは間接的にProtocolを適用できない、というか、しない、っぽい？

Swiftで書かれたクラスのdeinitが呼ばれるタイミングってSwiftから使ったときとObjective-Cから使ったときで変わったりしますか？

変わらないと思うけどObjCのオブジェクトはAutoReleasePoolで解放される場合があるのでそういうのから参照されてるとARPoolのdrainのタイミングまで遅延する場合がありそうです

あーなるほど。それはありそうですね

9:31 AM

SwiftってAutoReleasePoolないんですか？

9:32 AM

Swiftから書ける autoreleasepool {} はあれ完全にObjC用なのでしょうか

無いはず・・・

9:33 AM

あれはFoundationで定義される関数です

9:33 AM

フルネームだと ObjectiveC.autoreleasepool っぽい。

思いっきりObjectiveCの中に入ってましたね。

https://github.com/apple/swift/blob/14d796d8287928b8e3ef9ac793b4aab4becf3cf6/stdlib/public/SDK/ObjectiveC/ObjectiveC.swift#L170

https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

すごくObjC用っぽい

9:37 AM

とりあえずタイミング違う可能性ありそうなのがわかってすっきりしました。ありがとうございます

1

調べたいオブジェクトがわかってるなら、deinitを書いてそこにブレークポイントを貼るとわかりやすいかもしれません。

SE-0235 - Add Result to the Standard Library

The review of SE-0235 - Add Result to the Standard Library begins now and runs through November 12, 2018. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback priva...

Swift.ErrorはExtension with Generic Where Clauseで。

public enum Result<Value, Error> { case success(Value), failure(Error) // … } extension Result where Error: Swift.Error { /*…*/ } extension Result where Error == Swift.Error { /*…*/ }

https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md#detailed-design (edited)

throws as returning a Result

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

来ましたね大物が

12:02 AM

ていうか今回も起きたらすでに野村速報が投稿済みw

12:07 AM

プロポーザル書けるほど話し合いまとまってたんですね

プロポーザル読んだ Error == Swift.Error の場合がExistentialとしてのエラー型の場合で、こっちを使えばエラー型を指定しない場合としても使えるのかな

12:57 AM

Antitypicalとはちょいちょいメソッド名が違いますね

1:00 AM

スラバがサラッとでかいこと言ってるw

Since Error existentials have a single retainable pointer representation, we should consider making Error self-conforming. As a bonus, in Chris's implementation the extension Result where Self.Error == Error can be merged with extension Result where Self.Error : Error.

1:01 AM

Existentialがそれ自身をconformしない仕様に切り込んでいる・・・

をー

1:39 AM

Result<T> vs Result<T, E>紛争が終結してる

両方サポートできていいですよね。

昔 Chris Lattner が、 typed throws をサポートするか決着を付けないと Result の話はできないって繰り返し言ってたから無視してたんだけど、 Proposal まで作ったのか。

1:45 AM

現段階では時期尚早な気がする。

そうですね。レビューマネージャがそのラトナー自身なのでちょっとびっくり。 (edited)

レビューマネージャーは適当に割り振られてるんじゃない？

1:56 AM

賛成とかじゃないと思う。

2:00 AM

非同期処理の多くは async/await で解決できるし、 "Delayed Handling" はむしろやらない方がいいケースが多いからやらざるを得ないときだけがんばればいいと思うし、 "Separating Errors" は例が抽象的すぎてこれがやりたいことが頻発するイメージがわかない。

そういう趣旨の反対コメントもありますねえ

dataTask については、戻り値を URLSessionDataTask に使ってるのが微妙だけど、これは Foundation の API 設計の問題だと思うなぁ。

2:06 AM

response をエラーケースでも受け取りたいとしても、 data と response と error を受け取るだけなら↓ async/await と typed throws で↓にできる。

func dataTask(with url: URL) async throws URLSessionDataTaskError -> (Data, URLResponse) { ... } struct URLSessionDataTaskError: Error { let response: URLResponse? }

2:08 AM

以前 Joe Groff が Result 全否定してたときのコメント。

Yeah, we extensively discussed adding a Result type internally, but ultimately couldn't justify it. The only real use case we could see in the wild was for threading errors through CPS-inversion-style abstractions like async promises, something we hope to provide proper language support for. More generally, expressing effects as monadic values is a pretty awful abstraction; aside from polluting the Internet with an endless deluge of unhelpful tutorials, they also don't compose cleanly, they impose nesting where is desired—you have to pick between Result<Async<T>> and Async<Result<T>>, or build ResultT<AsyncT<Identity>><T> out of monad transformers—and they don't do the natural thing when used with other higher-order abstractions—if you're mapping a `throws` function over a collection, you probably want to propagate that error like `rethrows` does, not end up with a collection of Result<T>. I'd rather see us adopt an extensible algebraic effects system, something like http://www.eff-lang.org , which provides a framework for `throws`, `async` and other control flow effects to be cleanly composed and abstracted over. I see `throws` as the first seed of that.

https://forums.swift.org/t/throws-as-returning-a-result/1799/2

Yeah, we extensively discussed adding a Result type internally, but ultimately couldn't justify it. The only real use case we could see in the wild was for threading errors through CPS-inversion-style abstractions like async promises, something we hope to provide proper langu...

https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752/21?u=omochimetaru

SE-0235 - Add Result to the Standard Library

It's not quite that cut and dry. As soon as you have more than one thing with this sugar, you get composition issues—is () throws async -> () a Result> or a Future>? More likely what you want when you're inside the context is to have a set of "effects" rather than a nesting...

2:22 AM

JoeGroff書き込んでここでも「エフェクトが欲しいんじゃないの？」って書いてる？

2:23 AM

Like much of the proposed API here, though, it's probably best to consider that additively once we get the basic type in place.

ここが読解できないんですけど、Resultを入れるんじゃなくてAPIごとにenumでも定義したら？って意味です？ (edited)

雑にまとめたら良く伸びました https://twitter.com/omochimetaru/status/1060348871698657280

SE-0235 - Add Result to the Standard Library

クランチに記事を投稿しました SwiftにResult型が提案されレビュー入りした https://t.co/vvAF2RzVSP #qrunch

そういえば、Existentialがそれ自身のプロトコルには準拠しない、っていうやつの理由は何なんでしょう？

本当はopening existentialをしないとfunction群は使えないはずだけど、swiftはそこの記法を省略してるだけみたいな感じ

書いた。 https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752/50

I disagree to add Result to the standard library for now. Major use cases of Result are error handling of asynchronous operations. We will be able to do it without Result when Swift supports async/await. // without Result nor async/await func download(from url: URL, _ c...

スレ伸びるの早いですね

@koher と同様に非同期が先って意見や、Optionalの言語サポート(?.とか)みたいなResultの言語サポートを無視して型だけ入れる話を先にするのは良くないとか、結構反対もある

少なくともこのまま入ることはないんじゃないかな。 Result 入れるにしてもどんな API 付けるかだけでも相当議論の余地があるはず。

入れるにしてもどんな API 付けるかだけ

そこについてはPitchスレがめっちゃ伸びてたんでそっちでやってるのかと思ってました。 (edited)

4:26 AM

でもこの流れを見てると、正規プロポーザル出てから本気出す人も結構居るんですね。

Proposal は Forum で議論すれば盛り上がってなくても出せるし、 Proposal 出てからが本番なのでは。

Forumで議論しなかったProposalは当然そうだけど、長いこと書き込まれてたPitchに関しては、関心のある人は書き込むと思ってた。

Proposal の Review が最後の砦なので、そこだけ見てる人も多そう。

文書化されていちどまとまるから入りやすいというのはあるか。

4:29 AM

スレ長すぎてわかんないもんなあ。

4:29 AM

最後の砦

なるほど

4:30 AM

そういう意味では、自分でプロポーザルかける程度にPitchが温まったら、さっさとレビュー出したほうが

4:30 AM

意見の回収効率が良くて良さそうだ。

4:31 AM

いや、難しいな、文書化するのにコストがかかるから、そこにジレンマがあるのか。

Result ほんと最近は↓さえあれば十分なんじゃないかと思ってる。 enum Result<Value> { case success(Value), failure(Error) func get() throws -> Value { ... } }

4:33 AM

throws/try でうまく書けないところで使うだけだから、すぐに get で throws/try の世界に戻して言語機能を活用した方がコードがシンプルになることが多い気がする。

4:34 AM

あとは Result { try foo() } ができるようにするイニシャライザを付けるくらい。

言語機能の方だとflatMapErrorとかは書きにくくないですか？

4:40 AM

あ、Untyped Errorなら、flatMapErrorはいらないか。

4:42 AM

非同期のところに関しては確かにそうですね. do { try get() } catch { } したいだけがほとんどだ (edited)

@omochimetaru

ここが読解できないんですけど、Resultを入れるんじゃなくてAPIごとにenumでも定義したら？って意味です？

よくわかんないけど、まずは最小限の Result を加えてから API の追加を検討する話をしてんのかな？？

Like much of the proposed API here

ここはResult型のメソッドのことか。

7:22 AM

例に出てくるNSURLSessionとかのことかと思った。

うーん、ドキュメントみたいなフォーマルな文章は読めても、こういうくだけた英文になると急に難易度上がるね・・・。多分その前の文が

I think it would nonetheless behoove us to integrate Result better into the language; if nothing else, it would be great to extend ?, ?? and other optional-related operators to also work with Result.

で、ほしいのはエフェクトのセットで Result とか Future はモナド変換の複雑さを抱えてて微妙だけど、にも関わらず標準ライブラリへの追加を望むのであれば、 Result のための ? （ ?. で使う ? のこと？）や ?? があった方がいいだろうね、ということを言ってると思うので、そういう風に続くのが自然かなと思った。

なるほど

+1 to an unconstrained, two-argument Result type. Referring back to @John_McCall's original error handling rationale, I think throws and Result can be seen as addressing different corners of the design space. As the rationale describes, throws was designed for systemic errors, which tend to have a large distance between error source and error handler, so source and handler end up needing to be rather loosely coupled, which was a motivator for the exception-like propagation and lack of specific typing in the current throws feature. Result on the other hand is great for conditions that are intended to be immediately handled by the caller, for which being an regular return value with a more specific failure type is in fact the more convenient representation. While we should definitely have helper operations to map back and forth between throws and Result when the failure type of Result conforms to Error, I think Result would be maximally useful if it doesn't need to be used as an integrated facet of the throws-based error handling mechanism.

https://forums.swift.org/t/adding-result-ii-unconstrained-boogaloo/17128/18

Adding Result II: Unconstrained Boogaloo

+1 to an unconstrained, two-argument Result type. Referring back to @John_McCall's original error handling rationale, I think throws and Result can be seen as addressing different corners of the design space. As the rationale describes, throws was designed for systemic errors...

4:48 PM

↓のような理解でいいのかな？ throws と Result は異なる問題を取り扱ってて、 throw されたエラーは伝播して問題の発生源から遠く離れたところでハンドリングされるから typed じゃなくてゆるく Error として扱えば良くて、 Result は（ Optional のように）即時ハンドリングされることが意図されてるから明確な型を指定できるのが適する。 throws と Result を相互変換できる機能は提供すべきだけど、 throws とは別の局面で使われてこそ Result は真価を発揮すると思う。 (edited)

1

前に @koher が同じこと書いてた気がしますけど

public enum VectorizateNoAccelerate {} #if !canImport(Accelerete) && !NO_ACCELERATE public enum Vectorizate {} #else public typealias Vectorize = VectorizateNoAccelerate #endif

でNO_ACCELERATE有効で外部からVectorizate.staticMethodで呼ぼうとするとパッケージ名のVectorizateの方を参照してしまって詰んだ…… (edited)

8:53 AM

結局パッケージ名か型名変えて対応したんでしたっけ？

シンボル名インポートする裏技？がある

インポート側で対応ってことですか？公開するライブラリとして作ってるのでそれだと微妙ですね……

そうだね、インポートする側の技

https://forums.swift.org/t/introducing-sourcekit-lsp/17964 きましたー

Introducing SourceKit-LSP

As recently announced by @akyrtzi, we have been working on a new language service for Swift and C-family languages based on the Language Server Protocol (LSP). I am excited to say that the source code for SourceKit-LSP is now available on GitHub! While the new language servi...

5

https://github.com/apple/sourcekit-lsp

apple/sourcekit-lsp

Language Server Protocol implementation for Swift and C-family - apple/sourcekit-lsp

2:15 AM

おおおお

2:19 AM

VSCodeとSublimeTextで試せる状態みたいですね

ですね。VSCodeの場合はそれ用のプラグインをビルドする必要があるのでちょっと面倒。

AppCode民も幸せになるかしら

AppCode は LSP 対応してないと思います

IDEAはやってませんでしたっけ

2:35 AM

https://plugins.jetbrains.com/plugin/10209-lsp-support

LSP Support - Plugins | JetBrains

Welcome to the JetBrains plugin repository

2:35 AM

プラグインだった

おお

swift-4.2.1-RELEASEでビルドしても、普通に動くぽい。

3:04 AM

Visual Studio Code - insidersで。

型が見えてる！

https://twitter.com/dmartincy/status/1062848673753784320

Daniel Martín (@dmartincy)

Emacs ❤️ sourcekit-lsp

func foo<T: P>(_: T) extension P { func _forwardToFoo() { foo(self) } } func callFooOnEach(_ ps: [P]) { for p in ps { p._forwardToFoo() } }

3:36 AM

PのExisはP自身にconformしないが、extensionの中のselfを介してconformさせられる技

3:37 AM

ネタ元 https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025/18?u=omochimetaru

Lifting the "Self or associated type" constraint on existentials

It's awkward, but you can in fact "open" the existential by invoking a protocol extension method, which will give you Self as the dynamic type of the value inside the method, which you can then pass to generic functions: func foo(_: T) extension P { func _forwardToFoo() {...

3:37 AM

↑existensialのassoctype制約を無くすピッチ

3:39 AM

昔々から今までできなかったのは技術的な理由で、PWTがassoctypeを持ってなかったからで、今はそこがクリアされてるらしい

これいつから出来るようになったの

5:25 AM

昔試して死んだ記憶がある

5:26 AM

いや、これじゃなかったかな

https://github.com/apple/swift/pull/20629

[DNM] Allow Error to conform to itself by rjmccall · Pull Request...

Most of the foundation for this was laid in earlier patches. This PR should not be merged because it arguably requires Evolution approval. PRs this depends on that aren't in the 5.0 branch: #20...

2:19 AM

let errorValue: Error = MyError.reallyImportant("goodbye") func castValueToError<T>(error: T) -> Error? { return error as? Error } // CHECK-NEXT: reallyImportant("goodbye") print(castValueToError(error: errorValue) ?? value)

2:20 AM

自己confromただしErrorだけ、という謎パッチ

1

November 16, 2018 (final branching)

7:03 AM

そういえば5.0final branchingが終わったのか

お、無事 @dynamicCallable が final branching 前にマージされてる。 https://github.com/apple/swift/pull/20305 (edited)

Implement @dynamicCallable. by dan-zheng · Pull Request #20305 ...

This PR introduces the @dynamicCallable attribute, which enables nominal types to be "callable" via a simple syntactic sugar. This is the implementation of SE-0216. Read the proposal for ...

5.0の大きな特徴の1つになりそうですね

うれしい。

import Foundation class Cat { @objc func nya() -> Int { return 3 } } class Dog { @objc func wan() -> Int { return 4 } } func f(_ a: AnyObject) { let x = a.nya() let y = a.wan?() print(type(of: x), x) // Int 3 print(type(of: y), y) // Optional<Int> nil } f(Cat())

7:26 AM

こんなんあるんですね・・・

なんで AnyObject に a.nya() できるの？

https://developer.apple.com/documentation/swift/anyobject

7:44 AM

@objcがついているメソッドはAnyObjectに対して呼び出せるんです。 (edited)

あー、 REPL に分割して貼ったからエラーになったのか。

7:47 AM

REPL に↓のように分割してコピペするとエラーになる。

import Foundation class Cat { @objc func nya() -> Int { return 3 } } class Dog { @objc func wan() -> Int { return 4 } } func f(_ a: AnyObject) { let x = a.nya() let y = a.wan?() print(type(of: x), x) // Int 3 print(type(of: y), y) // Optional<Int> nil } f(Cat())

let a: AnyObject = Cat() a.nya()

ほんとだ。なんで？

REPL のネームスペース（？）いまいちよく理解してないんだけど、実行単位ごとに名前空間が変なんよね。

なるほど。

7:49 AM

LLVM的にはModuleっていう単位が構築されてるので

7:49 AM

あり得ると思います。

同じ名前を使えたり。実行単位ごとに名前空間が切られてる？その割にはまたいでアクセスできたりするし、よくわからない。 (edited)

Swift的には、REPLのモジュールと、1コマンドごとのサブモジュールになってるのかな

@objcがついているメソッドはAnyObjectに対して呼び出せるんです。

↓これできるの気持ち悪い・・・。 import Foundation class Foo {} let a: AnyObject = Foo() print(String(describing: a.lowercased)) // nil

何がどうなってるんだ

7:59 AM

メソッドがなければunrecognized selectorで落ちるはず・・・

NSString に @objc な lowercased というプロパティがあるからまずコンパイルは通る。

8:00 AM

a.lowercased の結果が nil になるのはよくわからない。

8:01 AM

この @objc な API は呼び出せるの、 Swift でできる必要あったのかなぁ。今となっては @dynamicMemberLookup と @dynamicCallable でできるとキレイそうだ。

もしかして

8:01 AM

メソッドの場合は () と ?() が使えるように

unrecognized selector ではなく

プロパティの場合だから

nil になる仕様なら

生えてなければnilなのか

wan?() は普通の挙動だね。

8:03 AM

a.wan が nil になって、 nil に対するコールで ?() が nil を返してる？

8:05 AM

import Foundation class Cat { @objc func nya() -> Int { return 3 } } class Dog { @objc func wan() -> Int { return 4 } } func f(_ a: AnyObject) { let x = a.nya() let y = a.wan print(type(of: x), x) print(type(of: y), y) } f(Cat())

Int 3 Optional<() -> Int> nil (edited)

8:09 AM

↓だと型が定まらなくてコンパイルエラー。

import Foundation class Cat { @objc func nya() -> Int { return 3 } } class Dog { @objc func wan() -> Int { return 4 } } class Foo { @objc func wan() -> Double { return 5 } } func f(_ a: AnyObject) { let x = a.nya() let y = a.wan print(type(of: x), x) print(type(of: y), y) } f(Cat())

wan-nya-dynamic.swift:15:13: error: ambiguous use of 'wan()' let y = a.wan ^ wan-nya-dynamic.swift:7:16: note: found this candidate @objc func wan() -> Int { return 4 } ^ wan-nya-dynamic.swift:10:16: note: found this candidate @objc func wan() -> Double { return 5 } ^

なるほど

↓ z がヤバイことにｗｗｗ

import Foundation class Cat { @objc func nya() -> Int { return 3 } } class Dog { @objc func wan() -> Int { return 4 } } class Foo { @objc func wan() -> Double { return 5 } } func f(_ a: AnyObject) { let x = a.nya?() let y: Int? = a.wan?() let z: Double? = a.wan?() print(type(of: x), x) print(type(of: y), y) print(type(of: z), z) } f(Dog())

Optional<Int> nil Optional<Int> Optional(4) Optional<Double> Optional(1.385238852664656e-309)

8:13 AM

メモリレイアウトの違う二つの値だったらどうなるんだ？

ObjCのメソッドがないときのDoubleが0になる挙動・・・？

8:14 AM

いや、メソッドがないならnilか。なんだこれ。 (edited)

8:14 AM

Intの4をDoubleとしてbitcastしちゃってるのか。

うん、おそらく。

8:16 AM

32 bit が 64 bit になった

import Foundation class Cat { @objc func nya() -> Int { return 3 } } class Dog { @objc func wan() -> Int32 { return 4 } } class Foo { @objc func wan() -> Double { return 5 } } func f(_ a: AnyObject) { let x = a.nya?() let y: Int32? = a.wan?() let z: Double? = a.wan?() print(type(of: x), x) print(type(of: y), y) print(type(of: z), z) } f(Dog())

Optional<Int> nil Optional<Int32> Optional(4) Optional<Double> Optional(3.22526e-319)

8:20 AM

↓死んだ。

import Foundation class Cat { @objc func nya() -> Int { return 3 } } class Dog { @objc func wan() -> Int { return 4 } } class Foo { @objc func wan() -> X { return X(value: 5) } } @objc class X: NSObject { var value: Int init(value: Int) { self.value = value } } func f(_ a: AnyObject) { let x = a.nya?() let y: Int? = a.wan?() let z: X? = a.wan?() print(type(of: x), x) print(type(of: y), y) print(type(of: z), z) } f(Dog())

Segmentation fault: 11

プロパティアクセスは同名のメソッドの呼び出しに変換されてさらに呼び出す前にrespondsToSelector:でチェックしてますね

12:15 PM

nya() も wan() も呼び出す前にrespondsToSelector:でチェックしてますね

12:20 PM

プロパティアクセスではないですね。どっちもローレベルで見るとメソッドだ

@objc funcはObjcランタイムで動くようになるし、AnyObjectはFoundation importしたら実質NSObjectになるから

12:22 PM

凡ゆるメソッドが呼び出せる、idになる

nyaとwanに関しては、 .nya?() で呼び出さないと、なかった場合はunrecognized selectorといってクラッシュしました

そう、?をつける

メソッドの型が IUO になっているような感じ。

objc protocolのoptional funcと同じ

12:23 PM

ObjectiveCだと、id型に対してなんでもメソッド呼び出せた(クラッシュしないとは言ってない)のと一緒ですね

notRecogonizedで死なないようにrespondsToSelectorを挟むSwift優しい（優しくはない

ObjC Runtimeも内部的には検査はしているのではないですか？

12:28 PM

えいやで呼び出してるわけではなく。

12:28 PM

というか関数ポインタをvtableから探してこないといけないからそこで検出されそう。

vtableじゃなくて

12:28 PM

なんだったかな、objcはvtableではない

-doesNotRecognizeSelector:というメソッドが呼ばれて何もしなければ死ぬ

たしかにいわゆるvtableでは無理か。

https://developer.apple.com/documentation/objectivec/nsobject/1418637-doesnotrecognizeselector?language=objc

https://developer.apple.com/documentation/objectivec/1418530-class_getinstancemethod?language=objc

12:31 PM

selectorとclassのピアからmethodを引いて、そのmethodが関数へのポインタを持ってるみたいな感じ、だったはず

12:32 PM

所謂method swizzlingは、selectorとclassのピアに挟まってるmethodを差し替えるテクニックのこと

doesNotRecognizeSelectorをオーバーライドすると死なないやつもできるんか・・・

内部的なチェック機構は詳しく無いのだけど、methodが見つからなければdoesnotやって処理されなければunrecognizedで死

12:33 PM

事前チェックのためにrespondsToがある

12:34 PM

swiftのnya?()は、意味的にはrespondsTo(nya)→nya()だと思う

12:34 PM

RxSwiftで死を回避してるコードあった気がする

mport Foundation class Cat { @objc dynamic func respondsToSelector(_ sel: Selector) -> Bool { return true } } let c: AnyObject = Cat() c.lowercased

なんてことを

Unrecognized selectorで死んだ

ObjCの話だと https://developer.apple.com/documentation/objectivec/nsobject/1571960-methodsignatureforselector?language=objc https://developer.apple.com/documentation/objectivec/nsobject/1571955-forwardinvocation?language=objc methodSignatureForSelector: と forwardInvocation: の組み合わせでRailsみたいに完全に動的なメソッドやプロパティの呼び出しに対応することもできるよ。

1

respondsToSelectorをオーバーライドしたらobjcのメッセージ探索フェーズに入れる事が分かったのでやろうと思えばSwiftでもできますね

1:01 PM

やらないけど

forwardInvocationもありましたね、RxSwiftに入ってるのはそっちだった気がする

public class Animal { public init() {} } func main() { // OK _ = Animal() // OK _ = Animal.init() // OK _ = Animal.self.init() // error: Constructing an object of class type 'Animal' with a metatype value must use a 'required' initializer _ = (Animal.self as Animal.Type).init() }

2:49 AM

↑面白い。式「Animal.self」の型は「Animal.Type」だと思っていたけど、 Animal.selfは { K ; K == Animal.Type } で、 Animal.Typeは { K ; K <= Animal.Type } であって、型システム上の区別があるようだ

2:51 AM

一度ダイナミックなメタタイプになってしまうと、サブタイプのメタタイプが入る可能性があって、意味が変わる。 (edited)

なるほど。↓でも同じことになるね。 let animalType = Animal.self _ = animalType.init()

2:56 AM

あと、 Animal に final 付けてもコンパイル通る。

finalなるほど

あと当たり前だけど init に required 付けても通る。

そうですね。required init はSwiftにおいて理解するのが結構難しい概念だと思う

async/awaitのキャンセルについての提案が投稿されてたので、スレ違いだけど最近考えてたキャンセルサポートの方法を書き込んでみた。

3:17 AM

https://forums.swift.org/t/proposal-to-add-cancellation-abilities-for-async-await/18419/3

Proposal to add cancellation abilities for Async/Await

I want to share my idea to you. First, without any support about cancellation for async/await, user can use pattern as like below. // cancel notification sender interface class CancelContext { var token: CancelToken func cancel() } // cancel notification receiver interf...

ジョーグロフから、それ考慮済みだよ、ってコメント来た！

でも考慮済みなら良かった。

# This library is only hypothetical, sorry from cancel_tokens import cancel_after, cancel_on_callback # Returns an opaque CancelToken object that enters the "cancelled" # state after 10 seconds. cancel_token = cancel_after(10) # So this request gives up after 10 seconds requests.get("https://...", cancel_token=cancel_token) # Returns an opaque CancelToken object that enters the "cancelled" # state when the given callback is called. cancel_callback, cancel_token = cancel_on_callback() # Arrange for the callback to be called if someone clicks "stop" stop_button.on_press = cancel_callback # So this request gives up if someone clicks 'stop' requests.get("https://...", cancel_token=cancel_token)

https://vorpus.org/blog/timeouts-and-cancellation-for-humans/ (edited)

4:33 AM

Joe Groff が挙げてる方式。（斜め読みでコード抜き出しただけなので本当にこれが言いたいのかわからないけど。） (edited)

4:34 AM

トークンとコールバックが別で扱われてるのがちょっと気持ち悪い気がする。

4:40 AM

↓みたいな方がいい気がする。

struct Canceller { func cancel() func onCancel(_ body: () -> Void) } func download(from url: URL, canceller: Canceller? = nil) async throws -> Data let canceller = Canceller() let data = try await download(from: url, canceller: canceller) DispatchQueue.main.asyncAfter(deadline: .now() + 10.0) { canceller.cancel() } stopButton.onTap { canceller.cancel() }

4:41 AM

よくみたら @omochimetaru 案とほぼ同じ気がする・・・。

4:41 AM

ちがうか。

4:44 AM

↑の Canceller だと context と token の役割が一体化していて、 canceller に onCancel ができるのがまずいのか。

4:49 AM

外部に公開するときに純粋に cancel の機能だけを公開したい。

4:50 AM

でも外部から Canceller を注入するなら、一体化しててまずいことってあるかな？

非同期関数の内部でcancelを呼ばれないようにしたい。

そっち側の要求もあるのか。 API 利用者視点しか考えてなかった。

5:43 AM

@omochimetaru ↓は利用者側が context から token 取り出して register できるのは問題ない？

// cancel notification sender interface class CancelContext { var token: CancelToken func cancel() } // cancel notification receiver interface class CancelToken { func register(handler: @escaping () -> Void) }

それは問題ないですね、むしろやりたい可能性がある

5:43 AM

並行発火するタスクをその場でアドホックにクロージャーだけで書いたりできる。

うーん、↓みたいな API の視点で考えると Canceller に対して利用者がキャンセル時の挙動を登録できるのは気持ち悪い気がする。 func download(from url: URL, completion: (Result<Data, Error>) -> Void) -> Canceller

5:49 AM

並行発火するタスクをその場でアドホックにクロージャーだけで書いたりできる。

cancel を呼び出す側が必ず存在するので、そこに記述すれば良かったりしない？

それは場合によりそうですけど、局所性が下がって読みづらくなることがありそう

逆に、 API 側が何らかの都合で自己キャンセルはあり得ないのかな？

それはあり得るのでやったら良いです

5:50 AM

例えばネットワークが切断してしまうのと

5:50 AM

APIの利用側から見れば同じです（意図せず中断するという意味で

じゃあ cancel を呼べてまずい理由はないのでは？

スコープが違います

5:52 AM

タスクが自殺するのはそのタスクだけの話で

5:52 AM

Cancellerでやりたいのは複数の合成したタスク全体を全部止めたい話

一つの Canceller を複数の処理に与えてまとめてキャンセルするときに内部からキャンセルされたら困るのか

そうです

で、 cancel が複数箇所で行われうるときに、 Canceller 経由で register できないと cancel を書く度に同じ処理を記述しないといけないのか。

？　文意が取れない

canceller.token.register { // キャンセル時の処理 } ... func pressStopButton(_ sender: UIButton) { canceller.cancel() }

と書くよりも func pressStopButton(_ sender: UIButton) { canceller.cancel() // キャンセル時の処理 } の方がいいかと思ったけど、

canceller.token.register { // キャンセル時の処理 } ... func pressStopButton(_ sender: UIButton) { canceller.cancel() } func doubleTap(_ gestureRecogizer: UITapGestureRecognizer) { canceller.cancel() }

みたいなときはキャンセル時に差し込む処理がまとめて書ける？

ああ、そういう意味か。それもそうだし、 self.canceller が対応してる非同期タスクが、2種類あるかもしれない。

6:05 AM

ButtonAを押して発火する動画のDL処理と、ButtonBを押して発火する動画のアップロード処理があるとして、どっちの場合も同じcanceller propertyで使っているかも。（これらの処理は同時には生じないとする

6:05 AM

そのとき、今起きてる処理に対応するキャンセル処理っていうのは、Cancellerオブジェクトにぶら下がってないといけない。

なるほど。キャンセルしたときに何が起こるかは canceller に依存していて、そのためには canceller に登録処理を行えないといけないのか。

6:09 AM

そういう意味だと cancel_callback, cancel_token = cancel_on_callback() は callback と token の両方を取り回さないといけないことになって良くないんじゃない？

そのcancel_callbackとcancel_tokenを、cancelContext.cancel() と cancelContext.token にまとめてるのが僕の（というかC#の)書いてる案で

6:10 AM

そのpythonのやつがなんでそれをペアタプルで返したのかはよくわかんないですけど

6:11 AM

プログラミングインターフェースの観点からいけば、その段階は記事の中盤なので

6:11 AM

終盤ではwithで隠蔽してるからそこは論点の本質じゃないと思います (edited)

たしかに "Cancel tokens are unreliable in practice because humans are lazy" とか書かれてるな

6:14 AM

"Cancel scopes: Trio's human-friendly solution for timeouts and cancellation" が提案してる箇所か

昼読んだときは Joe Groff の返信しかちゃんと見てなくてコンテクストを取り違えてたけど、 @omochimetaru の提案は非同期処理とキャンセルのトークンを暗黙的に（全体で見れば明示的だけど個々の API コールで見れば暗黙的に）結びつけたいということだったのか。で、 Joe Groff がリンクしてるのも with を使った同じような仕組みになってると。 (edited)

そうです

10:09 AM

で、僕が言いたかったのはそれを実装するためには言語サポートで

10:09 AM

TLSにあたるもののコルーチン版が要るぞって話で (edited)

10:11 AM

ジョーグロフの回答で、それスレがあるよって言われたので解決

10:13 AM

スレッドの方では主に実行スレッドのコントロールについて話されてるけど、

10:13 AM

キャンセルに言及してる人も居て

10:13 AM

かつ、キャンセルのプログラミングインターフェースの観点では、そのブログの方で補完されてる

まだタグも無くswift.orgにも現れていませんがswift-5.0-DEVELOPMENT-SNAPSHOT-2018-12-03-aがダウンロード可能になってるぽいです。 (edited)

2:15 AM

dockerイメージ: norionomura/swift:swift-5.0-branch

2:16 AM

macOSインストーラ: https://swift.org/builds/swift-5.0-branch/xcode/swift-5.0-DEVELOPMENT-SNAPSHOT-2018-12-03-a/swift-5.0-DEVELOPMENT-SNAPSHOT-2018-12-03-a-osx.pkg (edited)

https://swift.org/download/#snapshots にも来てた。

https://apple.github.io/swift-evolution/#?version=5

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

私のPlaygroundもそろそろ更新しよう。 Swift 5っぽいソースコードを載せたいんですけど、何がそれっぽいですかねえ？

@dynamicCallable ですかねー

SE-0216 Introduce user-defined dynamically "callable" types

4:22 AM

SE-0215 Conform Never to Equatable and Hashable

4:23 AM

https://apple.github.io/swift-evolution/ ↑ここで5.0の見てたけど、あまり大きいのは無い感じ

4:28 AM

String周りは結構変わってる気がする。

ああそうか

4:28 AM

#"This string has an \#(interpolated) item"#

4:29 AM

RawString入ったのは見た目にも変化があっていいですね

^ これはわかりやすい！

4:32 AM

dynamicCallable も書いたらインパクトが強そうです。

StringInterpolation 関係もうまく使えば便利になりそう。

extension String.StringInterpolation { mutating func appendInterpolation<T>(_ val: T?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = nil print("The value is: \(value, default: "<nil>")")

^ いいですね。採用で。

ああこれ、コンパイルの仕方が変わるだけじゃなくて、

4:42 AM

\() のオーバーロード？を自分で追加できるようになるんですね。 (edited)

ですね。

default: "nil" はめっちゃいいな

前にゆってたやつ

ですね

swift-5.0-branchはSequence周りがぶっ壊れてるぽい。

Swift 5、@autoclosureで受け取ったクロージャを@autoclosureなパラメータへ渡せなくなってる。

$ docker run --privileged -it --rm norionomura/swift:5020181204a swift Welcome to Swift version 5.0-dev (LLVM 9a8bf9ce12, Clang eba26b8d1c, Swift b74d54a27c). Type :help for assistance. 1> func takeAutoclosure(_ closure: @autoclosure () -> String) { 2. takeAutoclosure(closure) 3. } error: repl.swift:2:21: error: function produces expected type 'String'; did you mean to call it with '()'? takeAutoclosure(closure) ^~~~~~~ ()

これってクロージャを実行するクロージャに展開されるんでしょうか

エラーメッセージに従って直すと、そうなりますよね。

1:24 AM

4.2まではクロージャのまま渡せてた。 (edited)

ですよね、地味に辛い

無意味なオーバーヘッドが強制されてしまうのか

報告しておいた。 https://bugs.swift.org/browse/SR-9420 (edited)

https://github.com/apple/swift/pull/20152 でなされた意図的なものなのですね。-swift-version 4.2 での互換性は保たれているはず。

[AST/Sema] Associate @autoclosure flag with parameter declaratio...

These changes aim to: Move @autoclosure flag from function type to parameter declaration Serialize @autoclosure as part of the parameter declaration Convert it from being a type attribute to be d...

ありがとうございます。

1:50 AM

Swift 5.0スナップショットでYamsのCIを毎日走らせようと試してたのだけど、自前のコレクションでSequence.compactMap()を使うと無限ループになってしまうので、テストにタイムアウトの仕組みとか入れないと怖くてCI設定できない…

だいたいのCIサービスは時間でAbortするんじゃないです？

そうなんだけど、毎日CI自身のタイムアウトまで実行してしまうと、Plan Usageが60倍くらい増えるんじゃ無いかな…

1:56 AM

Array.append(contentsOf:)とSequence.forEach(_:)でクラッシュ、Sequence.sort(_:)とSequence.compactMap(_:)で無限ループが起きるみたいで、Yamsのテストだと再現するけど、PlaygroundやREPLで再現しない

(edited)

2:02 AM

ちなみに無限ループを放置するとメモリを大量に消費して、macOSがクラッシュする。

謎なバグですね。

ステップ実行で確認すると、IteratorProtocol.next()がnilを返してもループを抜けないみたい。

費用がかさむっていう話なんですね。。。

stdlibのソースを読むとSequence準拠の型で public __consuming func makeIterator() -> Iterator { の様になってるけど、我々がSequence準拠の型を書く時にも__consumingをつける必要があるのかな？

ownershipに関してはオーバーライド関係があって

6:43 AM

例えばmoveを要求する場面で実際にはcopyしても問題ないみたいな

6:44 AM

consumingはselfの所有権の破棄だから、Sequenceの１回だけ読める性質を表していて

6:44 AM

てことは、準拠するときにconsumingをつけなくっても、

6:44 AM

問題はなさそう？

6:45 AM

インターフェースとしては保守的に１回だけ読んでselfがアクセス不能になるけど、実際の型のふるまいとしてはselfが生きてる、で正しい気がします

うーん、プロトコル定義に__consumingが付いていて、準拠する型の定義に付いている／付いていないでは、一応生成されるコードが違うぽい？ https://github.com/apple/swift/blob/master/test/SILGen/value_ownership.swift

https://gist.github.com/rintaro/0aa9c71409eacc5af24e60ed5744c0cf

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

7:35 AM

OwnershipManifestを読んでも、よくわからない。

それはそうだと思います、付いてないfuncで準拠する場合、consuming版としてthunkが必要

__consumingってこれかな。 https://forums.swift.org/t/ownership-annotations/11276

Ownership Annotations

Hello Swift Evolution, Over the course of summer of 2017, I was tasked with exploring the implementation of ownership annotations for the Swift language. The goal at the time was to release this proposal at the end of my time and un-underscore the attributes after we had co...

これですね

7:52 AM

func に対して付けられるのが３つあって

7:56 AM

selfに対する意味が代わる nonmutating : selfをshared渡しする mutating : selfをinout渡しする consuming: selfの所有権を譲る ( selfはdeinitされたような扱いでそこで使えなくなる )

7:58 AM

引数にはshared / inout / ownedがあって、これまでの無指定はowned相当らしいけど、引数のownedとselfのconsumingの間に対応があるのか無いのかよくわからないです

selfはdeinitされたような扱いでそこで使えなくなる って、将来のmoveonlyな型についてのOwnershipManifest内の説明ですよね。今使われてる、moveonlyではない型についてはどんな効果があるのだろう？

moveは普通の型でもできるから普通の型でもそうだと思ってました。 moveonlyっていうのは、can not copyというのが言いたい事であって、イメージとしては、今までの型がすべてCopyable、新しくCopyableでない型を追加したいという話

8:19 AM

【可能性1】今までの型: copyとmoveができる moveonly型 copyができなくて、常にmoveしないといけない型 consming: メソッドレシーバのselfの所有権をメソッド内部にmoveする (edited)

8:20 AM

でも逆の考え方もできそうですね。【可能性2】 moveonlyではない通常の型の場合、consumingメソッドの呼出しに対して、 selfのコピーを作成してそのコピーをメソッド内部にmoveする。そうするともともとのレシーバは生き続ける。 (edited)

__consumingメソッド内でのselfは常にコピーされたモノになるという事？

可能性2の場合そうなりますね。

なるほど。

僕もドキュメントからそう考えただけで、確認はまだです。現状のアンスコ版とかで試せそうですね。

xcrun --toolchain org.swift.5020181204a swiftc -emit-sil swift/test/SILGen/value_ownership.swift の出力を見た感じ、教えて頂いた説明で合ってそうです。 (edited)

可能性2？1？

あ、呼び出し前にコピーが発生しているかどうかは、これではわからないか。

2っぽい動き。 public struct S<T> { var x: T public __consuming func foo() {} } public func testing<T>(c: S<T>) { c.foo() } の __consuming 有り無しで

8:46 AM

あり

// S.foo() sil @$s4test1SV3fooyyF : $@convention(method) <T> (@in S<T>) -> () { // %0 // users: %2, %1 bb0(%0 : $*S<T>): debug_value_addr %0 : $*S<T>, let, name "self", argno 1 // id: %1 destroy_addr %0 : $*S<T> // id: %2 %3 = tuple () // user: %4 return %3 : $() // id: %4 } // end sil function '$s4test1SV3fooyyF' // testing<A>(c:) sil @$s4test7testing1cyAA1SVyxG_tlF : $@convention(thin) <T> (@in_guaranteed S<T>) -> () { // %0 // users: %3, %1 bb0(%0 : $*S<T>): debug_value_addr %0 : $*S<T>, let, name "c", argno 1 // id: %1 %2 = alloc_stack $S<T> // users: %6, %5, %3 copy_addr %0 to [initialization] %2 : $*S<T> // id: %3 // function_ref S.foo() %4 = function_ref @$s4test1SV3fooyyF : $@convention(method) <τ_0_0> (@in S<τ_0_0>) -> () // user: %5 %5 = apply %4<T>(%2) : $@convention(method) <τ_0_0> (@in S<τ_0_0>) -> () dealloc_stack %2 : $*S<T> // id: %6 %7 = tuple () // user: %8 return %7 : $() // id: %8 } // end sil function '$s4test7testing1cyAA1SVyxG_tlF'

8:47 AM

呼び出し側でコピーして、callee 側で破棄している。

8:47 AM

なし

// S.foo() sil @$s4test1SV3fooyyF : $@convention(method) <T> (@in_guaranteed S<T>) -> () { // %0 // user: %1 bb0(%0 : $*S<T>): debug_value_addr %0 : $*S<T>, let, name "self", argno 1 // id: %1 %2 = tuple () // user: %3 return %2 : $() // id: %3 } // end sil function '$s4test1SV3fooyyF' // testing<A>(c:) sil @$s4test7testing1cyAA1SVyxG_tlF : $@convention(thin) <T> (@in_guaranteed S<T>) -> () { // %0 // users: %3, %1 bb0(%0 : $*S<T>): debug_value_addr %0 : $*S<T>, let, name "c", argno 1 // id: %1 // function_ref S.foo() %2 = function_ref @$s4test1SV3fooyyF : $@convention(method) <τ_0_0> (@in_guaranteed S<τ_0_0>) -> () // user: %3 %3 = apply %2<T>(%0) : $@convention(method) <τ_0_0> (@in_guaranteed S<τ_0_0>) -> () %4 = tuple () // user: %5 return %4 : $() // id: %5 } // end sil function '$s4test7testing1cyAA1SVyxG_tlF'

オーナーシップ系の動きは一切ない。

おお！ほんとだ！

8:49 AM

なるほど、ジェネリック型にすることで最適化を抑制してcopy_addrとdestory_addrが出てきてわかりやすい (edited)

public protocol P { func foo() } public struct S<T>: P { var x: T public __consuming func foo() {} } public func testing<T: P>(c: T) { c.foo() }

これのときに、

8:57 AM

ああ、sil が張れない。

8:58 AM

test.sil

GitHub Gist: instantly share code, notes, and snippets.

8:59 AM

S.foo() 内で destroy しているけど、呼び出し側でコピーが無い。これ大丈夫なのかな？

これ、destroy_addrが生成されるのとrelease_valueが生成されるのは、どんな違いがあるのですか？ https://github.com/apple/swift/blob/master/test/SILGen/value_ownership.swift だと後者が生成される。

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

これ大丈夫

引数を破棄してる？

あ、これってmakeIterator()で壊れる原因なのでは… (edited)

makeIterator() で壊れる原因

それを疑っています。 self が破棄されている可能性。

9:05 AM

non-__consuming な protocol 要求に __consuming で準拠するテストケースはあるのかな？

public protocol P { func foo() } public struct S<T>: P { var x: T public __consuming func foo() {} } public func testing<U: P>(_ obj: U) { for _ in 0..<10 { obj.foo() } } class CC { } let obj = S(x: CC()) testing(obj)

とりあえずクラッシュするテストケースできました

複数回呼べてオーバーデストロイになるんですね

makeIterator()の場合、protocolが__consumingですね。

ああ、逆なのですね。だとすると、メモリリーク系か？

~~https://gist.github.com/norio-nomura/dc9fa7cd54592eb0d48dfe35251b9e80~~ (edited)

test.sil

GitHub Gist: instantly share code, notes, and snippets.

9:18 AM

protocol witness for P.foo() in conformance S<A>がdestroy_addrを生成するのに、呼び出し時にコピーされませんね。

これだと呼び出し側が P になってないです。

りんたろーさんのやつは、protocolとしては non-consmingだから、呼出し時にコピーが無いけど

ぬ。

実際に呼ばれてるのはconsumingだから内部にデストロイがあって壊れる？

9:19 AM

本当はコピーしてからメソッドを呼び出すようなthunkを生成して、そのthunkによってprotocol witness tableを埋めないといけないけど

9:19 AM

まだ作ってないとかかな。

あ、ちょっと離席するけど、YamsでmakeIterator()を__consumingにしても、やっぱりfor inは無限ループになった事は確認ずみ。ちょっと状況が違うのかも。

そういえば、Collectionプロトコルにはoverride func makeIterator() -> Iteratorとか含まれるのだけど、これって関係するのかな。

Yamsのテストがクラッシュしたり無限ループになったりしてたの、swift-5.0-DEVELOPMENT-SNAPSHOT-2018-12-08-aで直ってた。

お。

正確には 2018-12-06 -> 2018-12-07 で直ったぽい。

https://twitter.com/slava_pestov/status/1073280602974158849 (edited)

Improving OS Log using Custom String Interpolation and Compile-tim...

So we discovered last night that variadic enum cases work in Swift 4.2 when asserts are off: enum E { case numbers(_: Int...) } E.numbers(1, 2, 3)

11:33 PM

@swift-4.1.3 @swift-4.2.4 -frontend -repl enum E { case numbers(_: Int...) } E.numbers(1, 2, 3)

stderr:

<REPL Input>:1:29: error: cannot create a variadic tuple enum E { case numbers(_: Int...) } ^ <REPL Input>:1:1: error: use of unresolved identifier 'E' E.numbers(1, 2, 3) ^

// r0 : E = REPL.E.numbers([1, 2, 3])

それウケる

https://forums.swift.org/t/improving-os-log-using-custom-string-interpolation-and-compile-time-interpretation/18799 なんか大物がきた。

Improving OS Log using Custom String Interpolation and Compile-time Interpretation Hi all, I, along with @Ben_Cohen, @moiseev and @Devin_Coughlin, have been working on improving Swift APIs for Apple's unified logging system, based on some recent exciting developments to the ...

お

5:36 AM

これ欲しかった奴っぽい

コンパイル時書式構築自体は良いと思うんだけど、なんでOSLogの改修として出てくるんだろ Foundation.String(format:) 相当の標準が先に欲しいと思った

6:55 AM

書き込んどくか

@swiftbot versions

development_2018-12-15-a swift-5.0-branch_2018-12-14-a 4.2.1 4.1.3 4.1.2 4.1.1 4.1 4.0.3 4.0.2 4.0 3.1.1 3.1 3.0.2 3.0.1

^ Swift 5のスナップショットを使えるようにしました。

8:37 PM

https://swift-playground.kishikawakatsumi.com WebのPlaygroundもSwift 5が選べるように。他に良いサンプルがあったら教えてください。 StringInterpolationのサンプルはうまく動きませんでした

@swiftbot --version latest

extension String.StringInterpolation { mutating func appendInterpolation<T>(_ val: T?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = nil print("The value is: \(value, default: "<nil>")")

1

kishikawakatsumi

extension String.StringInterpolation { mutating func appendInterpolation<T>(_ val: T?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = nil print("The value is: \(value, default: "<nil>")")

Version:

swift-DEVELOPMENT-SNAPSHOT-2018-12-15-a

Output:

Error:

Stack dump: 0. Program arguments: /usr/bin/swift -frontend -interpret /usercode/main.swift -disable-objc-interop -module-name main /usr/bin/swift[0x4608a04] /usr/bin/swift[0x46067d0] /usr/bin/swift[0x4608bb2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f5500154390] [0x7f55005834e8] [0x7f5500583343] [0x7f550058313a] /usr/bin/swift[0xcec7de] /usr/bin/swift[0xcf09f2] /usr/bin/swift[0x515eff] /usr/bin/swift[0x4eae3e] /usr/bin/swift[0x4e6712] /usr/bin/swift[0x48db1e] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f54fe87e830] /usr/bin/swift[0x48b959] Segmentation fault (core dumped)

T を Any にすると動く

9:04 PM

@swiftbot --version latest

extension String.StringInterpolation { mutating func appendInterpolation(_ val: Any?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = nil print("The value is: \(value, default: "<nil>")")

1

kishikawakatsumi

extension String.StringInterpolation { mutating func appendInterpolation(_ val: Any?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = nil print("The value is: \(value, default: "<nil>")")

Version:

swift-DEVELOPMENT-SNAPSHOT-2018-12-15-a

Output:

The value is: <nil>

Error:

nil を渡さなければ T でも動く

9:05 PM

@swiftbot --version latest

extension String.StringInterpolation { mutating func appendInterpolation<T>(_ val: T?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = 99 print("The value is: \(value, default: "<nil>")")

1

kishikawakatsumi

extension String.StringInterpolation { mutating func appendInterpolation<T>(_ val: T?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = 99 print("The value is: \(value, default: "<nil>")")

Version:

swift-DEVELOPMENT-SNAPSHOT-2018-12-15-a

Output:

The value is: 99

Error:

Raw Stringはダブルクオートだけ、は無理かな？

9:16 PM

@swiftbot --version latest import Foundation print(#"""#) print(#""""#)

1

kishikawakatsumi

import Foundation print(#"""#) print(#""""#)

Version:

swift-DEVELOPMENT-SNAPSHOT-2018-12-15-a

Output:

Error:

/usercode/main.swift:2:11: error: multi-line string literal content must begin on a new line print(#"""#) ^ /usercode/main.swift:3:9: error: multi-line string literal closing delimiter must begin on a new line print(#""""#) ^

バグに思える。>ダブルクオートだけ (edited)

厳密には2連続のダブルクォートで始まる文字列が複数行リテラルの開始と解釈されてしまう、のかな。

自分で直せそうな気がしないでもない。

@swift-5.0.3 @swift-main

extension String.StringInterpolation { mutating func appendInterpolation<T>(_ val: T?, default defaultValue: String) { if let val = val { appendInterpolation(val) } else { defaultValue.write(to: &self) } } } let value: Int? = nil print("The value is: \(value, default: "<nil>")")

exit status: 11 with stderr:

Stack dump: 0. Program arguments: /usr/bin/swift -frontend -interpret - -disable-objc-interop -I /Libraries/.build/x86_64-unknown-linux/debug -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOZlib/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOHTTPParser/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOSHA1/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOAtomics/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIODarwin/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOLinux/include -module-cache-path /Libraries/.build/x86_64-unknown-linux/debug/ModuleCache -D DEBUG -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOZlib.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOHTTPParser.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOSHA1.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOAtomics.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIODarwin.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOLinux.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/checkouts/swift-nio-zlib-support-c4b8a10c/module.modulemap -module-name main -lLibraries #0 0x000000000460a444 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x460a444) #1 0x0000000004608210 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4608210) #2 0x000000000460a5f2 SignalHandler(int) (/usr/bin/swift+0x460a5f2) #3 0x00007f5f29f4b390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f5f2a37a4e8 #5 0x00007f5f2a37a343 #6 0x00007f5f2a37a13a #7 0x0000000000ceca9e llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) (/usr/bin/swift+0xceca9e) #8 0x0000000000cf0cb2 llv

stderr.txt

https://ptpb.pw/5BES.txt/text

exit status: 11 with stderr:

Stack dump: 0. Program arguments: /usr/bin/swift -frontend -interpret - -disable-objc-interop -I /Libraries/.build/x86_64-unknown-linux/debug -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOZlib/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOHTTPParser/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOSHA1/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOAtomics/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIODarwin/include -I /Libraries/.build/checkouts/swift-nio-b68c973e/Sources/CNIOLinux/include -module-cache-path /Libraries/.build/x86_64-unknown-linux/debug/ModuleCache -D DEBUG -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOZlib.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOHTTPParser.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOSHA1.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOAtomics.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIODarwin.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/x86_64-unknown-linux/debug/CNIOLinux.build/module.modulemap -Xcc -fmodule-map-file=/Libraries/.build/checkouts/swift-nio-zlib-support-c4b8a10c/module.modulemap -module-name main -lLibraries #0 0x000000000460a1c4 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x460a1c4) #1 0x0000000004607f90 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4607f90) #2 0x000000000460a372 SignalHandler(int) (/usr/bin/swift+0x460a372) #3 0x00007f05541f1390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007f05546204e8 #5 0x00007f0554620343 #6 0x00007f055462013a #7 0x0000000000cec7de llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) (/usr/bin/swift+0xcec7de) #8 0x0000000000cf09f2 llv

stderr.txt

https://ptpb.pw/20-f.txt/text

Linux のバグなのかなー手元のmacだと動く。

https://github.com/apple/swift/pull/21378 お知らせ：import したモジュールに標準ライブラリと同名のものがあった場合、常に明示的に import したほうが優先されるようになります。

[5.0] [Name lookup] Enable shadowing for type lookup and of the Sw...

Tweak the shadowing rules in two ways: For unqualified type lookup, apply shadowing rules. Without this, we would always get an ambiguity if there were two types with the same name, so this should...

11:46 PM

これによって Swift.Result より他の Result が優先されるのでソース互換が保たれます。

1

4

11:48 PM

Encodable と Decodable 導入されたときにこのルールになってればいろいろ楽だったのになー。。。

これはわかりやすいルールでいいですね。

そうか、ユーザ型と同名のstd型、いまさらあんまり無さそうだけど、Result は盛大にかぶりますもんね

Result.Resultが出来ないからというのも

そっちはそっちで言語に改修が必要そう。

1:44 AM

@modulename Result.Result ResultモジュールのResult型 Result.Result Result型のinner型のResult型みたいな

SR-5719: In Swift 5 mode, @autoclosure parameters can no longer be forwarded to @autoclosure arguments in another function call. Instead, you must explicitly call the function value with (); the call itself is wrapped inside an implicit closure, guaranteeing the same behavior as in Swift 4 mode. Example: func foo(_ fn: @autoclosure () -> Int) {} func bar(_ fn: @autoclosure () -> Int) { foo(fn) // Incorrect, `fn` can't be forwarded and has to be called foo(fn()) // Ok }

2:02 AM

https://github.com/slavapestov/swift/blob/ccdcfa605d28d3fe7466f92d3b48c90f4ec644ae/CHANGELOG.md

slavapestov/swift

The Swift Programming Language. Contribute to slavapestov/swift development by creating an account on GitHub.

2:02 AM

@norio_nomura が前話してたautoclosureの仕様変更、Swift5向けの変更だってハッキリ書かれてた (edited)

1

same behavior って書かれてるけど、クロージャのラップ回数が一個増えてパフォーマンスが低下してるような気がする

そんな話を前にここでしてた (edited)

4:12 AM

これってasyncやらの絡みでそうなるんですかね

https://bugs.swift.org/browse/SR-5719

4:12 AM

リンクされてるSRを見るとそうでもない

4:13 AM

func autoclosureFoo(_ c: @autoclosure () -> Int) { print(c()) } func autoclosureBar(_ c: @autoclosure () -> Int) { autoclosureFoo(c) // <-- This one here autoclosureFoo(c()) } func baz(_ c: () -> Int) { autoclosureFoo(c) // does not work as expected } autoclosureBar(42)

4:14 AM

これに一貫性が無いって話で

なるほど

https://github.com/apple/swift/pull/20152

[AST/Sema] Associate @autoclosure flag with parameter declaratio...

These changes aim to: Move @autoclosure flag from function type to parameter declaration Serialize @autoclosure as part of the parameter declaration Convert it from being a type attribute to be d...

4:17 AM

これで対応されてるんだけど、ここの文言を見る限り

4:17 AM

@autoclosure ってもともとの仕様だと型なんだよね

4:17 AM

autoclosureにautoclosureはクロージャ型のまま引き渡せるのに対して、 autoclosureに普通のクロージャは渡せないから、

4:17 AM

型システム的に取り扱いが区別されてる

4:18 AM

で、これがパラメータ属性に変更されて、型としての扱いは普通のクロージャになった

4:19 AM

から、今後はフォワードさせたい場合は () をつけましょうね、ということになる

@rintaro Linux のバグなのかなー手元のmacだと動く。 これ、LinuxでREPLの標準入力へそのソースコードを渡した時だけクラッシュする様です。

9:44 AM

LinuxのインタラクティブなREPLで入力してもクラッシュしません。

あいや、正確にはLinuxのREPLへソースコードをファイル（標準入力含む）で渡した時にクラッシュ、だ。

10:15 AM

swiftcでexecutableを生成して実行してもクラッシュしない。 (edited)

初めて質問させてもらいます！ライブラリのTabPageViewControllerを使っているのでが、このライブラリを使ってツイッターのプロフィール画面のような上にプロフィール部分があり、下にスクロールできるViewがあるもの作ることできますでしょうか？どうすればTab部分の上にViewを配置できるのかが分からず悩んでいます。 https://github.com/EndouMari/TabPageViewController

EndouMari/TabPageViewController

Paging view controller and scroll tab view. Contribute to EndouMari/TabPageViewController development by creating an account on GitHub.

2:47 PM

またできればツイッターアプリのような動きでスクロールした際にTab上部のみ隠れるようにできれば嬉しいです。

上記解決しました

Swift AST Explorerを最新のSwiftSyntaxを使うように更新しました。以前は独立したプロジェクトになる前のだいぶ古いものを参照していた（Linuxビルドも公式にはサポートされてなかった）から最新の結果が返るようになったはず！ https://swift-ast-explorer.kishikawakatsumi.com/

1

https://github.com/kishikawakatsumi/swift-magic ファイル種別を判定するライブラリ、libmagic のSwiftラッパーライブラリを作りました。

kishikawakatsumi/swift-magic

A Swift wrapper for libmagic. Contribute to kishikawakatsumi/swift-magic development by creating an account on GitHub.

SwiftのDictionaryのキーにプロトコル使えますか？もしくはそういう場面に出くわしたときの代替案はありますか？ユースケースとしては、DictionaryLiteral の pairs 変数のキーに ExpressionType を入れたいです。試した方法は下記のリンクとほぼ同じです。 ExpressionType を内部で持つ AnyLiteral みたいなstructを定義する以外の方法が思いつかない... https://forums.developer.apple.com/message/9175#9175 ソースコードの例です。インタープリタを実装していて、Dictionaryリテラルを追加しようとしています。

enum TokenKind: Int, Hashable { case integer case string case dictionary } protocol ExpressionType { var token: TokenKind { get } } struct IntegerLiteral { let value: Int64 } extension IntegerLiteral: ExpressionType { var token: TokenKind { return .integer } } struct StringLiteral { let value: String } extension StringLiteral: ExpressionType { var token: TokenKind { return .string } } struct DictionaryLiteral { let pairs: [ExpressionType: ExpressionType] } extension DictionaryLiteral: ExpressionType { var token: TokenKind { return .dictionary } }

(edited)

Can you create a Set of a single protocol? |Apple Developer Forums

I'm wondering, is it even possible to create a Set in Swift whose members are guaranteed only to share conformance to a Protocol? My initial attempt

DictionaryLiteralのpairsをDictionary<ExpressionType, ExpressionType>ではなくKeyValuePairs<ExpressionType, ExpressionType>にするとか…

そうか、KeyValuePairs はHashable準拠してなくても良いのか。まずはその方法で実装してみます、ありがとうございます！ DictionaryLiteral は名前かぶってるのでリネームしたほうが良いな...

この、ExpressionTypeをキーにしたいんですよね、Hashable準拠にして実装はAnyHashableにしておくとかで誤魔化せないでしょうか？

2:21 PM

HasherにObjectIdentifer(Self.self)を食べさせれば型ごとにもユニークになるはず

そう、AnyHashableは最初にパッとやってみた。どっちのほうが良いか実装して今比べてます。

普通は書いた順に評価されることを保証すると思うので、 { "a": foo(), "b": bar() } みたいなときに foo(), bar() の順で実行するためには Dictionary ではなく、 KeyValuePairs や Array<(key: ExpressionType, value: ExpressionType)> のほうが良いと思います。 (edited)

確かにその方が良いですね。修正してみます！

Swift 5のString.UTF8View.withContiguousStorageIfAvailable(_:)、macOSだとStringの作り方によって使えたり使えなかったりする。

12:05 PM

$ xcrun --toolchain org.swift.5020181228a swift swift_oss_helper command enabled. Welcome to Apple Swift version 5.0-dev (LLVM c351ac7354, Clang aadec4ff83, Swift 5cfc2e7ba9). Type :help for assistance. 1> import Foundation 2. let url = URL(fileURLWithPath: "/etc/passwd") 3. let a = String(data: try Data(contentsOf: url), encoding: .utf8)?.utf8.withContiguousStorageIfAvailable { $0.count } 4. let b = try String(contentsOf: url, encoding: .utf8).utf8.withContiguousStorageIfAvailable { $0.count } url: URL = "file:///etc/passwd" a: Int? = 6804 b: Int? = nil 5>

(edited)

@swift-4.2.4

import Foundation let formatter = DateFormatter() formatter.dateFormat = DateFormatter.dateFormat(fromTemplate: "YYYY-MM-dd", options: 0, locale: Locale(identifier: "ja_JP")) print(formatter.string(from: Date()))

2019/12/31

もうすぐ2020年ですね・・・・・？どういう事なんだろうこれ (edited)

8:33 PM

タイムゾーン周りで指定ミスっているなら9時間前後ズレるならわかるんだけど、１年近くズレる

8:33 PM

ちなみに29日だと大丈夫だった。時間周りで知らない仕様があるのか、バグなのかどっちなんだろ

@swift-4.2.4

import Foundation let formatter = DateFormatter() formatter.dateFormat = DateFormatter.dateFormat(fromTemplate: "yyyy-MM-dd", options: 0, locale: Locale(identifier: "ja_JP")) print(formatter.string(from: Date()))

2018/12/31

大文字のYと小文字のyは意味が違ったと思う

ある年における「最初の木曜日を含む週が、その年の第1週である」というルールで年(西暦)を出力。

8:34 PM

知らなかった・・・

8:34 PM

@omochimetaru ありがとうございます…！

つまりどういうことだってばよ

2019年の最初の木曜日は1/3なので、その週である12/31は2019年となる、ということのはず。

8:36 PM

12/31は2019年の第1週と扱われる。

ああなるほど！日本語の意味がわかりましたｗ

2019年はYYYYだと12/31(30?)から始まって12/29で終わるみたいな感じなんですね

なんかこれ踏んだ事があって、年末の数日間だけバグが出た事があって、それで覚えていた。

使ったことないけど、週番号を表示するカレンダーを作る場合には有用なんだろうか。

その日付がどの週に所属するか、を求めるときに使えるんですかね。

ちょうど最近その記事見ました https://ericasadun.com/2018/12/25/iso-8601-yyyy-yyyy-and-why-your-year-may-be-wrong/

erica

ISO-8601, YYYY, yyyy, and why your year may be wrong

The end of the year is rolling around and it’s time to remind everyone about that yyyy works the way you think it does and YYYY does not. Here’s a quick example to start: Just because y…

https://forums.swift.org/t/pitch-reducing-a-sequence-onto-its-own-elements-to-simplify-code-and-reduce-errors/19243

Pitch: Reducing a sequence onto its own elements to simplify code ...

Pitch: Introducing fold to reduce a sequence onto its own elements and eliminate common errors Work in progress is at this gist. Please refer to the gist for the latest updates as this post and thread may be out of date. Draft follows. Constructive feedback is greatly appre...

4:32 AM

Erica SadunさんのPitchで、クロージャしか取らないreduceの提案。

4:32 AM

足し算なら0, 掛け算なら1, みたいな初期値の指定が無いやつ。配列が空の場合は nil になる。 (edited)

4:34 AM

既存のreduceにはinout版のオーバーロードがあるけど、そっちはreduce(into:) { ... } でラベルがあったので良かったけど、これにも同じものを用意しようとするとダメそうなのが気になる。

4:35 AM

この提案自体ではそれに触れてないけど、reduce(into:)の必要性の議論はそのままinitialValue無しのreduceにも適用できるはず

compactMapValuesが壊れるw

既存のinitialValue付きを削除するわけじゃないから壊れることはない？

これは結構無理がある気がする、処理の初期値として何が正しいかをコンパイラが理解するのは至難じゃないの

初期値は array[0] と array[1] だよ。

なるほど？

7:18 AM

そういうことか

初期値が array[0] で、最初に呼ばれるクロージャが array[0] と array[1] のペア。

7:18 AM

要素が1個ならクロージャを呼ばずにarray[0]を返す要素が0個ならnil

7:18 AM

reduce<R>のRの型がArray.Elementに固定されている。

reduceはRの型が変動するイメージが結構強い、固定されるなら名前変えた方がいいのではみたいな

7:19 AM

議論すでにありそう、読んでみるか

[1, 2, 3] の合計を求めたいときにわざわざ 0 + 1 + 2+ 3 って式を計算させるのはナンセンスだし、欲しい。

名前はfoldの方が良さそう

7:20 AM

すでに書かれてるな

https://twitter.com/omochimetaru/status/1082506906495643648

Use Swift.Result instead of our Result if compiler(>=5) by n...

Swift forumにpitch投稿した https://t.co/GZwobJhVap

InputStream(Swift)/NSInputStream class has wasteful complicated functional. Its not useful and hard to understand.

^ なるほど。

エラーハンドリングもstreamErrorプロパティを逐次確認するという謎仕様なのでSwift的じゃないですし。そのへんは好みと言われたら終わりですが、ただ、シークできないという点は機能として致命的に思います。

5:30 AM

(1)は、stdlibでは今の所ファイルシステムの面倒を見てるやつらが無いし、Foundationは歴史の塊だから、そのへんは今の所スコープじゃないと言われそうですが、 (2)と(3)はもうちょっと整備されてほしいなあ。

antitypical/Resultを使ってるコードを、最小限の変更でSwift.Resultに対応させられるPRを書いた。 https://github.com/antitypical/Result/pull/280

#if swift(>=4.2) #if compiler(>=5) なるほど！ｗ

1:50 AM

compilerなんてありましたっけ。

とりあえずCommandantとかは、変更なしでantitypical/ResultをバージョンアップするだけでSwift.Resultを使う様になる事を確認。 (edited)

1:51 AM

Compiler Version Directive https://github.com/apple/swift-evolution/blob/master/proposals/0212-compiler-version-directive.md (edited)

Use Swift.Result instead of our Result if compiler(>=5) by n...

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

おお

1:52 AM

コンパイラのバージョンがswiftで、コンパイラが動作してるswift互換モードのバージョンがcompilerなのか。 (edited)

1:52 AM

たしかにそれがないとどうしようもないな。

#if swift(…)はlanguage versionで、コンパイラに渡す-swift-versionの影響を受ける。

あ、逆か

#if compiler(…)は-swift-versionの影響を受けません。

Semantic Versioningの観点からSwift 5オンリーにした方が良いと言われたのだけど、そうなのだろうか。 https://github.com/antitypical/Result/pull/280#discussion_r246621449

結局そのままマージさせてもらった。

https://forums.swift.org/t/why-doesnt-this-do-what-i-thought-it-would/19407 @swiftbot

struct HaveResult { var resultCode = 0 func returnResultCode(_ value: Int) -> Int { return resultCode } } func testA() { var r = HaveResult() print(r.returnResultCode(changeResult(r: &r))) } func testA_variant() { var r = HaveResult() let r2 = r print(r2.returnResultCode(changeResult(r: &r))) } func testB() { var r = HaveResult() let x = changeResult(r: &r) print(r.returnResultCode(x)) } func changeResult(r: inout HaveResult) -> Int { r.resultCode = 1 return 0 } testA() testA_variant() testB()

Why doesn't this do what I thought it would?

struct OpentimeErrorThrower { var resultCode = 0 var details = "" func returnOrThrow(_ value: T) throws -> T { if resultCode == 0 { return value } throw Error("oops") } } func doesntWorkCorrectly() throws -> Int { var et = ...

1

t.ae

struct HaveResult { var resultCode = 0 func returnResultCode(_ value: Int) -> Int { return resultCode } } func testA() { var r = HaveResult() print(r.returnResultCode(changeResult(r: &r))) } func testA_variant() { var r = HaveResult() let r2 = r print(r2.returnResultCode(changeResult(r: &r))) } func testB() { var r = HaveResult() let x = changeResult(r: &r) print(r.returnResultCode(x)) } func changeResult(r: inout HaveResult) -> Int { r.resultCode = 1 return 0 } testA() testA_variant() testB()

Version:

swift-4.2.1-RELEASE

Output:

0 0 1

Error:

これってtest_AはtestA_variantのような動作になってるってことでいいんでしょうか？ (edited)

パット見inoutの書き戻しと例外での脱出のタイミングの話？ (edited)

いやCoWがわかりにくいところで働いてるんじゃないかって思っています

ちゃんと読んでくる

元のコードがわかりにくかった&そのままじゃ実行できなかったので↑のコードは多少シンプルに変えています。 (edited)

例外は関係ないのか。

r.returnResultCodeのrがCoWで元の値のままのこっていてtestA_variantのようになってるんじゃないかと思っています。

まず、Copy on writeは関係ないよ

2:47 AM

Copy on writeはstructにはついてない

2:47 AM

ArrayやDictionaryなどで明示的なコードとして書かれてるだけ

Copy on writeという語の僕の頭の中の定義が間違ってそうですね……

Copy on writeについてはこれを読むとわかる https://qiita.com/omochimetaru/items/f32d81eaa4e9750293cd

Swift での Copy on Write の実装方法の解説 - Qiita

Swift の Array や Dictionary は Copy on Write になっていてとても使いやすいです。この記事では、そのような Copy on Write の実装方法を解説します。

CoW の動作

Copy ...

単に値型とこんがらがってただけか。

単純にレシーバと引数の評価順の問題な気がする

2:51 AM

r.returnResultCode(changeResult(r: &r)) ここで &r への結果の書き戻しって、changeResultのcallの終わった後だと思うけど

2:51 AM

第一引数changeResultの評価と、レシーバrの評価って、レシーバが先なんじゃないかな

そうですね。僕もそういう認識でした。

define hidden swiftcc void @"$S1a5testAyyF"() #0 { entry: %0 = alloca %T1a10HaveResultV, align 8 %1 = bitcast %T1a10HaveResultV* %0 to %swift.opaque** store %swift.opaque* null, %swift.opaque** %1, align 8 %2 = bitcast %T1a10HaveResultV* %0 to i8* call void @llvm.lifetime.start.p0i8(i64 8, i8* %2) %3 = call swiftcc i64 @"$S1a10HaveResultVACycfC"() %.resultCode = getelementptr inbounds %T1a10HaveResultV, %T1a10HaveResultV* %0, i32 0, i32 0 %.resultCode._value = getelementptr inbounds %TSi, %TSi* %.resultCode, i32 0, i32 0 store i64 %3, i64* %.resultCode._value, align 8 %4 = call swiftcc { %swift.bridge*, i8* } @"$Ss27_allocateUninitializedArrayySayxG_BptBwlFyp_Tg5"(i64 1) %5 = extractvalue { %swift.bridge*, i8* } %4, 0 %6 = extractvalue { %swift.bridge*, i8* } %4, 1 %7 = call %swift.bridge* @swift_bridgeObjectRetain(%swift.bridge* %5) #2 call void @swift_bridgeObjectRelease(%swift.bridge* %5) #2 %8 = bitcast i8* %6 to %Any* %9 = call swiftcc i64 @"$S1a12changeResult1rSiAA04HaveB0Vz_tF"(%T1a10HaveResultV* nocapture dereferenceable(8) %0)

2:53 AM

 %10 = call swiftcc i64 @"$S1a10HaveResultV06returnB4CodeyS2iF"(i64 %9, i64 %3) %11 = getelementptr inbounds %Any, %Any* %8, i32 0, i32 1 store %swift.type* @"$SSiN", %swift.type** %11, align 8 %12 = getelementptr inbounds %Any, %Any* %8, i32 0, i32 0 %13 = getelementptr inbounds %Any, %Any* %8, i32 0, i32 0 %14 = bitcast [24 x i8]* %13 to %TSi* %._value = getelementptr inbounds %TSi, %TSi* %14, i32 0, i32 0 store i64 %10, i64* %._value, align 8 %15 = call swiftcc { %swift.bridge*, i64 } @"$Ss5print_9separator10terminatoryypd_S2StFfA0_"() %16 = extractvalue { %swift.bridge*, i64 } %15, 0 %17 = extractvalue { %swift.bridge*, i64 } %15, 1 %18 = call swiftcc { %swift.bridge*, i64 } @"$Ss5print_9separator10terminatoryypd_S2StFfA1_"() %19 = extractvalue { %swift.bridge*, i64 } %18, 0 %20 = extractvalue { %swift.bridge*, i64 } %18, 1 call swiftcc void @"$Ss5print_9separator10terminatoryypd_S2StF"(%swift.bridge* %5, %swift.bridge* %16, i64 %17, %swift.bridge* %19, i64 %20) call void @swift_bridgeObjectRelease(%swift.bridge* %19) #2 call void @swift_bridgeObjectRelease(%swift.bridge* %16) #2 call void @swift_bridgeObjectRelease(%swift.bridge* %5) #2 %21 = bitcast %T1a10HaveResultV* %0 to i8* call void @llvm.lifetime.end.p0i8(i64 8, i8* %21) ret void }

真のtestA_variantはこうか。 func testA_variant() { var r = HaveResult() let f = r.returnResultCode print(f(changeResult(r: &r))) }

 %9 = call swiftcc i64 @"$S1a12changeResult1rSiAA04HaveB0Vz_tF"(%T1a10HaveResultV* nocapture dereferenceable(8) %0) %10 = call swiftcc i64 @"$S1a10HaveResultV06returnB4CodeyS2iF"(i64 %9, i64 %3)

(edited)

2:59 AM

なんか若干怪しいな

2:59 AM

%0にメモリ確保して、 initの返り値が%3に入って、 %3から%0 に代入して、っていう形で初期化しているけど、 %3をそのまま使ってるな。

%3 は変更される前の値だから、予想通りじゃないですか？

3:01 AM

第一引数changeResultの評価と、レシーバrの評価って、レシーバが先

ここで%3が来る理由がわからなくて。 rの値を%0から読み出す処理じゃなくてよいのかな。

3:02 AM

%3はあくまでinitの返り値であって、rを表してるわけじゃないというか・・・

3:03 AM

挙動は予想通りだけど、このIRになった生成過程がイメージと一致してなかった。

HaveResult 全体が i64 に lowered されてるからわかりにくいのかな。

それもありますね。

HaveResult.returnResultCode(r)(changeResult(r: &r)) と同等っていうのは説得力ある説明だな。 (edited)

define hidden swiftcc i64 @"$S1a10HaveResultV06returnB4CodeyS2iF"(i64, i64) #0 { ↑ returnResultCode が returnB4Code にsubstされてる・・・

3:09 AM

これどうなってんだ・・・

@rintaro taylorswiftさんが良い説明してくれましたね。僕も上で話した内容で理解がまとまりました。ありがとうございます。

置換 A = Have, B = Result だ

3:13 AM

そういうことか、 10HaveResult のときに HaveResultが辞書入りするんじゃなくて、 Have / Result にワード分割するのか

3:14 AM

クラス名とか CamelCase になりがちだからそうやっとくと便利みたいなやつか・・・

3:14 AM

さっきのやつだけど、

3:15 AM

本来structのメソッドレシーバはポインタ渡しだから

3:15 AM

この挙動は起きないはずで

3:15 AM

サイズが小さい時にレシーバを引数に並べちゃう値型の最適化が

3:15 AM

あったからこの挙動なんじゃないか

structのサイズが大きいと挙動が異なる可能性がある？

define hidden swiftcc i64 @"$S1a5testASiyF"() #0 { entry: %0 = alloca %T1a10HaveResultV, align 8 %1 = alloca %T1a10HaveResultV, align 8 %2 = bitcast %T1a10HaveResultV* %1 to %swift.opaque** store %swift.opaque* null, %swift.opaque** %2, align 8 %3 = bitcast %T1a10HaveResultV* %0 to i8* call void @llvm.lifetime.start.p0i8(i64 72, i8* %3) %4 = bitcast %T1a10HaveResultV* %1 to i8* call void @llvm.lifetime.start.p0i8(i64 72, i8* %4) call swiftcc void @"$S1a10HaveResultVACycfC"(%T1a10HaveResultV* noalias nocapture sret %0) %5 = bitcast %T1a10HaveResultV* %1 to i8* %6 = bitcast %T1a10HaveResultV* %0 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %5, i8* %6, i64 72, i32 8, i1 false) %7 = call swiftcc i64 @"$S1a12changeResult1rSiAA04HaveB0Vz_tF"(%T1a10HaveResultV* nocapture dereferenceable(72) %1) %8 = call swiftcc i64 @"$S1a10HaveResultV16returnAesultCodeyS2iF"(i64 %7, %T1a10HaveResultV* noalias nocapture swiftself dereferenceable(72) %0) %9 = bitcast %T1a10HaveResultV* %1 to i8* call void @llvm.lifetime.end.p0i8(i64 72, i8* %9) %10 = bitcast %T1a10HaveResultV* %0 to i8* call void @llvm.lifetime.end.p0i8(i64 72, i8* %10) ret i64 %8 }

3:19 AM

でかくしたらポインタになったけど、そしたらchangeResultにわたすHaveResultとreturnResultCodeを呼び出すHaveResultが別のオブジェクトになって、結果は同じく0だった。

@swiftbot

struct HaveResult { var resultCode = 0 mutating func returnResultCode(_ value: Int) -> Int { return resultCode } } public func testA() { var r = HaveResult() print(r.returnResultCode(changeResult(r: &r))) } func testA_variant() { var r = HaveResult() var r2 = r print(r2.returnResultCode(changeResult(r: &r))) } func testB() { var r = HaveResult() var x = changeResult(r: &r) print(r.returnResultCode(x)) } func changeResult(r: inout HaveResult) -> Int { r.resultCode = 1 return 0 } testA() testA_variant() testB()

1

rintaro

struct HaveResult { var resultCode = 0 mutating func returnResultCode(_ value: Int) -> Int { return resultCode } } public func testA() { var r = HaveResult() print(r.returnResultCode(changeResult(r: &r))) } func testA_variant() { var r = HaveResult() var r2 = r print(r2.returnResultCode(changeResult(r: &r))) } func testB() { var r = HaveResult() var x = changeResult(r: &r) print(r.returnResultCode(x)) } func changeResult(r: inout HaveResult) -> Int { r.resultCode = 1 return 0 } testA() testA_variant() testB()

Version:

swift-4.2.1-RELEASE

Output:

1 0 1

Error:

/usercode/main.swift:22:9: warning: variable 'x' was never mutated; consider changing to 'let' constant var x = changeResult(r: &r) ~~~ ^ let

mutating にしたら結果が変わると。

ウオｗ

これは Exclusivity でエラーになるべきなのかな？

&rのアクセスはchangeResultの評価中だけで、changeResultの呼び出し後にメソッド呼び出しだから、セーフな気がする

3:24 AM

どっちかがバグな気がする・・・

このスレッドに再現コード張って、意見聞いてみますね。

あざます

3:30 AM

struct HaveResult { var resultCode = 0 var padding: (Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64) = (0, 0, 0, 0, 0, 0, 0, 0) func returnAesultCode(_ value: Int) -> Int { return resultCode } } func testA() -> Int { var r = HaveResult() let x = r.returnAesultCode(changeResult(r: &r)) return x } func changeResult(r: inout HaveResult) -> Int { r.resultCode = 1 return 0 } print(testA())

3:30 AM

↑selfがポインタ渡しになるバージョン。でも挙動はもとと同じ。

3:31 AM

(print文があるとIRがしんどいのでちょっと改変してます

元の質問に合わせると、let x = r.returnAesultCode(changeResult(r: &r.resultCode)) で func changeResult(r: inout Int) -> Int { r = 1 return 0 } じゃないかな。

3:43 AM

まあ、結果は同じだけど。

ああ、ほんとですね。微妙に間違ってました。

protocol P { func hoge(_ a: Int) func hoge(_ a: String) } protocol IntOrString {} extension Int : IntOrString {} extension String : IntOrString {} struct S : P { func hoge<X>(_ a: X) { print("X") } } extension P { func hoge(_ a: Int) { print("default Int") } } let s = S() s.hoge(1) // default Int s.hoge("a") // X

10:08 AM

Generic実装でのプロトコルのオーバーロード一括コンフォームは、

10:08 AM

デフォルト実装よりは優先度が低いのね。

そうそう

ちょっと変な感じがする。

10:26 AM

通常のコンフォームを満たすときにはPWTのエントリをGeneric版のパラメータを埋めたthunkでフィルしてるはずで、

確かに言われてみれば

その発想から行くとデフォルト実装があろうがそれよりも優先したい

https://github.com/mxcl/swift-sh

mxcl/swift-sh

Easily import third-party dependencies in your Swift scripts - mxcl/swift-sh

3:02 AM

#!/usr/bin/swift sh import PromiseKit // @mxcl ~> 6.5 firstly { after(.seconds(2)) }.then { after(.milliseconds(500)) }.done { print("notice: two and a half seconds elapsed") exit(0) } RunLoop.main.run()

3:02 AM

↑こんな感じでSwiftをスクリプト的に使えるやつだそうです、importのところの記法がオシャレだなと思った。

リポジトリとframeworkの名前が一致してない場合はどうなるんだろ

5:54 AM

import BumbleButt // https://example.com/bb.git ~> 9 これか

5:54 AM

オシャンだ

@xxx が xxx/xxx のsugarみたいね import Floobles // mxcl/Flub == master import BumbleButt // https://example.com/bb.git ~> 9 (edited)

@swift-4.2.4 @swift-5.0.3 @swift-main

protocol P1 { associatedtype X } protocol P2 {} struct Box<T1, T2: P1> { struct X {} } extension Box.X: P2 where T2.X == String {} struct S: P1 { typealias X = String } _ = Box<Int, S>.X.self is P2.Type

(edited)

stderr:<stdin>:16:24: warning: 'is' test is always true _ = Box<Int, S>.X.self is P2.Type ^ (edited)

exit status: 11 with stderr:

<stdin>:16:24: warning: 'is' test is always true _ = Box<Int, S>.X.self is P2.Type ^ #0 0x000000000410ac94 PrintStackTraceSignalHandler(void*) (/usr/bin/swift+0x410ac94) #1 0x0000000004108b22 llvm::sys::RunSignalHandlers() (/usr/bin/swift+0x4108b22) #2 0x000000000410ae42 SignalHandler(int) (/usr/bin/swift+0x410ae42) #3 0x00007fbd9ed2d390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x00007fbd9aa60210 swift::TargetMetadata<swift::InProcess>::getTypeContextDescriptor() const (/usr/lib/swift/linux/libswiftCore.so+0x3c4210) #5 0x00007fbd9aa798cb searchInConformanceCache(swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptor<swift::InProcess> const*) (/usr/lib/swift/linux/libswiftCore.so+0x3dd8cb) #6 0x00007fbd9aa79343 swift_conformsToProtocolImpl(swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptor<swift::InProcess> const*) (/usr/lib/swift/linux/libswiftCore.so+0x3dd343) #7 0x00007fbd9aa78aa5 swift::_checkGenericRequirements(llvm::ArrayRef<swift::TargetGenericRequirementDescriptor<swift::InProcess> >, std::vector<void const*, std::allocator<void const*> >&, llvm::function_ref<swift::TargetMetadata<swift::InProcess> const* (unsigned int)>, llvm::function_ref<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>) (/usr/lib/swift/linux/libswiftCore.so+0x3dcaa5) #8 0x00007fbd9aa78905 swift::TargetProtocolConformanceDescriptor<swift::InProcess>::getWitnessTable(swift::TargetMetadata<swift::InProcess> const*) const (/usr/lib/swift/linux/libswiftCore.so+0x3dc905) #9 0x00007fbd9aa79a9f swift_conformsToProtocolImpl(swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptor<swift::InProcess> const*)::$_3::operator()(swift::TargetProtocolConformanceDescriptor<swift::InProcess> const&, swift::TargetMetadata<swift::InProcess> const*) const (/usr/lib/swift/linux/libswiftCore.so+0x3dda9f) #10 0x00007fbd9aa79637 swi

(edited)

stderr.txt

https://ptpb.pw/rMAi.txt/text

stderr:<stdin>:16:24: warning: 'is' test is always true _ = Box<Int, S>.X.self is P2.Type ^ (edited)

お、もう直ってるのか〜

3:07 PM

struct Box<T1, T2: P1>: P1 { struct X {} } extension Box.X: P2 where T2.X == String {} ここが肝で struct Box<T1: P1, T2> だとクラッシュしない。

@swift-4.2.4 @swift-5.0.3 @swift-main

let str = "\u{0336}\u{0344}\u{0357}\u{0343}\u{0314}\u{0351}\u{0340}\u{0300}\u{0340}\u{0360}\u{0314}\u{0357}\u{0315}\u{0301}\u{0344}a" let set = Set([str])

no output

exit status: 4 with stderr:

Fatal error: Output buffer was not big enough, this should not happen: file /home/buildnode/jenkins/workspace/oss-swift-4.2-package-linux-ubuntu-16_04/swift/stdlib/public/core/NormalizedCodeUnitIterator.swift, line 177 Current stack trace: 0 libswiftCore.so 0x00007f8205354fa0 _swift_stdlib_reportFatalErrorInFile + 215 1 libswiftCore.so 0x00007f82050ad5c1 <unavailable> + 1504705 2 libswiftCore.so 0x00007f82052ea0c2 <unavailable> + 3850434 3 libswiftCore.so 0x00007f82052ec3b9 <unavailable> + 3859385 4 libswiftCore.so 0x00007f82050acd0a <unavailable> + 1502474 5 libswiftCore.so 0x00007f82052ea008 <unavailable> + 3850248 6 libswiftCore.so 0x00007f82050acd0a <unavailable> + 1502474 7 libswiftCore.so 0x00007f8205246a28 <unavailable> + 3181096 8 libswiftCore.so 0x00007f8205269bfa <unavailable> + 3324922 9 libswiftCore.so 0x00007f8205269c36 <unavailable> + 3324982 10 libswiftCore.so 0x00007f8205269e6b <unavailable> + 3325547 11 libswiftCore.so 0x00007f82051e7870 _StringGuts.hash(into:) + 9 12 libswiftCore.so 0x00007f82051e79c1 <unavailable> + 2791873 13 libswiftCore.so 0x00007f82051d2470 _VariantSetBuffer.nativeInsert(_:forKey:) + 194 14 libswiftCore.so 0x00007f82051c8f70 Set.init<A>(_:) + 796 16 swift 0x0000000001043efe <unavailable> + 12861182 17 swift 0x0000000001048022 <unavailable> + 12877858 18 swift 0x00000000004f8b42 <unavailable> + 1018690 19 swift 0x00000000004df0bb <unavailable> + 913595 20 swift 0x00000000004da3f0 <unavailable> + 893936 21 swift

stderr.txt

https://ptpb.pw/paxS.txt/text

https://twitter.com/niw/status/1085714047226458119

Yoshimasa Niwa (@niw)

For those who’re interested in what Swift language bug is, which is not fixed yet and still in wild as of current released version of Swift, and will not be fixed until 5.0 release. https://t.co/9BegKKLxy6

こないだ当たった問題なんですけど、これわかる方いらっしゃいますか？

extension String { init(decimalStyle int: Int) { let formatter = NumberFormatter() formatter.numberStyle = .decimal self = formatter.string(from: int as NSNumber)! } } let ids = [89902,100238,123289] //ids.map(String.init).joined(separator: ",") // <- String.init(decimalStyle:)が呼ばれてしまう。String.init(decimalStyle:)を指定しないと呼ばれるべきでないのでは？ ids.map { String($0) }.joined(separator: ",") // <- こうすれば、回避できる

3:04 AM

ちなみに同じ型の引数を持つやつを追加するとどうなるかなと思って以下を追加してみたら Ambiguous use of 'init' とエラーを返されて「引数ラベル見てないのか...？」となった次第です。これの実行環境はPlaygroundでした。 init(hoge int: Int) { self = String(int) }

ラベルのついた引数がある関数は String.init(decimalStyle:) って関数を指定できるけど (edited)

3:06 AM

引数が１つでラベルがついてない関数の場合、同じノリで指定しようとすると

3:06 AM

String.init() って記法になるけどこれだと呼び出しになっちゃうから、それができなくって

3:06 AM

名前だけの記法→ String.init になると、今度はこいつはラベル付きも含めたオーバーロード検索になるよね

3:07 AM

でもなんでそれambiguousエラーじゃなくてdecimalStyleの方に確定しちゃうんだろう

3:08 AM

init<T>(_ value: T) where T : LosslessStringConvertible これになってるっぽい？

3:08 AM

Genericな関数と通常の関数だから、decimalStyle:のほうが勝っちゃうのか

ラベル付きも含めたオーバーロード検索になる

これは検索範囲が広く取られてしまうって話で合ってますか？

はい

なるほど。そのうえでGenericな関数と通常の関数の間には、優先順位がある？

import Foundation extension String { init<I : SignedInteger>(decimalStyle int: I) { let formatter = NumberFormatter() formatter.numberStyle = .decimal self = formatter.string(from: Int(int) as NSNumber)! } } let ids = [89902,100238,123289] let a = ids.map(String.init).joined(separator: "|") // Ambiguous use of 'init'

3:11 AM

↑こうすればGeneric同士だから曖昧になってコンパイルエラーになった。

なるほど

ジェネリックじゃなくて型がピタリと一致してる関数のほうが優先されます

3:11 AM

普段のオーバーロードでも。

fmfm

でもこれはハマりそうですね・・・

あくまで表示のためのString拡張と思って作ってたんですが、この例のようにAPIリクエストでids.map(String.init)している箇所があって、そこに作用があって一瞬ヒヤっとしました。下手に拡張するより、変換用の別のやつを作った方が安全だった...

extension Int { func formatDecimalStyle() -> String { let formatter = NumberFormatter() formatter.numberStyle = .decimal return formatter.string(from: self as NSNumber)! } } let ids = [89902,100238,123289] let a = ids.map { $0.formatDecimalStyle() }.joined(separator: "|") print(a) // 89,902|100,238|123,289 let b = ids.map(String.init).joined(separator: "|") print(b) // 89902|100238|123289

3:14 AM

initを拡張しなければ未遂に回避できそう (edited)

あー、こっちの書き方よさそう

map(String.init) ←おしゃれなコレが使えないけど、普段は value.formatDecimalStyle() って書けるので入力しやすいです

3:16 AM

でもこれを持ってしてinitを増やすのはバッドプラクティスだって言うのも早計だなあ　どうするのがいいんだ・・・

1

3:18 AM

map(String.init) ←この書き方にオーバーロード誤爆のリスクがあることは意識しておいたほうが良さそうですね

そうですね。結構使うシーンあるので 意識しとこう レベルで対策するのはアレな気がしていて、どう対策すべきか悩ましい。

3:25 AM

ひとまず腑に落ちました。ありがとうございます

static funcにしてids.map(String.formatDecimalStyle)とか。

あー、なるほど

@swift-4.2.4 -frontend -emit-syntax

import Foundation public class TestFunctionDeclNoReturn { func twoArgumentNoReturn(argument1: Int, argument2: String) { } }

{"kind":"SourceFile","layout":[{"kind":"CodeBlockItemList","layout":[{"kind":"CodeBlockItem","layout":[{"kind":"ImportDecl","layout":[null,null,{"tokenKind":{"kind":"kw_import"},"leadingTrivia":[{"kind":"Newline","value":1}],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},null,{"kind":"AccessPath","layout":[{"kind":"AccessPathComponent","layout":[{"tokenKind":{"kind":"identifier","text":"Foundation"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},null],"presence":"Present"}],"presence":"Present"}],"presence":"Present"},null],"presence":"Present"},{"kind":"CodeBlockItem","layout":[{"kind":"ClassDecl","layout":[null,{"kind":"ModifierList","layout":[{"kind":"DeclModifier","layout":[{"tokenKind":{"kind":"kw_public"},"leadingTrivia":[{"kind":"Newline","value":2}],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},{"kind":"TokenList","layout":[],"presence":"Present"}],"presence":"Present"}],"presence":"Present"},{"tokenKind":{"kind":"kw_class"},"leadingTrivia":[],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},{"tokenKind":{"kind":"identifier","text":"TestFunctionDeclNoReturn"},"leadingTrivia":[],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},null,null,null,{"kind":"MemberDeclBlock","layout":[{"tokenKind":{"kind":"l_brace"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},{"kind":"DeclList","layout":[{"kind":"FunctionDecl","layout":[null,null,{"tokenKind":{"kind":"kw_func"},"leadingTrivia":[{"kind":"Newline","value":1},{"kind":"Space","value":4}],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},{"tokenKind":{"kind":"identifier","text":"twoArgumentNoReturn"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},null,{"kind":"FunctionSignature","layout":[{"kind":"ParameterClause","layout":[{"tokenKind":{"kind":"l_paren"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},{"kind":"FunctionParameterList","layout":[{"kind":"Function

stdout.txt

https://ptpb.pw/uDno.txt/text

^ の結果についてわかる方答えてもらえると嬉しいです。 swift-syntaxで質問なのですが ^ の出力結果の json で comma の位置がおかしいなと思っているのですがあっていますか？ bugっぽいならフォーラムあげてPRまで送るのやってみたいなと思っていますおかしいと思っている場所

... "kind": "FunctionParameter", "layout": [ ... { "id": 20, "tokenKind": { "kind": "comma" // elipsis の位置に commaが来ているのがおかしい }, "leadingTrivia": [], "trailingTrivia": [ { "kind": "Space", "value": 1 } ], "presence": "Present" }, null, // ここは default argument のlayoutだから `null` で正しい null // ここが trailing comma のはず ], "presence": "Present" }, ...

順番はここで確認した https://github.com/apple/swift/blob/master/utils/gyb_syntax_support/DeclNodes.py#L338 (edited)

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

^ の「おかしいと思っている場所」のJSONと出力のJSONがちょっと違ってないですか？

3:53 AM

Ellipsis、は元のコードにないのでそれは無くて合ってると思います。

layout: [...] の中に入る子要素って Cursor の順番通り入っていないとおかしいのでは、と思っています ^ の質問は ... が含まれていない Syntax なのに ellipsis の場所に comma が入っていて、 (trailing) comma の場所が null なのがおかしいのでは、と思った質問でした

5:47 AM

^ でかいた僕が貼っている json は layout:[] の上下は結構削っていて、 ellipsis のところと comma を目立たせたかったのでそれ以前の layout の要素は削って貼ってあります

swiftcに渡してるソースコードには ellipsis が書いてある箇所があるってことですか？

いや、このコードには ellipsis は無い、です(で答え方あってるかな)

import Foundation public class TestFunctionDeclNoReturn { func twoArgumentNoReturn(argument1: Int, argument2: String) { } }

// elipsis の位置に commaが来ているのがおかしい ↑この「elipsisの位置」の意味が、わからないんです。

5:51 AM

コードにelipsisが書いてないから。

少し順序立てて質問の内容を整理したいのですが例えば FunctionParameter の "layout": だと https://github.com/apple/swift/blob/master/utils/gyb_syntax_support/DeclNodes.py#L317 この順番通りに layout が並ぶはずだと思っています。 Attributes(要素0) の次は FirstName(要素1) FirstName(要素1) の次は SecondName (要素2) って具合に。それで、省略可能な要素n番目に関しては、 layout[n] は null が代入されると思っています ellipsis が最後から数えると 3番目の要素になっているのですが、出力結果を見ると最後から 3番目に入っている要素の tokenKind.kind が comma になっているのがおかしいのでは、っていう質問でした

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

5:59 AM

それで、省略可能な要素n番目に関しては

少し違った。省略可能で、省略した場合の要素n番目に関して、だ。 (edited)

5:59 AM

引用どうやってやるんだ

Elilipsisというのは引数のラベル名じゃなくって、

6:00 AM

SwiftSyntaxにおけるなんかの構造のメンバ名なんですね。勘違いしてました。

たぶん可変長引数の ... の記号を指している言葉なはず (edited)

...を現すっぽいですね

そこでいうEllipsisはそうなんですけど、それはSwiftSyntaxは今のところ出さないんじゃないかな。

6:03 AM

それはEllipsisにはたぶん今のところならない

先のボットへ渡したソースに ... は無いし、ボットの出力にも ellipsis が無いので、???となってる。 https://ptpb.pw/uDno.txt/text/text

それはEllipsisにはたぶん今のところならない

実装がそうなってないので。

6:04 AM

定義を可変長引数にしても、、、って意味です。

https://github.com/apple/swift-syntax それはEllipsisにはたぶん今のところならない だと

public struct FunctionParameterSyntax: Syntax, _SyntaxBase, Hashable { enum Cursor: Int { case attributes case firstName case secondName case colon case type case ellipsis case defaultArgument case trailingComma }

Swift-Syntaxの Swiftコードに case ellipsis があるのはどういうことなんでしょう

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

定義上はそうで、後から実装が追いつくんじゃないですかね。

6:05 AM

推測ですけど。

最後から３番目がカンマっていうのがよくわからなくて

6:06 AM

今構造を追ってみたんですけど

だとしても、 layout の最後に trailing comma が来ないのはおかしいと思っているので、実装漏れとかそういう具合な気がしていますねこれがおかしい。っていうならフォーラムにあげようと思っているのですが。。

FunctionPArameterList の中に FunctionParameterが2つあって

1

１つ目のFunctionPArameterは Identifier, colon, SimpleTypeIdentifier, Comma

6:07 AM

2つめのFunctionParameterは Identifier, colon, SimpleTypeIndentifier

6:07 AM

となっているので

6:08 AM

( a : A, b: B ) の形で、特におかしくないと思いました。

ちなみに可変長引数の定義だと ... は今のところ演算子として解釈される。

 Child('Ellipsis', kind='Token', is_optional=True), Child('DefaultArgument', kind='InitializerClause', is_optional=True), Child('TrailingComma', kind='CommaToken', is_optional=True),

↑この3つが入るスロットは null, null, null になっているけど、 is_options = True なので、nullになるので良いのでは

trailing comma も無いので出ないと思うんですけど、来るべきというのはどこからですか？

もう少し大きめに json 貼ってdiscussionしている位置を合わせようと思っているので少しお待ちを

gistに張ると良いとおもます

お、確かに

6:14 AM

gist 初めて作ったまず今回の話題がここから: https://gist.github.com/bannzai/0fae75994c61d9ecf8cfb440de003515#file-json-L205 ここまで: https://gist.github.com/bannzai/0fae75994c61d9ecf8cfb440de003515#file-json-L261 のことです

swift-syntax-output. GitHub Gist: instantly share code, notes, and snippets.

swift-syntax-output. GitHub Gist: instantly share code, notes, and snippets.

6:14 AM

@omochimetaru さんが言っていた、第一引数ですね １つ目のFunctionPArameterは Identifier, colon, SimpleTypeIdentifier, Comma

Shiftで複数行選択できるよ https://gist.github.com/bannzai/0fae75994c61d9ecf8cfb440de003515#file-json-L205-L261

swift-syntax-output. GitHub Gist: instantly share code, notes, and snippets.

ふおおお、知らなかった

6:16 AM

↑この3つが入るスロットは null, null, null になっているけど、 is_options = True なので、nullになるので良いのでは

つまり場所が違うのでこれは一旦議論から外す

6:19 AM

まずこれそもそものあるべき姿を確認しておきたいのですが、 layout: [] の情報は Syntaxの種類によって要素の数と要素の順番は決定されている。っていうのは間違い無いですか？

ああ、質問の意図が分かったかも。

ここが null なのは @escaping とうの Attribute が無いから https://gist.github.com/bannzai/0fae75994c61d9ecf8cfb440de003515#file-json-L206 ここの構造が存在するのは argument1 という引数ラベルが存在するから https://gist.github.com/bannzai/0fae75994c61d9ecf8cfb440de003515#file-json-L207 ここが null なのはラベルとfunc内部で使われる変数が一緒だから https://gist.github.com/bannzai/0fae75994c61d9ecf8cfb440de003515#file-json-L216

swift-syntax-output. GitHub Gist: instantly share code, notes, and snippets.

swift-syntax-output. GitHub Gist: instantly share code, notes, and snippets.

swift-syntax-output. GitHub Gist: instantly share code, notes, and snippets.

6:21 AM

確認の意味は、^ って具合のことを言いたい (edited)

なるほど。私も質問の意図は理解しました

1

6:22 AM

要素の数が決まってるかどうかは、どうなんでしょうねえ？

6:22 AM

聞いてみるしかない気がします。

要素の数が決まってるかどうかは、どうなんでしょうねえ？ 確かに。全てを追ったわけじゃ無いので憶測は入っている。 null 埋めで要素を enum で吐いているみたいだからそうだと思ってしまっていました

私ならどうするかから推測すると、SwiftSyntaxはコンパイルエラーがある構文でもASTはできるので、数は決まってない、というのがありそうだとは思います。

1

並び順や要素数が固定であることを期待したコードにしてしまうと、すぐに破綻しそうだ。

@swiftbot --options='-frontend -emit-syntax'

import Foundation public class TestFunctionDeclNoReturn { func twoArgumentNoReturn(argument1...: Int,,, argument2: String) { } }

1

kishikawakatsumi

import Foundation public class TestFunctionDeclNoReturn { func twoArgumentNoReturn(argument1...: Int,,, argument2: String) { } }

Version:

swift-4.2.1-RELEASE

Output:

...

Error:

/usercode/main.swift:4:30: error: expected parameter name followed by ':' func twoArgumentNoReturn(argument1...: Int,,, argument2: String) { ^ /usercode/main.swift:4:48: error: unexpected ',' separator func twoArgumentNoReturn(argument1...: Int,,, argument2: String) { ^ /usercode/main.swift:4:49: error: unexpected ',' separator func twoArgumentNoReturn(argument1...: Int,,, argument2: String) { ^ /usercode/main.swift:4:5: warning: unknown declaration syntax exists in the source func twoArgumentNoReturn(argument1...: Int,,, argument2: String) { ^

6:30 AM

stdout-4.2.1.txt

4.12 KB

例えば、^ はカンマとかむちゃくちゃですけどJSON自体は出力されて、見た目どおりのツリーになるので。

6:31 AM

ASTはSwiftSyntaxがギブアップしない限り元のソースコードによる。

なるほど。失敗したパターンについては考慮できていなかったです。。が、話題の発端の ^ で出力した json については正確に構文解析はできるべきなのでは、と考えています。

commaの位置自体はおかしくないのでは？

あ、そういう風に捉えられるのか。ムムム。ちょっとお待ちをいくつか確認しよう

6:37 AM

commaの位置自体はおかしくないのでは？

っていうのはあれですよね。特定のキーワードにマッチしたものがあれば layoutは先頭から埋まっていく。っていう話ですよね (edited)

6:38 AM

@swift-4.2.1 -frontend -emit-syntax

import Foundation public class TestFunctionDeclDefaultArgument { func multipleArgument(argument1: Int = 1, argument2: String = "string") { } }

6:38 AM

やっちまった

6:38 AM

@swift-4.2.4 -frontend -emit-syntax

import Foundation public class TestFunctionDeclDefaultArgument { func multipleArgument(argument1: Int = 1, argument2: String = "string") { } }

{"kind":"SourceFile","layout":[{"kind":"CodeBlockItemList","layout":[{"kind":"CodeBlockItem","layout":[{"kind":"ImportDecl","layout":[null,null,{"tokenKind":{"kind":"kw_import"},"leadingTrivia":[{"kind":"Newline","value":1}],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},null,{"kind":"AccessPath","layout":[{"kind":"AccessPathComponent","layout":[{"tokenKind":{"kind":"identifier","text":"Foundation"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},null],"presence":"Present"}],"presence":"Present"}],"presence":"Present"},null],"presence":"Present"},{"kind":"CodeBlockItem","layout":[{"kind":"ClassDecl","layout":[null,{"kind":"ModifierList","layout":[{"kind":"DeclModifier","layout":[{"tokenKind":{"kind":"kw_public"},"leadingTrivia":[{"kind":"Newline","value":2}],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},{"kind":"TokenList","layout":[],"presence":"Present"}],"presence":"Present"}],"presence":"Present"},{"tokenKind":{"kind":"kw_class"},"leadingTrivia":[],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},{"tokenKind":{"kind":"identifier","text":"TestFunctionDeclDefaultArgument"},"leadingTrivia":[],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},null,null,null,{"kind":"MemberDeclBlock","layout":[{"tokenKind":{"kind":"l_brace"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},{"kind":"DeclList","layout":[{"kind":"FunctionDecl","layout":[null,null,{"tokenKind":{"kind":"kw_func"},"leadingTrivia":[{"kind":"Newline","value":1},{"kind":"Space","value":4}],"trailingTrivia":[{"kind":"Space","value":1}],"presence":"Present"},{"tokenKind":{"kind":"identifier","text":"multipleArgument"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},null,{"kind":"FunctionSignature","layout":[{"kind":"ParameterClause","layout":[{"tokenKind":{"kind":"l_paren"},"leadingTrivia":[],"trailingTrivia":[],"presence":"Present"},{"kind":"FunctionParameterList","layout":[{"kind":"Func

テキストが出ない。。 #swiftbot-sandbox で事前に同じコードで試していたものがあったので、それを貼りますね https://ptpb.pw/BAs-.txt/text

自分のターミナルで $ swiftc -frontend -emit-syntax で出ますよ。

ですね。一応同じもの見るためにここでやっとこうかなと思った感じでした

6:43 AM

^ で第一引数をまた話題にしたくて https://gist.github.com/bannzai/dfc79a80890e523ee193afed9afb7b03#file-json-L205-L283

with default argument

with default argument. GitHub Gist: instantly share code, notes, and snippets.

手元ではいたのをどっかに貼るのが１００％齟齬がないです

齟齬と言われると今どこが気になりました？ swiftbotでやっても変わらないのかなと思っていました。この場であればどのswiftのバージョンで吐いたかもわかるから利点もあるのかなと思っています！

6:47 AM

https://gist.github.com/bannzai/dfc79a80890e523ee193afed9afb7b03#file-json-L251 それでここを見ると

commaの位置自体はおかしくないのでは？っていうのはあれですよね。特定のキーワードにマッチしたものがあれば layoutは先頭から埋まっていく。っていう話ですよね

今度はここが null じゃなくて一つ次の "kind": "InitializerClause", が来るはずなのでは、と思っている感じです

with default argument

with default argument. GitHub Gist: instantly share code, notes, and snippets.

6:48 AM

今確認したらここも最後から3番目か

齟齬と言われると今どこが気になりました？

すでにたくさんbotの投稿があるので、どれを指してるのかよくわからなくなってきたので・・・

あああ、そこは。。。ある。これ gist に実行元コードも貼るのがいい気がしますね

今のgistのコードは

import Foundation public class TestFunctionDeclDefaultArgument { func multipleArgument(argument1: Int = 1, argument2: String = "string") { } }

↑これですか？

それですね！このコメントの内容のコードは @omochimetaru さんが今貼ってくれたコードです！

今度はここが null じゃなくて一つ次の "kind": "InitializerClause", が来るはずなのでは、と思っている感じです

6:54 AM

FunctionParameterのchildrenスロットは Attr, FirstName, SecondName, Colon, Type, Ellipsis, DefaultARgu, TrailingComma であるのに対して

6:55 AM

対応箇所は argument1: Int = 1, だから Attrなし FirstName=argument1, SecondNameなし, Colon=:, Type=Int, Elipsisなし, DefaultArg = 1, TarilingComma=,

6:55 AM

となることが期待されて

6:55 AM

実際JSONが

6:55 AM

そうなってるように見えますね。

YES！！なってます！言葉がややこしかったかもしれないのですが、僕はそれが正解だと思っています！

nullがあるポイントは、attrの[0], secondNameの[2], Elipsisの[5]。

1

6:57 AM

そうすると、emit-syntaxの出力も、期待通りですが、疑問点はなんでしたっけ

こっちの gist での https://gist.github.com/bannzai/0fae75994c61d9ecf8cfb440de003515#file-json-L205-L261 nullがあるポイントは attrの[0], secondNameの[2]、 Ellipsisの[5], DefaultArgument[6] だと思っています！

https://github.com/apple/swift-syntax/tree/master/Sources/SwiftSyntax

swift-syntax-output. GitHub Gist: instantly share code, notes, and snippets.

6:58 AM

syntaxを解析する元のコードは一番下に書いてある

あ、ほんとうだ

6:59 AM

ElipsisとDefaultArguのnullが無いまま

6:59 AM

commaが来ている？

nullの位置は無視した方が良いのでは…

末尾に２つあるnullはなんだろう？

7:00 AM

[5] = TarilingComma, [6] = Elipsisのnull？, [7] = DefaultARgのnull？

7:00 AM

って感じに見えますね。

お、そういうことになるのか。そこまではまだ追ってないし想像もできていませんでした。

あ、いや？

7:02 AM

~~なんかいろいろ無いね~~ (edited)

7:02 AM

[0] = null ( attr? [1] = identifier (FirstName [2] = null (SecondName [3] = colon [4] = TypeID [5] = comma [6] = null, [7] = null (edited)

7:03 AM

JSONを目で見た感じこうなってる

7:04 AM

https://github.com/apple/swift-syntax/tree/swift-4.2-branch/Sources/SwiftSyntax

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

7:04 AM

-emit-syntaxのJSONは、↑のSwift言語で書かれてるSwiftSyntaxでパースしてSwiftのオブジェクトになるので

7:04 AM

該当箇所のパースロジックを見てみると何かわかりそう

7:06 AM

https://github.com/apple/swift-syntax/releases/tag/swift-4.2-DEVELOPMENT-SNAPSHOT-2018-08-25-a

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

7:06 AM

↑masterだと今実装方法が変わっちゃってるとおもうんで4.2ブランチのだけど

7:06 AM

gybでテンプレート化されてて全く読めねえｗ

nullではない要素の順番が合ってて、欠けていなければ十分では…

順番が前後してるように見えませんか？

7:08 AM

本来commaはtrailingCommaなので[7]に欲しい。

7:08 AM

https://github.com/apple/swift-syntax#usage

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

7:08 AM

↑このスナップショットだとgyb処理した後だ

やったぜ

// ###sourceLocation(file: "/Users/alex/Documents/swift-src/swift-syntax/Sources/SwiftSyntax/SyntaxNodes.swift.gyb", line: 140) public var ellipsis: TokenSyntax? { let child = data.cachedChild(at: Cursor.ellipsis) // ###sourceLocation(file: "/Users/alex/Documents/swift-src/swift-syntax/Sources/SwiftSyntax/SyntaxNodes.swift.gyb", line: 143) if child == nil { return nil } // ###sourceLocation(file: "/Users/alex/Documents/swift-src/swift-syntax/Sources/SwiftSyntax/SyntaxNodes.swift.gyb", line: 145) return makeSyntax(root: _root, data: child!) as? TokenSyntax }

7:10 AM

 func cachedChild<CursorType: RawRepresentable>( at cursor: CursorType) -> SyntaxData? where CursorType.RawValue == Int { return cachedChild(at: cursor.rawValue) }

7:10 AM

おや？

7:11 AM

nullスキップとか考慮しないで、普通にIndexでアクセスしてるように見える

7:11 AM

これ、SwiftAPIのSwiftSyntaxから読み取ったら、trailing commaのデータを、elipsisとしてデコードしようとして

7:11 AM

クラッシュするかも？

そう。実はそこらへんはなんとなく確認していて、 Optional<SuyntaxData> がはいる Arrayになっているっぽいんですよね

7:12 AM

あれ、嘘ついたかも (edited)

このvar ellipsisは、 public struct FunctionParameterSyntax: Syntax, _SyntaxBase, Hashable のメンバです

1

7:14 AM

今SwiftSyntaxが、高速化アップデートで、-emit-syntaxの出力JSONをパースするのを辞めて、新しいC-APIでSwiftとマッピングするように変わったので

7:14 AM

このバグがもしバグだったとしても、根本的に実装方式が変わって水に流れるかもしれない

そんな、順序依存のコードになってるとは信じられないけど…

実験してみましょっか

このバグがもしバグだったとしても、根本的に実装方式が変わって水に流れるかもしれない

ほほん。そうなんですね。ただこれテスト漏れでもあるのでやっぱりおかしいならフォーラムにはあげる気概

7:17 AM

(実装漏れかなんかだとまだ思っている)

まあ、json実装の -emi-syntaxが壊れてるのは事実ですからね

7:23 AM

ビルドできねえ・・・

7:23 AM

let package = Package( name: "SwiftSyntax-issue-ellipsis", products: [ .executable(name: "SwiftSyntax-issue-ellipsis", targets: ["SwiftSyntax-issue-ellipsis"]), ], dependencies: [ .package(url: "https://github.com/apple/swift-syntax.git", .revision("swift-4.2-DEVELOPMENT-SNAPSHOT-2018-08-25-a")), ], targets: [ .target(name: "SwiftSyntax-issue-ellipsis", dependencies: ["SwiftSyntax"]), .testTarget(name: "SwiftSyntax-issue-ellipsisTests", dependencies: ["SwiftSyntax-issue-ellipsis"]), ] )

7:23 AM

なんかちがうかな

7:24 AM

swift-DEVELOPMENT-SNAPSHOT-2018-08-25-a こっちはビルドできた。

7:25 AM

4.2 08/25はこわれてる気がする・・・

これがStableなのかなと思いました

7:26 AM

https://github.com/apple/swift-syntax/tags

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

あ〜

7:26 AM

https://github.com/omochi/SwiftSyntax-issue-ellipsis/blob/master/README.md

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

7:26 AM

.package(url: "https://github.com/apple/swift-syntax.git", .exact("0.40200.0")), こうか

SwiftSyntaxはswift.orgで配布されてるswift-4.2.1-RELEASEに含まれてるのでは？

何もしなくてもimportできるんですっけ

出来る。

$ xcrun --toolchain org.swift.42120181030a swift -frontend -repl -sdk `xcrun --show-sdk-path --sdk macosx` *** You are running Swift's integrated REPL, *** *** intended for compiler and stdlib *** *** development and testing purposes only. *** *** The full REPL is built as part of LLDB. *** *** Type ':help' for assistance. *** (swift) import SwiftSyntax (swift) :print_module SwiftSyntax import Darwin import Foundation struct AttributeListSyntaxIterator : IteratorProtocol { typealias Element = AttributeSyntax let collection: <null> var index: <null> init(collection: AttributeListSyntax) mutating func next() -> AttributeListSyntaxIterator.Element? } … extension ValueBindingPatternSyntax { init(_ build: (inout ValueBindingPatternSyntaxBuilder) -> Void) } (swift)

なるほど・・・、まあ、tag指定しておいたほうが、先方環境で変な事がなさそうなので、これでいきます

swiftもSwiftSyntaxも、swift-4.2.1-RELEASEになるのに？

例えば5.0のswiftで実行したら問題が生じないとなると

7:40 AM

あとでよくわからなくなると思って。

ああ、5.0はSwiftSyntax.swiftmoduleとか無いからインポートできないな。

できた！！

1

7:49 AM

ちょいまちよ

7:50 AM

let sourceFile = try SyntaxTreeParser.parse(codePath) let blocks = sourceFile.children.compactMap { $0 as? CodeBlockItemListSyntax }.first! let block: CodeBlockItemSyntax = blocks.first! let classDecl = block.children.compactMap { $0 as? ClassDeclSyntax }.first! let funcDecl = classDecl.members.members.children.compactMap { $0 as? FunctionDeclSyntax }.first! let funcSig = funcDecl.children.compactMap { $0 as? FunctionSignatureSyntax }.first! let paramClause = funcSig.children.compactMap { $0 as? ParameterClauseSyntax }.first! let params = paramClause.children.compactMap { $0 as? FunctionParameterListSyntax }.first! let param0: FunctionParameterSyntax = params[0] print(param0) if let ellipsis = param0.ellipsis { print("---ellipsis---") print(type(of: ellipsis)) print(ellipsis) print("---") } else { print("no ellipsis") } if let trailingComma = param0.trailingComma { print("---trailing comma---") print(type(of: trailingComma)) print(trailingComma) print("---") } else { print("no trailing comma") }

7:50 AM

ccc: Int, ---ellipsis--- TokenSyntax , --- no trailing comma Program ended with exit code: 0

7:50 AM

ellipsis扱いで , が来て、 trailing commaが無いことになった。

7:52 AM

omochi/SwiftSyntax-issue-ellipsis

Contribute to omochi/SwiftSyntax-issue-ellipsis development by creating an account on GitHub.

あ、それが今まさに SwiftSyntax使って作っていたツールで起きていた問題ですです。(先に言え) ellipsis でアクセスして , が来るのが、アレってなってから仕様を追ってたんだ

↑cloneしてswift runで再現できます

1

7:54 AM

bannzaiさん報告するならこのリポジトリを参照してくれていいですよ

7:54 AM

面倒だったら僕が報告しても良いです

まじか。Special thanks!! 一度やってみたかったので僕がやります！

OKです、報告先はこちらが良いと思います→ https://bugs.swift.org

1

なるほど、確かにIndexでアクセスしているのですね…

あるtokenの情報は固定スロットのプロパティになっていて、可変長な要素は一回り外側で扱う感じの設計に見えますね

SwiftSyntaxの実装を初めてマトモに見たけど、何故こんな実装に…

ふああああああああ。Markdown効かないのか。初めてのbug?報告。皆さんありがとうございました！

https://bugs.swift.org/browse/SR-9710

4

https://twitter.com/jckarter/status/1088503336188313601

SE-0241: Explicit Encoded Offsets for String Indices

https://t.co/TLsCqb7T6P

Likes

144

ABI安定化はじまったな

https://forums.swift.org/t/strict-value-semantics/19677 strict value semanticsという新概念を試しに実装したらしい値型が参照を保有できないようにして、副作用の無い関数の検証などを可能とするらしい最適化や、将来的には並列処理サポートの役に立つとか。

Strict Value Semantics

Hello, In my free time and as a part of a larger research project, I’ve been maintaining a proof-of-concept patch that implements strict value semantics. At this point in my project, I’d like to see what it would take to get strict value semantics integrated into mainlin...

6:08 AM

サンプルはこのあたり https://github.com/davezarzycki/swift/blob/b247ec653a4f2cca130c797067927db3fdf93c29/test/Sema/enforce_value_semantics.swift

davezarzycki/swift

Contribute to davezarzycki/swift development by creating an account on GitHub.

enumは値型と参照型の二通りできるのかな

12:13 AM

現実的にはアノテーションつけるなりして段階を踏めるのが良さそう

enumは値型だからsemanticsもvalueだと思うけど、デフォルトのsemanticsを変更できる機能を考えてるって書いてある

indirectの扱い？

structの対はclass使うでいいんですがenumは無理、Optionalとか困る

Strict value types can pass/return/hold reference types but strict value types cannot call reference type members/getters/setters/etc. Thus strict value semantics are preserved, and popular generic value types continue to work (collections, Optional, etc).

1:01 AM

struct GeneralRefInValError { var c : C func foo() -> () -> V { // expected-error@+1 {{using reference semantic closure in a context expecting a value semantic closure}} return c.fn } }

1:02 AM

Casually speaking, strict value semantics means that value types “cannot” use reference semantics.

1:02 AM

「値型が参照型を持てない」は間違いだった。「値型がreference semanticsを使えない」だ。

#swift-contrib で話してた、String.IndexのencodedOffsetをdeprecatedにする提案が来てた。 https://forums.swift.org/t/se-0241-explicit-encoded-offsets-for-string-indices/19929

The review of SE-0241: Explicit Encoded Offsets for String Indices begins now and runs through Sunday, February 3rd, 2019. This is a very late-breaking proposal which we are considering for Swift 5. Reviews are a vital part of the Swift evolution process. All review feedbac...

レビュー期間短め

6:20 AM

イントロで野村さんの報告にリンクありますね

ちゃんとswift-5.0-RELEASEへ入れられる様に急いでくれるみたいで良かった。

あたらしいAPIはoffsetって概念をはっきりさせて、indexとの相互変換にviewを噛ませる感じですね

11:01 AM

自分のコードでもCとの境界で同じ事やってる部分が少しわかりやすくなりそう https://github.com/omochi/TMSyntax/blob/3e55117e889d24dc561596f9acea480573e46d7d/Sources/TMSyntax/Regex/OnigmoAPI.swift#L117

omochi/TMSyntax

WIP. Contribute to omochi/TMSyntax development by creating an account on GitHub.

https://forums.swift.org/t/accepted-with-modifications-se-0240-ordered-collection-diffing/20008

[Accepted with modifications] SE-0240: Ordered Collection Diffing

Hello Swift Community, The review of SE-0240 "Ordered Collection Diffing" ran from January 14...22, 2019. The review thread is available here. The proposal is accepted with modifications, specifically: The algorithm's semantic guarantees have been weakened to specify that ...

5:25 PM

diffが入るのが決まった

おお

6:22 PM

これ入るとTableViewの体験がObjCとSwiftで乖離してくるのかな

6:23 PM

UIKitのAPIレベルで (edited)

Collectionの拡張だからUIKitは変わらないよ

6:26 PM

差分をアニメーション付きでコミットとかは作りやすくなるかも

UIKitはこれを使ったAPIを提供しないのかな、そのうちするんじゃないかと思うのだけど

今ってデータの要素に関してはUIKitは感知していなくて

6:29 PM

Cellに自分で表示するようになってるから

6:29 PM

データの差分をUITableViewに与える形のAPIがどうなるのか想像つかない

https://github.com/apple/swift/blob/255c17aeb612d1c7a1575d3cbbf2ecdc6c57d334/stdlib/public/core/Substring.swift#L275-L280

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

12:37 PM

Substring.withCStringすると一度Stringにコピーされちゃうっぽい・・・

12:38 PM

String + Range<String.Index> を元にして自分でポインタをオフセットしたほうが良いって事になっちゃう

Substringが元のStringと同じ範囲を持つなら、元のStringを返す。 https://github.com/apple/swift/blob/master/stdlib/public/core/Substring.swift#L23 https://github.com/apple/swift/blob/master/stdlib/public/core/StringCreate.swift#L195

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

2:24 PM

元と違う範囲を持つなら、null terminationを追加する必要があるからコピーも仕方ないのでは。

2:25 PM

あいや、元Stringがnull terminationを持ってて、Substringの末尾が元Stringの末尾と同じになる場合にもコピーは回避して欲しいかな。

ああ、String.initの中にsubstringの場合の最適化は入っているんですね。

3:02 PM

たしかに途中で終わる場合にnullを入れたいから無理なのか。

3:03 PM

今使ってるライブラリが、Cブリッジはしてるけど、null terminationは特に求められていないので（start pointerとend pointerを渡すAPI)

3:03 PM

cString系のAPIを使おうとしているのが筋が悪いのかな

3:04 PM

でも、.utf8: UTF8View 経由だと、結局ArrayにコピーしてからwithUnsafePointerみたいな経路になりそうなんですよね (edited)

Swift 5からはString.UTF8View.withContiguousStorageIfAvailable(_:)を使う。

めっちゃそれっぽい名前のメソッド！！

3:06 PM

Swift4.2以前は等価なものは無かったんですか？

Swift 4.xはコピー発生は諦めて、String.utf8CString.dropLast().withUnsafeBytes(_:)を使うかな。

なるほど。

Yamsでそうした。 https://github.com/jpsim/Yams/blob/master/Sources/Yams/Parser.swift#L164-L173

jpsim/Yams

A Sweet and Swifty YAML parser. Contribute to jpsim/Yams development by creating an account on GitHub.

Swift5が来てからパフォーマンス最適化する方針にします。ありがとうございます。

どうせSwift 4.xまでは内部UTF-16だしね。

3:19 PM

withContiguousStorageIfAvailable(_:)がnilを返した場合に対応しなければいけないから、Swift 4.x向けに常にnilを返すwithContiguousStorageIfAvailable(_:)を定義しておけば、Swift 5では自動的に最適化されるコードを書けるよ。 (edited)

どうせSwift 4.xまでは内部UTF-16だしね

そうなんですよね。 IfAvailableって用意できない場合はコピー/トランスコードしてくれるって意味だと思ったら、nilで何もしないから自分でやるのかｗ

swift-4.2.2-RELEASEが来そう。まだtoolchainはダウンロード出来ない。 https://github.com/apple/swift/releases/tag/swift-4.2.2-RELEASE

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

https://swift.org/blog/abi-stability-and-more/ 今週3つ目の Swift.org ブログ記事

ABI Stability and More

It has been a longstanding goal to stabilize Swift’s ABI on macOS, iOS, watchOS, and tvOS. While a stable ABI is an important milestone for the maturity of any language, the ultimate benefit to the Swift ecosystem was to enable binary compatibility for apps and libraries. ...

サードパーティライブラリのバージョンをコード内でチェック出来るようにする仕組みは、将来入ったりしないのかな？>Library Evolution Support (edited)

3:09 AM

C系だとマクロを使えるけど、SwiftだとcanImportくらいしか無いよね。

3:11 AM

おーたしかに、今のところ知らないです。是非Jordanに聞いてみてほしい。

canImportがモジュール内の型やシンボルに使えると活用できるのだけど、現状はモジュールまでしかチェック出来ない。 @swift-4.2.4 #if canImport(SwiftBacktrace.enablePrettyStackTrace) import SwiftBacktrace enablePrettyStackTrace() #endif (edited)

exit status: 1 with stderr:

<stdin>:1:5: error: unexpected platform condition argument: expected identifier #if canImport(SwiftBacktrace.enablePrettyStackTrace) ^

(edited)

あー、ランタイムチェックが必要だからcanImportではダメか。

3:26 AM

将来Swift 6で新規にstdlibへAPIが追加されたとして、それを使ったアプリを実行できるかどうかのチェックは、deployment targetでされる様になるのかな。

3:30 AM

この辺りか。>Library Evolution https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#using-versioned-api (edited)

SE-0242: Synthesize default values for the memberwise initializer

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

3:32 AM

// Client code @available(Magician 1.5) class CrystalBallView : MagicView { /*...*/ } func scareMySiblings() { if #available(Magician 1.2) { summonDemons() } else { print("BOO!!") } }

5.0でStringProtocolのIndex周りにconstraintsが増えて使いやすくなった。 4.2.2:

protocol StringProtocol : BidirectionalCollection, Comparable, ExpressibleByStringLiteral, Hashable, LosslessStringConvertible, TextOutputStream, TextOutputStreamable where Self.Element == Swift.Character, Self.SubSequence : StringProtocol { associatedtype UTF8View : Collection where Self.UTF8View.Element == Swift.UInt8 associatedtype UTF16View : BidirectionalCollection where Self.UTF16View.Element == Swift.UInt16 associatedtype UnicodeScalarView : BidirectionalCollection where Self.UnicodeScalarView.Element == Swift.Unicode.Scalar

5.0:

protocol StringProtocol : BidirectionalCollection, Comparable, ExpressibleByStringInterpolation, Hashable, LosslessStringConvertible, TextOutputStream, TextOutputStreamable where Self.Element == Swift.Character, Self.Index == Swift.String.Index, Self.StringInterpolation == Swift.DefaultStringInterpolation, Self.SubSequence : StringProtocol { associatedtype UTF8View : Collection where Self.UTF8View.Element == Swift.UInt8, Self.UTF8View.Index == Swift.String.Index, Self.SubSequence.UTF8View.Index == Swift.String.Index associatedtype UTF16View : BidirectionalCollection where Self.UTF16View.Element == Swift.UInt16, Self.UTF16View.Index == Swift.String.Index, Self.SubSequence.UTF16View.Index == Swift.String.Index associatedtype UnicodeScalarView : BidirectionalCollection where Self.UnicodeScalarView.Element == Swift.Unicode.Scalar, Self.UnicodeScalarView.Index == Swift.String.Index, Self.SubSequence.UnicodeScalarView.Index == Swift.String.Index associatedtype SubSequence = Swift.Substring

お。ちょうどそれこの前気になったやつかな？ StringProtocolの方だと String.Index == String.UTF8View.Index == String.UTF16View.Index ... が無かった。

structのmutableプロパティがデフォルト値を持つ場合は、自動生成されるイニシャライザのパラメータにもデフォルト値を持たせる提案。 https://forums.swift.org/t/se-0242-synthesize-default-values-for-the-memberwise-initializer/20618 これは欲しいと思ったことが何度もある。

The review of SE-0242: Synthesize default values for the memberwise initializer begins now and runs through February 26, 2019. The proposal is written by @Alejandro. Reviews are an important part of the Swift evolution process. All review feedback should be either on this f...

わかる

2:17 AM

これがあるからinitの自動生成ほぼ頼って無くて書き下した上でデフォルト値をinitの方に書きがちだった

2:18 AM

ディスカッションだとなんかいろいろ指摘があって素直な流れじゃなかった気がするけどReview入したんですね

bugs.swift.orgへ登録したFeature Requestを基にpitchとかしてもらえるの、とても助かる。 https://forums.swift.org/t/pitch-string-gaps-and-missing-apis/20984

Pitch: String Gaps and Missing APIs

SE pull request and implementation. String Gaps and Missing APIs Proposal: SE-NNNN Authors: Michael Ilseman Review Manager: TBD Status: Pitched Implementation: apple/swift#22869 Bugs: SR-9955 Introduction String and associated types are missing trivial and obvious func...

https://forums.swift.org/t/opaque-result-types/15645/252

Opaque result types

There is nothing about opaque result types that make them unique in this respect from any other generic or existential context where the concrete type is unknown. Right now, AnyObject can be used to consorting to reference semantics. Perhaps in the future we will be able to...

9:35 AM

I think a subset of this proposal should be ready for review soon.

9:35 AM

opaque result typeのreviewが近いらしい

9:36 AM

protocol Shape { ... } func translucentRectangle() -> opaque Shape { ... }

9:36 AM

opaqueじゃなくてsomeはどうかなあ、だって

バイナリ配布をしないパッケージで@inlinable, @usableFromInlineを使ってはいけない場合ってのはあるのだろうか？ https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md

norio-nomura/InlinableTest

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

@inlinableを付けない方が速くなるパターンを見つけたかも。

インライン化されると逆に遅くなるケースですか？

モジュールで公開するAPIが@inlinableを付けたジェネリックメソッドで、それがstdlib内のプロトコルを使って実装されてると、stdlib内のプロトコルがモジュールを使う側でspecializeされなくて、結果的に遅くなる。

2:43 AM

@inlinableを外すと、元のモジュール内でstdlibのプロトコルがspecializeされて速くなる。

stdlib内のプロトコルって、たとえば<S: Sequence>でも該当しますね

そう。

stdlib内のプロトコルがモジュールを使う側でspecializeされなくて、

なんでだろ？

2:44 AM

inline化された後でspecializeされない？

2:45 AM

条件がそれだけだったら結構踏んでしまいそう。

再現するプロジェクトを作ってみるかな…

作った。 https://github.com/norio-nomura/InlinableTest

Contribute to norio-nomura/InlinableTest development by creating an account on GitHub.

swift test -c release で testInlined() average: 0.062 testNotInlined() average: 0.001 になる。

ジェネリックメソッドの呼び出しがspecializeされてるかどうかを簡単に確認する方法ってあるのかな？

IRを読むしか無さそう

6:58 AM

lower stageのSILを出力する方法があると嬉しいな。

$ swift test -c release -Xswiftc -save-optimization-record -Xswiftc -save-optimization-record-path -Xswiftc - とするとspecialized出来たかどうかを、各メソッド毎に出力してくれるぽい。 (edited)

9:37 AM

--- !Missed Pass: sil-inliner Name: sil.NoInlinedCost DebugLoc: File: /Users/norio/github/InlinableTest/Sources/InlinableTest/InlinableTest.swift Line: 17 Column: 29 Function: 'MyStruct.inlinedRanges<A>(_:)' Args: - String: 'Not profitable to inline function ' - Callee: '"specialized InlinableTest.RangeManager.ranges<A>(for:)"' DebugLoc: File: /Users/norio/github/InlinableTest/Sources/InlinableTest/InlinableTest.swift Line: 48 Column: 10 - String: ' (cost = ' - Cost: '72' - String: ', benefit = ' - Benefit: '40' - String: ')' ...

9:39 AM

どうやら@usableFromInlineなジェネリックメソッドを@inlinableなメソッドでspecialize出来ていないぽい。 (edited)

おお、save-optimization-recordいいですね

specialize出来ていなかった@usableFromInlineなジェネリックメソッドに@_specialize(where C==Range<Int>)と付けると、それを呼び出す@inlinableなメソッドもspecializeされる様になった。

10:10 AM

これはバグなのか仕様なのか。

どうやら@inlinableなメソッド内で直接stdlibのジェネリックなメソッドやプロトコルを使う分には問題ないらしい。

しかし、やはりジェネリックメソッドは@inlinableを付けない方が速いな。

someでreview始まった。 https://forums.swift.org/t/se-0244-opaque-result-types/21252

SE-0244: Opaque Result Types

Hi Swift Community, The review of SE-0244: Opaque Result Types begins now and runs through March 15, 2019. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback pri...

お

some Foo を返す関数を受ける変数の型は明示的に記述できない？

2:03 AM

変数の型として some Foo は書けない？

2:04 AM

書けても意味不明か。

2:05 AM

まだ Proposal 途中までしか読んでないけど↓になるという理解で正しい？

func foo1() -> some Foo { return Foo1() } func foo2() -> some Foo { return Foo2() } var foo = foo1() foo = foo2() // コンパイルエラー

これ実用上はassoctypeのあるprotocolのexistentialの代用という理解なんだけどあってるかしら (edited)

2:07 AM

むしろ本質的にそれなのかなぁ

existential 的な使い方はできないんじゃないでしょうか。

existentialの回避じゃない？

ふむー

なので、↑のコンパイルエラーになるんだと思ってます。

まだ最新提案を読んでないけど

2:08 AM

やりたいのは

2:08 AM

ArrayとかLazyCollectionとかで、func prefix()とか対応しようとすると

無駄に詳細になりすぎていた記述を必要最小限なレベルに簡易化したいということで、

2:09 AM

何かできることが増えるというものではないんだと思ってます。

理想のロジックを提供するためには専用のPrefixProxy型みたいなのが必要になっちゃって

https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md#opaque-result-types-vs-existentials

https://github.com/apple/swift/pull/21137

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

2:09 AM

あった

One could compose these transformations by using the existential type Shape instead of generic arguments, but doing so would imply more dynamism and runtime overhead than may be desired.

抽象的に書きたいっていうのと、具体的な型を書き下さないとオーバーヘッドが産まれる、っていう２つの矛盾する要求を解消するために

anyに対してのsomeは解りやすいな

コンパイラが追跡できる限り具体的な型に展開されるが、コードのインターフェースとしては抽象的で、モジュール境界とかでは自動でexistentialみたいになる

2:11 AM

みたいなもん？

つまりこれはあれだ一般的なexistentialに対してopenedな型だ

2:11 AM

@ukitaka 後で助けてくれ

おや

2:12 AM

The implementation of a function returning an opaque type must return a value of the same concrete type T from each return statement, and T must meet all of the constraints stated on the opaque type.

(edited)

2:13 AM

そもそも↓がエラーになりそう。 func foo1() -> some Foo { return Foo1() } func foo2() -> some Foo { return Foo2() }

え、なぜです？

2:14 AM

each return statements は　１つのfuncの中でのことだと思います。

エラーになるのは、 func foo() -> some Foo { if condition { return Foo1() } else { return Foo2() } } みたいなやつだと思いますよ。

1

ああ

2:15 AM

読み違えてた

2:15 AM

びっくりしました。

2:15 AM

return "a string" だけ見てその前の行を見てなかった。

Future Directionsのopaque type alias面白いな

2:19 AM

public typealias LazyCompactMapCollection<Elements, ElementOfResult> : some Collection<.Element == ElementOfResult> = LazyMapSequence< LazyFilterSequence< LazyMapSequence<Elements, ElementOfResult?> >, ElementOfResult > extension LazyMapCollection { public func compactMap<U>(_ transform: @escaping (Element) -> U?) -> LazyCompactMapCollection<Base, U> { // ... } public func filter(_ isIncluded: @escaping (Element) -> Bool) -> LazyCompactMapCollection<Base, Element> { // ... } }

2:19 AM

opaque return typeだけど、実際の型は２つの関数で同じだよって事を表明できるのか。

↓は OK なのに protocol P {} func foo<T: P>() -> T { fatalError() } ↓はダメなのか。 protocol P {} func foo() -> some P { fatalError() }

2:21 AM

A function with an opaque result type is also required to have a return statement even if it does not terminate:

func f9() -> some P { fatalError("not implemented") // error: no return statement to get opaque type } (edited)

2:22 AM

代入先から

2:22 AM

推論できるからか。

2:22 AM

あー、頭がバグってた・・・

2:22 AM

関係ない話だった。

NeverP[f9] みたいなものを内部的に生成してくれたらそこは無理やり通すようにできそうな気もする

2:23 AM

some P に対してとりあえず真の型が確定しないからエラーっていうのはひとまずはわかりやすいけど。

えっと、同じ話にするにはどうすればいいかな・・・

↓の someP がありってことは変数でも some が使える？？それともトップレベルの変数は変数じゃなくてプロパティ扱いなのかな？アクセス修飾子も付けられるし。

// Module A public protocol P { mutating func flip() } private struct Witness: P { mutating func flip() { ... } } public var someP: some P = Witness() // Module B import A someP.flip() // ok: flip is a mutating function called on a variable

(edited)

Opaque result types can also be used in stored properties that have an initializer, in which case the concrete type is the type of the initializer: let strings: some Collection = ["hello", "world"] (edited)

2:46 AM

letとかvarには書けるみたいですね。

2:47 AM

>「変数じゃなくてプロパティ」プロパティではない変数というのはどういう意味ですか？

↓の a はプロパティじゃないよね？ func foo() { var a: Int = 42 a += 1 print(a) }

一応 stored property なのかと思ってた。computed propertyにできるから。 func f() { var a: Int { return 3 + 3 } print(a) }

うん、今↓を試してた。 func foo() { var a: Int { return Int.random(in: 1...10) } print(a) }

get とか didSet とかも書けたはず (edited)

2:51 AM

@swift-main func foo() -> __opaque Collection { return [1, 2] } (edited)

exit status: 1 with stderr:

<stdin>:1:23: error: consecutive statements on a line must be separated by ';' func foo() -> __opaque Collection { ^ ; <stdin>:1:15: error: use of undeclared type '__opaque' func foo() -> __opaque Collection { ^~~~~~~~ <stdin>:1:24: error: 'Collection' cannot be constructed because it has no accessible initializers func foo() -> __opaque Collection { ^ <stdin>:1:24: error: protocol 'Collection' can only be used as a generic constraint because it has Self or associated type requirements func foo() -> __opaque Collection { ^

(edited)

まだマージされてないのでは？

2:52 AM

[WIP] Opaque result types prototype by jckarter · Pull Request #2...

WIP towards a prototype of an MVP subset of https://forums.swift.org/t/opaque-result-types/15645 . For an initial implementation, this won't include the resilience, second-order where constrain...

2:52 AM

というか

2:52 AM

まだレビュー中だし。

実装は結構進んでるんですよ

2:52 AM

masterには全く入れずにずっとやってるのか。

master に入るのはレビュー通った後じゃないのかな？

特定ブランチのbotが欲しい・・・

ブランチの数だけビルドしてボット化するのつらそう・・・

仮実装がmasterに入ってることはまあまあありますよ

2:54 AM

@swift-main func f(a: __shared Int) {}

no output

これとか。

まったく当てにならないけど、 The Swift Programming Language には

Properties associate values with a particular class, structure, or enumeration.

とは書かれてる。 Swift におけるプロパティの定義がわからないなぁ・・・。広義にはすべての変数や定数はプロパティなのかな？

2:59 AM

=== ↓の S はどこから来たの？？

protocol GameObject { associatedtype ObjectShape: Shape var shape: ObjectShape } struct Player: GameObject { var shape: some Shape { ... } /* infers typealias Shape = opaque result type of Player.shape */ } let sv: S.SomeType // ok: names the opaque result type of S.someValue() sv = S().someValue() // ok: returns the same opaque result type

https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md#associated-type-inference (edited)

[WIP] Opaque result types prototype by jckarter · Pull Request #2...

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

protocol P { associatedtype SomeType func someValue() -> SomeType } struct S : P { func someValue() -> opaque SomeType { ... } } let sv: S.SomeType sv = S().someValue()

3:04 AM

直前の説明文から推測すると、こういう事じゃないですか？ (edited)

GameObject と Player はどこいったんだろう？？後半だけコードを修正し忘れたのかな？

3:09 AM

let shape: Player.ObjectShape shape = Player().shape (edited)

Playerのところは

/* infers typealias Shape = opaque result type of Player.shape */

↑これが言いたいことだと思います

うーん、↑のコードが言いたかったんじゃないかな？

あれ？これはでもよくわからないな

↓の let result: Int = f7(-i) は禁止だけど

func f7(_ i: Int) -> some P { if i == 0 { return f7(1) // ok: returning our own opaque result type } else if i < 0 { let result: Int = f7(-i) // error: opaque result type of f7() is not convertible to Int return result } else { return 0 // ok: grounds the recursion with a concrete type } }

3:12 AM

ちょっと違うか

3:13 AM

でも、 Player.ObjectShape に some Shape を入れようとしてもこのケースではエラーにならないよってことでは？

それはIntで受けてるのがだめだよって話と、自己再帰は正しく推論するよって話ですかね

Player.ObjectShape に some Shape を入れようとしても

というか、逆で、 Player.ObjectShape が Player().shape で返される some Shape だと推論されるよってことかな。 (edited)

Player.shapeのsome Shapeが、Player.ObjectShapeになる

3:15 AM

protocolのassociated typeを、conformanceを満たすのに使ったfuncやvarのsome typeで充足できるって

3:15 AM

話っぽいですね

3:15 AM

2箇所で使われてたら、真の型の同一性がチェックされるのか？

↓この話おもしろい。

Hamish provides a complete explanation on StackOverflow as to why an existential of type P does not conform to the protocol P. The following example from that answer demonstrates the point with an initializer requirement:

protocol P { init() } struct S: P {} struct S1: P {} extension Array where Element: P { mutating func appendNew() { // If Element is P, we cannot possibly construct a new instance of it, as you cannot // construct an instance of a protocol. append(Element()) } } var arr: [P] = [S(), S1()] // error: Using 'P' as a concrete type conforming to protocol 'P' is not supported arr.appendNew()

(edited)

特定ブランチのbotが欲しい・・・ macOS版のtoolchainは随時更新されてるけど、Linux版は無いですね。あればローカル実行して随時ボットを動かすことはそれ程難しくなさそうですが… https://github.com/apple/swift/pull/21137#issuecomment-468118328

WIP towards a prototype of an MVP subset of https://forums.swift.org/t/opaque-result-types/15645 . For an initial implementation, this won't include the resilience, second-order where constrain...

そうか、普通のやつはビルド済みのパッケージがあるけど、ブランチだと無いのか。

↓なので、

func makeOpaque<T>(_: T.Type) -> some Any { /* ... */ } var x = makeOpaque(Int.self) x = makeOpaque(Double.self) // error: "opaque" type from makeOpaque<Double> is distinct from makeOpaque<Int>

やっぱり↓で正しそう。

func foo1() -> some Foo { return Foo1() } func foo2() -> some Foo { return Foo2() } var foo = foo1() foo = foo2() // コンパイルエラー

3:35 AM

これってモジュール（というかビルド単位）をまたいだときにどうやって静的に判定するの？ ABI に影響なくできる？

3:37 AM

Opaque result types are an ABI-additive feature

3:37 AM

書いてあった。

3:37 AM

additive だからいいのか。

3:44 AM

↓は OK ？エラー？ func p1() -> some P { return S(1) } func p2() -> some P { return S(2) } var s = p1() s = p2() // OK ？エラー？ (edited)

swift-PR-21137-216ツールチェインではエラーになった。

$ pbpaste protocol P {} struct S: P { let int: Int init(_ int: Int) { self.int = int } } func p1() -> __opaque P { return S(1) } func p2() -> __opaque P { return S(2) } var s = p1() s = p2() // OK ？エラー？ $ pbpaste|xcrun --toolchain org.swift.pr.21137.216 swiftc - <stdin>:17:5: error: cannot assign value of type '(__opaque main.(file).p2()@<stdin>:13:6)' to type '(__opaque main.(file).p1()@<stdin>:10:6)' s = p2() // OK ？エラー？%

swiftcの出力に変更 (edited)

ということは、静的に実の型を解析してるわけじゃなくて、 some P の宣言単位（？）でチェックされてるってことですね。

実際に真の型が同一でも駄目と

↓は OK という理解。

protocol P {} protocol Q { associatedtype T: P func foo1() -> T func foo2() -> T } extension Int: P {} struct S: Q { func foo1() -> some P { return 1 } func foo2() -> some P { return 2 } } let s = S() var a = s.foo1() a = s.foo2() // OK

4:15 AM

この opaque result type の概念、素晴らしいと思うけどコードの見た目が微妙そう。 var a: some Foo = ... let b: some Foo = ... a = b // コンパイルエラー a と b が同じ型に見えるのに。

4:15 AM

いや、だからこその some なのか。

4:16 AM

some Foo と some Foo だと英語的に同じじゃないという意味になるのか。

>The opaque type must be the entire return type of the function, For example, one cannot return an optional opaque result type: func f(flip: Bool) -> (some P)? { // error: `some P` is not the entire return type ... }

10:20 AM

The grammatical production for opaque result types is straightforward: type ::= opaque-type opaque-type ::= 'some' type The type following the 'some' keyword is semantically restricted to be a class or existential type, meaning it must consist only of Any, AnyObject, protocols, or base classes, possibly composed using &.

10:21 AM

() -> some (P?) も () -> (some P)? も使えなくて困らないんだろうか？

10:21 AM

throwsとOptionalで格差が出ちゃうのも気持ち悪い

10:22 AM

Collectionの.firstとか使えないと思ったが、.firstは .first: Element? だから、ここは some のユースケースじゃないので大丈夫なんだけど・・・。

でもそれができると existential になっちゃうし、同様に [some P] とかも認めないといけないんじゃないかな？

existentialになるってどういうことですか？あと、返り値じゃなければ[some P]はアリ

10:31 AM

var cc = [c] cc.append(c) // ok: cc's Element == the result type of makeMeACollection

10:31 AM

↑この例のところです

ほんとだ。型は決まってるわけだから別にexistentialじゃなくてできるか。

はい

たしかにそれができるのにreturnできなくて困るケースないのかな…。

(some P)? や [some P] を return できてダメな理由ってなんだろう？

わからない

そこ、できないとだけ書いてあって理由が書いてないよね。 https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md#restrictions-on-opaque-result-types

https://forums.swift.org/t/protocol-assoctype-t-shorthand-for-combined-protocol-and-associated-type-constraints-without-naming-the-constrained-type/21217

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

Pitchの方のフォーラムスレッドでは言及があるかもしれないですね

Optional<some P>が使えないのは不便じゃね、後回しなだけ？本質的な問題があるのか？って Tony Allevato が10時間前に質問してて

1:38 AM

ジョーグロフ「This is not a fundamental limitation. It could be added later. I'll include this in the "future directions".」

1:39 AM

なので、本質的な問題はないっぽい。よかった。

なるほど。

1:48 AM

Future Direction に書かれてる "where constraints on associated types of opaque types" とか "Conditional conformances" とかがないと標準ライブラリの問題に適用できなさそうなんだけど、それなしにでも先に導入したい理由があるのかな？

cocoaphonyさんが「mapで使えないよね？」って聞いてて

1:56 AM

Joe Groffが回答してるんだけど英語がよくわからん。「Granted, this initial revision of opaque result types doesn't either, but it could get there in time.」

1:56 AM

この辺の会話。

1:56 AM

今駄目だけど後々やると思う　って感じかな

1:58 AM

標準ライブラリの問題に適用できなさそう

全滅ではなくて、使えるところもあるでも互換性とかどうなるんだ

1:59 AM

func foo() -> some Collection where _.Element == Int { ... }

2:00 AM

この書き方だと、someについてるwhereとfuncについてるwhereのぶら下がりが曖昧だから

2:00 AM

Protocol<.AssocType == T> shorthand for combined protocol and asso...

Swift's notation for generic constraints generally requires naming the things being constrained; you say that a particular generic parameter conforms to a protocol by naming the generic parameter and the protocol it conforms to, like , and you put further constraints on its a...

2:01 AM

T: Protocol<.Type == Int> こっちの記法の話と並行して進めたいのかな

そういう意味合いもあるのか。

2:24 AM

where でだらだら続くのは視認性も悪いし P<.T == Foo> 形式の方がいいよね。

>JoeGroff: The implementation for an opaque type in another module does use witness tables just like a generic parameter; it has to in order to accommodate protocol resilience.

4:59 AM

モジュールまたいでopaque typeを使うときはジェネリックパラメータのところで使うwitness tableを使う

5:00 AM

もうランタイムレベルではassociated type付きexistentialが存在してると言って良さそう

5:00 AM

あ、 struct Box<T: P> { var value: T } の形でそれは元からあったか。

5:02 AM

IRGenのレベルで見た時にこの機能がこれまでと違うのはモジュール内部で使う直接形式と外部で使うresilentな形式が同時に生成されることか。関数シンボルが２つできるのかな？ (edited)

Protocol制約記法のスレのほうで

5:43 AM

Generalized Existentialの記法も同時に扱われているが

5:43 AM

Existential var x: Protocol<.A == Int, .B: P>

5:43 AM

この路線だと、普通のPと同じになるのがいいね

5:43 AM

let xs: Collection<.Element == Int> = [1,2,3]

5:45 AM

var x: Any<Protocol where _.A == Int, _.B: P> ←こっちだと既存のExistentialとの整合性問題がある

protocol Z<T> { associatedtype R ... } func baz(_ z: Z<Int, .R == Int>) { ... }

7:38 AM

もし、Parameterized Protocolが導入された未来において、< >の記法が、ジェネリックパラメータとassoctypeの両方をまとめて書く事になっちゃうけど、ギリ衝突はしない

めっちゃおもろい

4:37 PM

出来なかったことに色々手が届きそう

Swift5世代で結構ジェネリクス周りが進むかもね

ここ２年ぐらい、「なんにせよそれはABI安定化してからやな」って流れた話題がそこそこあった気がするし

いい話だ

https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025

Lifting the "Self or associated type" constraint on existentials

When the first seed of Swift came out many years ago, there were technical reasons for the "self or associated type" constraint on protocol existentials: At that time, protocol witness tables did not carry associated type information, so it was impossible to re-open the dynam...

3:23 AM

Generalized Existential？スレはここか。

3:28 AM

Selfかassoctypeのあるprotocolをexistentialに使えない理由として、昔は実装上witness tableに真の型が入ってなくてre-openできなかったから無理だったけど、最近Recursive constrained protocolの対応をしたときに、それも実行時に運ぶようになったから、原理上可能になっているその後のくだりがよくわからなくって、 Selfとassoctypeに関してcontravariantなメソッドをextentionで追加できるという型システム上の問題はすでに存在しているとかなんとか

3:31 AM

associated typeについてconstraintを設定できないから完全なgeneralized existentialの話ではないらしい

ふむ

3:37 AM

型システム上の問題

tsのisEqual的なアレかな (edited)

AnyEquatableを作ろうとすると Int と Stringの比較が静的には許可されて実行時になる話と関係してそう。 (edited)

3:38 AM

We'd follow the existing rule which is that protocol members that use contravariant Self or associated types aren't available on the existential

3:38 AM

そもそもこれなんだっけ

3:39 AM

あ、これは普通の existential 作れない事を言ってるのか

3:39 AM

(contravariant Self) or (associated types) か

最後の文脈はそれっぽい

なんでSelfの話するときにcontravariantってついてるのかよくわからない。

引数Self限定なんすよ

3:40 AM

返り値Selfはオッケー

あ〜〜〜

この間わいわいでやった

そういう意味か、「Selfが出現してたらexistentialが作れない」ではないのか。

3:41 AM

protocol P { func a() -> Self } struct S : P { func a() -> S { fatalError() } } func main() { var p: P = S() }

3:41 AM

ほんとだ。

言ってしまえばinit制約だってある種のSelfだべな

Selfであってもcontravariant positionになっていないならば許すのね。

3:42 AM

initはSelfを返してるようなもんだから、covariantだから、セーフかね

3:43 AM

protocol P { init(name: String) func a() -> Self } struct S : P { init(name: String) {} func a() -> S { fatalError() } } func takeExistentialArg(_ p: P) {}

3:43 AM

なるほどね

3:44 AM

protocol P { init(name: String) func a() -> Self } protocol Q { func takeSelf(_ self_: Self) } func takeExistentialArgP(_ p: P) {} // Protocol 'Q' can only be used as a generic constraint because it has Self or associated type requirements func takeExistentialArgQ(_ q: Q) {}

3:44 AM

このエラーメッセージ、「it has Self」のところ、「it has contravariant Self」のほうが、良さそう。

3:46 AM

protocol P { init(name: String) func a() -> Self } protocol Q { func takeSelf(_ self_: Self) } extension P { func takeSelf(_ self_: Self) { } } func takeExistentialArgP(_ p: P) {}

3:46 AM

However, nowadays we also have protocol extensions, so even if a protocol doesn't have any core requirements with contravariant Self or associated type arguments, contravariant protocol methods can be added by extensions, so the type system issues unavoidably exist already.

3:47 AM

たとえ、protocol Pの本体が、contravariant Selfを使っていないとしても、extensionでそれを追加する事ができちゃうので、すでに一部壊れてる

3:50 AM

extension P { func transfer(_ self_: Self) -> Self { return self_ } } func takeExistentialArgP(_ p: P) { // Member 'transfer' cannot be used on value of protocol type 'P'; use a generic constraint instead let a = p.transfer(p) }

3:50 AM

ウオオ

3:51 AM

protocol Pに生やしたのに existential Pでは使用禁止になるケースあるのか。

3:53 AM

これがまさに

We'd follow the existing rule which is that protocol members that use contravariant Self or associated types aren't available on the existential.

か

3:54 AM

だから、contra Self or assoctypeなメンバーの使用はできないという制限(これは実は既存)のもとで contra Self or assoctypeな protocolでもexistentialを可能にしよう　っていう提案か。 (edited)

3:56 AM

これって要するに、

3:56 AM

protocolからcontra Selfとassoctypeを取り除いた親protocolを作って、親protocolのexistentialを使う、っていう現時点で可能なワークアラウンドと、表現能力は一緒かな (edited)

3:59 AM

existential P が protocol P に準拠できないのもこの差分があるから、って言うこともできるんかな

4:00 AM

つまり、existential Pは <T: P> と違って真の型を失ったただの型境界にすぎない？

4:03 AM

func foo<T: P>(_: T) extension P { func _forwardToFoo() { foo(self) } } func callFooOnEach(_ ps: [P]) { for p in ps { p._forwardToFoo() } }

4:04 AM

you can in fact "open" the existential by invoking a protocol extension method, which will give you Self as the dynamic type of the value inside the method, which you can then pass to generic functions:

4:04 AM

protocol extension経由でSelfをreopenできるってこれなんか前話したな

4:05 AM

Pの中に隠れてるから　_forwardToFoo　を呼ぶ側からみるとセーフなのか。

https://twitter.com/kateinoigakukun/status/1103887180408139777

kateinoigaku (@kateinoigakukun)

なんでexistentialがSelf conformingしないのか。https://t.co/cBN6B5rRYI

5:25 AM

existential PがPにconformしないのって結局どこがネックなんでしたっけ

おもちのは前あった裏技ですね。そろそろprotocolとexistential周りの裏技一覧が欲しい

なんかわかってきた気がする

5:41 AM

extensionでPにSelfを引数にとるメソッドを追加できるから、 existential Pが、もしPに準拠してたら、そのメソッドは、existential Pを受け取ることになるけど、 exPはすべてのT:Pのスーパータイプだから、実際の型はSだったりして、SにおいてはそのメソッドはSを受け取るはずだから、壊れて困る

5:43 AM

exPはT:Pの共通の親であるって性質と、 exP自身がPである、って性質は、一般には両立しないのでは

Exsistentialに対して直接呼ぶのはコンパイルエラーにできるけど、T: P越しだと弾けないのか

self reopenの技をErrorに対して使えば、クラッシュさせられるのかな？

あ。。

extensionで追加したメソッドでSelfを引数に受けたとしても、その先の処理でextensionの中で何をすると問題が起こせるか、思いつかない・・・

mutating func killme(_ new:Self) { self = new } (edited)

5:49 AM

これ？

お！

壊すのは得意だよ

www

試してみたんですけど、これだと引数の型がexistential PじゃなくてT: Pになりませんか？

コードで見たい

@swift-5.0.3

struct IntError : Error { var value: Int } struct StringError : Error { var value: String } extension Error { mutating func assign(other: Self) { self = other } } func dispatchAssign<E: Error>(_ a: inout E, _ b: E) { a.assign(other: b) } func main() { let e0 = IntError(value: 3) var e0e: Error = e0 dump(e0e) let e1 = StringError(value: "a") let e1e: Error = e1 dispatchAssign(&e0e, e1e) dump(e0e) } main()

▿ main.IntError - value: 3 ▿ main.StringError - value: "a"

別の型になって生き延びとる

ex.Error に対する mutating funcを呼び出すためには、一度 ex.Error型の変数に代入する必要があるから、ex.Errorから元のIntErrorに書き戻す事が無いので、大丈夫

mutating funcはExsistentialじゃないとダメなのか

@swift-5.0.3

struct IntError : Error { var value: Int } struct StringError : Error { var value: String } extension Error { mutating func assign(other: Self) { print("assign:") print("self type=", type(of: self)) print("other type=", type(of: other)) print("dump self") dump(self) print("dump other") dump(other) switch self { case is IntError: print("self is IntError") case is StringError: print("self is StringError") default: break } print("---") self = other } } func dispatchAssign<E: Error>(_ a: inout E, _ b: E) { a.assign(other: b) } func main() { let e0 = IntError(value: 3) var e0e: Error = e0 dump(e0e) let e1 = StringError(value: "a") let e1e: Error = e1 dispatchAssign(&e0e, e1e) dump(e0e) } main()

▿ main.IntError - value: 3 assign: self type= Error other type= Error dump self ▿ main.IntError - value: 3 dump other ▿ main.StringError - value: "a" self is IntError --- ▿ main.StringError - value: "a"

type(of: self) だと ex.Error に見えるけど is で調べると元の型に見えるね

6:52 AM

https://stackoverflow.com/questions/33112559/protocol-doesnt-conform-to-itself

Protocol doesn't conform to itself?

Why doesn't this Swift code compile? protocol P { } struct S: P { } let arr:[P] = [ S() ] extension Array where Element : P { func test<T>() -> [T] { return [] } } let ...

6:52 AM

もし、Swift.Errorに init() が生えてたら

6:52 AM

ここのHamishさんのappendNew()のパターンで

6:52 AM

壊れそうな気がするんだけど。

昨日それ読んでたんですけど、逆にinit()が生えてなければself conformしていても問題なさそうに思えるんですよね

うむ。さっき思ったんだけど、

6:55 AM

Protocolの全ての機能 { contravariance Self associatedtype Existentialを作れる範囲の機能{ extension contravariant Self Existentialに対して呼び出せる機能 { covariance Self (init, static func) ExistentialがSelf conformできる範囲の機能{ func requirement } } } }

(edited)

6:55 AM

こういうことかなあと

6:59 AM

で、そのスレッドで提案しているのは、これを

6:59 AM

Protocolの全ての機能 { Existentialを作れる範囲の機能{ contravariance Self associatedtype extension contravariant Self Existentialに対して呼び出せる機能 { covariance Self (init, static func) ExistentialがSelf conformできる範囲の機能{ func requirement } } } }

6:59 AM

こう変更しようってことかなと

struct IntError : Error { var value: Int } func mutateError(_ e: inout Error) {} struct Cat { var error: IntError } func main() { var cat = Cat(error: IntError(value: 3)) // Cannot pass immutable value as inout argument: implicit conversion from 'IntError' to 'Error' requires a temporary mutateError(&cat.error) }

7:12 AM

existentialへの変換はアップキャストみたいな扱いで、戻してくるところはダウンキャストみたいに非安全としてガードされる

7:16 AM

import Foundation @objc protocol P { } func genericP<T: P>(_ t: T) {} func existentialP(_ p: P) { genericP(p) }

7:16 AM

Yes, there’s already logic to detect and diagnose this case in fact (@objc protocols are self-conforming, except when they contain static members or initializers).

7:16 AM

https://forums.swift.org/t/will-existentials-ever-conform-to-their-protocols/4919/5

Will existentials ever conform to their protocols?

Yes, there’s already logic to detect and diagnose this case in fact (@objc protocols are self-conforming, except when they contain static members or initializers). Slava ···On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution wrote: There is also a caveat w...

7:16 AM

@objc protocol は self-conformance していて、その条件チェックもされてるって！

7:17 AM

import Foundation @objc protocol P { init() } func genericP<T: P>(_ t: T) {} func existentialP(_ p: P) { // Cannot invoke 'genericP' with an argument list of type '(P)' genericP(p) }

pにinitつけたらエラーになった。

@objcのSelf conformingは知ってた

7:33 AM

でも確かぶっ壊れがあって

それが定義ベースで検査されてる

7:33 AM

昨日それ読んでたんですけど、逆にinit()が生えてなければself conformしていても問題なさそうに思えるんですよね

↑これが実現されてるってこと

ObjcProtocol.selfがObjcProtocolにキャストできる抜け穴がある

えｗ

治ったかは知らない、確かめてない

7:34 AM

RxSwiftのパッチ作ってる時に気づかずに踏んでざは先生にごめんなさいした

import Foundation @objc protocol P {} func takeGeneric<T: P>(_ t: T) {} func main() { let pMeta = P.self // Argument type 'P.Protocol' does not conform to expected type 'P' takeGeneric(pMeta) }

7:35 AM

大丈夫そう

確か、@objc protocolをassociatedtypeに突っ込んだ上でそれをやると崩壊した

Xcode10.1だとまだ壊れてますね

11:35 AM

import Foundation protocol Animal { associatedtype Food } protocol Carnivore: class { func bark() } class Lion: Carnivore, Animal { typealias Food = Carnivore func bark() { print("gawgaw") } } func something<T: Animal>(_ type: T.Type) { print(T.self as? T.Food) }

ジェネリック引数と opaque result type の関係について考えてたんですが、その二つは双対の関係になってませんか？つまり、 func useFoo<F: Foo>(_ foo: F) { /* ... */ } func makeFoo() -> some Foo { /* ... */ } があったとして、

useFoo の利用者は Foo の具体的な型を決定し、実装者はある Foo についてコードを記述する。
makeFoo の実装者は Foo の具体的な型を決定し、利用者はある Foo についてコードを記述する。

という関係があるということです。どちらも、（ specialize されれば）具体的な型で記述されたのと同等のパフォーマンスを実現できるという点、具象型と抽象型を橋渡しするものである点で共通です。

そうすると、ジェネリクスにおいて「ある Foo 」を利用する人が「ある Foo 」に仮の名前（型パラメータ）を与えるのと同じように、 opaque result type についても「ある Foo 」を利用する人、つまり some Foo を return する関数を利用する人が仮の名前を与えるような構文もあり得る気がします。そうすれば、字面上同じ some Foo 同士で代入できない↓のようなコードにならずに、それぞれの some Foo に利用者側が別の名前を割り当てて使うことができるかもしれません。 var a: some Foo = foo1() let b: some Foo = foo2() a = b // `some Foo` 同士の代入だけどコンパイルエラー (edited)

3:36 PM

たとえば↓のようなイメージ。

func foo1() -> some Foo { /* ... */ } func foo2() -> some Foo { /* ... */ } var a: Bar = foo1<Bar>() // `some Foo` に `Bar` の名前を付ける let b: Baz = foo2<Baz>() // `some Foo` に `Baz` の名前を付ける a = b // `Baz` を `Bar` に代入しようとしているのでコンパイルエラー

ただし、 foo1 の戻り値同士は代入可能なので、 foo1 の呼び出し箇所間で同じ名前を与えるためにどういう構文が良いのかわかりません。 (edited)

ジェネリック引数とsome返り値が対であると言う考え方は結構しっくりきますね

3:39 PM

ジェネリック返り値は大体まるで使い物にならないので

3:39 PM

まさに欲しかったものな気がしています

ですね。初めて見たときからジェネリクスに似てる気がするもののそれをうまく言語化できずにいたんですが、↑のような対として考えてしっくり来ました。

3:55 PM

利用時に名前を付けるうんぬんは対として考えたときの可能性の話で、 some Foo でも（ some のニュアンスで some Foo 同士が異なる型として解釈できるので）十分だとは思います。

なるほど。 func useFoo(_ foo: some Foo) { /* ... */ } func makeFoo() -> some Foo { /* ... */ } https://forums.swift.org/t/se-0244-opaque-result-types/21252/59

SE-0244: Opaque Result Types

You're correct that they're duals. I touched on this briefly in "future directions". It would be great to eventually support some Foo as an argument type as well, which would let you write: func useFoo(_ foo: some Foo) { /* ... / } func makeFoo() -> some Foo { / ... */ } ...

1

GeneralizedExistentialと、HigherKindedTypeがそれぞれ無いことによって表現できないプログラムを上手く補完できるように感じてるけどあってるかな

3:46 AM

Collection.mapの結果は一時的な利用であればCollectionでさえあればよくって、中身の実装がArrayなのかLazyなのかは、mapの結果を得たときにプログラマが知る必要はなく、ランタイム時と最終的に確定した型に押し込めるタイミングで一意でさえあればいい、はず。

higher kinded typeでやりたいのって functor みたいな制約を書いたり、 functor に対して抽象的に map を使ったコードが書けたりってことじゃないですか？ some P はプロコトルの制約として使えないから難しそうな気が。

むむ

7:57 AM

Opaque result types cannot be used in the requirements of a protocol:

本当だ

7:57 AM

じゃあHigherKindedが無いのは無いままですね

1

↓がもし通るならややこしそう。

protocol P { associatedtype F: Foo func foos() -> (F, F) } protocol Q { associatedtype F: Foo associatedtype G: Foo func foos() -> (F, G) } struct S: P { // これはエラーになる？ func foos() -> (some Foo, some Foo) { /* ... */ } } struct T: Q { func foos() -> (some Foo, some Foo) { /* ... */ } }

(edited)

someFooはtypoかな？

1

typo です。 iPhone から打ってて気づいてませんでした。直しました。

3:12 AM

↓が OK だと思われるので、↑の S も OK でないと変な気もする。

protocol P { associatedtype F: Foo func foo1() -> F func foo2() -> F } struct S { // これは多分 OK func foo1() -> some Foo { /* ... */ } func foo2() -> some Foo { /* ... */ } } let s = S() var a: some Foo = s.foo1() let b: some Foo = s.foo2() a = b // これも多分 OK

protocol P { associatedtype Dep func a(arg: Dep) init() init(with dep: Dep) } extension P { init(with dep: Dep) { self = Self.init() } } class A: P { required init() {} func a(arg: @autoclosure () -> Int) {} } _ = A(with: 1)

↑のコードがSwift 5からエラーになるのってSR-5719で@autoclosureが型じゃなくなったからって理解であってますか。 (edited)

initに@autoclosure渡せないし、素直にclosureで書くようにするしかないか。

変更を見ると

Move @autoclosure flag from function type to parameter declaration

って書かれてるから、その理解で合ってそうですね。 https://github.com/apple/swift/pull/20152

[AST/Sema] Associate @autoclosure flag with parameter declaratio...

These changes aim to: Move @autoclosure flag from function type to parameter declaration Serialize @autoclosure as part of the parameter declaration Convert it from being a type attribute to be d...

普通クロージャをconformしてautoclosureをオーバーロードじゃダメですかね？

オーバーロードするのはinit(with:)？

@swift-5.0.3

protocol P { associatedtype Dep func a(arg: () -> Dep) init() init(with dep: Dep) } extension P { init(with dep: Dep) { self = Self.init() } } class A: P { required init() {} func a(arg: @autoclosure () -> Int) {} } _ = A(with: 1)

no output

これで通りますね

protocol側を変えるのか。ただそれだとinitに渡す時にはautoclosureされないから渡したやつの初期化処理入ってしまうってことですよね。 (edited)

initオーバーロードです。普通クロージャ版でprotocolにconformして、利用者用のextensionとしてconveniences initでautoclosureを使います

protocol P { associatedtype Dep func a(arg: Dep) init() init(with dep: Dep) } extension P { init(with dep: Dep) { self = Self.init() } } final class A: P { required init() {} func a(arg: () -> Int) {} convenience init(with dep: @escaping @autoclosure () -> Int) { self.init(with: dep) } } _ = A(with: 1)

finalくっつける必要あったけど、これでいけた。

3:03 AM

ありがとう、この方向でいってみようと思います！

enum Foo { case a, b } ってenumがあるとしてこれのArrayをリテラルで作る際に変数つっこむ時は let a: [Foo] = [.a, .b] って書いてて、引数貰う側の型指定で明示されてないところに変数にせずにリテラルつっこむ時にはしょうがなく [Foo.a, Foo.b] って書いてたんですけど [Foo.a, .b] みたいに後続のものは省略できたんですねっていうのを今気づきました。 (edited)

@swift-5.0.3 enum Foo { case a, b } let xs = [.a, Foo.b, .a]

no output

途中でもいいんですね。

class Animal {} class Cat : Animal {} class User { var cat: Cat init(cat: Cat) { self.cat = cat } static let keyPaths: [KeyPath<User, Animal>] = [ // Key path value type 'Cat' cannot be converted to contextual type 'Animal' \User.cat ] }

4:10 AM

KeyPath型はReadonlyなのでcovarianceとして正しそうだけど、これはできないのか。

https://github.com/apple/swift-log こんなプロジェクト始まってたんですね。Swiftにおける標準ロギングパッケージ

apple/swift-log

Contribute to apple/swift-log development by creating an account on GitHub.

知らなかった

https://forums.swift.org/t/feedback-server-logging-api-with-revisions/19375 ですかね。

[Feedback] Server Logging API (with revisions)

Proposal Review: SSWG-0001 (Server Logging API) After the great discussion thread, we are proposing this as a final revision of this proposal and enter the proposal review phase which will run until the 20th January 2019. We have integrated most of the feedback from the disc...

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

POSIX is not portable, remove it by compnerd · Pull Request #2045...

This prepares swift-package-manager to adopt more functionality in Foundation. The implementation in swift-package-manager is EXTREMELY unfriendly to porting due to the highly POSIX/UNIX specific ...

2:38 AM

compnerdさんがSwiftPMをWindows対応するために動き出した気配がする

2:38 AM

SwiftPM.FileSystem.getDirectoryContentsをFoundationで実装するようにしたりなどのパッチなんだけど、逆にlibCブリッジで書いてた事が驚き (edited)

2:39 AM

SwiftPM初期にFoundationが不完全だった、みたいな時系列の都合があったのかな (edited)

SwiftPMとswift-corelibs-foundationの最初のコミット https://github.com/apple/swift-package-manager/tree/f0a5106f3449c22ec27df3776b819d039de5877d https://github.com/apple/swift-corelibs-foundation/tree/a7b2bc1fa48fc447c8b93f634b01a8ffcddd0337

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

https://forums.swift.org/t/pitch-introduce-static-callables/21732

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

4:57 AM

最初からLinuxで動かすことを想定していたみたいだから、これから作っていこうとしていたswift-corelibs-foundationに依存するのを避けるのは理解できる。

なるほど　最初のコミットの時期もかなり近いですね

Pitch: Introduce (static) callables

Hi all, @dan-zheng and I wrote a proposal to introduce static callables to Swift. This proposal is also available as a gist here. We'd love to hear your feedback. Introduce callables Proposal: SE-NNNN Authors: Richard Wei, Dan Zheng Review Manager: TBD Status: Implementati...

3:49 AM

おもしろそうな話題

3:49 AM

struct Adder { var base: Int call(_ x: Int) -> Int { return base + x } } let add3 = Adder(base: 3) add3(10) // => 13

3:50 AM

いわゆる関数オブジェクト、Swiftの型システム的にはnominalな関数型(現状はstructural only)とも言えそう

Scalaのapplyメソッド、Kotlinのinvokeメソッドと同じ感じっぽい

12:58 AM

Scalaのapplyは中のPrior artに書いてあった (edited)

提案通りcallキーワードを導入するのが良いと思う

1:01 AM

dynamicCallableでcallって言葉採用されてるし

1:03 AM

このスレ、ピッチ自体だけじゃなくて、コアチームがcompound typeのジェネリクスやプロトコルサポートの話してる struct BoundClosure<T, F: (T) -> ()>: () -> () { var function: F var value: T call() { return function(value) } }

1:05 AM

↑関数型がプロトコルの位置にある

https://forums.swift.org/t/pitch-property-delegates/21895

Pitch: Property Delegates

Hi all, There are property implementation patterns that come up repeatedly. Rather than hardcode a fixed set of patterns into the compiler, we should provide a general "property delegate" mechanism to allow these patterns to be defined as libraries. The complete proposal fol...

11:18 PM

property behaviorスレがどんどん伸びる

面白い

Property DelegatesのPRにmacOSとUbuntu 16.04のtoolchainが来てる。 https://github.com/apple/swift/pull/23440#issuecomment-475933741

[WIP] Property delegates by DougGregor · Pull Request #23440 · a...

This is the implementation of the Property Delegates feature currently being pitched on the forums. Or, you can read the proposal. The implementation has a few notable limitations: libSyntax/Swift...

これがあるとbotが作れるんですっけ？

とりあえずdocker imageは作りましたよ。まだbotにはしてない。 norionomura/swift:pr-23440

3:01 AM

swift-pr-toolchain的なボットを作ろうかどうしようか迷ってる。

3:03 AM

一つのボットアカウントで複数のtoolchainを切り替えられる岸川さん提供のボットの方が、仕組みは馴染むはず。

なるほどなるほど

お、使えるようにしますかね。

4:37 AM

swift-PR-23440-175-ubuntu16.04 か。名前の規則が違うからちょっと作業必要すね。家でゆっくりやるかな。

今 swift-PR-23440-177-ubuntu16.04 がビルド中ですね。 https://ci.swift.org/job/swift-PR-toolchain-Linux/177/

docker imageを更新しました。 norionomura/swift:pr-23440

7:34 AM

ビルドナンバー付きタグ norionomura/swift:pr-23440-177 でも使えます。

あ、PR中の @swift-ci please build toolchain で作成される ubuntu 向けtoolchainのアーカイブは、 https://swift.org/downloads で配布されるものと違って、アーカイブ内のファイルはタグと同名のディレクトリに入っていない点に注意が必要です。 tar -xvzf $SWIFT_ARCHIVE_NAME.tar.gz --directory / --strip-components=1とかすると、/bin/swiftとか書き込むことになります。

@swift-5.0.3 import Foundation print(ProcessInfo.processInfo.environment["SWIFT_VERSION"]!)

5.0-RELEASE

https://forums.swift.org/t/returned-for-revision-se-0244-opaque-result-types/22115

[Returned for revision] SE-0244: Opaque Result Types

The review of SE-0244: Opaque Result Types has concluded and the proposal has been returned for revision.

10:11 AM

ORT、return for revision

10:12 AM

「言語の大きな機能になるからFuture directionについてgenerics manifstoみたいにしっかり書いて」て感じ？

まずは "reverse generics" を導入するのがいいと思う。

2:13 PM

すでにジェネリクスはあるわけだし。

その先のORTですかね

ORT だけじゃ多分↓とかできないし。 func makeAnimals() -> <A: Animal> (A, A) { return (Cat(), Cat()) }

https://forums.swift.org/t/se-0253-static-callables/22243

SE-0253: Static callables

The review of SE-0253: Static callables begins now and runs through April 5, 2019. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as t...

12:38 AM

4/5まででstatic callableのレビュー

12:39 AM

こう、そこまでスレも伸びないままシュッと始まって期間も短いので、ほぼ内定してそう

let inputRadius: CGFloat = 0 var radius = UInt32(floor(inputRadius * 3 * sqrt(2 * CGFloat.pi) / 4 + 0.5)) ^ このコードは、Xcode 10.1ならビルドできるけど10.2では

The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions

でビルドできない。

https://reddit.app.link/ur360e6SxV

r/swift - Looking for people who want to do 100 Days of Swift

8 votes and 9 comments so far on Reddit

https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544

SE-0255: Implicit Returns from Single-Expression Functions

Hi Swift Community, The review of SE-0255: Implicit Returns from Single-Expression Functions begins now and runs through April 11, 2019. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would ...

6:28 AM

関数でも1行ならクロージャみたいにreturn不要にしよう機能のレビュー

2

6:29 AM

なかなか賛否両論 getterだけで良いなども

6:30 AM

個人的にはgetterのreturnは邪魔臭く感じる事多いけど、スレ読んでたら悩ましくなってきた

Swiftは意図しない戻り値が返ることもなさそうだからいいんじゃないかな、という印象。

意図しない戻り値ってどういう意味ですか？

6:58 AM

rubyのArray.appendがVoidかと思ったら実はselfをreturnしてたみたいな？

そうそう。 Swiftは戻り値をシグネチャに必ず書くから大丈夫かなっていう

6:59 AM

func remove(at i: Int) { array.remove(at: i) } ^ もしSwiftがこうだったら、意図しない結果になる、みたいな

なるほど

https://bugs.swift.org/plugins/servlet/mobile#issue/SR-9802

10:18 AM

さっきこのバグにハマった

Swift 5のString.Index周り、沢山バグあります。

https://forums.swift.org/t/improving-the-ui-of-generics/22814

@Douglas_Gregor wrote the Generics Manifesto almost three years ago, which provided the roadmap for the core of Swift's protocols and generics features. Since then, we've implemented almost all of the basic model that it envisioned. Although there are further features we coul...

読んできた。めっちゃ長かった、情報量多すぎるけどこれはすごい

1:28 AM

全てのカオスが整理されてる

ORTより先にReverseGenericsやで、という意思を感じるけどあってるかな

そうねまあ一応直交な話にはなってて some記法はあくまでGenericsから三角カッコを消して書きやすくするシュガー

1:38 AM

RevGencsは実装が決める型レベル抽象が今できないから足さなきゃねって位置付け

1

おk

1:38 AM

thx

1:39 AM

だいたいスッキリした

それ以外にもexitlのオープン構文、Generalized existential、anyの必須化、などもかかれてる

しかしこれ風呂敷たたむの大変やね

全く新しいトピックはオープン構文じゃないかな

それはgeneric manifestにあったやつかな？

あったんだっけ

誰彼のドラフトかも、見た記憶はある

let <X: Collection> openedX = x // X is now bound to the dynamic type of x let start = openedX.startIndex let first = openedX[start] // OK, indexing X with a value of type X.Index, to get a result of type X.Element

つまりExistentalがanyでかかれてGenericsがsomeのシュガーを持つ、と。めちゃくちゃわかりやすいんじゃないかなぁ

あとは

既存の混乱も終焉を迎えるはずだ

some 記法のところで型パラが無名になる問題に対して

1:42 AM

func concatenate(a: some Collection, b: some Collection) -> some Collection where type(of: a).Element == type(of: b).Element, type(of: return).Element == type(of: b).Element

お、上の構文の提案は私見たことないな。私が見たのはif letみたいなネストがあるやつ

このように、引数名から型を取ってきて指定できるようにする案

1:42 AM

これかなり良さそう

1:43 AM

あと、any必須化によって、exisだけに拡張が書けるようになる extension any Hashable: Hashable {

where句出るなら無理にsome使わなくていいんじゃないのとはおもったけどw

読むときの間接度が１つ減るから良いと思うんだよね (edited)

私は

「Tは第一引数」ってワーキングメモリ使わないといけない

$0 $1 $2みたいな感じで良いかな？とは思った

1:45 AM

type(of)は長い

1:45 AM

無名型引数に対して連番ラベルを持って処理する

なるほど

extension any Hashableは嬉しいなぁ

1:47 AM

結構ワクワクするねこれ

typeofはすでにある関数なのが良いと思う

1:48 AM

初見で読める

関数の定義に関数使えるように見えてキチい

あと、ここに型レベル式が書ける拡張が期待できる

それができるならそれでええんやが

1:51 AM

$0,$1...は結構いいかなと思ったんだがなぁ、デバッグしてたらτ0みたいなのはよく見るじゃん、それのイメージや

なんかシグネチャ変更時にズレて書き直すことになりそうなのが微妙なんだよな

1:52 AM

$とは記号変えて %a とか

それは変えた方が良いのは同意

type(of:)の省略記号としての前置演算子とか？

1:53 AM

うーんでもこういうのはやりすぎるとPerlになるから悩ましい。

前置は良さそうだけどスッと理解できる奴だと良いね

extension any Hashable: Hashable { static func ==(a: any Hashable, b: any Hashable) -> Bool { return AnyHashable(a) == AnyHashable(b) } func hash(into: inout Hasher) { AnyHashable(self).hash(into: &into) } }

これはめっちゃ綺麗で

1:55 AM

exitentialのself conformanceの定義付けと実装が

1:55 AM

与えられるようになるから、self-conformanceよくわからん問題が

1

おおすごい

一気にわかりやすくなると思う

1:55 AM

これで実装を与えられるならself-conformanceするってことだから。

Errorがコンパイラ特別扱いじゃなくなる

AnyHashableがめっちゃ良い例で、これは普通のEquatableよりゆるくなって型の同一性がないから、型比較（暗黙変換を考慮した謎体系） (edited)

1:56 AM

を実装しなきゃいけないということがよくわかる

1:56 AM

Errorの場合は extension any Error : Error {} (edited)

1:56 AM

って空で書けばいいわけだな

んだね

まあ、空になる場合は自動self-conformanceってのもありだと思う。

1:57 AM

Error特別対応を一般化する。

明示的にやった方がいい気はするけど

type(of: return).Element

2:03 AM

これだと引数名にreturnが使えなくなるから

2:05 AM

resultType.Element とか？　うーん。

>>14でDanielさんが同じこというてる

2:13 AM

>I don't think this is better than the &Rust syntax, but another potential way to go is the positional argument syntax:

func concatenate(a: some Collection, b: some Collection) -> some Collection where $0.Element == $1.Element, $2.Element == $1.Element

引数と返り値で添字つけるとわかりやすくなるかな、 $A0, $A1, $R0, $R1, ...

3:49 AM

わからん

お気持ちを投稿してみた https://forums.swift.org/t/improving-the-ui-of-generics/22814/33

It is a wonderful document, with many of the previous discussions being neatly organized. The ORT discussion was very complicated, but I think the extension of type system by concept of reverse generics and concise notation with the some keyword are very beautiful. If the s...

これほぼ完璧なドキュメントだな。ORT関連の議論が簡潔かつ網羅的にまとめられている。

うんうん

We think this is a reasonable first step because it directly addresses the biggest functionality gap in the generics model.

この this は ORT だと思うけど、これについては最初に reverse generics をやった方がいいと思うなぁ。

あとあとまとまるならどこから来ても良くないですか？

12:08 PM

先のプランもあれば内部実装の設計的な後戻りも避けられるだろうし。 (edited)

まあ Core Team の人たちはすごいから先まで見通せるかもしれないけど、考慮漏れがないように reverse generics からやった方が無難な気が。あと、すでにジェネリクスはあるから構文的にも新しい ORT から手を付けるより、 reverse generics から入った方が過程も自然な状態を保てそう。

書いてみた。 https://forums.swift.org/t/improving-the-ui-of-generics/22814/37

https://forums.swift.org/t/se-0244-opaque-result-types-reopened/22942

I really love the direction. some and any seems perfect keywords. I think explicit existential types are worth breaking source compatibility. It also helps to notify people who are familiar with languages like Java that protocols in Swift are different from interfaces in thos...

SE-0244: Opaque Result Types (reopened)

Hi Swift Community, The review of SE-0244: Opaque Result Types has reopened and runs through April 17, 2019. The previous review was returned for revision, with the goal of setting the proposal in a wider context of future possible directions for the generics system. Since ...

はやい…。

12:22 AM

↓diff https://github.com/apple/swift-evolution/commit/58f698c7fa10b03f5a11133d970fb8dcc761ec3e#diff-95e223c6c3ac2ea464c1263dc4fdd2f8

Revise SE-244 for re-review (#1018) · apple/swift-evolution@58f698c

Revise SE-244 for re-review
- Update status and resume review.

17日までで再レビューですか、展開がはやい

モチベーションの章とか全く違う話になってる

凄い展開だw

That makes opaque result types somewhat less compelling for the compactMap example presented in the introduction, because one cannot have compactMap be marked @inlinable with an opaque result type, and then later change the underlying concrete type to something more efficient.

2:16 AM

これがあるからシンプルな関数の返り値の例をintroから外したのかな

@koher >>5の書き込みですけど、システム上>>4へのレスになってるけど、内容としてはスレッドへの投稿だと思うので、クリックするReplyボタンを間違えたかも？

2:51 AM

これを食らうと、フォーラムのシステムでレス先のユーザには通知が行っちゃうんですよ。（昨日食らった）

2:52 AM

あ、あってるのか、これは。

2:53 AM

>>4じゃなくて>>2か

うん、これは書かれてたコメントへの reply

2:59 AM

レビューは今ちょうど投稿した。 https://forums.swift.org/t/se-0244-opaque-result-types-reopened/22942/9

SE-0244: Opaque Result Types (reopened)

I strongly agree with adding opaque result types to Swift. However, supporting "reverse generics" first seems better for me because Swift has already supported generics. I think having generics and "reverse generics", in the transition period to add features step by step, m...

1

There's no IsOptional type of protocol (in the language or standard library) unless I write my own to add it to the opaque type signature

https://forums.swift.org/t/se-0244-opaque-result-types-reopened/22942/10 Optional 互換のプロトコルがないという視点はおもしろい気がする。ちょっと話は変わるけど、もし OptionalProtocol があれば↓みたいなこともできる？ enum IndirectOptional<Wrapped>: OptionalProtocol { case none indirect case some(Wrapped) }

SE-0244: Opaque Result Types (reopened)

What is your evaluation of the proposal? Overall +1, but deferring handling Optionals will impede my ability to fully make use of this feature. For better or for worse, Optionals have a special place in the type system, and there's this weird boundary with them: There's ...

3:31 AM

indirect な Optional ときどきほしくなる。

OptionalProtocol無いと書けないextensionとかありますね

3:33 AM

ん、それはなにか意味ありますか？＞IndirectOptional

うん、プロトコルがない不便さは前からあったけど、 ORT 絡みでの意見は初めて見た気がする。

https://forums.swift.org/t/pitch-introducing-unwrappable-protocol/5385

[Pitch] Introducing Unwrappable protocol

I have been involved in several separate related draft proposals for discussions that were cut off about 4 months ago. I believe they meet the criteria for Stage 2, but I'm doing a poor job presenting them coherently on-list. Because of that, I'm going to start over here, ...

3:35 AM

Ericaさんがピッチ立ててて、ユーザ定義enumでもif let できるとかアイデアが出てるけど話題止まってるんよな

@swift-5.0.3 struct Foo { var foo: Foo? }

exit status: 1 with stderr:

<stdin>:2:9: error: value type 'Foo' cannot have a stored property that recursively contains it var foo: Foo? ^ <stdin>:2:9: note: cycle beginning here: Foo? -> (some(_:): Foo) var foo: Foo? ^

このORTでの意見は単に Optional<some Collection> ができないから

@swift-5.0.3 enum IndirectOptional<Wrapped> { case none indirect case some(Wrapped) } struct Foo { var foo: IndirectOptional<Foo> }

no output

OptionalなProtocol + associated typeにすればできるって事？

3:36 AM

some OptionalOfCollection でごまかしたい？ (edited)

いや、プロトコルは、 Optional と IndirectOptional を統合的に扱う仕組みが必要だろうなというくらいのことしか考えてない。

3:36 AM

Array だったら再帰できるのに、 Optional で再帰できないの辛い。 (edited)

あ〜

3:37 AM

普通のOptionalだと自分をフィールドに持てないのか。

うん。

Mordiiさんの意見に関しては

3:39 AM

Optional<some Collection> は　あとで対応するって書いてあるから

3:39 AM

それでいいような。待てなければ、自前定義でもできるし。

あとで対応せずに先にやってって言ってるんじゃないかな？

but deferring handling Optionals will impede my ability to fully make use of this feature.

3:40 AM

ああ、こっちが言いたい事か。

いずれにせよ reverse generics 先にやれば解決なんだけど、いきなり reverse generics やるのはきついのかな？実装が。 (edited)

少なくとも現時点のORTはすでに完成してますからね。

3:41 AM

Optional対応とかRevGenes対応をすると遅延するのは間違いない

3:41 AM

ちょっとずつ機能ができ次第入るのと

3:41 AM

完璧なものが一気にきてほしいのかの

3:41 AM

違いな気がしていて

3:41 AM

そういう判断は実装者に任せたらいいんではないかなあと思う

ただ、 ORT 実装したときってまだ reverse generics っていう概念が示されてなかったと思うから

まあ、残りの部分も早くして！って急かすことに意味はあるけど。

それに耐えうる汎用度で今の実装がされてるか疑問が。

3:43 AM

こんなややこしい機能を、最終的な汎用的な形に至らない部分的な形で実装しても、 ABI がぐちゃぐちゃになったりしないのかなぁ。

静的にはspecialize最適化と一緒で

3:44 AM

動的にはExistential Containerと一緒だから

ABI 安定化前はそれでよかったと思うんだけど、いくら additive とはいえ、 ORT は reverse generics のシュガーなのに ABI は二通りあるとかなりそうな気が。

型の決まり方っていうコンパイルステージの新しさしかなくって、実行時モデルとしてはジェネリックな T 型の resilient版のコードや Existentialと変わらない気がするんですよね

3:48 AM

同一モジュールでコードが見える場合やinline化可能な場合に生じるのはspecialize最適化と同じだし。

3:49 AM

実装で大変なのは型解決中のSemaのデータ構造の方に見える

同一モジュール内は露出していいと思うんだけど、モジュールをまたぐときに reverse generics 独自の表現になるんじゃない？

そのモジュールをまたぐときはExistentialと同じ仕組みでいけません？

3:51 AM

「どの関数から来た」って情報はあくまで別モジュールで型チェックするときに引っ張れればよくてコンパイル後は消える。

3:52 AM

Existentialと同じ仕組み＝(値本体, 真の型のメタタイプ, そのPWT...)

コンパイル後に消えたら、コンパイル単位が異なるときに existential 扱いにされたら↓みたいな型チェックができなくない？ func foo1() -> <A: Animal> A { ... } func foo2() -> <A: Animal> A { ... } var a = foo1() let b = foo2() a = b // NG

コンパイル後じゃないや、実行時。

3:53 AM

「コンパイルされたライブラリ」にはヘッダーとしてその情報は残ってる。

実行時は消えていい気がする。

3:56 AM

うーん、ヘッダーに型情報があればそれで問題ないのか・・・

もしかして、返り値でexistentialで返すときに、タプルの中身を個別の引数での参照返しになってて、 (edited)

3:58 AM

Optionalのフィールドみたいに、型の中に値として持つ表現がまだ決まってないんかな

3:58 AM

あ、でも、var a = foo1() の形のときはローカル変数に展開してるはずか。

3:59 AM

今度調べてみよう

4:05 AM

tackling "reverse generics" first can prevent lack of consideration about internal implementation.

4:05 AM

これに返信もらえるといいですね

4:07 AM

いくら additive とはいえ、 ORT は reverse generics のシュガーなのに ABI は二通りあるとかなりそうな気が。

↑ここまで書いとけば良かったかも

まあとりあえず様子見してみます。気持ちとしては reverse generics 先がいいんじゃないのと思ってるけど、別に ORT からでも手を付けてくれたら全然いいしね。↓はその通りだと思うし。

そういう判断は実装者に任せたらいいんではないかなあと思う

4:12 AM

ORT レベルじゃなくて、フルの reverse generics 持った言語って何かあるのかな？

実行時の動的な表現は無いけど

4:13 AM

C++のテンプレートは同じ事ができてる気がする

4:14 AM

Altenative Consideredの

4:14 AM

We could theoretically address the verbosity problem in its full generality and without introducing new type system features by allowing return types to be inferred, like C++14's or D's auto return types: func jsonBlob() -> auto { ... }

4:15 AM

あーまあ真の型がテンプレートとしては見えないけど展開されちゃうからfoo1()とfoo2()が相互に互換できたりするかも？

4:15 AM

でもまあ実装側から総称型が決まるって意味では似てます

それだと内部実装変えて型変わったときにコード壊れそう

そうですね、でも、C++はそもそも

4:16 AM

ジェネリックなコードは常にヘッダーで露出して、全部リコンパイルするのが大前提で

4:16 AM

そうじゃないやり方は存在してないので。

うーん、実装が露出してることと、型システム上で型が露出してることはまた別な気がする。

SwiftはC++の理想のバイナリに対してモジュール分割を導入してる点で新しいから

4:18 AM

そういう意味では先行事例は無い気がする

4:18 AM

そもそもSwiftが目指してる設計の方向性が完全に新しい。

戻り値 auto よく知らないけど、単に戻り値を記述しなくていいというレベルの簡略表現なわけではない？まあでも、実装が型を決めるという意味では通常の auto の dual になってるのか？

4:19 AM

Rust も ORT はできてるけど reverse generics はできてないのかな？

これはテンプレートのsugarになってるはずで

4:20 AM

https://cpprefjp.github.io/lang/cpp14/return_type_deduction_for_normal_functions.html

通常関数の戻り値型推論 - cpprefjp C++日本語リファ...

関数宣言の構文において、先頭の戻り値型をautoもしくはdecltype(auto)とすることで、戻り値の型が関数のreturn文から推論される。

4:20 AM

// C++14 template <class F> auto g(F f) { return f(); } (edited)

4:20 AM

//C++11 template <class F> auto g(F f) -> decltype(f()) { return f(); }

4:22 AM

↑あ、この例はreverseじゃないですね。

4:24 AM

static int static_value = 3; auto f() { return static_value; } ↑これは実装から決まってる

はじめまして。

1:10 PM

ゴールデンウィークに東京でSwift勉強会を開催するのですが、告知はどのチャンネルでするのがよいでしょうか？

generalかzatsuな気がします

zatsuで告知しました

1:06 AM

ありがとうございます！

>> 47 Joe_Groff

The runtime support I'm implementing is being done with an eye toward supporting generalized opaque types in the future, so if all goes well, there won't be further runtime deployment constraints on generalizing the feature (except maybe for debugger and tooling support).

(edited)

https://github.com/apple/swift/pull/22072

Opaque types with resilience by jckarter · Pull Request #22072 ·...

A continuation of #21137. This branch adds "proper" resilience support. Opaque types can now enter the SIL type system, and will be able to be represented at runtime with opaque accessors...

3:34 AM

↑これ手元でビルドしようとしてるけどなかなかうまくいかない。関連リポジトリのチェックアウトするリビジョンがまずいんだろうけど、どうすればいいんだ？

3:36 AM

$ utils/update-checkout --tag swift-DEVELOPMENT-SNAPSHOT-2018-11-30-a $ utils/build-script --xcode --debug --skip-build-benchmarks --jobs 4 ... Ld /Users/omochi/work/swift-source-ORT/build/Xcode-DebugAssert/swift-macosx-x86_64/Debug/lib/swift/macosx/x86_64/libswiftPhotos.dylib normal x86_64 clang: error: no such file or directory: '/Users/omochi/work/swift-source-ORT/build/Xcode-DebugAssert/swift-macosx-x86_64/Debug/lib/swift/macosx/x86_64/libswiftAVFoundation.dylib' clang: error: no such file or directory: '/Users/omochi/work/swift-source-ORT/build/Xcode-DebugAssert/swift-macosx-x86_64/Debug/lib/swift/macosx/x86_64/libswiftCoreLocation.dylib' clang: error: no such file or directory: '/Users/omochi/work/swift-source-ORT/build/Xcode-DebugAssert/swift-macosx-x86_64/Debug/lib/swift/macosx/x86_64/libswiftCoreMedia.dylib' ...

https://speakerdeck.com/hokuron/opaque-argument-type-with-type-system

Takuma Shimizu

Opaque Argument Type with type system

https://forums.swift.org/t/se-0258-property-delegates/23139

SE-0258: Property Delegates

The review of SE-0258: Property Delegates begins now and runs through April 23rd, 2019. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me...

SE-0258読んだ。複雑な仕様になったけどなんとか要望を全部まとめきった感じだ・・・

Proposal Returned to Pre-Review Discussion

https://forums.swift.org/t/se-0257-eliding-commas-from-multiline-expression-lists/22889/191

SE-0257: Eliding commas from multiline expression lists

Proposal Returned to Pre-Review Discussion Thank you to everyone who has participated in the review of this proposal. I am thrilled to see the amount of passion and energy everyone has in making Swift a better language. This has been a polarizing discussion. It also has no...

珍しい感じの展開だ

SE0250の決はまだかなあ

https://forums.swift.org/t/accepted-se-0255-implicit-returns-from-single-expression-functions/23581

[Accepted] SE-0255: Implicit Returns from Single-expression Functions

SE-0255 has been accepted.

https://twitter.com/omochimetaru/status/1120857885129318401 ↑好評っぽい

NA-VX8900R (@omochimetaru)

funcでも1行ならreturnが省略できるようになった #swift https://t.co/pWDXAfc6mu

4

2

3:21 AM

なにこれ・・・・

3:23 AM

https://github.com/apple/swift/blob/5f823fbaff525feb54d5e630b694b3bb6adc6a9c/lib/AST/ASTPrinter.cpp#L4234-L4252

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

3:25 AM

https://github.com/apple/swift/blob/e68a2330fe3bff37935d9cb6759aa8c9ccb9d2ea/lib/AST/ASTPrinter.cpp#L4249 なんですかねｗ「後で考えるとりあえずこれで」感

https://github.com/apple/swift/commit/399332b75b82cc31d609b04f8fb684d17d0a53b9

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

Parsable interface and type reconstruction support for opaque type...

When printing a swiftinterface, represent opaque result types using an attribute that refers to the mangled name of the defining decl for the opaque type. To turn this back into a reference to the ...

3:29 AM

https://github.com/apple/swift/pull/22072

Opaque types with resilience by jckarter · Pull Request #22072 ·...

A continuation of #21137. This branch adds "proper" resilience support. Opaque types can now enter the SIL type system, and will be able to be represented at runtime with opaque a...

3:29 AM

レビューではツッコミなしか〜

https://github.com/apple/swift/pull/24166

Sema: don't consider opaque types distinct for overloading purpose...

This is necessary because: func foo() -> some P func foo() -> some P theoretically defines two distinct return types, but there'd be no way to disambiguate them. Disallow ove...

3:46 AM

Opaque Result Type を持つ関数が、返り値の型のジェネリックシグネチャをmanglingに含めていなくて

3:46 AM

返り値オーバーロードができない（コンパイラクラッシュ）んだけど

3:46 AM

それを正式にsemaで禁止するようにするPR↑ (edited)

3:46 AM

未実装なのかと思って様子を見てたけど、意図的な設計だったっぽい

3:47 AM

I was also trying to prevent:

func foo() -> some P func foo() -> some Q

since there would still be no way to disambiguate these.

(edited)

3:47 AM

これ正しいのかなぁ

3:47 AM

特にGenericsの場合はシグネチャがオーバーロードに絡んでるんだけど

3:48 AM

ORTがReverse Genericsのsugarであるという解釈の元で

3:48 AM

おかしくならんのだろうか

https://forums.swift.org/t/adding-more-data-structures-to-the-standard-library/23651 私ももう少しリッチなデータ構造が標準ライブラリにあればいいと思う。

Adding more data structures to the standard library

I'm studying for job interviews for Swift positions by completing code problems. By far the most painful part of this preparation is the dismal state of data structures in Swift. If I were programming in Java (which I really rather wouldn't), I would have easy access to... ...

以前OrderdDictがほしくて作ったけど、計測したらオーバーヘッドが大きくて意味なかったんですよね〜実装が悪いのもあるとしても、そういうケースは多そうと思った

10:56 AM

その時の意味が出てくるのは要素数5000件ぐらいでした

OrderdDictが要素数に応じてパフォーマンスが劣化していくのは仕方ないんじゃないかな。実際に標準ライブラリに入ったときにどれくらいになるかはともかく、自分で作るしかないよりは、選べる方がいいんじゃないかな。とにかくLinkedListくらいは入ってほしい。

あいえ、5000件を超えるとパフォーマンスが良くなるという意味です

12:23 PM

それより小さい時はタプルのArrayの方が早いんです。

12:26 PM

公式に提供されるのは望ましいけど、標準ライブラリだと外せないから、外部パッケージがよいと思うんですけど

へえ。5000件くらいまでならHashより速いのか。 (edited)

Hashと、リンクリストのためのメモリアロケーションがかなり遅いですね Arrayはメモリ局所性が効いててかなり早い

特殊なやつは別ライブラリでいいんですけど、今のビルトインのデータ構造はさすがにプリミティブすぎると思うので、もう少し増えていいと思います。

まあ、たしかに、そうですね。いまはArray Dict Setしかないのは、粗いですね

1

Queue がほしいと思うことはよくありますね。

https://forums.swift.org/t/announcing-our-google-summer-of-code-2019-students/24225

Announcing our Google Summer of Code 2019 students

It is my pleasure to announce our two GSoC students for 2019! Don Cung (@cungd) will be working on Scalability benchmarks for the Swift Standard Library with Karoy Lorentey (@lorentey) as his mentor. Jan Svoboda (@jansvoboda11) will be working on Integration of libSynta...

1:07 AM

Jan Svoboda (@jansvoboda11) will be working on Integration of libSyntax with the compiler pipeline 9 with Rintaro Ishizaki (@rintaro) as his mentor.

1:09 AM

りんたろープロジェクトめっちゃ大変そう

1:12 AM

型付けされたSwiftSyntaxがあるといろんな応用がありそうで期待

唯一 Hard が付いてるｗ Expected difficulty Medium/Hard https://swift.org/gsoc2019/#integration-of-libsyntax-with-the-rest-of-the-compiler-pipeline

https://devblogs.microsoft.com/dotnet/introducing-net-5/

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

頑張ってメンターやります

1

4

Introducing .NET 5 | .NET Blog

Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family. There will be just one .NET going forward, and you will be able to use it to target Windows,

3:29 AM

Objective-C and Swift interoperability will be supported on multiple operating systems.

3:29 AM

すごいことかいてある

行列型も欲しいですかね（特にこれからARとか推していくのに、3Dが入ってきて行列式を頑張って配列で書くとパフォーマンスとセキュリティーのバランスが難しい

僕はGLKitのGLKMatrix4を使ってます Linuxだと無いですね

でもmultiple operating systemsというのは、macOSとiOSだけでもいいのか…

あ、たしかに。 Windowsを想定してたけどｗ

https://forums.swift.org/t/se-0260-library-evolution-for-stable-abis/24260

SE-0260: Library Evolution for Stable ABIs

Hi Swift Community, The review of SE-0260: Library Evolution for Stable ABIs begins now and runs through May 21st, 2019. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep you...

1:06 AM

LibraryEvolutionのレビュー

「新しくLibraryEvolutionモードでのビルド」が追加されて LE無効（デフォルト）・enumはfrozen ・structはfrozen LE有効（標準ライブラリはこっち）・enumはresilent ・structはresilent になり、LE有効時において、@frozen をつけると、enumやstructをfrozenにできる

1:43 AM

iOSアプリの場合は書き出されたアプリに内包されるライブラリだけを後から差し替えることはないから関係なさそうだな

この辺の値型のresiliencyに関してはC/C++/Rustはやってないので、柔軟さと高速さを両立するSwiftらしさを感じる

Set同士は + で足せないんだな。

できても良さそう

そうすると * で intersection をとるんでしょうか？

論理積和と対応するから&|のほうが良さそう？ (edited)

なるほど。

∪ や ∩ が良い？

7:12 AM

∧ や ∨ は & （ && ）や | （ || ）なので ∪ や ∩ だけあっても微妙そうだな・・・。

英字で一発で入力できないので運用上厳しそうですね…

謎記号が増える理由…

https://forums.swift.org/t/receiver-closures/24020

Receiver Closures

Receiver Closures Hello, I would like to get some feedback on a pitch idea. Idea allow specifying the receiver of a closure. (what a closure is being called on) This would modify how self behaves inside a closure body. Kotlin already has something similar Higher-Order Fun...

6:01 AM

Kotlinにあるようなレシーバクロージャの話ラムダ式がselfを引数にとって、その中でselfが省略できる

Xcode 10.2 (Swift 5)で U+FEFF (ZERO WIDTH NO-BREAK SPACE)から始まるStringをNSStringに変換するとU+FEFFが消えるのですが、これってなんなのかわかる方いらっしゃいます？バグ？

import Foundation let bom = "\u{feff}" bom.count // -> 1 (bom + "abc").count // -> 4 NSString(string: bom).length // -> 0 NSString(string: bom + "abc").length // -> 3 NSString(string: "a" + bom + "bc").length // -> 4

先頭にある時だけ消えちゃうんですね

そう、途中とかだと消えない。

10:55 PM

U+FEFFはいわゆるUTF8のBOMなんでなんかへんな処理が走ってそう。

UTF-8は本当はBOMは無いので、普通のUTF-16のBOMですね

1:44 AM

BOMは先頭にあるときだけエンコードを示す非コンテンツ部分だから、初期化時に捨てるのは正しい気もするけど、 "a"+ bomのときに消えないのはStringの結合処理とNSStringの初期化処理でポリシーがバラバラそう

文字列連結で(UTF8)BOMが消えないのはそのせいで2chブラウザのSevenFourがバグっててパッチ書いた記憶がある

7:11 AM

仕様？

bugsで聞いてみるのが良さそうだなあ

2chのスレが残ってた！文字列連結は全然関係なかった。 intel mac移行時のエンディアン問題だった。すみません。

import Foundation struct HB : Decodable { var heartbeatInterval: Int enum CodingKeys : String, CodingKey { case heartbeatInterval = "heartbeat_interval" } } let json = #"{ "heartbeat_interval": 30 }"# let d = JSONDecoder() d.keyDecodingStrategy = .convertFromSnakeCase let data = json.data(using: .utf8)! let x = try d.decode(HB.self, from: data) dump(x)

1:14 PM

↑CodingKeysでスネークケースにするのと、keyDecodingStrategyでスネークケースにするのを同時に使うと、デコードに失敗するんだけど、どういう考え方なんだ・・・？

1:15 PM

両方考慮される結果、CodingKeysはスネークケースを期待してて、Decoder側はJSONのスネークケースから変換されたキャメルケースを投げてて、ミスマッチする？

なんか最近 Optional<X> を書くところで X のスタティックメンバがちゃんと候補予測される気がする

Codableのこの前ハマりました…heartbeatIntervalをCodingKeysのrawValueにしないといけないんですよねこれ

やっぱりそうなのか〜

7:18 AM

あ、自分の件はconvertFromSnakeCaseを使わない方で対処しました。

僕もconvertFrom~~で何度か痛い目に遭ったので使わない方向に寄せてます

この前OSSFoundationのバグ直してたね。 (edited)

それです

7:24 AM

JSONDecoder側でキーのケースを決めるべきなのか？という気持ちになってきた

https://forums.swift.org/t/accepted-with-modification-se-0253-callable-values-of-user-defined-nominal-types/24605

[Accepted with Modification] SE-0253 - Callable values of user-def...

The second review of SE-0253 - Callable values of user-defined nominal types ran through May 13. Compared to the first round, the feedback was relatively light, mostly focused on the options of how to spell the callable member, more discussions of a @callable attribute, man...

3:40 AM

static callableが通ったけど func callFunction になったらしくて

3:40 AM

モヤモヤコメントがついてる。

3:41 AM

曰く func call だと既存の利用と衝突して予期せずこの機能が発動しちゃうのを避けるためらしい

初期の提案＋@dynamicCallable側を見直して

5:58 AM

init() {} subscript() {} call() {} dynamicallyCall() {}

5:59 AM

となってくれるのが個人的希望でした。

最初は call() {} だったけど後に func call() {} になりましたね

ですね。

@swift-5.1.5

protocol P { func print() } extension Int : P { func print() { Swift.print("Int \(self)") } } protocol PHolder { associatedtype PType: P func take1() -> PType func take2() -> PType } struct S : PHolder { func take1() -> some P { return 3 } func take2() -> some P { return 2 } }

exit status: 1 with stderr:

<stdin>:16:8: error: type 'S' does not conform to protocol 'PHolder' struct S : PHolder { ^ <stdin>:10:20: note: ambiguous inference of associated type 'PType': 'some P' vs. 'some P' associatedtype PType: P ^ <stdin>:20:10: note: matching requirement 'take2()' to this declaration inferred associated type to 'some P' func take2() -> some P { ^ <stdin>:17:10: note: matching requirement 'take1()' to this declaration inferred associated type to 'some P' func take1() -> some P { ^

思ってたのと違う・・・

@swift-5.1.5 let strings: some Collection = ["hello", "world"]

exit status: 1 with stderr:

<stdin>:1:32: error: cannot convert value of type '[String]' to specified type 'some Collection' let strings: some Collection = ["hello", "world"] ^~~~~~~~~~~~~~~~~~ as! some Collection

Proposalに出てくるコードすら通らないんだけど Status: Implemented (Swift 5.1) になってるのどういうことなんだ

@swift-5.1.5 func foo() -> some BinaryInteger { return 219 } var x = foo() x = 912 print(x)

912

@swift-5.1.5 func foo() -> some BinaryInteger { return 219 } var x = foo() x = Int(912) print(x)

exit status: 1 with stderr:

<stdin>:3:5: error: cannot assign value of type 'Int' to type 'some BinaryInteger' x = Int(912) ^~~~~~~~ some BinaryInteger( )

なんか最近 Optional<X> を書くところで X のスタティックメンバがちゃんと候補予測される気がする

Implicit member expression や enum element pattern 周りのコード補完に関しては 5.0 でかなり修正を加えていて、マシになってるとは思いますが、まだ改善中です。コード補完で必要な候補が出ない、使えない候補が出てくるなど、全部バグなので bugs に報告もらえれば嬉しいです！

2

やっぱ改良されてたんですね、ありがとうございます！

@swift-5.0.3

public class BaseView { } public class GenericView<T>: BaseView { } public class FinalView: GenericView<ContentForTheView> { } public class ContentForTheView { } extension ContentForTheView: InfoNeededByControllers { } public protocol ConditionallyConformed { } public protocol InfoNeededByControllers { } extension GenericView: ConditionallyConformed where T: InfoNeededByControllers { } open class BaseGenericController<T> where T: BaseView & ConditionallyConformed { } open class FinalController: BaseGenericController<FinalView> { public override init() { } } print(FinalController())

exit status: 134 with no output

すごいバグだな

5:58 AM

failed to demangle superclass of FinalController from mangled name '\255\375\377\377y\223\374\377\377G' 2019-05-24 14:57:44.734494+0900 Sandbox_20190524145301[51985:24831300] failed to demangle superclass of FinalController from mangled name '\^A\M--\M-}\M^?\M^?y\^A\M^S\M-|\M^?\M^?G'

5:58 AM

↑手元

RelativePointerのオフセットが間違ってる？

ランタイム関数のswift_conformsToProtocolが間違ってる事に起因するらしい

6:05 AM

https://github.com/apple/swift/pull/25030

Introduce a backward-deployment library for SR-10600. by jckarter...

Build a static archive that can be linked into executables and take advantage of the Swift runtime's hooking mechanism to work around the issue Doug fixed in #24759. The Swift 5.0 version o...

__swift_hook ってなんですか？

ふっふっふ

6:15 AM

なんとlibSwiftCore.dylibには

6:15 AM

ランタイム関数を差し替える機能があるのだ

www

6:16 AM

そんなハチャメチャ機能が必要になるタイミングあるんですか

それが初めて必要になったのがこのPRで

6:17 AM

Swift5.0ランタイムのバグを、パッチ版にすり替えるようにしてる。

6:17 AM

ただ、まあバグ修正で使うのは本命じゃなくて

6:17 AM

型システムが強化されたりしたときに

あー、ランタイム側はsharedになったからか

実行時キャストとかの処理をアップグレードすることを想定しているっぽい

6:18 AM

そう、OSに同梱しちゃってるから

6:18 AM

過去に出荷した仕様で永久にロックされないようにしてある

なるほど

このバグ、Xcode 9の時代から存在してるんですよね… https://bugs.swift.org/browse/SR-10442 https://bugs.swift.org/browse/SR-5466

Arrayをラップしてサイズ変更不可能なFixedSizeArrayを作ろうとしてるんですが、 memcpy(&array1, array2, count)のようにUnsafe*Pointerで渡すところだけができない気がしています。言語的に拡張できないコンパイラ組み込みの仕様だと思っていますが合っているでしょうか？

@t.ae 構文の話でなく渡す手段がほしいという意味であれば withUnsafePointer とか使ってできそうだけど構文の話かな？

構文の話です。そのまま渡せるほうが良いと思うので。

2:49 AM

UnsafePointerだけならarrayのゲッタを生やせばいいんですがUnsafeMutablePointerは対応できないですね。

withUnsafeMutablePointer を実装するか、 array セッターの willSet とかで count が変わってないことを precondition で確かめるかどちらかかな。

arrayセッタ形式は試してみたことあるんですが書き込みが多いと結構な負荷になるんですよね。

func memcpy<Element>(_ a: inout FixedSizeArray<Element>, _ b: FixedSizeArray<Element>) みたいなオーバーロードを作るとか。

ライブラリとして公開することを考えると一般の場合で使えないとなので特別対応はだめですね。

↑のオーバーロードもライブラリに含めるのは？

2:56 AM

あー

2:56 AM

memcpy だけじゃないって意味か

はい。

うーん、 withUnsafePointer と withUnsafeMutablePointer を FixedSizeArray に実装するのがいいんじゃないかなぁ。 (edited)

ところでこいつはImage型のバッファに使おうと思っていたんですが、Image.buffer自体を書き換えられた場合に対応できないことに気付いたので結局頓挫しました。

2:58 AM

この試行は以前にも同じことをした気がする……

Image のバッファだったらセッター露出しなければ Array でいいんじゃないの？ (edited)

まぁそうなんですが

3:00 AM

・現状@inlinable public internal(set) が使えない・書き込みのために専用のsubscriptを生やすのはちょっと不格好

3:01 AM

なのでどうにかできないかと考えている次第です。

SwiftImage （旧 EasyImagy ）では Image に withUnsafeMutableBufferPointer とか付けてるよ。生でピクセル配列を扱いたいときとか用に。 https://github.com/koher/swift-image/blob/dev-0.7.0/Sources/EasyImagy/Image.swift#L58-L60

koher/swift-image

SwiftImage: A Swift library for image processing with Swifty APIs - koher/swift-image

それはもちろん僕もつけてます。

3:02 AM

けどユーザーフレンドリーではないですよね？

そうかなぁ。安全でない操作をする場合はむしろわかりやすい気がする。

3:03 AM

得られたポインタのライフサイクルもわかりやすいし。

たとえばimage1の画素値を同サイズのimage2の画素値に足したい場合 image1.with~ { bp1 in image2.with~ { bp2 oin for i in 0..<count { bp1[i] += bp2[i] } } } (edited)

3:04 AM

のような多重ネストになるので (edited)

通常は露出してはいけない内部的な存在を露出してパフォーマンス上のメリットを得るわけだから、そのことが API 名からもわかりやすく、クロージャにすることでライフサイクルもわかりやすくするのは良いことかと。

露出してはいけないという視点を入れるとそうですね……悩ましい

bp[2] は bp2[i] の間違い？

です。

↑のような用途では += を提供するという方法もあるけど、画像に対して += を提供するのはあまり Swifty じゃない気がしてるのと、任意の演算をユーザー側で実現することができないから、 zip + (map or inout バージョンの map ) をパフォーマンスロスなく実現できる高階メソッドを提供するのがいいんじゃないかと最近思ってる。

3:08 AM

RGBA 型に + が定義されてるのはまだいいんだけど、 Image だとサイズが合わないと precondition に引っかかるのが辛い。

3:08 AM

サイズも型にできればいいけど。

3:09 AM

それか Swift for TensorFlow みたいな？

ぼくのは+=導入してますね

3:09 AM

S4TFのどうなってるか知らないです

SwiftImage は導入してたけど、なくそうかと検討中。 (edited)

3:10 AM

Swift for TensorFlow って行列のかけ算とかコンパイラが解析して型が合わない場合はエラーにするとかやろうとしてるんじゃなかったかな。 (edited)

ああ、それは聞いた気がします。

前試したときはまだできてなさそうだったけど、今はできてるのかな。

依存型できたとしてSwift本体側に入るのはいつになるか……

でもそういう部分は本体に戻すことを目標にしてたはずなので、可能性はあるかと。

3:14 AM

Finally, while TensorFlow is the reason we built this infrastructure, its algorithms are independent of TensorFlow itself: the same compiler transformation can extract any computation that executes asynchronously from the host program while communicating through sends and receives. This is useful and can be applied to anything that represents computation as a graph, including other ML frameworks, other kinds of accelerators (for cryptography, graphics, transcoding, etc), and general distributed systems programming models based on graph abstractions. We are interested in exploring new applications of this algorithm in the future.

https://github.com/tensorflow/swift/blob/master/docs/DesignOverview.md#graph-program-extraction (edited)

tensorflow/swift

Swift for TensorFlow Project Home Page. Contribute to tensorflow/swift development by creating an account on GitHub.

3:15 AM

Swift に戻したいとはここには書いてないか。でも一般的な用途まで視野には入れてるっぽい。

言語的に拡張できないコンパイラ組み込みの仕様だと思っていますが合っているでしょうか？

Arrayのポインタ化は特別対応でユーザ対応はできない

3:21 AM

普通に pointer プロパティを生やすのは？

pointer プロパティなら withUnsafe***Pointer 系の方が安全なんじゃない？

プロパティとして出すのはSwift的にはよろしくないのでは。

でも固定サイズなんですよね？

3:22 AM

ずっとアドレス変わらない。

CoW で変わるんじゃない？

ArrayとかDataとかがwithXXXなのは

3:23 AM

そのストレージ領域が実際に永続保証されていないからで

固定サイズだけど set はされるので。

@koher と同じ考えです。

CoWで変わるってどういうことです？値型ってこと？

少なくとも僕が話していたのは値型ですね。

値型ならだめですね

あと、↓とかもあり得る。 let p: UnsafeBufferPointer<Int> do { let a: FixedSizeArray<Int> = ... p = a.pointer } // 解放 p[0] // 解放済み (edited)

そうですねえ

withUnsafeMutableBufferPointers とかあればいいのかなぁ。 withUnsafeMutableBufferPointers(of: [a, b]) { pointers in for i in 0..<count { pointers[0][i] += pointers[1][i] } } (edited)

3:35 AM

あ、 Mutable が抜けた

3:35 AM

Buffer もいるかな。

3:36 AM

& じゃないとダメか。

さらにUnsafePointerとUnsafeMutablePointerも分けたいよな……とか考えてそのアプローチは保留してます。

そうだねぇ・・・。今は b は Mutable じゃなくていいもんね。

ずっと上の話ですけどArrayにset/willSet/didSet生やすのって newValueやoldValueのためにarray[i] = 0みたいな変更でもまるごとコピーされちゃって負荷大きいんですよね。 count不変だけならwillSetでカウントどっかに保存してdidSetでカウント比較とかできないかと思ったんですが newValue/oldValueに触れてなくても重いのでコピーされてそう。

3:42 AM

O(1)を期待してアクセスしたのにO(n)になっているということがありそう。

newValueやoldValueのためにarray[i] = 0みたいな変更でもまるごとコピーされちゃって負荷大きいんですよね。

これはそうですねただ、arrayがcomputed propertyだったとして owner.array[0] = 0 みたいなケースでは CoW が効いてないかなあ (edited)

4:05 AM

O(1)を期待してアクセスしたのにO(n)になっているということがありそう。

ありそうなので、なったら困るやつではやりたくないですね。

func testFloor1() { func f(array: inout [Double]) { for i in 0..<array.count { array[i] = floor(array[i]) } } var array = [Double](repeating: 1, count: 3840*2160*4) measure { // 58ms f(array: &array) } } func testFloor2() { func f<T: FloatingPoint>(array: inout [T]) { for i in 0..<array.count { array[i] = floor(array[i]) } } var array = [Double](repeating: 1, count: 3840*2160*4) measure { // 264ms f(array: &array) } }

floorがGenericかどうかで5倍も差がつく……

floorの呼び出し自体もFloatingPoint protocolのwitness呼び出しかな？

Foundationにfloorが複数あるんですよね。 doubleをとるやつとFPをとるやつ

5倍ってスケールはまあそのくらいな感じはする

https://github.com/apple/swift-evolution/blob/master/proposals/0246-mathable.md これにも入らないので独自にプロトコル作って頑張るしか (edited)

https://github.com/apple/swift/blob/master/stdlib/public/Platform/tgmath.swift.gyb#L47-L50

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

どういうこと？

8:42 AM

実用面で言えば-Oで解決する話ではない？ (edited)

ではないです。

8:42 AM

↑のテスト結果はリリースビルドでの結果です。

[omochi@omochi-iMac-PC43 fp]$ swift -O a.swift 0.02524399757385254 0.24626600742340088

8:45 AM

確かに手元で10倍差ついた

FloatingPointバージョンはビット数やなんかに依存しない実装になっててそれで遅いって感じでしょうか。 (edited)

そもそも [Double]にspecializeされてないのか？

8:48 AM

いや、specializeはされてる

silが全然違って参考にならない……

testFloor1の方は、fごとinline化されてる

fは@inline(never)つけないとでしたね。

inline(never)つけたら、testFloor側は同じになった

[omochi@omochi-iMac-PC43 fp]$ diff testFloor1.sil testFloor2.sil 1,2c1,2 < // testFloor1() < sil hidden @$s1a10testFloor1yyF : $@convention(thin) () -> () { --- > // testFloor2() > sil hidden @$s1a10testFloor2yyF : $@convention(thin) () -> () { 52,53c52,53 < // function_ref f1(array:) < %40 = function_ref @$s1a2f15arrayySaySdGz_tF : $@convention(thin) (@inout Array<Double>) -> () // user: %41 --- > // function_ref specialized f2<A>(array:) > %40 = function_ref @$s1a2f25arrayySayxGz_tSFRzlFSd_Tg5 : $@convention(thin) (@inout Array<Double>) -> () // user: %41 105c105 < } // end sil function '$s1a10testFloor1yyF' \ No newline at end of file --- > } // end sil function '$s1a10testFloor2yyF' \ No newline at end of file

8:56 AM

f1は80行、とspecialized f2は200行でだいぶ違うな

Doubleのほうはfloor関係のこれしかなさそうですね。 // floor sil [readnone] [clang floor] @floor : $@convention(c) (Double) -> Double

8:57 AM

FPは↑がないので全く違う内容が実行されていそう。

specialized f2は

 // function_ref Double._roundSlowPath(_:) %112 = function_ref @$sSd14_roundSlowPathyys25FloatingPointRoundingRuleOF : $@convention(method) (@in_guaranteed FloatingPointRoundingRule, @inout Double) -> () // user: %113

8:58 AM

いかにも遅そうな関数が呼ばれてる

FPには.round(RoundingRule)ってやつが生えてるのでそれにいってそうですね。

9:00 AM

Doubleの場合もfloorじゃなくてarray[i].round(.down)を使ったら同程度の速度になるみたいです。

FloatingPoint.floorの実装が見つけられない。

9:04 AM

https://github.com/apple/swift/blob/e9d4687e31a3ae8e90604d3b15bf8b241479c211/stdlib/public/core/FloatingPointTypes.swift.gyb#L1020-L1042

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

9:04 AM

これ？？

みたいですね。

tgmathってのはCのジェネリックなマクロセットらしい。

9:05 AM

同じ中身をSwiftソースで書いたものかな。

9:07 AM

あー

9:08 AM

_roundSlowPathは呼ばれてなさそうだ

9:08 AM

https://github.com/apple/swift/pull/25263

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

9:08 AM

 public mutating func round(_ rule: FloatingPointRoundingRule) { switch rule { case .toNearestOrAwayFromZero: _value = Builtin.int_round_FPIEEE${bits}(_value) case .toNearestOrEven: _value = Builtin.int_rint_FPIEEE${bits}(_value) case .towardZero: _value = Builtin.int_trunc_FPIEEE${bits}(_value) case .awayFromZero: if sign == .minus { _value = Builtin.int_floor_FPIEEE${bits}(_value) } else { _value = Builtin.int_ceil_FPIEEE${bits}(_value) } case .up: _value = Builtin.int_ceil_FPIEEE${bits}(_value) case .down: _value = Builtin.int_floor_FPIEEE${bits}(_value) @unknown default: self._roundSlowPath(rule) } }

SILにでてきてるのそのままですね。

このswitch-caseが、f2にinline展開されてる

9:08 AM

このdefault-caseのコードが、SILで見えているんだ。

9:08 AM

これ、めちゃくちゃいけてないね

9:09 AM

呼び出してるのはfloorなのに、一度roundの呼び出しになって

9:09 AM

/// // Equivalent to the C 'floor' function: /// var z = 6.5 /// z.round(.down) /// // z == 6.0

9:09 AM

このモードに分岐で突入してから本当の関数を呼ぶ

9:10 AM

最適化的には定数伝搬による分岐削除ができてれば、直接Builtin.int_floor_FPIEEE${bits}の呼び出しにできそうなはずだけど

9:10 AM

Doubleの場合もfloorじゃなくてarray[i].round(.down)を使ったら同程度の速度になるみたいです。

まあ結論として

9:11 AM

「FloatingPoint.floorは特殊化されたとしても遅い」

9:11 AM

って事になるね。。

9:11 AM

これは共有したほうが良さそう・・・

ですね。ベクター扱うライブラリだとFloat/Double用に独自にプロトコル作るほうが良さそうです。

9:11 AM

bugsですかね？

悩ましいね。とりあえずbugsは出して、解決案が浮かんだらそれを引用しつつDiscussionかなあ

9:13 AM

自分でfloor2とかをFloatingPointに実装して

9:13 AM

デフォルトではfloorに流しておいて

9:13 AM

FloatとDoubleだけは自分で早いやつに向けておけば

9:13 AM

独自プロトコルはいらんのじゃない？

それで良さそうですね。

あっ

9:14 AM

メソッドじゃねえのかこれ

トップレベルですけど内部的に使う分にはまぁ……

手元のワークアラウンドは組めそうだけどキレイにいかねえな。

https://bugs.swift.org/browse/SR-8746 探してみたらroundedで同じ問題が報告されてました。

9:41 AM

去年の9月って結構放置されてるのでは……

9:42 AM

しかもrintaroさんだ

さすりん案件だ

9:48 AM

We were getting that at the time that I implemented these, so this looks like a regression.

9:48 AM

以前は最適化できてたのか。

extension FloatingPoint { @inlinable mutating func round_(_ rule: FloatingPointRoundingRule) { if let zelf = self as? Float { switch rule { default: self.round(rule) } } else if let zelf = self as? Double { switch rule { case .towardZero: self = trunc(zelf) as! Self case .down: self = floor(zelf) as! Self case .up: self = ceil(zelf) as! Self case .toNearestOrAwayFromZero: self = Darwin.round(zelf) as! Self default: self.round(rule) } } }

こんなかんじに書いただけではまだ遅いですね。速度が同じくらいになったのでやっぱり分岐が消えてなさそう？

12:53 AM

やっぱprotocol作るしかなさそうですね。

12:56 AM

と思ったけどextension FloatinPoint: Roundableはできないか……

@inlinable func floor_<T: FloatingPoint>(_ x: T) -> T { if let x = x as? Float { return floorf(x) as! T } else if let x = x as? Double { return floor(x) as! T } else { return floor(x) } }

この粒度なら高速になるのでこのレベルで書くか……

func testRoundArray() { var array = [Double](repeating: 1.1, count: 3840*2160*4) measure { // 56ms for i in 0..<array.count { array[i] = floor(array[i]) } XCTAssertEqual(array.last!, 1) } } func testRoundSIMDCast() { var array = [Double](repeating: 1.1, count: 3840*2160*4) measure { // 29ms array.withUnsafeMutableBufferPointer { bp in bp.baseAddress!.withMemoryRebound(to: SIMD4<Double>.self, capacity: bp.count/4) { var p = $0 for _ in 0..<bp.count/4 { p.pointee = floor(p.pointee) p += 1 } } } XCTAssertEqual(array.last!, 1) } }

昨日SILみた段階でそんな感じがしてましたがfloorのsimd最適化はされないみたいですね。 simdにfloorとceilだけ定義されててroundその他が無いのも謎……

Swift5からSIMDの型が使えるようになったんですね。

こんにちは！

2

[WIP] Parameterized extensions by Azoy · Pull Request #25263 · a...

Refer to: Generics Manifesto. I'm not really sure exactly what to discuss here, but right now this is a bare implementation of parameterized extensions. There might be some more that this n...

8:09 AM

Azoy氏がparameterized extension作ってる！

https://forums.swift.org/t/parameterized-extensions/25563

Parameterized Extensions

Parameterized Extensions Proposal: SE-NNNN Author: Alejandro Alonso Review Manager: TBD Status: Pitching Implementation: apple/swift#25263 Introduction Hello Evolution, this is my first draft at a proposal for Parameterized Extensions. I would greatly appreciate any fee...

Azoy氏がピッチを！

同じ定義の別記法が産まれて、それがABI非互換ってのはよくないなあ

https://twitter.com/rxwei/status/1139339115990638592?s=21

Richard Wei (@rxwei)

Taking differentiable programming one step closer to Swift Evolution, I wrote a Swift differentiable programming design overview! Everyone is welcome to comment on the Google doc (no login required) and join the open design review tomorrow at 9AM PDT! https://t.co/DuNRtQgH...

1:22 AM

自動微分、本家に入れるモチベあるんですね機械学習意外で用途なさそうだけどどうなるかなあ

https://forums.swift.org/t/se-0258-property-wrappers-second-review/25843

SE-0258: Property Wrappers (second review)

The review of SE-0258: Property Wrappers (previously called "Property Delegates") begins now and runs through June 24th, 2019. This is the second review of SE-0258, which was returned for revision subsequent to its first review. Doug Gregor has provided the following list o...

特別なプロパティの名前がwrappedValueとwrapperValueに変わってるのは良いですね

https://forums.swift.org/t/pre-pre-pitch-swift-differentiable-programming-design-overview/25992

Pre-pre-pitch: Swift Differentiable Programming Design Overview

Differentiable programming is a language feature that we've been incubating for (the official) Swift as part of the Swift for TensorFlow project. After over a year's evolution and experimentation with real-world differentiable programming problems such as machine learning, t...

1:13 AM

本家に自動微分の投稿が！

1:16 AM

機械学習意外で役に立ちそうに無いけど、受け入れられるのかなあ

4TFと本家を統合するモチベーションがあるのかな

そのへんの言及どうだったかなあ

4:34 AM

ラトナーがdynamicCallableの話したときにはジョーグロフとスラバが結構反対意見も出してたし、

4:35 AM

ラトナーとコアチームでもこのあたりのビジョンは違ってそうだしどう進んでいくんだろうね

このスレの書き込みが少ないの、困惑してる人が多いんかな

お気持ちを書き込んでみた

お返事があって、Swift 4 TFは TensorFlow特化の立ち位置で今後も維持されて、完全には統合されないあくまでその過程で産まれる共通資産だけマージしていく機械学習以外にもいろいろ活用できるんじゃいとのこと

2

できるんじゃいw

勢いを感じたので・・・原文は適宜確認してや

@swift-5.1.5

var dict: [Int: () -> Int] = [:] for i in 0..<3 { dict[i] = { [i] in return i } } for (i, a) in dict { print("\(i) => \(a())") }

1 => 1 0 => 0 2 => 2

Swiftのescape captureってループカウンタがちゃんとループごとに束縛されてるんだ。

これ前に試した気がする。JSかなんかは共通なんよね。

はい。Rubyも共通だった気がする。

JSの場合ってスコープごとキャプチャされるんだっけ？（他の変数とかもキャプチャしちゃってリークしかねない？）

そのような話は聞いた事がないです

PropertyWrapperのCodingKeyを調整しようとしても、 enumのcase名に $ が使えないのでできない気がする

なるほど、実際にデコードするのはラップされた型だから$が必要なのか

@CodingKey("user_name") var userName: String @CodingProxy(Vector3ArrayProxy()) var position: Vector3 とかできたらいいなと思ってたんだけど。

https://github.com/apple/swift/pull/25129

[SE-0258] Minor adjustments to bring implementation closer to the ...

Three minor adjustments to the property delegates^Wwrappers implementation to bring it closer to the proposal: Ensure that non-final properties can have attached delegates/wrappers Adjust the name...

9:01 AM

シンセサイズされるコードは$無しを使うようにしてるっぽい

おお。

9:02 AM

XcodeBeta2で試してた。

9:03 AM

そうするとキー名の変更はCodingKeysでできるから、Proxyは作り込めばできそうだな

@CodingKey難しく無いですか？

そっちは無理だと思う

9:06 AM

キー名変更はenum CodingKeysでコレまで通りやるしかない

悲しい

パッチしたいだけでも全部書かないといけないのがな。

1

https://forums.swift.org/t/se-0258-property-wrappers-second-review/25843/293

SE-0258: Property Wrappers (second review)

This has already been fixed in the compiler to align with the proposal under review, but the changes didn't make it into Xcode 11 beta 1 or 2. Doug

9:54 AM

ちょうど今日話題に出てましたね

あっ、ほんとだ

おぉタイムリーだ

このスレ長すぎて読むの諦めた

@t.ae マージされたね https://github.com/apple/swift/pull/25658

Make AdditiveArithmetic.zero @_transparent by t-ae · Pull Request...

Make default implementation of AdditiveArithmetic.zero @_transparent. Seems it is simply overlooked.

1

https://github.com/apple/swift/pull/25781#issuecomment-505793395

[SE-0258] Implement revision #3 of property wrappers by DougGregor...

Implement the upcoming third revision of the property wrappers proposal, which includes the following changes: The private backing storage property is always named with a leading underscore, e.g.,...

1:18 AM

また名前が変わった！？

1:18 AM

>wrapperValue is renamed to projectedValue

w

https://github.com/apple/swift-evolution/pull/1054

[SE-0258] Revision #3 of the proposal, addressing feedback from re...

Changes from the second reviewed version The synthesized storage property is always named with a leading _ and is always private. The wrapperValue property has been renamed to projectedValue to ma...

1:24 AM

wrapperValueでラッパー本体を差し替えるのをやめてラッパー本体は常にアンスコ名、projectedValueがあると$付きが生えるってなったのかな？？

てか6.24までのレビューが閉じずにプロポーザル更新されるのアグレッシブだなあ

https://forums.swift.org/t/se-0258-property-wrappers-third-review/26399

SE-0258: Property Wrappers (third review)

The review of SE-0258: Property Wrappers (previously called "Property Delegates") begins now and runs through July 3rd, 2019. This is the third review of SE-0258. After the first review, the Core Team requested further development of the proposal to address some concerns rai...

4:45 AM

第3回レビュー開始だ

https://twitter.com/rxwei/status/1146134869090553856

Richard Wei (@rxwei)

Sequential coming to Swift for TensorFlow via function builders :) cc @eaplatanios https://t.co/7Ca0BX71tO

Likes

126

3:50 AM

Function Builderの用例として、ニューラルネットの構造定義に使うの面白いですね。

Swift 5.1では、Function Builderはプライベート機能扱いになるらしい。 https://forums.swift.org/t/function-builders/25167/341

Function builders

This bug will be fixed in the 5.1 release (https://github.com/apple/swift/pull/25944). Note that unfortunately function builders will remain a private feature in 5.1; we'll have to maintain compatibility with existing code that uses the @_functionBuilder attribute, but we ca...

あら。

https://forums.swift.org/t/se-0261-identifiable-protocol/26602

SE-0261: Identifiable Protocol

The review of SE-0261: Identifiable Protocol begins now and runs through July 12, 2019. The proposal is written by @anandabits and @kylemacomber. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if y...

9:26 AM

SwiftUIのIdentifiable protocolを標準ライブラリに持ってくる提案

中身まだ読んでないけど、 ID が Hashable でないといけない制約は強すぎないかな？一般的な DB はハッシュテーブルじゃなくてツリーだし。 Equatable で良さそうな気が。そのあたりのも書いてあるのかな？後で読んでみよう。

元がCombineIdentifierで、それをstdlibへ持って来ようという始まりだから、Hashableを外したら意味が無いのでは。 https://developer.apple.com/documentation/combine/combineidentifier

proposalには状態のスナップショットを取って差分計算とかするときにIDが欲しい、とかしか書いてないから、Equatableの必要性は書いてあるけど

12:54 AM

Hashableである理由は書いてないように見える

12:56 AM

スレッドで指摘してるレスもまだ無さそう

@norio_nomura Hashable な ID を持つ Identifiable が必要であれば、必要な側で Identifiable を継承して作ればよくないですか？標準ライブラリはできるだけ汎用的な方が良いかと。

protocol Identifiable { associatedtype ID: Equatable var id: ID { get } } protocol HashIdentifiable: Identifiable where ID: Hashable {} struct MyID: Equatable { static func ==(lhs: MyID, rhs: MyID) -> Bool { return true } } struct Foo: HashIdentifiable { // Hashable でないので Error var id: MyID }

~~equality と identity の違いは何か？の話になりそう。~~ (edited)

でも Hashable でも identity を equality に任せるわけですよね？

あいや、関係ないか。

書いてみました。 https://forums.swift.org/t/se-0261-identifiable-protocol/26602/44

SE-0261: Identifiable Protocol

Why must ID be Hashable? I think Equatable is enough for identification. DBs often use trees for indices instead of hash tables. Don't we want to make ID Comparable instead of Hashable in such cases? Even if ID is just Equatable in the standard library, we can make ID Hashabl...

Hashableが無い方は、想定されるユーザーがいるのですかね？

うーん、具体例は出せないですが、僕は標準に入れるからには極力最小限にしておきたいなという気持ちがありますね。 Java の Object が hashCode と equals 持ってたのとか今となっては失敗ですよね？

collectionのdiffはT: Equatableだし。

Java の Object.hashCode についても追記しといた。

この辺りがHashable使ってますね。 https://developer.apple.com/documentation/swiftui/identifiervaluepair https://developer.apple.com/documentation/swiftui/identifiervaluepairs

SwiftUI では↓を宣言しなおせばいいと思うんですよね。 protocol Identifiable: Swift.Identifiable where ID: Hashable {}

3:40 AM

使うときに名前衝突が面倒かな？

import SwiftUI struct User : Identifiable { ... }

3:40 AM

こうしたときは SwiftUI.Identifiable > Swift.Identifiable で解決するはず

それなら問題ないね。

Swift.Resultが入った時にantitypical/Resultとの絡みでそうなった

お、そうなってなかった気がしてたけど、最近なったのか。

5.0のところで整った。

素晴らしい。

実用を考えるとHashableでいいと思うんですよね。

4:04 AM

Identifiableが必要なケースはそれなりのボリュームを処理したいということだから、EquatableのショートカットとしてのHashableが普通は必要になるはず。

https://github.com/apple/swift-evolution/blob/master/proposals/0261-identifiable.md#motivation

https://developer.apple.com/documentation/swift/bidirectionalcollection/3200721-difference

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

4:05 AM

プロポーザルのMotivationセクションには

4:05 AM

配列のdiffを取ってListViewを更新する話しか書いてないから

4:05 AM

それでいくとEquatableで十分になってしまう。

ListViewを更新するのEquatable だけよりHashableの方が断然効率いいですよね。

いえ、MayerのDiffアルゴリズムの場合、辞書を使って加速する部分はないです http://blog.robertelder.org/diff-algorithm/

いや、==とhashValueの呼び出しは普通hashValueの方が速い、というのが言いたかったことです。 (edited)

4:09 AM

というかHashableというのはそうすべきものなので。

あれ？それって正しいですかね？

4:12 AM

ハッシュ値を求めるためにはそのデータの全ビットをスキャンしないといけなくて、さらに掛け算や足し算をすることになるので

標準に入れるからには極力最小限にしておきたい

これもわかるんですけど、普通に使って遅かったりしない、というのも標準には重要かなと。

A == B を直接比較するのと、 AとBのハッシュ値をそれぞれ求めてからそれを比較するのって、

4:12 AM

後者のほうが遅いような気がします。

4:13 AM

ハッシュ値が意味があるのは、ハッシュテーブルに入れて検索する時にO(1)で見つけられる場合だけなのでは。

4:15 AM

コレクション同士の場合は要素のハッシュ値をキャッシュできるから比較がなんども発生する場合には高速化するのかな？

4:16 AM

4:16 AM

You can expect faster execution when the collections share many common elements, or if Element conforms to Hashable.

4:16 AM

ちょうど書いてあった。

ちょっと私も書いてて自信無くなってきました。

func difference<C>(from other: C) -> CollectionDifference<Self.Element> where C : BidirectionalCollection, Self.Element == C.Element Available when Element conforms to Equatable.

BidirectionalCollection.differenceは、要素をEquatableを要求するけど、Hashableのときは加速するらしい。

これからオフィスに向かうのでその道すがら考えを整理します

Hashableのときは加速するらしい。

素晴らしい。

~~https://github.com/apple/swift/blob/f994fc3f80b4702229c0c608f13adc224b0c4cbe/stdlib/public/core/Diffing.swift~~ (edited)

4:20 AM

特に実装がそうなってない・・・ (edited)

4:23 AM

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

https://devstreaming-cdn.apple.com/videos/wwdc/2013/224xcx5x1y1yx8ra5jbmfyhf/224/224.pdf

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

えー…

1

hashは衝突していいので、「全ビットをスキャン」しなくても雑なスキャンで高速化はあり得るんじゃないでしょうか。

全ビットを影響させて衝突を防ぐのがハッシュの実装のベストプラクティスのはずです

5:28 AM

そこで手を抜くと逆に衝突確率があがり、辞書のパフォーマンスとしてみると赤字になるんだと思います

Hashableを使った func == も func != もstdlibには無いみたい。 (edited)

5:43 AM

Diffing.swiftで唯一Hashableが影響しえた部分がfunc ==だったから、さっき見直してみた。

ところで、「全ビットを使わないでハッシュを高速化」に関しても、==の途中で異なるフィールドが出てくれば、そこで中断できるので、それと同じ事だと思います

5:45 AM

それと、ハッシュは「異なる」ことしかわからないので、「等しい場合」については再計算が必要になるので高くつく場合もあります。

Stringのハッシュとかは一部しか計算に使っていませんでしたが、Hashableが変わってからは調べてないな。

私は完全に勘違いしていました。hashは==のショートカットとして常に使える気がしていましたが、そんなことはないですね。なので上で書いた私の意見は全部間違いです

6:36 AM

と、いうのをたった今ちょっとコード書いて検証しました

Objective-Cの時は全てにhashがあって、NSArrayとかは要素数を返したりしたから、hash比較で!=を得るのが速い場面も無くはなかった。 @swift-5.0.3 import Foundation let a: NSArray = [1, 2, 3] print(a.hash)

3

objcの頃は遅い-isEqual:を避けるためにまず-hashを使うというのがあったので-hashはぶつかってもいいから高速にと思ってたんだけど、別に-hashを速くしろとは書いてないみたい

7:46 AM

7:50 AM

中身が同じなら別のインスタンスでも同じとみなすクラスでもない限り-hash（と-isEqual:)は書かなかったけど

Objective-Cの時は全てにhashがあって、NSArrayとかは要素数を返したりしたから、

オワー！なんだこりゃ・・・

たしかに < 中断できる（特にイミュータブルクラスとかで）ハッシュ値をキャッシュしたときとかは速くなりそうだけど大分限定的だなぁ。

https://forums.swift.org/t/accepted-with-modification-se-0258-property-wrappers/26828

[Accepted with modification] SE-0258: Property Wrappers

The third review of SE-0258 has concluded. There was a lot more great discussion in this review, and while there were some questions and reservations, overall the community expressed strong support for accepting the proposal. The Core Team agrees and has decided to accept S...

ついに決着

ORT 使ったら existential や type erasure を使わずに heterogeneous なコレクションを実現できそうな気がしてるんだけどどうでしょう（↓みたいな感じで）？ただし、現状ではループして取り出す方法がないし、これをうまく扱うには道具が足りてなさそう。

import SwiftUI protocol ViewSequence { associatedtype Element: View associatedtype Next: ViewSequence var element: Element { get } var next: Next { get } } extension Never: ViewSequence { var element: Never { fatalError() } var next: Never { fatalError() } } struct ViewSequenceNode<Element: View, Next: ViewSequence>: ViewSequence { let element: Element var next: Next { if let next = _next { return next } else { fatalError() } } fileprivate let _next: Next? init(element: Element, next: Next) { self.element = element self._next = next } } extension ViewSequenceNode where Next == Never { init(element: Element) { self.element = element self._next = nil } } func foo() -> some ViewSequence { return ViewSequenceNode( element: Text("Hello"), next: ViewSequenceNode( element: HStack { Text("World") }, next: ViewSequenceNode( element: VStack { Text("!") } ) ) ) } let views = foo() print(views.element) print(views.next.element) print(views.next.next.element)

some ViewSequenceの時点で型情報が見えなくなってるので、リストの長さに関して型安全にならないと思います

これは sequence だから count はないけど、 count を付けること自体はできるんじゃない？

動的なcountはできると思いますけど、その場合ユーザーから見て、 (edited)

7:11 AM

ViewSequenceNodeが型パラメータNextを持たずに、var nextをViewSequenceのerasureで保持した場合と何が変わっているんです？

type erasure や existential によるパフォーマンスロスを削減できる。

あ〜そうか、たしかに。

↑が有用だと主張してるわけじゃないけど、 SwiftUI は ORT でパフォーマンスロスが・・・とか言ってるけどコレクションが結局 erasure （ AnyView ）でロスしてるよなと思って、 SwiftUI がジェネリック地獄を ORT で解消してるのを参考に似たようなことができないかなと。

7:14 AM

ただ、ループで回そうとしても element が一つずつ型が変わるから、専用の構文でも導入しないと回せないと思うんよね。 (edited)

ループで回すところに関してはOpaqueになった時点で、静的に次の要素の型がわからないから、AnyViewとかでeraseすることになりそうですね

それを erase せずに element を some View として扱ってアンロールしてくれる専用構文が必要そう。

7:16 AM

型から要素数がわかるからコンパイラがアンロールできるはず。

7:17 AM

しかも、 element を some View 扱いすれば共通のコードがアンロールされた個々の箇所ではちゃんと働きそう。

7:18 AM

heterogeneous sequence を表すプロトコルか何かを導入して、それを for 文に突っ込んだときは↑のようにアンロールとかいう挙動をコンパイラに実装すればできそう。

7:20 AM

array literal も拡張しないと ExpressibleByArrayLiteral を経由するときに erase されちゃうな。

some ViewSequence<.Element == Int> とかが書けるようになったとして、 some ViewSequenceの.elementは some View で良さそうですね

some HeterogeneousSequence<.Element: View> とかで、 Element が some View かなぁ。

7:26 AM

今は ORT に <.Element: ...> が書けないかなら : View 縛りで ViewSequence として試してみた。

protocol HeterogeneousSequence { associatedtype Element } に対して some HeterogeneousSequence<.Element : View> と制約するなら seq.element は some View になりそうですね、理論的には。

コレクションを Opaque Type の世界に持ってこれたら新しそうな気がするんだよなぁ。

7:29 AM

ただ、 some View になってもループ回るごとに実の型は違うからそのまま扱うと結局 existential になっちゃうから、コンパイラがアンロールしてくれないといけないんよね。

そうですね　ループの周回ごとに違うコードが要る (edited)

あー、でもイテレートはそれでよくても、作る方とか無理かな・・・

7:33 AM

いや、そもそも無理なのか、ループしながら要素を追加してコレクション作り上げようとしても

7:34 AM

ループ回るごとに完成形の型が変わっちゃうから、それを格納する変数を記述できない。

現状だとそういうイテレーターをfor文に適合するように記述する規格が無いですね。

7:34 AM

勝手な func forEach(f)とかならできそう。 (edited)

var collection: ??? = [] for foo in foos { collection = collection.appended(foo) } みたいなのができない。

7:35 AM

??? の部分がループ回るごとに変わる。

7:36 AM

（ Rust のシャドーイングみたいに？）型を上書きする仕組みが必要そう。アンロールしながら↑の collection の型をシャドーイングで上書きしていく。 (edited)

7:38 AM

現状だとそういうイテレーターをfor文に適合するように記述する規格が無いですね。

イテレートに関しては、新しい HeterogeneousSequence プロトコルとかを導入して、それに適合した型が for に渡された場合はコンパイラがアンロールっていう挙動に改造すればいけると思うんよね。 (edited)

HeterogeneousSequenceを言語仕様で入れちゃうのはありですね

組み立てる側はそれだけで済まない変更が必要そうだ。

7:39 AM

任意の N 要素から組み立てるコードの場合。

コンパイル時に型が決められないから動的に組み立てるのはダメだな。

9:39 AM

それなら、すべての要素が同じ制約を満たしていて、それを some Foo としてイテレートできて、 for に渡すとアンロールしてくれるタプルがあれば十分だな。

Standard Libraryへ追加する機能をプレビューするパッケージを作ろうというpitch https://forums.swift.org/t/pitch-standard-library-preview-package/27202

Pitch: Standard Library Preview Package

Hi Swift community, Here's a first draft of a proposal we've been working on that should help us work in our new, post-ABI stability, post-Xcode package manager integration world. PR for the proposal can be found here. Standard Library Preview Package Authors: Ben Cohen, M...

ああそうか、Standard Libraryの変更は、ツールチェインごと切り替えないといけないから試しづらかったけど、

3:58 AM

ツールチェインはそのままでStdlibだけ新しいのに試しに切り替える、というのがやりやすくなるのか。

4:02 AM

Take SE-0199 4 (the introduction of toggle) for example. It was accepted 4 almost 6 month before Swift 5 was released.

コレな

今更だけど、static let …はonceなチェックが毎回入るけど、static var … { get }だと入らない。onceチェックのコストより新規インスタンス生成のコストが低く、ポインタでの参照が不要の場合、後者を選んだ方が良いのか。

3:18 AM

onceチェックのコストってどれくらいだろう

それ知りたい

static let …の方は、コンパイル時に評価してしまえる場合、オプティマイザがonceチェックとかすっ飛ばして即値を持ってきたりする。

3:35 AM

なので、static letとstatic var { get }の速度差は、デバッグビルドでのパフォーマンスにしか影響しない場合もある。 (edited)

constexprが入れば、その最適化を静的に保証できるので楽しみ

-emit-assemblyを見ると、onceチェック2回目以降のコストは無視して構わない感じだけど、初回コストが大きいかも。

2回目以降の初期化済みかどうかスレッドセーフに調べるところはどうかなあ

_swift_onceへ渡すトークンの値が-1かどうかチェックしてるだけだった。 cmpq $-1, <token>してjeで_swift_onceをスキップ。

10:43 AM

 .private_extern main.S.letStatic.unsafeMutableAddressor : main.S .globl main.S.letStatic.unsafeMutableAddressor : main.S .p2align 4, 0x90 main.S.letStatic.unsafeMutableAddressor : main.S: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp cmpq $-1, _globalinit_33_1A61A3E7348A44FC8FF8726B26BEB4ED_token0(%rip) je LBB7_2 leaq _globalinit_33_1A61A3E7348A44FC8FF8726B26BEB4ED_func0(%rip), %rax leaq _globalinit_33_1A61A3E7348A44FC8FF8726B26BEB4ED_token0(%rip), %rdi movq %rax, %rsi callq _swift_once LBB7_2: leaq static main.S.letStatic : main.S(%rip), %rax popq %rbp retq .cfi_endproc

最初にもし2スレッドが突入した場合はその先の_swift_onceで同期をとるから大丈夫で、それ以降は同期無しでスキップできるのか

あれ？iOSのJSONEncoderっていつからUInt単体でエンコードできる様になったの？ (edited)

9:07 AM

これか。 https://developer.apple.com/documentation/foundation/jsonserialization/writingoptions/3081259-fragmentsallowed?changes=latest_minor

beta 5からJSONEncoderがこのオプションをJSONSerializationへ渡す様になったぽい。

なんかXcode11b5で、(Never)->Tなクロージャの定義がコンパイルエラーになるようになった気がする。

4:26 AM

Will never be executed がerrorになってるから、これはwarningかどうかフラグで切り替えるようになったのかな

4:28 AM

↑RACが SWIFT_TREAT_WARNINGS_AS_ERRORS=YES;を入れている+新しいWarningが追加されたから、っぽかった。

@swift-5.0.3 let r1: Range<Int> = 1..<10 let r2 = r1.dropFirst(1) print(type(of: r2))

Range<Int>

@swift-5.0.3 let r1: ClosedRange<Int> = 1...10 let r2 = r1.dropFirst(1) print(type(of: r2))

Slice<ClosedRange<Int>>

1

ClosedRange の SubSequence が ClosedRange でないのは ClosedRange だと空のレンジを表現できないから？ (edited)

ええなんだこれ

空の ClosedRange を作れなくて↓の r2 のようなケースが表現できないのかなと。 @swift-5.0.3 let r1 = 1...1 let r2 = r1.dropFirst(1) print(Array(r2))

[]

@swift-5.0.3

typealias OptString = String? struct User { var name: String? var email: OptString init(name: String) { self.name = name } } let user = User(name: "kagemiku")

exit status: 1 with stderr:

<stdin>:9:5: error: return from initializer without initializing all stored properties } ^ <stdin>:5:9: note: 'self.email' not initialized var email: OptString ^

@swift-4.2.4

typealias OptString = String? struct User { var name: String? var email: OptString init(name: String) { self.name = name } } let user = User(name: "kagemiku")

no output

↑のように、swift5でコード例のようなイニシャライズができなくなってるっぽいです

Optionalの自動初期値nilがtypealiasの場合に効かない挙動に変わった？

2:06 AM

意図された仕様変更なのか、実装上で挙動が変わってしまったのか、どっちだろう・・

2:09 AM

@swift-5.0.3 @swift-4.2.4 var a: Int? print(a) var b: Optional<Int> print(b)

exit status: 1 with stderr:

<stdin>:2:7: warning: expression implicitly coerced from 'Int?' to 'Any' print(a) ^ <stdin>:2:7: note: provide a default value to avoid this warning print(a) ^ ?? <#default value#> <stdin>:2:7: note: force-unwrap the value to avoid this warning print(a) ^ ! <stdin>:2:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(a) ^ as Any <stdin>:4:7: warning: expression implicitly coerced from 'Optional<Int>' to 'Any' print(b) ^ <stdin>:4:7: note: provide a default value to avoid this warning print(b) ^ ?? <#default value#> <stdin>:4:7: note: force-unwrap the value to avoid this warning print(b) ^ ! <stdin>:4:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(b) ^ as Any <stdin>:4:7: error: variable 'b' used before being initialized print(b) ^ <stdin>:3:5: note: variable defined here var b: Optional<Int> ^

nil nilstderr:

<stdin>:2:7: warning: expression implicitly coerced from 'Int?' to 'Any' print(a) ^ <stdin>:2:7: note: provide a default value to avoid this warning print(a) ^ ?? <#default value#> <stdin>:2:7: note: force-unwrap the value to avoid this warning print(a) ^ ! <stdin>:2:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(a) ^ as Any <stdin>:4:7: warning: expression implicitly coerced from 'Optional<Int>' to 'Any' print(b) ^ <stdin>:4:7: note: provide a default value to avoid this warning print(b) ^ ?? <#default value#> <stdin>:4:7: note: force-unwrap the value to avoid this warning print(b) ^ ! <stdin>:4:7: note: explicitly cast to 'Any' with 'as Any' to silence this warning print(b) ^ as Any

Int?は自動初期化だけどOptional<Int>はそうではないようだ。

2:10 AM

https://forums.swift.org/t/prepitch-optional-variables-should-require-explicit-initialization/26077

2:10 AM

↑ここで見た

2:10 AM

ただこれも5.0からの挙動だ。

typealias 起因というよりは、Optionalの実装起因、という感じですかね

https://bugs.swift.org/browse/SR-10047

4:11 AM

過去に報告されていて、Slavaがこれはリグレッションじゃなくて4.2→5.0での変更ですと答えているので、仕様っぽいです。

なんと…仕様とは　ありがとうございます

ソース互換性が壊れるけど、Evolutionプロセスにこんなのあったっけ・・・

@_hasInitialValue @swift-5.0.3 -frontend -emit-sil var a: Int? var b: Optional<Int>

sil_stage canonical import Builtin import Swift import SwiftShims @_hasStorage @_hasInitialValue var a: Int? { get set } @_hasStorage var b: Optional<Int> { get set } // a sil_global hidden @$s4main1aSiSgvp : $Optional<Int> // b sil_global hidden @$s4main1bSiSgvp : $Optional<Int> // main sil @main : $@convention(c) (Int32, UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>) -> Int32 { bb0(%0 : $Int32, %1 : $UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>): alloc_global @$s4main1aSiSgvp // id: %2 %3 = global_addr @$s4main1aSiSgvp : $*Optional<Int> // user: %6 %4 = metatype $@thin Optional<Int>.Type %5 = enum $Optional<Int>, #Optional.none!enumelt // user: %6 store %5 to %3 : $*Optional<Int> // id: %6 alloc_global @$s4main1bSiSgvp // id: %7 %8 = global_addr @$s4main1bSiSgvp : $*Optional<Int> %9 = integer_literal $Builtin.Int32, 0 // user: %10 %10 = struct $Int32 (%9 : $Builtin.Int32) // user: %11 return %10 : $Int32 // id: %11 } // end sil function 'main'

Int?の方は@_hasInitialValueってのが付くのね。

ほー

このPRに、Optional<Int>とInt?の挙動が違う理由が書かれてる。？ https://github.com/apple/swift/pull/12770 (edited)

Sema: Fix source compatibility break with default initialization o...

In Swift 4, properties declared with a sugared Optional type, like Int?, have a default value of nil. This can be observed in two ways: Classes and structs get an implicit no-argument initializer ...

A recent refactoring cleaned up some of the mess in this area, but accidentally broke source compatibility with code that relied on the broken Optional case.

6:53 AM

最近のリファクタリングで間違ってソース互換性を壊しちゃったから-swift-version 4で互換する実装をしたよ、が12770？

~~シンタックスシュガーを使っていないオプショナルが、Swift 4でデフォルト値を持っていた挙動はバグだったとも、コメントからは読める。~~

// Note: Swift 4 had a bug where properties with a desugared optional // type like Optional<Int> had a half-way behavior where sometimes // they behave like they are default initialized, and sometimes not. // // In Swift 5 mode, use the right condition here, and only default // initialize properties with a sugared Optional type. // // (The restriction to sugared types only comes because we don't have // the iterative declaration checker yet; so in general, we cannot // look at the type of a property at all, and can only look at the // TypeRepr, because we haven't validated the property yet.)

(edited)

7:04 AM

いや、違うな。

7:07 AM

Swift4でOptionalを持つ型のイニシャライザがバグってたから直したけど、その影響でsugared typeのOptionalだけ初期値を持てる様になってしまった、みたいな状態なのかな。 (edited)

これは謎な挙動だ

https://github.com/apple/swift/pull/26518

Experimental prototype of Swift quasiquotes by burmako · Pull Req...

Swift works great as an infinitely hackable syntactic interface to semantics that are defined by the compiler underneath it. The two options today are LLVM (there's a running joke that Swif...

1:49 AM

Swift for TFのユージンさんがなんかやばいの作ってる

1:50 AM

Scalaのマクロ機能について活躍してる人らしい

1:51 AM

https://docs.google.com/document/d/1UIPWl4lvBTozBD5OQ9SrxgcM7rA4pODMOjqQv3tm57w/edit

Swift as syntactic sugar for MLIR

This is a public document Swift as syntactic sugar for MLIR Author: Eugene Burmako Last Updated: 8/6/2019 History 2019/8/6 Initial public version of the document that describes five designs for metaprogramming MLIR in Swift. None of the designs have been implemented - we are ...

1:52 AM

多分この文書ではMLIRのコードをSwiftにembedする上でどういう言語インターフェースがありえるかを議論していて、

1:53 AM

このPRではその一つの実例として #quote(funcName) とすることで関数のSwiftASTを返す言語機能を作った？

3:48 AM

S4TFもMLIRもstableじゃないのに良くやるわ…

その文字列リテラル方式のところで何の話をしたいのかわかったｗ

これ例えばscala(string)でスカラ使えるとかですか？

Scalaだとコード全体が無いとコンパイルできないので実用性が無さそうですが

4:00 AM

scalaのREPL環境を実行時に用意して、scala("...") のたびにそこに投入していくみたいな実装なら動作しそうですね

4:04 AM

ただこれ、MLIRを実行時に構成してもあんまりうれしくないような。

4:04 AM

コンパイル時計算と組み合わせて、埋め込んだMLIRをコンパイルしておかないと、

4:04 AM

Swift書いてるのに静的言語環境じゃなくなりそうな

mlirをmachine learningの目的で使うなら嬉しさがなさそう、というかs4tfを使った方が良さそうだしあまりゴールが見えない

Sequence.Element って何のために追加されたんでしたっけ？元々 Sequence.Iterator.Element で良かったと思うんですが、それだと面倒だから？ Proposal ありますっけ？ ↓によると Xcode 9 （ Swift 4 ）で追加されてそうですが、 Proposal 一覧を "element" で検索してもひっかからず。リファレンスの表記上の問題で "Xcode 9.0+" になってるだけで、もっと前に追加されましたっけ？ https://developer.apple.com/documentation/swift/sequence/2908099-element

https://github.com/apple/swift/commit/ea2f64cad218bb64a79afee41b77fe7bfc96cfd2#diff-b9ba8d4ad76ba94c1eeabc504d582b57R330

[stdlib] Add Sequence.Element, change ExpressibleByArrayLiteral.El...

…nt to ArrayLiteralElement (#8990)

Give Sequence a top-level Element, constrain Iterator to match

Remove many instances of Iterator.

Fixed various hard-coded tests

XFAIL a few tes...

7:47 AM

このコミットで追加されていますね

7:48 AM

https://github.com/apple/swift/pull/8990

[stdlib] Add Sequence.Element, change ExpressibleByArrayLiteral.El...

This change will allow generic algorithms to refer to Sequence.Element instead of Sequence.Iterator.Element. The PR is big but the vast bulk of the changes are removal of Iterator. from numerous li...

7:48 AM

https://github.com/apple/swift/pull/9589

[4.0][stdlib] Add Sequence.Element by airspeedswift · Pull Reques...

And change ExpressibleByArrayLiteral.Element to ArrayLiteralElement (#8990) 4.0 merge of #8990

7:49 AM

4.0からっぽい。

これを見る限り Proposal を経なかった感じかなぁ。

Evolutionにも見当たらないですね

Additive かもしれないけど、 Proposal 経ないにしては結構大きな変更じゃない？ Sequence とか基幹となるプロトコルだし。

7:55 AM

あと、この Element って associatedtype じゃないといけないんだっけ？ typealias Element = Iterator.Element ではダメだった？

エイリアスだから無断で追加したのかと思ってたけど

7:57 AM

意味変わるのかな？

7:57 AM

僕もエイリアスだと思ってたけど制約つきのassoctypeなんですねえ

Generalized Existential を見越したら、 typealias は指定できるパラメータの対象にならない？ Sequence<.Element == Int> とかのときに。

8:03 AM

型パラの制約には typealias でも指定できるんだから、 Generalized Existential でも同じなのが自然か。 @swift-5.0.3

protocol P1 { associatedtype X func f1() -> X } protocol P2 { associatedtype Y: P1 //associatedtype X where X == Y.X typealias X = Y.X func f2() -> Y } func foo<P: P2>(_ p: P) where P.X == Int {}

no output

OrderedSetは何故Swiftで無くなってしまったんだろう

(正確にはNS接頭辞削除祭りから何故除外されてしまったのか…)

標準ライブラリのデータ構造、もう少し充実させてほしいですよね。

binarySearchはまあまあ使うので標準に欲しい

NSArrayにはあるんですよね。Arrayに付けてほしい。

https://forums.swift.org/t/pitch-offset-indexing-and-slicing/28333

[Pitch] Offset Indexing and Slicing

Hello, I'm back with yet another formulation of offset-based indexing and slicing. This builds on all the discussions from Pitch: Offsetting Indices and Relative Ranges and prior. The swift-evolution PR can be found here. Offset Indexing and Slicing Proposal: SE-NNNN Author...

12:25 AM

インデックスめんどくさい問題の新提案

12:26 AM

これは良いアイデアだと思う

Swift5.1で

4:29 AM

enum E : Int { case a; case b } switch E(rawValue: 0) { case .a: print("a") case .b: print("b") case .none: print("none") }

4:29 AM

って感じで、enumのOptionalに対して.someをつけずに網羅的にswitch-caseが書けるようになってるの便利なんだけど

4:29 AM

proposalあったっけ。

https://forums.swift.org/t/matching-optionals-in-a-switch-statement/12905/8

Matching optionals in a switch statement

That's a good idea. It ought to comple as well. That's a bug. Thanks for raising these issues! If you have a moment, both of them are worth filing on bugs.swift.org, if you haven't already.

4:53 AM

バグ扱いだったみたいですね

なるほどw

Xcodeのリリースノートにも明記されてるのにバグなのか...

リリースノート側では機能改良なの？

1

10:29 AM

.someつけずに書けるのはこれのことやんね？

10:29 AM

SwiftのNew Featuresとして書いてあるね

それですw

新機能だと思ってた

プロポーザルこれか？チケットに紐付いてた https://forums.swift.org/t/matching-optionals-in-a-switch-statement/12905

Matching optionals in a switch statement

I have two questions about matching optionals in a switch statement. Apparently an Int? can be matched against non-optional integer literals or non-optional integer expressions: let x: Int? = 1 switch x { case 1: print("one") case 1?: print("one?") case 1+2: print("one+two...

10:34 AM

いや承認プロセスとか無さそうだし違うのか

そのスレでジョーグロフが

It ought to comple as well. That's a bug.

10:35 AM

スレ自体はIntのときとenumのときで挙動違くない？って指摘

10:35 AM

挙動を同じにすると最終的に網羅チェックがついてくる、みたいな。

RobertさんがThat's not a bugと言って、Joe GroffがThat's a bugと言ってカオスだw

ほんとだwロバートってコダフィーさんか

そうそう。時間ある時にあとで読んでみる

https://forums.swift.org/t/swift-for-bare-metal-rtos-based-microcontroller/19372/13?u=omochimetaru

Swift for bare-metal/RTOS based microcontroller

Hi Andy, your work looks really interesting, but there were no more updates since March. Could you tell us what's the current status? Ps: I'd like to present also this very interesting paper: Swift for Embedded Systems

4:52 PM

STM32マイコンでSwift動かした修士論文？がシェアされてる

4:52 PM

9月からマージを計画してるらしい

最高じゃんw

4:53 PM

大学の授業これでやりたかった

結論のとこにコードサイズが問題って書いてある

https://forums.swift.org/t/differentiable-programming-mega-proposal/28547

Differentiable Programming Mega-Proposal

Hi Swift community, We have completed a comprehensive proposal for the differentiable programming feature we’ve been incubating over the last 1.5 years. We’ve gone over many iterations on the feature design, and have partially completed the implementation. Now we are rea...

7:59 AM

見逃してた微分機能のプロポーザル来てた

7:59 AM

メガって付いてるw

@swift-5.1.5 let t = Int.self let a: [t] = [2, 3, 5] print(a.reduce(0, +)) // 10

exit status: 1 with stderr:<stdin>:2:9: error: use of undeclared type 't' let a: [t] = [2, 3, 5] ^

↑を REPL で 1 行ずつ実行するとできたんだけど、そういうものだっけ？

7:46 PM

-frontend -replだとエラーになるね。

$ swift -frontend -repl -sdk $(xcrun --show-sdk-path --sdk macosx) *** You are running Swift's integrated REPL, *** *** intended for compiler and stdlib *** *** development and testing purposes only. *** *** The full REPL is built as part of LLDB. *** *** Type ':help' for assistance. *** (swift) let t = Int.self // t : Int.Type = Swift.Int (swift) let a: [t] = [2, 3, 5] <REPL Input>:1:9: error: use of undeclared type 't' let a: [t] = [2, 3, 5] ^ (swift)

iPlaygroundでDifferential Programmingの話をした人は、Mega proposalは100%マージされるって言ってた。

スレッド見ると、「素晴らしい機能だとは思うけど、普段使わない機能がコンパイラに組み込まれて、今後いろんな改修のたびにこの部分もメンテナンスするコストが上がっちゃうのが大丈夫ならいいんじゃない、」みたいなコメントが多い感じがする

4:43 PM

でもそもそもこれは、Swiftのユーザー領域を増やすための機能って側面が強いから、現在のユーザーが集まって話し合ってるフォーラムで意見を聞いても噛み合わないので、

4:43 PM

仕組みとしてフォーラムがうまく機能してないなと自分は感じた。

4:44 PM

まあコアチームはそのへんわかって、設計まで踏み込んだツッコミとか以外は無視すると思うから実際マージする方向に進むんじゃないかと予想している

既存の挙動をまったく変更しないというのと、もうすでにいくつかの実装はマージされてるし、って感じみたいですね。

https://forums.swift.org/t/se-0264-standard-library-preview-package/29068

SE-0264 — Standard Library Preview Package

The review of SE-0264 — Standard Library Preview Package begins now and runs through Sept 30, 2019 The proposal is written by @ben_cohen, @moiseev, and @nnnnnnnn. Reviews are an important part of the Swift evolution process. All review feedback should be either on this fo...

6:53 AM

標準ライブラリのベータ版パッケージSwiftPreviewを導入する提案！

https://forums.swift.org/t/pitch-double-or-more-trailing-closures/29147/22

Pitch: Double (or more) trailing closures

A simple solution to the ambiguity problem of multiple ‘trailing’ closures is to simply require that they start on the same line as the preceding closure, after the }. e.g.: // This is a single call to when(::otherwise:) when (2 < 3) { doSomething() } otherwise { do S...

12:11 PM

２つ目のクロージャ引数も丸括弧の外に出したい提案

func when<T>(condition: @autoclosure () -> Bool, then trueBranch: () -> T, `else` falseBranch: () -> T) -> T { if condition() { return trueBranch() } else { return falseBranch() } } let a = when (2 < 3) { 3 } else { 4 }

なるほど、そこにラベルが来るのか

パーサー的につらそうって意見があって

12:20 PM

requests.get("/user?ID=12345") { response in let user = response.args["user"] ... } catch: { print("Something went wrong") } finally: { // Always execute };

12:20 PM

↑こんな案も出てる

12:20 PM

これでもラベルと曖昧だよなあ。

12:21 PM

trailing closureとsecond labelの間に何か特定のトークンを置くような規則じゃないとつらそう

ラベル名だけで区切るのはパーサ辛そうですね

,置くのが妥当ではなかろうか

理屈はそうだけど、見た目に千切れた感じにならない？

例えば Dictionary 的な機能を持つ protocol を定義するとして、 mapValues を protocol level で書く（Value 型を変える）ということはできないのでしょうか？ struct Dictionary では： func mapValues<T>(_ transform: (Value) throws -> T) rethrows -> [Key : T] が定義されていますが，これを

protocol DictionaryProtocol { associatedtype Key: Hashable associatedtype Value func mapValues<T>(_ transform: (Value) throws -> T) rethrows -> Self (where Value == T) }

のようなことをしたい…

（もしそれがあるのであれば Sequence の map 型も [T] と specialize された形になってないはずなので，やはり無理なのでしょうか） (edited)

これはHigherKindedTypeと呼ばれる機能が相当しますね。そしてSwiftにはないです。

ふーむ…なるほど

(edited)

これができるとMonadやApplicativeをProtocolとして宣言できるようになりますが、現在はないので (edited)

12:45 AM

Sequenceのmap/flatMapはArray<T>へ変換されてますね

そうですよねー…

ついに高カインド型が欲しいところまで来たんですか

こういうことがしたいケースでは，Sequence.map みたいに具体型を特定してしまうか，適合型ごとに実装するしかないんですねぇ．

イナミさんがiOSDCで話してたラムダキューブの右方向の機能ですな

多項式を protocol 化しようとして（一変数・多変数など色々な種類があって個別に同じコードを書くのが嫌なので），係数環を変えるような map を実装したいのだけどできない，という感じです．

 public func mapCoefficients<R2: Ring>(_ f: (R) -> R2) -> Polynomial<x, R2> { .init(elements: elements.mapValues{ f($0) }) }

右じゃなくて奥か

例えば整数係数の多項式を有理数係数と思いたい，というようなケース．

12:50 AM

これを多項式の種類ごとに実装するのではなく，protocol として宣言して extension でまとめて書きたい，という思いからの疑問でした．

12:54 AM

代わりに struct を一個にして色々な generic 型を持たせることで種類を分けて，激しめに extend する方向も考えたのですが，異なる条件で同じ protocol に conditionally conform するということができないので，それも諦めました

まさにこれですね

他にも写像型を protocol 化しようとして，合成演算 ∘ が protocol レベルで宣言できずに困ったこともありました．

public struct Map<X: SetType, Y: SetType>: MapType { public typealias Domain = X public typealias Codomain = Y private let f: (X) -> Y public init(_ f: @escaping (X) -> Y) { self.f = f } public static func ∘<W>(g: Map<X, Y>, f: Map<W, X>) -> Map<W, Y> { g.composed(with: f) } }

(edited)

そうですね、、共通の一つのコンテナに固定されちゃいます

Sequence.map が全部 [T] になっちゃうことにストレスを感じてる人も多そうなので，将来的には対応が期待できそうな感じですかね

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

12:59 AM

マニフェストでは「Maybe」に入ってますね

その上の Generic value parameters と合わせて是非やっていただきたいですねw

1:02 AM

こないだ質問した Private conformances についても Unlikely に入ってたんですね

1:02 AM

当面は struct ごとに実装してく方向で対処します，ありがとうございました！

1:09 AM

上のを manifest にある記法で書くと： func mapCoefficients(_ f: (R) -> P.R) -> P という感じですかね．是非こう書きたい！

fの型の方からP.Rがそうやって決まるのか。制約はPがSelfと同じ型コンストラクタであると。面白い書き方ですね。

是非こう書きたい（2回目）

3:07 AM

ところでいつの間にか struct の property や func でも Self って使えるようになってたんですね．長い名前のとき毎回書かなきゃいけないのが冗長だったり，protocol に移すとき Self に直さなきゃいけなかったりで面倒だったので地味に嬉しい

(edited)

Swift5.1で実装されました

いえーい✌️

なんか随分前にacceptしてたんだけど、誰も実装してなかったのを、

3:07 AM

有志が実装してPRを投げてた気がする

おー，有志に感謝

protocol A, B に同シグネチャの関数があって，それぞれ protocol extension でデフォルト実装を入れているとして，struct X: A, B とすると ambiguity からオーバーライドさせられますが，「A の方の実装を採用する」というようなことはできないんでしょうか？ struct X: A, B { func common() { (self as A).common() } } こんな感じで…

1:40 PM

あ，A, B は Self つきの protocol で as が使えない奴です．

1:41 PM

上のコードをそのまま書くと Protocol 'A' can only be used as a generic constraint because it has Self or associated type requirements となるタイプのものです．

protocol extensionのデフォルト実装は呼べないので

1:43 PM

static関数を外においてextensionと実装強制の双方からコールするのが良いです

なるほどなるほど．

1:43 PM

extension で internal func _commonA() のようなものをつくっておいて，そちらを呼ぶというのもありですかね？

static func common<T: P>(_ self: P) こんな感じのを作っておけばオッケー

1:44 PM

あ、それもいけるかも。

OK です！

protocol A { func common() } extension A { func commonAImpl() { ... } func common() { commonAImpl() } } protocol B { 略 }

こんな感じですね

1:45 PM

うまくいきそう。

できました

1

ジェネリックシグネチャを通すことで属性を絞り込んで明示的にディスパッチするテクはたまに使えますね

Swift 5.1でフレームワークを作っています。URL: https://github.com/rizumita/Seda このプロジェクトの中にSedaSampleAppというiOSサンプルアプリがあるのですが、そのライブラリをインポートしてこのアプリをシミュレーター用にビルドすると Undefined symbols for architecture x8664 になってしまいます。 ``` Undefined symbol: (extension in Seda):Seda.StatefulView< where A.Action: Seda.ActionType>.dispatch(A.Action) -> () Undefined symbol: (extension in Seda):Seda.StatefulView.state.getter : A.Substate Undefined symbol: (extension in Seda):Seda.StatefulView< where A.State == A.Substate>.stateKeyPath.getter : Swift.KeyPath<A.State, A.State> Undefined symbol: (extension in Seda):Seda.StatefulView.binding<A>(: Swift.KeyPath<A.Substate, A1>, set: (A1) -> Seda.ActionType) -> SwiftUI.Binding<A1> ``` インポートではなくライブラリのファイルをサンプルアプリターゲットに直接追加してビルドするとビルド・実行できます。ライブラリのビルド時にシンボルが正しく作成されてないみたいなのですが、何を修正すればいいかさっぱり分かりません。どう修正すればいいかお分かりでしたら教えていただけないでしょうか？

rizumita/Seda

Seda is Redux+Elm Cmd framework for SwiftUI. Contribute to rizumita/Seda development by creating an account on GitHub.

Seda.frameworkのBase SDKがmacOSだからじゃないかな。

3:40 AM

なんかSeda.frameworkターゲットのビルド設定がおかしいように見えます。

でももう一つのサンプルアプリはリンクできてるのか。なんでしょうね。これ。

ビルド済みのSeda frameworkを別のプロジェクトにImportすると問題ないので、プロジェクト構成の問題っぽいですね。

僕も見てみました。ビルドできない問題は同じエラーで再現しました。とりあえず、SedaSampleAppのソースを空にするとビルドできました。岸川さんの「別のプロジェクトでいけた」は、使ってる側のコードが無いからで、同じ状況かも？

4:05 AM

CounterView, CountHistoryView, OptViewのいずれかをプロジェクトに追加した時点で

4:05 AM

エラーが出るようになる。

問題のプロパティ・メソッドを使用するとエラーが発生するようになります。

ほんとですね。ある程度コードをコピー＆ペーストしてたけどそれじゃ再現しなくて

4:13 AM

全部ファイルをコピーしたら再現しました。

今の所特定のコードの書き方がコンパイラのバグを踏むんじゃないかと予想してます (edited)

ということはツールチェーンの問題かなあ。

SwiftUI関連のバグかどうかも疑ってる。

バグの可能性ですか。

はい。少なくともコンパイルフェーズは通ってるので

4:16 AM

リンクだけ通らないってのはSwiftの世界観だと普通起きないので。

4:16 AM

ビルド構成に間違いがあればそういうこともあるけどいまのところ変な部分は見当たらない。

むむむ

4:26 AM

public protocol StatefulView where Self: View { ^^^^^^^^^^^^^^^^ここ 消すとビルドできますね。 (edited)

4:29 AM

public protocol StatefulView : View {

4:29 AM

↑これでもビルドできます。

おお

protocol P where Self : <クラス名> は　やることがあるけど、 protocol P where Self : <プロトコル名>は普通やらないような？ protocol P : <プロトコル名>と意味の違いがあるんだろうか。

4:31 AM

protocol P where Self : <クラス名> は　やることがあるけど、

いや、これもSwift5から、 protocol P : <クラス名> と書けるようになったんだった。

4:32 AM

where Self : <プロトコル名> って書いたときの取り扱いにコンパイラにバグがある気がします。

なるほど。ありがとうございました！

Hello guys , I have some questions,, please help me! Now I studying for my test in December , I study a lot topics kind Swift , I have this question: what is better study and why. Rxswift or combine, why is better know reactive programming ? . What topics are important for my test (edited)

9:08 AM

Thank you so much and sorry for my beginners question.

I think most major value of stream style is that we can solve callback hell problem by them. https://techblog.yahoo.co.jp/javascript/nodejs/callback-to-promise/

Callback を撲滅せよ

こんにちは。言語サポート（Node.js）チームの伊藤（@koh110）です。Node.js v10 も10月にLTSとなり async/await によるフロー制御は当たり前のように利用されるようになってきました。JavaScript...

9:16 AM

↑This article is written about Promise, async await in JavaScript. They are not stream but can avoid callback hell. Same worth is in streams.

9:20 AM

Streams are more high level abstraction than Promises. They can encapsulate about start of asynchronous operations. A one of good example is .retry operator in ReactiveX.

1

9:22 AM

If you use stream more agressive, you can get power of immutable programming and safety. Everythins is a stream meme says about this style. https://www.google.com/search?q=everything+is+stream&client=safari&rls=en&sxsrf=ACYBGNSrL5EOg_7a__un_phY7QRiR-SjEw:1570526439303&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjippn0qozlAhXvGKYKHWI2DNYQ_AUIESgB&biw=1430&bih=779 (edited)

1

Thank you so much for your response omochi San

@vicktorManuel Basically I think Combine (as well as SwiftUI) can wait, at present RxSwift is still comparatively better to learn. Here's why: 1. Combine is too new and may have lots of destructive changes in the future, just like when Swift came out; where RxSwift is based on a well developed theory ReactiveX, which has been used on products for many years and has a very wide user base. 2. Combine can only be used on iOS later than 13, where RxSwift doesn't have that kind of limitation 3. Actually combine doesn't declare itself as a "Reactive Framework", therefore you don't see concepts like Stream, or Hot/Cold observables etc. Instead, Combine is just a framework provides a declarative Swift API for processing values over time (according to Combine's document). It has many things similar with Reactive programming, but it's not a Reactive tool. But personally, I would prefer Combine much better over RxSwift.

1

Thank you so much for your answers! Very complete answer, ありがとうございます

1

#swiftbot-sandbox のコンパイルできないやつ、どこから String が出てきたのかと思ったけど、これにマッチさせようとしているのかな。 https://github.com/apple/swift/blob/da61cc8cdf7aa2bfb3ab03200c52c4d371dc6751/stdlib/public/core/MigrationSupport.swift#L547-L555

https://forums.swift.org/t/se-0267-where-clauses-on-contextually-generic-declarations/30051

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

SE-0267 — where clauses on contextually generic declarations

The review of SE-0267 — where clauses on contextually generic declarations begins now and runs through October 31, 2019. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep yo...

1:09 AM

外側のパラメータに関するwhereを定義本体に書けるように文法の制限を廃止する提案

1:11 AM

型制約上の意味が同じでもマングリングが異なる記法が生まれる事になるので、その2種の間でのABI非互換が産まれるという指摘がされてるけど、その問題は今もすでにあるという指摘もあった。

あれ？これ元から出来ませんでしたっけ？

struct S<T> { func f() where T == Int { } // ^ 'where' clause cannot be attached to a non-generic declaration }

3:24 AM

↑の例だとSのパラメータTについてはfuncのところでは書けない。func fのパラメータ<X>だったら書ける。 (edited)

なるほど

3:36 AM

んーーー？なんか裏技あった気がするな

裏技ってこれ？ extension Array { func compact<T>() -> [T] where T? == Element { [] } }

落ち着いたら記憶を掘り起こすんでお待ちを (edited)

1

class Manul {} class Mike {} protocol NekoCargoBase { associatedtype InCargoCat } class NekoCargo<NekoType> {} extension NekoCargo: NekoCargoBase { typealias InCargoCat = NekoType } extension NekoCargo where InCargoCat == Manul { func meou() -> String { return "マヌルネコだよ！にゃーん" } } extension NekoCargo where InCargoCat == Mike { func meou() -> String { return "ミケネコだよ！にゃーん" } } let cargo: NekoCargo<Manul> = .init() print(cargo.meou())

なんかさっと思いついたものですが自信がない・・・ (edited)

1:26 AM

あ、でもfuncのところでかけないのは同じか

型パラがconformanceを持ってる時に、それ自体は指定できないがprotocolが持つassoctypeなら出来た気がするんですよね

1:29 AM

ん、ダメだな

1:33 AM

なにか親しい議論あった気がするんですよね~と検索してみたがヒットしたのは https://discordapp.com/channels/291054398077927425/291054454793306112/372686348395610114 だった。

1:38 AM

うーんextensionで書ききれない制約を、initのタイミングで縛ってごまかすっていうコードを書いた記憶があるんだが

1:38 AM

どこにしまったかな。。

extensionで書ききれない制約を、initのタイミングで縛ってごまかす

そもそも今回のやつは、型としての制約の表現能力が上がる話ではないので

3:01 AM

元からextensionで書けないものはこの変更が入っても書けないはず。

3:02 AM

単に今までextensionで書けたものが本体でも書けるように記法が増えるというもの。

3:02 AM

(ただ記法が増えてるだけじゃなくてABIは増える)

https://twitter.com/vguerra/status/1189636537576804352?s=21

Victor Guerra (@vguerra)

Differentiable Programming Manifesto now available in swift/docs https://t.co/kKI26eAHg6

https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376

SE-0269: Increase availability of implicit self in @escaping cl...

The review of SE-0269: Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur begins now and runs through November 12, 2019. The proposal is written by @Jumhyn. Reviews are an important part of the Swift evolution process...

7:00 PM

execute { [self] in let foo = doFirstThing() performWork(with: bar) doSecondThing(with: foo) cleanup() }

7:00 PM

明示的なselfキャプチャーによってクロージャ内でメソッドみたいにself.が不要

7:02 PM

軽く話してるけどこれ系すすまないよな〜と思ったらレビュー開始してた

これ　~~escaping~~ nonescaping なら self 省略できることと一貫性があっていいね。 (edited)

non escapingですか？

ああ、nonescaping

一貫性というのはクロージャの中でself省略するという記法が新しいものではないのが好ましいって意味です？

SE-0269: Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur

12:45 AM

タイトルがこれだから、サイクルが起きない時という意味で同じなのか

@escaping のときに明示的な self が必要なのはキャプチャが起こっていることを意識させるためだと理解してるけど、 [self] があればその役割はすでに果たされているので、 @nonescaping のときに self が省略できることを考えると、 @escaping かつ [self] がある場合もクロージャ内で self が省略できて良いはずという意味での一貫性。

@escaping のときに明示的な self が必要なのはキャプチャが起こっていることを意識させるため

あ〜なるほど。この認識は無かったけど、たしかに。

@swift-5.1.5

struct AError: Error {} struct BError: Error {} func foo<E: Error>(_ errors: [E]) { print(errors.map { "\($0)" }.joined(separator: ", ")) } let errors: [Error] = [AError(), BError()] foo(errors)

AError(), BError()

@swift-5.1.5

struct AError: Error {} struct BError: Error {} func foo<E: Error>(_ errors: [E]) { print(errors.map { "\($0)" }.joined(separator: ", ")) } foo([AError(), BError()])

exit status: 1 with stderr:

<stdin>:8:5: error: in argument type '[Any]', 'Any' does not conform to expected type 'Error' foo([AError(), BError()]) ^

Error 型が Error プロトコルに適合するようになったけど、 [AError(), BError()] みたいなのの型を [Error] と推論する部分の実装が足りてない？

1:41 PM

ちがった

1:41 PM

as [Any] をつけろと言われてるのか。

1:41 PM

ん？上のエラーは違うか

1:41 PM

@swift-5.1.5 struct AError: Error {} struct BError: Error {} let errors = [AError(), BError()]

exit status: 1 with stderr:

<stdin>:4:14: error: heterogeneous collection literal could only be inferred to '[Any]'; add explicit type annotation if this is intentional let errors = [AError(), BError()] ^~~~~~~~~~~~~~~~~~~~ as [Any]

@swift-5.1.5 struct AError: Error {} struct BError: Error {} let errors = [AError(), BError()] as [Error]

no output

さっきの↓では [Any] に推論された上でエラーになってる？ <stdin>:8:5: error: in argument type '[Any]', 'Any' does not conform to expected type 'Error' foo([AError(), BError()])

複数の候補がある場合は一つ通れば良いので

1:43 PM

探索されてないですね

Error を特別に Error に適合させたときに漏れたかな？

普通のPだとどうなるか気になりますね

普通の P は P に適合しないから

@objcをつけると

1:45 PM

する

@swift-5.1.5 protocol P {} struct A: P {} struct B: P {} let values = [A(), B()]

exit status: 1 with stderr:

<stdin>:5:14: error: heterogeneous collection literal could only be inferred to '[Any]'; add explicit type annotation if this is intentional let values = [A(), B()] ^~~~~~~~~~ as [Any]

↑この挙動は共通みたい。 === ↓ @objc つけた場合も同じ (edited)

1:49 PM

 1> import Foundation 2. 3. @objc protocol P {} 4. class A: P {} 5. class B: P {} 6. 7. func foo<X: P>(_ values: [X]) { 8. print(values.map { "\($0)" }.joined(separator: ", ")) 9. } 10. 11. foo([A(), B()]) error: repl.swift:11:5: error: in argument type '[Any]', 'Any' does not conform to expected type 'P' foo([A(), B()]) ^

1:49 PM

 1> import Foundation 2. 3. @objc protocol P {} 4. class A: P {} 5. class B: P {} 6. 7. func foo<X: P>(_ values: [X]) { 8. print(values.map { "\($0)" }.joined(separator: ", ")) 9. } 10. 11. foo([A(), B()] as [P]) __lldb_expr_1.A, __lldb_expr_1.B

1:53 PM

ぱっと見、それっぽいバグレポないなぁ。

そもそも <X: P> に対して (any) X==Pを発見するケースってあるんかな (edited)

1:56 PM

既に構成されてる P から推論するケースじゃなくて

1:56 PM

直接のPは書かれてないケース

1:57 PM

直感的には推論がちょっと重くなりそうな気がする、ErrorのSelf-conformのスレでも気にしていた人がいたな

@swift-5.1.5 struct AE: Error {} struct BE: Error {} func f<X: Error>(_ a: X, _ b: X) {} f(AE(), BE())

exit status: 1 with stderr:<stdin>:4:9: error: cannot convert value of type 'BE' to expected argument type 'AE' f(AE(), BE()) ^~~~

@swift-5.1.5 struct AE: Error {} struct BE: Error {} func f<X: Error>(_ a: X, _ b: X) {} f(AE(), BE() as Error)

no output

うーむ

2:07 PM

CombineやReactiveSwiftで不便なシーンがあったりするだろうか

2:08 PM

見つからない暗黙変換があるということで普通にバグ扱いなのかなあ

2:09 PM

bugs見たけど error の検索性が悪すぎて全くわからんｗ

2:10 PM

微妙なラインだし報告するのが良いやつな気がしてきてる

error の検索性が悪すぎて全くわからんｗ

それｗ protocol とか色々入れて検索してみたけど、ぱっと見ではなさそう。

2:13 PM

@swift-5.1.5 struct AError: Error {} struct BError: Error {} func foo<E: Error>(_ error: E) {} foo(AError())

no output

↑これはいけるっぽい。 (edited)

それは E == AError だと思う

あ、そうだった

2:13 PM

ボケてた

2:13 PM

最小ケースを作ろうとして削りすぎたw

これって型パラメータ一般の問題かと思ってたけど、 heterogeneous collection のリテラル限定の問題なのかな・・・。

いや、２引数のケースを試したので、リテラルより一般的です

ああ、壊れ方が違うだけか。

8:09 AM

複数引数のときは、一つ目の引数の型として推論されて

8:09 AM

二つ目の引数の型が違うと言われた。

solutionの候補は複数あるけど

8:10 AM

全ての失敗した候補の失敗した理由は表示されないので

@swift-5.1.5

struct AError: Error {} struct BError: Error {} struct List<Element> { init(_: Element...) {} } func foo<E: Error>(_ errors: List<E>) {} foo(List(AError(), BError()))

exit status: 1 with stderr:

<stdin>:10:20: error: cannot convert value of type 'BError' to expected argument type 'AError' foo(List(AError(), BError())) ^~~~~~~~

失敗した候補の中から最も正解に近そうなエラーを出すように選んでる

@swift-5.1.5

struct AError: Error {} struct BError: Error {} struct List<Element> { init(_: Element, _: Element) {} } func foo<E: Error>(_ errors: List<E>) {} foo(List(AError(), BError()))

(edited)

exit status: 1 with stderr:

<stdin>:10:20: error: cannot convert value of type 'BError' to expected argument type 'AError' foo(List(AError(), BError())) ^~~~~~~~

(edited)

@swift-5.1.5 struct AError: Error {} struct BError: Error {} func foo<E: Error>(_ errors: (E, E)) {} foo((AError(), BError()))

exit status: 1 with stderr:

<stdin>:6:1: error: cannot invoke 'foo' with an argument list of type '((AError, BError))' foo((AError(), BError())) ^ <stdin>:6:1: note: expected an argument list of type '((E, E))' foo((AError(), BError())) ^

@swift-5.1.5 class Base {} class A: Base {} class B: Base {} func foo<X: Base>(_ values: [X]) {} foo([A(), B()])

no output

supertypeは見つかるんですよね

@swift-5.1.5 class Base {} class A: Base {} class B: Base {} func foo<X: Base>(_ values: (X, X)) {} foo((A(), B()))

no output

(継承に関する)supertype境界の合成は常に行われる (edited)

8:17 AM

existentialは別枠

@swift-5.1.5

class Base {} class A: Base {} class B: Base {} struct List<Element> { init(_: Element...) {} } func foo<X: Base>(_ values: List<X>) {} foo(List(A(), B()))

no output

@swift-5.1.5

class Base {} class A: Base {} class B: Base {} struct List<Element> { init(_: Element, _: Element) {} } func foo<X: Base>(_ values: List<X>) {} foo(List(A(), B()))

no output

全パターン OK だな。

8:21 AM

一方で、↓はできるから、型パラメータの self-conformance の考慮漏れってことでいいのかな。 @swift-5.1.5 struct AError: Error {} struct BError: Error {} let errors: [Error] = [AError(), BError()]

no output

ambiguousになる場合を除いて、同じ式を型アノテートして型チェックが通せる場合に

8:22 AM

型アノテートが無い場合でも必ず型チェックが通る

8:22 AM

っていうのが型推論器の規約なら、バグって話になると思います

8:23 AM

計算量を考慮して特殊なケースでサボる仕様なら仕様で

8:23 AM

いずれにせよ報告してみないと確定しないやつだと思います

https://bugs.swift.org/browse/SR-11726

8:27 AM

立てた。

8:33 AM

バグじゃなくても as [Error] を明記してねっていうエラーメッセージの方が良さそう。

@swift-5.1.5 func foo<A: Any>(_ value: A) {} let a: Any = 42 foo(a)

no output

Any は self-conformance と言っていいのかな？

8:59 AM

Any はプロトコルじゃないんだっけ？

9:03 AM

@swift-5.1.5 func foo<A: AnyObject>(_ value: A) {} let a: AnyObject = \String.count foo(a)

no output

↓これ知らなかった。 @swift-5.1.5

protocol P {} struct FooError: Error, P {} func foo<E: Error>(_ error: E) {} let e1: Error = FooError() foo(e1) // OK let e2: Error & P = FooError() foo(e2) // NG

exit status: 1 with stderr:

<stdin>:10:1: error: protocol type 'Error & P' cannot conform to 'Error' because only concrete types can conform to protocols foo(e2) // NG ^

↓これは OK @swift-5.1.5

protocol P {} struct FooError: Error, P {} func foo<E: Error>(_ error: E) {} let e1: Error = FooError() foo(e1) // OK let e2: Error & P = FooError() //foo(e2) // NG let e3: Error = e2 foo(e3) //OK

no output

This self-conformance does not extend to protocol compositions including the Error protocol, only the exact type Error. It will be possible to add such compositions in the future, but that is out of scope for Swift 5.

https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md#adding-swifterror-self-conformance

https://forums.swift.org/t/pitch-exposing-the-memory-locations-of-class-instance-variables/30584

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

Anyは空のprotocol compositionだから

1:33 AM

制約の無いexsitentialであってそれ自体はprotocolではないという認識

1:35 AM

あ、どうなんだろう、protocolと考えても矛盾は無い・・・？

1:35 AM

Errorが合成に変なしばりあるの面白いですね

結構際どいけど、Anyは空のcompositionであるから、existentialもcoformできるのであって、self conformingではなさそう

@swift-5.1.5 func f<X: Any>(_ x: X) {}

no output

これ書けるのかよ。

1:39 AM

お、書けるけど、

1:39 AM

f<X>でもf<X: Any>でも同じシンボルになる $s6code011fyyxlF

1:39 AM

つまり書いても書いて無くても同じ

1:40 AM

@swift-5.1.5 protocol P: Any {}

no output

基本的にprotocolとして扱えるっぽいなｗ

1:40 AM

意味が常に無だけど

Any はともかく AnyObject は self-conformance ？ @swift-5.1.5 func foo<A: AnyObject>(_ value: A) {} let a: AnyObject = \String.count foo(a)

no output

ですね

any P が導入されたら Any の表記に違和感が出てきそうな気がしてるんですがどうでしょう？

6:53 AM

any P & Q とかを考えると any ？ any () とかかな？でも Never との整合性が・・・。

someもあるし良いのでは

some だけで型を表せる？？

7:21 AM

@swift-5.1.5 func foo() -> some { 42 }

exit status: 1 with stderr:

<stdin>:1:20: error: expected type for function result func foo() -> some { 42 } ^ <stdin>:1:22: warning: integer literal is unused func foo() -> some { 42 } ^~

大文字小文字のことを言っているのかと思った。

@swift-5.1.5 func foo() -> some Any { 42 }

no output

some Any ｗ

some Any からすると any Any？

any Any はいいかもだけど、 any Any が top で Never が bottom ってなんか微妙やんね。

Pitch: Exposing the Memory Locations of Class Instance Variables

Dear Swift folks, Here is a pitch to plug a small hole in the stdlib API by providing a reliable method to retrieve the address for any directly addressable stored property inside a class instance. The need to work with such addresses comes up particularly often when we try ...

9:07 AM

クラスインスタンスのプロパティのストレージアドレスを取れるようにするピッチ

9:11 AM

マジで用途が限定的だけど言語としてはあってよさそう

https://github.com/apple/swift-evolution/blob/master/proposals/0223-array-uninitialized-initializer.md Arrayのuninitialized initializerが導入されて久しいですが、 UnsafeMutableBufferPointerのn番目の要素をinitializeのするのに var p = bp.baseAddress! + n p.initialize(to: value) みたいにちょっと長くなるのが気になってるんですが bp.initialize(index: n, to: value)みたいなのを導入するピッチ投げたら良いんですかね？インターフェース的にこうしたほうが良さそうとかあります？

https://forums.swift.org/t/se-0270-add-collection-operations-on-noncontiguous-elements/30691/

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

baseAddress.advanced.initializeは？

あーそれできますね。

2:45 AM

一応bp.initializeなら範囲チェック入れられるというメリットはありますがunsafeな時点で微妙か……

bp[n] = value

initializeしたい場合なんですよね。 (uninitialize状態で書き込んだときどういう弊害が起こるのかはイマイチ理解できてないんですが)

プロポーザルのサンプルにも書かれてる方法だけど。

んー確かにありますね。stablyPartitionedのほうだけ見てました。

bp[n] = value は左辺がinitializedな状態で使わないと不正ではないか

7:29 AM

今はメモリがuninitializedな状態なので

7:29 AM

誤った仮定をおくと、無意味なビット列に対して破棄操作が起こってしまう。

7:29 AM

Intみたいなtrivialな型の場合は問題は起きない。

中身によるってことですか？

中身って？

UnsafeMutableBufferPointer<T>のT (edited)

うん、initialized/uninitializedを無視しても良いかどうかは型による (edited)

@swiftbot

class MyClass { var i: Int init(_ i: Int) { print("init: \(i)") self.i = i } deinit { print("deinit: \(i)") } } do { print("# init array") var array = [MyClass(1), MyClass(2)] print("# assign 3") array[0] = MyClass(3) print("# assign 4") array.withUnsafeMutableBufferPointer { bp in bp.baseAddress!.initialize(to: MyClass(4)) } print("# exit do") }

1

t.ae

class MyClass { var i: Int init(_ i: Int) { print("init: \(i)") self.i = i } deinit { print("deinit: \(i)") } } do { print("# init array") var array = [MyClass(1), MyClass(2)] print("# assign 3") array[0] = MyClass(3) print("# assign 4") array.withUnsafeMutableBufferPointer { bp in bp.baseAddress!.initialize(to: MyClass(4)) } print("# exit do") }

Version:

swift-5.1-RELEASE

Output:

# init array init: 1 init: 2 # assign 3 init: 3 deinit: 1 # assign 4 init: 4 # exit do deinit: 4 deinit: 2

Error:

完全に理解した

そうだね、この場合は破棄がされない方の間違いだから3がリークしてる (edited)

逆に未初期化状態のところに代入しようとするとdeinitでおかしなことになるわけですね。

0ビットで埋まってればnilポインターだから何も起きないけど、0クリアされていない場所だったら、アドレスとみなしてむりやりdeinitしようとしてクラッシュするね (edited)

8:01 AM

uninitialized initializerのモチベーション自体が、そのゼロクリアをスキップすることでパフォーマンスを最適化するAPIだから

8:01 AM

当然ゼロクリアされていないメモリ領域があてがわれた場合の事を適切に考えないといけない

なるほど。

SE-0270: Add Collection Operations on Noncontiguous Elements

The review of SE-0270: Add Collection Operations on Noncontiguous Elements begins now and runs through November 21, 2019. The proposal is written by @nnnnnnnn. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum t...

1:32 AM

Rangeを複数くっつけてコレクションとして振る舞うRangeSetの審査

1:32 AM

唐突に凝ったのが来た Pitch見逃してたんかな

var numbers = Array(1...15) // Find the indices of all the even numbers let indicesOfEvens = numbers.indices(where: { $0.isMultiple(of: 2) }) // Perform an operation with just the even numbers let sumOfEvens = numbers[indicesOfEvens].reduce(0, +) // sumOfEvens == 56 // You can gather the even numbers at the beginning let rangeOfEvens = numbers.gather(indicesOfEvens, justBefore: numbers.startIndex) // numbers == [2, 4, 6, 8, 10, 12, 14, 1, 3, 5, 7, 9, 11, 13, 15] // numbers[rangeOfEvens] == [2, 4, 6, 8, 10, 12, 14] // Reset `numbers` numbers = Array(1...15) // You can also build range sets by hand using array literals... let notTheMiddle: RangeSet = [0..<5, 10..<15] print(Array(numbers[notTheMiddle])) // Prints [1, 2, 3, 4, 5, 11, 12, 13, 14, 15] // ...or by using set operations let smallEvens = indicesOfEvens.intersection( numbers.indices(where: { $0 < 10 })) print(Array(numbers[smallEvens])) // Prints [2, 4, 6, 8]

1:44 AM

↑歯抜けのindexの並びみたいなもんを扱える

Pitch出てたよ https://forums.swift.org/t/pitch-add-rangeset-and-related-collection-operations/29961

Pitch: Add RangeSet and Related Collection Operations

Hi folks! Here's a pitch to fill a missing chunk of functionality in the standard library around noncontiguous ranges of elements. Please take a look at the draft proposal below, and/or try out this new functionality by using the SwiftPM package here: https://github.com/nate...

お。

https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376

SE-0269: Increase availability of implicit self in @escaping cl...

The review of SE-0269: Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur begins now and runs through November 12, 2019. The proposal is written by @Jumhyn. Reviews are an important part of the Swift evolution process...

7:12 AM

これって、

7:13 AM

let a = obj() let f = { [self = a] in hoge() // call a.hoge } これできんのかな。

7:13 AM

できるなら他の言語のスコープ文みたいな機能が爆誕してる事になる

テストケース見る限り、それはできなさそう。 https://github.com/apple/swift/pull/23934/files#diff-d7c6f9df7278996950aba8a8ba87de75R176

doStuff({ [self = self.x] in x+1 }) // expected-note {{variable other than 'self' captured here under the name 'self' does not enable implicit 'self'}} expected-warning {{capture 'self' was never used}} expected-error {{reference to property 'x' in closure requires explicit use of 'self' to make capture semantics explicit}}

お、なるほど。ありがとうございます。まーそうか。

doStuff({ [self = self.x] in x+1 })

1:12 AM

英語がわからないのですが、これでキャプチャされるのは self ではなく self.x だけですか？

そうです、キャプチャリストは [var = exp] の形でかけて、クロージャを作る時にexpが評価されます

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

12:16 AM

そうなるとオーナーシップ関連のバグが仕込めそうですね。気を付けないと。

へんな状況を色々考えたけど僕にはオーナーシップ関連のバグが作れなかったｗ

6:39 AM

大丈夫なのかな？

キャプチャリストの仕様とは関係ない話なら、classをプロパティに持つstructをキャプチャに絡ませるとリークが避けられない、みたいな話ならありますよ

こうやればいいのかな？

struct A { var x: Int = 0 { didSet { doSomething() } } } func hoge() { var a = A() // take ownership of a. DispatchQueue.global().async { [x = a.x] in // take ownership of a ??? sleep(100) x = 9 } // release ownership of a. }

の時にdoSomething()が呼び出されるのかどうかというか、aのオーナーシップがどうなるのか。 (edited)

それだと xの型は let x: Intで、 x = 9はエラーになりそうそれと、x = a.xの評価はクロージャの構築時になるので、aのオーナーシップはクロージャは取りませんクロージャ構築時にa.xを読み取るだけでaは無くなる

キャプチャリストはオーナーシップの指示だけのものと思ってました。

8:27 AM

キャプチャリストに入れるとクロージャ内ではimmutableになるんですね。

8:28 AM

根本的なところが間違ってた

func highFunc(_ f: () -> Void) { f() } func main() { var a: Int = 3 highFunc { [a] in a = 5 // Cannot assign to value: 'a' is an immutable capture } }

(edited)

8:29 AM

たしかに、varのmutable captureを

8:29 AM

capture listで書く方法がなさそうですね

それが出来ると壊れるので、出来ないのが正解の気がします

func main() { var a: Int = 3 highFunc { () in a = 5 } } ↑これはできるよ。

それはescapingじゃないならokの気がする (edited)

escapingじゃないからOKの理屈なら元記法も通らないと一貫性が無くない？

8:35 AM

暗黙のキャプチャーは何らかの明示的なcapture list表記に対応すると思ってたんだけど

キャプチャリストでmutability伝搬できちゃうとescapingで壊れない？

暗黙のキャプチャーのときだけできるパターンがあるのは変

というかnon-escapingだとそもそもcapture不要の認識であった

class C { var f1: (() -> Void)? var f2: (() -> Void)? } func proc(c: C) { var a: Int = 3 c.f1 = { a += 1 } c.f2 = { print(a) } } func main() { let c = C() proc(c: c) c.f1?() c.f2?() } main() // => 4

8:39 AM

↑escapingで暗黙のcapture(var a)する例

クロージャのキャプチャは、クロージャ作成時点での変数の値をローカル変数（的な物）にコピーするだけなので、 let closure: () -> Void = { [x] in print(x) } は let closure: () -> Void do { let x = x closure = { in print(x) } } とほぼ同意です。

お、その書き換えは面白いですね。明示的なキャプチャーを暗黙のキャプチャーに書き換えている。

public func foo1() -> () -> Void { var x = 1 let closure: () -> Void = { [x] in print(x) } return closure } public func foo2() -> () -> Void { var x = 1 let closure: () -> Void do { let x = x closure = { () in print(x) } } return closure }

これのSILを出力すると

8:58 AM

foo1 と foo2 はほぼ同じになる。

8:58 AM

// foo1() sil @$s4test4foo1yycyF : $@convention(thin) () -> @owned @callee_guaranteed () -> () { bb0: %0 = alloc_stack $Int, var, name "x" // users: %3, %10, %4 %1 = integer_literal $Builtin.Int64, 1 // user: %2 %2 = struct $Int (%1 : $Builtin.Int64) // users: %8, %6, %3 store %2 to %0 : $*Int // id: %3 %4 = begin_access [read] [static] %0 : $*Int // user: %5 end_access %4 : $*Int // id: %5 debug_value %2 : $Int, let, name "x" // id: %6 // function_ref closure #1 in foo1() %7 = function_ref @$s4test4foo1yycyFyycfU_ : $@convention(thin) (Int) -> () // user: %8 %8 = partial_apply [callee_guaranteed] %7(%2) : $@convention(thin) (Int) -> () // users: %11, %9 debug_value %8 : $@callee_guaranteed () -> (), let, name "closure" // id: %9 dealloc_stack %0 : $*Int // id: %10 return %8 : $@callee_guaranteed () -> () // id: %11 } // end sil function '$s4test4foo1yycyF'

8:58 AM

// foo2() sil @$s4test4foo2yycyF : $@convention(thin) () -> @owned @callee_guaranteed () -> () { bb0: %0 = alloc_stack $Int, var, name "x" // users: %3, %14, %5 %1 = integer_literal $Builtin.Int64, 1 // user: %2 %2 = struct $Int (%1 : $Builtin.Int64) // users: %9, %7, %3 store %2 to %0 : $*Int // id: %3 %4 = alloc_stack $@callee_guaranteed () -> (), let, name "closure" // users: %10, %12, %13 %5 = begin_access [read] [static] %0 : $*Int // user: %6 end_access %5 : $*Int // id: %6 debug_value %2 : $Int, let, name "x" // id: %7 // function_ref closure #1 in foo2() %8 = function_ref @$s4test4foo2yycyFyycfU_ : $@convention(thin) (Int) -> () // user: %9 %9 = partial_apply [callee_guaranteed] %8(%2) : $@convention(thin) (Int) -> () // users: %11, %15, %10 store %9 to %4 : $*@callee_guaranteed () -> () // id: %10 strong_retain %9 : $@callee_guaranteed () -> () // id: %11 destroy_addr %4 : $*@callee_guaranteed () -> () // id: %12 dealloc_stack %4 : $*@callee_guaranteed () -> () // id: %13 dealloc_stack %0 : $*Int // id: %14 return %9 : $@callee_guaranteed () -> () // id: %15 } // end sil function '$s4test4foo2yycyF'

9:00 AM

クロージャのタイプは @convention(thin) (Int) -> () で一緒であって、それに partial_apply de

%8 = partial_apply [callee_guaranteed] %7(%2) : $@convention(thin) (Int) -> () // users: %11, %9

キャプチャさせてる。

x一個だからpartial applyするのがInt１個？

だと思います。

お、増やしたらちゃんと増えた

9:03 AM

SILの状態だとキャプチャ前の生関数とキャプチャ後のクロージャの型がちゃんと見えていて、partial_applyでちゃんと型の式になってるんですね

手元でいろいろ遊んで勉強し直しました

1:30 PM

めちゃくちゃためになりました

1:30 PM

皆さんありがとうございます

はじめまして。swiftサーバに最近参加したにーの（ @n_shhhin ）と申します。今現在バックグラウンドで加速度を取得したい状況で、Background系の開発に疎いので手助けが欲しいです。AppStoreにリリースするのは目的ではないので、プロトでできればいい程度に思っていますそこで質問なのですが、 iOS13で導入されたBackgroundTaskは

BackgroundTask、 ●Background Processing Tasks - 数分かかる処理 - 延期可能なメンテ処理やCoreMLによるトレーニングを想定 ●Background App Refresh Tasks - 30秒のランタイム - アプリを最新の状態に保つための用途を想定 - performFetchのAPI が代わりにdeprecatedに

みたいな感じの仕様らしいのですが、background processの数分ってのは実際どれぐらい処理が続く感じなんでしょうか。また BackgroundTask では実現できないなら他の案をご教授いただきたいです。既存アプリのGoogleフォトとかはバックグラウンドで常に写真のアップロードを監視してたりするのでできないことはないと思うのですが、どうやってバックグラウンドで常時処理をするのかが気になりました。よかったらどなたか強い人回答お願いします。 https://github.com/nshhhin/Background-Accel-Swift (edited)

nshhhin/Background-Accel-Swift

バックグラウンドで加速度を取るプログラムSwift. Contribute to nshhhin/Background-Accel-Swift development by creating an account on GitHub.

#beginner-help-archived にどうぞ

すいません！ここは別枠のチャンネルなんですね！ありがとうございます

https://forums.swift.org/t/accepted-se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/31064

[Accepted] SE-0269: Increase availability of implicit self in @esc...

SE-0269 has been accepted. Thank you to everyone who participated in the review!

2:41 AM

selfキャプチャーでself.の省略、通った

2:42 AM

自分はRxSwift.Singleではselfキャプチャーしてるからだいぶコードがスッキリしそう

これは [self] in ... と最初に書いておくとBodyで self.foo じゃなくて foo って書けるってものですよね？

そうです〜

4:29 AM

nonescapingなクロージャでは従来も何もせずとも foo と書けたが、 escapingなクロージャにおいても [self]による明示的なself captureをすると、同様にfooと書けるようになる。

Proposalにも書いてあるとおりSwiftUIの記述がだいぶスッキリしますね。

4:35 AM

GeometryReaderで包んだらself書きまくらないといけないのがなくなるかな？

return省略と同じでSwiftUIをスッキリさせたい気持ちを感じる

まあOSがうまくやってくれてselfとか意識しないで済むならその方がいいですね。

参照カウントだから意識するのはやめられない・・・

呼ばれる方でうまくやってくれれば。。。SwiftUIはたぶん何も考えずにselfキャプチャしても（するしかない）大丈夫（？）だからそんな感じで。

https://twitter.com/jckarter/status/1202260205074968578

https://www.youtube.com/watch?v=xOBGZ0FG6j0&feature=youtu.be

In the master branch of the Swift compiler, we now have a first pass at cross-module optimization, allowing generic specialization across packages without manual @inlinable annotations! https://t.co/D0uM3PsNc1

あるSwiftアプリでEXC_BAD_ACCESSでクラッシュして理由が表示されないのですが、Address Sanitizerをオンにするとクラッシュせずに実行できるようになります。どうやって原因を探ればいいでしょうか？

クラッシュしてるコードの行やその瞬間のコールスタックはデバッガでわかるので、そこから、まずはどこでクラッシュしてるのかを調べますそれでもわからなかったらその周辺のコードだけ新規アプリに持っていって、原因箇所と最小表現コードを探すそれができたら自分のコードの問題なのかコンパイラのバグなのかわかる

5:16 AM

ASANが無効だと大丈夫ならわかるが、有効だと大丈夫だとすると、コンパイラが怪しい気もするけど

ですよね。で、コールスタックなんですがクラッシュした行の次は0x00000000で終わってるんで、何も分からないです。サンプル作ってみても同じところでクラッシュします。ちなみにクラッシュするのは自作ライブラリの行で、SPMで導入したものがクラッシュして、ライブラリ内にあるサンプルプロジェクトではクラッシュしないという状態です。 (edited)

1:34 PM

コールバックじゃなくてコールスタック。

サンプルプロジェクト見せてもらうことできますか？

これかも https://bugs.swift.org/plugins/servlet/mobile#issue/SR-11564/comment/51285

SwiftPM限定ならSR-11564っぽいなあ。

DEAD_CODE_STRIPPING = NOでいけました。ありがとうございます！

自分の場合、これを踏んだとき、RxSwiftのジェネリックなクラスを初めて使う時の、クラス生成の処理内部で落ちてる感じでしたが、

1:59 AM

コールスタックなんですがクラッシュした行の次は0x00000000で終わってるんで、何も分からない

これがどういう状態なのかわからず気になる (edited)

2:00 AM

Xcodeのコールスタック表示は、ライブラリの部分を非表示にするモードがあるのですが、それで非表示になっている事はないですかね

無いと思うんですが、どこ見たらいいですか？

左のカラムの右下に青くなってるよく分からないボタンがあった気がする (edited)

明日動画上げますね

おもちメタル

SR-11564

1:39 AM

@rizumita ↑こんな感じです

閉じてました。が、開いてもクラッシュした個所の次は0 0x00000000で、そこまででした。

なるほど・・・

8:19 AM

関数ポインタがnullだったとかなのかなあ。

https://forums.swift.org/t/pitch-modify-accessors/31872

Pitch: Modify Accessors

Hi Swift Evolution, Some holiday reading for you, a pitch of a new way of writing mutable computed properties and subscripts. For more information on the performance implications of this change and why it's an important feature to add, you might also find this talk from las...

6:22 PM

modify accessorのピッチ！コルーチンが来るぞ〜〜〜〜

プロポーザルを見たときは、コルーチン中断時のクリンナップ制御にdefer使うのはクールだと思ったけど

1:32 AM

書き込み見てたら、非直感的で良くないなと思えてきた

これが出来るようになると、RxSwiftのVariable(もうdeprecatedだけど)のlock機構とかがちょっと良くなりますね

lock機構とは？

コードだそうとしたけどもう完全に消えてるのかw

4:31 AM

https://github.com/ReactiveX/RxSwift/blob/4.5.0/RxSwift/Deprecated.swift#L190-L206

https://github.com/apple/swift/pull/28916

Reactive Programming in Swift. Contribute to ReactiveX/RxSwift development by creating an account on GitHub.

4:32 AM

getとsetにlockが入ってるんですが、これだと値型のプロパティ変更で不整合が起きる可能性があるんですよね。_modifyならその可能性もなくなる。 (edited)

4:33 AM

variable.cat.age+=1 例えばこういうことが以前よりも安全に出来るようになる

ふむふむ

4:52 AM

以前の不整合が起きる手順がわからないけど、マルチスレッドとか自己の循環参照とかなら、 modifyになったところで同じように壊れる気もする

4:53 AM

modifyアクセサが排他せずに2個重ねて実行されて。

4:54 AM

あいや、ペアとなるget/setがまとめてmodifyの流れの中で頭とお尻でロックできるから

4:54 AM

今までと違うポリシーでロックできるのか。

そうです

4:56 AM

get get set setが発生して壊れていたのが

4:56 AM

modify modifyにしかならなくなるので、安全

なるほど〜

[Typechecker] Allow enum cases to satisfy static var { get } proto...

Allow payload-less enum cases to witness a static, get-only Self property protocol requirement. For example: protocol Foo { static var bar: Self { get } } enum Baz: Foo { case bar // Okay } Pa...

2

12:32 AM

これ最近話題に出たやつだ。

これ欲しい場面あったな

これってこの後プロポーザルが挙がるんでしょうか？

5:21 AM

それとも今までの挙動がバグ扱い？

どうなんでしょーー

5:24 AM

バグチケットの方にまだ

5:24 AM

コアチームの見解が書いてないすね

あっPRはごく最近できたのだったんですね

swift-5.2-DEVELOPMENT-SNAPSHOT-2020-01-06-aが出てる。

5:11 AM

型情報一切無いポインタなのにLLDBさんがそれがなんのwitness tableか教えてくれてる。

5:11 AM

シンボルテーブルと突き合わせてデマングルしてるのか？

5:12 AM

それともデバッグ用情報的なやつでわかるのか？

シンボルテーブルと突き合わせて

これだと思います。image lookup -a でシンボル見えます

1

@Yuta Saito

(lldb) image lookup -a 0x00007fff80870028 Address: libswiftCore.dylib[0x000000000039a060] (libswiftCore.dylib.__DATA_CONST.__const + 67528) Summary: libswiftCore.dylib`value witness table for Builtin.Int64

5:47 AM

ありがとう　なんかできてそう

1

-vオプションつけるとデマングルされる前のシンボルも見えます (edited)

ああ、Summaryこれdemangleしてるだけか

https://github.com/omochi/EquatableOpen

omochi/EquatableOpen

Contribute to omochi/EquatableOpen development by creating an account on GitHub.

7:57 AM

できた〜

Linuxだとdlsymが動かない・・・

9:24 AM

# nm -a /usr/lib/swift/linux/libswiftCore.so | grep sSQMp 000000000043e484 R $sSQMp # nm -a .build/debug/EquatableOpenPackageTests.xctest | grep s13EquatableOpen0A6OpenerMp 000000000000d524 R $s13EquatableOpen0A6OpenerMp

9:24 AM

$sSQMp　は見つけられるのに $s13EquatableOpen0A6OpenerMp が見つからない。

dlsym、Xcodeでプロジェクト作っても動かなくなる場合がありますね

iOSはSwiftPM依存で取り込んだら動いたよ

おお

swift_conformsToProtocolも大丈夫だなあ。なんか違う属性がついてるのかな。

9:27 AM

public protocol Equatable { /// Returns a Boolean value indicating whether two values are equal. /// /// Equality is the inverse of inequality. For any values `a` and `b`, /// `a == b` implies that `a != b` is `false`. /// /// - Parameters: /// - lhs: A value to compare. /// - rhs: Another value to compare. static func == (lhs: Self, rhs: Self) -> Bool }

9:27 AM

う〜む。

9:30 AM

# swift test -Xlinker -export-dynamic

9:30 AM

これでいけた

9:30 AM

https://stackoverflow.com/questions/19713517/how-to-self-dlopen-an-executable-binary

how to self dlopen an executable binary

I wrote a program to dlopen itself void hello() { printf("hello world\n"); } int main(int argc, char *argv) { char *buf="hello"; void *hndl = dlopen(argv[0], RTLD_LAZY); void (fptr)(void) = dlsym(

9:31 AM

Linuxでは実行ファイル自身を動的リンク可能にするにはリンカの指定が必要とのこと

https://qiita.com/takasek/items/f51c26a8ee6a2929bb6e 昔書いた記事がいいねされて、こんなん書いたっけと思い出したんですけど decodeで明示的に型指定してるのを推論させるextensionなんですが、今振りかえってもやっぱり、別にこれでいい気がしてるなんか型推論に寄せることによる懸念を思いつく人いますか

Decoder, DecodingContainerの、デコード先の型を推論さ...

デコード先の型を推論させたいという、ヒトなら誰しもが持つ欲望

@inamiy さんのスライド [Swift 4 Codable // Speaker Deck](https://speakerdeck.com/inamiy/sw...

ドーグの言う通り、「型推論は時々マジカルすぎる」というのはわかる

9:35 AM

型を解決するためには

9:36 AM

左辺か右辺の型がわからないといけないけど

9:36 AM

大体の場合は右辺から指定したい気持ちがある。

9:36 AM

これは評価順序と推論方向が一致してる方がわかりやすいから。

9:37 AM

で、タカセックの例だと

9:37 AM

大元のデコードは右から指定したいので推論拡張は不要で、、

9:37 AM

プロパティのデコードは、プロパティの型があるから左から推論できるんだけど

9:38 AM

そういう単純なパターンの場合はそもそもContainer操作を手書きしないで自動生成に寄せるべきだと思う

9:38 AM

自動生成に寄せられないようなややこしいケースがあるとしたら、そのときは右から推論させたい

9:39 AM

なので、良し悪し以前に利用シーンが個人的には無い気がする。

そういう単純なパターンの場合はそもそもContainer操作を手書きしないで自動生成に寄せるべきだと思う

それは同意で、ただ部分的にできればいいんだけど、そうはいかないのが現状の問題かと僅かな例外ケースのために、9割以上は単純なボイラープレートをひたすら書くことになる

どんなケース？

struct Hoge: Decodable { ... (10個くらいある単純なプロパティ) let isIPhone: Bool }

9:43 AM

ちがうな、これだとCodingKeysでいいか

1個でもカスタムにすると全部書くことになると思うのだけど

そう、そのこと

そういうときは

9:45 AM

そのカスタムしてるエンコード方法に対応するstructを一つ作った上で

9:45 AM

自動生成用の型を別に作ってる

9:45 AM

で、自動生成用の型と、元々のモデル型の間の変換だけ書いたら

9:46 AM

Codableになるようにプロトコルを使ってる。

9:46 AM

https://github.com/omochi/WeaselRoll/blob/master/Sources/WeaselRoll/Codable/CodableProxy.swift

Contribute to omochi/WeaselRoll development by creating an account on GitHub.

9:47 AM

↑利用側のコードが上がってないから説明不足になるけど、そのプロトコルはこれ

9:47 AM

プロパティごとにContainerのコードを書くよりは

9:47 AM

init(fromCodableProxy proxy: CodableProxy) throws

9:47 AM

を実装する方が、意味の露出が少なくて安全だし

9:48 AM

記述量がすくない

例えばカスタムデコーダーをどうしても書きたい(手書きになる)みたいなケースが、例えばenumとかでよくあるんだけど

9:52 AM

或いはUInt64はiOS10でバグるのでどうしても手書きが必要、とか (edited)

9:52 AM

まあその辺では左辺が型を決定しているのでselfで埋めて貰えると助かるな、というのはわかる

type名で分岐するパターンはちょっと書くことになるね

そうそうおもちさんのはこれはこれで興味深いけどちょっと解決したいものが違う

enumのassociatedValueに直接decodeする場合はまあ左からの推論になるか。

9:55 AM

そういう時は使うメリットはあると思うレアケースだから右に型書いて不便は無いけど

9:55 AM

ドーグが言うマジカルなケースは

9:55 AM

その通り時々なので

9:55 AM

そもそもそういう、まずい使い方に関しては

9:56 AM

俺は、まずい使い方はしなければ良い派なので、

9:56 AM

正しく使う前提で便利だとは思うよ。

9:57 AM

なんかリテラルとかガチャガチャ絡めた式でいつのまにかIntからFloatにかわっちゃって壊れるとかがあるんじゃない？そういうところでは右に書けと思う

うーん、そもそもそういうケースではambiguousになるはずなので

そうとは限らないよ

9:58 AM

1を1.0に書き換えちゃうとか。

"""{ "a": 1 }""" struct A { let a: Int } が """{ "a": 1.0 }""" struct A { let a: Int } に書き換わるって話？

var foo = try decode(from: json) + 1 こういう無茶苦茶な推論が通るのはちょっと…というのはまあわからんでもない

タルノンの例だね 1.0にかきかわるって言ったのはSwiftコード側の話

10:01 AM

そうそう。そういう変な書き方ができるのは後でややこしい壊れ方をするかも？ぐらい。

10:01 AM

まあ変なコードはいくらでも錬成できると思う

左辺で型が決まらないケースなら右辺に明示したいのはよくわかる

10:03 AM

でもたいていの場合は左辺が型決めてるでしょdecodeって

左辺で決まっていないにも関わらず右辺のリテラルから推論できちゃう、というのは何か別の問題な気がしていて

そこの、たいてい、には同意できないという事。

10:03 AM

そのたいていのケースは手書きしない方に解決できるから。

それをType引数のデフォルトを否にするのと絡めてるのはあんまり良くない肝

右辺のリテラルから決まるのは足し算の引数の合流から決まってるから

10:05 AM

左とも右とも呼びづらいなw

10:05 AM

隣？

型推論的にはdecodeから見たら左が決定してそう

まあコンテキスト的に決まってるという意味では左だけども

10:06 AM

そだね

10:06 AM

use position側からきまっとる

10:08 AM

たかせく自身が「ボイラープレート」でたくさん書くって主張してるけど

10:08 AM

ボイラープレートをたくさん書いてる場合はまずそれを最小化した後で

10:08 AM

議論すべきだと思う

10:10 AM

タルノンの言う

10:11 AM

enumの分解をたくさん書いてる話も

10:11 AM

EitherJSON3<A,B,C>みたいな型を一度作れば

10:11 AM

Container操作は再利用できる気がする。

ボイラープレートをたくさん書いてる場合はまずそれを最小化

うーん、この手段が見えてない DecodableProxyがその解決策になってる気がしないんですよねコード全体が見えてなくてぴんときてないのかもだけど

後で例を出しますね

あとおもちさんのHasDecodableProxyは他にも（あるいは他じゃないのかもしれないけど）引っかかるところがあって、 3層レイヤードアーキテクチャ View - Model - Infra 層があったとして、 CodableProxyはInfra層のDTO HasDecodableProxyはModel層のDomainObject になると思っていいかなそうすると、 1. 依存の方向を Model <- Infra にしたいけど、HasDecodableProxyの構造だとそれができない 2. CodableProxyがひとつに固定されてしまうという問題がある

依存の方向を Model <- Infra にしたいけど、HasDecodableProxyの構造だとそれができない

雑に言えばmemberwise initializerがinternalになるのと同種の問題だと思ってよくて、 DTOをInfra層に閉じ込めようとするとHasDecodableProxyをInfra側にextensionで書くことになるそうするとDomainObjectのpublic memberwise initializerを手で書かにゃならん DomainObjectにプロパティがたくさんあった場合、

public memberwise initializer
init(fromCodableProxy proxy: CodableProxy)

を手作業で書きまくって、それぞれをメンテしなきゃいけないの気が遠くなりそう

CodableProxyがひとつに固定されてしまう

明確な問題はたとえばCatを取得したくて、 V1 APIとV2 APIでレスポンス構造が変わるけどどちらもクライアントでは同じCatとして扱いたいそうすると以下のようになると思うんだけど

CatDTOV1: { id: Int, name: String, ownerID: Int, ownerName: String, ... } CatDTOV2: { id: Int, name: String, owner: Owner, ... }

struct Cat: HasDecodableProxy { typealias CodableProxy = CatDTOV1??CatDTOV2?? } このときassoctypeとしてProxyはV1かV2かどっちかひとつに固定されるのはきつくない？ (edited)

そういう場合は Model層のDomainObjectとしてのCatと、

10:51 AM

V1APIのCatと、V2APIのCatは別の型にしている。

10:52 AM

V1APIのCatの中で、Codable実装のためだけに、CodableProxyを使う。

10:52 AM

CodableProxyはInfra層のDTO HasDecodableProxyはModel層のDomainObject

両方ともDTOということ。

10:54 AM

 public struct PlayerM: HasCodableProxy { public var trackingID: String public var id: Player.ID public var x: Float public var y: Float public var distance: Float public var speed: Float public var position: GLKVector2 { GLKVector2(x, y) } public struct CodableProxy: Codable { public var id: String public var no: Player.ID @FormatCoding<FloatStaticFormatter> public var x: Float @FormatCoding<FloatStaticFormatter> public var y: Float @FormatCoding<FloatStaticFormatter> public var distance: Float @FormatCoding<FloatStaticFormatter> public var speed: Float } public init(trackingID: String, id: Player.ID, x: Float, y: Float, distance: Float, speed: Float) { self.trackingID = trackingID self.id = id self.x = x self.y = y self.distance = distance self.speed = speed } public init(fromCodableProxy p: CodableProxy) { self.init(trackingID: p.id, id: p.no, x: p.x, y: p.y, distance: p.distance, speed: p.speed) } public func encodeToCodableProxy() -> CodableProxy { CodableProxy(id: trackingID, no: id, x: x, y: y, distance: distance, speed: speed) } }

10:56 AM

↑最近のだとこんなの @FormatCoding<FormatStaticFormatter>　は Floatを %.2f 書式の文字列としてエンコードする型

10:56 AM

public struct CameraCalibration: Codable { public typealias JSON = [CameraCalibration] public var fov: Float @ColumnMajorFloatArray9Coding public var rotation: GLKMatrix3 @FloatArray3Coding public var translation: GLKVector3 public init(fov: Float, rotation: GLKMatrix3, translation: GLKVector3) { self.fov = fov self.rotation = rotation self.translation = translation } }

10:57 AM

↑こっちはCodableProxyは使ってないけど、 @FloatArray3Coding などが、3次元ベクトルを 3要素Float Array にエンコードする型

10:57 AM

ちょっと手元のテクニックが移行期で、PropertyWrapperを使うことによってCodingProxyが不要になりつつある・・・

10:58 AM

public struct PlayerSpecifier : HasCodableProxy, Hashable { public struct CodableProxy : Codable { public var teamID: Team.ID public var teamColor: ColorProxyRGB public var playerID: Player.ID public var name: String } public var teamID: Team.ID public var teamColor: Color public var playerID: Player.ID public var name: String public init(teamID: Team.ID, teamColor: Color, playerID: Player.ID, name: String) { self.teamID = teamID self.teamColor = teamColor self.playerID = playerID self.name = name } public init(fromCodableProxy p: CodableProxy) { self.init(teamID: p.teamID, teamColor: p.teamColor.value, playerID: p.playerID, name: p.name) } public func encodeToCodableProxy() -> PlayerSpecifier.CodableProxy { return CodableProxy(teamID: teamID, teamColor: ColorProxyRGB(teamColor), playerID: playerID, name: name) } }

10:59 AM

↑こっちは1世代前のコードでわかりやすいと思う ColorProxyRGB　が Color型を Float3要素Array にコーディングするための型

PlayerMやPlayerSpecifierは、InfraかModelかでいうとどちら？

PlayerMは完全に通信プロトコル固有のやつだから、

11:01 AM

Infraになるのかな？(DDD詳しくない)

11:01 AM

PlayerSpecifierはInfraとModelどっちも共通（そのままで済んだ

11:01 AM

PlayerMとは別にモデルとしてのPlayerは別にある。

11:02 AM

(1つめと2つめのコードが最近のプロジェクトSで、３つめのコードは別のプロジェクトJ

なるほど Playerに新たなプロパティhogeを増やす場合、

Player.hoge
Playerのmemberwise initializer
PlayerM.hoge
PlayerM.CodableProxy.hoge
PlayerMのmemberwise initializer

に改修が入る？

その５つはそう、それに加えて、 PlayerMのinitFromCodableProxyとencodeToCodableProxyもだね。

11:05 AM

ただ、Player.hogeに改修を加えた時点で、他の６つは全部連鎖的にコンパイルエラーが出るので漏らすことは無い。

11:05 AM

DecodingContainerを触るコードを書く場合の致命的な問題点として、 Decode処理とEncode処理の対称性が静的に保証できないという事があると思ってて

11:06 AM

Decode側で追加したのと対になるロジックをEncode側にも書かないと、 EncodeしたときはJSON表現が違うとか、Encode側に追加をわすれて、保存すると消えちゃうみたいなバグが出る

11:07 AM

このスタイルだとJSONとのマッピングは常に自動生成に頼ってるのでそういう事故がないこれはボイラープレートの手書きを回避したからって事だと思ってる

Decode処理とEncode処理の対称性が静的に保証

そこの解決策としてのありがたさはよくわかった

11:12 AM

ただ、やっぱりそもそもの「ボイラープレート」で意図してるところが違ってるんだな

11:16 AM

ぼくがボイラープレートって言ったのは、プロパティ1つにつき上記7箇所の本質的ではないコードを自分で書かなきゃいけないってことプロパティが10個あったら70箇所それをボイラープレートと言ったそれはCodableに則って init(from:) や encode(to:) を書く場合には1つになるけど、それでもプロパティ10個あったら10行の非本質的なコードが発生するその中で、左辺で型が分かりきってるのに右辺にも型を書かなきゃいけないってのは、さらにげんなりする右辺から型を省略可能になれば、焼け石に水ではあるけど少しはマシになるんじゃないの？というのが今回言いたかったこと

CameraCalibration

の例だと数が同じにならない？

11:19 AM

CodableProxyでやりたかった事がPropertyWrapperで解決してるんだよね

11:20 AM

同じというか減ってる気がする

CameraCalibrationはPropertyWrapperがなくてもinit(from:) encode(to:) を書かずに済むので、それは話が発散する

いや、そこは発散じゃなくて同じ話だと思う

11:25 AM

ボイラープレートになるようなCodingContainerの操作は

11:25 AM

単純故に自動生成に寄せられるはずだから

11:25 AM

そもそもそういうケースは減らせるはずというのが僕の主張で

11:25 AM

CodableProxyはその実例だけど、ただ、別種のボイラープレートが増えちゃうから良し悪しが出ちゃうと

11:25 AM

でも PropertyWrapperによる解決だったら、ボイラープレート数が増えてはいないので

11:26 AM

もともとの主張のより強い根拠になってる。

11:30 AM

まあ、「自動生成に寄せられる」が否だったとして

11:30 AM

その中で、左辺で型が分かりきってるのに右辺にも型を書かなきゃいけないってのは、さらにげんなりする

これはわかる。

11:31 AM

「左辺の型がプロパティの型として決まってて、右辺がボイラープレートになる」これがまさに自動生成できる要件が整ってる事を言ってるような気もするけど・・・

11:31 AM

「ボイラープレートを手書きしないといけないなら推論が効いて楽な方が良い」はまあ正しいと思います

11:33 AM

もともとのそれをやる問題点のトピックに関しては、変なコードを書いた場合に混乱しうるという観点はあるが、提案してるシナリオだとそれは踏まないしね。

>PropertyWrapperによる解決だったら、ボイラープレート数が増えてはいないので JSONのプロパティとModelのプロパティが1:1に定まる、という条件ならおもちさんの話は通る JSONを単純に型付けしたDTOを作って、そこからModelに投射するというのも良い案だし、「CatV1, V2をCatDTOにしてからCatを作る」という例はむしろそのアプローチが最大に活きるパターン

11:37 AM

それでも、DTOを噛ませずContainerから直接作りたいと思うことはけっこう自分はあって、たぶんその状況が普段生まれるか生まれないかが視点の違いになってると思う

11:43 AM

要は、何層もネストしたDTOのコンバートってキツいよねってことなんだけど { a: { b: { c: { d: { e: { x: "", y: "", z: "", i: 1 }}}}}} { a: { b: { c: { d: { e: { x: "", y: "", z: "", b: true }}}}}} Eの中身の一部が、場合によって変化するとします EにDTOを噛ませる場合、連鎖的にD,C,B,AもDTOを噛ませなきゃいけない同じ構造の型を作るの辛いだったらEには init(from:) を書いて、全部素のDecodableにしたいそのとき、x,y,zが変わらないのはわかりきってるのに、そこでも右辺にも型指定しなきゃいけないのはめんどい (edited)

11:46 AM

こういったデコードが多く発生するプロジェクトだと、Containerの扱いの細かい部分が気になってくるわけです逆に、JSON色付け係ばっかでEncodableが出てくることはほぼなかったので、そこをCodableProxyで解決できるんだって言われても有難みがあんまり気にならない (edited)

あー

11:54 AM

構造の深堀りを型を使わずにcontainerでゴリゴリ書いちゃうって事？

11:56 AM

CodableProxyにせよ、PropertyWrapperにせよ、ABCDはそのままで、Eだけ改造することはできますよ。

11:56 AM

逆に、JSON色付け係ばっかでEncodableが出てくることはほぼなかった

Encodableが出てこない、なるほど・・・

11:59 AM

あいや、あれか、API用のデコードを別にしようとすると

11:59 AM

ABCDをデフォルトにできない？

あーそうか、 init(fromCodableProxy:) 呼んでるのは init(from:) の中か https://github.com/omochi/WeaselRoll/blob/master/Sources/WeaselRoll/Codable/CodableProxy.swift#L16

https://forums.swift.org/t/dynamically-dispatched-protocol-extension-members/32566

Contribute to omochi/WeaselRoll development by creating an account on GitHub.

そうそう。

たしかにこれで解決だ

ABCDがややこしいのはAPI固有のほうの話だから、そうだよね

終　制作・著作　━━━━━ 　　ⓃⒽⓀ

たしかにこれで解決だ

そこの誤解があったか

Decoderを使って得られるのがDTOで、そこからModelにマップしてやらなきゃいけないって前提で喋ってた

12:03 PM

Decoder使ったら直でModelが得られるならそれで全然いい

12:04 PM

だから HasDecodableProxy : Decodable なのか

4:25 PM

extension MyProto { dynamic func myMethod() { print("Protocol method") } } struct NoOverride: MyProto {} struct HasOverride: MyProto { func myMethod() { print("Struct method") } } func call_generic<T: MyProto>(_ object: T) { object.myMethod() } let defaultObject = NoOverride() defaultObject.myMethod() // "Protocol method" call_generic(defaultObject) // "Protocol method" let object = HasOverride() object.myMethod() // "Struct method" call_generic(object) // "Struct method" <-- This.

4:25 PM

protocol requirementsではない場合にでもprotocol extensionをdynamic funcにするとdynamic dispatchになるという仕様の提案

4:25 PM

実装できなくね？とオモタ

switch からループを break できると思って↓のようなコード書いてしまった・・・。 @swift-5.1.5 for i in 1...10 { switch i % 5 { case 0: print("end") break default: print("\(i)") } }

1 2 3 4 end 6 7 8 9 end

正しくは↓。 @swift-5.1.5 loop: for i in 1...10 { switch i % 5 { case 0: print("end") break loop default: print("\(i)") } }

1 2 3 4 end

普段 case に break 書かないから必要ないものと認識されてて外側のループに作用するように思ってた。

2:07 AM

空 case で break 必要だからしかたないのか

2:08 AM

あ、↑のコードは if でいいけど、実際のコードは exhaustive に switch で分岐したいケース。

「何もしない」が表現できればそれでも良い気はしますね

ですねー。なんかせっかく break から開放されたと思ってたらまだ C に引きずられてて気持ち悪い感じ。

2:14 AM

でも、昨日初めて（ではないかもしれないけど数年ぶりに？） fallthrough が必要なコードを書いたし、仕方ないのかな・・・。

breakはswitchに吸われるけどcontinueはforに吸われるので

5:39 AM

switchの後ろにbreakを書きつつ、not endのcaseでcontinueを書くと

5:40 AM

ラベル不要にw

げー、 break と continue でそこ揃ってないのか・・・。

そう。その特性うまく使うとおしゃれに書けることあるけど、ややこしい

揃えたとするとcontinueはfallthrough相当の動きをするべきなのかな

switch/for/continue/breakはC系で全部同じ動きするから

1:47 AM

fallthroughになるのはやばそう

1:48 AM

やるとすると書くのを禁止するしかないんじゃないか

switchが下に抜けないようにした時点でbreakはswitchじゃなくて外側に作用するようにしてたら良かったと思うな。今となってはしょうがないけど。

あ〜外側に揃えるのか。

それがベストな気はしますね、switchの中で挙動のコントロールはfallthroughだけになる

switchにbreak書く意味はないからbreakはswitchに作用しなくて外側にループがあったら抜ける。

確かにif文にもbreakは無いしswitchだけ途中で終われる事のほうが変な感じだ。 (edited)

switchがfallthroughしない他の言語はどうなってたかなと思ったけど、Goもラベル付きbreakですね。こういう場合は。

4:48 AM

他の言語はよく知らない。

その場合空caseに何か必要なのでは？

空case 別によくねって思う。

空ケースに書くのはセミコロンとか()でいいんじゃないですか

何も書かなくても特に曖昧性ないですよね？

空で書けてもいいと思います。

そうですね。下にfallthroughしそうな見た目だと思ったんですがswiftが明示的なfallthroughを要求することを知っていれば大丈夫か。

Swiftのその辺の文法はC系(Objective-Cもか)からの移行コストを減らす事にだいぶ寄せているなあ

Rustから借りてきて match みたいな文にして今のswitchをなくすか徐々に使われなくしていってもいいのかもしれない。

class ViewController: UIViewController { let processingQueue = DispatchQueue(label: "com.kishikawakatsumi.test") override func viewDidLoad() { super.viewDidLoad() processingQueue.async { [weak self] in self?.processingLoop() } } private func processingLoop() { while true { // Do something } } }

^ これでDispatch QueueがViewControllerの参照を持ち続けてしまうためにViewControllerが解放されないの、直す手段ありますか？

12:50 PM

while true のところを変数にして while isProcessing とか閉じるタイミングなどで外からそのフラグをfalseにする、くらいしか思いつかなかった。

ループが自身の参照持ってるんでこうなるのは正しそう

12:53 PM

とりあえず

12:53 PM

class ViewController: UIViewController { class Process { let processingQueue = DispatchQueue(label: "com.kishikawakatsumi.test") weak var parent: ViewController? init(parent: ViewController) { self.parent = parent } func run() { while let parent = parent { } } } lazy var process = Process(parent: self) override func viewDidLoad() { super.viewDidLoad() process.run() } }

12:54 PM

メモリリーク避けつつ開放されたら止まるようにもしてみました。

フラグなりなんなりで分岐してループ抜ける必要がありますね

たるのんさんのやつ、なんか違くない？これだと process.run() で無限ループに入って出てこなくなってしまう。

あwDispatchQueue使うの忘れてました

1:00 PM

よしなに補完してくだされ〜

1:00 PM

高階関数にすればクラス使わなくてすみそうな気がしてきた

class ViewController: UIViewController { class Process { let processingQueue = DispatchQueue(label: "com.kishikawakatsumi.test") weak var parent: ViewController? init(parent: ViewController) { self.parent = parent } func run() { while let parent = parent { } } } lazy var process = Process(parent: self) override func viewDidLoad() { super.viewDidLoad() process.processingQueue.async { [weak self] in self?.process.run() } } }

1:02 PM

こうですね！無限ループの条件がselfがあるかどうかだからいいのか。

runの中でasyncした方がちょっとだけ綺麗かな

1:02 PM

クラスいらないやつ書いてるので暫しお待ち

1:07 PM

class ViewController: UIViewController { let processingQueue = DispatchQueue(label: "com.kishikawakatsumi.test") override func viewDidLoad() { super.viewDidLoad() processingLoop { (self) in print(self) } } func processingLoop(_ f: @escaping (ViewController) -> ()) { processingQueue.async { [weak self] in while let strongSelf = self { f(strongSelf) } } } }

1:07 PM

できたできた

1:08 PM

while letで弱参照をループごとに引っぺがすことで、永続的なretainを持たないことがミソですね！ (edited)

なるほど？

うーんなるほど。これはすごいですね。

1:21 PM

while let ... じゃないと書けないんですよね？

while文でoptional bindingしてるだけで

1:22 PM

本質的には while true { guard let self = weakSelf else { break } } に同じです

1:23 PM

ループの中に弱参照持ち込むところだけできればどんな書き方でもオッケー

あ、ホントだ。いろいろ書き換えてて、while letじゃないと（＝たるのんさんのやつじゃないと）うまく言ってなかったんですけど、while true {とguardでもできました。

1:25 PM

完全に理解しました。どうもありがとうございます

1

extension DispatchQueue { func startBindingLoop<T: AnyObject>(_ object: T, _ f: @escaping (T) -> Void) { weak var object = object self.async { while true { guard let object = object else { break } f(object) } } } } class ViewController { let pq = DispatchQueue(label: "pq") func viewDidLoad() { pq.startBindingLoop(self) { (self) in print(self) } } }

1:32 PM

パターンの再利用可能版↑

良さそう。

class ViewController { class Task { var param: Int = 3 func run() { print(param) } } let pq = DispatchQueue(label: "pq") var task: Task? func viewDidLoad() { let task = Task() self.task = task pq.startBindingLoop(task) { $0.run() } } func viewWillDisappear() { task = nil // stop task } }

1:40 PM

↑こんな風に止めたりできて便利かもしれませんね

1:43 PM

ただまあ、元のコードにしても、 ViewControllerがnilになった後も、「BG処理の次のループが開始しない」だけであって、 nilになった瞬間に開始していた周回の処理が割り込まれて止まるわけではないので、「ViewControllerはnilだけどBG処理が実行されている」時間帯が発生しうるので、その状況でエンバグしない考慮は必要ですね。

1:44 PM

「BG処理の実行中はVCがdeinitされていない」事は保証されてるけど。

OptionalBindingしたらループ抜けるまで最低でもretainCount=1にならないんでしたっけ？

最低1はあるからdeinitはしない。

1:47 PM

ただ、もともと想定してたほうのVCを持ってる最後の変数がnilになっても、そっちのループ側が残るからVCが解放(deinit)はされてないけど、UIKit上は完全に消えてる時間帯が生じる (edited)

それはそうだね

実際にはこれはループの中ではマイクからの音を処理していて、波形を描くための情報をループごとにモデルにPublishする、というものです。 Viewが閉じたあとにコールバックが呼ばれても無視するようにしておかないといけないってことですね。

そうですね。コールバックが呼ばれている「最中」でさえ、Viewが閉じる可能性がありますね。モデルにPublishするところとか、モデルからUIに流し込まれるところで、なんかチェックしておけば大丈夫そう

安全な設定APIみたいなのを型システムでつくりたい的な話題はどのチャンネルでしょうか...? ここかな?

ここだと思います

enum Valid {} enum Invalid {} struct Configurable { let configuration: Configuration<Valid, Valid> } struct Configuration<FlagA, FlagB> { private var a: Int? func setFlagA(a: Int) -> Configuration<Valid, FlagB> { return Configuration<Valid, FlagB>(a: a, b: b) } private var b: String? func setFlagB(b: String) -> Configuration<FlagA, Valid> { return Configuration<FlagA, Valid>(a: a, b: b) } } func noConfiguration() -> Configuration<Invalid, Invalid> { return Configuration() } let configuration = noConfiguration() .setFlagA(a: 1) .setFlagB(b: "b") Configurable(configuration: configuration)

12:34 AM

一応あるていど期待通りなんですが、なんかイマイチ感があって。

12:35 AM

似たような感じの知られてる実装があったら知りたいと思いました。

僕が知ってるのもそんな感じですねえ。

各プロパティが Optional である必要はなさそうに思います。

未設定の状態が維持できなくないですか？型を変えようとすると、設定手順の組み合わせ爆発しちゃうし

Optionalなのは隠せるので、まあ...

2:12 AM

なんというか Scala でいうところの Nothing がないので、若干冗長なことが多いです。何かを入れなきゃいけないので。

Never が似たような役割を果たす場面もありますよ

Valid か Invalid で未設定の管理しているわけで、初期値が0とか""みたいにtrivialに入れられるのであれば、いらなくないです？

初期値なるほど

そうかも。

2:17 AM

プロミティブなやつらだけならそうですね。

Invalid の代わりに Never でもいいですね。

Scala でいうところの Nothing がないので、若干冗長なことが多いです。

これって、たとえば Never 使っても enum Invalid {} の一行がいらないだけでに思えるんですけど、 Scala だとどういう冗長さをなくせるんですか？

nitpickですが Configuration<Int, Int>() とか作れちゃいますね。

Scalaだと、Generics のデフォルトがNothingなので

1

3:29 AM

書かなきゃNothingになるんです

1

なるほど。

protocol Condition {} enum Valid: Condition {} enum Invalid: Condition {} にして FlagA: Condition... とかにすれば Int とか作られなくなりますけどまあ、作りたかったら作っても良いのでは的な気持ちも

3:32 AM

noConfigutation() とかいらなくて Configuration() みたいにかける感じです > Nothing (edited)

extension Int: Condition で回避されそうですね・・・。

lol

3:34 AM

protocol は隠せないからなあ...

@koher さすがにそこまでは面倒見きれないですねぇ

sealed が要りますね。

sealed trait みたいなのがないから enum で回避したことを思い出した

あー、 public class Condition にして、サブクラスをモジュールに閉じ込めれば（ open でないと外部から継承できないので）できるかも・・・。

3:38 AM

noConfiguration については、↑の話を聞くまでは、 Configuration<Int, Int> とかを防止するために、 Configuration のイニシャライザは本来 fileprivate にして外部から隠蔽して、 noConfiguration と setFlag 経由でしかインスタンス生成できないようにするためのものかと思ってました。

なるほど。あんまり隠すことは丁寧に考えてなかった...

Configuration<Int, Int> は問題ないけど、 Configuration<Valid, Valid> を勝手に作られたら、型で守っても壊されそうです・・・。

そんなの作らないで >_<

1

5:14 AM

いやでもクリティカルな指摘だと思います。正しく隠蔽する必要性は高いですよね。

目的の種類が違うんで状況次第だと思います

5:24 AM

正しく隠蔽するのはわからない人もそれを使う場合には大事だけどわかってる本人にとってヒューマンエラーを減らすための仕組みにも価値があって、その範囲だと隠蔽はいらない

個人的なきもちとしては設定APIのパターンとして蓄えておきたいので、ある程度の考慮はしておきたいなと思ってました。

なるほど

Configuration のイニシャライザは本来 fileprivate にして外部から隠蔽して、 noConfiguration と setFlag 経由でしかインスタンス生成できないようにする

これをやっておけば

Configuration<Valid, Valid> を勝手に作られたら

↑Valid, Validのインスタンスは勝手に作れない気がする

Builder にしておいたほうが、使用側の利便性はよさそうと思いました

enum Valid {} enum Invalid {} struct Configurable { let configuration: Configuration } struct Configuration { fileprivate init(a: Int, b: String) { self.a = a self.b = b } let a: Int let b: String } struct ConfigurationBuilder<FlagA, FlagB> { private var a: Int = 0 func setFlagA(a: Int) -> ConfigurationBuilder<Valid, FlagB> { return ConfigurationBuilder<Valid, FlagB>(a: a, b: b) } private var b: String = "" func setFlagB(b: String) -> ConfigurationBuilder<FlagA, Valid> { return ConfigurationBuilder<FlagA, Valid>(a: a, b: b) } private init(a: Int, b: String) { self.a = a self.b = b } } extension ConfigurationBuilder where FlagA == Invalid, FlagB == Invalid { init() {} } extension ConfigurationBuilder where FlagA == Valid, FlagB == Valid { func build() -> Configuration { return Configuration(a: a, b: b) } } let configuration = ConfigurationBuilder() .setFlagA(a: 1) .setFlagB(b: "b") .build() _ = Configurable(configuration: configuration)

(edited)

1

Builderだとデフォルト値が取れないような型があっても、Builder内部にだけOptionalで持たせて、Productの型はnon-optionalにできて良いですね (edited)

昨晩はお布団に吸い込まれてしまったが、extension の where つかうと implicit をつかった evidence みたいなのができる確かに、と思った。これだとかなり Scala のパターンに近いレベルになってる。素敵。

https://forums.swift.org/t/on-the-road-to-swift-6/32862

On the road to Swift 6

The Swift project has achieved a critical milestone of maturity of the core fundamentals, providing stability for users to invest in using Swift in earnest. On Apple's platforms such as macOS and iOS, the arrival of ABI and module stability has enabled the creation of stable...

11:44 PM

Swift6の方向性がアナウンスされた！

11:49 PM

concurrency, ownership、あとcompnerdさんがコアチーム入りだって

11:50 PM

windows版公式サポートに進むかな？

variadic genericsも書いてあるし期待

1:34 AM

tkremenek I suspect that Swift 6 will not push generics features "to their limits", but I do suspect that some work in this area will be prioritized especially where there is a compelling need that will empower users to write better APIs. For example, I mentioned variadic generics in my post.

1:35 AM

このbetter APIのためのvariadic generisってSwiftUIのTupleView<...>　の事意識してると思う

https://twitter.com/objcio/status/1219998374352629760?s=21 型推論は難しいな。間違えたわ。

objc.io (@objcio)

// Swift Quiz // by @tammofreese func foo() throws -> Int { 0 } func foo() throws -> Int? { 1 } let a = (try? foo()) let b = (try? foo())! let result = (a == b) // What’s the value of result? (Swift 5)

やってみた、あってた。

さすが。これtry?がついてるのが難しいですよね。

あれ？勘違いしてたな　なんで正解したんだ

2:10 PM

結果的にresultの値と呼び出されるfooは思ったとおりだけど、全然わかってなかった

2:12 PM

func goo() throws -> Int? { 1 } let a = try? goo() print(type(of: a)) // Optional<Int>

2:13 PM

↑そもそもこれが Optional<Optional<Int>> になると思ってた・・・

compnerdさんがコアチーム入りだって windows版公式サポートに進むかな？

すごい。色んなプラットフォームへの展開が Swift 6 の目標に掲げられてて Windows ポート主導してますって紹介されてる compnerd さんがコアチーム入りって、 Swift 6 での Windows サポートあるんじゃないの？

2:13 PM

@omochimetaru try? の flatten って前に proposal なかったっけ？

話題２つあるから部屋わけますね

2:15 PM

try? のflatten確かに記憶あるの思い出してきた (edited)

https://github.com/apple/swift-evolution/blob/master/proposals/0230-flatten-optional-try.md

https://twitter.com/kateinoigakukun/status/1220586386778021888

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

その上でflattenされる方が優先なのか・・・

Swift5って書いてあるから5.0botで試したら怒られたｗ

5:09 AM

returnなしは5.1から

そうですねｗ

return付けて4.2で　print(type(of: a), type(of: b), result)　を出力してみたら 5.xと同じで悩んでる

aとbの値も同じ？

sil見たら型推論が変わってる 4.2は () throws -> Int を使ってる

お、ですよね

5:18 AM

だから、SE-0230でtry?の仕様が変わりつつも

5:19 AM

いや、だめか、挙動が変わった。

5:19 AM

flattenするからtry?後の式の型は変わってないけど。

kateinoigakukun (@kateinoigakukun)

Swift6でVariadic Generic Parameterをどうやって実装するのか気になって勉強が手につかない

6:59 AM

ツイッターで会話してたんですが、仕様や実装の上で悩ましい点が結構ありますね

7:03 AM

https://forums.swift.org/t/variadic-generics/20320

7:03 AM

https://github.com/technicated/swift-evolution/blob/variadic-generics/proposals/XXXX-variadic-generics.md

technicated/swift-evolution

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

7:04 AM

このスレッドのAndrea Tomarelliさんのproposal draftでなんとなくできてるけど

タプルにしか展開できないように見えますね

// ============================================================================= // With the following hack, the result type of the second `curry` function might // become expressible. // ============================================================================= enum CurryHelper<variadic T, Result> { #ifempty T typealias Fn = Result #else typealias Fn = (#head(T)) -> CurryHelper<#tail(T), Result: Result>.Fn #endif } // CurryHelper<A, B, C, R>.Fn // CurryHelper<A, B, C, R>.Fn = (A) -> CurryHelper<B, C, Result: R>.Fn // -> (B) -> CurryHelper<C, Result: R>.Fn // -> (C) -> CurryHelper<Result: R>.Fn // -> R // CurryHelper<A, B, C, R>.Fn = (A) -> (B) -> (C) -> R func curry<A, B, C, variadic D, Result>( _ fn: @escaping (A, B, C, D...) -> Result ) -> CurryHelper<A, B, C, D..., Result>.Fn { return { a in curry { otherValues in fn(a, otherValues...) } } }

でもこれをまともに運用するためにはタプルがnominalにならないといけないんじゃ

7:05 AM

お、、、パラメータ側もやるのか

↑の#ifempty + typealias はまあ確かに書けてる

7:06 AM

タプルがnominal

↑nominalかどうかは関係ない気がする

いや、展開されたタプルを利用する側が

7:06 AM

まともに書けないんじゃぁ意味がない

7:07 AM

それをまともに使えるための構文なり言語機能なりが必要

func getFirstMember<variadic T>(_ values: T) -> #head(T) { return #head(values) }

7:08 AM

#head と #tail とかは、variadic T自体に型操作としても使えるし、variadic T型の式自体に値操作(と同時に型操作)としても使える必要があると思う。

7:10 AM

#head と #tail と #ifempty があれば、再帰的に操作できそう

ふむ

7:10 AM

テンプレートみを感じる雰囲気がありますね

C++はこういうのいろいろできますね

7:11 AM

たださっきの #ifempty を enum　の内側で展開するのはなんかいろいろルール違反を感じるので

7:12 AM

分岐が必要ですよね　型レベルの

7:15 AM

enum CurryHelper<variadic T, Result> {} extension CurryHelper where #empty(T) { typealias Fn = Result } extension CurryHelper where #notEmpty(T) { typealias Fn = (#head(T)) -> CurryHelper<#tail(T), Result: Result>.Fn }

7:15 AM

↑こうだったらもうちょっと今のSwift風で許せそう

Swiftらしいけどifとnotが別のdeclにあるのがちょっと気持ち悪いですね

VD入れた瞬間にコンパイル時計算のドアが開いてしまいそうだなあ (edited)

7:18 AM

ifとnotが別のdeclにある

そうだね〜〜

7:20 AM

enum CurryHelper<vairadic T, Result> { typealias Fn = #condtype(#empty(T), Result, (#head(T)) -> CurryHelper<#tail(T), Result>.Fn) }

7:21 AM

↑こんなのはどうか

そうするともうenumでネームスペース切らずに typealias CurryFn<variadic T, Result> = #condtype(#empty(T), Result, (#head(T)) -> CurryFn<#tail(T), Result>) でいい気がしてきました

おお。

TSっぽくなってきた

それスレに書いてきていい？

‍♀️

7:27 AM

1年くらい前からスレ立ってるんですね、追ってみよう

なんか最初の方は問題を理解してない雰囲気があって

7:27 AM

読めなかった。。

https://forums.swift.org/t/variadic-generics/20320/98?u=omochimetaru

7:51 AM

英語むずい

But rule of evaluating #ifempty happens when application of generic parameters is not consistent with existing evaluation of #if.

たしかに〜 #ifemptyは #ifの挙動と紛らわしいですね (edited)

うむ〜

可変長引数は (s: S, t: T...) なのに、可変長型パラは <S, T...> じゃなく <S, variadic T> なのはなんでだろう？シンタックス上問題なさそうだけど。

スレッドの途中で出てきてるからその辺に会話がありそう

Douglas_Gregor struct Variadic<Types...> { init(_ values: Types...) { } } (edited)

5:23 AM

可変長引数(同じ型の配列）と曖昧になるからか。

うーん、まあ納得かな。 foo: bar の形式が、 bar の位置に型が来る（宣言時）のと値が来る（呼び出し時）のがあるとか、類似表記で意味が違うとかはあるから許容範囲な気もするけど。まあ、宣言と呼び出しだと、宣言は型なので UpperCamelCase 、呼び出しは値なので lowerCamelCase で一応見分けられるとかはある。 (edited)

ん、見分けられなくないですか？

2:39 PM

struct Hoge<T> { func foo(_ values: T...) { } } struct Fuga<T...>{ func foo(_ values: T...) { } } Hoge<Int>().foo(a, b, c, ...) // a, b, c...は全部Intでなければならない、数は自由 Fuga<Int, String, Float>().foo(a, b, c) // a, b, cはInt, STring, Floatでなければならない、数は3つ固定

2:40 PM

HogeとFugaのパラメータ宣言部分まで見ればわかるけど、同じ記述のfooの宣言だけ見た時の解釈が全くことなる２つの可能性がある (edited)

variadic を ... に置き換えると考えるとして、利用する側には ... はいらないんじゃない？ struct Hoge<Ts...> { func foo(_ values: Ts) { } }

2:49 PM

ってか、 variadic ってここに付くの？？ struct ZipSequence<S1: Sequence, S2: Sequence, Ss: variadic Sequence> { }

あれ、それは変そう

2:49 PM

型パラメータ名の左ですよね

制約がない場合は↓なのかな？ struct Hoge<Ts: variadic Any> { }

2:50 PM

Proposed Solution にそう書いてあるよ。

2:50 PM

てっきり型パラの左だと思ってた。

2:50 PM

struct ZipSequence<S1: Sequence, S2: Sequence, Ss: variadic Sequence> { private let s1: S1 private let s2: S2 private let ss: Ss // used as a type here, in a property declaration... // ... and here in a function signature init(_ s1: S1, _ s2: S2, _ ss: Ss) { (self.s1, self.s2, self.ss) = (s1, s2, ss) } }

2:51 PM

↑を見る限り、 variadic の利用側には variadic は付かないから、 variadic が ... でも利用側の ... は variadic の意味にならない（可変長引数の意味しか持たない）と思った。 (edited)

2:52 PM

ただ、併用も意味不明な気がするのでコンパイルエラーかな？

func variadicGenericFunction<variadic T>(ts: T) { } https://github.com/technicated/swift-evolution/blob/203f8baec8201ac4237106aef9d9d97cfd499044/proposals/XXXX-variadic-generics.md

technicated/swift-evolution

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

2:53 PM

1月のどっかのリビジョンで変わってる気がする（これは12月

2:53 PM

func overloaded<variadic T: P1>(ts: T) { } func overloaded<variadic T: P1>(ts: (T...)) { }

どういう経緯で変わったんだろう？

スレッドの途中で変わったんじゃないですかね？

2:54 PM

まあたしかに、新しいやつだと、プロトコルの前についてますね

: の右な理由がぱっと思いつかない

なんか

2:54 PM

静的なパラメータ展開じゃなくて

2:54 PM

ランタイム表現の方に気持ちを寄せると

func collectionOfValues<T: variadic Any>(_ values: T) -> T { return values }

右につくきもちがしてきた

おや、本当に : variadic Any なのか。

Tっていう文字がたくさん増えるんじゃなくって

なるほど

Tが、複数型パラメータを意味するパラメータの名前なんだという解釈

2:55 PM

実際ランタイム表現の事は気になっていて

2:56 PM

Swiftの場合はABIPublicじゃなくてもGenericAPIが使える方針だから

うん、 T が variadic なんじゃなくて、 T は variadic Any を表すんだってことね。

コンパイル済みの実体は一つで０〜N個の引数を受け取れる必要がある（ただし一個ずつ型が違う (edited)

これも特殊化されたら K 個に展開された版が生成されるのかな？

ABIPublicだった場合や事前に指定した場合は0個、1個、2個...の場合は実際に関数が生成されていてほしいですよね。

2:58 PM

その場合は可変長な表現じゃなくて実際にその個数の引数と固定数の型パラメータを持つ。

なんかこれすごくマクロっぽくない？

てかそうじゃないと、SwiftUIのbuildBlockとかがパフォーマンスリグレッションしちゃうし。

2:58 PM

はい。

2:59 PM

てか、ジェネリクスはだいたい全部、マクロっぽい。

Chris Lattner が前に、まだマクロは早いって言ってたけど、将来マクロを導入するのであれば、それも考えて検討した方が良いような気も。

うーん？マクロってことは

3:00 PM

どういう記法になりますか？

いや、具体的には考えてないけど、

可変長ジェネリクスは可変長ジェネリクス用の記法として用意したほうが良いと思います。

struct ZipSequence<S1: Sequence, S2: Sequence, Ss: variadic Sequence> { private let s1: S1 private let s2: S2 private let ss: Ss // used as a type here, in a property declaration... // ... and here in a function signature init(_ s1: S1, _ s2: S2, _ ss: Ss) { (self.s1, self.s2, self.ss) = (s1, s2, ss) } }

それに制限としてABIPublic限定を強制して、ユーザー側でコード生成させるっていう方針は一つありえると思う。 (edited)

↑の Ss とそれを使っている箇所が展開されるのって、これまでの構文と比べて異質すぎて

3:02 PM

たとえば gyb だとそういうことできるけど、それってメタレベルが一個上がってるというか。

3:03 PM

enum CurryHelper<variadic T, Result> { #ifempty T typealias Fn = Result #else typealias Fn = (#head(T)) -> CurryHelper<#tail(T), Result: Result>.Fn #endif }

「今まではテキストとしてソースコードを自動生成しないとできなかった事が新たなジェネリクスでできるようになる」事は普通の事ではあると思う

このあたりとか。

#ifempty　や僕の代案の #condtype はメタレベルというか

3:04 PM

型の表現としてパラメータ展開時に再評価される抽象的な式を導入するので

3:04 PM

まあレベルはあがりますね

3:04 PM

でもそれ故にマクロってのは飛躍があるかなと思います。

3:04 PM

マクロまでいっちゃうと自由度が無制限に吹っ飛んじゃうから。

この # による制御が必要になるのは、普通のジェネリクスの導入によってそれまでできないことができるようになったけどこれまでの構文の範囲で吸収できたのとは、ちょっとレベル感が違うと思うんよね。

そうですね

3:05 PM

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html

3:05 PM

参考までに、typescriptは既にそういう概念を持ってます

無制限なマクロじゃなくても、ひとつ上のメタレベルについて、他にやりたいことも考えて整合性を考えなくて良いのかな？という疑問。考えられてるのかもしれないけど。

他にやりたいことも考えて整合性を考えなくて良いのかな

なるほど。

Variadic Generics だけを見て構文考えてて大丈夫かなと。

Variadic Genericと同じぐらい複雑なレベルの機能とか、更にそれを超える機能まで想定して

3:06 PM

一貫性が壊れないようなものを設計してほしいですね。

async/await と throws/try をメタに考えてなかったら整合性のとれない構文を導入することになってしまったのと同じような過ち（ C# とか Kotlin とか）を犯してしまうような。

それでいうと

3:07 PM

variadic genericsは、generic manifesto に昔から書かれてる一つのアイデアでしかないので

3:07 PM

generic manifesto全体を考慮できていれば良さそう

3:08 PM

あとこの間のUI of generics

しかも # はすでに色々使われてるし、本当にそこのレベルと同じレベルのものなのかな？

確かに # のニュアンスは怪しいですね。

3:08 PM

コンパイルタイム時評価って気持ちが # には入ってるように思うけど

3:09 PM

variadic genericsのコンパイル済み関数が実行時に０〜Nで対応できるものなのであれば

3:09 PM

別にコンパイルタイム時じゃないんだよな。

3:09 PM

#first とか #tail とか。でも #condtype はコンパイル時な気がする。

もう少し汎用的なメタ制御構文みたいなので扱わなくて大丈夫かなぁ・・・

いや、 #condtype も頑張れば実行時に動的にもなるはずか・・・？

あれ？ CurryHelper は variadic T のままだｗ

CurryHelperはなくなってますよ

3:13 PM

Andreaさんが昨日proposalを更新していて

3:14 PM

そこでcurryの対応をオミットしたんだって

3:14 PM

スレで言ってます。

3:14 PM

多分Andreaさんの実装では、variadic genericsを、

あ、リロードしたら消えたｗ

実行時に、型と値のペアの配列として表現するような仕組みを考えているんじゃないかな

3:14 PM

で、curryだけは

3:15 PM

curry自体の返り値の型が

3:15 PM

その配列的なもので表現できないんですよね

3:15 PM

階数の異なる関数型として返ってくるから。

3:15 PM

そういう意味だと @koher がまさに言っているように

3:16 PM

Andreaさんのアプローチだと、過剰な制約をいれた実装になっちゃってて

3:16 PM

将来的にcurryも対応しようとしたら全然違う実装が更に必要になっちゃうかも？

#ifempty 消えてるけど、これとかこれまでの #if との整合性がヤバくないのかな？

僕はヤバいと思うので #condtype　を提案しました。

#ifempty T ... #elseif FOO ... #else ... #endif

3:22 PM

とか崩壊するよね。

#ifempty　だと

3:23 PM

typealiasだけじゃなくてfuncとかも挟めるから

3:23 PM

意味不明な事になりそう。

#ifempty は実行時に処理されうるんじゃないの？

3:24 PM

typealias だからそんなことはないのか？

あーコンパイル済みでも動かすならその必要がありますね。

よくわからないんだけど、あるモジュールがさっきの CurryHelper みたいな #ifempty を使った public な API を公開していて

3:25 PM

それで動かすには実行時に処理する必要があるけど、

3:25 PM

その実行時の部分に typealias が書かれてるってどうなるの？？

前提の確認ですけど

3:25 PM

さっきまでマクロって言っていたけど

3:26 PM

マクロではできない ABI non public でも動くことを前提の話ですか？ (edited)

あー、 ABI public になる前提なのか。

いいえ、そこは、僕はproposalからは確認できてないです

3:28 PM

ABI Public 前提で、利用側でのコード生成を前提なら、いろいろ簡単になると思います。 C++のテンプレートと同じように、C++が既にできてるそれらが同じようにできる。

3:28 PM

スレッドも90レスあって、そのあたりの議論はどうなったか調べられてない。

今の @inlineable とかって、 #if とかも保持するようになってるの？

どうだっけ、実験してみよう

3:29 PM

実装に入ってるケースですか？

うん。

3:30 PM

もし今 ABI-public が #if とかを維持しない仕組みだったら、

3:31 PM

#ifempty とか、たとえ ABI-public 前提でも新しい仕組み導入しないといけないよね？

[omochi@omochi-iMacPro sif]$ cat c1.swift @inlinable public func foo() -> Int { #if os(macOS) return 1 #else return 2 #endif } [omochi@omochi-iMacPro sif]$ swiftc -emit-module-interface -enable-library-evolution c1.swift && cat c1.swiftinterface // swift-interface-format-version: 1.0 // swift-compiler-version: Apple Swift version 5.1.3 (swiftlang-1100.0.282.1 clang-1100.0.33.15) // swift-module-flags: -target x86_64-apple-darwin19.2.0 -enable-objc-interop -enable-library-evolution -module-name c1 import Swift @inlinable public func foo() -> Swift.Int { return 1 }

3:32 PM

消えてますね。

3:32 PM

あ〜そうか〜・・・

3:32 PM

だから swiftinterfaceってたくさん生成されるのか。

3:33 PM

一つのライブラリから、 x86.swiftinterface arm64.swiftinferface とかがいっぺんに複数生成されるんですよね。

3:33 PM

ビルド時の変数を全部事前展開するのか。

なるほど。

3:33 PM

でも #ifempty は展開できない・・・

3:34 PM

さらに、 #ifempty T ... #elseif FOO ... #else ... #endif だと、 FOO が os(...) だったときに、それも保持する必要がありそう。

てか　#ifempty 自体proposalから消えちゃってますね

うん、消えてる。

3:35 PM

実装してて無理ってなったのかな？

3:36 PM

え、てか # 全部消えてる？

3:37 PM

# でページ内検索しても何も出てこない・・・

はい。

3:40 PM

struct|class|enum SimpleVariadic<T: variadic P1> { } extension SimpleVariadic { var someTs: T { /* ... */ } func testCollection() -> (T...) { // All your `map`, `filter`, etc are here! let arr1: [String] = someTs.map { "\($0)" } let arr2: [P1] = someTs.filter { $0 is Int } let first: P1? = someTs.first return (someTs...) } }

3:40 PM

こんな感じになってますね。

3:41 PM

#ifempty じゃなくて　(variadic型).first みたいな。

よくわからないんだけど、 T は Collection や Sequence じゃないけど、この map とかは何なの？？

variadic type に対する APIのようですね

// Variadic values are somewhat "special", because both inside and outside of a // generic context act like a Collection - or better are a Collection. The // Element of this collection is the constraint of the Variadic Generic. In- // side a generic context, the ... syntax allows users to convert this collec- // tion to a tuple whose shape and types will be the concrete types passed to // the Variadic Generic parameter.

3:44 PM

だから、 var someTs: T は一見、T型のプロパティに見えるけど

3:44 PM

SimpleVariadic<T: variadic P1> だから

えー、無理じゃないかな？

someTs: T は、 variadic P1 型としての、型を持つ

3:45 PM

から、map とか first とかでコレクション操作ができる。

いや、いいのかな？制約があれば

3:46 PM

↓は可能か。

extension SimpleVariadic { var someTs: T { /* ... */ } func testCollection() -> (T...) { let arr = someTs.map { $0.methodOfP1() } return (arr...) } }

methodOfP1() の返り値が Self ならいけるのかな・・・？ testCollectionの返り値 (T...) が怪しい木が

そこ怪しすぎるよね

3:48 PM

extension SimpleVariadic { var someTs: T { /* ... */ } func testCollection() -> (T...) { let arr = someTs.filter { _ in Bool.random() } return (arr...) } }

3:48 PM

型不定

うーんこれおかしいなあ

コンパイラ実装できない気がする。

あ、いや、一応・・・サンプルコードは

3:50 PM

 func testCollection() -> (T...) { // All your `map`, `filter`, etc are here! let arr1: [String] = someTs.map { "\($0)" } let arr2: [P1] = someTs.filter { $0 is Int } let first: P1? = someTs.first return (someTs...) }

3:50 PM

returnしてるのはsomeTs... だから

3:50 PM

tomeTs... が (T...) なのは、まあそうかも。

3:50 PM

var someTs: T において (someTs...) の型が (T...) だというのは

3:51 PM

よくわからないけど。

え？でも T しか展開できなくて、 map の戻り値が T にならなかったら何もできなくない？？

T って一つで書いてもコレクション的なもので (T...) って書いたらタプル展開？

うん。そうだという認識。

はい、arr1 , arr2, first は意味ないですねこの例だと returnしてないんで

3:52 PM

このproposalは詳細が詰めきれてないような気がする

関数の中ではコレクションに見えて、外から見ると型の列に見えるような存在ってことなんだと思うんだけど、

3:52 PM

func testCollection() -> (T...) { let arr = someTs.map { $0.methodOfP1() } return (arr...) }

3:52 PM

↑のようなことがしたいんじゃないかと思ってる。

こんなふうに書けたらいいよね、ぐらいのになってて、厳密な一つ一つのルールがわからん

3:53 PM

その場合は methodOfP1 の返り値が -> Self だったら

3:53 PM

arr の型も T になって、

3:53 PM

辻褄は合いそう。

あ、ちがうか、 map じゃなくて modifyEach か、 (T) -> T に縛られた map じゃないといけないのか。

そうです

3:54 PM

let brr = someTs.filter { $0 is Int } ↑これとか、brr　の型は [Int] しか無さそうだけど

それくらいしか使えないよね。 filter はしたら型不定でダメな気が。 map は Array になるなら OK だね。

そんな高階関数filterの型チェック特別に実装するのは現実的じゃ無さそうだ

あーでも someTs.map { $0 } の扱いが面倒そうだな。

3:56 PM

[P1] でいいのかな？

3:56 PM

reduce とかは、普通に使えると思うんよね。

3:57 PM

func some<Ts: variadic IntConvertible>(_ values: Ts) -> Int { values.reduce(0) { $0 + $1.asInt() } }

3:57 PM

filter はダメだね。

3:59 PM

for はありなのかな？

func some<Ts: variadic IntConvertible>(_ values: Ts) -> Int { var some: Int = 0 for value in values { some += value.asInt() } return some }

forはその中で出来ることが自由すぎて

4:00 PM

コンパイル時計算みたいな話になっちゃいますね

4:00 PM

要するに、 [Any] 型の値 array がある時点で実際の値が [Int, String, Float] だったとわかっているときに (edited)

4:01 PM

いろんな操作した結果の型がどうなってるか調べられるようにする、みたいな話に感じる

map とか reduce もじゃないの？クロージャに何でも書けるよ。 < 自由すぎ

あ〜　そうか、だめそうだなあ

for だとしても、 Ts の制約で表される型以外のことはできないし、結果として Ts を得ないならいけるんじゃないかな？

4:03 PM

どっちにしろ、特殊化はできなさそう。

var i = 0 someTs.map { i+=1 return i%2 == 0 ? Int(1) : String("") }

4:03 PM

↑こんなこととかもできちゃいますね。

map の結果が [Any] ならいいんじゃないの？

4:04 PM

map で Ts を得ることは諦めてる。

4:04 PM

Ts のままで有用な操作をするなら modyfyEach 的なものがいるね。

それならまあ良さそうですが

4:04 PM

例えば

4:04 PM

self.someTs = someTs.map { $0 + 1 } これとかも通らないか。まあいいか。 (edited)

あと、 for inout t in someTs

4:05 PM

うん。究極的には someTs.map { $0 } で、これの戻り値の型を Ts じゃなく [P1] にするならいい。 (edited)

4:07 PM

modifyEach と for inout があれば Ts のまま操作できるし、その場合は要素を P1 として扱えるから色々できるし、あとは集約して別の型に変換するくらいしかできることなさそう。

4:09 PM

んー、ここには ... 展開出てこないの？？

struct ZipSequence<S1: Sequence, S2: Sequence, Ss: variadic Sequence> { private let s1: S1 private let s2: S2 private let ss: Ss // used as a type here, in a property declaration... // ... and here in a function signature init(_ s1: S1, _ s2: S2, _ ss: Ss) { (self.s1, self.s2, self.ss) = (s1, s2, ss) } }

4:09 PM

頭からちゃんと読んでないからかもしれないけど、どういう構文なのかよくわからない・・・。正式な Proposal になってから読もう・・・。

4:10 PM

あ、ちがうか

4:10 PM

これは代入してるだけだからいいのか

左はパターンだからいいですけど

4:10 PM

右はタプルだから

func zip<S1: Sequence, S2: Sequence, Ss: variadic Sequence>( _ s1: S1, _ s2: S2, _ ss: Ss ) -> ZipSequence<S1, S2, Ss> { return ZipSequence(s1, s2, ss) }

(S1, S2, Ss) みたいな型になってますね

4:11 PM

Ssの中身は展開されてないあくまで3要素のタプル

4:11 PM

さっきまでの...だとSsが展開されてタプルの要素数がSsのvariadic数に応じる

これもまあいいのか。

あれ？いいのか？

4:11 PM

ZipSequence(1, 2, 3, 4, 5)

4:11 PM

ってかいたときとズレてるような。

4:12 PM

タプルの規則と合わせるなら ZipSequence(s1, s2, ...ss) になりそう？

extension ZipSequence.Iterator: IteratorProtocol { // The result of `next` is a tuple containing an `Element` of `S1`, an // `Element` of `S2` and an element of each member of `Ss` func next() -> (S1.Element, S2.Element, Ss.Element...)? { if reachedEnd { return nil } // We are going to talk about `project` later, in the *detailed design* // section // Moreover, please note that a variadic value of optional elements can be // directly used in pattern matching expressions guard let e1 = baseStream1.next(), let e2 = baseStream2.next(), let es = otherStreams.project({ $0.next() }) else { reachedEnd = true return nil } return (e1, e2, es...) } }

4:12 PM

ここで展開してるからいいのかな。

ZipSequence.init だけを見た時の整合性が変な気がする。

この project が (T) -> T の map なのかな？

// the function is defined something like this mutating func project<T>(_ transform: (inout Self.Element) throws -> T) rethrows -> <variadic value of T's> { return try indices.map { index in try transform(&self[index]) } }

(edited)

<variadic value of T's> が構文なのか、構文未定なのかどっちなんだろ？

4:15 PM

やっぱ正式な Proposal になってから読まないとあんま意味なさそうな気がしてきた・・・

僕もコアチームはこれはあんまり気にせず進める気がします

4:16 PM

ただコミュニティがいろんな意見を言ってそれが集まってるのは良くって　Example1,2,3,4,5は

4:17 PM

やりたい事集として良いと思う

それにこれを見たおかげで Variadic Generics でどんなことを考慮しないといけないのか少し頭の中を整理できた気がする。

たしかに。

そうかー。 zip をするためには型の map が必要なのか。

4:23 PM

SS: variadic Sequence から、 next の中で (SS.Element...)> に変換しないといけないのか。

4:24 PM

さっきの (T) -> T 変換と for inout じゃできないな。

どういう意味ですか？

4:26 PM

projectが T -> T 変換だからさっきのproposalのコードみたいに project　で書ける（？）のでは？

Iterator から Element を取り出すから (T) -> T じゃなかった。

ああ、 SS から SS.Element への変換か。

associatedtype とかメタタイプとかへの型の map みたいなのが必要そう。

そゆことか otherStreams.project({ $0.next() }) ↑じゃあこれは

4:29 PM

かなり高度な事をやってますね。

うん。

4:30 PM

modifyEach, for inout, reduce, for に加えて型マップくらいがあれば道具は足りるのかなぁ。

4:30 PM

でもそのアプローチ特殊化できないよね。

4:30 PM

SwiftUI のパフォーマンスを考えるとどうすればいいんだろう？

あれは TupleView<...> にしたいだけだろうから

4:31 PM

このあたりの話でいくとかなり小さな要件しかなさそう。

4:31 PM

たしか、TupleViewって TupleView<(Text, Image)> みたいに

4:32 PM

型パラメータは1個で、タプル使って擬似的にn個にしてるし。

4:32 PM

func buildBlock<T: variadic View>(views: T) -> TupleView<(T...)> { TupleView((views...)) }

4:32 PM

↑実装側(SwiftUIの中のコード)としてはこれだけじゃないかしら。

あー、えっと、 SwiftUI のことを考えるとっていうのは、 SwiftUI で必要とされてる要件を実現するというより、（ SwiftUI が必要とするように）モジュールをまたいだ特殊化を前提として、一般的な Variadic Generics を考えるとどういう仕組みだといいんだろうってことを言いたかった。

モジュールをまたいだ特殊化

またいだ特殊化？

@inlineable のように、別モジュールから使うときにも特殊化されるようにしたいってこと。

特殊化するには絶対、ABIPublicな必要があって、

4:37 PM

SwiftUIで必要な範囲だったら、引数で受けたN個のパラメータパックを、タプルにする構文(splat) があれば、足りそう。

SwiftUI の名前を出したのは SwiftUI にこだわってるわけじゃなくて、単に SwiftUI にすでにそういうものがあって Variadic Generics を使ってもパフォーマンスを保ちたいニーズがあるから挙げただけで、他のどんなケースでも（たとえば標準ライブラリに任意個数の zip を追加するとしても）ベタ書き展開したのと同じパフォーマンスを実現できるような特殊化を実現するために、どういう方法があるんだろう？と。

4:40 PM

ABI-public なのは前提として。

4:41 PM

さっきの map とか for とかみたいなやり方だとうまく特殊化できなさそう。

なるほど。Example1...5を再検討するのがベストそう ZipSequence難しいですね。

うんむずい

https://qiita.com/pshiko/items/aee2641149b0cc97e287

c++でzip関数を実装してみた. C++17の構造化束縛と...

追記

@niinaさんから有り難いコメントを頂き、type_traitsを使い一部コードを修正しました。（詳しくは[gitのコミット](https://github.com/pshiko/czipp/commit/f217456...

4:47 PM

C++の実装例を見てみた

4:50 PM

タプルのイテレータとして作って、 next()相当の部分(operator*) は、std::tieとstd::getとstd::make_index_sequenceで作って、 ==はany_cmp_implという関数を作って再帰してた

4:51 PM

std::enable_if_tによるコンパイル時型計算が活用されてますね

うーーん、読めない・・・。いずれにせよそういうメタな道具が必要ってことだね。

このCPP TMPと、件のproposalはだいぶ次元が違う世界だから、ギャップの理解が難しいけど

1:30 AM

可変長パラメータの取り扱いに関して言えば

1:31 AM

T...での宣言と展開、t...での値の展開しか、

1:31 AM

特別なものはなさそうなんだよな。

1:31 AM

それ以外は汎用的？なTMP(template meta programming)

1:32 AM

の道具でできてる

思ったんだけど、求められてるのってタプルに対する演算なんじゃないかな？可変長型パラを型として使うとそれらを展開したタプル型として扱われて、タプルの構造を維持したまま個別要素に対する操作を行える方法を提供する。タプルの要素に対する制約があるから、制約の範囲で共通の操作を受け付けられる。必要な操作の種類は、map的なものとreduce的なもの。タプルからタプルへの変換と考えれば型の変化も受け入れられる。後は、タプルの中に展開する ... があればやりたいことは大体できそうな気がする。

可変長型パラと独立にタプルの各要素を操作する方法が提供されていれば（↓の場合はメソッドの形で提供しているけど別の方法も考えられる）、それを土台にして可変長型パラを論じられないかな？

func square<T1: Numeric, T2: Numeric>(of values: (T1, T2)) -> (T1, T2) { values.map { $0 * $0 } } square(of: (3, 5.0)) // (9, 25.0)

func firsts<S1: Sequence, S2: Sequence>(of sequences: (S1, S2)) -> (S1.Element?, S2.Element?) { sequences.map { $0.first } } firsts(of: ([2, 3, 5], "XYZ")) // (2, "X")

func descriptions<T1: CustomStringConvertible, T2: CustomStringConvertible>(of values: (T1, T2)) -> (String, String) { values.map { $0.description } } descriptions(of: (42, true)) // ("42", "true")

func sum<T1: IntConvertible, T2: IntConvertible>(of values: (T1, T2)) -> Int { values.reduce(0) { $0 + $1.asInt() } } sum(of: (3, 5.0)) // 8

(edited)

↑のタプルに対する操作を可変長型パラに拡張して

func square<T...>(of values: (T...)) -> (T...) { values.map { $0 * $0 } } square(of: (3, 5.0, Complex<Double>.i)) // (9, 25.0, (-1.0, 0.0))

func firsts<(S: Sequence)...>(of sequences: (S...)) -> ((S.Element?)...) { sequences.map { $0.first } } firsts(of: ([2, 3, 5], "XYZ", 42...)) // (2, "X", 42)

func descriptions<(T: CustomStringConvertible)...>(of values: (T...)) -> (String...) { values.map { $0.description } } descriptions(of: (42, true, "XYZ")) // ("42", "true", "XYZ")

func sum<(T: IntConvertible)...>(of values: (T...)) -> Int { values.reduce(0) { $0 + $1.asInt() } } sum(of: (3, 5.0, "7")) // 15

たしかに可変長型パラメータより基本の道具としてタプルの静的な型操作がありそう

7:08 AM

ただやはりmapやreduceの中に書ける計算の質のルールが何かしら必要そう

7:11 AM

文字列固定のやつはいかそう Selfのままと Associatedtypeは対応したいけど

7:11 AM

その２つだけの特別な扱いというより

7:11 AM

なんか規則的な事があるような気がする

Self と AssociatedType に限らず、制約から導かれる T -> K として一般化できないかな？

7:24 AM

たまたま K が T 自身だったり、 T の associatectype だったりするだけで。

一般化したい

あーーなんか閃いてきた

7:38 AM

(移動中・・・

7:43 AM

sequences.map { $0.first }

7:43 AM

↑ここのmapに与えてる関数の型を考えたんですけど

7:43 AM

<T: Collection>(_ x: T) -> T.Element (edited)

7:44 AM

↑型としてはこのように書けると思います。

7:44 AM

で、何が引っかかっていたかと言うと

7:44 AM

今のSwiftでは関数型オブジェクト(クロージャ)は、ジェネリックパラメータを取れないんです

7:44 AM

だから、まずそこを拡張する必要がある。

7:45 AM

次に

7:46 AM

ある多相な型関数 <A>(A) -> B を考えると

7:47 AM

あいや、 <A>(A) -> B かもしれないんですけど

7:47 AM

この計算(AからBを求めること)を記述できる言語機能は

7:47 AM

多分 struct に対するメンバの typealias しかない。

7:47 AM

で、ただ、 <A>A が多相なので

7:48 AM

<A> に与えられる実際の型を規定するのが、

7:48 AM

言語機能としての protocol だと思う。

7:49 AM

つまり、 <A>(A) -> B は protocol AP { associatedtype R } なときに、 <A: AP>(A) -> R な式が持ってる型。

7:51 AM

普通のクロージャ構文だと、 $0 って書いた時点でもうなんらかの T としてのコンパイルになっちゃってクロージャも (T) -> U になるけど、そうじゃなくて <A: P>(A) -> U のほうにならないといけない。

7:51 AM

でそれがあると、

7:52 AM

動的なタプルの場合は動的な処理としてさっきのmapが動かせて

7:52 AM

もし入力元のタプルの型が静的にわかっているときは、

7:53 AM

静的解析で結果のタプルの型がわかる。

7:54 AM

$0.first は、 $0 の型がわかっている(<A>(A) -> B の A が特定できる)ときには、 .first の型が静的にわかるけどそれは、 .first の associatedtype を与えているprotocolがあって、それを個別の A が充足してる　typealias が静的に見えるから、です。

7:56 AM

任意の x.y の形の式に対して、 x の型があるプロトコルで制約されていて、 y がそのプロトコルのメンバなのであれば、 x.y は静的に具体的な型が決定できる式、って事になりそう。

7:56 AM

x だけのときは <A>(A) -> A まあつまり <Self>(Self) -> Selfとして同じことが言える。

7:58 AM

式が複雑になって？そうじゃないものが式の中に混ざり込んだ時は、静的に決定できない式になって、タプルのmapとしては、全部の要素の型が同じタプルになっちゃう。

7:58 AM

そうじゃないものって存在しない気がするな？

8:00 AM

必ず何らかの式の型はあるから型は決定できるけど、 <A>(A) -> B の B が　<A> を充足する個別の T に対して静的に解決できる型の場合と <A> に入る T がなんであろうが固定の型になっちゃう場合 ( description($0) など )がある。

8:01 AM

この、個別に異なりえて、かつそれが静的に決定できる場合と、そうでなくて固定になっちゃう場合が、またなんかちゃんと述べられる気がする。

8:01 AM

やっぱ　<A>(A) -> B と <A>(A) -> B の違いなんじゃないか？？

8:03 AM

なぜなら、 map に <A>(A) -> B を与えたらそりゃ結果は (B, B, B, ...) でしか無いはずなので。

8:04 AM

で、結果の型は、呼び出し側から決定できるわけじゃないから、リバースジェネリックパラメータがあるってことになりそう。

(String...) については、本当は (type(of: T.description)...) なんよね。 associatedtype との違いは、それを記述するシンタックスがないだけで、どちらも T によって一意に決まる点は同じ。

8:13 AM

CustomStringConvertible に準拠した型の description という時点で String が決定される。

8:14 AM

associatedtype の場合は個々の T によって別の型が導かれる。

8:14 AM

シンタックスの問題以外は同じ話だと思うけどなぁ。

いや、そこが違うと思います

8:15 AM

CustomStringConvertible の description は

8:15 AM

<T: CustomStringConvertible> の T がたとえわかっていなくても String であるとわかるけど

8:15 AM

associatedtype の場合は個々の T がわかってないと導く型がわからない。

8:16 AM

そこには型システム的な意味の違いがある気がする。

それはそうだけど、それって↓の差と同定の話だと思うけど。 ```swift func first<S: Sequence>(of sequence: S) -> S.Element? { sequence.first } ``` ```swift func description<T: CustomStringConvertible>(of value: T) -> String { value.description } ```

あ〜そうか。 S.Element な時点で　パラメータ的な型になっているのか。

8:20 AM

ただ、クロージャとして入力パラメータが残ってないといけないという違いはやっぱりあると思います。

8:20 AM

descriptionの例は (CustomStringConvertible) -> String 型のクロージャを渡してるって事でも説明ができるけど

8:21 AM

firstの例はexistentialで考えると書けない

入力パラメータが残ってないといけない

これはそうだと思うけど、それって associatedtype に限らず、可変長型パラを使う時点で残しておこないといけないよね？

はい、可変長型パラに対するコレクション操作みたいなことをやろうとしたら

8:22 AM

その操作を記述するクロージャは型パラメータを取るんじゃないかって事です。

CustomStringConvertible の方のクロージャも、 existential ではなくて、あくまで型パラを埋められたときに決定される T を使って (T) -> String となるイメージ。

8:23 AM

タプルの操作と可変長型パラを同時に考えるとややこしいから、まずは普通のタプルについて考えたら

動的な振る舞いを考えるとそういう事だと思います。

func firsts<S1: Sequence, S2: Sequence>(of sequences: (S1, S2)) -> (S1.Element?, S2.Element?) { sequences.map { $0.first } }

は

func firsts<S1: Sequence, S2: Sequence>(of sequences: (S1, S2)) -> (S1.Element?, S2.Element?) { (sequences.0.first, sequences.1.first) }

のシュガーみたいに解釈できると思うんよね。

8:25 AM

シュガーとして考えるときにメソッドという形がややこしければ、別の新しいシンタックスを導入してもいい。

// Array func map<T, U>(_ f: (T) -> U) -> Array<U> // Tuple3 func map(_ f: <T, U>(T) -> U) -> (<type(of: f(E1)), type(of: f(E2)), type(of: f(E3)) )

8:26 AM

↑こういうことじゃないかしら？？

もう少し正確に書くと↓かな。

func firsts<S1: Sequence, S2: Sequence>(of sequences: (S1, S2)) -> (S1.Element?, S2.Element?) { ({ $0.first }(sequences.0), { $0.first }(sequences.1)) }

シュガーみたいに解釈できる

期待してる実行結果がそうなのはそうですが、それをジェネリックに表現する型の言葉が必要だと思います。

8:27 AM

それは、これまでのジェネリクスでも同じ事で

えっと、普通のタプルについては完全にシュガーとして変換できるよね？

struct Box<T> { var x: T } // に対して // Box<Int> は struct Box<Int> { var x: Int } // というシュガー展開として解釈できる // 実際最適化でもそうなる、 // でも動的な動作の場合は、↑と同じ結果をもたらす一つの仕組みになる

8:29 AM

クロージャの中身が見えないので変換できないです。

解釈だけじゃなくて、普通のタプルに対する map はコンパイル時に展開できる。

mapがinlinableならできるけど。

可変長を混ぜて考えるとややこしいから、まずは普通のタプルについて考える。

8:30 AM

その後、可変長型パラとの組み合わせにおける拡張を考える。

8:30 AM

↑の 2 要素固定タプルでコンパイラが書き換えできない例ってあるかな？

8:31 AM

@escaping とか

２要素タプルは言語に１個しかないから

8:31 AM

仕様が固定されれば、ユーザー側で展開できると思います

8:31 AM

それは普通のgenericsでも同じ事で。

色々工夫が必要なケースがある気がしないでもないけど、基本的にできると思うんよね。

8:32 AM

いや、利用側じゃなくて、その関数で完結して展開できるよね？

なんだろう、ABIPublicでコード展開が可能っていう方針で考える限り

ABI-public である必要すらない。

型とか考えなくて良い気がするんですよね

8:32 AM

展開後のコードについて型チェックすれば良いから。

8:33 AM

gybを使ってるときと同じノリ。

8:37 AM

tuple.map { expression } って形で書ける事にすることで、見かけはSwiftコードっぽくなるけど、このmapをコードの展開として考えるのであれば、あくまで型システムや実行モデルで考える必要があるのは、展開後のコードだけの話になるので、なんだろう、見た目がおしゃれなgybみたいな感じの話になると思うんです。

8:38 AM

その方針で突き詰めていっても最終的に、ユーザー定義可変長ジェネリクスの話まで到達した時に、実行モデルの話が出てきて止まっちゃうので、最初から、 tuple.map { expression } ↑コレ自体をSwiftのコードとして受け付けられるようにする方法を考えたほうが良い気がします。

うん、可変長型パラを考えたらそこで実行モデルの話が出るのはその通りだけど、

8:42 AM

それって（普通の）型パラが特殊化されなかった場合に三組で扱うのと同じような話で、それを扱えるモデルを導入すれば済む話なんじゃない？

8:43 AM

特殊化されれば可変長でも展開されるし、特殊化されなければその実行モデルで動的に処理される。

8:43 AM

あと、可変長型パラまでの間にもう一つ可変長タプルがある気がする。

8:44 AM

func square(of values: (Int...)) -> (Int...) { values.map { $0 * $0 } }

8:44 AM

↑を扱う実行モデルがあれば、それを使って可変長型パラでもいけるんじゃないかな？

8:45 AM

func descriptions(of values: (Int...)) -> (String...) { values.map { $0.description } }

それを扱えるモデルを導入すれば済む

実行はそうですね、３つ組ですねで、実行できる前の型チェックが鬼門かなと思います

func firsts<T>(of arrays: [T]...) -> ((T?)...) { arrays.map { $0.first } } (edited)

8:47 AM

そうかな？各 T には同じ制約付いてるから、普通にその制約についてチェックするだけじゃない？

例えば

let aa: [Int] = [1, 2, 3] let sa: [String] = ["a", "b", "c"] let zipped = zip(aa, sa) let fst = zipped.first! let ri : Int = fst.0 let rs : String = fst.1

8:49 AM

↑こう書いた時に、 ri: Int と rs: String の部分の型チェックが必要で

8:50 AM

fst の型が (Int, String) であることが、 ZippedSequence.first の型定義シグネチャから導かれないといけない。

use-site については型が決まるから展開してから考えるんじゃない？

8:51 AM

問題は declaration-site でどのように扱うかというモデルであって、

8:51 AM

use-site は常に展開したらいいんじゃないかな？

展開するために

8:55 AM

ZippedSequence.first の宣言は・・・

8:55 AM

まあなんか書けるか。 Elementのところが可変長タプルになってればよいか。

8:56 AM

気になってるのは２要素タプルのmapで

8:57 AM

extension <A, B> (A, B) { func map(_ f: <T, U>(T) -> U) -> (T, U) } 多分こう

8:57 AM

func firsts<T>(of arrays: [T]) -> ((T?)...) { arrays.map { $0.first } } ↑コレはヤバそうですね、要素数がArrayの動的な個数からタプルの静的な個数にする？

ああ、間違えた

これは可変長型パラを超えたその先の機能だと思います Arrayの要素数の静的な追跡が必要になる

func firsts<T>(of arrays: ([T]...)) -> ((T?)...) { arrays.map { $0.first } }

あれ、それだと、Tが同じにみえる

8:59 AM

あ、要素数だけが可変長って事ですか？

うん。

9:00 AM

元の方も修正しました。

あ〜そうか

9:01 AM

それはそれで必要ですね

↓の 3 ステップで実現するのが良いと思う。 1. タプルに対する map-like, reduce-like オペレーション 2. 可変長タプル 3. Variadic Generics

gybだとできるけどSwiftでできなくてでも可変長型パラではない。

うん。

9:02 AM

1 と 2 の道具があれば、可変長型パラをその上に乗せられると思うんよね。

関係はそうなってる気がする。

この 3 step はどう？って forum に書いてみようか・・・。

9:03 AM

何か知見が得られるかも。

// これは展開できるから良いとして func f1(_ tpl: ([Int], [String])) { let fst: (Int?, String?) = tpl.map { $0.first } } // これもジェネリック型のまま展開できる func f2<T, U>(_ tpl: ([T], [U])) { let fst: (T?, U?) = tpl.map { $0.first } } // でもその変換が外部から来たら展開できない、こうか？ func f3(_ tpl: ([Int], [String]), _ g: <A>(A) -> <B> B) { // #decltypeはC++からアイデアを借用 let fst: (#decltype(g(tpl.0)), #decltype(g(tpl.1)) = tpl.map(g) } // これもこう？ func f4<T, U>(_ tpl: ([T], [U]), _ g: <A>(A) -> <B> B) { let fst: (#decltype(g(tpl.0), #decltype(g(tpl.1)) = tpl.map(g) }

(edited)

9:53 AM

↑やっぱりmapに渡すクロージャの型は、リバースジェネリクスが含まれませんかね？  が前にあるとしたら、呼び出し側が決定するわけだけど、実際g　の実装が $0.first なのか description($0)　なのかわからないという立場だから、 f3 や f4 からすると、  のパラメータは指定できない。 (edited)

f3 を実現するには↓になるんじゃないかな？ func f3<T..., U...>(_ tpl: ([T]...), _ g: ((T) -> U)...) { let fst: (U...) = tpl.map(g) }

10:05 AM

T... と U... の数が同じであることや、どの ... がどの ... と対応するのかは、何らかのシンタックスで指定できる必要があるけど。

今は、(f1,2,3,4)シンプルに2要素タプルを考えてます (edited)

10:05 AM

可変長パラメータではない。

2 要素タプルではできないよ。

10:06 AM

タプルの map は単純にタプルについての式だから。

できないとは？f1,f2,f3,f4のどれが変ですか？

f3

10:06 AM

f3 を書くなら↓になる

f3では、f1とf2で { $0.first } になっている部分が、引数として外からやってくる場合を考えてます。

func f3(_ tpl: ([Int], [String]), _ g: ((Int) -> Foo, (String) -> Bar) { ... }

10:08 AM

タプルの map と関数のシグネチャはまったく関係ない。

10:08 AM

タプルの map はそれを使う式に閉じた話。

10:09 AM

f3 は 2 要素タプルを受け取ってて、それと map には何の関係もない。

10:09 AM

それぞれの要素にオペレーションを指定したいなら、オペレーションも二つ渡さないといけない。

10:09 AM

それを一つにまとめることをしたいなら、さっき書いた↓になる。 func f3<T..., U...>(_ tpl: ([T]...), _ g: ((T) -> U)...) { let fst: (U...) = tpl.map(g) }

10:10 AM

ああ、これでもおかしいか。

10:10 AM

一つにまとめられてるわけじゃないな。

10:11 AM

うーん、そうか。

えっと、 2要素タプル (T, U).map(g) という式において、g の型がどういうものかを考えているんですけど、 { $0.first } が渡せるのであれば、これはオペレーション？というか、関数型の値としては、１つですよね？

10:11 AM

でも map から見たら、渡された g を 2回使うわけです。

実行モデルはあくまで内部的なものだから

10:13 AM

それに対応したことができないといけないわけではないんじゃない？

10:14 AM

特殊化されないときの三組を明示的に作れないのと同じように。

10:14 AM

（それができるなら generalized existential みたいなこともできるはず）

f1、f2とf3, f4は抽象度が違うので、f3, f4はできるようにはならない、という仕様で考えること自体は別に良いと思うんですが、もしできるようになったら型システムにおいてどういう意味を持つかを考えておかないと、 f1、f2の実装が筋の悪いものになっちゃうかもしれない。

f3 みたいなのは、 Variadic Tuple だけじゃなくて Variadic Generics の文脈でも意味を持たないと思うんだよなぁ。それを考えるなら、この問題とは独立してまずジェネリック関数オブジェクトを考えないといけないんじゃないかな？

10:24 AM

で、それがあればそれを受け取ることでタプルの map に渡すとかも考えられるようになると思う。それが必要かは別として。

f1、f2の時点で、 map　にクロージャを渡すところで、このmap自体のシグネチャがあるはずなので、 (edited)

10:26 AM

f1, f2 でもそこは考えてるはずじゃないですか？

10:27 AM

例えばXcodeで、f1のコードのmapのところをCmd + Clickしたら、mapのシグネチャが出るはず。

いや、これはただのクロージャじゃないから、クロージャとメソッドのような構文を採用してるだけで。

10:28 AM

別に↓でもいい。 func squares<T1: Numeric, T2: Numeric>(of values: (T1, T2)) -> (T1, T2) { #map element in values { element * element } }

10:29 AM

実行モデルとしては、ジェネリック関数オブジェクトのようなものを持たないといけないし、

10:29 AM

特殊化されると個別に展開される。

実行モデルとしては、ジェネリック関数オブジェクトのようなものを持たないといけないし、

実行モデルとしても、型システムとしてもそれが必要なのではないかなと。そうでないと、f1のlet fst の型チェックのところで、型推論器が困っちゃうし。静的なコード展開だけを考えてるなら、いらないとおもいます、その場合は実行モデルを考える必要も無いその場合は、ユーザーにとってどんな文法で機能を提供すればよいか？を話したいってことですかね (edited)

いや、固定長タプルに対しての map や reduce は静的に展開されるけど、

10:35 AM

可変長タプルや可変長型パラは特殊化されない限り動的に扱わないといけないから

10:35 AM

そこでこれまでにない実行モデルが必要になる。

10:36 AM

そのときにクロージャはジェネリック関数オブジェクトのようなもので扱われると思う。

10:36 AM

コーディングする側は、そこに書くクロージャ式は外で定義された T: Protocol について書くときと同じようになる。

10:38 AM

func square<T: Numeric>(of values: [T]) -> [T] { values.map { $0 * $0 } }

10:39 AM

↑と↓は func square<variadic T: Numeric>(of values: (T...)) -> (T...) { values.map { $0 * $0 } }

10:39 AM

クロージャを書くときの意識はまったく同じだと思うけど。

10:40 AM

それがどのように扱われるかが違うだけで。

10:40 AM

クロージャの中で守るべき制約も、コンパイルエラーになる条件も、何も変わらなくない？

10:41 AM

ABI 上は新しいものを追加しないといけないし、実行時にはジェネリック関数オブジェクト的なものにしないといけないし、特殊化されたら展開されないといけない。

10:41 AM

一度落ちます。

それは、例示してるmapの中身が単純だから、性質の違いを踏んでいないだけだと思います。例えば

func square<T: Numeric>(of values: [T]) -> [T] { var sum: T = T.zero let ret = values.map { (a) in sum += a return a * a } print("sum is \(sum)") return ret } // ↑これはコンパイルが通るけど // ↓これはエラーになるはずです func square<variadic T: Numeric>(of values: (T...)) -> (T...) { var sum: T = T.zero // ←まずこれが書けないし let ret = values.map { (a) in sum += a // values.0 と values.1は型が違うから + はできない return a * a } print("sum is \(sum)") return ret }

10:50 AM

ジェネリック関数のジェネリックパラメータは呼び出しのたびに具体型が渡されてくるけど、前者のArrayの例ではmapのクロージャのa はずっと同じ T 型 (squareのスコープで束縛) だけど後者のTupleの例ではクロージャの a は呼び出されるたびに別のもの。

T はクロージャの中でしか具体的な型を持たないから、クロージャの外で T.zero はできないね。 T はクロージャの外ではそのままでは使えない。 (T...) とか、 (T.Foo...) とか、展開した形でないと。

12:39 PM

そういう意味で確かに array 版とは異なるけど、そういうことじゃなくて、

書けるようにするなら var sum: #first(T) とかでしょうね。 (edited)

それもだめじゃない？

var sum: #decltype(values.0) でもいいか。

12:39 PM

ああ、いずれにせよ、足せないです。

12:40 PM

T はクロージャの中でしか具体的な型を持たない

言いたかったのはそういうことで、型システム的に異なる意味をもっているということです。

そこの型にはアクセスできなくていいと思う。

12:41 PM

してたのはクロージャをどう扱うかという話だから、クロージャの中の世界は同じように型検査ができると思うよ。

12:41 PM

外の世界では展開しない T は使えない。

12:41 PM

そのルールでうまくいくんじゃないかな？

12:42 PM

sumやるなら制約を加えて変換できるようにしないといけなくて、IntConvertibleの例みたいに。

mapについてはそういうシバリでの実装はできそうですね (edited)

reduceも同じ。

んーたとえば

12:42 PM

(Int, String, Float) を (String, Float, Int) みたいに

12:42 PM

ローテーションするようなオペレーションを作ろうとしたら

それはそのためのオペレーション用のメソッドが必要だろうね。

また map, reduce　とは別の機能が必要そう。

このmapやreduceはメソッドじゃなくて特殊構文だから

12:44 PM

足りないものは言語が用意するしかないんじゃないかな？

mapやreduceをユーザー実装できるような

そこをユーザー定義できるようにするというのは、

もっとプリミティブな道具だけ提供する方法があったらよさそう

言語のメタレベルを上げないときついと思うよ。

12:45 PM

それこそ、言語の仕組みの上で Variadic Generics を可能にする仕組みを自作できるようなメタ度になるんじゃない？

12:46 PM

制御構文だって自作できないし。

12:46 PM

ちなみに reduce は for でもいいんだけど、

12:46 PM

ループの中だけ T が展開される

12:47 PM

ループ回るたびに別の型として実行される

12:47 PM

でも特殊化が難しそう、と思ったけどループばらすだけだから簡単か。

C++のTMPだと変数が絡んじゃうループは使わなくてだいたい再帰とコンパイル定数と分岐でやるけど、うーんたしかにそういう方針だと必要なものが一気に増えるな

ためしに書いてみた。どうでしょ？ https://gist.github.com/koher/62ec1cb06258e1d6f034645506e7f99e (edited)

READ.md

GitHub Gist: instantly share code, notes, and snippets.

5:02 AM

こんな内容で forum に投稿してみたらどうかと考えてるんだけど。

長！　レスじゃなくて、スレ立て？

5:03 AM

あ、[PITCH]って書いてあった。

_ = xs.map { x: T in // ✅ OK

↑(x: T) じゃないと文法エラーで、それを直したとしても、ここに T はおかしいような。 T　じゃないから。

5:12 AM

実際には T1 T2 T3 , ... のように別々の型になってて、毎回違うやつになってるから。

5:13 AM

ソレ以外の全体としては言いたいことが整っててわかりやすいと思いました。

ありがとう。 () たしかに。 T は、 variadic generics では T でいいと思うけど、 nomal tuple のときは書きようがないんよね。

6:20 AM

<(T: Protocol)...> で、 T は可変長型パラの一つの型を表すプレースホルダー。

variadic generics では T でいい

variadic tupleでは　ですか？

6:28 AM

tupleの時はそうですね。ジェネリッククロージャがもしあれば↓こうかなと思いますけど。 func squares<T1: Numeric, T2: Numeric>(of values: (T1, T2)) -> (T1, T2) { values.map { <X> (a: X) in x * x } }

variadic tuple だと要素の型が固定されてるので具体的な型で書けるよ。

7:19 AM

あー、 (Int, Double...) とかもあるから一般的には言えないか。

7:21 AM

variadic generics では T でいい

その言葉の通りです。 func squares<(T: Numeric)...>(of values: (T...)) -> (T...) { values.map { (value: T) in value * value } }

7:22 AM

この T はタプルオペレーションの外では T... としてしか使えないけど、中では T として使えて、 T... の個別の型を表すプレースホルダーとして働く。

あ〜、mapの中ではその時のT　を表すという解釈か。

うん。

7:57 AM

normal tuple のときに制約が適用されるルールが曖昧かなぁ。

7:58 AM

各要素の共通の制約が自動的に適用されるのはあまり swifty でない感じがする・・・。

共通のプロトコルを導き出す挙動ってあったかなぁ。

これまでタプルの要素に対して共通のオペレーションを行うこと自体ができなかったから、タプルの各要素に共通の制約を適用する構文もなくて、それが問題なんだよなぁ。

共通の制約が自動でつくの、goにそういうのありませんでしたっけ

stractural subtyping ？

そうそう

swifty な感じがしないんですよねぇ。

Goのstatic duck typingは宣言を伴わないからまた違うと思う

この先にgo相当のそれが欲しいという議論が出てきそうだな、と。

これは T1 と T2 がそれぞれ Numeric に適合してることは述べられているけど、 values のすべての要素が共通して Numeric に適合していることは暗黙的だから、 map したときに * できるのは structural subtyping 的だと思う。 func squares<T1: Numeric, T2: Numeric>(of values: (T1, T2)) -> (T1, T2) { values.map { $0 * $0 } }

Swift的にはジェネリッククロージャとして自前で宣言する方向だと思います

func squares<T1: Numeric, T2: Numeric>(of values: (T1, T2)) -> (T1, T2) { // T1とT2がXに束縛できるか静的にチェック values.map { <X: Numeric> (a: X) in x * x } }

8:04 AM

$0 記法の時は悩ましいな。

8:04 AM

これまで関数のシグネチャが推論されるのはクロージャーだけで、func のシグネチャ推論は存在しなかったから

8:05 AM

クロージャーに存在しないジェネリックパラメータが増えると推論をジェネリックパラメータで受けるのか型で受けるのか曖昧性が出てくる場所もありそうだ

タプルの型宣言に制約を記述できないかな？

8:05 AM

これまで使い道がなかったから構文がないだけで。

8:07 AM

let a: <*: Numeric>(Int, Double) = (2, 3) let b = a.map { (a: X) in a * a } // X: Numberic (edited)

8:08 AM

冗長な感じがするなぁ。

func squares<T1: Numeric, T2: Numeric>(of values: (T1, T2) where Element: Numeric) -> (T1, T2) (edited)

書かなくても自明なわけだし、自動的に推論されてもいいような気もしてきた。

least common conformanceって簡単に求められるのかなあ。 (edited)

8:11 AM

least common supertypeの推論ロジックはあるんですけどね。

配列を宣言する時に

8:11 AM

[dog,cat]ってやったらどうなるんだっけ

least common supertype

8:12 AM

ただ、Existentialにはならなかった気がする？

そう、それと同じ気がしてて

8:12 AM

@swift-5.1.5 func f<X>(_ xs: [X]) { print("Any: \(xs)") } func f<X: Numeric>(_ xs: [X]) { print("Numeric: \(xs)") } f([2, 3, 5])

Numeric: [2, 3, 5]

それはfのオーバーロード探索だから、求めたい共通性の候補をユーザーが与えている

8:13 AM

@swiftbot class Animal {} class Cat: Animal {} class Dog: Animal {} let a = [Cat(), Dog()] print(type(of: a))

omochimetaru

class Animal {} class Cat: Animal {} class Dog: Animal {} let a = [Cat(), Dog()] print(type(of: a))

Version:

swift-5.1.3-RELEASE

Output:

Array<Animal>

Error:

@swiftbot protocol Animal {} class Cat: Animal {} class Dog: Animal {} let a = [Cat(), Dog()] print(type(of: a))

omochimetaru

protocol Animal {} class Cat: Animal {} class Dog: Animal {} let a = [Cat(), Dog()] print(type(of: a))

Version:

swift-5.1.3-RELEASE

Output:

Error:

/usercode/main.swift:5:9: error: heterogeneous collection literal could only be inferred to '[Any]'; add explicit type annotation if this is intentional let a = [Cat(), Dog()] ^~~~~~~~~~~~~~ as [Any]

今はExistentialは無理みたいですね。

square のは existential ではないんよね。

(今の２つのコードはclass Animalかprotocol Animalを変えてる)

8:14 AM

はい、制約それ自体を推論させる仕組みは多分存在しない

8:14 AM

推論できるのは型パラメータに適用する型の方で

8:15 AM

型パラメータの制約は型ではない

8:15 AM

まあ

8:15 AM

そもそも今できない事を拡張してできるようにする話をしているんで

そのものがなくても、類似の仕組みはあるわけだし、制約が推論されても良さそうな気はするね。

「$0 is Numeric を自動的に推論するんだ」って提案するのは自由ですね (edited)

8:17 AM

ある型が満たすプロトコルを全部列挙することはできるはず(superprotocolを走査)だから積集合を取るだけな気はしますね

8:17 AM

その後冗長なものを排除した上で残ったもののintersection protocolですね

[Pitch] と [Pre-pitch] と [Idea] ってスレッドがあるんだけど、どれがいいんだろう・・・。

https://forums.swift.org/t/about-the-pitches-category/11

[Pitch] よりももっとふんわりした話な気がするんだけど、温度感がよくわからない・・・

↑一応こういう風に、タグの説明がそれぞれありますよ。

8:51 AM

タグとしては Pitch か Discussion がありますね

8:51 AM

PrePitchはフォーラムのタグじゃなくて勝手にタイトルにつけてるだけ

8:52 AM

The Pitches category is an area for pitching ideas for evolution of the Swift language prior to a formal review. The Evolution Discussion category is for general discussion of the evolution of the Swift language.

(edited)

うん、でもニュアンスはわかるんよね。 Pitch の前段階って言いたい。

8:52 AM

Pitches タグを付けた上で [Pre-pitch] とかにしとけばいいかな。

Discussionタグは特定のアイデアについて話すやつではなかったのか。今知った。

8:53 AM

そうですね

[Idea] の温度感がわからないけど・・・。 [Idea] っちゃ [Idea] な気もするけど。まあ、定義も存在しない雰囲気なんだろうけど。

僕が見てる限りはそんなに統一感は無いですよ

よくわからんし [Pitch] でもいい気もしてきた

初めて投稿する人とか結構定期的に現れるのもあって。

8:56 AM

こういうときは XXタグのほうがいい　みたいな指摘自体も見かけない

投稿してみた。 https://forums.swift.org/t/pitch-three-steps-to-variadic-generics/33154

[Pitch] Three steps to Variadic Generics

Variadic generics was referred to in "On the road to Swift 6". I think it may be a good idea to break down it into the following three steps compared to tackle variadic generics directly. Operations for tuples Variadic tuples Variadic generics 1. Operations for tuples The ...

読みました。３ステップの構成が非常に読みやすかったです！

10:03 AM

func tupleFrom<T>(head: T, tail: (T...)) -> (T, T...) { (head, tail...) } let a: Int = 2 let b: Int = (3, 5) let c: (Int, Int, Int) = tupleFrom(head: a, tail: b) // (2, 3, 5)

ここの b の型は (Int, Int) ですかね?

返信しづらいリプが付いたなあ

まあここの議論は見えてないですからね。無視してるんじゃなくてそこからスタートしてそこの議論に立脚してこのような考えが出ている、ということを説明したらいいんじゃないか（大変ですが。。）

10:52 AM

要するにそれは誤解である、と。

そうなんだけど、そのためには、既存のプロポーザルがなぜ微妙で、やり直したいか、って論拠が必要ですよね。

必要だと思います。なんでブレークダウンして個別に考えた方がいいのか、ってことの理由だと思うので。

そうですね。

一応返事しておきました。 https://forums.swift.org/t/three-steps-to-variadic-generics/33154/3

Three steps to Variadic Generics

@DevAndArtist No. Before I created this thread, I discussed the proposal of the thread with my colleague and during the discussion I noticed that variadic generics can be broken down into small steps. It was just an idea and I was not sure if it was a good approach. It is a...

12:41 PM

@Yuta Saito ありがとう！直しました。

1

with my colleagueだとそれがおもちさんであると言うのが理解できない気がしました。

my colleague が誰であるかが重要だということですか？ (edited)

リンク先がおもちさんの投稿だったので、元々の議論からの派生だということが分かりやすくなって良いかと思ったんですが、まあどっちでもいいか。

I agree it’s worth linking to the other thread in this OP, but I disagree that “this town is too small for all of these threads” or that we as a community need to put all of our eggs in one basket or else never make any progress. I have been following the other thread and I still welcome this view on how to break down the feature conceptually.

https://forums.swift.org/t/three-steps-to-variadic-generics/33154/6 比喩が多くて賛成してるのか反対しているのかよくわからない・・・。 " I disagree ... that we as a community need to put all of our eggs in one basket" だからスレッド分けてもいいじゃないって言ってるのかな？ (edited)

Three steps to Variadic Generics

And that‘s my point. You‘re proposing to push the topic forward, yet you have your own vision of this whole feature and do not consider that you could block further generalized designs. No offense though. ;)

スレッドの分け方で消費しないで中身見ようぜ、と言ってるように見えました。

3:12 AM

一応ちょうど今日メにいるのでネイティブ勢に聞いてみます

1

ネイティブ勢に聞いたら違うかったw 「元スレは話題が増えすぎると進捗できなくなるから、新しいスレッドを作るのがいいと思うぜ」とのこと。

3:57 AM

むっっっっず

Adrianさんの英語むずかしいね

ありがとうございます。 Forum で英語で話すのむずいと思ってましたが、技術の話してても、きっと議論は技術英語じゃないからむずいんですね・・・。

5:33 AM

@omochimetaru これは Adrian さんじゃなくて Mathew さんだね。

ああ

↓これ確かにできるんだけど、特殊化がきつい気がする。再帰関数を再帰インライン展開することとかあるのかな？

// as pseudo syntax. func squares<(T: Numeric)...>(of values: T...) -> (T...) { switch values { case (): return () case let (t, ts...): return (t * t, squares(ts)...) } }

(edited)

5:37 AM

再帰インライン展開自体は世の中に存在するのか。 Swift にはあるのかな。 https://stackoverflow.com/questions/190232/can-a-recursive-function-be-inline

Can a recursive function be inline?

inline int factorial(int n) { if(!n) return 1; else return n*factorial(n-1); } As I was reading this, found that the above code would lead to "infinite compilation" if not handled by compi...

C++はTMPでできますねループが無いからだいたい再帰だし

5:42 AM

通常の関数の最適化は知らないです

5:43 AM

Swiftの場合自己再帰が無限ループしてる時の診断はありましたね

@swift-5.1.5

func factorial(of n: Int) -> Int { if n <= 1 { return 1 } else { return n * factorial(of: n - 1) } } print(factorial(of: 5))

120

swiftc -O -emit-ir recursive-inlining.swift | cat

5:54 AM

define i32 @main(i32, i8** nocapture readnone) local_unnamed_addr #0 { entry: %2 = load %swift.type*, %swift.type** @"$ss23_ContiguousArrayStorageCyypGML", align 8 %3 = icmp eq %swift.type* %2, null br i1 %3, label %cacheIsNull.i, label %"$ss23_ContiguousArrayStorageCyypGMa.exit" cacheIsNull.i: ; preds = %entry %4 = tail call swiftcc %swift.metadata_response @"$ss23_ContiguousArrayStorageCMa"(i64 0, %swift.type* getelementptr inbounds (%swift.full_type, %swift.full_type* @"$sypN", i64 0, i32 1)) #5 %5 = extractvalue %swift.metadata_response %4, 0 %6 = extractvalue %swift.metadata_response %4, 1 %7 = icmp eq i64 %6, 0 br i1 %7, label %is_complete.i, label %"$ss23_ContiguousArrayStorageCyypGMa.exit" is_complete.i: ; preds = %cacheIsNull.i store atomic %swift.type* %5, %swift.type** @"$ss23_ContiguousArrayStorageCyypGML" release, align 8 br label %"$ss23_ContiguousArrayStorageCyypGMa.exit" "$ss23_ContiguousArrayStorageCyypGMa.exit": ; preds = %entry, %cacheIsNull.i, %is_complete.i

5:55 AM

↓続き

 %8 = phi %swift.type* [ %2, %entry ], [ %5, %is_complete.i ], [ %5, %cacheIsNull.i ] %9 = tail call noalias %swift.refcounted* @swift_allocObject(%swift.type* %8, i64 64, i64 7) #1 %10 = getelementptr inbounds %swift.refcounted, %swift.refcounted* %9, i64 1 %11 = bitcast %swift.refcounted* %10 to <2 x i64>* store <2 x i64> <i64 1, i64 2>, <2 x i64>* %11, align 8 %12 = bitcast %swift.refcounted* %9 to %swift.bridge* %13 = getelementptr inbounds %swift.refcounted, %swift.refcounted* %9, i64 2 %14 = tail call swiftcc i64 @"$s4main9factorial2ofS2i_tF"(i64 5) %15 = getelementptr inbounds %swift.refcounted, %swift.refcounted* %9, i64 3, i32 1 %16 = bitcast i64* %15 to %swift.type** store %swift.type* @"$sSiN", %swift.type** %16, align 8 %._value = bitcast %swift.refcounted* %13 to i64* store i64 %14, i64* %._value, align 8 tail call swiftcc void @"$ss5print_9separator10terminatoryypd_S2StF"(%swift.bridge* %12, i64 32, %swift.bridge* inttoptr (i64 -2233785415175766016 to %swift.bridge*), i64 10, %swift.bridge* inttoptr (i64 -2233785415175766016 to %swift.bridge*)) tail call void @swift_release(%swift.refcounted* %9) #1 ret i32 0 }

5:55 AM

%14 = tail call swiftcc i64 @"$s4main9factorial2ofS2i_tF"(i64 5) だし、インライン展開されてる感じはない？

5:59 AM

↓ @inline(__always) 付けたけど結果変わらなかった。

@inline(__always) func factorial(of n: Int) -> Int { if n <= 1 { return 1 } else { return n * factorial(of: n - 1) } } print(factorial(of: 5))

mainでは無くて、factorialのコンパイル結果は？

factorial の declaration-site では再帰回数がわからないから展開できなくない？

6:05 AM

; Function Attrs: nounwind define hidden swiftcc i64 @"$s4main9factorial2ofS2i_tF"(i64) local_unnamed_addr #2 { entry: %1 = icmp sgt i64 %0, 1 br i1 %1, label %2, label %8 ; <label>:2: ; preds = %entry %3 = add i64 %0, -1 %4 = tail call swiftcc i64 @"$s4main9factorial2ofS2i_tF"(i64 %3) %5 = tail call { i64, i1 } @llvm.smul.with.overflow.i64(i64 %0, i64 %4) %6 = extractvalue { i64, i1 } %5, 0 %7 = extractvalue { i64, i1 } %5, 1 br i1 %7, label %10, label %8

ループになったりしてるかなと思って。

6:07 AM

なんもないな

6:07 AM

LLVMだけでもできそうな最適化だけどそうでもないんだなあ

S4TF内にこんなのがあるんですがこういうのもVariadic Genericsで対応してほしいところ。 (元トピック読んでないのでこういうパターンが議論されてるかは知らない)

@differentiable func sequenced<L1: Layer, L2: Layer, L3: Layer, L4: Layer, L5: Layer, L6: Layer>( through l1: L1, _ l2: L2, _ l3: L3, _ l4: L4, _ l5: L5, _ l6: L6 ) -> L6.Output where L1.Input == Self, L1.Output == L2.Input, L2.Output == L3.Input, L3.Output == L4.Input, L4.Output == L5.Input, L5.Output == L6.Input

https://github.com/tensorflow/swift-apis/blob/2cab4dba9889c354c941234f990e1bbab0ca5e5c/Sources/TensorFlow/Layer.swift#L210-L215

tensorflow/swift-apis

Swift for TensorFlow Deep Learning Library. Contribute to tensorflow/swift-apis development by creating an account on GitHub.

パラメータ間の制約なるほど

Variadic generics are basically some small part static metaprogramming facilities, which means it won‘t scale if you try to build it with existing features as we don‘t have any static metaprogramming features yet (besides property wrappers maybe). Variadic packs (basically variadic values variadic T), are similar to tuples but they are not tuples at all. For variadic generics we would need an ability to iterate on variadic packs and also on the variadic type and tell the compiler statically how to generate type safe (boilerplate) code for us.

一般的に variadic generics がメタプログラミングの領域なのはそうとして、今提案してるのってそれをコンパイル時じゃなくて実行時でも扱えるようにするという話と言えるかも。一般的な型パラメータと同じように扱って、実行時にも扱えるし、特殊化によってコンパイル時にも解決できるようにする。それって C++ のテンプレートと Swift のジェネリクスの関係を考えたら自然なマッピングじゃないかな？

12:38 PM

@t.ae こういうのが扱える構文は必要になるよね。

TMP に限らず、 C++ のテンプレートってコンパイル時に解決されるという認識なんだけどそれは正しい？？

はい、C++ のテンプレートはコンパイル時に解決されます。

2:10 PM

C++がそういう仕組みを持ってないというのもあるけど、実行時にGenericパラメータのTが、みたいなものを評価してとかはできないです。

1

2:12 PM

バイナリ配布されたライブラリだったらコンパイルしたときに使われなかった型も使えない。

Swiftのジェネリクスも、テンプレート的に見れば静的にはTのところにIntとかが書かれたコードを生成する機能なので、そうだと思います

func viewDidLoad() { ... var previewSwipeDismiss: PreviewSwipeDismiss = .none { didSet { guard oldValue != .none else { return } if previewSwipeDismiss == .none { self.setupPreviewModeRegular() // reset to regular size self.timeScrubberView.isUserInteractionEnabled = true self.showPlayerControl() } } } ... }

^ ローカル変数のdidSetを使ったコードを久しぶりにみたけどやっぱりRetain Cycleを起こしてたので、便利なんだけど要注意って感じの書き方だなあ。 didSet { [weak self] って書けたらいいのかな？

これviewDidLoad抜けるときに破棄されるんじゃないんですか？

previewSwipeDismissがループしてませんか

あれ、条件はこれだけじゃないんだっけか。

didSet内でpreviewSwipeDismissを参照してる部分ですよね？ここでリークするんですか？

5:59 AM

@swiftbot

class Test { var value: Int init(_ value: Int) { self.value = value } deinit { print("deinit") } } do { var x: Test = Test(0) { didSet { print("did set \(x)") } } x = Test(1) print("exit do") } print("End")

t.ae

class Test { var value: Int init(_ value: Int) { self.value = value } deinit { print("deinit") } } do { var x: Test = Test(0) { didSet { print("did set \(x)") } } x = Test(1) print("exit do") } print("End")

Version:

swift-5.1.3-RELEASE

Output:

did set main.Test deinit exit do deinit End

Error:

あれ、違うか

こういうことですよね？（循環参照になるならdo抜けるときのdeinitが呼ばれないはず） (edited)

ちょっと最小構成を考えてみます。 Retain Cycleを起こすのはdidset内のselfですね。

6:06 AM

前にも同じこと相談して、そのときも単にローカル変数のdidSetだけじゃないよ、ってなったのを見返しました。

省略した箇所でpreviewSwipeDismissがループしてる予感

6:07 AM

エスパーだったw

続きがあって

 previewViewContainer.panGesture(failForSwipe: false, delegate: self) .sink { [weak self] (gesture) in guard let self = self else { return } switch gesture.state { case .began: ... case .changed: ... if delta > 40 && velocity.y > 300 { // quick swipe print("swipe down dismiss") previewSwipeDismiss = .down } else if previewView.frame.minY < -self.view.bounds.height*0.25 { print("swipe up dismiss") previewSwipeDismiss = .up } else { previewSwipeDismiss = .none }

これはループしますね

^ これと組み合わさるとRetain Cycleが起こるんですね。。

previewSwipeDismiss -> self -> recognizer -> pre....

6:09 AM

ローカル変数ではなく、正しくclassのフィールドにしてweak self経由でアクセスすると解決します

そうですねえ。ただきっとフィールドに昇格させたくはなかったんでしょうね。ここでしか使ってないので。

previewSwipeDismissに予めweak selfを渡す構造にすれば

6:11 AM

ローカル変数でも動きそう

6:11 AM

どっちの方が良いかは…

難しいところですね。このコードに関していうと、このGestureのSwitchめっちゃ長いのでここでいろいろやるのやめて、Viewの方に移すべきだなと考えています。

6:14 AM

そしたらpreviewSwipeDismissのdidSetのトリガーがいるとしてもフィールドにしてしまって自然になるはず。。

適切にコンポーネント分割するならそうなりそうですね

とりあえず応急処置としてweak selfを渡すコードでPRして、それで直るけどそのPRに書いたテキストはだいぶ間違ってたということになります

どうもありがとうございました。

↓このあたりで variadic pack と variadic tuple について Core Team メンバーが議論してたっぽいです。 https://forums.swift.org/t/starting-to-implement-variadic-generics/21159/16

Starting to implement Variadic Generics

Oh yes, very good point. Does this mean that variadic parameter packs will be "what tuples should have been"? Variadic parameter packs don't need to be varargs (in the current sense) so that is one bit of complexity they wouldn't have to eat. I think the only other things ...

5:08 PM

Doug Gregor, Chris Lattner, Joe Groff, John McCall の四人が議論してる・・・。

↑のスレッドの会話を読んだけど、たしかに実行時表現は気にしている(C++のようなテンプレート展開だけの方針は無い前提)けど

4:26 AM

あくまで型パラメータに渡されるメタタイプの表現を配列的なものにするところだけで

4:27 AM

tupleのmapみたいな事をやろうとしたときのクロージャの表現とかは

4:27 AM

直接的な言及はなさそうな気がする

4:28 AM

コアチームがどこまでの事をできるようにするつもりなのか気になるなあ。

4:28 AM

あ、でも、ラトナーがタプルの要素数とか動的に取れないとねとか書いてたな

思ったんだけど、タプルの map 等のクロージャの表現って新しいものを追加しなくても、↓みたいな関数でも同じことになってないかな？ func squares<T: Numeric>(of values: [T]) { values.map { $0 * $0 } }

4:29 AM

このクロージャの型、実行時まで決まらないよね？

確かにそうか。

4:34 AM

掛け算をすることは決まってるけど実際のT　は呼ばれるまで固定できないから、ジェネリックシグネチャを受け取っているはずなのか

うん。タプルの map を実行時に取り扱うやつ、軽くお試し実装できたりしないかなと思ってるんだけど、コンパイラの中身全然わかってないけど、メソッド風構文を採用するならパーサは通ると思うから、 Sema あたりで軽くいじってできたりしないかな？ (edited)

func squares<T: Numeric>(of values: [T]) { values.map { (a) in a * a } }

4:39 AM

// closure #1 in squares<A>(of:) sil private @$s2c17squares2ofySayxG_tSjRzlFxxXEfU_ : $@convention(thin) <T where T : Numeric> (@in_guaranteed T) -> @out T {

4:40 AM

たしかにclosureはジェネリックシグネチャを受け取ってた。

4:45 AM

Sema あたりで軽くいじって

固定長タプルだけなら、.map の型チェックの前に、AST変形かけたらいけるような気もする

4:46 AM

レシーバの型に推論が必要な場合は難しいと思う。

固定長タプルだけなら静的に全部展開できるんだけど

4:46 AM

それだと variadic generics の下請けにならないから

「Tはmapメソッドが呼び出せる」って制約を推論器で扱わないといけない

4:47 AM

けどタプルはnominalじゃないからメソッドが生えてないし、ましてや特別な扱いのメソッドだから

固定長タプルでもサイズ不定のように扱って、↑の [T] の map と同じように扱えないかなぁと。それがあれば、その上に variadic generics 乗せられると思うんよね。

4:49 AM

タプルはnominalじゃないからメソッドが生えてないし、ましてや特別な扱いのメソッドだから

タプルに map 呼び出したときだけ裏口ですり抜けさせるとか、エラーとされたところでハンドルして復活させるとかでできないかな？

タプルに map 呼び出したときだけ

それができるのが、レシーバの型がタプルだとわかってるときってことです。

4:50 AM

例えば、 (1, "hello").map { $0.description }

4:50 AM

↑こういうコードだったら、mapのレシーバが (Int, String) のタプルである事自体が (edited)

うん

この式全体の推論対象として含まれてるから

4:51 AM

裏口にすり抜けさせる前にエラーが出るかも？

その推論の過程でレシーバに対してメソッドを探すよね？そこに裏口を作れないかな？

うーんまあ、この例だったらtupleにはなってるかな。

4:53 AM

まあそれはできそうですね。

レシーバとメソッドの組み合わせを探索するのかな？どちらにしても、そこでタプルと map の組み合わせをパスさせる。

で、まあ、コード変形でやらないんだとしたら

4:55 AM

ASTに対して型付けが終わった状態になるようにして、verifier的なものも、回避するショートカットを差し込んで

4:55 AM

次のSIL生成でやる感じかな。

4:57 AM

固定長タプルでもサイズ不定のように扱って

↑ここが微妙で、「可変長タプル」の内部表現が無いから、SILの式が構築できないような気がする。

これって結局 <T: Numeric>[T] のようなものになると思うんだけど

5:01 AM

さっきの func squares<T: Numeric>(of values: [T]) { values.map { (a) in a * a } } の T が特殊化されないときの [T] のように扱えないかな？

実行時モデルとしてそのように扱う基盤はあると思うけど

5:07 AM

SILコードは基本的に全部SIL型システムで型付けされた命令列として構築されるから

5:07 AM

少なくとも可変長タプルを型として追加しないとどうにもならない気がする

SIL レベルでは追加が必要で、 LLVM-IR にするときに既存の仕組みにできるかもってこと？

5:08 AM

SIL の型システムでは扱えないと。

そうですね。

なるほど。

あーまあ、 [Any] にしちゃえば

それは考えたんだけど、その実装あまり説得力がなさそうだなとｗ

なんか無理やり組み上げられる気もするけど・・・

5:09 AM

まあでも「可変長タプルを追加して固定長タプルをそれにアップキャストする」のと「固定長タプルを [Any] にアップキャストする」のは

5:09 AM

本質的にあまり変わらない気がする。

5:10 AM

の T が特殊化されないときの [T] のように扱えないかな？

↑このレベルの観点ならまさにそういう話なような。

本質的にはそうかもしれないけど、ぎりぎりの緩さで留めておかないと説得力がないかなと。

うーん？仮に実装できたとして、それをもって何を主張したいんですか？ (edited)

Variadic generics are basically some small part static metaprogramming facilities, which means it won‘t scale if you try to build it with existing features as we don‘t have any static metaprogramming features yet (besides property wrappers maybe). Variadic packs (basically variadic values variadic T), are similar to tuples but they are not tuples at all.

5:21 AM

とのことなので、既存の仕組み（かそのちょっとした拡張）の上でタプルと共通化して実現できるよと言えるかなと。

5:22 AM

TMPみたいな方式として導入するよりも、ジェネリクスとテンプレートの関係を考えたら、ジェネリクスみたいに動的にも扱われる仕組みとした上で特殊化もできるという方が Swift に馴染むと思うんだけど。 (edited)

うーん？AdrianさんはC++みたいな静的展開機能を前提に考えてるのかな？

5:26 AM

さっきの「Starting to implement Variadic Generics」のスレだと

5:26 AM

コアチームの人たちはジェネリクスみたいな動的な仕組みを前提に会話してるように見えたけど。

5:26 AM

ラトナー This could allow a more dynamic model for variadics that might fit better into the overarching swift design than the static C++ model.

(edited)

5:27 AM

StaticなC++方式じゃなくて、動的な方式がSwiftの設計の拡張としてフィットするって。 (edited)

5:29 AM

Douglasも At this point you can write something like: struct Tuple<Types...> { } but not do anything with it.

5:29 AM

↑こう書いてるし、これは、可変長ジェネリクスが言語機能にあったら、タプルはそれだけで表現できる　事を言っているので

5:31 AM

うーん、このスレにもAdrianさんは居るんだよな、うーん？ (edited)

謎だね。

Variadic generics are not to make just tuples nice, there are more use cases which cannot be solved through tuples.

こっちが言いたい事なのかな。

5:38 AM

可変長タプルよりも可変長ジェネリクスのほうがより広くて柔軟な機能だから、可変長タプルじゃできないことも可変長ジェネリクスだとできると。

5:39 AM

ただそれはお互いにわかってて（てか、steps to VGなんだから、包含関係はそれいがいありえない）

5:40 AM

VGがある時点で struct Tuple<Types...> でタプルは終わるし。

うーん、前段からのつながりではメタプログラミングでやるんだって思い込みが先にあっての発言なのかなぁと思ったけど、どうなんだろうな。

お悩み相談させてください

自作のグラフ構造を使った計算を行おうとしているのですが，絶望的に速度が出ず悩んでいます．扱う頂点の数はかなり多く（558,661），動的に辺を追加したり外したりする処理を行います．TimeProfiler を見るとほとんどが Set や Dictionary の変更にかかっているようです．同等の処理をしているはずの C++ ライブラリだと一瞬で計算が終わるので，かなり悲しい気持ちです．もし改善のヒントなどあればご教示頂けると幸いです

↓ こちらの main.swift を実行すればすぐみられます． https://github.com/taketo1024/SwiftyMath-knots/tree/graph グラフ構造（Set や Dictionary を組み合わせたシンプルな struct ） https://github.com/taketo1024/SwiftyMath-knots/blob/graph/Sources/Sample/SimpleDirectedGraph.swift グラフ処理部分 https://github.com/taketo1024/SwiftyMath-knots/blob/graph/Sources/Sample/HFKCalculator.swift こちらが高速な C++ のライブラリ https://bitbucket.org/t3m/py_hfk/src/default/hfk_class.cpp C++ のライブラリの方は頂点を std::vector で，辺を std::list で持っているようです．

https://discordapp.com/channels/291054398077927425/291211035438874625/674106280708931594 からこっちにFW

4:39 AM

Swiftの値型はCoWがあってもループを伴うmutating処理などでは極端に遅くなる傾向がある

値型というかコレクションでしょうか？

値型そのものの性質だと認識していますが、今回は特にCollectionですかね

4:40 AM

おそらくなんですけど、 https://github.com/taketo1024/SwiftyMath-knots/blob/graph/Sources/Sample/HFKCalculator.swift#L74 ここでバッファの完全コピーが走ってしまっているのでは。 (edited)

taketo1024/SwiftyMath-knots

Contribute to taketo1024/SwiftyMath-knots development by creating an account on GitHub.

4:41 AM

もう少し下にもループ内のMutatingがありますね

CoW は言語機能ではなく、コレクションがそのように実装されているものだと認識してます。

4:42 AM

言語機能としては、 Existential のときに CoW を使うのはありますが。

モジュール別れてるようなので@inlinableつけていくのも良さそうです。

あー、なるほど。ジェネリクスが特殊化されてないのか。それありそう。

あ、これは同じモジュールか (edited)

あ、そうなのか。

4:44 AM

SimpleDirectedGraph は同じモジュールだけど、 SwiftyMath や SwiftyKnots, SwiftyHomology にジェネリックで特殊化されてないところはないのかな？

4:46 AM

TimeProfiler で見る限りは specialized されてるように見えます．

Set.insertの時間、バッファコピーされてる数値が出ていると思います

4:47 AM

593msはエグい

4:48 AM

てかその下もすごい時間かかってるなw

総量決まってるなら先にreserveCapacityできないですか？

辺は動的につけたりはずしたりするので，予測するのは結構難しそうです… 試しに一律に 800 ぐらいで reserve したら落ちましたw

1

@t.ae reserveCapacity は有効かもしれないけどオーダーまでは変わらないから CoW がうまくいかずにコピーされてしまってる方がありそう。

4:49 AM

そっち（コピー）は O(1) → O(N) になってしまうので。 (edited)

試しにもっと大きい値でガッツリ取ってみるとどうでしょう

@koher 以前書かれていた画像処理のライブラリで似たようなパフォーマンスの問題があったような記憶があるんですが、そのときはどうされたんでしたっけ。

すみません、何も記憶がないです

1

5:01 AM

@Taketo Sano 僕の環境でリポジトリを clone して swift run -c release すると（コンパイル後）一瞬で結果↓が表示されるんですが、これはおかしいですか？ 3_1 j\i -3 -2 -1 0 -1 𝐙 -3 𝐙 -5 𝐙 -7 𝐙₂ -9 𝐙 (edited)

あらっ

あ、ブランチが

それは master か develop branch だと思います。 graph っていう branch がありませんか？

graph じゃないといけないのか

さようでございます

6:35 AM

ただの subscript.getter でめちゃくちゃ時間かかってるんで，単純に巨大な collection は swift に不向きということなんですかね…

GridComplex.Generatorのハッシュ関数とEquatableがかなり重いですねこれ

6:45 AM

https://github.com/taketo1024/SwiftyMath-knots/blob/graph/Sources/SwiftyKnots/GridHomology/GridComplexGenerators.swift#L12-L16 なんでこれでこんなに時間掛かるんだろ…

taketo1024/SwiftyMath-knots

Contribute to taketo1024/SwiftyMath-knots development by creating an account on GitHub.

hash は Int 型の値を一個 combine してるだけなので重いはずはなさそう…

6:52 AM

extension で struct 定義してるからとか？

もしかして、これって複数回呼び出した累計の時間で計測されてます?

多分そうだと思います（あまり TimeProfiler の見方わかってないですが…）

Hasherは1個だけだと使う意味なさそうなので直接hashValue返してもいいかも。

https://github.com/apple/swift/blob/master/stdlib/public/core/Hashable.swift func _rawHashValue(seed: Int) -> Int これを実装しとけばいいんですかね

おお、今の定義ってそうなってたんですね…そうするとそこは原因じゃないか…

7:09 AM

1

7:09 AM

7:11 AM

こんな感じでボトルネックはgraph.connectの中のDictionary.subscriptとSet.insertなんですが

7:11 AM

CoW由来のコピーコストが掛かってる雰囲気のトレースではないんですよね

7:12 AM

Set.insertの40%が参照カウント操作なのは気になる

7:15 AM

forループの対象がSetで、そのSetに対するinsertがconnectの中で生じるから、参照共有されてコピーされる気はしたんだけど、何が起きてるかイマイチわからん

7:16 AM

1

7:17 AM

connectの中のDictionary.subscriptの方は、52% mallocが食ってる。

intoなreduceにすれば改善するとか有りえますかね

むむむ…

reduce

僕にはよくわからん

7:22 AM

この２重ループって

7:22 AM

a in cotargetsとb in targetsをconnectしてるから

graph 関数をパラレルで走らせてるのが関係あったりしますかね？

その時の書き換えは targets[a] << b と cotargets[b] << a だから、かみ合わせがズレてるから同じSetはほぼ操作しないですよね？

7:24 AM

ん、ちがうな

7:24 AM

yとxも出てくるのか

7:26 AM

graph 関数をパラレル

graph()が大本で並列になってる件ですよね、それ自体は関係ないはず

7:26 AM

処理が完全に垂直(?)分割されてるので相互作用しない (edited)

1

x -> y という頂点の組と辺をセットで消すんですけど，その際に a -> y なる全ての a に対して，x から生えてる辺を mod 2 で足す，ということをしてます．

7:28 AM

a, x の両方から繋がってる b は辺を消して，x のみ x -> b となってる場合は a -> b とつなぎ直す，という．

7:29 AM

Generator 型で index されてるのが問題なのかと思って，さっき Int-indexed に書き換えてみましたが，それでも速度は変わりませんでした．

7:31 AM

let A = graph.cotargets[y] ?? [] let B = graph.targets[x] ?? [] for a in A where a != x { for b in B where b != y { if graph.targets[a]?.contains(b) ?? false { graph.disconnect(a, b) } else { graph.connect(a, b) } } }

こういう風に A, B を外に出すのも試してみたけど変わりません…

a -> b とつなぎ直す時の targets[a]とcotargets[b]は、イテレートされてる cotargets[y] と targets[x]とは別のSetだから

7:36 AM

やっぱりコピーは起きない気がするな。

はいー

7:36 AM

そんなに非常識なことをしてるコードじゃないと思うんですけどねぇ…

そうですね

7:37 AM

僕もなんかパフォーマンス頭打ちになったときDictionaryとかSetのこんな感じのプロファイルになった事あって

7:37 AM

参照カウント処理の割合が高くてウームとなった

ウーーーム

7:38 AM

この計算対象は grid-number = 11 に対応するものなんですが，10 の場合は割とすんなり終わるんですよね．

10の場合の11倍ぐらい重い感じ？

main で let G = GridDiagram.load("11n37")! としたのがそれです．

7:39 AM

いえ，３秒ぐらいで終わりますw

7:39 AM

N = 11 になった瞬間にシンギュラリティがw

なるほどｗ

（まぁ N だけで計算量が決まる訳ではないんですが，一つの目安として）

graph() のうち malloc: 23%, retain: 35%, release: 34% (edited)

7:41 AM

N=10の場合のセットアップ教えてもらえますか？

7:42 AM

ん？もう10か

7:42 AM

let G = GridDiagram.load("10_152")!

7:43 AM

10_152　でも全然３分以上かかる。

10_152 は N = 11 のケースです（ややこしいですが）

7:45 AM

11n37 が N = 10 です．

なるほど、そこは逆なのか。

（ 11n とかについてる数字は結び目の交点数というもので，今の N は GridNumber というまた別の数になります） (edited)

7:47 AM

graph() のうち malloc: 23%, retain: 35%, release: 34%

何か謎のオブジェクトが生成＆消滅を繰り返している…？

11n37: malloc: 24%, retain: 27%, release: 32% あんまりかわんないかなあ

7:51 AM

Time profilerの一番下に在る文字列検索のとこに↑入れると、今見てるビューでそれにマッチする関数が何％かわかるんですけど。

7:53 AM

mallocについては、DictionaryやSetの初回か拡張で必要な操作かもしれなくてなんとも言えなくて、 retain/releaseについては、DictionaryとかSetの内部にあるヒープオブジェクトに触る前後な気がします。

なるほどー

7:55 AM

大規模なコレクション操作でいつもパフォーマンスの壁にぶつかってる感じがするので，やはりこの手の処理は Swift でやるべきじゃないのかなー

Swiftのstdlibが作りの問題で遅い説は自分の中でもフツフツとある・・・

7:56 AM

断言できるほど全体像が見えてないんですが。

ぬぬぅ

この謎のmalloc、ストレージ用のメモリじゃなくて、coroutineスクラッチメモリか？ (edited)

1

8:03 AM

この2つの対応が

8:04 AM

↑これのDictionary.Variant.subscript.modifyと NativeDictionary.subscript.modifyのとこ

malloc はどこに対応するんです？

8:05 AM

見方が分かってません

_modify がコルーチンになってて、コンパイラが生成するんですよね。 Variantのほうなら let cocoa と var native

8:07 AM

NativeDictionaryならlet bucket, found var value のため。

8:09 AM

要するに、subscript処理の70%ぐらいが、コンパイラが差し込んでるmallocのせいなんじゃないかと・・・

ふむふむ

8:09 AM

これって巨大な dictionary を作れば簡単に再現できるんですかね．

むしろ大きさは関係ない？

バグレポ出すとして，めっちゃ遅いことを体感してもらうにはめっちゃでかいのを作る必要があるかと思いまして．

そうですねえ N=10 と N=11での振る舞いの違いとの関係もよくわからないけど・・・ (edited)

この計算は計算量が組み合わせ的に増えるので，N が 1 増えただけでボトルネックがめっちゃ強く効いてくることはありうると思います．

なるほど。

とりあえずyield入る前のSwiftでプロファイルするとどうなるんでしょう

入る前は、modify相当のやつは、 materializeForSet っていうアクセサだったんだよね

プロファイルに差が出るんじゃないかと

どっちかかな〜と思っていて 1. materializeForSetのときもmallocしてたから同じ 2. 実はmodify化で性能低下してる、malloc→allocaは最適化を今後実装予定

試しに走らせてみてる感じ

modify見える

いますね

8:18 AM

もっと古いXcodeで走らせないとだめか

coroutineは１年ぐらいは仕込まれてたはず。

8:19 AM

で、バージョン下げすぎるとコンパイルが通らなそう・・・

8:23 AM

バグレポ出すとして，めっちゃ遅いことを体感してもらうにはめっちゃでかいのを作る必要があるかと思いまして．

どういうのが良いんだろうなあ。単純に計算が複雑だから時間がかかるのではなく Swift stdlibのせいで時間が不当にかかってるという事を、主張したい。

8:23 AM

(現状、その事実も厳密に突き止められたとも言えない

巨大Dictionaryと小さいDictionaryを作って、insertの時間に差があるからO(1)じゃなくなってるよっていう報告でどうなんでしょ。

8:25 AM

それともサイズ関係なく遅いのが問題なのか。

サイズ関係ない気がする。

キャパシティの差で如実に差が出てるんですけど、こういうもんでしたっけ

8:30 AM

名前がアレなのはアレ

小さい時は辞書にしない最適化が入ってるかも。

なるほど

要素数が8個とかだったら、ハッシュ値の計算すらしないで

8:32 AM

全探索しちゃったほうが速いというのがある

なんかウォームアップの時間っぽい気がしてきた

@Taketo Sano これC++のやつはどういうデータ構造なんですか？ class Link { int graphsize; vector < vector <Int64> > Generators; vector < vector <Vertex> > Graph; }

8:56 AM

Linkの中にGraphがあるのも2次元vectorなのも謎だ

これは色々と特殊で，

8:56 AM

まず Link は数学用語で，結び目が複数あるやつのことですw

でも、 std::map も std::unordered_map も使ってないから、結構違う構造をしてそう

8:57 AM

Linkはデータ構造の方じゃないのかｗ

ここで現れるグラフは階層構造があって，上から下へ辺が落ちるような形になっています．僕のプログラムで var gens = generators.group{ $0.MaslovDegree }.mapValues{ Set($0) } と分けて，上から順番に Graph に頂点を追加してるのがそれに対応します．

9:00 AM

( MaslovDegree というのがその階層，C++ コードでは MM と書かれている)

あ〜。

とりあえず、単純な subscript set で Dictionary の要素数によるパフォーマンスの差はなさそうです。 https://github.com/koher/swift-dictionary-performance

koher/swift-dictionary-performance

Contribute to koher/swift-dictionary-performance development by creating an account on GitHub.

1

僕のコードの Generator 型に code というプロパティがありますが，これが C++ のコードで Int64 型の Generator と対応しています．

↓を 1 から 10_000_000 まで試した。

 func testDictionary_1() { var dictionary: [Int: Int] = .init(uniqueKeysWithValues: (0..<1).map { ($0, $0 + 1) }) XCTAssertEqual(dictionary.count, 1) let count = dictionary.count measure { for i in 0..<n { let key = i % count dictionary[key] = i + 2 XCTAssertEqual(dictionary[key], i + 2) } } }

(edited)

ふーむ．

あ、いちおう count の assert をしておいた方がいいな。→しました (edited)

入れ子構造？特有の問題なんですかね

ちなみにこれリポジトリをクローンしたあと単純に実行してどれくらい時間かかるプログラムなんですか？とりあえず実行してみてるんですけど全然終わる気配がなくて。。。

なるほど。 C++の方だと階層が1次のキーで、2次のキーが頂点のindex 頂点に対してstd::linkのinとoutが　上からくる辺と下に出ていく辺の、ターゲットの頂点のindexか。

@Kishikawa Katsumi はい，全然終わらないです．C++ のライブラリで対応する計算は1秒とかで終わるので悲しいのです

これって階層とか１つの階層の頂点の数って数量的にはどのくらいですか？

頂点数はトータルで55万ぐらいです．

9:07 AM

階層ごとはちょっと調べてみないとわかりません．

なるほど。

なんかもう少し短い時間で試せるように問題は変えずにデータを減らしたりしたいんですけど、それって簡単にできます？

@Kishikawa Katsumi はい， main.swift で 10_152 と書いてるところを 9_42 とか 11n37 とかに変えるとすぐ終わります．

1

if (*search == *k) { Graph[MM][*j].out.erase( search ); if( *k != target) Graph[MM-1][*k].in.remove(*j); break; } ↑この辺のerase　とか remove が O(N) アルゴリズムなので、オーダーで見ると佐野さんの実装のほうが遥かに速いはずなんですが、そうではないとすると、一つの頂点につながる辺の数自体はたかだか100とかそんなもんなんだろうか。 (edited)

@omochimetaru そうなんですよ！

9:10 AM

それをみて，Swift の方でも Array に変えてやってみたんですが，ゴリゴリ遅くなりましたw

↑のテスト、 N によらず 10万回の subscript set and get （および剰余演算と XCTAssertEqual ）が 0.1 秒くらいなんですけど、絶対値として十分に速いですか？

なんか雑に調べてる感じ、Dictionaryそのものをパッと使ったときの性能としては、Swift.DictionaryもNSDictionaryも優位な差は無いっぽいんですよね

@omochimetaru ちなみに edge のほうは vector じゃなくて list を使ってるんですよね．

@Taketo Sano ほんとだ。listだからこの削除はO(1)　ですね。

でも検索は片っ端からやってるから，そこは結構効いてくると思うんですけどねぇ． (edited)

@koher NSMutableDictionaryと同等のスピードが出ていれば、参照型に対してスペックで劣ってるとは言えない気がしています

9:13 AM

そうか、手早く試すのにNSを入れて見るのがあった

そうかそうか。絞り込み検索のとこが遅いはずですね。

はい

なのに set.contains の方が絶望的に遅いっていう

@tarunon

NSMutableDictionaryと同等のスピードが出ていれば

Dictionaryのほうが内部オブジェクトへのretain/releaseが無駄に発生して時間を食う気がしてるでも簡単なコードだと最適化でそこをスキップしたりしてるかも

9:15 AM

まあハッシュテーブルは計算量は小さくてもいろんなオーバーヘッドがでかくて、問題の規模によっては計算量が大きい実装に負けることはあるんですよね C++のやつと同じデータ構造とアルゴリズムのコードを実装しないと、 Swift stdlibのせいで遅いとは言い切れないですね

そうですねぇ…

あれれ

9:16 AM

これやってて気がついたんですが

9:16 AM

for u in cotargets.object(forKey: v) ?? [] { targets[u]?.remove(v) } ここでArrayのオブジェクト生成する可能性ないですか? (edited)

ただ同じの実装するの結構大変な規模ですね。。SwiftにListねえし (edited)

どんなコードかわからないけど、スタック的に使っているだけなら Array で代替してもパフォーマンス変わらないんじゃないかな？

9:18 AM

キューだとダメだけど。 < Listねえし

いや，間に挿入したり抜いたりします．

↑で書いたとおり O(1) の削除をやってますね

それだと連結リストでも O(N) な気が・・・ < 間に挿入したり抜いたり (edited)

9:19 AM

O(1) の削除は、 Array の末尾追加や削除も O(1) だから

9:19 AM

先頭だけならひっくり返せばいいし、末尾だけならそのままで同じかと思った < O(1) の削除

連結リストは挿入する前後で矢印を入れ替えるだけなのに対して，Array の場合はその先にある奴を丸ごと移動しないといけないから遅いんじゃないかと思います．

9:20 AM

↑これの、途中での挿入削除がある処理。

9:21 AM

あ、挿入は後ろだけかな？

途中のカーソルがあるならいいけど

末尾への挿入はメモリの再配置が発生すると配列でもO(n)になる

カーソルがないから先頭（か末尾）からたどらないといけないから O(N) になる

この計算回数と大きさだとそれなりに再配置発生しそうなイメージはあります

@tarunon 末尾の挿入の1回のオペレーションならそうですが、バッファを増やすときに倍々に増やすので、ならせば O(1) になります。

 // For every j->target, j != source for(list<int>::iterator j = Graph[MM-1][target].in.begin(); j != Graph[MM-1][target].in.end(); j++) { if( !Graph[MM][*j].alive ) continue; // For every source->k for(list<int>::iterator k = Graph[MM][source].out.begin(); k != Graph[MM][source].out.end(); k++) { // Search for j->k. If found, remove it; if not, add it. list<int>::iterator search; for(search = Graph[MM][*j].out.begin(); search != Graph[MM][*j].out.end(); search++ ) if (*search == *k) { Graph[MM][*j].out.erase( search ); if( *k != target) Graph[MM-1][*k].in.remove(*j); break; } if (search == Graph[MM][*j].out.end()){ Graph[MM][*j].out.push_back(*k); Graph[MM-1][*k].in.push_back(*j); } } }

なるほど

↑検索してるところは O(N) になってますね。

連結リストは挿入する前後で矢印を入れ替えるだけなのに対して，Array の場合はその先にある奴を丸ごと移動しないといけないから遅いんじゃないかと思います．

移動のためのコピーが速いか、連結リストで先頭からたどるのが速いかで言えば、たどる方が速い可能性はありますが、係数の差でオーダーとしてはどちらも O(N) ですね。 (edited)

各 k に対して，毎回辺を全部走査してるから遅いはずなのに，

9:24 AM

どういうわけか速い

感覚的には1000個ぐらいだったら

9:24 AM

ループはめちゃ速いですよ

9:24 AM

LinkedListだとメモリ局所性が無いんでループも遅いんでそこは謎・・・

そう、飛び飛びにたどらないといけないから、まとめてコピーの方が速い可能性もあるかなと。

なるほどー

9:27 AM

（帰宅のため一旦抜けます，色々調べて下さってありがとうございます）

@Taketo Sano

それをみて，Swift の方でも Array に変えてやってみたんですが，ゴリゴリ遅くなりましたw

これは、今の SimpleDirectedGraph の中身の実装だけSetからArrayに変えたってことですよね？ (edited)

はい、edge のとこを配列にしました。

了解です。

find して remove

@tarunon

ここでArrayのオブジェクト生成する可能性ないですか?

あるけど、空のArrayって専用の型があって内部最適化されてるからあんまり気にしなかった

Generator は順序をつけることができるので、sortedarray にすれば速くなるかなと思ったりはしました。

>空 naruhodo

```swift for u in cotargets.object(forKey: v) ?? [] { targets[u]?.remove(v) } ```

空 Array の問題はないにしても、 if let で書き換えた方が良さそうな気が。

9:50 AM

ん？てか targets[u]?.remove(v) これコピー発生しませんか？↓になって Set が二重に存在しない？ var ids: Set<Id>? = targets[u] ids?.remove(v) targets[u] = ids (edited)

↑で16:09に貼った画像のとおりで、 connect が最大のホットスポットなんですよね

9:51 AM

そこは、そうならない、subscriptに対するmodifyアクセスになるから。

内部実装をNS使って参照型に書き換えてみたんですけど、速くなったようには見えない。

時間どのくらい変わった？

終わらンゴ

10:02 AM

テストケースは全部通過するのを確認しています。

終わらんケースだと比較にならないっしょ

10:03 AM

@Kishikawa Katsumi はい， main.swift で 10_152 と書いてるところを 9_42 とか 11n37 とかに変えるとすぐ終わります．

↑これで比較すると良いと思う

ok

10:03 AM

そしてプロファイルは強制終了してしまうようになったんですよね

計測は $ time .build/release/SwiftyKnots-Sample が良いと思う

あーなんか

^ 同じことやったんですけど変わらないかむしろ遅くなる感じがあります。

ですよね

そして要素が少ないとたぶん問題が変わるような印象。

10:05 AM

遅いのってメモリアロケーションが大量だからじゃないかな？

そこがわからない 10_152 が11n37に比べてどのくらい爆発的に問題を膨らませているのかが・・・

^ データ構造もあると思いますけど、要因の１つとして。

可能性はありますね。

みてると元のコードは15GBくらいメモリ使う（たぶんもっと増える）ので。

マジか。

NSSetとかにすると減るんだけどそれでも7GBくらい使ってた。

10:07 AM

なんかリニアに使うメモリが増えてくように見えました。

10:08 AM

↑シングルスレッドに改造してて1.57Gだ。たしかに4並列ならそのくらいになってそう。

10:09 AM

確かにそこまで行くとmallocが重くなっちゃってあちこち重くなるのがありそう

今のケースに近いような [Int: Set<Int>] に変えて insert するようにしたら、 Set の N が大きくなると激遅に・・・。

 func testDictionary_10_000_000() { let count = 10_000_000 var dictionary: [Int: Set<Int>] = .init(uniqueKeysWithValues: (0..<100).map { ($0, Set(0..<count)) }) XCTAssertEqual(dictionary.count, 100) XCTAssertEqual(dictionary[0]!.count, count) measure { for i in 0..<n { let key = i % 100 dictionary[key]?.insert(i) XCTAssertTrue(dictionary[key]!.contains(i)) } } }

ほお

Dictionary の要素数は 100 固定で、 Set の要素数だけ変えてる。

10:35 AM

やっぱコピー走ってないかな？

コピーが走ったかどうか確認する方法なにかあるかな。

dict.remove -> insert -> dict.add にしてみる

おぉ

お、速くなった気がする

https://github.com/apple/swift/blob/master/stdlib/public/core/NativeSet.swift#L230

https://gist.github.com/omochi/29f5aae812d4556c96ab289ee48fa937

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

10:39 AM

Setの場合、ensureUniqueってメソッドの中でcopyまたはcopyAndResizeが呼ばれるから

10:40 AM

これにブレークポイントを貼ることができればわかりそう

（みんなすごい）

直感通り#beginner-help-archived で収まらない解決フローだったw

1

10:41 AM

Swiftの関数はマングル済みの文字列でSymbolicBrakepoint貼れますよ (edited)

https://github.com/omochi/SwiftyMath-knots/tree/ptr とりあえず、グラフの実装をポインターベースに書き換える実験をしてみましたシングルスレッドで、 11n37が 5.48sec から 3.02secになった。

omochi/SwiftyMath-knots

Contribute to omochi/SwiftyMath-knots development by creating an account on GitHub.

10:42 AM

10_152はそもそもの元のバージョンが25分待っても終わらなかったので比較できてない。

10:43 AM

↑このバージョンだと、余計なコピーの心配は多分無いのと、subscriptアクセスの回数はかなり減らしてる

わーぉ。10_152 は改善版でも終わらないですか？

あれ？変わらなかった・・・。さっきのはなんだったんだ？？

いま13分ぐらい経過だからなんとも言えない > 10_152

10:44 AM

@tarunon > Swiftの関数はマングル済みの文字列まずlibSwiftCoreからそれっぽいの探すやつかｗ

ちょっとまってて

デバッガシンボルトリガーでコピーが発生したらprint("copy!!")とかやってみたらいいのか。

（C++ のライブラリだと数秒で終わるんですよね…）

そのオーダーの高速化はできてないですね〜

10:47 AM

数秒レベルになると、ライブラリの性能とかの次元じゃないと思うんで、なんか理由がありそうですけど・・・

うーむ…

ほい ss10_NativeSetV12ensureUnique02isD08capacityS2b_SitF

10:49 AM

ん

10:49 AM

なんか余計なもんひっついてるな

ensureUniqueのほうじゃなくてcopyだね

copyねおk

copyとcopyAndResizeの両方が居る、どっちに行くかは状況によるから。 (edited)

_$ss10_NativeSetV13copyAndResize8capacityySi_tF _$ss10_NativeSetV4copyyyF

10:50 AM

ほい

10:50 AM

思ってたより素直なマングルだった

で、これを、さっきのkoherのコードで試してみると

10:56 AM

insertももらえます？

10:56 AM

あー

10:56 AM

profilerでもわかるかな

11:01 AM

なるほど specializeされてるからシンボル違った

11:05 AM

あとインライン化されてたりもする

11:06 AM

16.00 ms 45.7% 7.00 ms specialized _NativeSet.insertNew(_:at:isUnique:) _$ss10_NativeSetV9insertNew_2at8isUniqueyxn_s10_HashTableV6BucketVSbtFSi_Tg5

(edited)

ふむ

11:06 AM

あーそうか

11:06 AM

nmをgrepするとはやいと思います

↑これで止めてからアセンブリステップ実行した感じでは、コピーのフローには入ってない気がした

[omochi@omochi-iMac-PC43 Release]$ nm Sandbox_20200204195103 | grep NativeSet 0000000100001b70 t _$ss10_NativeSetV13copyAndResize8capacityySi_tFSi_Tg5 0000000100001970 t _$ss10_NativeSetV4copyyyFSi_Tg5 0000000100001e50 t _$ss10_NativeSetV6resize8capacityySi_tFSi_Tg5 0000000100001870 t _$ss10_NativeSetV9insertNew_2at8isUniqueyxn_s10_HashTableV6BucketVSbtFSi_Tg5 [omochi@omochi-iMac-PC43 Release]$ nm Sandbox_20200204195103 | grep NativeSet | swift demangle 0000000100001b70 t generic specialization <Swift.Int> of Swift._NativeSet.copyAndResize(capacity: Swift.Int) -> () 0000000100001970 t generic specialization <Swift.Int> of Swift._NativeSet.copy() -> () 0000000100001e50 t generic specialization <Swift.Int> of Swift._NativeSet.resize(capacity: Swift.Int) -> () 0000000100001870 t generic specialization <Swift.Int> of Swift._NativeSet.insertNew(_: __owned A, at: Swift._HashTable.Bucket, isUnique: Swift.Bool) -> ()

特にcopyは走ってない気がしますね

11:16 AM

こういう実験をして、insertNewは止まるけど、copy系は止まらなかった。

あ、そうだ。_を消さないといけないのもあった。すみません

Xcodeのシンボリックブレークポイントは、部分一致でいけますよ。

1

_NativeSet だけとかだと、引っかからない

11:25 AM

_NativeSet.insertNew だと、普通のメソッドは引っかかるんだけど、 specializedされた方は引っかからなかった。

11:26 AM

OSSツールチェインをシンボルと一緒に入れて使うと、specializedなのもいける。

ほう。なんでだろ・・・

シンボル入れてるとinline化されててもブレークポイントが効く。

今って遅い原因が COW が走ってしまってるからかどうか検証してる感じですか？（ついていけてない）

そうですね　ブレークする方法がわかったから

12:49 PM

元のコードでcopyが起きてるか、起きてないか、検証できる道具を得た

12:50 PM

ただまだ未確定ではあるけど、個人的にはcopyは起きていなくて他の処理が重い気がしています

12:57 PM

あ、あと、岸川さんの指摘したメモリ使いすぎはある気がします

12:58 PM

使用量が多い状態で小さいアロケートが遅くなるのかどうかは知らないですけど・・・

12:59 PM

C++実装と計算手順が対応するようにコードを書いてみて、どういう処理が何倍ぐらい遅いのかってのを突き止めていかないとわかんない気もしてます。

前に作った自作 LinkedList を使ってみるのは試してみようと思います。

@Taketo Sano cppのhfkdemo.cppに、10_152を与える方法を教えてくださいー GridDiagramData.swiftから取れそうだけど・・・

1:36 AM

あと、11n37だと速すぎ、10_152だと重すぎるので、その間ぐらいの入力が欲しい・・・

昨日の僕の検証はあやしかった気がします。ちゃんと確かめたいけどちょっと時間がなく・・・。 (edited)

ありがとうございます，少々お待ちください．

とりあえずSwiftyMathのExtensionsで定義されてるAPI全部に@inlinableを付けるとヒープアロケーションがガッツリ減って、11n37が~~12秒台~~9秒台から7秒台くらいになる。 (edited)

2

https://bitbucket.org/t3m/py_hfk/src/default/ こちらの python package をインストールした上で，

from hfk import * D = HFK([10, 9, 8, 7, 6, 5, 4, 2, 1, 3, 0], [7, 5, 6, 4, 2, 3, 1, 0, 8, 10, 9], "10_152") D.HFK_ranks()

とやると計算できます．

hfkdemo.cppを直接触ってるので

2:22 AM

 int m, a; //12n_679 //const int gridsize = 13; //int black[13] = {5,3,1,2,0,12,11,8,10,9,7,6,4}; //int white[13] = {9,6,5,4,3,1,0,2,12,11,10,8,7}; //Conway Mutant C_{2,1} const int gridsize = 11; int black[11]={10,9,3,4,5,8,6,7,1,2,0}; int white[11]={6,1,7,0,3,10,9,2,4,8,5}; //const int gridsize=12; //int black[12] = {4,1,3,7,8,9,11,2,10,6,5,0}; //int white[12] = {11,5,0,10,1,7,8,4,3,2,9,6};

2:23 AM

"10_152": {"X": [10, 9, 8, 7, 6, 5, 4, 2, 1, 3, 0], "O": [7, 5, 6, 4, 2, 3, 1, 0, 8, 10, 9]},

おぉw

2:23 AM

それです，X が black で O が white です．

X が　black で、 O が white になればいいのか。

gridSize は配列の長さです．

2:24 AM

Link::Link(int gridsize, int *black, int *white, int (*Progress)(const char *, int), bool quiet) Progress は NULL でいけると思います． (edited)

HFK^ ranks: 0 0 0 0 0 0 1 1 0 0 0 0 0 3 3 0 0 0 0 0 3 3 0 0 0 0 0 3 2 0 0 0 0 0 3 3 0 0 0 0 0 3 3 0 0 0 0 0 1 1 0 0 0 0 0 0

2:25 AM

↑結果のコレと

おぉ，それです

[(3, 3, 1), (1, 1, 68), (2, 2, 12), (0, 0, 244)] ↑これの対応は？

これはちょっと説明が難しいです… 配列の要素 (i, j, n) は (i, j) 成分に n が入ることが対応するんですが，j >= 0 の部分だけ計算していて，さらに色々と調整をして j < 0 まで広げたものが，上に表示されてる表です．表だけだと (0, 0) がどこにあるかわからない形になってます (edited)

1

あと、SwiftyKnotsから並列性を消したくて(途中過程の固定のため) Arrayのparallel系のextensionと、Matrixの中にあったconcurrentPerformを潰したんですけど、まだ実行のたびに結果が変わるので、あとどこにありますかね

並列処理ですか？

はい。あと、乱数って使ってますか？

乱数は使ってないはず…

2:28 AM

並列処理もだいたいそれらを経由してるはずです．

ふむ

上の配列だと，例えば (3, 3, 1) は (i, j) が最大のとこですが，その点における値 1 と，表の右上の数は一致します． (edited)

なるほど。

僕の計算は，C++ のソースにある ComputeMOSRanks を計算したとこまでになってます．このあと ComputeHFKRanks に対応する計算をすると，同じ結果が得られるはずです．

計算してる内容が全くわからないけど、実行のたびに出力が違うのは、正しい挙動なのですか？

それは間違いなく正しくないです，僕のやつではそうなってないと思いますが，一応確認します．

2:32 AM

MOS は情報が無駄に多すぎるので，それを右上から順番に削減していって， j < 0 の部分に鏡映させる感じのことをします．

2:33 AM

for(i=1; i <= gridsize-1; i++) (*HFK_Array)(m-i,a-i) -= (*HFK_Array)(m,a)*Binomial(gridsize-1,i); } }

2:33 AM

この辺がその処理

HFK^ ranks: 0 0 0 0 0 0 1 0 0 0 0 0 3 0 0 0 0 0 5 0 0 0 0 0 7 0 0 0 0 0 5 0 0 0 0 0 3 0 0 0 0 0 1 0 0 0 0 0 0 C++の方に11n37を入れてやったら↑が出てきたけど、 [(3, 3, 1), (2, 2, 12), (0, 0, 244), (1, 1, 68)] ↑(3,3,1)の1が右上にあるのでOKということかしら。 12, 244, 68は表には直接出てこないけど。

2:36 AM

あ〜そうか、実行結果が一定にならないのは、Dictionaryをfor-inしてる場所があるのかもな

はい，11n37 は gridNumber N = 10 で，(3, 3) のところは 1 で一致していて，(2, 2) は 12 - 1 * (N - 1) = 3 で OK，(1, 1) のとこは 68 - 1 * (N - 1)(N - 2)/2 - 3 * (N - 1) = 5 で OK, ... という感じであってそうです． (edited)

2:37 AM

二項係数 nCk の分だけ右上から左下に向けて増殖してくので，それを差っ引くと正しい結果が出てきます．

2:38 AM

(*HFK_Array)(m-i,a-i) -= (*HFK_Array)(m,a) * Binomial(N-1,i); これがそれです．

実行のたびに出力が違う

あ、配列の要素順が違うだけだ。

244のところは 244 - 5x9 - 3x36 - 1x84 = 7か。

2:52 AM

let gens = generators.group{ $0.AlexanderDegree } ↑ここで戻る辞書をイテレートする順番がシャッフルされるのかな？

1

11n37が12秒台から7秒台くらいになる。

12秒台ってのは悪いサンプルだった。@inlinableの効果は9秒台だったのが7秒台になるくらい。

 let gens = generators.group{ $0.AlexanderDegree } let d = GridComplex( type: .tilde, diagram: gridDiagram, generators: generators ).differential let alexs: [Int] = gens.keys.sorted() let H = alexs.flatMap { (i) -> [(Int, Int, Int)] in let gens = gens[i]! return self.graph(generators: gens, differential: d) .vertices .map{ $0.MaslovDegree } .countMultiplicities() .map{ (k, n) in (k, i, n) } } print(H)

1

2:54 AM

これで実行結果はいつもおなじになった。

2:58 AM

MOS ranks for non-negative Alexander grading: 0 0 0 0 0 0 1 0 0 0 0 0 12 0 0 0 0 0 68 0 0 0 0 0 244 0 0 0 Link.init(..., quiet=false) にしたら↑が出た

おぉ，それは同じ結果ですね！

3:15 AM

本当にそこまでやって頂いて感謝です．

3:16 AM

はい，配列の順番が異なるのは .group で Dictionary にしてるためですね．本当はこの後の処理も書いてくつもりだったのですが，計算があまりに遅いのでこの段階のものでご相談をした次第でありました

@Taketo Sano https://gist.github.com/omochi/ed7e3f3a1e20cc1caeb38e573de5fc2a

3:22 AM

↑よくわからないので質問を書きました (長くなったのでgist

なるほど，計算の範囲がそもそも違う！？

3:47 AM

あ，いや，あってるはずです．この計算は AlexanderDegree ごとに分割することができて，僕の計算ではグラフが大きくなりすぎないように AlexanderDegree 0〜3 を分けて計算しています．CPP の方は一個のグラフにまとめて突っ込んで計算していますね（連結成分が４つあるはず） MaslovDegree の範囲も，CPP の方は MM = 13〜25 の範囲で計算がされてますが，僕のプログラムでも alex = 0 で k = -7〜5 の範囲で計算をしていて，index のつけ方が違うだけで同じ計算をしているはずです．

3:48 AM

（もともと僕の計算も一個のグラフに突っ込んでいたのですが，それだと dictionary が大きくなりすぎて遅いのかな？と思って alex ごとに分けた，という経緯があります）

3:49 AM

MaslovDegree が表における横軸，AlexanderDegree が縦軸に対応してます．AlexanderDegree ごとに分割できるという事実は，表を横に分割して行ごとに計算できるということに対応しています．

3:55 AM

HFKCalculator.run() を次のように書き換えると，CPP のと同様に Alex ごとの分割がなくなるはずです：

public func run() { let d = GridComplex( type: .tilde, diagram: gridDiagram, generators: generators ).differential let H = self.graph(generators: generators, differential: d) .vertices .map { x in [x.MaslovDegree, x.AlexanderDegree] } .countMultiplicities() .map{ (deg, n) in (deg[0], deg[1], n)} print(H) }

(edited)

ふむふむ

self.graph 以降は，グラフに残った各頂点 x に対して，(x.MaslovDegree, x.AlexanderDegree) を対応させて，その個数を数え上げて表にするということをしているだけです．

4:00 AM

コードを改善しましたw

@Taketo Sano 最終的に扱う頂点数は同じっぽいんですが、エッジ生成の挙動が結構違うようです。 https://gist.github.com/omochi/fca8a7dc1490cfd04cf5d725e6b5bf1d

knots-memo-2.md

GitHub Gist: instantly share code, notes, and snippets.

なるほど…！そこまで見て頂いて恐縮です

‍♂️

（いまじっくり読んでます）

5:34 AM

とりあえず二つのコードの間で、 MM = k +20 という対応になっていて、僕のコードでは頂点がない部分をスキップするようにしているので、 CPP の方で 0 本しか生成されない頻度については無視していいファクターなはずです。

5:34 AM

辺生成の総本数が違う理由は気になる… (edited)

ふむふむ

たぶん分かりました、CPP の方は alive = 0 の vertex に対しても辺を（無駄に）生成してるっぽいです…

5:49 AM

恐らく BuildEdges に if(!Graph[MM][index]) continue; を挿入すると、辺の生成総数は一致すると思います（そして計算もより速く…） (edited)

今、もっと、決定的な差が、発見できました。

お

しょうしょおまち

ドキドキ

knots-memo-3.md

GitHub Gist: instantly share code, notes, and snippets.

6:07 AM

検索の実行回数が60倍違います。

6:07 AM

検索対象のサイズも10倍ぐらい違う。(ただこれはSetを使うことで影響を消せてるかも (edited)

6:12 AM

を挿入すると、辺の生成総数は一致すると思います（そして計算もより速く…）

これやってみました。結果を、memo-3のコメント欄に追記しました。かなり一致度が高くなりました！

6:13 AM

まだ1000本ぐらいC++のほうが多いけど7万というオーダーは揃った。

遅くなりました、今から確認します。

間違ったことを書きました

‍♂️

まだ仮説に過ぎませんが，実は edges に順序がついてるのが本質的に効いてるのかもしれません．僕のコードでは x = source に対して，y = target をその targets の中の anyElement として選んでいますが，CPP の方は target = Graph[MM][source].out.front() と最初のものを選んでいます．辺を取り除くたびに残った頂点たちから生える辺はより密になって行きますが，first から選ぶことで生えてる辺の個数が少ない頂点を選んでいるのかもしれません… もうちょっと考えてみます． (edited)

8:54 AM

その点以外は，使ってるデータ構造の違いしかなく，検索の総数に違いが出る理由はないように見えます…

9:00 AM

とりあえず言語の違いではなく，僕の実装がクソだというところに原因がありそうです…！（結果的に beginner だったということになりそう

）

9:06 AM

@omochimetaru この計算は，11n37 に対するものですか？

はい、そうです > 11n37

9:09 AM

実験用のコードを共有しましょうか？

大丈夫です，とりあえず searchCount で見て見ます！

9:14 AM

なんでこんな違いが出るのかサッパリ分からない

ｗｗ

9:15 AM

なんか処理の進め方（yの選び方？）によって、後々の処理量が大きく変わるような

9:15 AM

そういう雰囲気があるけど

9:15 AM

僕はそもそものやってる事が全くわからないので全然イメージがつかない・・・ (edited)

edge を Array にして first を取り出すようにしてみたところ，検索数が 300万 → 100万ぐらいに減りましたが（それだけでも結構驚きですが），CPP の方は数万ですもんね…

9:17 AM

何かもっと本質的な無駄をしてしまってる気がする

9:17 AM

しかしそれがさっぱり分からない

それと、C++ではMM=16から=23 の以外のケースでは searchCount = 0 がたくさんあるのも気になります。

9:18 AM

AlexanderDegreeで4つに分割できるって話だったんで、

9:18 AM

C++の方でも、あと3つはsearchCount=1が出てきそうな気がするんですけど。

確かに

MM=23から16にかけての処理は、連鎖的に何か影響を与えて削減されているのだとしても、 23-16と他のAlexになってるグループはその影響をうけないと思うから、また同じ条件から始まるはずと言うか。 (edited)

(23 - 16 + 1) = 8, (4 - (-5) + 1) = 10 の差は何かということですよね？

たしかに、そこも違うし

9:21 AM

@@@ loop=13, alex= 1, k= 4: searchCount= 5, size= 50, ave= 10, max= 12 allSearchCount= 3653463 @@@ loop=14, alex= 1, k= 3: searchCount= 258, size= 3364, ave= 13, max= 24 allSearchCount= 3653721 @@@ loop=15, alex= 1, k= 2: searchCount= 3075, size= 45772, ave= 14, max= 44 allSearchCount= 3656796 @@@ loop=16, alex= 1, k= 1: searchCount= 11211, size= 233691, ave= 20, max= 72 allSearchCount= 3668007 @@@ loop=17, alex= 1, k= 0: searchCount= 11653, size= 297422, ave= 25, max= 65 allSearchCount= 3679660 @@@ loop=18, alex= 1, k=-1: searchCount= 3974, size= 56627, ave= 14, max= 38 allSearchCount= 3683634 @@@ loop=19, alex= 1, k=-2: searchCount= 429, size= 2535, ave= 5, max= 13 allSearchCount= 3684063 @@@ loop=20, alex= 1, k=-3: searchCount= 10, size= 20, ave= 2, max= 2 allSearchCount= 3684073

9:22 AM

alex=1のk=4..-3の分のsearchCountはC++の方だと(MM=いくつのところだろう？)0しかないし。 (edited)

とりあえずこれは僕の実装に問題がある話な気がするので，こちらのチャンネルからは撤退した方がいい気がしました．みなさん色々とアドバイスをくださりありがとうございます

‍♂️

9:23 AM

絶望のあまり「こういう処理は Swift でやらない方がいい」などと口走ってしまってすみません

‍♂️ まずは自分を疑わねばなりませんね

(edited)

そうですね、とりあえず、現状だと言語の差よりロジックの差が支配的なようです。個人的にはひとまずそれが示せてよかった。

1

辺が張られる最も簡単なケースが 5_1 で，すでに両者に違いが見られました： theirs:

14: (V, E) = (1, 0) 0 searches 13: (V, E) = (21, 77) 66 searches 12: (V, E) = (42, 88) 32 searches 11: (V, E) = (15, 45) 0 searches 10: (V, E) = (6, 12) 0 searches 9: (V, E) = (1, 1) 0 searches

mine:

0 : (V, E) = (1, 0) 0 searches -1 : (V, E) = (21, 77) 79 searches -2 : (V, E) = (42, 88) 140 searches -3 : (V, E) = (15, 45) 82 searches -4 : (V, E) = (6, 12) 5 searches -5 : (V, E) = (1, 1) 0 searches

(edited)

おお！しかも結構な差が出てる

明らかにもっと早くこういう検証をしとくべきでしたね… アルゴリズムは間違ってないという思い上がりが…

http://katlas.org/wiki/5_1

5 1

張られてる辺の数は一致してそうです．

5-1いいかたちだ

Build Edges: 13 0 -> 34 0 -> 47 0 -> 0 0 -> 1 0 -> 2 0 -> 3 1 -> 48 1 -> 0 1 -> 4 1 -> 6 1 -> 5 2 -> 43 2 -> 27 2 -> 7 2 -> 8 2 -> 5 3 -> 49 3 -> 1 3 -> 4 3 -> 9 3 -> 10 4 -> 44 4 -> 28 4 -> 7 4 -> 11

こういう感じでデバッグしてきますw

12:53 PM

こうやるしかないw

やはり頂点や辺に順序がついてることが本質的なようです…！ (edited)

x -> y を選択する際に， a -> y なる a が最も少ない y を選ぶようにしたら 10_152 の計算が完了しました…！

1

2:13 PM

あっ

2:13 PM

すいません，これ @omochimetaru さんに DM 送ってるつもりが思いっきり #swift に投稿してました

2:15 PM

アホ丸出しですいません

‍♂️

おお～

6:52 AM

@norio_nomura toolchainをdebug symbolと一緒に入れてsymbolic breakpointを貼って見るやつ、確かにspecializeされたシンボルも含まれたけど、おそらくstdlibに含まれるやつだけで、アプリ側で作られたものはヒットしなかった。

$ss10_NativeSetV9insertNew_2at8isUniqueyxn_s10_HashTableV6BucketVSbtF11SwiftyKnots11GridComplexV9GeneratorV_Tg5 (generic specialization <SwiftyKnots.GridComplex.Generator> of Swift._NativeSet.insertNew(_: __owned A, at: Swift._HashTable.Bucket, isUnique: Swift.Bool) -> ())

などがヒットしてない

7:08 AM

そして、COWのコピーを発見した

7:09 AM

7:10 AM

ブレークしたいタイミングを制限するために、こんな方法を発見した↑

7:11 AM

あ〜、↑のcodomain.remove　の内部でのコピーは、ループのホットスポットではないから問題ないかも。

アプリ側で作られたものはヒットしなかった

ほんとだ。 (edited)

8:35 AM

lldbでbreakpoint set -r NativeSet.insertNewとすると、アプリ側で作られたものにもヒットする。

8:37 AM

(lldb) breakpoint set -r Generator.*NativeSet.insertNew Breakpoint 15: 2 locations. (lldb) b Current breakpoints: 15: regex = 'Generator.*NativeSet.insertNew', locations = 2, resolved = 2, hit count = 0 15.1: where = SwiftyKnots-Sample`generic specialization <SwiftyKnots.GridComplex.Generator> of Swift._NativeSet.insertNew(_: __owned A, at: Swift._HashTable.Bucket, isUnique: Swift.Bool) -> () at <compiler-generated>, address = 0x0000000100009030, resolved, hit count = 0 15.2: where = SwiftyKnots-Sample`generic specialization <SwiftyKnots.GridComplex.Generator> of Swift._NativeSet.insertNew(_: __owned A, at: Swift._HashTable.Bucket, isUnique: Swift.Bool) -> () at <compiler-generated>, address = 0x00000001000bdf60, resolved, hit count = 0

8:39 AM

Xcode GUIのBreakpoint navigatorには表示されないけど。

 -r <regular-expression> ( --func-regex <regular-expression> ) Set the breakpoint by function name, evaluating a regular-expression to find the function name(s).

1:44 AM

できた。

1:46 AM

うーん？XcodeのGUIのsymbolicってのはどのモードなんだろう

1:46 AM

help breakpoint set を見たけどよくわからなかった

たぶん-n

 -n <function-name> ( --name <function-name> ) Set the breakpoint by function name. Can be repeated multiple times to make one breakpoint for multiple names

(edited)

ふむ。試してみたら同じ結果が出るな

https://github.com/apple/swift/pull/29775

This will be used for compiler-driven type erasure

[Parse] Add an attribute for typeEraser. by hborla · Pull Request #...

This will be used for compiler-driven type erasure for dynamic replacement of functions with an opaque return type. For now, just parse the attribute and ignore it.

hborla@apple.com

7:37 AM

Appleじゃん

これを宣言しておくと、existentialを作るとtype erasureになる、とかかしら。

class AnyP: P1 {} @_typeEraser(AnyP) // okay protocol P1 {}

7:37 AM

テストコードがちょっと謎、attributeテストだけだからかな。

テストケースを見る限りは実装はユーザーサイドで…というように見えるんですよね。

P1 の erasure として AnyP を自動定義するんじゃない？

struct AnySequence: Sequence { ... } @_typeErasure(AnySequence) protocol Sequence { ... } ってことか。

むむ・・・？

これをやると、Sequence の

7:40 AM

Existential が作れるようになるが実体は AnySequence

erasureがprotocolに対して1つに定まっちゃうのがなんか変な感じ

ってのが tarunon 予想ですよね？

ですです

7:40 AM

アトリビュートの宣言位置から想像出来るのはそういう機能

This will be used for compiler-driven type erasure for dynamic replacement of functions with an opaque return type.

with ORT がよくわからん

タイトルだけ見ると、erasureの実装を埋めるCodable的な機能を予想したんですが、テストケースは違うようだった。

ORTの抽象表現として使うって意味かしら？？

7:41 AM

最初はORTのruntime representationを再利用してtype erasureを提供するって意味かと思ったんだけど逆かもしれない

7:42 AM

そうすると、ORT の generic ABI representation が AnySequence になるから

7:43 AM

既存のStdlibのAnySequenceを返してる関数が、 some Sequenceを返すAPI定義にアップグレードしつつも、既存のAnySequenceを返す実装とABI互換性が保てる。

@omochi Yes, the spelling is intentional. The type eraser is the type that implements type erasure.

type erasureは型消去というパターンの事で、それを実現するための型消去器(とでも言えばいいのか)の事を type eraser と呼ぶらしい。 (edited)

つまり、 AnySequence は type erasure ではなく type eraser ってことね。

そう。

@swift-5.1.5 print(#file)

<stdin>

昔って #file でフルパスがとれてたような気がしたんですが気のせいですっけ？

つい最近かわりましたよ

9:32 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md

https://forums.swift.org/t/manifesto-interoperability-between-swift-and-c/33874

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

そうだったのか。知りませんでした。ありがとう。

1

9:37 AM

@swift-5.1.5 print(#filePath)

exit status: 1 with stderr:<stdin>:1:7: error: use of unknown directive '#filePath' print(#filePath) ^

これってもう実装されてて #filePath はまだ実装されてないってこと？？

9:38 AM

というか、 5.1.3 時点ですでに絶対パスじゃなくなってるような・・・。

詳細な進捗は追ってなくてわからないです

まだレビュー中では。

ステータスみるとそうなんですけど、実際実行してみたらすでに絶対パス返ってこなくないですか？僕のローカルは 5.1.3 です。

~~ソースファイルがカレントディレクトリにある場合はファイル名だけになる~~のですね、知りませんでした。 (edited)

あいや、正確にはコマンドラインでコンパイラへ渡されたパスが使われるのか。

あそうだったのか、常に絶対パスに直されるものと思い込んでいた

sh-session $ pushd (mktemp -d) $ echo 'print(#file)'>a.swift $ swift a.swift a.swift $ swift ./a.swift ./a.swift $ swift (pwd)/a.swift /var/folders/kt/2mwy9b_56_7993x190pl_1fh0000gn/T/tmp.3q2Yqu5G/a.swift

guard let URL = URL(string: "\(baseURL)api/v0/tsdb/latest") else { fatalError() } ^ は書けるけど let URL = URL(string: "\(baseURL)api/v0/tsdb/latest")! ^ とは書けなかった。Variable used within its own initial value

確かにoptional bindingはshadowingで特別な処理が挟まってそうですね

3:51 AM

let URL = Foundation.URL(string: "\(baseURL)api/v0/tsdb/latest")! これなら許されるはず (edited)

一貫性が無くて気持ち悪いですね。

おお、右辺をFQNにする手があるのか

[Manifesto] Interoperability between Swift and C++

Swift provides ergonomic interoperability with C (How Swift Imports C APIs), Objective-C (Importing Objective-C into Swift, Importing Swift into Objective-C), and Python ([1], [2], [3]). Interoperability between Swift and C++ has been previously discussed on the forums ([1], ...

1

6:56 PM

かつてAppleでSwiftのstdlibの主要開発者であったDmitri。今はGoogleにいてしばらくclangdの開発をしていたのですが、最近はSwift C++ interoperability をやっているようです。まだ読めてないけど、Manifestとかすごい真面目にかいてる。

半分まで読んだけどやはりめっちゃ考えることありますね。思ってたののさらに３倍くらいあるって感じだ。

C++のNamespaceを空のSwift Enumにマッピングする（お、いけるんちゃう？）、でも細かいこと考えていくとハックが積み上がるからいっそC++を使うとき限定の言語機能を導入してもいいんじゃない？っていうところはそれでいいんだろうかという感じもするが、どうなんかな。

C++ manifesto今日読もうと思ってた元々Appleに居たんですね

長かったけど軽く読んだ・・・

2:50 AM

参照型と右辺値参照型のマッピングは結構悩ましいですね

2:51 AM

テンプレートは基本的に事前特殊化を前提にいろんなバリエーションを検討してある感じだった。

2:53 AM

それでユースケース対応できるのかイマイチ想像しきれない

↓これ記法混乱してない？ void じゃなくて func では？ // C++ header imported in Swift. void printInt(_ value: UnsafePointer<Int>) https://github.com/apple/swift/blob/4e12db450677d7c10b9dbfa9b1aa576385b9cd21/docs/CppInteroperabilityManifesto.md#const-reference-parameters

https://swift.org/blog/argument-parser/

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

ｗｗ　ほんとだ。

3:17 AM

俺も一個typo見つけたんだよな

その直後のコードも混乱が。

インラインレビューってレビュワー指定されてないとできないんだっけ？

3:21 AM

スレッドに書き込んじゃった。

どうだっけ？権限にもよるのかな？

void caller() { のミスが複数箇所あるからこっちの件はコメント欄だと伝え漏れが出そうですね。

PRにしてみた。 https://github.com/gribozavr/swift/pull/1/files

PRのブランチに対するPRだ。

普通にdiffへコメント付けられない？ https://github.com/apple/swift/pull/29880/files

あれ、ほんとだ。[+] ボタンありますね。

3:44 AM

さっき見ててわからなかったんだよな。

3:44 AM

あ、Rich Diff　モードだとできないのか。 (edited)

3:44 AM

Source Diffモードだとボタンが出た。

3:45 AM

やり直した。

あー、それだとわざわざ PR にせずコメントの方が良かったかな・・・。

11:44 PM

コードサンプルのシェルプロンプトが > なのが微妙に分かりづらいな

これはもう別物だ

https://forums.swift.org/t/se-0279-multiple-trailing-closures/34255

6:07 AM

multiple trailing closureのレビューが来た。優先度高いしSwiftUI圧を感じる。

SwiftUI圧w

去年よくわからん機能が優先してゴリゴリ進められてるな〜と思ったらWWDCあけてみたら全部SwiftUI関連だったので

6:09 AM

SwiftUIの書き心地に関連する機能は優先度が高いと思っている

はたして言語機能がDSLのために拡張されていくのは望まれる事なのかどうなのか...

6:09 AM

macroいれてそっちでやれと思わなくもない

一応一つ一つのdiscussionはSwiftUIと独立して価値が合意されてるんですけどね。

けど、scalaの最近のmacro非互換みてるとうーんとも思う

macroは良くないと思う。

6:10 AM

自由度が高すぎてその上で難しいものが発展しすぎると

バランスですよね。

後々ややこしくなっちゃう。

ruby界隈でみてきた気がする(chef, puppet...)

古くはCのpreprocesssorもそうですね。 (edited)

歴史は繰り返すってやつ

Swiftはその歴史を繰り返すまいと慎重みたいですよ。節々でそういう発言がなされる。

6:13 AM

SwiftUIで使ってるFunctionBuilderが地獄の釜じゃないのかどうかはちょっとわかんないけど・・・結構制限が強いのでギリギリセーフかなあと思ってる

fbは結構際どいと思うw

際どいよね。

FunctionBuildersはSwiftUI専用でしばらく進めるのがいいんじゃないかな。

https://twitter.com/dgregor79/status/1234888627160670249

https://twitter.com/krzyzanowskim/status/1234499779494924288

Yay for code review. @pathofshrines noted a subtle omission in constraint generation that affected the semantics of switch statements in function builders. The fix was trivial but the implications are really interesting: https://t.co/NQTrOkdrSU:

6:16 AM

↑switch文対応が入ったよ。

ｳｵｵ

Property Wrappersも便利だけどあれも強力すぎる気がする

property wrapperとfunction builderの2つは

Property wrapperはちょっとドットアクセスが省略されてるだけっちゃだけ

明確にそれまでのswiftとは毛色の違う機能だなと思っていて

それはそうだね〜　初見殺し度が高いよね。

6:17 AM

知らなきゃ全く意味不明で予想もつかない事が起きる。

6:18 AM

PWの$　付けたアクセスとかやばいよね。

$ｙあばい

6:18 AM

discordぇ...

a, _a, $a だもんな〜w

↑のswitch文のサンプルコードとか見ると switch getSomeEnumOverloaded(17) { case .a: "a" default: "default" }

いやあ@変数に代入したら何が起こるのか、っていうの標準ライブラリとCocoaだけならいいけど3rd Partyも入ると大変だなあと思う。

あとinit(initialValue:)とinit(wrappedValue:)も

明らかにもう文指向じゃなくなってんだよな。 (edited)

@PropertyWrapper と @_functionBuilder 、型を定義する側のIDEのサポートも一切得られないので、結構渋い感じがする

IDEサポートは今後ついてくんじゃない？

7:04 AM

新規作成メニューからテンプレート生成とかでもいいし。

まあそうか。機能を満たして無くてもコンパイル通ってしまうところに一抹の気持ち悪さを感じるんだよな

ああ確かに。

7:05 AM

間違ってても関係ないinitが生えてるだけになっちゃうのか。

7:06 AM

アノテーションでマーキングするのもそれ自体忘れたら同じだしなあ。 IDEが「init(initialValue:)の実装が無いですよ」みたいなのを薄く表示してくれるとかが良さそう。

0279スレ、結構反対意見あるな。

xwuさんの指摘してる丸括弧表記の場合とカンマ1文字しか違いが無いじゃんって指摘に同意だなあ

8:29 AM

かつ、もしカンマが嫌ならSE-0257を進めたらいいじゃん？、もそのとおりすぎる

8:33 AM

クリスラトナーが！

Strong -1.

支配的な-1だ。。

ワイもコメントしてみた。Adrianさんが同じこと書いてたっぽいけど。

10:05 AM

UIView.animate { withDuration: 0.7 delay: 1.0 options: .curveEaseOut animations: animationFunction completion: completionFunction }

10:05 AM

↑これと何が違うの？と思って。

(が{に変わっただけで嬉しくないやんけ!っていうのは何度かみた記憶がある

うん、それ複数回書かれてるんだけど

10:07 AM

末尾クロージャに限定しなくてもいい拡張になってると考えるとよりそれが強調されるなと思って。

これ前スレに書こうとしてモニョくなって反芻してるんだが (edited)

どちらかというと「なぜか末尾クロージャに限定された」第二のカッコが追加される

10:08 AM

すごい不格好な話に見える。

この言語拡張はラベル付きTrailingクロージャと、末尾以外Trailingクロージャの2回に分解した方が

10:08 AM

シュッと終わる気がしている

？？

つまり、複数のクロージャのTrailingを満たすための問題が2種類あって

「ラベル付きTrailingクロージャ」「末尾以外Trailingクロージャ」これ両方新概念か。

その2種類は別々の話題として議論して、その2つの組み合わせで実現可能になる、という設計の方が

10:11 AM

筋良く議論出来て終わりそうだな、と。

それぞれ何の事〜

2つに分けると、それぞれどちらも、なんでそれいるの？になりそうな気がするんですが。

array.first { ... } を例えば array.first { where: ... } みたいに_で省略されてないラベルを見えるようにする、という話と (edited)

1

10:13 AM

末尾以外の引数にクロージャを渡すときの糖衣を定義する、という話かな

10:13 AM

これ組み合わせると今の議論の置き換えになると思う

末尾以外を許可すると今の議論を超えた機能を提案することになるのでは。

今の議論も最後から2番目とかのTrailingやろうとしてるわけで (edited)

あと、「末尾以外」だけ先に導入する事が不可能じゃない？

本質的には同じだと思うけどね

あ、そこは前後順なのか

10:15 AM

たとえば↓これは0279では多分駄目 func f(a: () -> Void, b: Int) {} f(b: 0) { a: { () in } } (edited)

それはそうだね

言いたいことはなんとなく伝わってたんですが、改めてみると、「末尾以外Trailingクロージャ」というネーミングがじわじわくるw

末尾以外パラメータ(仮引数)のTrailingクロージャ実引数(argument)ってことね。 (edited)

意味はわかるんですが、末尾じゃなければtrailingじゃないなと。名前だけで見て、ね。 (edited)

2

まあ結構難題だと思うんですけど、それをする上で、合理的な仕組みを作れば、2引数とかも普通に対応出来る結果になってるはず

10:18 AM

2引数をTrailing Closureにするという議論になっていることが、実態よりも簡単だと誤解される要因になっている気もする (edited)

10:18 AM

末尾じゃなければtrailingじゃない

それはそうw

結局最終的な形を考えないとあんまり良い着地にならないんじゃないか

10:20 AM

あと、「ラベル付きTrailingクロージャ」だけだと通る気がしない。

個人的にはラベルが省略されるようになってしまった、というのは結構痛手な初期の設計ミスだと思っていて (edited)

10:21 AM

どうだろ、同意は得られないか

その気持ち悪さはわかる。

10:23 AM

呼び出しラベル省略できるかどうかは本来関数の定義側のラベル名で決まっているはずなのに

ラベル付きを強制する（省略を不可にする）というものなら、まあ意味がある気がしますが、ラベル付きでも書けるというものなら、Trailingクロージャにしなくていいんじゃないと個人的には思います。

末尾仮引数の関数型だけは、呼び出し側で勝手にラベルを削除できてしまう。

なので、これをどっちに倒したいか (ラベル付きTrailingを追加するか、いっそTrailingを禁止するか)という議題がまずはじめにあって

でも、現状仕様を残したまま、指定できる記法を入れる意味はないと思う。それは丸括弧で書けばいいから。

後者に倒れるならそもそも複数引数のTrailingは不要だった。というわけです。

その観点でありえるのは「ラベル消しTrailingClosureを禁止する」だと思うけど下位互換破壊だから無理そう

この辺をすっ飛ばして複数Trailing議論してるので、そりゃこじれるよなというのが

10:27 AM

ワイの感想であった

いずれにしても最終形は、proposalのalternative consideredに載ってるもの含めて、他に無いと思う。

10:27 AM

trailing closureっていう言語機能が嬉しいのって

10:28 AM

}) って閉じカッコが2重になるのを防げる事だと思っていて

10:28 AM

それが　 }} になっても意味ないと思うんだよな。

10:29 AM

when(2 < 3) { 3 } else { 4 } ↑で、こういうぶら下げスタイルはparser的に厳しいとなるともう選択肢が無いと思う。

10:29 AM

（専用の変な記号でぶら下げる手はある）

10:30 AM

そうした意見は、話の進め方を変えたところで最終型の文法に対して有効な反論になるから、変わらない気がする。

「ラベル消しTrailingClosureを禁止する」だと思うけど下位互換破壊だから無理そう

現実的にシンプルで良さそうだけど、やっぱ破壊的すぎて今からだとダメそうという同じ結論に至った・・・

1

UIView.animate(withDuration: 0.7) { animations: frame.size.width += 10 completion: _ in backgroundColor = .yellow }

1:23 AM

これはアリだな・・・・・・

1:25 AM

あーでも文法的にラベルに見えてしまうか

「ラベル消しTrailingClosureを禁止する」だと思うけど下位互換破壊だから無理そう

@noomit label: () -> Void のようなアノテーションを導入したら下位互換は解決できそう？

たしかに。

下位互換破壊って一年くらい前まではカジュアルにあったと思うんだけど

6:02 PM

もうやめることになったんだっけ。

Swift4が出たときにこれからはコード下位互換は壊さないようにしようねって雰囲気だったと思う

↓このAPIに UnsafeMutablePointer<ObjCBool>? が使われてるのってなんででしょう？ inout Bool? じゃダメ？ NSFileManager のままなのかと思ったけど、 FileManager 導入時に気付けたような。 https://developer.apple.com/documentation/foundation/filemanager/1410277-fileexists

その話最近dorgがツイッターでしてましたね。理由としてはObjctive-CのBOOLのポインタを機械的に変換したからで

4:55 AM

専用のオーバレイを用意するのが望ましいけどやりそこねた。

やりそこねた・・・

Marcin ~swift.best~ Krzyzanowski (@krzyzanowskim)

Thank God Swift Foundation is fundamentally cross-platform

‍♀️ We have even "ObjCBool" for non-objc platforms. https://t.co/5LMI66FXZY

4:57 AM

↑英会話むずいけど多分そんな話だと思う。 (edited)

4:58 AM

多分やるんだったらSwift3の時のAPI Swift化の時でしたね。

4:58 AM

Swift2のときは機械変換がいっぱいあった。俺それ気がついてたし伝えたら良かったなあ。

もしかして Foundation 捨てることも視野に入ってる？ https://twitter.com/dgregor79/status/1234527858317389826

https://forums.swift.org/t/swiftpm-support-for-swift-scripts/33126

@krzyzanowskim @simjp Personally, I think we as a community should be focusing on great cross-platform Swift APIs and not continue to tune the import of Objective-C APIs. The latter is source-breaking and is at best good, but almost never great.

4:59 AM

swift-file とかできてほしい。

たしかに。

5:00 AM

この前もCryptoとかArgumentParserとか出してたし

5:00 AM

ちょこちょこ小さい単位で出していく気持ちもあるのかな。

SPMのTSCにファイル操作のやつあるし、独立する可能性はあるんじゃない？

たしかに。

swift- 系のライブラリは、今は SwiftPM 経由だけど、将来的にコンパイラに同梱配布も見込まれてるのかな？

SwiftはPythonみたいにバッテリーインクルードの方針じゃなかったでしたっけ？

5:02 AM

^ （うろ覚え。）

どっちかというとSwiftPMでいろいろ必要なものを取ってくる方向に進んでるように感じます。

そう、うろ覚えでそんな話を @omochimetaru がしていたような。 < バッテリーインクルード (edited)

あ〜でもStandardLibrary Previewは

5:03 AM

通ったものは入れてくからStandardLibraryは育つのかな。

なるほど。じゃあ同梱はしないで本体はスリムのまま、かなあ。

swift- 系は標準ライブラリじゃないからなぁ。

現時点でswift-系を分けててstandard library evolutionの流れにはしてないし、

5:05 AM

機能系（？）はSwiftPMで取る感じになっていきそう。

標準ライブラリと分離しながらも、同梱されてて SwiftPM 通さずに import できたら便利そうな気が。やっぱりいちいち SwiftPM 通さないといけないのは不便な感じが。ファイル周りとか、ネットワーク周りとかも swift- に切り出すなら余計に。

まあファイルIOは同梱してほしいけど負債になりやすいやつだから悩ましいですねえ。やはりケースバイケースか。

不便な感じ

それは、Package.swiftとかのことですか？

うん

Script modeを強化して、swift-shみたいに、単一ファイルでもimport文にリモートリポジトリパッケージを使えるようにしようっていう方向性の話があるので、それで解決するのが良いと思ってます。

Goっぽい。悪くないと思う。

5:08 AM

↑ここかな？　Swift6 アナウンスのときにスレがちょっと復活した。

5:09 AM

クリスラトナーも2/3に > I love this pitch って書き込んでる。 (edited)

うん、でもこれにしても、やっぱ import Foundation とだけ書けたのと比べると面倒だと思うんだよなぁ。

swift-shなら import Foundation import PromiseKit // @mxcl ~> 6.5 (edited)

ファイルI/Oの度に↓を書きたいかどうか。 @package(url: "https://github.com/apple/swift-file.git", from: "1.0.0") import File (edited)

ちょうどいいバランスになるんじゃないですか？

5:10 AM

必要とされるものは本体に同梱、そうでないものは@package importって感じで。

GithubのURL全部書くのはめんどくさいから、 GitHubだったら省略して、 import mxcl.PromiseKit とか書けると良いと思う。

この辺の仕組みだと後から本体に同梱するようにした、とかも問題ないし。

中央リポジトリみたいなものがあればmxcl. も削れそう。

GitHub だったら省略はどうだろう？外部サービスに言語仕様が依存するのは・・・

5:12 AM

中央リポジトリはいいかもだけど、 SwiftPM の中央リポジトリがない良さが。悩ましい・・・。

「標準でコンパイラと一緒に出荷するものを選ぶ」のと「中央リポジトリを用意する」って同じ話じゃないですか？

5:12 AM

GitHub特別扱いは外部サービスだからちょっと違うけど。

中央リポジトリに登録するのが swift- だけならいいけどね。

まあ import "github.com/kishikawakatsumi/KeychainAccess" でいいんじゃない。 Goと一緒。加えてSwiftはバージョンの指定ができる。

サードパーティのライブラリも登録し始めると、 GitHub に push するだけって現状と比べると面倒になるなと。

5:14 AM

import "github.com/kishikawakatsumi/KeychainAccess" は、パッケージとモジュールが別だから一手間要りそうですね。

5:16 AM

パッケージ中の全モジュール import 扱いとかもできるかもですが、コード中にモジュール名が現れないのは、 Module.Foo とかするときに対応が分かりづらいのが・・・。

import KeychainAccess と同じ意味を想定しているのでは？

import "github.com/swift/SourceKit-LSP/Core" import "github.com/swift/SourceKit-LSP/JSONRPC" Pathのように書けるとか

5:17 AM

^ これは妄想

↑だとありだと思います。最後は / じゃなくて : とかの方が明確かもですが。

まあ、中央リポジトリにしても書く方の複雑さはそれほど変わらないと思います。 CocoaPodsとかRubyGemでわかったように、名前空間がある程度必要なので、結局ドメイン的な衝突しないものが必要になる、のでそこそこ長くなるかと。

5:20 AM

そうすると、中途半端にこの場合は書けるってしてもたぶん覚えにくいだけとなりそうだからある程度カッチリ書く、っていうのは悪くないんじゃないかな。

@omochimetaru リポジトリから指定したいモジュールが一意に定まらないので。たとえば import "github.com/apple/swift-numerics" として、 import Numerics なのか import ComplexModule なのか。

リポジトリ名とパッケージ名が別名の時は指定するとして、同名だったら省略が良いと思う。 (edited)

Apple はリポジトリ名とパッケージ名を同名にすることは推奨してなさそうだし、パッケージ名と同名モジュール読み込みはできるけど、その場合はモジュール名が import 文に現れないのが気持ち悪い・・・。

5:23 AM

名前空間がある程度必要なので、結局ドメイン的な衝突しないものが必要になる、のでそこそこ長くなるかと。

そうですね。その上で swift- 系だけは特別扱いされるといいなと。 import File と書きたいです。

5:24 AM

話は逸れますが、今ってモジュール名が衝突した場合って解決できるんですっけ？

5:25 AM

import "github.com/swift/SourceKit-LSP/Core" みたいなのを想定すると、解決できてほしいですし、それが解決できるなら同じライブラリのバージョン違いを同時に使うとかもできそうですね。

推奨してないことはないと思うんですよね。（どっちを推奨してるかは分からないけど）Appleが公開リポジトリに上げるようなものはそこそこの規模だから必然的にいろんなモジュールがかかわらざるをえない、んじゃないかな。

swift- プレフィックスが付いてるのと、 GitHub の標準的なリポジトリ命名規則に従って小文字ハイフン区切りになっている辺りですね。

モジュールの衝突は回避できないんじゃないかなあ。

昔のサードパーティの Swift ライブラリのリポジトリって UpperCamelCase が多かったですけど、僕は最近は Apple の習って foo-bar-baz みたいにするようにしてます。

import "github.com/swift/SourceKit-LSP/Core" ^ これはうろ覚えで import "github.com/swift/SourceKit-LSP/SKCore" こうでした。

モジュール名衝突が回避できないと、

名前空間がある程度必要なので、結局ドメイン的な衝突しないものが必要になる、のでそこそこ長くなるかと。

の対応も中途半端になるかなぁと。

swift- プレフィックスが付いてるのと、 GitHub の標準的なリポジトリ命名規則に従って小文字ハイフン区切りになっている辺りですね。

なるほど、確かに。

5:29 AM

モジュール名衝突はなんとかしてほしいですね。。。

Java の FQDN で指定する方法みたいなのは必要だと思うんですよね。 (edited)

Javaはそれとディレクトリ構造を一致させてしまったことがよくなかったですね

そうですねｗ

5:32 AM

import "github.com/foo/bar:Module" as BarModule

5:32 AM

みたいなのがいいのかな。

import時に別名をつける、というのは古いProposalがあったような気がしますね。

SKCore・・・　TSCもあるしなんかObjectiveCみたいになってきちゃってるよな。

構文だけの問題じゃなくて、 ABI 安定化された今、そこの衝突回避ってできるんでしょうか？

SK prefix は SpriteKiteとかぶっちゃってるしな。

追加仕様だったらいいんじゃない？

5:37 AM

ABIも今のところ限定的な話だし、壊すときは壊す気もする（別にいいと思う）。

現状だとパッケージ名がシンボルにマングルされてるから

5:40 AM

たとえソースコード側でパッケージ名に別名を付けてimportできたとしても、元々のパッケージ名が同じだったら衝突しちゃうので一緒に使えないですね。

import "github.com/foo/bar:Module" みたいなときはパス込みでシンボル名を作れば ABI 仕様を破壊しない？でも、既存の SwiftPM と衝突するかな。

パス形式でimportしたときはパスを埋め込んだシンボルにすれば、それは追加仕様なので下位互換は壊れないですね

5:44 AM

でも事前ビルドしたバイナリを配布する形式を考えると、

5:44 AM

利用側がどういうパスで指定したかとは関係なく

それだと Package.swift に書かれたときは衝突回避できないから、 Package.swift もパス込みにした方がいい気が。

ライブラリ自体がユニークな名前を持っている必要がありそう。

あと、これができれば同一ライブラリを別リポジトリに置いて重複importできるので、それだったらバージョン違いで重複importできてもいい気がする。

5:44 AM

なので、シンボル名にバージョンまで焼き込まれる。

それやると

5:46 AM

互換性のあるバージョン間で

5:46 AM

バイナリ差し替えができなそう。

少なくとも、 1. コンパイル時にどっちのインターフェースを参照するか、はABI関係ないから記法とか順序とかで解決できる。

5:49 AM

でバイナリがどっちを呼ぶか、というのは、、、とここまで書いてやっぱり難しいなと思いました。

5:49 AM

フレームワークとかモジュールの単位でFQDNみたいな区別できるものがないとだめじゃないですかね。

5:49 AM

つまり、今のSwiftが想定している名前空間では足りない。拡張する必要がある。 (edited)

互換性のあるバージョン間でバイナリ差し替えができなそう。

なるほど。それは言い換えると、今は Package.swift に書くリポジトリ変わってもモジュール名同じなら互換性持たせられるけど、パスを焼き込んじゃったらそれもできなくなる？

同じパスのままバージョンが変わるかぎりは差し替えられる。

うん。でも、リポジトリ引っ越しましたには対応できなくなっちゃうと。

そですね。まあ、引越し先でも以前のパスを焼き込み続ければいけます。

それは、実際のリポジトリの在り処と焼きこまれてるパスを独立に管理しないといけなくて大変そう・・・。 (edited)

まあそうですね。結局の所「焼きこまれてるパス」に相当するのが岸川さんの書いてる「フレームワークとかモジュールの単位でFQDNみたいな区別できるもの」ですね。

うーん、一意性を保証する一番お手軽な手段はリポジトリの在り処だと思うから、引っ越し時は諦めてリビルドくらいが現実的そう。

区別する手段はリポジトリのURLでいいと思いますが、結局配布することを考えると、それがバイナリについてこないとダメなので名前空間の仕様は拡張しないと難しそうですよね。

URLだと文字列として長すぎて、シンボル全部に含まれるとなると、バイナリサイズがちょっと膨らみそうなのが気になるな。

ビットを最大限使ってエンコーディングしたらいいのかな。 Swiftはモジュール名はHuman Readableな形で残ってるんでしたっけ？

概ねHumanReadableですね　同じ単語が２回出てくる時は参照記号に圧縮される。

1

6:08 AM

http:// とか github.com を表す特別な記号とかを用意すれば少し圧縮することはできるかも？ｗ

考えてたら大変すぎてPrefixでも別にいいけど、って気分になってきた。

6:10 AM

まあまあちょうどいいバランスな気がする。

サブパッケージの機能は欲しいな。

6:11 AM

TSCBasic よりも SwiftToolsSupport.Basic になってて欲しい。

6:11 AM

使う側で as TSCBasic する事はあるかもしれないけど。

6:12 AM

SwiftPMでライブラリ作る時全部のパッケージにそのライブラリを現すprefixを付けるのはめんどくさい。

6:13 AM

URLやドメインを使わずにライブラリ名同士の衝突を防ぐためには中央リポジトリで名前登録する仕組みが必要だけどそれは悩ましいところだ。

6:14 AM

例えば FileKit みたいな名前ってファイル操作のライブラリを作ろう、って思ったら思いつきやすくて

6:14 AM

中央がある場合、最初に FileKit を取った人のものになっちゃうけど

6:14 AM

中央リポジトリがない場合、別の人の作った FileKit のほうが出来が良かったときに

6:15 AM

民主的に乗っ取れる可能性があるのは良いところな気もする。

6:15 AM

てか昔 antitypical じゃない Result もなかったでしたっけ

6:15 AM

まあ派閥が分裂した時はオシマイだけど・・・

厳密にはFileKitとFileKitの衝突の話とさっきまでの話は別といえば別なんですよね。 FileKitとFileKit

6:21 AM

の衝突はResultもですが、両方を使いわけたいケースではないと思うので。

あ〜そうか。両方使いたい話と、どっちかが代表を取れる話は別ですね。

いい感じの名前が取り合いになる問題はもう少しシンプルに解決できそうな気がしている。

6:22 AM

ただPackage.swift （import ~~）にフルパスが書ければいい？のかな。

6:23 AM

そこはたぶんそれでいい気がする。

フルパスが要らない短い記法は欲しいなあ・・・

1

6:25 AM

今ってコマンドラインツールだととりあえずimport Foundation　すればよいところがあるけど

6:25 AM

これからさきだんだん、ファイル操作ならXX、通信ならYY、みたいなのを覚えていく事になりそうで。

TestFlightでの稼働か、AppStore経由での正式リリースかを判定する方法ってないですかね。（#if DEBUG的な感じでできるとととてもありがたいんだけどw）

if Bundle.main.appStoreReceiptURL?.lastPathComponent == "sandboxReceipt" { ~ }

protocol Cat { func play(catToy: Toy) } let fn = Cat.play fn(myCat)(myToy) プロトコルメソッドを一級オブジェクトとして取れるようになったらしい。 https://github.com/apple/swift/pull/28698/files

ほおー

これ、従来は呼び出しだけでもジェネリック関数を経由しないといけなかったし、いったん関数の形にするのは今までは無理だったんじゃないかな？多分継承boxでeraseしないといかん

()()

レシーバと引数で2階のカリー化されてるのはstructのメソッドとかと同じですね。

あーこれ <T: P>(T) -> (A) -> R じゃなくて (P) -> (A) -> R かも。。？

@swiftbot

import Foundation struct DocumentSymbol: Encodable {} class Service { func perform() { sendDocumentSymbolRequest(context: [:], resource: "", slug: "", path: "") { (_, _) in } } private func sendDocumentSymbolRequest(context: [String : String], resource: String, slug: String, path: String, reply: @escaping (Bool, [String : Any]) -> Void) { let documentSymbols = [DocumentSymbol()] reply(true, ["result": "success", "value": encodeResponse(documentSymbols)]) } private func encodeResponse(_ documentSymbol: DocumentSymbol) -> [String: Any] { print("A") return [:] } private func encodeResponse(_ documentSymbols: [DocumentSymbol]) -> [String: Any] { print("B") return [:] } private func encodeResponse<T: Encodable>(_ response: T) -> Any { print("C") let data = try! JSONEncoder().encode(response) return try! JSONSerialization.jsonObject(with: data, options: []) } } let service = Service() service.perform()

kishikawakatsumi

import Foundation struct DocumentSymbol: Encodable {} class Service { func perform() { sendDocumentSymbolRequest(context: [:], resource: "", slug: "", path: "") { (_, _) in } } private func sendDocumentSymbolRequest(context: [String : String], resource: String, slug: String, path: String, reply: @escaping (Bool, [String : Any]) -> Void) { let documentSymbols = [DocumentSymbol()] reply(true, ["result": "success", "value": encodeResponse(documentSymbols)]) } private func encodeResponse(_ documentSymbol: DocumentSymbol) -> [String: Any] { print("A") return [:] } private func encodeResponse(_ documentSymbols: [DocumentSymbol]) -> [String: Any] { print("B") return [:] } private func encodeResponse<T: Encodable>(_ response: T) -> Any { print("C") let data = try! JSONEncoder().encode(response) return try! JSONSerialization.jsonObject(with: data, options: []) } } let service = Service() service.perform()

Version:

swift-5.1.3-RELEASE

Output:

B

Error:

^ これは当然Bが呼ばれるのだけど、

7:07 AM

AとBのメソッドにデフォルト引数を足すと（デフォルト引数なのでCall siteの変更はナシ）

7:07 AM

@swiftbot

import Foundation struct DocumentSymbol: Encodable {} class Service { func perform() { sendDocumentSymbolRequest(context: [:], resource: "", slug: "", path: "") { (_, _) in } } private func sendDocumentSymbolRequest(context: [String : String], resource: String, slug: String, path: String, reply: @escaping (Bool, [String : Any]) -> Void) { let documentSymbols = [DocumentSymbol()] reply(true, ["result": "success", "value": encodeResponse(documentSymbols)]) } private func encodeResponse(_ documentSymbol: DocumentSymbol, _ indent: Int = 0) -> [String: Any] { print("A") return [:] } private func encodeResponse(_ documentSymbols: [DocumentSymbol], _ indent: Int = 0) -> [String: Any] { print("B") return [:] } private func encodeResponse<T: Encodable>(_ response: T) -> Any { print("C") let data = try! JSONEncoder().encode(response) return try! JSONSerialization.jsonObject(with: data, options: []) } } let service = Service() service.perform()

kishikawakatsumi

import Foundation struct DocumentSymbol: Encodable {} class Service { func perform() { sendDocumentSymbolRequest(context: [:], resource: "", slug: "", path: "") { (_, _) in } } private func sendDocumentSymbolRequest(context: [String : String], resource: String, slug: String, path: String, reply: @escaping (Bool, [String : Any]) -> Void) { let documentSymbols = [DocumentSymbol()] reply(true, ["result": "success", "value": encodeResponse(documentSymbols)]) } private func encodeResponse(_ documentSymbol: DocumentSymbol, _ indent: Int = 0) -> [String: Any] { print("A") return [:] } private func encodeResponse(_ documentSymbols: [DocumentSymbol], _ indent: Int = 0) -> [String: Any] { print("B") return [:] } private func encodeResponse<T: Encodable>(_ response: T) -> Any { print("C") let data = try! JSONEncoder().encode(response) return try! JSONSerialization.jsonObject(with: data, options: []) } } let service = Service() service.perform()

Version:

swift-5.1.3-RELEASE

Output:

C

Error:

Cが呼ばれるって変じゃないかな？

7:09 AM

互換性を保つように変更したつもりなのに呼ばれるメソッドが変わっているという罠。

7:10 AM

ちなみに、これは同じシグネチャでトップレベルのFunctionだと、どっちのケースもBが呼ばれる。インスタンスメソッドにするとこうなった。

これはどのケースでもCが呼ばれるのが正しいと思います。

8:50 AM

Bは [String: Any] からAnyへの変換でペナルティを食らうけどCはペナルティなしじゃないですかね？

8:52 AM

インスタンスメソッドとトップレベル関数でオーバーロードの解決が違うのはよくわからない… (edited)

リテラルの型推論が組み合わさってるからこれ難しいな。

8:53 AM

とりあえず、デフォルト引数を追加しただけでオーバーロード選択結果が変わるのは変だと思います。

@swiftbot -Xfrontend -debug-constraints

protocol P {} struct S: P {} struct V { static let value = V() } class Service { func perform() { let s = S() let _: Any = encodeResponse(s) } private func encodeResponse(_ s: S, indent: V = V.value) -> [String: Any] { fatalError() } private func encodeResponse<T: P>(_ response: T) -> Any { fatalError() } } let s = Service() s.perform()

(edited)

kateinoigakukun

protocol P {} struct S: P {} struct V { static let value = V() } class Service { func perform() { let s = S() let _: Any = encodeResponse(s) } private func encodeResponse(_ s: S, indent: V = V.value) -> [String: Any] { fatalError() } private func encodeResponse<T: P>(_ response: T) -> Any { fatalError() } } let s = Service() s.perform()

Version:

swift-5.1.3-RELEASE

Output:

Error:

Fatal error: file /usercode/main.swift, line 19 Current stack trace: 0 libswiftCore.so 0x00007f1672a4f3a0 swift_reportError + 50 1 libswiftCore.so 0x00007f1672ac0090 _swift_stdlib_reportFatalErrorInFile + 115 2 libswiftCore.so 0x00007f16729e44fe <unavailable> + 3515646 3 libswiftCore.so 0x00007f16729e4677 <unavailable> + 3516023 4 libswiftCore.so 0x00007f16727d9ddd <unavailable> + 1375709 5 libswiftCore.so 0x00007f16729bb458 <unavailable> + 3347544 6 libswiftCore.so 0x00007f16727d9179 <unavailable> + 1372537 10 swift 0x00000000005283fe <unavailable> + 1213438 11 swift 0x000000000052cce2 <unavailable> + 1232098 12 swift 0x000000000051cdbf <unavailable> + 1166783 13 swift 0x000000000050b5e8 <unavailable> + 1095144 ...

8:55 AM

stderr-5.1.3.txt

2.02 KB

おや。

8:55 AM

ああfatalError入れてるのか

stderr-5.1.3.txt

2.02 KB

あれオプション間違ってます？

@swift-main -frontend -typecheck -debug-constraints

protocol P {} struct S: P {} struct V { static let value = V() } class Service { func perform() { let s = S() let _: Any = encodeResponse(s) } private func encodeResponse(_ s: S, indent: V = V.value) -> [String: Any] { [:] } private func encodeResponse<T: P>(_ response: T) -> Any { 0 } } let s = Service() s.perform()

8:57 AM

あれ？BOTちゃんが居ない。

8:57 AM

@swiftbot -frontend -typecheck -debug-constraints

protocol P {} struct S: P {} struct V { static let value = V() } class Service { func perform() { let s = S() let _: Any = encodeResponse(s) } private func encodeResponse(_ s: S, indent: V = V.value) -> [String: Any] { [:] } private func encodeResponse<T: P>(_ response: T) -> Any { 0 } } let s = Service() s.perform()

omochimetaru

protocol P {} struct S: P {} struct V { static let value = V() } class Service { func perform() { let s = S() let _: Any = encodeResponse(s) } private func encodeResponse(_ s: S, indent: V = V.value) -> [String: Any] { [:] } private func encodeResponse<T: P>(_ response: T) -> Any { 0 } } let s = Service() s.perform()

Version:

swift-5.1.3-RELEASE

Output:

Error:

型変数の置き方が全然違いますね

まだよくわかってないのだけれど、

final class CreatorThumbnailImageView: UIView { @Published var images = [PlayLogUploadParameter]() { didSet { ... } } ... }

^ のようなクラスがあるとして、 thumbnailImageView.images.append(image) のような操作をしたときにDidSetが呼ばれない現象がXcode 11.4で発生している。 Xcode 11.3.1でビルドして実行するとDidSetが呼ばれる。

https://forums.swift.org/t/swift-5-2-struct-property-wrapper-didset-defect/34403

[Swift 5.2] Struct + Property Wrapper didSet defect?

Hi all, Something I noticed in Swift 5.2 in the latest betas, and the latest snapshots, when you use a property wrapper for a struct, and you set a value inside the struct, a didSet does not get called. For example: import Combine struct MyStruct { var details: String }...

1:41 PM

この件ですかね

同じ事象のようですね。 Swift 5.2のバグ、なんですね。

いや、違うな。私のは再代入するように変えたら動く、わけなので。

1:55 PM

iPhoneで見てるから細かいとこ読めてなかった。 (edited)

nil as String? is AnyObject を Xcode の Playgroundで試すと true なんだけど

5:31 AM

REPL だと false になる不思議

5:31 AM

なんででしょうね...

Optional<Any>.none is AnyObject

それでも結果が違う

5:34 AM

@swift-5.2.5 Optional<Any>.none is AnyObject

exit status: 1 with stderr:<unknown>:0: error: no such file or directory: 'Optional<Any>.none'

使い方こうじゃないのか...

5:36 AM

@swift-5.2.5 Optional<Any>.none is AnyObject

stderr:

<stdin>:1:20: warning: 'is' test is always true Optional<Any>.none is AnyObject ^ <stdin>:1:20: warning: conditional cast from 'Optional<Any>' to 'AnyObject' always succeeds Optional<Any>.none is AnyObject ^ <stdin>:1:20: warning: expression of type 'Bool' is unused Optional<Any>.none is AnyObject ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~

@swift-5.2.5 print(nil as String? is AnyObject)

truestderr:

<stdin>:1:22: warning: 'is' test is always true print(nil as String? is AnyObject) ^ <stdin>:1:22: warning: conditional cast from 'String?' to 'AnyObject' always succeeds print(nil as String? is AnyObject) ^

むむ

22:51 niw@tpurr:~/Desktop $ cat a.swift let b: Bool = nil as String? is AnyObject print(b) 22:51 niw@tpurr:~/Desktop $ swiftc a.swift 2>/dev/null && ./a false

(edited)

5:54 AM

むむむ...

5:58 AM

22:57 niw@tpurr:~/Desktop $ cat a.swift import Foundation let n: NSString = "a" let b: Bool = nil as String? is AnyObject print(b) 22:57 niw@tpurr:~/Desktop $ swiftc a.swift 2>/dev/null && ./a true

(edited)

5:58 AM

trueになった...

5:58 AM

まじか...

5:58 AM

$ otool -L ./a ./a: /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1675.129.0) /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.8.25) /usr/lib/swift/libswiftFoundation.dylib (compatibility version 1.0.0, current version 0.0.0)

5:58 AM

Foundation.framework がリンクされてるかどうかで挙動がかわるっぽい？ (edited)

6:01 AM

23:00 niw@tpurr:~/Desktop $ cat a.swift import Foundation let n: Data? = nil let b: Bool = nil as String? is AnyObject print(b) 23:00 niw@tpurr:~/Desktop $ swiftc a.swift 2>/dev/null && ./a false 23:00 niw@tpurr:~/Desktop $ otool -L ./a ./a: /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.8.25)

(edited)

6:01 AM

えーっということは Foundation.framework がない場合の import Foundation では挙動が変わらないと... (edited)

NSObjectへの暗黙変換が走る環境かどうかでAnyObjectへのキャストの可否は結果に差が出ます

気持ちはわかるけど、なかなか怖い

あんまり好きじゃない挙動の1つですね。

5:08 PM

任意の値をclassかどうか判別するのに type(of: someValue) is AnyObject.Type で見ないといけない

これ最適化の有無で結果が変わるね。

$ pbpaste let b: Bool = nil as String? is AnyObject print(b) $ pbpaste|swiftc -suppress-warnings - && ./main false $ pbpaste|swiftc -suppress-warnings -O - && ./main true

www

11:56 PM

気持ちはわかる

Foundation.frameworkをリンクしてるかどうかは関係ないぽい。

$ pbpaste|swiftc -suppress-warnings - && ./main && otool -L ./main false ./main: /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.8.25) $ pbpaste|swiftc -suppress-warnings -O - && ./main && otool -L ./main true ./main: /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.8.25)

(edited)

なるほど...?

12:15 AM

NSObject が現れるかどうかとか？

~~あ、間違い。~~ (edited)

12:19 AM

いや、提示したログの検証手順が間違ってたけど、結果は会ってた。

12:21 AM

Linuxだと最適化に関係なくtrue

$ pbpaste|docker-swift-run bash -c "swiftc -suppress-warnings - && ./main && ldd ./main" true linux-vdso.so.1 => (0x00007ffd56da9000) libswiftSwiftOnoneSupport.so => /usr/lib/swift/linux/libswiftSwiftOnoneSupport.so (0x00007f1bed03c000) libswiftCore.so => /usr/lib/swift/linux/libswiftCore.so (0x00007f1bec8e1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1bec517000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1bec2fa000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1bec0f6000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1bebd74000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1beba6b000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1beb855000) libicui18nswift.so.65 => /usr/lib/swift/linux/libicui18nswift.so.65 (0x00007f1beb335000) libicuucswift.so.65 => /usr/lib/swift/linux/libicuucswift.so.65 (0x00007f1beaf3e000) libicudataswift.so.65 => /usr/lib/swift/linux/libicudataswift.so.65 (0x00007f1be928f000) /lib64/ld-linux-x86-64.so.2 (0x00007f1bece61000)

12:22 AM

$ pbpaste|docker-swift-run bash -c "swiftc -suppress-warnings -O - && ./main && ldd ./main" true linux-vdso.so.1 => (0x00007ffeea9c8000) libswiftCore.so => /usr/lib/swift/linux/libswiftCore.so (0x00007f4e73cb0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4e738e6000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4e736c9000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4e734c5000) libicui18nswift.so.65 => /usr/lib/swift/linux/libicui18nswift.so.65 (0x00007f4e72fa5000) libicuucswift.so.65 => /usr/lib/swift/linux/libicuucswift.so.65 (0x00007f4e72bae000) libicudataswift.so.65 => /usr/lib/swift/linux/libicudataswift.so.65 (0x00007f4e70eff000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4e70b7d000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4e70874000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4e7065e000) /lib64/ld-linux-x86-64.so.2 (0x00007f4e74230000)

print()を使わない様にすると最適化の有無に関係なくfalse

$ pbpaste let b: Bool = nil as String? is AnyObject $ pbpaste|swift -frontend -repl -sdk (xcrun -sdk macosx -show-sdk-path) 2>&- // b : Bool = false $ pbpaste|swift -frontend -repl -sdk (xcrun -sdk macosx -show-sdk-path) -O 2>&- // b : Bool = false

(edited)

12:39 AM

それにimport Foundationを追加すると最適化の有無に関係なくtrue

terminal.sh-session $ pbpaste import Foundation let b: Bool = nil as String? is AnyObject $ pbpaste|swift -frontend -repl -sdk (xcrun -sdk macosx -show-sdk-path) 2>&- // b : Bool = true $ pbpaste|swift -frontend -repl -sdk (xcrun -sdk macosx -show-sdk-path) -O 2>&- // b : Bool = true

12:43 AM

let b: Bool = nil as String? is AnyObjectは

明示的にimport Foundationするとtrue
明示的にimport Foundationしなくても、print()を使ってる場合、最適化ありでtrue、無しでfalse

(edited)

むむむ、

12:46 AM

print()...

print()して見ようとすると挙動が変わるのなかなか難しい問題だな

REPLだとimport Foundation前に評価すると、インポート前も後もfalse

$ swift Welcome to Apple Swift version 5.2 (swiftlang-1103.0.32.1 clang-1103.0.32.29). Type :help for assistance. 1> let a: Bool = nil as String? is AnyObject a: Bool = false 2> import Foundation 3> let b: Bool = nil as String? is AnyObject b: Bool = false 4> ^D

評価前にimport Foundationするとtrue

$ swift Welcome to Apple Swift version 5.2 (swiftlang-1103.0.32.1 clang-1103.0.32.29). Type :help for assistance. 1> import Foundation 2> let a: Bool = nil as String? is AnyObject a: Bool = true

@swift-main -Osize

struct S { } struct T { let s: S } class C { func method() -> Any { let t = f() let r = (t != nil) ? 1 : nil return (r, t?.s) } func f() -> T? { return T(s: S()) } }

exit status: 1 with stderr:

<stdin>:1:1: error: extraneous '}' at top level } ^ <stdin>:4:12: error: use of undeclared type 'S' let s: S ^ <stdin>:15:21: error: use of unresolved identifier 'S' return T(s: S()) ^

ふへ

11:19 PM

なぜ...

11:19 PM

@swift-nightly -Osize

struct S { } struct T { let s: S } class C { func method() -> Any { let t = f() let r = (t != nil) ? 1 : nil return (r, t?.s) } func f() -> T? { return T(s: S()) } }

11:20 PM

あれ、これは動かない、、、

11:20 PM

@swift-main -Osize

struct S { } struct T { let s: S } class C { func method() -> Any { let t = f() let r = (t != nil) ? 1 : nil return (r, t?.s) } func f() -> T? { return T(s: S()) } }

no output

おお？ crashしない

11:21 PM

@swift-5.2.5 -Osize

struct S { } struct T { let s: S } class C { func method() -> Any { let t = f() let r = (t != nil) ? 1 : nil return (r, t?.s) } func f() -> T? { return T(s: S()) } }

no output

-Osize無視されるのかな...

11:23 PM

swiftcをこれでクラッシュできるはずなんだけど。

Immediate モードだと IRGen した後 LLVM 通さずに JIT 実行してしまうからですかね。

1

nightlyダウンロードしてた

11:29 PM

Swift ビルドするのはしんどい...

11:29 PM

わーい

11:29 PM

クラッシュした

11:31 PM

https://bugs.swift.org/browse/SR-12495 です

1

siloptimizerのバグっぽいなあ

12:11 AM

tuple_element_addr が分岐で違うほうのうやつを見ちゃってる

optimizeを一つだけオフとかできるのかなあ

できますよ

ConditionForwardingを切りたい

ちょっとまってて

⏳

$ swiftc -Xllvm -sil-disable-pass=<パスの名前> a.swift 多分こう (edited)

1

6:29 AM

パスの名前は $ swiftc -Xllvm -sil-print-pass-name=true a.swift を一度流してデバッグログを見たらわかる気がする

6:30 AM

https://github.com/apple/swift/blob/master/lib/SILOptimizer/PassManager/PassManager.cpp#L87

https://swift.org/blog/5-3-release-process/

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

6:30 AM

情報はこのへんとテストケース。 (edited)

Passes.defみてた

ああ、そっちがいいですね。

ConditionForwardingではなかったか...

SILCombine か...

6:50 AM

めちゃでかい...

JumpThreadSimplifyCFG だけdisableする、でも大丈夫だな

7:08 PM

5.3でwindowsサポートするらしい

ね。なんか急に進んだなあという感じ。

imaginary WWDC で Gates が登壇してみたいなことがあったのかもしれない (edited)

6までかかると思ってたたしかに進捗的にはもう出すだけだけど

4:25 AM

実際にどのくらい使ってみたんだろう

https://twitter.com/omochimetaru/status/1249908644759498752

財布紛失タル (@omochimetaru)

え！openExistentialってすでに存在していたの！？ https://t.co/p6R0ZLenvW

3:54 AM

https://twitter.com/anandabits/status/1249897699366899712

Matthew Johnson (@anandabits)

@jckarter is there any way to get a value of type Any to pass itself to an unconstrained generic function to recover its type (without using the runtime directly)?

3:54 AM

https://twitter.com/anandabits/status/1249905733610754049

Matthew Johnson (@anandabits)

@jckarter Awesome, thanks! I found some in the tests already https://t.co/aRYzVsG8pZ

3:56 AM

// RUN: %target-typecheck-verify-swift protocol P { } func foo<T: P>(_: T) {} func bar<T: P>(_: T.Type) {} func open(existential: P, mutExistential: inout P) { _openExistential(existential, do: foo) _openExistential(type(of: existential), do: bar) _openExistential(mutExistential, do: foo) _openExistential(type(of: mutExistential), do: bar) }

3:56 AM

existential self openテクを使わなくてもopenできる

@swift-4.0.3 @swift-4.1.3 @swift-4.2.4 @swift-5.0.3 @swift-5.1.5 @swift-5.2.5

protocol P { } func foo<T: P>(_: T) {} func bar<T: P>(_: T.Type) {} func open(existential: P, mutExistential: inout P) { _openExistential(existential, do: foo) _openExistential(type(of: existential), do: bar) _openExistential(mutExistential, do: foo) _openExistential(type(of: mutExistential), do: bar) }

no output

4.0マジ

https://github.com/apple/swift/pull/30916/files

[SE-0279] Add support for an unbraced syntax for multiple trailing ...

This PR implements an alternative to the syntax proposed in SE-0279, allowing an initial unlabeled trailing closure to be followed by an arbitrary number of labeled-closure postfixes.

5:08 PM

func mixed_args_2(_: () -> Void, a: () -> Void, _: () -> Void) {} mixed_args_2 {} a: {} _: {}

5:09 PM

SE-0279 のスレで出てきた別文法の(実験？)実装が出てる・・・

5:11 PM

0279はプロポーザル通りの実装もメリメリ進んでてそのまま行くんかな〜と思ってたけど、いろいろ試してるのかな。

https://gist.github.com/niw/95078dfa2505bff76a3966c7600b4fcd

OSLog.swift

GitHub Gist: instantly share code, notes, and snippets.

6:04 PM

argといえば...

6:04 PM

しんどい

あれ？ os_log ってそもそも可変長の CVarArg... が提供されてますよね？

CVarArg... を CVarArg... のまま渡せない。

引数の順番を並び替えたかったってことですか？

(すくなくとも発見できなかった)

はい、可変長引数の転送は確かにできないです。

まず、os_log はiOS12以前と以降で引数の順番がかわっててですね

6:06 PM

iOS12以前のやつはキモい順番なので使いたくないんですが

マジｗ

6:06 PM

しらなかた。

os_log(message, type:, ...) はiOS12以前でも動く

6:07 PM

os_log(type:, log:, message, CVarAg ...) (よりナチュラル)なのはiOS12以降

書式文字列とパラメータの間にtypeがあるのヤバいな。

そこでこのようなキモいwrapperを書くと幸せ（かつ将来の以降が簡単）なんだけど

なるほどですね

キモい

6:08 PM

Tuple1 〜 Tuple22 を思い出す実装となっています

22 まであるのScalaっぽいな

6:08 PM

あれ、17だっけ

22以上は設計の問題という話

6:09 PM

22だったはず

6:09 PM

21かな？なんかそれくらい

ですよね　なんか変な数

6:09 PM

配列から可変長パラメータへのsplat展開は

va_listなos_logがあればwith_valistで解決するんだけど...

まあまあ話題に上がるんですけどあんまり進まないっすね

6:09 PM

va_list版は公開されてないんですね。

os_log系以外では多分使われない？

6:10 PM

そうなんですよ。_swift_os_logとかそんな名前

Cの全ての可変長引数関数はva_list版を提供すべきだと思うんだけど。

6:10 PM

転送できないから。C言語だけ考えたときにも。

https://github.com/apple/swift/blob/master/stdlib/public/Darwin/os/os_log.swift

https://github.com/apple/swift/blob/4008261ab8a7b938469bc6cd0141a048030bcdd9/stdlib/public/Darwin/os/os.m#L69-L105

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

あ、まあプリプロセッサ展開はあるけど

os_logがそもそもマクロだから...

https://github.com/apple/swift/blob/master/lib/SILOptimizer/Mandatory/OSLogOptimization.cpp

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

6:14 PM

よくわかんなかった。

6:17 PM

ObjC版はマクロだからこんな感じのあれに展開されてるのかな。 (edited)

_os_log_implがAPIの実態で、os_logはAPIでマクロだったはず

なるほど。。

os_logがマクロなのは、loggingを無効にしたときにマクロレベルで抹消するためと思われる

6:21 PM

swiftからつかったらどうなるのよという部分はよくわからないけれど

6:22 PM

到達できないようになって最適化で消えるのかな...

6:22 PM

という気持ちだけある

os_log向けのoptimizer passがあった気がするな。

やはり

PASS(OSLogOptimization, "os-log-optimization", "Optimize os log calls")

os_logはいろいろ厳しい

https://forums.swift.org/t/se-0279-multiple-trailing-closures-amended/35435

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

tryEliminateOSLogMessage

ビルドスイッチとはまた別の最適化っぽい？

6:25 PM

書式文字列の中に定数を埋め込むとかなんとか

ですね

6:27 PM

消える機能みたいなのはないのかも。

#define os_log_with_type(log, type, format, ...) __extension__({ \ os_log_t _log_tmp = (log); \ os_log_type_t _type_tmp = (type); \ if (os_log_type_enabled(_log_tmp, _type_tmp)) { \ OS_LOG_CALL_WITH_FORMAT(_os_log_impl, \ (&__dso_handle, _log_tmp, _type_tmp), format, ##__VA_ARGS__); \ } \ })

6:31 PM

API_AVAILABLE(macos(10.12), ios(10.0), watchos(3.0), tvos(10.0)) OS_EXPORT OS_NOTHROW OS_WARN_RESULT OS_PURE bool os_log_type_enabled(os_log_t oslog, os_log_type_t type);

6:31 PM

スイッチになってるos_log_type_enabled がシステムAPIなので

6:31 PM

ビルド時の削除は無いかも？

6:31 PM

#define os_log(log, format, ...) \ os_log_with_type(log, OS_LOG_TYPE_DEFAULT, format, ##__VA_ARGS__)

6:32 PM

#define os_log は一箇所しか無さそう。

おってみたらそうですね

6:32 PM

自分で #define したら消せる

なるほど！ｗ

6:33 PM

そうするとこれがマクロなのは、インライン化の強制と、可変長引数の転送のゼロコスト化が目的かな？

それっぽいですね

6:35 PM

いづれにせよ、swiftから使うのはいろいろしんどい...

SE-0279: Multiple Trailing Closures [Amended]

The second review of SE-0279 — Multiple Trailing Closures begins now and runs through April 24, 2020. This is the second review, with a modified proposal. The core team has considered the feedback from the first review and believes that: the underlying motivation for the p...

>>2 で jroseさんがラベルの消える想定してる位置違くない？の件を突っ込んでてワロタ

https://forums.swift.org/t/se-0279-multiple-trailing-closures-amended/35435/2

it also feels weird to me that all of these are the same call:

foo(bar: { provideBar() }, baz: { provideBaz() }, garply: { provideGarply() }) foo(bar: { provideBar() }, baz: { provideBaz() }) { provideGarply() } foo(bar: { provideBar() }) { provideBaz() } garply: { provideGarply() } foo() { provideBar() } baz: { provideBaz() } garply: { provideGarply() }

SE-0279: Multiple Trailing Closures [Amended]

I understand how existing syntax encourages removing the argument label from the first trailing closure rather than the final trailing closure, but I'm worried that this puts us at odds with APIs designed for pre-Swift-5 code, which would put the "heaviest" closure last and "l...

2:22 AM

同じの見てたｗ

2:23 AM

omochimetaru が言ってるのは↓の方か。

I understand how existing syntax encourages removing the argument label from the first trailing closure rather than the final trailing closure, but I'm worried that this puts us at odds with APIs designed for pre-Swift-5 code, which would put the "heaviest" closure last and "light" ones in the middle in order to make existing trailing closure syntax feel natural

そう。

2:24 AM

詳細のところのfooの例も面白いですね。結局、好きなところを一つだけラベル消せるのね

2:25 AM

お〜　ラトナーがシュッと+1してる

これヤバさあるよねｗ < 好きなところを一つだけ消せる

2:25 AM

初っ端から元Apple社員の jrose さんによる反論が出て「いいね」集めまくってて荒れそうだ・・・。 (edited)

ラトナーが反対してたポイントは直ってるから態度に一貫性がある

2:25 AM

>>2 にハート多いの面白いですねｗ

なるほど。 < ラトナー

前スレはラトナー vs Dorg(プロポーザルオーサー) なシーンがあってアツかった

まあでも元から traling closure のラベル消せるのにも違和感あったし、どこでも消せるのが変ってのは今更な気もするなぁ。 (edited)

まあ確かに。一個消えるのはもともとあった謎要素だから、

2:28 AM

それが拡張された結果、消しゴムが移動するようになったのは

2:28 AM

自然か？ｗ

せめて既存 API と衝突しないように、ラベルを省略しないオプションがあってもいいと思うんだけどなぁ。

2:29 AM

というか、これサポートされたからって使う？ animate でも普通に () で書きそう・・・。

僕はXcodeのインデントが治るのとセットなら使いますね

2:30 AM

記号やネストの数が減るやつは使える限り使ってる

2:31 AM

今はtrailing closureすら、Xcodeが変なインデントするケースでは使ってないけど。

2:31 AM

インデントがちゃんとするのは前提で。

view.animate(withDuration: 5.0, animations: { // some code }, completion: { isFinished in // some code }) ↑で困ってないんだよなぁ。

2:32 AM

ネストって言ってもインデント深くなってないし。

末尾の }) は目がちょっと目がチカチカする。

2:34 AM

２つ重なって }) }) とかなると　やだ。

2:35 AM

ま〜でも animate の場合は、 completion も使う時は ( ) で書く気もするななんか不揃いで気持ち悪いから。

カーソル併せたら ( と ) の対応示してくれて、クロージャがたくさんのときは、かえってどこからどこまで関数コールだったのかわかりやすくて良い気も。 (edited)

2:36 AM

SE-0279 の提案に偶然ぴったりの animations: 省略がマッチしてる animate でもそれなんだから、他の API で使いたくなるのかな・・・。

ちなみに、インデントは次のバージョンではこうなります (2スペース設定で)

view.animate(withDuration: 5.0, animations: { // some code }, completion: { isFinished in // some code }) view.animate(withDuration: 5.0, animations: { // some code }, completion: { isFinished in // some code }) view.animate( withDuration: 5.0, animations: { // some code }, completion: { isFinished in // some code })

(edited)

view.animate( withDuration: 5.0, animations: { // some code }, completion: { isFinished in // some code }) ^ 私はこの中ならこう書く。インデントだけの好みなら。

2:38 AM

１番上もアリ。

@Kishikawa Katsumi 二つ目の // some code のインデントはミスですよね？

↑僕がミスったから

2番目はカッコの次に引数の頭が揃うわけではない？ (edited)

ああ、なるほど。

ついにクロージャーのインデントが奇麗に！

2:40 AM

今まで手動でそのインデントにしてました

2:40 AM

2番目の奴

2:40 AM

個人的には最後の}と)を改行するのが好きだけどまあ誤差

私も手で直して

// Default .receive(on: RunLoop.main) .sink { [weak self] in guard let self = self else { return } self.coordinator.onThumbnailCollectionViewSelectionChange() } .store(in: &cancellables) // Modified thumbnailCollectionView.onSelectionChange .receive(on: RunLoop.main) .sink { [weak self] in guard let self = self else { return } self.coordinator.onThumbnailCollectionViewSelectionChange() } .store(in: &cancellables)

^ こうしてた。 (edited)

昨日 tarunon さんが挙げてた↓とかも辛そうな気が・・・。それとも Button にとっては action こそが本質なのかな。 Button { print("hello world") } label: { HStack { ... } }

(デフォルトだと最後の.storeが左に寄っちゃう。)

@tarunon 2番目、メソッド名が長いと辛くないですか？

うーん、必要に応じて.の前に改行挟むので

2番目は１個のクロージャでいきなり始まりが右に飛んでしまうのが（私は）読みにくいですね。 (edited)

view .animate( withDuration: 5.0, animations: { // some code }, completion: { isFinished in // some code } ) こういう書き方が多かったかな。メソッドチェーンあるなら確実にこうする。

foo.bar.baz .superUltraVeryLongLongLongNameMethod(a: 42, b: "XYZ", c: true)

あ、2番目じゃなくて3番目だった

koherさんの例だと、〜Method(のところで（最初の引数ラベルの前）（私は）改行します。 (edited)

それだと 3 番目ですよね？ tarunon さんも 3 番目だし、 2 番目ユーザーはいないのかな？

最初は挙動を知らなかったから2 番目で書いてましたが。。。

僕も長い場合は 3 番目も使います。 ) を次の行にしてましたが・・・。

Appleのコード見てるとイニシャライザとかカッコの後で改行してるなあと思ってやってみたら「なるほど」という感じで転向しました。 (edited)

なので tarunon さんが書いた animate の例とまったく同じかな。

2:49 AM

. 前で改行するなら tarunon さんのとまったく同じで、改行しないなら view.animate( withDuration: 5.0, animations: { // some code }, completion: { isFinished in // some code } )

2:50 AM

もし trailing comma が採用されるなら ) の前に改行して , おいた方がうれしい気が。

改行あると各コンテキストが全てインデントによって整理されるので嬉しい

1

2:51 AM

まあ無くても終端はわかるのでいいっちゃいいんですが

↓とかも ] 前に改行するしなぁ。 let a = [ 2, 3, 5, ]

ちなみに、インデントは次のバージョンではこうなります (2スペース設定で)

おおお

僕は圧倒的に)前改行無しです。。

@rintaro 仮に trailing comma がサポートされた場合はどうですか？ foo( a: 42, b: "XYZ", c: true, ) foo( a: 42, b: "XYZ", c: true, d: 0.0, ) (edited)

メソッドチェーンしてるときが特に変になるからそれも気になる。

↑デフォルト値ある引数に値渡すときに、 diff がその行で完結する。 (edited)

trailing comma 採用して欲しくない理由があって、 foo.bar( arg: 1<カーソル>) この状態からリターンキー押したときに、カンマがあれば arg: に揃える、無ければ foo に揃えるっていうのが出来るんですが、trailing comma 採用すると判断がつかない。 (edited)

後ろの)で判定するのじゃだめなんですか？

なるほどー、考えたことないポイントでした。おもしろい・・・。

コードフォーマットは書いてる途中はどうでもいいので保存したタイミングとかで一定のフォーマットに整ってくれた方が嬉しいですね。よくあるPrettierの挙動。

foo.bar( arg: 1, <カーソル>) この状態で、例えば 1 入力して終了したいとき、それだけだとインデントがトリガーされないんですよね。

3:02 AM

じゃあ配列リテラルはどうなんだっていう話ではあります。

常に)に揃えて改行して、改行したその先で何かタイプされたらその時点でインデントするみたいな、遅延評価だとうまくいく気がする

行頭になにか入力されたらインデントトリガーするようになれば良さそう。

foo.bar( arg:1|) foo.bar( arg:1 |) foo.bar( arg:1, b|) こういう感じ (edited)

3:05 AM

,も補完するのかな?w (edited)

今は Preferences > Text Editing > Syntax Aware Editing > Indent when typing でチェック入ってるものしかトリガーしないのです。

3:09 AM

あー、一行で書いてたのを複数行に直すシナリオはあるけど、そのときは結局直さないといけなさそうな。

最初の状態からリターンキーで次の状態に移行しちゃうと、)前改行なし派が怒りそう。

それは設定で変えられるようにするかでしょうか。でも岸川さんの言うように、フォーマッターがよろしくやってくれたらそれでいいですね。

私は書いてる途中は複雑なことはしてくれなくていいです。この例だと、 foo.bar(|) foo.bar( |)

Eclipse 時代に Java のフォーマッターに慣れ親しんでたので、標準が機械的に決めてくれるなら従います。

こうかな。

3:14 AM

カッコのあととかはインデントを下げる、というのはやって欲しいけど（さすがに書きにくい）、あとは書き終わったら保存するのでそこで変わってくれればいいです。

保存時に自動フォーマット大抵はうれしいけど、一部フォーマット変えてほしくないコードとかあるから難しいですよね

↓みたいな。

var board = ReversiBoard([ "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "o", "x", "-", "-", "-", "-", "-", "-", "x", "o", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", "-", ])

3:17 AM

Eclipse はこういうやつも破壊してきました・・・。

そういうのは // prettier-ignore っていうのがあるからそれを付けます (edited)

なるほど。

JSのprettierのデフォルトだと三項演算子を積極的に改行しようとするので、たまに付けますね（私は）。

3:20 AM

まあXcodeのできるだけ現状の状態を汲み取ってくれる、みたいな挙動はけっこう好きですが。

フォーマットとインデントの違いですね。インデントは行頭の空白文字しか調整しないけど、フォーマットは改行位置も行中空白文字も変えてくる。

3:23 AM

僕はインデンタがまともなら選択して Ctrl + i でとりあえず十分です。

なるほどXcodeでペーストしたときに実行されてるのは「Re-indent」でFormatはやってない、、ということなんですね。

はい、Xcodeには現状フォーマットの機能は無いです。

行中の空白文字は整えてくれるとうれしいですね。抜けちゃってるケースがあると気になるし。

なるほど。前にフォーマッタを作ったときにできるだけXcode風の現状の様子を生かしつつフォーマットしよう、みたいなのを作ったけど、あれはインデントとフォーマットを分ければ済んだ話だったのか。。。

1 ... 100 を 1...100 と書いてしまったり。

swift-formatがXcodeに導入されるのを祈りましょう。

1

Multiple trailing closure ですが、

Section { Text("Foo") } header: { /* some code */ } footer: { /* some code */ } Section { Text("Foo") } header: { /* some code */ } footer: { /* some code */ }

どちらが良いと思います？

1

後者かな。。。？あまり自信ないけど、たぶん後者。

3:35 AM

いや、前かな。。。

3:35 AM

（どっちでも良さそう

）

if foo { /* some code */ } else { /* some code */ } っていうのを考えると前者なのかなー。いずれにしても、こういう風に書かれることはほとんどなさそうですね。

僕も後者ですねー。見た目は似てるけど文と式だし、区別されてた方が良さそうな気が。 (edited)

1

インデント絡みで言うと、もし時間あったらnightlyのツールチェーンで全選択 Ctrl + i 試してみてください。気に入らないインデントになったら bugs に是非！

https://discordapp.com/channels/291054398077927425/291054454793306112/691905724468428811 ^ このデフォルトパラメータの有無（とトップレベル関数かどうか）でオーバーロードの解決が変わる事象について遅くなったけど聞いてみました。 https://bugs.swift.org/browse/SR-12630

snapshot 2020-04-15 をXcode11.4.1に設定してインデントしてみたけど、一番気になってるやつは変わってなかった。

 let files = try fm.contentsOfDirectory(at: dir, includingPropertiesForKeys: nil) .filter ({ (file) in var isDir = false return fm.fileExists(at: file, isDirectory: &isDir) && !isDir }).map { $0.lastPathComponent }

↑これはOK

 let files = try fm.contentsOfDirectory(at: dir, includingPropertiesForKeys: nil) .filter { (file) in var isDir = false return fm.fileExists(at: file, isDirectory: &isDir) && !isDir }.map { $0.lastPathComponent }

↑これが嫌今度要望出します

むむ、僕の環境 (Version 11.4 (11E146), Toolchain: Swift Development Snapshot 2020-04-19 (a)) ではこうなります。

 let files = try fm.contentsOfDirectory(at: dir, includingPropertiesForKeys: nil) .filter { (file) in var isDir = false return fm.fileExists(at: file, isDirectory: &isDir) && !isDir }.map { $0.lastPathComponent }

Trunk のスナップショットで試してます？

あ〜　こっちは5.2.2だから新しいの入ってないのか

4:01 PM

trunkじゃなかったです、すいません

4:02 PM

一番上がmasterだと勘違いした

1

4:05 PM

 let files = try fm.contentsOfDirectory(at: dir, includingPropertiesForKeys: nil) .filter { (file) in var isDir = false return fm.fileExists(at: file, isDirectory: &isDir) && !isDir }.map { $0.lastPathComponent }

4:05 PM

おお、きた

4:06 PM

てか2段下がるんですね。

二段というか、let ではなくて files に対してインデントしていますね。理由としては

4:08 PM

let val1 = foo .bar(), val2 = 1 みたいなときに、letに相対しちゃうと例えば2スペースインデントだと let val1 = foo .var(), val2 = 1 になってしまう。 (edited)

なるほど〜

let じゃない普通の代入のときには1インデントになります。 foo = bar .baz()

このツールチェインで作業したかったけど、ビルドしようとしたら別のところでコンパイラクラッシュしてしまった (edited)

お

https://github.com/omochi/WeaselRoll

4:43 PM

↑masterをビルドすると GLKVector3Ex.swift で怪しいassertion failureしました

超コーナーケースな Swift 5.2 の変な挙動見つけました。最適化の問題だと思います。 @swift-5.2.5 -O

class Foo { private let deinitBody: () -> Void init(_ deinitBody: @escaping () -> Void) { self.deinitBody = deinitBody } deinit { deinitBody() } } func main() { var a = 42 var foo = Foo {} foo = Foo { a = -1 } let _ = foo // to ignore warnings print(a) } main()

-1

@swift-5.2.5

class Foo { private let deinitBody: () -> Void init(_ deinitBody: @escaping () -> Void) { self.deinitBody = deinitBody } deinit { deinitBody() } } func main() { var a = 42 var foo = Foo {} foo = Foo { a = -1 } let _ = foo // to ignore warnings print(a) } main()

42

@swift-5.1.5 -O

class Foo { private let deinitBody: () -> Void init(_ deinitBody: @escaping () -> Void) { self.deinitBody = deinitBody } deinit { deinitBody() } } func main() { var a = 42 var foo = Foo {} foo = Foo { a = -1 } let _ = foo // to ignore warnings print(a) } main()

42

Swift 5.2 においてだけ、最適化有効にするだけで挙動が変わる。

deinitとprintの前後ですかね？ (edited)

はい。

4:08 AM

バグなのか許された最適化なのかわかりません。

Swiftはスタック変数の削除は

4:08 AM

使わないところですぐ消しても良いし、

4:09 AM

スコープ抜ける末尾でも良い

4:09 AM

そこは定まってないから

へー

ある範囲まで寿命を引っ張りたいなら

4:09 AM

使用を明記する必要があります

4:09 AM

標準ライブラリの中だとたしかfixLifetimeって

4:10 AM

ユーティリティ関数でそれをやってる

@swift-5.2.5 -O

class Foo { private let deinitBody: () -> Void init(_ deinitBody: @escaping () -> Void) { self.deinitBody = deinitBody } deinit { deinitBody() } } func main() { var a = 42 var foo = Foo {} foo = Foo { a = -1 } defer { let _ = foo } print(a) } main()

42

とりあえず↑で引っ張れたけど、 let _ = foo は最適化で削除される可能性もあるかな？

let _ = a 式を削除して良いのかどうかは良く知らない経験的には消えなくて、寿命引っ張れるんだけど

4:14 AM

最適化を無効化してある関数の呼び出しに渡すのが確実そう。

4:15 AM

https://github.com/apple/swift/blob/6636815568efa8af5a62bbd68d585691d981a82b/stdlib/public/core/LifetimeManager.swift#L50

https://discordapp.com/channels/291054398077927425/380329942505750529/433106939640152066

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

withExtendedLifetime これ使うのが良いのかな

Builtinだ・・・

4:15 AM

あ！それっぽい

生存期間保証するためにはこの関数使うのがヨシ、みたいな

4:15 AM

ここでやった記憶ある

4:16 AM

おおお、こんな関数が・・・

koherもコメントしててワロタ

koherさんディスカッションに参加してますよw

タルノンよく覚えてんなあ

はい、それみてワラタ

だいたい全部覚えてる

すごい

いつの間にかif文の条件の中のTrailing Closureがコンパイルできるようになってたんですね。紛らわしいからカッコをつけろ、って警告に変わった。

7:52 PM

結局直すことになるのは変わらないけど。

@swift-5.2.5 if [true, false].reduce(true) { $0 || $1 } { print("Hello") }

Hellostderr:

<stdin>:1:31: warning: trailing closure in this context is confusable with the body of the statement; pass as a parenthesized argument to silence this warning if [true, false].reduce(true) { $0 || $1 } { ~~^ , )

ほんとだ・・・。

@swift-5.1.5 @swift-5.2.5 if true == [true, false].reduce(true) { $0 || $1 } { print("Hello") }

Hello

Hellostderr:

<stdin>:1:39: warning: trailing closure in this context is confusable with the body of the statement; pass as a parenthesized argument to silence this warning if true == [true, false].reduce(true) { $0 || $1 } { ~~^ , )

っていう5.1.5のバグを直してコンパイルエラーにすると、ソース互換性が崩れてしまうので、警告に統一しました。

何事もなく通るようになってた時期があったんですね

一番外側が trailing closure でのコールじゃない限り通ってましたね。僕の例だと == がAST上では外側です。

あー、 == があるんですね。見落としてました。

https://github.com/omochi/WeaselRoll/blob/master/Sources/WeaselRoll/Geometry/PointProtocol.swift https://github.com/omochi/WeaselRoll/blob/master/Sources/WeaselRoll/Geometry/RectProtocol.swift https://github.com/omochi/WeaselRoll/blob/master/Sources/WeaselRoll/Geometry/SizeProtocol.swift

Contribute to omochi/WeaselRoll development by creating an account on GitHub.

Contribute to omochi/WeaselRoll development by creating an account on GitHub.

Contribute to omochi/WeaselRoll development by creating an account on GitHub.

4:52 PM

3つのプロトコルが相互に参照しあってる定義を作ったら、Xcode11.4ではビルドできるけど11.3ではできなくて微調整すると11.3でも11.4でも、コンパイルエラーやらリンクエラーやらプロセスクラッシュやら

4:53 PM

ありとあらゆるコンパイラの死に方をして何もわからなくて2時間ほど溶かした・・・

4:53 PM

昔からこういうのできないけどそろそろいけるんじゃねえかと思ったら全然ダメだった、一度通った実装は針の穴を通すような成功例だった

4:54 PM

ワークアラウンドとしてprotocolの定義の方では循環するような関係を定義しないでおいて、必要に応じてメソッドの実装するところで最低限の == 関係を注入するように書いたら行けた。

ありとあらゆるコンパイラの死に方

恐ろしい

1

全然通せなくて笑っちゃったｗ

コンパイラを拷問する100の方法

4:58 PM

著: おもちメタル

イメージ的には CGPoint, CGSize, CGRect みたいな3つのグループを

4:58 PM

Point, Size, Rect　と IntPoint, IntSize, IntRect みたいに

4:58 PM

他にも作れるようにしたかった。

これは使い方はどうなるんですか？ (edited)

5:01 PM

public struct IntRect: RectProtocol { public typealias Element = Int public typealias SizeType = IntSize public var origin: IntPoint public var size: IntSize public init(origin: IntPoint, size: IntSize) { self.origin = origin self.size = size } }

CGRectって要素がCGFloatなのが不便なので、FloatになってるRectとIntになってるIntRectを作りました

これか。

あ、それtypealias足りて無さそう・・・

5:03 PM

画像サイズとか扱おうとした時に

5:03 PM

整数ピッタリじゃない可能性とかがあって気持ち悪いことがよくある

これを実現するのにコンパイラとの格闘が必要になるんですね。

そうなんです

もっと簡単にできても良さそうな気がするけど

 public func transform<R: RectProtocol>(_ rect: R) -> [R.PointType] where R.Element: BinaryFloatingPoint { let points: [R.PointType] = [ rect.topLeft, rect.topRight, rect.bottomLeft, rect.bottomRight ] return points.map { (p) in transform(p.toGLKVector().to3(z: 0)).to2().toPoint().to(type: R.PointType.self) } }

5:05 PM

↑恩恵の一つがGLKMAtrix4.swift のこれで (edited)

5:06 PM

Rectを行列で変換すると(直角じゃない場合もあるので) 変換された4つの座標が返ってくるんですが

5:06 PM

CGRectを回転したらCGPointの配列が返ってくるし、 Rectを回転したらPointの配列が返ってくるって機能をひとまとめに実装できている。 (edited)

そこでProtocol Extensionの恩恵が受けられるのですね

5:24 PM

Genericsの、かな？

両方混ざってますね。中に出てくる toGLKVector() とか toPoint() は Generic な Protocol Extension なので。

Swifc かわいそう

かわいそうなのはこちらでは！？

:シマリスくんの画像:

1

ObjectIdentifier 、同じプロセス中でもオブジェクトが解放された後なら被ることがあるのか。仕組み的に当たり前？ @swift-5.2.5

class Foo {} var identifiers: Set<ObjectIdentifier> = [] for i in 0 ... 10 { identifiers.insert(ObjectIdentifier(Foo())) print("\(i): \(identifiers.count)") }

(edited)

0: 1 1: 2 2: 2 3: 2 4: 2 5: 2 6: 2 7: 2 8: 2 9: 2 10: 2 (edited)

そうですね。ObjectIdentifierが参照型を指している場合はretainする設計だったらそうはならなかったですけど

2:47 AM

まあ必要だったら自分でObjectIdentifierとAnyObjectのペアの型を作って管理すればよいから

2:47 AM

そういう意味では部品としては余計な副作用がなくてよかったと思う。

うーん、思わぬバグを生んでしまうケースもありそうな？

まあそれは仕様を知らないとバグるのはなんでもそうでは

Collection のIndex が内容変わると無効になる可能性があるのと同じような話だと思うのですが、ドキュメントに書いてあってもよさそう。

おお、その例は面白い。確かに同じだ。

ポインタのint値を使っても同じことは起き得るので、被らないようにするのはコスパが悪そうな気がしますね

コスパは悪いと思います。ただ、ドキュメントはほしいですね。 https://developer.apple.com/documentation/swift/objectidentifier

ドキュメンテーション足すのもPR投げれるのでは

なるほど。

2:56 AM

doc comment から生成されてるのか。

だと思いました

ドキュメンテーションの PR は英語添削がヤバそうですねｗ

今なら educational note というアツいやつがありますよ

2:56 AM

koher とかめちゃくちゃコントリビュートできそう

↓これ？ https://github.com/apple/swift/blob/4c4a55f651ab87b946fdb1a53ecf838a1033a4b8/docs/Diagnostics.md#educational-notes

3:02 AM

https://github.com/apple/swift/tree/master/userdocs/diagnostics まだ6個しかない

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

3:03 AM

GSoCにdiagnostics localizationのプロジェクトがあるから、おいおいコレの日本語版を作るタスクも発生するはず

localization版はただの翻訳作業になりそう。そして、英語を書くと↓になりそう

3:04 AM

3:06 AM

↓が送信エラーになってた。

↓これ？ https://github.com/apple/swift/blob/4c4a55f651ab87b946fdb1a53ecf838a1033a4b8/docs/Diagnostics.md#educational-notes

[Pitch] Make Never the bottom type

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

それ。

英語ネイティブじゃなければ添削祭になるのはもう仕方ない、ドキュメントを足そうという最初の一手を入れるか入れないかでしかないので添削は甘んじて受けて良いと思うのですが

3:08 AM

足さなければ永遠に足されないままなので

コードレビューと違って、ノンネイティブの自然言語による文章の添削はレビュー側にとっても高コストな気がするんですよね。それでも書いてもらった方がありがたいというのであれば PR ありだと思うんですが。

「最初の一手を入れるかどうか」と言う判断が問題意識を持った人間にしか出来ないので、ここで誰かが手を入れなければ誰も手を入れない、と言うことです

きっとまたrayfixさんが直してくれる（？）

ｗ < rayfix さん (edited)

3:18 AM

「最初の一手を入れるかどうか」と言う判断が問題意識を持った人間にしか出来ない

確かにそれはそうなので、今回は一文足す程度でも良いし、 PR 送ってみるのが良さそうですね。

koher が出す話題がこれにちょうど良さそうなやつが多い気がするんですよね今思い返してたんだけどArraySliceのインデックスがズレるやつとか。

3:20 AM

ただコンパイルエラーに起因して出てくるからどう仕込むかが難しいけど・・・多分Xcodeだと「FixIt」みたいなかんじで「詳しく知る」みたいなボタンが出るんだと思う

おもしろそうだし興味あるけど、やっぱり英語がネックだなぁ。ドキュメンテーションのための文章はクオリティが求められるだろうし。まあでも、それで PR で添削してもらえるのなら英語力向上には良さそうだ

気持ちはわかる。プルリク出した時に、「ここなんでこうなるの？」って聞かれて説明すると「なるほどね、それコメントに書いといてよ」って言われるんだけどそこで結構困る

3:23 AM

あとエラーメッセージ実装するときとかも・・・

コード書くよりむずいよね

そう・・・

何でも良ければ書けるけど、多分ネイティブが読むと「てにをは」がぐちゃぐちゃな日本語読んでる感じなんだろうなぁと・・・。

3:27 AM

不自然な言い回しや単語、前置詞チョイスとか。

我々が日本語母語でない人間のてにをはぐちゃぐちゃテキストを見ても何も思わないのと一緒で、向こうもまあ修正しとこか、ぐらいにしか思わないんじゃないかしら (edited)

1

まあ、今回の件やエラーメッセージくらいだとそうだと思います。 Educational Note みたいなのになってくると、小手先の修正ではどうにもならなくて、意図を読み取って全部書き直すみたいなことにならないかなと。

ObjectIdentifierをキャッシュのキーにして被ってバグったことある。 (edited)

1

複数スレッドでメモリ確保・開放ってしてると、被って誤動作する頻度が下がって、見つけづらいバグになる。

キャッシュのキーにする場合、もしretainする仕様だったら、キャッシュのせいでオブジェクトがリークしてしまうから、

3:49 AM

その場合はweak retainしていてくれたら良かったやつですね。

Never を bottom type にする Proposal https://forums.swift.org/t/pitch-make-never-the-bottom-type/36013

Hi all, Since it's come up again in discussion recently, I wanted to share my proposal for making Never a true bottom type in Swift. This is partially implemented here, though there remains work to be done before it's ready for review. In the meantime, I'd be interested in he...

2

お

4:59 PM

Nothing 相当かな

ですね。

https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md Multiple trailing closureはいまだに賛否両論で、私が見える範囲だといやがる人の方が多そうに見える。私自身はこれに関しては全然興味なくて、変わっても変わらなくてもどっちでも良くて決まったものを使うだけだけど、これだけに限らず今後Swiftに変更を加える上でソースコードの破壊的変更をしない、ということにこだわらなくてもいいんじゃないかという意見には同意したい。

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

protocolのassociatedtypeにoverrideが付けられる様なんですけど、どういう意味付けか知ってたりしませんか？ stdlibのCollection.Elementとかに付いてるんですけど、あんまりテストケースが無くてどういう使われ方をするのかいまいち分からない… https://github.com/apple/swift/blob/7e6d62dae4bae4eb3737a6f76c0e51534c1bcca3/stdlib/public/core/Collection.swift#L342

[Standard library] Audit protocol member overrides in protocols. · ...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

これかな？ https://github.com/apple/swift/commit/f8e53d912954e63f967fc6e0450731a40f4cc08b

Add the -warn-implicit-overrides flag when building the standard library and overlays, so that each protocol member that overrides a member of an inherited protocol will produce a warning unless ...

コメント5回位読み直してやっと少しわかりましたw

7:57 AM

@swift-main

enum GenericElement {} protocol MySequenceP { associatedtype Element associatedtype Iterator: IteratorProtocol where Iterator.Element == Element func makeIterator() -> Iterator } struct MyDefaultIterator: IteratorProtocol { func next() -> GenericElement? { return nil } } protocol MyCollectionP: MySequenceP { override associatedtype Element associatedtype Iterator = MyDefaultIterator } struct MyCustomIterator: IteratorProtocol { func next() -> GenericElement? { return nil } } struct MyCollection: MyCollectionP { typealias Element = GenericElement func makeIterator() -> MyCustomIterator { return .init() } }

exit status: 1 with stderr:

<stdin>:23:8: error: type 'MyCollection' does not conform to protocol 'MySequenceP' struct MyCollection: MyCollectionP { ^ <stdin>:25:10: note: candidate has non-matching type '() -> MyCustomIterator' [with Iterator = MyDefaultIterator] func makeIterator() -> MyCustomIterator { ^ <stdin>:7:10: note: protocol requires function 'makeIterator()' with type '() -> MyDefaultIterator'; do you want to add a stub? func makeIterator() -> Iterator ^

このとき MyCollection のIteratorを推論する材料として makeIterator が使われないので、assoctypeのデフォルト型と一致せず失敗するが、

8:00 AM

@swift-main

enum GenericElement {} protocol MySequenceP { associatedtype Element associatedtype Iterator: IteratorProtocol where Iterator.Element == Element func makeIterator() -> Iterator } struct MyDefaultIterator: IteratorProtocol { func next() -> GenericElement? { return nil } } protocol MyCollectionP: MySequenceP { override associatedtype Element associatedtype Iterator = MyDefaultIterator // Added override func makeIterator() -> Iterator } struct MyCustomIterator: IteratorProtocol { func next() -> GenericElement? { return nil } } struct MyCollection: MyCollectionP { typealias Element = GenericElement func makeIterator() -> MyCustomIterator { return .init() } }

no output

こうすると通るようになるのか

https://discordapp.com/channels/291054398077927425/291054454793306112/692696352810860564 ^ この @Published のプロパティを直接変更してもdidSetが呼ばれない件、Xcode 11.5で元の挙動に戻ってますね。

ほほー。

(edited)

protocolのデフォルト実装みたいなのを持たせる方法ってあるですかねー。

1:02 AM

ええと、

extension P { func f() {} } ? (edited)

そうじゃなくて (edited)

1:03 AM

この日本語はだめだ、えっと

ｗ

super呼びたい的な

protocol P があったときに、struct DefaultP: P みたいなのがあるとして

1:03 AM

この DefaultP の所在というか,

1:04 AM

val p: P = .default ってできたらいいなっていうか

ないですね enum Ps { static var default { DefaultP() } } とかでごまかすしか

1:04 AM

あ、まてよ

enum ...

1:05 AM

(あと、val じゃなくて let)

extension P { static var default: P { DefaultP() } } ↑こんな感じ？ (edited)

RxSwiftのDisposableなんかはおもちさんのenumの方法に近い実装になってますね

1:06 AM

だめかあ

existentialにstaticメソッドは持たせられないので

直感的な方法はダメだったんですよねえ

P.self が存在しないからできないんだなあ

そうだった

現実解はs付けたenumになると思います

厳しい...

あとはDIで注入させるとか？

SwiftUIで

1:08 AM

むりやりな方法でデフォルトっぽいのやってなかったっけ

1:08 AM

StaticValue<T: P> みたいなやつ

むむ？

結局廃止されたんだっけな、なんだっけ

DIを常に要求するっていうてもありますが、なんていうかうーん使い勝手が。

あとは無理やり型消去した AnyP.defaultP を作るとか？

SwiftUIのリファレンス見てきたけど廃止されている気がする

SwiftUI であったのは StaticMember ですね。廃止されました。

StaticMemberか。

1:14 AM

あれがまさに、protocolを受け取るところで .red とかやるためのものだった気がする、違うっけ

1:14 AM

https://forums.swift.org/t/protocol-metatype-extensions-to-better-support-swiftui/25469

Protocol metatype extensions (to better support SwiftUI)

Swift's dot shorthand for static factories is wonderful! Unfortunately, it currently requires a concrete type context in order to work. A while ago I pitched an idea for lifting this limitation. It turned out that the original idea in that pitch isn't viable, but the thread ...

1:14 AM

protocol ColorStyle { typealias Member = StaticMember<Self> } extension StaticMember where Base : ColorStyle { static var red: RedStyle.Member { return .init(.init()) } static var blue: BlueStyle.Member { return .init(.init()) } } extension View { func colorStyle<S : ColorStyle>(_ style: S.Member) -> some View { ... } } MyView().colorStyle(.red) MyView().colorStyle(.blue)

1:16 AM

これの問題点は、消費側で <S: ColorStyle> に対して、 (_ s: S) と (_ s: S.Member) の両方をオーバーロードしておかないといけないことだけど

変数はダメだけど、引数でDefaultPをとる実装をオーバーロードすると、確かに引数だけなら .default が使えそうですね

ふむー

確かにオーバーロードするんだったら DefaultP を取るだけが楽か。

implicit type conversion ってないですよね

ないです

toNankanoKata(): T (edited)

4:02 AM

みたいなの足してるのが一般的?

<T: CustomStringConvertible> T こういうので受け取れば、変換っぽくはみえるけど。

受け取りはコントロールできないからなあ

僕は .toHoge(): Hoge つくってますね。

4:04 AM

でも標準ライブラリだとあんまりそれはなくって

implicit ほしい

逆で、Hoge.init が T をうけとる

4:04 AM

APIが多いと思います

なるほど、、

T.toHoge() じゃなくて Hoge.init(T)

ふむー

4:05 AM

print() ってそういえばなんでも String にするけど

4:05 AM

どう言う理論なんだろう

printもそうですし "\(exp) これもそうですね

4:06 AM

結構やばい変換をいろいろやってますよ

String() が実はめっちゃ強い

4:06 AM

とかじゃなく。

CustomStringConvertibleとかCustomDebugStringConvertibleとかStringOutputStreamとか (edited)

4:06 AM

いろいろなプロトコルに動的にダウンキャストしてます (edited)

あー、なるほど

String(describing: Any) をつかってるんだったきがする

String(describing:) なのか。

4:07 AM

/// A type with a customized textual representation. /// /// Types that conform to the `CustomStringConvertible` protocol can provide /// their own representation to be used when converting an instance to a /// string. The `String(describing:)` initializer is the preferred way to /// convert an instance of *any* type to a string. If the passed instance /// conforms to `CustomStringConvertible`, the `String(describing:)` /// initializer and the `print(_:)` function use the instance's custom /// `description` property.

4:07 AM

ほんとだ

4:08 AM

print(_:) は直接使ってるわけじゃないのかな？

https://github.com/apple/swift-evolution/blob/master/proposals/0269-implicit-self-explicit-capture.md selfのキャプチャがシンプルになるやつ、次のSwiftに入るんですね。値型にselfが要らなくなるのはよい、[self]は実際にはほとんど使わないかな？

Swift の struct の stored property は var にしよう - Qiita

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

11:33 AM

いや、UIView.animateとかの明らかに循環参照しないことを誰でも知ってるやつには使うと便利だな。

1

PromiseとかSingleだと循環気にしなくて良いので、結構 [self] 使いたいかも

Promiseでも必要なときなかったでしたっけ？

Promise自体を永続して保持し続けるような状況(あんまりやらないと思うけど)だと必要になりそうですね。

11:47 AM

非同期処理を上から下に順番に流す基本的な使い方のときは大丈夫

extension Client { public func perform<Response>(request: Request<Response>) -> Future<Response, Error> where Response: Decodable { return Future<Response, Error> { [weak self] promise in self?.perform(request: request) { switch $0 { case .success(let response): promise(.success(response.body)) case .failure(let error): promise(.failure(error)) } } } } }

11:56 AM

^ こういうURLSessionのCompletionHandlerをFuture（Promise）にしてる実装があって、これはSinkする方で[weak self]しないとダメなんですけど呼び出される側の実装で回避できるかな？

11:57 AM

あ、これはそのさきのperformのCompletionHandlerをリトライのためにある程度保持するからかな？

11:58 AM

ちょっとまず自分でいろいろ確認してみます。

これを見る限りはFutureが終われば解放されそうに見えますねえ

それがこのコードを使う側は[weak self]にしないとViewControllerが解放されないんですよね。

ふむ・・・

import UIKit import Combine class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in let vc = ViewController2() self?.present(vc, animated: true) } } } class ViewController2: UIViewController { private var cancellables: Set<AnyCancellable> = [] deinit { print("deinit") } override func viewDidLoad() { super.viewDidLoad() Client.shared.perform(request: URLRequest(url: URL(string: "https://www.google.com")!)) .sink(receiveCompletion: { (completion) in print(completion) self.updateUI() }) { (response) in print(response) self.updateUI() } .store(in: &cancellables) } func updateUI() { } } class Client { static let shared = Client() private let session = URLSession(configuration: .default) private init() {} func perform(request: URLRequest) -> Future<URLResponse, Error> { return Future<URLResponse, Error> { [weak self] promise in self?.session.dataTask(with: request) { (data, response, error) in if let error = error { promise(.failure(error)) return } if let response = response { promise(.success(response)) return } } .resume() } } }

1:06 PM

^ 小さく再現できるコードだとこうなるんですけど、これはViewController2の self.updateUI() の呼び出しはweak selfじゃないとViewController2を閉じてもViewController2は解放されないんですよね。

このFutureは何度も開始できるObservableみたいな種類のものなのかな

1:25 PM

VC -> Set<AnyCancellable> -> Future -> VC のサイクルっぽい

RxSwiftのSingleだとここはリークしないんですか？

1:27 PM

リーク=>循環参照

しなかった。CombineのFutureとちょっと違うんですねえ。

1:40 PM

Futureも一度きりの動作に見えますね。

Futureが一度きりなら、クロージャ捨ててほしいけど、そうじゃないのか。

RxSwiftのSingleだと[weak self]だとコールバックが返る前に画面を閉じるとselfがなくなるのでコールバックの中の処理はスキップできる、Strong参照している場合はコールバックが返るまでselfが保持されるので画面を先に閉じてもコールバックの処理が実行できる。

1:47 PM

Combineは後者の振る舞いは諦めるか、コールバックの中をselfを使わないようにする必要がある。 (edited)

1:47 PM

今のところこういう違いがあるのか。

PromiseとかSingleだと循環気にしなくて良いので、結構 [self] 使いたいかも

こういうときでも VC が捨てられてから遅れて不要な処理が走るのが気持ち悪くて基本的に [weak self] + gurad let self = self else { return } してるなぁ。

それは同意します。確認が大変なので全部[weak self]でお願いしたい、というのも含まれていますが。

1:57 PM

^ 画面を閉じてもしたい処理がある、というのはあまりないという前提で。

VCについてはweak captureして、disposeBagをdisposeさせてます。

1:58 PM

この話の例だと、僕がstrong selfにしたいのは、Clientのメソッドの方ですね

確認が大変なので全部[weak self]でお願いしたい

これありますね。 weak ついてないときいちいち大丈夫か考えなきゃいけないし。

1:59 PM

guard let self = self else { return } がボイラープレートすぎて、 [weak self return] とかほしいです・・・。

Clientの方はStrongにできるかなあ。例ではSingletonにしているけどClientも不要になったら解放したいので。 (edited)

2:01 PM

weak selfの場合をなんとかしたい、というのは先のProposalで触れられてるけど対象外だから別の提案でなんとかしよう、とか書いてあったと思います。

2:01 PM

要するに別に何も変わらない

1

async/await が入ったときに、 await 後は weak キャプチャしたい場合ってどうなるんだろう。

2:03 PM

基本循環しないから大丈夫ってことになるのかな。

awaitもそうですね、Promise相当だからstrong selfだらけ

2:05 PM

Clientも不要になったら解放したい

これが、VC.deinit -> DisposeBag.dispose -> Singleのterminateで、解放される。

1

明示的にweakにしたければ、weak var weakSelf = self ってかいておいてそれ使うしかない気がする。 (edited)

await[weak self] とか。

2:22 PM

それができても、スコープが切られないからその後の gurad let self = self ... が許されなさそう・・・。 self が被って。 (edited)

2:23 PM

まあ strong で諦めることになるのかな。 await 後は self. 必須になるのかな？それならせめて await[self] はほしくなりそう。

await後はself不要のほうが自然なコードになって良いと思います

self. 必須って意図しない strong capture を防ぐためのものだと思うけど、 await なら基本循環しない（解放される）から意図しない strong capture があっても問題ないってこと？

はい。

3:11 PM

でも、deinitでキャンセルとかの仕組みと噛み合わない事はありそうですねえ。 (edited)

そもそも await の後ろはクロージャじゃなくて self のメソッドそのものだから、 self が解放されてるのはおかしいか。

あ～、たしかに。

awaitの下はコールバックの中だからselfが解放されていることはあるんじゃないですか？

async func がメソッドだった場合、

3:47 PM

メソッドの呼び出し中はselfがretainされているという規則があるから (edited)

3:47 PM

それの延長で考えるとってことです

あ、そういうルールがあるんですね。

3:47 PM

違うか、

ObjCのARCだとなかったんだけどSwiftだとある。 (edited)

awaitがあってもなくても

3:48 PM

メソッドの途中でselfが消えることはない、ってことですね。

3:49 PM

一般的な言語仕様として。

はい

view controller はかなり簡単にleakするので、

4:13 PM

weak を意図的に強制してるかつ debug では leak detection するロジックをいれてる (edited)

こういうときでも VC が捨てられてから遅れて不要な処理が走るのが気持ち悪くて

なるほど。全部weak書いてるつもりでもコールバックがネストしたら循環参照したりしたことがあったので、さらに検知する機構が入ってるのはいいですね。

かなりアレな実装だけど。view controllerのポインタ定期的にしらべて画面にでてるかどうかチェックという... (edited)

4:28 PM

でもVCがリークするのはほんとうに頻繁にあるので役には立っている。

4:28 PM

UIKitの仕組み上、VCはめっちゃ大量の所有をしているので一つのリークのインパクトがでかい (edited)

コールバックがネストしたら循環参照したり

ネストする場合も各段階で毎回 [weak self] してますね。ネストで循環参照したのはどこかの段階で [weak self] を忘れた場合ということですか？

4:34 PM

それとも全部書いても循環参照するパターンということですか？

全部書く、でOKなんですけど、どっちかではself使ってないみたいなときに書き忘れることがあったり

機械的に検出できるといいですよね。一応、どこかで書き忘れても self. を書かなければ大丈夫だと思うんで、 self. を書くときにキャプチャしようとしてると気付くかなと思いながら書いてます。

@swift-5.2.5 let range = 0 ... 10 print(range.startIndex < 0)

exit status: 1 with stderr:

<stdin>:2:24: error: referencing operator function '<' on 'BinaryInteger' requires that 'ClosedRange<Int>.Index' conform to 'BinaryInteger' print(range.startIndex < 0) ^ Swift.BinaryInteger:1:11: note: where 'Self' = 'ClosedRange<Int>.Index' extension BinaryInteger { ^

@swift-5.2.5 let range = 0 ..< 10 print(range.startIndex < 0)

false

この ClosedRange の挙動は仕様？

10:42 AM

なんかダメなケースがあった気が。

RangeとClosedRangeで違うのか。なんでだろう。

10:43 AM

いずれにしても、 .startIndex を Int と比較するのがそもそも変な感じはします。

Range<Int> の Index は Int じゃない？

10:44 AM

Array ならできるわけで。

Range<Int>.subscript に Range<Int>.Index を渡した結果の型は Int だと思うけど

10:45 AM

Range<Int>.Index 自体が Int である必要性はない

10:45 AM

性質的に Int でも全く問題ないですけど。

うーーん、どっちが良いとも言いづらいな。

10:47 AM

< については lowerBound と比較すればいいんだけど、 Range と ClosedRange の違いは気になる・・・。

10:49 AM

あと関係ないけど、 lowerBound が let であるのは、おもち理論↓的に必要なさそう？ https://qiita.com/omochimetaru/items/7265e440418b38088ccb

記事についてこの記事は potatotips#39 という勉強会で発表した内容を再掲したものです。スライドの画像と、喋った言葉を載せました。以下スライドそれではこれから、Swift の struct の st...

あ、lowerBoundは微妙ですね

10:51 AM

lowerBound <= upperBound という恒等式を満たさないといけないから

10:51 AM

lowerBound 単体で変更できるのはまずい

willSet で precondition かけたらどうだろう？

それはありかも。

10:54 AM

まあ、didSetでもいいです。

CoreTeam的には、基本的に制約があるプロパティは struct でも let の方針なのかな。

どうだろう。他にどんな型があるかな・・・

わからないけど、 lower/upperBound が let だったのが、さっき見つけて理解できるけど、そうなのかーと思ったので。

初歩的な質問で申し訳ないのですがSwiftでDiscord botを作成することってできますか？

できますよ

12:01 PM

https://github.com/Azoy/Sword

Azoy/Sword

Discord library for Swift. Contribute to Azoy/Sword development by creating an account on GitHub.

12:01 PM

僕が作ってみたときはこれ使いました

12:01 PM

https://github.com/nuclearace/SwiftDiscord

nuclearace/SwiftDiscord

Discord API Client for Swift. Contribute to nuclearace/SwiftDiscord development by creating an account on GitHub.

12:01 PM

こっちもある

ありがとうございます！今までdiscord.jsでしか作ったことがなくて、作って観れるのかなと思い　早速作ってみます

https://github.com/norio-nomura/SwiftCompilerDiscordappBot

norio-nomura/SwiftCompilerDiscordappBot

Swift Compiler Discordapp Bot. Contribute to norio-nomura/SwiftCompilerDiscordappBot development by creating an account on GitHub.

12:06 PM

nomuraさんが作ってるこのサーバにいるswiftコンパイルbotのコード↑ これもSwift製です (edited)

ありがとうございます!

ボットのホスティング環境のおすすめはございますか (edited)

Swift on Linuxならなんでも良さそう

了解です　ありがとうございます

https://github.com/vinivendra/Gryphon

vinivendra/Gryphon

The Swift to Kotlin translator. Contribute to vinivendra/Gryphon development by creating an account on GitHub.

8:06 AM

Swift to Kotlin translatorらしい。 Arrayが壊れまくりそう https://vinivendra.github.io/Gryphon/collections.html

Gryphon Tutorial

The Swift to Kotlin translator.

https://discordapp.com/channels/291054398077927425/291054454793306112/702188269319880784 これ変更されて、複数行に渡るときは let に対してインデントするようになります。

9:43 PM

https://github.com/apple/swift/pull/31941 let files = try some(at: nil) .filter { return ... }.map { ... }

[SourceKit/CodeFormat] Don't column-align PatternBindingDecl entrie...

Don't column align PBD entries if any entry spans from the same line as the var/let to another line. For example: // Previous behavior: let foo = someItem .getValue(), // Column-align...

1

.mapそこなのかあ

.map の位置は書き手次第ですよ。

なるほど

次行に書いた場合は let files = try some(at: nil) .filter { return ... } .map { ... }

このほうが最初の行と統一感があっていい

おお、ということはCombineのstore()も同じ位置になりますか？

NotificationCenter.default.publisher(for: UIApplication.keyboardWillChangeFrameNotification) .receive(on: RunLoop.main) .sink { [weak self] in self?.keyboardWillChangeFrame($0) } .store(in: &cancellables)

今までは } .store だけ手作業でインデントを直してました。

はい、意図通りのインデントになると思います。

3

やったー。ありがとうございます。

1

めっちゃいい

なんでやろう・・・UI調整してるときに，適当なコード書いたら，こんなコードで型推論が失敗した．

10:14 AM

10:15 AM

項が多いと，コケちゃうのかしら．

Floatとリテラルを混ぜると起こりがちな気がする

リテラルの足し算とか掛け算はめっちゃそうですね

そうなのかｗ

10:16 AM

height = self.view.safeAreaInsets.top + CGFloat(44 + 10 + 44 + 10 + 10)

10:16 AM

とりあえず，これで回避した．

いい感じ。

項の数で指数的に推論が重くなる

いい感じだけど、その足し算気になりますね。それ必要かな。SwiftUIだとしかたない気もするけど。

~~一番手っ取り早い方法だと型アノテーションだけつければ良くなる気が~~ (edited)

10:18 AM

あ、、

あ，調整中というか，雰囲気を調べるために高さとマージンを手で書いてました

すでにある変数への代入か、しつれいしましたｍｍ (edited)

1

なるほど。納得です

実際のときは，ちゃんと定数とかに置き直して，綺麗に書く予定

10:20 AM

いや，こんなところで型推論失敗しないと思い込んでて，コンパイルは長いわ，コンパイルが失敗してる理由を探し当てるのに四苦八苦しました．

失敗するんですよねぇ

https://qiita.com/freddi_/items/044bdf6defbbe434a8e2#comment-2fc63d4d19f07e8fc5e4 この記事のおもちさんのコメントを思い出した (edited)

Swiftの数値リテラルをﾁｮｯﾄﾀﾞｹ詳しく調べた話 - Qiita

こんにちは、freddiと申します。Swiftを始めて8ヶ月少々、最近は周囲の影響からかSwiftコンパイラやSILについてちょっと勉強し始めています。この記事は、「Swift Advent Calendar 2018」の14日目...

まぁそうか，選択肢が３つあって，リテラルが５個あったら，3^5の選択肢が・・・・・

そんな感じ

試してないんですけど、リテラルがFloatだったら大人しくなりそう？ ... + 44.0 + 20.0 + 56.0 みたいな

行けそうな気がする

10:31 AM

ko

10:31 AM

こけた

10:31 AM

10:32 AM

正直，CGFloatかましても，結構遅い

10:34 AM

if self.traitCollection.horizontalSizeClass == .regular { height = self.view.safeAreaInsets.top + CGFloat(44) + CGFloat(10) + CGFloat(10) } else { if self.view.bounds.size.width < self.view.bounds.size.height { height = self.view.safeAreaInsets.top + CGFloat(44) + CGFloat(10) + CGFloat(44) + CGFloat(10) + CGFloat(10) } else { height = self.view.safeAreaInsets.top + CGFloat(44) + CGFloat(10) + CGFloat(10) } }

10:34 AM

こうしたら，爆速になった

10:34 AM

めんどい

F()みたいに1文字の関数を用意するとか？

もう１個回避方法見つけた

10:37 AM

Intへの暗黙を狙うパターン

10:37 AM

let tmp = 44 + 10 + 44 + 10 + 10 height = self.view.safeAreaInsets.top + CGFloat(tmp)

10:37 AM

どちらにしても余計だけど，これが一番，理想に近い．

let tmp: CGFloatでもいけますか？ (edited)

いけた

あ〜 CGFloatが確かくせ者で

10:47 AM

これとリテラルを混ぜるとすぐコケるだった気がしてきた

CGFloatは32-bit/64-bitでもアレなとてもアレな型

6:38 PM

ところで44dp足すのはいろいろダメな気がする

それはそうw

リテラルの型推論の上で Float と CGFloat に何か違いってありますか？↑の CGFloat が仮にすべて Float だったとしても同じことが起こりそうに思うんですが（ import CoreGraphics した（ ExpressibleByFloatLiteral に適合した型が同じ数だけある）状態では）。

11:24 PM

Double は優先ルールがあるから違いがあるかもしれないけど。

FloatとCGFloatは同じはず

だよね。

Doubleだけが特別

ExpressibleByFloatLiteral に適合した型、 Double, Float, CGFloat だけじゃなく、たくさんあるっぽい。

Decimal DispatchQueue.SchedulerTimeType.Stride ImmediateScheduler.SchedulerTimeType.Stride MaterialScalarParameter NSDecimalNumber NSNumber OperationQueue.SchedulerTimeType.Stride RunLoop.SchedulerTimeType.Stride

https://developer.apple.com/documentation/swift/expressiblebyfloatliteral

11:26 PM

これに加えて BinaryFloatingPoint

11:26 PM

CGFloat Double Float Float80 https://developer.apple.com/documentation/swift/binaryfloatingpoint

多分探索されるのは適合してる型じゃなくって

11:27 PM

足し算のオーバーロードの方です

リテラルの組み合わせも考えてるんじゃないの？

いや、考えない感じがする　見落としがなければ。

11:30 PM

言い方を変えると、Decimalとして推論されるためには、多項式の中にDecimalが確定してる項がないといけない。

11:30 PM

あ、Decimalはオーバーロードがあるかな？

Decimal は SignedNumeric らしいからあるみたい。

11:32 PM

Stride 系も Numeric に適合してるね。

import なし (edited)

あー、しかも今リテラルは整数リテラル書いてるから、もっと数があるのか。

import Foundation (edited)

+ を持つ整数リテラルで記述できる型って山のようにあるよね。

Decimalの+はあるけど

11:35 PM

NSNumberの+は無いですね (edited)

うん、NSNumber はない。

11:35 PM

けど Stride 系はあるっぽい。

FloatingPointの+で済ませるんだと思う。

11:35 PM

プロトコルの+de

ん？ NSNumber は + できないんじゃないの？

アレ、本当だ

@swift-5.2.5 import Foundation let a: NSNumber = 2 let b: NSNumber = 3 print(a + b)

exit status: 1 with stderr:

<stdin>:4:9: error: binary operator '+' cannot be applied to two 'NSNumber' operands print(a + b) ~ ^ ~ <stdin>:4:9: note: overloads for '+' exist with these partially matching parameter lists: (Array<Element>, Array<Element>), (CGFloat, CGFloat), (Date, TimeInterval), (Decimal, Decimal), (DispatchTime, DispatchTimeInterval), (DispatchTime, Double), (DispatchWallTime, DispatchTimeInterval), (DispatchWallTime, Double), (Double, Double), (Float, Float), (Float80, Float80), (IndexPath, IndexPath), (Int, Int), (Int16, Int16), (Int32, Int32), (Int64, Int64), (Int8, Int8), (Measurement<UnitType>, Measurement<UnitType>), (Other, Self), (Self, Other), (Self, Self.Scalar), (Self, Self.Stride), (Self.Scalar, Self), (Self.Stride, Self), (String, String), (UInt, UInt), (UInt16, UInt16), (UInt32, UInt32), (UInt64, UInt64), (UInt8, UInt8) print(a + b) ^

ExpressibleByFloatLiteral じゃないのか？ (edited)

いや、 ExpressibleByFloatLiteral ではあるはず。

11:38 PM

@swift-5.2.5 import Foundation let a: NSNumber = 2.0 print(a)

2.0

AddtiveArithmetic ではない。

うひー FloatingPointでもAdditiveArithmeticでもねえのかｗ

11:39 PM

例が悪かった。

まあ、↓とか考えると・・・。 @swift-5.2.5 import Foundation let a: NSNumber = 2.0 let b: NSNumber = true print(a + b)

exit status: 1 with stderr:

<stdin>:4:9: error: binary operator '+' cannot be applied to two 'NSNumber' operands print(a + b) ~ ^ ~ <stdin>:4:9: note: overloads for '+' exist with these partially matching parameter lists: (Array<Element>, Array<Element>), (CGFloat, CGFloat), (Date, TimeInterval), (Decimal, Decimal), (DispatchTime, DispatchTimeInterval), (DispatchTime, Double), (DispatchWallTime, DispatchTimeInterval), (DispatchWallTime, Double), (Double, Double), (Float, Float), (Float80, Float80), (IndexPath, IndexPath), (Int, Int), (Int16, Int16), (Int32, Int32), (Int64, Int64), (Int8, Int8), (Measurement<UnitType>, Measurement<UnitType>), (Other, Self), (Self, Other), (Self, Self.Scalar), (Self, Self.Stride), (Self.Scalar, Self), (Self.Stride, Self), (String, String), (UInt, UInt), (UInt16, UInt16), (UInt32, UInt32), (UInt64, UInt64), (UInt8, UInt8) print(a + b) ^

足し算できるけど、足し算の直接定義がなくて、プロトコル定義での足し算に頼ってる型を探してた

+ ってオペランドの型が Self だからそんなことある？

Swift.(file).FloatingPoint.+, が出てくるから。 (edited)

↓の中にはなさそう？

<stdin>:4:9: note: overloads for '+' exist with these partially matching parameter lists: (Array<Element>, Array<Element>), (CGFloat, CGFloat), (Date, TimeInterval), (Decimal, Decimal), (DispatchTime, DispatchTimeInterval), (DispatchTime, Double), (DispatchWallTime, DispatchTimeInterval), (DispatchWallTime, Double), (Double, Double), (Float, Float), (Float80, Float80), (IndexPath, IndexPath), (Int, Int), (Int16, Int16), (Int32, Int32), (Int64, Int64), (Int8, Int8), (Measurement<UnitType>, Measurement<UnitType>), (Other, Self), (Self, Other), (Self, Self.Scalar), (Self, Self.Stride), (Self.Scalar, Self), (Self.Stride, Self), (String, String), (UInt, UInt), (UInt16, UInt16), (UInt32, UInt32), (UInt64, UInt64), (UInt8, UInt8)

11:44 PM

あ、 NSNumber は FloatingPoint じゃないからか。 (edited)

FloatingPoint.+は実装は無いっぽい

11:53 PM

お

11:54 PM

RangeReplaceableCollection.+は、protocol extensionとして実装が与えられているから

11:54 PM

もし、ExpressibleByFloatingLiteralで、かつ、RangeReplaceableCollectionな型を自作した場合は、

11:54 PM

これは足し算の項のどこかにその型が無いと推論できないはず

今、iPadを制御するためのBluetoothのマウスの作成をしています。そこで、以下の点をご存じの方がいればおしえてもらえますか。・マウスカーソル位置をピクセル単位で指定できるか

ソフトウェアから位置をずらすということかな...?

4:21 PM

HIDとして特定の位置に移動するということかな...?

できれば後者の、特定の位置へポインタを移動させることがしたいと思っています。 macOS用であればNSViewControllerを使えば任意の位置にマウスポインタを移動できたので、同様のことをiPadOSやiPhoneでも実装したいと考えています。

たぶん正攻法ではそういうことはできなくて

1

11:34 PM

ひょっとすると UIAccessibility 関連でできるかもしれない、くらいですかねえ印象としては。

なるほど。現時点でマウスデバイスとしては認識できているんですが、どうもピクセル位置を直接指定した制御だけはできないみたいで、何か方法があればと思っていたのですが難しそうですね。 UIAccessibility関連について再度調査してみます。ありがとうございます。

ちなみに、特定の位置に移動するのではなく、指定した量だけマウスポインタを動かすということはできると思いますか？（ポインタの位置を直接指定できないとなるとこちらも難しいとはおもいますが）

このけんちょっと考えましたが可能性としては、UIWindowのsendEvent:あたりでUIEventを奪って、(UIHoverEventが pointer とかのやつっぽい)加工すれば可能なような気がしています。 (edited)

4:44 PM

どの方法でもprivate apiへのアクセスは必要そうですね (edited)

いろいろと考えていただきありがとうございます。挑戦してみます！

質問です

4:51 PM

あ、ここじゃないほうがいいかな。

4:51 PM

#swiftpm かも

中身によるのでは

SPMの話だからそっち行きます〜

https://forums.swift.org/t/unexpected-length-of-r-n/37652/12 ひどいバグだ

Unexpected length of \r\n

The result changes when you import Foundation. ("\r\n").contains("\r") // false ("\r\n").contains("\n") // false But: import Foundation ("\r\n").contains("\r") // true ("\r\n").contains("\n") // true (Tested in Xcode 11.5.1, Swift 5.2.4) This is because String implic...

マジかｗｗ

lol

12:46 AM

import Foundation changes many things for sure

Xcodeのインデントの話題が最近あった気がするんだけれど、どこだっけ...

4:22 AM

https://github.com/apple/swift/pull/31941 これか

[SourceKit/CodeFormat] Don't column-align PatternBindingDecl entrie...

Don't column align PBD entries if any entry spans from the same line as the var/let to another line. For example: // Previous behavior: let foo = someItem .getValue(), // Column-align...

標準ライブラリをモジュールに分けて必要なものだけ、とするとそういう場合だいたい外したいのはStringとかLocaleとかだったりすると仮定すると、どのライブラリを利用しているかでソートの結果とかも変わってしまう、みたいなことになるのかな。

2:30 AM

みたいなことを考えると、最適化でがんばって枝を払う方が良い結果になるのかもしれない。

最適化でがんばって十分な効果が出るなら、コードを書くときに人間ががんばらなくていいので良いと思います。僕は今の標準ライブラリの範囲はひとかたまりとして好きですね。

2:39 AM

Java みたいにコレクション使うためにインポート、とかは嫌な感じが。

2:41 AM

I/O とかネットワークとか入ってなくて、（本来の意味の）スクリプト言語として他のプログラムに埋め込む用途にもちょうど良い範囲になっているように思います。

2:42 AM

SIMD はちょっと異質でしたが・・・。

それはそんな気がしますね。良いバランスなのかも。

2:46 AM

ファイルIOが入ってないなら文字列の扱いは入出力だから（標準ではない）ライブラリでやるべき、とも思うけどそこは実用性とのバランスかなあ。

さすがに String が標準外なのは辛いし、内部でいい感じに ASCII か Unicode かとか考慮して切り替えてくれて、 ASCII の範囲でしか使ってないときは Unicode 側には触らず、最適化で消えてくれるとかが理想的な気がしますね。

ASCIIの範囲だったら、ってさすがにコンパイラ・リンカがわかるケースはすごく限られるから人間がヒントを与える仕組みも必要かも。

内部で String の実体となる型を分けて、リテラルから ASCII のみのときは ASCII 限定の実体に紐付けられて、 ASCII 限定の実体の API しか呼び出されてないから他は消される、とかはきついかな・・・。 (edited)

最適化でうまくやってくれる、ということになったら標準ライブラリはもっと拡充しやすくなるのかな。 Linked ListやOrdered Setはよく言われるけどそういうのも入れてしまって良いという判断にしやすいかも。

そもそも String の仕様が...

3:04 AM

なんというか顧客が本当に必要だったものではないというか...

String(data: data, encoding: .utf8) とかすぐ出てくるのでこの時点で膨大なunicode仕様が必要になっちゃいますね

3:07 AM

↑のencoding: が .ascii だったらカットできるけど。

顧客が本当に必要だったものではない

よくバグってるのは別として、仕様自体は、やっと正しいものにたどり着いたと思ってます、僕は。

Stringの仕様はどうなってるのがいいんでしょうねえ。私はRubyのがいいんじゃないかと思ってます。

3:17 AM

いや、それも大変かな。

UTF-8みたいな可変長シーケンスは、いきなり飛び地への効率的なシークができないので、indexの仕様を普通の配列みたいにするとよくない。 (edited)

3:18 AM

UTF-16にしてそれができる処理系もあるけど、結局はサロゲートペアでつらいことになるわけで(最近は絵文字合成もよくあるし)、あれも嘘だし。 (edited)

逆か、UTF-8に依存しない自由なStringを用意すればいいのか。

3:23 AM

内部エンコーディングにUTF-8を使うというのはたぶん99%くらいはそれでうまくいくわけだから。

UTF-8として読み込むときに一度なめるんだったら、そのときにインデッスクテーブル作って内部に保持しておけばインデックスでランダムアクセスできると思うんだけど、Stringが太るのは許容できない？

それはString型じゃなくてそういうデータ構造の二次的な型を作るのが良いと思います

4:05 AM

そうすればString直接使う場合と、そのテーブル付きStringを使う場合の両方選択できて、トレードオフをユーザが決定できる。

4:05 AM

そもそも、ランダムアクセスが必要なシチュエーションがどういうものかも、気になりますけど。

4:07 AM

例えばパーサーのバックトラックだったら、戻りたいところだけindexを事前に保存しておけるし、行頭の逆方向への検索も逐次的な移動でできるし、一定文字数で丸めるとかもできるし・・・

4:08 AM

クロスワードパズルゲームを実装するみたいなちょっと変わったシナリオでしかインデックスランダムアクセスは必要ない気がします。

4:08 AM

(ただクロスワードの例だったら文字列長が短いので毎回頭から数え上げても大丈夫そうだ）

4:13 AM

どちらかというと、みんなが気に食わないのって、

4:13 AM

stringとindexのデータ構造のほうじゃなくって

4:14 AM

str[str.index(str.startIndex, offsetBy: 2)] って、 str を3回書かないといけないところじゃないかと思います。

4:16 AM

これについては https://forums.swift.org/t/offset-indexing-and-slicing/28333 これが進んだら解決すると思ってて

Offset Indexing and Slicing

v2 changes Removed .start and .end, now all OffsetBounds are built from .first and .last. Simplifies usage and learnability. Delineates OffsetBound abstraction and terminology from indices. Added RangeReplaceableCollection convenience overloads, subscript setters. .inser...

4:17 AM

str[.first + 2] って書けるようになります。

うーん、現実的にでもなんかcharacter単位で操作してうれしいことがあんまりないっていうか... (edited)

4:25 AM

ほとんどの操作はscalarかUTF-16単位だったり。

4:26 AM

Swiftがどう、というより、Swiftが生きている世界がSwiftの世界と違いすぎて、

4:26 AM

(e.g. JVMベースのデータサービス、Objective-CのUIライブラリなど) (edited)

4:27 AM

NSString的なのがほとんどでString的な操作は例外という印象

4:29 AM

そして多分その未来は当分変わらない

scalar単位の操作に関しては .unicodeScalars が使えるので、デフォルトのcollectionがcharacters相当なのがめんどくさいって意味ですかね？

5:07 AM

そして多分その未来は当分変わらない

NSStringとかを使い倒す必要があってcharactersとして使う場面が少ないというのは課題だと思います、↑のmichaelさんもStringサポート拡充担当なはず

5:08 AM

とりあえず正規表現とか進んでほしい

そう

6:22 AM

デフォルトがUnicode Code Pointの操作で、拡張で UTF-16/UTF-8、さらにオプショナルな拡張で Grapheme の操作でよかった。 (edited)

6:23 AM

ああ、未来が変わらないのは取り巻く環境がってことね

6:23 AM

世の中のStringは多分そうとう先までUTF-16だと思う。

デフォルトがコードポイントなるほど・・・ (edited)

6:33 AM

確かに他の言語がだいぶどうにもならなそうですね＞世の中

そしてswiftがそれ単体でシステムを作る世界は多分こないので

6:34 AM

結局swiftのstringがデフォルトでcharacter操作で嬉しいってことはなかったという (edited)

6:34 AM

そんな感じ

逆に言えばSwiftが10年後に戦える言語で居られるかもしれない

Apple「新しい言語つくりました、 Swiftはもうだめです」 (edited)

6:35 AM

ありうるんだよなあ

そうですねえｗ

↓ってダメなんでしたっけ？ @swift-5.2.5

protocol P1 { func foo() -> Int } protocol P2: P1 { func bar() -> String } class C1 { init<P: P1>(_ p: P) {} } class C2: C1 { override init<P: P2>(_ p: P) { super.init(p) } }

exit status: 1 with stderr:

<stdin>:14:14: error: overridden method 'init' has generic signature <P where P : P2> which is incompatible with base method's generic signature <P where P : P1>; expected generic signature to be <P where P : P1> override init<P: P2>(_ p: P) { ^ <stdin>:10:5: note: overridden declaration is here init<P: P1>(_ p: P) {} ^

C2 を C1 としたときに init ができなくてダメ？ (edited)

6:59 AM

C1.init が required じゃないときに問題ありますか？

struct S1: P1 {} (C2.self as C1.Type).init(S1()) これで破綻しそう (edited)

7:16 AM

でもそもそもジェネリックシグネチャを縮めたりしながらオーバライドするのできましたっけ

7:17 AM

その型パラメータのvariancityを判定しないといけないから難しい気がするけど。

@omochimetaru required じゃないとそもそも↓ができないみたいで @swift-5.2.5 class C { init() {} } let cType = C.self print(cType.init())

exit status: 1 with stderr:

<stdin>:6:13: error: constructing an object of class type 'C' with a metatype value must use a 'required' initializer print(cType.init()) ~~~~~ ^ <stdin>:2:5: note: selected non-required initializer 'init()' init() {} ^

@swift-5.2.5 class C { required init() {} } let cType = C.self print(cType.init())

main.C

それならダメな理由あるかなと。

requiredじゃない場合、サブクラスにもそのinitがあるとは限らないのか。

7:33 AM

~~じゃあrequiredじゃないinitをoverrideする意味ってなんだろう~~ overrideするとsuper.initが呼べるぐらいの意味しかないのかな。 (edited)

7:33 AM

struct S1: P1 {} (C2.self as C1.Type).init(S1()) だめな理由はこれが型としておかしくなるからってのもあるけど、そもそもジェネリックシグネチャを縮めたりしながらオーバライドするのできましたっけ

Overridden method 'init' has generic signature <A where A : Sequence> which is incompatible with base method's generic signature <A>; expected generic signature to be <A>

ダメみたいですね

8:12 AM

こっちだと通る。これ目的で余計な型パラ追加したの1回だけあった気がするな class Foo<A> { init(a: A) { } } class Bar<A>: Foo<A> where A: Sequence { override init(a: A) { super.init(a: a) } }

ダメな方の入力はどんなコード？

class Foo { init<A>(a: A) { } } class Bar: Foo { override init<A: Sequence>(a: A) { super.init(a: a) } } (edited)

protocol P1 {} protocol P2 : P1 {} class Animal { func f<X: P2>(_ x: X) {} } class Cat: Animal { override func f<X: P1>(_ x: X) {} }

8:15 AM

↑これいけた。

おー

8:15 AM

Anyだけだめなのか

いや、ちがう

8:15 AM

variance逆

あw

引数で使ってる型はcontravarianceだから継承先では広がらないといけない

そもそもinit引数だから大分変なことやってたわ

protocol P1 {} protocol P2 : P1 {} class Animal { func g<X: P1>() -> X { fatalError() } } class Cat: Animal { override func g<X: P2>() -> X { fatalError() } // Overridden method 'g' has generic signature <X where X : P2> which is incompatible with base method's generic signature <X where X : P1>; expected generic signature to be <X where X : P1> }

8:17 AM

covarianceはダメだった

普通のメソッドや static method でそうなるのはいいとして、 .init で呼び出せない required でない init の場合はどういう問題があるの？

シンプルにrequiredじゃないinitはサブタイプではoverrideしない限り存在しないことになってるので

あれ？さっきの変な気がしてきた

8:26 AM

class Animal { init<X: P2>(_ x: X) { } } class Cat: Animal { override init<X: P1>(_ x: X) { super.init(S2()) } }

8:26 AM

これはコンパイルできますね。

8:29 AM

どういう問題があるの？

そもそもoverrideとして型がおかしいからoverrideできない、というレベルのエラーに思えます。

8:30 AM

ただこのoverrideって別に動的ディスパッチされる事がなさそうだから、実際には型がめちゃくちゃでも問題は無いのかな？その場合overrideじゃなくて単に同名の無関係なinitがあるって事ですけど。

8:34 AM

あ、わかったかも・・・？

@swift-5.2.5 class C1 { init(_ x: Int) {} } class C2: C1 { init(_ x: String) { super.init(42) } }

no output

↑これができるのに

8:35 AM

@swift-5.2.5

protocol P {} protocol Q {} extension Int: P {} class C1 { init<T: P>(_ x: T) {} } class C2: C1 { init<T: Q>(_ x: T) { super.init(42) } }

exit status: 1 with stderr:

<stdin>:10:5: error: overridden method 'init' has generic signature <T where T : Q> which is incompatible with base method's generic signature <T where T : P>; expected generic signature to be <T where T : P> init<T: Q>(_ x: T) { ^ <stdin>:6:5: note: overridden declaration is here init<T: P>(_ x: T) {} ^

↑これができないのが問題な気がする。

(連続した投稿が混ざっちゃったので再投稿) こういうことだ。

class Animal { init<X: P2>(_ x: X) { } required convenience init() { self.init(S2()) } } class Cat: Animal { override init<X: P1>(_ x: X) { super.init(S2()) } } func main(_ animalType: Animal.Type) { animalType.init() } main(Cat.self)

convenience required initからinitを呼び出したときに動的ディスパッチです。 (edited)

？？これは required だからそうじゃないの？ required がついてないときに引数の型を狭めるのが許可されないのはなぜ？という話では？ (edited)

required convenience init は関係なくて、

あれ？見間違いか？ init は引数があるのか。

initとoverride initの間で、型パラメータがcontravarianceでないといけないよという話です。

8:40 AM

required convenience initが出てきたのは、

.init で呼び出せない required でない init の場合はどういう問題があるの？

これにたいする回答です。

8:41 AM

<metatype>.init で呼び出すことはできないけど、別のinitからself.init で呼び出すことはできるので、

8:41 AM

そこで動的ディスパッチが発生するので、関数型の互換性を保ってオーバライドされてないといけない。 (edited)

えっと、そもそもオーバーライドしろって言われるのが変な気がして、オーバーライドせずに↓を通すのはダメなんだっけ？ジェネリックだとシグネチャが被る？

protocol P {} protocol Q {} extension Int: P {} class C1 { init<T: P>(_ x: T) {} } class C2: C1 { init<T: Q>(_ x: T) { super.init(42) } }

8:43 AM

↓との違いは何かだね。 class C1 { init(_ x: Int) {} } class C2: C1 { init(_ x: String) { super.init(42) } }

ジェネリックシグネチャの部分は関数のシグネチャ(オーバライド関係になる同一性判定）に含めてないんだと思います。 (edited)

これって判定を緩めれば特に問題が起こらない話なのかな？

PかつQである型を定義することができるので

8:44 AM

その場合どっちを呼び出したいか曖昧になる問題はありそうですね

C2 経由で C1 の init は呼べないのでは？

8:46 AM

C1 の init は C2 を使うときには見えないので。

init2つの話だと確かにそうかも。

8:47 AM

ただそこのルールは普通のfuncとかと同じにしておいたほうがルールがシンプルになるしわかりやすいのでこれで良いと思う。 (edited)

@swift-5.2.5 class C1 { init(_ x: Int) {} } class C2: C1 { init(_ x: String) { super.init(42) } } print(C2(42))

exit status: 1 with stderr:<stdin>:11:10: error: cannot convert value of type 'Int' to expected argument type 'String' print(C2(42)) ^

うーん、わざわざ required を設けてるんだから、そこはちゃんと動いてほしい気が。

8:48 AM

サブクラスでイニシャライザの引数の型を変えるなんて普通にあることで、その一部が封じされてる。他の言語だと普通にできるよね？

他の言語だとメタタイプオブジェクトが無いことが多いのでイニシャライザ自体のオーバライドという概念が無いですね。

はい。なので普通にできる。

SwiftのObjectiveC由来っぽい部分だ。

で、 Swift はそれを required を導入することでせっかく区別したのに、

requiredじゃなくてもoverrideできるから、区別と言って良いのかわからない。

8:53 AM

話の順番が違う気がするんですよね

8:53 AM

・関数同士のシグネチャを比べて、サブクラス側のそれがオーバライドできるシグネチャだったら、override 　をつけることを強制する (edited)

8:54 AM

というルールが先にあって、 funcでもinitでもそれは同じように適用されているってだけじゃないですか？ (edited)

8:54 AM

そういう作りになっていないと

8:54 AM

オーバーライドしたつもりでオーバーライドできていなかったバグが出てきちゃうから

8:54 AM

override 指定子は、オーバライド制御をするものじゃなくて、その承認マークをプログラマがつける物になってる。

required じゃないときの init のオーバーライドって何のためにあるの？

さっきの例と説明じゃ不足ですか？ (edited)

あー、さっきのはそうか。

<metatype>.init で呼び出すことはできないけど、別のinitからself.init で呼び出すことはできるので、そこで動的ディスパッチが発生するので、関数型の互換性を保ってオーバライドされてないといけない

8:55 AM

もうこれ以上説明を分解できない。

8:57 AM

話してて逆にわかってきたけど、 required ってのは、メタタイプに対して呼び出せる事を示す（それ故にoverrideが強制される）って機能だったのか。 (edited)

8:57 AM

で、それとは別に、そもそもinitは継承できるダイナミックなものであると。

init はサブクラスから不可視なわけではなくて、オーバーライドしないと普通に使えるからいいのか？？ @swift-5.2.5 class C1 { init(_ x: Int) {} } class C2: C1 {} print(C2(42))

main.C2

でも、それなら↓ができないの変じゃない？ @swift-5.2.5 class C1 { init(_ x: Int) {} } class C2: C1 { init(foo: String) {} } print(C2(42))

exit status: 1 with stderr:

<stdin>:9:10: error: missing argument label 'foo:' in call print(C2(42)) ^ foo: <stdin>:9:10: error: cannot convert value of type 'Int' to expected argument type 'String' print(C2(42)) ^

それは、 override init の自動実装なんじゃないだろうか。

普通のメソッドと異なる挙動のものを、メソッドと同じオーバーライドルールを割り当てるのは変な気がする。

サブクラスにinitが1つも無いとき、自動でやる。

9:03 AM

class C1 { init() {} } class C2 { private init(_ a: Int) {} } C2() // error

9:03 AM

class C1 { init() {} } class C2 { } C2() // ok これはC1.initが見えてるんじゃなくて、C2.initが自動定義されてるんじゃないだろうか。 C++の自動コンストラクタ定義みたいなノリで。

9:04 AM

class C1 { required init(a: Int) {} init(b: Int) {} } class C2 { } C2() ↑よくViewController書いてるとなるやつ

9:06 AM

class C1 { required init(a: Int) {} init(b: Int) {} } class C2: C1 { override init(b: Int) { super.init(b: b) } // 'required' initializer 'init(a:)' must be provided by subclass of 'C1' }

9:06 AM

サブクラス側にひとつでも何かしらのinitがあると、自動実装がなくなるから、required initのoverrideしてないよって言われる。

うーん、さっきの required convenience init からオーバーライドされた init を呼び出すパターンがあるのはいいとして、

class C1 { required init(a: Int) {} init(b: Int) {} init(c: Int) {} } class C2: C1 { required init(a: Int) { fatalError("init(a:) has not been implemented") } override init(b: Int) { super.init(b: b) } // init(c: Int) はなくてOKだけど、 // C2.init(c: 3) は呼び出せない }

でも、requiredではないinitについては、オーバライドしないことも許されている。（ただし直接呼び出せない） (edited)

ん？そのパターンでオーバーライドしないとどうなるんだ？？

C2にあるinitは、(a:)と(b:)だけ。

9:10 AM

もし、C2を空っぽにした場合は、自動実装されるから、(a:)と(b:)と(c:)全部がC2にある。 (edited)

9:13 AM

initならなんでも動的ディスパッチでオーバライド可能というのが前提で、 requiredだと外から呼び出せる、requiredじゃなかったら、selfからしか呼び出せない。というルールですね。

@swift-5.2.5

protocol P1 {} protocol P2: P1 {} struct S1: P1 {} struct S2: P2 {} class Animal { init<X: P2>(_ x: X) { } required convenience init() { self.init(S2()) } } class Cat: Animal { let foo: Int init(foo: Int) { self.foo = foo super.init(S2()) } } func main<A: Animal>(_ animalType: A.Type) -> A { animalType.init() } let cat = main(Cat.self) print(cat.foo)

exit status: 1 with stderr:

<stdin>:21:1: error: 'required' initializer 'init()' must be provided by subclass of 'Animal' } ^ <stdin>:11:26: note: 'required' initializer is declared in superclass here required convenience init() { ^

Cat で init(_:) をオーバーライドしても何も言われないけど、オーバーライドじゃない init を作ると init() （ init(_:) ではない）をオーバーライドしろと言われる。おもしろい。 (edited)

これどういうルールなんだ・・・？

9:18 AM

サブクラスにinitがあっても、オーバライドしろって言われない場合がありますね。

↑のケースでは init(foo:) を作ったことで init(_:) が不可視になって

9:19 AM

そうすると init() が困るから init() をオーバーライドしろと言われてる？

9:20 AM

なにせ init(_:) では foo を初期化できないしね。

class C1 { init(b: Int) {} required convenience init(e: Int) { self.init(e: 1) } } class C2: C1 { override init(b: Int) { super.init(b: b) } } // OK

9:21 AM

class C1 { init(b: Int) {} init(c: Int) {} required convenience init(e: Int) { self.init(e: 1) } } class C2: C1 { override init(b: Int) { super.init(b: b) } // NG: init (e) must be provided }

9:22 AM

convenienceとdesignatedで2段階の処理になっている気がする。

9:23 AM

もし、サブクラス側にdesignated initが存在しなければ、全てのdesignated initを自動オーバライドする。もし、全てのdesignated initがオーバライドされていて、サブクラス側にconvenience initが存在しなければ、 convenience initのオーバライドが自動実装される。

convenience は自動オーバーライドなのかなぁ。

9:24 AM

というか、自動オーバーライドという概念がなくてもうまく動く気が。

class C1 { init(b: Int) {} convenience init(c: Int) { self.init(b: 1) } convenience init(d: Int) { self.init(b: 1) } } class C2: C1 { init(f: Int) {} convenience init(c: Int) { self.init(f: 1) } } C2(d: 1) // NG

うーん、 Swift の関数って参照型なのに === で比較できないから、同じものなのか調べられなかった・・・。

この場合、convenienceも見えなくなる↑

C2 に独自の init を作ったら全部見えなくなっていいんじゃない？

その「見えなくなる」が、見えなくなってるんじゃなくて、「見える」ように思えるのは、自動実装って事じゃないかなと思っている

まあ、自動オーバーライドかスーパークラスのが見えるのかはセマンティクス的には見分けられないからどちらでもいい気が。

見えなくなるセマンティクスがよくわからない。

9:29 AM

あ〜、サブクラスのdesignated initがある場合必ずソレを呼ばないと初期化できないって事かしら

サブクラスで init を作らない限り全部透過してる。

9:29 AM

独自 init があるケースでは独自の初期化が必要かもしれないから、透過させられない。

class C1 { init(b: Int) {} convenience init(c: Int) { self.init(b: 1) } convenience init(d: Int) { self.init(b: 1) } } class C2: C1 { convenience init(c: Int) { self.init(b: 1) } } C2(d: 1) // OK

9:30 AM

convenience initは、動的ディスパッチでは無いっぽい？

9:30 AM

自身のdesignated initを呼ばないといけないから、継承できたらまずいんだろうか。

convenience では独自の初期化は行われないから、透過／自動生成のままでもいいんじゃない？

9:31 AM

うん。 designated が存在するだけでそいつを経由しないと壊れる（可能性がある）から、透過／自動生成が封じられる。

class C1 { init(b: Int) {} convenience init(c: Int) { print("C1.init(c:)") self.init(b: 1) } convenience init(d: Int) { self.init(c: 1) } } class C2: C1 { convenience init(c: Int) { print("C2.init(c:)") self.init(b: 1) } } C2(d: 1)

9:32 AM

C1.init(c:) が出力された。確かにオーバライドではないっぽい。

9:33 AM

class C1 { init(b: Int) {} required convenience init(c: Int) { print("C1.init(c:)") self.init(b: 1) } convenience init(d: Int) { self.init(c: 1) } } class C2: C1 { required convenience init(c: Int) { print("C2.init(c:)") self.init(b: 1) } } C2(d: 1)

9:33 AM

required convenience initだとオーバーライドされる。

9:33 AM

C2.init(c:) が出力された。

これはこうなるのか。ということは、 convenience init をうまく使えばやりたかったこともできるのかも？

9:35 AM

狭める分を convenience にできれば。

サブクラスのほうが受ける型を狭めたいんでしたっけ？ (edited)

はい。

9:38 AM

ジェネリックにするからダメな気がしてきた。

9:38 AM

やりたいこととしては

protocol C1Delegate { func foo() -> Int } protocol C2Delegate: C1Delegate { func bar() -> String } class C1 { init(delegate: C1Delegate) {} } class C2: C1 { init(delegate: C2Delegate) { super.init(delegate: delegate) } }

みたいな感じなんだけど（これはできる） (edited)

9:39 AM

このプロトコルが existential にできない（ associatedtype を持っている）からジェネリックに受けてから対処しようとしたけど、

9:40 AM

渡す時点で type erasure に包むようにすればいける？

うーん、convenience initにしても無理やりオーバライド判定されて間違ってるよって言われちゃってダメだな。

9:42 AM

先にまずrequiredとかconveienceとか取っ払ってシグネチャだけでオーバライド関係を解決してそう。

9:42 AM

その後でもろもろの指定子に基づいてチェック。

9:43 AM

type erasureならただの型なのでできると思うけど使う側がしんどいですね

9:45 AM

protocol P1 {} protocol P2: P1 {} class C1 { init<X: P1>(p: X) {} } class C2: C1 { convenience init<X: P2>(p2: X) { self.init(p: p2) } }

当然ラベルを変えればいけるけど・・・

動的ディスパッチされない convenience でもダメなのかぁ。

convenienceつけなさいみたいな診断が出ることがあるし、その判定は後なんでしょうね。

9:48 AM

理屈上は静的なconvenienceだけはシグネチャ無視で実装できて良いはずだけど

↑についてだけど、 module A で C1 を宣言し、 module B で C1 の extension で convenience init<X: P1>(_ x: X) を作り、 module C で C2 の init<X: P2>(_ x: X) を作ったらどうなるんだろう？（試せばわかる話だけど・・・） (edited)

https://qiita.com/omochimetaru/items/428324ed8bcd2b98dacb#ヘッダのみ使う

コマンドラインから直接Swiftコンパイラを使ってビルドする方法 - Qiita

この記事では、Swiftコンパイラを直接使って、コードを実行したり、モジュールを分割ビルドする方法を解説します。この内容を理解すると、Swiftのビルドの仕組みの理解が深まるでしょう。また、コンパイラに対していろいろな実験をする上...

1

4:12 AM

モジュール分割したときの型チェックだけ実験する方法を↑に多分書いた

@objc var cat: Bool って isCat 作らないですよねえ

1

6:35 AM

@property (nonatomic, getter=isCat) BOOL cat 互換の @objc var ってどう書くんだろう

6:36 AM

Swift的には、var isCat: Bool のほうが良くて、だから setter だけ setCat: で見えるようにすればいいのかな? (edited)

6:37 AM

@objc var isCat: Bool は isCat と setIsCat: を作った...

class ExampleClass: NSObject { @objc var enabled: Bool { @objc(isEnabled) get { // Return the appropriate value } } }

6:38 AM

https://docs.swift.org/swift-book/ReferenceManual/Attributes.html

6:39 AM

getterとsetterにそれぞれobjc側の名前を指定できそう。

storedは無理か

あ〜そっか。

@objc(getter, setter) みたいには無理そう

The objc attribute optionally accepts a single attribute argument, which consists of an identifier.

だし、そういう記法はなさそうですね。

なるほどー。

6:41 AM

proxy用意してあげることになるのか...

ドキュメントあんまり信用してないのでコンパイラほじくったらなんか裏技あるかもわからんが

6:41 AM

少なくとも僕は知らない。

これなんかずっと疑問で Objective-CのBOOLは、isCat, setCat: になるように getter= を書くのがなんというか習慣なんだけど

6:42 AM

@objc はそんなことしてくれないんですよねえ

習慣というかBOOLだと @property が自動で isXxx を作りませんでしたっけ？ (edited)

しかも Swift はいつのまにか Bool のは isCat が主流に。 (edited)

Swiftが isCat なのはかなり初期からそうだったはず

つくんないですね。getter=isCat って Appleのヘッダーにはほとんど書かれてる

6:43 AM

最初でたときは is ついてなかったと思ったんだけどなあ。

6:44 AM

1のころ。

そうか。あ〜、自動で is・・・　になるのはKotlinがJavaをimportするときかも。

並行世界の話だったw

混ざった。

6:44 AM

Javaでgetterとsetterなやつをkotlinで勝手にプロパティに見せかけるんですよね

POJOみたいなやつのか

Kotlinから見たJavaのクラスはなんでもその変換かかります

6:47 AM

Swiftの @objc は

6:47 AM

Swift側から ObjC 向けに ObjC らしいクラスを提供する気概をあまり感じない

衝突が回避できればO K、くらいの感じかもしれないですね。 (edited)

Swiftにマイグレーションしていく上で最低限困らないようにするって感じで

6:51 AM

ObjCと長く良く連携していく、までは見てない印象。 (edited)

確かに...

6:53 AM

時代に逆行する昨日は提供する意義も薄い...

これなんかずっと疑問で

niwさんがそう感じるのは業務内容的にもわかるけど

6:54 AM

実際(昔の)MLとかForumとか見てた限りでは (edited)

6:54 AM

そのあたり掘り下げて不便なんじゃなんとかしてくれ〜って言う人は全然居ないです

6:55 AM

@objc 属性周りの SE proposal とかの前後ではちょっと話題があったけど、あんまりそこから話題も広がらなかったと思う

んー、っていうか他の @objc は名前が習慣に合うように頑張ってるのに

6:56 AM

BOOLのproperyだけそうなってなくて、

6:56 AM

しかも途中(2だっけ)でisつけたりしてうーんって思ってた。 (edited)

あ〜なるほど。たしかにメソッド名のwith周りとか妙に頑張ってますもんね。

そう。withとか。

isXXXに関する誤解はこれかな？ objcくんはBOOLなプロパティに自動でisXXXというsetterを作らないけど、KVCくんはxXXをkeyにするとインスタンス変数isXXXを検索します。

あー、それも理由で getter=isCat が習慣になってる? (edited)

isXXXは無くても動くのでむしろisXXXや_XXXの慣習があるからKVC側が気を遣ってるんじゃないですか。

Swift 5.3から導入された@mainを使って、SwiftUIのエントリポイントが↓みたいに簡潔に書けるようになってるの面白いですね。

// SwiftUI side public protocol App { public init() ... } extension App { public static func main() -> { ... } } // App side @main struct MyApp: App { var body: some Scene { ... } }

(edited)

おーすごい

正規のエントリポイントがprotocol extensionで実装されてるがゆえに、アプリの起動をフックしようとすると、こんな感じなる

@main struct MyApp: App { static func main() -> Void { print("Hello") func takeApp<T: App>(_: T.Type) { T.main() } takeApp(Self.self) } }

それって本質的に // app.swift struct MyApp: App { ... } // main.swift SwiftUI.main(MyApp.self) と変わらないと思ってて (edited)

11:48 AM

嬉しいのってワンファイルになった(main.swiftが不要)だけよね？

11:49 AM

フック

プロトコルデフォルト実装を呼び出すために型落として <T: P> にするテクだ。

11:50 AM

あんまり嬉しさが理解できないままproposalからアレヨアレヨとacceptしてSwiftUIで出荷されてきた。

これmain無限ループしないの

11:50 AM

まーなんかこれに関しては

11:50 AM

@UIApplicationMain よりはマン倍マシでしょ、ということなんじゃないですかね

11:51 AM

@UIApplicationMain を今更駆逐は出来ないし

まーそうですねー

あれ、無限ループしそうに見える。requirementsあるよね？

いや、Appプロトコルの方にrequirements無いんですよ

ないのか。

なのでデフォルト実装へのディスパッチは常に静的になる

@main に基づいて静的書き換えされているだけなのね。

11:53 AM

「requirementsが無いからデフォルトが呼べる」って世界観はモヤっとするなｗ

実装を知ってるとそうだよね、ってなるけど知らないと意味不明ですよね

まあまあマニアックだね。

11:55 AM

@UIApplicationMain も @main になるなら確かに統一されてマシになるね・・・

このオーバーライド邪悪だなと思ったらSR-106の挙動を利用してるのかw

staticだけどまあそういうことだね。

11:56 AM

SwiftUIをマスターするにはSR-106の理解が必要！

11:57 AM

その辺も main.swift だったら前後をフックするのとか自明にできるんだけどなあ。

106じゃなくて103でした、すぐ忘れる

11:58 AM

https://bugs.swift.org/browse/SR-103

11:59 AM

あーでもこれはスーパークラスの宣言の有無だからまた別か

それよりは邪悪度低いですね

この挙動は知っているのでもしかしたら報告してたかもしれねえ

こうすると素朴にフックできるけど、もはや@main使う意味が無い

@main struct Entry { static func main() -> Void { print("Hello") MyApp.main() } } struct MyApp: App { var body: some Scene {...} }

むしろ素朴にして @main 使わないほうが良いのでは。。。

それはそう…

main.swiftでよかったじゃんってなるやつ。

12:04 PM

まあ1ファイルなのがちょっとだけ嬉しいか。

https://forums.swift.org/t/question-re-5-3-function-builder-enhancement-let-is-allowed/38055/12 Dictionary[_:default:] がデフォルト値を元のDictionaryに挿入してくれないのを解決するために Dictionary[_:orInsert:] っていうのを付加してるんだけど、その実装が面白い。

extension Dictionary { public subscript(key: Key, orInsert value: @autoclosure () -> Value) -> Value { mutating get { // We have to "mutate" the result of subscript[_:default:] in order // to ensure an entry gets added, so we pass it inout to a function. return { $0 }(&self[key, default: value()]) } } }

{ $0 }(&mutableValue) で値を返すと同時に $0 が inout と解釈されて mutableValue の setter がトリガーされる。 (edited)

おもしろいですね。

11:36 PM

この使い方はおもしろいけど、 mutating get はちょっと混乱を招きそうな気も・・・。

dictionary[key, default: 0] += 1 とかも (+=)(&dictionary[key, default: 0], 1) のように考えれば同じような感じになって、 { $0 }(&self[key, default: value()]) の発想になるのかな。

おー、なるほど。確かにassignment operator っぽさありますね。

prefix operator % prefix func % <T>(_ val: inout T) -> T { val } var dict = ["foo": 1] _ = dict["bar", default: 2] print(dict) // -> ["foo": 1] _ = %dict["bar", default: 3] print(dict) // -> ["bar": 3, "foo": 1]

もし↑の % が採用されたら、 $ に加えて初見殺しの謎の記号が Swift にｗ

12:53 AM

callAsFunction の無名 function 案が検索性の問題で見送られたのに、 Property Wrapper で $ が採用されてるのダブスタ感がある気が。

12:54 AM

declaration site と call site の違いはあるとはいえ。

value()が2回実行されそうな気もしたけど、inoutになった時点で_modify {…}が呼び出されるから、そうはならないのね。 @swift-5.3.3

extension Dictionary { public subscript(key: Key, orInsert value: @autoclosure () -> Value) -> Value { mutating get { // We have to "mutate" the result of subscript[_:default:] in order // to ensure an entry gets added, so we pass it inout to a function. return { $0 }(&self[key, default: value()]) } } } var d: [String: Int] = [:] print(d["a", orInsert: {() -> Int in print("closure"); return 1}()]) print(d)

closure 1 ["a": 1]

Dictionary の subscript[_:default:] の set って、 += （ inout ）とかチェーンの途中で使わず単独で使ったときって特に意味ないですよね？ dictionary[key, default: 0] = 1 みたいなの。

1:35 AM

@swift-5.2.5

struct Foo { var value: Int = 0 } let key = "key" func foo() -> Foo { print("`foo()` is called.") return Foo() } var dictionary: [String: Foo] = [:] dictionary[key, default: foo()].value = 42 print(dictionary)

`foo()` is called. ["key": main.Foo(value: 42)]

inout じゃなくても 1 回しか呼ばれない。

1:42 AM

実装これか。 https://github.com/apple/swift/blob/master/stdlib/public/core/Dictionary.swift#L892-L903

https://forums.swift.org/t/improving-the-ui-of-generics/22814

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

1:47 AM

set が何もしてないんじゃなくて、 _modify のおかげで一度しか呼ばれない？

1:49 AM

キーを2回引かなくてよくなってるのか。

_modifyではなくsetで書かれていたとしても、setの場合はdefaultValueが不要だから、一度しか呼ばれないですね。 @swift-5.3.3

extension Dictionary { public subscript(key: Key, default2 defaultValue: @autoclosure () -> Value) -> Value { get { print("get") return self[key] ?? defaultValue() } set { print("set") self[key] = newValue } } public subscript(key: Key, orInsert value: @autoclosure () -> Value) -> Value { mutating get { { $0 }(&self[key, default2: value()]) } } } var d: [String: Int] = [:] print(d["a", orInsert: {() -> Int in print("closure"); return 1}()]) print(d)

get closure set 1 ["a": 1]

その場合 get と set で 2 回 self[key] でハッシュテーブルを引くことになりますよね？

3:06 AM

あ、 value が一度しか呼ばれないのはいいんですが、元々 @norio_nomura さんが書いた _modify を使わないような実装になってるのかと思ってましたが、 _modify を使うことでそれだけじゃなくてハッシュテーブルを一度しか引かなくて済んでるんだなと。

ですね。

Objective-Cのprotocolにconformすると@objcになるんだっけ...?

ObjCで宣言されたprotocolの事なら、NSObjectProtocolがbaseになっていて、これに宣言された関数は暗黙的に@objcになっていたと思います。また、実装先はNSObjectであることを要求されます。

なるほど、特に何もしなくてもそうなってたからそうなのかなって感じてたけど。 (edited)

1:46 AM

NSObjectProtocolが暗黙的にいろいろしてくるのか...

2とか3の頃はかなり色々やってたんですが、4か5くらいから@objcを暗黙的につけるのを辞めるぞ〜みたいなのがあった記憶が朧気に

1:50 AM

今どうなってんだろ

1:52 AM

ちょっとPlayground触った感じ、Swiftで宣言したNSObjectProtocolの場合は、@objcを明示してねって怒られますね

1

import Foundation protocol Foo: NSObjectProtocol { func a() } class Bar: NSObject, Foo { func a() { } } // Foo2はObj-C headerに宣言 class Bar2: NSObject, Foo2 { func a() { } } // true print(class_getInstanceMethod(Bar.self, Selector("a")) == nil) // false print(class_getInstanceMethod(Bar2.self, Selector("a")) == nil)

(edited)

2:00 AM

Protocolの出身地で暗黙的に@objcになるかどうかの挙動が変わりますねw

@swift-5.2.5 import Foundation protocol P: NSObjectProtocol { optional func f() }

exit status: 1 with stderr:<stdin>:4:3: error: 'optional' can only be applied to members of an @objc protocol optional func f() ^~~~~~~~~

暗黙的に@objcにならない

どこ由来なのかによる...?

うーん、なかなか恐ろしいな。

12:15 PM

interface作ってる側がSwiftに書き換えちゃったら動かなくなる、とかあるのか。

@swift-5.2.5

protocol Container { associatedtype Item var item: Item { get } } struct MyContainer<T>: Container { var item: T } extension Container { func transform<T>(_ f: (Self.Item) -> T) -> some Container { MyContainer(item: f(self.item)) } } let c1 = MyContainer(item: 1) let c2 = c1.transform { item in item + 1 } let item: Int = c2.item print(item)

exit status: 1 with stderr:

<stdin>:21:20: error: cannot convert value of type '(some Container).Item' to specified type 'Int' let item: Int = c2.item ~~~^~~~ as! Int

ぇー...

9:00 PM

Opaque Type...

リバースジェネリクスが欲しくなるパターンっぽい

リバースジェネリクスか、（今はまだできない） ~~some Container<.Item == Int>~~ some Container<.Item == T> ？ (edited)

ちなみに :Int がなければ大丈夫...

.Item == T ですかね

ああ、そうですね。

12:30 AM

:Int がなくても Int になってるわけではないから、

12:30 AM

@swift-5.2.5

protocol Container { associatedtype Item var item: Item { get } } struct MyContainer<T>: Container { var item: T } extension Container { func transform<T>(_ f: (Self.Item) -> T) -> some Container { MyContainer(item: f(self.item)) } } let c1 = MyContainer(item: 1) let c2 = c1.transform { item in item + 1 } let item = c2.item print(item + 1)

exit status: 1 with stderr:

<stdin>:22:7: error: cannot convert value of type '(some Container).Item' to expected argument type 'Int' print(item + 1) ^ as! Int

print は何でも渡せるから動いているだけのよう。

なんですよねえ

12:32 AM

some の使い所...

12:32 AM

AnyContainer<T> みたいなのがまだ必要

some Foo<.Bar == Baz> が書けるようになるまでは、

12:33 AM

some View みたいな、かなり使いどころが限られると思います。

some View は associated type ないんだっけ。

Body が assoc type ですが、型パラ的性質のものじゃないので成り立ってます。

なるほど

あと、 any と some は性質が違うので、 some View はできるけど AnyView もあります。

12:36 AM

Generalized Existential が導入され（て any 修飾子も導入され）たら any View と書けるようになるかと。

12:36 AM

@Douglas_Gregor wrote the Generics Manifesto almost three years ago, which provided the roadmap for the core of Swift's protocols and generics features. Since then, we've implemented almost all of the basic model that it envisioned. Although there are further features we could...

とうぶんかかりそう...

some Foo<.Bar == Baz> についても、↓のセクション（ Expressing constraints directly on arguments and returns ）で言及されてます。僕はこの記法で any と some が統一されるのが良いと思います。 https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--directly-expressing-constraints

https://speakerdeck.com/omochi/swiftfalseobarodoxuan-ze-falsesukoagui-ze-12zhong-lei

@Douglas_Gregor wrote the Generics Manifesto almost three years ago, which provided the roadmap for the core of Swift's protocols and generics features. Since then, we've implemented almost all of the basic model that it envisioned. Although there are further features we could...

12:39 AM

今のところ動きがなさそうなので、当分かかるのは間違いないと思います。おそらく Swift 6.0 では来ないでしょうね・・・。

12:40 AM

any だけなら Parser の問題なので、早めに導入してほしいですが・・・。

SwiftUI ドリブンで今の some だけ入った感がある (edited)

そうだと思います。

気のせいかもしれないけど、オーバーロードが曖昧になってしまうときに、一方を優先させる黒魔術とか _ 付き attribute とかありませんでしたっけ？

@_disfavoredOverload

お、ありがとう。

omochimetaru

Swiftのオーバーロード選択のスコア規則12種類

わいわいswiftc #16 https://iosdiscord.connpass.com/event/158511 ソース(rawを見て) https://gist.github.com/omochi/587ce6e7089c763007b46ce8fa3f27a4

5:42 AM

個人的に実用はすすめないけど・・・↑で紹介してます。

5:42 AM

P28, 29.

1

https://discordapp.com/channels/291054398077927425/375206337937801216/698578768696049664 を応用して、イニシャライズできない型のデフォルト引数を与えるとかもありかな？ (edited)

5:43 AM

それはデフォルトにできないか？

デフォルト引数の有無は同じスコアのときのさらなるオーダー付けじゃないかしら

5:44 AM

あー、visibilityの問題でデフォルトにできないですね

5:44 AM

デフォルト引数の評価はcaller contextです

さっきの #combine で話してた Future の get 、 Failure が Never のときだけ Result<Output, Never> じゃなくて Output で受け取るようにできた。

@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) extension Future { @_disfavoredOverload public func get(_ body: @escaping (Result<Output, Failure>) -> Void) { let keep: Keep<AnyCancellable> = .init() keep.value = sink(receiveCompletion: { completion in switch completion { case .finished: break case .failure(let error): body(.failure(error)) } keep.value = nil }, receiveValue: { output in body(.success(output)) }) } } @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) extension Future where Failure == Never { public func get(_ body: @escaping (Output) -> Void) { let keep: Keep<AnyCancellable> = .init() keep.value = sink { output in body(output) keep.value = nil } } } private class Keep<Value> { var value: Value? }

5:48 AM

@_disfavoredOverload がないと ambiguous になってしまう。 (edited)

これambiguousかあ

5:56 AM

Failureに関して厳しさが上がってるから優先度差付いて欲しい感じがする

5:57 AM

あれ？てか、Neverではない方がdisfacoredなのか。

いや、 ambiguous だったから同じ順位かな？

6:11 AM

引数の型違いのオーバーロードだから ambiguous でも正しい気がするんよね。

はい。スコアは同じ上で、generic signatureの差でNeverの方になってほしいと思った。

Output|Failure が Output になったなら後者を選んでほしいけど。

引数が違って比較不能なんかな、そこのルールまだ未調査で。

generic signatureの差でNeverの方になってほしいと思った。

これって、たとえば

extension Future { func foo(_ f: (Int) -> Void) { ... } } extension Future where Failure == Never { func foo(_ f: (String) -> Void) { ... } }

だとしても後者が選ばれてほしいってこと？

6:14 AM

全く無関係なオーバーロード。

基本は前者が選ばれてほしくて、Failure == Neverになる情報があるときは後者になってほしい。

6:15 AM

あ違うか、前者になるような時は曖昧なのか？

6:16 AM

少なくとも、Failure == Never になるときは、厳しい方なので確定して欲しい、か。

future.foo { x in ... } みたいに書いたときにどっちになってほしいか（もしくは ambiguous でエラーか）だね。

6:17 AM

↑の場合って、 Failure == Never のときに foo のオーバーロードが追加されてるだけで、個人的には優先度が並列なのは納得なんだよなぁ。

6:18 AM

Int と String じゃなくて Result<Output, Never> とOutput だと、型の上では変わらないんだけど、意味的には狭まってるから後者が選ばれてほしい気持ちになるけど・・・。

Result<Output, Never> と Output って意味的には狭まってるけど、型空間的には広がってますね

6:21 AM

Output は任意の Result<A, B> を包含するから。

あー、それ辛そう

6:23 AM

@swift-5.2.5

class Animal {} class Cat: Animal {} struct Foo<Value> { var value: Value } extension Foo { func f() -> Animal { Animal() } } extension Foo where Value == Int { func f() -> Cat { Cat() } } print(Foo<Int>(value: 42).f())

main.Cat

これだと優先されても納得。

返り値も狭まってるし文句ないですね

@swift-5.2.5

class Cat {} class Dog {} struct Foo<Value> { var value: Value } extension Foo { func f() -> Dog { Dog() } } extension Foo where Value == Int { func f() -> Cat { Cat() } } print(Foo<Int>(value: 42).f())

main.Cat

↑が ambiguous にならないの変じゃない？

6:26 AM

いや、 Output が Result<Output, Never> を含んでいるから ambiguous になってるだけ？

これは返り値に関しては狭まってないけど、原則はそうなるという理解

6:28 AM

元々のやつも同じようになると期待した。

6:28 AM

extension where の影響でより厳しいgeneric signatureを持つほうが勝つはず・・・

@swift-5.2.5

struct Foo<Failure: Error> { var value: Failure? } extension Foo { func f() -> Result<Int, Failure> { .success(1) } } extension Foo where Failure == Never { func f() -> Int { 2 } } print(Foo<Never>().f())

2

えー、これでもいけるなら get もいけてほしいな。

6:34 AM

@swift-5.2.5

final class Future<Output, Failure: Error> { var result: Result<Output, Failure>? } extension Future { func get() -> Result<Output, Failure>? { result } } extension Future where Failure == Never { func get() -> Output? { try! result?.get() } } let future = Future<Int, Never>() future.result = .success(42) print(future.get()!)

42

@swift-5.2.5

final class Future<Output, Failure: Error> { var result: Result<Output, Failure>? } extension Future { func get(_ body: @escaping (Result<Output, Failure>) -> Void) { guard let result = self.result else { return } body(result) } } extension Future where Failure == Never { func get(_ body: @escaping (Output) -> Void) { guard let result = self.result else { return } body(try! result.get()) } } let future = Future<Int, Never>() future.result = .success(42) future.get { value in print(value) }

exit status: 1 with stderr:

<stdin>:21:1: error: ambiguous use of 'get' future.get { value in ^ <stdin>:6:10: note: found this candidate func get(_ body: @escaping (Result<Output, Failure>) -> Void) { ^ <stdin>:13:10: note: found this candidate func get(_ body: @escaping (Output) -> Void) { ^

これ二つ同じことだと思うんだけど、どうなってるんだろう？

6:37 AM

contravariant の contravariant を考えるところとかでうまくスコア計算できてないのかな？

返り値と引数でスコアリングの形態が違うのかな

引数の引数だから反転して戻り値と同じ扱いになってほしいところですが・・・。そのあたりがうまく考慮されてなさそう？

https://github.com/apple/swift-numerics

apple/swift-numerics

Numerical APIs for Swift. Contribute to apple/swift-numerics development by creating an account on GitHub.

4:01 AM

For this reason, modules that would have this ambiguity are suffixed with Module within Swift Numerics: import ComplexModule // I know I only ever want Complex<Double>, so I shouldn't need the generic parameter. typealias Complex = ComplexModule.Complex<Double> // But I can still refer to the generic type by qualifying the name if I need it occasionally: let a = ComplexModule.Complex<Float>

4:02 AM

パッケージ名とそのパッケージが提供する型の名前が衝突してると面倒な事になる問題に対して

4:02 AM

swift-numericsの対応方針はパッケージ名に Module suffix をつける派らしい。

ほう。。。

↑の下の方の Notes のところ。

Swift 、 suffix で解決するの好きだな。 IteratorProtocol とか。

KeyedDecodingContainerProtocol もありますね

4:36 AM

まあsuffixで解決されてるほうが

4:36 AM

初見の人にとっては簡単ですよね

4:37 AM

種類による解決規則を気にしなくて良いので。

$nantoka... _nantoka...

PropertyWrapperのそれはだいぶ厳しいよなあ・・・

初見殺しには間違いない

覚えればSwiftUIが書きやすいのはそうだけども

たぶんSwiftUIつかってる多くの人がよくわからずにそういうもんだと使ってる気がする

structでView書いてState<Int> とかやるの

4:51 AM

本当にわかりやすくなってるのかずっと疑問

4:53 AM

self.age, self.$age, self._age じゃなくて self.age.value, self.age.asBinding(), self.age の方が何が起こってるかは明確だし。最終的なコードがスッキリするのはわかるんだけども。

4:54 AM

処理系の方に値ツリーのスナップショットが残ってて差分チェックするあたりが、全然値型的なふるまいじゃないのに雰囲気はただのstructだから混乱する

PropertyWrapperって歴史的にSwiftUIありきで策定実装されたんですかね

かつそのインスタンス的なものが実ビューのイベントハンドラからイベントを受け取るところとかがすごく参照型的。 (edited)

4:55 AM

そうですよ

4:55 AM

WWDC 2019の半年前ぐらいに

4:55 AM

よくわからないプロポーザルがバコバコ通って

4:56 AM

コアチームのモチベーションがすごかったから謎だったんだけど

ばこばこ

もっと基本的で一生遅延してるプロポーザルとかもあるので。

4:56 AM

PropertyWrapperとDynamic Member KeyPathLookup (edited)

PropertyWrapperの提案はPropertyDelegateからだから最初はSwiftUI関係なかったと思う。

あ〜そうですね

ただいろいろ渋ってた割に急に通ったのは完全にSwiftUIのためっぽい。

Property Delegateは大昔からあって超初期にまだはやいっつって停止してた。

Proposalはかなり魅力的だったけどなかなか入らずで結局入るんかいって印象だった。

そう、放置系をそろそろやってくのか？と思ったら

4:58 AM

それだけだったから

4:58 AM

なんだったんだ・・・？って思った。

4:59 AM

まあSwiftUIは結局

4:59 AM

最大の言語拡張のFunction Builderが

4:59 AM

WWDC期間中にproposal draftが出るっていう

5:00 AM

だから結局、Xcode固有のSwiftオレオレ拡張って事になってるのもなんだかなあ。

5:01 AM

Xcode12の実装でFunction Builderの構文サポートと型推論はかなり良くなったはずだから、まあ、そろそろproposalが出そう。

5:02 AM

たぶんSwiftUIつかってる多くの人がよくわからずにそういうもんだと使ってる気がする

それで良いような気もするしダメな気もする　ずっとモヤモヤしている。

なんかSwiftUIのことdiscloseできないから$ _ がそのままになったとかだったら

5:02 AM

悲惨だなあと思った。

そうなんですよね〜 SwiftUIの事を秘密にしたままで

5:03 AM

抽象的な話するから

5:04 AM

本当はSwiftUIを前提に話した方が建設的だと思うんだよな。

5:04 AM

まあうまくやってたような気もするけど。 (edited)

Swift の例えばフレームワークとかでドキュメント生成はjazzyがデファクトなんですかね

12:47 AM

https://github.com/realm/jazzy

realm/jazzy

Soulful docs for Swift & Objective-C. Contribute to realm/jazzy development by creating an account on GitHub.

12:48 AM

それともこっち? https://github.com/SwiftDocOrg/swift-doc

SwiftDocOrg/swift-doc

Generates documentation for Swift projects. Contribute to SwiftDocOrg/swift-doc development by creating an account on GitHub.

DefactoはJazzy、Swift Docはとても最近リリースされて（先月？）これから期待。後発だからJazzyよりパフォーマンスが軽いとか優れてる面はちょいちょいあるみたいです。

見た感じ swift doc がモダンで

4:09 AM

jazzyは重そうな感じというか実際依存gemの量がヤバかった

4:09 AM

ただ、デフォルトの https://swiftdoc.org/ のこの見た目はちょっと

(edited)

Home

Auto-generated documentation for Swift. Command-click no more.

その依存はプロダクトに入ってこないからてんこ盛りでもいいんじゃないかな。

もちろんそうなんですけどね

bundleとか使ってgemがあちこちに散らばるのがいやで、jazzyのdockerイメージ作りました。 https://hub.docker.com/r/norionomura/jazzy

12:46 PM

Linux版でビルドできるものにしか使えないけど。

@norio_nomura このDockerfile、途中でbundlerインストールしなくていいんじゃないですか？ (edited)

4:30 PM

使ってないように見えます

Linux版のsourcekitten実行環境でもあるので、jazzyのgemだけbundlerでバージョンを合わせてLinuxで実行したいという要望に応える為に入ってます。 (edited)

あ、なるほど。DockerImageに入って使う感じなんですか。

そうですね、CIとかで「このstepだけdocker」とか出来ない環境向けですね。

https://github.com/apple/swift-evolution/blob/master/proposals/0286-forward-scan-trailing-closures.md

https://twitter.com/niw/status/1287987768149176320

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

ごしつもん: Result<S, F> を返す function の XCTestCase テストどうやってかいてますか?

1:44 AM

えらく冗長になりがち

func XCTResultSuccess<T: Equatable, E>(Result<T, E>, T) func XCTResultFailure<T, E>(Result<T,E>, (E)->Bool) これ作っておけば成功はワンライン、失敗はcast一回で済みそう (edited)

1:53 AM

SuccessもBool返すクロージャーでもいいかも

それっぽいのやったんですけど、TかEが推論できないですうあーんってswiftに言われて、まあそりゃそうかとなった

もしかしてResult.success(1)とかで与えちゃってます？

2:24 AM

関数の返値を評価したいなら、T,Eは定まってるはずなので

どうやってたんだったかな...

Result<Int,Error>.success(1)とかが相当してるはず

結局 Result.failure: Failure? Result.succss: Succes? を追加して XCTAssertEqual() で比較してる (edited)

確かにそれは楽っぽい

なんで

のやつで型推論聞かなかったんだったかな... (edited)

@swift-5.2.5

import XCTest extension String: Error {} func XCTAssertResultSuccess<T, E>(_ actual: Result<T, E>, _ expect: (T) -> Bool, file: StaticString = #file, line: UInt = #line) { switch actual { case .success(let value): XCTAssertTrue(expect(value), file: file, line: line) case .failure(let error): XCTFail("Unexpected failure: \(error)", file: file, line: line) } } func XCTAssertResultFailure<T, E>(_ actual: Result<T, E>, _ expect: (E) -> Bool, file: StaticString = #file, line: UInt = #line) { switch actual { case .success(let value): XCTFail("Unexpected success: \(value)") case .failure(let error): XCTAssertTrue(expect(error), file: file, line: line) } } XCTAssertResultSuccess(Result<Int, Error>.success(1), { $0 == 1 }) XCTAssertResultFailure(Result<Int, Error>.failure("error"), { $0 is String })

no output

動くはず

enum MyError: Error { case notEven } func f(_ a: Int) -> Result<Int, Error> { a % 2 == 0 ? .success(a) : .failure(MyError.notEven) } func assert<T: Equatable, E>(_ r: Result<T, E>, success: T) { switch r { case .success(let value): XCTAssertEqual(value, success) default: XCTFail() } } func assert<T, E: Error & Equatable>(_ r: Result<T, Error>, failure: E) { switch r { case .failure(let value): XCTAssertEqual(value as? E, failure) default: XCTFail() } } func test() { assert(f(2), success: 2) assert(f(1), failure: MyError.notEven) }

2:31 AM

できた

2:31 AM

なんでできなかったんだ...

2:32 AM

as? が消える分、failure: Failure? を使うより綺麗だなあ (edited)

関数の返値が、T or Eを逆伝搬させるような作りになってたか、或いは

2:32 AM

Result.success(1)と即値を与えたがErrorの指定をしていなかった、かな

そうかも

try result.get() はだめですか？ throws な func のテストと同じと考えれば。

XCTAssertThrows(try result.get()) { error in ... } (edited)

2:36 AM

ですかね。

2:36 AM

ダメじゃないです。でも冗長かなあと。

do { ... XCTAssertEqual(try result.get(), ...) ... } catch { XCTFail("\(error)") } とか。 (edited)

拡張しないで書くのは何パターンかあるんだけどなんかそのパターンのコピペの嵐に...

2:38 AM

unit test はコピペが多い世界なのでなるべく避けたいなあと。

Result を throws の特殊ケースだと考えると数の少ない Result は throws と同じでも良いかなぁと。 niw さんは throws 使わず Result 派でしたっけ？ (edited)

いや状況次第

2:42 AM

throws できないパターンもあるので。

2:42 AM

(てかthrows派/Result派とかあるの...) (edited)

typed throws がないから基本 Result にするという意見も聞いたことがあります。

なるほど。

非同期処理は現状で Result 使わざるを得ないですが、 async/await が導入されたら throws async になるでしょうし、そうすると結局↑のようにテストするだろうなと考えると get 方式でもいいのかなぁと。

throwはわりと躊躇なくつかうかな。asyncのときは Result.

でもよく考えると async/await 導入されたら非同期テストどうなるんでしょうね？ expectation と wait とかも書きづらいし。

expectationないとrunloopとか回らないから

2:57 AM

非同期のunit testしんどそうだなあ。

コールバック化してテストとかだと嫌ですね・・・。

2:58 AM

それなら結局テスト時は Result か。

テストする関数自体がasyncで書ければ何も問題なくなるはず

それに対応してくれたらとても書きやすくなってうれしいです。

func testFoo() async { // await 書き放題 🥳 } こうなる

await書き放題w

expectation 要らずで最高ですね。

3:00 AM

timeout が問題か。

3:01 AM

XCTestCase のプロパティで設定とかかなぁ。ちょっと気持ち悪いけど。

3:02 AM

func testFoo() async { timeout = 3.0 XCTAssertEqual(await foo(), 42) } (edited)

3:06 AM

throws async なら↓みたいな感じ？

func testFoo() async { timeout = 3.0 do { XCTAssertEqual(await try foo(...), ...) XCTAssertEqual(await try foo(...), ...) XCTAssertEqual(await try foo(...), ...) } catch { XCTFail(...) } do { // error cases _ = await try foo(...) XCTFail(...) } catch error as FooError { XCTAssertEqual(error.bar, ...) } catch { XCTFail(...) } )

swift-doc の挙動をしらべてて、

5:47 AM

Swiftではファイルをデフォルトのパーミッションで作る、ということができないような気がしている

5:47 AM

open(2)を指定したmode_tで呼ぶ術がない

5:47 AM

Yoshimasa Niwa (@niw)

By quickly searching, this is the only API in Swift that can create file with open(2) (via _CFOpenFileWithMode(),) however there are no way to control this permission value. Therefore, in Swift we can’t create file with regular permission using umask. Surprise!

5:47 AM

これほんとかなあ...?

バグっぽい

6:24 AM

https://bugs.swift.org/browse/SR-13307

6:24 AM

https://github.com/apple/swift-corelibs-foundation/pull/1876/files#diff-f731010b894263672b9190abbdd789ddL493

NSData: Refactor write(toFile:options) using FileHandle methods. by...

Remove makeTemporaryFile(inDirectory:) in favour of using _NSCreateTemporaryFile(path). FileHandle: Add internal _write(buf:length) method to write out memory buffers. FileHandle: Add a throwin...

https://github.com/apple/swift/pull/33147

[Concurrency] Add async to the Swift type system. by DougGregor ·...

Add async to the type system. async can be written as part of a function type or function declaration, following the parameter list, e.g., func doSomeWork() async { ... } async functions are distin...

2:43 AM

asyncがマージされた

2:44 AM

async関数宣言が型システムで扱えるようになっただけっぽいけど、いよいよ進むのかしら

おおおお！

おー

ちゃんと async 付いてる！ // CHECK: "$s5async1fyyYF" public func f() async { } // CHECK: "$s5async1gyyYKF" public func g() async throws { } https://github.com/DougGregor/swift/blob/b1802fa2eb9a03f3232a178ecbbc86ee2dfdeae3/test/IRGen/async.swift

DougGregor/swift

The Swift Programming Language. Contribute to DougGregor/swift development by creating an account on GitHub.

なにもしないasyncだ

async だとデフォルト throws 案もあったけど、分離する案に落ち着いたのか。

2:50 AM

ってか、 Proposal 通ってなくない？？？

今はだいたいそうですよ

通るどころか正式に出てもないよね・・・。

実装できてから審査行き

Apple 「SwiftUIに必要だから足した」 (edited)

実装してから審査はわかるけど、マージしてから審査なの？

2:51 AM

もう結論が出てるのか・・・。

asyncはswiftUIみはあんまりないけど

Apple「AppStoreの審査と同じ」

うーん例えば

AppStoreの審査は草

全部の機能がマージされるタイミングでコンパイラスイッチがついて

_modify みたいに _ も付いてないけど、いきなり async でマージなのか。

masterで -enable-async をつけたら使える状態で審査開始　とかは

2:52 AM

よくある

これから出てくる Proposal が楽しみだね。

下敷きとなるproposal draftとかが明示されてないのは気になるけど

2:53 AM

もはやSwiftUIのFunction Builderとか未だに何も正式に通ってないし

まあ、一応昔の Lattner のがあるからね。 < Proposal ドラフト

Xcode版でとりあえずリリースしたから試してみてくれ、OSS Swiftの正式採用はその後で、　もありえなくはない・・・

そういうやつは一応 _ は付いてるのでは？

2:54 AM

今の段階で無理して async ぶちこむ必要って Apple 的にあまりなさそうだけど・・・。

たしかにFunctionBuilderは @_functionBuilder か。

2:57 AM

awaitは _await でやるのかな

2日でマージって裏で結構進んでたんですね。 Futureベースのswift-nioがasyncになるだろうしまた影響大きそう……

でもマージされたの async になってない？ < アンスコ (edited)

async はそうですね。

ああ、 await か。

await のほうはアンスコするのかなあと思っただけ

await にはアンスコ付けるけど async には付けないその心は？

うーんたしか modify も最初普通に実装してすぐにアンスコつけるPRが通ったような気がする　超初期に

たしかに後からアンスコ付いてたかも。

3:00 AM

modify も別に急ぎの理由はなかったことを考えると、 Foundation の非同期 API の対応とかもあるし、とりあえず入れて気長にやっていくのかな。 Swift 5.3 じゃなくて Swift 6 だろうし。

3:01 AM

Swift 6 、 Ownership に async/await に、色々とすごいな。 (edited)

手順としてはownership完成してからじゃないとasyncawait作れないよねって話が過去にあったはずで

3:03 AM

そのへんは謎

一応 @differentiable の例もあるので、Appleだけが未審査の機能をマージしているというわけでは無い、ということは言っておきたい。

1

differentiable確かに

-enable-experimental-cxx-interop も

スイッチで封印またはアンスコ付きのどっちかはやってる気がする

https://forums.swift.org/t/swift-type-checking-is-undecidable/39024

Swift type checking is undecidable

More precisely, the introduction of SE-0142 and SE-0157 has made canonical type computation into an undecidable problem. I'll begin with the necessary background information before presenting my argument, and then outlining the next steps. Canonical types Consider these two p...

1:56 AM

ジェネリックシグネチャにおけるCanonical Typeが決定不能？

associatedtypeでprotocl自身を参照するとそうなる、のかな

2つのプロトコルを使って循環定義しててもなりそう

2:10 AM

プロトコル成約周りでコンパイラのバグをたくさん楽してきたけどやってもやっても新しい問題がみつかってきたけど

2:10 AM

これは背景にこの問題が決定不能だからっぽい、みたいな事を書いている

2:11 AM

We are also aware of examples where we don't manage to canonicalize types properly, causing miscompiles and crashes. We've been fixing these gradually over time, but we continue to discover more problems as we fix them. This was a strong hint that the underlying approach was not correct, which is why I spent some time thinking about the fundamentals of this problem. Indeed, we can now see that the reason we have struggled with correctness in this area of the language is that a solution is impossible in the general case.

2:18 AM

型を要素、型の中の型を参照する . オペレータを関係とする半群を考えると「語の問題」という既知の決定不能問題を含むことがわかる　みたいな話の流れかな

2:20 AM

protocol Impossible { associatedtype A : Impossible associatedtype B : Impossible associatedtype C : Impossible associatedtype D : Impossible associatedtype E : Impossible where A.C == C.A A.D == D.A B.C == C.B B.D == D.B C.E == E.C.A D.E == E.D.B C.C.A == C.C.A.E }

2:21 AM

func isEqual<A>(_: A, _: A) -> Bool func foo<T : Impossible>(_: T) { let x: T = ... let y: T.A = ... let z: T.B.A.B = ... isEqual(y, z) }

2:21 AM

↑こんな感じで、 T: Impossible を起点に作れる型 (ABCDEの並び) が

2:22 AM

同じ型を指してるかどうか判定しないといけない (isEqualの型チェック) ときに

2:22 AM

この Impossible なケースで無理らしい

2:23 AM

https://twitter.com/waidotto/status/1123243255154397189

y. (@waidotto)

令和になりました．決定不能問題ギャラリー第12弾は「半群の語の問題」です．有限表示半群において，生成元からなる2つの文字列が同じ元を表すかどうかは決定不能になります． https://t.co/98dOvD34X0 #たのしいけいさんろん

2:24 AM

ちょっと違うけど Tseitin半群と同じ置換関係を持ってるように見える

適当に T.A.B.C.E と T.E.D.C.A とか考えても

2:42 AM

確かに where を網羅的考えようとしてもどんどん伸びてって着地させらんない雰囲気がある

おもしろい

もうちょっと腹落ちさせたいんだけどそのあたりググってもよくわからなかった

Swift 固有のなにかがそうなってるのだろうか

確かに。ScalaとかHaskellには似たような型の機能は無いんだろうか？

今日ずっとScalaでval/let/type/typealiasとかの微妙な違いですごい辛かった

1

ｗｗ

#swift-playgrounds から

12:57 PM

@swift-main

protocol P { static func foo() } func callFoo<T>(_ v: T) { if let pProto = T.self as? P.Protocol { pProto.foo() } if let pType = T.self as? P.Type { pType.foo() } }

exit status: 1 with stderr:<stdin>:7:9: error: static member 'foo' cannot be used on protocol metatype 'P.Protocol' pProto.foo() ^~~~~~~~~~

.Protocolは純粋なメタタイプだからメソッド呼び出しはできない？ (edited)

existentialはそもそもstatic methodを実行できない

.Typeにキャストするとテーブルも付いてきて16byteになるみたい

existential typeはインスタンスを格納するコンテナーだから、existential type型に対するstaticなアクセスというのは理屈的におかしい

12:59 PM

openして取り出したTに対してアクセスするものなので

12:59 PM

metatypeそれ自体は「格納してるT」を持たない。

12:59 PM

https://qiita.com/omochimetaru/items/06c7c9ed34695b94247e

Swiftのprotocolの存在型がそれ自身のprotocolに準拠しない理由 - Qiita

概要 Swiftのprotocolには型の性質を記述する機能と、存在型として使用する機能があります。その存在型はそれ自身のprotocolに準拠しません。その理由は、スタティックメンバに関して問題が生じるからです。この記事ではそ...

12:59 PM

↑以前書いた

それはThinなmetatypeに対する呼び出しだからじゃないですか？

thinなmetatype？

thickなexistential metatypeに対する呼び出しはあると思います。

1:07 PM

thinなmetatype？

コンパイル時に決定されるがゆえにサイズが0のメタタイプ

1:07 PM

@swift-main

protocol P { static func foo() } extension Int: P { static func foo() { print("Int") } } let ty: P.Type = Int.self ty.foo()

Int

https://qiita.com/kateinoigakukun/items/8718d152c3708a7a314b#thin-metatype

Swift Type metadata - Qiita

Swiftには実行時に型情報を保持するためのType metadataという仕組みがあります。我々が頻繁に使うことはありませんが、Swiftのランタイムの動作を理解するための重要な要素です。この記事では Type metadata...

1:09 PM

過去の自分が調べてた

さっきの話からすると P.Type って exsitential P の型じゃないんじゃない？

1:09 PM

@swift-main protocol P { static func foo() } extension P { static func foo() { print("static P.foo") } } func callFoo() { P.foo() }

exit status: 1 with stderr:<stdin>:10:5: error: static member 'foo' cannot be used on protocol metatype 'P.Protocol' P.foo() ^~~~~

↑これはできないよ。 (edited)

ORTの話に戻っちゃうけど、'some' return types are only available in iOS 13.0.0 or newer ←これ辛い

P.TypeがExistential metatype containerでP.Protocolがmetatypeじゃないですか？

@swift-main

protocol P { static func foo() } extension P { static func foo() { print("static P.foo") } } extension Int: P {} func checkPE(_ a: P) { checkT(a) } func checkT<T>(_ a: T) { print(type(of: a) is P.Type) print(type(of: a) is P.Protocol) } checkPE(1)

false true

ORTの話に戻っちゃうけど、'some' return types are only available in iOS 13.0.0 or newer ←これ辛い

iOS12を切ると幸せになります

1

それが逆なんじゃないかなと思って。 P.Protocol が existential P の型じゃない？ ↑のcheckPE経由のcheckTの結果から判断した。 (edited)

ああ、Existential Pの型はP.Protocolですね、これは名前がややこしいな

1:20 PM

P.ProtocolはExistential Pの型でP.TypeはPにconformする型のメタタイプのsupertype

で、Existential P の　型 P.Protocol は、それ自体は「型のコンテナ」ではないから、真の型を内包しない。

1:21 PM

Existential P型の値は、値のコンテナだから、T型の真の値を内包する。

1:21 PM

P.TypeはPにconformする型のメタタイプのsupertype

そうだと思う。

そうするとExistential containerとExistential metatype containerの対応がきれいになるのか

「Pにconformする型のメタタイプのsupertype」この概念に名前がほしいな。今まで意識してなかったモノ。

それがExistential metatype containerですよ

なるほど

1:23 PM

そういうことか

いやースッキリした

existential container のmetatype と exsitential metatype container は　違うものであるということか

そうそう、それがややこしいですよね

1:24 PM

値のコンテナとメタタイプのコンテナだと思えるとキレイに見えてくる (edited)

メタタイプのコンテナがある事を知らなかった・・・ｗ

思いがけず理解が深まったw （ lovee さんありがとうございます）

2

むしろこちらこそお陰様で目が覚めたｗ（今日なんか一日中眠かったｗ

1:57 PM

そしてORTｶﾝｾﾞﾝﾆﾘｶｲｼﾀ

https://twitter.com/dgregor79/status/1291257597836713984

https://developer.apple.com/documentation/swift/character/3127002-asciivalue

The urge to code won, but I limited myself to an hour. Managed to get break, continue, switch, fall through, and assert all working for my multi-statement closure inference in Swift prototype: https://t.co/bikY9NT8nA

6:22 AM

let _ = ints.map { i in let value = i + 1 return String(value) }

6:23 AM

複数文クロージャの返り値の型の推論がほぼできたらしい

ツイートの英語は「コードを書く衝動が勝ったけど1時間に制限した」かな？たしかにコミットがほぼ全部1時間以内にされている早すぎ (edited)

すげー

すごいけど、戻り値の型を推論させたいモチベが微妙にイマイチわからない

例えば、今までって、↓とか書けない @swift-main let foo = { let a = 1 let b = 2 return a + b + 1 }() print(foo)

exit status: 1 with stderr:

<stdin>:1:11: error: unable to infer complex closure return type; add explicit type to disambiguate let foo = { ^ () -> <#Result#> in

foo: Int か、 { () -> Int in のどちらかが必要。

個人的には、それ書けない方がコードが読みやすいと思うんですよね…

複数行の型推論はコンパイラよりもむしろレビュアーのリーディングコストが高い気がします

flatMap reduceで死にがちな型推論も多少はマシになるかなぁ

読みにくくなるというのは一理ありますね return String(...) とかだったら、大丈夫だと思う (edited)

8:29 AM

なんでもかんでも省略するのは良くなさそう

multiline string literal のときの改行文字ってどうなるんですっけ？常に \n ？それとも環境によって変わる？

試してみようとしたらバグっぽいものが見つかってしまった

7:39 AM

@swift-5.2.5 let s = """ """ s.forEach { print($0.asciiValue!) } print(s.count)

0

これは0文字であってそうな気がします

@swift-main let s = """ abc """ dump(s)

- "abc"

"""(ここはカウントされない) (ここから開始)(ここで終了) (ここもカウントされない)""" なので

最後の改行は含まないのね

7:46 AM

変な変換掛かるの忘れてた

7:46 AM

https://forums.swift.org/t/se-0287-extend-implicit-member-syntax-to-cover-chains-of-member-references/39398

SE-0287: Extend implicit member syntax to cover chains of member re...

The review of SE-0287 "Extend implicit member syntax to cover chains of member references" begins now and runs through August 24th, 2020. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would l...

6:21 AM

let milky: UIColor = .white.withAlphaComponent(0.5) と書けるようにする提案です。

たまにそうなって型名書く事になっちゃうからたまに嬉しそう

これいいよね。

あー、これ4年前に欲しかったやつだ…

https://twitter.com/SmileyKeith/status/1295904967312592896 ^ ここで言ってることって、この警告のことなのかな？

Backward matching of the unlabeled trailing closure is deprecated; label the argument with 'completion' to suppress this warning

Keith Smiley (@SmileyKeith)

Xcode 12b5 has SE-0286 which has turned out to be pretty brutal for us. Pro-tip: add API variations instead of fixing hundreds of call sites

SE-0286、Nimbleでもまさに困ることになりました…… https://github.com/Quick/Nimble/issues/809

Xcode 12 beta 5 build error ambiguous use of 'expect' · Issue #80...

I have read CONTRIBUTING and have done my best to follow them. What did you do? I installed Xcode 12 beta 5 and tried to build our existing (test) code: it("should throw an error"...

むむ、互換性が壊れてる不具合があるんですね。

この前壊れたやつじゃん

https://github.com/apple/swift-evolution/blob/master/proposals/0286-forward-scan-trailing-closures.md ?

Johannes Weiss (@johannesweiss)

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

https://twitter.com/johannesweiss/status/1297937217789337600 @swift-5.2.5

class One { var x: Int? init?() { return nil } deinit { print("YO") } } class Two { var x: Optional<Int> init?() { return nil } deinit { print("NO") } } _ = One() _ = Two()

(edited)

@NSExceptional @steipete It’s confusing to everybody! Int? gets magically nil initialised before init. So the class is fully initialised before init (and will therefore be deinit’ed). Optional<Int> does not get this magic nil init, so the variable is uninitialised so...

YO (edited)

https://twitter.com/dgregor79/status/1300496668542918656?s=21

https://forums.swift.org/t/typed-throws/39660

#SwiftLang function builders is up for review: https://t.co/K9EPr62tCt

おお、ついに。

プロポーザルの文章がドラフトから完全に書き直されてる気がする

2:09 AM

そこに出てくる話で

2:09 AM

リテラルで頑張ると条件分岐とかだるくなるって話が出てくる

2:10 AM

このまえリテラルに分岐入れようとしてFuncB使うアイデアが出てきた話と一緒だ。

これって、文指向言語であるSwiftに

2:21 AM

部分的に式指向言語の力を与えるためのインターフェースと

2:21 AM

捉えると良い気がしてきた

2:22 AM

言語自体を式指向にするととっ散らかっちゃうから、型で縛った世界に部分的にそれを許す

確かに、FB内ならif式とswitch式が実現できてますね

2:29 AM

指定した型(例えばEither)にコンパイルされる、というのも含めて良いバランスに思える

欲を言えばwhileやforも式展開出来ると良いなと思うのだけど、難しいかな

できるっぽくない？ buildArray(_ components: [Component]) -> Component is used to build a partial result given the partial results collected from all of the iterations of a loop.

マジ？

3:28 AM

激アツじゃん、知らなかった

1

この間のおもちゃのTupleリファクタリングのついでに入れておこう。 (edited)

scalaみたいにできるようになるのかなあ

4:45 AM

alias let=val

これ Proposal 見たとき、 for-in とかと SwiftUI の ForEach の兼ね合いはどうなるんだろうと思ったんだけど、 Identifiable なら for-in でも良いとかになるのかな？ buildArray が ForEach を返す？ Identifiable のときだけとかできるかな。

forを特定の型の時にForEachに展開する、と言うことが出来るようになると思います (edited)

それはうれしいですね。 ForEach を減らせる。

6:13 AM

一方で、 Identifiable じゃないものを for-in で書いちゃうとひどいことが起こりそうですね・・・。

ある型が複数のOptionalフィールドを持っているとき、全てnilであることを検証する良い方法ってありますか？

protocol ErrorMessageProtocol { var noError: Bool } struct ErrorMessageA: ErrorMessageProtocol { var nameError: String? var valueError: String? var noError: Bool { nameError == nil && valueError == nil } }

今はこんな感じでnoErrorを書き下しているんですが、フィールドが変動すると書き漏らしが出そうで…… (edited)

Mirror使ってOKならMirror使っちゃうのが手っ取り早そう

実はMirror使ったこと無いのでちょっと不安なんですよね。 KeyPathIterableの早期導入が待ち望まれる。

@t.ae プロパティの実体を Dictionary にするとかどうでしょ？

5:50 AM

「フィールドが変動すると書き漏らしが出そう」も解決できるかと。

上の例に書いてないですがCodableになっててシリアライズするので、Dictionary だとフィールド名がぱっと見でわからないのがちょっと辛そうですね。

5:54 AM

とりあえず Mirror で書いてみます。ありがとうございました。

Mirrorだと一般にErrorMessageProtocolに直にextension書けるので楽ができそう

そうですね。ちょうど今それ書いてるところでした。

それ最近全く同じ事やったな

6:12 AM

struct ErrorProperties<T> { typealias ErrorsGetter = (T) -> [ValidationError] var getters: [ErrorsGetter] = [] init(of type: T.Type, configure: (inout ErrorProperties<T>) -> Void) { _ = type configure(&self) } mutating func add<X>(_ keyPath: KeyPath<T, Validator<X>>) { getters.append({ (target) in target[keyPath: keyPath].errors }) } mutating func add(_ keyPath: KeyPath<T, [ValidationError]>) { getters.append({ (target) in target[keyPath: keyPath] }) } func errors(of target: T) -> [ValidationError] { getters.flatMap { (getter) in getter(target) } } }

6:13 AM

Optionalじゃなくて配列だったけど

 struct Props: Encodable { var name: String = "" var nameErrors: [ValidationError] = [] var email: String = "" var emailErrors: [ValidationError] = [] var password: String = "" var passwordErrors: [ValidationError] = [] var passwordHints: [ValidationError] = [] var passwordConfirm: String = "" var passwordConfirmErrors: [ValidationError] = [] static let errorProperties = ErrorProperties(of: Self.self) { (c) in c.add(\.nameErrors) c.add(\.emailErrors) c.add(\.passwordErrors) c.add(\.passwordConfirmErrors) } var validationErrors: [ValidationError] { Self.errorProperties.errors(of: self) } }

6:13 AM

この実装だと取りこぼすリスクはあるけど。

6:14 AM

型のメタデータを自分で定義してることに相当すると思う。 static let errorProeprties だし。

keyPathで全部書くのでそうですね。

Typed throws

Typed throws Excerpt of the current discussion on the thread: https://github.com/minuscorp/swift-typed-throws/blob/master/Typed%20throws%20discussion.md The latest version of the draft can always be found in: https://github.com/minuscorp/swift-typed-throws/blob/master/SE-XX...

12:39 PM

21日前に Typed throws のしっかりした提案が投稿されてた　レスも伸びてる

お、ちゃんと rethrows についても検討されてる。

レス14でジョンマッコールがrethrowsについてツッコミを入れてから

7:56 PM

残りのレス全部rethrowsの話題だ

7:56 PM

なかなか面白い

提案されている rethrows は、高階関数に渡されたクロージャが返すエラーを、その高階関数も返す　という仕様なんだけど

7:16 AM

従来のrethrowsは、

7:17 AM

高階関数に渡されたクロージャがエラーを返すなら、その高階関数もエラーを返す、というだけの仕様で、

7:17 AM

クロージャが返すエラーの型と、高階関数が返すエラーの型の、一致性が、「今までは無かったのに新たに制約が追加される」

7:18 AM

という下位互換の無い提案になっているから、Source breaking (過去のコードがコンパイルできなくなる)になってしまう。

7:19 AM

それで、それを回避するためのアイデアがたくさん書き込まれてた。

これまで typed throws はなかったわけだから、高階関数に渡されたクロージャが単なる untyped な throws のときはこれまでと同じ挙動じゃダメなの？既存コードの関数を typed throws に変更するのは戻り値は covariant だからできそうだけど、 rethrows を持つ高階関数に渡しているところが contravariant だから壊れるって意味？

互換性の話の対象がズレてそう。

5:58 AM

まず前提として、

func loadData(file: String) throws IOError -> Data { ... } func main(files: [String]) throws IOError { // loadDataの IOError が .map から返ってきて欲しい try files.map { try loadData(file: $0) } }

(edited)

5:59 AM

で、こうなるためには extension Array { func map(_ f: (Element) throws -> U) rethrows -> [U] } ↑このrethrowsは、throwsのところのエラー型を投げる、としたいけど

6:03 AM

extension Array { func map<U>(_ f: (Element) throws -> U) rethrows -> [U] { var ret: [U] = [] for i in indices { let x = self[i] do { ret.append(try f(x)) } catch (error) { throw ArrayMapError(index: i, element: x, underlyingError: error) } } return ret } }

6:03 AM

↑例えばこのコードは従来はコンパイルできたけど、 rethrows を同じエラー型を投げる仕様にしてしまったら、コンパイルできなくなっちゃう。

型をバインドする/しないをラベル付けする必要があるんですね。型パラ増やすとかになるのかな

6:14 AM

後はこういうのも気になる。 func foo(_ a: () throws -> Int, _ b: () throws -> String) rethrows これはもう有無を言わさず型を消してErrorにしちゃわないとコンパイラの負担大きくないかな、とか。

func map<U, E>(_ f: (Element) throws E -> U) throws E -> [U] ↑rethrowsは従来仕様のままにしておいて、伝搬スローはこうやって明示的に手書きするというアイデアもあった。

6:17 AM

E == Never のとき throws しない　という扱いが入れば、これまでのrethrowsの挙動の上位互換になる。

こうした場合、throwsが無しだとNeverが伝搬するのか。

そそ。 typed throws にジェネリクスが組み合わせられるなら、rethrowsがなくてもそもそも手書きできたのだ、っていう。 (edited)

それは正解ぽいですね

そそ。 typed throws にジェネリクスが組み合わせられるなら、rethrowsがなくてもそもそも手書きできたのだ、っていう。

これResultで同じようなことしてました https://twitter.com/kateinoigakukun/status/1256523271618478081?s=20

kateinoigakukun (@kateinoigakukun)

rethrowsの伝播の代わりにResultが使えることを発見した

Resultはその性質をもってるよね。

あー、エラーを透過的に投げるんじゃなくて投げ直すパターンがあるのか。

そうなんですよ。従来のrethrowsは、エラーが「投げられる」ことだけを述べていて

6:35 AM

「同じエラーを投げる」とは言ってなかったのだ。

なんかでもそれは微妙だな。 rethrows は意味合い的にそのまま投げるもので、別のエラーで包むのはイレギュラーな使い方な気がする。 reasync を考えると rethrows は透過的なものであることが正しそうに思う。

僕もそう思う。

reasync は async/await のプロポーザルからも外れててまだ形がないけど、 rethrows までなくなってしまうとさらに遠のきそうで嫌だな・・・。

// A func foo(fn: () throws -> Void) rethrows // B func foo<erased E: Error>(fn: () throws E -> Void) rethrows E // C func foo<erased E: Error>(fn: () throws E -> Void) rethrows Error

6:40 AM

>>53 で John McCallが謎文法を書き込んでる

↓とかしたくなりそう < reasync let values = try await paths.map { try await load($0) } (edited)

Cが、従来のrethrowsの振る舞いを、新しい文法で形式的に書いてるとしたら、

6:42 AM

過去のコードはmigrationでこれに置き換えつつ

6:42 AM

シンプルなrethrowsは新しいそのまま投げる仕様に変更する

6:42 AM

って手順をとれば一応以降できそう。

erased は何のためにあるの？

書き込みを読んでもよく理解できなかったんですが、多分、静的にはEだけどコンパイル的にはErrorってことかなあ。

6:45 AM

ABI的に？

B に erased な Error が介在したいのは何なんだろう？？

従来のエラーと同じで、ジェネリックシグネチャーを引数に取らない

6:45 AM

B is the more aggressive answer, and it would generally allow callers of higher-order operations like && to maintain more precise error types.

6:45 AM

よくわからない。Bはよりアグレッシブな案らしい。

6:46 AM

https://forums.swift.org/t/typed-throws/39660/53?u=omochimetaru

Typed throws

It's a nice, simple formalization of some of the type-system behavior, but it doesn't actually change the key question with rethrows, which is whether the signature of A below is equivalent to that of B or that of C: // A func foo(fn: () throws -> Void) rethrows // B func fo...

6:46 AM

ハート７個もついてる重要書き込みなのに意味がわからなくて困る

rethrows の後ろに型を書けるようにするとして、思いつくのって↓こんなパターンだけど・・・。

// (1) func foo(fn: () throws -> Void) rethrows // (2) func foo<E: Error>(fn: () throws E -> Void) rethrows // (3) func foo(fn: () throws -> Void) rethrows FooError // (4) func foo<E: Error>(fn: () throws E -> Void) rethrows FooError

(edited)

(3) は、fooの実装者は、 E の生成ができないのでは？

6:49 AM

init がついてるプロトコルじゃないといかん。

あ、間違えた。

6:50 AM

修正した。

6:51 AM

従来の map とかは (2) 、包み直す系は (3), (4)。 (edited)

// (5) func foo(fn: () throws -> Void) rethrows Error // (6) func foo<E: Error>(fn: () throws E -> Void) rethrows Error

6:52 AM

これを追加した上で、従来の(1)と(2)は、それぞれ(5)と(6)になってほしい。で、これからの(1)と(2)は、

(5), (6) は (3), (4) と同じじゃない？具体的な型を書くという意味で。

6:52 AM

ああ、そうだね。完全に同意。 < 従来の(1)と(2)は、それぞれ(5)と(6)になってほしい。

// (7) func foo<E: Error>(fn: () throws E -> Void) rethrows E (7)になってほしい。

うん、そっちも同意。

6:53 AM

多分考えてること同じっぽい。

(1)と(2)の意味が変わって互換が壊れるのは、しょうがない！

6:53 AM

Swift6なら許される

どうせ migration 必要なんならそれでいいよね。

6:54 AM

rethrows は rethrows Error の意味にするって方法もあるのかなぁ。透過的に投げたいなら rethrows E 。それなら互換性保てる？

6:55 AM

throws が throws Error になるなら、それはそれで一貫性あるかも。

そうですね。

6:55 AM

ただ、簡単な書き方が、望ましくない方を意味しているのは

6:55 AM

年を取った言語って感じで嫌だな。

6:56 AM

新しい言語は得てしてシンプルな記法の方に、推奨挙動を込める

ただし、 map とかは func map<T, E: Error>(_ transform: (Element) throws E -> T) rethrows E になって互換性壊れるけど。

結局mapは絶対その振る舞いになってほしいんですよね

うん。

6:58 AM

簡単な書き方が、望ましくない方を意味している

↑の map みたいなときに、結局 E: Error と throws E は書かないといけないわけで、そういう意味では throws の後ろ省略できる時点で「望ましくない方」が「簡単な書き方」になってしまってそう。

6:59 AM

func map(_ transform: (Element) throws some Error -> some Any) rethrows (edited)

6:59 AM

これはありか。

省略した throws と rethrows は <E> を伝搬するって意味になれば良いんじゃ？

6:59 AM

従来のthrows / rethrows は明示的に throws Error って書いた時の挙動にする。

それは、普通の戻り値の型の throws と意味合いが変わっちゃってるんじゃない？

7:00 AM

func foo() throws -> Foo ↑これをできなくするならいいけど・・・。

7:01 AM

↑を throws Error と同じ意味にするからには、高階関数は大抵は throws some Error -> を書くことになるんじゃない？

たしかにただのthrowsと高階関数にわたすクロージャのthrowsで意味が変わるのはややこしいかも。

これって Typed Throws に関する落とし穴じゃない？高階関数において、一番簡単な書き方が望ましい書き方でなくなってしまってる。

func foo() throws -> Foo // ↑これが func foo() throws some Error -> Foo // ↑これの略記だという解釈だとどうだ？

あー、 some でもダメな気がしてきた。

「一般的な書き方が望ましい書き方ではない」この命題はシンプルに下位互換をするかしないかと言うだけの話な気がする

7:05 AM

今までは何でもアリだったのでそこに揃えるなら望ましくならないのは当然なので。。

今やりたいのは引数と戻り値で同じ E を使いたいことで、そうすると some じゃダメだ。

ああ、 some は名前引っ張れないからか。

func foo(x: some P) -> some P これはそもそも同じ型にできない。 (edited)

7:08 AM

func foo<T: P>(x: T) -> T が必要で、同じように考えると

7:09 AM

func foo<E: Error>(fn: () throws E -> Void) throws E が正しい書き方な気がする。

やっぱその形が正式ですよね

この命題はシンプルに下位互換をするかしないかと言うだけの話な気がする

これはそうかもですね。 throws の後ろを省略するのをやめれば解決。

7:10 AM

あー、話が混ざってたか。戻り値関係ないただの高階関数なら some Error でもいいのか。

7:11 AM

func foo(fn: () throws some Error -> Void)

7:11 AM

↑で some Error を使うのはありか。

7:12 AM

で、それなら一般的に throws を throws some Error にするのか throws any Error にするのかっていう話はあり得て

7:12 AM

今は throws any Error だけど、 throws some Error にするというのも悪くないか。

some Errorにしちゃうと、tryで別々のError Typeを指定した瞬間にコンパイルエラーですね

はい、その場合は明示的に throws any Error を書きます。

うーーーーーん

自動で共通の親の any Error が some Error にセットされるのだとややこしいか。

直感的には厳しそうな気がしますね

そうですか？ < 直感的には厳しそう

自動で共通の親の any Error が some Error にセットされるのだとややこしいか。

これが可能なら受け入れられそう

普通に -> some P するときと -> any P するときと同じじゃないですか？

厳しそう、というのは、Swiftユーザーが受け入れられるかどうかという話です

あーでも、自動で共通の親は、some return でもやってないし、なしかなあ。

some returnで出来ていないのはなぜかと言うと

throws を戻り値の一種と考えればむしろ自然な気が。

any P: Pが一般に宣言できてないからで

7:15 AM

Errorは any Error: Errorなので、多分出来る。

あー、自動erasure構成できない問題もからんでるのか。

7:16 AM

まだ any P がないから。

7:16 AM

でもどうなんだろうね、someは最適化指向的な言語機能だから、いつのまにか親にeraseされてるのは、罠になるから

7:16 AM

なんか結局コンパイラ警告が出たりしそうだな。

そもそもTypedになるのかという仮定もあるんですが、その上で最初は許容する方向に倒れると思います。

7:18 AM

自動でsome Errorになって、any Errorも推論されうる、というのはすごく良いバランスに見える

ふむー

@swift-5.3.3

struct AError: Error {} struct BError: Error {} func foo() -> some Error { Bool.random() ? AError() : BError() } print(foo())

exit status: 1 with stderr:

<stdin>:5:21: error: result values in '? :' expression have mismatching types 'AError' and 'BError' Bool.random() ? AError() : BError() ^~~~~~~~

現状では any P: P でもできないっぽいですね。

@swift-5.3.3

struct AError: Error {} struct BError: Error {} func foo() -> some Error { Bool.random() ? AError() as Error : BError() } print(foo())

AError()

あ、なるほど。Errorで試せるのか。

as Error を明示的に書くのであれば throws some Error でも同じことができると思います。 (edited)

これが自動で推論されるようになればいいだけなので

7:22 AM

まだ想定されてないから実装が無いだけ、のように思える

まあ追加する路線はありえるね。

うーん、 some を return するケースで暗黙的にこれが起こるのはうれしくない気が。 (edited)

someのメリットは見かけの型を消すけど特殊化して性能低下しないことにあるから

7:24 AM

その挙動があると性能低下する可能性があることになって

7:25 AM

someを書くのがアンチパターンになりかねない。

7:25 AM

あ、わかった、コンパイルエラーで、

7:25 AM

result values in '? :' expression have mismatching types 'AError' and 'BError' がでたときに

7:25 AM

fix-it ボタンクリックしたら any Error に書き換わるならいいんじゃない。

@swift-5.3.3

class Animal {} class Cat: Animal {} class Dog: Animal {} func foo() -> some Animal { Bool.random() ? Cat() : Dog() } print(foo())

main.Dog

これはできるんすよ

なにー！？

だからprotocolについてはany P: Pが一般的に宣言出来ないから実装されてないだけ (edited)

クラスならそれできるのか〜

親クラスあると吸い込まれるのかマジか

いやでも一貫性として微妙な気がしてきた。

いやそれに警告出したくなってきたわ

@swift-5.3.3 struct AError: Error {} func foo<E: Error>(x: E) { print(x) } foo(x: AError())

AError()

↑はできるわけで、

7:27 AM

それなら同じことはリバースジェネリクスでもできるべきで、

7:27 AM

Opaque Result Type でできない理由はない気がしてきた。

@swift-5.3.3

class Animal {} class Cat: Animal {} class Dog: Animal {} func foo() -> some Any { Bool.random() ? Cat() : Dog() } print(foo())

main.Cat

これも出来ますね。

7:28 AM

クラスでは畳み込まれる。

リバースジェネリクスがreturnのところで型パラメータに代入してると考えるとそうなのか。

↑は単に some Any が Animal になってるだけじゃないですか？

some Any って響きがウケる。

プロトコルの conformance とクラスの継承はまた別な気が。

CatとDogがAnimalに畳み込まれることが許されるなら AErrorとBErrorがany Errorに畳み込まれるのと同じ

some がパフォーマンスのためのものという文脈では、 Cat と Dog が Animal として扱われても問題ないですが、 any Error は Existential が出てくるので明確にパフォーマンス上のデメリットがありますよね？

7:32 AM

つまり、 any Xxx に畳まれるのは許容しないっていう選択があり得ると思ってます。

問題ない

表現は確かにポインタなのでexistential containerができるよりはマシですが、なくはないです。 Catってわかってればメソッド呼び出しのdevirtualizeができうる。（vtableを無視できる）

程度の問題って書こうとしたら書かれてた

1

うん、 vtable を介さないってのはあるけど、

7:34 AM

でもクラスの継承は抽象型としての利用を前提としてるんじゃないのかなぁ。

それはそうかも。

プロトコルはそうではないという意味で違うと思う。

structがexistentialになるのはSwiftプログラマに取っての重みが違う。

程度問題の程度が、 1 が 2 になるのと 1 が 100 になるのくらいの違いがありそうな気が。

some Xでany Xへの変換を許容しなかった場合、結果どうなるかというと

7:36 AM

return typeにany Xが使われてもっと悪い方向に向かうので

7:37 AM

まあ警告出してもいいけど許容するしかないんじゃないの。。。とは思いますね

-> some P で暗黙的に existential 返すくらいなら、明示的に -> any P した方がいいんじゃないですか？

私はその理屈は理解できますけど、一般Swiftプログラマーに理解しろ、というのはかなり無理筋だと思っていて

その違いを理解せずに適当に some P, any P を使うのはヤバい気が・・・。

基本的にはsome Pを使えばそれなりに効率よく動く、どうしようもない場合だけany Pにする、みたいなプラクティスに落としておくのがバランスが良い気がしていて

7:40 AM

リバースジェネリクスみたいな局所的な場面に閉じてるんだったら、まあ高難易度でもいいんですけど

はい、それが現実的だと思います。

throws/rethrowsみたいな凄い広いユースケースでそれが露出してしまうのはかなり厳しい

7:41 AM

デフォルトでsome Errorに倒して、暗黙的にany Errorになりうるぐらいのバランスじゃないと、利用者側のフラストレーションが大変なことになるんじゃないかと

うーんたしかに、素人はガバガバ throws 使っとけって気もするな

うーん、 throws も一種類しか投げてなければコンパイルエラーにならないので、エラーになったら throws any Error にするので良い気も？

Javaの検査例外が嫌われたことを思うと・・・

高階関数書くような人はきちんと理解して throws some Error を書けと？

7:45 AM

map とかは結局ジェネリクスになるしなぁ。

や、じゃなくて

7:45 AM

「throws some Errorがデフォルトだが、素人が使ってもエラーが出ない」を満たす必要があって

7:46 AM

これを満たしておけばかなり高確率で高性能だし、ガバってもany Errorでカバーできる

僕は some に対する親消去は良くないと思うので、無印throwsは throws any Error にしておいて

7:46 AM

パフォーマンスや型システムがちゃんとわかってる人が map とかを <E> で書くのが

7:46 AM

やっぱりバランスが良い気がしてきた。

そうすると世の大半のthrowsは全部Existentialになっちゃうけど

7:47 AM

まあそれはそれで今まで通りか

ライブラリでは Typed Throws を、アプリでは Untyped Throws をという棲み分けならそれでもいいのかなぁ。

some Errorデフォルトなら、かなりの確率でtypedに倒せるっていう旨味があるんで

foo(fn: () throws -> Void) // vs foo(fn: () throws some Error -> Void) foo<E: Error>(fn: () throws E -> Void)

あー

7:50 AM

因みにsome Errorになりうるのはクロージャ側じゃなくて関数側

せめて Opaque Argument Type がないときつい気がする・・・。

func foo() throws some Error func bar<E: Error>(_ fn: () throws E -> Void)

7:50 AM

これが正しい

あ、そういうことじゃなくて、一般論として func foo() throws が func foo() throws some Error func foo() throws any Error のどちらになるのかという話があって、

OATが導入されてGenericsをsomeで書けるようになるかつ、 throws無明記がsomeに倒れれば

7:52 AM

今ある全てのthrowsが修正無く(そこそこの確率で)高効率に動くようになる、というのは結構魅力的ですね

そこで any Error をとった場合は、これまで bar(fn: () throws -> Void) と書いてたものについて、望ましい書き方は foo(fn: () throws some Error -> Void) または foo<E: Error>(fn: () throws E -> Void) になると。

そうですね。なのでsomeに倒れたほうがいいんじゃない?(その上で内側で発生するany Errorも許容すれば、下位互換も保てる) という議論です

7:54 AM

下位互換を保つというのは、ただ既存のプログラムの挙動を保証するだけではなく言語のアップデートをキャッチアップしなくてもPGがそのまま使い続けられる、ということも含めるので (edited)

any Error: Error を考えると、高階関数の引数が throws any Error であってうれしいケースはない気がするから、無印 throws を any Error に倒してしまうと高階関数が常に辛いことになる。

7:55 AM

一方で今のまま throws some Error に倒してしまうと一般人が異なる型を throw しようとして辛い目にあう。

既存実装を性能が良い方に倒したいというのはあるか。 (edited)

折衷案として tarunon さんのいう some Error で any Error を投げるという手がある。

someに倒してミスマッチしてるケースはエラーもしくはmigrationでanyに直す　だと、自分的にはアリかな。 (edited)

しかも、それはジェネリクスの <E: Error> に対して any Error を渡せる今の仕様と一貫性がある。

7:56 AM

ただし、 -> some P してるのみミスって existential 返してしまっているケースを検出できなくなる。

7:57 AM

あー、 throws some Error についてだけ暗黙的に any Error になるという形で一般的な戻り値と区別すれば現実的な落とし所になるのかな？

まあそもそもエラーはマイナーパスなので性能最適化いらない説とかありそう。

ミスって existential 返してしまっている

これはミスではないとは思うけど

7:59 AM

どちらかというと、some Pって書いてるところに「お前これany Pって書けるやで」っていうwarningをfix-itで出してあげるぐらいで親切っぽい

7:59 AM

それが可能ならその仕組をthrowsに転用したらまー大体平和なんじゃないかな

-> some Animal で return isFoo ? Cat() : Dog() してるとかはエラーにしてほしい気がしますね。

いや〜〜〜〜〜

警告でいいのかなぁ・・・。

警告+any Animalへのfixitで良さそう

まあやりたいケースはあるかぁ。

例えばOptionalとかを渡したら警告でるのと一緒で、エラーではないですね

some から any になると API の型が変化してしまうけど、それを避けたいケースはあるかも？

因みに

8:03 AM

これが可能である条件は any P: P の場合だけで

8:03 AM

APIの型としては共変性がある状態で狭い方になってるだけなんで

8:03 AM

互換性の問題が発生しません。

そうか、 any P: P ができるようになっても、それが opt in である限り問題にならないわけですね。

8:37 AM

その上で警告はかなり良いバランスな気がしてきました。

8:40 AM

まとめると↓でしょうか。高階関数の問題も解決されますね。

無印 throws は throws some Error の意味にする
any Error: Error なので、複数種のエラーを throw すると any Error として throw されて警告が出る

(edited)

8:42 AM

こういう意見がフォーラムに出てないなら一言書いておいた方が良さそうだ。今晩でも書いてみようかな。

多分出てなかったと思う。

8:44 AM

途中の John McCallの書き込みと、 xwu さんの >>143 がなんかまとまってるっぽい雰囲気になってるからこれは読んでおくと良いかも

1

書いた。 https://forums.swift.org/t/typed-throws/39660/181

Typed throws

Let me show an option though I am not sure if it is good. Currently, it is discussed that the following two are equivalent. func foo() throws func foo() throws Error In the context of "Improving the UI of generics", it can be written as shown below. func foo() throws any E...

1

5:38 PM

やっぱ英語書くの時間かかりすぎる・・・。

any Errorが文脈すっ飛んでいきなり出てきてるように見えます

逆に考えるのです... 日本語が速すぎるのです...

1

簡潔だ

5:40 PM

In the context of "Improving the UI of generics",

↑これを受けてるから文脈は繋がってると思うよ

ああ、リンク先にあった

まだ 3 人も起きてたｗ (edited)

これを読んでないとわからんと思うけどこれは最近の必読テキストだからええやろ

これ前提の議論がされてる感じなんすか

いや、このスレッドではany X とか some Xは初出かも

このsome使うのが良いんじゃないか、は

5:42 PM

かなり多くの議論の上に成り立つから日本語でも難しそう

Opaque Result Type は実際に導入されてて、 "Improving the UI of generics" はその前提になったドキュメントだからここにいる人は知ってる前提でいいかなと。知らない人はリンク先読めるし。

5:42 PM

今日も相当話しましたしね < 日本語でも難しそう

5:44 PM

そういえば、これ書く過程で、 func map<T, E: Error>(_ transform: (Element) throws E -> T) throws E -> [T] がいいとは限らないことに気付いた。

5:44 PM

transform が複数の種類のエラーを throw するかもしれない。 (edited)

その場合はany Errorだから問題ないのでは

はい、それ前提なら問題ないんですが

5:45 PM

昼間はそれ前提でなくても↑にしたいみたいな話をしてたので。

ログ見返してたけどどこで指摘してるのかわかんなかった

5:52 PM

そもそもthrows rethrowsではクロージャ側だからORTじゃなくて普通にgenericsになるはず

5:53 PM

で、ORTでany Errorを推論されたくないという結論のもと、throws rethrowsでも封印する仮定ならthrows rethrowsでGenericsを使うのが良いとは限らない、という話？ (edited)

↓とかですね。 https://discordapp.com/channels/291054398077927425/291054454793306112/756049063803093034

6:24 PM

throw AError と throw BError があるときに E を any Error として解釈してくれるならいいんですけど、それができないなら func map<T, E: Error>(_ transform: (Element) throws E -> T) throws E -> [T] ではなく func map<T>(_ transform: (Element) throws -> T) rethrows -> [T] でないと、これまでできたことができなくなるなと。

any Errorを許容するのが丸いのではw

6:25 PM

割と僕はそれも含めて一貫した挙動が良いと考えています

ですね。 any Error が良さそう。

これもしかしてORTへの言及って初めてですかね？

とりあえず投稿前に "some" と "opaque" で検索してもこのスレッドではそれらしきものはヒットしませんでした。

https://twitter.com/maxdesiatov/status/1308107138070388737?s=21

Max Desiatov (@maxdesiatov)

It looks like concurrency support in Swift 6+ is going to be quite powerful, and quite possibly not limited to just async/await. I'm starting to see more and more references to actors in toolchain PRs. OTOH, this could be a purely internal thing. https://t.co/Vlz3GIfQeL

2:30 AM

新しいキーワードにactorって語が含まれてる

なんか最近Rubyでも見たワードですね

5:13 AM

Ractorだったかな

Akkaですね

5:30 AM

この辺かな https://doc.akka.io/docs/akka/current/actors.html

Classic Actors • Akka Documentation

Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala.

5:31 AM

actorモデル自体が発表されたのは1970年代とかなんでかなり古典

Actor については Concurrency Manifesto の中で async/await と同時に当初から言及されてますね。 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#part-2-actors-eliminating-shared-mutable-state

2:48 PM

僕は actor そのものもですが、 Part 3 で述べられている "Reliability through fault isolation" に注目しています。 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#part-3-reliability-through-fault-isolation

2:50 PM

これによって Logic Failure のハンドリングが可能になるかもしれません。

2:51 PM

actor を取り入れていることで一番有名な言語は Erlang だと思います。 (edited)

2:54 PM

Erlang の書籍で有名なのは、 Erlang の設計者自身が書いた↓と、 https://www.amazon.co.jp/dp/B079YZC22H

プログラミングErlang | ＪｏｅＡｒｍｓｔｒｏｎｇ, 榊原一矢 | 工学 | Kindleストア | Amazon

AmazonでＪｏｅＡｒｍｓｔｒｏｎｇ, 榊原一矢のプログラミングErlang。アマゾンならポイント還元本が多数。一度購入いただいた電子書籍は、KindleおよびFire端末、スマートフォンやタブレットなど、様々な端末でもお楽しみいただけます。

2:54 PM

それより新しく数年前に話題になった↓あたりがあります。 https://www.amazon.co.jp/dp/B00MLUGZIS

すごいErlangゆかいに学ぼう！ | ＦｒｅｄＨｅｂｅｒｔ, 山口能迪 | 工学 | Kindleストア | Amazon

AmazonでＦｒｅｄＨｅｂｅｒｔ, 山口能迪のすごいErlangゆかいに学ぼう！。アマゾンならポイント還元本が多数。一度購入いただいた電子書籍は、KindleおよびFire端末、スマートフォンやタブレットなど、様々な端末でもお楽しみいただけます。

まだasync awaitが入ってないのに、actorの、しかもそれのisolationとやらが出てきてるのが気になります

async/await はしっかりやってほしいね。 Swift 6 で入らなかったらかなり辛い・・・。

そうですね。server sideでfutureでガシガシ書いてると、やっぱり同期コードと比べてしんどいです。

あと個人的になんとか any Protocol を Swift 6 に入れてほしいかな。そうじゃないと any はかなりきつくなりそう・・・。

3:02 PM

破壊的変更だし。

3:02 PM

とりあえず現状の互換性維持＆警告という形ででもいいから。

早く欲しいけどくるかなあ、、

リバースジェネリクスとか some の拡張とかは後からでも何とでもできるけど、 any だけは Swift 6 で入れないと入れ時がなくなる気がしてる。

3:05 PM

実装は難しくないと思うけど、破壊的変更なのがネックで、それ単体で利便性もわかりづらいんよね。 Joe Groff のドキュメントがあるとはいえ。

actor !!

9

5:36 PM

数週間で並行処理について出てくるらしい

https://swift.org/blog/swift-system/

5:29 AM

これは嬉しい

5:30 AM

Multi-platform not Cross-platform

5:30 AM

おもしろい

DarwinとGLibCのブリッジとかエラーのthrows化とか

5:38 AM

まずそこからになるからめんどくさかったんだよね。

5:39 AM

 @_alwaysEmitIntoClient public static var ioError: Errno { Errno(_EIO) } @_alwaysEmitIntoClient @available(*, unavailable, renamed: "ioError") public static var EIO: Errno { ioError }

もうこれ書かなくて良いのか #if canImport(Darwin) import Darwin #elseif canImport(Glibc) import Glibc #endif

↑最初から死んだAPI用意してあるｗ

5:39 AM

調べてでてくるのは EIO の方だから一度補完で出させてからきれいな名前の方に誘導してる

5:40 AM

https://github.com/apple/swift-system/blob/main/Sources/System/Errno.swift

apple/swift-system

Contribute to apple/swift-system development by creating an account on GitHub.

えらい

かしこい

// @available(macOS 10.16, iOS 14.0, watchOS 7.0, tvOS 14.0, *) internal func valueOrErrno<I: FixedWidthInteger>( retryOnInterrupt: Bool, _ f: () -> I ) -> Result<I, Errno> { repeat { switch valueOrErrno(f()) { case .success(let r): return .success(r) case .failure(let err): guard retryOnInterrupt && err == .interrupted else { return .failure(err) } break } } while true }

5:43 AM

retryOnInterruptの実装はこのユーティリティで共通化してあるみたい。

5:44 AM

シグナル割り込みって普通にエラー飛べば良いと思ってたんだけどこのライブラリではデフォルトは再試行らしい。

大抵の場合リトライするからなぁ

そうなのか・・・

雑なハンドリングしかしないから分からない…

終了はアプリ側で自力のシグナルハンドラを書いて明示的にやるのがモダンなのか？

5:45 AM

まあ C-c でなくとも C-z とか考えるとそうするしかないんかな

TSCのシステムコールユーティリティは大体↑みたいな実装になってる

そうなんだ〜

5:47 AM

今後はswift-nioとswift-pm(tsc)の下請けをこれに変えるって書いてある

5:50 AM

FilePath型はnull terminatedで、ExpressibleByStringLiteralだけど、 (edited)

5:51 AM

文字列操作APIは持ってないみたい

5:52 AM

path component　の結合ぐらいはあったらよさそうだけど

5:53 AM

いまんところ FILE 系しか無いみたいだ　今後が楽しみ

このくらいのインターフェースならWasi実装も入れられそう

WASIならほぼ自明に対応実装くっつけられそうだね

1

https://github.com/apple/swift-atomics

apple/swift-atomics

Contribute to apple/swift-atomics development by creating an account on GitHub.

基本的には SE-0282 の初版でレビューされてたものですね https://forums.swift.org/t/se-0282-low-level-atomic-operations/35382

SE-0282: Low-Level Atomic Operations

The review of SE-0282: Low-Level Atomic Operations begins now and runs through April 24, 2020. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly...

12:48 AM

レビューの結果 SE-0282 自体はメモリーモデルの明確化にフォーカスして再レビュー、それを元に

The Swift project itself plans to develop one of these packages.

としていたものの成果です (edited)

libclangのラッパーなのね。

linuxでテストをビルド出来ないな。

ビルド時間比較のために4行ほど修正してSwift 5.2でビルドできる様にしたのだけど、PR受け入れてもらえるのだろうか？>swift-atomics (edited)

Linux上でSwiftPMのバグっぽいの前から気になってたんですが再現作ってみました。だれか確認してもらえますか＆既知のバグだったら教えてもらえますか。 https://github.com/t-ae/SPMDeps

t-ae/SPMDeps

Contribute to t-ae/SPMDeps development by creating an account on GitHub.

2:43 AM

概要はREADMEに書いてますが、特定条件でswift package resolve の結果がおかしいというものです。

0.0.1をチェックアウトしてswift package resolveをした時点で、.build/workspace-state.jsonにSPMDepLibの0.0.1使っているという情報が保存されます。 0.0.2をチェックアウトしてswift package resolveすると、ワーキングコピーよりもworkspace-state.jsonの情報を優先して、Package.resolvedのSPMDepLibを0.0.1に戻すのだと思います。

swift package reset したら正しく解決するようになるので何かキャッシュされてるとは思ってたのですがそこにあるんですね。予期する挙動とずれていてバグになるんじゃないかと思うのですがどうでしょう？swift package reset すると全部再フェッチ＆ビルドが必要なのも気になりますし。

swift package --force-resolved-versions resolveするとPackage.resolvedを基にworkspace-state.jsonを更新してくれるみたいなので、その後swift package resolveすれば再フェッチは回避出来そう。

5:18 AM

--force-resolved-versionsというオプションがある時点で、この様な場面は過去に問題として挙がってそう。

1

おお、そんなオプションが！ vaporプロジェクトmacで開発してubuntuに展開するんですが、依存変わるたびにこれで悩まされてたので使わせてもらいます。教えていただいてありがとうございました

‍♂️

1

@swift-5.3.3 let a: [Int?] = [nil] let b = a.randomElement()! print(type(of: b)) if case let c as Int = b { print("OK", c) }

Optional<Int>stderr:<stdin>:5:15: warning: 'as' test is always true if case let c as Int = b { print("OK", c) } ^

これなんでalways trueっていってくるんだろ？

bの型がIntだから

1:23 PM

あ、ちがうか

1:24 PM

bはInt??にびっくり付けてInt?か

1:25 PM

バグっぽい

swift-4.1.3 botでも同じだからかなり見過ごされてきてる

@swift-5.3.3 let a: Optional<Int> = 1 print(a is Int) print(Optional<Int>.self is Int.Type) (edited)

true falsestderr:

<stdin>:2:9: warning: checking a value with optional type 'Optional<Int>' against dynamic type 'Int' succeeds whenever the value is non-nil; did you mean to use '!= nil'? print(a is Int) ~ ^~~~~~ != nil <stdin>:3:26: warning: cast from 'Optional<Int>.Type' to unrelated type 'Int.Type' always fails print(Optional<Int>.self is Int.Type) ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~

(edited)

型的にはInt? is Intはfalseだけど、Optionalの特別扱いで中身を見ている？

1:31 PM

あ、nilに対してalways trueが出てるのか。誤読してた

最適化逃れコードが入ってて分かりづらかったですね

1:48 PM

@swift-5.3.3 let a:Int? = nil if case let b as Int = a { print("OK", b) }

stderr:<stdin>:2:15: warning: 'as' test is always true if case let b as Int = a { print("OK", b) } ^

switchだと

2:04 PM

@swift-5.3.3 let a: Int? = 1 switch a { case let b as Int: print("OK", b) }

exit status: 1 with stderr:

<stdin>:3:12: warning: 'as' test is always true case let b as Int: print("OK", b) ^ <stdin>:2:1: error: switch must be exhaustive switch a { ^ <stdin>:2:1: note: add missing case: '.none' switch a { ^ <stdin>:2:1: note: add missing case: '.some(_)' switch a { ^

.someも足せっていってきますね

[質問です] 秘匿情報をKeychainに保持する時に bundleId: userId: accsessTokenなど: value のように保存したい場合 kSecAttrService: ???: kSecAttrAccount: value という感じになるのかなと思っているのですが ??? の部分に入れるのは何がいいのでしょうか. kSecAttrGeneric なのかなーと眺めているのですが... https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_return_result_keys?language=objc (edited)

Keychain APIは「キー: 値」の形で保存するものなので階層を持つようような構造を保存したい場合は値の部分をまるっとその構造にする必要があります。今だったらCodableに対応させてJSONエンコードして保存する、などが簡単じゃないでしょうか。

ご回答ありがとうございます! 質問の仕方が悪く申し訳ないのですが, 階層構造を持ちたいと言うよりは bundleId && userId && accessToken みたいにできると嬉しいなと思っています. Kishikawaさんの作成されているKeychainAccessの

let keychain = KeychainAccess(service: bundleId) keychain.set('hogehoge', key: "accessToken") let token = try? keychain.get("accessToken") // "hogehoge"

という処理は bundleId && accessToken と言う条件で取得をできているのではないかと思っています. この取得の条件に userId を付加できないかなと考えているのですが, これは難しいというか, 使い方としてまちがっていますかね... (edited)

おっしゃられているようにクエリに使えるAttributeを代用するのはアリと思います。が、まあ意外にないので素直には難しいですね。キー : 値として "\(bundleId)\(serId)" : accessToken のように連結するか bundleId : userId userId : accessToken のように辿るようにするか、かと思います。

なるほど, 素直に実装するにはちょっと難しいということなんですね. ご丁寧にありがとうございます!

7:50 AM

"\(bundleId)\(serId)" : accessToken 一旦こっちでやってみようと思います.

単純に連結すると重複ができることがあるので両方で使われない文字を間に挟むとかするとだいたいうまくいくと思います。 "\(bundleId)$\(serId)"

たしかに重複の可能性ありますね. ありがとうございます, とても参考になりますmm

Swift の Documentation Comment （↓のような）についての公式ドキュメントってありますっけ？ https://github.com/apple/swift/blob/main/stdlib/public/core/Result.swift#L23-L40 ↓とか？ Latest Commit が 2015 年なのが厳しそう・・・。 https://github.com/apple/swift/blob/aa3e5904f8ba8bf9ae06d96946774d171074f6e5/docs/DocumentationComments.md

そのmdしか見たことないです

2:05 AM

そういえばちゃんとテキストが無いの変ですね。

どこかで見たな〜〜と思って今必死に探したらそれっぽいのが見つかりました。 https://developer.apple.com/library/archive/documentation/Xcode/Reference/xcode_markup_formatting_ref/index.html#//apple_ref/doc/uid/TP40016497-CH2-SW1

Markup Formatting Reference: Markup Overview

Describes the markup formatting language used for creating rich playgrounds, documenting swift code, and adding developer symbols to QuickHelp.

DocumentationComments.mdの末尾にそれへのリンクがありますよ。

ホントだ

おお。

/// 主体なのはただの慣習ですが？

スラッシュ3つにするとxcodeでフォントが変わりますよね

はい。

2:15 AM

ブロックコメントにする場合は↓が紹介されてるけど、 /// で統一するのは慣習なのかなと。 /** */ https://developer.apple.com/library/archive/documentation/Xcode/Reference/xcode_markup_formatting_ref/ComentBlock.html#//apple_ref/doc/uid/TP40016497-CH103-SW1

Markup Formatting Reference: Block Comment

Describes the markup formatting language used for creating rich playgrounds, documenting swift code, and adding developer symbols to QuickHelp.

2:16 AM

「xcodeでフォントが変わ」るのは /** も同じっぽいので。

///の方がインデントを統一しやすいんじゃないかな。 (edited)

/// は何行にもわたると流石にうざい感じがある

1:48 AM

/** */ と /// はXcodeでは同じ扱いかなあ

1:48 AM

ドキュメントコメントできない箇所につかうとなんか変なことになった気がする... のはswiftdocかsourcekittenの仕様だったか...

https://forums.swift.org/t/accepted-se-0289-result-builders/41377

[Accepted] SE-0289: Result Builders

Hello Swift Community, The second round of review for SE-0289 "Result Builders" ran from September 24 through October 1, 2020. You can find the review thread here. The first round of review for SE-0289 "Function Builders" ran from August 31 through September 14, 2020 and yo...

2:21 PM

Result Builder で決まった

4

Tuples Conform to Equatable, Comparable, and Hashable マージされてました https://github.com/apple/swift/pull/28833

[SE-0283] Implement Equatable, Comparable, and Hashable conformance...

From: https://forums.swift.org/t/hacking-equatable-conformance-on-void/25975 The tests right now are kind of lackluster, what else can I be testing with this? What else can be improved upon in this...

いいやん。

インラインアセンブリもりもり実装でwasm向けに直すのがすごく大変

2

1

VoidがEquatableになるぞヤッター！

インラインアセンブリ

なんでそんなのいるんだ？

stdlibにタプル向けのプロトコルコンフォーマンス達を事前に定義しておかないといけないんですけど、プロトコルコンフォーマンスはPC相対を含んだ構造なので普通のC++だと表現できないから？

どれのことやろ、と思って探してたけど初期状態だと隠れてた https://github.com/apple/swift/pull/28833/files#diff-c289d2fa8030a8b0648018ab48d060bb32554aa01b96399c406702089ef0033c この辺が実装か。

C++ソースをコンパイルするだけでオブジェクトファイルの中にメタ情報がレイアウトされてるようにしたいってこと？ (edited)

そうですそうです

BuiltinProtocolConformances.cpp

6:46 AM

6:47 AM

たしかにC++の定数定義じゃ記述できない・・・

 #if defined(__ELF__) " .type __swift_tupleEquatable_private, @object\n" " .local __swift_tupleEquatable_private\n" " .comm __swift_tupleEquatable_private, 128, 16\n" " .protected " TUPLE_EQUATABLE_CONF "\n" " .type " TUPLE_EQUATABLE_CONF ", @object\n" " .section .rodata\n" #elif defined(__MACH__) " .zerofill __DATA, __bss, __swift_tupleEquatable_private, 128, 4\n" " .section __TEXT, __const\n" #elif defined(_WIN32) " .lcomm __swift_tupleEquatable_private, 128, 16\n" " .section .rdata, \"dr\"\n"

こういう感じだからWebAssembly向けの実装を足さないといけないのか。

初期構築関数みたいなの作ってもヒープアロケートになっちゃうし、たしかに・・・

6:48 AM

コンパイラでしか無さそうなニーズと深いハックだなあ・・

__asm__ に書けるアセンブリコードのドキュメントが見当たらなくて、LLVMのテストケースを見ながらせっせと書いてます (edited)

そもそもwasmターゲットのときにもちゃんと動くんかしら

6:51 AM

__asm__ 文。

動くんですよそれが

なんか関数とかもアドレスじゃなくてテーブルインデックスとかで管理されるよね？

6:53 AM

概念モデルがうまくマッピングできるもんなのか

関数アドレスがテーブルインデックスとして降下していればいい感じに動くんじゃないですかね

7:02 AM

関数アドレスの相対位置からデータアドレスを得るとか、逆にデータアドレスを足し引きして関数アドレスを得る、みたいなことを意図的にできないようにしているんだったかな。

関数テーブルは別として、データアドレス空間は普通にリニアなの？

そうですね、線形メモリです (edited)

それなら同じようにコンパイルできそうだなあ。なるほど。

https://github.com/apple/swift/pull/34517

Create ConcurrencyRoadmap.md by airspeedswift · Pull Request #34517...

File describing the roadmap for introduction of concurrency. Living document expected to link to various proposals and cover features as they are designed.

5:18 PM

並行処理についての文書

5:19 PM

asyncやactorについて。

おおお、ついに

5:21 PM

やけに短いな。 https://github.com/apple/swift/blob/71aa4c983221f3f890163c55c47d8443e05f83c7/docs/ConcurrencyRoadmap.md

https://forums.swift.org/t/concurrency-actors-actor-isolation/41613

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

5:25 PM

Unlike a manifesto, which might describe multiple possible directions and in some cases unlikely directions, this document describes a single intended plan for tackling concurrency in Swift.

5:31 PM

なるほど。このドキュメントが短い理由↓

As a roadmap, this document does not go into the same level of detail as will those proposals. It also discusses features for the second phase, but detailed proposals for this area will wait until after the first phase is better defined.

[Concurrency] Actors & actor isolation

Hello all, One of the main parts of the Swift Concurrency model is actors, which provide a mechanism for isolating state in concurrent programs to eliminate data races. This proposal introduces actors and actor isolation into Swift. It is part of the Swift Concurrency effort ...

1

おおお

これは読むのが忙しくなりそう。

github の md file と forums の投稿と、関係性がよくわかってない

6:24 PM

コミュニティの全体図とリソースと誰がリードしてるのかとか図があるといいなあ

mdファイルはAppleのチームの人達が勝手に追加したりしてるやつで、今後の方針とか開発者向けのガイドとか裏技とかいろいろあるフォーラムはコミュニティと意見交換したり、evolutionプロセスをすすめるための場所

mdファイルはAppleのチームの人達が勝手に追加したりしてるやつ

7:10 PM

まじかw

いろいろ読んだ　Actorっていうのは要するに外からはasyncなメソッドしか呼び出せない特殊なクラスなんだな

masterが全部mainになっててめちゃくちゃになった...

7:54 PM

辛い

外部から呼ぶ場合のキューへの投入も自動か。

4:32 AM

スレッドセーフなクラスを作るときに手書きしてるパターンを自動でやってくれるという感じだから普通に便利そう

こういうマルチスレッドなコンポーネントを作る時って、キャンセルや停止のAPIだけは同期的にして、呼び出しの後でコールバックが起きないようにするのがパターンだけど

5:39 AM

アクターだとそういう停止も組めないのはどうすればいいんだろう？

5:40 AM

一回普通のクラスでラップするといいのかな。

actor class PlayerRefreshControler { var players: [String] = [] var gameSession: GameSession func refreshPlayers() async { ... } }

9:36 AM

↑この Roadmap に載ってるクラス、プロパティは private じゃなくていいの？

9:36 AM

queue.sync が挟まれるのかな？

じゃなくていいとは？

actor class のメソッドやプロパティがあるキューからのみアクセスされることが保証されるとして、 async メソッドは非同期にそれが行えるけど、それができないプロパティの場合はどうなるの？全部 sync 相当になる？

9:43 AM

まだ actor の Proposal は読んでなくて Roadmap 読んでるところなので、

そもそもアクセスできないです

Proposal には書いてあるのかも。

アクターのプロパティはそのアクターのメソッドの中でselfのものしかさわれない

そうなのか。 Proposal も読んでみます。

9:54 AM

スレがいっぱい

First Phase までしか読んでなかったけど "Actor Isolation and The Second Phase" 以降に色々書いてあった。

セカンドフェーズはソースブレーキングなの面白そうですね

10:01 AM

func makeDinner() async throws -> Meal { async let veggies = try chopVegetables() async let meat = marinateMeat() async let oven = try preheatOven(temperature: 350) let dish = Dish(ingredients: await [veggies, meat]) return await try oven.cook(dish, duration: .hours(3)) }

10:02 AM

structured concurrencyなんだこりゃ

10:02 AM

async letはパラレルになるらしい

あー、let自体がasyncだからawaitしてから使う気持ちなのか

10:15 AM

nurseryって保育所？は子タスクを閉じ込めてるアナロジーか。へー

asyncawaitのproposalはラトナー版から全く書き直されてますね

4:48 PM

beginAsyncとかも出てこないような？

4:49 PM

元々のやつは実行系についてはノータッチだったけど、

4:49 PM

アクターのメソッドを呼び出す時にはアクターの型のenqueueメソッドが差し込まれるので

4:50 PM

asyncを呼び出すところで実行系が変わる仕組みを差し込めるようだ

4:50 PM

それで呼び出しから戻ったら元のexecuterで続きをやるらしい

まだ読んでないけど、 beginAsync はなくなって @asyncHandler になったんじゃないの？この前の waiwai で見てた PR の感じだと。

async proposalにその辺の話が無いきがする？

5:26 PM

structuredの方に Task.runDetached というのがあったりしますね

5:27 PM

ロードマップのほうに

5:27 PM

Async handlers introduces the ability to declare a synchronous actor function as an asynchronous handler. These functions behave externally like a synchronous function, but internally are handled like an asynchronous function. This allows traditional “notification” methods, such as those on UITableViewDelegate, to perform asynchronous operations without cumbersome setup.

5:27 PM

というのはあるけど、notification的なやつって言ってるしこれはベーシックな道具じゃない感じもする

https://github.com/DougGregor/swift-evolution/blob/structured-concurrency/proposals/nnnn-structured-concurrency.md#cancellation

DougGregor/swift-evolution

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

9:01 AM

func chop(_ vegetable: Vegetable) async throws -> Vegetable { await try Task.checkCancellation() // automatically throws `CancellationError` // chop chop chop ... // ... guard await !Task.isCancelled() else { print("Canceled mid-way through chopping of \(vegetable)!") throw CancellationError() } // chop some more, chop chop chop ... }

9:01 AM

キャンセルの取り扱いはStructured Concurrencyの方に出てきた。

9:05 AM

func test_cancellation_withCancellationHandler(_ anything: Any) async -> PictureData { let handle = Task.runDetached { () -> PictureData in let file = SomeFile() return await try Task.withCancellationHandler( handler: { file.close() }, operation: { await test_cancellation_guard_isCancelled(file) }) } handle.cancel() }

9:05 AM

https://github.com/apple/swift/pull/34459/files

9:06 AM

コールバック式のやつもPRにあった。

The restrictions on only allowing access to (non-async) actor-isolated declarations on self only work so long as we can ensure that the code in which self is valid is executing non-concurrently on the actor.

言いたいことはなんとなくわかるけど、この英文の構造むずくない？

今回の Concurrency 関連の Roadmap や Proposal 群の中に Manifesto の Part 3 にあった fault isolation の話ってどこかにありますか？ Erlang の actor だと気軽にクラッシュさせられるのが良いみたいですが。まだ読んでない Structured concurrency の方にある？ https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#part-3-reliability-through-fault-isolation

Swift Concurrency Manifesto

Swift Concurrency Manifesto. GitHub Gist: instantly share code, notes, and snippets.

僕は見かけなかったです

Phase 3 以降があるのかな・・・

今回の方針決定にラトナーはあまり関わってない気がします

5:05 AM

https://forums.swift.org/t/pitch-protocol-based-actor-isolation/41677

Pitch: Protocol-based Actor Isolation

Hi all, I got a chance to write up some thoughts on how to address one of the major challenges with the recent actor model proposal: how do we ensure that values transferred between actors do not introduce shared mutable state. I'd appreciate thoughts and feedback, thanks! ...

5:06 AM

昨日(13時間前)、ラトナーが追加の提案を出したし。

Manifesto も Chris Lattner 単独で進めたんじゃなくて Joe Groff も関わってた気がする。

5:18 AM

↓こっちに Joe Groff が入ってるだけで Manifesto は Chris Lattner 単独の名前になってるな。とはいえ、 Core Team で話されてないということはないと思うけど・・・。 https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619

Concrete proposal for async semantics in Swift

Concrete proposal for async semantics in Swift. GitHub Gist: instantly share code, notes, and snippets.

ラトナーが4つのスレ全部で凄いたくさん感想とか質問とか投稿してるんですよね

8:17 AM

まーコアチームでも話してた事をもっかい公の場で投稿してるのかもしれんけど

今回のに Chris Lattner が噛んでたかは別として、前回のマニフェストを Core Team で議論してないわけはないと思うから、 Fault Isolation についても Core Team は検討したと思うんよね。

それはそうですね。

https://twitter.com/slava_pestov/status/1326236194716454912

Boolean comparison causes extremely slow compilation

It’s not just the brand new CPUs that will improve your compile times. This PR by @hollyborla and @gregtitus optimizes operator type checking performance as well: https://t.co/TwtRN7Au1h

7:13 PM

演算子たくさん使った式が推論できない問題がだいぶ改善したっぽい

3

7:14 PM

式に現れるオペランドが全部同じ型であるケースを先に探索するというヒューリスティックスっぽい。

おっ！

7:30 PM

試したい

オペランドの型が全部同じと仮定ということは、 isFoo || a + b + c + d + e + f + g >= 0 みたいなのはダメか。

実装読んでないのでなんとも言えないですがprecedanceごとに区切って探索とかはあってもよさそう

12:03 AM

木構造は型決定以前に決まるはずなので

アプリカティブスタイルがちゃんと使えるようになる？

@t.ae たしかに、全部が同じという仮定と全探索の中間に、precedenceグループごとが同じ型になっている、という仮定も置けるね。その場合は結局複数のグループごとの組み合わせ探索は起きうるけど。

そのPRこのスレッドでも話題に出てましたね https://forums.swift.org/t/boolean-comparison-causes-extremely-slow-compilation/41609

Since we moved parts of our codebase to swift, our compile times have effectively quadrupled. Trying to combat this, we've used the function and expression debug time flags to figure out if there's something to be saved by simplifying expressions. Apart from the usual suspect...

execution timeout with no output

@swift-5.3.3

import Foundation func measure(_ body: () -> Void) { let start = Date.timeIntervalSinceReferenceDate for _ in 0 ..< 10 { body() } let end = Date.timeIntervalSinceReferenceDate print((end - start) / 10) } let n = 1000 func makeNestedArray() -> [[Int]] { var a: [[Int]] = [] for _ in 0 ..< n { a.append((0 ..< n).map { _ in Bool.random() ? 1 : 0}) } return a } do { var a = makeNestedArray() measure { let y = (0 ..< n).randomElement()! for x in 1 ..< n { a[y][x] &+= a[y][x - 1] } } } do { var a = makeNestedArray() measure { let y = (0 ..< n).randomElement()! for x in 1 ..< n { let t = a[y][x - 1] a[y][x] &+= t } } }

(edited)

0.0003666043281555176 5.6803226470947266e-05 (edited)

↑これおかしくないですか？ a[y][x] &+= a[y][x - 1] を let t = a[y][x - 1] a[y][x] &+= t に変えると速くなるんですけど、おそらく前者は CoW のコピーが走ってると思います。

10:40 AM

でも、 a[y][x] &+= a[y][x - 1] でも右辺は &+= の実行前に評価が終わっているから、リファレンスカウントに関係なくて良いはず。

10:41 AM

昨日の AtCoder Beginner Contest 183 の E 問題で、おそらく↑が原因で、 Swift だと TLE （制限時間オーバー）になるという声を 2 件聞きました。

SILを確認してみたんですが確かにa[y]のリリースの位置が違いました

11:36 AM

前者はループの最後、後者はtをgetした直後にリリースされてました。それ以外は全く一致してます

なるほど。前者でもリリースのタイミングを &+= をコールする直前にできますよね？

できますね。SILレベルで命令を入れ替えてmodifyする前にリリースするようにしたところ前者と同じくらいのパフォーマンスになりました

1

SILレベルで命令を入れ替えて

これはコンパイラを修正したわけではなく、出力された SIL を直接修正したということですか？

そうですそうです。emit-silしたやつを書き換えました。

僕にできるかわからないけど、コンパイラの PR にチャレンジしてみようかな・・・。

1

このぐらいなら最適化でホイスティングされると思ってたんですけど、-Oでも同じ結果なんですね (edited)

そうなんです。 < -O

@swift-main

import Foundation func measure(_ body: () -> Void) { let start = Date.timeIntervalSinceReferenceDate for _ in 0 ..< 10 { body() } let end = Date.timeIntervalSinceReferenceDate print((end - start) / 10) } let n = 1000 func makeNestedArray() -> [[Int]] { var a: [[Int]] = [] for _ in 0 ..< n { a.append((0 ..< n).map { _ in Bool.random() ? 1 : 0}) } return a } do { var a = makeNestedArray() measure { let y = (0 ..< n).randomElement()! for x in 1 ..< n { a[y][x] &+= a[y][x - 1] } } } do { var a = makeNestedArray() measure { let y = (0 ..< n).randomElement()! for x in 1 ..< n { let t = a[y][x - 1] a[y][x] &+= t } } }

0.0021299004554748537 8.890628814697265e-05

これはアカン奴や

https://forums.swift.org/t/concurrency-evolving-the-concurrency-design-and-proposals/42184

[Concurrency] Evolving the Concurrency design and proposals

Hello all, We posted the first drafts of a number of proposals related to Swift concurrency a few weeks ago. At this time of this writing, the forum topics directly related to the concurrency proposals have more than 600 posts in total (!), which includes lots of great ideas for design improvements, requests for clarification, and so on. We'll ...

4:32 AM

非同期関係の方針の更新

4:34 AM

プロポーザルを4つから7つに分離する、reasync、アクターの同期メソッドを外から非同期で呼べる

reasync

Taskライブラリはちゃんと知りたかったし分離されて助かる

4:37 AM

非同期コンテキストの新規作成はTask.runDetachedだよって7でコンラッドが書いてる、やはりそうなんや

reasyncやっぱ最初の4本で言及なかったんだね

AppleシリコンでFloat80使えないのかな？ error: 'Float80' is unavailable: Float80 is not available on target platform.

x86系だけでは？

そうみたいですね

そもそもの、__float80がx86独自タイプなんすね。 (edited)

https://tclementdev.com/posts/what_went_wrong_with_the_libdispatch.html

7:16 PM

TLDR; まぢlibdispatch害悪だわー、asyncなんていらんかったんや。SwiftのActorもおんなじ間違いするんでねーの？

人類にマルチスレッドは早すぎたという点（←そうは書かれてないが）には同意しておきます

早すぎたんだ... (わかる) (edited)

それはともかく、意味がわかっている人の手間やミスを防ぐために簡単にしたツールを提供すると、意味がわかってない人も簡単に使えて悲劇が起こるというのは、libdispatchだろうがActorだろうがどうしようもない気がしますね。と、DispatchQueueを雰囲気で使ってるぼくがいう。

いや、でもそれはその通り、この主張のなかで問題だと思っている部分

11:28 PM

libdispatchは被害者とも言える

11:30 PM

でもasyncにしだしたら、全部asyncになって逆にパフォーマンス落ちたとかわかりみがすごい

悲劇としか言いようが・・・

11:33 PM

libdispatchも被害者だが、この記事の人も被害者で、Actorが出るとまた被害者が増えるのもたぶん予見通り。

もしかして、微細化できなかったIntelが悪いのでは?

ひどいw

非同期処理が明らかに向いてる(NWやIO)みたいなのは手動でasyncとか使えると良くって

1:03 AM

それ以外はコンパイラがなんとかしてくれる世界が嬉しいなぁ

途中まで読んだけど、使いすぎてオーバーヘッドが増えたりデバッグしづらくなった、って、そりゃあそう

4:16 AM

意味がわかっている人の手間やミスを防ぐために簡単にしたツールを提供すると、意味がわかってない人も簡単に使えて悲劇が起こる

完全にこれでしょう

極論プログラミング言語は悪でわかってるやつが機械語書く世界が良いになってしまうから、なんともや

「マルチスレッドが速いんでしょう？じゃあ全部マルチスレッドにしろ！」ってやって自爆する話はiOSやDispatchQueueに限らず昔から聞きますね

CS多少齧ってればマルチスレッドのオーバーヘッドがどの程度あってとかは履修するから

4:18 AM

前提知識の欠如というか

というか小規模なところで計測したらわかるよね。

asyncに関していうと、functionにasyncのアノテーション付けるだけでは真に非同期になるわけではないので

「書き換えまくってたらいつのまにかアプリの性能が落ちてた」というスタンスはそもそもDispatchQueueに限らずいろいろやらかしそう

わからない太郎がパフォーマンスに著しい破滅をもたらすかというと、そうはならない気はしている

4:20 AM

「せやclassからstructに書き換えたろwww」「メモリ枯渇したンゴ、structは悪！」とか容易に想像できますね (edited)

確かに実際のawaitポイントが無いasyncならスレッドコンテキストはそのままなのでそこまで遅くはならないけど、呼び出し側でコルーチンへの書き換えは起きるから、少しは非効率なコードになるはず

本人が気付かなければ幸せなままなので

4:23 AM

そういう意味でも被害は小さい

ｗ

4:23 AM

多分

4:23 AM

なんでもActorにする、は、

4:23 AM

制限が強くなるので早々に諦めるので大丈夫なんじゃないかな

Concurrency ついていける気がしない… https://twitter.com/Catfish_Man/status/1333936848150745089

David Smith (@Catfish_Man)

This is cute. Dependency diagram showing which in-flight Swift concurrency proposals depend on which other ones https://t.co/Jq0KxnylOx

https://github.com/apple/swift/pull/34916

Concurrency: Implement withUnsafe[Throwing]Continuation by slavapes...

This PR introduces two new entry points named withUnsafe[Throwing]Continuation() in the _Concurrency module. The two new entry points have the following types: withUnsafeContinuation: <T&...

4:14 AM

withUnsafeContinuation: <T> ((UnsafeContinuation<T>) -> Void) async -> T withUnsafeThrowingContinuation: <T> ((UnsafeThrowingContinuation<T>) -> Void) async throws -> T

4:14 AM

let x: Int = await withUnsafeContinuation { c in c.resume(123) } // x = 123

4:14 AM

beginAsync的なものが出てきた。 (edited)

4:15 AM

UnsafeContinuation という名前なのが面白いですね。

一番根底のやつか

これは今夜読んでみよう。

今までのUnsafeはメモリ破壊とかの意味だったけど、非同期制御の基盤が壊れないように、の意味で使ってる

4:16 AM

あと例外の有無で分けてありますね。

そうかクロージャの中で同期的にthrowするわけじゃないからrethrowsにできないんですね

そうだね

4:20 AM

rethrowといえば

4:20 AM

https://forums.swift.org/t/pitch-rethrowing-protocol-conformances/42373

[Pitch] Rethrowing protocol conformances

Hey all, Here's a pitch for a feature that @Philippe_Hausler, @Joe_Groff, @Tony_Parker and I have been thinking about to make rethrows also work for protocol conformances. It's motivated by some of the concurrency work, but is separable and useful on its own. Philippe has been prototyping it in the compiler so we have a fairly good sense that t...

4:21 AM

これが昨日出てた

4:22 AM

プロトコルで受けててもプロトコルのメソッドがrethrowsかつ実態の型がnon throwなメソッドでconformしている場合はnon throwになる。

4:22 AM

さっさとtyped throwsに行った方が話が簡単な気がした

ややこしくなってきたな

https://forums.swift.org/t/concurrency-asyncsequence/42417

[Concurrency] AsyncSequence

Hi everyone, @Philippe_Hausler and I would like to pitch the following proposal. We build on the Swift Concurrency pitches to add the concept of an AsyncSequence to the Swift standard library. An up-to-date version of this proposal can be found here. Async/Await: Sequences Swift's proposed async/await feature provides an intuitive, built-in w...

4:32 AM

for-inのasync版のfor-await-inをする話↑

これはべんり

asyncな道具が増えてくればこれが欲しくなるときが来るんでしょうね

4:36 AM

まさにサンプルが思いっきり extension URL { struct Lines: AsyncSequence { /* ... */ } func lines() async -> Lines } (edited)

4:36 AM

ってなってるな。

べんり

for を拡張するなら早く for inout もほしいなぁ。

5:51 AM

↓こういうやつ。 var users: [User] = ... for inout user in users { user.points += 100 }

AsyncSequence、Observableみがある

for inoutはOwnershipの整理が先ですね、なかなか進まないが

5:52 AM

Observableと似てるね。

Observable を operator のパズルで扱うより制御構文で扱えるようになるの良さそう。

うーーーん、AsyncSequenceを返す側の構文を考えると

5:53 AM

yield周りの整備をした方が良いような気もするな

似てるけど決定的に違うものな気もする

5:54 AM

async(コルーチン）は常に実行箇所が一つなので。

5:54 AM

イベントストリームとそれに対するハンドラを書いてるObservableとは違う。

Observableは頼まなくても桃がドンブラコしてくるけどAsyncSequenceは頼まないとやって来ない (edited)

発火依頼についてはsubscribeの呼び出しと、for文への到達で対応取れてると思う。

正確にはhotとcoldが…

hotとcoldはそうすねw

5:56 AM

forとの組み合わせでは対応取れてるか

hotでもcoldでも最初につなぐsubscribeの呼び出しとfor文の対応があるのは同じでは

5:57 AM

まあhotなものをasync sequenceで扱うとAPI的な違和感はかなりありそうだけど。

5:57 AM

というかだからそうか、無限ストリームを考えると、

5:57 AM

一箇所のfor awaitに到達したところで実行位置がそこに留められちゃうから

5:58 AM

subscribeを２つ呼ぶようなパターンが扱えないね。

zipしたりすんのかね

ストリームが分岐してるパターンも無理そう

5:58 AM

マージも無理そうだな、どっちか一つしかawaitできないから、

5:58 AM

流れに合わせて様々な合流戦略を制御するコードが書けない

Observableのdo記法相当のはfor文になるだろうなとは思ってたので

5:59 AM

あー

5:59 AM

その辺は解決可能だと思っていて

5:59 AM

Zip2AsyncSequenceやMergeAsyncSequenceを実装して解決する

AsyncSequence のための async let 的なものがあるとよい？ (edited)

AsyncSequenceはfor awaitに対応するprotocolなので、それに対する実装はパターンを持たせレるはず

6:00 AM

実質的にObservableのオペレーターと同じになる

zipはいけそうですけど止めるポイントが一箇所しか無いからマージは難しくないですか？

イテレータとして扱って任意のタイミングで async let で next を取り出しつつ好きなように合成すれば一応なんでもできそう？多様な operator と同等の処理はそれぞれ関数にするしかなさそうな気が。

取り出す手段がfor awaitだけだと、そうですね

6:02 AM

コールバックでも取り出せるようになってれば問題は無くなりそう

for await 使わずに next で取り出せますよね？

func next() async -> T? になってればokなのは、それはそうですね (edited)

ああ、そのnextをFutureに昇格すればなんでもコールバックベースで書けますね。

public protocol AsyncIteratorProtocol { associatedtype Element mutating func next() async throws -> Element? mutating func cancel() }

6:04 AM

↑のようです。

オペレーター相当のAsyncSequence実装とセットで、現行のObservableのユースケースをかなり食えるイメージ

Future に昇格というか、 async let はそれと同じことができるものだと思ってるんだけど違うのかな？まだちゃんと読めてないけど。 (edited)

async letは通り抜けておいてawaitした時に止めるものなので

6:05 AM

「３つのうちどれかが到達したら」は結局書けないと思います。

↓な理解。どれかが到達はたしかに無理か。 let a = Future { await foo() } let b = Future { await bar() } let c = await a.get() + b.get() async let a = foo() async let b = bar() let c = await a + b

6:11 AM

autoclosure で↓を作るとかかなぁ。 < どれかが到達したら let a = await one(of: await foo(), await bar()) (edited)

なるほど。autoclosure awaitってFutureと似たような振る舞いになるのか。

6:12 AM

トリッキーだから普通にFutureで受けたほうが親切な気も。

結局autoclosureを使った内部実装でFuture使わざるを得ないと思う

あ〜　たしかに。

6:21 AM

autoclosureがasyncな関数だから、内部もまたawait一箇所ルールに縛られるね。

そうです

てか

6:22 AM

Futureってasync proposalには入ってるんだっけ

6:22 AM

さっきのwithUnsafeContinuationは callback → async だけど、

6:23 AM

Future は async → callback のプリミティブで逆よね

6:25 AM

https://forums.swift.org/t/pitch-2-async-await/42420 こっちには無さそう

[Pitch #2] Async/await

Hey all, Here's a second pitch of the async/await proposal, which has been revised based on feedback from the first pitch thread. This second document has the following changes from the first pitch: One can no longer directly overload async and non-async functions. Overload resolution support remains, however, with additional justification....

ちゃんと読めてないけど、 async/await には入ってなくて、代わりに async let が出てきたのかなと思ってます。

6:27 AM

async → callback の道具が必要なのはそう。

structured concurrencyで Task.detached　が出てくるんだけどこれは callback → async なんですよね

https://twitter.com/dgregor79/status/1334983963132063744?s=21

Swift Concurrency Proposal Dependencies

In case you’re up for some light weekend reading, the #SwiftLang async/await proposal is available now and will go into review this coming Tuesday. This is the first of a series of proposals that’s part of the Swift Concurrency effort. https://t.co/upcK0txhOx

11:49 PM

asyncの正規レビュー火曜日 (edited)

読んだ英語読みやすかった仕様は特に違和感なし

実装終わってからレビューなのかあ

随分前からそうなりました

JSの場合async/awaitとmapやforEachって相性悪いけどSwiftの場合はどうなるんでしたっけ？ mapのクロージャ内でawaitするみたいなパターン。

Swiftの場合、中でawaitできる版をオーバーロードできますね

async版のクロージャをとる別のmapが追加される？

reasyncがあれば自動実装だけど最初のプロポーザルには入ってないのでその別のmapを別途書く

7:28 AM

配列に関してはAsyncSequenceの提案もありますね

7:29 AM

mapだけじゃなくてそもそものリストが非同期に読み込みたい場合があるので。

どうもどうも。調べてみます。

JSでも同じ事ができるはずですけど

7:52 AM

JSだと標準ライブラリに大きな改修は入らないのと、

7:53 AM

overloadが無いから mapAsync みたいな名前が必要になっちゃうことが問題なのかな。

ああ、確かに。await付きでクロージャを呼び出してくれる版のmapがオーバーロードで利用できるとめっちゃいいですねえ。

↓の図には reasync あるんだけど、プロポーザルないんだっけ？ https://gist.github.com/DougGregor/444575ac67cbd25bfc4b1d4fd241ae93#file-swiftconcurrencydependencies-svg

Swift Concurrency Proposal Dependencies. GitHub Gist: instantly share code, notes, and snippets.

https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md#reasync

https://forums.swift.org/t/se-0296-async-await/42605

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

ああ、「最初のプロポーザル」か。後であるんだと思ってたけど、この書き方だとあまり前向きではないのかなぁ。

SE-0296: async/await

Hi Swift Evolution! The review of SE-0296 — async/await begins now and runs through December 22, 2020. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via email or direct message in the S...

8:37 PM

審査はじまた

async/awaitもsomeと同じように下位OSでは使えないんですかね

そのへんプロポーザルに明記されてないですねランタイムライブラリがあるので使えない気がしますけど・・・

3:20 AM

I really can't comment on Apple products. The concurrency runtime support library is built as a separate library 3 that builds upon existing APIs (e.g, libdispatch) that have been around for a while. If you grab the right PR 4 and use a hack to start async code, it works fine on generally any macOS.

3:21 AM

25でマックスが質問して31でドーグが答えてる

3:24 AM

今まで言語機能のための組み込みのライブラリはstdlibしかなかったから、

3:24 AM

それとは別扱いの可能性もあるのかも

是非使えるようになってほしいですね。。

4:59 AM

浸透するまで2~3年待つのは辛い

タイミング的に

5:05 AM

WWDC2021でSwift6、asyncawait, iOSですぐ使えます！

5:06 AM

みたいになるかな？

1

libswiftConcurrencyが静的リンクでバックデプロイできればワンチャン…

Apple「なんで最新のiOS使わないの？」

5:50 AM

本気でそれがAppleの答えだから困る

1

https://forums.swift.org/t/se-0297-concurrency-interoperability-with-objective-c/42702

SE-0297: Concurrency Interoperability with Objective-C

Hi Swift Evolution! The review of Concurrency Interoperability with Objective-C begins now and runs through December 22, 2020. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via direct me...

9:05 AM

非同期審査第2段はobjc連携

9:06 AM

ここで、asyncとクロージャの相互変換が発生するが

9:06 AM

その際の生成コードについても言及されてる

9:07 AM

それによると、クロージャ→asyncはwithUnsafeContinuation

9:07 AM

async→クロージャはTask.runDetached

9:07 AM

となるようです。

https://twitter.com/dgregor79/status/1337643590386733057 Structured concurrency 使ったマージソート実装。パフォーマンスはわからないけど、なるほどねーっと。

For a little Friday evening fun, I borrowed the merge sort implementation from @rwenderlich ‘s Swift Algorithm Club, sprinkled in a little async/async let/await, and lo! It ran as a parallel merge sort. https://t.co/2lpm3NqER3

async let使いやすそうですね

9:23 AM

この例は、部分配列をコピーしてるので、遅そうだけど。

その実装、swiftNightlyボットで実行可能になりました。

1

https://swiftfiddle.com/5nche4blg5b7bkvcvw3mribpbq SwiftFiddleでも使えるようになりました。

SwiftFiddle is an online playground for creating, sharing and embedding Swift fiddles (little Swift programs that run directly in your browser).

1

Nightly BuildのDockerイメージ、masterがmainに変わったからタグ名も変わったんだけどmasterをmainにマップしたらいいと思うんだけどmasterが止まってmainが別にできたんだよな。別にどっちでもいいんだけど。

3:31 PM

ちょっと不思議に思ったという話。

https://swiftfiddle.com/5nche4blg5b7bkvcvw3mribpbq OGPのテスト

https://forums.swift.org/t/accepted-with-modification-se-0296-async-await/43318

SwiftFiddle is an online playground for creating, sharing and embedding Swift fiddles (little Swift programs that run directly in your browser).

3:55 PM

出るなあ。なんで上は出なかったのかしら。 (edited)

func mergeSort<T: Comparable>(_ array: [T]) async -> [T] { func f(_ array: ArraySlice<T>) async -> [T] { guard array.count > 1 else { return Array(array) } let middleIndex = array.startIndex + array.count / 2 async let leftArray = await f(array[array.startIndex..<middleIndex]) async let rightArray = await f(array[middleIndex..<array.endIndex]) return merge(await leftArray, await rightArray) } return await f(array[...]) }

2:27 AM

こうすれば元の配列はコピーされない

この例は、部分配列をコピーしてるので、遅そうだけど。

なんでコピーしてるのかわかんないね。 mergeSort が RandomAccessCollection を受けて Index を Int とかで縛っておけば良さそうだけど。

SwiftのArrayは、読み書きの同時アクセスに対して、たとえインデックスが異なっていてもスレッドセーフではないです

4:15 AM

その辺でややこしくなるから説明のためにコピーで書いたのかと思います

↑の場合同時アクセスは Read しかなくないかな？ Write がなければ同時アクセスしても問題ないのでは？ (edited)

分割して呼びだす部分だけならそうですね

4:26 AM

普通マージソート作る時は、結果の合成もインプレースでやると思います

4:26 AM

なのでまあ元のコードは正確にはCoWが効いてコピーは起きないけど、

4:27 AM

結果の配列の合成のところでアロケーションやコピーがバンバン起きてる

そっちはアロケーションしてるけどオーダー変わってないからまあいいんじゃない？と思ったけど、最初に分割する方も無駄だけどオーダーは変わってないか。

async let 読んだ。 async/await を並べると上から順に１つ１つ待って逐次的な処理になるけど、それを並列に実行するための仕組みなんすね。 (edited)

5:28 AM

上のmergeSortの例だと、普通にawaitで書くとleftが終わってからrightを処理するけどasync letを使って書くとleftとrightが並列に処理されると。

5:29 AM

というのをちょっとした文法の追加だけで自然に簡単に書けるのが良い、ということか。

ですね。

5:33 AM

async awaitだけだと逐次的な処理しか書けないけど、async letは並列な処理を書けるようにしてくれる、というまとめ方は良いですね

5:34 AM

ちょっとした機能だと思ってたけど結構良いものに思えてきた

async letはFuture的なもの（Taskというオブジェクトになるらしい？）を作るように自動的に右辺をWrapするみたいな、感じかな。

Structured concurrencyは上記のmergeSortの例でいうと、親のmergeSortの中で定義されたleftとrightのメソッド呼び出し（再帰だから同じメソッドだけど）が子ということで、大元のascync関数から子のasync関数を呼び出すという構造を作れる、ということを言っているのかな？

structured concurrencyの他のAPIの機能も見た感じでは

5:53 AM

「子タスクが終わらないと自身が終わらない」という関係があるのが親と子で (edited)

5:53 AM

その親子関係のことがstructuredと呼んでそうと思った

例えばTS/JSのpromise+awaitだと、async関数を呼んだ行でブロックする必要があるので、awaitだと直列にしか書けないこれが、async letが入ると任意の行でブロックが可能になり、結果として平行処理の記述が平坦に書けるようになる、という感じで見てます (edited)

あ、なるほど。でSwiftのasyncはawaitしないということを許さない（合ってる？）から「子タスクが終わらないと自身が終わらない」という関係が作れるということかな？

どうなんだろう？async let 宣言した値を await しない場合コンパイルエラーになるんかな？

それはならないとおかしいと思うけど

なるんだったら完全にそうですね。Future手書きだとawait忘れの可能性がありますもんね。

プロポーサルにはasync letはScopeに束縛されるからスコープ内でawaitしないとダメ、みたいなことが書いてあったと思う。

async let, try に対する try? に似た物を感じる

JSのasync/awaitだとConcurrentにやりたいときはどうしてもPromise.joinとか出てくるから自然に書けていいですよね。

もちろん限界はあって、もっと複雑なことをしようとすると、流石にFuture使うことになるとは思います

5:58 AM

あーでも

5:58 AM

try?もあるから割となんとかなりそうだな

5:58 AM

あと、swiftのasyncはtry-catchと混ざってない(jsは混ざってる)のも

5:58 AM

問題がシンプルになりそうな予感

混ざってるってどういう意味？

PromiseがFutureとEitherの合成モナドなので

5:59 AM

async/awaitは必然的にtry-catchが発生し得る状態になってる(かつ、もともとtrycatchしなくても怒られないのも相まって中々に

1

async throws なのに await try 強制なのちょっと微妙な気が。気持ち的には先に Future<Result<Foo, Error>> の Future を先に剥がしたいから try await が正しいと思う。

10:19 AM

ないと思うけど、万が一将来 throws や async を Result や Future を返すことと交換可能にしようみたいなことが起こった場合に齟齬が出る可能性がある。

10:20 AM

二つだけだと大丈夫か？ await だけ使うのは。三つ以上になったときに、一部だけ使うと順番が変になりそう。

むむ、たしかに。左右の並びより、内外の対応のほうがきれいな気がする。

4:54 PM

まだレビュー期間だったら書くと良いかも。

でもわざわざ順番強制が修正で入ったところにコメントしても覆ることはなさそう・・・。

12:08 AM

まあ意見くらいはしておくか。

プロポーザルのリビジョン間で変わってるなら、リビジョンのスレッドで、差分について考慮したこととか書いてあることが多いです

iPadOSで、任意の座標をタッチさせる機能は存在しますか？

dangomushi.3

iPadOSで、任意の座標をタッチさせる機能は存在しますか？

相対的に移動させるのであればマウスでできるんですが、任意の場所へタッチすることが必要であり、マウスデバイスとしてのアクセスはあきらめました。その代わりにタッチ機能で代替できるのではないかと考えています。

dangomushi.3

相対的に移動させるのであればマウスでできるんですが、任意の場所へタッチすることが必要であり、マウスデバイスとしてのアクセスはあきらめました。その代わりにタッチ機能で代替できるのではないかと考えています。

以前同様の内容で質問した時に、Private APIでアクセスすればあるかもしれないという話でしたが、マウスの移動関係のAPIはどこを探せばあるかわかりますか？ (edited)

#uikit の方が適切かな？

tarunon

#uikit の方が適切かな？

なるほどです！そちらでも質問します！

コメントするまでもなく try await になりそう。

It was suggested that try await reads better than await try. The core team agrees, and the proposal will be modified accordingly.

[Accepted with Modification] SE-0296: async/await

The review of SE-0296 – async/await has concluded and the proposal is accepted. Feedback was very positive on the concept of adding async/await in general with a few key points raised: It was suggested that try await reads better than await try. The core team agrees, and the proposal will be modified accordingly. There was some discussion of ...

acceptedだ

なんかSwiftのJIRAで報告したIssueがDuplicateで閉じちゃった。

さっき大量にadminが閉じてましたね

7:15 PM

ミスか、ほんとにduplicateなのか...

AppleのRadarに登録したからDuplicateってことなのかな

それっぽくもあるし

7:16 PM

単に機械的に古いのは全部閉じたのかもしれないし

7:16 PM

わからない

7:17 PM

このタイミングなのが、新年の仕切り直しっぽくて

7:17 PM

機械的な処理に感じる

https://bugs.swift.org/browse/SR-2145?focusedCommentId=60277&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-60277

We are investigating this and other similar incidents, and working to rectify the situation.

(edited)

手違いっぽいなあ

7:20 PM

なにがおこったんだろう

7:21 PM

"Changes by Admin on 2 Jan 2021 8:49 AM"

7:21 PM

このadminって攻撃されたのか

7:21 PM

なるほど

7:22 PM

bad123bb123 さんひどいなあ (edited)

7:25 PM

https://twitter.com/maxdesiatov/status/1345449350445588481

Max Desiatov (@maxdesiatov)

@johannesweiss @nicklockwood Not a script bug, this was a user (w/ a great nickname bad123bb123 later renamed themselves to Admin, which is the nickname that emails show) that previously tried to upload simple-backdoor.php on different issues, history still available here https://t.co/sgDgfxJUJ7

なるほど。事故ならしょうがない。

7:32 PM

もうわかってるようで一安心

だれかが戻すスクリプト走らせるのかな

7:33 PM

SwiftのJIRAが脆弱だったってことだよなあ...

最悪１日分巻き戻るとかですかねえ

正月開けが週末なのが悔やまれる

7:34 PM

普通なら今日から仕事

あれ (edited)

8:19 PM

bad123bb123 が reopen してる...

8:20 PM

ImprovementsとかがBugに変更されてる...

8:20 PM

もうめちゃくちゃだ

https://forums.swift.org/t/se-0298-async-await-sequences/43786

SE-0298: Async/Await: Sequences

Hello Swift community, The review of SE-0298 "Async/Await: Sequences" " begins now and runs through January 26, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the revi...

1

2:14 AM

次はAsyncSequenceをやるそうな！

https://github.com/jckarter/swift-evolution/blob/continuation-proposal/proposals/ABCD-continuation.md

jckarter/swift-evolution

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

7:25 AM

https://forums.swift.org/t/concurrency-continuations-for-interfacing-async-tasks-with-synchronous-code/43619

[Concurrency] Continuations for interfacing async tasks with synchr...

Hi everyone. The UnsafeContinuation API, which exposes async task continuations so they can be used to interface with existing synchronous event-based code, were buried somewhat arbitrarily in the Structured Concurrency proposal. Since there are interesting things to discuss about this API particularly, and it's an important part of interfacing ...

7:25 AM

asyncを作るAPIとして

7:26 AM

withUnsafeContinuation が提案されてる

7:26 AM

withCheckedContinuation というのもある。

Instead of leading to undefined behavior, CheckedContinuation will instead trap if the program attempts to resume the continuation multiple times.

なるほど

これどっち使うか悩ましくない？

デバッグするときはCheckedになっててほしいけどリリース時にはオーバーヘッド無いほうが嬉しい。。

1

The API is intentionally identical to the Unsafe variants, so that code can switch easily between the checked and unchecked variants.

API 切り替えろってことだと思うんだけど、あんま Swift で見かけない気が。それなら -Ounchecked ならチェックが消えるとかの方が整合性ありそう。

言われてそうな気がするスレッド見てみるか

10:16 AM

例外の有無で型を分けずに、エラーの型パラメータをもつようにしてバリアントを減らす意見あるな

10:19 AM

書かれてなさそう

rethrowsみたいにできればなぁ

例外の有無で型を分けずに、エラーの型パラメータをもつようにしてバリアントを減らす

Never で潰すってこと？複数のエラー型に対応するときは Error で埋めればいいからできるか。将来的に Typed Throws が入る可能性あるならそっちの方がいいかも。

3のdanteさんのレスです

なるほど。 withUnsafeContinuation と withUnsafeThrowingContinuation は分けたまま UnsafeContinuation に一本化できるってことか。

omochimetaru

書かれてなさそう

書き込んでみた。

How about switching checked or unchecked automatically depending on if -Ounchecked (or maybe -O) flag is on? It seems consistent with precondition (or assert).

https://forums.swift.org/t/concurrency-continuations-for-interfacing-async-tasks-with-synchronous-code/43619/27

[Concurrency] Continuations for interfacing async tasks with synchr...

How about switching checked or unchecked automatically depending on if -Ounchecked (or maybe -O) flag is on? It seems consistent with precondition (or assert).

お、良いですね！

1

I don't think we can do that automatically because the types are not layout-compatible; CheckedContinuation needs to hold on to a class instance whose lifetime tracks whether the continuation is leaked, whereas UnsafeContinuation can be implemented as a raw pointer to the task structure.

4:52 PM

なるほど？

4:53 PM

なんとかならんもんかな。

そういうもんなんかな。IFが一緒なんだったらコンパイラフラグを見て実装を入れ替えたらよさそうに思うけど。 (edited)

都度ソースからビルドするならいいけど、標準ライブラリとしては難しそうな・・・。 ABI も定まらなさそう。

4:56 PM

でもこれ手で切り替えるのいやですよねぇ

あ～そういう事かー

Ouncheckedってビルド済みのものにも影響あるんでしたっけ？

4:56 PM

ああ、違うか。標準ライブラリみたいに添付するものは

わかった。自前で作ればいいんだ。

切り替えられないからってことですね。

4:57 PM

つまり一段ラップしたものを自分で作ればいい、ということっすね。

作ればいい

withContinuation を SwiftPM として作って withUnsafeContinuation と withCheckedContinuation を切り替えればいいんだ。

4:58 PM

それだとソースからビルドするからビルド時に切り替えられますね。

読んでないんですけどwithUnsafeContinuationのメリットはパフォーマンスだけですか？

typealias Continuation = CheckedContinuation と typealias Continuation = UnsafeContinuation を切り替えるのも必要か。

Kishikawa Katsumi

読んでないんですけどwithUnsafeContinuationのメリットはパフォーマンスだけですか？

僕もちゃんと読んでないですけど多分そうだと思います。

そうだとすると、いわゆる非同期に実行したいものはパフォーマンスが支配的なのは中身だろうから基本的にwithCheckedContinuationを使う、でいいかなという気が私はしていますね。

まあここがボトルネックになることもあまりなさそうだし、プロダクションコードが Unsafe だらけになるのも気持ち悪いし、普通に Checked で良さそうな気がしますね。

はい。そんな手間をかけるメリットあるのかな、という。

5:01 PM

128コアをめっちゃ並列に動かす、みたいなのだと差があったりするのかな？

PromiseK でも普通に check してますね。これ使いまくってても特にパフォーマンスの問題感じたことないしなぁ。 precondition だから check 自体は -Ounchecked だと消えるけど。 https://github.com/koher/PromiseK/blob/master/Sources/PromiseK/Promise.swift#L15

２回呼ばれてないかチェック、はやっぱり排他とったりするから多少コストあるのかな？

128コアをめっちゃ並列に動かす、みたいなのだと差があったりするのかな？

こういうのは差があるのかもしれませんが、 CheckedContinuation 使ってても JS で Promise 使ってるより効率良さそうな・・・。

ちなみにOuncheckedかどうかって取れないっすよね？Ouncheckedと一緒に別のフラグを渡す感じっすか？

5:06 PM

ラッパーを作る場合。

ほとんどの部分はネイティブのコルーチンになってるわけで、これ必要なのはつなぎの部分だけの話でしょうし。既存の Obj-C の API が自動で async 化されるときはこれに置き換えられる？

Kishikawa Katsumi

ちなみにOuncheckedかどうかって取れないっすよね？Ouncheckedと一緒に別のフラグを渡す感じっすか？

うーん、たしかに。 precondition とかどうなってるんでしょう。標準ライブラリだからこそできること？

5:10 PM

https://github.com/apple/swift/blob/a73a8087968f9111149073107c5242d83635107a/stdlib/public/core/Assert.swift#L82-L99

https://forums.swift.org/t/se-0300-continuations-for-interfacing-async-tasks-with-synchronous-code/43891

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

5:10 PM

_isDebugAssertConfiguration とか _isReleaseAssertConfiguration とかで分岐してる・・・。

SE-0300: Continuations for interfacing async tasks with synchronous...

Hi Swift Evolution! The review of SE-0300 — Continuations for interfacing async tasks with synchronous code begins now and runs through January 26, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the re...

2:31 AM

継続API、正式審査開始

https://qiita.com/omochimetaru/items/7aa8f4582f357293782e

Swiftで継承とプロトコルとprotocol extensionが絡んだ時のメソッド呼び出し - Qiita

Swiftで継承とプロトコルとprotocol extensionが絡んだ時に呼び出されるメソッドがわかりづらい事があるのでまとめました。バージョン $ swift --version Apple Swift version ...

4:35 AM

vtable/witnesstableのあれで爆死したコードを今日引いて多数のチームの人の数時間を溶かしたので気を付けたい

これ何回やっても壊れがちで辛い

4:55 AM

全部ちゃんとテーブルに乗る実装にするのが吉

辛い

これ パターン B が直感的に見落とすよなぁ… (edited)

runAsyncAndBlockから @main struct Main { static func main() async { await runTest(numCounters: 10, numWorkers: 100, numIterations: 1000) } } になった https://github.com/apple/swift/pull/35642

[Test] Replaced temporary function with async main. by nate-chandle...

2:39 PM

@main struct Main func main で3回もmainが出てくる

2

@main func main(){} でいいのでは、、、、、

async/awaitの練習問題作り直さないと早速動かなくなりそう

Main.mainの名前はなんでもいいんですよね？

https://forums.swift.org/t/if-for-postfix-member-expressions/44159

'#if' for postfix member expressions

Hi all, Here's a pitch for a feature that expands #if functionality to postfix member expressions. I'll keep an update-version of this proposal here. Implementation is here #if for postfix member expressions Swift has conditional compilation block #if ... #endif which allows code to be conditionally compiled depending on the value of one or m...

7:24 AM

りんたろーさんがピッチ出してて、メソッドチェーンを #if できるようにする話 baseExpr #if CONDITION .someOptionalMember? .someMethod() #else .otherMember #endif

7:25 AM

おしゃれと思ったら、 >>2 でラトナーが、Swiftの #if の路線間違いだったと思うって書いててビックリ

7:25 AM

そのあとakyさんと意見交換してて面白い。

FWIW I disagree; the approach of the parser being able to understand all of the code, independent of #if sections and compiler arguments (truly context-free), is what allowed us to support syntactic understanding of the code everywhere (syntax coloring, indentation, formatting, structure view, etc.) with just a source file or text as input.

なるほどたしかに

有効じゃない方のコードの健全性がチェックできるのが良いところだよね

@swift-main -Xfrontend -enable-experimental-concurrency

import Foundation func foo() async {} @asyncHandler func bar() { print("bar A", Thread.current) await foo() print("bar B", Thread.current) } print("main A", Thread.current) bar() print("main B", Thread.current)

(edited)

main A <Thread: 0x000000000ac0fa70> main B <Thread: 0x000000000ac0fa70> (edited)

@asyncHandler の中（の最初の suspension point まで）は同期的に実行されない？？

2:10 AM

@asyncHandler の中のスレッドが呼び出し元と変わっているという報告を受けました。

そうみたいですね

2:10 AM

実際

2:10 AM

async contextが変わらないようにするためには

2:10 AM

そうするしかないような気がする

2:11 AM

barの開始した場所と、barの再開後は同じコンテキストじゃないといけないけど

2:12 AM

barの呼び出しから最初の停止までが同期的だと、同期的な推移は同じコンテキストになるはずだから (edited)

2:12 AM

コンテキストが二つに増殖しちゃって一貫性が欠けそう

その async context ≒ Task ？

Task.currentだったかな？

async 関数を抜けるまでは Task を専有してないといけないけど、 @asyncHandler が付与された関数が同期的に実行されるなら bar の呼び出し元と bar の中は同じ Task に属していなければならない。そうすると bar の中の await (suspension point) で bar を抜けたときに呼び出し元の bar の後続処理が、 bar が専有しているはずの Task で行われてしまっておかしい、と。

2:20 AM

同期的な場合にスレッドはそのまま Task だけ切り替えることは絶対できないんだっけ？できなさそうな気がするけど確信が持てない。

絶対できない

絶対できないということはないかも・・・？コンパイラが呼び出し前に切り替え処理を挿入すればいいから。

2:44 AM

でも、今の所そういう挙動は存在してないから、

2:44 AM

asyncHandler の場合だけそういうことが起きるようになるのは良くないと思う。

2:45 AM

他の、同期からTaskを開始するAPIとしては Task.runDetached があるから

2:45 AM

asyncHandlerの呼び出しと、自分でTask.runDetachedで呼び出しをラップするのが

2:45 AM

同じ挙動になっているという仕様にしたいんじゃなかったっけ

2:50 AM

asyncHandlerの挙動設計について議論されてる文書がどこにあるか忘れた・・・

asyncHandlerはまだProposalのDraftもなかった気がする。Forumに分散してコメントがあったような気も？ @asyncHandler は別スレッドで非同期、同期的処理は Task.runDetached （を呼ぶ前に）ということになりそうだね。 (edited)

https://forums.swift.org/t/pitch-4-concurrentvalue-and-concurrent-closures-evolution-pitches/44446

Pitch #4: ConcurrentValue and @concurrent closures Evolution Pitches

Hi all, Thank you for all the great feedback on the proposal. Doug and I have been iterating on it a bit and have a draft #4 up. My sense is that this is getting close to convergence for a formal review. This proposal differs from draft #3 in the following major ways: This includes a more explicit definition of marker protocols. Conformanc...

11:19 AM

ConcurrentValue のピッチを読んだけどなかなかおもしろいです。

11:19 AM

SwiftにActorが導入されてアクターアイソレーションが導入されたとしても、

11:21 AM

参照型のオブジェクトをアクター間で受け渡してしまったら、共有オブジェクトに並行同時アクセスすることになるので、スレッドバグが起きてしまうわけです

11:21 AM

そこでこのピッチで解決しようとしているのが

11:21 AM

「スレッドをまたいで受け渡しても安全である型かどうか」を静的に検査する仕組みを作ろうということです

11:22 AM

Swiftには値型があるけど、値型のプロパティとして参照型を持っていたらだめだとか、参照型だったとしても、immutable class patternだったら安全であるとか

11:22 AM

そのへんをマーキング用のプロトコル ConcurrentValue で示す＋コンパイラがデータ構造をチェックする

11:23 AM

によって保証しようとのこと

11:23 AM

UnsafeConcurrentValueというのもあって、これは、検査なしで強制的にConcurrentValueにするためのマーカー。

11:23 AM

それと、関数型に対する @escaping のように @concurrent という属性も追加して

11:24 AM

関数がマルチスレッドセーフかどうかも検査します

11:24 AM

例えば何もキャプチャしていないクロージャなら、2つのスレッドから同時に使っても大丈夫だけど

11:25 AM

var をキャプチャしていると、そこを介してミュータブルステート共有が起きるのでだめだとか

11:25 AM

そのあたりをチェックするそうです

RustのSend/Syncっぽい

Rustにもなんかあるよね　よく覚えてないけど　結構違うものな気がする

11:27 AM

Swiftは言語自体に参照型の概念とアクターが入ってて、それを踏まえてこの機能が設計されてるから、使いやすそう (edited)

11:27 AM

Rustは、結局unsafeだらけになってしまうという話を聞いた事がある

コンパイラが自動でtrait実装を提供できないとunsafeがでてくる…

ふむ

11:33 AM

jroseさん

It’s weird to read this whole part of the proposal without any reference to Rust’s Send and Sync, which work very similarly. I don’t think we’re going to need both protocols in Swift, but it’s absolutely prior art.

これはモジュール外の型を後からConcurrentValueに準拠させたいときどうなるんだろう

omochimetaru

jroseさん

It’s weird to read this whole part of the proposal without any reference to Rust’s Send and Sync, which work very similarly. I don’t think we’re going to need both protocols in Swift, but it’s absolutely prior art.

なるほど

~~Equatableとかと同じでextensionで後付けできるって話だったような~~ いや、わからん、見直したけど言及が見つからず。 (edited)

Equatableのあと付けって基本同一ファイルでしかできなかった気がするんですよね

なるほど。

外からだとprivateなフィールドが見えなくなっちゃうので

これに関してはマークだけで実装が無いからその点は平気そう

11:38 AM

ちなみにクラスに関しては

11:38 AM

たとえプロパティとして値型のletしか持っていなかったとしても (edited)

11:38 AM

継承して追加したフィールドにmutable stateが生えるかもしれんから駄目

11:39 AM

たとえfinal classだったとしても、

11:39 AM

ABI互換を保った新しい実装がmutable stateを増やしているかもしれんから駄目

11:39 AM

final かつ frozen なら許せる気がするがややこしいのでこのピッチでは先送り

11:39 AM

って書いてあった。

11:40 AM

よってクラスの場合は UnsafeConcurrentValue をエイヤでつけることしかできない。

omochimetaru

これに関してはマークだけで実装が無いからその点は平気そう

ユーザーに見える実装がなかったとしてもコンパイラが何らかのコード生成をする気がするんですよねー。

11:41 AM

ピッチちゃんと読んでみます

いや、それは、ないって明言されていて

11:42 AM

らとなー

One of the interesting-to-me realizations is that these marker protocols are vaguely attribute-like (since they are compile time only). The problem with this viewpoint is that we want ConcurrentValue to participate in the generics system, and making attributes do that would open a ton of complexity we don't want.

11:42 AM

マーカープロトコルはアトリビュート的（コンパイルタイムだけだから）

11:43 AM

と >>5 でも書いてるしピッチにもなんかそれっぽい話があった

11:44 AM

This proposal introduces the concept of a “marker” protocol, which indicates that the protocol has some semantic property but is entirely a compile-time notion that does not have any impact at runtime.

11:44 AM

これだ。 ConcurrentValue個別の話にはいる前に「Marker Protocols」について定義？している。

Custom Executor Pitch と Structured Concurrency Pitch を読み直してるけど、だんだんわかってきた

2:38 AM

async関数がsuspension pointによって区切られた個別の同期処理にPartial Taskとして分解されていて

2:39 AM

これはUnownedJobRefとしてopaqueに表現されて

2:39 AM

Executorはenqueueメソッドでそれを受け取る。 Executorが実行するときにはjob.executeを呼ぶ。ここがダブルディスパッチなのは、Executorがスケジューリングやスレッドホッピングなどをするため。

2:41 AM

という理解であってるんかな。 SerialExecutorのgiveUpThreadとかはまだよくわかっていないけど

2:42 AM

ActorがExecutorにタスクを投入する前に

2:43 AM

tryClaimThreadして成功したら直接実行してgiveUpThreadで戻す　てことなんかなあ。

2:43 AM

スレの会話によるとDispatchQueueがasyncメソッドでもスレッドスイッチしないでmutexですませるキューカウント0のときの話と似た話をしていた

2:46 AM

なんでTaskGroup.add自体がasyncなんだ。

Custom Executorが入るとJSイベントループ向けのExecutor実装が綺麗になって嬉しいな

たしかに。

今はヘッダをコピーして、テスト用に開けられたフックポイントを使って実装してる https://github.com/swiftwasm/JavaScriptKit/pull/112/files

なんかめっちゃいろいろinclude追加してるな

4:26 AM

Executor.hがほしかったけどそこから芋づる式になってしまったやつか

1

4:27 AM

global executorを実行時に差し替える仕組みも用意するってPitchに書いてあるし

4:27 AM

きれいになりそう

まさに求めてたやつ

4:28 AM

あとはSwiftNIOが嬉しいのかな

どうなんだろう・・・ channelReadとchannelRead0とか

4:32 AM

channel周りの設計ってうまくactorに乗るのかな

https://forums.swift.org/t/future-of-swift-nio-in-light-of-concurrency-roadmap/41633/3

Future of Swift-NIO in light of Concurrency Roadmap

Hey there, realistically all this will take quite some time to pan out and fully understand all the implications on APIs. However a few "simple" things that can be done early are: The concurrency design offers Task.Handle APIs which effectively are "futures" but married together with the async world. When you look at it you realize it's not v...

よくわかっていない

It is not entirely clear how NIO would be expressed as actors

コンラッド先生がそういってるんかｗ

4:33 AM

でも8月の書き込みだし進捗してそう

4:33 AM

Handlers are pretty similar to actors in that they isolate state and run not concurrently

(edited)

4:33 AM

NIO will want to "don't hop to other executor because that executor is the same event loop as my event loop"

4:33 AM

なるほど。

4:34 AM

ktoso Konrad `ktoso` Malawski 🐟 8d Good morning everyone :wave: To follow up here, the concurrency efforts now gained another proposal: Custom Executors 19 which relates to some of the questions posed in the thread. As in: an EventLoop could be a custom executor.

4:34 AM

てか最新の書き込みで、EventLoopがCustom Executorになるだろうとさ (edited)

はやくasync/awaitでServer Side Swift書きたい

1

めっちゃ楽になりそうなんだよな〜

static func withCancellationHandler<T>( handler: @concurrent () -> Void, operation: () async throws -> T ) async rethrows -> T

7:22 AM

同期的割り込みキャンセルのインターフェース例も追記されてた

7:22 AM

これがちゃんとあるのかがずっと心配じゃった

https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md

https://forums.swift.org/t/pitch-3-actors/44470

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

8:11 AM

継続APIの3回目のレビューで、Throwingな型が廃止されて

8:12 AM

型パラメータとしてエラーの型を取るようになった

NonThrowならEにNeverを入れるってことね

func withUnsafeContinuation<T>( operation: (UnsafeContinuation<T, Never>) -> () ) async -> T func withUnsafeThrowingContinuation<T>( operation: (UnsafeContinuation<T, Error>) throws -> () ) async throws -> T

8:15 AM

ですね。withのやつはそのまま

8:18 AM

NeverかErrorのどっちかしか埋まらないのかな？自分で作る方法がないもんな

これはうーん

8:25 AM

まあそうなるか

結果がResult<T, E>で取れるAPIが生えても良さそう

Result<T, E>と入れ子にするのとどっちがいいんだろう、って思った

Yuta Saito

結果がResult<T, E>で取れるAPIが生えても良さそう

いまresumeしかないからasyncでやる事しかできないね

UnsafeContinuation<T>にして

func withUnsafeContinuation<T>( operation: (UnsafeContinuation<T, Never>) -> () ) async -> T func withUnsafeThrowingContinuation<T, E: Error>( operation: (UnsafeContinuation<Result<T, E>>) throws -> () ) async throws -> T

にすれば、throwsで受けることもResultで受けることもできそうだ

8:33 AM

でもContinuationだから継続の話ですよね、だとするとError発生は中断させたいはずで、Result入れ子は不適切だと思う

そうかーなるほど

[Pitch #3] Actors

Hello again, everyone, After yet more interesting discussion in pitch #2, we've revised the actor proposal for this, pitch #3. Changes in the third pitch: Narrow the proposal down to only support re-entrant actors. Capture several potential non-reentrant designs in the Alternatives Considered as possible future extensions. Replaced @actorInd...

1:38 AM

アクターがピッチ3になってだいぶ読みやすくわかりやすくなった

Yuta Saito

結果がResult<T, E>で取れるAPIが生えても良さそう

これよくわからなかったんですが、 func resume(with result: Result<T, E>) のことではなくて、 withUnsafeThrowingContinuation の戻り値を Result で受け取りたいケースってことですか？

そうですね。こういうのを考えてました func withUnsafeThrowingContinuation<T, E>( operation: (UnsafeContinuation<T, E>) -> () ) async -> Result<T, E> (edited)

withUnsafeContinuation （ Throwing でない）を T == Result<U, Error> に対して呼び出して resume(returning:) に Result<U, Error> を渡すのはダメですか？

おそらくそれと等価だと思います

4:06 AM

ただせっかくUnsafeContinuationにパラメータEが付いてるのに勿体ないな…と

withUnsafeThrowingContinuation だと Error になっちゃうけど、 withUnsafeContinuation で resume に Result を渡す場合はエラーの型を温存できるんじゃないでしょうか。

4:11 AM

let result: Result<Foo, FooError> = await withUnsafeContinuation { continuation in barAsync { result in continuation.resume(returning: result) } }

(edited)

4:12 AM

ああ、 UnsafeContinuation の E は有効活用できてないですね・・・。

UnsafeContinuation<Result<T, E>, Never> だとUnsafeContinuation自体のエラー型がNeverで埋められてしまうのが

4:12 AM

そうですそうです (edited)

4:13 AM

実用上は問題ないと思いますｗ

typed throws が導入されれば変わるのかもですが、このあたりも含めて変えるの大変そうですね。

https://forums.swift.org/t/se-0302-concurrentvalue-and-concurrent-closures/44919

SE-0302: ConcurrentValue and @concurrent closures

Hello, Swift community. The review of SE-0302: ConcurrentValue and @concurrent closures begins now and runs through March 1st, 2021. This review is part of the large concurrency feature, which we are trying to review in many small portions. While we've tried to make it independent of other concurrency proposals that have not yet been reviewed...

1

4:35 AM

レビュー

https://swiftfiddle.com/gozs3j2nabfsdehsb56tl2roje Async/Await、Linuxでも期待通りに動くようになった気がするんだけど誰か合ってるか見てくれません？

[Concurrency] Enable concurrent global executor on non-Darwin platf...

SwiftFiddle is an online playground for creating, sharing and embedding Swift fiddles (little Swift programs that run directly in your browser).

2

8:00 AM

このコードがAwaitしてる見た目で単にブロックしているとかではなくて、ちゃんと別スレッドで動いているのをAwaitで待っているという本来のAsync/Awaitの動きを示すコードと動きになっているかどうか。

このPR以降はLinuxでもlibdispatchの上で動くようになったので、ちゃんと別スレッドで動いてるはず…！ https://github.com/apple/swift/pull/35871

おおー、つい最近だ。いいですねえ。

あと最新の書き方だとエントリポイントはこうなります

@main struct Entrypoint { static func main() async { print("task started") do { let data = try await download("https://httpbin.org/get") let response = try await parseJson(data) print(response) } catch { print(error) } print("task end") } }

main() async でいいのか。やってみよう。 runAsyncAndBlock使わなくていいってことですよね？

Fiddleで試してみたんですけど、トップレベルのコードが別にあるっぽい？

/[REDACTED]/main.swift:48:1: error: 'main' attribute cannot be used in a module that contains top-level code @main ^ /[REDACTED]/main.swift:1:1: note: top-level code defined in this source file import Glibc ^

8:16 AM

そうですー

そうそう。mainに包んで実行している。

なるほど

そうしないと毎回自分でmain書かないと動かないから。 async mainのコードに包むようにしてみる。

1

8:22 AM

違った。swiftcじゃなくてswiftで実行してるからいくつか足してるコードがあるのはそうなんだけど、main()は別に作ってなかった。

8:23 AM

swiftでスクリプト的に実行するコードだとトップレベルでawaitするのは無理かな？

そうなのかな…？

8:24 AM

手元で試してみよ

今までのコードを @main struct Entrypoint { static func main() async { // <= ここに入力コード } } のようにして $ swiftc -parse-as-library ./main.swift $ ./main

8:27 AM

だと動きそう。

ふむふむ

8:28 AM

-parse-as-library はなに用ですか？

こうしないと@mainがついたコードをコンパイルしてくれなkった。

8:30 AM

https://bugs.swift.org/browse/SR-12683

おぉ

8:33 AM

ホントだ @mainに書き換えるタイミングで-parse-as-libraryも付くようになってる https://github.com/apple/swift/pull/35642/files

[Test] Replaced temporary function with async main. by nate-chandle...

main() asyncの中にユーザーのコードを入れるのはちょっと難しかった。 Importとかトップレベルにしかかけないものをいけないとか。

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

9:08 AM

SwiftSyntaxでTopLevelDeclを探してやるとか、大掛かりになりそう

そうですね。最初ちょっとimportだけ抜き出すとか文字列操作でやろうとしたところで、他にもいろいろありそうと思っていったんやめました。Swift Syntaxを使うでうまくできそう。

protocolとかextensionとかトップレベルでしか書けないやつがいくつかありそうですよねー (edited)

まあ現時点でいろいろ試せるようになったからこの状態でシェアしてみよう。

1

https://github.com/apple/swift/commit/e83b0a2a84ecacdebf34b19b448885faccf84513 runAsyncAndBlockのDeplecatedはこれかあ

Deprecate runAsyncAndBlock API · apple/swift@e83b0a2

We don't want people using this as a means of jumping from synchronous code to async code. It blocks the thread that it's running on and spawns a new thread to run the async code. ...

StringにはRight PaddingがあるけどLeft Paddingがないんですね。両方ほしい。

-> some View とかのようなOpaque Result Typeってオーバーライドできないですか？

class Parent { func makeView() -> some View { EmptyView() } } class Child: Parent { override func makeView() -> some View { // Method does not override any method from its superclass Text("abc") } }

へー

3:53 AM

some だから?

これはできないで正しいと思います

some View は一般的な View を意味するのではなく、ある特定の View の型を隠蔽して見せてないだけなので、できないと思います。

Parentの時点でEmptyViewが返り値であるということをコンパイラは知っていて

class Parent { func makeView() -> EmptyView { EmptyView() } } class Child: Parent { override func makeView() -> Text { Text("abc") } }

↑ができないのと同じですね。

一方ユーザーは何もわからないので、オーバーライドできるとすると齟齬が生まれる

うーん型を隠蔽してるだけなのはわかるのでなんとなく予想はつきましたけど、こうしてもできないのはなんでだろ

class Parent { func makeView() -> some View { Text("") } }

型としては Parent.makeView が Text を返すのはわからないので、そういうものだと思います。 (edited)

「型を知っていればoverrideできる」なら、「最初からその型で実装すればよい」になる

そうですね。↑をやりたい場合、どちらも戻り値の型を Text にすれば良いです。

バグの温床「コードが知り得ない知識の利用」か

3:58 AM

実装してるもののみが知っている知識を使ってしまう

3:58 AM

どちらかっていうと、でもこの場合は逆か...?

実装のみが知っている知識の濫用に当たると思います

3:59 AM

型には含まれていない情報なので

（逆だとしても同じことだけど。そしてそれが阻まれてるのはよき）

そしたらルータをDIしたい（遷移先の画面を外から注入したいとき）って、ジェネリクス以外の方法はもう AnyView 使うしかない感じです？

意図しているイメージが合っていればジェネリクスで差し込みかAnyViewになると思いますよ (edited)

AnyViewか…パフォーマンスどうだろ

（あまり気にするほどのものではないはずかとは思いますが

4:00 AM

ジェネリクスはちょっと画面数が多いからできれば避けたいですよね

確かその辺iOSDCのときに青山さんに聞いた記憶があって

「実装者のみが知りうる知識<インプリメンターズ・ナレッジ>」厨二っぽくていいな (edited)

AnyViewになるけどパフォーマンス劣化はそこまでひどくない感じ、みたいな話を聞いた気がする

omochimetaru

「実装者のみが知りうる知識<インプリメンターズ・ナレッジ>」厨二っぽくていいな (edited)

code review で「まあそのこと知ってるのはあなただけですよね」ってよくやる。

niw

code review で「まあそのこと知ってるのはあなただけですよね」ってよくやる。

その言葉、今度のコードレビューで使わせていただきますw

レビューコメント:くっ、能力者か・・・ (edited)

1

www

SwiftUI 的にはジェネリクスでやるのがご行儀が良いとは思います。型パラ付けるの面倒ではありますが、↓みたいに。 struct Button<Label> where Label : View

まあ本来はそのはずですが、流石に20も30ものジェネリクスがあると、みてるだけでも気が滅入るので…

struct Router< MyItemView, MyListView, MyPreferenceView, MyUserProfileView, MyUserProfileEditView, .... > 爆誕

そうそれ

しんじゃう

流石にそれは嫌だわー

ただこれやんないと、Viewが入出力持った時に対応できないねみたいな感じになり辛くなるケースもありそう

20, 30 の associatedtype を持った protocol 作って、 Router の型パラは一つにできないかな？ちょっと今よく考えずに発言してますが。

となると型としてラップするガワとしてのViewの定義があればワンチャン

AnyViewってラップするだけで内部のレイアウト変わることがあるのでげきればラップ避けれると良さそうですが・・・

やばすぎ情報でてきた

Iceman

AnyViewってラップするだけで内部のレイアウト変わることがあるのでげきればラップ避けれると良さそうですが・・・

mjsk…

草

4:07 AM

イレイジャ(消すのが型だけとは言っていない)

草

koher

20, 30 の associatedtype を持った protocol 作って、 Router の型パラは一つにできないかな？ちょっと今よく考えずに発言してますが。

それ結局何かしらの形でジェネリクスに反映されてしまいそうな気がするんですよね…

protocol P {} struct A: P {} struct B: P {} struct C: P {} struct D: P {} protocol FooProtocol { associatedtype X: P = A associatedtype Y: P = B associatedtype Z: P = C } struct S<Foo: FooProtocol> {} struct MyFoo: FooProtocol { typealias X = D } let s: S<MyFoo> = .init() print(s)

(edited)

4:12 AM

今のケースに当てはまるかわかりませんが、 associatedtype だとデフォルトの型を指定できるから楽になるとかないでしょうか？

使う側の型名を短くしたいだけならtypealiasは？

あーkoherさんの言いたいことわかった気が

4:19 AM

前の実装が enum 使ってビューの出しわけをしてるのをそもそも引き継いじゃいけないんだ、そうすると確かに protocol の associatedType を具象型で隠せる

4:20 AM

（ただしMockを作るのが面倒な点は変わらないきがw

そもそもこれ具体型のRouterを作る時に個々の実装の型を知ってなきゃいけなくて

4:21 AM

もちろんそのRouterへのアクセスする全ての個々のViewが、対象先のViewの型を知ってなきゃいけなくなるから

4:21 AM

Routerを作る目的からすると結構厳し見ありそうな予感

4:26 AM

あーまあ大丈夫か？

よしこんな感じに落ち着かせ（ることにし）た

protocol RouterObject: ObservableObject { associatedtype Login: View = EmptyView func loginView() -> Login associatedtype Home: View = EmptyView func homeView() -> Home } extension RouterObject { func loginView() -> EmptyView { EmptyView() } func homeView() -> EmptyView { EmptyView() } } final class Router: RouterObject { func loginView() -> Text { Text("Login") } } Router().loginView() Router().homeView()

これ結局Routerを注入する側のViewでGenericsにRouterを宣言しないといけなくなりません？で、そのViewをRouterから参照しようとするとループになりそうな

5:01 AM

5:02 AM

Encodableのマージ、あるタイミングで SingleValueEncoder 越しにできなくなったんだけど、 Encoder 越しならできるらしい・・・

5:02 AM

知らなかった・・・

SingleValueEncoderしか状態を持ってないのか

割と想像可能な挙動な気もする

マージになるのがたまたまなのか意図された結果なのか・・・

すくなくともEncoderの実装依存。。。

5:06 AM

https://developer.apple.com/documentation/swift/singlevalueencodingcontainer

A container that can support the storage and direct encoding of a single non-keyed value.

2回エンコードできるかどうかについては記述されてなさそう

呼び出し先のencodeにsingleValueContainerが含まれてると死にそう

https://github.com/apple/swift-corelibs-foundation/blob/main/Sources/Foundation/JSONEncoder.swift#L953

https://github.com/apple/swift-corelibs-foundation/blob/main/Sources/Foundation/JSONEncoder.swift#L394-L407

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

5:08 AM

OSS Foundationの場合だと、 SVEC はチェックが入ってるから死んで (edited)

5:09 AM

https://github.com/apple/swift-corelibs-foundation/pull/2987

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

5:10 AM

この実装の場合経由することになる KEC は、2回目は同じ .object を再利用するコードになっている

前見たときとかなり実装変わってるな〜と思ったら直近で巨大リファクタリングが入ってた

5:14 AM

JSON Encoding based on JSONValue by fabianfett · Pull Request #2987...

After #2966 and #2985, this is the last step to make JSON Encoding and Decoding much more performant on Linux.

8日前だね

5:16 AM

旧実装でも

5:16 AM

// If an existing keyed container was already requested, return that one.

5:17 AM

2回めのKVCの生成において、下請けのストレージ(このときは生のNSMutableDictionaryだったようだ)に同じものを返す挙動についてコメントがあるから、意図的っぽくはみえる。 (edited)

なるほど。こんど実装することがあったら気をつけよ

そうするとSVECとSVDCはわざわざ経由しないほうが良いのかな。

5:18 AM

ソッチのほうが行儀が良い気がしてそうしてた。

っぽいですね

アイエェ

Yamsはどっちのパスも塞がれてそうｗ https://github.com/jpsim/Yams/blob/adeee7ef61d9c80da61c53561d65d189670d7a36/Sources/Yams/Encoder.swift#L64-L67 https://github.com/jpsim/Yams/blob/adeee7ef61d9c80da61c53561d65d189670d7a36/Sources/Yams/Encoder.swift#L205-L222

jpsim/Yams

A Sweet and Swifty YAML parser. Contribute to jpsim/Yams development by creating an account on GitHub.

いや、 func container() のなかの canEncodeNewValue は旧実装でもあって

5:22 AM

それはまた別のチェックみたい

5:23 AM

private var canEncodeNewValue: Bool { return node == .unused }

5:23 AM

YAMSのcanEncodeNewValueは別のロジックだった・・・ダメそう

なるほど。 https://github.com/apple/swift-corelibs-foundation/blob/94691e39c205d6e863a64634988b5fb4fb9c22ec/Sources/Foundation/JSONEncoder.swift#L288

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

5:28 AM

マージに関するテストケースなさそうに見える… https://github.com/apple/swift-corelibs-foundation/blob/main/Tests/Foundation/Tests/TestJSONEncoder.swift

https://forums.swift.org/t/pitch-swiftpm-support-for-swift-scripts-revision/46717

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

さっきザッと見たけど無さそうだよね

5:32 AM

どっかで挙動が変わったら地獄が生まれそう

FoundationはOSに載ってるから

5:33 AM

iOSのアップデートによりアプリが落ちることになるな

Foundationのバージョンアップで壊れるやつ、稀によくある

1

serializerで仕様がふんわりなことはよくあるし、まあなんか実際のところは雰囲気でなんとなーく動いてて、でもたまに死んだりしてでもまあレアなことだから世の中それで回ってるんだろうなあという印象

ちょうどこの間それやったんですが、野良Encoder実装はほぼほぼ対応してない(msgpackのEncoderもだめだった)ので、どうしようもない場合を除いてやめておいたほうが無難そう (結局その時はJSONEncoderで吐いたJSONをJSONSerializationで戻してmsgpackのライブラリに食わせた)

JSONの場合、仕様が先に存在している場合もあるので・・・

6:07 AM

でも野良コーデックが対応してないってことは

6:07 AM

やっぱりちゃんとはっきりさせておいたほうがいいんだろうな

6:07 AM

めんどくさいな・・・

[Pitch] SwiftPM support for Swift scripts (revision)

Pitch: SwiftPM support for Swift scripts Proposal: SE-NNNN Authors: Rahul Malik, Ankit Aggarwal, David Hart, YR Chen Review Manager: TBD Status: Awaiting implementation Introduction Swift is a general-purpose language that aims to expand its availability and impact on various domains and platforms. We believe great scripting support and expe...

6:00 AM

Swiftのスクリプティングモードの仕様の提案

6:01 AM

package.swiftのpackage指定と同じ文法で@packageをimportの上に書くという仕様で、良さそう

SwiftでAPI公開してるプロジェクトでdelegateのprotocolに新しく追加する場合って、破壊的な変更になってしまうのってどうやって回避してるんだろう

6:45 AM

1. じつはわかってるので最初から @objc optional で公開している

1. @obj optional 2. extensionでデフォルト実装を与える

2. extension でデフォルトの実装を与えてる。派生して呼べなくなってもしらない

3. 別名のプロトコル

ぐぅー、そうかぁ...

派生して呼べなくなってもしらない

これはどういう心配ですか？

なんだっけ、protocolを実装してるclassを派生してoverrideしても見えないってやつ

ああ。

厳しい...

6:47 AM

majorバージョンあげるか...

6:47 AM

こっそりminorで破壊的な変更をするか... (行儀悪い)

継承元でconformしてるprotocolのメソッドと、同名のメソッドを継承先で実装したときに呼ばれないやつか

はい

まず継承元で実装しましょう

それはprotocol使う側の問題なんだよなあ...

使う側の問題なので提供側の態度としては問題がないのでは

つまりextensionを与えるとそれも破壊的な変更になってしまう

6:49 AM

なかなか手厳しい

ライブラリとしての下位互換性はこわれてないのでは？

6:49 AM

その問題はprotocolのデフォルト実装についてまわる問題で

6:50 AM

互換性とかライブラリの話とはそもそも独立

ああ、そうか、確かに。

6:50 AM

与えるか...

ポリシーとして、その問題があるからdefault実装は使わないって話なら、だめですが。

できれば避けたいのが本音

そしたら別名のプロトコルにするしかなさそう

だなあ...

もともとが protocol P1 だとして、 protocol P2 を導入しつつ

6:53 AM

P1からP2に変換するアダプタを用意してライブラリ内部はP2に書き換える、P1からのインターフェースはアダプタかますようにして互換性を保つ。

なんらかそう言うのが必要になりますね...

6:57 AM

delegate2

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createwindowexa

CreateWindowExA function (winuser.h) - Win32 apps

Creates an overlapped, pop-up, or child window with an extended window style; otherwise, this function is identical to the CreateWindow function.

A/Wは文字のやつじゃなかったっけ

https://docs.microsoft.com/ja-jp/windows/win32/api/winnls/nf-winnls-enumcalendarinfoexex?redirectedfrom=MSDN

EnumCalendarInfoExEx function (winnls.h) - Win32 apps

Enumerates calendar information for a locale specified by name.Note The application should call this function in preference to EnumCalendarInfo or EnumCalendarInfoEx if designed to run only on Windows Vista and later. Note This function can enumerate data that changes between releases, for example, due to a custom locale. If your application m...

Exの部分か

6:58 AM

ExEx w

Exの部分です

6:58 AM

無限に伸ばせるぞい

delegatex

基本delegateパターンは@objc optionalが無難な気はします

6:59 AM

無理に純swiftにする必要はなくて、純swiftの必要があるならdelegateよりは各所handler渡しにしちゃった方が良い (edited)

それはあるな。

7:02 AM

自分はdelegateパターンってそもそもSwiftで使わなくて、必要なだけ関数型のプロパティをセットさせるようにしているから

7:02 AM

今回みたいなコールバックの追加の際はプロパティが増えるだけ

まあそうなんですよねー

7:02 AM

失敗した

7:02 AM

学びがある

delegateパターンのほうが嬉しいのはそもそもObjCにクロージャがなかった頃に使いやすいやりかただったからということを踏まえると

0.1にしておけばよかった

1

delegateパターンを提供するんであれば最初から @objc にしてしまってもよい

まあしばらくはdelegate追加とextensionのdefault動作でごまかして2に早めに移行かなあ... (edited)

delegateパターンは個別handler全部入りを渡すわけで、そもoptionalじゃないとキツいし、分けて実装したいみたいなときに不便で個人的には好きではなかったり

7:09 AM

あとデフォルト実装のは、それがoptionalであることを明示できないので、あんまり良くないかなと思いました (edited)

blockがclangに追加されたときにAppleのAPIがやたらめったらhandlerを使うようになったんだけど

7:15 AM

次第に嫌われてdelegateに戻っていた過去があるんですよねえ...

7:16 AM

Swiftはまた別だけど。

純swiftのライブラリとして出すならhandler、objcからも使えるならdelegateでも良くて、そうした場合は@objcつけるのがベストな気はする (edited)

多分、retain cycleへの備えが爆発的に増えて厳しかったんじゃないかなあと思う

block出たときはもうweakあったから、ちゃんとしてないだけでは…と思ったけどそれはそれで

ちゃんとするのが難しいのは変わらないからなあ...

swiftはweak指定がobjcよりは遙かに楽なので

そんな変わるっけ？

@weakifyマクロとかありましたねObjC しんどかった印象 (edited)

objcも __weak とかじゃなかたっけ

swiftはキャプチャ構文とguard letがあって遙かに楽

あーキャプチャブロックがないし型推論がないからローカル変数で型名書き直さないといけないのか。

__weak typeof (self) weakSelf = self; void (^const block)(void) = ^{ typeof (self) const strongSelf = weakSlef; if (!strongSelf) { return }; };

7:21 AM

これですよね

それそれ

10000回は補完してる

typeofなるほど

{ [weak self] in guard let self = self else { return } }

7:22 AM

簡単

7:23 AM

でもまあ本質的には変わらなくて、

7:23 AM

やっぱり retain cycle への備えみたいなのが厳しい印象ある

https://forums.swift.org/t/accepted-se-0295-codable-synthesis-for-enums-with-associated-values/46851

[Accepted] SE-0295: Codable Synthesis for enums with Associated Values

The review of SE-0295 - Codable Synthesis for enums with Associated Values has concluded and the proposal is accepted. You can find the 1st and 2nd rounds of reviews here and here respectively. There was general consensus that the solution would help a number of users, even if the encoding was not unanimously agreed upon. The core team does n...

5:23 PM

enumのCodableサポートが通ったぞう

5:24 PM

https://forums.swift.org/t/serialization-in-swift/46641

Serialization in Swift

Hello folks, Common feedback during the review of SE–0295, and over the years since the introduction of Codable, is that Codable is not flexible or customizable enough to address all serialization needs. The core team felt it was important to share that while Codable plays a critical role in the Swift ecosystem, the core team does not see Coda...

5:24 PM

合わせて、Codableの将来について意見を募るスレッドが立っていて、いろんな意見が書き込まれてる

5:25 PM

>>47 の BackedCodable はなかなかおもしろい https://github.com/jegnux/BackedCodable

jegnux/BackedCodable

Powerful property wrapper to back codable properties. - jegnux/BackedCodable

5:26 PM

enumのCodable対応には苦労していて、コードの自動生成したりもしてたから、0295はとても助かる

https://async-await-in-swift.netlify.app/ PlaygroundをEmbedできるようにして動くドキュメント（チュートリアル？）みたいなの作れるようにしてみた。 (edited)

1

1:01 PM

なんかもっとうまく書いてくれる人が書いてくれるとめっちゃいい感じになると思うのだが。。。

おお？

8:25 PM

'runAsyncAndBlock' is deprecated

8:26 PM

.playground をHTMLに埋め込む感じ?

はい。iframeで埋め込んだときの体裁を整えました。 ^ のソースコードは https://github.com/kishikawakatsumi/async-await-in-swift/blob/main/index.html

kishikawakatsumi/async-await-in-swift

Contribute to kishikawakatsumi/async-await-in-swift development by creating an account on GitHub.

<iframe class="code-snippet-sm" src="https://swiftfiddle.com/txdtgymelzddre63gl2dv5wori/embedded/" frameborder="0"></iframe>

1:25 AM

みたいな。

https://forums.swift.org/t/accepted-se-0293-extend-property-wrappers-to-function-and-closure-parameters/47030

[Accepted] SE-0293: Extend Property Wrappers to Function and Closur...

The third review of SE-0293 has concluded. Feedback in the third round of review was quite positive, a result of the great iteration from the previous rounds of proposal. As such, the core team has accepted the proposal as written. Thank you to the proposal authors and to the community for the discussion and iteration, and for helping make Sw...

6:30 PM

パラメータ部分にwrapperつけられるやつ決着した

今年のWWDCは言語面だけでも盛り沢山になりそうですね

https://forums.swift.org/t/se-0307-allow-interchangeable-use-of-cgfloat-and-double-types 通ったね

SE-0307: Allow interchangeable use of CGFloat and Double types

The review of SE-0307, "Allow interchangeable use of CGFloat and Double types", begins now and runs through March 24, 2021. The proposal is authored by @xedin. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to ...

また一つ暗黙の型変換が増えた

7:10 PM

とはいえ、ま～これは便利だし実害もあんまり無い気がする。

こわい

7:14 PM

implicit こわい

32bit環境がほぼ実在しないので

Windows 「え？」

WindowsにCore Graphics無いから大丈夫

swift-corelibs-foundation にあるから 32bit CGFloat は実在はする。

けど今回のはランタイムは一切関わらずルールに従ってコンパイラが暗黙的に変換を埋め込むだけだから、リスクは低そう。つまり、 let a: CGFloat = 1.0 let b: Double = a + 1.0 が、 let b: Double = Double(a) + 1.0 に書き換えられるだけ。実行時暗黙変換はしないので下記は失敗する。 let a: Any = CGFloat(1.0) let b: Double = a as! Double

Double => CGFloatは大丈夫なんだろうかと思ったけど既存のコードはすべてコード上で自分で変換してるわけだから知らないうちに問題が起こることはないのね。

https://forums.swift.org/t/se-0308-if-for-postfix-member-expressions/47163 #if の機能を拡張するプロポーザルがレビューに入りました。 Text("title") #if os(iOS) .iOSSpecificModifier() #endif .commonModifier() みたいなのを出来るようにする提案です。

SE-0308: #if for postfix member expressions

The review of SE-0308, "#if for postfix member expressions, begins now and runs through April 16, 2021. The proposal is authored by @rintaro. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager...

3

これはいいですね。 #if os(iOS) func button() -> UIButton { #else func button() -> NSButton { #endif ... } こういうのは無理なのかな？

それはまだダメですね。今のところ typealias で対応する必要があると思います。

4:31 PM

#if canImport(UIKit) typealias ButtonType = UIButton #elseif canImport(AppKit) typealias ButtonType = NSButton #else #error("UIKit or AppKit is required") #endif

まあそれとは別の問題という感じある。 Proposalの提案ができるようになるだけでもだいぶ見やすく書けそう。 (edited)

1

このメソッドチェーンの一箇所だけ #if で付け外しできるの便利だけど、コンパイル時の #if 文だとできるのに普通の実行時の if 文じゃできないのが逆に不満に感じるようになりそう

6:06 PM

今までは #if は式の途中に差し込むことはできなかった（？）から、カットできるのは文の単位だから、普通の if 文とコードの形的にはほぼ同じ機能だった（？）気がするけどこれが出てくると #if の方が強くなってしまう　まあ別に便利だからそれ自体はいいんだけど

それは思う。SwiftUIだと普通のifもチェーンの途中で割り込みたいことよくある。

そうですよね。Motivation sectionで os(iOS) って条件文を書いてるけど、そうじゃなくて動的な条件でも同じことがしたいことがありそう。まあSwiftUIだと式の型まで影響を受けるから厳しそうだけど

前あったのはこういうケースでした。

if widgetFamily == WidgetFamily.systemSmall { Link(destination: Self.endpoint(APIKey: entry.configuration.APIKey, deviceID: entry.configuration.deviceID )) { Label("", systemImage: "lock.fill") .frame(minWidth: 0, maxWidth: .infinity) .font(.headline) .padding(.trailing, -8) .padding(.all, 16) .background(Color.gray.opacity(0.2)) .clipShape(Capsule()) .offset(CGSize(width: 0, height: 6)) } } else { Link(destination: Self.endpoint(APIKey: entry.configuration.APIKey, deviceID: entry.configuration.deviceID) { Label("Unlock", systemImage: "lock.open.fill") .frame(minWidth: 0, maxWidth: .infinity) .font(.headline) .padding(.all, 16) .padding(.all, 0) .background(Color.gray.opacity(0.2)) .clipShape(Capsule()) .offset(CGSize(width: 0, height: 6)) } }

6:11 PM

SwiftUIは意外とModifierチェーンの順序も影響するから途中だけ違うっていうのが難しいんすよね。順序が影響しなかったら共通部分だけ変数に入れてそこからModifierを分岐ってするのがいいと思うけど。

6:12 PM

まあこの例はもしかしたら順序関係なくいける気もする (edited)

この具体例に限れば、オペレータの並び順自体は一緒だから、パラメータの部分を個別に分岐するか、パラメータ達だけ先にletで組んでおくって書き方はできそうですね。でも言いたいことはわかります。

どれがわかりやすいかはケースバイケースになって難しいんですよね。この場合はModifireの形が一緒だからifで複数書かない方がわかりやすいと思って違う部分だけ三項演算子で書いたんですが、違う部分を変数にしとくってのも良さそう。ただチェーンにIfが割り込めたら多分それはベストっぽい。

if演算子があれば目的が達成できそうで、メソッドチェーンのためにif文そのものを拡張するのはやりすぎかなと思いました

6:27 PM

例えば Link(destination: ...) { Label(...) .if(condition) { $0.color(...).... } else: { $0.color(...).... } .font(...) } の様な。後岸川さんの例は、Linkのclosureの中でifでEitherView<...<Label>,...<Label>>に出来そうな気がする。 (edited)

こんな感じか？

struct If<Then: View, Else: View>: ViewModifier { var condition: () -> Bool var `then`: (Content) -> Then var `else`: (Content) -> Else func body(content: Content) -> some View { if (condition()) { self.then(content) } else { self.else(content) } } } extension View { func `if`<Then: View, Else: View>( _ condition: @escaping @autoclosure () -> Bool, then: @escaping (If<Then, Else>.Content) -> Then, else: @escaping (If<Then, Else>.Content) -> Else ) -> some View { modifier(If(condition: condition, then: `then`, else: `else`)) } }

(edited)

なるほど〜たしかに。

#available(iOS 14, *) とかが使え無いのが残念ではありますね。

あー、自作if文ってそういう弱みがあるのか

なるほど。これは良さそうだな。

https://swift.org/blog/swift-collections/ OrderedSetとかOrderedDictionaryとか。めっちゃいい。

Introducing Swift Collections

I’m thrilled to announce Swift Collections, a new open-source package focused on extending the set of available Swift data structures. Like the Swift Algorithms and Swift Numerics packages before it, we’re releasing Swift Collections to help incubate new functionality for the Swift Standard Library.

ODほしくて自作した事もあるぐらいだから助かる c++より少し早いの凄いな

Dequeだけでもかなり凝った実装してるなあ

Numericとかもだけど、今後は基本Foundationじゃなくて個々にOSSリポジトリが作られてく感じなのかな

そうっぽいですね。まあ、Foundationでやっていくと、Server Side Linuxとか進まないですし。

Deque 前に作ったからどんな実装してるのかと気になって見てみたけど、標準ライブラリに ManagedBuffer とかあったのか。これ使えば自前の実装からコード削減できそう。 https://developer.apple.com/documentation/swift/managedbuffer

ManagedBufferはコード量削減というより

5:03 AM

tail-allocatedなデータ構造を作るためのヘルパーですね

5:04 AM

たしかSwift.ArrayやSwift.Stringだと使ってなくて同じ事を自力でやっていて

いや、多分これに相当する機能を自作してたから、それを削減できそう。

ManagedBufferの立ち位置微妙だな〜と思ってたんですが、このライブラリだとこれをしっかり活用していてよかった

5:04 AM

なるほど。

5:05 AM

自作するとかなりunsafe APIを駆使したコードになっていそう。 (edited)

はい、 Unsafe 使ったコードになってます。

5:07 AM

あと、 append に対応する先頭への追加は prepend になるのかぁ。わからんかったから appendFirst にしてしまった。

整数が扱えるだけの _HashTable があって、 OrderedSet は _HashTable と ContiguousArray をもっていて、要素はArrayにいれといて、 _HashTable は値から配列のインデックスを逆引きできるように同期しているっぽい。

5:15 AM

OrderedDictionary は OrderedSet<Key> と ContiguousArray<Value> をもっていて、 2つのインデックスは揃えてあるっぽい。

5:17 AM

DequeもHashTableも Storage の実装に ManagedBuffer を使ってますね。ただDequeのほうはStorageをstructにしてあって Storageが ManagedBufferPointer を使って ManagedBuffer を所有していて更にややこしい

rintaro

#available(iOS 14, *) とかが使え無いのが残念ではありますね。

#available 使えない問題に関してはif modifierなんて作らずに、こんなので良い気がしてきた。

extension View { func map<Result: View>(@ViewBuilder _ transform: (Self) -> Result) -> Result { transform(self) } } Text("test") .map { if #available(iOS 14, *) { $0.ignoresSafeArea() } else { $0.self } }

(edited)

めっちゃいい

6:51 AM

というか基本的にif式ほしいときはこのアプローチでいいんですよね。if式が使えるコンテキストを開く関数が1個あれば

mapの中もViewBuilderで、型は伝搬できるのか

SwiftUIに限らずだいたいなんとでもなる

これ型あわせないといけなくて大変なんじゃって思ったけどViewBuilderついてるからConditionalContentになるのか

mapってかletだな〜

2

6:54 AM

式を名前に束縛してスコープを作ってるから。

なるほど let か、多分 map じゃないよなーと思いながらとりあえず出してみたのです。

1

let関数に相当するのって、他の言語だとどういう名前になるんだろ

9:20 AM

帯域でlet関数に相当するものを作っておくと便利なんだけど、let が予約語なので使えないんだよな

https://kotlinlang.org/docs/scope-functions.html#let

Scope functions | Kotlin

9:20 AM

kotlinはまさにletで、 Anyに対するextension methodだよ

Any

9:20 AM

に対してのextensionはできないので

定数(というかreadonlyだけど)宣言は val を使う

9:21 AM

Swiftはできないね。> extension Any

if/switch/(xcode12.5でwhile/for)を式として使えるスコープをパパっと作る関数を定義したくて

9:21 AM

なんか型推論の魔法使えて

9:22 AM

LCTを指定したらその型に、そうでない場合は近傍のEitherに収束する関数ができた

1

9:22 AM

同じ型ならその型になる。

protocol Lettable { func `let`<R>(_ f: (Self) throws -> R) rethrows -> R } extension Lettable { func `let`<R>(_ f: (Self) throws -> R) rethrows -> R { try f(self) } } struct S: Lettable { } S().let { print($0) }

それだとEitherにしたいときに不便なんだよね。なので

Lettableつけた型なら使える　ってスタイルならできる

let a = xxx { if cond { 1 } else { "" } } // Either<Int, String> let b = xxx { if cond { 1 } else { 2 } } // Int let c = xxx { if cond { Cat() } else { Dog() } } // Either<Cat, Dog> let d: Animal = xxx { if cond { Cat() } else { Dog() } } // Animal

こういうのが出来た。 (edited)

Eitherに対して .leastCommon ってプロパティがあればいいような気も？

xxxの名前は何がいいかな〜って感じ

9:25 AM

いやそれは無理なんだよね

汎用のResultBuilderを使って式スタイルを使いたいって感じの機能だから、名前をつけるなら expressive とか？

このxxxの関数の嬉しいところは、左辺で型が束縛されていればよしなに解決されるし、でなければEitherで出てくるし、全部同じ型ならそのままの型で使える

9:27 AM

まあそんな感じですかね

9:27 AM

tx

うーん、その２つは別名でいいのでは

9:27 AM

推論に頼るとユーザーの想定と違う挙動して混乱する事もありそう

gistにポン置きする30行程度のメモ書きだからよしなに書き換えたらいいと思うよ。

いやそれは無理なんだよね

これはどういう無理？不便ってこと？実装上？

実装上不可能です。EitherのL, Rを判定して計算されたLCTを出す、というのが

9:34 AM

are

9:34 AM

できるかもしれねぇ

9:34 AM

あでも、だめだ

9:34 AM

Either<Either<A, B>, C> が解けない

9:34 AM

ResultBuilderだとこれが解けるようになる

9:37 AM

親クラスって成約につかえないのか

ネストしてなくてもだめだったか。

9:40 AM

ネストしてる場合は完全に無理なんで

パラメータとして与えられた型を制約にするのって無理なんだなあくまで最初から静的にプロトコル名を与えないといけないのか (edited)

9:41 AM

あ、いや、そうか・・・

9:43 AM

enum Either<L, R> { case left(L) case right(R) } extension Either { func join<C>( type: C.Type = C.self, left: (L) -> C, right: (R) -> C ) -> C { switch self { case .left(let x): return left(x) case .right(let x): return right(x) } } } class Animal {} final class Cat: Animal {} final class Dog: Animal {} func main(_ x: Either<Cat, Dog>) -> Animal { x.join { $0 } right: { $0 } }

9:44 AM

class Animal {} final class Cat: Animal {} final class Dog: Animal {} final class Bird: Animal {} func main(_ x: Either<Cat, Dog>) -> Animal { x.join { $0 } right: { $0 } } func main2(_ x: Either<Either<Cat, Dog>, Bird>) -> Animal { x.join { $0.join { $0 } right: { $0 } } right: { $0 } }

なかなかにしぶい

9:45 AM

私の型マジック付きコードだと

main2 がネストしてる場合。意味のない { $0 } が必要になっちゃった。

9:45 AM

RxSwift使ってて意味のない .map { $0 } があると思ったら T から T? にキャストしてるやつを思い出した。

9:46 AM

この意味のない { $0 } を推論器からデフォルトの値として生成させられたらベストだけど多分ないんだろうな

let x = expressive { if cond1 { Cat() } else if cond2 { Dog() } else { Bird() } } // Either<Either<Cat, Dog>, Bird> let y: Animal = expressive { if cond1 { Cat() } else if cond2 { Dog() } else { Bird() } } // Animal

になるので、なかなかに便利だよ

buildExpressionとかがオーバーロードできるからできるのかな？

buildEitherをオーバーロードして

buildEitherか。

@_disfavoredOverload でEitherの順位を下げるとこうなる

ズル

1

9:49 AM

曖昧なケース出ちゃう気がしたけど disfavored・・・たしかに・・・ (edited)

天才っしょ

ただ式が内包してるifの数だけそのbuildEitherの選択があるから推論計算量が爆発しそうだな

午前4時頃思いついた

でもまあそうやって局所的に使うなら問題ないかも。

expressiveで閉じてるから多分大丈夫

https://gist.github.com/tarunon/c45d76d8be9d01ce0ea074b69a586d6f とりあえず。swift5.4だと @_disfavoredOverload は要らなかった。

Introducing if statement for statement into swift. Required swi...

Introducing if statement for statement into swift. Required swift 5.4. - Expressive.swift

3:22 PM

@basashi ResultBuilderを使ってクロージャ内限定ですがif式を実現してみたので、興味があればご覧ください。 (edited)

Swift CollectionsにLinkedListほしいと思ったけどDequeがそのポジションなのかな。

6:32 AM

Dequeはランダムアクセスも十分速いっぽい。

Dequeは先頭と末尾への追加挿入がO(1)なのが便利なコレクションです

6:32 AM

LinkedListは挿入と削除がどこでもO(1)の代わりにランダムアクセスができないコレクションです

先頭と末尾か。

6:32 AM

確かにそれはちょっと違うな。LinkedListは別に欲しいな。

そうですね。LinkedListは需要があると思う。手書きするのもちょっとややこしいし。

6:34 AM

https://github.com/apple/swift-collections/issues/1

Implement SortedSet, SortedDictionary · Issue #1 · apple/swift-...

OrderedSet and OrderedDictionary work great when we need to keep their elements in the order they were inserted, or if we only need to infrequently reorder/sort them. However, inserting (or removin...

そうそう。書いてもいいけど、微妙に毎回デザインに迷って困るみたいな。

@koher が書いていたSortedSetはissueになっているな。Lorenteyさん本人で。

Bagとかも構想にあるのかな。

6:35 AM

Multimapってなんだっけ？

6:35 AM

重複するキーを許すDictionaryか。

valueがn個のやつかな？

6:36 AM

ああそうか、Dictionary<Key, Array<Value>> だと駄目なのか。

6:36 AM

Key-Valueのペア自体がOrderedだから。

勝手に追加されるやつね

LinkedListは挿入と削除がどこでもO(1)の代わりにランダムアクセスができないコレクションです

挿入・削除が O(1) だけどそこまでアクセスするのが O(N) だからかなり用途が限定されませんか？事前にイテレートして同じ箇所に挿入削除を繰り返すとかでなければ。

典型的なユースケースとしてはメモリアロケーターがありますね

6:40 AM

確保したメモリ領域をコレクションで管理しておきたくて、解放されたらそれをコレクションから除去したい

あとLRUキャッシュはLinkedListよく使いますね。

たしかに。キャッシュは高速化のための仕組みだしキャッシュアウトするときにO(n)で削除してパフォーマンスロストするの気持ち悪いですね。

どちらも一般的な Sequence 準拠の Linked List を超えたノード操作が行えないときつくないですか？ Iterator にそういう役目を負わせればいいのかな・・・。

6:45 AM

Value Semantics も考えるときつそう。

iterator.remove()が一般的かな？

Swift の Value Semantic な世界観では無理じゃない？

なぜ？

iterator に対する操作がその iterator の生成元の list に影響を与えてはいけないんじゃないかな？

そんなことは特に無いきがしますよ

6:48 AM

https://github.com/apple/swift/blob/390cebe88ba01e11f9584491ea4735a51697da1c/stdlib/public/core/Sequence.swift

https://github.com/omochi/OrderedDictionary/blob/master/Sources/OrderedDictionary/LinkedListObject.swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

6:48 AM

makeIterator がそもそも consuming なので

だいたいLinkedListは要素自身から前後の要素を辿れるように作ると便利ですけどそういう話ですか？（超えているというのは）

いや、consumingは関係ないか・・・　元のコレクションを見たら削除されているという状態がほしいのだから・・・

だいたいLinkedListは要素自身から前後の要素を辿れるように作ると便利ですけどそういう話ですか？（超えているというのは）

前後を知っているのは Element ではなくそれを包むノードのはずなので、 Element を扱う Sequence の枠組みを超えたところでないと、あるノードから操作を開始して前後のノードをつなぐみたいな操作はできないのかなと。

それはそうですね。

6:54 AM

SwiftだとCollection.Indexがノードと対応する気がします。

6:54 AM

IndexはStridableとかも要求してて駄目か？

あー、 Index をノードにするのはいい案かも？

なんか以前この辺を悩みながら実装してウーンとなった記憶があるな

6:56 AM

omochi/OrderedDictionary

Contribute to omochi/OrderedDictionary development by creating an account on GitHub.

6:56 AM

思い出した

6:57 AM

Collection.Indexが Comparableを要求するんですけど

6:57 AM

LinkedList.NodeをIndexとさせようとしても

6:57 AM

あるNode2つの間の前後関係の検査に

6:57 AM

O(n)が必要になってしまうんですよ。

6:58 AM

RangeReplacableCollection.remove(at i: Index) のシグネチャには綺麗にハマるんですけどね。

まあ、 Collection に乗せずに似た仕組みを採用することはできるね。

Collection.Index.< が O(1) でなければならないという文書は見つからなかったのでギリギリセーフなんですけど、

6:59 AM

ま〜罠でしかないし・・・

7:00 AM

Collectionと似て非なるものが必要ですね。

Value Semantics も COW で実現できそうだけど、 struct LinkedList とノードの間に class Buffer みたいなのがあって、ノードから Buffer へ弱参照持ってるとかじゃないとユニーク参照か調べられなさそうな気が。

そうですね。僕の↑の実装はCoWをやってます

7:05 AM

そのへんの都合でノードからコレクションへの弱参照を持たせてます。

7:07 AM

全ノードがコレクションへのポインタを持ってるのはメモリ効率が良くないのでいけてないんですが

7:07 AM

その時は解決策が思いつかなかった。

ああ、 LinkedListObject の外側に LinkedList があるのか。とすると LinkedListObject が僕の言っている Buffer に相当しますね。

そう。

7:11 AM

LinkedListObject直接使っても良いようになっている

思ったんだけど、クラスでも mutating func が使えたら、 self 書き換えで COW で Value Semantics 実現できないかな？例の、プロトコルを使った class の mutating func という黒魔術が・・・。

えっと

7:13 AM

外側がクラスだと

7:13 AM

外側のクラス自体が共有されているので

7:14 AM

内側のストレージクラスへの参照は常に１だから

いや、外側をなくす

複製するタイミングが判定できない？

7:14 AM

あーそれはできますね

LinkedListObject を class LinkedList にして

self書き換えがprotocol越しにしかできないのと

クラスの mutating func って意味あるのかって話があったけど、これ結構おもしろいユースケースじゃないかな？

classなのにvarで使わないといけないけど。

7:16 AM

うーんでもそもそも

7:16 AM

CoWが便利なのは

7:16 AM

structでそもそも var a = b が bからaへのコピーに見えるのが遅延できるという話であって

7:16 AM

classの var a = b はそもそも共有に見えているので

7:16 AM

共有だと思ったら実体が増殖して分裂するという挙動になってしまって

7:17 AM

structのコピーのようにコピーしたかのように振る舞うclass

7:17 AM

になって何がなにやら

まあこれまでの常識からするとややこしいけど、 struct のように振る舞う class を作れるということになる。

そうですね。ただ、protocol越しの裏技が必要だから

7:18 AM

ユーザーからするとprotocol型で扱うので

7:19 AM

やっぱりそもそもstructに見えてますよ

SwiftUIよろしくstructでラップしておくのがユーザーには親切かな

@swift-5.3.3

protocol MutableCollection { associatedtype Element mutating func append(_ element: Element) } protocol _LinkedList: MutableCollection { init(_: Self) } extension _LinkedList { mutating func append(_ element: Element) { self = .init(self) } } final class LinkedList<Element>: _LinkedList { typealias Element = Element init() {} init(_: LinkedList<Element>) {} } var list: LinkedList<Int> = .init() print(ObjectIdentifier(list)) list.append(42) print(ObjectIdentifier(list))

ObjectIdentifier(0x0000000009ecd880) ObjectIdentifier(0x0000000009e4ff50)

ユーザーからするとprotocol型で扱うので

これはなくてもいけそう。

あれ？そうか、そうなるのか。

ちなみに ~~var list~~ let list にするとコンパイルエラーなので完全に値型っぽく振る舞ってる。 (edited)

「let list だとコンパイルエラー」ですかね？ (edited)

ああ、間違えた。

おもろいな、これ。

もし、これができるならクラスに mutating func を開放してもよいと考えるなら、プロトコルの黒魔術も要らないね。これまではユースケースが思いつかなかったけど、 COW で Value Semantics を持ったクラスというのはおもしろい気がする。ややこしいけど。

言語の設計的にはclassにmutating funcを開放する事自体は特に問題無さそうですね

7:30 AM

あ、でもそうなると、今度は、プロパティの変更の有無とmutatingの検査が必要になって

7:30 AM

既存のclassのコードは壊れるな。

いや、クラスではプロパティの変更は mutating によらない。

あくまでself書き換えだけをコントロールするって意味ですか？

self の書き換えができるかどうかだけが mutating による。

あーまあ、structの場合もそういう風に考えられるのか。

7:31 AM

structだからselfにpropertyが含まれているからであって

そうそう。

classはselfが書き換わるかどうかとpropertyのmutabilityは関係ないと

7:32 AM

なるほど。理屈はあってそうｗ

ややこしいけど、理論上はきれいにおさまるよねｗ

7:33 AM

Linked List の例付きで Forum で聞いてみたらどんな反応得られるかなぁ。今忙しいけど、落ち着いたら書いてみよかな・・・。

tarunon

@basashi ResultBuilderを使ってクロージャ内限定ですがif式を実現してみたので、興味があればご覧ください。 (edited)

わざわざありがとうございます。拝見させていただきます。

extension Either: Publisher where L: Publisher, R: Publisher, L.Failure == R.Failure { public typealias Output = Either<L.Output, R.Output> public typealias Failure = L.Failure public func receive<S>(subscriber: S) where S : Subscriber, L.Failure == S.Failure, Either<L.Output, R.Output> == S.Input { switch self { case .left(let left): return left .map(Output.left) .subscribe(subscriber) case .right(let right): return right .map(Output.right) .subscribe(subscriber) } } }

EitherをPublisherにして

public extension Publisher { func flatMap<T, P>(maxPublishers: Subscribers.Demand = .unlimited, @Expressive<P> transform: @escaping (Self.Output) -> P) -> Publishers.FlatMap<P, Self> where T == P.Output, P : Publisher, Self.Failure == P.Failure { self.flatMap(maxPublishers: maxPublishers, transform) } }

こうするじゃろ

myPublisher.flatMap { value in if value.isNantoka() { URLSession.shared.dataTaskPublisher(for: hitotsumenoAPI).mapError(...) } else { URLSession.shared.dataTaskPublisher(for: futatsumenoAPI).mapError(...) } }

flatMapの中でif文が使えるようになるんじゃ

12:17 PM

combineの書き味を良くするのに、ResultBuilderを使って色々ハックができる (edited)

12:18 PM

型推論をめちゃくちゃ強化するツールでもあるので、いろんなことが出来る

丁度全く同じものを先週書いてた

flatMapとreducer, scanあたりの型推論をバキバキに強化出来るね

12:19 PM

しかもこれ、下手するとコンパイラに優しいんじゃないか？だめだったりするかの

12:19 PM

（実用はしていないのでわからん）

若干の懸念点として、内部でthrowできない、guard書けないという欠点がありました

throw/guardは確かに、使えないね

レスポンスをデコードした際のエラーを独自のエラー型にラップしようとしてスッと書けなかったので一旦諦めたけど、その処理をラップするPublisherを定義すればできそうではある

12:22 PM

コンパイラに優しいかどうかはわからんですが、型推論は若干省略がより効く気がしますね

flatMapは、クロージャ側の型と外側の型との狭間で型が確定する、そのうちの内側の型はreturnの数だけ推論とチェックが走ってしまうが、ResultBuilderを挟むことで、内側の型は一意に決定するので、確実に優しくなっていると思う

12:23 PM

省略出来る箇所が増えてるなら、優しくなってそうですね

12:24 PM

うーん、とすると、Combine使うなら最初にこれ入れておきたいレベルで便利だな

普段のflatMapは -> AnyPublisher<> がほぼ必須だけど、resultBuilder経由してると今の所書かなくて済んでる

flatMapがanyPublisher無しだと誰も書けません！w から、思考停止で書ける、まで昇華される

12:26 PM

実行時にどれくらいパフォーマンス稼いでくれるのかは気になるね。

12:26 PM

anyPublisher使ったらその時点でPWTの参照入るけど

12:26 PM

ResultBuilderならPWT無しでいけるんじゃないか

PWTは何の略ですか

Protocol Witness Table

12:27 PM

この場合はsubscribeの動的ディスパッチになるか、ならないかを指してます

AnyPublisherでラップしないから軽減されてそうですね

全部Genericsで動いていてTE無しなら、動的ディスパッチなくせる気がする

試しに型覗いてみたら画面横幅いっぱいのウィンドウで4行くらいの型が出てきてよかった

12:33 PM

スクショ貼りたかったけどさすがに断念

間にEitherも挟まってるから余計に長そう

12:34 PM

ところで、私のExpressiveを使うと

12:34 PM

不要なときはEitherが消えるので(殆ど無いが)

12:34 PM

ちょっとだけ短くなるかも？

一応僕が使ってるのはこんな感じですね https://gist.github.com/sidepelican/a2045cb614c603cd2fcf6ada22cf509a

flatMapBuild.swift

GitHub Gist: instantly share code, notes, and snippets.

12:35 PM

最小限しか書いてないけどこれで動いてたからこれでやってる

レビューすると、FlatMapBuilderそのものは型パラ要らない気がする

12:36 PM

ResultBuilderの型パラは、結果から型を縛る(?)というテクい事をするときしか役に立たなくて、基本は無くてもよしなに推論してくれるようになってる (edited)

ほんとだ。なくてもビルド通りました (edited)

ResultBuilderの作り方と推論の仕組み、かなりテクいので、どこかで紹介したいですね

12:40 PM

アーーーーOptionalの記事書いてないわ、詐欺師じゃん

w

https://github.com/apple/swift/commit/c76dac715552082178a390bf9472b444af628296

We don't want @asyncHandler to be part of the concurrency model, so put it behind a different flag.

なんか@asyncHandlerが-enable-experimental-async-handler つけないと使えなくなってる。 (edited)

Banish @asyncHandler to a hidden flag. · apple/swift@c76dac7

We don't want @asyncHandler to be part of the concurrency model, so put it behind a different flag.

-enable-experimental-async-handler つけてもシンボルがない、みたいなこと言われるな。

Iceman

一応僕が使ってるのはこんな感じですね https://gist.github.com/sidepelican/a2045cb614c603cd2fcf6ada22cf509a

flatMapのオーバーロードがいくつか足りなかったので足した

@tarunon flatMapにresultBuilder使うやつ、型推論が劣化するケースを見つけて残念に思ってるのですがなにか解決方法思いつきますか？

外からFailureを指定できないんだっけか

 func `catch`( _ handler: @escaping (Self.Failure) -> Empty<Output, Never> ) -> Publishers.Catch<Self, Empty<Output, Never>> { Publishers.Catch<Self, Empty<Output, Never>>(upstream: self, handler: handler) }

一応こういうの定義すると解決はできるんですが、できればresultBuilder側でいい感じになれたらなぁと

4:07 PM

resultBuilder側に無理やりFailure型を指定させても解決できないんですよね

ワイちゃんの奴でやってみよ

4:07 PM

pcない！

4:08 PM

私の書いた奴はちょっと型推論のパワー上げてるので

4:08 PM

ワンチャンいけるんじゃないかと思う (edited)

おお。今日はもう眠いので寝ちゃいますが吉報を待っています

とおってなかったわw (edited)

4:16 PM

私の奴、ちょっと悪いことしてオーバーロードしてるから純正flatMapが通っただけでした

解ったのは、ResultBuilderなクロージャの中ではさらにネストしたクロージャへの型推論が弱いかもしれないってことですね

ネスト関係なくダメっぽいんですよね。外の型に内側の型をあわせる働きがなさそう

それは私のは通った

まじか〜〜

あー、ちょっと違うかも知らん

3:30 AM

昨日似たことやって通ってたので、後でやってみる

https://forums.swift.org/t/se-0309-unlock-existential-types-for-all-protocols/47515

SE-0309: Unlock existential types for all protocols

Hi everyone. The review of SE-0309, "Unlock existentials for all protocols", begins now and runs through May 1, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the revie...

existentialは何でも作れるようにするやつ

11:24 PM

審査始まった

11:24 PM

ラトナーが3で賛成しててついでにany P構文への移行計画を話してる

any P アツい

おお、 any 期待。

ディスカッションも大勢はany P welcomeな論調っぽい。Errorのようなself conformingへの言及もありますね

@swift-5.3.3

func take(_ c: () -> Optional<Int>) {} take { Optional(nil).map { v in return v } } take { Optional(nil).map { v in _ = 0 return v } }

exit status: 1 with stderr:<stdin>:10:25: error: unable to infer type of a closure parameter 'v' in the current context Optional(nil).map { v in ^

これ何でだめなんですっけ

Optional(nil) の型を決めるためにはクロージャの中身が v をそのまま転送しているだけであるって事を考慮しないといけないけど

3:14 AM

2文以上のクロージャの中身は

3:14 AM

クロージャ自体の推論が終わった後に中の推論をするから。

なるほど。前者が特殊で、1文だけだったら中身まで見てよりリッチに推論しているということでしょうか？

そう。1文のクロージャのときは、クロージャの外側と中身から作れる制約式を全部一気に推論機に突っ込む。

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

1

ResultBuilderを挟むと推論が通る気がする

tarunon

ResultBuilderを挟むと推論が通る気がする

yes。ResultBuilderはその制限を外す。

変数宣言が使えるようになったお陰で、こういうシチュエーションもハマるようになったね、

たしかに。

3:37 AM

2文クロージャの推論の分割は、コードをわかりやすくするためと、推論時間の増加を防ぐための2つの理由が書かれているんだけど

3:38 AM

ResultBuilderは推論時間の増加を防いでそういう推論が上手いことできる仕組みを導入したので、もう2文クロージャの制限を外してもいいんじゃない？って意見に対してドーグがそれもそうかもみたいな事を言ってたのを見た。

ResultBuilderの中で kawa.map { ~~~ } してるときに推論が正しくできなくてこれに遭遇したんですよね

ResultBuilder書いてる時頭がリミッター解除モードになってるからつまづいたのかｗ (edited)

変数宣言できるようになったけどその場合にreturnする値はどう決めるのがいいんでしょうかね？最後の式をreturnなしで返すのが一番違和感ないのだろうか

ResultBuilderに関しては式が3つあるなら3つとも渡るでしょ？

let宣言は返り値として採用されず

View { Text() Text() Text() } みたいな。

最後の一文が返り値として採用される

あれ、そうなん

まあ解りやすくするためにreturn書いてもok

あ、そうなんですけど、その3つの式を合体させたくないケースにおいてどうするのが正解なのかなと

3:41 AM

returnかけなくないですか？

returnは書けないんじゃないっけ。

return 書いた時点で result builder 扱いじゃなくなります。

あ、書けないのか

rintaro

return 書いた時点で result builder 扱いじゃなくなります。

「扱いじゃなくなる」という挙動があるのか〜！

書けるけど、その場合は普通のクロージャとして扱われる。

Iceman

returnかけなくないですか？

_ = Text() こうすれば消せるんじゃない？

兎に角、式を返り値として採用したくないなら、let foo = myMethod() みたいにして

それはVoidがかえるんですよ

消してしまえばokと思う

じゃあ let _ = Text() 　・・・

letにVoidを吸わせれば帰らない

letに吸わせると返らないの知らなかった・・・

3:44 AM

ありがとうございます

ちなみに複数文クロージャの型推論実装 https://github.com/apple/swift/pull/32223

ウオオ

rintaro

ちなみに複数文クロージャの型推論実装 https://github.com/apple/swift/pull/32223

main　ブランチ対応で自動closeされてるｗｗｗ

1年前じゃん

そうそう、このPRを見た記憶があったんですよ。一応完成してたんですね。

あ、自動closeされてそれっきりなんですかこれ

俺が知る限りは動きはない

3:46 AM

_ = a が Void 扱いになるのはこれとは別なのかな

_ = って書けるの知らなかったんだけど

うおーいけたー

3:48 AM

代入文は式として使えないんだと思いこんでいた

3:48 AM

代入文おまえ式だったのか

むしろ_ = を let _ = と同じだと考えてしまっていた

3:49 AM

let文は式ではなかった。

それはそうだね

Iceman

むしろ_ = を let _ = と同じだと考えてしまっていた

俺もそう考えてた。let の略記なのかと思ってた。

Iceman

むしろ_ = を let _ = と同じだと考えてしまっていた

そうじゃなかったのか・・・。

letの略は出来たらダメでしょw

3:50 AM

左辺に変数があってもオッケー。 (edited)

それなら Void になるのも自然な話だ。

これ出来るからと言ってResultBuilderで副作用のある関数をほいほい呼ぶのは

あれ？でも = は関数じゃないのか。

期待した副作用と異なる結果になる事があるのでよろしくない

同意。

@swift-5.3.3 var x: Int? = nil (x? = 12).map { _ in print("assinged")} ?? print("was nil")

was nil

ただ多くの言語だと代入文の型はVoidじゃなくて右辺の型なんだけどな〜

確かにそうね

3:53 AM

それでもって a = b = 2 みたいなの書くことがある

それを利用して a = b = 3 みたいに　かぶった

assign を void にしたのは何かしら rationale があった気がする

if の条件中で代入を許さずみたいなのじゃなかったですっけ？

それか

それならそもそも式にしなければよいのでは

= は代入文じゃなくて binary expression の一部として式だった。

あーoperatorが定義されているのか

頭にキーワードが無いと普通の binary expression と区別がつかないので、式にしないと Parser 実装が面倒くさくなるのはありますね。

3:57 AM

= オペレータの定義はないはずです。

あーそうか、代入文よりも優先度の低い演算子を作れるようにするためにはそれしか無さそう

@swift-5.3.3 var a: Void = () var b: Void = () a = b = a = b = a

no output

https://github.com/apple/swift/blob/7123d2614b5f222d03b3762cb110d27a9dd98e24/stdlib/public/core/Policy.swift

3:58 AM

たしかになかった。

Swift でも a = b = a = b = a みたいなのが書けるケースがあるとは。

*= とかはあったけど。

koher

Swift でも a = b = a = b = a みたいなのが書けるケースがあるとは。

めっちゃ虚無の式だ・・・

3:59 AM

// User-defined assignment operators are not supported. The = operator is // hardcoded as if it had the following attributes: // infix operator =: AssignmentPrecedence

3:59 AM

↑コメントアウトされてた。

omochimetaru

めっちゃ虚無の式だ・・・

取り扱ってる値が虚無（ Void ）な上に何も変更しないので虚無。

1

https://twitter.com/CodaFi_/status/1384333502712205315 なかなかタイムリーな笑

C++ Delenda Est (@CodaFi_)

Calling these “skipping stone statements” try = = = = = = { “splash” }()

ｗｗ

4:30 AM

Xcode12.5から自作resultBuilderで作ったスコープの{}　の色が変わるようになったw

おお、便利そう

8:48 AM

resultBuilder適用部分とそうでない部分が区別できる

ifと同じ色になってるのか、あーこれはifがrbの影響になるから (edited)

ifもRBに畳まれてるからじゃない？

理解

これはいいな魔術モードなのがわかるので

影響がある部分のハイライトもされる

よくできてんな

https://forums.swift.org/t/se-0312-add-indexed-and-collection-conformances-for-enumerated-and-zip/47740

SE-0312: Add indexed() and Collection conformances for enumerated()...

Hello, Swift community. The review of SE-0312: Add indexed() and Collection conformances for enumerated() and zip(::) begins now and runs through May 7th, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly t...

5:42 PM

@koher が最近、標準に欲しいと言っていたやつ、標準化する審査入りました↑

皆のコメントが雑に +1 だけで笑う

Motivationに書いてあるこれがほんとそう

For many collections this integer offset is different from the Index type, and in the case of ArraySlice in particular this offset is a common source of bugs when the slice’s startIndex isn’t 0.

0始まりじゃないindexで混乱するといえばsql

5:48 PM

しかも丁寧に0じゃないよってエラーで言ってくる

おお、素晴らしい！

https://twitter.com/stzn3/status/1388100365522927618

shiz(しず)福岡県民初級 (@stzn3)

async let 改め spawn let https://t.co/5H9eCsgzzr

https://twitter.com/omochimetaru/status/1388100794960867328

@stzn3 そのほうがわかりやすくていいね

spawn だと await するのとの関係がわかりづらくないかな？

12:01 PM

どういう議論があったのかは追えてないけど。

async let だと並行処理になるって事がわからないんで

12:01 PM

知らなきゃそこが並行であることは全く予想できないと思うんですけど

12:01 PM

spawn letだったら初見でも想像できそう

そうかなぁ。 await する箇所で suspend するってだけで十分なわかる気がするけど。

型名のPに二つの意味があってわかりにくいからany Pになったように

suspension point は await なんだから、 async let で suspend せず並行に実行されるのは推測可能だと思う。し、 spawn だから初見でも推測できるというのは微妙かと。 (edited)

別の意味のasyncが2つあるのは混乱しそう

この場合は await と結びついてるから自然じゃない？

12:04 PM

むしろ、 async がないのに await しなきゃいけないのが混乱しそう。 (edited)

12:06 PM

↓とかでもよかったのかもしれないなぁ。 let a: async Int = foo()

この記法だと解りやすいけど型を明示する必要があってしんどいですね型を_で略記できる仕様があればこれになったかもしれない

たしかに。推論させる場合は↓とかかなぁ。 let a: async = foo()

5:05 PM

() async -> Int の async が型であるように、 spawn let とかも型であるのが自然な気がする。

5:06 PM

まあ、 async Int は Promise<Int> みたいなものなんだけど。

child taskを生成するのでspawnを共通で使用する、というのが主な理由ですかね

We feel that using the word spawn in every case that involves the creation of a child-task is simple to understand and allows developers to learn and assume about both features in tandem. https://github.com/apple/swift-evolution/blob/5a9aaec2f95a14dd8ad6db64e6278e2a83a9b8d4/proposals/mmmm-spawn-let.md#alternative-name-async-let (edited)

[Concurrency] Async Let by ktoso · Pull Request #1338 · apple/swift...

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

1

そもそも throws -> Int や async -> Int じゃなく -> throws Int や -> async Int として型扱いにするのが良かったんじゃないかなぁ。そうすれば let a: async Int はすごく自然だったし、 await しないまま持ち運ぶのも自然だった。

6:26 AM

async property とかとも整合しないかな・・・。

koher

suspension point は await なんだから、 async let で suspend せず並行に実行されるのは推測可能だと思う。し、 spawn だから初見でも推測できるというのは微妙かと。 (edited)

awaitがsuspension pointを示すのは、非同期である事は示しているけど、並行である事は示さないです。 async/awaitはあくまで直列な処理の構文なので。

6:29 AM

spawnという言葉から推測できるというのは、Structured Concurrency API の方で spawn メソッドがあるから、という話とセットですね。

6:29 AM

実際spawnメソッドをメソッド呼び出しじゃなくて言語構文として書ける機能だし。

async let a = foo() async let b = bar() let c = await a + b としたときに、 foo と bar の中の suspension point に至るまでもなく並行に実行されるからか。

6:31 AM

たしかに async とは概念が違う気がする。

6:32 AM

うーんでも async Int を Promise<Int> 的な扱いにして整理するのはありだったと思うけどな。

6:32 AM

一般的なモナドと違って合成がしやすいものとして。

型扱いにした場合、

6:35 AM

let a: async Int = foo() みたいに書く事になるけど、

6:35 AM

foo() の返り値の型 Int が async Int 型に暗黙昇格するのはまあいいとしても、

6:36 AM

それが、foo() から値が返った型変換のタイミングではなくて、 fooの呼び出しそのものを並行に投げる事になるのは、

6:36 AM

他の言語機能と比較すると唐突な挙動に感じます

6:37 AM

async let だと、 let の初期化代入文そのものにかかってるmodifierになるので、

6:38 AM

右辺値の処理に特別な変更があるのはまあ構文構造的には妥当に見える。

6:38 AM

let a = spawn foo() 構造的な観点で、「並行に投げる」作用を記述する点で言えば↑これでも良さそうな気がするけど・・・ (edited)

6:39 AM

右辺値の処理を並行に投げるだけじゃなくて、左辺値の「変数aをこのスコープの中でawaitせねばならない」っていう (edited)

6:39 AM

特別な静的な制約も導入しているという意味では

6:40 AM

let文自体の属性になっているのがやっぱり一番妥当に思います (edited)

よく考えてみたら、これできないのは当たり前と言えば当たり前ですが…どうしてもこれやりたい時、TypeErasure以外で何か方法はありますか？

protocol TestObject: AnyObject { associatedtype Some func doSomething<Item>(with item: Item) -> Some } final class Test: TestObject { func doSomething<Item: View>(with item: Item) -> Optional<Item> { return item } }

ちなみに何をやりたいかというと、SwiftUIのViewを渡して、それを内包するコンテナViewを返して欲しいわけです

Higher Kinded Typeが必要(エスパー)

つまり現段階のSwiftではやはり無理ですね…

associatedtypeを指定せずに protocol TestObject: AnyObject { func doSomething<Item>(with item: Item) -> Optional<Item> } はダメなんですかね

7:22 AM

associatedtype無しなら可能

まあ可能ですね、ただしジェネリクスが多用しすぎて相当カオスな型になっちゃっていますw

どちらかというとprotocolを使った問題解決よりは、関数とoverload, ORTあたりを使った解決を目指すと

7:24 AM

解に近づく予感がします

とりあえず <Item> のジェネリクスを外して対応します

omochimetaru

それが、foo() から値が返った型変換のタイミングではなくて、 fooの呼び出しそのものを並行に投げる事になるのは、

これ GW で返事し忘れてた。どうして Promise<Int> ならよくて async Int 型だと不自然に感じるのか考えたんだけど、 Promise だとイニシャライザに明示的にクロージャ式で生成してる感があるからなのかな。クロージャ式に渡した部分が並行に実行されても違和感はない。でも、 withUnsafeContinuation とかだとクロージャ式で渡すのは同じだし、 JS でもたとえば const a = asyncFoo(); const b = asyncBar(); const sum = await a + await b; の asyncFoo/Bar の戻り値が Promise のコンストラクタで生成されたとは限らない（ await の結果かもしれない）し、慣れの問題な気がする。 async Int が扱いやすいかは別として、 async Int と Promise<Int> に本質的な違いはないんじゃないかな。

モナドかどうかぐらいの差だと思います

3:40 AM

それでいうと、spawn letは事実上のPromise<Int>だがモナド表記を避けているだけと言える

3:40 AM

逆にPromise(Future)モナドが最初からあれば、spawn letはそっちに丸め込まれたかな〜とかは思いますね

@koher @tarunon いやいや、型は型でしかないけど、 spawn letにはスコープに束縛された実行を終了待機するという実行制御も含まれているので、型の機能を超えているので型としてみなすのはおかしいと思います。 (edited)

あーーawaitしないとコンパイルエラーになるのか

関係性としては、Promise型を含んでいるけど、さらに広範囲な機能です。

その機能は把握できてなかった。偉いね。

1

なのでlet文に対するアノテーションなのが妥当だというのが僕が↑でかいた意見です。

機能的にはPromiseにコンパイルチェックが乗算された格好なのか。いいね

letにはこれまでにもif-elseの両方で初期化されないといけないとか、そういう制御フロー的な機能がある。 (edited)

一周回って async let に戻るっぽい... https://github.com/apple/swift-evolution/pull/1338#issuecomment-834167135

Originally part of the Structured Concurrency proposal, ripped out into it's own proposal by @jckarter many months ago :-) This is now updated to reflect present day structured concurrency...

2

え〜ｗ　spawnメソッドと揃えたいんじゃないんか・・・

まあ、 async は asynchronous とは限らないけど他言語とのわかりやすさを考えて async にするみたいな話もあった気がするから、挙動として適切なネーミングよりも async 系のものは async で統一するのはわかりやすい気もする。

そもそもspawn letってpitch出たんだっけ。

3:50 AM

まだ文書はspawn letで、

It'll be async let after all, need to update the proposal again.

再変更に関してはこんらっどさんが書き込んだだけなのか・・・

omochimetaru

@koher @tarunon いやいや、型は型でしかないけど、 spawn letにはスコープに束縛された実行を終了待機するという実行制御も含まれているので、型の機能を超えているので型としてみなすのはおかしいと思います。 (edited)

async 型は async 型のまま外に持ち出せないというルールを加えれば同じにならないかな？ inout 型のように。つまり、必ず await しなければならなくなる。

それはもうそうなってるんじゃ (edited)

外に持ち出せないこととawaitしなけらばならないことは別じゃないですか？

↑書きながら思ったんだけど、 async -> Void の場合って async let はどうなるんだっけ？↓みたいにしたら暗黙的に末尾で await されるんだっけ？ func f() async { async let _ = foo() async let _ = bar() }

inoutのように引数でしか使えない型(型modifier)のような感じで変数宣言だけでしか使えない型としてそういう制約を入れるという形なら辻褄は取れるかも？

tarunon

それはもうそうなってるんじゃ (edited)

async Int があった場合の話です。↓みたいなのを許さない。 func f() -> async Int { let a: async Int = foo() return a // コンパイルエラー }

async Int が関数返り値に書けてしまうと話が変わると思います。

仮にそうあったとしたら、それはコンパイルエラーでいいと思います。

omochimetaru

inoutのように引数でしか使えない型(型modifier)のような感じで変数宣言だけでしか使えない型としてそういう制約を入れるという形なら辻褄は取れるかも？

そうだね。戻り値には書けない方が良さそう。

関数返り値にasyncは書けないで統一でいいんじゃないだろうか。

任意の非同期関数 (async -> Int) に対して、スコープ束縛並行実行を完結に書けるという話なので。

async -> Int で let a: async Int なら良さそうな気がする。

そうですね。

本質的には同一なので、同じことを2通りで書けるよりは、1つに統一してしまっていいと思う

そうすると async 引数はあってもよい？ inout みたいな。

SEプロセス的にはStructured Concurrencyのレビュー期間がとっくに終わってるのに完了処理がされてない状態で、 spawn letの文法に関してはまだpitchも出てないのかな？

async引数はなんか嫌な予感がするんだよな

3:59 AM

throwsと同じで、関数を引数に取るなら良さそう

func foo(x: async Int) { ... } let a: async Int = foo() foo(x: a)

だめだと思います

呼び出し時に何か & の代わりがほしいけど

それ実質的にオーナーシップなんですよね

4:00 AM

ようするに、スコープを出るまでにawaitしないといけないかわりに

fooがawaitしないとおかしなことになる

async引数にわたすことでも consume できるってことですよね

tarunon

fooがawaitしないとおかしなことになる

それも強制されるとすればいけそうだね。

tarunon

fooがawaitしないとおかしなことになる

foo が await しないとコンパイルエラーじゃないでしょうか？

func foo(x: async () -> Int) { ... } こうするべきだと思うよ

それは意味が違うんよね

async X 型の宣言者は await する責任を負い、

そう、その違う意味のみ許可する方法が良いと思う

それだとxの呼び出し時点で非同期な取得を開始する事になる

async X 引数を持つ関数に渡すことでその責任を譲渡する。

そうです。そこの段階で切り分けてしまったほうが、結果として全体の仕様がシンプルになると思う

x: Promise<Int> で await x.get() でいい感はある

4:03 AM

非同期はたくさん使いたいけど、並行実行はそんなあちこちに出現しないと思うんですよね。

throws () -> T が事実上の Result<T, Error> であるのと同様に

4:03 AM

async () -> T も事実上の Promise<T> だからね

4:04 AM

それで渡すのが丸い

omochimetaru

x: Promise<Int> で await x.get() でいい感はある

これ言ったら async let もそもそも Promise で良いとならない？

スコープ一個までならやることあるんですよね。

4:05 AM

それを引き渡して更にデータフローをつなげたことはない。

async let a = foo() async let b = bar() return await a + b も let a = Promise { await foo() } let b = Promise { await bar() } return await a.get() + b.get() で済ませられる。やや面倒なだけで。

そうした場合は、a,bのawaitをすっぽかしたときにコンパイルエラーにできないんですよね (edited)

いえ、下に関しては b について触らなくてもいい点が違います

TSだと結構発生してデバッグも辛いのでしんどい

上はaとbがスコープに縛られている。

4:08 AM

 await withTaskGroup(of: CookingStep.self) { group in group.spawn { try await .vegetables(chopVegetables()) } group.spawn { await .meat(marinateMeat()) } group.spawn { await .oven(preheatOven(temperature: 350)) } for await finishedStep in group { switch finishedStep { case .veggies(let v): veggies = v case .meat(let m): meat = m case .oven(let o): oven = o } } }

4:08 AM

↑これの、withTaskGroup のように、async letを含む関数全体が振る舞う。

つまり、 await 強制の機能はほしいから async let はほしいけど、それを引き渡してまで階層的に処理したいことはないから async 引数はなくてもいいんじゃないか？ってこと？で、稀にそれが起こったら x: Promise<Int> で渡すので良いと。 (edited)

そうですね。 ↑withTaskGroupを使いたいことはあると思うので、それのsugarがあるのは助かるって感じ。

4:11 AM

withTaskGroupだと結果をreduceするところが [T] になっちゃうけど、 async letだと (A, B, C) になっててもっと便利だな。 (edited)

引き渡したいケースが思いつかないのは同意だけど、もしやりたいケースが見つかったときに Promise 導入は微妙なので、 async 引数的なものを導入したくなることを見越すと、 inout との整合性で async let a: Int よりも let a: async Int の方が良い気がする。

4:13 AM

async 引数は現段階で導入しないにしても。

inoutは別に書き込まなくても処理は破綻しないけど、asyncで渡すとawaitしなければ破綻するんですよね。そういう意味でいうと性質はthrowsのほうが近いので

4:19 AM

throwsと同じ扱いで基本的に良いと思うんですよ

引き渡しに関して言えば、 Result<T> の代わりに使える throws Int 型があっても良いという話になりますね。 (edited)

4:21 AM

Promise<T> を導入しなくて良いように、 async Int 型を導入するというアイデアなので。

いやーーー

Optional<T> に対して Int? があるのと同じで

4:21 AM

型syntaxレベルの話かな。

throwsもasyncも、スコープの中で処理を確実に完了させるための意味合いも現状あるわけで

4:21 AM

それを棄却してまで実装するのはどうかと思うんだよな

4:22 AM

optional/inoutとはわけが違う

throws Int も必ずスコープの中で try しなければならないということになるんじゃないでしょうか。

そもそも引数として渡した時点でerror処理がセットになるので、do try catchで書けなくてthrows関数にする or 他のthrows Int引数に渡すという結構アクロバティックなルールになるはず

4:56 AM

そういう整合性を合わせるために無理くりなルールを導入するくらいなら、現状の関数でのみ渡せて評価とハンドリングがセットになる、という仕様のほうがよいです。

4:56 AM

これと同じことが、async T引数でも発生すると思います。

↓みたいなイメージ。 func f() { do { let a: throws Int = foo() let b: throws Int = bar() print(try a + b) } catch { print(error) } }

4:58 AM

この例の場合 throws Int にする意味はないけど。

ああ、同一スコープ内ではOK 一方で引数に渡せるようにするのは複雑性が爆発するのでNGです

4:58 AM

fooが失敗してもbarを実行するので、直列ではなくなりますね。

そうですね。

必ずtryしなければならないは今も実現できているけど、 tryする代わりに引数に渡せる　ができるようになる。

4:59 AM

なんか可読性が低くなりそうだな。 inoutの& みたいにマーキングが必要そうですね。

仮にそれを認めて整合性のあうルールが出来たとしても、それはそれで型検査が連鎖的にしんどくなると思う

omochimetaru

なんか可読性が低くなりそうだな。 inoutの& みたいにマーキングが必要そうですね。

& 的なのはほしい。

5:00 AM

全部 & にするんじゃなければ記号が足りなくなるなぁ。

記号が増えるのも嫌ですね。

foo(throws a) とか foo(async b) とか書けばいいのかな。

5:02 AM

滅多にないパターンだから、これくらいのタイプ数は許容できそう。

5:02 AM

throws X, async X 型、結構ありだと思うけどなぁ。引数は別として。

5:03 AM

async let だと try 必要なのかわかりづらいし。

引数と変数に許可した瞬間に複雑性が爆発するんだよな。ローカルスコープはいいんじゃないかと思うけど。

戻り値の型には許可しないんでローカルスコープは守られますね。

ところで、@autoclosure を使えば利用側にtry/awaitを明示する形でやりたいことが出来るんで、実際のシーンではそれでもいいかなぁという気はしますね。

10:42 AM

スコープを跨いで処理を持ち越すのはそもそもNGとして、そうではなく表記上やりたいことができればOKとする

↓って extension Array: IntCollection {} 前提での話？？

protocol IntCollection: RangeReplaceableCollection where Self.Element == Int {} let array: IntCollection = [3, 1, 4, 1, 5] array.append(9) // OK, 'Self.Element' is known to be 'Int'.

https://github.com/apple/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md#proposed-solution

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

そうです

11:18 PM

たしか今までは

11:18 PM

親プロトコルがassociatedtypeを持ってるプロトコルは

11:19 PM

existentialにできなかった

いきなり Array が IntCollection に適合してないのに IntCollection に代入できててびっくりした。

ああ。文章の上の段の話と繋がってるという理解

We suggest allowing any protocol to be used as a type and exercise the restriction on individual member accesses uniformly across extension members and requirements. Additionally, the adjusted access criteria for protocol members shall account for associated types with known implementations:

11:25 PM

うーん、それにしても extension Array: IntCollection {} が 2 行目にあった方がいいんじゃないかな？

PR出して良さそう

‼️ https://forums.swift.org/t/improving-the-ui-of-generics/22814/162

Yes, I'm working on an implementation of general opaque result types, i.e. func foo() -> <T> T where T.U == Int.

https://github.com/willtunnels

Yes, I'm working on an implementation of general opaque result types, i.e. func foo() -> T where T.U == Int.

2

1

https://github.com/search?q=bdriscoll&type=users うーんGitHubには居ない？コントリビューターかどうか調べようとしたんだけど。 (edited)

2:20 AM

他に投稿もないな、何者なんだろう・・・

willtunnels - Overview

Computer science and math student at UC Berkeley. willtunnels has 12 repositories available. Follow their code on GitHub.

2:20 AM

この人かな

あ、このランダムアイコンって連携してるんだ

2:21 AM

@apple だ

2:21 AM

https://github.com/apple/swift/pull/37596

[Parse] Parse generic argument list after '->' by willtunnels · Pul...

In order to support generalized opaque return types like func foo() -> <T> T where T.U == Int, we need this syntax extension. See https://forums.swift.org/t/improving-the-ui-of...

2:22 AM

ほんとだ。パーサーから着手してる。

General Opaque Type というか Reverse Generics ？

i.e. func foo() -> <T> T where T.U == Int

と本人が投稿しているのでそうだと思います。

3:10 AM

Opaque Result Type の一般化構文だからgeneral opaque typeと個人的に呼んだんじゃないだろうか。

これが来るとすごくうれしいですね。

3:25 AM

some Sequence<.Element == Int> とかが先に来るかとも思ったけど、これは Generalized Existential との構文の兼ね合いがあるから後回しなのかな？

パラメータ付きのopaque type(some keyword)を作るのと、reverse genericsを作るのって、ABI的には同じタスクじゃないだろうか？

3:37 AM

てか、opaque typeも、ABI境界をまたいだ状況だと具体型が消去されて抽象化されるので、generalized existentialのベースになる？

↑これ思いました

generalized existentialは、それに加えてユーザ側での型の扱いがあるので、その次の段階になりそう。

existentialはスコープ外の変数格納まで含めた話なので (edited)

ABI的には大きな変更はなくて上のレイヤーだけで解決できるのかな

そのスコープだけで取り扱われる分、関数返り値のortの方が狭い範囲の議論になると思う

3:40 AM

あとはそも本質的にはgenericsだから複数の関数があるときに同一の型にならない

3:41 AM

existentialとはここが違う

Yuta Saito

ABI的には大きな変更はなくて上のレイヤーだけで解決できるのかな

some typeとany typeの違いはコンパイル時のタイプチェックだけで実行時は同じ抽象表現に乗る気がしている。

1

あー、いや、現状のORTとReverse Genericsは同じ抽象に乗るけどany typeは別じゃないですかね

どこが違うかな。

関数の返り値として使われるとき、ORTの場合返り値の型が関数の実行前に分かったり、一度calleeから実体の型を取得したらその後変わらなかったり、any typeよりもかなり狭いので同じ抽象に乗せると最適化チャンスが減って嬉しくない

同一型である事がわかる場合の最適化はコンパイル時のspecializeと同じで抽象化を捨てる最適化だから関係なくない？

それができるのはcalleeのソースがモジュール内にある場合だけですよね

うん。

あー、関数の実行前、っていいうのはコンパイル時というわけではなくて、

3:52 AM

call 命令の前という話です

そういえば前調べた内容だと

3:58 AM

some typeが返り値で変えるときの表現は、

3:59 AM

その真の型のmetatypeを返す補助関数をまず呼び出して、その結果を使ってスタックに真の型のストレージを確保して、 callerがそのストレージへのポインタを渡して、calleeがそこに書き込むって作りだったから

4:00 AM

その時点で常に24+ byteなcontainerにラップするexistentialとは表現が違うな。

そうですそうです

4:00 AM

たとえば、

func makeSequence() some Sequence<.Element = Int> { ... } var s = makeSequence() for item in s { print(item) } s = makeSequence() for item in s { print(item) }

(edited)

4:00 AM

だと makeSequence の実体型を取得するのは理論上一回で済むですけど、

4:01 AM

func makeSequence() any Sequence<.Element = Int> { ... } var s = makeSequence() s = makeSequence()

4:02 AM

anyだとそれぞれboxから取り出さないといけない

ジェネリックパラメータ型の表現として真の型へのポインタを渡すという点では普通のジェネリクスと同じだなあ。 caller側が決めるジェネリクスだとmetatypeを引数で渡すけど、 callee側が決めるジェネリクスだと、それに対してmetatypeを返す補助関数を一つ用意するだけになっていて、ほかは同じか。

そうですね

あー，同じ関数に対するcallのたびに変わるかどうかがあるのか。 (edited)

渡すジェネリックパラーメータが常に同じ、に対応しそう

制約付きのsome typeの表現は・・・

4:08 AM

some Sequence<.Element = Int> とか、 .Element = Int は、結局普通のジェネリクスの where で修飾してるのと同じで、

4:09 AM

それ自体の受け渡し方やmetatypeをcalleeから取る補助関数の仕組みは変わらなそうだな。

4:10 AM

メタタイプからSequenceのwitness tableを取り出してそれ経由で操作するのは同じで、

4:10 AM

その時に、埋まってないassociatedtypeが絡む部分についてはメソッドが呼び出せないって制限についてはコンパイル時に事前にかけるだけか。

4:11 AM

そのへんの仕組みはこの前実装されてたexistentialの制限緩和と関連するな。

existentialの制限緩和

これなんでしたっけ？

https://github.com/apple/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md

4:12 AM

これまでは、呼び出せないエントリがwitness tableに発生する状況ではそもそもexistentialとして利用することができなかった

あー、これか

この機能が入ったことで、どんなプロトコルでもexistentialとして使えるようになったけど、もともと駄目だったようなassociated typeが絡むメソッドは使えない。

4:14 AM

で、associated typeが埋まってないメソッドは呼び出せないって話は、 some typeでパラメータが埋まってないメソッドは呼び出せないのと同じルールになると思った。

Calleeから決定される型が入力に来るようなパターンですよね

func makeSequence() -> some Sequence<.Element = Int> { ... } この .Element についての話だから、calleeだな。

4:16 AM

Sequenceに関して言うと↑だと .Iterator が決まってないので

4:16 AM

このままだと結局 for-in が使えない事になっちゃうので、

for inは使えるんじゃないですか？

.Iterator が決まってないのであれば、 makeIteratorは func makeIterator() -> some Iterator だとみなす新しい仕組みがいるのかな。

4:17 AM

あいや、metatypeがあるから使えるのか？

IteratorはIteratorProtocolに準拠していることがSequence側で制約かかってるので、Element = Intがない場合、どんなElementがくるかわからんけど取り敢えず回せる事になりそう

4:18 AM

@swift-5.4.3 func makeSequence() -> some Sequence { return Array<Int>([1, 2, 3]) } for element in makeSequence() { print(element) }

1 2 3

let collection: RangeReplaceableCollection = [1, 2, 3] // error: member 'append' cannot be used on value of protocol type 'RangeReplaceableCollection' // because it references associated type 'Element' in contravariant position; use a conformance // constraint instead. collection.append(4)

4:19 AM

そうか、問題が起きるのはcontravariant positionのときか？

入力に来るパターン

makeIterator() -> Iterator は covariant positionだからoK

4:19 AM

Calleeから決定される型が入力に来るようなパターンですよね

入力ってvariance的な話か。そうですね。

varianceってワードがぱっと出てこなかったw

型推論機に対する条件入力とかそっちの意味かと思った。

4:21 AM

varianceというワードが出てこなくても概念が出てきているので本質的な理解度が高そう。

「引数にassoctypeを取るクロージャ」を引数に取るようなメソッドは呼び出せるんですよね多分

contraのcontraはcovなのでそうですね。 (edited)

4:28 AM

あれ？ほんとか？

4:28 AM

Swiftの関数型はジェネリックパラメータを取れないから駄目？

Yuta Saito

「引数にassoctypeを取るクロージャ」を引数に取るようなメソッドは呼び出せるんですよね多分

これはmapとかforEachを想定してました

func RangereplaceableCollection.forEach(_ f: (Element) -> Void)

4:30 AM

あーいけるか。

4:31 AM

ユーザが書けないだけでクロージャが内部表現的にジェネリックパラメータを取る事はあるので

いけそう

Elementだとなにもないけどプロトコルついてても同じだな。

4:33 AM

where付きの高階関数にクロージャを渡す時にユーザはそのクロージャが受け取った T: P に対してPのメソッドを呼んだりできるので。 (edited)

これ初めてSwift触る人に説明できる自信ない…

どれ？

ORTで取り出したインスタンスに対してジェネリックパラメータが絡んだメソッド呼び出しが可能なパターン

MutableCollectionを例に出せば直感的には理解できると思う。

func coll() -> some MutableCollection { ... } var a = coll() a[a.startIndex] = 1 // だめ。aのElementがIntかどうかはわからない a.forEach { (x) in // OK。x: Elementがなんでもいいので print(x) }

4:40 AM

↑ところでここの x に対して型を書く記法が無いっすね。

4:40 AM

func coll() -> some MutableCollection { ... } var a = coll() a[a.startIndex] = 1 // だめ。aのElementがIntかどうかはわからない a.forEach { (x: #type(of: a).Element) in // OK。x: Elementがなんでもいいので print(x) }

↑無理やり考えるならこうか (edited)

4:41 AM

#_returnType(of: coll) って実在してたっけ。

そう、型をexplicitlyに書く記法が無いのが混乱させそう。Xcodeはこうだし…

そもそも some Sequence は今は無理でしょ？

いけますよ

あれ？そうだっけ

4:42 AM

あそうか

制約書けないだけで (edited)

パラメータを与えられないのであって、なにもないのはいいのか

omochimetaru

#_returnType(of: coll) って実在してたっけ。

SILレベルだとありそう

4:43 AM

これだ @_opaqueReturnTypeOf("$s24OpaqueReturnTypeExporter07exportsaB0QryF", 0) opaque

4:44 AM

それそれ。

4:44 AM

今書く方法ないのウケるな。

4:45 AM

_opaqueReturnTypeOf の第二引数の 0 って、reverse generics になってcalleeが決める型パラメータが複数になったときに

4:45 AM

1, 2, 3... と index になるように用意されてる？

ざっとテストケース眺めた感じだと今の所全部第２引数は0っぽい

俺も0しか見たことないんよね

4:47 AM

func foo() -> some Sequence は func foo() -> <S> S where S: Sequence> だから、今は -> <ここ> は1要素のことしかない？

こういうののためとか？ func makeSequence() -> (some Sequence, some Sequence) { return (Array<Int>([1, 2, 3]), 0..<10) }

そうそう。

これは現状書けない

まあ、そのケースは、一個の <T = タプル> にできる。

4:50 AM

それ言うと全部そうか？

4:50 AM

func foo() -> <T, U> (T, U) { ... }

4:53 AM

全部そうっぽい、じゃあそのsome, someのときは 1が出てきそう

SE-0259のpolyfillジェネレータできた。

入力 https://github.com/omochi/SE0295Polyfill/blob/main/Tests/SE0295PolyfillTests/Resources/test01/in.swift (edited)

5:20 AM

出力 https://github.com/omochi/SE0295Polyfill/blob/main/Tests/SE0295PolyfillTests/Resources/test01/out.swift (edited)

整えた https://github.com/omochi/SE0295Polyfill

omochi/SE0295Polyfill

You can generate Swift source code of enum with associated values which complies with SE-0295. - omochi/SE0295Polyfill

enable-experimental-async-handler のフラグなくなってるな。

9:09 AM

async/awaitの話。

https://github.com/apple/swift/pull/37415 asyncHandler完全になくなった。

the problem of creating a sync->async bridge

ってことだけどよくわからない。

John McCallさんが以前こんなコメント残してましたね

There are a lot of basic questions about @asyncHandler that we're not confident about right now:

The spelling doesn't seem great.
Async handlers make it really easy to accidentally break structured concurrency, since the handler task is detached. Perhaps the tasks shouldn't be fully detached and need some other form of structure.
Async handlers currently detach immediately, which is nice for certain use cases; however, the goal was originally to support the needs of synchronous UI handlers, which almost certainly want to do an initial segment of their work synchronously.
Relatedly, actor-isolated async handlers become non-actor-isolated externally, which doesn't really mesh with even allowing the preferred semantics for synchronous UI handlers. https://forums.swift.org/t/new-concurrency-api-not-available-in-latest-toolchain/47389/13

(edited)

New concurrency api not available in latest toolchain

There are a lot of basic questions about @asyncHandler that we're not confident about right now: The spelling doesn't seem great. Async handlers make it really easy to accidentally break structured concurrency, since the handler task is detached. Perhaps the tasks shouldn't be fully detached and need some other form of structure. Async handle...

なるほど

難しいな。読んだけど

Async handlers make it really easy to accidentally break structured concurrency, since the handler task is detached. Perhaps the tasks shouldn't be fully detached and need some other form of structure. Async handlers currently detach immediately, which is nice for certain use cases; however, the goal was originally to support the needs of synchronous UI handlers, which almost certainly want to do an initial segment of their work synchronously. Relatedly, actor-isolated async handlers become non-actor-isolated externally, which doesn't really mesh with even allowing the preferred semantics for synchronous UI handlers.

最初の命名以外はよくわからなかった。

2:06 PM

デタッチされるのはなんでダメなんだろう。

accidentally break structured concurrency なので

4:01 PM

structured concurrency は、並列に走らせたサブタスク達の完了を根本で非同期に待機する仕組みだけど

4:02 PM

そのタスクの中で何らかのAPIを呼んで、それがデリゲートメソッドを呼び戻して、そこがasynchandlerだと、

4:02 PM

detachしているので、大本の待機の仕組みからはぐれてしまうというケースの事じゃないでしょうか

4:03 PM

その次のinitial segment of their work synchronously の話は

4:04 PM

デリゲートメソッドが呼ばれて、非同期タスクを開始するにしても、その開始するまでの処理は同期になる、それが必要な状況があるのに、

4:04 PM

asyncHandlerだと全体がいきなりdetachedな非同期タスクになるから、冒頭の同期部分の処理が書けないって事を言っているのだと思った

4:05 PM

最後のactor isolatedな話は、detachedに専用に発火されちゃうので、asyncHandlerがどのアクターにも紐付けられないから、

4:06 PM

preferred semantics for synchronous UI handlers に適合できなくてうまくいかなそう

4:07 PM

preferred semanticsというのはおそらく、例えばUIKitの処理は全部 MainActor でやり取りするってパターンを最終的に目指したいからじゃないかなあ

最後のactor isolatedな話は、detachedに専用に発火されちゃうので、asyncHandlerがどのアクターにも紐付けられないから、 preferred semantics for synchronous UI handlers に適合できなくてうまくいかなそう preferred semanticsというのはおそらく、例えばUIKitの処理は全部 MainActor でやり取りするってパターンを最終的に目指したいからじゃないかなあ

ここは納得しました。確かにUIは全部 MainActor またはウィンドウごとのUI Actorsっていうのが理想だと思います。他はなんとなくわかるけどまだ私の理解が足りてない。

UIKitからくるデリゲートメソッドの中で同期的に処理を終えないと、

4:18 PM

一瞬ずれた位置に出てる画面が描画されちゃったりする

1

4:18 PM

UIにまつわる処理はデリゲートの中で同期的にすぐに終えて、それとは別に非同期に遅れて発火(detach)したいタスクを投げるというのがよくある状況です

4:19 PM

asyncHandlerだと冒頭から全部detachedになってるので、そういうことができない。

4:19 PM

非同期な処理を投げるだけでいいような状況もあるので、

which is nice for certain use cases;

なのでしょう。

delegateだけの特殊なルールじゃなくて、同期的関数の中から非同期関数をキックする一般的な仕組みって話の方が筋は良さそうに見えますね。

4:20 PM

それなら今出てる種々の議論も解決できる方法があるんでなかろうか。

それは今は新しくできたグローバル関数の async ってのがあるね

んじゃあそれを使ってね、で完全に良さそう

待機はしないんだけどdetachedではない、そのdetachedではないって事の意味は、アクターisolationのルールとの関係があったと思う、正確に理解してないけど

将来の話を置くと、現在のところはasyncHandlerでメソッド全体じゃなくて async {} で適宜asyncなfunctionを呼ぶのが正しい、ということで合ってる？

多分そう考えてるんだと思いますけどちゃんと追ってないのでソースは把握してないです。

1

今は async {} -> Taskのinit detach -> Task.detach に変わってますね(だいぶ議論になってますが) https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#unstructured-tasks-1 https://github.com/apple/swift/pull/37495 違いとしてはざっくりと

Taskのinit -> 呼び出し側のmeta情報やpriorityなどを引き継ぐ
Task.detach -> ↑を引き継がない

なんですかね https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#context-inheritance 僕はasyncHandlerの代わりだと思ってます。 We might need to create new tasks whose lifetime is not bound to the creating task, for example in order to fire-and-forget some operation or to initiate asynchronous work from synchronous code (edited)

[Concurrency] Alternative Task API. by DougGregor · Pull Request #3...

The Task type has oscillated somewhat from being purely a namespace, to having instances that are used (albeit rarely), back to purely being a namespace that isn't used for all that many na...

https://forums.swift.org/t/sswg-annual-update-2020/49223

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

shiz

今は async {} -> Taskのinit detach -> Task.detach に変わってますね(だいぶ議論になってますが) https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#unstructured-tasks-1 https://github.com/apple/swift/pull/37495 違いとしてはざっくりと

Taskのinit -> 呼び出し側のmeta情報やpriorityなどを引き継ぐ
Task.detach -> ↑を引き継がない

なんですかね https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#context-inheritance 僕はasyncHandlerの代わりだと思ってます。 We might need to create new tasks whose lifetime is not bound to the creating task, for example in order to fire-and-forget some operation or to initiate asynchronous work from synchronous code (edited)

ありがとうございます以下は結構大事に思います

2:13 AM

// Actor context propagation func notOnActor(_: @Sendable () async -> Void) { } actor A { func f() { notOnActor { await g() // must call g asynchronously, because it's a @Sendable closure } Task { g() // okay to call g synchronously, even though it's @Sendable } } func g() { } }

あ、そうですね！actor-isolatedかどうかは大事な違いですね！

だいたい読みました。TaskのAPIはけっこう苦労があって、いろいろ変わっているのはわかった。

名前がまたひっくり返ったのがすごいですね。

iOSとかで実際にいろいろ使ってるんだろうなあ

Konradさんはswift-nioもやってるので、そっちの実験もしてそう。

2:18 PM

SSWG Annual Update 2020

SSWG updates Since the last time we gave a major update on the SSWG, a lot has happened. First of all, we were very happy to welcome MongoDB and Amazon to the SSWG, represented by Kaitlin Mahar (MongoDB) Simon Pilkington (Amazon) Todd Varland (Amazon) Kaitlin, Simon and Todd officially joined on the 24th June last year. Further changes to...

2:18 PM

SSWGの定例会報告？が上がってて、

2:19 PM

委員は２年の期限があるらしくて入れ替わりがあって、

Gwynne Raskind (Vapor, first term) Tim Condon (Vapor, first term) Konrad Malawski (Apple, first term) Johannes Weiss (Apple, second term)

2:19 PM

Konradさんが新規参加してた。

おお。

Konradさんめちゃくちゃ仕事してる気がする。

2:21 PM

Distributed Actorの実験もしてるし

2:21 PM

今季のGSoCの学生応募受け入れの窓口対応も担当ぽかったし

スーパーエンジニアだ。

2:22 PM

そこに載ってるOpenAPIKit気になった。

OpenAPIってSwaggerのことかしら

そうみたい。

既存のコールバックapiをasync関数にラップする機能って提供されてるんでしたっけ。nodeのpromisifyみたいなの

xcodeのリリースノートに、マイグレーターの話があったよ

マイグレーターだとサードのapiを使えないじゃん

ユーザーが変換するならwithUnsafeContinuationだね

1

これ多少ラップした関数作ったら嬉しい場面多そうだ

promisifyみたいな一発変換する高階関数は無いけど、多分引数の数ごとにジェネリクスで用意したら作れそう (edited)

migratorはwithUnsafeContinuationを使うように書き換える?

niw

migratorはwithUnsafeContinuationを使うように書き換える?

あーそうか、そのはずですね。

なるほど

UISheetPresentationControllerって意外とiOS 13くらいからいたのか。。。？

プライベートだったんじゃなかったでしたっけ

そうそう。プライベートで。

4:27 AM

ランタイムヘッダーのダンプかクラッシュのスタックトレースが検索にめっちゃ出てくる

ww

そうか、ずっといたのか〜

たぶん Mail.app の Compose とかずっとそれ使ってそうw

なるほど。確かに。

@Kishikawa Katsumi @noppe @rintaro さっきspaceで話していたやつ struct A { enum B { case c(d: D) } } みたいなことをやるとdが緑色にhighlightされる

手元では再現しないっぽいです

なるほど。ちなみに @_exported がハイライトされなくなってました

1

同じの観測してた。でもdependenciesがハイライトされないからなんかおかしい気がしてた。

わーお

d_date

@Kishikawa Katsumi @noppe @rintaro さっきspaceで話していたやつ struct A { enum B { case c(d: D) } } みたいなことをやるとdが緑色にhighlightされる

うーん、コンパイルエラーがでちゃってるのを直してから出直してみます

7:17 AM

ちなみにこんな感じになる

なるほどおかしいですね。

自分もコンパイルエラー出ているからそれかもしれないw

Platform state of the unionのセッションのコードも引数ラベルが緑になってる (edited)

asyncのプロパティも結局入ったんですね。

1

shiz

今は async {} -> Taskのinit detach -> Task.detach に変わってますね(だいぶ議論になってますが) https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#unstructured-tasks-1 https://github.com/apple/swift/pull/37495 違いとしてはざっくりと

Taskのinit -> 呼び出し側のmeta情報やpriorityなどを引き継ぐ
Task.detach -> ↑を引き継がない

なんですかね https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#context-inheritance 僕はasyncHandlerの代わりだと思ってます。 We might need to create new tasks whose lifetime is not bound to the creating task, for example in order to fire-and-forget some operation or to initiate asynchronous work from synchronous code (edited)

async {} -> Taskのinit

"Meet async/await in Swift" では async として紹介されてたんですが、 WWDC のビデオの情報が古いですか？（↓の async のことですよね？） https://developer.apple.com/videos/play/wwdc2021/10132/?time=1385

Meet async/await in Swift - WWDC 2021 - Videos - Apple Developer

Swift now supports asynchronous functions — a pattern commonly known as async/await. Discover how the new syntax can make your code...

koher

async {} -> Taskのinit

"Meet async/await in Swift" では async として紹介されてたんですが、 WWDC のビデオの情報が古いですか？（↓の async のことですよね？） https://developer.apple.com/videos/play/wwdc2021/10132/?time=1385

はい、最初のbetaは(WWDCのビデオも)まだ古いままのようです。 For reference, here is the full list of concurrency-related proposals included in the first beta. Note, in some cases there can be lag between a proposal being updated in open source and it making it into the build, so some proposal amendments are not reflected in the first beta. For example, beta 1 still requires async { } to launch an unstructured async task rather than the now-proposed Task { }. https://forums.swift.org/t/swift-concurrency-feedback-wanted/49336

Swift Concurrency: Feedback Wanted!

Today Apple released the first beta of Xcode 13. This includes Swift 5.5, with support for language-native concurrency. Most of these features have already been accepted as evolution proposals, as well as a few that are still in review. Swift Concurrency is a huge feature, by far the biggest change to the language that has been through the evol...

1

shiz

はい、最初のbetaは(WWDCのビデオも)まだ古いままのようです。 For reference, here is the full list of concurrency-related proposals included in the first beta. Note, in some cases there can be lag between a proposal being updated in open source and it making it into the build, so some proposal amendments are not reflected in the first beta. For example, beta 1 still requires async { } to launch an unstructured async task rather than the now-proposed Task { }. https://forums.swift.org/t/swift-concurrency-feedback-wanted/49336

ObservableObject とか WWDC 後に派手に変更されたのはありましたが、発表時からすでに情報が古いのは新しいですね

1

WWDC直前にかわったのかな? (edited)

1

5.5に入ったのは10日前くらいですね https://github.com/apple/swift/pull/37680

[Concurrency] Alternative Task API by DougGregor · Pull Request #37...

The Task type has oscillated somewhat from being purely a namespace, to having instances that are used (albeit rarely), back to purely being a namespace that isn't used for all that many na...

スライドの修正やビデオの撮影・編集を考えると間に合わなさそうですね

10日前は厳しそうw

オフラインなら修正できたかもですが。

12:51 AM

まあでもそもそも beta に入ってないからダメか。

ですね

そしてこの変更に対してもまた色々な意見が出ている状態です。

この1年はまあ実戦投入きびしそうだし、様子見かなあ...

そうですね…あとはiOS15+の制限がやはり厳しいなぁ、と感じてます。 https://forums.swift.org/t/will-swift-concurrency-deploy-back-to-older-oss/49370

Will Swift Concurrency deploy back to older OSs?

Maybe this is not the place to ask since is Apple specific but I'm sure a lot of folks are wondering: will the async features be backwards deployable or only work on the new OSs?

1

At this time, folks should assume that concurrency does not backward deploy. That said, everyone is aware of the value of it doing so, and is something that is being explored/considered.

12:56 AM

これなー。

iOS 14 以下で使えるようにならないと当分先のお楽しみですね

サーバーサイドで使おう！

会社だとAndroidもやってる影響で片手間サーバーサイドがだいたいKotlin… (edited)

KotlinはAndroidもサーバーもasync/await使えますね。

KotlinはSpring転用できるから現実的だし良い選択肢ですね

Swiftのとは違って await を付けないからどこがasyncなのかコードからわからないのと、 try - throws も無いからどれが例外投げるのかわからんという違いはあるけど。

1

どこがasyncなのかコードからわからない

AndroidStudio使う前提みたいなのはあるので、エディタ側で表示してくれるのでまあとは思いますね

あれ、表示されたっけ？

左ににょろマークがでます

やったときは気づかなかったな。

Kotlin が Java の検査例外捨ててしまったの悲しい。

なんかこういう→が出る

1

検査例外とasync、コンパイラ側が勝手にやってエディタ側で表示するという世界線がありえるのか(重そう)

むむ、それはあったら気づいたはずだ、俺が触った時はなかったとかありえそう AS結構アプデどんどんあるし。

3:16 AM

とはいえIDEで気づけるならいいですね。

ガチIDE屋さんが作ってるのはつよい…

認識を改めた

にょろ

3:16 AM

チルダ

このkotlinのIDEによるサポートは、例外への対応もあるんですか? (edited)

3:17 AM

そもそも関数の定義側に宣言がないと使えないからだめか

omochimetaru

認識を改めた

うーん、でも表示上気付けるのと、コード書いた人が自分の意思で明示的に許可するのはやっぱワンステップ違うんだよなぁ。

tarunon

そもそも関数の定義側に宣言がないと使えないからだめか

あーそうか。asyncはあるけどthrowsはないのか。

tarunon

このkotlinのIDEによるサポートは、例外への対応もあるんですか? (edited)

これはなさそうですねそういうアノテーションあるかどうかは知らないですが

tarunon

検査例外とasync、コンパイラ側が勝手にやってエディタ側で表示するという世界線がありえるのか(重そう)

歴史的に、IDEでやっていくパラダイムが覇権だったけど、 Swiftが、最初から言語仕様にしたらよくね？って更に世代を進めた印象がある。

tarunon

そもそも関数の定義側に宣言がないと使えないからだめか

ですね。 Kotlin の suspend は async しかない状態だけど、エラーハンドリングについては Swift で言う throws も try もない状態。

omochimetaru

歴史的に、IDEでやっていくパラダイムが覇権だったけど、 Swiftが、最初から言語仕様にしたらよくね？って更に世代を進めた印象がある。

コンパイラがチェックする async/await は C# からあるのでは？

3:20 AM

コルーチンベースではないけど。

koher

コンパイラがチェックする async/await は C# からあるのでは？

C# の async はまたちょっと違うんすよね。

(こうしてみると、Discordのリプライはスレッドにまとめてほしくなっちゃうな)

返り値のシグネチャが async かつ Task<T> を返すという条件があって、 (edited)

(TwitterのリプライツリーはUIとしてよくできていた。) (edited)

await しなくても Task を受け取る式としてそのままにできる。

(サービスとしてはのこってる)

tarunon

(こうしてみると、Discordのリプライはスレッドにまとめてほしくなっちゃうな)

スレッド、もうすぐ来るらしいですよ (APIドキュメントだけあるw)

1

あーいや、 async はcalleeの内部で await ができるようになる + 返り値をTaskかvoidに強制するだけで、 caller には影響を与えていない。 (edited)

3:22 AM

Task 型に対して await オペレータが使える、という構成です

3:23 AM

TaskからTを取り出すところに必ずawaitを書くので、suspension pointはわかりますね。

うん、形は違うけど、 await をコンパイラが扱うという意味では。

3:23 AM

Swift はそれをエラーハンドリングのときに try で手を入れてて、

えっとそれだとJSもそうですね。 IDEうんぬんの話はasync/awaitに限らず、言語機能全般に対するトレンドに対して言いました。

それは Java の検査例外にもなくて、 Kotlin はその概念を手にしてなかったから suspend の call site 側の修飾子がないままになってしまったのかな。

うーん、それは微妙ですね

3:25 AM

TypeScript/JSも、例外は投げっぱなしだけど、awaitは明示的なので。 (edited)

3:25 AM

例外のマーキング性が非同期のマーキング性になるとは限らない

でもそれらの async/await は↑で語られてるように Swift や Kotlin のコルーチンベースのものとはちょっと違ってて、

3:27 AM

Kotlin の suspend はより throws に近いはずだったんだけど、

あー、なるほど。

もし Kotlin に検査例外があって、さらに try のマーキングが必要だったら

suspendableな関数としてのcoroutineが言語仕様にあるのは Swift, Kotlinで、

suspend の call site にもマークが必要と気づいた気が。

C#とTypeScriptのawaitはcorountineではなくTaskやPromiseオブジェクトに対するオペレータで、ノリが違うと。

ですね。

func request<R: Request>(of request: R) async throws -> R.Response func request<R: Request>(of request: R) async -> Result<R.Response, Error>

みたいな実装をした時に、tryの有無だけでは Ambiguous use of は解決できんのね

そこで @_disfavoredOverload (edited)

できなそうてか、後者だけあれば、 request(of: ...).get() が前者と同じだし要らないような

(できるかな)

実際には後者はエラーの型を縛りたい

Swift.Error のときしか get() ないんだっけ。

いや、そんなことないと思う

9:02 AM

asyncでエラーも起きるメソッドがthrowsするかResultをかえすかが各所で議論されてて考えてた

asyncかどうかで変わらないと思うんだよな〜

9:03 AM

今までのthrowsかResultかと同じ考え方で良いと思う。

たしかに

shiz

はい、最初のbetaは(WWDCのビデオも)まだ古いままのようです。 For reference, here is the full list of concurrency-related proposals included in the first beta. Note, in some cases there can be lag between a proposal being updated in open source and it making it into the build, so some proposal amendments are not reflected in the first beta. For example, beta 1 still requires async { } to launch an unstructured async task rather than the now-proposed Task { }. https://forums.swift.org/t/swift-concurrency-feedback-wanted/49336

この話、 Task になったら _ = Task { } が強制されるかと思ったけど、イニシャライザにも @discardableResult 付けられるんですね。考えたことなかった。 @swift-5.4.3 struct Foo { @discardableResult init(_ handler: () -> Void) { handler() } } Foo { print("hello") }

hello

@swift-5.4.3 struct Foo { //@discardableResult init(_ handler: () -> Void) { handler() } } Foo { print("hello") }

hellostderr:<stdin>:8:1: warning: result of 'Foo' initializer is unused Foo { ^ ~

インスタンスを生成するためのイニシャライザなのにインスタンスを discard するのおもしろい。

2

1

https://github.com/apple/swift/pull/37854 ありがたい

[docs] Add documentation for underscored attributes. by varungandhi...

I figured I should at least start a PR instead of being lazy. Fixes rdar://65258964.

1

Right now the supported deployment target is iOS 15, macOS Monterey, etc., or later. This is because of enhancements to Dispatch to support Swift concurrency, of which the concurrency runtime uses. We are actively exploring the possibility of backward deployment, but are mindful of not compromising the future of concurrency performance by doing so.

これはまあ期待して良さそうな気がする。

1:06 PM

async/awaitがiOS 14で使えないの？という質問に対して。

実現できるか検討中、なるほど。

Actorが作られるオーバーヘッドはコンパイラとランタイムでかなり最適化されるからすごく少ないよっていうQ&Aもよかった。

らしいですね〜 DispatchQueueで自分で書くのと違って。

Xcodeのplaygroundでasync/awaitってつかえないんですかね

13なら使えると思います

macOS 12にしないとだめ？

2:58 PM

昨日寝る直前にためしてなんか使えなかった…

あーどうなんだ？

2:59 PM

ConcurrencyはOSのランタイム使うから確かに。

iOSならイケるのかな

iOS15beta入れないと・・・

2:59 PM

iOS Simulatorが楽そう

iOSターゲットなplaygroundはSimulatorが動いてるわけじゃないんだっけ。

playgroundはsimulatorですね、お、それがいいか

#xcode だったかもしれないこの話題は

3:00 PM

…とおもってiOSなplaygroundにしたんだけど、なんか使えなかったんだよなあ…

import _Concurrency 書くと使えます？

rintaro

import _Concurrency 書くと使えます？

やってみまsu

import _Concurrency import Foundation async { let (dat, _) = try await URLSession.shared.data(from: URL(string: "https://www.google.com")!) print(String(decoding: dat, as: UTF8.self)) }

とりあえずこれは動きました。

うごいた...

4:28 PM

えーw

4:29 PM

FBした方がいい感じ

4:29 PM

なお macOS の場合

既知だとは思いますが、一応

Done FB9155068

1

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct DefaultMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } struct Matrix<A, B: MatrixImpl> where B.BaseRing == A {} extension Matrix where B == DefaultMatrixImpl<A> {} // Redundant conformance constraint 'B': 'MatrixImpl' <- huh?

最後の extension で redundant だと警告が出るんですが，警告が間違ってますよね？ (edited)

8:46 AM

想定している状況は、行列の実装を係数環（整数・有理数 etc）ごとに変えられるようにしたくて、行列の実装が特定の型の場合にインターフェースも拡張できるようにしたい、というものです。

extension Matrix where B == DefaultMatrixImpl<A> {} においてMatrixの制約からA == B.BaseRingとなるので、 B == DefaultMatrixImpl<B.BaseRing>となって循環しているのではないでしょうか

Taketo Sano

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct DefaultMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } struct Matrix<A, B: MatrixImpl> where B.BaseRing == A {} extension Matrix where B == DefaultMatrixImpl<A> {} // Redundant conformance constraint 'B': 'MatrixImpl' <- huh?

最後の extension で redundant だと警告が出るんですが，警告が間違ってますよね？ (edited)

Swift5.5のβだと特に警告は出ていません

おぉ，なるほど… 5.5 で解消されるのですね。

@swift-5.4.3 @swift-main

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct DefaultMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } struct Matrix<A, B: MatrixImpl> where B.BaseRing == A {} extension Matrix where B == DefaultMatrixImpl<A> {} // Redundant conformance constraint 'B': 'MatrixImpl' <- huh?

no output

stderr:

<stdin>:10:26: warning: redundant conformance constraint 'B': 'MatrixImpl' extension Matrix where B == DefaultMatrixImpl<A> {} // Redundant conformance constraint 'B': 'MatrixImpl' <- huh? ^ <stdin>:10:26: note: conformance constraint 'B': 'MatrixImpl' implied here extension Matrix where B == DefaultMatrixImpl<A> {} // Redundant conformance constraint 'B': 'MatrixImpl' <- huh? ^

おお、ほんとですね。 < Swift 5.5

循環してる感じは確かにするんですが，そうしないと extension が使えないんですよね… 本当は parametrized extension を使ってこう書きたい：

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct SomeRing: Ring {} struct Matrix<B: MatrixImpl> {} struct DefaultMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } extension<A: Ring> Matrix where B == DefaultMatrixImpl<A> {}

(edited)

なるほど、Aはダミーの型パラメータなんですね

はい，そうすればできるかなと思ってやってみたら警告が出てしまいまして

9:13 AM

でもこういうトリッキーなことはしない方がいいのかもしれません

ワークアラウンドですが、これだとまずい状況でしょうか

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct DefaultMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } struct Matrix<B: MatrixImpl> {} // DefaultMatrixImplのみDefaultMatrixImplProtocolに適合させる protocol DefaultMatrixImplProtocol { associatedtype BaseRing: Ring } extension DefaultMatrixImpl: DefaultMatrixImplProtocol {} extension Matrix where B: DefaultMatrixImplProtocol {}

(edited)

それだと大丈夫ですね．ただちょっとこの方法で protocol を増やすのも抵抗があるので，別の方法を考えようと思います．ありがとうございます

なるほど、失礼しました

1

元の挙動がおかしいので直すのも妙だと思いますが、これだと5.4でも警告が出ませんでした。

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct DefaultMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } struct Matrix<A, B: MatrixImpl> where B.BaseRing == A { typealias A = A typealias B = B } extension Matrix where Self.B == DefaultMatrixImpl<Self.A> {}

(edited)

@Taketo Sano Parameterized Extension が使えるようになるまで↓でごまかすのはダメですか？ extension Matrix { func foo<A: Ring>() -> Foo where B == DefaultMatrixImpl<A> { ... } } (edited)

9:27 AM

@swift-5.4.3

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct SomeRing: Ring {} struct Matrix<B: MatrixImpl> {} struct DefaultMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } struct Foo {} extension Matrix { func foo<A: Ring>() -> Foo where B == DefaultMatrixImpl<A> { Foo() } }

no output

そうですね，今回は initializer を拡張したいだけだったので，toXXX 的な instance method を生やすか，init 代わりの static method を生やすかに変えようと思います．ありがとうございます

これで行こうと思います！

protocol Ring {} protocol MatrixImpl { associatedtype BaseRing: Ring } struct SomeRing: Ring {} struct Matrix<Impl: MatrixImpl> { init(_ impl: Impl) {} } struct DenseMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } struct SparseMatrixImpl<A: Ring>: MatrixImpl { typealias BaseRing = A } extension Matrix { func toSparse<A: Ring>() -> Matrix<SparseMatrixImpl<A>> where Impl == DenseMatrixImpl<A> { .init(SparseMatrixImpl<A>()) } func toDense<A: Ring>() -> Matrix<DenseMatrixImpl<A>> where Impl == SparseMatrixImpl<A> { .init(DenseMatrixImpl<A>()) } }

1

method を private にしとくと compiler が良い感じに inline 化してくれたりするのだろうと期待しているのですが，実際に private にするのと public にして @ inlinable などをつけるのではどちらが速くなるかといったことは知見などありますか？

Taketo Sano

method を private にしとくと compiler が良い感じに inline 化してくれたりするのだろうと期待しているのですが，実際に private にするのと public にして @ inlinable などをつけるのではどちらが速くなるかといったことは知見などありますか？

インライン化は public でも同一モジュール内であれば勝手にされるはずですね。モジュールをまたぐときは @inlinable 等 https://github.com/apple/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md が必要になります。

koher

インライン化は public でも同一モジュール内であれば勝手にされるはずですね。モジュールをまたぐときは @inlinable 等 https://github.com/apple/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md が必要になります。

ふーむ，なるほど… 実感としては public + inlinable が明らかに速くなってるような気がするんですが，protocol extension を色々やってる影響ですかねぇ…

クロスモジュールの場合、 private メソッドがインライン化されてない等あり得ると思います。 (edited)

private なのに inline 化してくれないんです？

private は inline 化可能なはずです。可能かどうかとは別に、 @inlineable をつけることで、インライン化されやすくなるかどうかは知らないです。同じだと思ってますけど・・・

8:17 AM

具体的に @inlineable がやってるのは、関数の中身をライブラリヘッダーに書き出すという事です

8:18 AM

通常の状態だと関数のシグネチャのみが見えていて、中身が見えないので、インライン化できないのですが、 @inlineable をつけると、インライン化できるように、中身も露出するという仕組みです。

8:18 AM

private メソッドはそもそも同一モジュール内からしか呼び出せなくて、同一モジュール内についてはコンパイル時に中身が見えているので、付けなくても同じはずなんです。

inlineable をつけるには method を public にしなきゃいけないのが嫌な場合が多くて，private にしとけばコンパイラが賢くやってくれるのが一番なのですが，public + inlineable の方が速くなるようなケースがある感じがしてまして…

インライン化するかどうかの判断に影響を与えるのは @_inline(always), @_inline(never) などがありますね。

8:20 AM

そのメソッドがインライン化されるかどうかとは別の話として、

8:20 AM

そのメソッドを呼び出している別のメソッドとまとめてインライン化できるかどうか、というのが変わってきますね

8:21 AM

public struct S1 { @inlineable public func f2() { f3() } private func f3() { compute() } } (edited)

8:24 AM

例えばこうなってたとき、 f2を呼び出す外部モジュールにおいては、f2の中のf3はインライン展開されなかった気がします。

8:24 AM

で、f2の中のf3のインライン展開も怪しい気がします。↑の話があるので。

8:25 AM

https://docs.swift.org/swift-book/ReferenceManual/Attributes.html

8:25 AM

@usableFromInline というのがあって

8:25 AM

public struct S2 { @inlineable public func f2() { f3() } @usableFromInline private func f3() { compute() } }

8:26 AM

こうすると、 f2の中にf3はインライン展開されるし、 f2をインライン展開する外部のモジュールにおいて、f3もインライン展開される、って事だったと思います。

8:26 AM

このへんかなりややこしくてちょっと自信ないですけど。

8:26 AM

public + inlineable は、 ↑の @usableFromInline と同じ状態になるので

8:26 AM

差が出ているならそういうことかもしれません。

omochimetaru

public struct S1 { @inlineable public func f2() { f3() } private func f3() { compute() } } (edited)

そもそもこれはコンパイルできないですね。 @swift-main public struct S1 { @inlinable public func f2() { f3() } private func f3() { } } (edited)

omochimetaru

public + inlineable は、 ↑の @usableFromInline と同じ状態になるので

Proposal 読んでたんだけど

The @usableFromInline attribute can only be applied to internal declarations. It does not make sense on public declarations, which are already ABI-public. It also cannot be applied to private and fileprivate declarations.

exit status: 1 with stderr:

<stdin>:4:5: error: instance method 'f3()' is private and cannot be referenced from an '@inlinable' function f3() ^ <stdin>:7:16: note: instance method 'f3()' is not '@usableFromInline' or public private func f3() { ^ <stdin>:8:5: error: cannot find 'compute' in scope compute() ^~~~~~~

Yuta Saito

そもそもこれはコンパイルできないですね。 @swift-main public struct S1 { @inlinable public func f2() { f3() } private func f3() { } } (edited)

ああ、できないか。それをできるようにするために @usableFromInline が出てくるんだね。

private に @usableFromInline 使えないんだっけ？

koher

Proposal 読んでたんだけど

The @usableFromInline attribute can only be applied to internal declarations. It does not make sense on public declarations, which are already ABI-public. It also cannot be applied to private and fileprivate declarations.

internalじゃなきゃだめか。

で、 @usableFromInline って @inlinable から呼び出せるだけであって

どうせABI可視性をぶっ壊す(そしてABI互換性の担保をほぼ無理にする）ので付けられても良さそうですけどね。 (edited)

インライン化したいならその internal なメソッドに @usableFromInline じゃなくて @inlinable 付けるんじゃないっけ？

あー、 @usableFromInline は呼び出せるだけか。

8:30 AM

コンパイルできないのができるようになる（ただし普通に呼び出すコードが出る）か

Taketo Sano

inlineable をつけるには method を public にしなきゃいけないのが嫌な場合が多くて，private にしとけばコンパイラが賢くやってくれるのが一番なのですが，public + inlineable の方が速くなるようなケースがある感じがしてまして…

なので

inlineable をつけるには method を public にしなきゃいけないのが嫌な場合が多くて

については、 public じゃなくて internal にして @inlinable つければとりあえずいいのかな？

@inlinableから呼び出すinternal関数を更にinline化するためのアトリビュートが@transparentだったはず

1

transparentってそういうことなのか

@transparentは可視性を問わずに付けられたはず

これ？ https://github.com/apple/swift/blob/main/docs/TransparentAttr.md

それですね

1

LLVMのアセンブラも最適化で独自のインライン化を実行するはずなのでそこまで下りないとどうなるかわからない気がする

Swiftの関数はLLVM側で勝手にインライン化されることは無い気がします。それがあるとABI保守性が壊れるので

↓一つ目から超厳しい制約が書いてある・・・。

When should you use @_transparent? - Does the implementation of this function ever have to change? Then you can't allow it to be inlined.

transparent は標準ライブラリでよっぽどなやつに使うやつ用のイメージ

- Does the implementation need to call private things---either true-private functions, or internal functions that might go away in the next release? Then you can't allow it to be inlined. - Is it okay if the function is not inlined? You'd just prefer that it were? Then you should use @inlinable, rather than @_transparent. (If you really need this, you can add @inline(__always) as well.)

8:38 AM

今回のケースでは internal + @inlinable が無難な気がしますがどうでしょう？

1

そもそもユーザーが提供するライブラリが安定なABIを保証する必要があるのか、という議論もありますが…w

それで合ってると思います。

Yuta Saito

そもそもユーザーが提供するライブラリが安定なABIを保証する必要があるのか、という議論もありますが…w

まあねえ。フルリビルドしてくださいでいいよねえ。

Yuta Saito

そもそもユーザーが提供するライブラリが安定なABIを保証する必要があるのか、という議論もありますが…w

そうですね。どうせビルドすればいいし。

usableFromInline と inlineable の違いがいまひとつ分かっていないです

usableFromInlineは僕の説明が間違ってたのでまずその話は忘れてください

もし、コードサイズの肥大化に躊躇がない&ABI安定を必要としない場合、評価関数によってInline化されないケースが有るinlinableより、絶対にインライン化される@_transparentの方が好ましい場合がありそうです。

Yuta Saito

もし、コードサイズの肥大化に躊躇がない&ABI安定を必要としない場合、評価関数によってInline化されないケースが有るinlinableより、絶対にインライン化される@_transparentの方が好ましい場合がありそうです。

評価関数とどっちが賢いかは微妙じゃない？

8:42 AM

コードサイズが肥大化して、ローカル変数がレジスターに乗り切らなくなる場合とかだと

8:42 AM

関数ジャンプしたほうが早いってことがありそう

8:42 AM

その場合(calleeではなく)callerのコード内容にもよってすべきかどうかが変わってくる (edited)

あー、たしかに。単に命令列が長くなるだけじゃなくて、そういうケースもあるか

まああとコードサイズとキャッシュページのサイズの関係とか。よほどでかいと。

Taketo Sano

usableFromInline と inlineable の違いがいまひとつ分かっていないです

@usableFromInline は @inlinable な関数から呼び出せるだけですね。名前の通りの説明になってしまいましたが

(edited)

8:46 AM

@Taketo Sano クロスモジュールでインライン化されるということはその body が呼び出し側に埋め込まれることになります。そうすると、そのインライン化された関数の中から呼ばれている public でない関数がモジュールを越えて見えないといけないということになります。そのためには public でなくても ABI を公開しないといけなくて、それを可能にするのが @usableFromInline です。

8:47 AM

// Module A import B func a() { b() } // Module B @inlinable public func b() { print("b") _b() } @usableFromInline internal func _b() { print("_b") }

8:48 AM

↑の場合に a が b を利用している箇所がインライン化された場合、↓のようになるイメージです。 func a() { print("b") _b() }

8:49 AM

一方でもし @usableFromInline が @inlinable でフルにインライン化されたら↓のようなイメージです。 func a() { print("b") print("_b") }

8:50 AM

@usableFromInline の例では a の中から _b を呼ばないといけないので internal な _b の ABI がモジュールを越えて公開されていなければなりません。それを可能にするのが @usableFromInline です。

3

8:51 AM

という理解です。間違いがあれば指摘下さい。

ふむふむ，なるほど！

TypeScript で await 忘れやらかして 30 分くらい悩んでた。やっぱり Swift の await 強制はすばらしい・・・。

返り値未使用の警告出なかったですか？Voidだった？ (edited)

Web API で await なメソッドの戻り値を JSON にして返してたんだけど、空のオブジェクトになってておかしいなと思って、クラウドの API だったからパーミッションまわりを疑って権限付与されてるかとか調べてた（実際権限正しく与えてられてなかったから与え直したんだけどうまく動かなくて悩んだり）。そしたら Promise が {} になってただけだった。 (edited)

返り値を使ってるけど駄目だったパターンかあ。 JSONだったからany型になってて、Promise型がそれにハマってしまったのかな。

↓みたいな感じ。 const value = getValueAsync(); const responseValue = JSON.stringify(value);

valueが型推論でPromiseになってるけどstringifyがなんでも受け付けるからチェックできなかったのか。 (edited)

うん。

これはハマる。

value に型を書いてれば tsc が救ってくれたんだろうけど・・・。

Swiftだったら(もしawaitが必須じゃなくても)stringifyのところでEncodable conformanceがなくて、そこで止まってそうだし

10:25 AM

２つのゆるさがかけ合わさって見つかりにくいやつだ

たしかに。

以前Koherさんの記事にコメントさせていただいたんですが、これどう思われますか？ https://qiita.com/koher/items/338d2f2d0c4731e3508f#comment-668fc5304cebad8ca60a

Swift 5.1 に導入される Opaque Result Type とは何か - Qiita

Swift 5.1 で Opaque Result Type (SE-0244) が導入されます。 Opaque Result Type とは何でしょうか。例を見てみましょう。次のような Animal と Cat があるとします。 ...

1

Miwa / Ensan

以前Koherさんの記事にコメントさせていただいたんですが、これどう思われますか？ https://qiita.com/koher/items/338d2f2d0c4731e3508f#comment-668fc5304cebad8ca60a

すみません、完全に通知に埋もれて気付いてませんでした。

2:38 PM

ちゃんと読んでから返事しますね。

そうかなと思っていました、急かすような形でごめんなさい

https://twitter.com/pathofshrines/status/1405295806702366722?s=21

John McCall (@pathofshrines)

@rzidane360 Swift concurrency doesn’t use green threads; switching between tasks pretty much just means returning from the current function that was running the old task and calling the resumption function for the new task, plus a tiny amount of bookkeeping

4:07 AM

おもしろいスレッドが続いてる (edited)

ほー

スケジュールにスレッドを使わないから、事前に用意されたスレッドの上で動くexecutorがひたすら待機してる次のコルーチンを呼び出すループをしてるだけで、コンテキストスイッチも起きないし、コルーチンの中断はスレッドを止めないから、スレッドも止まらないし、コルーチンの内部実装はどんどん次の関数ポインタを返していく仕組みだから小さい関数を繰り返し呼んでいくだけだ。

1

サスペンションポイントが静的に決定できることとタスク内でスレッドをブロックしないという仮定が上手く使われた仕組みっぽい

nodejsがやっていたコールバック関数チェーンだけで全部並行処理をやるって世界観を、完全に言語レベルで組み込んだ感じ。

4:26 AM

ローカル変数も必要なければスタックに置くらしいし。

かしこい

Yuta Saito

サスペンションポイントが静的に決定できることとタスク内でスレッドをブロックしないという仮定が上手く使われた仕組みっぽい

スレッドをブロックしないという仮定

多分これはしばらく死人が出そう

セマフォとか使われると死んじゃう

4:30 AM

まぁ他の言語のconcurrency機能も似たような仮定があるだろうし、他言語触ってれば死ななそう

いや、無いんじゃないかな？

4:30 AM

C# では、良くないですよってぐらい。

4:31 AM

JS は、呼び出せるAPIにブロッキングが一つも無いことで実現してる

呼び出せるAPIにブロッキングが無くてもユーザーがビジーウェイトとかしたらイベントループがブロックされちゃいません？なのでJSは同じような仮定があると思ってました。 (edited)

うーん、まあそれはそうだけど、それ言うとJS環境はシングルスレッドだからなあ。

4:35 AM

並行性が最初から無い・・・

4:35 AM

あと、こういうのあるよ。 https://developer.mozilla.org/ja/docs/Web/API/Window/confirm

window.confirm - Web API | MDN

Window.confirm() メソッドは、メッセージと、OK, キャンセルの 2 つのボタンを持つモーダルダイアログを表示します。

まあConcurrency関係なしにブロックしたら死んじゃうのはそうw

同期でYES/NOを待つ。

あー、そうかそのへんの古のAPIはブロッキングだ

Yuta Saito

まあConcurrency関係なしにブロックしたら死んじゃうのはそうw

正しいけど、ひとつ下の次元で実現しているというかｗ

古のapiがブロッキングなのとブラウザ側からjsを割り込ませる仕組みの組み合わせで

semaphoreとかが出てくるのは、まずthread base concurrencyがあって、そこで制御したくてだからなので

4:37 AM

JSに慣れてるとまあ最初からそれをやってしまうことはないかも。 (edited)

止まった時の中を動くみたいなコードが書けて面白いんだが、swiftでもそういうの書けたりするのかな。マルチスレッド持ってるから単一プログラムの中で実現しそう

tarunon

止まった時の中を動くみたいなコードが書けて面白いんだが、swiftでもそういうの書けたりするのかな。マルチスレッド持ってるから単一プログラムの中で実現しそう

postMessageで非同期にJS <-> ネイティブ通信するんじゃなくてconfirmとかをフックして同期で通信するみたいな話ですか？

それ自体はsemaphreで書けるね

4:40 AM

関数を結果が来るまでブロックして、別スレッドでその割り込み処理をやって結果を渡して、ブロックしてたスレッドを起こす。

promptフックとevaluateJavaScripでwebネイティブ同期通信が成り立つよ

ただasync/awaitになってからそれをやると、

4:41 AM

他のasync taskが巻き込まれて止まるので崩壊する

ふむ

自分で立てた割り込みスレッドは動くけど。

4:42 AM

ブロッキングを使った仕組みが、async/awaitで動いてるところに混ざり込むと、並列で動くつもりだったasync達が想定外に巻き込まれて止まる

DispatchSemaphore に警告出すとかしないと事故がいっぱい起こらないかな？

LIBDISPATCH_COOPERATIVE_POOL_STRICT=1 にすると

5:28 AM

そういうところでクラッシュするようになってくれるらしい

XCTestExpectation とかも事故りそう。

あれは完全にヤバそうですね。

5:29 AM

.wait するけど、それでスケジューラが止まって、Taskが止まるので、世界が停止してテストが終わらないｗ

5:29 AM

xctestがasyncになるんじゃないのかしら。throwsになったときみたいに。

うん、なるはず。

5:31 AM

でも慣れてない人が XCTTestExpectation と混ぜて死ぬとかありそう。

現状のXcode13betaのXCTestframeworkだと特になってないのかな

5:31 AM

まああとすでに書いてあるテストが問題ですね。

5:31 AM

asyncへの段階的以降ができない。

まあ、コールバック→ async/await に自動変換された API をテストで元々使ってて expectation 使ってる箇所はコンパイル通らなさそうなので検出できるかな？

enum Command: Codable { case load(String) case store(key: String, Int) } の .load("MyKey") が { "load": { "_0": "MyKey" } } にエンコードされることになったの、なんで "0" じゃなくて "_0" になったんでしょうか？ 0 はラベルにできないから case load(0: String) は作れないので衝突しないけど、 case load(_0: String) は作れて衝突するから "0" をキーにした方が良さそうに思うんですが・・・。何か理由があるんだとは思いますが。 (edited)

enum LoadCodingKeys: CodingKey { case _0 }

6:27 AM

のように、ケースごとの構造の方のCodingKeyが作られるからだと思います

6:28 AM

まあ enum LoadCodingKeys: CodingKey { case _0 = "0" } ってことにすることは可能ですけど。

6:28 AM

あー、もしかしたら、

6:29 AM

PHPやJSだと { "0": "a" } と ["a"] が区別できなくてトラブルの元だから、みたいな事もあるかも？

6:32 AM

提案書には細かい議論が書いてないですねえ。

6:33 AM

このunlabeled parameterは長いこと話が伸びてたトピックの一つだったのを見た気がするのでいろいろありそうですが。

なるほど。衝突しうるのは問題な気はするけど、実質的には問題ないだろうし（ _ から始まるラベルなんか作らないし）、シンプルに CodingKey を作るところが一番の理由になってそうだね。

https://qiita.com/ensan_hcl/items/1cbe299df9394d8cd638

[Swift] 引数の位置のsomeは本当にジェネリック引数なのか？ - Qiita

背景 Swift5.1でOpaque Result Typeという種類の型が追加されました。これは「制約を満たすなんらかの特定の型」を関数が返せるようにする仕組みです。その動作は「リバースジェネリクス」という概念で説明されます。...

Miwa / Ensan

以前Koherさんの記事にコメントさせていただいたんですが、これどう思われますか？ https://qiita.com/koher/items/338d2f2d0c4731e3508f#comment-668fc5304cebad8ca60a

これについて書きました

Miwa / Ensan

以前Koherさんの記事にコメントさせていただいたんですが、これどう思われますか？ https://qiita.com/koher/items/338d2f2d0c4731e3508f#comment-668fc5304cebad8ca60a

遅くなりましたがお返事を書きました。 https://qiita.com/koher/items/338d2f2d0c4731e3508f#comment-6bce387660d7028e2b4d

Swift 5.1 に導入される Opaque Result Type とは何か - Qiita

Swift 5.1 で Opaque Result Type (SE-0244) が導入されます。 Opaque Result Type とは何でしょうか。例を見てみましょう。次のような Animal と Cat があるとします。 ...

1

4:14 PM

戻り値ジェネリクスに対して引数リバースジェネリクスというのはおもしろいですね。

// 戻り値ジェネリクス func foo<T: Foo>() -> T // 引数リバースジェネリクス func bar(_ x: T) -> <T: Foo> Bar

ありがとうございます！

11:28 PM

リバースジェネリックな引数と同じ振る舞いを持つクロージャは今のSwiftでも作ることができます

let value: some BinaryInteger = 42 let someClosure = value.isMultiple // someClosure: (some BinaryInteger) -> Bool let number: Int = 42 someClosure(number) // 引数の型がIntとはわからないのでエラー someClosure(.zero) // (some BinaryInteger).zeroは存在するのでエラーにならない

Miwa / Ensan

リバースジェネリックな引数と同じ振る舞いを持つクロージャは今のSwiftでも作ることができます

let value: some BinaryInteger = 42 let someClosure = value.isMultiple // someClosure: (some BinaryInteger) -> Bool let number: Int = 42 someClosure(number) // 引数の型がIntとはわからないのでエラー someClosure(.zero) // (some BinaryInteger).zeroは存在するのでエラーにならない

これおもしろいですね。

https://forums.swift.org/t/add-shared-storage-to-property-wrappers/49898

Add shared storage to property wrappers

(Add shared storage to property wrappers pitch on github) Introduction Property Wrappers have empowered users to abstract common property implementation details into expressive components. This proposal aims to make property wrappers more flexible and efficient by allowing them to opt-in to a shared storage. Motivation Property Wrappers are ...

2:17 AM

5日前に立ったスレッドなんだけど、Joe GroffとHolly Borla (推論器とかProperty Wrapperの機能実装してる人)とJohn McCall が長めの文章でかなりディスカッションしてる

2:18 AM

トピックとしては、Property Wrapperのメタパラメータって、値のインスタンスごとにあるのって同じ設定になってるので無駄だから、宣言に対して一つになるように、インスタンス間で共有したほうがよいので、そういう言語機能がほしいというもの

2:20 AM

>>8 で Karl さんがジェネリックパラメータに値が書けたらよくない？と言っていて僕もこれが綺麗だと思ったけど・・・

今だとgenericsあるとstatic変数宣言できないってのを、何かしら制限解除すればいいんかしらね

このproposalでは前提としてstatic変数で宣言してそれを渡すのでも同じだけど直感的な専用記法がほしいって主張になってる。実際、この機能を使ったらコンパイル後はstatic変数になるって言ってる。

なるほど

2:24 AM

直感的は個人の主観ではって思っちゃった

うん、俺は提案された仕様自体は、なんかいろいろついててわけわからんなと思った。新しいアトリビュート？キーワードが増えちゃうからね。 (edited)

既存の仕組みで表現できるならそれの中に収める方が良いだよなぁ

https://www.swiftbysundell.com/tips/default-decoding-values/

Annotating properties with default decoding values | Swift by Sundell

Making Codable much more flexible.

2:26 AM

僕はこのDecodale Defaultをよく使うんだけど

2:26 AM

このテクニックは型パラメータとして値を入れる手法で、これでやりたいことは出来てると思う

2:27 AM

ただまあかなりテクくてわかりにくいかも。

static変数が宣言できるようになったら、このテクが幾許か楽に書けるようになるかな？

2:28 AM

まあやるにしてもstatic解禁が良いんじゃないかなぁ

たるのんが言ってる解禁ってどういう話？

@swift-5.3.3 struct Cage<Animal> { static var size=1 }

exit status: 1 with stderr:<stdin>:2:14: error: static stored properties not supported in generic types static var size=1 ~~~~~~ ^

これを何かしらの制約で出来るようにすると言うことです

それだと、 Cage 全体で共有されちゃうけど

2:30 AM

struct Hud { @Clamped(@shared: RangeStorage(0...14)) var bar = 5 @Clamped(@shared: RangeStorage(1...9)) var foo = 1 }

例えばwhereで切るなりして宣言するとか

↑のすべての Hud.bar で共有、だからそこじゃないんだよね

2:31 AM

Hud 自体はジェネリックパラメータが無いから static 変数は使える。

ンー？

宣言で見たユースサイト側で共有される (edited)

2:33 AM

今だと Hud のインスタンス１つにつき、bar1個と 0...14 と foo 1個と 1...9 が存在する

何がやりたいかわかった気がするが、これは大分ややこしい機能を提案してる気がするな

でもどのHudのインスタンスであっても、 bar にたいして　0...14 という同じ値をもつので、それを Hudのインスタンス間で共有したい。 Clamped自体は foo では 1...9 を持つので Clamped にたいしては static ではない。 (edited)

オブジェクトの利用宣言の側から共有変数を宣言することを強制してインスタンス化するって事ね

そう。

これ共有変数が共有されるべきであるというコンテキストはどうやって指定するンや

@propertyWrapper struct Clamped<Value: Comparable> { @shared let storage: RangeStorage<Value> var wrappedValue: Value { ... } // a plain struct, with properties that will be shared across wrappers struct RangeStorage<Value: Comparable> { ... } }

2:36 AM

@shared っていうのが提案されてる

sharedの宣言じゃなくて、Hud.barであるという証明が必要

2:36 AM

別にオブジェクトをinitするときに、何処で其のオブジェクトが作られたなんて今までは責務の外だったのが

struct Hud { @Clamped(RangeStorage(0...14)) var bar = 5 @Clamped(RangeStorage(1...9)) var foo = 1 } ↑ここで RangeStorage(0...14) を指定してるよ (edited)

突然関係するようになってくるから死ぬんじゃないかな

この RangeStorage(0...14) の実行が、最初の Hud.init のときにしかされず、2回目以降はキャッシュされたオブジェクトが渡される。

2:38 AM

struct Hud { @Clamped(RangeStorage(0...14)) var bar = 5 @Clamped(RangeStorage(1...9)) var foo = 1 } var hud1 = Hud() var hud2 = Hud() // desugars to struct Hud { static let bar$shared = RangeStorage(0...14) static let foo$shared = RangeStorage(1...9) var bar = Clamped(wrappedValue: 5, @shared: bar$shared) var foo = Clamped(wrappedValue: 1, @shared: foo$shared) } // both Hud's get access to the same $shared properties. var hud1 = Hud() var hud2 = Hud()

↑のdesugars toと見比べるのが挙動は一番わかりやすいな

ンじゃあ他のコンテキスト、例えばstruct CatでRangeStorage(1...9)って書いたらHudのsharedが汚染される？

いや、そのときは Cat の中に static なんちゃらが生える

あーー、Hud側にstaticが展開されるって事ね

またコンテキストの深い @ が増えるのか

よくわかってないんですが、属性で@をつけるかどうかってどういう判断なんでしょう

@ は追加的な型情報になってる場合 (@escaping) と、コード生成をほのめかす ( @propertyWrapper, @resultBuilder) 場合がありますね。

2:50 AM

この場合は後者のニュアンスでの採用だと思います

2:51 AM

# はコンパイルタイム変数 ( #file , #if ) のニュアンスがありますね。

@unknownとかは後者です？

@unknown はどっちでもないですねｗ

2:52 AM

@unknown はコード検査に影響を与えるがそれ自体は制御に影響を与えないやつ。（なくてもロジックが同じ）

2:52 AM

なくてもロジックは同じで検査に影響が与えるって意味では @escaping もそうだな。

@discardableResultとかも同じ分類ですかね、じゃあ

あ、そうですね。 @discardableResult はロジック一緒で検査が変わる。

なるほど

その2つにわけると良さそうですね。ロジック一緒で検査が変わるやつと、コード生成するやつ。

2:55 AM

あ、今の話は僕の持論で、公式なソースはないです。

SE-0293とかメソッド内での宣言の場合はどうなるんだろう (edited)

Clampedのユースケースがまさに SE0293 なので、考慮しているんじゃないでしょうか？

3:30 AM

メソッド内のパラメータ宣言に対応して、

3:30 AM

メソッドを定義してるコンテキストにstaticに定義されれば実現はできます。

確かにdesugarの頑張り次第ですね

https://forums.swift.org/t/add-shared-storage-to-property-wrappers/49898/72

Add shared storage to property wrappers

I've been talking more with @hborla and @Douglas_Gregor about this, and I think we can structure this into a series of three proposals. Expanded parameters The first proposal allows a subsequence of call arguments to be implicitly collected together at compiler time to initialize a single aggregate argument. That is, one could write a functio...

2:57 PM

expanded便利そうだなと思ったんですが、多分コード生成なので@expandedの方が近そうに見える

Yuta Saito

Yamsはどっちのパスも塞がれてそうｗ https://github.com/jpsim/Yams/blob/adeee7ef61d9c80da61c53561d65d189670d7a36/Sources/Yams/Encoder.swift#L64-L67 https://github.com/jpsim/Yams/blob/adeee7ef61d9c80da61c53561d65d189670d7a36/Sources/Yams/Encoder.swift#L205-L222

めちゃ遅いレスですが、Yamsだとomochiさんのあげたコード: func encode(to encoder: Encoder) throws { try a.encode(to: encoder) try b.encode(to: encoder) } はマージされ、 func encode(to encoder: Encoder) throws { var c = encoder.singleValueContainer() try c.encode(a) try c.encode(b) } はPrecondition failed:でクラッシュします。

家庭君のレスだとどっちも駄目だと思ったけどSVC介さない場合はオッケーだったんですね。 (edited)

a, bどちらもKeyedEncodingContainerを使いますが、YamsのKeyedEncodingContainerはcanEncodeNewValueがfalseを返しても、直前に使われたのと同じ型ならば通す様になっています。UnkeyedEncodingContainerも同様。 (edited)

6:59 AM

この挙動はJSONEncoderの初期実装に合わせたような気がする。

KEC, UECがマージする挙動はこの辺りで初期からテストされてるけど、SingleValueEncodingContainerの挙動はテストされてないかも。 https://github.com/apple/swift-corelibs-foundation/blob/main/Tests/Foundation/Tests/TestJSONEncoder.swift#L1356-L1368

7:20 AM

あー、ランタイムクラッシュするテストを書けないから、テストで表せないのか。

1

なるほど

@available(*, deprecated) ってProperty Wrapperには効かないんでしょうか？ @available(*, deprecated) @OptionalField(key: "start_date") public var start_date: Date? があるんですが、model.start_date は警告出るのに model.$start_date は警告が出ない……

というか、その指定は start_date に対してついてるんじゃない？

$start_date に対して付ける方法はないのかという疑問です。

なさそう　projectionValue は宣言が無いから。　start_date　についてるものが $start_date にも伝搬したほうが嬉しそうだな

start_date が deprecated なのに $start_date が deprecated でない状況は存在しないように思うから、単に考慮漏れじゃないかなぁ。

2:44 AM

$ でなく _ にも出ないのか。

2:44 AM

import Combine だな・・・。本題とは関係ないけど。 (edited)

不具合扱いでバグレポート出しちゃうのが良い気がします

@koher シンプルで良いのでこれ参考にバグレポート書きます。

1

https://bugs.swift.org/browse/SR-14884

import Foundation let line = (1 ... 1_000_000).map { $0.description }.joined(separator: " ") func measure(_ body: @escaping () -> Void) -> TimeInterval { let start = Date.timeIntervalSinceReferenceDate for _ in 0 ..< 10 { body() } let end = Date.timeIntervalSinceReferenceDate return (end - start) / 10 } print(measure { let numbers = line.split(separator: " ").map { Int($0)! } print(numbers.count) }, "[s]") print(measure { let numbers = line.split(separator: " ").map { Int(String($0))! } print(numbers.count) }, "[s]")

(edited)

4:22 PM

$ swift -O convert-time.swift 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1.265830397605896 [s] 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 1000000 0.3805763006210327 [s]

4:22 PM

Substring を直接 Int に変換するよりも String に変換してから Int に変換した方が速い。

4:24 PM

String を Int のイニシャライザに渡すと Int.init(_: String) が呼ばれ、 Substring を Int のイニシャライザに渡すと Int.init<S: StringProtocol>(_: S, radix: Int = 10) が呼ばれる。

4:26 PM

後者は N 進数版だから遅いのかと思ったら↓なのでそれは関係なし。

extension FixedWidthInteger { ... @inlinable @inline(__always) public init?(_ description: String) { self.init(description, radix: 10) } }

4:26 PM

Substring の場合は specialize されないから遅い？

SIL 確認したけど Specialize されてるっぽいなぁ。単に Substring が遅いのかな・・・。

↑これ、Substringが遅いわけじゃなくて、Stringかつメモリ上で連続アクセス可能なときfastPathに入って速くなってるんじゃないですかね？ https://github.com/apple/swift/blob/2e3b1b3e77afab4d158d40f54ca8bfc76521da81/stdlib/public/core/IntegerParsing.swift#L154-L163

1

1:44 AM

（というのをzennを読んで思いました https://zenn.dev/koher/articles/swift-kyopro-substring-to-int ）

↑ですね。昨日 https://forums.swift.org/t/parse-int-from-substring-slower-than-string/50516/4 で同じ回答をもらいました（この問題を解決した人に）

Parse Int from Substring slower than String

Ah, you're using Swift 5.4! The code you're reading in IntegerParsing.swift was rewritten (by me) in March, so you'll need macOS 12/Swift 5.5 to see the results I posted. The previous implementation was indeed over 10 times slower for Substring, one of the reasons I rewrote it. My main preoccupation during the rewrite was making sure code size ...

1

なるほど。

2:19 AM

if let str = text as? String, で分岐しちゃってるんですね。

2:20 AM

Substring でも同じ様に処理すれば同等のパフォーマンスを実現できるのか。

ribilynn

↑ですね。昨日 https://forums.swift.org/t/parse-int-from-substring-slower-than-string/50516/4 で同じ回答をもらいました（この問題を解決した人に）

main だとすでに解決されてるんですね。

 @inlinable @inline(__always) public init?<S: StringProtocol>(_ text: S, radix: Int = 10) { _precondition(2...36 ~= radix, "Radix not in range 2...36") guard _fastPath(!text.isEmpty) else { return nil } let result: Self? = text.utf8.withContiguousStorageIfAvailable { _parseInteger(ascii: $0, radix: radix) } ?? _parseInteger(ascii: text, radix: radix) guard let result_ = result else { return nil } self = result_ }

そうですね。原因を探そうと思ってこのコードを読んでしまって String Substring 違わないか？？と混乱しました

後で Zenn に追記しておきます。ありがとうございました。

違いが判らないと思ったらHEADは修正済みだったのか　なるほど

@Yuta Saito @ribilynn 追記しました。ありがとうございました。 https://zenn.dev/koher/articles/swift-kyopro-substring-to-int

1

https://github.com/apple/swift/pull/38599 何周か回って yield() になりそう

[SE-0304] Rename Task.suspend() back to Task.yield(). by DougGr...

ええーw

AsyncThrowingStreamはFailure==Errorのイニシャライザしかないけど特定のErrorにするにはどうしたらいいんだろ

どちらにせよ利用側で for await in するときに型が消えるので、特定のErrorでは作れなくていいのではないでしょうか

Failureを明示的に持たせる意味がよくわからなくて…、将来typed throwsに対応したときのためのシグネチャ的な感じなんですかね

async sequence、モナド記法もそのまま使える気配があるので、モナド記法なら型付きFailureが役に立つんだと思います

1

AsyncStreamの方は Failure == Never になってて実装を共通化できるのかなとか思ってました

今のところ実装は完全に別々みたいですね

なるほど・・・　なんかどっかのrevisionでそうなった的な話が書いてあったから、調べたら意図がわかるかな

#available の否定で #unavailable が使えるようになるの便利。新しいバージョンだと何もしなくていいけど古い場合はこれを呼ぶ必要がある、っていうのをキレイに書けなかったのがスッキリ。 https://swiftfiddle.com/udg7iynkkjebzhazpliscwovoq

7:32 AM

if !#available(...) って書けるほうがいいけど、、、って思ったことにはちゃんと説明があった。 https://github.com/apple/swift-evolution/blob/main/proposals/0290-negative-availability.md#alternatives-considered

swift-evolution/0290-negative-availability.md at main · apple/swift...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0290-negative-availability.md at main · apple/swift-evolution

@available の obsoleted みたいなやつって #available にはなかったんですね。

Kishikawa Katsumi

if !#available(...) って書けるほうがいいけど、、、って思ったことにはちゃんと説明があった。 https://github.com/apple/swift-evolution/blob/main/proposals/0290-negative-availability.md#alternatives-considered

ここの処理は汎用計算にはなってないっぽいですね。

知らなかったわ。

なんか、Foundation ビルドしてるときに気がついたかな。OSごとのラインタイムがあって、判断するロジックが組み込まれてたんだったかな。

そうなんですね。

clangにあるやつと同じ実装を使ってる雰囲気だった気がした

4:31 PM

嘘かも。

https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805

guard capture specifier for closure capture lists

Hey folks, this pitch discusses introducing a new guard capture specifier for closure capture lists. This topic has come up before over the years ([1] [2] [3] [4] [5]), but has never been implemented before as far as I can tell (until now!). This proposal is implemented in apple/swift#38718. Introduction guard captures behave like weak captur...

4:48 PM

guard captureの提案、実装付き！

[guard self] だと self. の省略もできるのか。なるほど〜

実装つきすごい

5:04 PM

voidを返してるんだよなみたいなのが意味的に消滅してしまってるのが気になる

guard の意味ぎゃくじゃねって twitter でレスされてたきがする

早期returnを別途宣言できるようにしてさ

5:05 PM

voidならそれが省略できますってのが、丸いと思った

5:06 PM

まあでもそれだったら普通に高階util関数で良い罠

niw

guard の意味ぎゃくじゃねって twitter でレスされてたきがする

スレでも[if self]を提案してる人がいますね

なんか、if も微妙な気がするけど。

https://github.com/apple/swift/pull/36441 -- defer のやつ

Sema: Ban forward references of captured values from 'defer' body b...

While 'defer' is implemented as a local function, it doesn't behave as one. In particular, since SILGen runs it after destroying all local bindings that appear after the &am...

omochimetaru

https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805

ふと思ったのだけど、これasync sequenceでうっかりメモリリーク作る原因になっちゃうね

3:57 AM

// ok async { [weak self] in for await notification in NotificationCenter.default... { guard let self = self else { break } self... } } // leak! async { [weak self] in guard let self = self else { return } for await notification in NotificationCenter.default... { self... } }

こういうケースは前から結構あったし、async sequenceが出てきた以上無視できないようになったと思う

tarunon

// ok async { [weak self] in for await notification in NotificationCenter.default... { guard let self = self else { break } self... } } // leak! async { [weak self] in guard let self = self else { return } for await notification in NotificationCenter.default... { self... } }

こういうケースは前から結構あったし、async sequenceが出てきた以上無視できないようになったと思う

あーなるほど。 for await イベント通知パターンだと、ループごとに self 取り出さないと、循環参照になるね。 [guard] captureだと固定で先頭で取り出すから駄目なのか。

4:04 AM

どうなんだろうなあ。リークというか、循環してるだけで、切ればいいよね。画面が表示されてる間は循環してても良くて、画面が閉じられた時にtaskを一通りcancelして購読解除してやるスタイルなら大丈夫。

画面が表示されるたびに購読を開始して、画面が消えるたびに購読を解除するが実現可能ならそれでもいいが (edited)

RxSwiftだと循環作らないようにした上で DisposeBag で全部片付けるのが主流だけど、そもそも画面が裏に行ってるけど解放はされない状態(presentの裏とか)で、イベントが飛んできたら問題があるし。 (edited)

viewDidUnloadがなくなって、appear系が呼ばれずにdisappear系だけが呼ばれたりする今のUIKitでその管理はかなり厳しい

それは左端スワイプでフェイントかけてチラチラしたりしたときに、　予告である willDisappear だけ何回も呼ばれるとかで、 didDisapper と willAppear で挟む限りは表示状態と対応取れてるんじゃなかったっけ (edited)

interactive transitioningをキャンセルした時、遷移先でなくなった画面って、willAppearの後didDisappear呼ばれてましたっけ

4:09 AM

結構この辺は苦心した覚えがある（が、どうだったかはちゃんと覚えていない）

あ〜 willAppear も予告で、 didAppear が確定保証なんかな？

あとは、willAppearから購読開始だと遅すぎるって問題があって

4:10 AM

その作りに統一しよう！っていうのは結構厳しい

willAppear で早めに開始したいけど willAppear だけ呼ばれて didAppear も didDisappear も呼ばれないというハマりはありそうな気がするな。

4:11 AM

でも↑で書いた、裏に居るのに NotificationCenter からイベント来たら困る問題はあるでしょ？

まあ逆も然りだなぁ、作りによるのでは

interactive transitioning側のイベントをうまくハンドリングしないと、全ての問題を回避する実装ってできないんかね。

viewController.view.windowがいるかいないかで、画面上に存在してるかどうかを見分けるのが一番楽で

4:14 AM

購読はするが、イベントを発火させるかをwindowの有無をトリガーに制御するってのが一番楽

4:14 AM

Disposeはメモリ管理に任せたい

view.window ってKVOできるっけ

できない

じゃあcustom viewでdidMoveToWindowか

4:16 AM

presentとかpushの裏に行った時ってwindowから剥がされてるの？

そこまで積みこんでまで[guard self]を使う理由はないなぁ

剥がされてない気がする。

えーと

4:16 AM

今のpresentは裏に居続けてるから剥がれないね

購読はするが、イベントを発火させるかをwindowの有無をトリガーに制御する

購読はしっぱなしでイベントは読み捨てるのはなるほど。

昔は剥がれた気がするけど、ちょっと覚えてない

そうだよね　なんかpresentもチラ見えモードがデフォルトになったし。

4:17 AM

まあれか、さっき言った、willAppearフェイントパターンは

4:17 AM

やっぱり出なかったことはwindowチェックでいけるね。

4:18 AM

画面が出る前にはwillAppearフェイント問題があって画面が出た後には裏画面生存問題があるんだな。

https://discord.com/channels/291054398077927425/291054454793306112/874868766763274250 結論これになると思うけど

うーんたしかに。guard returnしたい状況のほとんどがviewControllerのselfチェックでイベント読み捨てなきはする。

4:20 AM

循環させないスタイル→先頭でespaceするのはだめ循環させるけど切るスタイル→strong captureで良いだから

4:20 AM

まあどっちにしろ将来ほとんど出番が無い？ってことになる？

4:22 AM

https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805/13

guard capture specifier for closure capture lists

I don't like this feature because I think this is an anti-pattern, but I'll toss in another spelling: guard weak self, or some other modifier on weak self. I think having the keyword weak is valuable for making the object graph ownership semantics clear; it makes it less "new syntax you have to learn the desugaring of".

4:23 AM

jroseさんがこの文法はアンチパターンを促すから良くないよって言っててまあ unowned self 使いたいからだって意見だからぜんぜん違う視点なんだけど

4:23 AM

tarunonの書いた将来のfor awaitパターンにおいてはアンチパターンを促しそうって意見は共有する価値がありそう。

4:23 AM

アンチパターンと言うか状況によっては直接的なバグやな。

[weak self] に限らず、 await は単発で基本的に必ず resume される想定だから strong capture でよかったという前提が、 for await によって破られてるのか。 https://discord.com/channels/291054398077927425/375206337937801216/571199858916982793 (edited)

必ず resume される想定だから strong capture でよかったという前提が

この認識は特になかったw

4:35 AM

大半はstrongでもいいけど、気をつけないと死ぬよぐらいの温度感でした

それが for await で普通に死ぬくらいになった感じかと。

そうですね。正確には無限ストリームに対するfor awaitだから問題ですね。

4:37 AM

有限ならいつか解放される。

async { [weak self] in だとループの中で guard let self = self しやすいけど、 func foo(...) async の中で for await で無限ストリーム扱う場合とかきつくない？そんなケースはない？

4:39 AM

for await でなくても無限 for ループの中で await したら同じだけど、 for await で現実的に相当起こりやすくなってそう。

その場合fooが無限ストリームを返す関数になってるんじゃないかしら

そうあるべきですねぇ

4:40 AM

書ける書けないでいうと、まあ壊すことはできます。それ言ったら func foo() { while true {} } と本質的には同じだし

内部で購読という副作用を起こすのは困りが増えそう

まあ基本 async とセットで購読か。購読のメソッドだけあって呼び出す側で async する意味はないか。

4:42 AM

async { await subscribeFoo() } みたいなのはしなさそう、という意味。

パターンとしては

4:54 AM

func subscribeFoo() { async { [weak self] in for await ... { ... } } } であるべきでしょうね

1

struct のデフォルト initializer を public にしたいだけのために init(a: ...) { self.a = a... } を大量に書かないといけないのはどうしようもないんでしたっけ。全ての member が public であったとしても。 (edited)

niw

struct のデフォルト initializer を public にしたいだけのために init(a: ...) { self.a = a... } を大量に書かないといけないのはどうしようもないんでしたっけ。全ての member が public であったとしても。 (edited)

どうしようもないと思ってますが、改善されてほしいですね。

4:36 PM

一応、型を右クリック → Show Code Actions → Generate Memberwise Initializer で生成できますが・・・。まあでも意図しない public API の破壊の可能性を考えると仕方ないのかな。

そうかー。。。

5:01 PM

気持ちはわかる。

5:01 PM

…若干過剰なきもするけど。

わかるけどボイラープレートだらけになるの辛いですよね・・・。

プロポーザル出せそうなネタな気はしますね、難易度的にも丁度良い？

ありそうではある（探してはいない） (edited)

まあ当然いろいろあるな... https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md とか 18...

swift-evolution/0018-flexible-memberwise-initialization.md at maste...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0018-flexible-memberwise-initialization.md at master · apple/swift-evolution

18からのDeferredは事実上のRejectedではw (edited)

swift の progressive exposure 的な精神で public なんてダメ絶対的なそこは譲れない一線があるのかも。

でもenumのcaseは自由に作れちゃう

0018は出たのが早すぎたからで

3:37 AM

多分ちゃんと着火すれば再開するやつだと思う (edited)

3:38 AM

単に今はまだ早い的な決定がされただけで内容の議論は深まってない

3:40 AM

public struct S { public default init } とか書けたらいいと思うんですけどね

ほしい

これはちゃんとなにかいてみるいい機会なんだろうか...

https://forums.swift.org/c/related-projects/25

Related Projects

The Related Projects category includes sub-categories that are dedicated to open source projects within the Swift community that are separate from the Swift language itself.

5:53 PM

↑一気に５個のライブラリが1.0に向かうらしい

2

https://forums.swift.org/t/announcement-planning-for-swift-collections-v1-0/51321

[Announcement] Planning for Swift Collections v1.0

[Announcement] Planning for Swift Collections v1.0 TLDR: We'd like to officially declare Swift Collections source stable and tag version 1.0 of it in the next week or two. Please speak up now if you have something you'd like to see changed in Deque, OrderedSet or OrderedDictionary -- this is the last opportunity to (easily) fix any API issues. ...

2:35 PM

アンスコ付きはpublicでもunstableだよって明言してる

https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467

Pitching The Start of Variadic Generics

Hello Swift Community, As part of our efforts to improve the ergonomics of the generics system, as well as providing better support for abstractions that use tuples, I wanted to approach y’all with a sketch for the surface syntax and preliminary semantics. Because this is a large topic area with a lot of impacts on the direction of both the lan...

10:37 AM

可変長ジェネリックパラメータの設計案をcodafiさんが出した

オッ

10:37 AM

出来るようになって欲しいねぇ

仕様の決めが難しいよね c++みたいに型パラメータのところに任意の式が書けるようにはしたくない

10:39 AM

でも任意の式を書けるようにしないと多様なユースケースに対応できない

10:41 AM

このcodafi案で面白いと思ったのは

10:41 AM

func allPresent<T..., U...>(haystacks: T..., needles: U...) -> Bool where T == Set<U> { for (haystack, needle) in zip(haystacks, needles) { guard haystack.contains(needle) else { return false } } return true }

10:41 AM

こういうふうに、 T と U の間に Constraint を書くと、

10:41 AM

T... と U... の個数が同じって制約も付くらしい

逆に違って嬉しい場面ってあったっけ、あんまり思い付かない

10:44 AM

可変長Genericsやったときって、個数がバラバラになると中のコードが異様に書きにくくなる、或いは書けるのかも怪しいと思うんですよね

例えば、個数の違う T... と U... を受け取って、長い方のあまりをなんか別の処理に回すとか

10:45 AM

T... U... V... において T + U == V の制約のもとでペアでなにかするとか

型のたたみ込みとそれに伴うコードの記述とか上手く行くモンなのかな

C++ならできるね

10:46 AM

基本的に再帰的に書いて

10:46 AM

先頭一個の取り出しと、残りのリストにわけて、

なるほどね

ジェネリック関数自体を再帰すればなんでもできる

async/awaitからさらに可変長Generics入ってとかなると

10:48 AM

SwiftUIはいっそ作り直した方がマトモなIF定義できるんじゃ無いかとすら思えてくる

...はpartial rangeに使っちゃったからsplatに使えないのかw

for-inの中で要素の型がイテレーションごとに変わるけど、全ての要素に対して同じ制約を課すことで、ループ内の型検査が静的にできるようになってるのが良い

11:21 AM

前おもちさんと話したのを掘り起こした https://twitter.com/kateinoigakukun/status/1220591042228940802?s=21

kateinoigakukun (@kateinoigakukun)

@omochimetaru あー、それでいうと気になってたのは文法とランタイムの話かもしれないです型の数はcalleeを定義するときに決定できないからイテレートする手段が提供されないといけないけど、そうするとfor param in paramsでparamの型が毎回変わるのか。とか

1

この提案だと

11:52 AM

struct Head<H, R...> { } func car<T...>(_ t: T...) -> Head<T...>.H { t[0] }

11:53 AM

これできるのかな T... が 0個のときおかしいから駄目かな

C++っぽい

例えば高階関数を畳み込むようなやつがこういうのができないと書けないよねえ

11:55 AM

forループに書き下して無理やりやれるかもしれんけども、、、

具体的なユースケースどんなのあります？

レス13に稲見さんの書き込みあった

Yuta Saito

具体的なユースケースどんなのあります？

最近まさに使ってるのだと、 EventLoopFutureを返す関数をN個受け取って、順番にflatMapで呼び出して、 N要素のタプルのELFを返す高階関数を6通りオーバーロードした (edited)

なるほどそれは無理そう

https://github.com/apple/swift/pull/39051

Add an option to build the concurrency library for back deployment....

Introduce an additional build product to build-script to build back-deployable concurrency libraries. These libraries would need to be embedded in apps deployed prior to macOS 12/iOS 15 to support ...

やったー

2:29 AM

These libraries would need to be embedded in apps deployed prior to macOS 12/iOS 15 to support concurrency.

今後こういう機能が追加されてもBack deployされることがわかってうれしい

これどうやってEmbeddedされるんだろう

Back deploy用のlibswift_Concurrency.dylibがアプリに埋め込まれるんじゃ無いんですかね

2:44 AM

ビルドシステムが頑張る

Build Settingsにフラグが生えるのか (edited)

バックポートできるのはiOS 13までっぽいね。13でも使えるっていうのはかなり大きいんじゃないだろうか。

1

Always Embed Standard Libraryみたいなオプションが生えそう

もうありそうな名前だw

ABI Stableなランタイムが出荷されたのが13でしたっけ

おお、そういうことか。12以前は手の出しようがないのか。

そんな気がしますねえ

15が出れば底が13でも大きな問題は無いだろうし、時間で解決できそう

今もう大体12は切られてるはず。大きな会社は知らんけど

iOSで早めに使えるようになったか　やったー

Yuta Saito

ABI Stableなランタイムが出荷されたのが13でしたっけ

Concurrency.dylibが libSwiftCore.dylib の iOS13, 14, 15 同梱版全部とリンクできるようになっとるってことか (edited)

3:19 AM

iOS12はABI Stableじゃないからリンクできない可能性があると

3:19 AM

stdlibのABI stabilityなんも気にしてなかったけどこういう影響があるのか

上に貼ってたPRの他に準備のためのPRがいくつかあるように見えたので追ってみるか

3:24 AM

古いランタイム向けのバックデプロイパッチがあるお陰でConcurrencyライブラリはランタイムのバージョンごとに手を入れる必要が無いのかな

バックデプロイパッチは、新しく増えた関数は使えないけど、既存関数で挙動が変わったものを新しい挙動にパッチするから、古い関数（ただし新しい挙動）だけで作れば同じ

3:26 AM

でもそれはランタイム関数だけで、

3:26 AM

標準ライブラリ部分はパッチの仕組みないから

3:26 AM

標準ライブラリは気をつけてソース固定してるんだよね？

あー、そうですね

3:27 AM

今回のConcurrencyモジュールはモジュールを分けてたおかげですんなり行けた

だから実行時に動くコードは・1. Swiftで書かれたstdlibライブラリ実装・2. ランタイム関数部分・3. ユーザーがビルドしてコード生成された部分の3種類あって、1と2は環境固定だけど2だけは一部パッチできる

3:29 AM

コンパイラチームはあらゆる仕組みを1と2と3のどれにするか気をつけて設計しないといけない

3:29 AM

（原理的に選択肢1がほぼだめな場合はあるけど

3:29 AM

何を2にするかはかなり難しそうだけど経験と勘でうまいことやっているんかな

そして1の実装詳細をうっかりinlinableとかでABI Publicにすると一生固定することになる

それはどうなんだろう？

3:30 AM

結果が同じなら実装コードは変わってても問題なくない？

3:31 AM

動かす時に、アプリの中にインライン埋め込みされたコードと、環境のライブラリを呼出すコードが混在するけど

変えられるコードの範囲が限定されないですか？

その結果のデータの変化が同じ挙動なら大丈夫

ミクロな単位ではそう

そもそも「仕様」はABIprivateであっても変えちゃいけないから

3:32 AM

結構大丈夫な気がするんだよね

3:33 AM

データ構造は固定しがちだからそこが一番厳しそう

3:33 AM

まあでも大丈夫かどうかを人間が気にするのが複雑すぎて無理そうではあるな

コアチームのレビューが砦

3:35 AM

そういえば、KeyPathのランタイム実装が、2にあっても良さそうだけど何故か1にあるんですよね

SwiftとしてはConcurrencyが使えるけど、例えばSwiftUIのasyncなAPIを古いOS向けに出すのってきっと難しいんだよね？

Yuta Saito

そういえば、KeyPathのランタイム実装が、2にあっても良さそうだけど何故か1にあるんですよね

Swiftで実装されているけど他のランタイム関数と同じでパッチ可能なテーブルに乗ってない？

omochimetaru

Swiftで実装されているけど他のランタイム関数と同じでパッチ可能なテーブルに乗ってない？

あーどうだろう。実はRuntimrFunction.defに入ってたりするのかな

d_date

SwiftとしてはConcurrencyが使えるけど、例えばSwiftUIのasyncなAPIを古いOS向けに出すのってきっと難しいんだよね？

一つのモジュールに新しいAPIを足すのは難しそうですねぇ

3:39 AM

ObjCヘッダから自動変換するやつは使えそう

だよねぇ

https://github.com/apple/swift/blob/main/include/swift/Runtime/RuntimeFunctions.def#L1478

swift/RuntimeFunctions.def at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

3:42 AM

@Yuta Saito swift_geyKeyPath あったよ

それだ。じゃあ一応差し替えられるんですね

これSwift側でもこの名前になるように silgen_name かなんかついてなかったっけ

3:42 AM

むしろ昔家庭くんに教えてもらった気がするんだよな

3:43 AM

なので1と2の違いは実装言語は実は関係なくて(混ぜてリンクされるし) 単に RuntimeFunctions.def に掲載されるかどうかという事かな

そうそう。ランタイム関数の宣言はC呼び出し規約なのにsilgen_nameで実装してるからswiftccになってて規約違反してた

omochimetaru

なので1と2の違いは実装言語は実は関係なくて(混ぜてリンクされるし) 単に RuntimeFunctions.def に掲載されるかどうかという事かな

ですね

Yuta Saito

そうそう。ランタイム関数の宣言はC呼び出し規約なのにsilgen_nameで実装してるからswiftccになってて規約違反してた

あ〜 calling convention 関係か

3:44 AM

まあランタイム関数テーブルを経由するとオーバーヘッドもかかるし最適化阻害もあるから

3:45 AM

何を割り当てるかはやっぱり難しそう。

デザインセンスが問われる

APIデザインむづい

@Yuta Saito そういえば、stdlibのフックの仕組みはもっと前からあったけど、iOS13からのABI stableって何を意味してるの？

8:45 AM

ABI stableでないころに、フックが有効に機能するシナリオがよくわからない

ん、質問が難しい

えーっと

8:51 AM

stdlib hookの仕組みってそもそも、

8:51 AM

新しいSwiftでアプリをビルドした時に、実行環境のSwift Stdlibが古い時に、

8:51 AM

起動時にフックをロードして、実行環境のSwift Stdlibの挙動を新しいSwiftに合わせる仕組みでしょ？

はい

それが動作するって前提条件だったら、それってABI Stableとは違うのか？ってこと

8:52 AM

例えばもし、フックとは関係ない標準ライブラリの関数の仕様が変わってしまっているなら

8:53 AM

そもそもフック以前に、その部分の影響で動かせない

8:53 AM

フックが機能するってことは、フックできない部分も、古いstdlibバイナリが、新しいアプリと動的リンクできないとおかしい

フックの仕組みは5.0から入った機能じゃなかったでしたっけ

そうだと思う。あれ？iOS13が5.0？

そうそう

えっ

9:02 AM

iOS13ってすごい最近だけどSwift5って大昔じゃないっけ

Swift 5.0 は iOS 12から？

嘘だった

9:03 AM

じゃあ5.1でABI Stableかな

9:04 AM

どっちだっけ

hookの仕組みって __50 とかなかったっけ

Compatibility50があった

それそれ。

9:04 AM

Compatibility50があるiOS12でもいけそうな気がする

OSに入ってるんだっけ

Swift 5.1 は Module Stability らしい https://swift.org/blog/5-1-release-process/

Swift 5.1 Release Process

This post describes the goals, release process, and estimated schedule for Swift 5.1.

5.1のmodule stabilityは人々が使えるようになったやつで

9:06 AM

5.0のstdlibは先行して特別にstableじゃなかったっけ

9:06 AM

Dispatchとかにも依存しててそっちが駄目とかあるのかな

見つけた https://github.com/apple/swift/pull/25030

Introduce a backward-deployment library for SR-10600. by jckarter ...

Build a static archive that can be linked into executables and take advantage of the Swift runtime's hooking mechanism to work around the issue Doug fixed in #24759. The Swift 5.0 version o...

なんか俺がいる

いた

swift_conformsToProtocol を Swift5.0 向けにパッチを同梱出荷するようにした修正

じゃあ4.2のランタイムにくっつけるってことか？

これはcompat50だから、既に出荷した5.0ランタイムを

9:21 AM

swift5.1でビルドしたアプリを動かすために差し替える話じゃない？

ん、それはCompat51じゃないですかね

9:24 AM

ここ https://github.com/apple/swift/blob/4a058aee09fe00d8b9f9bc8bd288e0e8bcc91a20/lib/IRGen/GenDecl.cpp#L482-L506

omochimetaru

swift5.1でビルドしたアプリを動かすために差し替える話じゃない？

あ、逆か。これであってるのか。

9:26 AM

すみません

9:28 AM

Swift apps no longer include dynamically linked libraries for the Swift standard library and Swift SDK overlays in build variants for devices running iOS 12.2, watchOS 5.2, and tvOS 12.2.

https://developer.apple.com/documentation/xcode-release-notes/swift-5-release-notes-for-xcode-10_2 iOS 12.2から一応ランタイムはOSに入ってるっぽい

なるほど

9:29 AM

マイナーバージョンだからまあ13.0からって感じかな

https://github.com/waiwai-swiftc/waiwai-swiftc-ideas/issues/8

ランタイム関数の差し替え機能 · Issue #8 · waiwai-swiftc/waiwai-swiftc-ideas

Swiftにはランタイム関数を差し替える機能がある。これにより、新しいコンパイラでビルドした実行ファイルを、古いマシン環境で実行した場合でも、そのマシンに同根されている古いランタイムの挙動を新しいものに変える事で、実行ファイルの後方互換性をABIレベルで実現している。この差し替え関数は__swift51_hooksというセクションに登録されていて、実行時にロードされる。このあた...

5:58 PM

これ？

それ

https://iosdiscord.connpass.com/event/223396 今回のback deployment関連の話、今度わいわいswiftcでやることになったのでどうぞ～

わいわいswiftc #30 オンライン (2021/09/24 19:30〜)

# わいわいswiftc #30 オンライン昨今の社会的情勢を鑑みて、当面はオンライン開催を致します。 swift-developers-japanのDiscordサーバー上でオンライン配信を行う予定です。 Discordサーバーへはこちらのリンクから参加いただけます。 https://discord.gg/7RKD8dxBsm 本サーバーについて詳しく知りたい方は、下記をご覧ください。 https://medium.com/swift-column/discord-ios-20d586e373c0 # わいわいswiftc わいわいswiftcは、Swift Comp...

4

Concurrencyのback deployment、デフォで有効になったのか https://github.com/apple/swift/pull/39090

Enable concurrency back-deployment in the compiler by default. by D...

Remove the option that explicitly enables concurrency back-deployment, and instead always enable its support in the compiler. Remove the use of the extraneous CMake option as well.

2

https://forums.swift.org/t/pitch-distributed-actors/51669 https://github.com/apple/swift-sample-distributed-actors-transport

[Pitch] Distributed Actors

Hello everyone, With the recent introduction of Swift concurrency, and most notably actors to the language, Swift gained powerful and foundational building blocks for expressing thread-safe concurrent programs. This proposal aims to extend Swift's actors with the ability to work equally well for distributed systems thanks to the introduction of...

GitHub - apple/swift-sample-distributed-actors-transport: Distribut...

Distributed actors transport example, for feature review - GitHub - apple/swift-sample-distributed-actors-transport: Distributed actors transport example, for feature review

少しずつ読んでる

distributed actor の distributed func は、 actor の func が isolated な呼び出しのときに必ず async になるように、 isolated な呼び出しが必ず async throws になる事によって、通信が失敗する（ネットワークトラブル、リモートホストのクラッシュ）などの場合にエラーが飛ぶらしい。アクターじゃん。

2:12 AM

そして、distributed func の引数と返り値は、 Sendable である事に加えて、 Codable である事を要求されるらしい。良さそう。

想像してた感じになってて良い

2:13 AM

Akkaじゃん

ActorTransportの実装では、リモートホストにあるActorインスタンスのメソッドを呼出す場合のための実装として、 _receive_xxx という特別な名前のメソッドを @dynamicReplacement(for:) で注入するとかなんとか書いてあるんだけど、なんでそんなややこしい話になってるのかうまく読み解けなかった。

2:14 AM

また後日続きを読みます。

Yuta Saito

想像してた感じになってて良い

うむ。基本的な仕組みは、できそうだな〜と思ってたやつがそのまんま綺麗に実現できるってぽい。すごい。

さすがKonradさん

ネットワークアプリやマルチプロセスアプリを作る時に、自分でソケットやプロトコルを実装しなくても

2:18 AM

このアクター仕様の上に組めばかなり楽ができそうと感じた

2:19 AM

アクターを使うというより、アクターをプロトコルライブラリとして使えそう

omochimetaru

distributed actor の distributed func は、 actor の func が isolated な呼び出しのときに必ず async になるように、 isolated な呼び出しが必ず async throws になる事によって、通信が失敗する（ネットワークトラブル、リモートホストのクラッシュ）などの場合にエラーが飛ぶらしい。アクターじゃん。

Erlang の actor っぽい。

ですよね。

2:55 AM

2017年？のラトナードラフトがほぼそのまんま実現されていて

2:56 AM

Konradさんがこのために呼ばれた感がめっちゃする

長かったけど読み終わった

1:49 AM

distributed func は、ビルドするとローカル/リモート分岐するthunkにラップされて、実装したコードはローカル版の実装になり

1:49 AM

リモート版は _remote_<method name> というクラッシュするだけの関数になっていて (edited)

1:50 AM

これを dynamicReplacement で実装を入れ込むそうな

1:51 AM

ActorTransportライブラリが、SwiftPMのextension packageを使って、コード生成を行う事を想定していて

1:51 AM

これによって、distributedメソッドごとに、メッセージ生成と送信の処理を生成する

1:52 AM

なかなか派手な仕様だけど、

1:52 AM

たしかにSwiftの言語機能だと、メソッド呼び出しそれ自体を抽象化してフックする一級の仕組みは無いから

1:53 AM

とりあえずそうなったっぽい

なるほど。派手だ

提案読み終わったころにはフォーラムが伸びてたまだ少ししか見てないけど、Codableは遅いから微妙じゃない？って意見が気になった

Codable遅いんですか

まあ俺も遅いなーとは思ってる

2:07 AM

プロトコル呼び出しが多すぎてディスパッチオーバーヘッドが大きい感じがしてる

2:08 AM

サーバーサイド(vapor)で使っててもCodableの処理時間がちょっと多くてしぶい

エンコーダ/デコーダの問題なのかCodable自体の生成コードの問題なのか調べたいですね

そうね。本質的な問題がどこなのかはっきりわかっていない。

なんか昔測ったときはJSONSerializationのほうが2倍以上速かったですね

JSONSerializationは超早いんすよね。 JSONDecoder使うと文字列→JSON→SwiftType の 2段階の変換になっているけど、後段で前段の5倍ぐらい時間がかかるイメージ

JSONSerialization （というか NSJSONSerialization ）は NSDictionary とか NSArray 使うけど、最初から Swift ネイティブな Dictionary や Array を使ってくれたらもっと速くなりそう。今、遅い原因で支配的なのは Codable の方だろうけど。

https://github.com/apple/swift-corelibs-foundation/blob/main/Sources/Foundation/NSArray.swift

swift-corelibs-foundation/NSArray.swift at main · apple/swift-corel...

The Foundation Project, providing core utilities, internationalization, and OS independence - swift-corelibs-foundation/NSArray.swift at main · apple/swift-corelibs-foundation

2:48 AM

気になって見てみたらlinuxだとNSArrayがArray<AnyObject>で実装されてるんだな

NSNumber とかでボクシングされるのも辛い。

nsnumberは小さい整数ならtagged pointerになるからヒープ確保はしないですけどね

3:16 AM

余計なオーバーヘッドはありますね

omochimetaru

nsnumberは小さい整数ならtagged pointerになるからヒープ確保はしないですけどね

そうなんだ。これは知らなかった。

distributed actorのフォーラム書き込みを読んだ

2:19 AM

Douglasさんのツッコミで

2:20 AM

distributed func 指定子いらなくない？というのが一番おもしろかった

2:21 AM

Actorのメソッドはアクターの外からasyncとして呼べるように Distributed Actorのメソッドはasync throwsとして呼べるでいいじゃんと

2:21 AM

protocolの distributed func エントリもなくして、 async throws なら呼べるで良い

読んでないけど、 async throws に加えて Distributed Actor のメソッドに渡せる／返せるものは Sendable の代わりに Codable という制約があればいいのかな？参照型でもコピーになるし。 Codable は理想的な実装になったとしても無駄が多そうだから（キーを焼き込まないといけないので）、 Serializable みたいなものがあった方が良さそう？

CodableでもUnkeyedコンテナ使えば無駄なくできそうだなと思いましたが、デフォルト実装が無いのが辛いですね

koher

読んでないけど、 async throws に加えて Distributed Actor のメソッドに渡せる／返せるものは Sendable の代わりに Codable という制約があればいいのかな？参照型でもコピーになるし。 Codable は理想的な実装になったとしても無駄が多そうだから（キーを焼き込まないといけないので）、 Serializable みたいなものがあった方が良さそう？

提案はそうなってますね

1:38 AM

ドーグさんが、プロトコルはCodableだと広すぎるからトランスポート側で指定できる方がいいんちゃうって指摘していて

1:39 AM

コンラッドさんが、Codableは楽ちんなデフォルトだといいんじゃないか、とか言ってた

Yuta Saito

CodableでもUnkeyedコンテナ使えば無駄なくできそうだなと思いましたが、デフォルト実装が無いのが辛いですね

なるほど、たしかに。 Serializable でもデフォルト実装ないと辛いですね。

1:44 AM

UnkeyedEncodingContainer って JSON にしたらどうなるのかよくわかってなかったけど↓こうなるのか。 @swift-5.4.3

import Foundation struct Foo { var a: Int var b: String var c: Bool } extension Foo: Encodable { func encode(to encoder: Encoder) throws { var container = encoder.unkeyedContainer() try container.encode(a) try container.encode(b) try container.encode(c) } } let original: Foo = .init(a: 42, b: "xyz", c: true) let encoded = try! JSONEncoder().encode(original) print(String(data: encoded, encoding: .utf8)!)

[42,"xyz",true]

そうですよ上方互換性が取りにくい

Unkeyed でなくても SerializationEncoder みたいなのを作るときに、キーをソートしてからバイト列に変換するとかすればキーは省略できるかな？スキップされたOptionalなキーはスキップの印だけ入れて。

新しいバージョンでフィールドが増えているときに、古いペイロードパケットが読めなくなります

1:50 AM

Distributed Actorを使う状況で、全てのノードが同時に最新版をデプロイできるものなのかどうか。

1:51 AM

暗号通貨ネットワークみたいな分散P2Pシステムを作るんだったら、

1:51 AM

ノードごとにバイナリバージョンがズレてることはあるのかも

1:51 AM

対戦ゲームみたいなアプリだったら、揃ってそうだからそういう方法もありですね

新しいバージョンでフィールドが増えているときに、古いペイロードパケットが読めなくなります

これは思ったんだけど、結局リネームされたとかだと対応できないわけだし程度問題かなと。で、

全てのノードが同時に最新版をデプロイできる

を前提とする（か、フォーマットが変わらない範囲のアップデートのみ許容する）のは仕方ないのかなぁと。

一般系には対応できないですが追加だけなら大丈夫なので人間が意識するやつですね。（もしくは、機械的にチェックするか

1:55 AM

Unkeyedでも、末尾への追加しかしなければ追加はできます。

1:55 AM

「キーでソートする」があると追加位置が名前次第で真ん中になるのでindexがズレちゃう。 (edited)

Codable 限定だと JSON には Keyed で書き出したいけど Distributed Actor でやり取りする場合には Unkeyed で最適化したいみたいなのができないから辛いかなと思ったけどどうだろう？シリアライズするエンコーダががんばるにしても、 distributed なコンテクストにエンコーダ指定できるとかないければ、結局エンコーダをどう実装するか（キーを残すのか残さないのか）の二者択一になって、

暗号通貨ネットワークみたいな分散P2Pシステムを作るんだったら、ノードごとにバイナリバージョンがズレてることはあるのかも

と

対戦ゲームみたいなアプリだったら、揃ってそう

の両者に最適化できない。

ああなるほど

それでいうと Codable もすでに破綻してるのかな？サーバーAにはA用のフォーマットで、サーバーBにはB用のフォーマットでエンコード／デコードしたいとかはできないわけだし、やり取り用の専用の型を間に噛ますしかない。 (edited)

Unkeyedだと自動生成もなくてしんどいからEncoder側でキーを消すということか (edited)

omochimetaru

Unkeyedだと自動生成もなくてしんどいからEncoder側でキーを消すということか (edited)

そうそう。でもやりとりするサイズは小さくできるけど、エンコード／デコードがますます遅くなりそう。

distributed なコンテクストにエンコーダ指定できるとかないければ

Actor Transportオブジェクトがシリアライズは全責任を持つので、Codable依存は無いですね

2:02 AM

そういえばそこちょっと変だな

2:03 AM

Codableを実際に使用するかどうかはActorTransport実装依存なのに、言語としてはCodableであることを常にチェックするのか

omochimetaru

distributed なコンテクストにエンコーダ指定できるとかないければ

Actor Transportオブジェクトがシリアライズは全責任を持つので、Codable依存は無いですね

なるほど。そろそろ想像してる内容と現実がずれてきてそうだから、ちゃんと読んでから話します。

1

僕も提案とフォーラムは目を通したから後はサンプル実装を読まなきゃ。

アプリケーションの方のサンプル実装のトランスポート生成器の実装は、 (edited)

5:44 AM

ソースコードと完全に対応した手動定義された生成結果を埋め込んでるだけの嘘だった

5:44 AM

https://github.com/apple/swift-sample-distributed-actors-transport/blob/main/FishyTransport/Sources/FishyActorsGenerator/SourceGen.swift#L130

w

5:45 AM

やればできる。あとはやるだけ (edited)

Fishy: 怪しい、いかがわしい、うさんくさい、魚の、魚の多い、魚からなる、魚のような、生臭い、どんよりした、無表情の ↑調べて納得した

そういことか

まあ、実際に生成されてるのはどういうコードなのかが、テキストとして見られる状態のほうが、仕様を理解する上では助かるね。

https://forums.swift.org/t/precise-error-typing-in-swift/52045

Precise error typing in Swift

Introduction When error handling was added to Swift in 2015, it intentionally did not allow the expression of precise error types: either a function cannot throw, or it can throw any Error. The error-handling rationale I wrote, which uses an awful lot of words to describe most aspects of the design, gives this one pretty short shrift: There ar...

11:11 AM

エラーの型についての議論が投稿された

やっぱUnion型に踏み込まないといけないよね

まだ読んでない

真ん中ぐらいにType combinatorsで議論がある typed Errorの実装はuntaggedなUnion型とのセットだから、やっぱハードルがクソ高いよなと思う

読んだけど、John McCallさんの英語はやはり難しい・・・

12:34 PM

ローレベルなライブラリで、パフォーマンスと正確性のために使いたい場合と、ジェネリクスと組み合わせたいケースのために必要だから機能は足すべきだけど、一般的なコードではやらないほうが良い、解決する問題より、複雑になって持ち込まれる問題のほうが多い、というような意見に見えた

12:34 PM

errorUnionの議論のくだりは結局これをやるべきと言ってるのかやらんべきと言ってるのかわからず。

12:35 PM

下層のエラーを合成するようなケースは Swift.Error にアップキャストしてまとめちゃうのが良いと言っている・・・？

ローレベルなライブラリで、パフォーマンスと正確性のために使いたい場合

今は全部 Existential だからパフォーマンス悪いのか。

そうですね。ダブルポインタにlowerされてる(しかも専用レジスタに割り当てられる)から、ダイナミックアロケーションは無いんだけど、それでもオーバーヘッドはあるみたいな事が書いてあるような・・・

まだdraftですが...back deploymentのrelease/5.5へのPRが出てますね https://github.com/apple/swift/pull/39342 (edited)

Back-deploy concurrency by DougGregor · Pull Request #39342 · apple...

Back-deployment support for Swift concurrency.

おー

1

12:50 PM

なんかややこしそうな事もしてる (edited)

うわぁそうしたか

どういうこと？

ウィークリンク

weak_import

本物のランタイムがある時にシンボルがコンフリクトするのを回避するためのハック

ふむふむ

あいや、weak_importは元々あったやつか

1:03 PM

別ファイルから移動してきただけっぽい

1:09 PM

詳しいことは来週の金曜日までにまとめよう…

4

まとめに期待

やばいそのbackdeployの話がすごい気になって今度のわいわい参加しようと思ったら、見事にメルカリさんのiOSDCアフターイベントとかぶってしまった

どうしよう

さっきkoherさんのAsk the speakerの時に話に出ていたResultのinit async、こんな感じですかね？

https://forums.swift.org/t/swift-concurrency-feedback-wanted/49336/105 (edited)

Swift Concurrency: Feedback Wanted!

Result could be extended with an async initialiser — something like this: extension Result where Failure == Error { init(awaiting task: () async throws -> Success) async { do { self = .success(try await task()) } catch { self = .failure(error) } } } self.taskHandle = async { self.result = await Result { try aw...

2

lovee

やばいそのbackdeployの話がすごい気になって今度のわいわい参加しようと思ったら、見事にメルカリさんのiOSDCアフターイベントとかぶってしまった

どうしよう

ワイワイは録画もあるよ

1

shiz

さっきkoherさんのAsk the speakerの時に話に出ていたResultのinit async、こんな感じですかね？

https://forums.swift.org/t/swift-concurrency-feedback-wanted/49336/105 (edited)

まさにそれですね

1

どこかで見たなーと思い気になって探しましたw (edited)

@swift-5.5.3

import Foundation class C {} _ = AsyncStream(String.self) { continuation in let c = C() continuation.onTermination = { print("\(c)") } } _ = AsyncStream(String.self) { continuation in let c = C() let cushion: @Sendable (AsyncStream<String>.Continuation.Termination) -> Void = { _ in print("\(c)") } continuation.onTermination = cushion }

(edited)

Iceman

@swift-5.5.3

import Foundation class C {} _ = AsyncStream(String.self) { continuation in let c = C() continuation.onTermination = { print("\(c)") } } _ = AsyncStream(String.self) { continuation in let c = C() let cushion: @Sendable (AsyncStream<String>.Continuation.Termination) -> Void = { _ in print("\(c)") } continuation.onTermination = cushion }

(edited)

exit status: 1 with stderr:

<stdin>:7:30: error: converting non-concurrent function value to '@Sendable (AsyncStream<String>.Continuation.Termination) -> Void' may introduce data races continuation.onTermination = { ^

(edited)

swift55

exit status: 1 with stderr:

<stdin>:7:30: error: converting non-concurrent function value to '@Sendable (AsyncStream<String>.Continuation.Termination) -> Void' may introduce data races continuation.onTermination = { ^

(edited)

onTermination に差し込むクロージャが Sendableにならないっぽくて困ってるのですが何かわかるかたいますか？クッション挟むといけてて謎。（しかもc はsendableじゃないし）

https://swift.org/blog/swift-5-5-released/

Swift 5.5 Released!

Swift 5.5 is now officially released! Swift 5.5 is a massive release, which includes newly introduced language capabilities for concurrency, including async/await, structured concurrency, and Actors. My heartfelt thanks to the entire Swift community for all the active discussion, review, and iteration on the concurrency (and other additions) t...

1

Iceman

onTermination に差し込むクロージャが Sendableにならないっぽくて困ってるのですが何かわかるかたいますか？クッション挟むといけてて謎。（しかもc はsendableじゃないし）

continuation.onTermination = { @Sendable _ inでどうでしょうか？

（しかもc はsendableじゃないし）

以前mainに追加されたSendableチェックがrelease/5.5にまだ入ってないんですよね。mainでやるとwarningが出ます(5.5に入らないんですかね？)

(edited)

shiz

continuation.onTermination = { @Sendable _ inでどうでしょうか？

（しかもc はsendableじゃないし）

以前mainに追加されたSendableチェックがrelease/5.5にまだ入ってないんですよね。mainでやるとwarningが出ます(5.5に入らないんですかね？)

(edited)

お〜これでいけました！ここに @Sendable つけるんですね

5:48 AM

Sendableチェックはまだ全部じゃなかったんですね

Iceman

お〜これでいけました！ここに @Sendable つけるんですね

以前同じところでハマって↓を見て「そうなんだ」って思ったことを思い出しましたw https://forums.swift.org/t/asyncstream-and-progress-reporting/50588/7 Sendableチェックは↓に向けて色々変わっているみたいですね。そしてプロポーザル通りにチェックされないところもあって僕もまだよくわかってない状態です

https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341

AsyncStream and progress reporting

I get it now. The onTermination closure needs to be annotated with @Sendable: continuation.onTermination = { @Sendable termination in … }

[Pitch] Staging in Sendable checking

Hi all! SE-0302 introduced the Sendable protocol, which is used to indicate which types have values that can safely be copied across actors or, more generally, into any context where a copy of the value might be used concurrently with the original. Applied uniformly to all Swift code, Sendable checking eliminates a large class of data races cau...

Task 作ったときにactorが引き継がれるのってどういう条件なんですか。async/await 外のコールバックの中で Task 作っても引き継がれるとは思ってなかった

https://zenn.dev/link/comments/6d69e9523300b4

Swift Concurrency チートシート

外側がアクター世界だと引き継がれますね大半はMainActorなんじゃないだろうか

WWDCのセッションに何が引き継がれるかのチートシートがあったはず

1:34 AM

どれだっけな

1:36 AM

あった。Joe Groff先生が教えてくれるやつ https://developer.apple.com/videos/play/wwdc2021/10134/

Explore structured concurrency in Swift - WWDC21 - Videos - Apple D...

When you have code that needs to run at the same time as other code, it's important to choose the right tool for the job. We'll take you...

1

1:37 AM

26分くらいのところに多分知りたいスライドがあります

1

YouTube みたいにタイムスタンプでリンクできたらいいのにな (edited)

きっとフルで見てもらうためにわざと…

2

Yuta Saito

26分くらいのところに多分知りたいスライドがあります

おお！見てみます！ありがとうございます！これみてなかった（みてないのいろいろある）

1

1:50 AM

いや、これは見たことあるなw

hironytic

Task 作ったときにactorが引き継がれるのってどういう条件なんですか。async/await 外のコールバックの中で Task 作っても引き継がれるとは思ってなかった

https://zenn.dev/link/comments/6d69e9523300b4

tarunon さんの言うように、外側が actor の世界だとその actor が引き継がれる認識です。 Task.detached だと context を引き継がないので、 @MainActor な API から呼び出しても MainActor の世界にならないです。

niw

YouTube みたいにタイムスタンプでリンクできたらいいのにな (edited)

秒でカウントしたタイムスタンプ付きでリンクできそう https://developer.apple.com/videos/play/wwdc2021/10134/?time=1585

Explore structured concurrency in Swift - WWDC21 - Videos - Apple D...

When you have code that needs to run at the same time as other code, it's important to choose the right tool for the job. We'll take you...

1

おー

外側というのは、スコープの外側って感じなんですかね。実行時のスタックとは無関係で。

これかな。 https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#actor-context-propagation

swift-evolution/0304-structured-concurrency.md at main · apple/swif...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0304-structured-concurrency.md at main · apple/swift-evolution

hironytic

秒でカウントしたタイムスタンプ付きでリンクできそう https://developer.apple.com/videos/play/wwdc2021/10134/?time=1585

そうでした。たしか Transcript をクリックすると、その time 付きリンクに飛ぶんですよね。

@_inheritActorContext がActor引き継ぎマークっぽいですね。 Task.initにだけ付いてる

https://github.com/apple/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md#_inheritactorcontext

2

actorのメソッドの中で作られたTaskには引き継がれる認識があったけど、actorのメソッド内で作ったクロージャーの中で作ったTaskに引き継がれるとは思ってなかったんですよね。思い込みで。

Yuta Saito

@_inheritActorContext がActor引き継ぎマークっぽいですね。 Task.initにだけ付いてる

https://github.com/apple/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md#_inheritactorcontext

@_implicitSelfCapture に続いてｗ

hironytic

秒でカウントしたタイムスタンプ付きでリンクできそう https://developer.apple.com/videos/play/wwdc2021/10134/?time=1585

知見...!

hironytic

actorのメソッドの中で作られたTaskには引き継がれる認識があったけど、actorのメソッド内で作ったクロージャーの中で作ったTaskに引き継がれるとは思ってなかったんですよね。思い込みで。

この前自分の発表聞きながらよくわからなくなったのは、↓の sink の中が MainActor 上と判定されるのはなんでだろう？ということですね。もしかしたら、ひろんさんもこのことを言ってる？（ Task が出てきてないから違う？）

state .objectWillChange .receive(on: DispatchQueue.main) .sink { [self] _ in // state を View に反映する処理 nameLabel.text = state.user?.name } .store(in: &cancellables)

どこかで、 Task.init はできるだけコンテクストを推定するみたいなのを読んだ気がしていて、 DispatchQueue.main から推定されている？

そうそうそれを言ってます。

2:08 AM

あ違う。sink の中がじゃないや、 sink の中で Task を作った中が、というのがぼくの言ってるやつ。

2:11 AM

うん？やっぱり同じことを言ってる？つまり、 sink の中は（ receive(on:) してなかったら）メインスレッドで動く保証はないと思ってた（実際どうなんだろう

）んだけど、そこから作った Task には @MainActor が効いてくるのかと思って。

2:13 AM

ちなみに、ViewControllerの外側にグローバル関数作っておいて、その中から Task を作るようにして、この sink の中でそのグローバル関数を呼んでも、その Task 内（の、await後）はメインスレッドで動いていなかった。そりゃそうだろなとは思いましたが。

2:18 AM

だからやっぱり、スコープの外側っていう言い方が合ってるかどうかわからないけど、例えば private 変数にアクセスできるかどうかと同じような感じで、実行時のコンテキストには関係なくて、コードの外側にある actor が引き継がれるのかなという結論に落ち着きつつあります。

Marks that a @Sendable async closure argument should inherit the actor context based on the declaration site of the closure.

なのでひろんさんの認識であってると思います

koher

この前自分の発表聞きながらよくわからなくなったのは、↓の sink の中が MainActor 上と判定されるのはなんでだろう？ということですね。もしかしたら、ひろんさんもこのことを言ってる？（ Task が出てきてないから違う？）

state .objectWillChange .receive(on: DispatchQueue.main) .sink { [self] _ in // state を View に反映する処理 nameLabel.text = state.user?.name } .store(in: &cancellables)

どこかで、 Task.init はできるだけコンテクストを推定するみたいなのを読んだ気がしていて、 DispatchQueue.main から推定されている？

ちなみに sink の中って MainActor 上で実行されるんでしょうか？だとしたら、 reveive(on: DispatchQueue.main) を消しても大丈夫？

2:34 AM

いや、 receive(on:) を消したら、sink の中はメインスレッドとは限らなかった (edited)

hironytic

ちなみに sink の中って MainActor 上で実行されるんでしょうか？だとしたら、 reveive(on: DispatchQueue.main) を消しても大丈夫？

まず、 receive(on: DispatchQueue.main) した上でだと sink の中はメインスレッド上で実行されるので（そして MainActor は DispatchQueue.main を使うので、事実上 MainActor に守られているのと同じだと思います。で、わかっていることは、その sink の中に書いたコードは MainActor 上と判定されるようです（ MainActor に isolate された API を同期的に呼び出せるので）。

そうですね。

2:39 AM

面白いのは、 receive(on: DispatchQueue.main) を外したら、 sink の中はメインスレッドとは限らないけど、その sink の中で Task を作ったら、そこに渡したクロージャの中はメインスレッドになる。

2:41 AM

DispatchQueue.main が事実上 MainActor と同じだというのは当然だけど、なんでコンパイラはそれがわかるんだろう

あー、sinkのActorではなくその更に外のVCのActorを継承してるんですかね

で、 Case 20 であればそもそも state が @MainActor なので receive(on: DispatchQueue.main) しなくても sink はメインスレッド上なんですが、 receive(on: DispatchQueue.main) しているのは別の事情で、 objectWillChange なのでそのまま購読すると will なのでまだ変更が反映されてないんです。

2:42 AM

did change な状態にするために 1 サイクル遅らせたくて入れている。

Yuta Saito

あー、sinkのActorではなくその更に外のVCのActorを継承してるんですかね

これがよくわかんなくて、その外の VC の Actor を継承とかできるんですっけ？たとえば、 receive(on: DispatchQueue.global()) する場合とか考えると変なような。

Yuta Saito

あー、sinkのActorではなくその更に外のVCのActorを継承してるんですかね

そうそう、だから sink （をコールする側の） actor が引き継がれるんじゃなくて、ソース上で Task 生成を囲んでいる actor が引き継がれるのかなと。

receive(on: DispatchQueue.global()) を挟んだ場合でも、 sink に渡すクロージャが再度 MainActor に投入される？

koher

receive(on: DispatchQueue.global()) を挟んだ場合でも、 sink に渡すクロージャが再度 MainActor に投入される？

Yes！

試してみると、コンパイルは通るけど実行時に↓でした。 UILabel.text must be used from main thread only

ん？違う

ですね。

2:47 AM

コンパイラは MainActor に投入されると判断してるけど、実際の挙動はそうなってない？

↓これで、ViewController 1 は別スレッドで、2と3はメインスレッドで呼ばれます。

state .objectWillChange .receive(on: DispatchQueue.global()) .sink { [weak self] _ in guard let self = self else { return } printIsMainThread("ViewController 1") Task { printIsMainThread("ViewController 2") _ = await self.state.user printIsMainThread("ViewController 3") } } .store(in: &cancellables)

ええ…

2:48 AM

なんでだろ。Taskの中で同期で呼べば、静的に決まってるActorにホップした状態で実行されるはずなのに。

hironytic

↓これで、ViewController 1 は別スレッドで、2と3はメインスレッドで呼ばれます。

state .objectWillChange .receive(on: DispatchQueue.global()) .sink { [weak self] _ in guard let self = self else { return } printIsMainThread("ViewController 1") Task { printIsMainThread("ViewController 2") _ = await self.state.user printIsMainThread("ViewController 3") } } .store(in: &cancellables)

なるほど・・・。その 2, 3 はメインスレッドになるのか。

koher

試してみると、コンパイルは通るけど実行時に↓でした。 UILabel.text must be used from main thread only

これはTask.initのクロージャの中でUILabel操作したときですか？

僕が試したのは↓ですね。

state .objectWillChange .receive(on: DispatchQueue.global()) .sink { [self] _ in nameLabel.text = state.user?.name // UILabel.text must be used from main thread only } .store(in: &cancellables)

ああ、それはダメですね

これはコンパイル時に検出はできない？？

2:50 AM

これまでも書けたコードだから無理か。 (edited)

UILabelにアクターの保護が付いていれば検出できるのかなぁ

この場合に、ひろんさんが試した場合に sink の中に Task を書いたら MainActor 上になるというのがよくわからなくて、 sink に渡すクロージャをクロージャ式じゃなくて別の場所に宣言したグローバル関数だとどうなるんでしょう？

2:52 AM

ちなみに、ViewControllerの外側にグローバル関数作っておいて、その中から Task を作るようにして、この sink の中でそのグローバル関数を呼んでも、その Task 内（の、await後）はメインスレッドで動いていなかった。そりゃそうだろなとは思いましたが。だ

これか。

func outerFunc(state: UserViewState) { printIsMainThread("outerFunc 1") Task { printIsMainThread("outerFunc 2") _ = await state.user printIsMainThread("outerFunc 3") } } class ViewController: UIViewController { ... state .objectWillChange .receive(on: DispatchQueue.global()) .sink { [weak self] _ in guard let self = self else { return } outerFunc(state: self.state) printIsMainThread("ViewController 1") Task { printIsMainThread("ViewController 2") _ = await self.state.user printIsMainThread("ViewController 3") } } .store(in: &cancellables) ... }

2:52 AM

これだと、outerFunc 1〜3は全部別スレッドから

なるほど。 .receive(on: DispatchQueue.main) だと outerFunc でもメインスレッド？

2:54 AM

あれ？今気づいたけどこれ僕のコード sink で [self] になってるのミスってますね。

mainだと、outerFunc 1はメインスレッド。outerFunc 2と3は別スレッドです。

非同期単発で [self] 書きまくってたのにつられてて [weak self] じゃないといけないところまで [self] になってる。

あえて目立つようにキャプチャーしてるのかと思ってたw ＞ [self]

hironytic

mainだと、outerFunc 1はメインスレッド。outerFunc 2と3は別スレッドです。

えー、そうなんですね。じゃあメインスレッド上で実行されていることから推定して context を引き継ぐんじゃなくて、 @MainActor な API の中に書かれたクロージャ式であることが重要なのか。

だと思います。実行時のコンテキストを引き継ぐんではなくて、Task を作るコードを書いたところがどのアクターの中にあるかなんだと思います。

それちょっと気持ち悪いですね・・・。

それが、private なメンバにアクセスできるかどうか、というのに似てるなと。

クロージャ式で書いていたコードを切り出して関数にしたら挙動が変わるということですよね・・・。

そうです。リファクタリングするとき危険です。

それが、private なメンバにアクセスできるかどうか、というのに似てるなと。

outerFunc でなく同じインスタンスのメソッドだと？

3:00 AM

そもそも MainActor か。

同じインスタンスのメソッドなら大丈夫じゃないかな。

3:00 AM

はい、そもそも MainActor だから。

Task に渡すクロージャは基本的にメンバーにアクセスしたいはずで、そう考えると問題ないのかなぁ。 (edited)

3:01 AM

そんなことないか？

3:02 AM

Task から思い非同期タスクを発火して結果を返したいこととかもあるか。

3:02 AM

いや、でもクロージャの中でメンバにアクセスして結果を戻さないなら、どこで実行されようが同じだし、メンバにアクセスするならクロージャ式か同じインスタンスのメソッドになるか。

sink の中で作ったTask の中で ViewController の private メンバにはアクセスできるけど、outerFunc の中では private メンバには当然アクセスできない。これと同じことだとは思うので、まあ、自分的には納得しました。

3:04 AM

今回みたいに、outerFunc にメンバを引数で渡すようするようなリファクタリングをしてしまうと、事故りますねw (edited)

outerFunc、@MainActor がついてないからそれだけでかなり怖い存在になってるの感

hironytic

今回みたいに、outerFunc にメンバを引数で渡すようするようなリファクタリングをしてしまうと、事故りますねw (edited)

self.state は actor isolated だからそれ自体は問題ない？

actor A と actor B で全く同じ処理してるやんー、ってことで、そこを共通メソッドに切り出して、ああ、メンバがとれないから引数で渡すようにして・・・ってやれば事故を起こせそう

hironytic

actor A と actor B で全く同じ処理してるやんー、ってことで、そこを共通メソッドに切り出して、ああ、メンバがとれないから引数で渡すようにして・・・ってやれば事故を起こせそう

事故を起こせそうだけど、切り出した処理の中から Task のイニシャライザを呼びたいケースが限定的な気はします。

3:12 AM

というか、そもそも Task にそのメンバを渡せない？ @Sendable でひっかかる？

3:13 AM

逆にメンバが Sendable なら事故らない？

koher

というか、そもそも Task にそのメンバを渡せない？ @Sendable でひっかかる？

これはどういう意味です？今回のぼくの例のように outerFunc の中の Task に state を渡すことはできます。

3:14 AM

state自体はstateのアクターで保護されてるけど、Task の中の処理が actor A と actor B で保護されないという感じか。

hironytic

これはどういう意味です？今回のぼくの例のように outerFunc の中の Task に state を渡すことはできます。

state は actor だから state 自体は破壊できないし、前後の処理が VC のメンバにアクセスするならそれも isolated じゃないといけないし、そうでなければどこで実行されても大差ない？

呼び出し先がactorになっていれば、「あれ？なんでここでawait呼ばないといけないんだ？」ってなる一方、まだactorになっていないものをメインスレッドだと思い込んで呼ぶと事故が起きる、ということかな？と思いました。

Task.init に渡すクロージャは @Sendable なので壊せるようなものを渡そうとすること自体ができない？

3:21 AM

なんかよくわからなくなってきた。 UIView って @MainActor なのになんでさっきの nameLable.text = で UILabel.text must be used from main thread only になったんだっけ？？ https://developer.apple.com/documentation/uikit/uiview

3:22 AM

ちょっと用事で離脱します・・・。 (edited)

~~クロージャーの中身は、そのクロージャーを呼び出したスレッドから同期的に実行されるから・・・ですかね。~~ (edited)

3:23 AM

~~sink に渡すクロージャーは sendable でもなんでもないので。~~ (edited)

3:27 AM

まあ、そもそも Task 関係なく、別の actor の中の処理を、共通だからって切り出そうと考えることが愚かな行為か・・・

3:31 AM

ただ、基底クラスの UIViewController が @MainActor だから、自分では意識せず @MainActor になっていて、アクターが違うとか考えずに切り出すと、今まで意識することなくメインスレッドで動いていた Task の中身が、切り出したら別スレッドで実行されることがあるようになるということか。（ぼくも離脱します）

koher

なんかよくわからなくなってきた。 UIView って @MainActor なのになんでさっきの nameLable.text = で UILabel.text must be used from main thread only になったんだっけ？？ https://developer.apple.com/documentation/uikit/uiview

僕もこれずっと気になってます

↓も似た質問なのかなと思っていて、このやり取りで直ったと言っているのですが、RC以降でも引っかかりますね(僕の勘違いで全然関係ない話かもしれないですが...) そもそもawait付けないでアクセスできるのがおかしいのか...？DispatchQueueと混ざっているのが問題なのか...？構文上はMainActorに見えるので、receiveでThreadが切り替わっていることがわからない…？すいません書いてたらよくわからなくなってきました

https://forums.swift.org/t/await-in-async-function-isolated-to-mainactor-resumes-on-non-main-thread-bug/51957/2 https://github.com/apple/swift/pull/38768 (edited)

このコミットで@escapingクロージャに対するactor-isolationの制約が無効になって、escapingクロージャが定義位置のアクターを引き継ぐようになったようです。 non-escapingであれば、関数の脱出までに寿命が尽きるので、スレッドを跨ぐことはないので、アクターを引き継ぐ仮定は正しいです。 escapingではこの仮定は明らかに安全ではないんですが、既存のコードを壊さないための妥協として5.5に入ってるそうです。 https://github.com/apple/swift/commit/5ecb9ebec2168582e0197453ba06b7d556e680fd で、Combineのsinkは、渡したクロージャの実行スレッドがreceiveで変わってしまうので、まさにその安全でないケースだった、ということだと思います。 (edited)

3

koher

なんかよくわからなくなってきた。 UIView って @MainActor なのになんでさっきの nameLable.text = で UILabel.text must be used from main thread only になったんだっけ？？ https://developer.apple.com/documentation/uikit/uiview

なので、現状のコンパイラのactor-isolated判定がゆるく、sinkに渡したクロージャが呼び出し元のMainActor-isolatedを引き継いだため、MainActorでisolatedされているUILabelへの代入がawait無しでできた。しかし実際はスレッドが変わっているのでisolatedではなく、実行時に怒られる。ということではないですかね。 (edited)

2

既存のコードを壊さないための妥協

警告が出るようになってくれたら安心だね。できるだろうか (edited)

Swift 6では壊れるんですが、そのための準備として警告を出すモードがあって、

8:35 AM

-warn-concurrency フラグを付けるとSwift 6で違法になるコードにワーニングを出してくれるんですが、なんかこのケースは動いてないっぽい…

1

ありがとうございます！なるほど現状チェックされないケースがあるんですね。

-warn-concurrency フラグを付けるとSwift 6で違法になるコードにワーニングを出してくれるんですが、なんかこのケースは動いてないっぽい… 

僕もさっきmainリポジトリのsnapshotで同じこと試したのですが、警告も何も出てこなかったですね... (edited)

1

なんか忘れられてそうなのでチケット作りました。https://bugs.swift.org/browse/SR-15235

5

Yuta Saito

なので、現状のコンパイラのactor-isolated判定がゆるく、sinkに渡したクロージャが呼び出し元のMainActor-isolatedを引き継いだため、MainActorでisolatedされているUILabelへの代入がawait無しでできた。しかし実際はスレッドが変わっているのでisolatedではなく、実行時に怒られる。ということではないですかね。 (edited)

よく考えたらsetterだからasyncにできないし、nonisolatedなんでしょうか？setterだけnonisolatedとかできるのかわからないですが。元がObj-Cだし、余計複雑？nonisolatedじゃなくて、MainActorの外からsetterが見えないのが正解？

setterの場合は foo.bar = await .... になるのでは？と思ったが果たして

プロパティのエフェクトはgetだけ

そうか、セッタか

理論上setter側で止めたいとしても、それは値を渡す側で待ち受けるんじゃないかってことですね

10:57 AM

今の状態だとsetterに副作用とか紛れ込ませて違法コンカレンシーやりたい放題だな…

更新処理を関数に出してもawaitなしで関数呼び出しできますね(チェックしてないのでそうなんですが...) nameLabel にアクセスしているところでこういう感じのエラー(警告)が出て欲しいです (edited)

shiz

更新処理を関数に出してもawaitなしで関数呼び出しできますね(チェックしてないのでそうなんですが...) nameLabel にアクセスしているところでこういう感じのエラー(警告)が出て欲しいです (edited)

出てほしいですよね。ただ、エラーにしてしまうと既存コードが軒並み通らなくなるから厳しい？警告が限界でしょうか。

1:36 PM

Concurrency 的に正しいコードは↓のようになるんでしょうか。

state .objectWillChange .sink { [weak self] _ in guard let self = self else { return } Task { await MainActor.run { // state を View に反映する処理 self.nameLabel.text = self.state.user?.name } } } .store(in: &cancellables)

1:39 PM

Task と MainActor.run を統合したい（ Task にイニシャライザに Actor の context を明示的に渡したい）なぁ。

1:42 PM

本当にほしいのは、 ObservableObject が actor の場合は、その actor に isolate された状態で購読する手段か。

koher

出てほしいですよね。ただ、エラーにしてしまうと既存コードが軒並み通らなくなるから厳しい？警告が限界でしょうか。

> 出てほしいですよね。ただ、エラーにしてしまうと既存コードが軒並み通らなくなるから厳しい？警告が限界でしょうか。

今のSwift Coreチーム(Dougさん？)の考えだと、Swift5.X + -warn-concurrencyフラグで警告、Swift6にしたらエラーという流れになる感じなのかなと僕は思ってます。

Concurrency 的に正しいコードは↓のようになるんでしょうか。

どんな状況でもMainActorで呼び出したい場合はそうなるのかなと思ってます。ただ今回のケースだとUILabelを扱うのがUIViewControllerの中以外だとないのかなと思っており、MainActor.runは必要ないのではと思いました(どうなんでしょう？)

shiz

> 出てほしいですよね。ただ、エラーにしてしまうと既存コードが軒並み通らなくなるから厳しい？警告が限界でしょうか。

今のSwift Coreチーム(Dougさん？)の考えだと、Swift5.X + -warn-concurrencyフラグで警告、Swift6にしたらエラーという流れになる感じなのかなと僕は思ってます。

Concurrency 的に正しいコードは↓のようになるんでしょうか。

どんな状況でもMainActorで呼び出したい場合はそうなるのかなと思ってます。ただ今回のケースだとUILabelを扱うのがUIViewControllerの中以外だとないのかなと思っており、MainActor.runは必要ないのではと思いました(どうなんでしょう？)

Swift5.X + -warn-concurrencyフラグで警告、Swift6にしたらエラーという流れ

なるほど。

ただ今回のケースだとUILabelを扱うのがUIViewControllerの中以外だとないのかなと

あー、 Task が MainActor を受け継ぐからということですね。↑でひろんさんと話していた、 actor-isolated な API の中に書かれたクロージャ式の中に書かれた Task は元の actor-isolated な context を引き継ぐというので満たされているということですね。 (edited)

koher

Swift5.X + -warn-concurrencyフラグで警告、Swift6にしたらエラーという流れ

なるほど。

ただ今回のケースだとUILabelを扱うのがUIViewControllerの中以外だとないのかなと

あー、 Task が MainActor を受け継ぐからということですね。↑でひろんさんと話していた、 actor-isolated な API の中に書かれたクロージャ式の中に書かれた Task は元の actor-isolated な context を引き継ぐというので満たされているということですね。 (edited)

あー、 Task が MainActor を受け継ぐからということですね。↑でひろんさんと話していた、 actor-isolated な API の中に書かれたクロージャ式の中に書かれた Task ｈ元の actor-isolated な context を引き継ぐというので満たされているということですね。

はい、そうですね！

actor-isolated な context を引き継ぐ条件がよくわからなくなってきました・・・。 @MainActor な API で↓を実行したときに、

print("#0", Thread.current, Thread.current == Thread.main) Task { print("#1a", Thread.current, Thread.current == Thread.main) Task { print("#1b", Thread.current, Thread.current == Thread.main) } } task { print("#2a", Thread.current, Thread.current == Thread.main) Task { print("#2b", Thread.current, Thread.current == Thread.main) } } Task.detached { print("#3a", Thread.current, Thread.current == Thread.main) Task { print("#3b", Thread.current, Thread.current == Thread.main) } } taskDetached { print("#4a", Thread.current, Thread.current == Thread.main) Task { print("#4b", Thread.current, Thread.current == Thread.main) } } DispatchQueue.main.async { print("#5a", Thread.current, Thread.current == Thread.main) Task { print("#5b", Thread.current, Thread.current == Thread.main) } } dispatchQueueMainAsync { print("#6a", Thread.current, Thread.current == Thread.main) Task { print("#6b", Thread.current, Thread.current == Thread.main) } } DispatchQueue.global().async { print("#7a", Thread.current, Thread.current == Thread.main) Task { print("#7b", Thread.current, Thread.current == Thread.main) } } dispatchQueueGlobalAsync { print("#8a", Thread.current, Thread.current == Thread.main) Task { print("#8b", Thread.current, Thread.current == Thread.main) } }

2:23 PM

（なお、 task などはそれとペアにある Task { } などをただラップしただけの関数です。）

2:23 PM

結果は↓のようになりました。

#0 <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #1a <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #1b <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #2a <NSThread: 0x6000035eac00>{number = 6, name = (null)} false #2b <NSThread: 0x6000035eac00>{number = 6, name = (null)} false #3a <NSThread: 0x6000035f6500>{number = 4, name = (null)} false #3b <NSThread: 0x6000035f6500>{number = 4, name = (null)} false #4a <NSThread: 0x6000035fc4c0>{number = 5, name = (null)} false #4b <NSThread: 0x6000035fc4c0>{number = 5, name = (null)} false #5a <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #5b <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #6a <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #6b <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #7a <NSThread: 0x600003571780>{number = 8, name = (null)} false #7b <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true #8a <NSThread: 0x6000035b2440>{number = 3, name = (null)} false #8b <_NSMainThread: 0x6000035f4000>{number = 1, name = main} true

2:24 PM

1b, 5b, 6b, 7b, 8b のみ context が引き継がれている。

2:25 PM

1b が OK なのに 2b は context が引き継がれず、にも関わらず 8b は引き継がれているのとか謎じゃないでしょうか。

1

外側のタスクに影響されてるってことかな

みたいですね。呼び出し側のスレッドに依っているような気がします。(コードの生成のされ方で変わる...？) @MainActorを付けいない関数に抽出して実行するとまた違う結果が出て来ました。

#0 <_NSMainThread: 0x6000022e43c0>{number = 1, name = main} true #1a <NSThread: 0x6000022bc840>{number = 5, name = (null)} false #1b <NSThread: 0x6000022bc840>{number = 5, name = (null)} false #2a <NSThread: 0x6000022f0040>{number = 6, name = (null)} false #2b <NSThread: 0x6000022f0040>{number = 6, name = (null)} false #3a <NSThread: 0x6000022e8f00>{number = 8, name = (null)} false #3b <NSThread: 0x60000226d140>{number = 9, name = (null)} false #4a <NSThread: 0x6000022dedc0>{number = 7, name = (null)} false #4b <NSThread: 0x6000022dedc0>{number = 7, name = (null)} false #5a <_NSMainThread: 0x6000022e43c0>{number = 1, name = main} true #5b <_NSMainThread: 0x6000022e43c0>{number = 1, name = main} true #6a <_NSMainThread: 0x6000022e43c0>{number = 1, name = main} true #6b <NSThread: 0x6000022bc840>{number = 5, name = (null)} false #7a <NSThread: 0x60000226d140>{number = 9, name = (null)} false #7b <NSThread: 0x60000226d140>{number = 9, name = (null)} false #8a <NSThread: 0x6000022bc840>{number = 5, name = (null)} false #8b <NSThread: 0x6000022bc840>{number = 5, name = (null)} false

(edited)

＠MainActor付き関数

#0 <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #1a <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #1b <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #2a <NSThread: 0x600003d84140>{number = 7, name = (null)} false #2b <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #3a <NSThread: 0x600003dfcc80>{number = 3, name = (null)} false #3b <NSThread: 0x600003dfcc80>{number = 3, name = (null)} false #4a <NSThread: 0x600003d80340>{number = 8, name = (null)} false #4b <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #5a <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #5b <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #6a <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #6b <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true #7a <NSThread: 0x600003d84140>{number = 7, name = (null)} false #7b <NSThread: 0x600003d84140>{number = 7, name = (null)} false #8a <NSThread: 0x600003df7580>{number = 4, name = (null)} false #8b <_NSMainThread: 0x600003dbc700>{number = 1, name = main} true

(edited)

うおー、なんかわからんくなってきた。あーでも、falseなら「MainActorが引き継がれてない」のはいえますが、trueの場合は「MainActorが引き継がれているかどうかは不明」ですね。

MainActorは内部的にMainActorとDispatchQueue.mainは同期していて、MainThreadで実行されることは保証されているけど、MainThreadで実行されていてもMainActorであるという訳ではない、ということですかね？WWDCでMainThreadは協調スレッドプールとは切り離されていると言っていたので、MainThreadはMainActorでしか使えず、他のExecutorがMainThreadを使うことはないのかなと思ってました

あ、でもCustom Executor使えばできるのかな…

(edited)

引き継がれる条件がぜんぜんわからないですね・・・

@discardableResult func task<Success>(operation: @escaping @Sendable () async -> Success) -> Task<Success, Never> { return Task.init(operation: operation) } @discardableResult func taskDetached<Success>(operation: @escaping @Sendable () async -> Success) -> Task<Success, Never> { return Task.detached(operation: operation) } func dispatchQueueMainAsync(execute work: @escaping () -> Void) { DispatchQueue.main.async(execute: work) } func dispatchQueueGlobalAsync(execute work: @escaping () -> Void) { DispatchQueue.global().async(execute: work) } func dispatchQueueMainAsyncSendable(execute work: @escaping @Sendable () -> Void) { DispatchQueue.main.async(execute: work) } func dispatchQueueGlobalAsyncSendable(execute work: @escaping @Sendable () -> Void) { DispatchQueue.global().async(execute: work) }

と定義しておいて

11:22 PM

@MainActor をつけたクラスのメソッドから↓を実行

print("#0", Thread.current, Thread.current == Thread.main) Task { print("#1a", Thread.current, Thread.current == Thread.main) Task { print("#1b", Thread.current, Thread.current == Thread.main) } } task { print("#2a", Thread.current, Thread.current == Thread.main) Task { print("#2b", Thread.current, Thread.current == Thread.main) } } Task.detached { print("#3a", Thread.current, Thread.current == Thread.main) Task { print("#3b", Thread.current, Thread.current == Thread.main) } } taskDetached { print("#4a", Thread.current, Thread.current == Thread.main) Task { print("#4b", Thread.current, Thread.current == Thread.main) } } DispatchQueue.main.async { print("#5a", Thread.current, Thread.current == Thread.main) Task { print("#5b", Thread.current, Thread.current == Thread.main) } } dispatchQueueMainAsync { print("#6a", Thread.current, Thread.current == Thread.main) Task { print("#6b", Thread.current, Thread.current == Thread.main) } } DispatchQueue.global().async { print("#7a", Thread.current, Thread.current == Thread.main) Task { print("#7b", Thread.current, Thread.current == Thread.main) } } dispatchQueueGlobalAsync { print("#8a", Thread.current, Thread.current == Thread.main) Task { print("#8b", Thread.current, Thread.current == Thread.main) } } dispatchQueueMainAsyncSendable { print("#9a", Thread.current, Thread.current == Thread.main) Task { print("#9b", Thread.current, Thread.current == Thread.main) } } dispatchQueueGlobalAsyncSendable { print("#10a", Thread.current, Thread.current == Thread.main) Task { print("#10b", Thread.current, Thread.current == Thread.main) } }

11:23 PM

結果

#0 <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #1a <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #1b <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #2a <NSThread: 0x600002f82180>{number = 6, name = (null)} false #2b <NSThread: 0x600002f82180>{number = 6, name = (null)} false #3a <NSThread: 0x600002f82540>{number = 2, name = (null)} false #3b <NSThread: 0x600002f82540>{number = 2, name = (null)} false #4a <NSThread: 0x600002f82540>{number = 2, name = (null)} false #4b <NSThread: 0x600002f82540>{number = 2, name = (null)} false #5a <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #5b <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #6a <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #6b <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #7a <NSThread: 0x600002f82780>{number = 4, name = (null)} false #7b <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #8a <NSThread: 0x600002f82180>{number = 6, name = (null)} false #8b <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #9a <_NSMainThread: 0x600002fb4140>{number = 1, name = main} true #9b <NSThread: 0x600002f82540>{number = 2, name = (null)} false #10a <NSThread: 0x600002f82180>{number = 6, name = (null)} false #10b <NSThread: 0x600002f82180>{number = 6, name = (null)} false

11:24 PM

@Sendable のクロージャー内だと、クロージャーの外側のactor contextが引き継がれないってこと？

koher

1b, 5b, 6b, 7b, 8b のみ context が引き継がれている。

5b, 6b, 7b, 8b は全部 @Sendable じゃないクロージャー内で Task を作ってる。一方、2b, 3b, 4b, (9b, 10b) は @Sendable なクロージャー内。 1b も @Sendable だけど、 Task.init には @_inheritActorContext がついてるとのことなのでこれは特別？

通常のクロージャ式の中に Task.init が書かれた場合は actor の context を引き継ぐ、 @Sendable なクロージャ式の中に Task.init が書かれた場合は actor の context を引き継がない。ただし、 @_inheritActorContext が付与されている @Sendable なクロージャ式の中に書かれた Task.init は例外的に actor の context を引き継ぐ。ということですね。

見つけました。 https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md#closures

swift-evolution/0306-actors.md at main · apple/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0306-actors.md at main · apple/swift-evolution

11:57 PM

Actors prevent this data race by specifying that a @Sendable closure (described in ...) is always non-isolated.

11:57 PM

@Sendable なクロージャの中はnon-isolatedなので引き継がないってことですね。

おおお、この Closures のところ特に難しくて、前に読んだときふんわりとしか理解できなかったんですよね。今の問題意識で読めば理解できるのかも。

今のぼくにはまだまだ部分的にしか理解できないw が、とりあえず引き継ぎの条件については「完全に理解した」のでとりあえず満足しておきます

あー、これ文章が難しかったんですが、ここのコードの例は別に難しくなかったのを思い出してきました。 (edited)

おお！完全に理解した

12:05 AM

(aka ちゃんと読む)

1

↓が何を言ってるのか理解するのにめっちゃ苦労したけど、コードは大して難しくない。単に detach のクロージャ式の中が non-isolated だから await 必須だよと。

A task created with detach runs concurrently with all other code. If the closure passed to detach were to be actor-isolated, we would introduce a data race on access to the mutable state on BankAccount. Actors prevent this data race by specifying that a @Sendable closure ... is always non-isolated.

@Sendable のクロージャー内だと、クロージャーの外側のactor contextが引き継がれない

12:08 AM

日本語だと、つまりこれが結論ってことでOKかな...

ですね。

で、その理由は、@Sendable なクロージャーは常に non-isolated だから。

ですね！

で、(多分)混乱の要因は Task.init のクロージャーは @_inheritActorContext だからと... (edited)

今話題にしてるのって↓のパターンで、 bar が挟まってるからもう一段階複雑な気がしています。 @MainActor func foo() { // (A) MainActor bar { // (B) MainActor でない Task { // (C) ここは？ } } } (edited)

12:12 AM

bar のクロージャが @Sendable でない場合に (C) が (A) の context を引き継ぐことはこの "Closures" からは読み取れないような？ (edited)

1

実は問題は @_inheritActorContext の挙動ってことか...?

いや、そもそも Task.init の引き継ぎの条件の話なので @_inheritActorContext の挙動そのものが話題というかw

で、 bar のクロージャが @Sendable でない場合に (C) が (A) の context を引き継ぐのであれば、 bar のクロージャが @Sendable の場合に (C) が (A) の context を引き継ぐのかも自明でなくて（ Task.init が呼び出された context が引き継がれるわけではないから）、調べてみたら引き継がれなかったと。 (edited)

そうだった、なんか長くてわかんなくなってきたw

(B) が MainActor ではないところが微妙

12:17 AM

でもそれは↓に関することだとしたら、現状はまだ正しい状態ではない？ https://discord.com/channels/291054398077927425/291054454793306112/890513245801160744

Task.init が呼び出された context が引き継がれるわけではないから

これが超絶わかりにくい気がします。これまで「呼び出された context 」が引き継がれるのだと思ってたし、それなら話はシンプルだけど。

hironytic

でもそれは↓に関することだとしたら、現状はまだ正しい状態ではない？ https://discord.com/channels/291054398077927425/291054454793306112/890513245801160744

そうなんですよね。現状の挙動が正しいのかわからないのも余計にややこしい・・・。

あと、メソッド名が確定するまでうろちょろしたので、過去のいろんな資料が見返すと混乱をまねく。。。

今はなき detach ・・・。

12:22 AM

WWDC の資料も結構修正されてるんですけど（これはすごいと思った）、一部残っちゃってるんですよね。

修正されてるんですか！それはすごい

たとえば async { } の 7 割くらい（？）は Task { } に修正されてます。

1

まあ、そこ async って覚えてしまうと、いきなり躓きそう

スライドレベルの修正で済むものは大体修正されているんですが、 https://developer.apple.com/videos/play/wwdc2021/10194/ みたいなスクリーンをレコーディングしたものは、おそらく修正が難しいことが原因で修正されていませんね。

Swift concurrency: Update a sample app - WWDC21 - Videos - Apple De...

Discover Swift concurrency in action: Follow along as we update an existing sample app. Get real-world experience with async/await,...

ああ、それは収録しなおしになるから無理ですねw

スライドが修正されたものについては、トークが修正されたかはわからないんですが、元々どっちになっても違和感がないように Transcript が考えられてたのかも。

関係ないけど、これをみてVimモードはライブプレゼンには向かないと思いました。いきなり範囲選択無しに数行消えたりするので、何をやったのかわかりにくいw

1

たしかに・・・。

koher

Task.init が呼び出された context が引き継がれるわけではないから

これが超絶わかりにくい気がします。これまで「呼び出された context 」が引き継がれるのだと思ってたし、それなら話はシンプルだけど。

実行時のcontextが引き継がれるとしたら話はシンプルそうだけど、コンパイル時の静的型チェック（actor isolatedのチェック）は超絶難しそうですw

Yuta Saito

このコミットで@escapingクロージャに対するactor-isolationの制約が無効になって、escapingクロージャが定義位置のアクターを引き継ぐようになったようです。 non-escapingであれば、関数の脱出までに寿命が尽きるので、スレッドを跨ぐことはないので、アクターを引き継ぐ仮定は正しいです。 escapingではこの仮定は明らかに安全ではないんですが、既存のコードを壊さないための妥協として5.5に入ってるそうです。 https://github.com/apple/swift/commit/5ecb9ebec2168582e0197453ba06b7d556e680fd で、Combineのsinkは、渡したクロージャの実行スレッドがreceiveで変わってしまうので、まさにその安全でないケースだった、ということだと思います。 (edited)

escapingクロージャが定義位置のアクターを引き継ぐようになった

これはコンパイラが、アクターを引き継いでいると 判断するようになった という話で、エラーが出なくなるだけで実際にそのアクターに守られているわけではない、という理解で合ってますか？

hironytic

(B) が MainActor ではないところが微妙

↑の話で考えると、 (B) は最終的な仕様上 MainActor にならないし、現状でも MainActor に守られているわけではないけど、 self.nameLabel.text = ... みたいなのが書けないと既存コードが破壊されまくるので、現状ではコンパイラが MainActor 扱いにしてコードの互換性を保っている（ただし守られてはいない）、 Swift 6 では MainActor でなくなるし await 必須になる、ということになる？そして、それと bar をすっ飛ばして Task.init が foo の context を引き継ぐ話はまた別で、 @Sendable は actor の context をぶった切る、 @Sendable でない @escaping なクロージャが何かの actor の context を持つことはないと考えると、 Task.init に渡されるクロージャは、それが宣言された場所で最も近い（内側のスコープの） actor を引き継ぐと考えれば一般化できる？という感じでしょうか。

12:59 AM

// Actor 1 a { // @escaping // どの Actor でもない Task.init { // Actor 1 await MainActor.run { // MainActor b { // @escaping // どの Actor でもない Task.init { // MainActor c { // @Sendable @escaping // どの Actor でもない Task.init { // どの Actor でもない actor2 { // Actor 2 @Sendable @escaping // Actor 2 d { // @escaping // どの Actor でもない Task.init { // Actor 2 } } } } } } } } } }

1:00 AM

↑のような感じ？

@Sendable でない @escaping なクロージャが何かの actor の context を持つことはない

あれ？これは引き継ぐのではないでしょうか？(わかんなくなってきましたw) Escaping closures can now be actor-isolated; only @Sendable prevents isolation. https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md#revision-history @Sendable はnon-isolatedであるものの、 @_inheritActorContextが例外にしているのかと。あーすいません上で既に話されてましたねw (edited)

僕が勘違いしてそうな気がしてきました・・・

ぼくもsendableじゃないクロージャーなら引き継ぐのが正しいと思います。

Remove the heuristic that escaping closures cannot be actor-isolated. This is in line with the long term plan for actor isolation, but opens up some holes in the short term because Sendable closures are not enforced throughout the Swift ecosystem.

https://github.com/apple/swift/commit/5ecb9ebec2168582e0197453ba06b7d556e680fd

1:05 AM

これは暫定的な対応ではなくて、恒久的対応だけど今はチェックが完全じゃないから穴が開いてるよってこと？

ただ、正しく引き継ぐと、DispatchQueue.global().async { }の中もメインスレッドで実行されちゃって既存コードを破壊するということなんじゃないかなあ

koher

escapingクロージャが定義位置のアクターを引き継ぐようになった

これはコンパイラが、アクターを引き継いでいると 判断するようになった という話で、エラーが出なくなるだけで実際にそのアクターに守られているわけではない、という理解で合ってますか？

議論全部終えてないんですが、これはあってます

1

koher

// Actor 1 a { // @escaping // どの Actor でもない Task.init { // Actor 1 await MainActor.run { // MainActor b { // @escaping // どの Actor でもない Task.init { // MainActor c { // @Sendable @escaping // どの Actor でもない Task.init { // どの Actor でもない actor2 { // Actor 2 @Sendable @escaping // Actor 2 d { // @escaping // どの Actor でもない Task.init { // Actor 2 } } } } } } } } } }

これコード読んで判断しろといわれても厳しいな (edited)

現状だとただescapingなだけのクロージャはどのActorで実行されるか不定だけど、isolationが完了した理想世界ならActorを跨ぐescapingなクロージャは同時にSendableも付くはず (edited)

1:09 AM

過渡期において動作が不定のものが含まれてしまってるが、ということかな

hironytic

ただ、正しく引き継ぐと、DispatchQueue.global().async { }の中もメインスレッドで実行されちゃって既存コードを破壊するということなんじゃないかなあ

そっち側に壊れるのかぁ。

たるのんさんの言うように、isolationが完了した理想世界はスレッド管理を言語外ではやらなくなるのでうまくいくのであって。

「暫定的に Actor を引き継いでいると判定する（ただし守られてはいない）→最終的には引き継いでいないと判定するように変更」かと思っていたけど、「恒久的に Actor を引き継いでいると判定する（ただし現状では守られてはいない）→最終的には守られているようにする」ということ？

sendableなクロージャーはnon-isolatedとして扱う、とわざわざ言うからには、sendableじゃないクロージャーならisolatedというのが自然ですよね

そうすると、↓のように解釈すればいいってことでしょうか。

@MainActor func foo() { // (A) MainActor bar { // (B) MainActor （ただし現状は守られていない） Task { // (C) MainActor } } }

isolationが完了した理想世界ならActorを跨ぐescapingなクロージャは同時にSendableも付くはず

こうなるとSendableチェックがきちんと働くので

「暫定的に Actor を引き継いでいると判定する（ただし守られてはいない）→最終的には引き継いでいないと判定するように変更」

僕はこっちなのかと思いました。 (edited)

錯綜してきたｗ

koher

そうすると、↓のように解釈すればいいってことでしょうか。

@MainActor func foo() { // (A) MainActor bar { // (B) MainActor （ただし現状は守られていない） Task { // (C) MainActor } } }

barはbarを宣言したコンテキストのActorになります

1:14 AM

もしbarをSendable無しでActorを跨いで渡したのなら、それ自体が将来的に違反コード (edited)

tarunon

barはbarを宣言したコンテキストのActorになります

bar の宣言ではなく bar に渡すクロージャの宣言ですか？

既存のDispatchQueueとかがアクターになってないのが根本の原因で、アクターになっているならsendableを受け取るように変わるからsendableじゃないクロージャーなんか受け取ることはないということかと

あ、そうですね。クロージャがinitされたとき、です

アクターを挟まずにスレッドを切り替える手段がないのが理想世界で、そうだとすると、barがsendableじゃないクロージャーを取るのなら、その先が別のスレッドではないわけで

そうですそうです

その世界で、 @Sendable でない @escaping ってどんなものが考えられますか？存在しない？

逆にbarがスレッドを切り替えてクロージャーを実装するたぐいのものなら、sendableなクロージャーを取るようになむてるはずだと

そのActorの中でしか使われないクロージャーとかじゃないですかね。結構色々ありそうだけど。 (edited)

1:19 AM

UIView.animateのcompletionとかが、当に

今、メインスレッドしか使わずにプログラムしても生まれるescapingなクロージャーと同じですよね。後からいいタイミングで呼ぶ的なやつ

1:20 AM

メンバに持っといて、なんかの拍子で実行するとかそういう

故に今出来ることは、スレッド跨ぎクロージャー渡しに全部@Sendableをつけて宣言するようニしておく、と言うことだと思います

1

（…離脱します）

スレッド跨ぎクロージャーかつSendable無しは違法コード

1:21 AM

だから動作が不定になる

既存のDispatchQueueとかがアクターになってないのが根本の原因

DispatchQueue が actor なら async メソッドに渡すクロージャは @Sendable なはずで、そうすれば↓のようになるはずと。 @MainActor func foo() { // (A) MainActor DispatchQueue.global().async { // (B) global Task { // (C) global } } }

そうですね、そうなると思います

1:33 AM

現状はDispatchQueue.global().asyncはActorの管轄外なのでそういう動きは出来ないんじゃないかな

これを実行すると

@MainActor func foo() { print("#0", Thread.current, Thread.current == Thread.main) DispatchQueue.global().async { print("#1", Thread.current, Thread.current == Thread.main) Task { print("#2", Thread.current, Thread.current == Thread.main) } } } final class ViewController: UIViewController { override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) foo() } }

#0 <_NSMainThread: 0x60000250c000>{number = 1, name = main} true #1 <NSThread: 0x60000251c480>{number = 8, name = (null)} false #2 <NSThread: 0x60000251c480>{number = 8, name = (null)} false

となるので、既にそうなっています？(あれ？) (edited)

tarunon

そうですね、そうなると思います

最終的に↓の (1), (2) と actor isolation はどのような関係になるという認識ですか？

@MainActor func foo() { publisher .receive(on: DispatchQueue.global()) .sink { _ in // (1) Task { // (2) } } .store(in &cancellables) }

(edited)

sinkはSendableになるはずですね。故に1global, 2globalじゃないでしょうか。

1:40 AM

現状SwiftConcurrencyの外にあるところにいきなりTaskを生やすのが飛び道具過ぎる感覚はあります (edited)

1:40 AM

安全にやるならActorの宣言が先じゃないかな

shiz

これを実行すると

@MainActor func foo() { print("#0", Thread.current, Thread.current == Thread.main) DispatchQueue.global().async { print("#1", Thread.current, Thread.current == Thread.main) Task { print("#2", Thread.current, Thread.current == Thread.main) } } } final class ViewController: UIViewController { override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) foo() } }

#0 <_NSMainThread: 0x60000250c000>{number = 1, name = main} true #1 <NSThread: 0x60000251c480>{number = 8, name = (null)} false #2 <NSThread: 0x60000251c480>{number = 8, name = (null)} false

となるので、既にそうなっています？(あれ？) (edited)

え、これって昨日の #7b と同じなのに挙動違いますよね？？？ Xcode 13.0 ？

はい、Xcode13.0です

全てnullableだった世界にOptionalを入れたときと同じで、全部?(今回は明示的なActorの宣言)をつけないと正しくならない

1:43 AM

最悪実行する度に違うとしても、それはまあ現状脱法コードだしな、と言う感覚ですね (edited)

viewDidAppear から直接だと Obj-C も絡んで挙動が違ってしまっているとか？？ @shiz さんの foo の中身を viewDidAppear の foo の呼び出し箇所にコピペすると true, false, true ですか？

あ、変わりましたw

#0 <_NSMainThread: 0x6000023f8140>{number = 1, name = main} true #1 <NSThread: 0x6000023d82c0>{number = 8, name = (null)} false #2 <_NSMainThread: 0x6000023f8140>{number = 1, name = main} true

(edited)

1

こっちでも再現しました。

1:47 AM

何がなんだか・・・。

@Sendable有りと無しの間に、未定義(つまりActorのContextを失う)を用意して、そのクロージャ下でのTaskの宣言をコンパイルエラーにする、と言うのが必要だったように見える

1:49 AM

DispatchQueue然り旧世界の非同期APIでActorにまだ対応してない箇所においては、そこに渡したクロージャの中からSwiftConcurrencyのAPIを呼ぶなら第一にActorの宣言が必要なはずです

こういうことですね

@MainActor func myFunc() { self.foo = .... // 合法 someActorsFunc { self.foo = ... // 違法 Task.init { // 合法 self.foo = ... // 違法 } } } @MainActor func myFunc() { self.foo = .... // 合法 DispatchQueue.global().async { self.foo = ... // 脱法 Task.init { // 脱法 self.foo = ... //脱法 } } } @MainActor func myFunc() { self.foo = .... // 合法 DispatchQueue.global().async { self.foo = ... // 脱法 Task.init { // 脱法 await MainActor.run { self.foo = .... // 合法 Task.init { // 合法 self.foo = ... //合法 } } } } }

(edited)

1

2

1:59 AM

メンバへのアクセス同様、Task.initの宣言にも脱法性がある

1:59 AM

1度脱法コンテキストに落ちたらその中のTaskの宣言も、その中のコンテキストも汚染されています (edited)

2:01 AM

本来なら脱法コンテキストのTask宣言は違法にして欲しかったけど、まあスケジュール的に仕様組むのも間に合わなかったんじゃないか

tarunon

こういうことですね

@MainActor func myFunc() { self.foo = .... // 合法 someActorsFunc { self.foo = ... // 違法 Task.init { // 合法 self.foo = ... // 違法 } } } @MainActor func myFunc() { self.foo = .... // 合法 DispatchQueue.global().async { self.foo = ... // 脱法 Task.init { // 脱法 self.foo = ... //脱法 } } } @MainActor func myFunc() { self.foo = .... // 合法 DispatchQueue.global().async { self.foo = ... // 脱法 Task.init { // 脱法 await MainActor.run { self.foo = .... // 合法 Task.init { // 合法 self.foo = ... //合法 } } } } }

(edited)

現状で↓のような挙動をしているのはどう解釈しますか？実装上たまたまそうなってるだけ？

final class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // MainActor DispatchQueue.global().async { Task { // MainActor } } } }

2:16 AM

脱法で未定義？

本来ならコンパイルエラーで然るべきだと思いますが、そうなってないので未定義の動作でたまたま望ましい方を引いているだけですかね。

内側が意図せずに MainActor になるのって結構謎じゃないですか？さっきの shiz さんの foo の例があるから微妙ですが・・・。

未定義なら何でもありじゃないかと

2:21 AM

コールスタックを遡るのかコンテキストを外側に辿るのかは知らないですけど、Actorコンテキストはそこにはないので、何かしらの方法で最寄りのActorコンテキストを拾ってきて埋めて動いてる。だから動きが不安定に見えているって事だと思います

そうすると、一番最初の話に戻って、 iOS 15 で VC から Publisher を購読して View に反映する正しい書き方は↓？

override func viewDidLoad() { super.viewDidLoad() state .objectWillChange .sink { [weak self] _ in guard let self = self else { return } Task { await MainActor.run { // state を View に反映する処理 self.nameLabel.text = self.state.user?.name } } } .store(in: &cancellables) }

MainActor.runがTaskの外じゃないといけない

それはできないです。

あーそうなのか

MainActor.run は await しないといけないので。

そしたらそうですね、外側のTask.initを捨て石にしてMainActor.runを呼ばないといけない

たとえ sink に渡すクロージャが @Sendable になったとして、 receive(on: DispatchQueue.main) したとしても、コンパイラはそれを検出できないから、 .sink { } の中が MainActor として判別することはできない・・・。

どんな状況でもMainActorで呼び出したい場合はそうなるのかなと思ってます。ただ今回のケースだとUILabelを扱うのがUIViewControllerの中以外だとないのかなと思っており、MainActor.runは必要ないのではと思いました(どうなんでしょう？)

なるほど。僕のこの認識が間違ってましたね。

過渡期において汚染されたTaskが存在し得るというのがかなり重要ですね (edited)

shiz

どんな状況でもMainActorで呼び出したい場合はそうなるのかなと思ってます。ただ今回のケースだとUILabelを扱うのがUIViewControllerの中以外だとないのかなと思っており、MainActor.runは必要ないのではと思いました(どうなんでしょう？)

なるほど。僕のこの認識が間違ってましたね。

うーん、僕はまだ仕様上なにが正しいのか自信を持ててません。 shiz さんがおっしゃってたのが正しい可能性もあるのかなと。

2:29 AM

なにせ現状で実際の挙動は当てにならないので

たしかにそうですねw結局何が本当に正しいのかがまだわからない

(edited)

1

koher

たとえ sink に渡すクロージャが @Sendable になったとして、 receive(on: DispatchQueue.main) したとしても、コンパイラはそれを検出できないから、 .sink { } の中が MainActor として判別することはできない・・・。

これはちょっと違うと思っていて、DispatchQueue.mainではなく、MainActorのインスタンスを渡して型に焼き込む方法になるんじゃないかと。

tarunon

これはちょっと違うと思っていて、DispatchQueue.mainではなく、MainActorのインスタンスを渡して型に焼き込む方法になるんじゃないかと。

なるほど？でも任意の actor は型に現れないですよね？同じ型の異なるインスタンスは異なる actor だけど型が同じなので。

2:38 AM

Publisherの購読、AsyncSequenceを使うのが正解？でも無限ループだと循環参照がきついかぁ。

Publisher自体がディスコンになるのは有り得ると思います

2:39 AM

JS世界もasync generatorがあるからRxわざわざ使うでもないって感じだし

2:40 AM

(最もあっちはReact/Vueの影響がかなり大きいけど)

2:41 AM

AsyncSequenceは、購読するときはちゃんとweakにしましょうねって話を前にやった気がする (edited)

2:42 AM

https://discord.com/channels/291054398077927425/291054454793306112/874863999735439360

そうか、 Task.init があるからそこで weak capture すればいいのか。

3:35 AM

objectWillChange を購読するにしても for await 使うのが良さそうですねぇ。

せっかく完全に理解したのに、shizさんの @MainActor のfooのやつで打ち砕かれたw やっぱり脱法はわけがわからない

1

脱法コードは書いちゃダメだよ(´･_･`)

AsyncSequenceとして購読だと Sendable でない escaping クロージャがどこにも出てこないので明快ですね。

tarunonさんが書いてるように、 @Sendable と、そうじゃないのと、それとは別に第3の「未定義」がマークできるのならまあわかるんだけど、その未定義というマークはないから、今はこれは「 @Sendable じゃない」になっているはずで、コンパイラからするとそこでスレッドの切り替えは発生しないとみるしかないはずだと思うんだけど。 (edited)

未定義を作れなかった結果、旧世界のルールに落ちるのは別にこれに限った話じゃないと思います。

3:44 AM

JavaのOptional然り

でも、 foo を経由しないとき（7b）はメインスレッドへの切り替えが発生してるし、fooを経由したら発生してないし。。。

未定義動作であれば、そうなってもおかしくない (edited)

3:45 AM

宣言だけしたcのポインタに謎の数値が！？みたいな話です

未定義は未定義なんだけど、コンパイラ上は未定義じゃないのに、7bでスレッドの切り替えは発生してるから、なんでかなーと。

3:47 AM

あー違うのか。MainActorだから、コンパイラからすると、新しくメインスレッドでタスクを実行してもいい（7b）し、そのまま継続してもいい（本来はスレッドの切り替えが発生しないのだからメインスレッドで実行されるはず）のか。

コンテキストから外側のActorを拾ってるフロー(コンパイル時)と、コールスタックからActorのポインタを取ってくるフロー(実行時)の2通りがあるんじゃ無いだろうか

3:47 AM

基本コンパイル時解決するが、それが出来ない場合は実行時解決される。今は過渡期だから許してくれ、と。 (edited)

そのまま継続しても、新しく乗せても、メインスレッドで実行されるはずなのに、脱法によって継続元が別のスレッドにいる場合ができてるから、コンパイラ的には意図せず、foo の方の末端の Task が false になってると考えれば辻褄はあう気がします。

3:49 AM

コンパイラがというよりは MainActor のglobalActorの実装が、ですかね。

3:51 AM

現在の DispatchQueue.async には @Sendable はついていないのだから、コンパイラのお気持ちとしては

@MainActor func foo() { // ここはMainActor print("#0", Thread.current, Thread.current == Thread.main) DispatchQueue.global().async { // ここもMainActor print("#1", Thread.current, Thread.current == Thread.main) Task { // ここもMainActor print("#2", Thread.current, Thread.current == Thread.main) } } }

(edited)

3:53 AM

だから、#1のprintが終わったあとのTaskをそのままそのスレッドで実行してもいいし、次のタイミングでメインスレッドで実行してもいい、と考えてよいはず。

どちらでもいいですね

3:54 AM

なお #1 がウソなので…

なのに脱法によって #1 のprintが実は別のスレッドで実行されているので、そのままのスレッドで実行する方に倒れたときに #2 もメインスレッドじゃなくなると。

これまでの話を総合して得られた、 Swift Concurrency を考慮した正しい ObservableObject （の objectWillChange ）の購読方法はこうかな。

override func viewDidLoad() { super.viewDidLoad() Task { [weak self] in guard let state = self?.state else { return } for await _ in state.objectWillChange.values { guard let self = self else { return } // state を View に反映する処理 self.nameLabel.text = self.state.user?.name } } }

その Task 自体は ViewController が破棄されるときに cancel() してあげた方がいいのではなかろうか・・・

明示的な Set<AnyCancellable> や DisposeBag 相当のものは不要で、 VC が解放されたら guard let self = self else { return } で Task.init を脱出する。

あ、そうか。for await を抜けるから。 (edited)

[weak self] と、 for await の中に guard let self = self else { return } があるのがポイントで、もし strong capture したり for await の前で guard let self = ... をやっちゃうとリークする。

んー？次の value が来るまでは脱出しない？

hironytic

んー？次の value が来るまでは脱出しない？

ですね。ただ、それは明示的にキャンセルしても同じかと。

5:30 AM

Task の cancel は isCancelled のフラグを立てるだけなので、 await したときにそこで使われている非同期 API が checkCancellation するか、自前で checkCancellation しない限りは終了しないので。

AsyncSequence自体はキャンセルされないのかなあ

Task が終了すると AsyncSequence をキャプチャするものがなくなるから、 AsyncSequence も解放されて、クリーンナップが必要ならそこで行われる？

いや、Task をキャンセルしたら、AsyncSequence の next 待ちのところでキャンセルされないのかなあと思ったのです

Task をキャンセルしたら next のところで CancellationError が throw されると思います。

5:33 AM

あー、でも for try await じゃないから無理？

わからなくなってきた

多分 for await で next が nil を返してループ終了で Task が終了ですね。

そうすると、次の値が来る前に終了しますよね、ということが言いたかった。

あー、そういうことか。そうですね。

public protocol AsyncSequence { associatedtype AsyncIterator: AsyncIteratorProtocol where AsyncIterator.Element == Element associatedtype Element __consuming func makeAsyncIterator() -> AsyncIterator } public protocol AsyncIteratorProtocol { associatedtype Element mutating func next() async throws -> Element? }

そして、ボタンを押すとかを起点にして値が更新される場合ヤバイな。

throws の無い AsyncSequence ってあるんですか？

5:37 AM

↑のコードは↓から引用 https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md#proposed-solution

少なくとも for await の場合と for try await の場合がある。 (edited)

どういう規則でやってるんだろう

5:38 AM

AsyncSequence に conform している具体型の AsyncIterator.next() が nothrow なら

Never のときに

コンパイラがそれを考慮する？

NoThrowなasync sequence、たとえば NotificationCenterがそうかな

あれ？ AsyncSequence に Failure はない？

Publisher のエラー型がNeverならIteratorがnothrowってSwiftの文法で記述できないですよね (edited)

（話が戻るけど）末端がこういう AsyncStream だと、ViewController がなくなったときにさっさとキャンセルしてくれたら onTermination がやってきてネットワークとの接続を切断できそう。

return AsyncStream(Item.self) { continuation in continuation.onTermination = { @Sendable _ in // ネットワークから切断 } // ネットワークに接続して // 値が来るたび continuation.yeild(item) するコードをここに }

勝手に、 Failure が Never な AsyncSequence では var next: Element { get async } がオーバーロードされてるのかと思ってた。

AsyncSequenceの定義にエラー型を表すassociatedtypeは無いように見えるんですよね。

なんかその仕組み、 1 月の waiwai でややこしい話になって、そんなことほんとにできんの？ってなった気がする。

As described there, the iterator can choose how it responds to cancellation. The most common behaviors will be either throwing CancellationError or returning nil from the iterator.

AsyncSequence自身はキャンセル要求があったときにエラーを再送するかnilを返すかを選べるらしい

5:42 AM

そうか、ストリームの終了を意味するnilを返す手段があるから

5:42 AM

nothrowであってもキャンセルに即座に連動する事はできるのか

5:42 AM

次の値としてnilをすぐ返せる。

5:43 AM

https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md#cancellation

task をとっておいて、 VC が解放されたときに明示的にキャンセルはちょっといやだなぁ。まず、 AnyTask がない。 cencels: [() -> Void] で task.cancel を保持すれば良い？

実は、タイムリーに、ちょうど、このタスクをとっておいてキャンセルするのめんどいなあと思ってたところだったのですw

そして cancellables: Set<AnyCancellable> と違って明示的に deinit でキャンセルしないといけない。ので、専用の型（保持する task （か task.cancel ）を deinit で全部キャンセル）が必要になる。 (edited)

そういう型を自作するのが良さそう

omochimetaru

Publisher のエラー型がNeverならIteratorがnothrowってSwiftの文法で記述できないですよね (edited)

Publisherの values がエラー型がNeverなら AsyncPublisher を、それ以外は AsyncThrowingPublisher をというように2つあるので、それでなんとかなってると思ってた https://developer.apple.com/documentation/combine/publisher/values-1dm9r https://developer.apple.com/documentation/combine/publisher/values-v7nz

Rxと同じ気分になってこういうの作ってましたね

class TaskDisposer { var cancells: [() -> ()] = [] deinit { cancells.forEach { $0() } } func add<S, F: Error>(_ task: Task<S, F>) { cancells.append(task.cancel) } } extension Task { func disposed(by disposer: TaskDisposer) { disposer.add(self) } }

DisposeBag.add<T>(_ task: Task<T>)

5:48 AM

Fも消さないと駄目か。↑まさにそれ

自作すればいいのはそうなんだけど、単に ObservableObject の object.willChange を購読するだけで必要になるものが標準で用意されてないのはおかしい。

単に ObservableObject の object.willChange を購読する

これって割とレアなんじゃないでしょうかね？

5:49 AM

基本的にはPublished のほうを購読したりしないかな

5:49 AM

でも同じか

hironytic

Publisherの values がエラー型がNeverなら AsyncPublisher を、それ以外は AsyncThrowingPublisher をというように2つあるので、それでなんとかなってると思ってた https://developer.apple.com/documentation/combine/publisher/values-1dm9r https://developer.apple.com/documentation/combine/publisher/values-v7nz

Combine.AsyncPublisher Combine.AsyncThrowingPublisher なるほど、これなら良さそうですね

koher

自作すればいいのはそうなんだけど、単に ObservableObject の object.willChange を購読するだけで必要になるものが標準で用意されてないのはおかしい。

「deinitでキャンセルする」戦略を正解と決めたくなかったからじゃないでしょうか？

5:50 AM

僕はもう一つのアプローチとして、循環参照は許容した上で、

5:50 AM

イベントを起点に解放する戦略がありえると思っています。

僕は SwiftUI に寄せて宣言的にコードが書けるように最近は極力 objectWillChange を購読してます。が、いずれにせよどの Publisher を購読しても同じですね。

「画面が表示されるときに購読を構築して、画面が消えるときに購読をキャンセルする」みたいな作りにする。

ObservableObject は Combine ですよね。だから標準というか、そっちで標準的に用意されているのはAnyCancellableで。。。

実際のAPIとして viewDidAppear と viewWillDisappear にすると、うまくいかない場合があるみたいな話もあるけど、それはUIKitの問題であって。

もうちょっと単純化すると、 viewDidLoad で Publisher を購読して変更を View に反映する、 Swift Concurrency 時代の正しいやり方は何なのか、かな。

5:53 AM

↓だと publisher に値が流れてくるまで return しないので、もし VC 解放後に値が流れて来ないならリークする。

override func viewDidLoad() { super.viewDidLoad() Task { [weak self] in guard let publisher = self?.publisher else { return } for await value in publisher.values { guard let self = self else { return } self.label.text = value } } }

PassthroughSubject と CurrentValueSubject に相当する使い方ができる AsyncSequence メーカーがあれば、そもそも Combine を使わなくてよくなるのかなあ

5:56 AM

そうでもないか…share()とか考え出したら、Combine相当の別のライブラリになるだけか

次のWWDCではこれがベストプラクティスだよって言いながらそのための道具が提供されそう。

1

ObservableObject 相当のものは結局必要そうですし、 Concurrency が導入されても簡単には Combine はなくせない？

ObservableObject の代わりが AsyncSequence では？

objectWillChange を Publisher じゃなくしてしまう方法はあるのか。

慣れの問題だと思うけど

omochimetaru

ObservableObject の代わりが AsyncSequence では？

AsyncSequence は Publisher の代わりにしかならないんじゃない？

6:01 AM

ちがうか。

オペレーター欲しいなら増やせばokです

6:02 AM

その二つは概念的に等しい

makeIterator で得られるものが Publisher か。

6:02 AM

やっぱ違うな。

ObservableObject は抱えてる @Publisher の変更を通知する機能か。

6:03 AM

それは何かしら実装が必要ですね。

AsyncSequence は Publisher で、 ObservableObject は Publisher を返す型だから。

あ、どうせCombine使うなら、AnyCancellable { task.cancel() } を作って、普通に Set<AnyCancellable> にストアしたらいいのか

hironytic

あ、どうせCombine使うなら、AnyCancellable { task.cancel() } を作って、普通に Set<AnyCancellable> にストアしたらいいのか

Set<AnyCancellable> に task を insert できるオーバーロードをたせそう。

extension Task { func store(in set: inout Set<AnyCancellable>) { set.insert(AnyCancellable { cancel() }) } }

と言うかキャンセルだけならシンプルに[()->Void]でいいよ

6:05 AM

.cancelを持たせれば良い (edited)

tarunon

と言うかキャンセルだけならシンプルに[()->Void]でいいよ

それだとdeinit時にcancelする動作が実装できないよ

classの中に持たせるストレージの話だよ

まず、 Publisher.values は Task がキャンセルされた場合に即時 nil を流してくれるんだろうか？ (edited)

tarunon

classの中に持たせるストレージの話だよ

Set<AnyCancellable> ならdeinit cancel挙動がもうついてるからそれを再利用すると楽という話では

ああ、なるほどね

omochimetaru

それだとdeinit時にcancelする動作が実装できないよ

AnyCancellable は deinit 時に cancel を呼ぶので大丈夫では。

koher

AnyCancellable は deinit 時に cancel を呼ぶので大丈夫では。

[()->Void] だと呼ばれないですよね

呼ばれそうな気がする

ああ、ひろんさんにリプしてるのかと勘違いした。

AnyCancellable.cancelがキャプチャされて解放されなくなるだから、成り立つんじゃないかしら

6:10 AM

まあTaskはキャンセルされないから、結局呼ばなきゃだけど

たぶん全員同じことを言ってるのが混乱してるだけに見えてきたww

関数の呼び出しをcancelに対応付けるんじゃなくて関数がキャプチャするだけでその関数が死ぬときにAnyCancellableが解放されることを利用するって言ってるのか。

6:12 AM

その場合はtaskを直接キャプチャしたら駄目だから、ミスしそう。

無理矢理Combine噛ませるよりは、両方共通して使うための構造を1個作ってそれを使った方が、良いと思うけどね

それはそう思う。

6:13 AM

でもCombineでたくさんコード書いたプロジェクトに段階的に導入するとかなら

6:13 AM

いったん Set<AnyCancellable> に寄せておくのが楽とかはありそう

それこそ導入したところから共通層入れていくのが良さそうだけど

なるほど

うーん、いずれにせよ標準で用意されていない道具を使うと、標準で出てきたときに置き換えないといけないんだよなぁ。

tarunon

無理矢理Combine噛ませるよりは、両方共通して使うための構造を1個作ってそれを使った方が、良いと思うけどね

それはそうですね。AnyCancellable をかますやつは、どっちかというと、koherさんの↓に対する解決策ですね。 https://discord.com/channels/291054398077927425/291054454793306112/890837087148982293

なんとか今提供されている道具だけで手軽にできないのかなぁ。

AnyCancellable でいいじゃないですか＞今提供されている道具

TaskGroupは使えないんだっけ、これは並行計算のためのものか

hironytic

AnyCancellable でいいじゃないですか＞今提供されている道具

Task に extension 書かないと面倒じゃないですか？

それはそう。でも、これだけですよw https://discord.com/channels/291054398077927425/291054454793306112/890841388244140042

まあでもCombineのCancelableをdeinitしたらキャンセルされちゃうよりは、キャンセルを明示的にやらなければキャンセルしない、の方が理にかなってるな

6:17 AM

まとめてキャンセルしたいときはdeinitを持ったBagを作るだけで良いのだから

6:17 AM

キャンセルしたくないヤツが手軽になる方が利点が大きい

tarunon

まあでもCombineのCancelableをdeinitしたらキャンセルされちゃうよりは、キャンセルを明示的にやらなければキャンセルしない、の方が理にかなってるな

自分はそう思っててRxSwiftの設計のほうがCombineより良く出来てると思ってる

6:18 AM

キャンセルするインターフェースと、deinitでキャンセルする機能が分離されていて、ユーザーに委ねられている方が綺麗に見える。

hironytic

それはそう。でも、これだけですよw https://discord.com/channels/291054398077927425/291054454793306112/890841388244140042

そうですが、こういう道具を作り込むと後で全部置き換えないといけなくなるので、まだ Concurrency について色々わかってない中で本当にもっといい方法はないのかな？と。

このへんはConcurrencyの機能じゃなくて、その上でどういうパターンでアプリケーションを実装するかというフレームワークの層の話だから、まだ提供されてないんじゃないだろうか

Publisher.values を提供したのにそっちを提供してないのおかしくない？

まずConcurrencyだけでもパラダイムが大きく変わるから、その上でどういうフレームワークがいいのかはコミュニティが正解を見つけるのを待ったほうがいいというか。

koher

Publisher.values を提供したのにそっちを提供してないのおかしくない？

.values の部分はどんなフレームワークにするにせよ自明だから良いと思います。

6:20 AM

残りの部分は自分で考えてねってなってるだけ。

元々の話は、これまで行われていたような、↓のようなコードすら Swift Concurrency の元では正しくないんじゃないかという話で、

override func viewDidLoad() { super.viewDidLoad() state .objectWillChange .receive(on: DispatchQueue.main) .sink { [weak self] _ in guard let self = self else { return } self.label.text = state.user.name } .store(in: &cancellables) }

6:24 AM

またわかんなくなってきたな。一体このコードは Swift 6 でどう扱われることになるんだろう？

6:24 AM

脱法コードとして有効なまま？警告？エラー？

そのへんの会話はちゃんと追ってないんですけど

sink は @Sendable でない @escaping なクロージャだから actor-isolated なはずで

完成した世界なら、sinkに渡してるクロージャが、viewDidLoadのactor contextを引き継ぐんじゃ？

でもスレッドスイッチできるからヤバイと。

sink は @Sendable でない @escaping なクロージャだから actor-isolated なはずで

これが過渡期における脱法行為なので

6:25 AM

Sendableに整理されると思います

omochimetaru

完成した世界なら、sinkに渡してるクロージャが、viewDidLoadのactor contextを引き継ぐんじゃ？

もし receive(on: DispatchQueue.global()) するとどうなる？それでも sink の中は MainActor ？

完成した世界では sendable なしにスレッドスイッチはできないのでは

koher

もし receive(on: DispatchQueue.global()) するとどうなる？それでも sink の中は MainActor ？

引き継いでるactorに投入されるクロージャに暗黙変換されるのかなと思ってました。

だから、 receive(on:) とはそもそも相容れないからどうするんだろ・・・でもそこ（Combine）はswiftの外なんですよね。一応。

だから、Combineとしてはglobal queueで実行するけど、この関数が自分で即座にmain actorに投入するから

今のSendableがついてないクロージャ渡し、!やtry!がそこら中についてるのと一緒ですよ (edited)

.sink { DispatchQueue.main.async { 本文 } } ↑このコードのような挙動をする (edited)

hironytic

だから、 receive(on:) とはそもそも相容れないからどうするんだろ・・・でもそこ（Combine）はswiftの外なんですよね。一応。

Swift の外としても、違法として破壊的にエラーにしてしまうのか、脱法として穴を残すのか、

と思ってた

6:28 AM

あーでもそれはありえないか

6:28 AM

返り値がある関数だったら成り立たない話になるな

結局どうしようもなくって、脱法マーカーが出来るんだと思いますよ

6:29 AM

@UnsafeNonSendable みたいなのが生まれる

じゃあActor Contextの引き継ぎって何を意味してるんだ？あくまで静的解析の話なのかな

それはたぶんループしてるので、おもちさんに午前の会話を眺めてもらう方が話がはやそうww

omochimetaru

じゃあActor Contextの引き継ぎって何を意味してるんだ？あくまで静的解析の話なのかな

すくなくとも、 // Actor foo Task { // ここも Actor foo の中 } これはやってくれるはず。

6:31 AM

@Sendable クロージャは context の引き継ぎをぶった切る。

hironytic

それはたぶんループしてるので、おもちさんに午前の会話を眺めてもらう方が話がはやそうww

今北産業

Sendableの言語仕様って、「俺のアクター」「お前のアクター」しかやってなくて (edited)

@nonescaping なクロージャは context を引き継ぐ。

6:31 AM

問題は @Sendable でない @escaping なクロージャがよくわからん・・・。

そこに第三勢力としてアクターじゃ無いですってのが混ざってるんだからそりゃ無理って話

6:32 AM

@Sendable でない @escaping なクロージャ 今のところこれは90％ぐらい脱法です

tarunon

@Sendable でない @escaping なクロージャ 今のところこれは90％ぐらい脱法です

@Sendable を付けることでセーフティが導入されるけど、付けない場合は旧世界のガバガバ挙動しかないってこと？

そうだよ

ほ〜ん

6:33 AM

ObjCの IUO みたいな感じか

付けない場合は、「完成された安全なところ」と「旧世界ガバガバ危険地帯」が混ざってる

@Sendable でない @escaping なクロージャもcontextを引き継ぐ、と、コンパイラは思っているが、言語の外でランタイムにスレッドスイッチできてしまうことにより脱法が可能になっている

だから安全になったマーカーか脱法マーカーが欲しい

脱法マーカーに関しては

6:33 AM

@propertyWrapper struct UnsafeSendable

6:33 AM

これつくって

6:34 AM

見かけ上Sendableだけどその上で @UnsafeSendable var foo で

6:34 AM

ゴリ押しするスタイルがいいんじゃない。

omochimetaru

今北産業

現状で↓のような挙動をするんだけど、 Task { } が MainActor を引き継いで見えることで混乱して色々話したけど、これ自体仕様じゃないっぽいという話をしてた。

final class ViewController: UIViewController { override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) // (1) メインスレッド DispatchQueue.global().async { // (2) 別のスレッド Task { // (3) メインスレッド } } } }

(edited)

クロージャ渡しに関しては以下の通り。なし -> 合法 @Sendable -> 合法 @escaping -> 脱法だが稀に合法 @Sendable @escaping -> 合法 (edited)

koher

現状で↓のような挙動をするんだけど、 Task { } が MainActor を引き継いで見えることで混乱して色々話したけど、これ自体仕様じゃないっぽいという話をしてた。

final class ViewController: UIViewController { override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) // (1) メインスレッド DispatchQueue.global().async { // (2) 別のスレッド Task { // (3) メインスレッド } } } }

(edited)

その挙動すごいですね。どうやって実現されてるの・・・

koher

現状で↓のような挙動をするんだけど、 Task { } が MainActor を引き継いで見えることで混乱して色々話したけど、これ自体仕様じゃないっぽいという話をしてた。

final class ViewController: UIViewController { override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) // (1) メインスレッド DispatchQueue.global().async { // (2) 別のスレッド Task { // (3) メインスレッド } } } }

(edited)

それに関しては、いまのところ結局、↓という挙動かなと思ってます。 https://discord.com/channels/291054398077927425/291054454793306112/890807721052479529

現状の実装も正しくないから、結局想定されている正しい仕様が何なのかわからない・・・。

hironytic

それに関しては、いまのところ結局、↓という挙動かなと思ってます。 https://discord.com/channels/291054398077927425/291054454793306112/890807721052479529

解釈は僕もそう思うんですけど、実際問題mainへの投入はどうやって実装されているのか？

そのまま継続せずに新しくMainActorのキューに積むとmainへの投入になるということじゃないかと。

Task.init が MainActor をどうやって持ってくるのか

そこは実行時じゃなくて静的に、外側のアクターを引き継ぐ。

Effectively, when the closure is called, it will immediately "hop" over to the actor's context so that it runs within the actor.

6:39 AM

https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#actor-context-propagation

hironytic

そこは実行時じゃなくて静的に、外側のアクターを引き継ぐ。

コード生成されてるってことですか？

6:41 AM

Task.init だけ、コンパイラが特別に配慮して、静的に対応付けられたMainActorのインスタンス？を注入する？ (edited)

よくわからないけど、まず、さっきの Task の中身は、メインスレッドで実行されるときと、別スレッドで実行されるときの両方が確認されていて、

それともcurrent actorみたいな秘密の変数があるのかな。

↓によると @escaping な（ @Sendable でない）クロージャは actor-isolated 扱いになっていて、でも検査されていなくて危険と。なので、実際には↑の (2) は MainActor に投入されてないけど、 MainActor とコンパイラは思ってる？ https://discord.com/channels/291054398077927425/291054454793306112/890513245801160744 (edited)

6:42 AM

そう考えると、 (1) から (2) へ、 (2) から (3) へ MainActor が引き継がれるとも考えられる。

hironytic

よくわからないけど、まず、さっきの Task の中身は、メインスレッドで実行されるときと、別スレッドで実行されるときの両方が確認されていて、

同じコードでも(3)の結果が変動するってことですか？

いや、コードの書き方によって、ですね。えーとshizさんの

6:43 AM

https://discord.com/channels/291054398077927425/291054454793306112/890773961275764736

omochimetaru

同じコードでも(3)の結果が変動するってことですか？

viewDidLoad の中を別の @MainActor な関数に切り出すと挙動が変わる。

hironytic

https://discord.com/channels/291054398077927425/291054454793306112/890773961275764736

なるほど

6:44 AM

ヤバいな。なんだそりゃ。

6:45 AM

https://github.com/apple/swift/blob/main/stdlib/public/Concurrency/Task.swift#L45

swift/Task.swift at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

6:45 AM

@available(SwiftStdlib 5.5, *) @frozen public struct Task<Success: Sendable, Failure: Error>: Sendable { @usableFromInline internal let _task: Builtin.NativeObject @_alwaysEmitIntoClient internal init(_ task: Builtin.NativeObject) { self._task = task } }

6:45 AM

Task.init はマジでコンパイラが特別扱いしてそうな見た目をしてるな。

だから、コンパイラとしては、(1) から (2) へ、(2) から (3) へ、全部MainActorだと思っていて、(2) が終わったあと、そのままそのスレッドで継続して (3) を実行するコードを吐いてもいいし、(3) は改めてMainActorのキューにのせるコードを吐いてもいいんじゃないかと。

omochimetaru

なるほど

それ見て結局何が正しいのかわからんってなってる。想定されている仕様が何なのか。それに対する一つの仮説が tarunon さんの脱法の整理。

本来ならばDispatchQueueとかCombineのクロージャは @escaping @Sendable なはずだけど、過渡期に置いてこれを宣言できないので、整理されず @escaping だけになっている、という考え方です

コンパイラは (2) が MainActor で実行されるものだと思ってるのに、ランタイムで (2) を別のスレッドで実行できちゃっているから、(3) の挙動が安定しないのかなと思ってます。この (2) を脱法と呼んでます

hironytic

だから、コンパイラとしては、(1) から (2) へ、(2) から (3) へ、全部MainActorだと思っていて、(2) が終わったあと、そのままそのスレッドで継続して (3) を実行するコードを吐いてもいいし、(3) は改めてMainActorのキューにのせるコードを吐いてもいいんじゃないかと。

でもこれが想定仕様だとすると、 (2) は将来 MainActor に投入されるようになる？↓だし。

This is in line with the long term plan for actor isolation, but opens up some holes in the short term because Sendable closures are not enforced throughout the Swift ecosystem.

https://github.com/apple/swift/blob/main/stdlib/public/Concurrency/Task.swift#L445-L448

6:47 AM

 public init( priority: TaskPriority? = nil, @_inheritActorContext @_implicitSelfCapture operation: __owned @Sendable @escaping () async -> Success ) {

omochimetaru

https://github.com/apple/swift/blob/main/stdlib/public/Concurrency/Task.swift#L445-L448

結局 Task.init の actor context の引き継ぎとはこの @_inheritActorContext の挙動は何なのかって話になってて、コンパイラがこれをどう扱ってるかを追うとわかるのかも。

_inheritActorContext の取り扱いで魔法がかかってそうですね

ただ、それでわかるのは結局今の実装がどうなってるかで、想定仕様が何かはわからない。

想定仕様はproposalに書いてある範囲ですよね。

omochimetaru

_inheritActorContext の取り扱いで魔法がかかってそうですね

それについては昨日、家庭さんが話としては出してきてた（魔法の中身はわからない） https://discord.com/channels/291054398077927425/291054454793306112/890416523825537064

omochimetaru

想定仕様はproposalに書いてある範囲ですよね。

@escaping なクロージャのことほとんど書いてなくない？

書いてないというか、 @Sendable なクロージャだけが non-isolated で、他は @escaping も含めて isolated だと思うんだけどなあ。書いてないだけに。 (edited)

hironytic

書いてないというか、 @Sendable なクロージャだけが non-isolated で、他は @escaping も含めて isolated だと思うんだけどなあ。書いてないだけに。 (edited)

Escaping closures can now be actor-isolated; only @Sendable prevents isolation.

なので actor-isolated はそうだと思います。

ふむふむ

で、これが

This ... opens up some holes in the short term

はその通りとして

今の扱いはこうなってそうなし -> 合法 (isolated) @Sendable -> 合法 (non-isolated) @escaping -> 脱法 (non-isolated) @Sendable @escaping -> 合法 (non-isolated)

This is in line with the long term plan for actor isolation

なのはどういう想定なんだろう？

6:53 AM

将来的には安全になるってこと？

6:53 AM

これ。 https://github.com/apple/swift/commit/5ecb9ebec2168582e0197453ba06b7d556e680fd

tarunon

今の扱いはこうなってそうなし -> 合法 (isolated) @Sendable -> 合法 (non-isolated) @escaping -> 脱法 (non-isolated) @Sendable @escaping -> 合法 (non-isolated)

(1)が合法なのはそもそもコンテキストスイッチをまたぎようがないからってことよね

そうだね

tarunon

今の扱いはこうなってそうなし -> 合法 (isolated) @Sendable -> 合法 (non-isolated) @escaping -> 脱法 (non-isolated) @Sendable @escaping -> 合法 (non-isolated)

その脱法の部分は、コンパイラは isolated としてる気がする。そのままMainActorのメソッドをawaitなしに呼べるので。

えーと、もうちょっと誤解のないように書くと

6:55 AM

@escapingは新世界と旧世界の両方から自分にとって都合のいいように見えています

koher

これ。 https://github.com/apple/swift/commit/5ecb9ebec2168582e0197453ba06b7d556e680fd

このパッチのテストケースがまさにわかりやすいですね。

たまに両方にとっての合法な使われ方（UIView.animateなど）をしている場合がありますが、それは例外で

6:56 AM

ほとんどが DispatchQueueとかCombine のような違法コードになっている

コメントの書き換えが明確に犯罪予告してる

omochimetaru

コメントの書き換えが明確に犯罪予告してる

こう変化したのはわかるし、右のコードが現状で危険なのはわかるんだけど、将来的にどう解決するつもりなのか（解決されないのか）がわからない。最初に omochimetaru の言ってたように強制的に MainActor 投入されるようになるのかもしれないし。

koher

こう変化したのはわかるし、右のコードが現状で危険なのはわかるんだけど、将来的にどう解決するつもりなのか（解決されないのか）がわからない。最初に omochimetaru の言ってたように強制的に MainActor 投入されるようになるのかもしれないし。

強制投入は返り値を持って帰れないから無理ですね

ブロッキングになっちゃうかぁ。

6:59 AM

async にするわけにもいかないしなぁ。

解決方法は難しいですね。

7:00 AM

安全性を達成するには下位互換ぶっ壊して違法認定するしかないけど

7:00 AM

逆に誰もDispatchQueueを使わなくなれば違法のままでも問題が起こらないようにできるかな？

そうすると

This is in line with the long term plan for actor isolation, but opens up some holes in the short term

の long term はどう考えてるの？将来みんながこの API を使わなくなったら安全ってこと？

脱法マーカー付けて締め付けていくのが良いと思いますけどね

7:01 AM

@escapingなんて普通にSwift書いてそこら中に出てくるので、これが脱法状態になってるのはマズい

koher

そうすると

This is in line with the long term plan for actor isolation, but opens up some holes in the short term

の long term はどう考えてるの？将来みんながこの API を使わなくなったら安全ってこと？

昔フォーラムで、Swift5から6の間に警告期間を設けて6では徹底する、みたいなコアチームの意見は見ましたね

omochimetaru

昔フォーラムで、Swift5から6の間に警告期間を設けて6では徹底する、みたいなコアチームの意見は見ましたね

~~https://discord.com/channels/291054398077927425/291054454793306112/890515638613844008~~ https://discord.com/channels/291054398077927425/291054454793306112/890516635738333234 (edited)

for awaitやめてasyncSequence.map使ったらActor跨いで書き込めます！とか記事がQiitaに出てきた日には白目ひん剥いて倒れると思う

omochimetaru

昔フォーラムで、Swift5から6の間に警告期間を設けて6では徹底する、みたいなコアチームの意見は見ましたね

それって、この話ですかね？ https://github.com/DougGregor/swift-evolution/blob/sendable-staging/proposals/nnnn-sendable-staging.md

swift-evolution/nnnn-sendable-staging.md at sendable-staging · Doug...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/nnnn-sendable-staging.md at sendable-staging · DougGregor/swift-evolution

家庭先生が全部回答してた

shiz

それって、この話ですかね？ https://github.com/DougGregor/swift-evolution/blob/sendable-staging/proposals/nnnn-sendable-staging.md

あ！これですこれです。フォーラムじゃなくて文書か。

でも Swift 6 で違法になるってどういうことだろう？ @escaping も non-isolated に戻すってことかな？

7:05 AM

↑のドラフトに書いてあるのかな？

はい、僕はそういう意味で書いてます。

7:06 AM

単純に考えて、@escaping は言葉通りエスケープするのでどこから実行される事もありえるわけだから

7:06 AM

non-isolated　でしかありえないわけで、

7:07 AM

なので暗黙に @Sendable がついてくるんじゃないか。

有り得ないことはないんだよな

isolationを担保できなくない？

7:07 AM

さっき書いたように、返り値があるから。

7:07 AM

あ、async 関数なら、暗黙actor投入をすることができるか。 (edited)

その方向は違法マーカーよりは望ましいと思うけど、 Proposal の

Escaping closures can now be actor-isolated; only @Sendable prevents isolation.

は暫定措置ってことなのかなぁ。

UIView.animateとかがそうだし、AsyncStreamのcontinuation.onTerminationもこれ実質escaping かつ Sendableじゃないか (edited)

UIview.animateの安全性は型からはいえなくて実際の実装が安全ってだけだから、 @UnsafeUncheckedIsolated みたいな

7:09 AM

マーカーを付けるんじゃない。

koher

その方向は違法マーカーよりは望ましいと思うけど、 Proposal の

Escaping closures can now be actor-isolated; only @Sendable prevents isolation.

は暫定措置ってことなのかなぁ。

その差分が出たときのフォーラムのアナウンスに書いてないかしら

7:10 AM

Changes in the second reviewed proposal:

7:10 AM

2版でこんな重大なトピックが出てたのか。

omochimetaru

なので暗黙に @Sendable がついてくるんじゃないか。

これ（ @Sendable でない @escaping なクロージャ）は単に後から実行する単純な計算とかもあるんじゃない？ (Int) -> Int みたいな。計算を DI するような場合とか。

2回めのレビュー後だから3版か？

koher

これ（ @Sendable でない @escaping なクロージャ）は単に後から実行する単純な計算とかもあるんじゃない？ (Int) -> Int みたいな。計算を DI するような場合とか。

単純な計算なら @Sendable チェックを突破したらいいのでは

7:12 AM

クロージャ実装側が { $0 + $1 } とか書いてるだけなら、 @Sendable になってても別に困らない

The rule about @escaping closures being non-isolated was never great: it's always been an heuristic to try to deal with the world where @Sendable has yet to be fully adopted. So instead of making this heuristic part of the actors design, to be removed at some later point, we've removed it from the proposal. Instead, we'll need to rely on dynamic checking where actor code interacts with non-@Sendable`-enforcing code.

https://forums.swift.org/t/se-0306-second-review-actors/47291/4

SE-0306 (Second Review): Actors

There was a little feedback here, but not a lot of discussion. The rule about @escaping closures being non-isolated was never great: it's always been an heuristic to try to deal with the world where @Sendable has yet to be fully adopted. So instead of making this heuristic part of the actors design, to be removed at some later point, we've remov...

omochimetaru

クロージャ実装側が { $0 + $1 } とか書いてるだけなら、 @Sendable になってても別に困らない

サードパーティライブラリの型を使っていて、その型が Sendable に適合してないとかあると面倒そう。

そういうときは自己責任でさっきかいた @UnsafeSendable を使うしかないですね

サードパーティライブラリの型を使っていて、その型が Sendable に適合してないとかあると面倒そう。

これがその文書で提案されようとしている@unsafeSendableに該当しますかね？ The @unsafeSendable attribute indicates that the corresponding parameter (of function type) is intended to be @Sendable going forward. For a client that has not yet adopted concurrency, it will be treated as a non-@Sendable function type. https://github.com/DougGregor/swift-evolution/blob/sendable-staging/proposals/nnnn-sendable-staging.md#supporting-clients-that-predate-concurrency (edited)

shiz

サードパーティライブラリの型を使っていて、その型が Sendable に適合してないとかあると面倒そう。

これがその文書で提案されようとしている@unsafeSendableに該当しますかね？ The @unsafeSendable attribute indicates that the corresponding parameter (of function type) is intended to be @Sendable going forward. For a client that has not yet adopted concurrency, it will be treated as a non-@Sendable function type. https://github.com/DougGregor/swift-evolution/blob/sendable-staging/proposals/nnnn-sendable-staging.md#supporting-clients-that-predate-concurrency (edited)

おお。言語機能としての提供が議論されているのか

shiz

The rule about @escaping closures being non-isolated was never great: it's always been an heuristic to try to deal with the world where @Sendable has yet to be fully adopted. So instead of making this heuristic part of the actors design, to be removed at some later point, we've removed it from the proposal. Instead, we'll need to rely on dynamic checking where actor code interacts with non-@Sendable`-enforcing code.

https://forums.swift.org/t/se-0306-second-review-actors/47291/4

Sendableが普及するまでの処置で、良くないねって言ってますね。

7:17 AM

プロポーザルからはこの部分を除去して、代わりに実行時のチェックに頼る必要があるだろう。

英語むずくない？細かい部分がよくわからん・・・。

7:19 AM

The rule about @escaping closures being non-isolated was never great:

@escaping クロージャが non-isolated になるルールははまったく良くなかった。

non-isolatedなのが古い提案で、この審査で、それをやめた(違法コードを許すようにした)から、そうですね (edited)

7:20 AM

never greatは過去の提案を否定してるだけか。読み違えてた。

7:20 AM

その次の文が大事だと思ってて、

it's always been an heuristic to try to deal with the world where @Sendable has yet to be fully adopted.

つまり、それは常に、 @Sendable が完全に採用されるまでの世界を扱うためのヒューリスティックだ。

これ、「hueristic」が指す仕様がもともとあって、提案から削除されてるんじゃないですかね (edited)

7:22 AM

escaping closureの場合の特殊なルールが(単純に常にnon-isolatedにするわけではないもの？) (edited)

7:22 AM

いろいろ書いてあったんだけど全部やめたよっと。

So instead of making this heuristic part of the actors design, to be removed at some later point, we've removed it from the proposal.

だから、このヒューリスティックを actor の設計の一部とする代わりに、将来のどこかで除去されるものだし、プロポーザルから削除した。

omochimetaru

いろいろ書いてあったんだけど全部やめたよっと。

削除されたのは @escaping クロージャが non-isolated になることじゃない？

diffみてみましょうか

7:24 AM

なんか長い話があった気もしてきたんですよね

7:24 AM

この古い版を読んだ気がする

確かescapingなものは全部Sendableと見なすが元々だったような...

あ、これだ。

If the closure is @escaping or is nested within an @escaping closure or a local function, it is non-isolated.

で、これに対してラトナーさんから反対の意見が出ていました https://forums.swift.org/t/se-0306-actors/45734/4 (edited)

https://github.com/apple/swift-evolution/commit/0a5f21382c19d1c7dc252dc388f0c60e5537d371

[SE-0306] Drop "@escaping implies non-isolated" rule. · apple/swift...

This rule was a hack to try to interoperate with existing Swift code that doesn't understand Sendable. We'll have to deal with this in a different way.

Instead, we'll need to rely on dynamic checking where actor code interacts with non-@Sendable`-enforcing code.

代わりに、 actor のコードが @Sendable であることが強制されていないコードと interact するところでは、動的検査に頼る必要があるだろう。

「 @escaping なクロージャーは non-isolated だよね」というのが、完成された世界では成り立たないんじゃね？ということで、その仕様はやめたということなのか。

うーん、 DispatchQueue の async みたいなスレッドスイッチしちゃうヤバイ @escaping クロージャは将来的に誰も使わなくなるから、それらのために @escaping クロージャを non-isolated にしてると不便だよね（さっきの単純な計算を注入した後から使う例とか）、だからプロポーザルから取り除いて @escaping クロージャも isolated 扱いにしたけど、現状は DispatchQueue の async みたいなやつもいるから危険だよ、ってこと？

> **Rationale**: In theory, `@escaping` is completely orthogonal to `@Sendable`, and a Swift program built entirely with `@Sendable` from the ground up would not have the rule that `@escaping` closures be non-isolated. However, the existing Swift ecosystem is built without `@Sendable`, which leaves us with an unfortunate choice. We can assume that the lack of `@Sendable` on a function type means that the closure won't escape the concurrency domain, and where existing code (i.e., all Swift code that's been written so far) breaks this assumption, we'll have a data race. Or, we can conservatively assume that all existing function types are `@Sendable`, which will prevent all data races, but at the cost of being unable to use even the most basic facilities (such as `Sequence.map`, above). Therefore, we employ an heuristic: `@escaping` is a good (but imperfect) indicator in Swift today that the closure can be executed concurrently, so we don't permit escaping closures to be actor-isolated. This eliminates a significant proportion of the data races that would affect actor state, and the cost of (1) admitting some data races with existing code that manages to execute a closure concurrently without escaping it, and (2) prohibiting some safe patterns where a closure escapes but does not cross concurrency domains. This is a pragmatic, temporarily solution to the problem of rolling out data-race prevention throughout an existing ecosystem. Our approach will ratchet up the safety as code opts in to more concurrency safety in future language versions.

7:35 AM

「理論上は、escapingとsendableは直行する概念だけど、まだsendableが普及してないから妥協をする必要があって、実際escapingはコールバックに使ってることが多いし、escapingならnon-isolated(=sendable)にするヒューリスティックにしようと思うよ」

7:35 AM

みたいな事が書いてあって

7:35 AM

それに対してラトナーが↑で

7:35 AM

「いやいやそれだとマズイでしょ理論上直行するわけで・・・(以下説明)」みたいなツッコミをした結果

7:36 AM

第二回レビューのタイミングでは、escapingに関するヒューリスティック(=sendable)が取り除かれた？

7:37 AM

ラトナー

and it makes perfect sense for a closure to be @escaping without being @Sendable.

7:37 AM

Sendableじゃないけどescapingなクロージャは完全に正しい（ありえる）

やっぱ、完成した世界ではそもそも @escaping かつ non- @Sendable なクロージャが危険な振る舞いをすること自体があり得ないってことなんだろうな。

完成された世界では、スレッドスイッチするのはactorだけであって、actor境界をまたぐときはsendableでないといけない。もし、sendableでない escaping クロージャをメンバに持つ型があったら、その型は sendable にはなれないはず？そうするとその型が actor 境界をまたぐことはないので、問題は発生しない？

完成された世界がActorだけの世界を言うのか、DispatchQueue等があっても検査と文法で上手いことやれるのかのどっちだ

hironytic

完成された世界では、スレッドスイッチするのはactorだけであって、actor境界をまたぐときはsendableでないといけない。もし、sendableでない escaping クロージャをメンバに持つ型があったら、その型は sendable にはなれないはず？そうするとその型が actor 境界をまたぐことはないので、問題は発生しない？

@Sendable でない @escaping なクロージャを呼び出すときは actor context を引き継いでも問題のないコードしか存在しない、ってことじゃないでしょうか。

1

omochimetaru

完成された世界がActorだけの世界を言うのか、DispatchQueue等があっても検査と文法で上手いことやれるのかのどっちだ

DispatchQueue の async 等の壊せる API が（ deprecated を経て）取り除かれるか、 async 等に @Sendable が付与されるかかなぁ。 (edited)

7:41 AM

Swift の世界からは壊せなくなると。

7:41 AM

他言語連携してスレッド使ってとかやったら壊せるんだろうけど。 (edited)

koher

DispatchQueue の async 等の壊せる API が（ deprecated を経て）取り除かれるか、 async 等に @Sendable が付与されるかかなぁ。 (edited)

例えば UIView.animate の受け取るクロージャは、定義側が @MainActor @escaping () -> Void になってればうまくいくんですかね？

それはうまくいきそうだ

@MainActor のときは問題なさそうだけど、他の actor の context で呼び出されたらどうなるんだ？？

利用側が他のActorのcontextの場合、クロージャを定義するところでSendableなものしかキャプチャできなくなるのかな？

あーそうか

他の actor の context で呼び出すのが無理なのでは

(そもそもanimateを呼び出せないけど

全部 await 付けないといけなくなっちゃって、でも async じゃないから何もできないんだ。

うーんつまり整理すると

7:48 AM

@escaping のときに Sendable になってなくて脱法に見えるけど

UIView.animate(withDurations: 0.5, animations: { self.label.alpha = 1.0 // MainActor でないとこれができない })

これは既存APIが脱法実装なのであって、

7:48 AM

言語仕様としては最終的な形として正しいってこと？

そもそもUIViewのコンテキストがMainActorだから

7:49 AM

animations, completionもMainActorなら問題ないよ

UIView.animate は他の actor context でも呼び出せるけど、 animations に渡すクロージャ式の中で UI コンポーネントに触れないから意味のあることができない。

tarunon

そもそもUIViewのコンテキストがMainActorだから

MainActor からだと問題ないですが、別の actor から呼び出したときに long term でどう安全になるんだろうと。

koher

UIView.animate は他の actor context でも呼び出せるけど、 animations に渡すクロージャ式の中で UI コンポーネントに触れないから意味のあることができない。

UIView.animate の呼び出しを含めてまるごと MainActor.run に丸投げするしかないですね

他の actor context から、 sendable じゃないクロージャを渡せるんですかね。そもそも。

hironytic

他の actor context から、 sendable じゃないクロージャを渡せるんですかね。そもそも。

animations に @Sendable が付与されるはずってことですか？

hironytic

他の actor context から、 sendable じゃないクロージャを渡せるんですかね。そもそも。

Actor ContextをまたぐときはSendable closureしか渡せない、というのが良いのでは

Sendableなのはその通りだと思いますよ

omochimetaru

Actor ContextをまたぐときはSendable closureしか渡せない、というのが良いのでは

そう、それが良いと思うので。

hironytic

そう、それが良いと思うので。

でも、まだそういうルールは整備されてない？ってことかしら

↓自体は完全に合法で actor context もまたいでなくないですか？ // MainActor でない何かの Actor UIView.animate(withDuration: 0.5, animations: { })

koher

↓自体は完全に合法で actor context もまたいでなくないですか？ // MainActor でない何かの Actor UIView.animate(withDuration: 0.5, animations: { })

僕が思ってる理想の解決方法だと、 animations が、 @MainActor 宣言されているので、そこで作っているクロージャは MainActor コンテキストになっていて、作っているコンテキストはotherActorなので、そのクロージャは@Sendable になるんだけど、中身が空だからキャプチャが無いのでsendableチェックを突破できて動く。

7:55 AM

あれでも、 @MainActor ってのも変な気がしてきたな。動的なActorのときは同じようなことをどうやればいいんだ。

omochimetaru

僕が思ってる理想の解決方法だと、 animations が、 @MainActor 宣言されているので、そこで作っているクロージャは MainActor コンテキストになっていて、作っているコンテキストはotherActorなので、そのクロージャは@Sendable になるんだけど、中身が空だからキャプチャが無いのでsendableチェックを突破できて動く。

それだったら UIView.animate に @MainActor が付与されて、 animations は @Sendable が強制される、他の Actor から呼ぶときは await 必須、かなぁ。

7:56 AM

await するといってもアニメーションが終わるまで待つんじゃなくて、メインスレッドで発火されるまで suspend 。

koher

それだったら UIView.animate に @MainActor が付与されて、 animations は @Sendable が強制される、他の Actor から呼ぶときは await 必須、かなぁ。

それだったら、とは？

7:57 AM

反論されているのか同意されているのかよくわからない

omochimetaru

それだったら、とは？

animations が @MainActor よりも UIView.animate が @MainActor がいいかなと。

UIView.animate 自体が @MainActor 宣言されると、引数の animations も MainActor外から渡すときはSendableになるからか。

はい。

どうなんでしょう、もともと UIView.animate が、メイン以外から呼んでも良い仕様なら、

Sendableがわからなくなってきた

それは仕様をせばめちゃってますよ

omochimetaru

それは仕様をせばめちゃってますよ

完全な世界を作るのは仕様を狭めるんじゃない？

asyncからしか呼べなくなる影響が一番大きいのかな。

omochimetaru

asyncからしか呼べなくなる影響が一番大きいのかな。

MainActor から呼ぶときは同期的だし、大体問題ないのでは。

koher

MainActor から呼ぶときは同期的だし、大体問題ないのでは。

処理本体をメインスレッドでやらないスタイルがありえるのかなと思って。

どうしても他の Actor から呼ばないといけないときは↓でいいし。 Task { await UIView.animate(...) }

アニメーション周りだとミリ秒単位の応答性が気になりそうな気がしてた。

今ちょうどアニメーション伴うところでasync await使えねーなってなってるところでした

completion も async で受け取るのがいいのかな。

view.setNeedsLayout() と viewDidLayoutSubviewsを使ってループさせて、微妙なレンダリング完了の隙間にエフェクトを差し込むみたいなテクニックがあるんですけど、これをasync sequenceを使うように書き換えたらスレッド跨ぐのでちらつきが見えるようになっちゃった

// UIView @MainActor class func animate(withDuration duration: TimeInterval, animations: @escaping () -> Void) async -> Bool

(edited)

AsyncStreamのyieldが全然yieldじゃないw

tarunon

view.setNeedsLayout() と viewDidLayoutSubviewsを使ってループさせて、微妙なレンダリング完了の隙間にエフェクトを差し込むみたいなテクニックがあるんですけど、これをasync sequenceを使うように書き換えたらスレッド跨ぐのでちらつきが見えるようになっちゃった

UI周りだとやっぱりうかつなawaitはチラつきになるかあ

全然だめですね、このあたりはJavaScriptのasync generatorの方が優秀だな

動画関係の処理でも、bufferのライフタイムが厳しくてactorのメソッドにbuffer渡すとawaitしてる間にバッファ死んでしまいましたね

Taskのpriorityに.realtimeが欲しい

Iceman

動画関係の処理でも、bufferのライフタイムが厳しくてactorのメソッドにbuffer渡すとawaitしてる間にバッファ死んでしまいましたね

それはコピーが必要そうな・・・。

Iceman

動画関係の処理でも、bufferのライフタイムが厳しくてactorのメソッドにbuffer渡すとawaitしてる間にバッファ死んでしまいましたね

従来の「あるスレッドでコールバックが呼ばれる」系のAPIは、その呼出の間に同期的に作業を終えないといけない仕様な事が多い

8:07 AM

従来のというかメディア系はだいたいそう

既存コードがコピーナシでうごいてるのでコピー避けたくて、結局actorを諦めました

メディア系だと性能のためにコピーを嫌ってロックで制御してるから。

kotlinのrunBlocking相当の操作はあると嬉しいなと思いました

tarunon

全然だめですね、このあたりはJavaScriptのasync generatorの方が優秀だな

ただまあ、これからはnon-asyncであるか、asyncでもawaitが無ければ同期的だからチラつかない、ということを意識するというだけであって

Iceman

既存コードがコピーナシでうごいてるのでコピー避けたくて、結局actorを諦めました

それだと同期的に処理する必要があるし、 actor は向かないように思います。

従来の、コールバックを挟むとチラつくので気をつける、の見た目が変わっただけでは？

8:10 AM

元からあった課題の見た目が変わっただけで課題が増えたわけではないというか。 (edited)

課題は増えてないけど、解決を期待したボイラープレートがそのままになっちゃうのは残念ですね

課題は増えてないけど見た目が気づきにくい感じになったような

なるほど

そうか、本質的にasync awaitは待ち受けでしかなくて割り込みの概念はないんですね

8:16 AM

それだとコールバックパターンの完全な置き換えには成り得ないな

割り込みの概念？

var done = (() -> Void)? func a() async { await withUnsafeContinuation { continuation in done = continuation.resume } // A } func b() { done?.() // B done = nil }

こういうコードがあったときに、同一Actor上で await a(), b()の順番で呼び出した時に //B -> //A の順番で実行されるってことですね

8:20 AM

//A -> //B になっていてほしい。もしa()の処理の先にもう一個awaitがあったら、はじめてそこで//Bに帰ってくる、みたいな

8:20 AM

この辺が他の言語のyieldとかなり違うし、UI、特にアニメーションで使えないねとなる原因でもある (edited)

omochimetaru

Actor ContextをまたぐときはSendable closureしか渡せない、というのが良いのでは

Swift5.6だと警告が出るので、Swift6ではエラーになりそうですね。 Cannot pass argument of non-sendable type '(() -> Void)?' across actors

tarunon

var done = (() -> Void)? func a() async { await withUnsafeContinuation { continuation in done = continuation.resume } // A } func b() { done?.() // B done = nil }

こういうコードがあったときに、同一Actor上で await a(), b()の順番で呼び出した時に //B -> //A の順番で実行されるってことですね

await a() b() ↑こうかいたら、 // A が終わるまで、 await a() が返ってこないので、 // A -> B の順番にならんか？

デッドロックになりそう

あ、done が共有されてるのか、そこを読めてなかった、もう一度考える (edited)

多分、yieldはyieldで別の言語機能として出てくるから、async awaitはこれで良くって

8:30 AM

今使おうとしたのは用途外ってことだろうね

いや、やっぱり同じじゃないのか？ // A に到達しないんじゃない？

Task.init { await a() } b() 正確にはこう

あ、なるほど。

8:33 AM

bの中のdoneの呼び出しの瞬間、同期的に全てが連鎖してaが完了することを期待していたけど

8:33 AM

aの中のawaitが戻ってくる前に、bが進行するってことね

そうそう

8:33 AM

特にUIの微細な調整はそれだと困るんだよね

それは、aを Task.init で退避したからじゃないか？

だからこの実装パターン自体が間違っていて

8:34 AM

yieldの言語仕様の出現を待つしかないって話

aの中のawaitのところで、いまのTaskに戻ってくるhopが刺さってるよね

継続を同期で作れば解決しないですか？ (edited)

tarunon

だからこの実装パターン自体が間違っていて

なるほど。主張の中身はわかった。

8:35 AM

なんかうまいこと書けばやりたいことを正しく記述できる気もする。。

同期にしたら全部解決するよ。これVoidだからだけど、値渡しとかもあるときに、もうちょっと現代的に書きたいな、async awaitは使えんやろか、使えんか。って感じ (edited)

ふむ

shiz

Actor ContextをまたぐときはSendable closureしか渡せない、というのが良いのでは

Swift5.6だと警告が出るので、Swift6ではエラーになりそうですね。 Cannot pass argument of non-sendable type '(() -> Void)?' across actors

おおそうなのか。やっぱりそういう考え方であってそうですね。

8:36 AM

まだ「割り込み」の気持ちがわからないな。

8:36 AM

aとbのどっちがどっちに割り込んでるの？

割り込んで欲しいのは//Aがbの実行に割り込んで欲しいって感じかな

8:37 AM

async awaitはそういうのはない

doneはそのためのカスタムポイントって感じ？

yieldとして使おうとしたってことですね

あーわかった

8:38 AM

doneが呼ばれたときに、aが走るように、ストッパーみたいにしたかったのか

8:40 AM

ああそれでyieldという話が出てくるのか

8:42 AM

同期的な「次の suspension pointまで実行を再開」する機能をSwift asyncで実装できるか、という問いなんだ

8:44 AM

無理そうな気がする。 Generatorをawaitを使って書けるラッパーを実装できないか考えてみたけど、 yield側とdrain側の両方でどこかしらawaitを書くことになっちゃってどうしても待ちが出そうだ。 (edited)

async awaitはまあいいけど、AsyncStreamのcontinuationの受け取りがyieldなのは、オマエ〜〜〜って感じになった

ああ、continuation.yieldはそのまま先に進むからか

進まないンゴ

8:50 AM

yield(嘘)

8:50 AM

ああ、進むのは、AsyncStreamのcontinuation.yieldの先の行にさっさと進んじゃいますね

JSとかのは呼び出し側が.next()相当のやつを呼ばないとyieldの先に進まなかったよなと

そうそう

そういう協調して動くカスタムExecutorを作ればいけそう

8:53 AM

いけるかな

AsyncStream.Continuation のメソッド名は yield だから、generator的なものかと思ってしまうということか。

完全に期待しちゃったよね

カスタムExecutorって部分的に指定するとかってできるんでしょうか？

アクターにExecutorを指定できるんですよ

actor Generator { ... }

8:56 AM

こんな感じにできるかもしれないってことか

そうそう

激アツそう

ただconsumer側もproducerと同じactorにジョブを投入する必要があるので、記法が微妙になるかも (edited)

おお。actorの宣言時にExecutorを指定するための何らかのシンタックスがある？

何だったかな、computed propertyが指定できるんですよね

結局MainActorで実行ができないから、UIに当てれないみたいな結果になりそうw

var serialExecutor だっけ (edited)

https://github.com/apple/swift/blob/e1a9be5dacd4f0ea9c41412cb80dee50208fc550/stdlib/public/Concurrency/MainActor.swift#L22

8:59 AM

これだこれ

tarunon

結局MainActorで実行ができないから、UIに当てれないみたいな結果になりそうw

これになりそう…

MainActor は特別なものじゃなくて @globalActor がついただけの型名なのか。

Yuta Saito

これになりそう…

あ〜なるほどね

omochimetaru

MainActor は特別なものじゃなくて @globalActor がついただけの型名なのか。

Android で GL スレッド必須とかあったけど、ああいうので @MainActor みたいな @GLActor 的な @globalActor も作れるんじゃないかと思ってる。 (edited)

お〜 Actor プロトコルがそもそもあってそれを使うのか

9:01 AM

すべてのactorは暗黙的に Actor にconformしてると

koher

Android で GL スレッド必須とかあったけど、ああいうので @MainActor みたいな @GLActor 的な @globalActor も作れるんじゃないかと思ってる。 (edited)

GLスレッドはGLSurfaceViewごとにあるからglobal singletonにはならなそう。

あれ？そうだったか。じゃあただの actor だ。

GLSurfaceViewごとにGLContextとスレッドが作られる。

9:03 AM

global actorって、ようするに、

9:03 AM

見えない引数としてただのactorが来てるのと同じ事になるんだろうか？

9:04 AM

ただのactorだとインスタンス同一性が動的になるから、静的に解析できるglobal actorじゃないとできないこともあるのかな？

型やインスタンスを越えて actor-isolated な API を散らばらせられますよってだけじゃないのかな？

ああそうか、ただのactorの場合は散らばらせることはできないか

9:05 AM

isolatedなコードを書きたければ、actorにたいするextensionとして書く必要があるから

9:05 AM

全部そのactorのメソッドの形で集約してしまう？

だし、同じ型の actor でも異なるインスタンスだと別 actor になっちゃうし。

extension にしないで引数で受け取る方法があった気がするんですよ

MainActor.run ?

runじゃなくて

9:07 AM

関数の引数にActorを受け取りつつ

9:07 AM

この関数の本文はこの引数のActorの中だとしますよって記法

isolated ですか？

https://github.com/apple/swift-evolution/blob/main/proposals/0313-actor-isolation-control.md#actor-isolated-parameters

shiz

isolated ですか？

それだ！

func deposit(amount: Double, to account: isolated BankAccount) { assert(amount >= 0) account.balance = account.balance + amount }

お～

おお

思い出してきたぞ。

これで同期的操作ができるのでは

いや、shizさんに思い出させてもらったんですけど

9:09 AM

なので知りたいのは

9:09 AM

globalactorはようするに、これを省略してるだけと本質的に同じか？ってこと。

sharedな気持ち以外は同じっぽい

それなら、 func foo(param: Int, gl: isolated GLActor) みたいな感じができるのかも。

いけそう

9:14 AM

GLActorインスタンス側からactor contextをもらえない場合にrun的な逃げ道は必要そうだけど

Yuta Saito

GLActorインスタンス側からactor contextをもらえない場合にrun的な逃げ道は必要そうだけど

MainActor.run の意味もよくわかってないんだけど、

9:15 AM

これはどうして全てのactorに生えてなくて、MainActorの実装なの？ (edited)

なんでだろう

ActorからUnownedSerialExecutorが取れて、そこからenqueueが呼び出せるから

9:17 AM

なんかどのActorでもできそうな気もする

特別なことをしてるわけじゃないから任意のactorで出来るはず

9:17 AM

あ、

9:18 AM

~~任意のactorではなくglobal actorが正確だ~~ いやそんなことないな。actorで出来るな (edited)

enqueueできるのはjobだからクロージャは入れられないか。

https://github.com/apple/swift/blob/e1a9be5dacd4f0ea9c41412cb80dee50208fc550/stdlib/public/Concurrency/MainActor.swift#L46-L58

Yuta Saito

https://github.com/apple/swift/blob/e1a9be5dacd4f0ea9c41412cb80dee50208fc550/stdlib/public/Concurrency/MainActor.swift#L46-L58

bodyに@MainActor がついてるから？

9:20 AM

/// A service which can execute jobs. @available(SwiftStdlib 5.5, *) public protocol SerialExecutor: Executor { // This requirement is repeated here as a non-override so that we // get a redundant witness-table entry for it. This allows us to // avoid drilling down to the base conformance just for the basic // work-scheduling operation. @_nonoverride func enqueue(_ job: UnownedJob) /// Convert this executor value to the optimized form of borrowed /// executor references. func asUnownedSerialExecutor() -> UnownedSerialExecutor }

9:20 AM

nonoverride ってなんやねん

omochimetaru

bodyに@MainActor がついてるから？

そうですね

Yuta Saito

そうですね

Actorのメソッドの引数のクロージャに「 @SelfActor 」みたいな指定を付ける方法がない？

そうそう

9:23 AM

文法の問題

マジか。

selfのactorにhopするのは普通に出来るので

9:24 AM

あー、でもインスタンスの同一性を気にした静的なactor-isolation検証がムリ？

そうか、仮に isolatedWithSelf が指定できたとして、

9:28 AM

actor FooActor { func hoge() func run(body: isolated(self) () async -> Void) } func body(actor: FooActor) { // このactorと actor.run { // このactorの同一性が静的に必要？ // actor に isolatedなので↓にawaitは要らない actor.hoge() } }

(edited)

そうそう

Yuta Saito

そうそう

うーんでもこのくらいシンプルなケースならキャプチャしてる同じ変数だからOKぐらいの検証はできそうよ (edited)

頑張ればできるか…

9:31 AM

actorのメソッドとして書けばselfが不変というのは強力な前提なんだな

self 不変なるほど。

9:32 AM

run がないのが、いまは↑で書いたような実装とか文法仕様がないから作れないよってだけなのか、それとも本質的に、一般にrunを提供するとactorシステム上の意味論上の安全性の問題などがあるのか、気になります。 (edited)

waiwaiの途中だけど・・・さっきの Publisher の購読、 extension なしだとこれでいける気がする。

override func viewDidLoad() { super.viewDidLoad() let task = Task { [weak self] in guard let state = self?.state else { return } for await _ in state.objectWillChange.values { guard let self = self else { return } // state を View に反映する処理 self.nameLabel.text = state.user?.name } } cancellables.insert(.init { task.cancel() }) }

(edited)

これは。。。。

for await _ in ここで受け取った値を使わないと壊れるのでは？と思ったのと

12:49 PM

cancellables.insert(.init { task.cancel() }) このためにCombineをimportするのはやっぱりなんか違う気がするな〜

@hironytic ↑ extension よりはちょい面倒ですが、 extension なしならギリ許せるレベルかとおもいますがいかがでしょう？

stateがObservableObjectなのかな

tarunon

stateがObservableObjectなのかな

あ、そうです。 state は ObservableObject で、 objectWillChange を購読してます。結局元々 import Combine してるのでいいかなと。

1

extensionなしだと、そうなりますね！

12:53 PM

2つ以上購読するとき、task 変数の名前を考えるお仕事がでてきますね

1

hironytic

2つ以上購読するとき、task 変数の名前を考えるお仕事がでてきますね

こういうのは var task にして逃げることあります。

まあそれはあり

12:55 PM

Kotlinのスコープ関数的なものがあればいいのにな

スコープ関数自作して使ってます

12:56 PM

https://github.com/omochi/WeaselRoll/blob/main/Sources/WeaselRoll/Basic/Scopeable.swift

WeaselRoll/Scopeable.swift at main · omochi/WeaselRoll

Contribute to omochi/WeaselRoll development by creating an account on GitHub.

12:57 PM

これを使う場合だと extension Task: Scopeable {} Task { ... }.let { (x) in cancellables.insert(.init { x.cancel() }) } (edited)

それだと名前を考えなくて済む（ただそれだけですがw）

僕は do でスコープ切りますね。

extension がちょっとでも出るなら Task { ... }.dispose(to: &bag) にしちゃうし、実際その方が楽。

ようやく一日以上考えて ObservableObject の objectWillChange を subscribe する答えが得られた・・・。 Swift Concurrency むずい。

12:59 PM

チートシート直さないと・・・。

willChangeのはSwiftUI最初期のころにこれdidChangeだと壊れるくね？みたいな話があった気がする

tarunon

extension がちょっとでも出るなら Task { ... }.dispose(to: &bag) にしちゃうし、実際その方が楽。

.let 生やすぐらいなら専用の dispose(to:) つくったらいいね。

Publisher に限ればどうせ Combine だし、ひろんさんの extension が一番手軽そう。

もはや毎回.dispose(to: ) 書くのも怠いな

問題は .store(in:) を書くのを忘れても警告が出るわけでもなんでもないことですね

tarunon

もはや毎回.dispose(to: ) 書くのも怠いな

僕はViewControllerに対して addAction みたいなメソッドはやしてて、この話題で言うところのTaskとcancellablesへの登録をいっぺんにやってますね。

1:02 PM

それはRxSwiftで組んでるけど、Swift Concurrencyになっても同じようにすると思う。

hironytic

問題は .store(in:) を書くのを忘れても警告が出るわけでもなんでもないことですね

あー、 Task.init が @discardableResult だからか。そこが sink と違うのか。 (edited)

1:04 PM

そうだ、昼書こうと思って書き忘れたんだけど、 AsyncSequence を考えると Task.init の implicit self capture はよくなかったのでは？

Task<T, E>から.cancelを取り出すresultBuilder使ったら、

AnyCancellable を返す Task のようなものがあれば

self.bag = bag { Task { ... } Task { ... } Task { ... } } みたいに出来る気がする

1:05 PM

結局AsyncSequenceが出てきたら、implicit self captureだろうがなんだろうが

1:06 PM

問答無用でタスクが破壊される vs うっかりメモリリークする　の構図でしかなくて、

1:06 PM

Taskをキャプチャしたら結局メモリリークするのには変わらない、ということになったと思います。今のCombineと同じで。

tarunon

結局AsyncSequenceが出てきたら、implicit self captureだろうがなんだろうが

implicit self captureだとself.も[self]も書かなくてもアクセスできるので、うっかりが起こりやすくないですか？

うーん、AsyncSequenceに終端があれば問題ないはずなんですよね

1:19 PM

なんというかそれってfor文使うと無限ループして危ない！と言っているのと変わらない気がしていて

1:19 PM

いくつかの用途では終端=selfのdeallocになりがちなので、って話だからなんですけど

1:19 PM

それはもうちょっと他の落とし所があるんじゃないかなと思います

1:21 PM

こんぐらい宣言すればめちゃ快適になれそう

1:21 PM

TaskBagはdeinitでキャンセルしてるだけのclassでし

hironytic

AnyCancellable を返す Task のようなものがあれば

extension Task: Cancellable {} Extensionは↑これだけにして AnyCancellable(Task { ... }).store(in: &cancellables) とすれば、 .store(in:) 忘れたら怒ってくれます。 AnyCancellable から忘れたらどうしようもないけど (edited)

なお無理にResultBuilder使わなくてもTaskBagに可変調引数のinitを生やしたらそれでいいっちゃいい

@koher ↑↑どうでしょう

hironytic

extension Task: Cancellable {} Extensionは↑これだけにして AnyCancellable(Task { ... }).store(in: &cancellables) とすれば、 .store(in:) 忘れたら怒ってくれます。 AnyCancellable から忘れたらどうしようもないけど (edited)

そのconform面白いですね。cancelメソッドが生えてるんだし実際ただしい。

むしろ Cancellable は Foundation にあってほしいw

Conccurency.Task.CancellationError があるのだから、 Conccurency.Cancellable があって良さそう。

1:29 PM

いや、Concurrencyだと、CancellableなものがTaskしかないから、要らないのか。

うーーん、やっぱり複数の場合はTaskGroupを使うでいいのではないでしょうか？

1:35 PM

ViewControllerのdeinit自体を一つのTaskのcancelと見做して、それに連なるTaskのインスタンスを全てChildTaskであるとすれば、ごく自然な実装になる

たしかに、同じ箇所で起動する購読Taskは、一つのTaskGroupにまとめられるはずかも。同じ箇所で起動したなら解放タイミングが同じはずだから。

hironytic

@koher ↑↑どうでしょう

store(in:)はCancellableであれば使えるから https://developer.apple.com/documentation/combine/cancellable/store(in:)-95sfl AnyCancellableで囲む必要はない？

お、そうなんですね！

1:46 PM

いやしかしAnyCancellableで囲まないと、 .store(in:) なしでは怒ってくれない

Task.init が discardable なのってなんでなんでしょう。

hironytic

いやしかしAnyCancellableで囲まないと、 .store(in:) なしでは怒ってくれない

でも結局囲み忘れたら怒ってくれないのでは

原則として、そのうち停止するはずだから？

キャンセルしない場合は多いから？投げっぱなしでいいやつ

omochimetaru

Task.init が discardable なのってなんでなんでしょう。

戻り値使わないこともおおいので。

koher

でも結局囲み忘れたら怒ってくれないのでは

その通りですw

@IBAction で非同期発火とか。

うーん。投げっぱなしで良いことはほぼなくて、副作用が起きる前にコンテキスト的なものの終了に合わせてキャンセルする必要があるのは、非同期の原則だと思うんですよねえ。

1:49 PM

副作用が起きるところで、「終了してたら何もしない」って制御を入れる方式だと、そのタイミングまで無駄に計算リソースを使ってしまう事になるし。まあ負荷的な実害はほぼないけど。 (edited)

omochimetaru

副作用が起きるところで、「終了してたら何もしない」って制御を入れる方式だと、そのタイミングまで無駄に計算リソースを使ってしまう事になるし。まあ負荷的な実害はほぼないけど。 (edited)

UIViewのアニメーションとかわざわざ停止しなくない？

というか、終了してたら何もしないという分岐をするぐらいなら、終了するときに止めればいいじゃん、という。

koher

UIViewのアニメーションとかわざわざ停止しなくない？

あれは特殊で、アニメーションが終わる前から、見かけの値はコミットされるので、

投げっぱなしは無いにしても、Storeしないと勝手にキャンセルされる、は論外で

表示がディレイしてるだけで見かけ上は同期な感じなんですよね。

何もしない分岐って大抵 guard let self = self else { return } で実現されてるから余分にすることあまりないのでは？

まあ、アニメーションの終わりをつなげたいときは、話が違うんですけど。

TaskがdiscardableResultなのが行き過ぎなのかもしれないって話ではありそう

koher

何もしない分岐って大抵 guard let self = self else { return } で実現されてるから余分にすることあまりないのでは？

その分岐を実行するコストに違和感を持ってますね。

確かに投げっぱなしたいときは _ = Task { } にしてる方がむしろわかりやすいかもしれない

「終了してたら何もしない」よりは、「終了するときに止める」のほうが、シンプルに、あるべき状態だと思うって話です。

1:53 PM

「終了してるけど何もしない残像がちょっと遅れて残る」のは、状態管理的にも気持ち悪いです。

omochimetaru

「終了してたら何もしない」よりは、「終了するときに止める」のほうが、シンプルに、あるべき状態だと思うって話です。

そこに実際問題になるほどのオーバーヘッドが存在しないなら、コードをシンプルに保ちたい。ダウンロードとかは止めるとして。

URLSessionとか昔からあるAPIは基本そういう設計になっていて、cancelメソッドとかで停止した場合、ギリギリのタイミングだったとしても、コールバックとか呼び戻されることは無いんですよね。

まあ実際にトランザクション走るようなコードとか大量に走ってオーバーヘッドが問題になるような箇所じゃ無ければ真面目にキャンセルしないですよね

koher

そこに実際問題になるほどのオーバーヘッドが存在しないなら、コードをシンプルに保ちたい。ダウンロードとかは止めるとして。

いま話してるようなcancelを呼ぶコードを最後にちょっと付け足すぐらい、十分シンプルなままだと思います。

RxSwiftは人間が考えなくてもちゃんとキャンセルされるようにできていて、あれはあれで整っていた

むしろ、initしっぱなしで忘れるリスクのほうが、本当に止めたいダウンロードみたいな処理が出てきたときに、見逃すツケのほうが高くつきませんかねえ

1:57 PM

https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#unstructured-tasks-1

1:58 PM

The initializers are marked with @discardableResult because the task itself will immediately execute the operation and run to completion when the handle is unused. This is a fairly common use case for fire-and-forget asynchronous operations.

確かに Task.init が @discardableResult じゃなければ、 extension Task: Cancellable {} だけで十分なんですね。storeしないと勝手にキャンセルされるわけではないし、何もしなければ警告が出るし、 store(in:) が Cancellable で利用できるなら、storeしたら、bagの削除とともにキャンセルされるようになるし。 (edited)

hironytic

確かに Task.init が @discardableResult じゃなければ、 extension Task: Cancellable {} だけで十分なんですね。storeしないと勝手にキャンセルされるわけではないし、何もしなければ警告が出るし、 store(in:) が Cancellable で利用できるなら、storeしたら、bagの削除とともにキャンセルされるようになるし。 (edited)

そうそう。

2:00 PM

「fire-and-forgetなユースケースはよくある(fairly common) 」だかららしい。

それ自体は間違ってないと思う

2:01 PM

まあでもバランス考えるとたしかに

2:01 PM

discardableResultとimplicit self captureは行き過ぎのような気がしてきたな

and run to completion when the handle is unused

↑ここはどういう意味だろう。

tarunon

discardableResultとimplicit self captureは行き過ぎのような気がしてきたな

まあ0304はレビュー終わっちゃったんで今更なんだけどね・・・

どっちにしても、UIKitよりはSwiftUIの方を見て仕事してそうだなとは思いますね

omochimetaru

and run to completion when the handle is unused

↑ここはどういう意味だろう。

ストアしなくても勝手にキャンセルされるわけではない、ってことかなあ。。。 (edited)

hironytic

ストアしなくても勝手にキャンセルされるわけではない、ってことかなあ。。。 (edited)

ああなるほど。もし、deinitで自動キャンセルな仕様だったら、まずいけど、そうじゃないから最後まで行くよってことか。

2:04 PM

逆説的な説明になってるな。そういう順番で考えてたのか。

sinkの場合はcancellableをretainしておかないと解放されちゃうというのがあって、CombineだとFutureでも投げっぱなしにできなくて面倒みたいなのはあった。

なるほど。

2:06 PM

止まるときに止めたらいいは、僕の意見だから、まあそこは、guard returnすればいいなら楽でいいという立場から考えると

2:06 PM

それでもまだおかしいことになってると思ってて

2:06 PM

AsyncSequenceが導入されたことによって、

2:07 PM

終了しないfor - await が出てくるようになって、それをセットアップするためのTaskを作るのがセオリーになっているから、

2:07 PM

そういうTaskは、for-awaitを止めるためのcancelチェインが必要なので、

omochimetaru

まあ0304はレビュー終わっちゃったんで今更なんだけどね・・・

どっちもAsyncSequenceとの組み合わせがあまり考えられてなさそうな。implicit self captureはともかく、discardableResultは警告の問題だし将来変えられるかも？

そこがもうちょっとなんとかなんねーかなっていうのは思う

↑のfairly commonが覆されてるのが、ねじれているところじゃないかしら。

ループ構造とキャプチャ対象が循環しなければ

2:08 PM

別にTaskをガチャガチャやんなくていいんす

koher

どっちもAsyncSequenceとの組み合わせがあまり考えられてなさそうな。implicit self captureはともかく、discardableResultは警告の問題だし将来変えられるかも？

ですね。 async sequenceに対する無限forループを構築するときの書き方だけの話なら、それようのオペレータというか書き方が別に提供されるのでもいいのかも。

Task { [weak self] in for await ... { /* guard let self*/ } } てか別に

なんかこれ以上楽にならない気もするな。

guard let self else return いれてれば

2:10 PM

Taskはキャプチャいらんがな

2:10 PM

勝手にbreakしてTaskは終わる

元のstreamが別の方法でdeinit経由で終了すればいいだけか。

2:10 PM

NotificationCenterとかは駄目だよね。

いやちゃんと終わるはず

元のstreamが終わらないとだめ

だめなんですかぁ

guard let が動くのが、次の値が来たときですよね。

Streamへの参照がなくなっても、Taskが勝手に終わらないのルールがあっちゃうからダメなのか

2:11 PM

いやぁ？？

hironytic

guard let が動くのが、次の値が来たときですよね。

いや、そこは、async iterator . next がnilを返して止まるんで、guardにいかずに、forが終わります (edited)

いやそれはTaskをcancelしたら、ですよね。

元のstreamが解放されるときにも停止する実装だったら止まる。

それはそう

停止すると思いますね

ただ、NotificationCenterからくるasync sequenceとかだったら

AsyncStreamのcontinuationに、onTerminationっていう開放用のハンドラがある

やっぱりunsubscribeをしないといけない

しなくていいよ

2:13 PM

開放されるなら、だけど

NotificationCenter.mainはシングルトンだから解放されないので。

unsubscribe（cancel）しないとonTerminationが呼ばれないんじゃないですかね。

ちょっとためしてみよう

2:14 PM

onTerminationが呼ばれるなら、Notificationも多分管理いらないと思います

2:15 PM

なぜならNotificationCenterとAsyncSequenceのオブジェクトは別なので

2:15 PM

AsyncSequenceがonTerminateで購読破棄をして、NotificationCenterからAsyncSequenceへの参照がなければ成立しますね

tarunonが想定してる挙動だといったい何を起点に全体が停止するん？

[weak self] <-このselfが消えたらguard let self = self else { break or return } でループの外に出てTask自体が完了し

onTerminationが呼ばれるのが、for await を break で抜けたとか、AsyncSequenceのprefixで先頭から指定した数だけきたら終わるとか、そういうときじゃないと

その結果キャプチャされていたAsyncSequenceのRefCountが0になる

tarunon

[weak self] <-このselfが消えたらguard let self = self else { break or return } でループの外に出てTask自体が完了し

なるほど。そのguardはfor-awaitの本文に書いてあるguardだよね？

そうだね、最低その処理は書かないといけないから

その guard let self = self に流れるのが、次の値がきたときだから、次の値がこなかったら流れないように思うんですよね

俺の想像だと、for - await の頭のところでawaitしてて、本文に突入してないから、値が来るまでそのguardによる脱出ができないと思うんよな。

そっちに寄せてるんじゃないだろうかというのはSwiftConcurrencyの内容を確認した時からそう思っていることで

2:18 PM

それは問題じゃないってことなんじゃないですかね

2:18 PM

問題だとしても些細な話ということだと思う

omochimetaru

俺の想像だと、for - await の頭のところでawaitしてて、本文に突入してないから、値が来るまでそのguardによる脱出ができないと思うんよな。

そうそう、ぼくも同じ意見で。NotificationCenterに登録したけど一度もNotifyされない場合とか、ずっと登録したままじゃないかと。

投げっぱなしでええんやでっていう意見に、それが問題であったとしても些細な話っていうニュアンスが含まれていると思うんですよね

2:20 PM

discardableResultがその結果出てきたものという気がする

投げっぱなしの話は「and run to completion」だからってのはわかるんだけど for-awaitだと、run to completionしないから、おかしくね、という疑問を持っているところ。

まぁimplicit self captureは失敗だけど…

過去に議論されてないかなあ。

フォーラムで軽く検索したけど見つからず。

ところで Task.init （旧 async ）は外側のactor contextが引き継がれるのに、 TaskGroup.addTask （旧 TaskGroup.async ）は引き継がれないのはなぜ

2:34 PM

複数の場合は TaskGroup を使えばうんぬんというのを試してみようと思ったんですが

Task { await withTaskGroup(of: Void.self, body: { group in group.addTask { // ここが non-isolated になっちゃう } group.addTask { // ここが non-isolated になっちゃう } }) }

2:36 PM

いや、なぜかといえば、 @Sendable なクロージャーを取るからなんですが、 Task.init と同じ扱いにしてないのはなぜ、という意味で。

extension NSObjectProtocol where Self: NSObject { func observe<T>(keyPath: KeyPath<Self, T>) -> AsyncStream<T> { AsyncStream { continuation in let observation = self.observe(keyPath, options: [.new]) { _, change in if let newValue = change.newValue { continuation.yield(newValue) } } continuation.onTermination = { @Sendable _ in print("onTermination") observation.invalidate() } } } }

こういうの生やして実験してみたけど

2:44 PM

onTermination発火してましたよ

2:44 PM

で、NotificationCenterもこれと同じような実装になっていて、破棄されるんじゃないかと踏んでいます

おお？

最後の1回が呼ばれないとonTermination発火しないから終わらねーじゃん、はまあそれはその通り。

2:48 PM

でも投げっぱなしでオッケー✨っていう価値観なら、無害なクロージャと化したTaskは大した問題ではないに分類されると思います。

tarunon

最後の1回が呼ばれないとonTermination発火しないから終わらねーじゃん、はまあそれはその通り。

ああ、最後の一回はそうなのね。そうするとそのクロージャからキャプチャしてる参照から思わぬオブジェクトがつながっててメモリリークが問題になりそうだから、その方針は厳しいんじゃないか。 (edited)

その場合はそもそもweak selfがnil化しないから

2:51 PM

ところで continuation.onTermination の引数は

2:51 PM

cancelled or finishedのenumで

2:52 PM

多分for文が最後まで回ったかどうか、がここに来るんだと思います

2:52 PM

breakならcancelled

tarunon

その場合はそもそもweak selfがnil化しないから

たしかに多くの場合で循環が問題になるのはselfがリークしてる場合ではあるな。

利用側はこんな感じね

 Task { [weak self] in guard let observeFoo = self?.observe(keyPath: \.foo) else { return } for await foo in observeFoo { guard let self = self else { return } self.printFoo(foo) } }

2:54 PM

でこれは流石にウッて感じなのはその通りなので

2:54 PM

まあやっぱりselfの何某かを購読するってのは無理があるらしい

2:55 PM

子のメンバを親が購読して子に通達する、というユースケースならはまりそうだけどね

2:56 PM

 Task { [child, weak self] in for await foo in child.observe(keyPath: \.foo) { if self == nil { return } child.printFoo(foo) } }

うーーん。。。 (edited)

2:57 PM

やっぱりなんか終端記号の付与の仕方がもうちょっとなんとかなってほしいな

2:58 PM

AsyncSequenceのオペレーターにそういうのが追加されるかも (edited)

Taskをinitするときにweakifyするオブジェクトを渡してあげて、内部でそれをthrows propety(nilならerror)として参照すれば、結構上手く行くんじゃ無いか

3:23 PM

これは普通に便利かも

class TaskContext<T: AnyObject> { private weak var weakValue: T? var value: T { get throws { guard let value = weakValue else { throw CancellationError() } return value } } init(weakValue: T?) { self.weakValue = weakValue } } extension Task where Failure == Error { @discardableResult init<T>(priority: TaskPriority? = nil, context: T, operation: @Sendable @escaping (TaskContext<T>) async throws -> Success) { let taskContext = TaskContext(weakValue: context) self.init(priority: priority, operation: { try await operation(taskContext) }) } }

こういうのを作っておくするとこうなる

 Task(context: self) { context in for await foo in try context.value.observe(keyPath: \.foo) { try context.value.printFoo(foo) } }

(edited)

3:31 PM

書き味はめちゃくちゃいいね

property wrapper使って.value消せるかな？

throwsでアクセスできなくないか

3:33 PM

やってみよう

3:34 PM

Property wrappers currently cannot define an 'async' or 'throws' accessor

3:34 PM

これが解禁されたPropertyWrapperが、目玉だぜ！最高！ってWWDCに出てくる可能性はほんのちょっとだけありそうだ (edited)

tarunon

Property wrappers currently cannot define an 'async' or 'throws' accessor

だめかー

これは個人的にはかなり正解に近い拡張な気がするけど、最後の１滴が来てくれないとTaskが残ってる問題は、未解決だね。

IUOはTのようにアクセスできてnilだとクラッシュするけど (edited)

3:38 PM

Tのようにアクセスできてnilだと例外が飛ぶっていう仕組みは

3:38 PM

多くの状況で便利そうな気がした。

上手いよね、ちょっと上手く行きすぎたからGistに乗せてTwitterに放流して自慢したろw

おしい

propertyWrapperだとできないならcallAsFunctionにしたら () だけにできるｗ

気持ち的にはやっぱり for の行のtryで離脱してほしいのでAsyncZipSequenceないかと思ったけどないか

作ればいいよ

AsyncFlatMapSequenceがあるのでそれでいけるかも

最初にその方法やったんだけど、思ったより長くなるし結局tryは外せなかったから

3:50 PM

今のにした

selfを for await (self, notification) in の形式で受け取るのはちょっとだるさありますよね

それ

3:52 PM

しかもselfの名前使うとセグフォ出しおる

ｗ

あれ？もしかしてflatMap使えばthrowsせずにいける？

3:55 PM

って思ったけど無理やわ。

3:56 PM

flatMapで作った終端記号はflattenされるときに接続記号になっちゃう (edited)

一晩でめちゃくちゃ流れててもう追えない

Swift5.5へのback deployment、ひとまずmergeされましたね。(まだ諸々のbug fix必要みたいですが)

Alright, there's a bit more to come here to fix some known bugs, but this is a good baseline to land.

https://github.com/apple/swift/pull/39342 (edited)

1

throws/asyncをPropertyWrapperに許可する方向性とはまた別に、weakキャプチャのthrowable版を用意するという方向の進化もありそうだなと思った。そもそもOptionalをthrowableに変換するオペレーターがあれば実はそれで良いのでは？解りやすくなると思う

5:19 AM

override func viewDidLoad() { super.viewDidLoad() Task { [weak self] in for await value in try self.tryUnwrapped.mySomeAsyncSequence() { try self.tryUnwrapped.use(value) } } }

うん、これでいいな。

【悲報】 cancel されても Publisher の values に nil は流れてこない。

koher

【悲報】 cancel されても Publisher の values に nil は流れてこない。

えっ、それじゃあ停止できなくない？？

7:22 AM

for awaitを抜けられないですよね？

↓みたいなコードで確認したところ、 deinit と cancel は表示されたけど release は表示されず。

 deinit { print("deinit") } override func viewDidLoad() { super.viewDidLoad() let task = Task { [weak self] in guard let state = self?.state else { return } for await _ in state.objectWillChange.values { guard let self = self else { print("release"); return } // state を View に反映する処理 self.nameLabel.text = self.state.user?.name } } cancellables.insert(.init { print("cancel"); task.cancel() }) }

それはそうなるんじゃ

あ、 nil はそうか

7:24 AM

勘違いした。

このコードはVCのdeinit時点で購読を中断しているから、selfがnilのときにguardに突入しない

7:25 AM

deinitの行を消して試すといいと思いました

ちゃんと流れてた。

7:25 AM

 override func viewDidLoad() { super.viewDidLoad() let task = Task { [weak self] in guard let state = self?.state else { return } for await _ in state.objectWillChange.values { guard let self = self else { print("release"); return } // state を View に反映する処理 self.nameLabel.text = self.state.user?.name } print("nil") } cancellables.insert(.init { print("cancel"); task.cancel() }) }

7:25 AM

お騒がせしました。

7:26 AM

よかった。

なんだ。

最初に考えてた self が nil になって脱出のイメージが強すぎて、 nil で脱出が guard let self の nil で脱出と頭の中で混ざってた。

チートシート修正した。 https://twitter.com/koher/status/1441691691908415498

koher (@koher)

"Swift Concurrency チートシート"のCase 18・20のコードを大幅修正しました。修正理由＆内容は　https://t.co/TGpCbMtgfv を御覧ください。簡単に書くと、Publisher購読についてConcurrency下でオススメできる書き方になってなかったのでfor awaitを使う形に修正しました。 https://t.co/XgP1LqaqsH

5

1

koher

UIView.animate(withDurations: 0.5, animations: { self.label.alpha = 1.0 // MainActor でないとこれができない })

まだここまでしか読んでないけど、UView.animateは2つblockとって、最初のは@escapingじゃない(即時実行される)で、問題になるのはcompletionのほうでは？と思った

animationsもescapingだったような

6:24 AM

別スレッドから実行できるという話があるのでescapingだと思います

tarunon

animationsもescapingだったような

 @available(iOS 4.0, *) open class func animate(withDuration duration: TimeInterval, animations: @escaping () -> Void, completion: ((Bool) -> Void)? = nil)

これはおかしいような... え... (edited)

そもそも受け取ったクロージャを加工して実行する時点で、即時実行であったとしても@escapingの記述が往々にして必要になる気がします

+ (void)animateWithDuration:(NSTimeInterval)duration animations:(void (^)(void))animations completion:(void (^ __nullable)(BOOL finished))completion NS_SWIFT_DISABLE_ASYNC API_AVAILABLE(ios(4.0)); // delay = 0.0, options = 0

@escapingだから必ず即時実行されないとは限らないので。

いや animations は読んだ時に即時評価されないと意味不明なことになる...

6:34 AM

[UIView beginAnimtions:...]; ... [UIView commitAnimations]; の別記法みたいなものだから。 (edited)

@escaping が即時評価されないことと等価ではないですよ

ええと、animationsに@escapingついてなかったと思ったんだけどついててあれって思ってる。

6:37 AM

逆にcompletionに@escapingついてなくてあれって思ってる

completionはOptionalなので

6:38 AM

Optionalに渡される時点で自明にecapingです

6:38 AM

（escapingがつくのはこの手の実装都合とか普通にあるので、即時評価と関係あるとは限らない

6:39 AM

で、実装都合のescapingが安全なescapingで、sendable不要なんですよね

6:39 AM

スレッド跨がないから。

ふむー。

6:40 AM

なるほど...

6:40 AM

ついてないと思ってた。

これこそ @_implicitSelfCapture ついててほしいですね

omochimetaru

たしかに多くの場合で循環が問題になるのはselfがリークしてる場合ではあるな。

関係あるかわからないけれど、NotificationCenterは登録するだけでリソースを食って、それで問題になったことが何度もあって、今のweakのやつも、deinitでunregister明示的にしないとweakだから勝手に消えるから(でもそれはそのnotificationが最後にもう一回来た時なので自分が出してるやつとかだと永遠に来ないこともある)放置はダメってのがあるんだけど... (edited)

7:06 AM

(あとちょっとでログに追いつく...)

niw

ついてないと思ってた。

UIView.animate ってもしかして非メインスレッドから読んだら、animationsがメインスレッドに投入されるんじゃないですかね？それなら @escaping がついてるのが正しい

niw

関係あるかわからないけれど、NotificationCenterは登録するだけでリソースを食って、それで問題になったことが何度もあって、今のweakのやつも、deinitでunregister明示的にしないとweakだから勝手に消えるから(でもそれはそのnotificationが最後にもう一回来た時なので自分が出してるやつとかだと永遠に来ないこともある)放置はダメってのがあるんだけど... (edited)

なるほど。ユーザ側のメモリリーク以外にも害があるのか。まあ僕は最後にもう一回来ない場合にリークするスタイルは良くないと思ってます。

omochimetaru

UIView.animate ってもしかして非メインスレッドから読んだら、animationsがメインスレッドに投入されるんじゃないですかね？それなら @escaping がついてるのが正しい

なのかな... それはちょっと知らない挙動かも。UIViewのこの実装は読んだことがあって、変わってないと思うんだけどなあ...

簡単に書ける書き方が全く等価なら採用したいけど、動作上のデメリットが有るなら、書きやすさより望ましい挙動を優先したい。

niw

なのかな... それはちょっと知らない挙動かも。UIViewのこの実装は読んだことがあって、変わってないと思うんだけどなあ...

そうなんすかね。animationsのescapingは僕も昔から謎でした。

NotificationCenter.default.notifications(named: .init("namae"), object: nil) で帰る Notifications: AsyncSequence ってそもそもどうやってunregisterできるんだろう... (edited)

for文から抜けたらunregisterだと思いますよ

あ、なるほど

forに突入するときが内部的にはmakeAsyncIteratorでこれがsubscribe

7:37 AM

forを回すたびに await iterator.next()

niw

なのかな... それはちょっと知らない挙動かも。UIViewのこの実装は読んだことがあって、変わってないと思うんだけどなあ...

...そんなことはなく、普通にbackground threadから呼ばれた

niw

...そんなことはなく、普通にbackground threadから呼ばれた

お。じゃあanimateはやっぱりスレッドをまたげるんだ

7:39 AM

ん、ぎゃくか？

7:39 AM

（どっちにも読み取れる

えーっと UIView.animate(duration:animations:) を呼んだその場所から普通に呼ばれてます (edited)

7:41 AM

 * frame #0: 0x0000000104483a9c Test`closure #1 in closure #1 in ViewController.viewDidLoad(self=0x0000000132f08d90) at ViewController.swift:42:17 frame #1: 0x0000000104483b80 Test`thunk for @escaping @callee_guaranteed () -> () at <compiler-generated>:0 frame #2: 0x000000018529b5b0 UIKitCore`+[UIView _setupAnimationWithDuration:delay:view:options:factory:animations:start:animationStateGenerator:completion:] + 576

(edited)

なるほど。じゃあnonescapeっぽいな・・・

UIKit の挙動がいきなり変わることはないと思うんですよ

omochimetaru

forを回すたびに await iterator.next()

ということは一度は通知を受け取る必要があって、なんか自分が通知を投げるみたいなやつを聞いてるとかの場合、guard let self else return してても、投げる自分がきえちゃってゾンビは簡単にありえるのか...

niw

ということは一度は通知を受け取る必要があって、なんか自分が通知を投げるみたいなやつを聞いてるとかの場合、guard let self else return してても、投げる自分がきえちゃってゾンビは簡単にありえるのか...

いや、AsyncSequenceのソースになってるなんらかの購読が解除されれば、

8:15 AM

next() が nil を返してforがbreakします。

8:15 AM

で、Task.cancel を呼べば明示的な unsubscribe になります。

なるほど、この場合も Task.cancel 呼べいいのか。さっきちょっと試してそこで unregister されるのかなーどうなんだろうと思った。

niw

なるほど、この場合も Task.cancel 呼べいいのか。さっきちょっと試してそこで unregister されるのかなーどうなんだろうと思った。

Task.initの返り値を使わない場合には、何かイベントが来るまでループを抜けられない、って話ですね。

animationsはリピートが、とか昔聞いた気がする。

リピート時にまた呼ばれる？

えーまじか

omochimetaru

Task.initの返り値を使わない場合には、何かイベントが来るまでループを抜けられない、って話ですね。

そうですね。気をつけて使わないといけないなという感じ。やっぱり task が @discardableResult なのはやりすぎなのかも。

niw

そうですね。気をつけて使わないといけないなという感じ。やっぱり task が @discardableResult なのはやりすぎなのかも。

プロポーザルやフォーラムを軽くみた感じTask.initの仕様を議論するときにAsyncSequenceによる無限forループのことが十分に考慮されなかった気がするんですよね。 (edited)

8:50 AM

整理して聞いてみたい。

NotificationCenterみたいな無限AsyncSequenceのfor awaitについては、一度も発動しないとリークするというのは嫌なので、不要になった時点でTaskのcancelを呼ぶのを個人的にテンプレ（定石）にしたいと思ってます。そして、その方針でいくと @discardableResult が邪魔だと思ってます。忘れたときに警告してほしい。

1

この間Optional -> Throwsの変換をやってて思ったんですが、weak selfの方を便利にする方針はあり得るんじゃないか？と思いました

11:45 AM

どっちの方が良いのかは正直わからんな…

hironytic

NotificationCenterみたいな無限AsyncSequenceのfor awaitについては、一度も発動しないとリークするというのは嫌なので、不要になった時点でTaskのcancelを呼ぶのを個人的にテンプレ（定石）にしたいと思ってます。そして、その方針でいくと @discardableResult が邪魔だと思ってます。忘れたときに警告してほしい。

implicit self capture も要らないですね・・・。

1

https://cockscomb.hatenablog.com/entry/2021/09/26/103128

cockscomb

Swift ConcurrencyのwithTaskCancellationHandlerとSendable - cockscombl...

Swift 5.5がリリースされた。おめでとうございます。 Swift 5.5の目玉はもちろんSwift Concurrencyだ。言語機能として並行処理がサポートされた。async/awaitの構文だけでなく、Structured Concurrencyとしての整理や、actorの導入など、野心的な取り組みと言える。 Swift Concurrency Swift Concurrencyに直接関係するSwift Evolutionの提案はこれだけある。 SE-0296 Async/await SE-0297 Concurrency Interoperability with Objectiv…

1

yutailang0119

https://cockscomb.hatenablog.com/entry/2021/09/26/103128

onCancelの部分、AsyncStreamの実装見て、@unchecked SendableのクラスでWrapして自前でlockしなければいけないのかなと思っていましたが、やはりそうなのですね

https://github.com/apple/swift/blob/main/stdlib/public/Concurrency/AsyncStreamBuffer.swift#L56

swift/AsyncStreamBuffer.swift at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

これ僕もコンパイルエラーになったので無理やりクラスにラップして通すことはできたんですが、それじゃダメなので何かしらの同期機構で守らないといけないんだろうなぁと思ったまま放置してました。 -warn-concurrency だとちゃんと警告出るんですね。使うの大変すぎると思うんですが、想定ではどうやって使うつもりなんでしょうね？ Proposal のコードもエラーだし、 AsyncStream がそうなってるということはそうするしかない？

基本的に、そもそも従来の形の非同期APIが提供される場合、

8:33 AM

なんらかの購読かタスク抽象オブジェクトに対する cancel メソッドが呼び出せるように設計されている事が多くて

8:33 AM

かつ、そのcancelメソッドはスレッドセーフになってる事が多いので、

8:33 AM

そのオブジェクトが Sendable準拠してくれていて、普通に { task.cancel() } がconccurency safeと判定される

8:34 AM

というのが自然な展開じゃないですかね？

8:34 AM

元記事でいうと、

勢いよくURLSessionTaskもSendableにしてしまっているが、スレッドセーフなはずなので大丈夫だと思う。

↑これと同じ発想です。

8:35 AM

もしそうじゃなかったら、そもそもそのローレベルの(Swift concurrencyにラップする対象の)cancelメソッドを呼び出すことの安全性が保証できなそう。 (edited)

omochimetaru

そのオブジェクトが Sendable準拠してくれていて、普通に { task.cancel() } がconccurency safeと判定される

これは理想的だと思います。今はまだ Sendable に適合してないけど、適合する想定なのかな？

8:37 AM

まあ、 URLSession に限って言えば async 対応の API が用意されたからそもそも必要ないのか？

koher

これは理想的だと思います。今はまだ Sendable に適合してないけど、適合する想定なのかな？

してくれないと、ユーザーがやるのはおかしいですよね。だって、ユーザーにはほんとうの意味でそのSendableの正しさを知ることが出来ないし。

koher

まあ、 URLSession に限って言えば async 対応の API が用意されたからそもそも必要ないのか？

あー、それは、そうか。

8:38 AM

でも、ラップAPIを提供するんだったら、自分でラップするだけの必要な下準備も共有してほしいけど。

koher

まあ、 URLSession に限って言えば async 対応の API が用意されたからそもそも必要ないのか？

iOS15以前だとURLSessionのasync APIがおそらく使えないので、その場合はやはり自前の実装が必要なのかなと思ってます。 (edited)

shiz

iOS15以前だとURLSessionのasync APIがおそらく使えないので、その場合はやはり自前の実装が必要なのかなと思ってます。 (edited)

そうだった。。せっかくbackdeployがあってもoverlay APIが提供されない問題。

こんにちは〜。いい記事ですね。FoundationのクラスとかにもじきにSendableついていったりするのだろうなとは思いました。その上でSendableなクロージャからvarのキャプチャができないのはけっこう不便ですね〜

8:43 AM

lazyに初期化されるvarに対してなんらか手当があると嬉しい

APIに期待されるふるまいとしては withUnsafeThrowingContinuation の呼び出しが終わってからでしか onCancel が呼ばれることはないから、withUTCのなかで何かオブジェクトを作って、onCancelでそれに対してインタラクトするって前後順は大抵パターンになりそうだけど、 2つのクロージャで同じものを触ろうとしたらvarを経由する必要があって、そのvar変数自体がconcurrency safeにならないのか・・・

8:50 AM

withUnsafeThrowingContinuation がopaqueな <Handle> を返せるようになってて、 onCancel に <Handle> が渡ってくる、みたいなインターフェースになっていたら、大抵の場合では使いやすそう。

propdrtyWrapperなConcurrencySafe<T>が純正でそのうち出てくるんじゃないかな (edited)

tarunon

propdrtyWrapperなConcurrencySafe<T>が純正でそのうち出てくるんじゃないかな (edited)

出たとして、それを正しく使うのが難しくない？悪用されて破滅するかも

8:52 AM

悪用するのが悪いからまあそれはいいのかな

少なくとも現状のCancel部分はそれがないととてもとても

Future workに出ているUnsafeTransfer みたいな感じですかね？これはUnsafeですが... // The caller *promises* that it won't use the transferred object. https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md#adaptor-types-for-legacy-codebases (edited)

swift-evolution/0302-concurrent-value-and-concurrent-closures.md at...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0302-concurrent-value-and-concurrent-closures.md at main · apple/swift-evolution

それっぽい

8:54 AM

当にこれじゃん

var に対する get/set だけ atomicにすればいいのであれば

8:55 AM

public struct AtomicOptionalReferenceStorage<Instance: AnyObject> https://github.com/apple/swift-atomics/blob/main/Sources/Atomics/AtomicStrongReference.swift#L444

8:56 AM

こういうのがあるみたいだけど、コレ自体がstruct だから駄目なんかな？

8:56 AM

この AtomicOptionalReferenceStorage が c.c. で extension Sendable where Instance: SEndable 　ならOK?

8:59 AM

いや、駄目か・・・？ var それ自体の更新が保護されるわけじゃないから？

classとstructとで動き変えたくなるヤツだなぁ

記事にあるように ManagedAtomicLazyReference がピッタリ正解なのか、これはやろうとしてることに対して過剰なのか、よくわからない

9:02 AM

/// A reference type holding a lazily initializable atomic /// strong reference, with automatic memory management. /// /// These values can be set (initialized) exactly once, but read many /// times. @_fixed_layout public class ManagedAtomicLazyReference<Instance: AnyObject> {

9:08 AM

一回だけセットして、後でそれを参照する、だから、ピッタリな気もする。

いずれにしてもAnyObject縛りがアレですね

9:08 AM

結局classで囲まないといけない

ManagedAtomicLazyReference の方がいろいろあってちょっとだけコストが低いような

tarunon

結局classで囲まないといけない

こういうハンドラはそもそもclassじゃない？structだと、同じ対象に対するcancelでも変な感じ。

@Iceman が言ってたんだけど、 React.useEffectとかRxSwift.Observable.createは、

9:22 AM

subscribeクロージャの中でcancellerクロージャを作ってreturnさせるインターフェースになってるから

そ結構ズルしてるstructがあるからなぁ、まあその辺は使わないやろか

クロージャの入れ子関係が処理の前後順保証に対応していて、varを経由する必要がないので、よく出来てますね。

AsyncStreamはそんな感じなんだよね

onCancelはなんで引数で横並びにしたんだ。

でもキャンセルは@Sendableだけど

tarunon

AsyncStreamはそんな感じなんだよね

えっ、そうなんだ。

AsyncStreamはそういえばそうだった

9:23 AM

onTermination というプロパティに任意のキャンセル処理をさす形です

それがcontinuationのプロパティだからクロージャの内側で登録する形なのか。

1

ただこれはやらなくても良いになっちゃってるんだよね

(ソリ・・・か・・・？

キャンセル処理を書くことを強要する意味だとRxSwiftが一番優れてる

（「それ」→「そり」）

2

1

Reactは書かなくても良い、だからビミョ (edited)

tarunon

キャンセル処理を書くことを強要する意味だとRxSwiftが一番優れてる

なるほど。

9:28 AM

キャンセルしようがないときに空のDisposable書かないといけないけど、それによって反省を促されるしね。

1. 弱参照をAsyncThrowsSequence として返し、開放時にErrorを発生させるものを作る 2. CombineThrowsSequenceを定義するの二つを作ると、キャンセラ登録無しでもちゃんと消えてくれるfor awaitが作れるけど、キャンセラ書くのとどっちが良いかと言われるとウーンって感じ

1:47 PM

Task{ [xxx self] in for try await (self, foo) in combine(self, NotificationCenter.default.observe(...)) { ... } } こんなイメージ

1:48 PM

弱参照をAsyncThrowsSequence として返し、開放時にErrorを発生させるものを作る

これ自分で作れっかな。nillingの通知って出来ましたっけ。黒魔術必要だな…

1:49 PM

.rx.deallocatedと同じ作りになる

1:51 PM

Swiftのそもそもの方向性として、キャンセラを書くことを強制するよりは、書かなくてもちゃんと動く世界を構築する、の方がやっぱり近い気がして、そう言った道具が出てくるんじゃないかな〜と思うんですよねやっぱし

1

任意のオブジェクトに対して実現することはできないとしても、 (edited)

4:00 PM

deinitを通知する仕組みにprotocolとして名前をつけて

4:00 PM

Task { [xxx self] って書いてるところを

4:01 PM

Task(deinitNotifiable: self) { (self) in

4:01 PM

みたいな形で書くとかできても良さそう

4:01 PM

キャンセルも動作に対する副作用ではあるので、

4:02 PM

完全に暗黙に参照解放と連動してキャンセルが発動するのはそれはそれで常に正しいとは限らないと思っていて、

4:02 PM

参照解放とタスクの停止を紐付ける宣言は何か書く形のほうが良いと思う

たるのんの書いてるイメージの combine(self, ...) がそれを意味してるのかな。

そうだね

7:37 PM

この場合selfはAsyncThrowsSequenceになっていて、一回目はweak selfが取り出せて、解放されたときにerrorが吐き出される。そうすると、combineで組み合わせると解放によるエラーもしくはもう片方のasync sequenceの終端での脱出、ということになる。 (edited)

7:37 PM

エラーは別に終了でも良いけど

https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344

Swift 5.5 has serious stack corruption bugs!

hi all, I’ve discovered several stack corruption bugs related to async/await which can be reproduced in simple test programs compiled with recent nightly toolchains. i have confirmed that two three four of these bugs are present in the 5.5-RELEASE toolchain. stack corruption when using values returned by async closures the return values of ...

niw

https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344

もうすぐ修正(回避)されるみたいですね https://github.com/apple/llvm-project/pull/3314

The actual bug appears to have been introduced in July 2020 15 in LLVM's coroutine handling, so it's gone undiagnosed for more than a year despite LLVM coroutines being in use for a number of different features (e.g., C++20 coroutines in Clang, async functions in Swift).

https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/27 (edited)

おー、、1年以上も…

https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md#extend-property-wrappers-to-function-and-closure-parameters Swift5.5で関数やクロージャの引数でPropertyWrapperが使えるようになったんだけど

swift-evolution/0293-extend-property-wrappers-to-function-and-closu...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0293-extend-property-wrappers-to-function-and-closure-parameters.md at main ·...

7:00 AM

let a: (Binder<Int>) -> () = { $arg in ... } こんな風に$prefixつけて引数を宣言するとinit(projectedValue:) に渡して使えるというもの

7:01 AM

なんだけど、throwsやasyncと併用しようとすると壊れてしまう。久しぶりに報告した https://bugs.swift.org/browse/SR-15274

https://swift.org/blog/swift-docc/ DocC オープンソースになりました

Swift-DocC is Now Open Source

At WWDC21, Apple announced Swift-DocC, a new documentation compiler for Swift frameworks and packages. Swift-DocC provides an effortless way to author great documentation alongside your code, and generate comprehensive documentation websites for Swift codebases. It supports API docs authored as code comments, long-form conceptual articles writte...

12

6

自前クラスだとprotocolのglobalActorが検証されるけど、UIViewControllerとかは検証されないのどこが違うんでしょうかね？ (edited)

NS_SWIFT_UI_ACTORは @MainActor(unsafe) ですね

1:34 AM

@MainActor(unsafe) class Base { } protocol MyBaseProtocol: Base { func f() } class MyClass: Base, MyBaseProtocol { func f() { } }

1

1:34 AM

これなら通る

へぇ〜

おお、なるほど

こっちの方が正しい気がしてきた @Iceman @omochimetaru

@MainActor class Base { } @MainActor protocol MyBaseProtocol: Base { func f() } class MyClass: Base, MyBaseProtocol { func f() { } }

8:02 AM

unsafeの例だとexistential経由の呼び出しが、Actor保護されないという問題が出てくるはず。

8:02 AM

それを避けるためには、protocolに明示的にMainActorの宣言をしておくと良い

MyBaseProtocolはBaseを継承する時点で MainActor にならないの？

べきかどうかはさておき、ならないからこうなってるという理解です

BaseのglobalActorみて何かしらエラーをだすのに、mainActorかどうかは見ていない感じになってるんでしょうかね？

protocol周りの実装が追い付いてない説は普通にありそう

BaseについてるglobalActorの存在を認識しているからエラーは出せるけど、それがMainActorだとわかっていないからMainActor同士のconformでもエラーが出てしまうという

「Base部分はMainActorで保護されているのにDerived部分はそうではない」に意味があるかどうかだな

8:06 AM

型理論的にはサブタイプ側でゆるくなる分にはおかしくはないか・・・？

BaseはMainActorだけどMyBaseProtocolは解らない、になってるわけです。足りない分の宣言を足してあげると解決する。

8:06 AM

おかしいとは思う

基本的なポリシーとしてSwift5.5では明示的にConcurrency機能を使わない限り検査対象にならないので

1

self保護を考えてるからおかしいよねえ

全部検査するよモードにするオプションがあるので、それを付けると実装漏れかどうか分かりそう

1

8:08 AM

フラグ名は忘れた…

なるほど。緩めモードの振る舞いかもしれないか。

-warn-concurrencyだ

-warn-concurrency はもうつけてました

8:09 AM

とくに何も出ず・・

なるほど〜

上記に関連して疑問があるのですが、 UIViewControllerのサブクラスに@MainActorを付けるとTaskのイニシャライザのクロージャ内のwarningが消えるのは、なぜなのでしょうか？

// Xcode13.1 // -Xfrontend -warn-concurrency を設定した状態で @MainActor protocol MyViewProtocol: UIViewController { func f() } class MyViewClass: UIViewController, MyViewProtocol { let value = 0 func f() { Task { print(value) // Cannot use parameter 'self' with a non-sendable type 'MyViewClass' from concurrently-executed code } } } @MainActor class MyOtherViewClass: UIViewController, MyViewProtocol { let value = 0 func f() { Task { print(value) // 何も出力されない } } }

(edited)

これはわからんですね、UIViewControllerのextensionに書いても出るし、ベースクラスを自前のにしたらMainActorもMainActor(unsafe)も全て警告が出るようになりました

1

もしかして、↓の self?.state も本来ダメなんでしょうか・・・。

final class UserViewController: UIViewController { private let state: UserViewState ... override func viewDidLoad() { super.viewDidLoad() ... let task = Task { [weak self] in guard let state = self?.state else { return } // この self もダメ？🤔 for await _ in state.objectWillChange.values { guard let self = self else { return } // state を View に反映する処理 self.nameLabel.text = state.user?.name } } cancellables.insert(.init { task.cancel() }) } ... }

Task { } の外側で let state = self.state しておくのがいいのかな。 state （ UserViewState ）は @MainActor が付与されてるから Sendable になるはず。

4:09 AM

あれ？違うか。 VC は @MainActor だからいいのか。 (edited)

4:12 AM

これ↓も本来 MyViewClass が MainActor だから警告出ないのが正しい？ print(value) // Cannot use parameter 'self' with a non-sendable type 'MyViewClass' from concurrently-executed code (edited)

警告出るべきじゃないよな〜とは思うんですが、protocol周りのActor対応は結構おざなりな感じがしてるので、まあ何が出てきても不思議ではないかなと言う感じがします

actor contextの引き継ぎとsendable周り、何が意図された正しい挙動なのか混乱する・・・。

これ↓も本来 MyViewClass が MainActor だから警告出ないのが正しい？

僕も出ないのが正しいのかなと思ってます。それが今は警告出てきて、さらに@MainActor付けると消える理由がわからなくて、「何が正しいんだっけ？」な状態です

ちなみにSwiftUIのViewでも同じことが起きます(@MainActorを付けると警告が消える) (edited)

おおお、 @MainActor は値型にも付けれるんですね・・・。個々のメンバにかかってるからいいのか。

https://forums.swift.org/t/pitch-light-weight-same-type-constraint-syntax/52889

[Pitch] Light-weight same-type constraint syntax

Authors: Pavel Yaskevich, Holly Borla Status: Awaiting implementation Introduction As a step toward the goal of improving the UI of generics outlined in Improving the UI of generics, we’d like to propose a couple of improvements that bridge the syntactic gap between protocols and generic types, and hide some of the complexity (both visual and...

3:35 AM

Protocolのassociatedtypeにprimary associatedtypeという概念を追加して

3:35 AM

Collection<Int> のように、アングルブラケットで指定できるようにする構文の提案

3:36 AM

generic parameterとassociated typeが紛らわしくなるし将来generic protocolの構文を実装する余地がなくなるから微妙だと思う・・・

そのままウッカリgeneric protocolとして実装されて欲しい

ABIとか型推論とか与える影響がありすぎるのでそれはないｗ

https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes

You can now use Swift Concurrency in applications that deploy to macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes async/await, actors, global actors, structured concurrency, and the task APIs. (70738378)

6:39 PM

ついにConcurrencyのバックデプロイが使えるようになるらしいよ

3

思ったよりずっとはやい

来月くらいから申請できるのかな？

6:40 PM

少なくとも来年すぐくらいには使っていけそう

あとはSendable周りの彼是が良くなっていけばかなり快適になりそう

6:42 PM

SendableをExistentialとして使うとbad accessが出まくるというのをこの間踏んでしまった

https://twitter.com/dgregor79/status/1453432581622362112 複雑なことしてるから使ってバグレポートしてほしいとのこと

Introducing Swift Distributed Actors

Please try this out and file bugs, then tag us on Twitter with Feedback numbers or SR numbers. It’s an enormously complicated feature to back-deploy and there may yet be issues we didn’t uncover. https://t.co/kmt97rXyV1

Twitterが正規のレポート手段だったのか…

Twitterすごい

べんり

かなりアツい https://swift.org/blog/distributed-actors/

We’re thrilled to announce a new open-source package for the Swift on Server ecosystem, Swift Distributed Actors, a complete server-oriented cluster library for the upcoming distributed actor language feature!

7:19 AM

3年前から内部で開発されてた分散アクタークラスタ用のフレームワークが、言語機能のdistributed actorによってAPIが洗礼されて、ついに公開された

あれ、そんなアツい話が書いてあるのか。冒頭だけ読んで後回しにしてた

Yuta Saito

3年前から内部で開発されてた分散アクタークラスタ用のフレームワークが、言語機能のdistributed actorによってAPIが洗礼されて、ついに公開された

これはリポジトリのログ見て判明した

7:25 AM

これがdistributed actor導入コミット https://github.com/apple/swift-distributed-actors/commit/378a8eb3bd19c096804c29c25e147f46a273391c

viewDidLoad()でawaitしようとしたらasyncにしないと呼べない、、、と思ったけどTask.detachedで包んでこう書くのね。根っこまでasyncかどうかをコンパイラがチェックしてくれるのはかなり良い。

override func viewDidLoad() { super.viewDidLoad() Task.detached { var req = URLRequest(url: URL(string: "")!) req.httpMethod = "POST" do { let data = try await URLSession.shared.data(for: req, delegate: nil) ... } catch { print(error) } } }

actor context を引き継ぐなら Task { } だと思います。

なるほど！ Task { } だとURLSessionのコールバックでMainQueueにディスパッチ、したときと同じ挙動になるんですね。

8:02 AM

元のActorってことか。UIで使う場合はそのほうが絶対にいいですね。

これですね。 https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#actor-context-propagation

9:30 AM

@Sendable closure は通常 actor context を引き継がないんですが、 @_inheritActorContext で Task.init の場合は引き継ぐようになってるんですよね。ややこしい・・・。

9:31 AM

https://github.com/apple/swift/blob/main/stdlib/public/Concurrency/Task.swift#L447

9:32 AM

他にもめっちゃいっぱい付いてる

@_inheritActorContext @_implicitSelfCapture operation: __owned @Sendable @escaping () async -> Success

むむ、後で読みます

わかったと思ったけど、またわからんくなってきた。 DispatchQueue の async に渡すクロージャは @Sendable 付いてないんだけどいいんだっけ？過渡期だから付いてないだけ？？

過渡期だと思いますよ

1

8:24 AM

現存する@escapingの9割はSendableであるべき、と思います

そうですね。かなりの割合は @Sendable である必要がありそうです。 @Sendable でなくていいのは↓みたいなやつという理解。 struct Converter { let convert: (Int) -> Int init(convert: @escaping (Int) -> Int) { self.convert = convert } }

合成関数の生成とかはSendable要らないですね

1

8:29 AM

ただし、Sendableやescapingを伝播させる仕組み(rethrowのような)は無いと、今後キツくなっていくと思います (edited)

8:30 AM

Converterは、Sendable用のConverterを別途用意しないと成り立たない気がする

たしかに

クロージャそのものを型パラとして見れるようにして、Sendableの場合のconformingを作らないといけない

8:31 AM

この辺は今の型システムだと埋め切れてなくて、将来的に何とかなって欲しいなと言う感じがしますね

8:32 AM

というか、関数を@Sendableにして、型へのconformingから逃げてしまったのは

8:32 AM

実は負債に成り得るんじゃないか、と思ったりした

struct Converter<F: (Int) -> Int> { let convert: F init(convert: @escaping F) { self.convert = convert } } extension Converter: Sendable where F: Sendable {}

こう書けるようになりたい

わかる

8:33 AM

実は、@Sendableじゃなくて、Callableの筋から頑張るのが正解だったんじゃないか？

actor に Sendable な Converter を渡したとして、それを利用するときに @Sendable クロージャが呼び出されると actor context がぶった切られる？

8:35 AM

いいのか、戻り値を利用するだけだから。

8:35 AM

クロージャの中は関係ないのか。

8:35 AM

そもそもクロージャの中は actor の外で宣言されていて、引き継ぐも何もないのか。

8:38 AM

struct Converter: Sendable { let convert: @Sendable (Int) -> Int } let converter: Converter = .init { // ここは何の context で実行される？？ $0 * $0 } actor A { func foo(x: Int, converter: Converter) { print(converter.convert(x)) } }

Converter、事実上CombineのCancellerと等価ですが、であるならば常にSendableで良い気がしてきた

12:33 PM

等価の事例にAsyncStreamのterminationクロージャがありますが、これはSendableですね

https://forums.swift.org/t/pitch-introduce-existential-any/53520

[Pitch] Introduce existential any

Hello Swift Evolution! I recently started a discussion about easing the learning curve of introducing generic parameters. In that discussion, it was brought up multiple times that the existing syntax of existential types is actively harmful, and we should consider making the implications explicit in the language. I wrote up a proposal for intro...

7:17 AM

anyキーワードのピッチじゃあー

7:24 AM

このレベルの変更入れられるなら、trailing closureのラベル周りも何とかなったりしないだろうか

Enforcing that existential types use the any keyword will require a source change. To ease the migration, I propose to start allowing existential types to be spelled with any with the Swift 5.6 compiler, and require existential types to be spelled with any under the Swift 6 language mode. The old existential type syntax will continue to be supported under the Swift 5 language mode, and the transition to the new syntax is mechanical, so it can be performed automatically by a migrator.

7:26 AM

古い記法を5系では有効、6系では無効、機械変換できるのでヨシ

ヨシ

ホントかなァ

マイグレーター、コーナーケースで壊れがち

7:27 AM

コンパイル可能な状況なら理論上書き換え可能なのは、そう。

tarunon

このレベルの変更入れられるなら、trailing closureのラベル周りも何とかなったりしないだろうか

そうだね、第一クロージャのラベルも、5系では記述可能、6系では必須ってしてほしい

単体で見たときは大丈夫だが、swift6はこの変更だけではないから

7:28 AM

組み合わせで死ぬ、は有り得るけど

お、たしかに。

まあこの変更はあるべきだから、最悪壊れても良いよ

いや、でも、

7:29 AM

anyを付与する変更は、まだ、5.6としてvalidなコードだから

7:29 AM

コンパイルできる状態を維持して次のマイグレーターをかけられるはず

大体カチキレてる人間は互換のある間に仕事を済ませないで、後に引けなくなったときに全部やろうとして失敗するんだ

7:29 AM

夏休みの宿題ってヤツだな

古いマイグレータを搭載したXcodeが起動できなくなったら詰むのかな

Xcode12は実質IntelMacでしか動かないからわりと早く淘汰されそう

古いコードが動かないことによる損失は私はもっと大きいと思うのでもうちょっとがんばってほしいと思うな。別のキーワードにしたらいいんじゃないか。

Yuta Saito

古いマイグレータを搭載したXcodeが起動できなくなったら詰むのかな

うわっ、なるほどっ

Kishikawa Katsumi

古いコードが動かないことによる損失は私はもっと大きいと思うのでもうちょっとがんばってほしいと思うな。別のキーワードにしたらいいんじゃないか。

別のキーワードだとしても、「現状のキーワードなしを違反文法とする」という変更が、破壊的であるのは変わらないですよ

そうなのか。Breaking Change不可避の変更なのね。

5.6までは「現状のキーワードなしも許す」にしておくからそこで移行しなさいというプラン

7:50 AM

岸川さん的な立場からは「6.0からは違反とするのはやめろ」って意見がいいですね

7:50 AM

6.0でも警告が出るだけでも自分は構わないな〜

本命はExistemtialの記法が確立することで、extension any P: Pが書けるようになることだと思うけど

だいたい読んだ。ちょっと勘違いしていた。

それは別にコンパイルエラー無くても新記法さえ存在すれば実現できますよね (edited)

もともとの文法はそのままでany追加、でいけないのかな。

7:53 AM

それは別にコンパイルエラー無くても新記法さえ存在すれば実現できますよね

^ これこれ

7:53 AM

つまり「6.0からは違反とするのはやめろ」ということか。

tarunon

それは別にコンパイルエラー無くても新記法さえ存在すれば実現できますよね (edited)

それだけなら extension any P: P {} という記法だけ導入する手があるね。(このanyは Pではなくextensionにかかっている) (edited)

6.0から違反（エラー）にしなければいけない理由ってあるんですかね。警告でいいようにも思うんだけど。そしてわかっている人が明示的にその警告をオフにできるコンパイラオプションがあるとなおうれしい。 (edited)

hironytic

6.0から違反（エラー）にしなければいけない理由ってあるんですかね。警告でいいようにも思うんだけど。そしてわかっている人が明示的にその警告をオフにできるコンパイラオプションがあるとなおうれしい。 (edited)

理論上はないと思いますどちらも使える状態を維持するのはコンパイラの保守コストが上がってつらい、とかはあると思います

omochimetaru

理論上はないと思いますどちらも使える状態を維持するのはコンパイラの保守コストが上がってつらい、とかはあると思います

ああ、保守コストはたしかに。

https://forums.swift.org/t/support-hosting-docc-archives-in-static-hosting-environments/53572

Support hosting DocC archives in static hosting environments

Hi all! This post discusses an enhancement to Swift-DocC and Swift-DocC-Render that will allow developers to build DocC archives that can be hosted without custom routing. This is specifically designed to enable DocC to be used in additional static hosting environments, most notably GitHub Pages. This change is meant as a quick solution to add...

3

8:28 PM

doccを静的にホストできるようにするための議論かな

@giginet がGitHub Pagesで使いにくいって言ってたやつかな

1

すべてのアクセス可能なパスにindex.htmlファイルを置く、ということでrewrite不要にするってことらしい。けっこう大がかりだなと思ったけど好印象なコメント多い。

doccってstatic hostingにうまいこと対応してない...?

すぐ上に話題ありますね

1

まだそうはなってないという話

なんか、意外だな。ちゃんとみておけばよかった。

ぎぎにゃんのdocc解説 https://discord.com/channels/291054398077927425/380329942505750529/910113051359977492

みてきた

6:52 AM

なるほど...

6:53 AM

https://github.com/unsignedapps/Vexil/blob/main/.github/scripts/generate-docs.sh

Vexil/generate-docs.sh at main · unsignedapps/Vexil

Vexil (named for Vexillology) is a Swift package for managing feature flags (also called feature toggles) in a flexible, multi-provider way. - Vexil/generate-docs.sh at main · unsignedapps/Vexil

6:54 AM

こういう感じなのか...

↑はなんか凝った事も追加でやってそうですね

ファイルコピーしてるだけにみえるけれど...

7:01 AM

https://vexil.unsignedapps.com/documentation/vexil/ 出力はこんな感じになってる

# Re-create the .json structure inside /documentation find "${WORKING}/data" -type f -name '*.json' \ | sed 's%data/%%g' \ | sed 's%\.json%%g' \ | xargs -n 1 mkdir -p # Copy our website root files over the top too cp "${WEBSITE_DIR}/index.html" "${WORKING}" cp "${WEBSITE_DIR}/styles.css" "${WORKING}/css" cp "${WEBSITE_DIR}/vexil.svg" "${WORKING}/img"

7:03 AM

↑このへんは非標準に見えます

cp -R "${VEXILLOGRAPHER_DOCCARCHIVE}"/data/documentation/* "${WORKING}/data/documentation/"

7:04 AM

なので、もともとdocarchiveにあるjsonを元にディレクトリつくってる感じ? (edited)

https://github.com/waiwai-swiftc/waiwai-docc

GitHub - waiwai-swiftc/waiwai-docc

Contribute to waiwai-swiftc/waiwai-docc development by creating an account on GitHub.

7:07 AM

ぎぎにゃんのサンプルはもうちょっとシンプルだけど、デプロイのところは含まれてないから、アーカイブしてから色々コピーするという感じにはなりそう

そんな感じですねえ

7:08 AM

index.htmlを配置とか、フォーラムの提案をhackyだって言ってる人がいるけどまあそうだと思う

@MainActor を書いたクラスはバックポートされるXcode 13.2betaを使わなくてもiOS 14以前で動くんですね。コンパイルエラーにもならない。

async呼ばなければタダですね

そうなんですねえ。

これで思い出したんですけど、Rustの場合はサスペンションポイントをまたいで値を共有したい場合、その値はSendトレイトを実装している必要があるんですよね。 Swiftはその制約が無いけど、既にどこかで議論されてたりするのかな？ https://discord.com/channels/291054398077927425/430242233468452865/915087485640511598

ええ、そうなんだ。Rustの場合はそのコールスタックでしかvalidでないポインタとかが出てくるからかな？

4:55 AM

Swiftの場合それに該当するのは inout T 型だけど、これは async 関数だと使えないから、出てこないので

4:55 AM

Swiftの値はどんな値も suspension point 間を move していけることは保証されてるので必要ない気がする。

たとえばこうすると2スレッドから同時にSendableでない値sにアクセスできちゃう気がするんですよね。

import Foundation func g() async {} func f(s: NSMutableString) async { Thread.current.threadDictionary["str"] = s await g() Thread.current.threadDictionary["str"] = s }

(edited)

5:01 AM

@swift-main -warn-concurrency import Foundation func f(s: NSMutableString) async { DispatchQueue.main.async { print(s) } }

Yuta Saito

@swift-main -warn-concurrency import Foundation func f(s: NSMutableString) async { DispatchQueue.main.async { print(s) } }

stderr:

<stdin>:5:15: warning: cannot use parameter 's' with a non-sendable type 'NSMutableString' from concurrently-executed code print(s) ^ Foundation.NSMutableString:1:12: note: class 'NSMutableString' does not conform to the 'Sendable' protocol open class NSMutableString : NSString { ^

これがワーニング出るんだったらサスペンションポイント跨ぎでスレッド変わるパターンもダメじゃないですかね

actor contextに守られてるスコープではスレッド変わっててもアクセスが常に並行になるから大丈夫というわけではなく？

そもそもactor context外での並行アクセスは常に非安全か

Iceman

actor contextに守られてるスコープではスレッド変わっててもアクセスが常に並行になるから大丈夫というわけではなく？

直列だから大丈夫、じゃない？

omochimetaru

直列だから大丈夫、じゃない？

同時にアクセスが起こらない的な意味で発言しましたが直列のほうが正しいんでしょうかね？

並行というのは同時に起きることをさすので

7:09 AM

時系列的にかぶらないことを言うなら直列です

それは並列ではないですか？

あー並列と並行を意識して使い分けていたのか

7:12 AM

https://ja.wikipedia.org/wiki/%E4%B8%A6%E5%88%97%E8%A8%88%E7%AE%97

%E4%B8%A6%E5%88%97%E8%A8%88%E7%AE%97

7:13 AM

並列計算（へいれつけいさん、英語: parallel computing）は...複数の処理装置（プロセッサ）上でそれぞれの処理を同時に実行させることである[1]。並行計算(concurrent computing)は一つのタスクの計算を並列化することにとどまらず、複数の相互作用しうるタスクを、プロセスやスレッドなどをもちいて単一または複数の計算資源にスケジューリングするといった、より汎用性の高い処理をさす。

(edited)

7:14 AM

物理的に実際に同時に複数の計算を行うのが並列(parallel)で、もしかしたら1コアの状況でも時分割して見かけ上同時に実行するのが並行(concurrent)であると。 (edited)

7:16 AM

それで、actor isolatedな処理は、一つのactorでは常に一つの実行しかされず、スレッド並行という意味でも起こらないので、並行実行も並列実行もされない、と思います。 (edited)

複数のactor context内にキャプチャされた変数へのアクセスはその変数から見たら直列なアクセスではありますが、プロセス全体から見たら並行なアクセスに見えるなぁとも思ったのですが、こういう場合でも並行とは言わないんでしょうかね

プロセス全体では複数のactorが並行で実行されているのがSwift Concurrencyだと思います、それは言うと思う。でも並行というのはマルチスレッドなどによって見かけ上同時に実行することを言うので、同じactor contextで保護されている変数に見かけ上同時にアクセスが起きないことを言う場合は、「actor contextの元で直列化されているので大丈夫」になると思います。 (edited)

自分でも言ってて単一の変数の保護の話をしてるのにプロセス全体からの視点を持ち込む意味がよくわからないと思ったので、今度から直列と表現します

7:30 AM

僕の勘違いはこの記事が指摘してる通りの内容のような気がする https://zenn.dev/koron/articles/3ddcaaeae37f9befdf70

並列と並行 / 多言語からみるマルチコアの活かし方に見られるように並行(concurrent)とは「複数の処理を順番に実行すること」とする誤った記述を、この記事に限らずチラホラ目にします。

ふむふむ。。並行というのは(物理)並列に対して、スレッドなどによる仮想的な方法による同時実行も含めてより抽象化した言葉で、同時実行が主たる意味なのは同じなんだけど、その実現方法の一つであるプリエンプティブマルチタスクなCPUのスケジューリングの概念を拡張しちゃって、「非同期な処理をコードの制御上順番に実行する」事を指しているという誤解がある・・・？

7:39 AM

しかし、批判されている記事に60いいねついていてコメント欄にツッコミが無いのはちょっと気になるな。

https://github.com/apple/swift/pull/40340

[stdlib] Drop ICU by Azoy · Pull Request #40340 · apple/swift

Now that the stdlib no longer needs ICU, let's drop the dependency

This is marked as a draft because right now this only removes the immediate dependency on the stdlib, and isn't ...

8:29 AM

Now that the stdlib no longer needs ICU, let's drop the dependency

8:29 AM

@Yuta Saito ↑これどうやってん

全部再実装

すごい

Azoyさんがしばらくコツコツやってましたね

8:31 AM

https://github.com/apple/swift/pull/38922

[stdlib] Implement native normalization for String by Azoy · Pull R...

This is still a wip, but wanted to get some benchmarks and tests ran on this. Resolves: rdar://51635207, https://bugs.swift.org/browse/SR-9432

8:32 AM

すごい

気合だ

互換性本当に取れるのか

8:35 AM

https://github.com/apple/swift/blob/main/utils/gen-unicode-data/Sources/GenNormalization/Comp.swift#L142

swift/Comp.swift at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

8:35 AM

Swiftで書かれたC++コード生成機がある・・・

ブートストラップ…

https://github.com/apple/swift/tree/main/utils/gen-unicode-data

swift/utils/gen-unicode-data at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

8:37 AM

swiftpm packageになってる！

8:37 AM

https://github.com/apple/swift/blob/main/utils/gen-unicode-data/Data/emoji-data.txt

swift/emoji-data.txt at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

8:37 AM

やべえ

8:38 AM

UnicodeData.txtも1.7MBある

8:39 AM

これは凄いなあ

これでSwiftに必要な部分だけが抽出できたからサイズ最適化もやりやすくなりそう

ICU全体よりは持ってるデータやロジック量は減る？

流石に減るんじゃないですかねぇ

結局コードポイントに関する辞書が支配的そうな気もするけど

ICUの方でも埋め込むデータを削減するための仕組みがあって、Wasmではそれ使って既に削ってるのでそこまで減らないかも https://unicode-org.github.io/icu/userguide/icu_data/buildtool.html (edited)

へえ〜

昔の実験の記録によると文字セット変換用のマッピングデータが大きかったみたいです

文字セットって、sjisとeucの対応みたいな？ (edited)

そうそう

なるほど。それは確かに重そうだ。

そうか、Unicodeだけじゃダメなのかぁ・・・。

Foundation使うとsjisバイト列とか作れるけど、

8:51 AM

FoundationはICUをリンクしてるままってこと？

そこはそのままなんじゃないですかね

あれ、そうすると、バイナリサイズはでかくならないか？

8:51 AM

stdlibだけなら小さくて済むけど

たしかに

単純に考えるとでかくなりそう。

FoundationのICU部分と、再実装したUnicode部分が、冗長になる

どうするんだろう

ｗｗｗ　大変そうだ・・・

確かにFoundationでもsjis作れるのか

お仕事でやりましたね

8:54 AM

サーバーサイドSwiftから、Windowsエクセルで安定する生成CSVをダウンロードさせたくてね

なんかうまくいかなくて自分はiconvでやってました (edited)

any review 始まった https://forums.swift.org/t/se-0335-introduce-existential-any/53934

SE-0335: Introduce existential any

Hello Swift community, The review of SE-0335 " Introduce existential any" begins now and runs through December 22, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the r...

6

https://forums.swift.org/t/se-0336-distributed-actor-isolation/53939

SE-0336: Distributed actor isolation

Hi everyone. The review of SE-0336, "Distributed Actor Isolation", begins now and runs through December 22, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When messaging the review m...

10:24 AM

distributrd actorの正式レビューもはじまったのか、すごい

10:29 AM

0335の動機の章は、ワカリが強くて良い文章だなあ

Distributed Actor、↓のスレッドが興味深かったけど、コメントや判断できるほどの知見がなかった。 https://twitter.com/1amageek/status/1466656781774761984?s=21 (edited)

のり村本章憲 (@1amageek)

@xuwei_k @rizumita 重要なのは 1. Apple Siliconが分散システムにも対応できるように作られていること 2. Swiftが分散システムにおける実装を安全にかけるActor Modelを導入してること 3. Swiftがクライアントとサーバーで利用できること 4. Swiftがプロトコル指向であることなどが相まって、やばいって話なので

any P.Typeと(any P).Typeと(any P).selfはややこしいけど、じっくり眺めてると、素直な定義でしっくりくるな

Erlang の actor とかは最初から distributed だし、特別なものと思ってなかったけど、クライアントサイドで実際に使われている言語＆ Apple Silicon 的な視点の話は聞いたことがなかったので。まだ Distributed Actor については Proposal 等何も読んでないので書いてあるのかもしれないけど。

Erlangはマイナーだけどその論点ならScala akkaも満たしてるんですよね

10:44 AM

Swiftはそれに加えてasync awaitと統合されてる事が新しいと思います (edited)

Scalaはクライアントサイドであんまり使われない？

Androidで使われた時期もあったけどKotlinになりましたね

10:45 AM

でもデスクトップクライアントなら全然いけるとおもいます

Apple Siliconが分散システムにも対応できるように作られていること

この文脈だと JVM がダメ？

そのくだりは僕はよくわかんないです誰もまだAppleシリコン最適化バキバキのハイパフォーマンス分散システムを実戦投入してないと思う。

10:47 AM

まあこの前のワイワイで雑談にでてたIntelよりArmの方が参照カウンタの処理が早いからSwiftに有利、みたいな話はありましたね (edited)

10:48 AM

まあJVMだとどうしてもオーバーヘッドは少しはあるから、ネイティブ言語でトップスピードに期待できる、とかは言えるのかも

仮に Apple Silicon が効いたとしても、クライアントサイドが Apple Silicon オンリーにも、 Swift オンリーにもならないという問題はありそうだなぁ。でもクライアントサイドもサーバーサイドも Actor で統合された夢の世界もあり得るのかなぁ。

いわゆるモバイルアプリのクライアントがactorになってても、現状のJSON APIと大して使い心地は変わらないと思うんですよね (edited)

10:51 AM

どういうシステムにアクターがマッチするのか、という議論が重要なんじゃないか

DB が Distributed Actor でラップされたら、アプリから直接 Firestore にアクセスするくらいの感覚で DB 直接触れたりするんだろうか？ (edited)

どういう感覚の部分ですか？

API を介したやりとりの部分が消失して、直接やりとりしているような感じになるとか。

個人的には、Actor自体がSendableな事が強みな気がしています通信先のノード数が変動するような状況で、扱いやすくて便利になるというか。

koher

API を介したやりとりの部分が消失して、直接やりとりしているような感じになるとか。

それはトランスポートの実装をActorに任せられて楽、って話に見えますけど、使う側のユーザーからすると特にコードも変わらないような気がするんですよね

10:57 AM

SQLを引数に渡して、レコードが返ってくるasync funcなのは、同じ事なので。

10:57 AM

リモートにあるステートフルなオブジェクトを、そうと意識せずに、普通のclass instanceだと思って取り回せるところが、distributed actorの価値だと思う。

そうなったときに、リモート（サーバーサイド）にある DB の actor をローカル（クライアントサイド）から触れることで、 API を介したやりとりのレイヤーが消失したりしないかな？

APIを介するレイヤーって、実装詳細じゃないですか？もともとactorがなくても、メソッドにラップできるので。

11:02 AM

そのラップする作業をdistributed actor transportがやってくれるから手間が減らせるというのはわかりますが、あれも結局アクターのためにAPI操作を自動生成してるにすぎないので、話の構造が同じに見えるんです

11:03 AM

(distributed actorを使うためには、メソッドに対応したリクエスト型を定義して、受信側でメソッド呼び出しに転送するコードを、生成します (edited)

うーん、でもたとえば、仮に関数を呼び出すために直接インスタンスを渡せなくて、一度 JSON にエンコードした Data を渡して、それを受け取った側でもデコードして扱わないといけなかったという状況から、直接インスタンスを渡せるようになったくらいのインパクトはあるんじゃないかな？

11:05 AM

メソッドに対応したリクエスト型を定義して、受信側でメソッド呼び出しに転送するコードを、生成します

そうなのか。

それはアクターのメリットじゃなくて、アクターのためにコンラッドさんが用意したコードジェネレーターが便利って話で

11:05 AM

今までも同じ事はできたと思うんですよね。

11:06 AM

で、それは元のツイートで吉田さんが書いている、これまでのRPCと何が違うのか？という問いが指摘してるポイントだと思います

koher

メソッドに対応したリクエスト型を定義して、受信側でメソッド呼び出しに転送するコードを、生成します

そうなのか。

Swiftのdistributed actorは、実際の通信方法が言語機能から分離されているので、そこをJSON/HTTPにしたり、gRPCにしたり、ユーザーが選択できます。ここは面白いですね。

うーん、 API の消失というのは単にエンコード・デコードが省略できるというだけの意味ではなくて、

リモートにあるステートフルなオブジェクトを、そうと意識せずに、普通のclass instanceだと思って取り回せる

ということによって、より自由に API の向こう側とこちら側を行き来できる感じかなぁ。

koher

うーん、 API の消失というのは単にエンコード・デコードが省略できるというだけの意味ではなくて、

リモートにあるステートフルなオブジェクトを、そうと意識せずに、普通のclass instanceだと思って取り回せる

ということによって、より自由に API の向こう側とこちら側を行き来できる感じかなぁ。

例えば、distibuted funcの引数にactorを渡す事ができるようになるんですが、 (edited)

11:10 AM

これは確かに従来のAPIだとできないんですが、

11:11 AM

例えばactor ChatMessageみたいなものを引数に渡してしまうと

11:11 AM

サーバー側でawait chatMessage.textが必要になって、無駄な往復通信が起きます

11:11 AM

だから結局アンチパターンになると思います

リモートに渡された actor は実体が渡るのではなく、アクセスするときは必ず通信が発生するってこと？

そうです。アクターがトランスポートを通るときは、インターネットアドレスとしてシリアライズされます

なるほどー。まあそうじゃないと同期できないよなぁ。

アクター自体は常に産まれたホストマシンに存在しています

11:13 AM

リモートからみたときに、実は同じホストマシンにいるのか、リモートマシンにいるのかの見分けがつかないというのがマジックなところ。 (edited)

11:14 AM

あーだからそうですね、NoSQLみたいな環境で、データベースが複数あるときに、それぞれのレコードが自身のDBホストに実在するactor、みたいなスタイルは面白いかも

11:15 AM

P2Pのサンドボックス環境とかにも向いてるのかな？

アプリ同士が P2P で actor でやりとりするとかもできるのかな？

今流行りのメタバースの実装に向いてるのかもw

koher

アプリ同士が P2P で actor でやりとりするとかもできるのかな？

できますできます。

それはかなりおもしろそう。

11:16 AM

最初に actor を相手に渡すところがイメージできてないけど。

最初のクラスター参加にはサービスディスカバリーの仕組みが何かしら必要です。

11:18 AM

https://github.com/apple/swift-sample-distributed-actors-transport/tree/main/SampleApp

swift-sample-distributed-actors-transport/SampleApp at main · apple...

Distributed actors transport example, for feature review - swift-sample-distributed-actors-transport/SampleApp at main · apple/swift-sample-distributed-actors-transport

11:18 AM

一番最初って確かにどうすればいいんでしょうね？↑のどこかにあるはず

11:19 AM

let remoteRoom = try ChatRoom.resolve(room.id, using: chatter.actorTransport) try await chatter.join(room: remoteRoom) }

11:20 AM

見て思い出した。resolveメソッドを使うんだ。 (edited)

11:20 AM

その引数のIDを、何らかの方法で手に入れればいい。

11:21 AM

このIDの正体は、トランスポートの実装次第だけど、大体のケースではIPアドレスとポートとインスタンスIDだろう。

resolve は distributed actor に生えてる static メソッドなのか。

そう

11:23 AM

さっき言ってた、アクターがトランスポートを通り抜ける時に、これを活用してる。

DistributedActorSystem の実装側が大変そうだ・・・。

associatedtype ActorSystem: DistributedActorSystem

11:26 AM

ActorSystemってなんだろう。前読んだ時にはActorTransportって書いてたやつなことかな。

koher

DistributedActorSystem の実装側が大変そうだ・・・。

デフォルトのこれを使っとけばいいってことなんじゃないかしら https://github.com/apple/swift-distributed-actors ディスカバリ部分はどのくらい手間かかるのか気になりますね。

GitHub - apple/swift-distributed-actors: Peer-to-peer cluster imple...

Peer-to-peer cluster implementation for Swift Distributed Actors - GitHub - apple/swift-distributed-actors: Peer-to-peer cluster implementation for Swift Distributed Actors

1

protocol CodableDistributedActorSystem: DistributedActorSystem { typealias SerializationRequirement = Codable }

12:12 PM

typealiasの右辺にプロトコル書くのってありなんだっけ？

existentialがprotocolにconfirmしてるならいける

12:13 PM

Errorはいけてる

12:13 PM

はず (edited)

12:15 PM

あーー

12:15 PM

Codableは難しそうだな

それはプロトコルを書いてるというよりany Pを書いてるってことよね

12:22 PM

ここ、associayedtypeじゃなくて、associatedprotocolみたいな新しい構文にしたほうが良い気がする

associatedprotocolって、そうしたらそれはgeneric protocolになるのでは

1:09 PM

と言うかそうした方が色々具合が良い気がする…

tarunon

と言うかそうした方が色々具合が良い気がする…

generic protocolではまるかな？これちょっと特殊な扱いなんだよね

1:13 PM

distributed funcの引数と返り値がそのプロトコルを満たしてないといけないっていう特殊な検査をする

あーーー

1:31 PM

難しいね

1:31 PM

Higher Kinded Typeの方が近いかも？

1:32 PM

いやちょっと違うか

https://developer.apple.com/forums/thread/696197 自分で使ってなくてもConcurrencyを使ってるライブラリがあると14以前で起動できない問題。以前もFoundationをweak_linkしないといけない問題とか何かあったけど、こういう暗黙的にリンクされる標準のフレームワークをweak_linkしないといけないっていうのを気づくのはだいぶ難しいな。

13のサポートを落とす...

14もですよね。けど実際それはアリですよね。13から15にアップデートできないデバイスはなかったと思うので。iPadはもしかしたらあるんだっけか。

いや、なかったと思う

お、それならみんなでサポートバージョンを上げるのができれば一番いいですね。

https://forums.swift.org/t/pitch-move-function-use-after-move-diagnostic/53983

[Pitch] Move Function + "Use After Move" Diagnostic

Hey everyone! Attached inline below is a proposal to add a move function to the swift stdlib that possesses a use after move diagnostic. The full eternal URL is https://github.com/gottesmm/swift-evolution/blob/move-function-pitch-v1/proposals/000a-move-function.md Thanks in advance for any feedback/thoughts! You can try it out with the tool...

5:16 AM

moveも動いた！！

これは嬉しい

この変数はここで使うの終わりにしたい、ってことたまにあって、 varにして上書きしたり、shadowしたり、doスコープ切って終わらせたり、するんだけど、 moveがあるとシンプルに書けて嬉しい。

doスコープ切って終わらせたり、するんだけど、 moveがあるとシンプルに書けて嬉しい。

これは同名で再宣言はできるのかな？ do でスコープ切るときは、同じ名前で後で宣言したいことが結構多い気がする。

なるほど。それはできない気がしますね。意味解析の順番が前後しちゃうので。

8:21 AM

理屈上は再宣言できるようにはできるけど、結構頑張らないとその機能は入れられないと思うから、特に書いてないのでそうならなそう。

再代入の例はありましたね。でも再代入だからlet宣言できないかな

func f() { var x = getValue() let _ = move(x) // Can't use x here. x = getValue() // But I can use x here, since x now has a new value // within it. }

なるほどー。

Kishikawa Katsumi

https://developer.apple.com/forums/thread/696197 自分で使ってなくてもConcurrencyを使ってるライブラリがあると14以前で起動できない問題。以前もFoundationをweak_linkしないといけない問題とか何かあったけど、こういう暗黙的にリンクされる標準のフレームワークをweak_linkしないといけないっていうのを気づくのはだいぶ難しいな。

このサードパーティライブラリがConcurrency使ってるとiOS 14以下で起動できないっていうの、RealmSwiftで起こってるわ。。。

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Description: DYLD, dyld: Using shared cache: EC12EBDC-CAE3-34EC-ACCB-0B6E5ABC73EB | dependent dylib '@rpath/libswift_Concurrency.dylib' not found for '/private/var/containers/Bundle/Application/5A5B9B8F-4D0F-478A-B25B-2CF006B1C7FA/Illustail.app/Frameworks/RealmSwift.framework/RealmSwift', tried but didn't find: '/usr/lib/swift/libswift_Concurrency.dylib' '/private/var/containers/Bundle/Application/5A5B9B8F-4D0F-478A-B25B-2CF006B1C7FA/Illustail.app/Frameworks/libswift_Concurrency.dylib' '/private/var/containers/Bundle/Application/5A5B9B8F-4D0F-478A-B25B-2CF006B1C7FA/Illustail.app/Frameworks/RealmSwift.framework/Frameworks/libswift_Concurrency.dylib' '@rpath/libswift_Concurrency.dylib' '/usr/local/lib/libswift_Concurrency.dylib' '/usr/lib/libswift_Concurrency.dylib' Highlighted by Thread: 0

2

この問題ってライブラリ側で#if availableを気を遣って書いても発生するんですか？

Weak linkにしない限りは起こりそう

#if canImport(_Concurrency) の場合、ランタイムにdylibが環境にあるかは保証できないのでダメ。 if @available(iOS 15) の場合でも、これはimport文には付けられないので、結局暗黙的な import _Concurrency は挿入されてしまって、autolinkで強リンクされるのでダメですね

厳しいですね

Weak linkは乱暴にいうと分岐して呼び出さなければ大丈夫という仕組みなので

本来はドライバが、デプロイメントターゲットが14以下の場合は -weak-l_Concurrency を付けるべきなんですけど漏れてたのかな

意外と身近に起こりそうで、単にライブラリアップデートで起こるのでQA飛ばしがち、みたいなこともありそうで難しい。

ライブラリ提供者側で複数OS検証みたいなことも難しそうですしねぇ

3:45 AM

これまでもOSフレームワークのimportで似たような問題は起こり得たけど、今回のケースは暗黙的にimportが挿入されるから気がつけなさそう

Bitcodeオフでも直るらしいんだけど、それがなんでなのか分からない

CocoaPodsとSPMで試してみたけどweak linkされてるように見えるな。何か条件を見落としてるのかな。

6:04 AM

なるほどApp StoreかTest Flightで配布したときだけなのかな。ということはApple Sideで修正されるべきっていうのはそういうことか。App Store Connectでなんかしているってことか。なのでBitcode Offでも直ると。

https://discord.com/channels/291054398077927425/291211035438874625/920563280509018114 で話してた話、やっぱ @MainActor なメソッドをオーバーライドする場合でも、暗黙的に @MainActor にならない方がいい気がするなぁ。 viewDidAppear とかでも、もし super.viewDidAppear(animated) するなら、そこで await して viewDidAppear の宣言に async を付けるか、 @MainActor を（メソッドまたはクラスに）付けるか選べる。

そもそもはActorContextは暗黙で引き継いで、それとは別にActorContextを引っ剥がすアノテーションがあった方が良いのでは？という話でした

2:33 PM

今だと全て強制的に引っ剥がした上で改めて宣言しろ、となっているが、これは逆の方が勝手が良いのではないか、と

tarunon

そもそもはActorContextは暗黙で引き継いで、それとは別にActorContextを引っ剥がすアノテーションがあった方が良いのでは？という話でした

この実験によると、オーバーライド時は剥がされてなくないですか？ https://discord.com/channels/291054398077927425/291211035438874625/920567683420930068

オーバーライド関係なく、サブクラスのみに生やすメソッド含めて全てMainActorの扱いで良いのではと考えています

逆に、オーバーライドでも @MainActor 扱いをしなくていいんじゃないかというのが https://discord.com/channels/291054398077927425/291054454793306112/920672645412962365 で言いたかったことですね。

https://forums.swift.org/t/a-roadmap-for-improving-swift-performance-predictability-arc-improvements-and-ownership-control/54206

A roadmap for improving Swift performance predictability: ARC impro...

Swift's high-level semantics try to relieve programmers from thinking about memory management in typical application code. In situations where predictable performance and runtime behavior are needed, though, the variability of ARC and Swift's optimizer have proven difficult for performance-oriented programmers to work with. The Swift Performance...

2:17 AM

オーナーシップロードマップ！

おおお….

We will be posting pitches for the features described in this document over the next few months.

2:23 AM

非同期の次はオーナーシップのキャンペーンになるっぽいな

Generalized nonescaping argumentsがアツそうだ

コンパイラが挿入するretain/releaseが見える人向けのアトリビュート公式化きた https://forums.swift.org/t/pitch-formally-defining-consuming-and-nonconsuming-argument-type-modifiers/54313

[Pitch] Formally defining consuming and nonconsuming argument type ...

Hey everyone! This is the consuming/nonconsuming argument type modifier pitch I was speaking about. The permanent URL is: swift-evolution/000b-consuming-nonconsuming.md at consuming-nonconsuming-pitch-v1 · gottesmm/swift-evolution · GitHub. For convenience I also attached it inline below. Formally defining consuming and nonconsuming argumen...

オーナーシップ周りの一部かな？

3:19 AM

@sharedじゃなくて__sharedにするのかな (edited)

ロードマップに出てきたconsmingの単体ピッチだ

こんばんは。こういったコードを見かけたんですが、この記法（Selfを代入してるようでなんか違う）はなんという名前なのでしょう？うまくググれなくて困っておりまして。。。 public static let adaptiveWhite = Self { $0.userInterfaceStyle == .dark ? .isowordsBlack : .white } https://github.com/pointfreeco/isowords/blob/b87f4c61c0523564adf17c031f9fa4b88a40d631/Sources/Styleguide/Colors.swift#L4-L6

isowords/Colors.swift at b87f4c61c0523564adf17c031f9fa4b88a40d631 ·...

Open source game built in SwiftUI and the Composable Architecture. - isowords/Colors.swift at b87f4c61c0523564adf17c031f9fa4b88a40d631 · pointfreeco/isowords

Classにクロージャを受けるrequired initが生えてるんじゃないでしょうか？

あー、なるほど。

11:01 AM

確かに生えてました！ありがとうございます！ https://github.com/pointfreeco/isowords/blob/b87f4c61c0523564adf17c031f9fa4b88a40d631/Sources/SwiftUIHelpers/Color.swift#L17-L20

isowords/Color.swift at b87f4c61c0523564adf17c031f9fa4b88a40d631 · ...

Open source game built in SwiftUI and the Composable Architecture. - isowords/Color.swift at b87f4c61c0523564adf17c031f9fa4b88a40d631 · pointfreeco/isowords

これ、親クラスがUINavigationControllerになるだけでSendableじゃないと言われてしまうんですがなにか分かる方いますか？

これが関係しているかもしれません。 https://bugs.swift.org/browse/SR-15131 Xcode13.2.1だとwarning出ますが、2021-12-23のmain repoのsnapshotにしたらwarning消えました。UIViewController経由でMainActorになっているからとかなんですかね???

(edited)

確かに13.2.1から出たような気はしますね。明示的にMainActor指定してるからSR-15131の状況とは違いそうですが、その修正の巻き添えかなにかでこのパターンが壊れたのかなぁ

1

その辺りチェックしているコードを追ってみようとしているのですが、いつも途中で迷子になるんですよね

どなたかご存知の方がいらっしゃれば教えていただきたいのですが、-warn-concurrencyつけるとMainActor外で使われているUIKitのクラスのclassプロパティなどがエラーになるのですが、このsource breakingを回避する方法ないでしょうか？それともこういうエラーが出なくするまでは-warn-concurrencyはつけらないんですかね….

@MainActor let willResignActiveNotification = UIApplication.willResignActiveNotification トップレベルに代替用の定数を用意して迂回すればエラーは回避できるっぽいですね

ありがとうございます。既存コードに手を入れないで回避する方法はないですかね？(本当のproductionコードだと変更範囲がだいぶ広くなるなと思いまして)

(edited)

shiz

ありがとうございます。既存コードに手を入れないで回避する方法はないですかね？(本当のproductionコードだと変更範囲がだいぶ広くなるなと思いまして)

(edited)

ちょっと分からないですね

引数の方はともかくUIApplication.willResignActiveNotification はObjCからSwiftへのマッピング機能も何か影響していそうですが…

nanasi

ちょっと分からないですね

引数の方はともかくUIApplication.willResignActiveNotification はObjCからSwiftへのマッピング機能も何か影響していそうですが…

いえいえ、ありがとうございます！定数使うというのも一つの手段として検討してみます

koher

waiwaiの途中だけど・・・さっきの Publisher の購読、 extension なしだとこれでいける気がする。

override func viewDidLoad() { super.viewDidLoad() let task = Task { [weak self] in guard let state = self?.state else { return } for await _ in state.objectWillChange.values { guard let self = self else { return } // state を View に反映する処理 self.nameLabel.text = state.user?.name } } cancellables.insert(.init { task.cancel() }) }

(edited)

これ、 will なので state.objectWillChange.receive(on: DispatchQueue.main).values にするなどしないと更新された値が取れませんでした。

https://forums.swift.org/t/se-0339-module-aliasing-for-disambiguation/54730 (edited)

SE-0339: Module Aliasing for Disambiguation

Hello, Swift Community. The review of SE-0339: Module Aliasing for Disambiguation, begins now and runs through January 31st, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emai...

3:48 AM

モジュール名の別名を付ける提案の審査してる

3:49 AM

言語機能じゃなくて、SwiftPM側で、あるターゲットがある依存を取り込む時にビルド設定として別名に置換するらしい

com.apple.Foundation

ライブラリの中のターゲットで Logging みたいな名前が付いてると別の Logging とぶつかる問題。

3:51 AM

https://github.com/apple/swift-tools-support-core/blob/main/Package.swift#L64

swift-tools-support-core/Package.swift at main · apple/swift-tools-...

Contains common infrastructural code for both SwiftPM and llbuild. - swift-tools-support-core/Package.swift at main · apple/swift-tools-support-core

3:51 AM

 .target( /** TSCBasic support library */ name: "TSCBasic", dependencies: [ "TSCLibc", "TSCclibc", .product(name: "SystemPackage", package: "swift-system"), ], exclude: CMakeFiles + ["README.md"]),

3:51 AM

この問題があるから、 swift-tools-support-core とかは内部ターゲットに TSC prefix を付けるなどしている

なるほど

この提案によって、こういうプレフィックスを付けなくてもよくなるはず。 (edited)

SwiftPMのProposalだけどフロントエンドに変更も入るらしいからフロントエンドにパラメータ渡したらSwiftPMでも使えたりするのかな。

6:20 AM

フロントエンドだけで解決するものでもないんだろうか。

Kishikawa Katsumi

SwiftPMのProposalだけどフロントエンドに変更も入るらしいからフロントエンドにパラメータ渡したらSwiftPMでも使えたりするのかな。

Xcodeでも、ですか？

6:33 AM

SwiftPMの仕様が、フロントエンドへのオプションとして展開されるらしいので、できるかもしれない。 xcodebuild越しのパラメータ設定で十分に再現できるかはわからない

あ、間違えてる。SwiftPM以外でも、と書きたかった。SwiftPM以外のパッケージマネージャや直接XCFrameworkを入れた場合でもできたらかなりいいなあと。

結構難しそう

なんと。難しそうですか。

https://github.com/apple/swift-evolution/blob/main/proposals/0339-module-aliasing-for-disambiguation.md#detailed-design アーキテクチャ的なところはDetailed Designのところに結構詳しく書いてありますよ

swift-evolution/0339-module-aliasing-for-disambiguation.md at main ...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0339-module-aliasing-for-disambiguation.md at main · apple/swift-evolution

直感ですがビルド前に介入できるspmのライブラリと、ビルド成果物であるxcframeworkとでは難易度が違う印象です

そういう意味か。↑の記述だと、 Utils をビルドする時にまず GameUtils としてビルドする　って書いてあるから、確かにprebuiltなものだと難しいかも

読んだ感じだと頑張ってリネームするっていうことだからいけるんじゃないかなって。

6:47 AM

マングルされたシンボル名とかも大変そうだけど動的に決まるような要素はないんじゃないかと思って。

First, we need to take the Utils module from swift-game and rename it GameUtils.

6:49 AM

あ、take from して rename か。

func f(_: some Collection) { } の実装キタ https://github.com/apple/swift/pull/40993

Opaque parameters by DougGregor · Pull Request #40993 · apple/swift

Implement function parameters of the form some P be synthesizing an implicit generic parameter whose requirements come from the opaque type. We then map the opaque type back to the generic paramete...

ウオオ

4:30 AM

ORTはまだ本物のreverse genericsにはならない…？

そっちはまだですねぇ

どっちかというとそっちのがほしいw

4:34 AM

シンプルに出来ることが増えるからね

わかる

昔は Opaque Argument Type って呼んでたはずなのに、いつからか Opaque Argument Type ってタームが消え去って、この PR だと Opaque Parameter になってるな。元々 "Improving the UI of generics" にあったはずなんだけど、編集されて残ってない。 ✏️ ボタンから編集履歴見ようとしたけど、クリックしても何も出てこない。見れないんだっけ？ (edited)

argumentは呼び出しに与えるやつで関数の宣言に書く方はparameterだからその呼び替えは良さそう。

質問チャンネルがここじゃなかったら言ってください！

#beginner-help-archived がありますよ

ごめんなさい

11:26 AM

ありがとうございます！

1

https://forums.swift.org/t/the-future-of-reflective-programming-in-swift/54956#reflection-mechanisms-6

The Future of Reflective Programming in Swift

Hello Swift Community, TL;DR Swift has various reflection mechanisms, but they’re fragmented. By combining them, a more flexible and efficient reflection system could be established, that could enable features like compiler-synthesized conformances.

This post simply aims to start a discussion about the future of reflection and cultivate ide...

3:30 AM

動的なリフレクションのAPIを整えた上で、 Hashableの自動生成を、コンパイラ組み込みじゃなくてSwiftライブラリコードとして実装する提案

3:31 AM

その動的なリフレクションのコードは遅くなっちゃうけど、

3:31 AM

最適化によって、コンパイラ組み込み生成と同じものになるってアイデアが面白い。

いいんじゃないか

Tokamakで手書きしてる型リフレクション要らなくなると嬉しい

TokamakUIがまさに再発明してて大変な例として言及されてるね

1

きっとSwiftUIの実装も楽になるだろうから、アップル的にも嬉しい

SwiftUIのリフレクションがSwiftに登ってくる説 (edited)

SwiftUIってそのへんもほんと変な作りだよなｗ

3:46 AM

普通は言語機能のリフレクションを先に整えそうだけど

3:46 AM

ABIが安定化してるからそれがなくても作れるっていう。 (edited)

https://forums.swift.org/t/swift-and-c-interoperability-workgroup-announcement/54998

Swift and C++ interoperability workgroup announcement

Over the past few years there has been a huge amount of interest in bidirectional interoperability between Swift and C++. Thanks to the hard work of zoecarver, egor.zhdan, gribozavr, Michael Forster, Marcel Hlopko, scentini, and many other contributors, the Swift compiler is now able to import and use some C++ APIs, including C++ standard librar...

1

2:53 AM

C++ Interopの実装が進んで、 std::vector とか使えるようになったらしい。これからはC++ Interop Working Groupを作って、毎週ビデオ会議をやったりして進めていくらしい。

1

すごいね。ついにここまできたかって感じ。

すごい。

3:05 AM

https://forums.swift.org/t/bridging-c-templates-with-interop/55003

Bridging C++ Templates with Interop

Bridging Generic APIs In this post I'm going to lay out how I propose we bridge generic C++ APIs to Swift. Refresher If you’re already familiar with both Swift generics and C++ templates, feel free to skim this section and move on to "Goals." C++ Templates In C++ templates can be used for generic programming. Templates, as their name suggest...

3:05 AM

早速、C++ TemplatesがSwiftにインポートさせたときにうまく言語仕様と噛み合わせられなくて困ったよ、ってトピックも投稿されてる。

These are not too far away from C macros, but are substantially more ~complicated~ powerful.

3:12 AM

草

何回か読み直したけど論点がよくわからない・・・

3:25 AM

Class Templatesの章に書いてる func generic<T>(_ v: std.vector<T>) と func concrete(_ v: std.vector<CInt>) の両方に、 let vec = std.vector<CInt>() を渡せるモデルって、今のSwiftの型でいけるよね？

2回読み直したけどわかんなかった

3:52 AM

In the above example, depending on the call, vec needs to be both abstract and concrete.

可変長ジェネリックパラメータのランタイムABIについて検討するスレッドが立ってた https://forums.swift.org/t/abi-for-variadic-generics/55213 言語仕様のスレッドはこっち https://forums.swift.org/t/variadic-generics/54511

ABI for variadic generics

The language design for variadic generics is well underway, and it's time to start settling on decisions about how we're going to implement it. We can roughly divide the implementation into eight pieces: parsing representation in the AST type-checking representation in SIL AST-to-SIL lowering SIL analyses and optimizations SIL-to-LLVM lowerin...

Variadic Generics

Hello Swift Evolution, I'm pleased to bring you a refined copy of the variadic generics proposal, which was first pitched in this thread. The proposal text is available inline and online. I look forward to your feedback and questions. Variadic Generics Proposal: SE-NNNN Authors: Robert Widmann Review Manager: TBD Status: Awaiting implem...

https://forums.swift.org/t/accepted-se-0329-clock-instant-and-duration/55324

[Accepted] SE-0329: Clock, Instant, and Duration

Hello, Swift community. The third review of SE-0329: Clock, Instant, and Duration has come to an end. This review was narrowly focused on some APIs involving the Duration type; other aspects of the proposal were accepted during prior reviews. Review feedback was much lighter, which is not surprising given the narrow scope of the review. The ...

5:55 AM

時間関係の型を追加する提案が採択されたので、プロポーザルを読み直していたんですが気になる箇所があって

5:56 AM

ContinuousClockのところに

On Darwin platforms this refers to time derived from the monotonic clock, for linux platforms this is in reference to the uptime clock; being that those two are the closest in behavioral meaning.

と書いてあって

5:56 AM

SuspendingClockのところに

For Darwin based platforms this is derived from the uptime clock whereas for linux based platforms this is derived from the monotonic clock since those most closely represent the concept for not incrementing while the machine is asleep.

5:56 AM

と書いてあって、

5:57 AM

Continuous: Darwin -> monotonic clock; Linux -> uptime Suspending: Darwin -> uptime; Linux -> monotonic clock

5:57 AM

uptimeを使うかmonotonic clockを使うかが、macとlinuxで反転しているんですけど

5:58 AM

詳しく知りたいんですが、このあたり詳しくなくて、何を見たらいいやら。

単なるミスという可能性

あと、僕が英語を読み違えてる？説もある (edited)

"concept for not incrementing while the machine is asleep" がXNUとLinuxで違う...?

https://github.com/apple/swift/pull/40609/files#diff-b3f1d1e3b61d30d0c688db31783af7e38ea2844443d0310e86c36ec51a2aa076R29-R86

だとしたら面白い

このあたりですね、確かに逆転している

6:01 AM

正確には continuous linux: CLOCK_BOOTTIME continuous mac: CLOCK_MONOTONIC suspending linux: CLOCK_MONOTONIC_RAW suspending mac: CLOCK_UPTIME_RAW (edited)

6:02 AM

で、4ケースとも別の時計を取ってるな

clock_gettime(3) からのそれぞれの実装みればわかるのではないかな...

なるほど

6:04 AM

6:05 AM

CLOCK_BOOTTIME は mac にはそもそも無いんだな

6:05 AM

6:06 AM

BLOCK_BOOTTIME は Linux 2.6.39 で追加されたらしい

なるほど

6:07 AM

uptimeという表現がconfusingってことですねえ (edited)

たしかに、Linuxのマニュアルだと、 CLOCK_BOOTTIME はスリープ中も増加するけど、CLOCK_MONOTONICはそうではない(停止する)　と書いてあって

面白い

macのマニュアルだと、 CLOCK_MONOTONIC がスリープ中も増加するって書いてある

POSIXじゃないのかなこれらは。

STANDARDS The clock_gettime(), clock_settime(), and clock_getres() system calls conform to IEEE Std 1003.1b-1993 (``POSIX.1''). cleck_gettime_nsec_np() is a non-portable Darwin extension. The clock IDs CLOCK_MONOTONIC_RAW and CLOCK_UPTIME_RAW are extensions to the POSIX interface.

6:09 AM

もしかしてposixには「スリープ」の概念が無いのかな？

POSIX準拠(POSIXに準拠するとは言ってない) (edited)

6:09 AM

(XNUあるある)

難しいな〜　これは標準ライブラリで隠蔽してもらえると嬉しいやつだ

https://forums.swift.org/t/pitch-implicitly-opening-existentials/55412/

[Pitch] Implicitly opening existentials

Hi all, I've been looking into generics ergonomics, and one of the problems that keeps coming up is that going from concrete types or generics into existentials is a bit of a one-way street: you can create an any P from a value of any type that conforms to P, but once you have that existential value of type any P it's hard to get back to using ...

2:38 AM

existentialを暗黙にopenする、とんでもない仕様の提案が出てる

2:39 AM

見かけ上　any P が P に準拠するようになる

_openExistential あるしprotocol extensionでもopenできるし、裏技だったやつが表に出てきた?

そうそう。

2:42 AM

裏技の経由を不要にする (edited)

裏技w

_openExistential 初めて知った

_openExistential のインターフェースは Swift言語で型を記述できないマジック関数

protocol Costume { func withBells() -> Self func hasSameAdornments(as other: Self) -> Bool } func hasBells<C: Costume>(_ costume: Costume) -> Bool { return costume.hasSameAdornments(as: costume.withBells()) }

2:54 AM

func checkFinaleReadiness(costumes: [any Costume]) -> Bool { for costume in costumes { if !hasBells(costume) { // okay with this proposal: C is bound to the type stored inside the 'any' box, known only at runtime return false } } return true }

↑これができるようになる

2:56 AM

func checkFinaleReadinessOpenCoded(costumes: [any Costume]) -> Bool { for costume: some Costume in costumes { // implicit generic parameter binds to underlying type of each costume let costumeWithBells = costume.withBells() // returned type is the same 'some Costume' as 'costume' if !costume.hasSameAdornments(costumeWithBells) { // okay, 'costume' and 'costumeWithBells' have the same type return false } } return true }

↑これもできるようにするって書いてあるのかな・・・？

2:57 AM

any P に対して Self を返すメソッドを呼び出すと、 some P として返ってくる

2:59 AM

func cannotOpen1<T: P>(_ array: [T]) { .. } func cannotOpen2<T: P>(_ a: T, _ b: T) { ... } func cannotOpen3<T: P>(_ values: T...) { ... } struct X<T> { } func cannotOpen4<T: P>(_ x: X<T>) { } func cannotOpen5<T: P>(_ x: T, _ a: T.A) { } func cannotOpen6<T: P>(_ x: T?) { } func testCannotOpenMultiple(array: [any P], p1: any P, p2: any P, xp: X<any P>, pOpt: (any P)?) { cannotOpen1(array) // each element in the array can have a different underlying type, so we cannot open cannotOpen2(p1, p2) // p1 and p2 can have different underlying types, so there is no consistent binding for 'T' cannotOpen3(p1, p2) // similar to the case above, p1 and p2 have different types, so we cannot open them cannotOpen4(xp) // cannot open the existential in 'X<any P>' there isn't a specific value there. cannotOpen5(p1, p2.getA()) // cannot open either argument because 'T' is used in both parameters cannotOpen6(pOpt) // cannot open the existential in '(any P)?' because it might be nil, so there would not be an underlying type }

↑ structural position だと P のオブジェクトの数が動的になるから open できない

一瞬ウェッと思ったけど、直感は成り立つンじゃないかと言っている

Optionalのケースがだめなのは面白いな。実際の (any P)? が nil のときに、動的な真の型が取り出せない (edited)

3:02 AM

Neverがボトムタイプだったら、そのときは Never: P として open できそうだけど

X<any P> がダメだしそれはそう

3:06 AM

as? 的に失敗を許容するバリアントが欲しくなる？

厳密には X<any P> については X<T> が T を返すメソッドを持ってるかどうかじゃないかな

Tを引数にとる場合とTを返す場合があって (edited)

3:08 AM

swiftのgenericsはそれを区別する型でないから、出来るかどうかが型として明示的にならないと思う

返り値の型に出現するかどうかはチェックできるんじゃないですかね。頑張れば

tarunon

swiftのgenericsはそれを区別する型でないから、出来るかどうかが型として明示的にならないと思う

正しいと思う。

3:11 AM

多分同じことを言っていて

3:12 AM

今の Swift のジェネリック型のパラメータ部分は保守的に invariant だから、その規則だと無理ってことになるけど

3:12 AM

メンバ単位で出現状況をチェックするようにしたら、許容しうるという話

X<in T> X<out T> X<inout T> が表現できるようになれば

で、 Optional型に絞って考えれば、コンパイラ特別扱いで、 out parameter なのは既知だからありじゃないかってのが俺の言った事

許される境界を作れる

現在でも T < U で T? < U? の暗黙変換があるのは Optional の T が out parameter という知識が組み込まれてるからなので。

3:14 AM

ただ Never: P も現状は実装されてないから飛躍が２つ必要。

なるほど

omochimetaru

https://forums.swift.org/t/accepted-se-0329-clock-instant-and-duration/55324

このPRがマージされて、いつものようにWasmビルドが壊れたので直してたんですが、WASIはsleep中のクロックの増加に対して何も規定していなくて困ったな〜となった。が、ふとWindows向けの実装を見てみると ContinuousClock とSuspendingClock で全く同じ実装になってたので、WASIもそんな感じでお茶を濁しました。（それでいいのか？） https://github.com/apple/swift/blob/a0fbce0ffd111243bef190b58f838c269dfc5efd/stdlib/public/Concurrency/Clock.cpp#L74-L86 https://github.com/apple/swift/blob/a0fbce0ffd111243bef190b58f838c269dfc5efd/stdlib/public/Concurrency/Clock.cpp#L46-L57 (edited)

Yuta Saito

このPRがマージされて、いつものようにWasmビルドが壊れたので直してたんですが、WASIはsleep中のクロックの増加に対して何も規定していなくて困ったな〜となった。が、ふとWindows向けの実装を見てみると ContinuousClock とSuspendingClock で全く同じ実装になってたので、WASIもそんな感じでお茶を濁しました。（それでいいのか？） https://github.com/apple/swift/blob/a0fbce0ffd111243bef190b58f838c269dfc5efd/stdlib/public/Concurrency/Clock.cpp#L74-L86 https://github.com/apple/swift/blob/a0fbce0ffd111243bef190b58f838c269dfc5efd/stdlib/public/Concurrency/Clock.cpp#L46-L57 (edited)

Windowsはどうなんだろうなこれｗ WASIに関しては、Sleepの概念が存在してるかも微妙だね

なんとpollのタイムアウトでsleepを表現します

あ、待ちじゃなくて、OSのスリープ状態のことね

https://forums.swift.org/t/pitch-implicitly-opening-existentials/55412/24

[Pitch] Implicitly opening existentials

I'm excited to see this, opening existentials is a major gap in Swift expressiveness. I'm a bit concerned about the need to repeat the protocol name in some P. It does not look that bad in proposal with single-letter names, but I'm afraid that in production code it may be pretty verbose: func authenticate(alternativeAuthenticationProviders: [...

3:41 AM

protocol P { static func make() -> Self {} } func f<T: P>(x: T?) { print(x ?? T.make()) } let x: (any P)? = nil f(x) // It is not valid to substitute [T = Never] here

3:42 AM

Neverは全てのexistential には代入できるけど全てのprotocolには代入できないという意見をもらった

3:42 AM

↑たしかに上記コードだと Never.make() -> Never を呼び出す事になって実行時エラーが生じる

3:43 AM

実行時エラーが生じる事と、Neverが bottom type であるかどうかはまた別な気もするけど fatalError 関数とか実在するし

Neverが値として出現するならばそれはクラッシュなんじゃないか

3:46 AM

だから実行時エラーになる、というのはむしろそうなるべきであるはず

実行時エラーでそこで止まる分には、型理論的には壊れてない、よねえ？

3:48 AM

うーんでもそれ言うとなんでもありになっちゃうか？

それが正しいと思います

3:48 AM

Neverはそもそもそういう型だと思いますよ

クラッシュすれば見逃されるんなら、どんな型もどんな型に代入できる

BottomTypeはそういうものであるべき

ああNeverだけがその無茶苦茶な互換性を認められたものってことか

発生しない値だから、何にでもなれる

ここで言ってるのは

but it does not conform to every protocol:

だからNever: Pが常に成り立つとは限らないという話？

でもその例としての P.make は、 Self = Never を返す関数として、クラッシュしたらいいから、成り立たせられる (edited)

Pのstaticメソッドに返り値がSelfじゃないものがあると成り立たなくなる？ (edited)

例えば make の返り値が Int 固定だったら埋めようが無いから駄目か？ (edited)

protocol P { static func foo() -> Int } extension Never: P { static func foo() -> Int { ??? } } func takeP<T: P>(x: T) -> Int { T.foo() } let x: (any P)? = nil takeP(x)

(edited)

3:57 AM

そうそう

そもそも前提としてNeverの実体化が出来ないのだから

3:57 AM

その関数が実行されることはなく問題にならない

Never.Typeは実体化出来る

あ〜

3:57 AM

なるほど

tarunon

そもそも前提としてNeverの実体化が出来ないのだから

インスタンスは存在しないけど、metatypeは居るんだよな

3:58 AM

static funcに関してはnever特権理論が消えるのかなあ。

Never.Typeに対する関数呼び出しをクラッシュにしてしまって

3:58 AM

解決ということにした方が、諸々シンプルになる気がするなぁ

でもそれだと、あらゆる P の static func が

3:59 AM

Neverいれて実行時エラーを生じさせる事にもなるね (edited)

(any P)?のopenを禁止して、ちゃんとユーザにオプショナルアンラップさせるほうが良い気がするなぁ

他の言語のprotocol相当の機能にstatic関数がついてない事が多い理由が、ここにある気がしてきた (edited)

tarunon

他の言語のprotocol相当の機能にstatic関数がついてない事が多い理由が、ここにある気がしてきた (edited)

static func or associatedtype があったらNever conformはできない、というのはありかも。

4:00 AM

PATと同じ条件

それもいいかもね

言い換えると、他の言語だとnon PATしかないんだよね。 (edited)

Neverはstatic関数ある場合は自動でconformしない(ユーザがextensionする分にはok)

4:01 AM

これは良いバランスだと思う

tarunon

Neverはstatic関数ある場合は自動でconformしない(ユーザがextensionする分にはok)

よさそう

ユーザが書くと関数の実装も強制される

そうか、ユーザが勝手にconformance実装できるから、自動実装と思えば自然か

initは良いんだっけ

-> Selfまたは-> Self?だから良い？

throwsと将来的にasyncもあるけど (edited)

4:04 AM

うーんグレーだな、落として良い気がする

-> Self は fatalError() と同じで実装しないままクラッシュで許すはありな気もする (edited)

 override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) test2 { // com.apple.root.default-qos.cooperative print(Thread.current) } test2 { @MainActor () in // com.apple.main-thread print(Thread.current) } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

8:16 AM

無印関数を @MainActor 関数に変換するときに、メインスレッドにホップするサンクでラップしてくれないの、おかしそう

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print(Thread.current) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print(Thread.current) c.resume(returning: ()) } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

Yuta Saito

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print(Thread.current) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print(Thread.current) c.resume(returning: ()) } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

<Thread: 0x00007f0e14001040> <Thread: 0x00007f0e14001040> (edited)

なんか余計なもんつけちゃった？

queueの名前はデバッガで止めて調べました、実はこのprintでは出ないです

10:56 AM

あれ、スレッドが同じだな

10:57 AM

static func main() って暗黙のMainActor ? (edited)

いやー、めっちゃありそうなバグなんですよね。Actorホッピング漏れ結構ある

10:58 AM

普通にViewControllerにペタっと貼っても再現しなかったです

実験してるコードだと、 viewDidAppear とは書いてあるけど、これVCじゃなくて、全く @MainActor じゃないクラスです

ふむふむ

ViewControllerとかさっきのstaticfuncmainだと

10:59 AM

メソッドが @MainActor なせいで、クロージャリテラルも @MainActor に推論されてないかね

あ、このviewDidAppearめっちゃUIViewControllerっぽかったけどそうじゃなかったんですねｗ

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print(Thread.current) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print(Thread.current) c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

Yuta Saito

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print(Thread.current) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print(Thread.current) c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

<Thread: 0x00007f8c100030f0> <Thread: 0x00007f8bec000c20> (edited)

ほい

ここでparse-as-libraryつけるのってどんな意味があるんですか

無いと@main書けないので付けてますね

1

[omochi@omochi-iMacPro async]$ swift -Xfrontend -parse-as-library a.swift JIT session error: Symbols not found: [ _swift_task_asyncMainDrainQueue, _swift_task_getMainExecutor ] Failed to materialize symbols: { (main, { _symbolic B0, _$s1a4MainVN, _$sIetH_yts5Error_pIegHrzo_TRTu, _$sS2cMScAsWl, _symbolic IetH_, _$s1a4TestCMa, _$s1aMXM, ___swift_async_resume_project_context, _$s1a4MainV4mainyyYaKFZTu, _$s1a4MainVMn, __swift_async_extendedFramePointerFlagsUser, _$s1a4MainVMa, _$s1a4TestC5test2yyyyYacFTq, _$s1a4TestC5test1yyyyYaScMYccF, _symbolic _____ 1a4MainV, _$s1a4TestC5test2yyyyYacF, _$s1a4TestC5test1yyyyYaScMYccFTq, _$s1a4TestCMm, _$s1a4MainV5$mainyyYaKFZ, _symbolic IegH_, _$s1a4TestCN, _$sSccySccyxq_GBccfC, _$sScTss5NeverORs_rlE8detached8priority9operationScTyxABGScPSg_xyYaYbcntFZ, $.a.__inits.0, __swift_FORCE_LOAD_$_swiftObjectiveC_$_a, _$sScPSgMD, _$s1a4TestCACycfCTq, _$s1a4TestC4mainyyYaFTq, _$sIetH_yts5Error_pIegHrzo_TR, _$sIeghH_ytIeghHr_TRTu, _$s1a4TestCfd, _$sSa12_endMutationyyF, _$s1a4TestCACycfC, _$sScPSgWOh, _main, _$sIeghH_ytIeghHr_TR, _$sScPSgWOc, _async_MainTu, _async_Main, _symbolic IeghH_, _$s1a4MainV4mainyyYaKFZ, _$s1a4TestCACycfc, __swift_FORCE_LOAD_$_swiftCoreGraphics_$_a, _got.$sSccMn, ___swift_async_resume_get_context, _$sxIeghHr_xs5Error_pIegHrzo_s5NeverORs_r0_lTR, _got.$ss5NeverOMn, _$sScTyScTyxq_GBocfC, _$ss27_finalizeUninitializedArrayySayxGABnlF, _got.$sScPMn, _$sS2cMScAsWL, ___swift_instantiateConcreteTypeFromMangledName, _$s1a4TestCfD, _$ss22withUnsafeContinuationyxySccyxs5NeverOGXEYalFyBcXEfU_, _symbolic _____Sg ScP, _$ss22withUnsafeContinuationyxySccyxs5NeverOGXEYalF, __swift_FORCE_LOAD_$_swiftDarwin_$_a, _$s1a4TestCMn, _symbolic xIeghHr_, _$s1a4TestC4mainyyYaFTu, __swift_FORCE_LOAD_$_swiftCoreFoundation_$_a, _$ss5print_9separator10terminatoryypd_S2StFfA1_, _symbolic _____ 1a4TestC, _$sScc6resume9returningyxn_ts5NeverORs_rlF, _$s1a4TestC4mainyyYaF, __swift_FORCE_LOAD_$_swiftDispatch_$_a, _$sxIeghHr_xs5Error_pIegHrzo_s5NeverORs_r0_lTRTu, _$ss5print_9separator10terminatoryypd_S2StFfA0_, _symbolic _____yyt_____G Scc s5NeverO, __swift_FORCE_LOAD_$_swiftXPC_$_a, _$s1a4MainV5$mainyyYaKFZTu, _symbolic x, __swift_FORCE_LOAD_$_swiftFoundation_$_a, __swift_FORCE_LOAD_$_swiftIOKit_$_a, _$ss22withUnsafeContinuationyxySccyxs5NeverOGXEYalFTu }) }

11:05 AM

あー BigSurだからか

Immediateモードやめよう

swift55

<Thread: 0x00007f8c100030f0> <Thread: 0x00007f8bec000c20> (edited)

別のスレッドになった？

なってますねー

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print(Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print(Thread.current, Thread.isMainThread) c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

Iceman

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print(Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print(Thread.current, Thread.isMainThread) c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

<Thread: 0x000000000a1b43a0> true <Thread: 0x00007f1a64002d20> false <Thread: 0x00007f1a44000c40> false (edited)

あれ、main()はMainActorのスレッドというわけではないのか

class Test { func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } func test2(_ f: @escaping () async -> Void) { test1(f) } func main() async { let _: Void = await withUnsafeContinuation { c in test2 { print(Thread.current) c.resume(returning: ()) } } let _: Void = await withUnsafeContinuation { c in test2 { @MainActor () in print(Thread.current) c.resume(returning: ()) } } } } // AppDelegate func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? ) -> Bool { Task.detached { await Test().main() } return true }

(edited)

いや、MainActor強制です

iOSのappDelegateにコピペしたら再現できるようにした

11:09 AM

このとき出力が <NSThread: 0x282cdc480>{number = 5, name = (null)} <_NSMainThread: 0x282c8c080>{number = 1, name = main}

むしろ後者のMainActorついたクロージャがメインスレッドじゃないとこで実行されてるのか

あれ？

swift55

<Thread: 0x000000000a1b43a0> true <Thread: 0x00007f1a64002d20> false <Thread: 0x00007f1a44000c40> false (edited)

この結果はこっちの実験とはまた違うね。どっちもメインスレッドじゃないじゃん。

detachedでキューにスケジューリングされて実行順入れ替わってる？

11:11 AM

ラベル付け無いとわからん

ああそうか

11:11 AM

test2はなげっぱで待機してないから実行とログの組み合わせが確定してない (edited)

@swift-5.5.3 @swift-main -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print("t1", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print("t2", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

Yuta Saito

@swift-5.5.3 @swift-main -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print("t1", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print("t2", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

<Thread: 0x000000000b6fdf60> true t1 <Thread: 0x00007fa520002d40> false t2 <Thread: 0x00007fa508000c60> false (edited)

Yuta Saito

@swift-5.5.3 @swift-main -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print("t1", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print("t2", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) }

(edited)

<Thread: 0x000000000b244040> true t1 <Thread: 0x00007ff42c12ce70> false t2 <Thread: 0x00007ff414000c40> false

クロージャにMainActorついてても呼び出す側の気分で変わるのかあ

それは余計に困る。

ホップは基本的にcaller側の責務ですね

え、そうなの？

11:19 AM

それなら test1 の await f() で hop してないのが変ってことになるけど

変

他にもいろいろ試した感じでは、callee側で、ラムダ式を書くときに

11:20 AM

自己hopな関数が生成されてると思った

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print("t1", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print("t2", Thread.current, Thread.isMainThread) assumeMainActor() c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) } @MainActor func assumeMainActor() { print("Here must be MainActor! but Thread.isMainThread = \(Thread.isMainThread)") }

Yuta Saito

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test2 { // com.apple.root.default-qos.cooperative print("t1", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test2 { @MainActor () in // com.apple.main-thread print("t2", Thread.current, Thread.isMainThread) assumeMainActor() c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) } @MainActor func assumeMainActor() { print("Here must be MainActor! but Thread.isMainThread = \(Thread.isMainThread)") }

<Thread: 0x000000000ad55e70> true t1 <Thread: 0x00007f1f68002d40> false t2 <Thread: 0x00007f1f48000c60> false Here must be MainActor! but Thread.isMainThread = false

assumeMainActorのcallerはMainActorに居ると信じているので、assumeMainActor呼ぶ前にhopしなくて、こういうことになります。

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test1 { print("t1", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test1 { @MainActor () in print("t2", Thread.current, Thread.isMainThread) assumeMainActor() c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) } @MainActor func assumeMainActor() { print("Here must be MainActor! but Thread.isMainThread = \(Thread.isMainThread)") }

omochimetaru

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @globalActor actor OtherActor { static let shared = OtherActor() static func run(_ body: @OtherActor () async -> Void) async { @OtherActor func inner() async { await body() } await inner() } } @main struct Entrypoint { static func main() async throws { print(Thread.current, Thread.isMainThread) await OtherActor.run { let _: () = await withUnsafeContinuation { c in test1 { print("t1", Thread.current, Thread.isMainThread) c.resume(returning: ()) } } let _: () = await withUnsafeContinuation { c in test1 { @MainActor () in print("t2", Thread.current, Thread.isMainThread) assumeMainActor() c.resume(returning: ()) } } } } } private func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } private func test2(_ f: @escaping () async -> Void) { test1(f) } @MainActor func assumeMainActor() { print("Here must be MainActor! but Thread.isMainThread = \(Thread.isMainThread)") }

<Thread: 0x000000000a88e080> true t1 <Thread: 0x00007f28a0000c60> false t2 <Thread: 0x00007f28a0000c60> false Here must be MainActor! but Thread.isMainThread = false

むむっ

11:25 AM

test2じゃなくてtest1を直接呼ぶように変えたら

11:25 AM

t1もt2も、メインスレッドじゃないのはおかしいんだけど、でも、同じスレッドになった。

11:25 AM

test2を呼ぶテストのときは、t1とt2が、別のスレッドになったのに。

なんじゃこりゃ

偶然？

手元での実験だとクロージャ自体がメインに投入するようになってるからこそ、片方は変なスレッドだけど、もう片方はメインスレッドになったと解釈してたけど

11:28 AM

ここのLinuxの実験だと、まったく違う結果というか、何をどうやってもメインに投入されてないので

Task.detachedは実行時にActorを継承しないけど、なぜか静的にはクロージャの中がMainActorに居ることになっていて、f()でホップが発生してない。

お話にならないように見える

11:29 AM

あー、Task.detachedを書く場所の違い？

11:30 AM

グローバル関数なのか、クラスのメソッドなのかで、

11:30 AM

コンパイラの挙動が違う可能性があるね

ありそう

omochimetaru

class Test { func test1(_ f: @MainActor @escaping () async -> Void) { Task.detached { await f() } } func test2(_ f: @escaping () async -> Void) { test1(f) } func main() async { let _: Void = await withUnsafeContinuation { c in test2 { print(Thread.current) c.resume(returning: ()) } } let _: Void = await withUnsafeContinuation { c in test2 { @MainActor () in print(Thread.current) c.resume(returning: ()) } } } } // AppDelegate func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? ) -> Bool { Task.detached { await Test().main() } return true }

(edited)

この自分のやつはtest1とtest2はメソッド

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) } } }

Yuta Saito

@swift-5.5.3 -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) } } }

in main(): <Thread: 0x000000000ab51790> true in MainActor.run: <Thread: 0x000000000ab51790> true

ありゃ、これ手元のLinuxで↓になるんですよね in main(): <Thread: 0x000055ec99acfd90> true in MainActor.run: <Thread: 0x00007fca74000bf0> false (edited)

11:36 AM

つまり、MainActorに居てもisMainThreadがtrueとは限らないんじゃないかと疑ったんですが、botだとその可能性はなさそう (edited)

ふむー

@swift-5.5.3 -Xfrontend -parse-as-library @swift-5.6.3 -Xfrontend -parse-as-library @swift-main -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) } } }

(edited)

norio_nomura

@swift-5.5.3 -Xfrontend -parse-as-library @swift-5.6.3 -Xfrontend -parse-as-library @swift-main -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) } } }

(edited)

in main(): <Thread: 0x0000000009dd57c0> true in MainActor.run: <Thread: 0x0000000009dd57c0> true

norio_nomura

@swift-5.5.3 -Xfrontend -parse-as-library @swift-5.6.3 -Xfrontend -parse-as-library @swift-main -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) } } }

(edited)

in main(): <Thread: 0x000000000bb0d200> true in MainActor.run: <Thread: 0x00007f3f14000c40> false

MainActor.run でメインスレッドじゃないのかー

nightlyがおかしいの？

なるほどおかしい

norio_nomura

@swift-5.5.3 -Xfrontend -parse-as-library @swift-5.6.3 -Xfrontend -parse-as-library @swift-main -Xfrontend -parse-as-library

import Foundation @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) } } }

(edited)

in main(): <Thread: 0x000000000bd3c440> true in MainActor.run: <Thread: 0x000000000bd3c440> true

https://github.com/apple/swift/blob/8e154a415a2d0467690db69bac1d6090fc8b4852/stdlib/public/Concurrency/MainActor.swift#L66

4:24 AM

実装は @MainActor の作用に任されている？

https://github.com/apple/swift/commit/2850b65bd933c8906c2eb56b38e724b951df8c31

Simplify implementation and fix a test · apple/swift@2850b65

ウオ、いじっとる

↑のOtherActor.runの形じゃ無くなってる

https://github.com/apple/swift/blob/e675b310f89bb9fdfe6e139bdece3dcd28ad636f/stdlib/public/Concurrency/CooperativeGlobalExecutor.inc#L105

swift/CooperativeGlobalExecutor.inc at e675b310f89bb9fdfe6e139bdece...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

4:26 AM

c++ /// Enqueues a task on the main executor. SWIFT_CC(swift) static void swift_task_enqueueMainExecutorImpl(Job *job) { // The cooperative executor does not distinguish between the main // queue and the global queue. swift_task_enqueueGlobalImpl(job); }

4:26 AM

あ、こっちじゃないか・・・？

4:26 AM

https://github.com/apple/swift/blob/e675b310f89bb9fdfe6e139bdece3dcd28ad636f/stdlib/public/Concurrency/DispatchGlobalExecutor.inc#L304

swift/DispatchGlobalExecutor.inc at e675b310f89bb9fdfe6e139bdece3dc...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

4:27 AM

c++ SWIFT_CC(swift) static void swift_task_enqueueMainExecutorImpl(Job *job) { assert(job && "no job provided"); JobPriority priority = job->getPriority(); // This is an inline function that compiles down to a pointer to a global. auto mainQueue = dispatch_get_main_queue(); dispatchEnqueue(mainQueue, job, (dispatch_qos_class_t)priority, mainQueue); }

これはMainActorにホップする時に呼ばれるやつ

MainActor._enqueue から辿っていったらここに来そうだった

4:28 AM

CooperativeGlobalExecutor.inc の swift_task_enqueueMainExecutorImpl はなんなんだろう

4:28 AM

@MainActor の呼び出しを MainActor._enqueue に変換する処理はコード生成なんかな

アクターのホップポイントは、SILの時点でhop_to_executorになっていて、 (edited)

4:35 AM

IRGenでswift_future_ なんちゃらAPIの呼び出しになる。enqueueはその中で呼ばれてるはず (edited)

4:36 AM

だから、MainActor.runの実装のSILを見て、hop_to_executorの有無を確認したい

なるほどなるほど

Asynchronous functions isolated to global actors hop to the global at the beginning of the function but do not hop back on return.

https://github.com/apple/swift/pull/39872 あれ、認識間違ってたかも (edited)

お。

@swift-main -Xfrontend -parse-as-library

import Dispatch import Foundation func checkIfMainQueue(expectedAnswer expected: Bool) { dispatchPrecondition(condition: expected ? .onQueue(DispatchQueue.main) : .notOnQueue(DispatchQueue.main)) } @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) checkIfMainQueue(expectedAnswer: true) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) checkIfMainQueue(expectedAnswer: true) } } }

(edited)

Yuta Saito

@swift-main -Xfrontend -parse-as-library

import Dispatch import Foundation func checkIfMainQueue(expectedAnswer expected: Bool) { dispatchPrecondition(condition: expected ? .onQueue(DispatchQueue.main) : .notOnQueue(DispatchQueue.main)) } @main struct Entrypoint { static func main() async throws { print("in main():", Thread.current, Thread.isMainThread) checkIfMainQueue(expectedAnswer: true) await MainActor.run { print("in MainActor.run:", Thread.current, Thread.isMainThread) checkIfMainQueue(expectedAnswer: true) } } }

(edited)

in main(): <Thread: 0x000000000a8d75b0> true in MainActor.run: <Thread: 0x00007f6f54000c40> false (edited)

テストケース見てると、↑みたいにDispatchQueue.mainにいるかを検証していて、Thread.isMainThreadは見ていない模様

4:52 AM

そしてメインスレッドではないがDispatchQueue.main上にいる。

main queueがスレッドを移動する？

4:52 AM

@main の func main async が変な挙動するのかな

https://forums.swift.org/t/se-0345-if-let-shorthand-for-shadowing-an-existing-optional-variable/55805

SE-0345: if let shorthand for shadowing an existing optional vari...

Hello Swift community, The review of SE-0345 "if let shorthand for shadowing an existing optional variable" begins now and runs through March 22, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the revi...

4:01 AM

短縮if letの審査開始

これはスッと決まりそうだな。

これって超初期から、「よく聞かれるけどやらないよ」って言ってたアイデアなんですけど

4:04 AM

最近しばらくずっとスレッドが盛り上がっていて

4:04 AM

この前のラトナー引退のときもこのスレでのやり取りが引用されてたんですよね

4:09 AM

流れが変わってるなあ

そうなんだ。

スレ建ったときはシンプルじゃなくなるから却下、で終わりだと思ってたのに

まあLattnerさんの話を除外してもSwiftの見た目の文法は初期の頃とはだいぶ変わってるから拒否感はなくなってるとか。

4:11 AM

今さらシンプルじゃなくなるって言われてもねえ、、、みたいな。

4:11 AM

むしろシンプルやん。

ある変数の型は let で定義した時から固定って考え方なんですよね

4:12 AM

この文法を導入してしまうと、

4:12 AM

同じ変数のままなのに型が変わるっていうSwiftには無かった概念が出てくる (TypeScriptのフローキャストのような感じになる）

4:12 AM

のと、代入の省略記法なのか、変数の型変化なのかが文法上わからないから

4:13 AM

この変数が inout だったりしたときに、どうなるのかよくわからない

4:13 AM

if let 後に代入したら、元の変数も変化するのか、それとも分離された変数になっているのか。

let a = a, の左辺で変わるというのが今までの動作だけど let a で変わると混乱ってことか。 (edited)

そうそう。そこに代入文の形になっていて、型変化の前後で別物として分離されているというセマンティクスが

4:14 AM

省略記法を導入すると(見た目から)よくわからなくなる。 (edited)

4:14 AM

Swiftの見た目の文法は初期の頃とはだいぶ変わってる

↑これは一理ありますね。property wrapperとか、dynamic keypath とか、 result builder とか、もう見た目からは動作がさっぱり想像できないやついっぱいできちゃったｗ (edited)

別の変数に関する定義と使用が同じ箇所にあるのがなぁ

こういうのはScalaの周辺の議論でよく言われるのは easy と simple の違いってやつで

省略したら分かりにくくなる、は妥当なんですけど、それは省略だからlet a = a,の右辺が省略されてるんですよ、で解決してしまうな。

このif let 省略はいわゆる、easy だけど simple ではない　タイプの機能ですね

もっと決定的な衝突とかがないと難しそう。

Kishikawa Katsumi

省略したら分かりにくくなる、は妥当なんですけど、それは省略だからlet a = a,の右辺が省略されてるんですよ、で解決してしまうな。

そうですね。「知識が無いと読み解けない文法はこれに始まった事じゃないし、同名への代入って事を知っておけばいいだけじゃん」的なことをairspeedswiftさんが書いてた気がする

まあなんか２回書きたくないっていう考え方はけっこうあるよね。 JSのJSON記法もそういう省略あるし。

inoutで使った場合みたいなコーナーケースの混乱を気にするより、多くの場合で楽に書けるようになるメリットのほうが大きいじゃん的な

if var x も一緒に入るんですかこれ？

4:23 AM

if let foo { ... } if var foo { ... } あった

if let foo { ... } if var foo { ... } else if let foo { ... } else if var foo { ... } guard let foo else { ... } guard var foo else { ... } while let foo { ... } while var foo { ... }

4:24 AM

Detailed Designのとこに↑こんなのが

if let foo.bar { ... } // 🛑 これはダメと

Alternatives considered if foo if unwrap foo if let foo? if foo != nil if var foo は無し

4:26 AM

議論読んでないけどこれらは検討却下済みのようだ

if fooは衝突するよな。Bool的なやつと

1

Author の Cal Stephens さんは airbnb の人らしい

if let foo? いいなと思ったけど if let foo?: Foo 型アノテーション付けにくいとのこと

省略とは違うから別でやってほしいけど、 if foo != nil でfooがオプショナル外れるのはほしいな

1

IDEが = fooを薄く表示してくれれば混乱は減りそう

IntelliJっぽい

4:36 AM

いいよね

Xcodeくんガタガタだからなあ

1

それだ。それ最高だ。

Kishikawa Katsumi

省略とは違うから別でやってほしいけど、 if foo != nil でfooがオプショナル外れるのはほしいな

そういう Smart Cast 的なやつは、宣言箇所にジャンプしたときに型を確認できないからやらないって話が、前に別の文脈であったような。何の機能のときだっけな。

なるほど。それもわかる。まあだいたいはif letかguard letでいいし。どういうときに欲しいと思ったんだったかな。。。？

何か思い出せないんですが、ProposalかForumかの議論で、何かの機能について話してる中で、（多分Core Teamの誰かに）↑の理由が挙げられてたはずなんですよね。何も思い出せてなくてすみませんが

いえいえ。すでに議論済みだとは思ってました。理由がわかって興味深いです。

https://forums.swift.org/t/se-0346-lightweight-same-type-requirements-for-primary-associated-types/55869

SE-0346: Lightweight same-type requirements for primary associated ...

Hello, Swift community. The review of SE-0346: Lightweight same-type requirements for primary associated types begins now and runs through March 29th, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me ...

8:23 AM

プロトコルのprinary associated typeをangle bracketで書ける提案が審査入り

8:30 AM

https://github.com/apple/swift-evolution/blob/main/proposals/0346-light-weight-same-type-syntax.md#generic-protocols

swift-evolution/0346-light-weight-same-type-syntax.md at main · app...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0346-light-weight-same-type-syntax.md at main · apple/swift-evolution

8:32 AM

将来ありえるジェネリックプロトコルの文法を奪ってしまう問題については提案書で言及されてた

8:36 AM

途中までは何言ってるかわかるが最後の段落の

Nothing in this proposal precludes …

が、英語が読み解けない、、

if let x くらいならいいんですけれど、過去の互換のために associatedTypeとProgocol<E>みたいなのが混在するのは混乱しそう… (edited)

11:36 AM

でもmotivationを見ると結構よさそうですね

quesera2

if let x くらいならいいんですけれど、過去の互換のために associatedTypeとProgocol<E>みたいなのが混在するのは混乱しそう… (edited)

この前やってた any キーワードの話とかと合わせると、 AnySequence<Element> の代わりに any Sequence<Element> とか書けるようになって、これは直感的だし便利ですよね。

1

1:15 PM

AnySequence はライブラリ実装だけど any Sequence は言語機能だし。

omochimetaru

途中までは何言ってるかわかるが最後の段落の

Nothing in this proposal precludes …

が、英語が読み解けない、、

Nothing in this proposal precludes introducing generic protocols in the future under a different syntax

このプロポーザルの提案が将来的に異なる構文でジェネリックプロトコルを導入することを不可能にするわけではないくらいの感じ？で、例として↓のような構文が挙げられていると。

protocol Convertible(from: Self, to: Other) { static func convert(_: Self) -> Other } extension Convertible(from: String, to: Int) { static func convert(_: String) -> Int } extension Convertible(from: String, to: Double) { static func convert(_: String) -> Int }

Opaque result typeのassociated typeを指定できるようになるの良さそうですね。 https://github.com/pointfreeco/swift-parsing/blob/e7c65755c5634bd0ab4edd076c8b1b442f71457d/Sources/Parsing/Parser.swift#L231-L275

あれ、これって糖衣だけかと思ってたんですがORTに型パラ埋められるんですか

1:03 AM

eraseToAnyPublisherを大幅に減らせる？

かなり要らなくなりそう

Iceman

あれ、これって糖衣だけかと思ってたんですがORTに型パラ埋められるんですか

実はしれっと入っていて、pitch段階では「これ別のプロポーザルにするべきでは？」みたいな話も確か出ていたと思いますw https://github.com/apple/swift-evolution/blob/main/proposals/0346-light-weight-same-type-syntax.md#constrained-protocols-in-opaque-result-types (edited)

なるほどw ORTにwhereつけられるの嬉しいですが、これである必要ないですもんね。糖衣の部分は必要かどうか怪しいけど、ORTは明確にほしい

koher

Nothing in this proposal precludes introducing generic protocols in the future under a different syntax

このプロポーザルの提案が将来的に異なる構文でジェネリックプロトコルを導入することを不可能にするわけではないくらいの感じ？で、例として↓のような構文が挙げられていると。

protocol Convertible(from: Self, to: Other) { static func convert(_: Self) -> Other } extension Convertible(from: String, to: Int) { static func convert(_: String) -> Int } extension Convertible(from: String, to: Double) { static func convert(_: String) -> Int }

あー、その構文がよくわからなかったんですが、プロトコル名の後ろに丸括弧でパラメータを与えているんですね

ORTにwhereつけられる

そういえばNamed opaque result typesってまだ途中なんですね。もう完了しているのかと思ってました。 https://github.com/apple/swift/pull/40715 (edited)

Named opaque result types by DougGregor · Pull Request #40715 · app...

Implement support for named opaque result types, e.g., func f() -> <T: Hashable & P, U where U: Q> [T: U] { ... } this mostly involves wiring up name lookup and type resolution so we c...

@rethrows public protocol AsyncIteratorProtocol { mutating func next() async throws -> Self.Element? } こんなrethrowsの書き方があるんですね…

@rethrows ってAttributeがあったのか、と思って調べてたら https://www.pointfree.co/blog/posts/73-parser-errors なんか最近入った？まだExperimentalなものらしいですね。

Parser Errors

A new release of swift-parsing that brings delightful and informative error messaging to parser failures.

1

関数側じゃなくてプロトコルに付いてるのは初めて見た気がしたんですけれど、まだ実験段階なのですねプロトコルがrethrowsするみたいでちょっと違和感…！

https://twitter.com/slava_pestov/status/1480618687677743109

https://forums.swift.org/t/pitch-rethrowing-protocol-conformances/42373

@dgregor79 @stephencelis You can enable the feature by adding a @rethrows attribute on the protocol, but it's not "officially supported"

1:36 AM

[Pitch] Rethrowing protocol conformances

Hey all, Here's a pitch for a feature that @Philippe_Hausler, @Joe_Groff, @Tony_Parker and I have been thinking about to make rethrows also work for protocol conformances. It's motivated by some of the concurrency work, but is separable and useful on its own. Philippe has been prototyping it in the compiler so we have a fairly good sense that t...

1:36 AM

https://github.com/DougGregor/swift-evolution/blob/rethrows-protocol-conformances/proposals/NNNN-rethrows-protocol-conformances.md

swift-evolution/NNNN-rethrows-protocol-conformances.md at rethrows-...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/NNNN-rethrows-protocol-conformances.md at rethrows-protocol-conformances · Do...

1:37 AM

このあたりが関連する議論のようですね。

https://www.swift.org/blog/website-open-source/

Swift.org Website is Now Open Source

The Swift.org site has long served as the hub where developers come together to work on the open source Swift compiler, libraries, and tools. Today, we are happy to announce that the Swift.org website itself is also an open source project, ready for community contributions. With this move, the website is also expanding its mandate to better supp...

12:14 PM

ウェブサイトも開かれることでいい感じで人材が集まるといいですね～という感じですけれど、8年経ってようやくというのがもにょい感じですね

Swift.org、Jekyll製なんですね。 https://github.com/apple/swift-org-website/ (edited)

https://forums.swift.org/t/pitch-regex-builder-dsl/56007

[Pitch] Regex builder DSL

Full proposal: swift-experimental-string-processing/RegexBuilderDSL.md at main · apple/swift-experimental-string-processing · GitHub Regex builder DSL Status: Pitch Implementation: apple/swift-experimental-string-processing Table of Contents Introduction Motivation Proposed solution Detailed design RegexComponent protocol Concatenati...

2:45 AM

正規表現をResultBuilder上で構成して、

2:45 AM

その式中に含まれるCapture Listの数を、

2:45 AM

静的に型パラメータとして構成するライブラリの提案があって

2:46 AM

これ前に話題に出た時、実装しようと思うと、CaptureListの合成する部分がめっちゃ大変な事になるんじゃないかなとなんとなく思ったんだけど

2:46 AM

https://forums.swift.org/t/pitch-buildpartialblock-for-result-builders/55561

[Pitch] buildPartialBlock for result builders

Hi all, While working on the RegexBuilder-based DSL with strongly-typed regex captures, we’ve come across an issue with where concatenating the component types in a result builder block as a tuple would involve a factorial explosion of buildBlock overloads and unreasonably long compilation time, and it isn't something that could be trivially re...

2:47 AM

まず、ResultBuilderに対して、他引数のbuildBlockの代わりに、

2:47 AM

2引数のbuildPartialBlockの複数の呼び出しに変換するAPIを用意した上で

2:48 AM

結合する２つの正規表現式の、左側と右側のキャプチャ要素数の組み合わせに対して

2:49 AM

二乗の組み合わせ全部をオーバーロードする力技を提案しててビックリした

2:49 AM

extension RegexComponentBuilder { public static func buildPartialBlock<W0, W1, C0, R0: RegexComponent, R1: RegexComponent>( accumulated: R0, next: R1 ) -> Regex<(Substring, C0)> where R0.Output == W0, R1.Output == (W1, C0) { .init(node: accumulated.regex.root.appending(next.regex.root)) } }

2:49 AM

↑これは左側がキャプチャ0個、右側がキャプチャ1個

2:50 AM

 public static func buildPartialBlock<W0, W1, C0, C1, R0: RegexComponent, R1: RegexComponent>( accumulated: R0, next: R1 ) -> Regex<(Substring, C0, C1)> where R0.Output == W0, R1.Output == (W1, C0, C1) { .init(node: accumulated.regex.root.appending(next.regex.root)) } public static func buildPartialBlock<W0, W1, C0, C1, C2, R0: RegexComponent, R1: RegexComponent>( accumulated: R0, next: R1 ) -> Regex<(Substring, C0, C1, C2)> where R0.Output == W0, R1.Output == (W1, C0, C1, C2) { .init(node: accumulated.regex.root.appending(next.regex.root)) } ...

いまのResultBuilderも

 public static func buildPartialBlock<W0, W1, C0, C1, C2, C3, C4, C5, C6, C7, C8, C9, R0: RegexComponent, R1: RegexComponent>( accumulated: R0, next: R1 ) -> Regex<(Substring, C0, C1, C2, C3, C4, C5, C6, C7, C8, C9)> where R0.Output == W0, R1.Output == (W1, C0, C1, C2, C3, C4, C5, C6, C7, C8, C9) { .init(node: accumulated.regex.root.appending(next.regex.root)) }

↑ここまでは左側０個 (edited)

2:50 AM

 public static func buildPartialBlock<W0, W1, C0, C1, R0: RegexComponent, R1: RegexComponent>( accumulated: R0, next: R1 ) -> Regex<(Substring, C0, C1)> where R0.Output == (W0, C0), R1.Output == (W1, C1) { .init(node: accumulated.regex.root.appending(next.regex.root)) }

↑ここからは左側１個

2:50 AM

https://github.com/apple/swift-experimental-string-processing/blob/main/Sources/_StringProcessing/RegexDSL/Variadics.swift

swift-experimental-string-processing/Variadics.swift at main · appl...

An early experimental general-purpose pattern matching engine for Swift. - swift-experimental-string-processing/Variadics.swift at main · apple/swift-experimental-string-processing

2引数buildBlockを作っておいてかつ

「パラメータ数の合計が１０個」をアッパーにとってるから、100(10x10)通りよりは少ないけど。

雪だるまジェネリクスを解釈できるようにするとオーバーロード力業解決のアプローチが出来るよ

２引数しか定義してない状態で３行書いたらどうなるの？

M<M<A,B>,C> か M<A,M<B,C>> になる

あ、頑張って２引数の繰り返しに畳んでくれる仕様はあるのか。

この時にbuildBlockの第一引数、第二引数に制約を課すことで

2:53 AM

オーバーロードに指向性を持たせたり出来るよ

ただまあ雪だるま型だと、最終的なAPIでアクセスするときに、その構造を歩かないといけないから

2:53 AM

正規表現のキャプチャリストとしては使いにくいね

雪だるまを解くのは、実は賢い方法があって

2:55 AM

protocol Node と protocol KindA があるときに

2:55 AM

末端にKindAがあればNodeにKindAの機能を持たせる、みたいなのは一応書ける

2:56 AM

extension Node: KindA where Element: KindA と書けば、多重にネストしてても連鎖してNodeがKindAの機能を持てるので

2:56 AM

ただし、Nodeが2要素持つとこれは使えなくなる

2:57 AM

buildPartialBlockはその辺りを綺麗にしたい感じのAPIなのかな

リスト的なものだと2要素以上もつんじゃない？

2:57 AM

Regex { regex0 // Regex<Substring> regex1 // Regex<(Substring, Int)> if condition { regex2 // Regex<(Substring, Float)> } else { regex3 // Regex<(Substring, Float)> } } // Regex<(Substring, Int, Float)>

そうだね、なので連鎖して解けるためには指向性を持たせた雪だるまにしないといけない

Regex { let e0 = RegexComponentBuilder.buildExpression(regex0) // Component<Regex<Substring>> let e1 = RegexComponentBuilder.buildExpression(regex1) // Component<Regex<(Substring, Int)>> let e2: Regex<(Substring, Float)> if condition { let comp = RegexComponentBuilder.buildExpression(regex2) // Component<Regex<(Substring, Float)>> e2 = RegexComponentBuilder.buildEither(first: comp) // Regex<(Substring, Float)> } else { let comp = RegexComponentBuilder.buildExpression(regex3) // Component<Regex<(Substring, Float)>> e2 = RegexComponentBuilder.buildEither(first: comp) // Regex<(Substring, Float)> } let r0 = RegexComponentBuilder.buildPartialBlock(first: e0) let r1 = RegexComponentBuilder.buildPartialBlock(accumulated: r0, next: e1) let r2 = RegexComponentBuilder.buildPartialBlock(accumulated: r1, next: e2) return r2 } // Regex<(Substring, Int, Float)>

2:58 AM

partialBlockは reduceの s += x みたいな形にする

2:58 AM

だから２つの場合の合成を書ければ、N段の合成が書けるようになる

2:59 AM

ただ2つの場合において、左と右のタプル要素数の組み合わせに対応するために、たくさんオーバーロード書かないといけないという話

ふむー

2:59 AM

雪だるまを上手に書けばかなりサボれるんじゃん？と思ったけど

2:59 AM

そうもいかないのかな

そもそも最終的に出てくるものを Regex<(Substring, Int, Float)> にしたいよね (edited)

いまのbuildBlockだと3要素以上並んだときに雪だるま作れなくないですか？

3:01 AM

組み合わせの要素数乗のオーバーロードを用意するのは別として

3:02 AM

https://discord.com/channels/291054398077927425/291054454793306112/956385064709660695

3:02 AM

あ、そういう仕様がある？

あれ、出来なかったか？

3:03 AM

自信なくなってきたw

ｗ

俺の記憶だとできなくて

3:07 AM

SwiftUIは11個のViewを直列に並べられないよね

3:07 AM

10個までしかオーバーロードが無いから

確かに、これが可能なら11個の時にネストして組み立てれるはずですね

3:13 AM

じゃあ別の話と勘違いしているわ

じゃあなるほど、buildPrtialBlockというのが、任意の行をreduceに食わせて、必要によっては雪だるまを作れるようにするためのものなのか

そうだね。buildPartialBlockの実装次第では一段ごとにジェネリクスを深くしていくこともできる。

7:28 AM

で、段数の制限はない。

buildEitherでswitch文を作る仕組みは元々そうだったし、良い感じがしますね

7:34 AM

こうなってくるとやはり、可変長ジェネリクスが欲しくなってくるなぁ

7:34 AM

雪だるまはworkaroundの感が否めない

AsyncSequence使った新しいpackageが出ましたね

https://github.com/apple/swift-async-algorithms

GitHub - apple/swift-async-algorithms: Async Algorithms for Swift

Async Algorithms for Swift. Contribute to apple/swift-async-algorithms development by creating an account on GitHub.

1

operator使えるようになるのですね～ CombineよりAsyncSequenceみたいになるんでしょうか…

どうなるんですかねー。Dougさんは「いずれは…」的なことを前言ってましたね。 https://www.swiftbysundell.com/podcast/99/

AsyncSequence ベースの @Published や ObservableObject はこれの外側で扱うことになるんでしょうか？

> AsyncSequence ベースの @Published や ObservableObject はこれの外側で扱うことになるんでしょうか？

すいませんコメントに気がついてませんでした

この辺りで言及されてますね

There are obviously a few key areas that this package does not touch on (e.g. @Published or ObservableObject since those interact more so with SwiftUI than anything else)

https://forums.swift.org/t/introducing-swift-async-algorithms/56231/3

That boundary is not really part of this project and more so something the folks working on SwiftUI are more equipped to tackle.

https://forums.swift.org/t/introducing-swift-async-algorithms/56231/8 (edited)

12:22 AM

全然上と関係ない話ですが、 MainActor周りはどのバージョンで何が修正されているのかを把握するのが難しいですねw MainActorクラス内の関数がMain Threadで実行されない(Swift5.6で修正) MainActor isolation is not ensured https://bugs.swift.org/browse/SR-15789 MainActorクラスのMainActorではないinitがMainActorで守られていない(Swift5.7で修正) MainActor doesn't cascade to init in class https://bugs.swift.org/browse/SR-15694 https://forums.swift.org/t/mainactor-doesnt-work-or-misunderstood/56222 (edited)

shiz

> AsyncSequence ベースの @Published や ObservableObject はこれの外側で扱うことになるんでしょうか？

すいませんコメントに気がついてませんでした

この辺りで言及されてますね

There are obviously a few key areas that this package does not touch on (e.g. @Published or ObservableObject since those interact more so with SwiftUI than anything else)

https://forums.swift.org/t/introducing-swift-async-algorithms/56231/3

That boundary is not really part of this project and more so something the folks working on SwiftUI are more equipped to tackle.

https://forums.swift.org/t/introducing-swift-async-algorithms/56231/8 (edited)

ありがとうございます！

1

https://github.com/apple/swift-evolution/blob/main/proposals/0348-buildpartialblock.md

swift-evolution/0348-buildpartialblock.md at main · apple/swift-evo...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0348-buildpartialblock.md at main · apple/swift-evolution

6:14 AM

buildPartialBlock採択

swiftuiの行制限がなくなるね

6:18 AM

既存のbuildBlockはあんまり使わなくなりそうだ

これでViewを11個以上並べられるぞ！って思ったけどViewBuilderにbuildPartialBlockの実装が必要だからiOS13には出せないか (edited)

iOS13かつ11個並べたときだけエラー出るみたいな世界観になりそう

buildBlockとbuildPartialBlockは両立するのかな？

6:21 AM

あ、でも@unavalilable が今あるか

buildBlockの方を優先する作りにしてれば問題は起きなさそう

SwiftUIは TupleView<(A, B, C)> と TupleView<(A, B, C, D)> みたいにタプルが伸びていくようになってて再帰的定義ではないから

6:24 AM

結局 buuildPartialBlock を使って、 3個から4個、 4個から5個、... ってオーバーロードしておいた数までしか作れないんじゃないかな。

TupleView2<A,B>が作られてそれがメインに使われると予想しています

タプルを伸ばすんじゃなくて再帰的な型ツリーにする方針になるなら制限がなくなるね。

既存のTupleView、作りも無理があるので2要素にした方がグラフ解析の面でもメリットありそう

https://forums.swift.org/t/se-0351-regex-builder-dsl/56531

SE-0351: Regex Builder DSL

Hello, Swift community. The review of SE-0351: Regex Builder DSL begins now and runs through April 15, 2022. This review is part of a collection of proposals for better string processing in Swift. The proposal authors have put together a proposal overview with links to in-progress pitches and reviews. This proposal builds on the Regex type be...

12:47 PM

型安全正規表現の審査が来た

12:47 PM

展開が早い

12:48 PM

さっきのbuildPartialBlockを踏まえたやつ

https://forums.swift.org/t/se-0352-implicitly-opened-existentials/56557

SE-0352: Implicitly Opened Existentials

Hi everyone. The review of SE-0352: Implicitly Opened Existentials begins now and runs through April 18th, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or by direct m...

3:45 PM

暗黙existential openの審査来た

https://github.com/swift-issues-migration お

Swift Bugs Migration

This organization is used for migrating issue from bugs.swift.org to GitHub Issues. - Swift Bugs Migration

3:43 AM

日曜日の夜に...

1

invitation来てた

3:47 AM

なんでinvitation必要なんだ？

1

偽物の可能性

invitationするって説明合ったよ

うかつにポチッと押してしまった

Actions required Update Github and JIRA (bugs.swift.org 448) username mapping on forums.swift.org by April 7th 2022 Go to profile preferences - Swift Forums Update JIRA Username and GitHub Username Accept the invitation to “swift-issues-migration” organization on GitHub by April 18th 2022 The invitation will be sent by April 7th 2022

Accept the invitation to “swift-issues-migration” organization on GitHub by April 18th 2022 The invitation will be sent by April 7th 2022

3:50 AM

https://forums.swift.org/t/swift-bugs-are-moving-to-github-issues-and-we-need-your-help/56125

Swift bugs are moving to GitHub Issues and we need your help!

Swift bugs are moving to GitHub Issues and we need your help! Swift's open source project issues are currently in JIRA, making it difficult for developers to discover and integrate them into our workflows on GitHub, such as pull requests. To provide a better workflow for developers, we are working on migrating JIRA to GitHub Issues. The issues ...

3:51 AM

まだ本物とはわからないけれど多分本物かなあ

これが来てるってことはforum profile欄のGitHubユーザ名の設定は成功してる

同じことを第三者がやろうとしてもできる

まあ既に入ってるメンバーの人々から見て本物でしょう

org名の swift-issues-migration があってるから本物でしょう

入らないと見えないんだよなあ > 誰がいるか (edited)

ｗ

3:52 AM

名前は誰でも自由にとれる気がする? (edited)

↑入ったらURL欄で見れた

3:52 AM

URLだから重複できないでしょ

3:52 AM

表示名の Swift Bugs Migration のほうはなりすませそう。

swift-bugs-migrationっていうのを第三者が作ることはできるかなっていう話。

forumのアナウンスより前にorgが作られてたかを検証すればよさそう

それなー

3:53 AM

わかんないんだよなあ

えー

created_atみたいなのある? apiとかならあるのかな

https://api.github.com/orgs/swift-issues-migration

3:54 AM

"created_at": "2022-03-18T17:18:01Z"

おー、あった。

おお

forumのポスト= Mar 21, 4:44 PM (edited)

3:55 AM

大丈夫そうだ

すでに test という名前のリポジトリに (多分お試しで) issues がマイグレーションされてますね．Author がマネキンなものとそうでないものの違いが気になります...

https://forums.swift.org/t/accepted-se-0346-lightweight-same-type-requirements-for-primary-associated-types/56747

[Accepted] SE-0346: Lightweight same-type requirements for primary ...

Hello, Swift community. The second review of SE-0346 ended on April 12th. This round of review was narrowly focused on the changes to the proposal made after the first review, which are summarized at the start of the review thread. Feedback on the revised proposal was overall positive. Some community members maintained their misgivings about...

2

11:22 AM

Collection<Int> 採択

associatedtypeを定義に明記する(補足: <>の中には書かない)に変わってからはみんな賛成って流れでしたね。 (edited)

1

第二審査でそこが変わってたのか。なるほどー

↑のany版もreviewになってましたね。 https://forums.swift.org/t/se-0353-constrained-existential-types/56853

SE-0353: Constrained Existential Types

Hi everyone. The review of SE-0353: Constrained Existential Types begins now and runs through May 3, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or by direct messa...

似たようなのたくさんあってややこしい

1

このへんいろいろ進んだから　まとめて発表しようかなと思ってる

ちゃんと読み込めてないところもあるけど明日 #swift-zoomin で話す予定。

お

Proposalの紹介よりも、それらを交えつつSwiftらしいプロトコルの使い方というテーマで実演しながら話す感じだけど。

とりあえず明日聞いてみて判断しよう。

Proposalの内容中心のは、今レビュー中のもかたまってから、iOSDCとかで話すと良さそうだなと考えてた。

ところで、

7:19 AM

このあたりのAPIが充実してくると

7:19 AM

Java的な、 List<Int> でなるべく取り回すっていう流派が生じそうだけど

7:19 AM

そのへんどうおもってます？

それはできるようになるけど、あくまでこれまで通りの使い方がメインかなぁと思ってます。 any が導入された主旨にも沿うかと。

↓誤植 Desckset (edited)

1

7:21 AM

あ、治ってた、これは過去の開催の説明文だ

人間が読み書きするときは抽象度が高く、取り回しの良い型で、機械が取り扱うときはstrictな型になる、そんな感じの世界観になっていくんじゃないかと思う

7:22 AM

ORTとか正にそんな感じだし (edited)

tarunon

人間が読み書きするときは抽象度が高く、取り回しの良い型で、機械が取り扱うときはstrictな型になる、そんな感じの世界観になっていくんじゃないかと思う

じゃあ、これまで [Int] を受け取っていたような状況では any Sequence<Int> を受け取るように変わるということ？

少なくともArrayである必要が無い場面は、そうなるんじゃないか

some Sequence<Int> じゃないかなぁ。

someだね

7:23 AM

そう

struct User { var points: [Int] } こういう状況のとき。someは使えない。

ただなんか、anyとsomeの境界は、はやい段階で超えるんじゃないかという気はする

7:24 AM

これはArrayの必要がある場面と思います

omochimetaru

struct User { var points: [Int] } こういう状況のとき。someは使えない。

こういうケースで内部で抽象的な型で取り回したいケースは限定的じゃないかな。

そもそもフィールドに置いておく、みたいなのは関数メインのプログラムから見た場合、頻出するシチュエーションではない気がしていて

[any Foo] は結構増えそう。

関数引数部分の some Sequence は特殊化が期待できるので [Int] じゃなくて some Sequence<Int> になってもペナルティは無いですね。ちょっとコードの文字数増えるぐらいか。

[any Foo] 自体はこれまでもできたけど、 associatedtype があると existential にできなかったようなケースができるようになった（なる）ので。 (edited)

structよりも関数に寄せたコードの方が有利な場面が多くなってくる、はありそうだ

koher

[any Foo] 自体はこれまでもできたけど、 associatedtype があると existential にできなかったようなケースができるようになった（なる）ので。 (edited)

type erasureを手書きしていたケースが any P でタダで使えるのは便利ですね。

omochimetaru

type erasureを手書きしていたケースが any P でタダで使えるのは便利ですね。

しかも type erasure よりオーバーヘッドも小さかったりしないかな？

実装を見てみないとわからないですが、手書きだと二段階ディスパッチになってる部分が、コンパイラサポートなら効率的な実装を生成できそうな気がしますね。

Rustの世界観に近づきそう

最近の opaque & existential type 関連の Proposal を洗い出してみた。

anyキーワード(0335)だけは5.6でもう来てるんですね。 (edited)

ですねー。5.7になれば色々入りそうですね。

5.6でany付けられる場所洗い出す方法とかないんでしたっけ？

11:26 AM

anyなしに警告が出るのはswift6になったときだったっけ。

今のところなさそうですねー(これが最新情報なら) There isn't currently a way to turn on warnings for missing anys in your code. That's intentional; we're working on a lot of generics ergonomics features right now that may change the way programmers update their current use of existential types. https://forums.swift.org/t/finding-existentials-for-any/55956/3 (edited)

Finding existentials for any

There isn't currently a way to turn on warnings for missing anys in your code. That's intentional; we're working on a lot of generics ergonomics features right now that may change the way programmers update their current use of existential types. A lot of Swift code today uses existential types where it doesn't need to because existential types...

1

Swift 6モードでコンパイルすればエラーになるみたいなの見た気がするけど、どうやって切り替えるんですっけ？できないのかな？Swift 5か4.2か切り替えるオプションとかありましたよね？

コンパイラに対して言語バージョンを指定するオプションがあります

2:03 PM

互換性のない仕様変更があったときは、古いコードはその機能を使ってコンパイルする。

ちょっと違いますが、-enable-explicit-existential-typesというフラグがあった頃は、これ使って確認できてたんですよね。 (edited)

ほおー

omochimetaru

互換性のない仕様変更があったときは、古いコードはその機能を使ってコンパイルする。

で、新しいコンパイラで古いバージョンを指定してる場合は、古い書き方に対してコンパイルはできるけど警告が出るので、それを使ってマイグレーションするのが基本。

omochimetaru

コンパイラに対して言語バージョンを指定するオプションがあります

-swift-version <バージョン番号> というものがそれですか？(私も Swift 6 モードが何者なのか気になってました)

kebo

-swift-version <バージョン番号> というものがそれですか？(私も Swift 6 モードが何者なのか気になってました)

それだったと思います。

1

2:59 PM

https://github.com/apple/swift-evolution/blob/main/proposals/0212-compiler-version-directive.md

swift-evolution/0212-compiler-version-directive.md at main · apple/...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0212-compiler-version-directive.md at main · apple/swift-evolution

2:59 PM

#if compiler ではコンパイラのバージョンがチェックできて

2:59 PM

#if swift ではswiftのバージョンがチェックできます

それですね！思い出せなかった。しかし、今のコンパイラでは使えなさそう。

Swift --swift-version 3 --swift-version 4 --swift-version 4.2 --swift-version 5 3.0 N/A N/A N/A N/A 3.1 N/A N/A N/A N/A 4.0 3.2 4.0 N/A N/A 4.1 3.3 4.1 N/A N/A 4.2 3.4 4.1.50 4.2 N/A 5.0 3.5 4.1.51 4.3 5.0 5.1 3.6 4.1.52 4.4 5.1

3:30 PM

上のリンク先見る限り使えそうなんだけどなあ

$ cat non-any.swift protocol Animal {} struct Cat: Animal {} let animal: Animal = Cat() print(animal) $ $ swift -swift-version 5 non-any.swift Cat() $ $ swift -swift-version 6 non-any.swift <unknown>:0: error: invalid value '6' in '-swift-version 6' <unknown>:0: note: valid arguments to '-swift-version' are '4', '4.2', '5'

3:36 PM

この "Swift 6 language mode" はまだ存在しない架空のモードなのか。

this syntax should be required for existential types under the Swift 6 language mode

https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md

koher

この "Swift 6 language mode" はまだ存在しない架空のモードなのか。

this syntax should be required for existential types under the Swift 6 language mode

https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md

https://swiftfiddle.com/zxvu5klsmnd3lljuw5g2cumamu で compiler options に -swift-version 6 を指定したら動きました．nightly だと行けるようです．

swift-evolution/0335-existential-any.md at main · apple/swift-evolu...

SwiftFiddle is an online playground for creating, sharing and embedding Swift fiddles (little Swift programs that run directly in your browser).

1

kebo

https://swiftfiddle.com/zxvu5klsmnd3lljuw5g2cumamu で compiler options に -swift-version 6 を指定したら動きました．nightly だと行けるようです．

おおお！ありがとうございます。

3:53 PM

@swift-main -swift-version 6 protocol Animal {} struct Cat: Animal {} let animal: Animal = Cat() print(animal)

koher

@swift-main -swift-version 6 protocol Animal {} struct Cat: Animal {} let animal: Animal = Cat() print(animal)

Cat()

あれ？まだ any 必須のチェックは入ってないのかな？

↓のPRにこう書いてあるのでwarningは出そうですけどね(まだ限定的なんですかね？) This diagnostic for requiring any on existential types with Self or associated type requirements has already been staged in as a warning. あと、今後は必須になりそうですね。(3時間前くらいにmainには入っているようです) https://github.com/apple/swift/pull/42558 https://github.com/apple/swift/pull/42590 (edited)

Swift5.7だとこのケース(any on existential types with associated type requirements)はwarningが出てきました

https://github.com/apple/swift/blob/main/test/type/explicit_existential.swift (edited)

1

ほんとだ、 associatedtype がある場合だけ any がないと warning 出ますね。でも、 associatedtype の有無と any って無関係ですよね？奇妙な挙動・・・。

Swift5.7からSE-0309 Unlock existentials for all protocolsが入ることでPAT問題が解消される結果、existentialが使われる機会が多くなりそうだけど、anyなしで使うとSwift6でanyつけろというエラーが大量に発生しそうだから先に警告(エラー)にしよう、ってことですかね？ https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md#source-compatibility (edited)

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0335-existential-any.md at main · apple/swift-evolution

SE-0309 Unlock existentials for all protocols enables more code to be written using existential types. To minimize the amount of new code written that will become invalid in Swift 6, I propose requiring any immediately for protocols with Self and associated type requirements.

(edited)

1:08 PM

この文はそういう話に見えますね

1

1:08 PM

１文前の「enables more code ...」がズバリだ。 (edited)

https://forums.swift.org/t/se-0354-regex-literals/57037

SE-0354: Regex Literals

Hello, Swift community. The review of SE-0350: Regex Literals begins now and runs through May 10, 2022. This review is part of a collection of proposals for better string processing in Swift. The proposal authors have put together a proposal overview with links to in-progress pitches and reviews. This proposal introduces a literal syntax for t...

4:47 PM

正規表現リテラルの提案

4:47 PM

名前付きキャプチャだとキャプチャ結果の型のタプルにラベルが付くとか

4:47 PM

シャープをつけると文字列みたいにエスケープ不要モードになるとか

4:48 PM

複数行スタイルとか

4:48 PM

便利な機能がついてて良さそう

4:49 PM

既存のスラッシュ演算子との絡みで文法解釈が変わっちゃうケースがあるのは厳しいね、ほぼ踏むことは無さそうだけど

https://github.com/apple/swift-evolution/blob/main/proposals/0355-regex-syntax-run-time-construction.md

swift-evolution/0355-regex-syntax-run-time-construction.md at main ...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0355-regex-syntax-run-time-construction.md at main · apple/swift-evolution

6:56 PM

文法自体は別提案になってる、きちんと書き下されていてえらい

https://forums.swift.org/t/se-0357-regex-string-processing-algorithms/57225

SE-0357: Regex String Processing Algorithms

Hello, Swift Community. The review of SE-0357: Regex String Processing Algorithms begins now and runs through May 23, 2022. This review is part of a collection of proposals for better string processing in Swift. The proposal authors have put together a proposal overview with links to in-progress pitches and reviews. This proposal builds on th...

8:09 AM

正規表現と文字列のAPIの提案 switch caseとも組み合わせられるのがオシャレだな

2

https://forums.swift.org/t/se-0359-build-time-constant-values/57562

SE-0359: Build-Time Constant Values

Hello Swift community, The review of SE-0359 "Build-Time Constant Values" begins now and runs through June 6, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review...

1

5:27 AM

コンパイルタイム定数 @const の提案

5:28 AM

以前Swift 4 TFのときにconstexprとして進んでた話なんだけど、いろいろ巻き戻ってプロポーザルが書き直されてる。著者の一人のXi Geさんは前回のときも関わってた気がする。

朝出てましたが、Opaque Result Type、if #availableで型分岐できるようになるみたいですね

A function returning an opaque result type is allowed to return values of different concrete types from conditionally available if #available branches without any other dynamic conditions, if and only if, all universally available return statements in its body return a value of the same concrete type T.

struct Square { func asRectangle() -> some Shape { if #available(macOS 100, *) { return Rectangle(...) // ⭕️ } return self } }

https://forums.swift.org/t/se-0360-opaque-result-types-with-limited-availability/57729 (edited)

SE-0360: Opaque result types with limited availability

Hi everyone. The review of SE-0360, Opaque result types with limited availability, begins now and runs through June 14, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager by email or DM. ...

これって分岐の分だけ複数のバイナリが吐き出されることになるんでしょうか？ func foo(square: Square) -> some Shape { let rectangle = square.rectangle ... return rectangle } とかだと、 foo まで複数生成される？？ (edited)

PR見ると戻り値の型の部分だけ分かれているように見えますが、どうなんでしょう？？

If particular opaque type descriptor has multiple conditionally available underlying types, emit a special type and witness reference accessors that would be called at runtime to determine actual underlying type.

https://github.com/apple/swift/pull/42104

[IRGen] Augment opaque type descriptor to support limited availabil...

If particular opaque type descriptor has multiple conditionally available underlying types, emit a special type and witness reference accessors that would be called at runtime to determine actual u...

実行時のオーバーヘッドがあるのか気になりますね。 opaque type はオーバーヘッドが生じないところに価値があると思うので。

1:21 AM

中身まったくわかってないですが、普通の if ではできず Proposal で "without any other dynamic conditions" でないといけないと言っているからには、 "emit a special type and witness reference accessors that would be called at runtime to determine actual underlying type" と言っても実行時に当該箇所で毎回解決されるわけではなく、最初にロードされるときに環境に合わせて型が解決されるとかなんでしょうか。 (edited)

先日の #waiwai-swiftc の内容を踏まえると、ORTで使われる真の型はランタイム関数から取得されてその際に実行単位でキャッシュされるので、foo がたくさん生えるわけではなく foo の返り値の型を取得する関数の内部で分岐が起こるだけ（結果はキャッシュされるので1回だけ）、という感じなのではないでしょうか

2:57 AM

同一モジュール内でSpecializeされるときにどうなるかは気になりますね

3:00 AM

今まで同一モジュール内ならORTの真の型が常に見えてたと思うけど、これが入ると同じ関数から複数種類の型が返ってくる不思議関数になりうるので特殊化が難しそう

if #がコンパイル時に解決されれば或いは

Iceman

今まで同一モジュール内ならORTの真の型が常に見えてたと思うけど、これが入ると同じ関数から複数種類の型が返ってくる不思議関数になりうるので特殊化が難しそう

特殊化されずにモジュール跨ぎの時と同じコードが吐かれてました

1

tarunon

if #がコンパイル時に解決されれば或いは

そのとおりで、minimum-deployment-targetを元に #available が消せる場合は特殊化されてました

かしこい

この特殊化はどの段階で入るんだろうなぁ。SILOptimizerが走らない-emit-silgen でも特殊化されてるように見えるし、SILGenの段階でやってる？

同一モジュール同士なら固定される気もしたけど、そのコンパイル済みのコードが様々な実行環境にデプロイされる可能性があるから動的になるのか。

5:22 AM

で、deployment target次第では、デプロイしうる実行環境のバリエーションが無いことが保証できて固定するのね。

こっちのPRが何か関係してますか？？ここら辺のコメントから何かしてそうだなあと思いまして

// Universally available type doesn't have any availability conditions // so it could be serialized into "unique" slot to safe space. // Check whether there are any conditionally available substitutions. // If there are, it means that "unique" we just read is a universally // available substitution.

https://github.com/apple/swift/pull/42167 (edited)

[Serialization] Opaque types: serialize conditionally available und...

…lying types Resolves: rdar://90595158

import Foundation @propertyWrapper struct WrapperValue<Value> { var value: Value init(wrappedValue: Value) { self.value = wrappedValue } var projectedValue: Self { return self } var wrappedValue: Value { get { self.value } set { self.value = newValue } } func printValue() { print(value) } } class Test { static func test() { (0..<100).map { _ in @WrapperValue var value: Bool = false if value { $value.printValue() // .. compile error on 5.7 } } } }

Swift 5.6.1 だと大丈夫だけど Swift 5.7(nightly) だととおらない (edited)

@swift-main

import Foundation @propertyWrapper struct WrapperValue<Value> { var value: Value init(wrappedValue: Value) { self.value = wrappedValue } var projectedValue: Self { return self } var wrappedValue: Value { get { self.value } set { self.value = newValue } } func printValue() { print(value) } } class Test { static func test() { (0..<100).map { _ in @WrapperValue var value: Bool = false if value { $value.printValue() // .. compile error on 5.7 } } } }

Iceman

@swift-main

import Foundation @propertyWrapper struct WrapperValue<Value> { var value: Value init(wrappedValue: Value) { self.value = wrappedValue } var projectedValue: Self { return self } var wrappedValue: Value { get { self.value } set { self.value = newValue } } func printValue() { print(value) } } class Test { static func test() { (0..<100).map { _ in @WrapperValue var value: Bool = false if value { $value.printValue() // .. compile error on 5.7 } } } }

exit status: 1 with stderr:

<stdin>:35:9: error: cannot reference invalid declaration '$value' $value.printValue() // .. compile error on 5.7 ^ <stdin>:32:25: note: '$value' declared here @WrapperValue var value: Bool = false ^

なんじゃこりゃ

あと property wrapper を body で宣言すると一部のコードが型チェックでクラッシュしますね (edited)

8:24 AM

最低の再現コード今頑張って書いてます

8:25 AM

一瞬 if let hoge の新機能導入してぶっ壊れたのかと思いました

必ずじゃないんだ。

再現できたこれはコンパイラがクラッシュします (edited)

8:31 AM

nightlyでも死ぬ

8:31 AM

@swift-main

import Foundation @propertyWrapper struct WrapperValue<Value> { var value: Value init(wrappedValue: Value) { self.value = wrappedValue } var projectedValue: Self { return self } var wrappedValue: Value { get { self.value } set { self.value = newValue } } func printValue() { print(value) } } class Test { static func test() { return [0, 1, 2].compactMap { _ in @WrapperValue var value: Bool? = false if value != nil { return false } return value ?? false } } }

freddi

@swift-main

import Foundation @propertyWrapper struct WrapperValue<Value> { var value: Value init(wrappedValue: Value) { self.value = wrappedValue } var projectedValue: Self { return self } var wrappedValue: Value { get { self.value } set { self.value = newValue } } func printValue() { print(value) } } class Test { static func test() { return [0, 1, 2].compactMap { _ in @WrapperValue var value: Bool? = false if value != nil { return false } return value ?? false } } }

exit status: 134 with stderr:

Already type-checked UNREACHABLE executed at /home/build-user/swift/lib/Sema/CSGen.cpp:2956! Stack dump: 0. Program arguments: /usr/bin/swift-frontend -frontend -interpret - -disable-objc-interop -new-driver-path /usr/bin/swift-driver -empty-abi-descriptor -resource-dir /usr/lib/swift -module-name main 1. Swift version 5.8-dev (LLVM 278d67f38c6a910, Swift ee312bc1e20eb01) 2. Compiling with the current language version 3. While evaluating request TypeCheckSourceFileRequest(source_file "<stdin>") 4. While evaluating request TypeCheckFunctionBodyRequest(main.(file).Test.test()@<stdin>:30:15) 5. While type-checking statement at [<stdin>:30:22 - line:39:3] RangeText="{ return [0, 1, 2].compactMap { _ in @WrapperValue var value: Bool? = false if value != nil { return false } return value ?? false } " 6. While type-checking statement at [<stdin>:31:5 - line:38:5] RangeText="return [0, 1, 2].compactMap { _ in @WrapperValue var value: Bool? = false if value != nil { return false } return value ?? false " 7. While type-checking expression at [<stdin>:31:12 - line:38:5] RangeText="[0, 1, 2].compactMap { _ in @WrapperValue var value: Bool? = false if value != nil { return false } return value ?? false " Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): /usr/bin/swift-frontend[0x60fd223] /usr/bin/swift-frontend[0x60faf6e] /usr/bin/swift-frontend[0x60fd5af] /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f00bdc7c420] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f00bd0cb00b] /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f00bd0aa859] /usr/bin/swift-frontend[0x6038061] /usr/bin/swift-frontend[0x1354b99] /usr/bin/swift-frontend[0x134551e] /usr/bin/swift-frontend[0x1ac48d3] /usr/bin/swift-frontend[0x1ac4c17] /usr/bin/swift-frontend[

あれ、 $value のドル記号は関係なかっったのか。

前者はドル記号の別の問題かなあっておもいます (edited)

Feedback 送りました

2

https://github.com/apple/swift/issues/59294 bug ticket がいつのまにかissueになってたのでそっちにも記念にやってみた

Property Wrapper make compiler crash in function body (Xcode 14 and...

Describe the bug Property Wrapper make compiler crash in function body. It can be reproduced with below code. import Foundation @propertyWrapper struct WrapperValue<Value> { var value...

3:24 PM

（ただfixされないとつらいのと割とFBは反応が薄いと聞いてるので、リマインダもかねて

jiraじゃなくてissueになったのか

-Xfrontend -disable-availability-checking こんなオプションあったんですね。

これは導入されたらうれしいかもしれない。↓が全部いける extension Array where Element == String { ... } extension Array<String> { ... } extension [String] { ... } https://github.com/apple/swift-evolution/blob/main/proposals/0361-bound-generic-extensions.md

swift-evolution/0361-bound-generic-extensions.md at main · apple/sw...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0361-bound-generic-extensions.md at main · apple/swift-evolution

わかりやすくなりますね

これは良い。

Array<Animal>でArray<Cat>とArray<Dog>の拡張も考えられるし、ExistentialならArray<any Animal>と整理もできる

2:34 AM

今のタイミングだからこそ良いですね

where の使い所がなくなりそうな勢いだ

JavaとかScalaにあるようなアンスコプレースホルダーがあれば

Type argument listはconcrete typeである必要があるので、こういうのは無理って書いてある。 extension Pair<Int, _> {} // error: Cannot extend a type that contains placeholders よってwhereはこういう場面で使われることにはなりそう。

殆ど要らなくなるんじゃないか

コメントが前後した感w

そう、これが出来るようになるとは書いてなくて

2:49 AM

まあじゃあ…ってとこではある。あっていいじゃん？とは思うのだけど

こういうときにとりあえず使えるAny的な何かがほしい

AnyはBottomTypeなのでまた話が違うんですよね…ん？

Anyはtop typeね

any Anyとはならなかったんだっけ

2:51 AM

Topや、すまん

any Any は Any 表記になった(というか旧仕様維持された)けど意味は any Any (edited)

じゃあ任意のgenericsを意味するAnyは使えないのか

2:52 AM

any AnyとAnyが分けられていれば

2:52 AM

Pair<Int, Any>でよかった

2:52 AM

分けられてないのでダメだね

some Any かな・・・

2:53 AM

extension <Wrapped> Array<Optional<Wrapped>> { ... }

2:53 AM

↑これのsome化で

extension Pair<Int, some Any> が書けるのだろうか？

extension [some Equatable] { ... }

2:53 AM

と書く形が Future Directions に書いてあるよ

ほほー

おおそこまで読んでなかった。それよさそうね

じゃあアンスコプレースホルダーをsome Anyで表現できるね

だから任意のパラメータなら some Any になるけど、、　まあわかりづらいなｗ

2:54 AM

someなのかanyなのかどっちなんだい、みたいになってる (edited)

ただでさえsomeとanyでみんな混乱してるのにw

制約付きフィールドを埋めることが出来なくなるのは稀に発生するが

2:54 AM

殆どwhereは出て来なくなるな

2:55 AM

some無しで書けるの辞めさせた方がいいかもね

2:55 AM

○ extension Array<some Animal> × extension Array<Animal>

2:55 AM

後者は混乱の元だ

extension Array where Element: Equatable { } ↑この形が残るんじゃないかな

それが

制約付きフィールドを埋めることが出来なくなるのは稀に発生するが

今回三角カッコの中に書けるのはconcrete typeだけでしょう

ああ将来的に可能という話ね

ああ

proposalは未来の話だが、proposalで言及されてない更に未来で考えられる、破綻しない範囲の話

最終形まで行くと多分someまたぎたいケースしか残らなそうだ

2:57 AM

extension <T: P> (T, T) { ... }

assoctypeに制約付けてる場合とか

2:58 AM

込み入ったヤツだけwhereが入り用になるんだと思う

Swift Regexを簡単に試せるツールを作りました。 https://swiftregex.com/

Swift Regex: Learn, build and test Swift Regex

Regular Expression Tester with highlighting for Swift Regex. Quickly test and debug your regex and Regex Builder.

2

おお〜　色も付いてる

11:50 AM

色分け用の情報はSwift Regex内部から取り出せるんですか？

11:51 AM

マウス乗せると対応が出る！

ASTができるからそれをみて頑張る。

なるほど

ASTはInternalだからtestable importで実行している。

11:53 AM

Builderとの対応は簡単な対応関係にないのでけっこう間違ってるのをがんばって補正している。ただ今は本当に間違ってることも多いと思う。

11:53 AM

ここで間違ってる、っていうのは単に私の実装の話。

11:53 AM

Swift Regexのすごいところは現在存在する正規表現をすべてサポートしようとしているところ。まだ実行はできないけどOnigurumaや.NETの超絶便利だけどマニアックな文法とかもParseまではできる。

なるほど

11:54 AM

そうか、公式の実装自体にはコンパイラ部分にソース位置との対応情報を残すAPIがない感じか

Kishikawa Katsumi

Swift Regexのすごいところは現在存在する正規表現をすべてサポートしようとしているところ。まだ実行はできないけどOnigurumaや.NETの超絶便利だけどマニアックな文法とかもParseまではできる。

4つの正規表現方言のスーパーセットにする目標ウケますよね

^[^<>]*(((?'Open'<)[^<>]*)+((?'Close-Open'>)[^<>]*)+)*(?(Open)(?!))$ ^ これとか.NETのマニアックな正規表現。

11:55 AM

ParseはできるけどNot implemetedって出ると思う。

11:55 AM

4つの正規表現方言のスーパーセットにする目標ウケますよね

ウケる。でも正規表現はコピー＆ペーストで使いたかったりするから最大限機能がサポートされるのはめっちゃいいと思う。

11:56 AM

高機能なエンジンの正規表現を低機能なエンジンで実行するために書き換えるとかかなり無理だし。

11:59 AM

あ、あと Swift Regexが便利なのは { One(.date(.numeric, locale: Locale(identifier: "en_US"), timeZone: .current)) } や { One(.url()) } っていう正規表現を超えたコンポーネントをRegex Builderだったら差し込めるところだけど、残念ながらFoundationに入ってるのでLinuxだと（今のところ？）動かない。

RegexComponentが埋め込めるの改めて考えてみるとすごいですね (edited)

12:26 PM

ゲスト言語である正規表現の中にホスト言語で書いたロジックを差し込めるわけか (edited)

すごいよね。自分で作ることもできるし。一気に最強の正規表現の実行環境となった。

3:19 PM

ジェネリクスの型パラメータ名を絵文字の

にしてるｗ

3:19 PM

phantom typeにかけたダジャレ・・・

Swift RegexはCustomStringConvertibleにかぎかっこ「」が使われたりしててそれも賢いなと思った。クオーテーション使ったら区切りか字そのものかわかりづらいし。

ほお。日本語カギカッコは、英語圏の人でもカッコだなって直感的に思えるんですか？ (edited)

それはわからない。わからないけど何かで区切っているということはわかるんじゃないか。 Half Quoteなんとかって名前がついてた。

たしかに、少なくとも見た目が枠線っぽいか

halfWidthCornerQuotedだった。かぎかっこという認識がなくてもQuotedっていうのは伝わるってことかな。

extension CustomStringConvertible { @_alwaysEmitIntoClient public var halfWidthCornerQuoted: String { "｢\(self)｣" } }

たしかにhalf width corner だ

そしてUnicodeにはhalf widthとfull widthのかぎかっこがあるっぽいな。日本語のかぎかっこじゃないのかもしれない。 (edited)

U+300C (LEFT CORNER BRACKET) と U+FF62 (HALFWIDTH LEFT CORNER BRACKET) があるのか…

ね。検索だとどっちも当たるし日本語のかぎかっこだと思ってた。

6:13 AM

かぎかっこもかぎかっこそのものを扱うときは紛らわしいだろと思うけど、カギかっこは上下ペアなのでクオートよりはだいぶわかりやすかった。

【重要】　←日本人のメールでこれよく見る (edited)

【至急】

1

⸤⸣ 上下逆もあったw

墨付きカッコか。これはUnicodeなんていうんだろ。 (edited)

6:15 AM

開閉でカタチが違うカッコは分かりやすいということだな。

｢⸣ ⸤｣

2

日本語の半角カナのかぎかっこが HALFWIDTH LEFT CORNER BRACKET になるっぽいですね。

そのHALFだったのか

半角カナ！

3:15 PM

上下反転は縦書きのカギカッコ（上の例を左右入れ替えると⸤⸣となって縦横がおかしいけど形は合ってる）がなんかの勘違いで入ってしまった、のではないかとみてるけどどうだろう。

3:19 PM

(papyrology, epigraphy) Encloses restored writing where the original scribe has written something else erroneously or where text has been lost and the restoration is likely but not certain.

https://en.wiktionary.org/wiki/%E2%B8%A2_%E2%B8%A3 なんか全然違うことが書いてあるな

%E2%B8%A2_%E2%B8%A3

U+2E22 (TOP LEFT HALF BRACKET) と、U+300C (LEFT CORNER BRACKET) と U+FF62 (HALFWIDTH LEFT CORNER BRACKET) があるんですね

⸢と「と｢ → 後ろ2つが日本語のかぎかっこ（全角と半角）

https://twitter.com/k_katsumi/status/1543477313748480001

kishikawa katsumi (@k_katsumi)

@kateinoigakukun Deployed SwiftWasm version. https://t.co/f30hlfsVgX You can see that regex can be parsed and executed without network!

1

6:14 AM

kateinoigakukunさんがSwiftWasmで動くバージョンを作ってくれた。 https://swiftregex-pr-16.onrender.com/ こういうタイプのサイトはWasmでブラウザーだけで動かせるとサーバーリソースをまったく気にしなくてよくなるのですごく便利。

Swift Regex: Learn, build and test Swift Regex

Regular Expression Tester with highlighting for Swift Regex. Quickly test and debug your regex and Regex Builder.

1

6:15 AM

今はPRプレビュー機能が使えるからRender使ってるけどGitHub Pagesみたいな静的なホスティングでも動くはず。

Kishikawa Katsumi

kateinoigakukunさんがSwiftWasmで動くバージョンを作ってくれた。 https://swiftregex-pr-16.onrender.com/ こういうタイプのサイトはWasmでブラウザーだけで動かせるとサーバーリソースをまったく気にしなくてよくなるのですごく便利。

@Kishikawa Katsumi @Yuta Saito コンソールみるとうまく動いてないっぽいエラー出ますね。SafariもChromeも同様でした。こういうものです？ (edited)

直したはずなんですが、いくつかコミット消えてますね…w

1

4:29 AM

プッシュし直したのでしばらくしたら治るはず‥！

4:32 AM

このprotocol conformanceが実行時に読めずに壊れる問題は、5.7からSwiftPMで -c release 時にリンク時GCが有効になったのと、lldのGCがgoldに比べて積極的な挙動をすることで起きてる面白いエラーなんですよね。

1

ごめん、masterからrebaseしたときに壊してしまったのかも。

1

https://forums.swift.org/t/pitch-3-opt-in-reflection-metadata/58852

Pitch #3: Opt-in Reflection metadata

It's been a while since the last iteration on the Opt-In Reflection metadata proposal, but we've been working with @Joe_Groff, @ctp and @mren on the updated version recently and while finishing the last bits, we would like to get the community's feedback on the new pieces in the proposal. TL;DR Reflectable is a marker protocol now and develope...

5:21 AM

バイナリに埋め込まれるメタデータを減らしてサイズを小さくできるように、

5:21 AM

今は常に全部埋め込まれているリフレクションメタデータを、

5:21 AM

Reflectable プロトコルに準拠する型だけ埋め込むというコンパイルモードを追加する話

5:22 AM

SwiftUIはそのリフレクションメタデータを使うので、 SwiftUI.View プロトコルには親プロトコルとして Reflectable を追加するらしい。

5:22 AM

また、 print や dump 関数はそのリフレクションメタデータがなくても簡易な出力は可能らしい。

5:24 AM

「リフレクションメタデータ」はどうやらタイプメタデータの一部らしいので、オプトインモードにおいて消えるものと残るものがあるっぽいけど、そのあたりの詳細をよく知らないのでよくわからないけど。

https://forums.swift.org/t/se-0366-move-function-use-after-move-diagnostic/59202

SE-0366: Move Function + "Use After Move" Diagnostic

Hello, Swift community! The review of SE-0366: Move Function + "Use After Move" Diagnostic begins now and runs through August 8th, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager by e...

3:08 AM

急にmoveが来た

コンパイラにヒントを与えることでCopy on Writeによるコピーを減らせる可能性がある、ってことでいいのかしら？

そうですね。

アプリを書いてる分には積極的に使うことはなさそうだけどあると良いものな気がする。

3:41 AM

議論は名前や関数形式がイマイチ不評、って感じなのかな。

変数から変数にコピーする時や、関数に渡す時に、moveしながら渡すと、retainが生じない var b = move(a) foo(move(b)) (edited)

3:41 AM

あとはmoveの返り値を捨てれば、そこで変数の寿命が終わる _ = move(x)

なんで関数形式なんだろう？

その代わりaとbはそれ以降使えなくなるんですよね？

そうです。moveに渡したところで消える。

finalize(a)の方が、みたいな意見はわかると言えばわかるな

koher

なんで関数形式なんだろう？

引数がconsumingだからですね。関数で表現できるからです。

C++で見慣れてるのでmoveはしっくりきますが、そうでなければ命名はよくわからないかもですね

func move<T>(_ x: __consuming T) -> T { return x } これだけなはず・・・ (edited)

move/copyだからわかるけどcopyというのが出てこないのが分かりにくいのかな

なるほど。そうすると自作しても同じってこと？

koher

なるほど。そうすると自作しても同じってこと？

はい。もしかしたらmove専用の最適化で差がでちゃうかもしれないけど、、意味としては。

3:45 AM

moveにかぎらず、consmingな引数をもつ関数は同じように振る舞う。渡したら変数がそこで死ぬ。

__consuming じゃなく __owned になってる？ /// This function ends the lifetime of the passed in binding. func move<T>(_ value: __owned T) -> T https://github.com/apple/swift-evolution/blob/main/proposals/0366-move-function.md#detailed-design

__consumingはmakeIteratorとかselfを消費するメソッドにつくやつですね

https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md

swift/OwnershipManifesto.md at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

3:47 AM

そっか、consmingはselfのときで、引数ではownedか

move が本質でないなら、先に __owned や __consuming の Proposal をやった方が良いのでは・・・。それとも、その部分はまだ議論したいから、とりあえず一番のユースケースとして move を先に入れちゃおうってことなのかな。裏側はともかく、 move の挙動自体は変わらないから。

このproposalはmoveに対する診断を追加するという話なのかなぁ。move自体は今でも作れるっぽいですし

koher

move が本質でないなら、先に __owned や __consuming の Proposal をやった方が良いのでは・・・。それとも、その部分はまだ議論したいから、とりあえず一番のユースケースとして move を先に入れちゃおうってことなのかな。裏側はともかく、 move の挙動自体は変わらないから。

そうそう。オーナーシップが入ってないのに一足とびでmoveだけ出てきたから、驚いた。

Iceman

このproposalはmoveに対する診断を追加するという話なのかなぁ。move自体は今でも作れるっぽいですし

そうそう。現状use after moveが許されてるんですよね

move()はC++の人はstd::move()と同じで馴染みやすいのかな。Rustはどう書くんだろう？

https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md#move ↑オーナーシップマニフェストにもmoveが出てくる

swift/OwnershipManifesto.md at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

Rustだと何もかかなくてもmoveになりませんでしたっけ

moveがデフォルトなのか

借用のほうを明示するので

Kishikawa Katsumi

move()はC++の人はstd::move()と同じで馴染みやすいのかな。Rustはどう書くんだろう？

そうですね。std::moveが出発点、これがムーブセマンティクスって概念と一緒に普及したんで、move が一番わかり易いですが

3:50 AM

そういう前提が無いと唐突なのかも

Rustはデフォルトがmove、関数キャプチャしながらmoveはmoveキーワードがあった気がする

move || よくみる

関数でいいんじゃないかな。そしておっしゃる通り __owned と__consumingの話をしないと #move()や@move()の方が、みたいな話と議論できなさそう。 (edited)

たしかになあ

https://forums.swift.org/t/se-0366-move-function-use-after-move-diagnostic/59202/32

SE-0366: Move Function + "Use After Move" Diagnostic

I think the proposal is nice, and particularly appreciate the attention to detail with defer and repopulating an inout after moving from it. I agree with the general concerns above. move isn't a function and breaks composition in weird ways, it is built-in. I think that Xiaodi's suggestion is good, given that operators feel more "built in". ...

1:05 AM

moveのスレッドに面白い意見があった

1:05 AM

ある値を inout 引数に渡す時は & を付けるのと同じように、

1:06 AM

ある値を move に渡す時は、そこで値が破壊される事を示すオペレータを付けるのはどうか let a = foo() let b = move(<-a) ってアイデア。これにクリスラトナーも賛成意見を書いてる

いやーわかりにくいんじゃないかな。&が許されてるのは既存の他の言語に同様の昨日であるからで、move()っていうのもC++で馴染んでるから、だし。

いや、 & があることによって、

2:01 AM

コードを見た人が、「ここで引数に渡した値が変更されるかもしれない」という事が視覚的に把握しやすいんですよ

2:01 AM

呼び出し先の関数のシグネチャをしらなくてもそこで副作用が起きる事がわかるのがメリット

ああ、なるほど。そうするとOperator案は一理あるな。

& という記号がわかりにくい、という観点では、 foo(a: inout a) みたいに、キーワードでも良かったかもしれませんね。C#みたいに。 (edited)

呼び出し側のコードを見るだけで理解できるのは、メリットですね

2:02 AM

await tryもそうだ。

moveも同じで、これを採用すると「ここで引数に渡した値の寿命が終了する」というマークが残せて、読むときにわかりやすい。

唯一trailing closureのラベルだけわからんこつなってるが

2:03 AM

記号として<-は適切なんだろうか

tarunon

await tryもそうだ。

そうですね。calleeの特性を、call expressionのところで専用の目印を付けることでわかるようにする。 (edited)

tarunon

記号として<-は適切なんだろうか

この <- のアイデアは、 let a = foo() let b = move(<-a) を省略して let a = foo() let b <- a って書けるようにするアイデアもセットになってるから、 <- にしたっぽい。

なるほど

あ、投稿者のアイデアは let b = <- a だった。

Source Breakingの可能性はないんだろうか。このタイプのOperatorは作れないんだっけ？

C++の文脈だと、「右辺値にする」感は出てますよね。左矢印の右側にオペランドが来るから。

<-をprefix operatorとして自作は出来ますね

Kishikawa Katsumi

Source Breakingの可能性はないんだろうか。このタイプのOperatorは作れないんだっけ？

作れるので衝突しそうｗ

moveはSwift.move()ってかけることで回避するということだけど。

やってる人がどれだけ居るかは解らん

まあfunc move()よりは全然少ないだろう。

<- 見慣れない感じがすごいですね

2:07 AM

-> の逆でしかないけど

そういえば <- 、Goのchannelにもありますね

1

@swift-5.6.3

@propertyWrapper class FugaWrapper { public var projectedValue: Int { return wrappedValue } public var wrappedValue: Int init(wrappedValue defaultValue: Int) { self.wrappedValue = defaultValue } } class Hoge { @available(*, unavailable) @FugaWrapper() var piyo: Int = 0 } print(Hoge().$piyo)

unavailable なプロパティの projectedValue にアクセスできるのって何でなんでしょう？ projectedValueもunavailableになりそうなものですが…

rinsuki

@swift-5.6.3

@propertyWrapper class FugaWrapper { public var projectedValue: Int { return wrappedValue } public var wrappedValue: Int init(wrappedValue defaultValue: Int) { self.wrappedValue = defaultValue } } class Hoge { @available(*, unavailable) @FugaWrapper() var piyo: Int = 0 } print(Hoge().$piyo)

unavailable なプロパティの projectedValue にアクセスできるのって何でなんでしょう？ projectedValueもunavailableになりそうなものですが…

0

https://forums.swift.org/t/accepted-se-0365-allow-implicit-self-for-weak-self-captures-after-self-is-unwrapped/59517

[Accepted] SE-0365: Allow implicit self for weak self captures, aft...

Hello Swift Community, The review of SE-0365 ended on August 1st, 2022. This proposal improves the ergonomics for use of implicit self in closures capturing self weakly. The Language Workgroup has decided to accept the proposal. Feedback on the proposal was mostly positive. Reviewers identified that the proposal text could be clarified furt...

これ嬉しいですね

というか今は guard let self else { return } って書けるのか

if let foo = foo が if let foo になるやつでしょ

一回も使ったことなかった

できるの5.7だからまだですよｗ

まだかw

7:18 AM

もうすっかり入った気になってた

https://forums.swift.org/t/borrow-and-take-parameter-ownership-modifiers/59581 (edited)

borrow and take parameter ownership modifiers

Hi everyone. I'd like to revive a pitch from a while back to turn our shared and owned parameter ownership modifiers into an official language feature. During the recent review of SE-0366, for the move operator, the community raised the importance of considering these modifiers, and their naming, as part of the naming of the move operator it...

4:34 AM

オーナーシップ指定をborrowとtakeにしようってスレッド

4:35 AM

ついでにselfについてはborrowing funcとtaking funcはどうかとのこと

4:36 AM

で、moveはやめてtakeにする

4:40 AM

所有権を奪う操作はすでにUnsafePointer系のAPIとか内部のValueWitnessTableで、takeって言葉が使われてるから

4:40 AM

Swift用語としての一貫性もある

moveより方向が分かりやすくなるのがいいのかしら

まずtake引数が導入されることで、takeオペレータはそれと同じだから、という意味でわかりやすくなりますね (edited)

4:45 AM

元々はowned引数とmoveオペレータだったので、この関係は少し難しかったかも。

4:46 AM

moveスレッドには、逆にowned引数なんだからmoveオペレータじゃなくてownオペレータにしたら？という意見も書き込まれてましたね

https://forums.swift.org/t/returned-for-revision-se-0366-move-operation-use-after-move-diagnostic/59687

[Returned for revision] SE-0366: Move Operation + "Use After Move" ...

Hello, Swift community! The review for SE-0366: Move Operation + “Use After Move” Diagnostic ended on August 8th. The Language Workgroup decided that the proposal is returned for revision. Based on early review feedback, the proposal authors revised the syntax of the move(_:) function to a contextual move keyword. The Language Workgroup agrees...

7:20 AM

moveの審査が再検討に差し戻されました。さっきのborrow/takeの検討と連動してそう。 (edited)

omochimetaru

https://forums.swift.org/t/borrow-and-take-parameter-ownership-modifiers/59581 (edited)

https://forums.swift.org/c/evolution/18

これリンクミスってませんか？

koher

https://forums.swift.org/c/evolution/18

これリンクミスってませんか？

直しました

1

https://forums.swift.org/t/a-new-swift-parser-for-swiftsyntax/59813

A New Swift Parser for SwiftSyntax

Hello Swift Community, SwiftSyntax is a SwiftPM package that allows one to parse Swift source code into a syntax tree, manipulate that tree, and render the tree back to source code. It is used by tools such as SwiftLint and swift-format that operate on Swift source code. The parsing capabilities of SwiftSyntax (in the module SwiftSyntaxParser) ...

1

5:39 PM

Swift ParserのSwift実装だって！

5:39 PM

SwiftSyntaxがlibISSPに依存しなくてよくなる

これは嬉しい

https://github.com/apple/swift-syntax/pull/616/files コミットでっけ〜

5:51 PM

Efficient: The parser should provide similar parsing performance to the existing C++ parser implementation that it seeks to replace.

これがどこまでいけるか気になるな　実装も今後見ていこう

なんか昔パフォーマンス出なくてswift-syntaxの統合諦めたみたいな話なかったでしたっけ

あったけど、あれはC++でAST作ってそれをSwiftとブリッジしようとしたオーバーヘッドが無視できなかったって事じゃないんかな

5:54 PM

パーサもSwiftだったらそこはアーキテクチャ的な無駄がなくなっていけるんじゃないか

C++ のコンパイラパイプラインに C++ の libSyntax を統合しようとして諦めた件かな？ https://github.com/apple/swift/pull/27675 これは SwiftSyntax は関係なくて、C++パーサ内での諸々のオーバーヘッドによって満足できるパフォーマンスが出なかったです。

Swift側は関係ないか。

ああ、それですそれです。

5:57 PM

なるほどー

まあ SwiftSyntax はそれ以上に重かったんですけど、いろんなテクニックを駆使してなんとかします笑

今回はパーサごと作り直しだからそこはクリアできそうってことですね

んー、いちばん重いのはオブジェクトの作成(malloc/dealloc)とリファレンスカウンティング(retain/release)なんですよね。

むむ

6:02 PM

新しい ParserもSwiftSyntaxTokenだから (edited)

おー、やっぱりそうなんですね。なんかSyntaxArenaとかそれっぽいワードが。

RawTokenでそれやるのは同じ・・・？

なんで Bump pointer allocation https://github.com/apple/swift-syntax/pull/544

Bump allocated RawSyntax by rintaro · Pull Request #544 · apple/swi...

Introduce SyntaxArena that manages the memory of RawSyntax RawSyntaxData is the "data" of raw syntax managed by SyntaxArena, and it has Unowned pointer to the SyntaxArena Tagged union of...

マジ

6:03 PM

あつい

6:03 PM

手動メモリ管理Swiftだ

めっちゃ最近のPRだ

struct RawSyntax { /// Pointer to the actual data which resides in a SyntaxArena. var pointer: UnsafePointer<RawSyntaxData> init(pointer: UnsafePointer<RawSyntaxData>) { self.pointer = pointer }

なるほど

6:06 PM

理論上できるよなと思ってたけど本気でやったコード初めて見た

そんなに大量のオブジェクトを作る必要のあるプロジェクトもなかなか無いですよね

Root SyntaxData now owns the SyntaxArena of the root RawSyntax.

ふむふむ

6:12 PM

SwiftSyntaxのライブラリユーザのコードで、ルートだけ解放しちゃって子供ノードだけ掴んでる状態にするとクラッシュ？ (edited)

子は親を retain しているので、大丈夫です

public struct SyntaxNode { let absoluteRaw: AbsoluteRawSyntax let parents: ArraySlice<AbsoluteRawSyntax> ↑これですか？

これですね https://github.com/apple/swift-syntax/blob/1313c36fbf86215d4d6894b8d5e85f1230f013d1/Sources/SwiftSyntax/SyntaxData.swift#L217-L223

 private enum ParentOrArena { // For non-root nodes. case parent(SyntaxBox) // For root node. case arena(SyntaxArena) } private let parentOrArena: ParentOrArena

(edited)

SyntaxBoxなるほど

このPRも参考にどうぞー https://github.com/apple/swift-syntax/pull/512

2

子から親をretainするツリーって珍しいですね

6:18 PM

SwiftSyntaxだと出来上がったツリーに部分的にノードを挿入/離脱したりできなくて、編集する場合まるごと作り直すイミュータブルデータ構造っぽいやつだからそれでいけるのか・・・？ (edited)

Roslyn の red-green ツリー系統のツリーはそんな感じだと思います

へえ〜〜

6:20 PM

これはいろいろ読んだら面白そうだ

red-greenツリーってRoslyn由来なんだ

https://ericlippert.com/2012/06/08/red-green-trees/

ericlippert

Persistence, façades and Roslyn’s red-green trees

We decided early in the Roslyn design process that the primary data structure that developers would use when analyzing code via Roslyn is the syntax tree. And thus one of the hardest parts of the e…

6:43 PM

これが原典かな？イミュータブルなAPIの皮がred treeで、内側の実装ツリーがgreen treeと呼ぶのね

ですです。

Swift Parserはいいですね

リカバリー能力は既存のSwiftSyntax パーサーより良いと思うので、機会があったら Swift AST Explorer で使ってみていただけると

リカバリー気になる

使ってみたい。SwiftRegex.comでもBuilderの実行のために使ってるんですけどmain x mainだとバージョン合わせが大変でそこが解消されると嬉しい。

@_spi(RawSyntax) public struct RawSyntax { var rawData: RawSyntaxData { unsafeAddress { pointer } }

1:02 AM

謎の文法がある

1:02 AM

/// This is an address-family accessor: a function that is called when /// a value is loaded from the storage, like a getter, but which works /// by returning a pointer to an immutable value of the storage type. /// This kind of accessor also has an addressor kind. /// /// Addressors are a way of proving more efficient access to storage /// when it is already stored in memory (but not as a stored member /// of the type). IMMUTABLE_ADDRESSOR(Address, unsafeAddress)

https://github.com/apple/swift/blob/7123d2614b5f222d03b3762cb110d27a9dd98e24/include/swift/AST/AccessorKinds.def

1:03 AM

get とか _read みたいなプロパティ実装方法の一つらしい

1:08 AM

@_spi(RawSyntax) public struct RawTryExprSyntax: RawExprSyntaxNodeProtocol { public var unexpectedBeforeTryKeyword: RawUnexpectedNodesSyntax? { layoutView.children[0].map(RawUnexpectedNodesSyntax.init(raw:)) } public var tryKeyword: RawTokenSyntax { layoutView.children[1].map(RawTokenSyntax.init(raw:))! } public var unexpectedBetweenTryKeywordAndQuestionOrExclamationMark: RawUnexpectedNodesSyntax? { layoutView.children[2].map(RawUnexpectedNodesSyntax.init(raw:)) } public var questionOrExclamationMark: RawTokenSyntax? { layoutView.children[3].map(RawTokenSyntax.init(raw:)) } public var unexpectedBetweenQuestionOrExclamationMarkAndExpression: RawUnexpectedNodesSyntax? { layoutView.children[4].map(RawUnexpectedNodesSyntax.init(raw:)) } public var expression: RawExprSyntax { layoutView.children[5].map(RawExprSyntax.init(raw:))! } }

unexpectedなんちゃらを含む構造で正規の文法よりゆるいソースコードをパースしたそうな雰囲気

1:11 AM

 struct ParsedToken { var tokenKind: RawTokenKind /// Whole text of this token including leading/trailing trivia. var wholeText: SyntaxText /// Range of the actual token’s text. /// /// Text in `wholeText` before `textRange.lowerBound` is leading trivia and /// after `textRange.upperBound` is trailing trivia. var textRange: Range<SyntaxText.Index> }

leading trivia, token, trailing triviaの持ち方も軽そうな感じになってる

SyntaxText も non-owning なテキスト実装として面白いと思いますよ。

見てきました。これも良いですね。 public struct SyntaxText { var buffer: UnsafeBufferPointer<UInt8> 実装でも UnsafeBufferPointerの機能もうまく使われてる

1:32 AM

Swift.Substring が機能的に近いと思うけど、不正なUTF-8バイト列を含むソースコードファイルもbyte-to-byteエディットしようとしてるから、Swift.String 系だとダメそうだ

1:33 AM

 for case let node? in layoutBuffer { byteLength += node.byteLength descendantCount += node.totalNodes recursiveFlags.insert(node.recursiveFlags) arena.addChild(node.arenaReference) }

↑これ知らんかった

元は素直にC++と同じで StringRef 命名だったんだ

そーなんですよね。僕はC++コンパイラにコントリビュートしてた人がわかりやすいからStringRefでいいと思ったんですけど。

なるほど

2:04 AM

AbsoluteSyntaxPositionはutf-8 offsetしか持ってないけど行番号は SourceLocationConverter で先に行分割結果をキャッシュしといて二分探索なるほどなあ (edited)

お〜 TokenPrecedence 面白いアイデア

2:45 AM

これなら一個ずれてもグチャァってならずにそれっぽいアンカーを当てはめられそうだ

2:46 AM

Swiftのディクショナリリテラルが [:] カッコで良かった

で、これがトークン読み取る時の一般挙動として実装してあるから文法の実装から隠蔽できるのか

Swift向けLLVMバインディングも始まってる https://github.com/apple/swift-llvm-bindings

GitHub - apple/swift-llvm-bindings: Swift Bindings for LLVM Project...

Swift Bindings for LLVM Project APIs. Contribute to apple/swift-llvm-bindings development by creating an account on GitHub.

すごい

C++ interopの成果凄すぎる

LLVMってC++のテンプレートテクニックかなりヤバいレベルだけど

8:17 AM

いけるんだ。

すごすぎる

まだガッツリ実装があるわけではなさそう?だけど、StringRefがそのまま使えてる https://github.com/apple/swift-llvm-bindings/blob/llvm.org%2Fmain/Sources/LLVM/LLVM_Utils.swift

add_library(LLVM_Utils LLVM_Utils.swift) target_compile_options(LLVM_Utils PUBLIC "-enable-library-evolution" "-emit-module-interface" "-Xfrontend" "-enable-experimental-cxx-interop") target_include_directories(LLVM_Utils PUBLIC "${LLVM_MAIN_INCLUDE_DIR}" "${LLVM_INCLUDE_DIR}")

8:19 AM

実装はこれだけなんじゃない？

8:19 AM

LLVM側はそのまま使うから

あー、そっか

extension llvm.Twine: ExpressibleByStringLiteral { public init(stringLiteral value: String) { self.init(value) } } こういうSwiftらしく使える部分は付け足していくのかもだけど。

LLVMのADT周りさえそのまま使えれば機械的にC++ -> Swiftの書き換えできるのかなぁ (edited)

https://twitter.com/swiftlang/status/1569402670678679553?s=46&t=WNcVTBCu_o3-TZA9GfV76A

Swift Language (@SwiftLang)

Swift 5.7 is now available! This release contains many of the enhancements announced at WWDC22, including improved generics syntax, regular expression literals, enhanced data race safety, and more. https://t.co/BJpSyLgSPw

Likes

302

Retweets

110

5

https://github.com/apple/swift/pull/61107/files

[interop][SwiftToCxx] initial generic enum support by hyp · Pull Re...

This supports generic enums, including getting a generic associated value. The one thing that's not supported yet is the construction of generic enum values. This will allow Optional to be ...

6:07 AM

C++ Interopで、Swiftで定義したenum (associated value付き) を C++から使えるようになってる

6:07 AM

テストコード見るとわかるけど、

6:08 AM

this ポインタから value witness table取り出してそれを使うコードが C++コードとして生成されてて面白い

6:08 AM

LLVM-IRの形で見たやつだ・・・ってなる

実行時にVWT経由するのはジェネリックな型だから？

そうだと思う PRもgeneric enum support ってタイトルになってるし (edited)

6:10 AM

c++ // CHECK-NEXT: template<class T_0_0> // CHECK-NEXT: requires swift::isUsableInGenericContext<T_0_0> // CHECK-NEXT: inline T_0_0 GenericOpt<T_0_0>::getSome() const { // CHECK-NEXT: if (!isSome()) abort(); // CHECK-NEXT: alignas(GenericOpt) unsigned char buffer[sizeof(GenericOpt)]; // CHECK-NEXT: auto *thisCopy = new(buffer) GenericOpt(*this); // CHECK-NEXT: char * _Nonnull payloadFromDestruction = thisCopy->_destructiveProjectEnumData(); // CHECK-NEXT: if constexpr (std::is_base_of<::swift::_impl::RefCountedClass, T_0_0>::value) { // CHECK-NEXT: void *returnValue; // CHECK-NEXT: returnValue = *reinterpret_cast<void **>(payloadFromDestruction); // CHECK-NEXT: return ::swift::_impl::implClassFor<T_0_0>::type::makeRetained(returnValue); // CHECK-NEXT: } else if constexpr (::swift::_impl::isValueType<T_0_0>) { // CHECK-NEXT: return ::swift::_impl::implClassFor<T_0_0>::type::returnNewValue([&](void * _Nonnull returnValue) { // CHECK-NEXT: return ::swift::_impl::implClassFor<T_0_0>::type::initializeWithTake(reinterpret_cast<char * _Nonnull>(returnValue), payloadFromDestruction); // CHECK-NEXT: }); // CHECK-NEXT: } else if constexpr (::swift::_impl::isSwiftBridgedCxxRecord<T_0_0>) { // CHECK-NEXT: abort(); // CHECK-NEXT: } else { // CHECK-NEXT: T_0_0 returnValue; // CHECK-NEXT: memcpy(&returnValue, payloadFromDestruction, sizeof(returnValue)); // CHECK-NEXT: return returnValue; // CHECK-NEXT: } // CHECK-NEXT: }

6:10 AM

↑生成されたコードも constexpr 使って最適化で畳めそうな感じになってる

これは面白いなぁ

6:11 AM

IRGenのコードと重複がかなり出そうだけどメンテ頑張るのかな

6:12 AM

いい感じに共有できてる？

二重実装に見える

すごい

6:13 AM

これからはランタイムライブラリとIRGenとCxxInteropでランタイムデータ構造の整合を取らないといけない

C++から使うためにはテンプレートパラメータ＋コードの形にexportするしか無いしこうなるよなあ VWTから先の本体？的な処理は共有されるからいいけど

6:15 AM

Swift側にもC++ Interopしたものを扱うための補助ライブラリがあるし (CxxIterator)

6:15 AM

C++側にもSwift exportしたものを扱うための補助ライブラリがあるようだ

6:16 AM

https://github.com/apple/swift/blob/6ed62904d3e726dfc4e74e27983f845a10a518c5/stdlib/public/SwiftShims/_SwiftCxxInteroperability.h

swift/_SwiftCxxInteroperability.h at 6ed62904d3e726dfc4e74e27983f84...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

こうなるんだ c++ /// Swift's Int type. using Int = ptrdiff_t; /// Swift's UInt type. using UInt = size_t;

なるほど。std::intptr_t かと思った

6:19 AM

// CHECK-NEXT: auto *vwTableAddr = reinterpret_cast<swift::_impl::ValueWitnessTable **>(metadata._0) - 1;

6:19 AM

ここで使われてる swift::_impl::ValueWitnessTable を探し中 (edited)

見当たらない

もしかしてRuntime用のヘッダーと共有できてるのかなと思ったんだけど

6:21 AM

そっちは swift::ValueWitnessTable にみえるんだよね

そうそう

https://github.com/apple/swift/blob/a93a57435e6e6dfa9722cc0b705476d8b4e7b5b5/include/swift/ABI/ValueWitnessTable.h

swift/ValueWitnessTable.h at a93a57435e6e6dfa9722cc0b705476d8b4e7b5...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

https://github.com/apple/swift/blob/main/lib/PrintAsClang/PrintSwiftToClangCoreScaffold.cpp#L83 これ？ (edited)

swift/PrintSwiftToClangCoreScaffold.cpp at main · apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

おわー

6:23 AM

ズタズタに切り刻まれてた。

c++ os << "\nstruct ValueWitnessTable {\n" << membersOS.str() << "};\n\n";

6:23 AM

kusa

#include "swift/ABI/ValueWitness.def"

6:23 AM

あっ、XMACROだ！

6:23 AM

そういうことか〜

6:25 AM

半分ぐらい共有されてる感じだな・・・

6:26 AM

printPrimitiveGenericTypeTraits で基本型のtraitが生成されてる。

 os << "template<>\n"; os << "static inline const constexpr bool isUsableInGenericContext<" << typeInfo.name << "> = true;\n\n";

6:27 AM

おもしろいなあ

C++のテンプレートのコード生成、コード生成器が壊れたりサポートしてない入力が来たときにエラーメッセージが大変なことになりそう

6:34 AM

conceptってやつで将来的になんとかなるのかな

C++テンプレートコードを自動生成する時の話？ C++テンプレートをユーザが使うときの話？

そうか、C++テンプレートコードを生成するときはその結果はClangに食わせないから、エラーが出るのはコード生成が終わってそれをユーザが使うときか (edited)

6:42 AM

なのでユーザが自動生成されたテンプレートを使うときに大変かな、という懸念

そういう意味では、両方の問題が同時に来るから普通のテンプレートより厳しい状況になりそうだね。

6:45 AM

C++テンプレート一般についていえば

6:45 AM

テンプレートクラスやライブラリの実装者が工夫することで

6:45 AM

わかりやすい壊れ方をするように作ったりはできるよ

なるほど

https://cpprefjp.github.io/reference/iterator/iterator_traits.html

iterator_traits - cpprefjp C++日本語リファレンス

iterator_traitsは、イテレータに関する型情報を取得するためのクラスである。

6:47 AM

traitパターンってのがあって、それで型をプロトコル（？）に準拠させたい側が丁寧にusing(or typedef) しておいて

6:47 AM

みたいにやっておくと、変なもの与えてもtrait準拠の時点でおかしいから

6:47 AM

コード本文の深いところに入る前にエラーが出る

6:47 AM

https://theolizer.com/cpp-school2/cpp-school2-10/

6:48 AM

あと今調べたんだけど頑張ればSFINAEを使って、メンバを持っているかどうかも静的に判定できるらしい

6:48 AM

だからめちゃくちゃ頑張ればconcept準拠相当のロジックを事前にテンプレートプログラミングで判定できるんじゃないかな・・・？

へー、そこもチェックできるんだ

6:48 AM

めちゃくちゃ頑張れば。。

6:48 AM

（コンパイル速度を犠牲にして）

concept文法が入るとそのへんがパターンとして簡単にかけて便利。

Yuta Saito

（コンパイル速度を犠牲にして）

その犠牲は確かに・・・

6:49 AM

さっきの isUsableInGenericContext も traitパターンになってると思うなにをtraitパターンと言うか正確にわかってないけど・・・パラメータ特殊化を使ってboolを返すようにしてconstexprで評価できるようにしている

なるほどなぁ。

 CHECK-NEXT: template<class T_0_0> // CHECK-NEXT: requires swift::isUsableInGenericContext<T_0_0> // CHECK-NEXT: inline bool GenericOpt<T_0_0>::isNone() const { // CHECK-NEXT: return *this == GenericOpt<T_0_0>::none; // CHECK-NEXT: }

6:52 AM

てかここのrequiresってconceptか？

マクロよりはマシかなぁ

6:52 AM

お

https://cpprefjp.github.io/lang/cpp20/concepts.html

コンセプト - cpprefjp C++日本語リファレンス

C++20から導入される「コンセプト (concepts)」は、テンプレートパラメータを制約する機能である。この機能を使用することで、以下のような面でプログラミングのしやすさが向上する：

6:52 AM

もう使ってそう

ぽい

6:52 AM

すごーい

c++ // 描画可能コンセプト。 // メンバ関数draw()を持つことを要求する template <class T> concept Drawable = requires (T& x) { x.draw(); // 型Tに要求する操作をセミコロン区切りで列挙する。 // ここでは、メンバ関数draw()を呼び出せることを要求している。 };

6:53 AM

結局こんな文法になったのか。

6:54 AM

なんか直接的で受けるな。Goのgenericsもこんな感じの仕様が検討されてたのを昔見た。どうなったんだろ。

requires節は関数本体に書いてたstatic_assertが関数宣言部にかけるようになった感じ？

c++ template <class T> requires std::constructible_from<T, int> && std::move_constructible<T> T make_from_int(int x) { return T(x); }

(edited)

static_assertは宣言にも書けた

c++ template <class T, std::size_t N> struct X { static_assert(N > 0, "number of array elements must greater than 0"); T array[N]; };

けど関数とペアにする場合たしかに本文か？

6:58 AM

そんな解釈で良さそうに思える

ふむふむ

6:59 AM

つまりSwiftコンパイラから生成されたヘッダを読み込むにはC++20が必須

C++11の会議において「コンセプトは本当にC++11に入れるんだな？」という投票を行い、コンセプトをC++11に入れる合意が得られてコンセプトが入った規格案であるCommittee Draft (CD) が公開された。しかしその後、コンセプトはやはり使うのが難しく複雑だということで取り下げられ、コンセプトが取り除かれたCommittee Draft (CD2) が再度公開された。ただしその際、コンセプトの策定で培った経験は活かすことになり、整理された自然言語としてテンプレートパラメータへの要求が規格に載ることとなった。 C++14の策定において、コンセプトの複雑さを回避して必要最小限の機能のみをまとめた「軽量コンセプト (Concept Lite)」という機能を入れることが計画された。これは、C++11で導入されたconstexprを使用し、bool型の定数式として制約を定義し、requires節にbool型定数式を指定して制約するというものだった。これはConcept TS (Technical Specification) として個別に各国承認が行われ、遅延したがC++17に導入される予定だった。 軽量コンセプトとしてなるべく早くプログラマにこの機能を導入するつもりだったが、その後コンセプトをさらに仕様拡張としていくことを考えると、最初の設計から大幅に違ったものになってしまう懸念があった。また、コンセプトは標準ライブラリの仕様に適用すべきものであるため、より完全なものが求められた。そのため、軽量コンセプトという予定はなくなり、より時間をかけて完全なコンセプトの仕様を策定することとなり、C++20で導入されることとなった。

7:00 AM

めちゃめちゃ迷走してたんだな

完全なコンセプトがようやく完成したのか

Yuta Saito

つまりSwiftコンパイラから生成されたヘッダを読み込むにはC++20が必須

どうだろう、検査を足してるだけだから、それを剥がせば許容バージョンを下げられそうだけど

インスタンス化できるべきでないテンプレートがインスタンス化されてしまう可能性があるくらい？

https://github.com/apple/swift/blob/main/docs/CppInteroperability/UserGuide-CallingSwiftFromC%2B%2B.md#c-language-and-library-requirements

7:03 AM

C++ Language And Library Requirements Importing Swift APIs into C++ requires certain C++ features introduced in newer C++ language standards. The following C++ standards are expected to work: C++20. It is the recommended standard, as C++ 20 concepts enable type checking for imported Swift generic APIs. C++17 and C++14 are supported with some restrictions. Some generic APIs might not be available prior to C++20.

7:03 AM

14まで下げられるって。

書いてあった

ドキュメントいろいろ増えてる

WKWebViewにこういうシグネチャのメソッドがあって、

func evaluateJavaScript( _ javaScript: String, in frame: WKFrameInfo? = nil, in contentWorld: WKContentWorld, completionHandler: ((Result<Any, Error>) -> Void)? = nil )

こんなふうに使うんだけど webView.evaluateJavaScript("document.body.innerHTML", in: nil, in: WKContentWorld.defaultClient) ２番目と３番目の引数のラベルがどちらも in で、２番目のラベルはデフォルト引数が設定されているので省略可能なのだけど、 webView.evaluateJavaScript("document.body.innerHTML", in: WKContentWorld.defaultClient) こういうふうに省略して書くと Extra argument 'in' in call とか、 completionHandler を付けても Cannot convert value of type 'WKContentWorld' to expected argument type 'WKFrameInfo?' ってコンパイルエラーになるんだけど、これは引数ラベルを同じにしてしまったことが問題なのかしら？

同じかつ両方省略可能にしたことによるバグっぽいですね

バグっぽいですよねえ。コンパイラの方のバグ、ってことですよね？

仕様バグかなぁ

6:33 PM

優先度が何かしら決まればエラーじゃなくは出来るから

6:33 PM

優先度がないことがバグ？と言えばそうかも

見つけたからレポートしてみよう。 AppleのAPIで見つかるのがおもしろいですよね。

その辺のラベルマッチングは結構実装読んだけど、探索的な動作はしないから無理なんですよね

8:19 AM

ただa:b: にたいして b:a: で呼び出すみたいな前後入れ替えとかは診断出すために対応を調べていたりして

8:19 AM

ややこしい動作も持っていたりする

8:19 AM

ラベルマッチングに関する文書は存在しなくて実装が仕様状態なんで、

8:20 AM

仕様のバグなのかどうかもハッキリしない

この例だと順序と型で区別できそうですけど無理ですか？

型での区別はやらない事になっているんですよね末尾クロージャーだけちょっと特殊な型の考慮があったりするんですけど

8:30 AM

理由？というかアーキテクチャとしては

型見ないんだ。そうすると型のオーバーロードはどうなるんですか？

オーバーロードの候補解決と型推論が関係していて

8:31 AM

「どのオーバーロードを呼び出すか」っていう選択肢は型推論システムに対して提供されるんですけど

8:32 AM

「あるオーバーロードを呼び出す時に引数のラベルマッチングをどうするか」っていう選択肢は提供されなくて、型推論システムにとっては、どのオーバーロードを呼び出すかを考える時点でラベルマッチングは固定済みなんですよね

8:34 AM

今回は in: ラベルで重複していますけど

8:34 AM

もっと一般的な問題としてはラベル無しの場合を考えるとよくて、（ラベル無しはラベル文字列が "" の場合として同じ理屈になる）

これが解決できないんですねえ。

↑の例みたいにデフォルト引数をそれぞれ与えてしまえば、もし型を考えるなら、２通りの型チェックで呼び出せる事になる今はそうなっていない

8:35 AM

もし解決できるようにすると、

8:35 AM

与えられてる実引数がどのパラメータに対応するかを、この方式で引数を増やせば増やすほど候補が増えていくので

8:35 AM

例えば4引数とかにしちゃったら探索範囲が2^4で16倍に爆発しちゃいます

8:35 AM

具体的な型がわかっているときならすぐにチェックできるけど

8:36 AM

型推論の最中だったりすると型が未確定のままこの組み合わせを調べないといけないとかが生じるので

8:36 AM

オーバーロード数が増えてるのと同じで型推論がめっちゃ重くなっちゃう状況が発生する可能性があります

そうなんですね。コンパイルエラーにしないのはできるかもしれないけど、そうすると型推論などのそれ以前の処理に大きく影響する恐れがあると。

そうですね

8:43 AM

あと、ラベルマッチングは末尾クロージャの扱いとか、可変長引数の扱いとかの仕様もあるので、結構複雑で、既存実装を型推論エンジンの中で問題として解かせるようにする改修の実装が大変そうです。

8:45 AM

https://github.com/apple/swift-evolution/blob/main/proposals/0286-forward-scan-trailing-closures.md

8:46 AM

末尾クロージャは、渡す引数のクロージャにはラベルがついてないけど、受け取る関数側にはラベルが付いているので、マッチングルールが例外処理されていてややこしくて、そこに複数末尾クロージャの仕様が入って問題が発生したので SE-0286 で仕様が直された事があります (edited)

8:46 AM

ラベルマッチングの仕様がそもそも文書化されていないのに、ここだけ急に仕様変更が形式的な審査手順を踏んだのでなんか妙な感じでした。

8:47 AM

変更前後で互換性問題が生じるのでまあ適切ですけど。

つまりWebViewのこのAPIは近い将来ではコンパイルできるようになる可能性は低い。コンパイラのバグとも言えない（仕様が決まってない）。ということはWebViewのこのメソッドシグネチャが悪いって感じだけどもうPublicになってるからそれはそれで難しそうだな。

簡単な？対策としては

8:53 AM

extension WKWebView { func evaluateJavaScript( _ javaScript: String, in contentWorld: WKContentWorld, completionHandler: ((Result<Any, Error>) -> Void)? = nil ) }

8:53 AM

これを自前で定義すれば呼び出せるかもしれません

8:53 AM

デフォルト引数を与えるんじゃなくて、引数が無いバージョンをオーバーロードする。

8:54 AM

たしか「あるオーバーロードと共にデフォルト引数を使う」より、「最初から引数がないオーバーロードを選ぶ」ほうがコストが安いっていうロジックが入っている (edited)

ああ、なるほどね。今はXcodeの補完に差はないけど、昔は補完をうまくするためにデフォルト引数じゃなくてオーバーロードで、みたいなのを思い出した。

8:56 AM

そうするとWKWebViewの方で、デフォルト引数じゃなくて引数の数でオーバーロードにする、という修正で解決できる？

Kishikawa Katsumi

そうするとWKWebViewの方で、デフォルト引数じゃなくて引数の数でオーバーロードにする、という修正で解決できる？

たしかに。バグレポート出したらそういう修正が降ってくる可能性はありますね。

https://forums.swift.org/t/initiative-swift-platform-work-group/60340

Initiative: Swift Platform Work Group

Swift Platform Work Group (tentatively named) is a new Swift community workgroup, working together to improve platform usability of Swift. This includes: Expanding available target platforms for Swift. SPWG should embrace community works in cross compilation area, and, help the community to contribute related changes to upstream. So far, the ...

11:54 PM

Swift Platform WGというのが発足したらしいいろんな環境のサポートを進めていくそうだ

11:55 PM

https://discord.com/channels/291054398077927425/375206337937801216/1005145210407374848

11:55 PM

↑WASM代表で最近Appleに転職したMaxさんの名前がフォーラム投稿に書かれている (edited)

11:55 PM

AppleがWASM対応に本気だしたかもしれない (edited)

11:56 PM

そういえば、Swiftコンパイラの部分的なセルフホストが始まってるから、

11:57 PM

全く新しいプラットフォームに対応する難易度が上がるな。

11:57 PM

C++だけでビルドできる古いSwiftをまずポーティングして、その次にその古いSwiftを使って最新のSwiftがビルドできる、というブートストラップになるはず？

omochimetaru

AppleがWASM対応に本気だしたかもしれない (edited)

Note that this initiative is not from the Swift core team or Apple. As the original author, I’m calling out for community effort and official support in this area by forming SPWG officially.

一応

う～む

10:26 AM

https://forums.swift.org/t/initiative-swift-platform-work-group/60340/15

Initiative: Swift Platform Work Group

As a contributor, I observed noticeably slow responses to patches around platforms apart from Darwin and Linux, even for trivial ones. This could be a result of multiple factors: new platform maintainers often don’t have commit access; there’s no platform manager so non-trivial changes are not easily evaluated; there’s no CI or testing infrast...

10:27 AM

ここで、karlさんのWASMって結構できてるけどこれ以上何するの？って質問に答えてるけど、

10:28 AM

コミュニティエフォートでどうにかならない話をしてるような・・・

10:29 AM

でも stevapple さんはGitHubみるとAppleじゃなくて中国の大学生なのか。appleついてるだけか。

はい

アプリ開発初心者です。Swiftの学習で行き詰まっておりまして、お時間ある方にご教授願いたいです。 viewControllrで画面を追加して追加した画面にTable view及び Table viewcellをドラッグアンドドロップし、シュミレーターで確認するとシュミレーター画面が飛び、 @mainに赤線が引かれ Table view:numberOfRowsinSection: unrecognized Serector sent to instance というエラーが出てしまいます。わかる方いたらぜひ教えてくださるとありがたいです。

エラーの直接の原因は、numberOfRowsinSection:というTable Viewにデータを何件表示するか、ということを示す関数がないことですが、そこを直しても今度はTable Viewに表示する内容を示す関数がないエラーが出る、、、となると思います。何か参考にされて書かれてますか？そうだとすると手順をいくつか飛ばしてしまってると思います。参考にされてるものがあるとするとその内容を載せてもらえますか？

ご回答頂きありがとうございます。とても助かります。 YouTubeの　Rikuto Satoさんの iPhoneアプリ開発講座2時間でマスター　総集編のパート8 リストを使ったアプリを参考にしながらやっております

おそらく、説明のテーブルビューをドラッグ＆ドロップで配置したあとに、delegateとdataSourceの線をView Controllerと繋ぐ手順（４分あたり）の後に何もコードを書かずに起動しているのではないでしょうか？ delegateとdataSourceの線を繋いだ後はテーブルのデータをどうするか、という関数を書かないとそれが見つからないということでそのようなエラーになります。続けて解説をみていくとコーディングの説明に入ってその見つからない関数を書いていくところが見られます。 (edited)

2:09 PM

全部は見てないですが手順どおりに全くおなじようになぞれば問題はなさそうですよ。 (edited)

そうです！動画の主が delegateとdata sauceをview Controllerに繋いでTable viewcellの identifyにcellと入力し、シュミレータでリストの欄ができていたので勘違いしていました！今一度最初からシュミレータで起動しなくとも一回最後までやってみようと思います！丁寧にありがとうございました！！また壁にぶつかったら頼りにくるかもしれないのでその時はまたよろしくお願いします。本当にありがとうございました！！

可変長ジェネリクスのパラメーターパックのドラフト https://forums.swift.org/t/pitch-parameter-packs/60543

[Pitch] Parameter Packs

Hello, Swift community! @Slava_Pestov and I have been working on an updated design for variadic generics in Swift. This pitch details the fundamental concept of abstracting over a list of zero or more type parameters with parameter packs. I've pasted a draft of the design below, and it is also available at swift-evolution/NNNN-parameter-packs.m...

1

typealias G<E...> = (Array<E>...)

これ難しいな

これは久々の大型マニフェスト？ https://gist.github.com/DougGregor/4f3ba5f4eadac474ae62eae836328b71

A possible vision for macros in Swift

A possible vision for macros in Swift. GitHub Gist: instantly share code, notes, and snippets.

4:21 AM

https://forums.swift.org/t/a-possible-vision-for-macros-in-swift/60900

A Possible Vision for Macros in Swift

Hey all, As Swift evolves, it gains new language features and capabilities. One of the ways in which it grows is via new syntactic sugar to eliminate common boilerplate, taking something that can be written out in long-form and making it more concise. Such features don't technically add any expressive power to the language, because you can alwa...

マジか

マクロ...

おおお

4:27 AM

SwiftSyntaxがSwift化したのもこれの布石だったりするのかな

4:28 AM

今までmacOSでしか使えなかったし

なるほど (edited)

We propose to introduce a macro system into Swift. At a very high level, macros can be explicitly triggered with syntax such as #stringify(x + y), subsuming a number of existing expressions that use similar syntax already (#line, #colorLiteral(...), etc.) with a general features. Macros can also be triggered more implicitly in response to type checking, e.g., applying a macro to the argument passed to a function. Macro arguments are type-checked so that tooling behaves similarly to today, but macro evaluation involves transforming the syntax so that it can serve a number of different use cases.

4:50 AM

面白そうな事書いてあるな

これはスッと受け入れられそうな気がする。CodableやPropertyWrapperみたいなより複雑な仕様が既にあるし、という感覚に私はなっている。

マクロの入力は自由なテキストではなく、syntaxが縛られていて、マクロ引数が型検査されるとある

4:54 AM

https://github.com/apple/swift-syntax/pull/969/files#diff-d9bc8d9c32b1536d8c5c8b23a3a51dc35f3d298aba421354695f6a335004b9de

4:54 AM

#stringify マクロの実装サンプル (edited)

4:55 AM

SwiftSyntaxの拡張ライブラリであるSwiftSyntaxMacrosパッケージのライブラリを使って引数としてSwiftSyntaxの MacroExpansionExprSyntax を受け取るんやな (edited)

#line の一般化もしてそう

1

マクロの実装本体を、

5:08 AM

ソースコードの中で書くんじゃなくて

5:09 AM

ライブラリの中でセマンティックなCST変換器として実装するのは

5:09 AM

結構珍しいアプローチな気がする？

Rustのproc_macroはちょっと似てる？

https://qiita.com/yagince/items/546d86588aaa3fdb3c94 proc_macro crateを使って、TokenStreamの変換関数を書くんだね、似ているな

[Rust] proc_macro入門 CustomDeriveを書いてみる - Qiita

davidpdrsn/juniper-eager-loading: Library for avoiding N+1 query bugs with Juniper ↑の実装を読んでいて、CustomDeriveってこうやって書くのか...

ただしproc_macroはRustとして不正なトークン列も受け付けられる

なるほど

5:14 AM

Swiftのアプローチのほうがより堅牢になるのかも？

かも

macro(contexts: [.expression], external: "MyMacros.Line") var line: Int { get } macro(contexts: [.expression, .parameter], external: "MyMacros.Stringify") func stringify<T>(_ value: T) -> (T, String)

マクロの型宣言　らしい

externalってなんだろ

public struct Stringify: ExpressionMacro, ParameterMacro { public static func apply( arguments: (String?, ExprSyntax)..., in context: MacroEvaluationContext ) -> (ExprSyntax, [Diagnostic]) { let node = arguments[0].1 return (##"(\(node), #"\(node.description)"#)"##, []) } }

6:16 AM

実装の名前

おおー、なるほど

protocol Cleanup { func cleanup() } macro(contexts: [.statement], external: "MyMacros.LocalCleanup") func localCleanup<Value: Cleanup>(_ varName: String, _ initializer: Value) --- #localCleanup("file", File(opening: "hello.txt")) --- let file = File(opening: "hello.txt") defer { file.cleanup() }

(edited)

6:19 AM

defer生み出せるの面白いな。moveonly typeがあれば要らないマクロですが・・・

6:22 AM

// In the standard library extension Equatable { macro(contexts: [.conformance], external: "MyMacros.EquatableSynthesis") static func ==(lhs: Self, rhs: Self) -> Bool } // In the macro definition library struct EquatableSynthesis: ConformanceMacro { public static func apply( conformingType: TypeDecl, protocol: ProtocolDecl, witness: FunctionDeclSyntax, in context: MacroEvaluationContext ) -> (FunctionDeclSyntax, [Diagnostic]) { let comparisons: [ExprSyntax] = conformingType.storedProperties.map { property in "lhs.\(property.name) == rhs.\(property.name)" } let comparisonExpr: ExprSyntax = comparisons.map { $0.description }.joined(separator: " && ") return witness.withBody( """ { return \(comparisonExpr) } """ ) } }

6:22 AM

この TypeDecl は今無いやつだ、めっちゃ欲しい

6:23 AM

無いので自作してるやつ

macro の宣言時には今までのようなプレフィックスがつかないんですね

2:39 PM

#macro だと実際に展開される側のものと紛らわしいのでないのは分かるんですが、何となく何かで囲われてないと違和感がある…

macro がそのprefixだと思います　カッコの中が長いからわかりづらいけどつなげれば macro static func の形になってます

1

もう使える記号がない

@swift-5.6.3

import Foundation enum Key: String, Codable { case a } let data1 = try JSONEncoder().encode([Key.a : 0]) print(String(data: data1, encoding: .utf8)!) let data2 = try JSONEncoder().encode([Key.a.rawValue : 0]) print(String(data: data2, encoding: .utf8)!)

t.ae

@swift-5.6.3

import Foundation enum Key: String, Codable { case a } let data1 = try JSONEncoder().encode([Key.a : 0]) print(String(data: data1, encoding: .utf8)!) let data2 = try JSONEncoder().encode([Key.a.rawValue : 0]) print(String(data: data2, encoding: .utf8)!)

["a",0] {"a":0}

前者はなんで’こうなるんでしょう？

8:37 AM

https://developer.apple.com/documentation/swift/dictionary/encode(to:) ふつうに書いてあった。

@swift-5.6.3

import Foundation enum Key: String, CodingKeyRepresentable, Codable { case a } let data1 = try JSONEncoder().encode([Key.a : 0]) print(String(data: data1, encoding: .utf8)!) let data2 = try JSONEncoder().encode([Key.a.rawValue : 0]) print(String(data: data2, encoding: .utf8)!)

Iceman

@swift-5.6.3

import Foundation enum Key: String, CodingKeyRepresentable, Codable { case a } let data1 = try JSONEncoder().encode([Key.a : 0]) print(String(data: data1, encoding: .utf8)!) let data2 = try JSONEncoder().encode([Key.a.rawValue : 0]) print(String(data: data2, encoding: .utf8)!)

{"a":0} {"a":0}

CodingKeyRepresentable もう使えますよ

便利そう

みたいですね。名前からぱっと分からなかったんですけどDictionaryのキーのための型なのかな？

https://github.com/apple/swift/blob/ae4ad5d0151928162a2494a5af1c20e9225c2ac4/stdlib/public/core/Codable.swift#L5631

8:44 AM

こんな感じで分岐してるんで、Dictionary用といってもいいでしょうね。

IntとStringしか辞書にならなかったのが、CodingKeyRepresentableでカスタム可能になったやつか。

CodingKeyRepresentable 、 15.4 以降なので微妙に使いづらいんですよね…

1

モバイルアプリだともうちょっとかかりそうですね

4:00 PM

Optional<Foo> 形式で書くと = nil によるデフォルト初期化が起きないらしい。

3

omochimetaru

Optional<Foo> 形式で書くと = nil によるデフォルト初期化が起きないらしい。

今はどうなったのかわからないですが，以前はそれのせいで T? だと二重初期化が起こるみたいな問題があったらしいですね．SwiftNIO とかはそれを避けるために全部 Optional<T> で書き直したりしてました． https://github.com/apple/swift/issues/54184

[SR-11777] 'var something: 'Type?' always get double initialised · ...

Previous ID SR-11777 Radar rdar://problem/57156726 Original Reporter @weissi Type Bug Status Resolved Resolution Done Attachment: Download Additional Detail from JIRA Votes 0 Component/s Compiler L...

kebo

今はどうなったのかわからないですが，以前はそれのせいで T? だと二重初期化が起こるみたいな問題があったらしいですね．SwiftNIO とかはそれを避けるために全部 Optional<T> で書き直したりしてました． https://github.com/apple/swift/issues/54184

ええ〜。その書き換えは大変だ・・・

https://forums.swift.org/t/pitch-if-and-switch-expressions/61149 ifとswitchが式になる、これはできるだけ早く採用されてほしい。

[Pitch] if and switch expressions

Hey all, an early-stage pitch for this feature. No implementation quite yet but hopefully not too far off. if and switch expressions This proposal introduces the ability to use if and switch statements as expressions, for the purpose of: Returning values from functions, properties, and closures; Assigning values to variables; and Declaring v...

これかなり前から文指向だからやらないよって言ってたやつですねえ最近そういうのが多いな ( if let foo { とか ) 割とコアチームの意見というよりクリスラトナーの意見って感じだったのかなあと思う

11:20 PM

文法がややこしくなって曖昧なケースとか生じそうなのとか、breakとの併用とかどうなるのとか思うけど、提案の通り func の return 省略と同じで 1文に限るとか、いろいろ制約いれてけば無難に導入できるんかな。

へえ、やらない一覧に入ってたやつもこれから変わってくんですかね。

そんな気がしますねえ

11:51 PM

この前のマクロのピッチもそういうやつですねまあマクロは、十分材料出尽くしたら検討してもいい、ぐらいの余地はありましたけど

https://github.com/apple/swift-evolution/blob/main/commonly_proposed.md#control-flow-closures-optional-binding-and-error-handling これか。確かによほどじゃないと採用されないリストにあるね。

swift-evolution/commonly_proposed.md at main · apple/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/commonly_proposed.md at main · apple/swift-evolution

if/else and switch as expressions: These are conceptually interesting things to support, but many of the problems solved by making these into expressions are already solved in Swift in other ways. Making them expressions introduces significant tradeoffs, and on balance, we haven't found a design that is clearly better than what we have so far.

11:57 PM

ここに書いてあるからには significant tradeoffs について言及されてほしいな・・・導入は別に良いと思うけど

せやな。どんなトレードオフがあるんだろう。ユーザーじゃなくてコンパイラかな。

たしかに型推論は難しくなるけど、もうすでにResult Builderで同等のものが入ってるから、問題ないはずですね。Result Builderのときにone-way constraintが発明されたから、そういう意味ではそこは技術進歩で解決してる。

うーん、値型＆ミュータブルの世界には文指向がマッチしてると思うんだけどなぁ。

その辺がトレードオフってやつなのかな。

2:46 AM

私は単純にスッキリ書ける場面が増えて実用的だと思ってますけど、どの辺が困る感じですか？

困るわけじゃないんですけどねー。過剰に式で書かれることにならないかなぁと。

2:49 AM

var に入れて if で分岐して変更すればいいものが、無理やり let にしようとして巨大な if 式で書かれたりとか。

2:50 AM

まず var を使うことを受け入れるのが Swift の第一歩だと思うんですよね。

var は下までずっとスコープが伸びるのがちょっと抵抗ありますけど、move が来ればそれもなくなるからなぁ

Iceman

var は下までずっとスコープが伸びるのがちょっと抵抗ありますけど、move が来ればそれもなくなるからなぁ

確かにそうですね。あまり長いスコープを作るの自体が良くないのかもしれませんが。

まず var を使うことを受け入れるのが Swift の第一歩

あ、なるほど。読み違えてた。値型＆「ミュータブル」か。

2:56 AM

なるほどねえ。値型ならイミュータブルに固執しなくても、ということなんですね。でif/switch式はそれに逆行するんじゃないか、と。

2:57 AM

if/switch式が使えてしまうと、無理にletにしようとする力が働いてしまう、、と。

値型ならイミュータブルに固執しなくても

var が直接ミュータブルに結びついているわけではなくて、値型はミュータブルでもイミュータブルクラスと同等なので、標準ライブラリでも mutating func がいっぱい使われているし、無理して let にこだわる必要はないよということですね。

2:59 AM

Each branch of the if, or each case of the switch, must be a single expression.

これがあるからそんなに長大な if 式が作られたりはしないかなぁ。

クロージャが中に書かれそうだな。

3:01 AM

って考えるとif式の中は複数行書けた方がいいんじゃないかな。

3:02 AM

いや、わからん。

↓こんなの生まれそうですよね

let foo = if isBar { { ... }() } else { Foo(...) } (edited)

書きそう。さらに三項演算子を使ったり。。。

Alternatives Considered and Future Directions Sticking with the Status Quo The list of commonly rejected proposals includes the subject of this proposal:

if/else and switch as expressions: These are conceptually interesting things to support, but many of the problems solved by making these into expressions are already solved in Swift in other ways. Making them expressions introduces significant tradeoffs, and on balance, we haven't found a design that is clearly better than what we have so far.

The motivation section above outlines why the alternatives that exist today fall short. One of the reasons this proposal is narrow in scope is to bring the majority of value while avoiding resolving some of these more difficult trade-offs. The lack of this feature puts Swift's claim to be a modern programming language under some strain. It is one of the few modern languages (Go being the other notable exception) not to support something along these lines.

1. 状況を限定することでtradeoffを避けました 2. 他の子はみんなやってる

{} の中が single expression に限定されてしまうのが Swift と相性悪そう。イニシャライザで初期化終わらず var にして後から変更加えるやつとか結構いる気が。 URLRequest とか。

4

5.7からこれで書けるの何でだろ extension String? {}

SE-0361が入ったからです https://github.com/apple/swift-evolution/blob/main/proposals/0361-bound-generic-extensions.md

swift-evolution/0361-bound-generic-extensions.md at main · apple/sw...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0361-bound-generic-extensions.md at main · apple/swift-evolution

1

let foo: Int switch condition { case pattern: foo = 0 ... default: return // early return }

6:23 AM

これを

6:23 AM

let foo = switch condition { case pattern: 0 ... default: return // early return }

6:24 AM

こう書けたりするのだろうか

6:24 AM

後者はリッチなガード文として嬉しい反面、分かりづらそう…

An exception to this rule is if a branch either returns, throws, or traps, in which case no value for the overall expression need be produced.

例外として、もし分岐がreturnやthrowsをしている場合は式の値を用意しなくて良いとあるんで、returnになってる分岐もアリみたいですね、かけそう。

8:25 PM

guard let foo = switch condition { case pattern: 0 ... default: nil } else { return } こう書いたほうがguardであることが表明できるけど、ちょっと行が増えちゃいますね (edited)

returnやthrowの値をNeverにしたら解決するヤツだったりしない？ (edited)

それやると let a = 1 + return とかも認められる事になるので話が広がってそう

挙げたのは値なしの return だったけど、switch 式としての型と関数の返り値の型が同じだとバグを埋め込みそうで怖いですね

https://github.com/hborla/swift-evolution/blob/variadic-generics-vision/vision-documents/variadic-generics.md

swift-evolution/variadic-generics.md at variadic-generics-vision · ...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/variadic-generics.md at variadic-generics-vision · hborla/swift-evolution

1:30 PM

ホーリーさんの可変長ジェネリクスのビジョン文書小さめなマニフェストって感じだ

1:31 PM

この前のピッチだと長さは固定だったけど、こっちだと<First, Rest…>による長さのマイナス1計算の話が増えてるかな

@main struct Main { static func main() { testPowerAssert() } static func testPowerAssert() { let a = 4 let b = 7 let c = 12 #powerAssert(max(a, b) == c) #powerAssert(a + b > c) struct Person { let name: String let age: Int var isTeenager: Bool { return age <= 12 && age >= 20 } } let john = Person(name: "John", age: 42) let mike = Person(name: "Mike", age: 13) #powerAssert(john.isTeenager) #powerAssert(mike.isTeenager && john.age < mike.age) } }

^ こんなマクロを書くと (edited)

11:40 AM

@main struct Main { static func main() { testPowerAssert() } static func testPowerAssert() { let a = 4 let b = 7 let c = 12 PowerAssert.Assertion("#powerAssert(max(a, b) == c)", line: 12, verbose: true).assert(max(a, b) == c).record(expression: max(a, b), column: 13).record(expression: a, column: 17).record(expression: b, column: 20).record(expression: max(a, b) == c, column: 23).record(expression: c, column: 26).render() PowerAssert.Assertion("#powerAssert(a + b > c)", line: 13, verbose: true).assert(a + b > c).record(expression: a, column: 13).record(expression: b, column: 17).record(expression: a + b > c, column: 19).record(expression: c, column: 21).render() struct Person { let name: String let age: Int var isTeenager: Bool { return age <= 12 && age >= 20 } } let john = Person(name: "John", age: 42) let mike = Person(name: "Mike", age: 13) PowerAssert.Assertion("#powerAssert(john.isTeenager)", line: 27, verbose: true).assert(john.isTeenager).record(expression: john.isTeenager, column: 18).record(expression: john, column: 13).render() PowerAssert.Assertion("#powerAssert(mike.isTeenager && john.age < mike.age)", line: 28, verbose: true).assert(mike.isTeenager && john.age < mike.age).record(expression: mike.isTeenager, column: 18).record(expression: mike, column: 13).record(expression: john.age, column: 37).record(expression: john, column: 32).record(expression: mike.isTeenager && john.age < mike.age, column: 41).record(expression: mike.age, column: 48).record(expression: mike, column: 43).render() } }

^ こういうコードに展開されて、

11:41 AM

#powerAssert(max(a, b) == c) | | | | | 7 4 7 | 12 false #powerAssert(a + b > c) | | | | 4 7 | 12 false #powerAssert(john.isTeenager) | | | false Person(name: "John", age: 42) #powerAssert(mike.isTeenager && john.age < mike.age) | | | | | | | | false | 42 | | 13 | | | Person(name: "Mike", age: 13) | | false | Person(name: "John", age: 42) Person(name: "Mike", age: 13)

^ このような結果が得られる。

11:41 AM

というのがなんとなくできた。 https://github.com/kishikawakatsumi/swift-syntax/commit/dc962129da32c5ebbbb6719fe35838568515e45f (edited)

Implement proof of concept for power assert · kishikawakatsumi/swif...

1

マクロの使い方としてめっちゃ良いユースケースですね

ですよね。SwiftのマクロがAST => AST’っていう仕組みになってるからうまくハマる。

11:49 AM

強いていうならASTがもうちょっとリッチだと嬉しい。

11:50 AM

もうちょいいろいろなケースに対応したらフォーラムのスレッドに書いてみようと思う。

良いですね　キャッチーだと思う

a + b > c これが [a, +, b, > c] みたいなASTの構造になるとかがちょっと辛い。左辺と右辺、のような概念がほしい。

演算子の結合を考慮したツリーじゃなくて配列なのが不便ッテ意味ですか？ (edited)

そうですね。 > のparentを取っても + のparentを取っても a + b > c になってしまうのが使いにくい。

https://github.com/apple/swift-syntax/pull/619/files#diff-5cba4532795f1481f3c0ba6284381df92d0ce80eb1c315a8c83edf7c4515a36f

Introduce a library to handle user-defined operators by DougGregor ...

Introduce a library that implements the semantics of Swift user-defined operators and precedence groups. The primary operation is a "fold", which takes a sequence expression (i.e....

+ のparentが a + b になるか、 +, < の左辺と右辺が取れる、みたいなのが欲しい。

これ使えばツリー化してくれるっぽいですよ

ありがとう。やってみる。

https://github.com/apple/swift-syntax/blob/main/Sources/SwiftOperators/SwiftOperators.docc/SwiftOperators.md

11:57 AM

マニュアルはこれかな。

ざっと検索したときに見たんだけどuser-definedだから違うかなと思ってしまった。

マクロいろんな可能性があっていいですね

stdlibの基本オペレータの定義は組み込みで入ってるみたいですね。

import SwiftSyntax import SwiftParser import SwiftOperators var opPrecedence = OperatorTable.standardOperators // Use the Swift standard library operators let parsed = Parser.parse(source: "x + y * z") dump(parsed) // contains SequenceExprSyntax(x, +, y, *, z) let folded = try opPrecedence.foldAll(parsed) dump(folded) // contains InfixOperatorExpr(x, +, InfixOperatorExpr(y, *, z))

(edited)

OperatorTable.standardOperators これがStdLibのためのやつか

1

a + b > c ▿ ExprListSyntax ▿ IdentifierExprSyntax - unexpectedBeforeIdentifier: nil ▿ identifier: identifier("a") - text: "a" ▿ leadingTrivia: [] - pieces: 0 elements ▿ trailingTrivia: spaces(1) ▿ pieces: 1 element ▿ spaces(1) - spaces: 1 ▿ tokenKind: SwiftSyntax.TokenKind.identifier - identifier: "a" - unexpectedBetweenIdentifierAndDeclNameArguments: nil - declNameArguments: nil - unexpectedAfterDeclNameArguments: nil ▿ BinaryOperatorExprSyntax - unexpectedBeforeOperatorToken: nil ▿ operatorToken: spacedBinaryOperator("+") - text: "+" ▿ leadingTrivia: [] - pieces: 0 elements ▿ trailingTrivia: spaces(1) ▿ pieces: 1 element ▿ spaces(1) - spaces: 1 ▿ tokenKind: SwiftSyntax.TokenKind.spacedBinaryOperator - spacedBinaryOperator: "+" - unexpectedAfterOperatorToken: nil ▿ IdentifierExprSyntax - unexpectedBeforeIdentifier: nil ▿ identifier: identifier("b") - text: "b" ▿ leadingTrivia: [] - pieces: 0 elements ▿ trailingTrivia: spaces(1) ▿ pieces: 1 element ▿ spaces(1) - spaces: 1 ▿ tokenKind: SwiftSyntax.TokenKind.identifier - identifier: "b" - unexpectedBetweenIdentifierAndDeclNameArguments: nil - declNameArguments: nil - unexpectedAfterDeclNameArguments: nil ▿ BinaryOperatorExprSyntax - unexpectedBeforeOperatorToken: nil ▿ operatorToken: spacedBinaryOperator(">") - text: ">" ▿ leadingTrivia: [] - pieces: 0 elements ▿ trailingTrivia: spaces(1) ▿ pieces: 1 element ▿ spaces(1) - spaces: 1 ▿ tokenKind: SwiftSyntax.TokenKind.spacedBinaryOperator - spacedBinaryOperator: ">" - unexpectedAfterOperatorToken: nil ▿ IdentifierExprSyntax - unexpectedBeforeIdentifier: nil ▿ identifier: identifier("c") - text: "c" ▿ leadingTrivia: [] - pieces: 0 elements ▿ trailingTrivia: [] - pieces: 0 elements ▿ tokenKind: SwiftSyntax.TokenKind.identifier - identifier: "c" - unexpectedBetweenIdentifierAndDeclNameArguments: nil - declNameArguments: nil - unexpectedAfterDeclNameArguments: nil

変わってないように見えるな。。。何か間違ってるのかしら。

12:09 PM

ドキュメントのコードをそのままやってみよ。

できそう。 SwiftParserから返ってきたSyntaxじゃないと期待どおり動かないっぽい。ASTの構造が違うのかな。

1

シンプルに#assertにしたかったけど、それはどうもSwiftSyntaxが予約してるか何かに使用してるっぽい。

Forumに書いた。 https://forums.swift.org/t/a-possible-vision-for-macros-in-swift/60900/87

A Possible Vision for Macros in Swift

The idea of AST to AST transformation by macro is excellent. It has very great potential. I want to show one practical example. I have created a proof of concept for the Power Assert library using currently publicly available code. If you write a macro like the following: let a = 4 let b = 7 let c = 12 #powerAssert(max(a, b) == c) #powerAsser...

2

マクロって仕組み的にそのファイル外の情報（型定義とかモジュール名とか）もとれるようになってるんですかね？

MacroEvaluationContextにモジュール名は渡ってきそうな雰囲気がありますね（今のところ動作環境が専用のCLI経由しかないので固定の文字列）。それ以外は少なくとも議論を読んでる限り最初のうちはないんじゃないかな。ただ自力で読むことはたぶんできる。コンパイラが読める範囲のものは全部読めるだろうし。

なるほど。基本はSwiftSyntaxを裏で使った結果が渡ってくるものとイメージしました。

そうですね。 #colorLiteral(red: 0.5, green: 0.5, blue: 0.25, alpha: 1.0) このマクロでいうと、このマクロをParseした結果のSyntaxとContextが渡されるのでマクロを実装する人はargumentListなどをみていって、最終的にマクロを置換する文字列を返す、となります。

コンパイラが読める範囲のものは全部読める

インターフェースとしては ExpressionMacro に渡ってくるのは部分CSTなのと MacroEvaluationContext も外側の情報は渡してこないように見える。 CompilerPluginみたいな感じで、sand-box下で実行されて、外側のソースは読めないっていう仕様への着地もありえる気がします。 (edited)

7:18 PM

実際、純粋なコード加工なら部分CSTだけで良いはずで、周りの型情報とか他の部分のソース情報も読み取るとなると、マクロの実行結果が局所的な情報だけで決定しなくなるという事なんで

7:19 PM

そのほうが高機能ではあるが、ユーザーにとってはマクロ展開結果の予測しづらい変動や不具合の原因にもなりえるので難しくなりうる

確かにそういう制限付きになることもありえるね。既存の＃始まりの言語仕様を置き換える、って話があるから #function が実装できる外側のfunctionまでの構造が渡される、っていうのが一番厳しい制限かなあ。

#function なるほど確かに。多少外側の情報が必要ですね。 (edited)

まあしかしコンパイラと同じ権限で動く、っていうのはちょっと楽観的すぎる見通しな気がしてきました。

そのへんの仕様によってビルドパイプラインにおいてキャッシュに影響を与える範囲とかも変わってくるんですよねえ

毎回結果が変わるマクロがあったらどうすんねん（#timestampみたいな）、ってのも議論にあったな。どういう話に進んだのか思い出せないけど。

うわあ、なるほど。それめんどくさいな・・・ (edited)

まさに毎回フルビルドになるのか、みたいな懸念が書いてあったと思う。

https://github.com/apple/swift/blob/2fc16373b32a335f8e0f74f0289bae6f217e4ce9/include/swift/Option/Options.td#L1721-L1726 マクロを使う手段はまだない、って書いたけど実はもうコンパイラに入っててフラグ指定したら使えるのかしら？

swift/Options.td at 2fc16373b32a335f8e0f74f0289bae6f217e4ce9 · appl...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

どうなんだろう　そうだとしたら、なにかテストケースがどっかにありそう

https://github.com/apple/swift/blob/92d970497ec165aef541ed032fcdac4abd578e55/test/Macros/macros.swift これかなあ。

swift/macros.swift at 92d970497ec165aef541ed032fcdac4abd578e55 · ap...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

https://github.com/apple/swift/blob/92d970497ec165aef541ed032fcdac4abd578e55/test/Macros/Inputs/macro_definition.swift なんかやれてそうですね

swift/macro_definition.swift at 92d970497ec165aef541ed032fcdac4abd5...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

9:36 PM

// RUN: %target-swift-frontend -enable-experimental-feature Macros -dump-ast %s -module-name MacrosTest 2>&1 | %FileCheck %s

9:36 PM

-enable-experimental-feature Macros これで有効化していそうだけど、定義したプラグインを読み込ませている箇所が見当たらないなあ

9:37 PM

struct StringifyMacro: _CompilerPlugin { static func _name() -> (UnsafePointer<UInt8>, count: Int) { var name = "customStringify"

名前が stringify じゃない・・・

9:38 PM

// RUN: %empty-directory(%t) // RUN: %target-build-swift -Xfrontend -disable-availability-checking -I%platform-module-dir/../.. -L%platform-dylib-dir/../.. -emit-library -emit-library-path=%t/%target-library-name(MacroDefinition) -working-directory=%t -module-name=MacroDefinition %S/Inputs/macro_definition.swift // RUN: %target-swift-frontend -L%platform-dylib-dir/../.. -enable-experimental-feature Macros -load-plugin-library %t/%target-library-name(MacroDefinition) -disable-availability-checking -dump-ast -primary-file %s | %FileCheck %s

お、こっちはそれっぽいですね

9:38 PM

https://github.com/apple/swift/blob/92d970497ec165aef541ed032fcdac4abd578e55/test/Macros/macro_plugin.swift

9:38 PM

Inputs/macro_definition.swift を MacroDefinition モジュールとしてビルドして

9:39 PM

次のコマンドでさっきみつけた -load-plugin-library で、 MacroDefinition を読み込ませている

9:39 PM

同じようにやったら動きそう

9:39 PM

あーわかった https://github.com/apple/swift/blob/92d970497ec165aef541ed032fcdac4abd578e55/test/Macros/macros.swift こっちのテストケースは -dump-ast なんで

9:40 PM

#stringify をパースさせているだけだ。 stringify は実際には提供されていない。パースから先は動かないんだと思う。

なるほど。ありがとう。やってみる。

いや、macro_plugin.swift も -dump-ast してるだけだな・・・

9:41 PM

https://github.com/apple/swift/blob/92d970497ec165aef541ed032fcdac4abd578e55/test/Macros/macro_plugin_exec.swift

9:41 PM

macro_plugin_exec.swift は、 -o で実行ファイル作って、実行していますね

9:41 PM

いけそう。

今はダイレクトにAST変換をするんじゃなくていったんファイルにソースコードの形にするわけね。

　 // RUN: %target-build-swift -Xfrontend -disable-availability-checking -I%platform-module-dir/../.. -L%platform-dylib-dir/../.. -emit-library -emit-library-path=%t/%target-library-name(MacroDefinition) -working-directory=%t -module-name=MacroDefinition %S/Inputs/macro_definition.swift // RUN: %target-build-swift -L%platform-module-dir/../.. -enable-experimental-feature Macros -load-plugin-library %t/%target-library-name(MacroDefinition) %s -o %t/main // RUN: %target-run %t/main

(edited)

いや、ファイルになるのは実行形式だけか

ダイレクトにビルドまでいけてそうです

そうだね

9:45 PM

そうすると実は一般に機能を解放するかどうかが論点か。

あとはまあSwiftPMが対応してくれないとこのままだとコマンドラインでコンパイルする使い方しかできないから一般利用は厳しいですね

9:47 PM

うーん、 #stringify のテストがなんで通るんだろう・・・ -dump-ast はたしか型チェックするから、どっかで定義されてないとダメそうなんだけど

マクロの提供はパッケージ単位になるだろうしねえ。

MODES: -dump-ast Parse and type-check input file(s) and dump AST(s) -dump-parse Parse input file(s) and dump AST(s)

SwiftSyntaxの方に実体があるんじゃないの？

https://github.com/apple/swift-syntax/blob/3b7d3ad1afccd53f1e2aaeb1b22437910f80fd2e/Sources/_SwiftSyntaxMacros/MacroSystem%2BExamples.swift

9:50 PM

これが固定で読み込まれてるんかな？

動かしてみないとわからんな。

https://forums.swift.org/t/pitch-expression-macros/61499 改めてPitchとProposalが投稿された。まだコンパイラ本体で試すのは難しいっぽい。 (edited)

[Pitch] Expression macros

Hey all, Following up on the vision for macros from last month, here is a pitch for expression macros. Expression macros are used as expressions in the source code (marked with #) and are expanded into other expressions. Expression macros can have parameters and a result type, much like a function, which describes the effect of the macro expan...

createUniqueLocalName() は gensym だな。（マクロが新しい変数や関数を定義する場合、既存のコードと衝突しない名前を自動的に作ってくれる。）

8:18 AM

TrackingやLoggingをFunction単位で差し込めるようなAspect Oriented Programmingを実現できるような機能はいったん見送りかな？ (edited)

8:21 AM

マクロは引数と戻り値が型チェックされて、型があってても失敗するような引数が来た場合はエラー情報を返せるインターフェースがある、具体的になったのはそれくらいかな？

考えてみればマクロは関数みたいな感じだから，型とか関数を丸ごと作るとかはできなさそうだ

6:15 AM

コード生成の需要はまだまだ続きそうやな (edited)

そうですねえ。いくつかのコード生成はマクロに置き換えられると思いますけど今のところ全部マクロで、みたいなのはまだまだ先っぽい。

#init みたいなのなかったですっけ

たしかにsyntaxのテストケースでは見た

8:57 AM

けど提案書の仕様にはハマらないようにみえる

#init 需要ありそうだけどな〜残念ですね

あーわかった

9:03 AM

vision documentのほうにはこういうのも書いてある

9:03 AM

// In the standard library macro(contexts: [.memberDeclaration], external: "MyMacros.MemberwiseInit") func memberwiseInit(access: Access = .public)

9:03 AM

今回のピッチはあくまで expression macro だから

9:03 AM

// In library macro(contexts: [.expression], external: "MyMacros.ColorLiteral") func colorLiteral(red: Double, green: Double, blue: Double, alpha: Double) -> _ColorLiteralType

9:04 AM

expressionの出てくるところでexpressionとして展開される限定のマクロなんだ

9:04 AM

少しずつ仕様をまとめていくつもりなんだな

9:05 AM

2023年にやりたい事リストにはマクロも書いてあるから、来年ちょっとずつ進んでいくんだろう。

9:05 AM

https://www.swift.org/blog/focus-areas-2023/

Swift project in 2023

There’s a lot of exciting work going on in the Swift project, and it’s hard to keep track of it all because it’s happening in many different repositories, pull requests, and forum threads. To give the community a better view of the big picture, the Core Team surveyed workgroups and developers across the project and collected information about wh...

Proposalには出てこなかったからちょっとずつやってくんでしょうね。

9:06 AM

ただマクロはVisionの時点で導入自体に対する反対意見も結構あったから入ることは既定路線みたいな感じになってるのは驚いた。

そうですね。いつのまにやら方向性が変わってきた。

9:08 AM

何が背景にあるんでしょうね。 Swift compiler内部では、結構pythonとかCプリプロセッサを使ったコード生成が多用されているので、Swiftコンパイラのセルフホストが内部的に大テーマとして決まってて、 C++ interoperabilityと合わせて考えると、コンパイラ実装するならマクロ必要だよね、という感じかなあ？

9:10 AM

SwiftUIみたいなユーザー向けフレームワークでAppleが出すもので、ってパターンには内容的に違いそうだし

マクロを書くにはSwiftSyntaxをもうちょいラップした何かが欲しいな。SwiftSyntaxで返ってくるのはちょっと冗長すぎるのでもうちょい高レベルな構造で返ってくるのが欲しい。。。といってもほとんどの簡単なマクロを書くにはいらないと思うけど。

https://github.com/omochi/SwiftTypeReader

GitHub - omochi/SwiftTypeReader: You can gather type definitions fr...

You can gather type definitions from Swift source code. - GitHub - omochi/SwiftTypeReader: You can gather type definitions from Swift source code.

9:14 AM

まさにそのためにこれを作ってる (edited)

なるほど確かに！

9:15 AM

これは来年大ヒットしそうだな。

マクロ文明が花開いてそこらじゅう黒魔術だらけになったらウケるな。 (edited)

単なる関数でいいものをマクロにする、とかはありそう。

そういうのもちょっと起きそうですよね。やりたいことを言語機能でやるよりコード展開で考えるほうがすぐにやり方が思いついたので・・・みたいな。

なんかいいアイデアあるかなっていろいろ考えたときにだいたい関数にまとめるだけのほうがいいよねって自分ではなった。

It is intended that MacroEvaluationContext will grow over time to include more information about the build environment in which the macro is being expanded. For example, information about the target platform (such as OS, architecture, and deployment version) and any compile-time definitions passed via -D, should be included as part of the context.

ちょっと改訂された。MacroEvaluationContextにはビルド設定とかプラットフォームの情報とか入ってくる予定らしい。 https://github.com/DougGregor/swift-evolution/commit/d101cff73398386b471798b750d6f89798721211 (edited)

Note that MacroEvaluationContext will grow to include build environ...

…nt stuff

おお。

compile-time definitions passed via -Dが取れるのはなんか応用範囲が広そうな気がする。

初めまして、質問よろしいでしょうか？特定の「View」以外の場所をタップした時に処理を実行したいのですが、その様な事はできるのでしょうか？調べても出てこなかったので、もしできる様でしたら誰かわかる方ご教授頂きたいです。

UIKit前提で言うと、「XX以外の場所をタップした」というイベントを取る方法は無いと思います。特殊な方法はあるかもしれないけど。自分だったらそういう場合は、「XX以外の場所」に該当する部分に、見えないボタンとかTap Gesture Recognizerを仕込んでおいて、タッチイベントを検出するように作ります。 (edited)

7:49 AM

画面全体の領域を持ってる親ビュー側のhit testを改造して、子にタッチが到達する前に何をタッチしてるか判定する、みたいなパターンもやる事があります。

やりたいUIパターンはUIPopoverController辺りが近そうな気がするので、公式のドキュメントやexampleを見ても良いかと思います

なるほど、お二人ともありがとうございます。実は「containerView」をタップした際に反応して欲しかったんですけど、それをやると「presentedView」をタップした時にも反応してしまうので、「presentedView」以外をタップした時に

8:22 AM

反応するってのがあればそれでどうにかしようとしてたんですけど、そんなものは無さそうですね。

8:25 AM

素直に背景としてもう一つViewをつけてそれをタップした時に反応する様に書いてみます。そんなイベント判定はないってのも勉強になりました。ありがとうございます

‍♂️

Swiftのマクロ、ファイルが読めるならバイナリをソースコードに埋め込む、っていうのできそうだけどファイル読めるかなあ。

全然関係ないですけど次のCにもそういうマクロが入るっぽい https://yohhoy.hatenadiary.jp/entry/20220915/p1

ファイルをコードに埋めちゃうのってプロセスの実行モデル的に効率悪い事があったりしないのだろうかワンファイル実行ファイルにできてデプロイしやすいとか、そういうメリットはあるけど

もしSwiftでインラインアセンブリが書ければ、アセンブリの機能にincbinというのがあって、アセンブラがファイル読んで埋め込んでくれる

お、 #embed 偶然作るならそういう名前かなと考えてたのと一緒だ

12:32 PM

主にコマンドラインツール作るとき用かな。

12:33 PM

バンドルを持てない、持てなくはないけど手間が異様に増えるやつ。

バンドルあると配布がすごい面倒くさいですよね

然り。作者も利用者もどっちも大変。

なるほど

MintやSwiftPMでいいやんみたいな話もあるけど。

12:35 PM

（私はMintやSwiftPMでやるのそんな便利と思ってない。）

バイナリ配布じゃないと壊れそうですね→swiftpm

Cの例にあるけど今だったらシェーダとかMLのモデルを埋め込む、みたいな需要もあるのかしら。CLIツールに。

しかしファイルを読めてしまうということは、ビルドシステムに読み込むファイルが依存物であることを伝えないといけないので大変だ

12:38 PM

プラグインでそういうのはできるんですかね

ファイルが読めたらこういうことができて嬉しい、ってことで聞いて（お願い）みよう。

例によってsandbox execされてて見えなそう

プラグインはLintのプラグインとかあるからできるんじゃないかな。

12:38 PM

できない？

ああ、コマンドプラグインは見えますね

12:39 PM

書き込みするときは、権限取得するやつがでる

12:39 PM

ユーザーがyesって打つやつ

12:39 PM

読み込みはフリー

まあ確かに読み込みのみにするとか、パーミッションが必要とか妥協点はありそう。

Dartにもマクロの提案があるらしい。はやりなんかな。Dartのマクロはパッと見てJavaのアノテーションぽい気もする。 https://github.com/dart-lang/language/tree/master/working/macros

language/working/macros at master · dart-lang/language

Design of the Dart language. Contribute to dart-lang/language development by creating an account on GitHub.

Dartも欲しそうですねマクロ

6:24 AM

@freezedっていうコード生成ツールがデファクトになってそうだけど、やっぱり公式で欲しいと思う

6:27 AM

kaptみたいにリフレクションっぽいAPIでメタタイプからフィールドやメソッドを引っ張り出せるようになってる？

なんか見た目も動きの説明もJavaのアノテーションっぽいですよね。

ぽいですよね。マクロというよりアノテーションプロセッサー的な印象

https://forums.swift.org/t/pitch-2-expression-macros/61861

https://forums.swift.org/t/pitch-2-expression-macros/61861

Hi all, Based on discussion in the first pitch of expression macros, I've revised the proposal. The updated proposal is here. Changes include: Rename MacroEvaluationContext to MacroExpansionContext. Remove MacroResult and instead allow macros to emit diagnostics via the macro expansion context. Remove sourceLocationConverter from the macro e...

5:56 PM

expression macroのプロポーザルが更新された提案書の中で岸川さんのpower assertがサンプルとして掲載されてる (edited)

5:57 PM

swiftpmでマクロパッケージを定義する書き方なども言及が入った

func type(of node: ExprSyntax) -> Type? マクロの型情報の話あるけどこのへんは将来の拡張予定って扱いっぽいな。

6:09 PM

アスペクト指向的なすべての関数に適用、みたいなのも後回しって書いてあるのかな。

本当だ，future directionの章に型情報の取得についての議論が書いてありますね

6:19 PM

まさに書いてある通りで、型情報をユーザーに渡そうとすると、コンパイラ内部のデータ構造を安定化させてAPIを整理しないといけないから大仕事なのはそうだと思います自力で同じ事をやってるのでわかる・・・

func type(of node: ExprSyntax) -> Type? しかしこれは完璧に求めていたものって感じですごい。 (edited)

そうですね。

さすがに導入はもう決定でいいのかな。Pitch1にも反対意見はなかったように見えるし。

大筋は既定路線でしょうねー

6:25 PM

形式的にはSEやるはずだけど、例の如く、ご意見募集であって投票ではないので。 (edited)

Hi all, Based on discussion in the first pitch of expression macros, I've revised the proposal. The updated proposal is here. Changes include: Rename MacroEvaluationContext to MacroExpansionContext. Remove MacroResult and instead allow macros to emit diagnostics via the macro expansion context. Remove sourceLocationConverter from the macro e...

6:52 PM

if式のレビュー始まった！

返り値と代入時に限定してる。

https://forums.swift.org/t/se-0380-if-and-switch-expressions/61899 if式のURLはこっちすね。

SE-0380: if and switch expressions

Hello, Swift community! The review of SE-0380: if and switch expressions begins now and runs through December 21st, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager by email or DM. Whe...

1

なんかぶっ壊れそうで漠然と怖いんだけど大丈夫なんかな笑

existentialとgenericsの一級化が済んでるから、結構良い感じになると思ってる。昔やったらAny祭りだったがw

あーそれが効いてくるのか。いいね。

let view = if foo { Image(...) } else { Text(...) } これでviewがany Viewになってくれると最高

その場合はview: any Viewがいりそう

3:40 AM

推論が完全な双方向にはしないって書いてある

流石に無理か

3:40 AM

解釈可能な最大の型を指定してくれたら嬉しかったが、計算時間が足りないか

// invalid: let x = if p { nil } else { 2.0 } // valid with required type context: let x: Double? = if p { nil } else { 2.0 } (edited)

なるほどね

推論からexistentialを解く挙動って多分今もどこにもないんよね

実際無理なんじゃないかと思ってる

3:42 AM

計算量的に

まあ候補めちゃめちゃあるしね

3:43 AM

any CustomStringConvertible とか通りすぎて逆に不便になりそう

最大値取れないと価値は無いっすね

3:44 AM

あと、それするにしても、existential/genericsに、普遍的な縛りを明示できるようになってからだろう、というのもある

3:44 AM

any Sequence<.Element=Int> みたいなやつ

any Sequence<Int> はもうできるんじゃないですか？ primary associatedtype に限らずって話？

あ、もう出来るのか。

5:09 AM

ただ、最大を指定できるようにするとどうしても、それより大きな範囲で出来る必要がありそうです

@swift-5.7.3 let numbers: any Sequence<Int> = [2, 3, 5] print(numbers.reduce(0, +))

koher

@swift-5.7.3 let numbers: any Sequence<Int> = [2, 3, 5] print(numbers.reduce(0, +))

10

自動で共通のスーパータイプを見つけてくると、意図せず Any になっちゃったりして難しいかもですね。あと、 any View の場合は self conformance 問題って解決されたんでしたっけ？まあ、 View は結局 ViewBuilder で組み立てるから if 式使う必要なさそうですが。

解決が何を指すかですが existential は self conform しないし、させる方法も今は無いです

5:15 AM

protocol P: Equatable {} struct S: Equatable { var a: any P } ↑これが通せないのでめっちゃ不便だということを最近気づきました

「解決」は、前に話してた any View で AnyView を代替できるようになるには、 self conformance がないとダメだって問題が解決したか。

koher

「解決」は、前に話してた any View で AnyView を代替できるようになるには、 self conformance がないとダメだって問題が解決したか。

してない！

self conformanceないと結構不便な場面あるよね・・・

マクロでコマンドプラグインと同等のパーミッションみたいな仕組みでファイルにアクセスしたい、っていうのを聞いてみたよ。 https://forums.swift.org/t/pitch-2-expression-macros/61861/9 (edited)

https://forums.swift.org/t/pitch-custom-metadata-attributes/62016

I am considering using macros to embed binaries into Swift source code. EXAMPLE: let data = #embed("images/icon.png") // ^ This macro will generate the code below. let data = Data([0x4d, 0x49, 0x54, ..., 0x65, 0x6e, 0x73]) Similar to the #embed macro in C23. This would be useful for applications that do not have bundles, such as command-lin...

1

Yes, I consider this a natural extension to the proposal, and probably one of the first ones we should do. I think it'll need both SwiftPM manifest file changes and new API in MacroExpansionContext.

マクロからファイルアクセスの計画はあるみたい。

The MacroExpansionContext isn't going to directly touch the file system---it's going to ask the compiler/SourceKit (whomever it is talking to) to give it the contents of the file as a buffer.

ファイルシステムにマクロ処理系がアクセスするのではなくて、構文木と同様にシステム（コンパイラ？）からバッファとして渡されるほうがよさそう、ということらしい。確かにそのほうがスマートかも。

そうすればマクロ評価時に読み込んだファイルが把握できて、ビルドキャッシュが制御できるのか。

ビルドの最初に決定したいってことならPathで取り回しても一緒な気がするけど、読んでくれるというのはこちらとしててはありがたい。

ask to give contentsというのは事前に読むという意味ではなくて、 context.files[“image.png”].data みたいな感じでラップしたファイルIOのAPIを通す、という意味だと思いました

岸川さんがレアカードみたいになってる

先に全部読んでおくだとメモリ使いすぎちゃうので。ラップしたAPIを通すことでマクロ評価時に読み込んだファイルが特定できるので、そのファイルが変更されてなければマクロの展開結果をキャッシュできるよね、という話に見えます

確かに全部読んでから渡すってのはそうですね。理解できました。

逆にsandboxの仕組みで触ったファイルを記録できる仕組みがあれば、マクロ実装者は普通にファイルAPI使ってても同じことができそうだけど無いのかな (edited)

なるほど。ユーザに自由に読み込ませる口を把握しておくのは賢いですね

omochimetaru

逆にsandboxの仕組みで触ったファイルを記録できる仕組みがあれば、マクロ実装者は普通にファイルAPI使ってても同じことができそうだけど無いのかな (edited)

あーもしこれがあっても、マクロ処理系のアクセスと、マクロ本体のアクセスの仕分けが必要だから、専用APIの方がいろいろ簡単か

omochimetaru

if式のレビュー始まった！

if 式と三項演算子、両方ある言語は珍しい？

nanasi

if 式と三項演算子、両方ある言語は珍しい？

たしかに。思いつかない。

Ruby とかですかね．

画面遷移についてハマったので誰かわかる方いましたらお伺いしたいのですが「UIPresentationController」クラスの「dismissalTransitionWillBegin」メソッド内で「 animate ( alongsideTransition : { [unowned self] _ in ..... } 」メソッド？を扱う際に、思う様に動作しないのでその事について質問したいのですが、誰か「この分野なら答えられそうだな...」という方いらっしゃいますか？もし力になって頂けるのなら質問したいです、、、。

答えられるかどうかは質問を見ないとわからないのでとりあえず質問を書いたほうがいいですよ。

Kishikawa Katsumi

答えられるかどうかは質問を見ないとわからないのでとりあえず質問を書いたほうがいいですよ。

わかりました、ありがとうございます。

質問です。簡単にいうとサイドメニューを作りたいのですが、サイドメニューに遷移した際に親Viewが少し下がっているように見せたいんです。それで遷移する際のアニメーションはうまくいったのですが、画面を閉じる際に思う様に戻っていかなくて、どの様な状態か説明が難しいので、動画を見ていただきたいです。

9:24 AM

戻りのアニメーションが「左上原点＋スケール縮小」から「初期変形」への遷移になってますね。

9:28 AM

戻りアニメーションの初期状態を、進みアニメーションの最終状態に設定するか

9:28 AM

beginFromCurrentState とかを設定したらいけそうな気がしますね。

9:29 AM

先述されてるtransition系のAPIは使ったことないので詳しくはわからないですけど。

あ、そうなんですありがとうございます。今こんな感じです、

9:30 AM

初期状態に設定するとしたらどこがいいとか、ありますかね？

うーん、ちゃんと traceView.frame = viewBack の状態が残ってそうですね。

一応 dismissalTransitionWillBegin(){ // 閉じる際に実行されるメソッド初期化フレームの適応アニメーションメソッド{ 戻る際のframeの適用 }) } っていうふうにも書いてみたんですが、やはり変わらなくて、、、書く場所が違うとかで解決できるならありがたいんですが。。。

戻りアニメーションの開始フレームで、なぜ左上寄せのレイアウトになってるのかを解明すると良さそうです。 (edited)

ちなみに dismissalTransitionWillBegin(){ // 閉じる際に実行されるメソッド traceView自体の削除(traceView.removeFormSuperview()) 全く別のtraceView2を変更後のframeの値で生成アニメーションメソッド{ 戻る際のframeをtraceView2に適用 }) } も試しましたがおんなじ動きでした

dismissalTransitionWillBegin にブレークポイント貼って時間止めて、 XcodeのView debuggerから何がどういう設定値になっているのか確認するのが良いと思います

それですよね

9:38 AM

なるほど

9:39 AM

View debuggerという機能を使った事ないんですが、ちょっと調べてやってみます。

予期しないlayout constraintsが何かしら生じてるとか、 translatesAutoresizingMaskIntoConstraints が迷惑な事してないか、とかが気になります。

色々frameのpointの部分を変な値にいじってみたのですが、やはりどんなことをしてもx:0 y:0から始まるので、ちょっと調べてみます。ありがとうございます。また調べてる途中で分からないことがあれば頼らせていただくかもです。

‍♂️

手元で試してみたんですが frame は触らず、 AutoLayout と UIView.transform で操作すると大丈夫そうです。

omochimetaru

予期しないlayout constraintsが何かしら生じてるとか、 translatesAutoresizingMaskIntoConstraints が迷惑な事してないか、とかが気になります。

ちょっとデバッガーとブレークポイントの使い方調べてみたんですが、何が悪さをしてるのかはわかりませんでした、、、。ただ一つ分かったのはdismissalTransitionWillBeginメソッドに入ったタイミングではframeのpointはズレてなかったのですが、animateの中に入ったタイミングで、pointが0,0になってました。結局理由は分からず、、、

nanasi

手元で試してみたんですが frame は触らず、 AutoLayout と UIView.transform で操作すると大丈夫そうです。

え！？本当ですか！？！？

11:09 AM

transformなんですが、戻る時はどの様にしましたか？戻りかたが分からなくて、使うの断念したんです。

戻る際は .identity にすれば良いです

わかりました、やってみます。わざわざ手元でまで動かして頂いて、本当にありがとうございます。

nanasi

戻る際は .identity にすれば良いです

度々すみません、よろしければAutoLayoutのところスクショなど貼ってもらえないでしょうか？自分何か間違えてるかもしれなくて、、、もうファイル削除してしまってたら大丈夫です、流石に手間ですので

あ！できた！できました！！！今日朝からずっとこの問題と対峙してたんですよね、本当にありがとうございます。すっごい嬉しいです。もっと早く質問すればよかったです！回答してくださった皆様！ありがとうございました！！

‍♂️

2

[Pitch] Custom Metadata Attributes

Hello everyone! The following is a pitch for adding an ability to declared a runtime discoverable attributes in the Swift language. We welcome any feedback or questions about this pitch! Authors: Pavel Yaskevich, Holly Borla, Alejandro Alonso Status: Awaiting implementation Implementation: [Sema/SILGen/IRGen] Implement runtime discoverable...

12:39 PM

カスタムアトリビュートをユーザライブラリ定義して実行時に集めてなんやかんやできるやつの提案

データベースのORマッパーとか作る時に、property wrapper使ってプロパティにメタデータ付けるみたいなやつを、実際にラップする副作用無しで実現できそう

いろいろメタプログラミングの手段を強化しようとしてるのかな。

そんな感じがしますね。SwiftUI 3 で派手な事が起きたりするのかなあ。

https://github.com/DougGregor/swift-macro-examples

GitHub - DougGregor/swift-macro-examples: Example macros for the Sw...

Example macros for the Swift macros effort. Contribute to DougGregor/swift-macro-examples development by creating an account on GitHub.

2:54 PM

マクロを実装して動作させてみるためのスケルトンプロジェクト・・・かな？

2:54 PM

READMEに Adding your own macro の章がある。

たぶんそうだな。

2:55 PM

これを待ってた。

岸川さんはこれのない状態で自力で動かしちゃったからもういらないですね。

2:57 PM

https://forums.swift.org/t/pitch-swift-predicates/62000

[Pitch] Swift Predicates

Hi all, @dgoldsmith and I have drafted a pitch outlining new APIs to express predicates natively in Swift code. We hope that this will provide a more robust and ergonomic experience for defining and using predicates in Swift. We plan to introduce this as part of the FoundationEssentials package and we'd love to hear your feedback. Introductio...

2:57 PM

https://gist.github.com/jmschonfeld/6821392a968a1a1a42aba3c96d333239

2:57 PM

あと、Foundationに NSPredicate みたいなやつを追加する話題（計画の報告？）があって、これがプロポーザルを見るとマクロを使っている (edited)

待ってたけど、これはまだコンパイラに統合された形ではうごかないんだな。

Kishikawa Katsumi

待ってたけど、これはまだコンパイラに統合された形ではうごかないんだな。

mainで実行できるだけって感じがしますね。

2:58 PM

SwiftSyntax上でマクロの展開までじゃないかな。実行できるかな。

クロージャでいいじゃねえかと思ったけど、Predicateオブジェクトは式ツリーオブジェクトなので、ネットワーク越しに送信できたりできるのが良いらしい

テストケースで動かす、という想定にみえる。

2:59 PM

PredicateやSQLみたいなのはマクロの使い方にマッチすると思う。

3:00 PM

SQLマクロを作る人もいるんじゃないかな。

Kishikawa Katsumi

SwiftSyntax上でマクロの展開までじゃないかな。実行できるかな。

3:02 PM

同梱されてるxcodeprojにコンパイラフラグが設定されていて

3:03 PM

MacroExamples/main.swift の中にかかれたマクロが展開されたものが実行されるように見えます

なるほど！めっちゃいいやん。

このxcodeprojでそのまま作業すればやりやすそうですね。

Forkした。今はForkするときにリポジトリの名前つけられるんだな。

もうMacroってXcodeに同梱されてるSwiftに実装されてるんですね

いや、されてない

3:18 PM

ツールチェイン落としてきて入れてねって書いてある

あ、なるほど。

3:19 PM

流石に早すぎるとは思いました

omochimetaru

https://forums.swift.org/t/pitch-custom-metadata-attributes/62016

これ難しいですね。アノテーションついてる型や関数を実行時に集めることができるのか。モジュールを跨いで本来は不可視の型同士をまとめられるの面白そうですね。 DIにすごく便利そう

Iceman

これ難しいですね。アノテーションついてる型や関数を実行時に集めることができるのか。モジュールを跨いで本来は不可視の型同士をまとめられるの面白そうですね。 DIにすごく便利そう

難しい。 Attribute.getAllInstances(of: Column.self)　って感じで集めるんだと思う。

3:24 PM

例えばpropertyにアノテートしてあった場合は、 Column.init<T, V>(attachedTo: KeyPath<T, V>, custom: Int) がよばれる(いつ？あつめたとき？)ので、KeyPathと合わせてなんとかしておく (edited)

VaporでCommandを最初にApplicationに登録する作業とか、ルーティング定義を登録する作業とか、そういうのをある程度自動化できそう

Iceman

VaporでCommandを最初にApplicationに登録する作業とか、ルーティング定義を登録する作業とか、そういうのをある程度自動化できそう

ああ〜 Vaporでいろいろ登録するやつは確かに相性良さそう。

3:26 PM

なんかこれをフルで活用するならメタデータ読んでリフレクションするやつと組み合わせないと道具が足りなくなるような気がしなくもない

3:27 PM

https://forums.swift.org/t/pitch-reflection/61438/39

[Pitch] Reflection

I agree partial type is maybe not the best name for this thing. I think type constructor would be a good name if that's the only thing this did (which is pretty much the only thing it does right now). I imagine in the future if we wanted to inspect "generic requirements of a generic type", then this would probably happen on partial types and wou...

3:27 PM

こっちのリフレクションライブラリの話とも繋がってるのかも。

3:28 PM

眺めてみるとマジでSwift6はメタプログラミングの時代になるかもしれん

反対意見もまああるな。ただこれも導入は決まってるんだろうか。

3:29 PM

私はなかなかおもしろそうと思う。

Fluentの@Childrenとかに関しても、今のめっちゃ難しいやり方より子のメタタイプを与えておくだけで最初に集めておいたModel情報からいろんなクエリ投げれてシンプルになるかも

3:29 PM

僕はかなり面白いと思いますね

メタプログラミングにひかれるのまあまあ中二病っぽいと思うけどしょうがない。

コンパイル時か、実行直後にエラーが検知できるならいいと思うんですよね

3:32 PM

そうじゃない使い方されてると変な壊れ方を見つけづらくなって闇になりますが・・・

この辺の強化はたしかにVaporとかORMに使われるのを想定している感じはあるな。 (edited)

Iceman

Fluentの@Childrenとかに関しても、今のめっちゃ難しいやり方より子のメタタイプを与えておくだけで最初に集めておいたModel情報からいろんなクエリ投げれてシンプルになるかも

そうなんだよね、すでにユースケースが生じてるから、それをよりスマートに実装するために導入するのは良いよね

めちゃくちゃよくある struct FooController { @Get("/api/home") func getHome() async throws -> Response { ... } } みたいなのが書けるようになりますからね（僕はこれいらないと思うけど）

例が要らないやつで草

Rustのactix-webみたいに引数の型を引っ張ってきてPathParameterにその型を埋め込まないとダメみたいなレベルまでできると嬉しい

3:37 PM

#[get("/{size}/{path:[^{}]+}")] async fn resize( req: HttpRequest, path: web::Path<(String, String)> ) -> impl Responder {

こういうの (edited)

decl macroの方でできるようになりそう

これはすごいな。

3:39 PM

新しいキラーWeb Frameworkが作られたりしてほしい。

1

3:39 PM

Vaporもいいものだけど。

なぜかサーバーサイドの人FastAPIみたいな記法好きがちなんだよなわかる

マクロの提案に番号ついた https://github.com/apple/swift-evolution/blob/main/proposals/0382-expression-macros.md

swift-evolution/0382-expression-macros.md at main · apple/swift-evo...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0382-expression-macros.md at main · apple/swift-evolution

というか、正式レビュー始まりましたよ https://forums.swift.org/t/se-0382-expression-macros/62090

SE-0382: Expression Macros

Hello Swift community, The review of SE-0382: "Expression Macros" begins now and runs through December 30, 2022. For context beyond the pitch threads linked in the proposal, there is a prospective vision document which has itself been pitched and is under consideration with the language workgroup. And, as noted in this proposal, a companion p...

えっ早いね。

3:25 AM

休みに入るためにサンプルリポジトリを大急ぎで用意したんだと思ってた。

たしかに、サンプルリポジトリを用意したばっかりだから、練習期間があんまりないですね。レビュー自体は月末までやるみたいだけどｗ

3:27 AM

3:28 AM

↑ #file と #line の型が StaticString , UInt から変わりそうだ。

3:29 AM

<T> で定義してるから従来の line: UInt = #line はこれからもコンパイル通るけど、 line: Int = #line って書けるようになりそう。

その辺は最終的には全部マクロで再実装されるのかな。

3:33 AM

提案では、やりたそうな感じに見える。

We propose to introduce a number of macro declarations into the Swift standard library. There are several different kinds of such macros.

セットで提案みたいですね

いやー、この状態でレビューするのは難しいだろう。レビューのたびに思うけどみんなすごいな。

とりあえずXcodeの品質もあって、マクロは使うのも作るのも非常に何が起こってるかわからなくてデバッグしづらい。

4:27 AM

すでに解消されてるコンパイルエラーとかが復活し続けてくるとかですごく難しい。

https://forums.swift.org/t/pitch-2-expression-macros/61861/23

https://forums.swift.org/t/swift-5-8-release-process/61540

There's a debug dump. Pass -Xfrontend -dump-macro-expansions to the compiler and it'll emit something like this: Macro expansion of #stringify(_:) in /path/to/MacroExamples/MacroExamples/main.swift:6:7-6:24 as (Int, String) ------------------------------ (x + y, "x + y") ------------------------------ Doug

4:30 AM

-Xfrontend -dump-macro-expansions でデバッグできるらしい。

4:30 AM

でもXcodeでいい感じに表示してほしいですね。

4:30 AM

C++でもプリプロセッサを駆使してるやつって展開結果を見ないとなんもわからんのでキツかったりする。

C++はマクロっぽい機能でテンプレートもあるけど、あれでコンパイルエラーとかはどうやってデバッグするの？

あれは超デバッグしにくいです。

4:38 AM

プリプロセッサはプリプロセッサだけ処理した結果を得る方法がある（Xcodeのメニューもある）んですけど

4:38 AM

テンプレートはそれが無いし、展開後のコードに対する型チェックエラーが出るので、何がなんだかめっちゃわかりづらいです

4:39 AM

一応テンプレートの実装方法次第で、エラーが早期に出るとかわかりやすく出るとか、そういう工夫はできます。

なるほど。テンプレートのデバッガとかは無いのか。。。

4:43 AM

Swiftのマクロは使う側はそこまで難しくないと思うけど、Swiftは合法なコードでもコンパイルできない場合があるからそれが起こると大変そうだなと思っている。

4:44 AM

マクロを作る側でできるだけ文を短くするとか型注釈をしっかり書く、みたいなノウハウが出てくると思う。

合法なコードでもコンパイルできない場合

Xcodeのバグでリビルドがうまくされないとかのことですか？

型推論に時間がかかりすぎて、ってやつ。

あ〜たしかに。

今はXcodeのバグもあるね

直しても直しても同じエラー出るから。

マクロを提供してメンテナンスしていくことを考えると、SwiftSyntaxのAPIや構文木の使用はある程度固定されてないとまあ困るけどSwiftSyntaxも合わせて正式版になったりするのかな？

コンパイラ内部でも使おうとしてるのである程度固定されると思います

そっちの作業の方が大変そうだな。

cxxにブリッジしたりもしてますしね

でもツリーを辿ってたらいつの間にか知らないNodeが挟まってた、とかはその後も発生するかなあ。

追加的な変更はまあ言語仕様と一緒に来ますよね

そういえばSwiftは5.8を刻むんですね。

Swift 5.8 Release Process

This post describes the release process, and estimated schedule for Swift 5.8. Snapshots of Swift 5.8 Downloadable snapshots of the Swift 5.8 release branch will be posted regularly as part of continuous integration testing. As support is available, snapshot downloads will be added for newly supported platforms. Once Swift 5.8 is released, th...

7:47 AM

if式やマクロが間に合うならまあまあ目玉リリースになりそうだ。

そんなに入るかな。Regexあたりが改善されるとかはあるんじゃないかと思うけど。

https://forums.swift.org/t/combined-se-0366-third-review-and-se-0377-second-review-rename-take-taking-to-consume-consuming/61904 あとこれ

Combined SE-0366 (third review) and SE-0377 (second review): rename...

Hello, Swift community! The combined third review of SE-0366: consume operator to end the lifetime of a variable binding and second review of SE-0377: borrow and consume parameter ownership modifiers begins now and run through December 14th, 2022. Throughout the reviews for SE-0366 and SE-0377, reviewers surfaced the concern that ‘take’ is too...

これは決着つきそう

7:53 AM

名前が決まれば実装はあるからすぐ使えるようになりそう。

そうですね。

https://forums.swift.org/t/pitch-custom-metadata-attributes/62016/46 Custom Metadata属性はもう少し練る必要がありそうだな。Unitテストのテストメソッド発見パターン以外のユースケースがあると良さそうだけど。 RealmみたいなORM的なAPIの構築には便利だと思うけどRealmの人でもこの提案はちょっとその場しのぎに見える、みたいな感じになってる。 (edited)

[Pitch] Custom Metadata Attributes

I think that through compiler evaluation we can unite a lot of features that are currently discussed separately. Both upthread and in the macro threads, forms of static introspection/reflection were discussed. Besides the static guarantee and optimization, I don’t see how that’s different from metadata-based runtime reflections. This feature al...

これこそ試しにライブラリを実装してみないと機能の不足とかわかんなそう (edited)

そうですねえ。Javaや.NETにある類似のライブラリを作ってみるとわかるかな。明らかにそれに影響された機能のようだし。

8:40 AM

https://forums.swift.org/t/pitch-reflection/61438/36 こっちの方はもともとプライベートに使われてたものをAPIとして整理するっていう前提が示されているからかほぼ+1の意見だけどAPIの設計はもっと練ったほうがいいって感じか。

[Pitch] Reflection

I'm really excited about more introspection capabilities in the language, but after reading the proposal, I think it's missing an important feature, and I don't quite understand another. What I really want to do is be able to find all types in a module (or linked into the app) that conform to a given protocol, and then instantiate instances of ...

Swift、別々のモジュールで重複して同じプロトコルに準拠するのはできると思ってたけど、両方 import して呼び分けられるのか。 // ModuleA extension Int: Sequence { public func makeIterator() -> IndexingIterator<[Int]> { [self].makeIterator() } }

// ModuleB import struct Foundation.Data extension Int: Sequence { public func makeIterator() -> Data.Iterator { var value = self return Data(bytes: &value, count: MemoryLayout.size(ofValue: value)).makeIterator() } }

// main.swift import ModuleA import ModuleB let n = 65534 for x: Int in n { print(x) } for x: UInt8 in n { print(x) } https://github.com/koher/extension-collision-swift (edited)

これ実装がたまたまそうなってオーバーロード解決してる＋静的な解決だからそのように動いてる、だけじゃないかしら・・・？

10:21 AM

ランタイムでグローバルに一個しか、ある型TのPへのconformは登録できないという認識で、ダイナミックなケースだとうまくいかないと思います

1枚目と2枚目: importするモジュールによって片方がエラー 3枚目: 両方importすると片方がエラー

10:31 AM

↑この例だと、２つインポートした場合は、片方のconformanceは無かった事になっているとみなせると思います。

10:33 AM

ただこれは半分ダイナミックなケースですね。ジェネリック関数を呼び出すところでダイナミックなABIを通すけど、その前の型検査は静的にやっているので。完全にダイナミックなケース(Any からキャストする)を実験しようとしたんですが、associatedtypeを具象型に含めてキャストするのって今はできない気がする？

10:33 AM

as? any Sequence<Int> が書けたらいいんですけど

10:34 AM

自分のマシンがMontreryだからまだできないかも (edited)

import ModuleA しかしないファイルで x: Int に対して x.makeIterator() と書くと "Ambiguous use of makeIterator()" と怒られました。 (edited)

10:35 AM

1枚目と2枚目: importするモジュールによって片方がエラー

ですら型推論で判別されていて、 import で判別されているわけではない？

koher

import ModuleA しかしないファイルで x: Int に対して x.makeIterator() と書くと "Ambiguous use of makeIterator()" と怒られました。 (edited)

ホントだ・・・あ、でも、 useA.swift の中身もコメントアウトして、ExtensionCollision の中に import ModuleA が全くない状態にしたら、ambiguousが消えました。

10:42 AM

<T: Sequence> な関数への適用はそのファイルの import 文が解決に影響するけど、直接の .makeIterator() の呼び出しは、モジュール全体での import が関係するみたいですね・・・？

// ModuleC public func show<S: Sequence>(_ sequence: S) where S.Element: AdditiveArithmetic { for x in sequence { print(x) } }

import ModuleA import ModuleC func useA(for x: Int) { x.foo() show(x) } import ModuleB import ModuleC func useB(for x: Int) { x.foo() show(x) } // main.swift import ModuleA import ModuleB useA(for: 65534) useB(for: 65534) ↑、 main の import 書く順によってどっちが呼び出されるか変わる

10:52 AM

https://github.com/koher/extension-collision-swift/commit/1b06ec0cb667de88257fc313a690781fe74fe29d

omochimetaru

<T: Sequence> な関数への適用はそのファイルの import 文が解決に影響するけど、直接の .makeIterator() の呼び出しは、モジュール全体での import が関係するみたいですね・・・？

↑のパターンも出てきたからカオス。 ambiguous になるパターン、型から一つが選ばれるパターン、よくわからないルールで一方が選ばれるパターン。

よくわからないルールはコンパイラが生成するビルド処理でたまたま並んだ順番とかで決まってそう

そうですね。

10:56 AM

多分そんな感じ。 (edited)

main.swift のほうがアルファベット順で上だからそのファイルの import文に支配されてるのかも。

うん、その可能性あるとも思ってる。

10:57 AM

エントリーポイントから処理されてる可能性もあるかもだけど。

10:57 AM

main.swift から import 消したら ModuleA が優先されたから、ファイル名順で useA.swift が優先された可能性も高そう。

今回の例みたいに

11:00 AM

型 T とプロトコル P において、それらが定義されたモジュールとは別のモジュールで、 T: P を後付準拠(retroactive conformance)させるのは、それを利用ライブラリAとアプリBの2箇所でやってしまったりしているとこのように崩壊するので

11:00 AM

コンパイラが警告を出すようにしよう、という提案が出てますね https://forums.swift.org/t/returned-for-revision-se-0364-warning-for-retroactive-conformance-of-external-types/59729

[Returned for Revision] SE-0364: Warning for Retroactive Conformanc...

The review of SE-0364: Warning for Retroactive Conformance of External Types ran from July 13th to 27th. The language workgroup has decided to accept in principle that a warning should be added for such conformances, but we are returning the proposal for revision to explore what the mechanism of silencing the warning should be. Accepted princip...

11:01 AM

8月で審査が再検討になってから止まってるな。

そっかー。 import で切り替えられたらグローバルな汚染を気にせず extension で準拠させられるんだけどなぁ。

11:02 AM

コールスタックを考えると一意に定まる気がするけど、実行時のパフォーマンスに影響を与えずには無理そうかな。 (edited)

Ventura以降なら、一度 Any 型の変数に入れてから、 anySeq as? any Sequence<Int> でダウンキャストしてから implicit open で <T: Sequence> where T.Element == Int に変換するパターンのコードが書けて、これはコールスタックとかで静的に決められないですね。

11:06 AM

静的なケースで <T: Sequence> where T.Element == Int> な引数を受け取る関数をネストして呼び出すパターンのコードなら、内側の呼び出しでは、外側の関数が受け取ったwitness tableをリレーしていくコードになるので、一貫性を維持して呼び出しが潜っていくはず。

any は確かに厳しそう・・・

その場合に限っては呼び出し元のファイルのimport文とかでちゃんと扱えてもいいかもしれないけど、その内部の奥底でグローバル変数の Any 型にコピーしちゃうケースとかを考えると結局怪しい動作にはつながる。

any を介しても existential containerがwitness table保持してるし、openされたときもそれが選択されたらうまくいかないかな？

any Sequence ならそうですね。 > witness tableを引き回すでも Any はwitness tableを持たないので、Any から as? any Sequence<Int> は不安定です。 (edited)

なるほど、 Any か。

https://forums.swift.org/t/se-0382-expression-macros/62090/22 マクロでStringのバイト列を直接埋め込むってのはおもしろい。あとちょいちょい反対意見も出てきた。レビューチームとしては使ってみてユースケースに対して仕様の不足がないかみてほしいと考えてるらしい。

SE-0382: Expression Macros

Would expression macros support trailing closure syntax? I have the feeling that passing closures could be a major use-case.

リテラルを渡す場合に限るけどマクロを使うと値の範囲をコンパイル時にチェックしたり特定のパターンに一致しない文字列をエラーにしたりできるな。なんかの役に立つかしら？

@swift-main let a: Int8 = 80 + 80

omochimetaru

@swift-main let a: Int8 = 80 + 80

exit status: 1 with stderr:

<stdin>:1:18: error: arithmetic operation '80 + 80' (on type 'Int8') results in an overflow let a: Int8 = 80 + 80 ~~ ^ ~~

↑こういうのはコンパイラにすでにありますね

1:07 AM

理屈上はそういうコンパイル時の定数計算(+検査)みたいなものはマクロである程度代用できますね。 (edited)

1:08 AM

昔だったら正規表現が正規表現文法に違反してる、とかもコンパイル時チェックする需要があったと思う。今はRegexがまさにそれやってくれるけど

このチェックは型の範囲内かどうかだから例えば50〜100の間、とか100以下とかUUIDの形式、とかは役に立ちそうかなって。

2:03 AM

配列で要素数がn個とか。

たしかにマクロにnとかの引数もあたえることで新しい検査ができますね

4:58 AM

https://forums.swift.org/t/pitch-2-build-time-constant-values/56762

[Pitch #2] Build-Time Constant Values

Build-Time Constant Values Authors: Artem Chikin, Ben Cohen, Xi Ge Introduction A Swift language feature for requiring certain values to be knowable at compile-time. This is achieved through an attribute, @const, constraining properties and function parameters to have compile-time knowable values. Such information forms a foundation for rich...

4:59 AM

そういうのは多分コンパイル時計算のほうがマッチしていると思うけど、これはピッチから進んでないからなあ。

https://forums.swift.org/t/se-0359-build-time-constant-values/57562 レビューに入ったあと差し戻しになったみたいよ。

SE-0359: Build-Time Constant Values

Hello Swift community, The review of SE-0359 "Build-Time Constant Values" begins now and runs through June 6, 2022. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review...

なるほど

https://github.com/apple/swift-syntax/pull/1207

[Macros] Introduce member declaration macros. by hborla · Pull Requ...

An initial implementation for member declaration macros. Member declaration macros are represented as custom attributes, and expanding a member macro for a given declaration can produce a set of ne...

3:21 PM

式マクロとは別のメンバ生成マクロの実装が来た

structの中で使ってプロパティを生成する例の他に、トップレベルで使って型を生成してるのがあるな

これは記法で議論がありそうだな。さすがにこの例は何が起こるのかわからなさすぎる。

public let testMacros: [String: Macro.Type] = [ "checkContext": CheckContextIndependenceMacro.self, "colorLiteral": ColorLiteralMacro.self, "fileID": FileIDMacro.self, "imageLiteral": ImageLiteralMacro.self, "stringify": StringifyMacro.self, "myError": ErrorMacro.self, "bitwidthNumberedStructs": DefineBitwidthNumberedStructsMacro.self, "addCompletionHandler": AddCompletionHandler.self, "addBackingStorage": AddBackingStorage.self, ]

11:32 PM

public struct AddBackingStorage: MemberDeclarationMacro { public static func expansion( of node: CustomAttributeSyntax, attachedTo decl: DeclSyntax, in context: inout MacroExpansionContext ) throws -> [DeclSyntax] { let storage: DeclSyntax = "var _storage: Storage<Self>" return [ storage.withLeadingTrivia([.newlines(1), .spaces(2)]) ] } }

11:32 PM

これだけか

11:35 PM

varが生えるとかstructが生えるとかがノーヒントなのは、型定義がある式マクロと比べるとわかりにくい

11:36 PM

しかし、「何が起きるのかわかるように宣言する」機能と、「マクロでなんでもできる」性質は矛盾するから仕様のバランスが難しそうだなあ

SwiftSyntaxがもうちょっと簡単になったら読めばわかるでもいいけどね。

https://github.com/apple/swift-syntax/blob/f5f45e224c4d12403e96dcf50c4d59fbdccf070d/Tests/SwiftSyntaxMacrosTest/MacroSystemTests.swift#L211-L320

swift-syntax/MacroSystemTests.swift at f5f45e224c4d12403e96dcf50c4d...

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/MacroSystemTests.swift at f5f45e224c4d12403e96dcf50c4d59fbdccf070d · apple/swift-syntax

フォーラムの議論にの方にもちょっとあったけどTriviaを意識しないといけないとかもかなり読みにくくしてるんよな。

AddCompletionHandler はパッと見だいぶ難しい

11:42 PM

指定された func を元に、completion handlerを持つ版の func を生成する(func1個が2個に増殖する)

Triviaをちゃんと保持して付け足さないとコンパイルエラーになったりするのは勝手にうまいことやってほしい、みたいに思っている。

Triviaムズいですよね

11:43 PM

その代わり、コメントや改行まで正確にコントロールできるのがメリットですけど・・・

Parseしてそれを使うぶんにはいい仕組みなんだけど改変する場合に相性が良くないんすよね。

あと僕が触って難しかったのは関数呼び出しの引数を区切るカンマの管理。 (edited)

11:44 PM

気持ちとしては関数呼び出しと引数リストにしか興味ないけど、syntaxレベルのAPIだからカンマ区切りの面倒をみないといけない (edited)

SwiftSyntaxのASTはソースコードに忠実すぎてあんまり構造として扱っているという感じじゃない。 (edited)

Kishikawa Katsumi

SwiftSyntaxのASTはソースコードに忠実すぎてあんまり構造として扱っているという感じじゃない。 (edited)

それがまさに AST じゃなくて CST だからですねえ Abstractじゃない。

やっぱりもう一段階抽象化されたラッパーがいるよね。

Triviaに対して「いい感じにしといて」みたいな特殊な値が設定できたらいいのかなあ？

Kishikawa Katsumi

やっぱりもう一段階抽象化されたラッパーがいるよね。

そうですね。意味的な構造だけabstractに操作する方法がほしいですね。どういうふうなAPIならうまく共存できるかイメージついてないけど

リフレクションのAPIみたいな感じのが私はいいと思う。

たしかにあの粒度は意味情報だけになってそう

特に今回の宣言につけられるマクロとか将来的に関数につけられるマクロが出てきたときに、 addInstanceVariableとか、returnStatement.insertBefore()みたいなインターフェースがあると使いやすいと思う。

なるほど。

今のSwiftSyntaxだとリターン文の前にprint()を入れる、っていうのもreturnを見つけて、前後を見て壊さないようにコードを挿入する、っていう手続きになって、かなり冗長になりそう (edited)

https://forums.swift.org/t/pitch-declaration-macros/62373

[Pitch] Declaration macros

Hey all, SE-0382 "Expression Macros" is under review now. Expression macros are one piece of the larger vision for macros. Declaration macros are another pieces, and are quite possibly the most important one, because they provide the ability for macros to produce new declarations as well as augment existing declarations. Declaration macros sup...

7:54 AM

見逃してた、ここだ (edited)

https://github.com/DougGregor/swift-evolution/blob/declaration-macros/proposals/nnnn-declaration-macros.md

swift-evolution/nnnn-declaration-macros.md at declaration-macros · ...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/nnnn-declaration-macros.md at declaration-macros · DougGregor/swift-evolution

7:34 PM

decl macroは色んなカテゴリが定義されていて、それで何が起きるかなんとなくわかるみたいだ

7:38 PM

witness decl macroとか、peerマクロとaccessorマクロによるClamping property wrapperの置き換えの例が面白い

例に出てるasyncメソッドにマクロを付けるとコールバックを受け取る関数を自動的に生成するっていうのはよいな。そういう機械的なボイラープレート、SwiftUIを使うときによさそう。

5:48 AM

@declaration(body) macro traced(logLevel: Int = 0) こんな感じでどこに作用するマクロなのかを宣言で指定するからキレイに作ってあればそれでなんとなくわかるし、ソースコード読むことになっても手がかりになるということか。

ですね～

Dougさんは以下のマクロを実装するのは簡単だし読む場合も明らかと言ってるけどそこはだいぶ見解の相違がありそうだな。

public struct AddCompletionHandler: PeerDeclarationMacro { public static func expansion( of node: CustomAttributeSyntax, attachedTo declaration: DeclSyntax, in context: inout MacroExpansionContext ) throws -> [DeclSyntax] { // Only on functions at the moment. We could handle initializers as well // with a bit of work. guard let funcDecl = declaration.as(FunctionDeclSyntax.self) else { throw CustomError.message("@addCompletionHandler only works on functions") } // This only makes sense for async functions. if funcDecl.signature.asyncOrReasyncKeyword == nil { throw CustomError.message( "@addCompletionHandler requires an async function" ) } // Form the completion handler parameter. let resultType: TypeSyntax? = funcDecl.signature.output?.returnType.withoutTrivia() let completionHandlerParam = FunctionParameterSyntax( firstName: .identifier("completionHandler"), colon: .colonToken(trailingTrivia: .space), type: "(\(resultType ?? "")) -> Void" as TypeSyntax ) // Add the completion handler parameter to the parameter list. let parameterList = funcDecl.signature.input.parameterList let newParameterList: FunctionParameterListSyntax if let lastParam = parameterList.last { // We need to add a trailing comma to the preceding list. newParameterList = parameterList.removingLast() .appending( lastParam.withTrailingComma( .commaToken(trailingTrivia: .space) ) ) .appending(completionHandlerParam) } else { newParameterList = parameterList.appending(completionHandlerParam) } let callArguments: [String] = try parameterList.map { param in guard let argName = param.secondName ?? param.firstName else { throw CustomError.message( "@addCompletionHandler argument must have a name" ) } if let paramName = param.firstName, paramName.text != "_" { return "\(paramName.withoutTrivia()): \(argName.withoutTrivia())" } return "\(argName.withoutTrivia())" } let call: ExprSyntax = "\(funcDecl.identifier)(\(raw: callArguments.joined(separator: ", ")))" // FIXME: We should make CodeBlockSyntax ExpressibleByStringInterpolation, // so that the full body could go here. let newBody: ExprSyntax = """ Task { completionHandler(await \(call)) } """ // Drop the @addCompletionHandler attribute from the new declaration. let newAttributeList = AttributeListSyntax( funcDecl.attributes?.filter { guard case let .customAttribute(customAttr) = $0 else { return true } return customAttr != node } ?? [] ) let newFunc = funcDecl .withSignature( funcDecl.signature .withAsyncOrReasyncKeyword(nil) // drop async .withOutput(nil) // drop result type .withInput( // add completion handler parameter funcDecl.signature.input.withParameterList(newParameterList) .withoutTrailingTrivia() ) ) .withBody( CodeBlockSyntax( leftBrace: .leftBraceToken(leadingTrivia: .space), statements: CodeBlockItemListSyntax( [CodeBlockItemSyntax(item: .expr(newBody))] ), rightBrace: .rightBraceToken(leadingTrivia: .newline) ) ) .withAttributes(newAttributeList) .withLeadingTrivia(.newlines(2)) return [DeclSyntax(newFunc)] } }

Kishikawa Katsumi

Dougさんは以下のマクロを実装するのは簡単だし読む場合も明らかと言ってるけどそこはだいぶ見解の相違がありそうだな。

public struct AddCompletionHandler: PeerDeclarationMacro { public static func expansion( of node: CustomAttributeSyntax, attachedTo declaration: DeclSyntax, in context: inout MacroExpansionContext ) throws -> [DeclSyntax] { // Only on functions at the moment. We could handle initializers as well // with a bit of work. guard let funcDecl = declaration.as(FunctionDeclSyntax.self) else { throw CustomError.message("@addCompletionHandler only works on functions") } // This only makes sense for async functions. if funcDecl.signature.asyncOrReasyncKeyword == nil { throw CustomError.message( "@addCompletionHandler requires an async function" ) } // Form the completion handler parameter. let resultType: TypeSyntax? = funcDecl.signature.output?.returnType.withoutTrivia() let completionHandlerParam = FunctionParameterSyntax( firstName: .identifier("completionHandler"), colon: .colonToken(trailingTrivia: .space), type: "(\(resultType ?? "")) -> Void" as TypeSyntax ) // Add the completion handler parameter to the parameter list. let parameterList = funcDecl.signature.input.parameterList let newParameterList: FunctionParameterListSyntax if let lastParam = parameterList.last { // We need to add a trailing comma to the preceding list. newParameterList = parameterList.removingLast() .appending( lastParam.withTrailingComma( .commaToken(trailingTrivia: .space) ) ) .appending(completionHandlerParam) } else { newParameterList = parameterList.appending(completionHandlerParam) } let callArguments: [String] = try parameterList.map { param in guard let argName = param.secondName ?? param.firstName else { throw CustomError.message( "@addCompletionHandler argument must have a name" ) } if let paramName = param.firstName, paramName.text != "_" { return "\(paramName.withoutTrivia()): \(argName.withoutTrivia())" } return "\(argName.withoutTrivia())" } let call: ExprSyntax = "\(funcDecl.identifier)(\(raw: callArguments.joined(separator: ", ")))" // FIXME: We should make CodeBlockSyntax ExpressibleByStringInterpolation, // so that the full body could go here. let newBody: ExprSyntax = """ Task { completionHandler(await \(call)) } """ // Drop the @addCompletionHandler attribute from the new declaration. let newAttributeList = AttributeListSyntax( funcDecl.attributes?.filter { guard case let .customAttribute(customAttr) = $0 else { return true } return customAttr != node } ?? [] ) let newFunc = funcDecl .withSignature( funcDecl.signature .withAsyncOrReasyncKeyword(nil) // drop async .withOutput(nil) // drop result type .withInput( // add completion handler parameter funcDecl.signature.input.withParameterList(newParameterList) .withoutTrailingTrivia() ) ) .withBody( CodeBlockSyntax( leftBrace: .leftBraceToken(leadingTrivia: .space), statements: CodeBlockItemListSyntax( [CodeBlockItemSyntax(item: .expr(newBody))] ), rightBrace: .rightBraceToken(leadingTrivia: .newline) ) ) .withAttributes(newAttributeList) .withLeadingTrivia(.newlines(2)) return [DeclSyntax(newFunc)] } }

Dougさん基準ｗ

> Removing the need for the trivia manipulation would probably help quite a bit with that too; if you're used to looking at code using SwiftSyntax I assume your eyes just automatically skip all of the withoutTrivia() etc. calls, but for someone new to it that's a lot of extra incidental code to read on the way to understanding what's actually happening. Definitely. I probably spent a quarter of my time on this messing with trivia

. It's something we can improve on via the swift-syntax APIs over time.

ただまあこの辺が冗長になるということは伝わってるらしい。 (edited)

おお。いい感じのAPIつけてほしい

Property Wrappersとマクロが重なる部分があるのでどっちを使うか、という話が出てきそうだけどProperty Wrappersはデバッグしやすいし見えない部分はないからその点でProperty Wrappersかな。マクロのデバッグサポートがめっちゃ使いやすかったら別だけど。

5:57 AM

今のところ作るのも使うのもProperty Wrappersの方がだいぶ簡単だろう。

https://forums.swift.org/t/pitch-declaration-macros/62373/36

[Pitch] Declaration macros

Hey all, It's become very clear to me that this "declaration macros" pitch is really two separate proposals rolled into one, so I've gone ahead and split this document into two separate proposals that we can iterate on: Freestanding macros covers the "freestanding" case, generalizing the # syntax to also introduce declarations and code items...

5:34 PM

decl macroがattached macroとfreestanding macroに分かれた (edited)

妥当だと思う。Declaration macrosは式マクロ以外の残りのアイデア全部入れたって感じだったから。 (edited)

5:46 PM

分けて個別にやったほうが議論もしやすそう。

Kishikawa Katsumi

分けて個別にやったほうが議論もしやすそう。

ですねー

https://forums.swift.org/t/accepted-with-modifications-se-0380-if-and-switch-expressions/

[Accepted with modifications] SE-0380: if and switch expressions

The review of SE-0380: if and switch expressions ran from December 7th to December 30th. Feedback was generally positive; many reviewers noted that the usability of if expressions in other languages is missed in Swift, and selection statements producing a single value in each branch is a common pattern across their Swift code. Most of the discus...

11:04 PM

if / switch 式内の return はなしで accepted になったみたいですね

omochimetaru

https://forums.swift.org/t/pitch-declaration-macros/62373/36

attached macroはpeer, accessor, member, memberAttribute macroの4つにしぼられてるな body, conforming, witnessは切り離されてる

2:26 AM

Here are several possibilities, omitted from this proposal primarily to reduce scope.

2:33 AM

-- freestanding macroの方も見てるけど

Additionally, we replace the @expression attribute introduced in SE-0382 with @freestanding(expression)

(edited)

2:33 AM

@expressionが産まれる前にオワコンかもしれん

まあそもそもそこは人間が読むためのもののはずだから区別できればなんでもいいんじゃなかったかな。たしかなくてもいいやつ。

それはそうですね。

正直なくていいならややこしいのいらんと思うんですけどね。

コード中のどこに書けるかを規定しているので無くすことはできないと思います

でもExpression macroはExpressionMacroプロトコルだしどのプロトコルかでわかるんじゃないかな。

たしかに。わざわざ手でヘッダー書いてるみたいな感じもありますね

https://forums.swift.org/t/se-0386-package-access-modifier/62808

SE-0386: package access modifier

Hello, Swift community. The review of SE-0386: package Access Modifier begins now and runs through February 8th, 2023. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager by email. When contact...

1

12:27 AM

packageスコープの審査だそうです (edited)

12:27 AM

他の案のところみると_spiの正式仕様版なのかな

パッケージ単位の最適化が行われるようになる？たとえば、 package class Foo がパッケージ内で継承されていなければ静的ディスパッチにできるとか。

12:36 AM

それがされるなら、ついでに同一パッケージだとモジュールを越えて Specialize されるようになったりしないかな？

inlineableってBUILD_LIBRARY_FOR_DISTRIBUTIONでは使えないですけど、packageスコープだったら使えるようになったりしないかな

packageスコープでも同一パッケージからサブクラスできるかどうかは保留されてるっぽい？ (edited)

12:58 AM

ただpublic未満にできることで増える最適化機会はいろいろありそうですね

Iceman

inlineableってBUILD_LIBRARY_FOR_DISTRIBUTIONでは使えないですけど、packageスコープだったら使えるようになったりしないかな

パッケージ単位の最適化が働くなら、 inlinable 関係なくパッケージ内はインライン化できそう。

inlineableあるとxcframeworkとして出荷できなくなるんですけど、その制約を既存の機能保ったまま取っ払えると嬉しい。

https://github.com/apple/swift/pull/62425 Xcodeの右クリックからマクロを展開できるようになる、、、のかな？

[SourceKit/Refactoring] Macro expansion by rintaro · Pull Request #...

Add refactoring "Expand Macro" that expands macro expressions. rdar://102739026

テストの書き方が特殊でよくわからないけど多分そうかな？ // EXPAND: source.edit.kind.active: // EXPAND-NEXT: 4:7-4:24 "(a + b, "a + b")" (edited)

だいぶいいよね。コンパイルエラーの表示も追従してくれるかな？

保守する上ではマクロ式のままがいいから、生成結果の確認とかコンパイルエラーの確認のために展開してみて、オッケーだったらCmd+Zでもとに戻すみたいな？

GitのDiffみたいなインライン表示のUIにならないかな。Refactorメニューだからテキストを変更しちゃうんだろうか。

11:26 AM

RegexのResult Builderに変換、みたいになるってことか。

実際にテキストに展開する機能な気がしますね。あってもいいし使い所はあるけど、一番欲しいのはポップアップで一時的な感じで見える方だなあ

そういえばマクロが生成したコードは展開した後の結果を使ってコード補完されるのかな。別モジュールに分かれてる場合は補完されるだろうけど同じモジュール内の場合も補完してくれるんだろうか。 (edited)

それちょっと気になってるんですよねー　展開した後の結果を使わないと、メソッドとか生えてなくて無理だと思います

聞いてみよ。メンバ変数、関数生成系は補完に出ないと使いづらい。 (edited)

質問です。画面をtransformして0.9に小さくする処理を書いてるのですが、headerも小さくする方法ってないですか?

11:56 PM

画面遷移した際に、透過した親viewのサイズをtransformで変えているのですが、navigationControllerだけ変わらなくて、やり方分からなくて困ってます。

↑すみませんこちらの問題は解決したのですが、navigationbarに動的に制約を設定する方法だけ誰かご存知でないでしょうか？

質問は #beginner-help-archived がオススメです navigationbarをどうしたいのかが解らないのでなんともですが、パッと思い付く方法だとchildViewControllerにUINavigationControllerを追加して、UINavigationController.viewに対して制約を追加するのが手っ取り早いでしょうか？

tarunon

質問は #beginner-help-archived がオススメです navigationbarをどうしたいのかが解らないのでなんともですが、パッと思い付く方法だとchildViewControllerにUINavigationControllerを追加して、UINavigationController.viewに対して制約を追加するのが手っ取り早いでしょうか？

わかりました！そちらで質問してみます！ありがとうございます

‍♂️ 簡単にいうとtransformしたnavigationBarを中央に持ってきたいのですが、直接navigationBarに制約を設定してもびくともしないという感じです。

@objc public protocol A: AnyObject { @objc var name: String { get } } 例えばこういうのが Swift なモジュールにあって、それを @interface B : NSObject <A> @end こんな感じで Objective-C なモジュールから使って、それを func f() { let b = B() print(b.name) } こうやって Swift なモジュールから使うと、nameが見えないと言われる。でも、 func f() { let b: A = B() print(b.name) } こうすると問題なく使える。 (edited)

6:11 AM

何が起こっているんだ...

壊れてそう、全部swiftなら問題ないですよね

もちろんです

6:13 AM

A が Objective-C ならもちろん問題ない

6:18 AM

いったいなにが...

POC = https://github.com/niw/SwiftObjcProtocolBridgeTest

GitHub - niw/SwiftObjcProtocolBridgeTest: I wonder why this is happ...

I wonder why this is happening. Contribute to niw/SwiftObjcProtocolBridgeTest development by creating an account on GitHub.

6:41 AM

ちょっと再現セットアップがめんどい

https://forums.swift.org/t/returned-for-revision-se-0382-expression-macros/62898 マクロの仕様レビューも周辺を巻き込んで大きくなっていく感じなのかな？

[Returned for revision] SE-0382: Expression Macros

The review of SE-0382: Expression Macros ran from December 16, 2022 until January 15, 2023. Overall, the feedback we received was positive. Modifications were incorporated to the proposal during review based on early feedback when the review period was extended. Having reviewed all of the points raised during the review period, the language wor...

Kishikawa Katsumi

Swiftのマクロ、ファイルが読めるならバイナリをソースコードに埋め込む、っていうのできそうだけどファイル読めるかなあ。

SwiftPMのほうにファイルを埋め込む機能がきてますね https://github.com/apple/swift-package-manager/pull/6067

Support for embedding resources in an executable by neonichu · Pull...

Basic support for a new .embed resource rule which will allow embedding the contents of the resource into the executable code by generating a byte array, e.g. @_implementationOnly import struct Fou...

4:34 AM

毎回ファイル読み込んでコード生成する形なので依存解決とかは問題なさそうだけど、ビルドの効率は悪そう？

キャッシュが効けば平気そう

ファイルが大きいときにSwiftPMがコード生成する時間とswiftcがパースとかする時間が効率悪そうという意味でした。PRのFIXMEにも書かれてますが。

良さそうだ。確かにSwiftPMがやってくれるならそれがベターな気がする。

Iceman

ファイルが大きいときにSwiftPMがコード生成する時間とswiftcがパースとかする時間が効率悪そうという意味でした。PRのFIXMEにも書かれてますが。

1回目はそうですね。バイナリがわざわざリテラル表現になっちゃうし。

ビルドツールでやるんならコード生成じゃなくてそのままくっつけてなんかうまいこと参照するとかできないんかな。

https://forums.swift.org/t/pitch-custom-actor-executors/63135

[Pitch] Custom Actor Executors

Hello everyone, I'd like to share the first pitch exploring the realms of custom executors in Swift. This proposal focuses on the minimum viable pieces to make actor executors configurable by library authors or end-users. It is based on the early draft of custom executors by @John_McCall which we had shared way back when Swift Concurrency was...

11:26 PM

Custom Executorのドラフト出てる

11:27 PM

まだ入ってないmoveonly typeがある想定で書かれてmoveonly struct Jobというのが出てくる。

moveonlyにすることで同じJobを2回実行しないようにしているんですね。

1

https://forums.swift.org/t/se-0389-attached-macros/63165

SE-0389: Attached Macros

Hello Swift community, The review of SE-0389: "Attached Macros" begins now and runs through March 2, 2023. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager ...

5:46 PM

Attached macro審査

まだWIPですけどObservationの実装出てきましたね。swift-async-algorithmにあったCritical Regionを作る仕組みとかを持ってきているようですね

https://github.com/apple/swift/pull/63725 (edited)

[WIP] Initial draft of observation by phausler · Pull Request #6372...

This is an initial draft of the observation feature. It includes an implementation of the Observation module and associated protocols and utility types. This does not yet include the macro synthesi...

shiz

まだWIPですけどObservationの実装出てきましたね。swift-async-algorithmにあったCritical Regionを作る仕組みとかを持ってきているようですね

https://github.com/apple/swift/pull/63725 (edited)

Observable関連の型とかライブラリの部分かな？特定の型を購読可能にする部分は含まれてなさそう？

omochimetaru

Observable関連の型とかライブラリの部分かな？特定の型を購読可能にする部分は含まれてなさそう？

Observable関連の型とかライブラリの部分かな？

はい、そうです。

特定の型を購読可能にする部分は含まれてなさそう？

ObservationRegistarですかね？ https://github.com/apple/swift/pull/63725/files#diff-b824e8d6f2a9d4c217d42ac8ef67d7628dafda2e86321ac23c4dc2e90545f13b

shiz

Observable関連の型とかライブラリの部分かな？

はい、そうです。

特定の型を購読可能にする部分は含まれてなさそう？

ObservationRegistarですかね？ https://github.com/apple/swift/pull/63725/files#diff-b824e8d6f2a9d4c217d42ac8ef67d7628dafda2e86321ac23c4dc2e90545f13b

プロパティの変更時にイベントを発火する処理の部分です type wrapperかマクロが必要な部分。

omochimetaru

プロパティの変更時にイベントを発火する処理の部分です type wrapperかマクロが必要な部分。

あ

まだなさそうです。 (edited)

shiz

あ

まだなさそうです。 (edited)

そこがどうなるかに一番興味があります

1

omochimetaru

そこがどうなるかに一番興味があります

追加情報出てきたら共有します！

1

https://forums.swift.org/t/se-0390-noncopyable-structs-and-enums/63258

SE-0390: @noncopyable structs and enums

Hello Swift community, The review of SE-0390: "@noncopyable structs and enums" begins now and runs through March 7, 2023. This feature is already partially implemented on the main branch of Swift behind the -enable-experimental-move-only flag. There are some pieces that landed very recently and are therefore not yet available in the normal ni...

2:57 AM

moveonly typeの審査が来ました！

2:58 AM

@noncopyable struct FileDescriptor { private var fd: Int32 init(fd: Int32) { self.fd = fd } func write(buffer: Data) { buffer.withUnsafeBytes { write(fd, $0.baseAddress!, $0.count) } } deinit { close(fd) } }

2:58 AM

moveonly じゃなくて @noncopyable というアトリビュートになったらしい。 (edited)

c++感あるw

ざっと読んで来たけど

7:38 AM

コピーができないから普通のValue Semanticsが使えないのでジェネリックパラメータにハメることができない、というのがキツすぎる

7:38 AM

その結果、Optionalに入れることもできないって。

7:40 AM

ワークアラウンドとか書いてあるけど、将来の方向性として、moveonlyを絡めたconditionalなジェネリクスとか書いてあるけど、最初からないとつらそー (edited)

これ var let の延長として、 moveonlyで値を宣言する、みたいな方向性じゃないのか (edited)

7:46 AM

値の宣言時に定義できるなら、genericsの問題も発生しないし、ArrayもOptionalも使えるように思う。それで破綻が産まれるかは、考えてはないけど

tarunon

これ var let の延長として、 moveonlyで値を宣言する、みたいな方向性じゃないのか (edited)

deinit書けるところとか大事だからユースサイトではうまく行かないと思う

ふむー

コピー可能かどうかがモジュール内部でしか見えないプロパティに埋まってしまうと、letで受けれるかどうか判断できなくなりそうですね

Iceman

コピー可能かどうかがモジュール内部でしか見えないプロパティに埋まってしまうと、letで受けれるかどうか判断できなくなりそうですね

それは型宣言についてるから外からもわかるはずちなみにletでは常に受けられるけど暗黙的にmoveになるっぽい

ああ、letの他にmoveonlyが追加されてもuncopyableはついたままということですね

https://github.com/apple/swift-package-manager/pull/6185 SwiftPMにもマクロのサポートが入った。.macroっていうターゲットタイプが新しくできるのね。

Initial support for Swift macros by neonichu · Pull Request #6185 ·...

Add a new module CompilerPluginSupport which vends the macro target type Represent macro targets in the package model Build system support for macros In order to be able to test this end-to-end be...

5:48 AM

.executable, .snippet, .library(.dynamic), .macro こうしてみると .macroってプロダクトタイプは最終的に何になるんだって感じが気になるけど。

マクロって普通のlibraryターゲットのソースコードの中についでで混ぜたりすることってできないんでしたっけ？

そこは全然わかんないんですよね。私もそんなふうにライブラリの一部として配布するものだと考えてたんですけど、まさか.macroっていうのが追加されるとは思ってなかった。

普通のtargetをmacroに入れ込めるみたいなので、targetに本体をほぼ入れておけば、ライブラリに混ぜたりもできそう

.macro ターケット(コンパイラプラグイン)はホストマシン向けにビルドされて、普通のライブラリ (macro declaration を書くとこ) はターゲットマシン向けにビルドされるものなので別ですね。 (edited)

おおたしかに

普通のtargetをmacroに入れ込めるみたいなので、targetに本体をほぼ入れておけば、ライブラリに混ぜたりもできそう

できるかもだけど、その targetが SwiftSyntax を import するようになって、おそらく必要ないものなので無駄になっちゃう。

SwiftPMのマクロサポートのピッチでました https://forums.swift.org/t/pitch-package-manager-support-for-custom-macros/63482

[Pitch] Package Manager Support for Custom Macros

Introduction Macros provide a way to extend Swift by performing arbitary syntactic transformations on input source code to produce new code. One example for this are expression macros which were previously proposed in SE-0382. This proposal covers how custom macros are defined, built and distributed as part of a Swift package. Motivation SE-03...

マクロの実装（ホスト向け）、マクロのシグネチャに出てくる型定義（クライアント向け）とでターゲットが分かれるんですね。なるほど。

サンプルだとMacroDefで定義するマクロシグネチャの右辺の#externalMacroのためにMacroImplへの依存関係がついてんのかなここはダイナミックな名前参照するだけなのかと思ってたけど、たしかにMacroImplにバグがあったりしたら気づいてほしいし、ビルド依存関係があるといえばあるのか。

マクロの実装が変わったら展開後のソースが変化するので、ビルド依存ありってことですかね。あとは単純に MacroDef が MacroImpl を使うっていうのが SwiftPM 的にわからんと macro ターゲットをビルドする理由がない。

rintaro

マクロの実装が変わったら展開後のソースが変化するので、ビルド依存ありってことですかね。あとは単純に MacroDef が MacroImpl を使うっていうのが SwiftPM 的にわからんと macro ターゲットをビルドする理由がない。

わからんとビルドする理由がない

あーたしかにそうでした。名前が書いてあるのは利用側も実装側もソースコード内部の情報だからビルドシステムとしては感知しないところだった。

https://forums.swift.org/t/se-0392-custom-actor-executors/63599

SE-0392: Custom Actor Executors

Hi everyone. The review of SE-0392: Custom Actor Executors begins now and runs through March 21, 2023. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager direc...

1

4:03 PM

カスタムエグゼキュータ審査入り

既存の見えてるインターフェースだいたいそのままって感じですね

4:53 PM

actorに個別のserialExecutor渡してinitされてるサンプルが紹介されてる、NIOのeventLoopの受け渡しがそのままactorになったという感じがしますね

ピッチともそんなに変わってないな

moveonly が入った前提になってる
Job.Priority = Task.Priority → JobPriority
runSynchronouslyのメソッドとレシーバが反転

Iceman

actorに個別のserialExecutor渡してinitされてるサンプルが紹介されてる、NIOのeventLoopの受け渡しがそのままactorになったという感じがしますね

特定のEventLoopで自身の処理を実行するオブジェクトを実装するときに、EventLoopを受け取るactorにするってパターンで書く感じになるのかな？

10:37 PM

ただそれだとステートフルになるんだよな structで書く限りステートレスなのが良いんだけどな

actorでもletなら別に良くないですか？

1:12 AM

あと、actorになるのはRequestだけで、Controller各種はそれをisolatedで受け取るパターンも考えられますね

うーん。classと同じでactor Aがプロパティのletで持ってるその先のactor Bがステートを持ってる場合とかもあるからなあ。あ、isolatedは面白いかも。

letで持ってる先のオブジェクトが状態を持つのはstructでも同じだと思います

それはそう。Aは変わらないですね Bをstructで書けるとそこが嬉しいという意味

1:19 AM

isolatedはまさにこの目的で使える機能な気がします

1:19 AM

自身をactorにしないままactor保護できるから。

https://twitter.com/giginet/status/1634059356181495809?s=20 これ皆さんどうしてるんですかね

giginet (@giginet)

単なるstatic letのNotification.Nameがmain actor isolatedなのおかしいだろ、と思って調べてたら同じこと困ってる人がいたけど、Apple様の公式回答は「全部メインスレッドから使ってくれ」とか言っていて厳しい https://t.co/5YK7SN1wsA

7:41 AM

お試しでstrict-concurrencyを引き上げて遊んでるけど、どうしようもない場面にいくつか遭遇する

7:41 AM

iOS SDKがSwiftの進化に追いついていない

発火する側は困りそうだけど購読する側はMainActorでもいいがちだから困ってなかった

Notification.Nameって文字列から自力でinitできないんだっけ？

7:44 AM

自前で別名で再定義してしまえば回避できそう・・・

任意の文字列でできるよ。今のところ面倒だけど必要な分をそうするしかないんじゃないかな。

やはりそうするしかないですよね。もしくはactor isolatedなところに固定値を退避させるとか

どうせ受け手がMain threadにディスパッチするのであれば送る側がMain threadにディスパッチしても一緒だしそれでもいい気はする。

8:22 AM

UIKitとAppKitに関係ないNotification.Nameは別になんもついてないんですよね、きっと。

受け取り側がメインスレッドで受け取るなら送信側も必ずメインスレッドで送るべきな気がする。別にNotificationCenterはスレッド切り替えの機構は持ってないと思います。

8:34 AM

複数スレッドで動くのはあくまで「任意のスレッドで送信し、送信されたスレッドで受け取ることが出来る」であって

8:34 AM

「任意のスレッドで送信し、任意のスレッドで受け取ることが出来る」ではない、と理解しています

そうそう。

任意のスレッドで送信し、送信されたスレッドで受け取ることが出来る

NotificationCenterは基本postしたスレッドで受け手のスレッドが呼ばれるという動作をするはず。 (edited)

そういう意味で、Notification.Nameがactor越境出来なくなってるのは、至極正しい実装に思えます。UIKit,AppKit関連ならMainActorであることは妥当に思える

つまり送信側が必ずメインスレッドから送るべき、ってことね。 (edited)

1

8:39 AM

今までアップルの実装も明確じゃないから安全のために結局受ける側がメインスレッドにディスパッチしてたけどそれをしなくてよくなる、はず。

observeにOperationQueue渡して、クロージャの動作するqueueを指定する機能あったと思うんですが

8:41 AM

これはNotificationCenterがネイティブ対応してると言うよりは、シンプルなラッパーなのではないかと思います。ちょっとうろ覚えだが、コールスタックはそんな感じになってたと思う

わしも詳しく調べたわけじゃないけどそうだと思う。自分でディスパッチしなくていいってだけで、クロージャの呼び出しをラップする、たぶん実装はクロージャをキューに突っ込んでるんだと思う。

これOperationQueueを渡せる機能が存在したことで、大きな誤解が広まったのでは、という感じがしてきました

なるほどー確かに

あ〜なるほど。UIKit関連のイベントはそもそも送り側も受け側もメインスレッドでやるもんか。

RxやCombineでラップする運用が長いのでそういう気持ち忘れてました (edited)

Swiftマクロ、パッケージマネージャで配布して動かせるようになったわ。 https://github.com/kishikawakatsumi/swift-power-assert-macro マクロを提供する側の定義はこんな感じで、

// swift-tools-version: 999.0 import CompilerPluginSupport import PackageDescription let package = Package( name: "SwiftPowerAssert", platforms: [ .iOS("13.0"), .macOS("10.15") ], products: [ .library( name: "SwiftPowerAssertLib", targets: ["SwiftPowerAssertLib"] ), ], dependencies: [ .package( url: "https://github.com/apple/swift-syntax.git", branch: "main" ), ], targets: [ .macro(name: "SwiftPowerAssertPlugin", dependencies: [ .product(name: "SwiftSyntax", package: "swift-syntax"), .product(name: "SwiftSyntaxMacros", package: "swift-syntax"), .product(name: "SwiftOperators", package: "swift-syntax"), .product(name: "SwiftParser", package: "swift-syntax"), .product(name: "SwiftParserDiagnostics", package: "swift-syntax"), .product(name: "SwiftCompilerPlugin", package: "swift-syntax"), ] ), .target(name: "SwiftPowerAssertLib", dependencies: ["SwiftPowerAssertPlugin"] ), ] )

マクロを使う側の定義はこう。ライブラリを依存関係に追加するだけで使う側はそれがマクロを含んでるかどうかはPackage.swiftを見るだけだとわからない。普通にライブラリを導入するのと一緒。だと思う。

// swift-tools-version: 999.0 import PackageDescription let package = Package( name: "swift-power-assert-client", platforms: [ .iOS("13.0"), .macOS("10.15") ], products: [ .executable( name: "swift-power-assert-client", targets: ["swift-power-assert-client"] ), ], dependencies: [ .package( url: "https://github.com/kishikawakatsumi/swift-power-assert-macro.git", branch: "main" ), ], targets: [ .executableTarget( name: "swift-power-assert-client", dependencies: [ .product(name: "SwiftPowerAssertLib", package: "swift-power-assert-macro") ] ), ] )

(edited)

4

1

よさそう

マクロを別に提供したいっていうのもパッケージングのやり方でどうにでもできそうだ。

999.0

@noncopyable、いつの間にか ~Copyable になってますね

2:54 AM

https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md

swift-evolution/0390-noncopyable-structs-and-enums.md at main · app...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0390-noncopyable-structs-and-enums.md at main · apple/swift-evolution

2:58 AM

~Sendable や ~Equatable の例も書かれてるし、~P の文法が新たに追加されるのかな？

2:58 AM

地味に嬉しいかも

~なのかあ。!もいいかも。

NonCopyable プロトコルみたいな否定への準拠だとだめな例が面白い extension Dictionary: NonCopyable where Key: NonCopyable, Value: NonCopyable https://forums.swift.org/t/pitch-noncopyable-or-move-only-structs-and-enums/61903/28

~ってそういう意味か。なんか〇〇Copyableみたいに思ってしまった。

1

not Copyable が読みやすくないかねえ

暗黙のconsumingとしてプロパティにセットする時と、initの引数が書いてあるな

9:08 AM

普通のfuncの引数は逆に暗黙のborrowingなんだろうな

9:09 AM

これ内部的な+1/+0ルールと一緒ですね多分

9:11 AM

クラスを渡すときにretainがされないケースとされるケースと対応してる

クラスのストアドプロパティにコピー不能型がある場合そのアクセスはborrowingにできるけど

9:24 AM

同じことをコンピューテッドプロパティからはできなくて、getがowned semanticsだからreturnするところでconsumeしようとするがクラス本体が生き続けるのでダメ (edited)

9:25 AM

将来的にはreadアクセサを使ってborrowingで返せる

9:26 AM

今までどっちのプロパティでもあまり差が無かったけどこういうところに敏感なんだな

https://forums.swift.org/t/pitch-observation-revised/63757/1

[Pitch] Observation (Revised)

Observation Proposal: SE-NNNN Authors: Philippe Hausler, Nate Cook Review Manager: TBD Status: Awaiting implementation Changes Pitch 1: Initial pitch Pitch 2: Previously Observation registered observers directly to Observable, the new approach registers observers to an Observable via a ObservationTransactionModel. These models control th...

9:31 AM

Observationも更新されました computed propertyも購読できるようにするために、

9:31 AM

extension MyObject { var someComputedProperty: Int { somePrivateProperty + someOtherProperty } nonisolated static func dependencies( of keyPath: PartialKeyPath<Self> ) -> TrackedProperties<Self> { switch keyPath { case \.someComputedProperty: return [\.somePrivateProperty, \.someOtherProperty] default: return [keyPath] } } }

1

9:32 AM

ユーザーがcomputed propertyが依存するプロパティを定義できるようですこれならたしかに動きそう

ユーザ定義ならいけそうだ

computed property の中の実装が変わったとき dependencies の方を変え忘れちゃいそうですね

AsyncStream がすごいバッファリングして continuation.finish 呼ぶまで for await を呼ばないんだけどなぜだろう。 (edited)

7:38 AM

そもそもblock callだとダメなのか...

デフォルトだとバッファリングする数が無限なんですよね https://github.com/apple/swift/blob/70b982f9ca6d6ce87df12e2a5d5654d02514b4f4/stdlib/public/Concurrency/AsyncStream.swift#L290-L294

みたいですね

あいや、そこじゃないのか。

そうかなと思ったけどbuildが完了しないとだめでblockコールするとダメだった

jobのスイッチが発生してないのかも

7:41 AM

もしconsumerが同じスレッドにスケジュールされていればTask.yield()で制御を明け渡さないとだめかも

1

Task.detachedしたら動いたのでそういうことっぽいです

7:41 AM

APIデザインむずいw

これムズいですよねぇ

Task.detached したら Consider using asynchronous alternative function 怒られた...

1

7:45 AM

参考: https://github.com/niw/AlpacaChat/blob/wip/initial/Sources/AlpacaChat/Chat.swift#L22

AlpacaChat/Chat.swift at wip/initial · niw/AlpacaChat

Contribute to niw/AlpacaChat development by creating an account on GitHub.

7:45 AM

これObjective-C++側で worker thread つくって Objective-C++ API をconcurrent にしたほうがいいのかも...

Consider using asynchronous alternative function は completionHandler じゃなくて、asyncメソッドとして呼んだら消えないですかね

let error = await self.chat.predictTokens(for: prompt, tokenHandler: { token in continuation.yield(token) }) continuation.finish(throwing: error)

(edited)

おー

7:59 AM

消えた

1

7:59 AM

 do { try await self.chat.predictTokens(for: prompt) { token in continuation.yield(token) } continuation.finish() } catch { continuation.finish(throwing: error) }

(edited)

7:59 AM

do - catch がださい

throwsも付くんだw

func predictTokens(for prompt: String, tokenHandler: ((String) -> Void)?) async throws

8:00 AM

ですね....

8:01 AM

まあでもObjective-CのAPI使う人から考えればそっちがconcurrentになってないのはきもいかな。 (edited)

Task.detachedも無限にプール持ってるわけではないので、専用スレッドを自前で管理する必要があると思いますよ

8:09 AM

他のTask.detachedされた処理が詰まると思います

なるほど

cancelに対応させるためにはどっちにしろC++側で何かする必要がある...

VariadicGenerics来ましたね func zip<each S>(_ sequence: repeat each S) where each S: Sequence

struct Pair<First, Second> { init(_ first: First, _ second: Second) } func makePairs<each First, each Second>( firsts first: repeat each First, seconds second: repeat each Second ) -> (repeat Pair<each First, each Second>) { return (repeat Pair(each first, each second)) } let pairs = makePairs(firsts: 1, "hello", seconds: true, 1.0) // 'pairs' is '(Pair(1, true), Pair("hello", 2.0))'

https://forums.swift.org/t/se-0393-value-and-type-parameter-packs/63859 (edited)

SE-0393: Value and Type Parameter Packs

Hello Swift community, The review of SE-0393: Value and Type Parameter Packs begins now and runs through April 3, 2023. For those who've followed along during the pitch phase for this feature, you'll note that the proposed syntax has changed based on implementation experience. While it is within the scope of review to consider an alternative ...

7

func < <each Element: Comparable>(lhs: (repeat each Element), rhs: (repeat each Element)) -> Bool

4:55 AM

読み始めたところだけど、結構変わったな

4:56 AM

トリプルドットじゃなくてeachキーワードだし、展開側にrepeatキーワードが付いてる

4:56 AM

初見に優しくなってそう

まあまあ形式的に書かれてるけど話がややこしくて英語が難しい・・・

1

7:47 AM

初期の案だと曖昧になるケースがあったんだけど、今回は型の型パラメータでの利用は無しの仕様で、関数の型パラメータだけだから、その手の問題は回避してるのか・・・？

repeat each is not a single production in the grammar; they don't always appear as consecutive tokens. repeat (each T, Int) means something other than (repeat each T, Int). If we substitute T for String, Bool, the first one becomes (String, Int), (Bool, Int) while the second is (String, Bool, Int).

11:56 PM

T = {String, Bool} のとき repeat (each T, Int) => (String, Int), (Bool, Int) (repeat each T, Int) => (String, Bool, Int)

1

11:56 PM

このようにrepeatがどこにかかってるかで意味が変わる (edited)

11:56 PM

https://forums.swift.org/t/se-0393-value-and-type-parameter-packs/63859/50

11:57 PM

ユーザーとしてはこの部分の理解がミソっぽい (edited)

11:59 PM

書き込みでは each T の each 要らなくない？って意見が結構多い実際意味解析としては T がパック型なのはわかってるから無くても良い文法にはできるけどチームとしてはマーキングされていることで読みやすい事が重要って意見っぽい (edited)

1

Swiftのマクロを使ってPower Assertのライブラリを作りました。 https://github.com/kishikawakatsumi/swift-power-assert Power Assertは #powerAssert(xs.contains(4)) | | | | false 4 [1, 2, 3] ^ こんな感じで１つのAssert関数だけでリッチなAssertの情報を出力してくれるというものです。将来の新機能であるマクロを使っているのでDevelopment Snapshotのツールチェーン（ https://www.swift.org/download/ ）をインストールする必要がありますが、それだけで実際のプロジェクトにテストフレームワークとして組み込んで使えます。 Swiftマクロは現在は型情報を扱えないので、コードパターンをヒューリスティックに解析していろいろなパターンに対応しています。ただ、Assert関数にはほぼどんなコードでも渡せるので対応できてないパターンがまだまだあります。もしよかったらこのライブラリを使ってみていろいろなパターンを試してください。コンパイルエラーが起こったり、正しく動いてなさそうな例があったら教えてください。

GitHub - kishikawakatsumi/swift-power-assert: Power Assert in Swift.

Power Assert in Swift. Contribute to kishikawakatsumi/swift-power-assert development by creating an account on GitHub.

Tuple of value pack expansion

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

1

6

@Kishikawa Katsumi PowerAssert って現状ざっくり

PowerAssert.Assertion("foo.bar(baz)") .assert(foo.bar.baz()) .capture(expression: foo.bar(baz), column: 4) .capture(expression: foo, column: 0) .captuer(expression: baz, column: 8)

みたいに展開するとおもうんですが、下みたいにしたら、副作用ある式でも対応できて評価が一回で済むかなと思ったのですが、

PowerAssert.Assertion("foo.bar(baz)") { (values: inout [Value]) throws -> Bool in func _capture<T>(_ expr: @autoclosure () throws -> T, column: Int) rethrows -> T { let val = try expr() values.append(Value(value: _toString(val), column: column)) return val } return try _capture(_capture(foo, column: 0).bar(_capture(baz, column: 8)), column: 4) }

なにか落とし穴あります？ (edited)

なるほど。 foo.bar(baz) の評価木の各ノードに capture を差し込んだ形だ

omochimetaru

なるほど。 foo.bar(baz) の評価木の各ノードに capture を差し込んだ形だ

言語化感謝

1

意図としては下の行を増やさないようにという設計があります。

1:34 AM

ただマクロで下の行の行番号が変わらないなら問題ないすね。テストの結果の出力で行番号が変わるとわからなくなるかなという昔の設計を引きずってるやつです。

1:34 AM

tryが簡単になるのはとてもいいですね。tryの扱いは難産だったので。

あーなるほど、#line を維持したかったということですね

1:36 AM

tryは試してないのでそれで行けるかどうか確信ないです

了解です。試してみます。めっちゃ感謝です

try の苦労って throws かどうかを知らずに try を書きたいってことだと思うので、無条件 throws な関数適当に作っておけば func _throwsShim<T>(_ value: T) throws -> T { value } func test() throws -> Int { return try _throwsShim(1) } とかで良さそう、そしたら _capture は @autoclosure も rethrows もいらず, (edited)

2:03 AM

 func _capture<T>(_ value: T, column: Int) -> T { values.append(Value(value: _toString(value), column: column)) return value } return try _throwsShim(_capture(_capture(foo, column: 0).bar(_capture(baz, column: 8)), column: 4))

とか。

おお、ダミーのthrows関数を挟むと警告なしにtryが書けるんですね。

2:11 AM

そうすると全部にtryが書けて try! JSONEncoder().encode(landmark) == #"{"name":"Tokyo Tower"}"#.data(using: String.Encoding.utf8) ^ のパターンで右辺を独立に評価したときにtryがないとコンパイルエラーっていうのが簡単に扱えそうです。 (edited)

あ～なるほど　tryが根本にかかってるときに、部分式がthrowsかどうかがわからないから難しかったのか。

そうなんす。今は左側のノードにtryがあったらtryを書くことで妥協しています。余分なtryを書くぶんにはエラーにはなりませんが、全部にやると警告だらけになるので、というバランスです。

タプルの続き https://forums.swift.org/t/tuple-of-value-pack-expansion/64269

co-author: Holly Borla Introduction Building upon the Value and Type Parameter Packs proposal SE-0393, this proposal enables referencing a tuple value that contains a value pack inside a pack repetition pattern. Motivation When a tuple value contains a value pack, there is no way to reference those pack elements or pass them as a value pack ...

元の話と同じに見える・・・

3:20 AM

func example<each U>(packElements value: repeat each U, tuple: (repeat each U)) { print((repeat each value)) print((repeat each tuple)) print((repeat (each value, tuple))) print((repeat (each value, each tuple))) } example(packElements: 1, 2, 3, tuple: (4, 5, 6)) // Prints the following output: // (1, 2, 3) // (4, 5, 6) // ((1, (4, 5, 6)), (2, (4, 5, 6)), (3, (4, 5, 6))) // ((1, 4), (2, 5), (3, 6))

3:21 AM

これ4通り読み取れてればユーザとしては良さそう

@swift-5.8.1

func f<T>(_ expr: T) -> T { let val = expr return val } let i = 0 _ = f([0]).firstIndex(of: 0) == i _ = f([0]).firstIndex(of: 0) != i

Kishikawa Katsumi

@swift-5.8.1

func f<T>(_ expr: T) -> T { let val = expr return val } let i = 0 _ = f([0]).firstIndex(of: 0) == i _ = f([0]).firstIndex(of: 0) != i

exit status: 1 with

<stdin>:8:12: error: value of optional type 'Int?' must be unwrapped to a value of type 'Int' _ = f([0]).firstIndex(of: 0) != i ^ <stdin>:8:12: note: coalesce using '??' to provide a default when the optional value contains 'nil' _ = f([0]).firstIndex(of: 0) != i ^ ?? <#default value#> <stdin>:8:12: note: force-unwrap using '!' to abort execution if the optional value contains 'nil' _ = f([0]).firstIndex(of: 0) != i ^ !

@swift-4.2.4

func f<T>(_ expr: T) -> T { let val = expr return val } let i = 0 _ = f([0]).firstIndex(of: 0) == i _ = f([0]).firstIndex(of: 0) != i

2:39 PM

^ Swift 5から f([0]).firstIndex(of: 0) == i は合法だけど、 f([0]).firstIndex(of: 0) != i は（== と!=の違い）コンパイルエラーになるのだけどどうしてだろう？

Swift 4ではどっちもコンパイル可能なことは独自に確認しました。

@swift-5.8.1

func f<T>(_ expr: T) -> T { let val = expr return val } let i = 0 _ = f([0]).firstIndex(of: 0) == i _ = f([0] as [Int]).firstIndex(of: 0) != i

(edited)

kebo

@swift-5.8.1

func f<T>(_ expr: T) -> T { let val = expr return val } let i = 0 _ = f([0]).firstIndex(of: 0) == i _ = f([0] as [Int]).firstIndex(of: 0) != i

(edited)

no output (edited)

こう型アノテーションすると通るんで [0] の型推論の問題なんですかね (T.Index の) (edited)

そんな感じっぽい挙動ですよね。i をリテラルにしても通りました。

func f<T>(_ expr: T) -> T { let val = expr return val } func f<T>(_ expr: [T]) -> [T] { let val = expr return val } let i = 0 _ = f([0]).firstIndex(of: 0) == i _ = f([0]).firstIndex(of: 0) != i

func f<T>(_ expr: [T]) -> [T] のオーバーロードを用意してやるのでもいけた。呼び出す側のコードを変更しない解決方法ならこれがよさそう。

1

Array 以外でも再現するので (Stringと Int 確認しました)、リテラル系はとりあえずオーバーロード用意しておいたほうが良さそうですね。とはいえユーザ定義の *LiteralExpressible だと失敗しそう。 TypeChecker の人がバグと判断するかはわかりませんが、issueたてていただけるとありがたいです。 @swift-5.8.1 func id<T>(_ val: T) -> T { val } func test(c: Character) { id("").first != c } (edited)

rintaro

Array 以外でも再現するので (Stringと Int 確認しました)、リテラル系はとりあえずオーバーロード用意しておいたほうが良さそうですね。とはいえユーザ定義の *LiteralExpressible だと失敗しそう。 TypeChecker の人がバグと判断するかはわかりませんが、issueたてていただけるとありがたいです。 @swift-5.8.1 func id<T>(_ val: T) -> T { val } func test(c: Character) { id("").first != c } (edited)

exit status: 1 with

<stdin>:4:10: error: value of optional type 'String.Element?' (aka 'Optional<Character>') must be unwrapped to a value of type 'String.Element' (aka 'Character') id("").first != c ^ <stdin>:4:10: note: coalesce using '??' to provide a default when the optional value contains 'nil' id("").first != c ^ ?? <#default value#> <stdin>:4:10: note: force-unwrap using '!' to abort execution if the optional value contains 'nil' id("").first != c ^ !

個人的には適用できる Solution があるのに見つけられてないのでバグと主張していいと思います。

どうもどうも。ありがとうございます。Issueを作ります。

Array 以外でも再現するので (Stringと Int 確認しました)、リテラル系はとりあえずオーバーロード用意しておいたほうが良さそうですね。

なるほどこれは気づいてなかったです。あとOptionalも同様にオーバーロード必要でした。 (edited)

rintaro

@Kishikawa Katsumi PowerAssert って現状ざっくり

PowerAssert.Assertion("foo.bar(baz)") .assert(foo.bar.baz()) .capture(expression: foo.bar(baz), column: 4) .capture(expression: foo, column: 0) .captuer(expression: baz, column: 8)

みたいに展開するとおもうんですが、下みたいにしたら、副作用ある式でも対応できて評価が一回で済むかなと思ったのですが、

PowerAssert.Assertion("foo.bar(baz)") { (values: inout [Value]) throws -> Bool in func _capture<T>(_ expr: @autoclosure () throws -> T, column: Int) rethrows -> T { let val = try expr() values.append(Value(value: _toString(val), column: column)) return val } return try _capture(_capture(foo, column: 0).bar(_capture(baz, column: 8)), column: 4) }

なにか落とし穴あります？ (edited)

https://github.com/kishikawakatsumi/swift-power-assert/pull/9 やってみました。いくつか元の処理だとできてた部分がうまく動かない部分がまだあるのですが逆に今まで無理してた部分が自然になったところも多いのと、コード生成の処理がかなりシンプルになったのでこちらの方が良さそうです。現状うまくいかなくない部分も調整すればたぶん解決できそう。 Positive: コード生成の処理が簡単になった。 Positive: 評価が一回になったので副作用のある式でもダンプした値と実際の値が一致するようになった。 Positive: "...".data(using: .utf8))の.utf8のような独立して評価すると型情報が足りないような式も全体で評価できるから型推論が効いてしてコンパイルできるようになった。 capture("...").data(using: capture(.utf8))みたいなコード生成になってコンパイルできる。 Positive: SyntaxRewriterを使って〜〜ExprSyntaxを対象にする、としたので今までのコードパターンから考えるやり方よりシステマチックにできるようになった。 Neutral: 動作したときに評価されなかった値はそもそも実行されないので出力されない。（例）三項演算子の片方、|| で短絡評価された場合の残りの式など。 (edited)

Changed to a code generation that does not affect the evaluation of...

Changed to a code generation that does not affect the evaluation of expressions containing side effects. Before: PowerAssert.Assertion("foo.bar(baz)") .assert(foo.bar.baz()) .capture(...

一番困っているのは c?.property.performAction() っていうOptional Chainを含む式は次のようなコードが生成されるんですけど、

PowerAssert.Assertion("", file: "", line: 0) { $0.capture( $0.capture($0.capture($0.capture(c.self, column: 13)?, column: 13).property, column: 16) .performAction(), column: 25) }

この場合、 $0.capture(c.self, column: 13)?, column: 13).property, column: 16).performAction(), column: 25) の.performAction() は?.performAction()としないとコンパイルエラーになるんですよね。そのもともと付いてなかった?をどう付けたらいいものかっていうところが困っています。

c?. ←ここから c がオプショナルであることがわかるから・・・ func captureOptional<T>(_ value: T?, column: Int, next: (T) -> Void) { ... } ↑こういうユーティリティを追加して captureの代わりにcaptureOptionalを適用するようにして

PowerAssert.Assertion(...){ (PA) in PA.captureOptional(c, column: 1) { (c) in PA.capture(c.property, column: 3).performAction(), column: 25) } }

こんな感じにして、 c が nil のときは .property も .performAction も評価されない (||と同じ) とする・・・？

2:03 AM

生成されたコードがややこしいので、 capture も継続渡しに修正して

2:04 AM

PowerAssert.Assertion(...){ (PA) in PA.captureOptional(c, column: 1) { (c) in PA.capture(c.property, column: 3) { (property) in PA.capture(property.performAction(), column: 25) } } }

↑こうしたほうが、元の式を左から右に書き下せて良いかもしれませんね。

2:05 AM

このアプローチだと、もし元の式が c?.property?.performAction() と、 ?. が更に入っていた場合も

PowerAssert.Assertion(...){ (PA) in PA.captureOptional(c, column: 1) { (c) in PA.captureOptional(c.property, column: 3) { (property) in PA.capture(property.performAction(), column: 25) } } }

↑このようにうまく対応付けられるはず (edited)

ありがとう、やってみる。

この用途なら手書きの継続渡しじゃなくて例外でも良さそう

たしかに！

2:18 AM

throw NilCaptureError() して、 PoserAssert.Assertion で catch してしまうのね。 (edited)

そうそう

そのほうが現在の実装から大きく変更せずに対応できそう。

うまい、なるほど

2:20 AM

?.で短絡される処理とtryで抜け出す範囲が一致しててうまくいく

Kishikawa Katsumi

ありがとう、やってみる。

もうやってみちゃってるかもしれませんがnilだったら例外投げる方式も検討したほうが良いかも (edited)

まだ取りかかってないから大丈夫

️

なるほどーいろいろな罠と効果があっておもしろいですね。

Neutral: 動作したときに評価されなかった値はそもそも実行されないので出力されない。

これはちょっと思ってたんですが、評価対象のexpr位置はわかっているので $0.capturing(columns: [13,16,25]) とか予約しておいて、capture() 呼ばれなかったところは評価されなかったことがわかるようにすると、不具合っぽくないし、テスト結果としても有用かなと思いました。 (edited)

あーそれは良さそう。やってみます。作ってて実装もれなのかかなりわかりにくかったんですよね。自分でもなんでここでないんだろうって何度もハマった。

3:31 AM

あとは

error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions

これが新しく出るようになったパターンがあるのですが、調べようと思って普通のプロジェクトにCopy&Pasteすると特に問題なくコンパイルできたりしてまだ詳細がわかってないのでわかったらまた相談に乗ってください。（ツールチェーンの違いとかでもなかった。あとはXCTestの環境かどうかとXcodeとSwiftのコマンドラインとの違い、くらいかなあ。）

むむー type checker が弱音を吐くパターンは出てきそうですねー

Yuta Saito

この用途なら手書きの継続渡しじゃなくて例外でも良さそう

foo?.bar() == expected みたいなときに throw しちゃうと途中で終わっちゃうかも。

1

foo?.bar() の範囲で do-catch しなきゃいけないのか。

3:39 AM

でもそれには文を分けないといけない・・・

簡単な例だと下記のコードは let initializer: (Int) -> String = String.init #expect([1, 2, 3].map(initializer).reduce("", +) == "123", verbose: true) こういうコードを生成して

PowerAssert.Assertion( #"#powerAssert([1, 2, 3].map(initializer).reduce("", +) == "123")"#, message: "", file: #""PowerAssertTests/PowerAssertTests.swift""#, line: 1712, verbose: true ) { $0.capture( $0.capture( $0.capture( $0.capture( [$0.capture(1, column: 14), $0.capture(2, column: 17), $0.capture(3, column: 20)], column: 13 ).map($0.capture(initializer.self, column: 27)), column: 23 ).reduce($0.capture("", column: 47), +), column: 40) == $0.capture("123", column: 57), column: 54) }.render()

swift test で実行した場合はunable to type-checkなんですけど手元の別のXcodeプロジェクトにコピーした場合は問題なかったり。よくわからない。

PowerAssert.Assertion("", file: "", line: 0) { $0.capture( $0.capture($0.capture($0.capture(c.self, column: 13)?, column: 13).property, column: 16) .performAction(), column: 25) }

これって $0.capture($0.capture($0.capture(c.self, column: 13)?, column: 13). がコンパイル通らないので

3:40 AM

optional チェーンはcapture 挟まないようにして

 $0.capture( $0.capture($0.capture($0.capture(c.self, column: 13), column: 13).property, column: 16)? .performAction(), column: 25)

ではだめですか？ (edited)

func optionalCatch<R>(body: () throws -> R) { ... } こうしておいて capture( optionalCatch { try capture(captureOptional(foo).bar) } ) == capture( expected ) こうか (edited)

rintaro

PowerAssert.Assertion("", file: "", line: 0) { $0.capture( $0.capture($0.capture($0.capture(c.self, column: 13)?, column: 13).property, column: 16) .performAction(), column: 25) }

これって $0.capture($0.capture($0.capture(c.self, column: 13)?, column: 13). がコンパイル通らないので

あ、これ整形のときのミスですね。ごめんなさい。 $0.capture($0.capture(c.self, column: 13)?.property, column: 16).performAction() 生成されたコードはこうでした。

あーなるほど。

で、 $0.capture($0.capture(c.self, column: 13)?.property, column: 16)?.performAction() と?.performAction()にハテナが必要。

その performAction にハテナが必要なことは c?.property のハテナからわかりません？ (edited)

なんか syntactic に?つける手もある気がする (edited)

3:50 AM

子に optional chain があったら親に伝播させていけばよいから。

a.b.c?.d.e.f みたいなとき、分解して考えると ?.d と ?.e と ?.f が必要

こういうSyntax Treeがくる。

3:52 AM

ハテナを追加でつけるならOptionalChainingExprをvisitしたときに上のノードを辿るかFunctionCallExprをvisitしたときに子を検査する、かなあ。

visit の帰りでラップしていけば親に状態伝播しながらどうラップするか決められませんか？

やってみます。

Swiftマクロ改めて思ったのは仕様は問題ないと思うけどSwiftSyntaxがやっぱり難しい。そこがいちばん問題になると思う。ここ１、２年でだいぶ変わっててChatGPTさんもあまり助けてくれないし。

1

4:05 AM

マクロがリリースされたらノウハウの共有も進むかもしれない。

ハテナを付けるっていうやり方でとりあえずうまくいった気がします。みなさんどうもありがとう

https://github.com/kishikawakatsumi/swift-power-assert/pull/11

Fixed a problem where code generation would fail for expressions co...

Fixed a problem where code generation would fail for expressions containing an optional chain, like the following: var c: SomeClass? #expect(c?.property.performAction() == nil, verbose: true) c = ...

1

8:41 AM

そういえば細かい部分で結果が変わったことでいうと

let zero = 0 let one = 1 let two = 2 let three = 3 let array = [one, two, three] #expect(array.firstIndex(of: zero) != two, verbose: true)

8:42 AM

のようにOptionalとNon-optionalを比較すると #expect(array.firstIndex(of: zero) != two) | | | | | | nil 0 | Optional(2) [1, 2, 3] true のように両方Optionalになる（例だとtwoは実際にはOptionalではない。）というのは確かに実際には両方Optionalに推論されるんだなというのがわかっておもしろかった。

rintaro

Array 以外でも再現するので (Stringと Int 確認しました)、リテラル系はとりあえずオーバーロード用意しておいたほうが良さそうですね。とはいえユーザ定義の *LiteralExpressible だと失敗しそう。 TypeChecker の人がバグと判断するかはわかりませんが、issueたてていただけるとありがたいです。 @swift-5.8.1 func id<T>(_ val: T) -> T { val } func test(c: Character) { id("").first != c } (edited)

https://github.com/apple/swift/issues/65061 報告しました。現象が奇妙だから説明がだいぶ難しかった。

Type inference fails when a literal is passed to a generic function...

Description When I pass a literal expression as an argument to a generic function and compare its return value to another literal with a binary operator, the == case is not a problem, but ! = cause...

味わい深い。不思議なバグですね。

さっぱりわからん。困ってる人もほとんどいないんじゃないか。ただ私はめっちゃ困っている。

11:01 AM

バージョンをいろいろ変えて試したりしたところ、どうも==と !=では型推論の処理が違うところ通るみたいだな。

Equatable の requirement が == だけなので、 != と違うのはたぶんそう。 (edited)

1

var output: TextOutputStream = "" print("", to: &output) ^ なんかこのコード、コンパイラがSegmentation Faultしないですか？ウチの環境のせいかもしれないからちょっと自信がない。

var output: some TextOutputStream = "" print("", to: &output) someつけたら通ったからなんかその辺の問題か。

main だと SILGen で assert に引っかかりますね

Assertion failed: (def->getFunction() == &F && "def of root local archetype is in wrong function"), function addTo, file SILInstructions.cpp, line 118.

確認どうもです。報告しておきます

1

https://forums.swift.org/t/macros-accessing-the-parent-context-of-a-syntax-node-passed-to-a-macro/64443/14 マクロの親のノードが取れる要件、絶対にあったほうがいいんだけど明確なユースケースっていうとパッと出てこないな。

[Macros] Accessing the "parent context" of a syntax node passed to ...

To me, there are currently three major categories of information not accessible by macros: Lexical context Type information about sub-expressions Reflection of arbitrary types It looks like the proposed addition would be sufficient to solve the first case, at least for the macros I have experimented with. I don't have a preference as to wheth...

関数に渡された値をログに出力したい時に使えるみたいな書き込みがありましたね。

func myMethod(_ text: String, num: Int, flag: Bool) { #debugLog("message") } // myMethod("text", num: 4, flag: true): message

https://forums.swift.org/t/macros-accessing-the-parent-context-of-a-syntax-node-passed-to-a-macro/64443/3 (edited)

[Macros] Accessing the "parent context" of a syntax node passed to ...

Here's a use case: I have a theoretically-working prototype* of a macro that prints the enclosing context for logging. For instance, if you had func myMethod(_ text: String, num: Int, flag: Bool) { #debugLog("message") } The macro would expand to printing myMethod("text", num: 4, flag: true): message to the console, or whatever the actua...

これはいい例ですよね。パラメータの型や数で記述変えなくていい。

1

https://github.com/apple/swift/pull/65299/files マクロで #assert が使えなかったのはStatic Assertっていう別の機能とぶつかってたかららしい。

[5.9] Disable lexing #assert unless experimental static assertion...

#assert should be usable as a macro name, but the experimental feature was getting in the way. Fixes rdar://107894668.

そういえばコンパイル時計算/定数とコンパイル時assertion途中までやってましたねでも #assert のパーサーの対応はそれより昔からあったような気がする初期から気持ちだけあって進んでなかったようなものかも

なるほどねえ。どこかで特別扱いしてるんだろうとは思ってたけどマクロじゃない機能のところでぶつかってるとはわからなかった。

4:30 AM

でもStatic AssertがAcceptedになったらまたそっち優先になりそうだな。今のところ進んでなさそうだけど

その問題はありますよねｗ

4:32 AM

コンパイル時assertion導入するならコードとしては #assert(foo == 3) がやっぱ一番キレイだと思うし・・・

4:32 AM

C++だと static_assert だけど、 # に、コンパイル時パラメータってニュアンスがありますからね。

いやー、今回のマクロで # はマクロ展開のものっていう感じになるので、#assert コンパイル時assertion に #assert 使うことは無いと思いますよ。もしあったとしてもこの Doug の patch によって #assert マクロが一般開放されたので、組み込みマクロによって source breaking にならないように配慮されるはず (edited)

#if とかがあるので、 # はコンパイル時評価のもので、マクロはその一部って関係じゃないですかね？ (edited)

4:37 AM

他にあるかな・・・ #file とかは確かにマクロとして改められた。

4:37 AM

#selector これはマクロにできそうな気がするなｗ (edited)

4:38 AM

if #available もあった

組み込みマクロによって source breaking にならないように配慮されるはず

たとえば #assert(...) はマクロとして parse されて、名前解決により、組み込み assertion か一般マクロかに解決されるとか

4:41 AM

#if などの組み込み #... がいくつか残るのは確かですが、僕の予想として、今後追加されるものは一般マクロで実現出来ないものはそれなりの特別な命名をされるんじゃないかと思っています。

4:41 AM

といっても #staticAssert() 程度だとおもいますけどｗ

なるほど。 attached macroもあるから、 #foo と @foo がユーザーに荒らされまくるから、公式の機能追加の命名はだいぶ慎重になりそうだなあ・・・

それなら#assertにしようかな。ForumにDougが書いてくれたんでそれに返信する形で聞こうかと思ってた。

4:50 AM

まあ聞いておこう。

4:51 AM

そういえばマクロも名前空間ってあるんだっけ。 #PowerAssert.assert() って書いてモジュールで区別できるのかな。

#PowerAssert まででマクロと認識されてしまい、.assert() はその結果に対する普通のメソッド呼び出しになります。

そうなんだ。そうするとマクロの名前は結構取り合いか。。。

手元で #powerAssert を定義して、実装を転送する事はできる？ユーザーにはできないんだっけ？

あ、マクロは確かにエイリアスは作りやすいっすね。

@freestanding(expression) public macro powerAssert( _ expression: @autoclosure () throws -> Bool, _ message: @autoclosure () -> String = "", file: StaticString = #filePath, line: UInt = #line, verbose: Bool = false ) = #externalMacro(module: "PowerAssertPlugin", type: "PowerAssertMacro")

(edited)

4:54 AM

↑これだけ書く。 (edited)

@~~~はモジュール名で区別できましたよね。そっちと合ってるほうがいい気がする。

#externalMacro( は module: から指定ですね

#externalMacro をクライアント側で書いて、同じ名前で上書きできるならいいけど、

4:56 AM

違う名前にする必要があるなら #PowerAssert.assert() `のほうがいいんじゃないかな。

#PowerAssert まででマクロと認識されてしまい、.assert() はその結果に対する普通のメソッド呼び出し

ごめんなさい動作未確認。いずれにしても #ModuleName.macroName できるべきだと思うので、確認してできなかったらIssue あげていただけると。

了解です

5:01 AM

4/6あたりのツールチェーンだと無理そうですね。#PowerAssertってマクロを探そうとする。

@ もマクロはダメみたいですね。 (edited)

PropertyWrapperって@Module.Name できたのか・・・

typealiasも効きますからね

Property WrapperってTypealiasできるんですか。 (edited)

型パラメータを複数持ったproperty wrapper作って、一部のパラメータだけ固定した版をtypealiasで作るみたいな事ができる

5:13 AM

似てるけど微妙に動作が違う複数のwrapperを作りたい時、差分の部分をプロトコルと型に切り出したりできて便利 (edited)

5:14 AM

例 https://github.com/omochi/TypeScriptAST/blob/main/Sources/ASTNodeModule/Node/GenericASTNodeStorage.swift#L122

なるほど！ジェネリックなProperty Wrapperを用意しておいてTypealiasで使いやすく特化したやつを提供できるんすね。

1

5:32 AM

Attached Macroだと同じことができたらよさそうな気もする。これは気がするだけ。

5:35 AM

MyCodableみたいなマクロを提供するとすると名前はモジュール名.Codableにしたい、みたいなことがあるかな。

5:40 AM

あ、TypeAliasの話じゃなかった。

5:41 AM

TypeAliasはパッと思いつかんな。

抽象的なマクロを作って挙動の変更を注入するみたいな事ですよねえ

5:44 AM

#externalMacro(module: "PowerAssertPlugin", type: "PowerAssertMacro") ↑今だと根本が結局これだからなんもできなさそうですけど・・・

5:47 AM

例えば、 (意味があるかは別として) #nyasuffix("hello") -> "hello nya" #wansuffix("hello") -> "hello wan" ↑みたいなやつを

macro nyasuffix(...) = #externalMacro(module: ..., type: "GenericSuffix", suffix: "nya") macro wansuffix(...) = #externalMacro(module: ..., type: "GenericSuffix", suffix: "wan")

↑みたいにexternalMacroの部分でパラメータを渡すみたいな

マクロを書くマクロ…

マクロプラグインの実装側でマクロを使うのは普通にできそう。

5:50 AM

↑はただの値パラメータをマクロプラグインに渡す例だけど、「マクロを渡して完成する高階マクロ」みたいなものは更に複雑な仕様が必要そうユースケースしらんけどｗ

5:51 AM

attached macroとかの場合で @FooBar って書いたら @Foo @Bar の2つになるみたいなのもあるかなこれは今も実装可能だな (edited)

たしかにマクロをまとめるマクロはほしいケースがありそうだな。要するに typealias Codable = Decodable & Encodable ができるようになるってことね。

ですね

6:17 AM

今だと @Codable マクロを作って実装として @Decodable と @Encodable をつけて中身をそのまま出すってやる感じですね

6:17 AM

合成の詳細がプラグインのマクロロジックとして埋め込まれるから

6:17 AM

まあできるけど見通しはだいぶ悪そう

なるほどProperty WrappersやResult Buildersと見た目が似てるから同じことできたらいいように見えるけど実際は難しいな。

6:23 AM

同じように使えないなら見た目を似せないほうがいいというセオリーもあるけど。

https://forums.swift.org/t/introducing-swift-power-assert/64197/9 Compile time assertが正式になったとしても違う構文になるとのこと。

Introducing Swift Power Assert

If compile time assertions are accepted some day, they could use a different syntax. Doug

おお、、、

その時はなんかシュッとした構文をおさえてほしいな

https://twitter.com/swiftlang/status/1651338724230463489?s=46&t=x82HmLxu4d0JVtr__-b65Q

Swift Language (@SwiftLang)

A new version of Foundation launched today as an open source project, written in Swift. This project provides a single, cross-platform implementation and shows significant performance improvements. https://t.co/ItMd423gvz

Likes

307

11:36 PM

Swift Foundationきたで

11:42 PM

In benchmarks parsing test data, there are improvements in decode time from 200% to almost 500%.

11:42 PM

jsondecoder速いらしいこれは嬉しい

2

5

2023前半は品質アップとコミュニティからのAPI追加をやって、URLやFileManagerは2023後半らしいながいなあー

 @available(macOS 10.10, iOS 8.0, watchOS 2.0, tvOS 9.0, *) public func components<T : StringProtocol>(separatedBy separator: T) -> [String] { #if FOUNDATION_FRAMEWORK if _foundation_essentials_feature_enabled() { if let contiguousSubstring = _asContiguousUTF8Substring(from: startIndex..<endIndex) { let options: String.CompareOptions if separator == "\n" { // 106365366: Some clients intend to separate strings whose line separator is "\r\n" with "\n". // Maintain compability with `.literal` so that "\n" can match that in "\r\n" on the unicode scalar level. options = [.literal] } else { options = [] } do { return try contiguousSubstring._components(separatedBy: Substring(separator), options: options) } catch { // Otherwise, inputs were unsupported - fallthrough to NSString implementation for compatibility } } } return _ns.components(separatedBy: separator._ephemeralString) #else do { return try Substring(self)._components(separatedBy: Substring(separator), options: []) } catch { return [String(self)] } #endif }

12:07 AM

旧Foundationがある場合/ない場合のコンパイル時分岐があって、ある場合に、swift-foundationを使うかどうかの実行時分岐があるようだ

12:08 AM

でも　「ない場合」と、「ある場合で使う場合」の実装が違うのはどういうことだ。

12:09 AM

FOUNDATION_FRAMEWORK は、旧があるかどうかじゃなくて、旧版と互換モードってことか・・・？

12:12 AM

 A JSONMap is created by a JSON scanner to describe the values found in a JSON payload, including their size, location, and contents, without copying any of the non-structural data. It is used by the JSONDecoder, which will fully parse only those values that are required to decode the requested Decodable types.

12:12 AM

中間データ構造のJSONオブジェクトを作らないっぽいな

12:15 AM

12:16 AM

JSONの構造だけ先にパースして、その構造を高速に巡回するためのオフセットテーブルだけを作るっぽい

12:16 AM

実際の値のデコードは Decodable が要求する時にやる

12:18 AM

なるほどなあ　こうやればよかったのか

 func testBasic() throws { let compareTo = 2 let predicate = Predicate<Object> { // $0.a == compareTo PredicateExpressions.build_Equal( lhs: PredicateExpressions.build_Arg( PredicateExpressions.build_KeyPath( root: $0, keyPath: \.a ) ), rhs: PredicateExpressions.build_Arg(compareTo) ) } try XCTAssertFalse(predicate.evaluate(Object(a: 1, b: "", c: 0, d: 0, e: "c", f: true, g: []))) try XCTAssertTrue(predicate.evaluate(Object(a: 2, b: "", c: 0, d: 0, e: "c", f: true, g: []))) }

12:39 AM

例の Predicate も入ってる

12:39 AM

マクロはまだ入ってないみたいでASTが手書きされてるけどｗ

12:40 AM

 // Hiragana, Katacana -- case not affected test("ァィゥㇳ゚ェォ ヶ゜ アイウエオ", "ァィゥㇳ゚ェォ ヶ゜ アイウエオ") test("ぁぃぅぇぉ ど ゕゖくけこ", "ぁぃぅぇぉ ど ゕゖくけこ")

12:40 AM

typoみつけた→Katacana

public struct PredicateBindings { // Store as a values as an array instead of a dictionary (since it is almost always very few elements, this reduces heap allocation and hashing overhead) private var storage: [(id: PredicateExpressions.VariableID, value: Any)] public init<each T>(_ value: repeat (PredicateExpressions.Variable<each T>, each T)) { storage = [] _ = (repeat storage.append(((each value).0.key, (each value).1))) }

12:47 AM

variadic genericsだ

Swift 5.9が必要なのね。

落としてきてXcodeに突っ込めばいいらしいです

へえ。

1:11 AM

じゃあSwift 5.9を要求するSwift Packageが使えるようなツールチェーンなんだ。

ですね

今まではSwift 5.9入れてもSwift Package ManagerはXcodeからは使えなかった気がする。

ツールチェーン入れてもそのへん怪しいがちですね。

Predicatesって何かしら？新機能でそんなんあったんだ。

NSPredicateをモダンにしたいやつ

1

へえ。Type Safeなクエリが作れるわけね。

https://discord.com/channels/291054398077927425/291054454793306112/1052600428988219452 ↑以前ちょっと話しました (edited)

理解した。めっちゃいいやん。

arrayをfilterするとかならクロージャで十分なので使い所が難しいですけどね

この展開方法はネストがすぐ深くなって型推論がタイムアウトになりがちだけど大丈夫かな。

1:16 AM

適当に変数に逃すのかもしれないけど。

predicateにするメリットはシリアライズできるので他のマシンとかで実行できるところ・・・

Kishikawa Katsumi

この展開方法はネストがすぐ深くなって型推論がタイムアウトになりがちだけど大丈夫かな。

現状はマクロが入ってなくてテストコードはマクロ展開後の状態を手書きしているので、そのようなテストコードが書いてある規模の式なら問題なさそう複雑な式だと駄目っていうのは起きそうですねえ・・・ (edited)

リテラルを混ぜるとけっこうすぐ起こせる気がするけどまあ今度試してみよう。

PredicatesはORMで使われそうですね

2:21 AM

元々NSPredicateもCoreDataでは良く使ったし

rintaro

#PowerAssert まででマクロと認識されてしまい、.assert() はその結果に対する普通のメソッド呼び出し

ごめんなさい動作未確認。いずれにしても #ModuleName.macroName できるべきだと思うので、確認してできなかったらIssue あげていただけると。

https://github.com/apple/swift-syntax/issues/1594 マクロをモジュール名で修飾できるようにしてほしい、っていうの報告した。

Swift macros should be able to use module names as namespaces · Iss...

Description The way Swift macros are syntactically defined and their appearance is quite similar to property wrappers and result builders, especially in the case of attached macros. Property wrappe...

3

1

Since name lookup happens inside semantic analysis, which is done after parsing, I’m moving this to the swift repo.

SwiftSyntaxより後の問題たしかに。

https://forums.swift.org/t/pitch-init-accessors/64881

[Pitch] init accessors

Hello, Swift Evolution! Property wrappers have the ability to abstract the storage of a property, including bespoke definite initialization support: @propertyWrapper struct Wrapper { var wrappedValue: T } struct S { @Wrapper var value: Int init(value: Int) { self.value = value // Re-written to self._value = Wrapper(wrappedValue: v...

3

5:23 AM

ホーリー&ドーグから面妖な提案が出た

5:24 AM

パッとみよくわからんかったので後でちゃんと読む

これが許されるならジェネリックなsetterも欲しい気がしてきた

11:31 AM

var foo: AnyPublisher<Int, Error> { set { (newValue: some Publisher<Int, Error>) in _foo = newValue.eraseToAnyPublisher() } }

11:31 AM

みたいな

読んできた

2:48 PM

property wrapperがついてても、ついてないラップされてるプロパティを初期化できるのは、wrapperの初期化に書き換えてくれるからなんだけど

2:48 PM

そのような挙動を任意のcomputed propertyに対して書けるようにして

2:49 PM

initでcomputed propertyに代入すれば、そのinit accessor内部で初期化するstored propertyを初期化した扱いになる

2:50 PM

これがないと、Ovservableマクロのように、ユーザー定義したstored propertyをcomputed propertyに変換してしまうマクロを使った時に、

2:51 PM

ユーザーはマクロが生成する新しいstored propertyを初期化しないといけなくてめちゃくちゃ使いにくいから

2:51 PM

この機能をいれることでマクロがinit accessorも入れることによって

2:52 PM

ユーザーはstored propertyが消された事を気にしないで普通な感じでinitが書けるというわけだな

Iceman

var foo: AnyPublisher<Int, Error> { set { (newValue: some Publisher<Int, Error>) in _foo = newValue.eraseToAnyPublisher() } }

これはgetの型はどうなるん？

omochimetaru

これはgetの型はどうなるん？

getはそのままAnyPublisher

Iceman

getはそのままAnyPublisher

あーgetより広い型だから成立しそうだ computed propertyはinoutに渡したりもするけど、いったんはgetの型で受けたら動きそうただ実質的に暗黙の型変換がプロパティの代入だけ導入される感じになりますね

3:01 PM

funcによる手書きのgetterとsetterなら可能な振る舞いだから、良いのかなあ？

結局暗黙の型変換になって読みづらくなるかもしれないので言いだしたものの特に欲しくはないですね

AnyPublisherという具体例についていえば、existentialの自己準拠機能が入れば、AnyPublisherが不要になってany Publisherを使えば良いので、任意のPublisherがany Publisherへ暗黙変換できるので、それで同じ効果が得られそう (edited)

代入とか->演算子の間でガチャガチャ何かが起こるC++を思い出すと避けたい気持ちになる

3:06 PM

existentialの自己準拠はスケジュールあるんでしたっけ？

future directionsとかで前向きに出てくるけど具体的なスケジュールの言及はいまのところない

なるほど。結構欲しい場面遭遇するので出たら嬉しいですね

2

Swift6 大計画にも乗ってなかったな・・・

https://forums.swift.org/t/se-0400-init-accessors/65583

SE-0400: Init Accessors

Hello Swift community, The review of SE-0400: Init Accessors begins now and runs through June 26th, 2023. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via the forum messaging featu...

3:38 PM

400番！

https://forums.swift.org/t/is-there-a-way-to-programmatically-allow-trust-the-compiler-plugin-to-run-from-the-command-line/65690/2 SwiftのマクロはCIだとコンパイラプラグインの検証を押せなくて失敗するんだけどスキップする方法を教えてもらった。 xcodebuildに-skipMacroValidationを渡すか com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES のUserDefaultsを設定すればスキップできる。Xcode Cloudはxcodebuildコマンド使えないから後者でやるしかないね。

Is there a way to programmatically allow (trust) the compiler plugi...

You can use defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES in a script to skip validation of macros from remote dependencies (the equivalent xcodebuild command line flag is -skipMacroValidation).

-skipMacroValidationはman xcodebuildに書いてあるけどUser Defaultsはみんなどうやって見つけてるんやろ。

strings

SwiftのTask、operation が throws なものまで @discardableResult が付いてるのってどこかで議論されていたりしますか？きちんと処理せずそのまま捨てられることになって微妙なのではと思うのですが…。 https://developer.apple.com/documentation/swift/task/init(priority:operation:)-5k89c (edited)

init(priority:operation:) | Apple Developer Documentation

Runs the given throwing operation asynchronously as part of a new top-level task on behalf of the current actor.

そうかバイナリの文字列を直接探すのか。

あとは、cfprefsdがないキーを検索されたときにwarningだかerrorだかをos_logに出すので、それを監視するみたいな。

そんなんあるんだ。存在はそれでわかるのか。

rinsuki

SwiftのTask、operation が throws なものまで @discardableResult が付いてるのってどこかで議論されていたりしますか？きちんと処理せずそのまま捨てられることになって微妙なのではと思うのですが…。 https://developer.apple.com/documentation/swift/task/init(priority:operation:)-5k89c (edited)

このThreadとかどうでしょう？ https://forums.swift.org/t/task-initializer-with-throwing-closure-swallows-error/56066

Task initializer with throwing closure swallows error

This is likely well-known at this point, but I wanted to ask about the rationale for this? Specifically, if this was discussed anywhere else on the forums or documented elsewhere, because I couldn't find it when searching. func someFunction() { Task { try await someThrowingFunction() } } This code swallows the error of someThrowingFun...

shiz

このThreadとかどうでしょう？ https://forums.swift.org/t/task-initializer-with-throwing-closure-swallows-error/56066

ありがとうございます！どうにかしたほうがいいよね〜…という声はありつつ、現状 Task { ... } の書き方をそのまま使う場合は SwiftLint で塞ぐしかない、という感じっぽいですね…

Aaronだw (もと同僚)

1

rinsuki

ありがとうございます！どうにかしたほうがいいよね〜…という声はありつつ、現状 Task { ... } の書き方をそのまま使う場合は SwiftLint で塞ぐしかない、という感じっぽいですね…

そうみたいですね。完全無視ではなく何かしらメッセージは出せそうみたいな記載がありましたが、現状は開発側で対策するしかなさそうですね。 (edited)

https://forums.swift.org/t/universal-escaping-attribute/65548

Universal escaping attribute

As macros arrive to swift, I would like to discuss a topic about code generation that annoyed me for some time. The main problem is that currently @escaping modifier might be applied only to function types, but, on syntax level, there is no way reliably understand that type is function type or not. Suppose I want to write a macro that generate...

6:14 PM

どれが関数型かわからないからinitマクロ作れない問題、キツイな

型情報を入れてくれるっていう拡張に期待なんだろうね。

別件でこれまさしくハマってました… 型の名前からその型の性質を調べるのが大変

11:41 PM

distributed actorは引数と返り値の型が特定のprotocolを満たしてるか検査できるので、そのような機能をマクロから利用したい

Iceman

distributed actorは引数と返り値の型が特定のprotocolを満たしてるか検査できるので、そのような機能をマクロから利用したい

distributed actor のその機能、完全に既存の言語機能の表現能力を超えてて、宣言方法も特別だし検査も特別実装なんだよなｗ

Kishikawa Katsumi

型情報を入れてくれるっていう拡張に期待なんだろうね。

やっぱりそれが正しい道なんですかね〜。型情報を提供するAPIの設計がすごく難しいのと、マクロの評価タイミングは現在は意味解析より前なので、結構頑張ってもらわないと良いものが出せなさそうだし、時間がかかってしまいそうだ。

型情報の解決にはSwiftコンパイラとの通信が必要で、現状ユーザコードとコンパイラドライバが通信するみたいなのはPackagePluginで存在するけど、同様の何かがマクロ側でも必要で、PackagePluginは色々大変そうだったしマクロでも大変そうだ

マクロで型使うのかなり大変な気がする

Iceman

型情報の解決にはSwiftコンパイラとの通信が必要で、現状ユーザコードとコンパイラドライバが通信するみたいなのはPackagePluginで存在するけど、同様の何かがマクロ側でも必要で、PackagePluginは色々大変そうだったしマクロでも大変そうだ

そういう動作アーキテクチャのレベルも結構おお仕事になりますよね。

コンパイル前にコンパイル後の成果物要求してるワケなので…

tarunon

マクロで型使うのかなり大変な気がする

本質的に多くの問題を孕むと思われますｗ　こういう簡単なケースはよくても、変なコーナーケースでややこしい問題が噴出しそう。

マクロの対象になったところだけ切り出して部分的に解決、みたいな。で、無限ループが発生して死んじゃう

tarunon

マクロの対象になったところだけ切り出して部分的に解決、みたいな。で、無限ループが発生して死んじゃう

意味情報はプロパティの型とかから芋づる式に他のファイルに書かれてる情報を辿れるから切り出せ無さそう (edited)

マクロ自体の引数に関しては完全にタイプチェックされてからのマクロ展開実行なので、型情報と通信の設計実装さえすればなんとかなる、はず。

frameworkが分離されてれば、理論上はimport先の型情報は使えることになりそう

けど attached マクロのアタッチ先のdecl やその中のものの型情報は限定的にならざるをえないんじゃないかと思います。 (edited)

frameworkの分離が出来ていれば型マクロが使える世界線、良い感じに分離するモチベーションが高まるだろうか

なるほど。じゃあ現時点でもマクロに依存した型に依存するマクロ呼び出しは書けないのかな・・・？

3:07 AM

expression macro func foo(_ x: some Observable) ... @Observable class C {} foo(C.init()) // NG?

#foo(C.init()) ですかね？それはできるはず。 (edited)

あ、そうだ。#foo でした。 (edited)

けど @attached(member) macro foo(_: Any) ... @foo(S.init()) struct S { } はどうなんだろうという感じです。

3:10 AM

foo マクロが競合する init() を生成するかもしれない。

ややこしいな。 foo の効果によって init が生成されるなら、暗黙の S.init は存在しないから、不正になっちゃうな。

試してないけど、おそらく circular reference だと思います。(じゃなかったらバグであるべき) (edited)

そうか。マクロ評価の順序付けさえあれば解決できるケースはまだよくて、あるマクロの評価前の型情報と、評価後の型情報が、互換性が無いパターンがありえるんですね。 (edited)

実際の実装としては macro プラグインからの型情報リクエストに応じて必要ならオンデマンドでタイプチェックして返す。circular reference 検知したらエラーを返すみたになるのかなと思ってます、が今のところ議論は進んでないですね。

そもそものスレッドの件に関しては、関数ではない型についてちゃっても無害な @escaping があれば解決はするんですよね。

3:18 AM

@escapingIfFunction みたいな。

3:19 AM

memberwise initの生成は個人的にはマクロに期待してた代表的な機能だし、そういう小汚い対応でもいいから早く実現してほしいｗ

macro 展開されたコードは当然元のソースとは別にパースされるし、タイプチェッカーはそれを知っているので仕様さえ決めればなんとでもなるっちゃなるはず。が、この特定の件に関しては別に「macro の制限だから typealias 使えないです」で良くないかとは個人的には思っちゃう。

なるほど・・・関数型はタイピング量が多くなりがちだからtypealiasしたくなりがちなんですよね。でもまあmemberwise initのためにプロパティのところだけ書き下すしてもお釣りは来るなあ。

あー、けどローカルだけの制限と考えてたけど、そのモジュールのインターフェイスにも出てきちゃうから混乱しちゃいますね(利用者はプロパティだけ生typeで他はtypealiasされてたら意味わからない)。前言撤回します

(edited)

たしかに。publicだと別のつらさが増えますね。

最初に言ってたtype(of node: SyntaxProtocol)みたいなのがあればだいたいいけると思うんですよね。

5:51 AM

これでカバーできないものは個別に議論していくことになるんじゃないかしら。

共有リソースの待ち合わせってstructued concurrencyの仕組みの中だけでは実装できないかな...? unstrucutedな何かが必須かな。 e.g. 複数のcallerから共有の準備ができたら使えるようになるリソースにアクセス、例えばダウンロードは1回だけのリソースに複数箇所からアクセス

7:26 PM

semaphore みたな何かが必要なはずだけど。

非同期でリソース初期化するDIコンテナ、がまさに具体の実装になりそう

止める必要があるところで継続を取って、準備ができたら継続をresume？

async initってもうあるんでしたっけ

ですねえ、semaphore 作ってる人わりといて、結果 actor で共有 Task {} の value を待つ, continuation 使うみたいな実装がありました (edited)

共有リソースの初期化のasync関数と、置いておく場所はawait propertyにしておけば、外側のclass若しくはactorを初期化するだけで良い気がしましたが、そういう話ではない？

二重に初期化されようとした時にセマフォ的なものが必要になりそうという話ですかね

そうですね

1:29 AM

URLから画像取ってくるが典型的な気がする

1:29 AM

https://developer.apple.com/videos/play/wwdc2021/10133/?time=719 Apple様の実装例

Protect mutable state with Swift actors - WWDC21 - Videos - Apple D...

Data races occur when two separate threads concurrently access the same mutable state. They are trivial to construct, but are notoriously...

わはは

なかなかに泥臭い

どうせ呼び出し側は違うTaskなんだから、わざわざTask.valueでunstructuredにしなくて良いと思います

これのImageがTask<Image, any Error> になれば良いと思ってました

func image(from url: URL) -> Task<Image, Error> ということですか?

var cache: [URL: Task<Image, any Error>] ということです。

ああ。

1:38 AM

ビデオちょっとだけ進めるとそういう実装になってます

あ、ほんとですね

どうせ呼び出し側は違うTaskなんだから、わざわざTask.valueでunstructuredにしなくて良いと思います

1:40 AM

ちょっとわかってない...

動画の実装、エラーがthrowされるかnilに潰されるかがキャッシュかどうかによって変わるな・・・

1:43 AM

いや読み間違えた

1:45 AM

-> Image? だけどnilが返るケースなさそうな気がする

w

1:49 AM

確かに

async property, stored propertyには使えなかったからダメでしたw

もし async let みたいなのがlocal以外で使えれば...

https://www.swift.org/blog/introducing-swift-http-types/

Introducing Swift HTTP Types

We’re excited to announce a new open source package called Swift HTTP Types.

2

10

11:42 PM

mac, iOSのURLSessionと、Linuxのswift-nioでHTTP関連の型がそれぞれ存在するの、共通のものにするって。

Swift Foundationもそうですけど、ここ最近はマルチプラットフォーム強化が多いですね。 (edited)

いい話

@swift-5.8.1

import Foundation struct Coordinate: Codable { var latitude: Double var longitude: Double } struct Landmark: Codable { var name: String var foundingYear: Int var location: Coordinate } let landmark = Landmark( name: "Tokyo Tower", foundingYear: 1957, location: Coordinate(latitude: 35.658581, longitude: 139.745438) ) let data = try! JSONEncoder().encode(landmark) print(String(decoding: data, as: UTF8.self))

(edited)

Kishikawa Katsumi

@swift-5.8.1

import Foundation struct Coordinate: Codable { var latitude: Double var longitude: Double } struct Landmark: Codable { var name: String var foundingYear: Int var location: Coordinate } let landmark = Landmark( name: "Tokyo Tower", foundingYear: 1957, location: Coordinate(latitude: 35.658581, longitude: 139.745438) ) let data = try! JSONEncoder().encode(landmark) print(String(decoding: data, as: UTF8.self))

(edited)

{"foundingYear":1957,"location":{"longitude":139.745438,"latitude":35.658581},"name":"Tokyo Tower"} (edited)

^ これ、iOS 16.xとmacOS Montereyだと {"name":"Tokyo Tower","location":{"longitude":139.74543800000001,"latitude":35.658580999999998},"foundingYear":1957} こういうJSONになる。iOS 17とSonomaだとLinuxと一緒になる。たぶん修正されたんだろうけどこういう突然の変更は困らないかな？ (edited)

浮動小数点の精度の違いですか？ (edited)

はい。小数が丸められるようになった？って感じです。

serializerの問題か、そもそも浮動小数点のIEEE754として確定しない値なのかどっちですかね... (edited)

その２つはDoubleの値としては同じみたいですね

3:14 AM

@swift-5.8.1

print(Double(139.74543800000001).description) print(Double(139.74543800000001).bitPattern) print(Double(139.745438).bitPattern)

(edited)

Yuta Saito

@swift-5.8.1

print(Double(139.74543800000001).description) print(Double(139.74543800000001).bitPattern) print(Double(139.745438).bitPattern)

(edited)

139.745438 4639120872052549187 4639120872052549187 (edited)

1

@swift-5.7.3

print(Double(139.74543800000001).description) print(Double(139.74543800000001).bitPattern) print(Double(139.745438).bitPattern)

tarunon

@swift-5.7.3

print(Double(139.74543800000001).description) print(Double(139.74543800000001).bitPattern) print(Double(139.745438).bitPattern)

139.745438 4639120872052549187 4639120872052549187

swiftのバージョンでここが変わったことを勘ぐったが、違ったw

これまではCの何かを使ってたけど、SonomaからSwiftのDouble.description が使われるようになったんじゃないかな (edited)

3:16 AM

SwiftのDouble.descriptionは色々かしこく綺麗に表示する実装が入ってる https://github.com/apple/swift/blob/main/stdlib/public/runtime/SwiftDtoa.cpp

2

Foundation のJSONEncoder/Decoder は浮動小数点数を一旦 Decimal にしてしまうせいでそう言う問題が起こっていたと思います．新 Foundation (swift-foundation) だと解決してた記憶があります． (edited)

なるほど

5:10 AM

import Foundation あるなしの違い...?

いや，JSONEncoder/Decoder が Foundation なのでありパターンしかないと思いますよ．

7:04 PM

https://github.com/apple/swift-corelibs-foundation/issues/4255

そもそもJSONにread/writeしたとき、浮動小数は10進化するときの誤差の関係で、ビットレベルでのroundtripはないものと思っていたけど、あったんですね。

JSONは仕様で数字の精度にきまりがないからなあ

12:43 AM

JavaScriptは全部Doubleだけど。

12:43 AM

JSONの数字はお気持ちでパースして精度をきめるしかない

数字の精度に決まりがないので、十分な桁数を書き込めば、Doubleがビットレベルで保存できるということですね。

ですね

https://github.com/apple/swift/pull/67454

[WIP] Try out then statements by hamishknight · Pull Request #674...

6:31 AM

then 文の実装が作業中だった

6:31 AM

func testNested3() -> Int { if .random() { print("hello") then if .random() { then 1 } else { then 2 } } else { () () then switch Bool.random() { case true: then 0 case false: then 1 } } }

6:32 AM

おそらく、ifやswitchを式モードで使うための文法で、本文が複数文ではない場合でも、最後の文で return のような感じで then を使うと、それを式の評価値として指定できる。

6:33 AM

これは結構うまいアイデアな気がするぞ。

これはreturnじゃあかんの？

returnとは共存するんだと思います。

returnだと関数のreturnとの見分けが問題になりそうな

returnは関数を抜ける(if文は中断される)。thenはそのif文の値を指定する。 (edited)

let hoge = if { ~ みたいになるんでしょうかね。

そうですね、まあ1文ならそれはもう書けるけど。 { ... } を2文以上にできる。 (edited)

let foo: Foo = if (...) { ... then xxx } else { ... then yyy } と書くのと let foo: Foo if (...) { ... foo = xxx } else { ... foo = yyy } と書くので、前者がうれしい理由は何？式の中（プロパティの初期化とか）で使えること？それとも、 if が foo の初期化のためのものだとわかりやすいこと？

1. 後者は : Foo を省略する余地がない 2. 後者は foo ３回出てきて冗長 3. 前者は、 = の右側が名前foo に依存していないので、コピペして再利用できる（foo 以外の代入に書き換えられる)

6:40 AM

if が foo の初期化のためのものだとわかりやすい

これもあると思いますね。ifの値があることで意味が強くなってると思う。

うーん、 1 についてはこんなに長い式で型が書いてないと可読性悪いし、 2 については冗長でも結局 then 書くのも同じくらい面倒だし、 3 についてもこんなに複雑な式をコピペで使い回すことなんてほぼないし・・・。

個人的な経験だと、if式を使った後で、デバッグしようとして分岐の中にprintいれたらif式が死んだ事があって(2文になっちゃったから) (edited)

6:42 AM

そういうときにprintいれられるのは便利だなと思う。 (edited)

if 式のブレースの中を複数の文にしたいというのはわかるんだけど、そもそも僕は if が文でもそんなに困ってなかったんですよね。 (edited)

利便性がぱっと良い判断できない割には真新しい文法が増えるのか〜という感じですね

then っておそらく一番最後にしか書けないんすよね？returnと一緒じゃないのかな。

プロパティの初期化とか、式しか許されてないところで使いたいことはあるけど、それなら if や switch だけでなく do も対応してほしい（対応してるんだっけ？）

Rustの;の有無がthenの無有に対応してるのかな

ブロックの最後にのみ書けるところに意義はありそうで、極力代入でなくthenを使いたい感じはしますね (edited)

僕はif式の代わりにクロージャ書くことあるけどネストするのが嫌だったので嬉しいですねあと嬉しさだとswitch式のほうが嬉しいです。

func foo() -> Foo { switch self { case .a: return .a case .b: return .b case .c: return .c ... //あと10回ぐらいある } }

↑このパターン、returnのお邪魔度が高い (edited)

switch は式になってほしいのわかります。 (edited)

1

Kishikawa Katsumi

then っておそらく一番最後にしか書けないんすよね？returnと一緒じゃないのかな。

func f() -> Int { let foo = if (cond) { then 1 } else { return 2 // returnなので、printに進まない } print(foo) return foo }

きしかわさんの言ってるのは代入だとブロック内のどこでも書けるけど、thenはブロックの末でしか使えないよね？ということでは

func f() -> Int { let foo = if (cond) { then 1 } else { then 2 // <= これは書けるの？ } print(foo) return foo }

koher

let foo: Foo = if (...) { ... then xxx } else { ... then yyy } と書くのと let foo: Foo if (...) { ... foo = xxx } else { ... foo = yyy } と書くので、前者がうれしい理由は何？式の中（プロパティの初期化とか）で使えること？それとも、 if が foo の初期化のためのものだとわかりやすいこと？

この論点でいうと、 4. thenは必ず末尾に値を出力する文がくる、ifの場合はそうじゃないかもしれないから読みづらくなりうるもありますね。

Kishikawa Katsumi

func f() -> Int { let foo = if (cond) { then 1 } else { then 2 // <= これは書けるの？ } print(foo) return foo }

書けると思いますよ。その場合は foo が 2 になって、 printされますね。 (edited)

むしろ書かないとエラーでは (edited)

なるほど？

tarunon

むしろ書かないとエラーでは (edited)

書かないでreturnできる規則もありえると思う。代入を中断して脱出する。 (edited)

あ、わかったぞ。

returnかthenが必須になるんじゃないかなと思う

6:52 AM

returnはつまりthen neverになる、と。

throwとtryでも抜けたいね

thenはcontinue的な制御か。

tarunon

returnはつまりthen neverになる、と。

その式におけるtypecheckとしてはそういう理屈になりますね。

do {} catch {} 式ができたらアツいな

omochimetaru

throwとtryでも抜けたいね

break や continue も

thenとreturnの違いはわかったこういうの書こうとすると必要ですね。

koher

break や continue も

あ、そうか。forの中でifをしてるときに、break (continue)とかできたら便利なことがあるかも。 (edited)

Iceman

do {} catch {} 式ができたらアツいな

if 式よりもほしいですね。

6:55 AM

しかし、 do 式を考えると then というキーワードは微妙かも？

@koher の立場だと↓でよくないのですか？ let foo: Foo do { foo = try make() } catch { foo = recovered }

omochimetaru

@koher の立場だと↓でよくないのですか？ let foo: Foo do { foo = try make() } catch { foo = recovered }

final class Foo { let x: X = do { ... then x } } これが書きたい

あ、catchじゃなくて素のdoか

catch があってもいいよ。 try したくなるかもしれないし。

6:57 AM

final class Foo { let x: X = do { ... try ... ... then x } catch { ... then x } } (edited)

omochimetaru

@koher の立場だと↓でよくないのですか？ let foo: Foo do { foo = try make() } catch { foo = recovered }

行数的にあんまりこれと変わらないかもですね。

@koher if式が要らなくて let foo: Foo if cond { foo = .. } で十分と感じているなら let foo: Foo do { foo = ... } と書いても十分ではないのですか？

そうじゃなくて、プロパティの初期化とか、式しか書けないとこで。

6:59 AM

これまで、クロージャ式即実行で対処するしかなかったところ。

7:00 AM

文が書けるところでスコープ切る目的なら let foo: Foo do { ... foo = ... } はよく書いてますね。

なるほど

で、どちらのケース（文が使えるところ、式しか使えないところ）にせよ、 if 式がほしいという立場であれば do 式もほしくなるはず。

それはそうですね、僕はあったら嬉しい。 (edited)

7:01 AM

いや、でもちょっとまてよ

7:01 AM

if式が使える部分は限定されているんですよ

7:02 AM

これは今もできないです。

そうなんよね。

だから、現行のif式の延長でのdo式の導入の場合、koherが嬉しいケースは禁止されそうｗ

引数に書きたいとかはある。

え、そうなのか。式なのになぜ

7:08 AM

まあいずれにせよ、 if 式が使いたい人にとっては、文が使える場所で let let foo: Foo = do { ... then ... } と書きたくなるニーズがあるはずで、そうすると then というキーワードは適してるのかな？別に変ではない？

do ... thenが英語として自然か？って話ですか？

koher

え、そうなのか。式なのになぜ

https://github.com/apple/swift-evolution/blob/main/proposals/0380-if-switch-expressions.md#detailed-design

There are of course many other places where an expression can appear, including as a sub-expression, or as an argument to a function. This is not being proposed at this time, and is discussed in the future directions section.

だめな理由ははっきりとは書いてないなあ、いったん狭い範囲で導入する、という感じですね。 Future Directionsのほうに、full expression化するとこれまでの文法とコンフリクトしてsource breakingになるケースの言及はありますね。

full expression化するとこれまでの文法とコンフリクトしてsource breakingになるケース

なるほどー。

7:29 AM

Future Directions に do 式あるね。 https://github.com/apple/swift-evolution/blob/main/proposals/0380-if-switch-expressions.md#do-expressions (edited)

7:30 AM

気になるのは、 do 式が返す値に使うキーワードが then で適切なのかというところ。

7:30 AM

よさそうな気もするし、条件を受けてないと変なような気もする。ネイティブの感覚がわからない。

まあthen文についてはまだforumにpitchすら投げられていない、実装を盗み見てるだけなので (edited)

7:31 AM

thenキーワードで提案されるかどうかもわからない

GPT-4に聞いてみた。 do then はちょっと違和感があるっぽい。 https://chat.openai.com/share/84f670d0-dc65-473c-b83b-d1cc2c6f08d2

それっぽい代案出せるのえらいなあ

7:40 AM

でも result や output は既存のローカル変数と衝突しまくりそうだ

ちゃんとプログラミングの文脈で return や yield がダメなのをわかってくれるから話が早い。

omochimetaru

でも result や output は既存のローカル変数と衝突しまくりそうだ

give は衝突しにくそうに思った。

ですね

Forum に then の話が出てきたら、 if 式の Proposal に do 式あるけど、 then だと微妙じゃない？ give とかどう？って書いてみればいいのかな。

私はemitいいと思うな

emit なら変数名には使われなさそうだから（メソッド名ならありそうだけど）、なんとかパースできそう？

7:44 AM

for とか in とかそんな扱いじゃなかったっけ？

まあ衝突する場合はバッククォートすればいいって感じにはなりそうだから、たまに衝突するのはセーフそう

ruby経験者なのでifだろうがなんだろうが式になると嬉しい

https://forums.swift.org/t/function-body-macros/66471

Function body macros

Hey all, I've been playing around with a design for function body macros, i.e., attached macros that can introduce, augment, or change the body of a function. Motivating examples include things like: @Remote // synthesizes a function body that does an RPC func f(a: Int, b: String) async throws -> String @Logged // adds logging on entry/exit...

1

3:14 PM

関数本文つくったり、関数をラップした関数にするやつの話が出てきた

3:15 PM

型検査のタイミング？とかで悩ましい事があるらしい

Swiftの6に入るのかな。5.9には間に合わんよな。

5.10かも

早めに来るとうれしいね。

下書きのほうに悩ましい事について詳しく書いてありそうなので後で読んでみる (edited)

https://github.com/DougGregor/swift-evolution/blob/function-body-macros/proposals/nnnn-function-body-macros.md#type-checking-of-functions-involving-function-body-macros

swift-evolution/proposals/nnnn-function-body-macros.md at function-...

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

7:24 AM

マクロが展開した結果として、ローカル変数が導入されるようなパターンで、

7:24 AM

マクロ展開前に型チェックすることができない

7:26 AM

なのでコード補完とかできない、みたいな話か・・・？展開してから処理するのは難しいのかな、よくわからなかった

expression macrosにもtype checkについて数点書かれてたけど、現状はfuncの引数みたいに型を明示的に書くから型チェックできたり、それ以外だと型が不明でも困らないケースしかないのかも

The main complexity of this future direction is in defining the APIs to be used by macro implementations to describe the Swift type system and related information. It would likely be a simplified form of a type checker's internal representation of types, but would need to remain stable. Therefore, while we feel that the addition of type information is a highly valuable extension for expression macros, the scope of the addition means it would best be introduced as a follow-on proposal.

https://github.com/apple/swift-evolution/blob/main/proposals/0382-expression-macros.md

swift-evolution/proposals/0382-expression-macros.md at main · apple...

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

expression macroと違ってfunc macroは関数本文だからマクロ適用前の型チェック要らなそうだよね (edited)

3:33 AM

というか、「既存の関数本文」の型ってなんだ？そんなものはないのか。

3:33 AM

@attached(body) macro Remote() = #externalMacro(...) @attached(preamble) macro Logged() = #externalMacro(...) @attached(body) macro Traced(_ name: String? = nil) = #externalMacro(...)

3:33 AM

なさそうだ。

On the other hand, type-checking the function bodies before macro expansion has other issues. For one, the declarations to which an attached macro is attached are generally not type-checked at all prior to expansion, so type-checking the body prior to expansion would be a departure from that. Additionally, type-checking a function body can be expensive at compile time, and doing that work twice (once for the function body as-written, once after expansion) could increase compile times unacceptably. Finally, type-checking the function body before macro expansion limits what can be expressed by function body macros.

関数本文の型チェックは何故か必要そうだね。attached macroは展開前に型チェックしてなくて展開後に型チェックしててOKだけど、func macroは展開前と後の2回型チェックしたいらしい。

3:49 AM

型チェックというかコンパイルと書いてるから、型推論とか最適化の何かが関数本文に必要という感じなのかな

なんで2回必要なんだろうなあ　展開後だけではだめなのか

3週間ほど休暇を取っていたのでまったく追えていないのですが、プロポーザルを読む限り:

マクロの引数がタイプチェックされるのと同様に、ボディも展開前タイプチェックするかどうかは完全にデザイン選択の問題です。タイプチェックしたほうが嬉しい場合もあるということですね

if they are fully type-checked prior to expansion, then the bodies are easier to reason about for programmers and also for tools.

プロポーザルで述べられている関数ボディマクロは3種

1) 元のボディがない → 展開前タイプチェック不要 @attached(body) macro Remote func f(a: Int, b: String) async throws -> String 2) 元のボディの前に何かを挿入する → 展開前タイプチェックする @attached(preamble) macro Logged func g(a: Int, b: Int) -> Int { return a + b } 3) 元のボディを書き換える → 展開前タイプチェックしない @attached(body) macro Traced @Traced("Doing complicated math") func h(a: Int, b: Int) -> Int { return a + b }

3 のパターンにおいて、展開前にタイプチェック_しない_ことでマクロで追加される変数名を使えるなどの利点がある一方、その関数ボディ内でのコード補完や Jump to Definition などの IDE 機能が制限される可能性が高いです。

展開してから処理するのは難しいのかな

コンパイラはマクロの実装が元のボディの要素を展開後のどこに配置したのか、そもそも利用したのかの知識がありません。なので仮に @SomeBodyMacro func foo(a: Int, b: Int) { expr } が func foo(a: Int, b: Int) { expr let a: String = "" expr } に書き換えられるマクロがあったとき、非常に恣意的な例ですが、 @SomeBodyMacro func foo(a: Int, b: Int) { a.<HERE> } みたいなコード補完だと、a が Int なのか String なのかわからない、みたいな話です。

あーーそうか〜〜

6:39 AM

展開後だけ常に考えたらいいと思ってたけど、自由bodyマクロだと、展開後のコードとエディタ上にある展開前のコードの対応関係が取れないんですね (edited)

6:43 AM

極端な話切り刻んで並び替えるようなマクロもありえるし。

その通りです。コード補完実装担当者としては（不正確かもしれないけど）展開前ボディでタイプチェックしてなんとか候補を出すしかないと考えています。

ローカル変数が注入されるタイプのマクロとかは、マクロ側でその変数の型情報とかを(peerマクロとかの名前のprefixとかみたいに)ヒントとして宣言するようなのが良さそう

6:46 AM

でも分岐の片方だけある変数が使えるとか、表現できないパターンは無限にあるな

6:46 AM

↑の挟んで2回出てくるパターンもそうですね

1

ほとんどの場合は展開前コードだけで実用的にはなるんじゃないかと思いますが、ローカル変数注入以外にも、 func foo(x: Int) { print(x) } が func foo(x: Int) { wrapper { (x: Wrapped<Int>) in print(x) } } に展開されるみたいなときに、不正確になる可能性が高いですね。

omochimetaru

5.10かも

https://forums.swift.org/t/swift-5-10-release-process/66911 5.10きざむみたいね。

Swift 5.10 Release Process

Swift 5.10 Release Process This post describes the release process, and estimated schedule for Swift 5.10. Snapshots of Swift 5.10 Downloadable snapshots of the Swift 5.10 release branch will be posted regularly as part of continuous integration testing. As support is available, snapshot downloads will be added for newly supported platforms. O...

おー、5.10出るのか〜

https://forums.swift.org/t/review-se-0408-pack-iteration/67152

[Review] SE-0408: Pack Iteration

Hello Swift community, The review of SE-0408 "Pack Iteration" begins now and runs through September 19th, 2023. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via the forum messaging...

7:35 AM

for <name> in repeat <pack> で可変長型パラメータをイテレートできるようになるらしい。

7:38 AM

直感的にはこれでだいぶいろんな事ができるようになりそう

タプルを配列に変換する事ができるようになりそうですね…

そうですね。

8:03 AM

でもタプルの前後をひっくり返すとかは無理そう

1

タプルの配列化は手で全部要素書くか、Mirror使わないとだったのが気持ち悪かったので便利になりそう…

ObjC側で公開してないメソッドと同名のメソッドをSwift側で@objc付けて実装するとoverride出来ちゃうのを見つけたんですけど、これって仕様ですか？

コード欲しいです

class ViewController: UIViewController { @objc func _contentOrObservableScrollViewForEdge( _ edge: NSDirectionalRectEdge ) -> UIScrollView? { nil } }

こういうのができちゃう

7:16 AM

ダンプヘッダーはこれ見て名前揃えてます https://headers.cynder.me/index.php?sdk=ios/16.0&fw=PrivateFrameworks/UIKitCore.framework&file=Headers/UIViewController.h

7:17 AM

_contentOrObservableScrollViewForEdgeはViewControllerの中にあるUIScrollViewのcontentOffsetが変わるとcontentScrollView(for edge: NSDirectionalRectEdge) -> UIScrollView?の直前で呼ばれる

ObjCクラスのメッセージディスパッチの仕組みを考えると、やむを得ない仕様だと思います

7:23 AM

ObjCの時も、UIWebViewをoverrideして、「たまたま」アンスコ始まりのメソッドを書くと「何故か」UIKitから呼ばれることはあったので (edited)

3

7:24 AM

同じ現象に思う。overrideの記号はあくまでswiftクラスのためのものじゃないかな

それってOjbCからでもoverrideできたりしませんか？

たまたま何故かww

解ってて言ってますよw(念為) ObjCでも同じ動きすると思います。dynamicがobjcを内包してそうな気はしますね

元のメソッド消えても急死したりしないし、たまたま偶然同じメソッドを定義するのは結構便利かもしれない

それでボコボコにした動きを前提としてると、呼ばれなくなって崩壊するのはちょいちょいありますねw window.openをフックしていて更新起因で死んだ記憶がある…

あー、あとoverrideしてもsuperを呼ぶ手段が無いから別の処理が足されると壊れるのか

https://developer.apple.com/documentation/objectivec/1456716-objc_msgsendsuper 間違えたフリしてこれを使うと、呼べますねw swiftからは無理ですが

objc_msgSendSuper | Apple Developer Documentation

Sends a message with a simple return value to the superclass of an instance of a class.

1

9:32 AM

プライベートメソッドに手を出すときに急に知能指数が下がるの、古めかしいiOSエンジニア仕草だと思う

2

まだ pitch までしか出たことがないと思いますが，typed throws の実装が始まってました． https://github.com/apple/swift/pull/68629

Typed throws by DougGregor · Pull Request #68629 · apple/swift

Start implementing typed throw specifiers with the syntax throws(X). There are a large number of tasks involved in such a feature; this pull request covers the parsing and type checking aspects. ...

8

Embedded Swiftで使いたいというモチベーションみたいですね

I've become interested in typed throws because it's a good direction for error handling in Embedded Swift, and have started on an implementation

https://forums.swift.org/t/status-check-typed-throws/66637/20 (edited)

Status check: Typed throws

Yes, I think it is. I've become interested in typed throws because it's a good direction for error handling in Embedded Swift, and have started on an implementation. I'd be happy to work with other folks on the proposal and design. @minuscorp had a good start on a proposal that captures a lot of the motivation, and @John_McCall laid out much of...

The types of thrown errors will be restricted in some manner, because thrown errors are of existential type any Error (which is disallowed by the prior item).

https://github.com/kubamracek/swift-evolution/blob/embedded-swift/visions/embedded-swift.md#embedded-swift-language-subset (edited)

swift-evolution/visions/embedded-swift.md at embedded-swift · kubam...

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

typed throwsって組み込み的にどう嬉しいんでしょうかね？

11:12 PM

Resultでは解決できない課題がある？

Iceman

typed throwsって組み込み的にどう嬉しいんでしょうかね？

ヒープメモリのメモリ消費とかアクセス速度を気にしてるとか？ ResultでいろいろやるとswitchとかflatMapが増えてthrowsに比べると制御を書くのが大変ということではないかなあ

11:16 PM

typed throwでもその辺のABIは変わらない気がするけど・・・

shizさんの貼ってくれたリンク先に書いてありましたね、そもそもexistential がない世界観なのか

えっ、それはすごいな組み込みSwiftそんな踏み込んだ方向目指してるのか

読んでるとめちゃくちゃ制約多くてかなり書き味が違うSwiftになりそう、これならzigとかでいいんじゃないかな

ダイナミックなもの全部潰してるな

Iceman

読んでるとめちゃくちゃ制約多くてかなり書き味が違うSwiftになりそう、これならzigとかでいいんじゃないかな

zigしらんのでチラッと見てきたけど、Swiftと比べるとジェネリクスはあるけどプロトコルがないっぽいのが気になった。

any無い世界凄いな

Goalの最後に

The Embedded Swift language subset should stay very close to “full” Swift,

と書いてあるものの、次のlimitation見ると結構違ってくるのではないかなという印象です。

Typed throws嬉しいは嬉しいけど、Swift Evolutionsにないよね…

Swift Evolutionsにないよね…

まだpitchが出てくるような段階に辿り着いていないという認識でした。最後のスレッドがこれだった気がします。 https://forums.swift.org/t/precise-error-typing-in-swift/52045

Precise error typing in Swift

Introduction When error handling was added to Swift in 2015, it intentionally did not allow the expression of precise error types: either a function cannot throw, or it can throw any Error. The error-handling rationale I wrote, which uses an awful lot of words to describe most aspects of the design, gives this one pretty short shrift: There ar...

2

Dorgが実装始めてる https://github.com/apple/swift/pull/68629

Typed throws by DougGregor · Pull Request #68629 · apple/swift

Start implementing typed throw specifiers with the syntax throws(X). There are a large number of tasks involved in such a feature; this pull request covers the parsing and type checking aspects. ...

2:29 PM

この投稿で示してた https://forums.swift.org/t/status-check-typed-throws/66637/20

Status check: Typed throws

Yes, I think it is. I've become interested in typed throws because it's a good direction for error handling in Embedded Swift, and have started on an implementation. I'd be happy to work with other folks on the proposal and design. @minuscorp had a good start on a proposal that captures a lot of the motivation, and @John_McCall laid out much of...

このスレッド今すごい勢いで伸びてる

10:00 PM

typed errorの話が動きそうだから意見のある人達が書き込んでる

1

複数のエラーをthrowするのは微妙だろうなぁ。Unionを導入することになっちゃうし、エラー型が爆発してJava状態になってしまう。typed throws使いたいなら各レイヤーでそれらのレイヤーなりの意味を持ったエラー型に読み替えるべき。で、ライブラリはそれをする労力を払う価値はあるけど、アプリケーションでは多くの場合コストに見合わないから、アプリではuntyped throwsを使うっていう棲み分けにだろうなぁ。

ライブラリとアプリというより、ある関数の機能の関心が、その動作に含まれるローレベルの動作に含まれるかどうか、ってことだと思うんですよね

11:26 PM

例えば func callAPI(request:) async throws -> Response みたいな場合、

11:26 PM

関心の粒度はAPIの仕様の粒度であって、

11:26 PM

それがどういうネットワークライブラリ(URLSession? async-http-client?) なのか、はたまたネットワークじゃなくてスタブに繋がっているのか

11:27 PM

みたいなその実現方法までは関心をもたない、抽象化してしまったほうが

11:27 PM

便利でもある、みたいな。

11:27 PM

エラー型を正確に列挙しようとすると、必然的にその実現方法に強く依存したインタフェースになってしまうので

11:27 PM

関心を上層に限定して抽象化することができなくなる。 (edited)

11:29 PM

https://github.com/apple/swift-tools-support-core/blob/3b13e439a341bbbfe0f710c7d1be37221745ef1a/Sources/TSCBasic/GraphAlgorithms.swift#L54

swift-tools-support-core/Sources/TSCBasic/GraphAlgorithms.swift at ...

Contains common infrastructural code for both SwiftPM and llbuild. - apple/swift-tools-support-core

11:30 PM

他にもこういう topologicalSort みたいな純粋なロジックの関数とかは、下層の実現方法の選択肢という概念がそもそもあてはまらなくて、ありえる失敗が固定されてるから、エラー型を列挙するのと相性が良い (edited)

そもそも列挙されていないと何のErrorが飛んでくるかわからないし、catchしてもせいぜいログ残して握りつぶすぐらいしかできない… 飛んでくるErrorに自分が関心があるかすら分かりづらいから基本的に列挙されてほしい気がします。 (edited)

omochimetaru

ライブラリとアプリというより、ある関数の機能の関心が、その動作に含まれるローレベルの動作に含まれるかどうか、ってことだと思うんですよね

理想的には、すべてのレイヤーでそのレイヤーのセマンティクスで抽象化されたエラー型が定義され、そのエラー型で throw されるべきだと考えています。それであれば上層が下層の実装に依存することはなくなります。でも、その型付けにはコストがかかり、多くの場合、アプリでは一回か多くても数回程度しか利用しないことが多いので、型付けのコストが価値を上回らないと考えています。ライブラリの場合は無限回利用され得るのでコストに見合う価値があります。

koher

理想的には、すべてのレイヤーでそのレイヤーのセマンティクスで抽象化されたエラー型が定義され、そのエラー型で throw されるべきだと考えています。それであれば上層が下層の実装に依存することはなくなります。でも、その型付けにはコストがかかり、多くの場合、アプリでは一回か多くても数回程度しか利用しないことが多いので、型付けのコストが価値を上回らないと考えています。ライブラリの場合は無限回利用され得るのでコストに見合う価値があります。

そのレイヤーのセマンティクスで抽象化されたエラー型が定義され

例えばAPI呼び出しなら、通信のレベルと、JSONを処理するレベル、APIに応じたバリデーションのレベル、みたいに整理する、という事でしょうか？そうだったとして、この抽象化されたエラー型の中に、具体的な実装に依存したエラー型が渡せるように、 any Error が混ざり込みませんかね？

// こういうのは列挙できたとしても・・・ enum ProtocolError { case brokenJSON case invalidFormat(String) ... } enum APICallError { case protocolError(ProtocolError) // ↓こっちは実装変更に対応しようとすると列挙できない case networkError(any Error) }

trickart

そもそも列挙されていないと何のErrorが飛んでくるかわからないし、catchしてもせいぜいログ残して握りつぶすぐらいしかできない… 飛んでくるErrorに自分が関心があるかすら分かりづらいから基本的に列挙されてほしい気がします。 (edited)

例にあげたような上流の関数の場合、仮に列挙されていたとしても、結局のところログを出すかユーザにメッセージを出すか、ぐらいしかできることがなくて、いくらかのパターンの場合にはリトライの選択肢がある、ぐらいになると思います。

omochimetaru

そのレイヤーのセマンティクスで抽象化されたエラー型が定義され

例えばAPI呼び出しなら、通信のレベルと、JSONを処理するレベル、APIに応じたバリデーションのレベル、みたいに整理する、という事でしょうか？そうだったとして、この抽象化されたエラー型の中に、具体的な実装に依存したエラー型が渡せるように、 any Error が混ざり込みませんかね？

// こういうのは列挙できたとしても・・・ enum ProtocolError { case brokenJSON case invalidFormat(String) ... } enum APICallError { case protocolError(ProtocolError) // ↓こっちは実装変更に対応しようとすると列挙できない case networkError(any Error) }

はい、その場合は any Error が混ざってしまうか、実装に依存した型がassociated valueに現れると思います。

koher

はい、その場合は any Error が混ざってしまうか、実装に依存した型がassociated valueに現れると思います。

そこの any Error には何が含まれうるか静的にわからないわけですけど、エラーハンドリングの観点でば、「ネットワークのエラーです (詳細情報はあったりなかったり)」って初手の分類はできるから便利・・・？

11:50 PM

ライブラリの利便性のためにネットワーク層は注入可能にしたい、みたいな状況がありえて、そうなると列挙不可能なんですよね。

omochimetaru

例にあげたような上流の関数の場合、仮に列挙されていたとしても、結局のところログを出すかユーザにメッセージを出すか、ぐらいしかできることがなくて、いくらかのパターンの場合にはリトライの選択肢がある、ぐらいになると思います。

上層のエラーをハンドリングする際に、下層のエラーの詳細に応じてハンドリングすることが誤りではないですか？それぞれの層に準じたセマンティクスがあるはずで、その層のセマンティクスではなく、下層のエラーに対してハンドリングをするのは、カプセル化された実装の中身が漏れ出しているのでは？

11:52 PM

ただ、理想的にはそうやってそれぞれの層におけるセマンティクスでエラーを型付けするのが正しいと思うけど、それにはコストがかかるので、現実的にはそのコストに見合うところでしかそれはできないだろうと考えています。

koher

上層のエラーをハンドリングする際に、下層のエラーの詳細に応じてハンドリングすることが誤りではないですか？それぞれの層に準じたセマンティクスがあるはずで、その層のセマンティクスではなく、下層のエラーに対してハンドリングをするのは、カプセル化された実装の中身が漏れ出しているのでは？

例えば Decodable が投げる DecodingError がキャッチできたとしても、内部処理のどのタイミングで発生したのかわからん、みたいな状況は、その指摘に該当するかなと思います。サーバーから返ってきたJSONが仕様と違った、だけとは限らなくて、内部のキャッシュシステムが持ってるメタデータが壊れていた、のかもしれない。みたいな。 (edited)

11:56 PM

「層による意味付け」がされていれば、 enum E { case responseDecodingError(DecodingError); case cacheSystemError(any Error) } みたいになっててわかりそう。

omochimetaru

例にあげたような上流の関数の場合、仮に列挙されていたとしても、結局のところログを出すかユーザにメッセージを出すか、ぐらいしかできることがなくて、いくらかのパターンの場合にはリトライの選択肢がある、ぐらいになると思います。

おっしゃるとおり取れる選択肢は少ないとは思いますが、 UXを考えて実装を作り込もうと思ったときは大事になると考えています。単純なリトライだけでなく「タイトル被ってるから変えてね」と入力画面に戻すとか色々細かくやるときなど。実際そこまでやることあんまりないしコストパフォーマンス釣り合ってないとかはあるかもしれませんが、使う側としてはできるのであればあっただけよいかなと。「そのError出るの知ってたらcatchで対応してたよ…(いちいち全部コード読まないと分からないの…？)」というのがなくなってほしい。 (edited)

trickart

おっしゃるとおり取れる選択肢は少ないとは思いますが、 UXを考えて実装を作り込もうと思ったときは大事になると考えています。単純なリトライだけでなく「タイトル被ってるから変えてね」と入力画面に戻すとか色々細かくやるときなど。実際そこまでやることあんまりないしコストパフォーマンス釣り合ってないとかはあるかもしれませんが、使う側としてはできるのであればあっただけよいかなと。「そのError出るの知ってたらcatchで対応してたよ…(いちいち全部コード読まないと分からないの…？)」というのがなくなってほしい。 (edited)

「タイトル被ってる」みたいなエラーは便利なので列挙したいですね。 (1)「含みうるエラー」を伝えるために列挙する事と、 (2)「ありえる全てのエラー」を完全に列挙する事にギャップがあると考えています。 (1)は便利だけど、typed throwsで(2)を目指してしまうと、先述のように抽象化できないとか、どうせほぼ意味のある処理は作れない下層の異常が飛んでくる、のに、そいつらを列挙する労力が無駄にかかりすぎてしまう。

1

12:01 AM

僕は最近は (1) だけ実現するために func login() async throws -> Result<LoginResult, LoginError> みたいにやってます。 (edited)

12:02 AM

そのレイヤーで関心があって、特別なハンドリングがありえるエラーはResultで明記して、その他の下層のエラーを流し込むために throws も付けておく。 (edited)

現実的なユースケースをみて無視されてるエラーって今でもたくさんありますよね Intのオーバーフローとか、OOMとか。それらのように無視させるエラーというのは一定数確実に存在していて、やはり型をつけたいエラーは人間が実装するビジネスロジック内のごく少数に限られると思うんですよね

omochimetaru

僕は最近は (1) だけ実現するために func login() async throws -> Result<LoginResult, LoginError> みたいにやってます。 (edited)

これはわかるんですが、戻り値で扱うと戻り値がない場合にエラーハンドリングを強制させづらくないですか？無視しても警告が出るから良い？

Iceman

現実的なユースケースをみて無視されてるエラーって今でもたくさんありますよね Intのオーバーフローとか、OOMとか。それらのように無視させるエラーというのは一定数確実に存在していて、やはり型をつけたいエラーは人間が実装するビジネスロジック内のごく少数に限られると思うんですよね

Universal ErrorとRecoverable Errorは区別されていて、その上でtyped throwsが議論の対象としているのはRecoverable Errorだと思います。

(1)「含みうるエラー」を伝えるために列挙する

これはエラーを提供する側とエラーを受け取って処理する側のコミュニケーションコストが高くなる場合もあるかなと感じることがあります。例えば、決済システムでサーバから返ってくる大量のエラーコードを、起こりうるエラーに変換してthrowする共通フレームワークがある場合、そのフレームワークを利用する側が「実はこういうエラーが欲しい」という要求をすると、実装されるまでの時間がかかったりなどのコストが結構かかることがあって悩むことがありますね... (edited)

koher

これはわかるんですが、戻り値で扱うと戻り値がない場合にエラーハンドリングを強制させづらくないですか？無視しても警告が出るから良い？

はい、Resultを使う問題点は普通にあります。あと、 LoginErrorが throws のほうに流し込まれる変なケースも頭がいたいです。だから、これと同じことが typed throws だけでできたら良いなあと今思いました。

omochimetaru

はい、Resultを使う問題点は普通にあります。あと、 LoginErrorが throws のほうに流し込まれる変なケースも頭がいたいです。だから、これと同じことが typed throws だけでできたら良いなあと今思いました。

そうすると、一般的なunionは避けるにしても、 any Error だけは特別に throw できたらうれしいってことになりそうですね・・・。

enum LoginError { case ... case other(any Error) } ↑まあこれを書いたらいいのかな？

Javaの検査例外・非検査例外に似てるけど、untypedでもハンドリングが強制される点が異なる。

型にできそうだな

enum PartialExplicitError<E> { case explicit(E) case implicit(any Error) } func login(...) async throws(PartialExplicitError<LoginError>) -> LoginResult

(edited)

フレームワークを利用する側が「実はこういうエラーが欲しい」

利用者によって関心が異なり、「回復すべきか？」ということすら利用者次第なの難しいですね… (例えばOOMだってシステムプログラミングなら対応したいかもしれない。Embedded Swift文脈から来たのはそういうこと？) (edited)

koher

そうすると、一般的なunionは避けるにしても、 any Error だけは特別に throw できたらうれしいってことになりそうですね・・・。

例にあげたtopologicalSortのように、本当に列挙しきりたくてそれが可能で、すり抜ける下層とかも無いこともあるんで、 any Error すりぬけがあるか、ないか、だけ書き分けられると便利だったりするかなあ

1

しかもそれに対応していくと特定の利用者限定のエラーが生まれてしまう可能性もあり。case others(any Error)などを作成して「あとは任せた」でいいのかもしれないですが。 (edited)

shiz

(1)「含みうるエラー」を伝えるために列挙する

これはエラーを提供する側とエラーを受け取って処理する側のコミュニケーションコストが高くなる場合もあるかなと感じることがあります。例えば、決済システムでサーバから返ってくる大量のエラーコードを、起こりうるエラーに変換してthrowする共通フレームワークがある場合、そのフレームワークを利用する側が「実はこういうエラーが欲しい」という要求をすると、実装されるまでの時間がかかったりなどのコストが結構かかることがあって悩むことがありますね... (edited)

「このエラーコードの場合のcaseも追加したい」みたいな状況は、コーディングとしては簡単なはずで、それが面倒になるのは開発体制の問題な気がしました例えばそのフレームワークをフォークしてたらすぐ対応できますよね

omochimetaru

例にあげたtopologicalSortのように、本当に列挙しきりたくてそれが可能で、すり抜ける下層とかも無いこともあるんで、 any Error すりぬけがあるか、ないか、だけ書き分けられると便利だったりするかなあ

こんな感じで // any Errorを許すアスタリスク func login(...) async throws*(LoginError) -> LoginResult

trickart

フレームワークを利用する側が「実はこういうエラーが欲しい」

利用者によって関心が異なり、「回復すべきか？」ということすら利用者次第なの難しいですね… (例えばOOMだってシステムプログラミングなら対応したいかもしれない。Embedded Swift文脈から来たのはそういうこと？) (edited)

利用者によって関心が異なるのはその通りだと思います。index out of boundsですら、Logic Failureとして扱われていて多くのケースではそれが適当だけど（たとえば、クイックソートを実装するときに毎回index out of boundsのハンドリングを強制されると辛いとか）、場合によってはハンドリングしたいこと（番兵のように使いたいとか）もありますし。なので、基本は多くの想定ユースケースに合わせながら、Universal ErrorやLogic FailureをRecoverable Errorに昇格させる手段が提供されるといいんだと思います。

1

omochimetaru

「このエラーコードの場合のcaseも追加したい」みたいな状況は、コーディングとしては簡単なはずで、それが面倒になるのは開発体制の問題な気がしました例えばそのフレームワークをフォークしてたらすぐ対応できますよね

例えばそのフレームワークをフォークしてたらすぐ対応できますよね

あ、これは内部で開発しているフレームワークを想定していてforkは想定していませんでしたmm

開発体制の問題な気がしました

そうですね。コミュニケーションに時間がかかるなどの面に関してはこれはすごい感じますw (edited)

koher

Universal ErrorとRecoverable Errorは区別されていて、その上でtyped throwsが議論の対象としているのはRecoverable Errorだと思います。

そう、だから何でもかんでもエラーに型をつけることは、Universal Errorの多くをRecoverable Errorに持ち込んで手間が増える結果になってしまうと思うんですよね

omochimetaru

型にできそうだな

enum PartialExplicitError<E> { case explicit(E) case implicit(any Error) } func login(...) async throws(PartialExplicitError<LoginError>) -> LoginResult

(edited)

これRustで（たぶん）よくある形ですよね

1

Iceman

そう、だから何でもかんでもエラーに型をつけることは、Universal Errorの多くをRecoverable Errorに持ち込んで手間が増える結果になってしまうと思うんですよね

Universal ErrorやLogic Failureにtyped throwsで型を付けることはないんじゃないでしょうか？これまでRecoverable Errorに型を付けられなかったのを付けられるようにしたいという、Recoverable Errorに限定した話ではないですか？

koher

Universal ErrorやLogic Failureにtyped throwsで型を付けることはないんじゃないでしょうか？これまでRecoverable Errorに型を付けられなかったのを付けられるようにしたいという、Recoverable Errorに限定した話ではないですか？

それでいうと僕の発言は https://discord.com/channels/291054398077927425/291054454793306112/1154199388881694790 を踏まえた上なので、Recoverable Errorに限定してない状況の想定でした (edited)

Iceman

それでいうと僕の発言は https://discord.com/channels/291054398077927425/291054454793306112/1154199388881694790 を踏まえた上なので、Recoverable Errorに限定してない状況の想定でした (edited)

ああ、なるほど、そこの会話がつながってたんですね。

shiz

例えばそのフレームワークをフォークしてたらすぐ対応できますよね

あ、これは内部で開発しているフレームワークを想定していてforkは想定していませんでしたmm

開発体制の問題な気がしました

そうですね。コミュニケーションに時間がかかるなどの面に関してはこれはすごい感じますw (edited)

まあ、そのシナリオだとちょっとの手間が大きな時間コストに増大してしまっている部分は体制の問題だとして、「ちょっとの手間」が増えてるのは事実ですね。エラーの完全列挙をするときは気をつけないと、下層でエラーが一種類追加されるだけで、それを呼び出す全ての関数に追加する変更をしないといけない、とかにになって、「大きな手間」になったりもしますね。

1

12:27 AM

shizさんのケースは enum のcaseが増えるだけで、エラー型そのものの種類は増えてないので、小さな手間で済みそうですが。

12:28 AM

あと、今列挙する話がここで盛り上がってますが、現在のdorgの実装としては列挙する方針ではなくて単一エラーですね (edited)

12:28 AM

いくつか書き込みに対するレスポンスとして、「それは any Error にするといいね」って回答されてます

結局existentialが許されるのか。

any Error つまりただの throws ですね

下層でエラーが一種類追加されるだけで、それを呼び出す全ての関数に追加する変更をしないといけない、とかにになって、「大きな手間」になったりもしますね。

多分、さっきの any Error が出てくるとか下層のエラーが型に現れてくるとかから考えても、各レイヤーのセマンティクスで定義されるエラーは下層のエラーを含まない（ラップしない）というのが型的には正しそうな気がする。そうすれば、Existentialは必要ないし、下層のエラーのセマンティクスで上層の利用者がハンドリングしてしまうことがない。けど、現実的には下層のエラーの理由を知りたいし、ログに残したいし、そういうわけにもいかない。なんか別口でエラーの原因を取得できる口があるといいのかなぁ。

koher

下層でエラーが一種類追加されるだけで、それを呼び出す全ての関数に追加する変更をしないといけない、とかにになって、「大きな手間」になったりもしますね。

多分、さっきの any Error が出てくるとか下層のエラーが型に現れてくるとかから考えても、各レイヤーのセマンティクスで定義されるエラーは下層のエラーを含まない（ラップしない）というのが型的には正しそうな気がする。そうすれば、Existentialは必要ないし、下層のエラーのセマンティクスで上層の利用者がハンドリングしてしまうことがない。けど、現実的には下層のエラーの理由を知りたいし、ログに残したいし、そういうわけにもいかない。なんか別口でエラーの原因を取得できる口があるといいのかなぁ。

その取得できる口が enum APICallError { case ... case network(any Error /*これ*/) } ↑に該当するのではないでしょうか？ (edited)

1

enum CallError { case network(underlyingError: URLError) case json(underlyingError: any Error) case authentication } みたいな感じで下層エラーをさらに握っておく形になるでしょうね (edited)

1

12:32 AM

実質的にエラーがコールスタックみたいになる。

12:33 AM

あんまり詳しくないですがGoのエラーも最近はラップし続けながら上に流して、取り出す側は中のものをフラットに扱いながらダウンキャストする、みたいな感じになってたと思います

ObjectiveCでちゃんとエラー返り値(ダブルポインタのやつ)やろうとしたとき、下のエラーを userInfo.undelyingError で包んでたらコールスタック手作りみたいになってウーンとなったのを思い出した。 (edited)

1

Swiftもだけどスマートにcatchする文法がほしい

typed throwsやるなら、同時にuntagged union ( T|U ) の整備も必要だと思うのだけど、そういう指摘はあるかしら (edited)

指摘というかトピックとしてはかなり触れられていて

現実的にenumで頑張るのは無理筋だと思う

1. throws句に複数列挙できるかどうか 2. unionを導入するかどうかの論点があるけど、コアチームの方針は 1については単一で、2は否定されてenum書いてね、に見える。

いやー厳しそう

そもそもモチベーションとして、組み込み環境のローレベルAPIみたいな、単一enumで列挙可能＋existentialのコスト回避したい、というのがターゲットと考えられていて

1:13 AM

アプリケーションに出てくるたくさん並べるやつは今まで通り throws の any Error が良いだろう、

1:13 AM

って話になってるよ

TypeScriptでUnionは厳しいと感じてるけど、メタタイプのあるSwiftなら違ったりするのかなぁ

まあ不便になるわけじゃないって話か

メタタイプがあるかどうかとunionの使い勝手は関係あるかしら

メタタイプがあるかというよりは実行時型情報の有無でした

あ、それはわかる(実行時型情報)けど疑問点は一緒です (edited)

ダウンキャストができないなどです

1:15 AM

（もちろん自前でメタタグをつければできるけど）

framework毎に、そのframeworkで発生する全てのエラーを包んだError型を定義してそれを使うのが流行りそうだ。そしたらfunction毎の多重ネストenumになるのはframeworkの毎になって緩和される

あと型として複雑すぎてジェネリックに扱う時に苦しい場面が多い

classインスタンスだったら実行時ダウンキャストは instanceof でできますね構造的な型の話？

structualな場合ですね (edited)

tsでunion辛いは、例えばkindを宣言したりして緩和するけど、それは実行時型情報あれば出来るから

ある意味TS環境に関して言えば、クラスインスタンス＝メタタイプを持っているオブジェクト　と言えると思います。

classは基本使わないので。

構造的部分型は構造だけに依存するゆえに互換性などが取れるというメリットと表裏一体なので

そもそもclassを使えという話になるのかもしれないけど、sealed classがないから型安全になれないですし。

tsで辛いのはclass使わずobjectと純粋関数でやるスタイルのせい、はあると思う

構造的部分型に実行時型情報を付与する、という話になると矛盾が生じて別の問題が起きそう。

同じ辛さはswiftでunionした場合は起きないと思います

たとえば構造的部分型は A & B みたいな状態を扱えるし、後で知らなかった C にも準拠できたりします。

https://discord.com/channels/291054398077927425/291054454793306112/1154224592618004581 こっちもまあまあ苦しいと思ってて、何かをジェネリックにしたいときにunionが混じってると型が変に分裂したりして1個タプルで囲ったりそもそもわからんくなったりといった場面が多い

でもそういうのは実行時型情報にするにはSwiftみたいにコンパイルタイムにconformanceを全部書いておかないといけないはず。

1:19 AM

ランタイムで判定しようとするとプロパティ定義を見ることになって、それは結局メタタイプが無い状態に戻ってます。 (edited)

1:22 AM

TypeScriptに sealed class と new でコンストラクタ呼ばなくても完結にかけるオブジェクトリテラル式によるnewと、クラスオブジェクトに対するオブジェクト展開構文 { ...s } などなど、が、あれば良いんじゃないか・・・？

TSで使っててしんどいのは構造的な型で区別つけづらいのと、Conditional typeを含むジェネリックな式で複雑すぎて手がつけられなくなる、という点なので、Swiftなら上手に扱えるのかもという気持ちになってきた

あ、でもTypeScriptって、「Aにプロパティxを足した型」みたいな、オブジェクトに対する操作で定義したテンポラリな型が頻出するので、これがクラスというかnominalな道具だと扱えないですね (edited)

Iceman

https://discord.com/channels/291054398077927425/291054454793306112/1154224592618004581 こっちもまあまあ苦しいと思ってて、何かをジェネリックにしたいときにunionが混じってると型が変に分裂したりして1個タプルで囲ったりそもそもわからんくなったりといった場面が多い

こっちについてはSwiftだったとしても同じになりそう？

そもそもswiftだと部分型作ってもconformance無しに使えないから、実行時に型がないって事にはならなさそう

つまり部分型を事前に宣言しておかないとダメですね。 (edited)

omochimetaru

こっちについてはSwiftだったとしても同じになりそう？

each repeatを用意してくれるSwiftなら同様にいい感じにUnionを扱ういい感じの構文を用意してくれれば何とか。

Iceman

each repeatを用意してくれるSwiftなら同様にいい感じにUnionを扱ういい感じの構文を用意してくれれば何とか。

指摘してる問題が具体的にイメージできてないので文法の問題なのかどうかよくわからないです。

1:28 AM

unionが分裂したり畳み込まれたりする事自体はunionの本質的な性質なので、そのややこしさ自体は取り除けないと思っています。

それはそうですね。継承関係が普段と逆向きだったり、分裂したりするのが難しいです。それだけ複雑で難しい構文であるにもかかわらず、TSは（それ以外にろくな表現力を持たないので）頻出してて難しいなと

1:31 AM

文法が改善されれば理解が容易になるかどうかは僕もわからないです

1:32 AM

eachなどで型が分裂することが明記できてるのはSwiftの良い点だなと。 (edited)

分裂と言っているのは↓の事であってます？

type AB = A | B // 素直な分裂 type K<X> = N | M | X type KAB = K<AB> // = N | M | A | B // 構造的な分裂 type O<X> = { o: X } type OAB = O<AB> // = { o: A } | { o: B }

そうですね。たしかMapped Typeでも扱いが特殊だったはず

1:39 AM

最近難しいと思ったのは

interface ReturnNotUndefined { (...args: any): Promise<NonNullable<unknown>> | NonNullable<unknown> } const a = (() => 42) satisfies ReturnNotUndefined; const b = (() => null) satisfies ReturnNotUndefined; // エラーになる、嬉しい const c = (async () => null) satisfies ReturnNotUndefined; // エラーにならない、嬉しくない

こういうnon nullなTを返すsyncまたはasync関数を定義したいときに、うまく区別できなかったりとか

1:40 AM

（これはPromise<null>がNonNullable<unknown>なせい）

ｗｗ

これはintersection typeの話ですが、

type AAA = string & { foo: null }; type BBB = Omit<AAA, "foo">; function useString(str: string) {} function useBBB(bbb: BBB) { useString(bbb); // Argument of type 'BBB' is not assignable to parameter of type 'string'. }

fooをうまく剥がせなかったりとか。

これは Promise に包まない場合を許してるのがよくなさそうですが、 TSは (JSは) Promise.then のシグネチャがそもそもそうなってたりして終わってますね (edited)

type _CCC<T> = T extends infer U & { foo: null } ? U : never; type CCC = _CCC<AAA>; function useCCC(ccc: CCC) { useString(ccc); }

こうやってinferを使えば剥がせますが、逆にConditional Typeに依存することでTがまたunionやintersectionだったりしてUとの間に綺麗な継承関係を作れなかった場合に崩壊したりとか。

Iceman

これはintersection typeの話ですが、

type AAA = string & { foo: null }; type BBB = Omit<AAA, "foo">; function useString(str: string) {} function useBBB(bbb: BBB) { useString(bbb); // Argument of type 'BBB' is not assignable to parameter of type 'string'. }

fooをうまく剥がせなかったりとか。

これはなんでだめなんだ、深淵に踏み込んでそう

1:42 AM

う〜〜ん。

1:43 AM

確かにnominal + unionで簡単になりそうまでは同意なんですが、一方でunionという概念自体がstructuralなので、中途半端にunionだけ入れた状態では変な困りが生じそうな気がしますねえ

1:43 AM

メインの型の方もstructuralに行かないと。

お疲れ様です。質問させていただきます。 iOSアプリでユーザーセッションをキーチェーンに保存し、ユーザーが別のデバイスに移行し、同じApple IDを使用してアプリをインストールした場合、キーチェーンに保存されたセッションを復元できるかどうかについての質問です。こちらが可能かどうか教えていただければ幸いです。また、もし可能であれば、以下の3つの関連する点についてもお伺いしたいです。設定アプリでiCloudキーチェーンの共有をオフにしている場合、セッション情報は他のデバイスと共有されるのかどうか移行方法によって、セッション情報が共有されない可能性があるかどうか複数のデバイスでアプリを使用している場合、デバイスごとに異なるセッション情報が生成されず、セッション情報を同期させる仕組みが存在するかどうか

同じApple IDでインストールしてるかどうかはアプリ側で判断する術がないはずなので、キーチェーンに保存したものはiCloudキーチェーンで共有されてないと、その情報は別の端末で読み取れないはずです

セッション情報の完全同期も基本難しい（オフライン時に同時に作られたものが複数ある時、オンラインになった時どれを取るかみたいな問題）ので、Safariのタブみたいに、端末ごとのセッションを持ってそれらを全部iCloudとかで上げるのが一番無難かなと思います

Keychainの属性にThisDeviceOnlyを設定してなければ別のデバイスにデータを移行（復元）するとKeychainも移行されるのでそういうシナリオもあります。

ありがとうございます。今回のケースはアプリ内での処理で簡単にできる方法を模索しておりましたので、同期の仕組みを提供する方法は採用せずとしたいと思います。 Keychainの属性にThisDeviceOnlyを設定せず、iPhone→iPhoneによるデバイス移行の手順を踏んだ場合に同期ではなく、移行されるという流れですね。こちらの事情を色々お伝えしておらずでしたが、現実的な落とし所なような気がします。お二人ともありがとうございます！！

1

typed throwsやるなら、同時にuntagged union ( T|U ) の整備も必要だと思うのだけど、そういう指摘はあるかしら

typed throwsと別のスレッドができましたね。(Coreチーム発ではないですが) https://forums.swift.org/t/structural-sum-types-used-to-be-anonymous-union-types/67432 (edited)

Structural Sum Types (used to be Anonymous Union Types)

Spinning off a new discussion thread on the topic of anonymous union types from the Status check: Typed throws thread. The spin-off discussion on this topic began somewhere around this comment.

1

Typed throws のプロポーザルが出ましたね． https://github.com/DougGregor/swift-evolution/blob/typed-throws/proposals/nnnn-typed-throws.md https://github.com/apple/swift-evolution/pull/2184

swift-evolution/proposals/nnnn-typed-throws.md at typed-throws · Do...

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

Typed throws proposal by DougGregor · Pull Request #2184 · apple/sw...

2

https://forums.swift.org/t/se-0410-atomics/68007

SE-0410: Atomics

Hi everyone. The review of SE-0410: Atomics begins now and runs through November 6th, 2023. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or DM. When contacting the review m...

1:08 AM

Swift標準ライブラリにアトミック操作ライブラリ(型)を追加する提案

1:11 AM

ついに言語標準に追加されることになったので、

1:11 AM

メモリオーダーについて勉強しなおした

1:14 AM

https://yamasa.hatenablog.jp/entry/20090816/1250446250

bsdhouse

次期C++に導入されるメモリバリアについて解説してみる - yamasaのネタ帳

前のエントリで次期C++標準(通称C++0x)にatomic型とメモリバリアが導入されるという話をしました。今回はそのC++での実装について、もう少し深く追いかけてみます。スライド資料では「atomic操作＋ acquire/releaseバリア」が基本であると書きましたが、実際に次期C++に導入される予定のatomic APIは、もう少し複雑な仕様になっています。一番の違いは、メモリバリアの種類が増えていることです。次期C++標準の現在のドラフトでは、メモリバリアの種類を表すenum型の定義は以下のようになっています。 namespace std { typedef enum memo…

1

1:15 AM

この記事がわかりやすかった

1:15 AM

seq-cstレベルを指定しなければバグる例を見ると

1:16 AM

もはや現代のコンピュータは、「一つのメモリ空間を複数のスレッドが順番に操作する」という解釈では説明できない挙動をすることがわかる

1:17 AM

まるで、スレッドごとにパラレルワールドが見えていて、それぞれで異なる順番で事象が起きたような挙動をする (edited)

1:22 AM

マルチスレッドプログラムの挙動の正しさを考える時、素朴に「もしこの時系列で各スレッドが動作したら・・・」というふうに考えているけど、それだとバグの事前の発見という意味では、十分ではないんですねえ

swift-atomicsとの違いは何なんでしょうね

プロポーザルを読む限りでは

ちょっと言及があった。基本は同じ機能を提供するけど、経験を活かしてちょっと良くしてるらしい

そうですね、APIとしてはそう

1:34 AM

それと、システムプログラミング言語になるためにはSwift標準ライブラリに必要、というのと、pure swift実装という事が言及されてる

1:35 AM

swift-atomicsはコアな部分をC言語で実装している＋外部パッケージだから

1:36 AM

組み込みなどの特殊なプラットフォームではそれがめんどくさい状況を引き起こしうる？のかも。 (edited)

1:36 AM

あと、

the swift-atomics package was shortly created to experiment and design what a standard atomic API would look like

によると

1:38 AM

swift-atomicsは、標準APIの設計をどうするか実験するために作られたパッケージ、だったらしい？

1:38 AM

swift-atomicsによって経験を経ていい感じのAPIが十分わかったのでいよいよ標準ライブラリに導入するぞ、という事でもあるのかも

そういえばなにかがリンクできなくて困ったケースありましたね

それはあれですね

1:48 AM

scipioによるカスタムビルド (edited)

https://github.com/apple/swift-atomics/blame/main/Sources/_AtomicsShims/src/_AtomicsShims.c#L19-L24

Blaming swift-atomics/Sources/_AtomicsShims/src/_AtomicsShims.c at ...

Low-level atomic operations for Swift. Contribute to apple/swift-atomics development by creating an account on GitHub.

1:48 AM

このへんのやつ

そうそう、Swiftランタイム関数をリンクしようとしているけど

1:48 AM

C側から適切？にその依存を表明できていないから

1:49 AM

リンカーに libSwiftCore が渡されないからビルドできない

1:49 AM

dynamic libraryだとCAtomicsを単体でビルドしようとするからそうなってしまう

1:49 AM

static libraryだと、リンクは最後まで遅延されて、そのときにlibSwiftCoreが巻き込まれるから大丈夫

1:49 AM

今は、そのリンク先のように asm命令でリンカーオプションを埋め込む魔術によって、どうやらなおったらしい。 (edited)

1:50 AM

本質的には(さまざまなものが完璧なら)問題ないはずだけど、実用的には(変な罠やバグをふんだりするから) swift package + Cコード混在である事で、面倒な状況はあるってことですよね (edited)

<stdatomic.h>使ってそうですもんね

1:51 AM

それがSwiftのBuiltinに依存するようになったから、問題が起きにくくなりそう

#if !defined(ATOMICS_NATIVE_BUILTINS) && defined(__swift__) && !defined(__cplusplus) # include <stdatomic.h>

1:52 AM

ほんとだ。

1:52 AM

C言語じゃなくてC++言語ビルドじゃないと動かないのかなあ？

https://forums.swift.org/t/accepted-a-vision-for-embedded-swift/68067

[Accepted] A vision for Embedded Swift

Hello Swift community, I'm pleased to announce that the Language Steering Group has accepted a vision document for Embedded Swift: This document presents a vision for "Embedded Swift", a new compilation model of Swift that can produce extremely small binaries without external dependencies, suitable for restricted environments including embedd...

12:29 AM

Embedded SwiftのVision DocumentがAcceptされてた

12:32 AM

embedded modeでダイナミックな型の機能が全部禁止されて、non allocating modeでヒープメモリ確保するものが全部禁止される

12:33 AM

前者についてはバイナリサイズ削減を重視しているので部分的に使えるならWASM用途にも良さそう

組み込み系でSwiftが覇権を取ったらおもしろいな。

Swift目線だと制約キツいけど、組み込み系なら普通の制約だから、その元でCやRustと比較されそうでも組み込みエアプだからどんな評価になるかイメージ付かないなー

キツキツ制約の下だと単にRustの劣化になってしまわないかが心配だ (edited)

Pythonもけっこう使われてるのかな。競争相手多いな。

2年ほど前からInfo.plistってバイナリに直接埋め込めるようになってたんですね。 https://www.polpiella.dev/info-plist-swift-cli/

Adding an Info.plist file to a Swift executable

Find out how to add extra information to your Swift command-line tool through an Info.plist file while keeping it as a single-file executable.

へー、専用のセクションとして入れたらいいんですね

https://forums.swift.org/t/pitch-task-executor-preference/68191

[Pitch] Task Executor Preference

Hello everyone, We'd like to share a proposal that've been working towards for a while now. Read the full proposal here: SE-NNNN: Task Executor Preference. (In case of small typos, please comment on the pull request) The proposal introduces task executors which enable a structured task hierarchy to have a "preference" where all of its tasks...

1

11:36 PM

konladさんが下書きしてたやつフォーラムに投稿された

11:36 PM

Actorに紐づかないTaskのexecutorを指定できる仕組み

11:37 PM

これでswiftnioのEventLoop threadでTaskが実行できるので、nioをswift concurrencyと組み合わせた時の無駄なホップが無くせる (edited)

Embedded Swiftというのが議論されているのですね。IOKitがEmbedded C++なので、代替になれば面白いですね。

IOKitがEmbedded C++

おお〜そうなんですね

C++ですが、NeXTSTEPのDriverKitの流れなのか、クラスの仕様がObjective-Cとなっています。例えば、クラスの初期化がコンストラクタでなくinitで行うとか。

https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/BaseClasses/BaseClasses.html#//apple_ref/doc/uid/TP0000016-BAJJFCHJ

The Base Classes

The basics of developing device drivers. Includes descriptions of I/O Kit families.

2:16 AM

ほ、ほんとだ、なんだこれわ

Swiftをそのまま組み込みで使うのかC++ interop経由でやるのかどっちがいいか難しそうですね。

4:15 AM

どこまでを組み込みとするか怪しいですが、Linux版Swiftをテコ入れするのでも良さそうな気がする...

組み込み環境はSDKなどがC/C++なので、最初はinteropが良いけど、だんだんそれをラップしてSwiftライブラリを揃えていく進み方をすると思います。 Linux向けSwiftは普通にデスクトップ想定で、メモリ量なども潤沢なので、Embedded Swiftでターゲットにしてる環境ではないと思います。自作キーボードだと現代でもマイコン環境が割と普及してるのでターゲットになりそう。

Raspberry Pi PicoとmicroPythonで自作キーボードみたいな話も見ますよね。 microPythonがやっぱり競合になるんだろうか…？

microPythonはたぶん競合になると思いますねえ。

7:43 AM

Raspberry Pi Picoもそうだし、ESP32でもSwift使えたらよさそう。

https://forums.swift.org/t/pitch-multi-statement-if-switch-do-expressions/68443

Pitch: Multi-statement if/switch/do expressions

A follow-on to SE-0380. Keen to hear everyone's thoughts on the alternatives outlined at the end. Available as a PR here. Multi-statement expressions using then Authors: Ben Cohen, Hamish Knight Review Manager: TBD Status: Awaiting Implementation Implementation: available on main via -enable-experimental-feature ThenStatements and -enable-expe...

6:10 AM

then文のピッチ

6:10 AM

だいたい事前リークどおりついでにdo式も誕生するよ

do式ちょっと欲しかった奴っぽい

6:11 AM

tryをシュッとguardに押し込むみたいなことが出来るようになりそう

1

使い捨てクロージャ書く系のパターンが言語サポートされるとreturnでの帯域脱出もできるし、記号もちょっと減るし嬉しいね

if式入ったタイミングでthenも入ってると思ってたら入ってなくてつかえね〜ってなってた

一行制限結構渋いよね

これで三項演算子と差別化できる

あ、たしかに。そういう見方もあるのか。

これってバグだと思うんですけどどうでしょう？たとえ var があったとしても、main actor isolate されていたら、外からのアクセスも、自身からのアクセスも、 main actor context からのアクセスではない場合は await が必要になるのだから、安全であり、 Sendableでいられると思う・・・実際、このような var って func b のようなメソッドによるgetterとsetterのようなものだと思うので。 (edited)

global

1:40 PM

actorついてない場合に安全じゃないのは正しいと思いますが、その警告がglobal actorついてても出てきてるのは変そうですね

ですよねえ

あー、inoutで渡せちゃうから？

1:42 PM

いや渡すところで禁止されますよね

inoutはget and setですよ

1:43 PM

あーでもasyncにできないか

Function Body Macroの提案仕様が更新されたようです。投稿 https://forums.swift.org/t/function-body-macros/66471/59 プロポーザルドラフト https://github.com/apple/swift-evolution/pull/2219/files (edited)

1

12:36 AM

肝心の問題である関数本体を書き換えるマクロの型チェックについてですが

12:37 AM

preamble: 先頭に追記するだけ、型チェックはマクロ展開前の状態で行う body: マクロ展開前は構文チェックだけ行う、型チェックはマクロ展開後の状態で行うという方針のようです

12:39 AM

The function body as written must be syntactically well-formed (i.e., it must conform to the Swift grammar) but will not be type-checked, so it need not be semantically well-formed.

フォーマルな言語仕様としての話で、IDEが推論に基づく支援をするのは別に禁止はしないんだろうな。

すいません、Swiftについてでなく、Xcodeに関してなのですが・・・。 macOS Sonoma 14.1.2 に、Xcode14.3.1 をインストールしたいのですが、どうしたら良いでしょうか。 Xcode14.3.1 のダウンロードは出来ましたが、インストールができません、エラーになってしまいました。

新しいOSと古いXcodeの組み合わせがダメになってる時はどうしようもないです。（たまに裏技があったりしますが）代わりにXcode15 をインストールすれば良いです。

https://discord.com/channels/291054398077927425/1166660538533679244 ここで上がりましたが、裏ワザがあります

よろしければ、裏ワザを、お教えいただけないでしょうか。 Xcode15は、インストールしてあります。Xcode14と、共存させて、切替ながら使いたいのですが・・・。お手数をお掛けします、何卒よろしくお願い申し上げます。

スレッドに書いてありますが、直接起動することが出来ます。またinfo.plistの内容を書き換えても動きます。Xcode14 sonoma infoplist あたりでググれば参考になるものが見つかると思います

k

よろしければ、裏ワザを、お教えいただけないでしょうか。 Xcode15は、インストールしてあります。Xcode14と、共存させて、切替ながら使いたいのですが・・・。お手数をお掛けします、何卒よろしくお願い申し上げます。

この吹き出しのアイコンがついた青い背景の文章をクリックすると、Discordの別の書き込みにジャンプできて、そのジャンプ先の書き込みに、裏技のやり方が書いてあるブログ記事へのリンクが、書いてあります。

tarunon様早速のご回答、ありがとうございます。「 Xcode14 sonoma infoplist 」でググってみます。感謝いたします。

omochimetaru　様すいません、アイコンがついた青い背景の文章をクリックしても、ジャンプしません。 Discordアプリにて、画面を開いているのですが、ブラウザの方が良いのでしょうか。

2

https://discord.com/channels/291054398077927425/1166660538533679244 こちらのリンクだとどうでしょうか？同じかな

tarunon　様ありがとうございます。クリックしたら、ジャンプしました。度々のご指導、深く感謝いたします。

k

omochimetaru　様すいません、アイコンがついた青い背景の文章をクリックしても、ジャンプしません。 Discordアプリにて、画面を開いているのですが、ブラウザの方が良いのでしょうか。

僕の書き込みの中にあるtarunonの書き込みは、テキストではなく、Discordの画面のスクリーンショット画像なので、クリックできません。

連絡が遅れて、申し訳ございません。粗忽者なので、お許しいただけると幸いです。

1

度々、申し訳ございません。 Xcode14.3.1の解凍は、Info.plistファイルとversin.plistのCFBundleVersionにて21815から22265に変更することで、解決しました。ご指導、色々と、ありがとうございました。その後、Xcode14.3.1を、アプリケーションディレクトリに移行させて、クリックしましたら、以下のメッセージが出ました。 select the platforms you would like to develop for required additional required components will also be installed macOS13.3とiOS16.4の、インストールを求められました。どう、対応したら良いか、ご教授いただけると幸いです。お手数をお掛けします、何卒よろしくお願いします。

多分よくあるシミュレーターとかの環境だけかなと思いますので、そのままインストールクリックすればいいはず…？（スクショあるとわかりやすいです）

すいません、お手数をおかけします。画像を、アップします。もしかして、Info.plistファイルの、DTPlatformVersionとDTSDKnaameを、13.3から14.1.2に変更すれば、良いのかなと考えました。しかし、他の箇所も変更しなくてはいけないかもしれないのと、予期せぬトラブルの可能性があるかも、と考えて止めました。

これは普通に必要なので要求されてますね。installして良いと思います。

8:30 AM

質問ですが、 #beginner-help-archived #beginner-help というスレッドも用意してるので、そちらの利用もご検討ください

ありがとうございました。 Xcode14.3.1のインストーと起動が、出来ました。深く、感謝申し上げます。「beginner-helpとbeginner-help-otameshi利用」の件、かしこまりました。度々の、ご指導、心より御礼申し上げます。

2

https://github.com/apple/swift/pull/69457 マクロがProperty Wrappersみたいにモジュール名で修飾できるようになったらしい。 @Observation.Observable final class Dog {} (edited)

[Macros] Support module-qualified attached macro lookup by ApolloZh...

Allow attached macro expansion syntax to have a module qualifier, @Foo.Bar. Resolves #65485 / rdar://108621205

9

1

お。これは絶対あったほうがいいっすね。

async deferは書けないですよね？awaitする処理をdeferに入れたかった。

書けないです！

ありがとうございます。諦めます！

自前でスコープ関数定義するとかしかないんですよね〜

https://forums.swift.org/t/embedded-swift-running-on-the-raspberry-pi-pico/69001/5 RP2040でSwiftが動くらしい。今はまだC++のSDKをSwiftから使ってるだけだけどSDK自体もSwiftで書いてみようって話が載ってる。

Embedded Swift running on the Raspberry Pi Pico

This is fantastic work, thank you for sharing it on GitHub! This should be possible with Swift SDKs. The build system used for SDK components has no impact on whether you can build software with those components using SwiftPM or not. You only have to assemble an artifact bundle in a format that SwiftPM can understand. Yes, I would love this ...

2

1

RP2040周辺回路がおおくてちょっと使うのが大変

2:11 PM

特にフラッシュ載ってないのがなあ...

RP2040ならキーボードのファームウェアをSwiftで書けるとよかったりしないかしら。 (edited)

フラッシュ乗ってないの地味にだるいですよね

なんですよねー

11:33 PM

AtmelがCOVIDで供給不足になってありえん高さ＆リードタイムになったときに安定供給されたrp2040は魅力があったのですが、

11:33 PM

周辺部品の多さ、3v3つくらなきゃいけないとかでかなり気合いがいるチップなのは事実です

11:34 PM

ただ、仕様や挙動がとてもSWE向けでかつそういう理由で設計の自由度があるので(e.g. flashのサイズが自在)、おおきなソフトウェアも載せられたりして

11:35 PM

十分有望な選択肢だなとは思ってます

11:36 PM

ただキーボード如きには過剰かもと思ったり。

11:36 PM

話かわりますが... (edited)

11:36 PM

https://developer.apple.com/forums/thread/731822

11:37 PM

@Observableと@MainActor使うとactor isolationが怪しくなる問題があって

1

11:37 PM

macroの実装知りたいと思ってるんですが、良い方法なんかないですかね... (edited)

Observableマクロの実装ですか？

ですね...

12:35 AM

SILみるとだいぶいろいろなことをしてくるようで...

まず、一番簡単な初手は、Xcodeで右クリックして expand macro

12:56 AM

その次は、リポジトリにあるテストケースを見ることだと思います。展開前と展開後のコードとして書いてあるので

12:56 AM

で、さらにその次は、ObservableMacroの実装を直接読むことだと思います。

ObservableMacroの実装って公開されているんですね。(勝手に非公開だと思いこんでいた) https://github.com/apple/swift/blob/main/lib/Macros/Sources/ObservationMacros/ObservableMacro.swift

swift/lib/Macros/Sources/ObservationMacros/ObservableMacro.swift at...

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

1

1

なんと、公開されてるのか...

1:01 AM

ソースない前提だった

ObservabilityはSwift ProjectでFoundationみたいなApple Projectじゃないので

1:02 AM

普通に全部見えますよ。

勝手にAppleがこっそり作ってるSwiftUIみたいなやつだと思ってた。思い込み。

2

なるほど、そこか

ドキュメントに(あるものは)ソースコードへのリンクつけて欲しいですねー。 (edited)

https://forums.swift.org/t/pitch-generalize-asyncsequence-and-asynciteratorprotocol/69283

[Pitch] Generalize AsyncSequence and AsyncIteratorProtocol

Hello, Swift evolution! I wrote up a dedicated pitch detailing solutions to two fundamental issues with AsyncSequence and AsyncIteratorProtocol: the bespoke-and-limited @rethrows attribute, and issues with Sendable checking when iterating over an AsyncSequence. This includes the typed throws adoption in AsyncSequence and AsyncIteratorProtocol d...

6:48 PM

AsyncSequenceにprimary associated typeつく

6:49 PM

そしてFailureがtyped throwsに渡される

6:50 PM

謎の言語機能　'@rethrows’ はこれで消せるらしい

6:50 PM

それと、non Sendableな値をAsync Sequenceで扱えなかった(スレッド安全が壊れていた？)問題を修正するために (edited)

6:51 PM

新しいnextElementメソッドは引数でoptionalなisolated引数を持つ

6:53 PM

で、for await inの構文展開ではその引数も自動で展開される

6:55 PM

たしかこれまでのisolatedはActorを取らなきゃいけなくて、nonisolatedを示す方法がなかったこの言語仕様が緩和される

これまでのnextは互換性のために残ってこれからはnextElementを使うらしいけど、苦しいな

5:16 AM

nonisolatedをnilにするためにsome Actor?にできなくてany Actor?になるのもモヤッとするね

5:17 AM

optionalな引数でよくありそうだ

むむ？確かに型が確定しないからsomeになれないんですね

8:51 AM

そのとき（nil相当の挙動をさせたいとき）はnextでいい気がするけど、そうはいかないんでしょうかね (edited)

代案のところに書いてあるけど、メソッドを別にするアプローチは実装共通化できなくて微妙だそう

10:12 AM

今のアイソレーションを取得する　#isolation の話もありそれも意識してそう

10:13 AM

nonisolatedもisolationの一種として、値として扱えるようにgeneralizeしたいそう

ここに書かれていた新しいavailabilityチェックのところがよくわからなかったのですが、Swift5.11からはnext()かnextElement()のどちらかは実装しなければならなくなるので、Swift5.11以前から使っていたものも実装が追加に必要になるということですか？あ、そもそも今はデフォルト実装がないからnext()は必ず実装されているのか。 ``` To avoid silently allowing conformances that implement neither requirement, and to facilitate the transition of conformances from next() to nextElement(), we add a new availability rule where the witness checker diagnoses a protocol conformance that uses an deprecated, obsoleted, or unavailable default witness implementation. Deprecated implementations will produce a warning, while obsoleted and unavailable implementations will produce an error. (edited)

そこの話は、互換性のためのデフォルト実装と、これからのためのデフォルト実装で、どっちのメソッドももう片方を使ってデフォルト実装されるから

10:27 PM

そのままだとどっちも実装しないままでOKになって実行時に壊れてしまうので

10:28 PM

nextElementは手で実装しないと(デフォルト実装はあるけど)怒られるようにする、ということだと思った

特に既存の実装を変更しなければならないという訳ではないんですね。ありがとうございます！

そうですね。ただし新しいSDKだとnextElementを実装するように警告が出るかと

1

https://forums.swift.org/t/se-0421-generalize-effect-polymorphism-for-asyncsequence-and-asynciteratorprotocol/69662

SE-0421: Generalize effect polymorphism for AsyncSequence and Async...

Hello Swift community, The review of SE-0421: Generalize effect polymorphism for AsyncSequence and AsyncIteratorProtocol begins now and runs through February 7, 2024. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, direc...

7:24 AM

新しいAPIが next(isolation:) になったおかげで next() とオーバーロードできるようになって、シンプルな next という名前を維持できる結果になってる。 (edited)

5

https://forums.swift.org/t/pitch-synchronous-mutual-exclusion-lock/69889

[Pitch] Synchronous Mutual Exclusion Lock

Hi all, I would like to propose a new type in the Synchronization module, Mutex. This type is a synchronous mutual exclusion lock, similar to things like OSAllocatedUnfairLock, NIOLock, etc. Please let me know what you think! Synchronous Mutual Exclusion Lock

Proposal: SE-NNNN Author: Alejandro Alonso Review Manager: TBD Status: [stdlib] Imp...

5:05 PM

SynchronizationモジュールにMutexを追加する提案いわゆるロック

5:06 PM

GCDでDispatchQueue使いましょうからの、Actorで、ロックを提供しない長い歴史を経て、結局提供するんかい、と思った

5:07 PM

まあ、結局ローレベル実装では必要だからstdlibやらswift-nioで再実装しまくってるのは良くないね、というのはシンプルによくわかるけど。

こういうクロスプラットフォームなプリミティブが無いとシステムプログラミング言語として闘っていけない！

間違いない

真面目な話として使いやすいロックが無いと、何も保護せずとりあえず @unchecked Sendable をつけるコードが蔓延していく未来が。

今だと DispatchQueueを隣に作ってgetterとsetterをDispatchQueue.syncで保護するのが標準的で移植性も高い書き方という認識

5:26 PM

キューの名前を要求されるのと隣に置くことになるから変数名がもう一個必要で、まあめんどいのはわかる

なるほどそれは現状だとかなりポータブルで少ない手数で書けていいな

5:27 PM

まあ1つのストレージ保護するためだけだとDispatchQueue持ち出すのは仰々しい気もしますが

内部的には結局DispatchQueueを実装するためのミューテックスが一個生成されてるだけな気はしてる(asyncしてないならスレッドは確保されない)

5:28 PM

意味的にはオーバーキルなのはそう

5:29 PM

Mutex<Foo>で楽になるのは良いですね

5:29 PM

逆に今更やるならもっと早い時からあって良かったじゃん感あってモヤモヤする (edited)

~Copyableが必要なんですよ！

あー

5:31 PM

間接化しないでそこに置きたいからstructにしたいけどコピーされてぶっ壊れるのも嫌なのね

そうそう

最高の形で導入するためにずっと力を溜めてたのか・・・

時は満ちた

distributed actorみたいなめっちゃハイレベルな機能とか作った後で、non copy入れてシステムレベルプリミティブに戻ってくる開発計画なんなんだ (edited)

5:35 PM

普通に考えるとローレベル周りからじっくり積み上げていったほうが変な破綻が起きにくそうなのに。

どうなんだろう、真のローレベルであるところのCとのinteropは最初から提供してたからSynchronizationモジュールみたいなやつはローレベルな機能を提供するのが目的というより、ミドルレベルというか使いやすさのためにギャップを埋めるもののように感じてきた

5:41 PM

なので実は上下から攻めていたのではないか

なるほど・・・確かにc interopで誤魔化せるものをお行儀よく使うものだから、できないことをできるようにするよりは後回しなのは自然なのか

ConcurrencyとかDistributed ActorとかはCでは逆立ちしても難しい…

そうだねえ asyncの前って何やってたっけ property wrapperとかORTだっけ

そのあたりのSwiftUI向けのやつだったかなぁ

5:48 PM

あーあとStable ABIか

ABIたしかに

歴史だ...

Swift5.0(2019-03-25)がリリースされてからもう5年経とうとしているんですね…(こわ) https://github.com/apple/swift/blob/main/CHANGELOG.md#swift-50

Swift5系、長生きですね。

Swift、とても好みな言語なのでさまざまなプラットフォームでどんどん使える様になって欲しい...特に組み込み...

https://www.swift.org/gsoc2024/

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

12:35 PM

GSoC2024のテーマおもしろい

12:36 PM

・SwiftSyntaxにAST解析を入れる順当にcxxからswiftにコンパイラ実装を引っ越すための次のステップ

12:38 PM

・AsyncHTTPClientにtracingサポートを実装今業務でトレーシング入れてるんだけど、AHCがネイティブサポートしてくれないと困るなーとちょうど思ってた (edited)

12:40 PM

・プロパティラッパー実装をコンパイラから剥がしてマクロ化するこれも良いよね、プロパティラッパー関係は型推論とかにも特別実装入ったりしてて大変

GSoCおすすめです

家庭くんのバイナリサイズ減らすやつってそういえばどうなったん

大体のDCEはhermetic-seal-at-linkによるLLVMレベルのLTOで達成できたのであとはSwiftPMとのインテグレーションですね

プロパティラッパーをマクロ化はそもそもできるんでしょうかね？

1:06 PM

仕様的に無理なパターンがあったような？

1:09 PM

_enclosingSelf含めて行けるような気もしてきた

Yuta Saito

大体のDCEはhermetic-seal-at-linkによるLLVMレベルのLTOで達成できたのであとはSwiftPMとのインテグレーションですね

あ、そうなのか。じゃあブロッカーは特に無いけど進んでないのは強いモチベーションが無いからか・・・？実際順番的にはWASMとかembeddedサポートが公式に確立してからな気もする「LLVMレベルのLTO」は家庭くんの発表に出てきた、継承関係とか考慮してメタデータも消すやつ、は含まない？

Iceman

仕様的に無理なパターンがあったような？

Macros and init accessors in their current state might not be sufficient to cover all of the property wrapper uses scenarios, so the project is most likely going to require improving and expanding aforementioned features as well.

仕様的に無理な場合みたいなケースを洗い出してマクロ側の仕様を強化するとかの作業も見据えてそう (edited)

omochimetaru

あ、そうなのか。じゃあブロッカーは特に無いけど進んでないのは強いモチベーションが無いからか・・・？実際順番的にはWASMとかembeddedサポートが公式に確立してからな気もする「LLVMレベルのLTO」は家庭くんの発表に出てきた、継承関係とか考慮してメタデータも消すやつ、は含まない？

Swift SDKの準備とかスレッド対応とか色々先にやらないといけないことが沢山あって優先度低めですねー。

LLVMレベルLTO

hermetic-sealモードでは継承関係考慮するやつが有効になります

Yuta Saito

Swift SDKの準備とかスレッド対応とか色々先にやらないといけないことが沢山あって優先度低めですねー。

LLVMレベルLTO

hermetic-sealモードでは継承関係考慮するやつが有効になります

なるほど。そういえばずっと前に、build-script なんとかしないとってテーマもあって、その時はこっそりM1チップ対応してるのかな、みたいな話もあったけど、Swift SDKもビルドなんとかしたいやつの一部か

Swift SDKはこれっすね https://github.com/apple/swift-sdk-generator/

Yuta Saito

Swift SDKの準備とかスレッド対応とか色々先にやらないといけないことが沢山あって優先度低めですねー。

LLVMレベルLTO

hermetic-sealモードでは継承関係考慮するやつが有効になります

hermetic-sealモードそれも対応してるのか　いいねえ

Yuta Saito

Swift SDKはこれっすね https://github.com/apple/swift-sdk-generator/

ああうん、把握してる

ああ、ビルド関連って話でしたか

長い目で見れば繋がってるなあと思った

ビルドシステムはどこもむずかしくて難しい

メタメタしくてややこしいね

難しいから時間がかかる…

@Foo var value みたいな、型を省略するパターンが難しそう

確かに・・・　マクロ展開された computed property は型を明記しないといけないから。 (edited)

1:35 AM

推論された value の型が取れないとどうしようもなさそうですね

1:36 AM

まあせっかくだからマクロに型渡ってくるやつ欲しいですよね

1:37 AM

Code Completion for Keywords using swift-syntax

テーマが増えてる。

GSoCに新しい面白テーマ増えました: Building Swift Macros with WebAssembly https://www.swift.org/gsoc2024/#building-swift-macros-with-webassembly (edited)