swift-developers-japan
コミュニティ / waiwai-swiftc
3
1
1
1
1
1
1
)
ambitious
import Foundation protocol Factoryable { init(factory: () -> Self) } extension Factoryable { init(factory: () -> Self) { self = factory() } } class MyAnimal: Factoryable { convenience init(name: String) { if name.contains("Cat") { self.init { MyCat() } } else { self.init { MyDog() } } } } class MyCat: MyAnimal { var meou: String { return "meou" } } class MyDog: MyAnimal { func bark(arg: String) -> String { return arg } } let x = MyCat(name: "Dog") let y = x.meou // Crash!!
1
18
3
1
8
1 
4
2
3
2 
6
protocol P {} protocol Foo { var foo: Int { get } } extension Int: P {} extension Array: Foo where Element: P { var foo: Int { return count } } let a = [1,2,3] print(a is Foo)
2
protocol A { static func foo() } extension Dictionary: A where Key == Value { static func foo() { print(type(of: self)) } } extension Array where Element: A { static func foo() { Element.foo() } } [String: String].foo() // Dictionary<String, String> [[String: String]].foo() // Dictionary<Dictionary<String, String>, Dictionary<String, String>> 1
3
どちらでもいい/わからない/考え中 
func a(_ f: @escaping () -> ()) { } func a(_ f: () -> ()) { } 1 
enumがいいのか、という議論になるかというとそうではなくて、（勘違いだったら申し訳ないんですが）Swiftのenumの各タグ（？、たとえば上記の例でいうaとかb）はたしか型パラメーターが取れないです。
1
public protocol HList { } public struct HNil: HList { init() { } } public struct HCons<H, T: HList>: HList { public let head: H public let tail: T public init(_ h: H, _ t: T) { self.head = h self.tail = t } }
extensionで型パラ取らせてくれー
1 1
1
https://stackoverflow.com/questions/38213286/overriding-methods-in-swift-extensions
2
4 2
1
1
1
2
1
️ minimum Swift compiler written in Swift. Contribute to giginet/MinSwift-workshop development by creating an account on GitHub.
ようつべ組ノ
がサロゲートじゃない前提で類推してたので今回の場合には当てはまらなかったすまん。
This copy of libswiftCore.dylib requires an OS version prior to 10.14.4. Abort trap: 6 の対策って文脈で合ってます？ 
7
1 1 
の記事の草稿がhttps://mametter.hatenablog.com/entry/2019/03/27/211140 
で公開されていたりします。RubyのRGenGCでブチあがっていた（過去のはなしか？）笹田さんなどのレビューであったり、そもそもラムダノート社の社長（？）である鹿野さんはSchemeマニアだったりと濃いメンバーが執筆・レビュー・編集しているので、ちょっと興味がある人は買ってみるといいかもです。（実は個人的にLaTeX関連で鹿野さんとはいろいろ付き合いがあるというのもありますが）
1 
@_specialize 大量虐殺 commit です。 https://github.com/koher/swift-image/pull/32/commits/e96103ade5f478cb470fe7cb80061e5f772f0797 2️ minimum Swift compiler written in Swift. Contribute to giginet/MinSwift-workshop development by creating an account on GitHub. 
1
protocol HTraverse { associatedtype Source: HList func traverse(_ f: () -> Void) -> HNil } extension HCons: HTraverse where T: HTraverse { typealias Source = HCons<H, T> // おい！ここを@inlinableにさせてくれ！！ func traverse(_ f: () -> Void) -> HNil { f() return self.tail.traverse(f) } } extension HNil: HTraverse { typealias Source = HNil public func traverse(_ f: () -> Void) -> HNil { f() return HNil() } }
こういう感じでHListをHNil まで型レベルで再帰していくことによって、たとえば HCons<String, HCons<Bool, HCons<Bool, HCons<Int, HCons<Optional<Int>, HCons<String, HCons<Bool, HCons<Bool, HCons<Int, HCons<Optional<Int>, HNil>>>>>>>>>> このように10回HCons がネストした型だと10回の違った（1つずつ展開された）呼び出され型がするため、その分の特殊化（？）でバイナリサイズが爆弾になることを期待してたんですが、コメントにあるとおり、狙った場所に @inlineable を書くとコンパイルがとおらない…… 2 1
1
2
1 1
func foo<X, Y>(_ aa: X, _ bb: Y) -> X { aa } foo((1, 2)) [1] これは第二引数が不足している [2] これは丸括弧が余計(tuple splat fixすべき) 
6
6 2 8 
1 5 
c++ static bool isCompletionHandlerParamName(StringRef paramName) { return paramName == "completionHandler" || paramName == "completion" || paramName == "withCompletionHandler"; } 2
Zenn needs help 
async/await を試せるようにオプションをつけて実行するようにしました。 https://swiftfiddle.com/ibz6zkexrbcmdd3zs2xz3oamkm ホントはネットワークリクエストとかそれっぽいサンプルを書きたかったけど書けないのでしょうがない。
2
ください、３つ超えたらやる 4 2
1
2 1 2
1
kyoprobu です。 
ABC 191 は個人戦です。コンテスト中に他人とコミュニケーションを取ることはできません。本イベントはコンテスト終了後に開催します。 # Swift と競プロ 競技プログラミングにおける Swift 使用人口は多くありません。だからこそ、 Swift 競プロerで集まっ...
kyoprobu です。 ABC 191 は個人戦です。コンテスト中に他人とコミュニケーションを取ることはできません。本イベントはコンテスト終了後に開催します。 # Swift と競プロ 競技プログラミングにおける Swift 使用人口は多くありません。だからこそ、 Swift 競プロerで集まってわい... 
1 
♂️
1 1
async let dinner = { cookDinner() }
https://github.com/ktoso/swift-evolution/blob/wip-tasklocals/proposals/nnnn-task-locals.md#binding-values-for-the-duration-of-a-child-task 
using the group's next method to collect those results as they become ready: // Wait for all of the chopping to complete, collecting the veggies into // the result array in whatever order they're ready. while let choppedVeggie = try await group.next() { choppedVeggies.append(choppedVeggie) }
https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#task-groups-and-child-tasks 
2
(すごい細かいですがwイベントの説明のところが「わいわいswiftc #26」になったままですかね？)
adds async stream rfc by nellshamrell · Pull Request #2996 · rust-lang/rfcs https://t.co/WR4QYCKZ1C
Probably, it will take not one but two major versions to adopt it. Or maybe even zero, and we jus...
2 https://github.com/apple/swift/blob/main/CHANGELOG.md 3 1
https://t.co/9l1TI3NvYR
3
1
Float80サポートと共にFloatingPointの文字列化をSwiftDtoaに置き換えようとしてやめたことを思い出した。 https://github.com/jpsim/Yams/pull/151
2 1 2 1
11/15 
11/16 
11/17 
11/18 
11/19 2 1 3 3 3 2
1
1 1
01/24 01/25 01/26 01/27 01/28 1 3 3 2 1
1
1
3
1
1
a.components(separatedBy: "_") ですかね？
1
5 1
2
2
A function or closure that throws can effectively return a value of any type that conforms to the Error protocol. If the function is called from a different concurrency domain, the thrown value can be passed across it. To close this safety hole, we alter the definition of the Error protocol to require that all error types conform to Sendable:
https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md#thrown-errors
// このように Animal を継承した Cat, Dog があるときに class Animal { ... } class Cat: Animal { ... } class Dog: Animal { ... }
// Covariant final class List<T> { // 戻り値の位置で T を利用 → Covariant get(at index: Int) -> T } let cats: List<Cat> = ... let animals: List<Animal> = cats // ✅ OK: なぜなら // ↓取り出された Cat インスタンスは Animal なので問題ない let animal: Animal = animals.get(at: 0)
// Contravariant final class List<T> { // 引数の位置で T を利用 → Contravariant set(_ value: T, at index: Int) } let cats: List<Cat> = ... let animals: List<Animal> = cats // ⛔ NG: なぜなら // ↓ animals === cats に Dog インスタンスを set できて破綻 animals.set(Dog(), at: 0) 2// Contravariant × Contravariant → Covariant final class List<T> { // 引数に渡すクロージャの引数の位置で T を利用 // Contravariant × Contravariant → Covariant func map<U>(transform: (T) -> U) -> List<U> } let cats: List<Cat> = ... let animals: List<Animal> = cats // ✅ OK: なぜなら↓ // ↓ map に渡されたクロージャが // 引数で受け取った Animal の任意のメンバにアクセスしても、 // 実際に渡されるのは Cat なので問題ない let noses: List<Nose> = animals.map(\.nose) 1
protocol P {} func makeP() -> some P { return fatalError() } <stdin>:3:12: error: return type of global function 'makeP()' requires that 'Never' conform to 'P' return fatalError() ^ <stdin>:2:17: note: opaque return type declared here func makeP() -> some P { ^~~~~~
1 2
func f<T>() -> any Sequence<T> 
2
1
1 3
2
1 1
とは関係ない
_RegexBuilder はいけた
1
7
let re = /Hello, (\w+)?/ <stdin>:1:19: error: expected pattern let re = /Hello, (\w+)?/ ^ <stdin>:1:23: error: consecutive statements on a line must be separated by ';' let re = /Hello, (\w+)?/ ^ ; <stdin>:1:23: error: expected expression let re = /Hello, (\w+)?/ ^ <stdin>:1:10: error: '/' is not a prefix unary operator let re = /Hello, (\w+)?/ ^ <stdin>:1:11: error: cannot find 'Hello' in scope let re = /Hello, (\w+)?/ ^~~~~
1
https://t.co/jR3DFSDHAI #swiftwasm
KeyPath の高速化に取り組んでいるらしく (Forums より) て，ランタイム側の変更だけでも割と速くなるみたいですね． https://github.com/apple/swift/pull/60758 
2 6
ください 14
6 1 頂いてもいいですか？
1 1
4
Watcher, bundler, and test runner for your SwiftWasm apps - GitHub - swiftwasm/carton: Watcher, bundler, and test runner for your SwiftWasm apps
1 1 1
2
3 1 1
1 1♂️ 発表時の補足なのですが、 StateObjectなどに関してはここにコメントがあって https://forums.swift.org/t/pitch-observation/62051/12 結論は「開発中なのでまだなんとも言えない」なんですけど、 @ Stateに対するStateObjectのように、XXXObjectは残るみたいですね。 
オフ 
あう 
all @*Object property wrappers will be able to be used as their non-object counterparts - i.e. where you used @StateObject before just @State etc. ただ、その下で、なるべくPropertyWrapperをつける作業は消したいようなことも言ってます。 the intent is to allow for when Observable is used developers need to consider fewer potential property wrappers and in the case where no lifetime specialities or bindings are needed and just plain observations are desired, no property wrapper is required. 3After taking the motivating use cases surfaced in this pitch thread and implementing them as macros, I'm confident that macros can fully subsume type wrappers while providing more flexibility to library authors.
https://forums.swift.org/t/pitch-type-wrappers/60019/45 
Holly and I have been collaborating on some updates to this for the use of macros.
https://forums.swift.org/t/pitch-observation/62051/105 1 1
1 1
1
14
リアクションをするだけでOKです 2 1
1 + (2 * 3) 1
1
1
1 4 1 1 1
サイズの箱
です
FooRepository を使う Container1 があったとして、仕様変更になったときに BarRepository も必要になったら、たとえコンストラクタインジェクションしててもコンストラクタ（イニシャライザ）の引数を増やさないといけないですよね？ final class Container1 { - init(fooRepository: any FooRespository) { + init(fooRepository: any FooRespository, barRepository: any BarRepository) { そうなると、 Container1 の利用箇所に問題が波及しますし、もし Container2 が Container1 をイニシャライズするような場合、 Container2 のイニシャライザにも影響が出たりしませんか？ final class Container2 { - init(fooRepository: any FooRespository) { + init(fooRepository: any FooRespository, barRepository: any BarRepository) { self.fooRepository = fooRepository + self.barRepository = barRepository - self.container1 = Container1(fooRepository: fooRepository) + self.container1 = Container1(fooRepository: fooRepository, barRepository: barRepository) なので、ある程度広めにまとめて多少利用しないものが入っても気にしないようにしており、そうすると（型パラインジェクションする場合でも）DIのための型パラは大抵一つにおさまるので、そこまで型パラが問題になることは多くないのではないかと思います。
Foo<> には、 直接の Repository と、 UserEditService の型パラメータの Repository と、 ZooEditService の型パラメータの Repository が3回出現しているので、 型パメータとして具体的な依存の実体である DatabaseRepository を 3回書かないといけない。 しかもこれは Repository を利用するコンポーネントが増えるたびに増えていきます。 一般的な動的なDIコンテナだったら、 まず Repository を登録して、その他のそれを利用するサービスは、 自身の依存先を DIコンテナ自体から取り出す事によって構築するので、 「具体的なRepositoryが何であるか」という宣言(コード上の表明) は1箇所で良いはずが、 このアプローチだと自明なはずの事を何度も繰り返して書かないといけない問題がありそうです。
1 1
1 3 1
2 1
repeat each だろうが 特別扱いなどはされないですかね https://fxtwitter.com/treastrain/status/1796142350349033730
1
3
3 1 8 1
comparing solutions 1 and 0 Comparing declarations func f(_ v: any P) { return } and func f(_ v: some P) { return } (isDynamicOverloadComparison: 0) comparison result: better Comparing declarations func f(_ v: some P) { return } and func f(_ v: any P) { return } (isDynamicOverloadComparison: 0) comparison result: not better comparing solutions 1 and 0 better とは... この部分を判定してそうなコードはありました // A non-generic declaration is more specialized than a generic declaration. if (auto func1 = dyn_cast<AbstractFunctionDecl>(decl1)) { auto func2 = cast<AbstractFunctionDecl>(decl2); if (func1->isGeneric() != func2->isGeneric()) return completeResult(func2->isGeneric()); }
https://github.com/apple/swift/blame/4517333b8ef249d2d8774a5e62b00ed1042bd1f5/lib/Sema/CSRanking.cpp#L482 