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

[Xiaodi Wu]

The question still remains unanswered, what generic algorithms are enabled
by having such a protocol? After a long chain, the answer so far is `return
T()`. Indeed, afaict, the semantics you are proposing would explicitly
limit us to that.


On Mon, Dec 26, 2016 at 09:32 Jonathan Hull <jhull at gbis.com> wrote:

> My two cents:
> 1) T() should NOT have anything to do with zero or even “default". (If we
> need semantic zero, create a protocol with a .zero static func/var)
> 2) This comes up enough in my programming, and is such a fundamental
> concept, that T() probably DOES deserve special treatment in the form of a
> protocol
> 3) The semantics of that protocol would be “Things which can be created
> without any additional information beyond their Type”
> 4) We should keep working on the name
>
> As to whether the protocol needs to be implicit… I am unsure.  It may be
> enough to have the standard library + cocoa types conform where
> appropriate.  On the other hand, I can’t think of any type having T() which
> would not fit the above semantics… and I would guess around 85~90% of types
> have it, so it may be worth the trouble to make it implicit in this
> specific case.  I am on the fence, but would probably lean against making
> it implicit.
>
> Thanks,
> Jon
>
>
> On Dec 25, 2016, at 11:28 PM, Daniel Leping via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> It's not a matter of probability, but rather of certainty. Please.
>
> On Mon, 26 Dec 2016 at 12:56 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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:
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/0324c72d/attachment.html>