[swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

Xiaodi Wu xiaodi.wu at gmail.com
Mon Dec 26 00:45:13 CST 2016


On Mon, Dec 26, 2016 at 1:21 AM, Daniel Leping <daniel at crossroadlabs.xyz>
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 <xiaodi.wu at gmail.com> wrote:
>
>> On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping <daniel at crossroadlabs.xyz>
>> 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Mon, Dec 26, 2016 at 12:58 AM, Daniel Leping <daniel at crossroadlabs.xyz
>> > 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping <daniel at crossroadlabs.xyz
>> > 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 <xiaodi.wu at gmail.com> wrote:
>>
>> On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution <
>> swift-evolution at swift.org> 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 <
>> swift-evolution at swift.org> 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%.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/1827bd14/attachment.html>


More information about the swift-evolution mailing list