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

[Xiaodi Wu]

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.


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%.
>>
>> On Sun, Dec 25, 2016 at 9:17 PM, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>>
>>
>> on Sun Dec 25 2016, Daniel Leping <swift-evolution at swift.org> wrote:
>>
>>
>>
>>
>>
>> > You are right, usually it's required to implement a protocol which is
>> not a
>>
>>
>> > good approach. The best is plain objects which can be used
>> independently of
>>
>>
>> > ORM if needed (as DTOs, i.e.).
>>
>>
>> >
>>
>>
>> > I was thinking of DefaultConstructable as a protocol automatically
>> applied
>>
>>
>> > to any class/struct having a default init, which is really logical for
>>
>>
>> > me.
>>
>>
>>
>>
>>
>> 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.
>>
>>
>>
>>
>>
>> > On Mon, 26 Dec 2016 at 9:41 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>
>> >
>>
>>
>> >> On Sun, Dec 25, 2016 at 10:50 PM, Daniel Leping
>>
>>
>> >> <daniel at crossroadlabs.xyz>
>>
>>
>> >> wrote:
>>
>>
>> >>
>>
>>
>> >> Ok, an example from ORM. You have an entity factory with a virtual
>> (read,
>>
>>
>> >> overloadable in the subclasses) method populating the properties.
>>
>>
>> >> DefaultConstructable is a great choice here. Otherwise you will have to
>>
>>
>> >> force the users of your ORM to implement a certain protocol, which you
>> most
>>
>>
>> >> probably would like to avoid.
>>
>>
>> >>
>>
>>
>> >>
>>
>>
>> >> Sorry--I'm not very familiar with using Swift for ORM purposes. Why do
>> you
>>
>>
>> >> want to avoid having your users conform to a certain protocol?
>> Wouldn't the
>>
>>
>> >> users of your ORM have to conform to `DefaultConstructible` then? I'm
>>
>>
>> >> looking at Swift ORMs, and all require users to conform to a protocol
>> or
>>
>>
>> >> inherit from a base class, typically named `Model` or similar. From a
>> quick
>>
>>
>> >> Google search:
>>
>>
>> >>
>>
>>
>> >> https://vapor.github.io/documentation/fluent/model.html
>>
>>
>> >> https://github.com/blitzagency/amigo-swift
>>
>>
>> >>
>>
>>
>> >>
>>
>>
>> >> In general I think the best showcase is generic factories.
>>
>>
>> >>
>>
>>
>> >> On Mon, 26 Dec 2016 at 9:02 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>
>> >>
>>
>>
>> >> On Sun, Dec 25, 2016 at 10:18 PM, Daniel Leping
>>
>>
>> >> <daniel at crossroadlabs.xyz>
>>
>>
>> >> wrote:
>>
>>
>> >>
>>
>>
>> >> Usually it's a generic function that needs to return a value from some
>>
>>
>> >> other function or a default value (zero) in a case of some conditions.
>>
>>
>> >> Optional value is an arguable solution in quite some scenarios. Afaik,
>>
>>
>> >> sometimes it can be used for optional resolution.
>>
>>
>> >>
>>
>>
>> >>
>>
>>
>> >> Right, I'd agree that Optional is the idiomatic way to do it. Afaict,
>>
>>
>> >> there's not much you can do with a default value that you couldn't with
>>
>>
>> >> nil, unless you have some guarantee as to _what_ that default is;
>> however,
>>
>>
>> >> I'd expect that in every case that you can rely on a guarantee about a
>>
>>
>> >> default value which would be more useful than nil, it's going to
>> require
>>
>>
>> >> more specific knowledge of your type than an all-encompassing
>>
>>
>> >> `DefaultConstructible` can provide.
>>
>>
>> >>
>>
>>
>> >> Also, generic factories. Widely used in ORM solutions.
>>
>>
>> >>
>>
>>
>> >>
>>
>>
>> >> Can you elaborate on this? Why is Optional not a solution here?
>>
>>
>> >>
>>
>>
>> >>
>>
>>
>> >> As mentioned above, algorythmical stuff that requires Zero.
>>
>>
>> >>
>>
>>
>> >>
>>
>>
>> >> I'm still not convinced there exist credible use cases that need to be
>>
>>
>> >> generic over both collections and floating point, for instance. In
>> fact, in
>>
>>
>> >> my experience, there are few math-heavy algorithms where one can ignore
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/2062afc4/attachment-0001.html>