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

[Xiaodi Wu]

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

> I totally agree Swift is an opinionated language and it's good.
>
> Also I have been thinking of DefaultConstructable vs reflection for
> generic factories and I would prefer to stick to the protocol as it gives
> compile time type safety check. With reflection the only way is to through
> an exception if there is no init. So again +1 pro to DefaultConstructable.
>

Well, you can't argue both ways. Either so many types implement `init()`
that it is unusually onerous to type, in which case you will gain nearly
nothing from compile-time checks, or not so many types implement `init()`,
and you can conform those types to a protocol by yourself :)


On Mon, 26 Dec 2016 at 12:32 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/8263f2a7/attachment.html>