On Mon, Dec 26, 2016 at 1:21 AM, Daniel Leping <[email protected]> wrote:
> I believe you're confusing in-class factory methods with factory pattern. > > Factories can be separate objects and it's a very different situation. > Fair, but I understand both to fall under the umbrella of "any factory pattern" and just wanted to point out that at least some of those patterns seem to be discouraged :) In any case, I think it's fair to say that the question "does this type implement `init()`?" is properly a reflection question and not a protocol conformance question: the answer provides no semantic guarantees whatsoever about the value that you get from `init()`, and in your use case you do not care and simply want to invoke the initializer and return what you get from it. Now, in a perfect world where the reflection facilities that Swift provided were essentially free of performance cost, would you object to that characterization? You're certainly right that `AnyObject` has magic. It's rather obvious that Obj-C bridging is non-negotiable for Swift, and of course a bridged type is all sorts of different under the hood from a native type. I'm going to take a wild guess that no other use case would pass that high bar for magic. [Resent after truncating replies.] > On Mon, 26 Dec 2016 at 11:46 Xiaodi Wu <[email protected]> wrote: > >> On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping <[email protected]> >> wrote: >> >> I'm giving a wider range, which is about ANY factory pattern related >> stuff. Doesn't look to be narrow to me. >> >> >> I thought factory methods were regarded as undesirable in Swift? One of >> the stated reasons for failable initializers was: "Failable initializers >> eliminate the most common reason for factory methods in Swift... Using the >> failable initializer allows greater use of Swift’s uniform construction >> syntax, which simplifies the language by eliminating the confusion and >> duplication between initializers and factory methods." < >> https://developer.apple.com/swift/blog/?id=17> >> >> >> On Mon, 26 Dec 2016 at 11:38 Xiaodi Wu <[email protected]> wrote: >> >> On Mon, Dec 26, 2016 at 12:58 AM, Daniel Leping <[email protected] >> > wrote: >> >> Well, reflection is a huge performance drop. Protocol conformance is way >> better. >> >> >> I'm not sure how huge it would be in the grand scheme of things; in your >> example, you are still evaluating a train of protocol conformances and >> casting at runtime. Of course, compiler magic can be fast, but I still >> don't see how this is a "very common use case" (as you write) that would >> justify magic equivalent to that for Objective-C bridging, which is what >> you're saying it should be. If `DefaultConstructible` is useful only when >> it's magic and the specific use case is dependency injection/inversion of >> control, then we're getting very specialized here. >> >> >> On Mon, 26 Dec 2016 at 11:26 Xiaodi Wu <[email protected]> wrote: >> >> On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping <[email protected] >> > wrote: >> >> I'm not arguing for implicit conformance in general, but I'm telling that >> DefaultConstructable is the same basic level as AnyObject, which is >> conformed implicitly. >> >> Shortly, I'm against implicit conformance in general. I'm positive with >> "automatic compiler magic" conformance to DefaultConstructable for any >> object having a default constructor as it really is a very basic stuff. >> Otherwise you will have to add explicit conformance to it in almost every >> class of yours (annoying). >> >> >> Well, this sounds very different from Adam's proposal, where he proposes >> semantic meaning for `init()` that, as he described, means that it cannot >> apply to every type that implements `init()`. However, he also just said >> that he thinks that all types with `init()` should conform, so I guess I'm >> confused which way that is. >> >> At base, you want a way of knowing if a type has `init()`. That sounds >> like reflection to me, not protocol conformance. For the record, I look >> forward to the day when AnyObject magic is removed; I assume it is coming >> eventually. >> >> >> On Mon, 26 Dec 2016 at 11:14 Xiaodi Wu <[email protected]> wrote: >> >> On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution < >> [email protected]> wrote: >> >> Thank you, Adam! >> >> >> Wait, are you arguing for implicit conformance or not? >> >> On Mon, 26 Dec 2016 at 11:12 Adam Nemecek via swift-evolution < >> [email protected]> wrote: >> >> > Swift doesn't do implicit conformance. It always has to be declared >> explicitly. I'm pretty sure Doug Gregor can explain why better than I >> could. >> >> >> I don't think Daniel was arguing for implicit conformance, he's saying >> that if it makes sense for an object to have a default constructor, it >> makes sense for it to conform to the protocol which I agree with 100%. >> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
