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

[Xiaodi Wu]

On Mon, Dec 26, 2016 at 1:48 AM, Daniel Leping <daniel at crossroadlabs.xyz>
wrote:

> Well, AnyObject exists on Linux with no bridging. Still it's IMPLICITELY
> conformed by all classes.
>
> What you say is just another approach to the same issue and we can argue
> for eternity. However, I am very positive with syntactic sugar and this one
> falls exactly to sugar category. Make people lifes easier ;)
>
> Moreover it will never ever do any harm.
>
> Adding an easy way to get another set of frameworks/approaches/etc (proven
> by time, btw) on board sounds very appealing to me. I wish to see Swift a
> very diverse ecosystem and this Pitch serves exactly this goal.
>

Yes, we should let others chime in on this issue. I will just end by saying
that I've always appreciated how the core team has been very careful and
thoughtful about certain precepts, and how they've stuck to the idea that
Swift is an _opinionated_ language.

In particular, I appreciate that there's a huge amount of thought put into
semantic meaning. The notion that protocols should carry semantics has been
adhered to very strictly. This is why I think this proposal does do harm,
because it explicitly rejects that very important idea, one that can only
be upheld by people and not compilers.

(Another semantic distinction observed in Swift is that a boolean value has
semantic meaning and is not just a bit; this is why, for instance, the
FloatingPoint protocols define an `enum FloatingPointSign { case plus,
minus }`--because floating point sign has different _semantics_ from a
Bool.)

Let's just see if it gets any more positive votes.
>
> On Mon, 26 Dec 2016 at 12:10 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> 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:
>>
>>
>> >>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/c7f9fdc5/attachment.html>