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

[Daniel Leping]

Braeden, a good point as for inheritance. Totally agree here.

Though the generic factory problem remains. Maybe it could be solved
differently? Any ideas?

The only thing that pops up in mind right now is to have some "compiler
magic" that deals with the constraints. Maybe a concrete class can fall
into the category (be DefaultConstructable).

Anyways, my point is that compile time constraints for a type that can be
created with a default constructor are important for certain patterns. I'm
not saying the protocol is the right or the only way, but I want to find a
solution.

On Tue, 27 Dec 2016 at 5:22 Braeden Profile via swift-evolution <
swift-evolution at swift.org> wrote:

> I’m gonna do my best to explain my thoughts on this, as I just spent an
> hour reading the whole thread…………
>
> I’m -1 on adding the protocol DefaultConstructible to the standard library
> (especially under that name).  It doesn’t explain its semantics
> effectively.  I agree that a protocol should have definite semantics that
> are hopefully explained by the name.  This protocol fails that test—a
> default instance of value types is completely context-specific, and default
> class instances are just iffy to me.
>
> I’m firmly in the camp that you could create a protocol like this for your
> own project and apply it to the types you think semantically fit the
> purpose…
> protocol ZeroConstructible { init() }
> extension Int: ZeroConstructible {  }
> …but I wouldn’t do this myself, as there are too many use-cases with too
> many definitions of “default”.  What if I wanted Int to conform to
> multiple?  It only can have one init().  I’d do something like this…
> protocol ZeroConstructible { static func constructZero() }
> protocol UnsafeConstructible { static func constructUnsafe() }
> protocol FactoryConstructible { static func constructDefault() } // I’ve
> never needed to use a factory, myself...
> …and create those new functions when I conform my types to it.  It’s
> cumbersome, but correct.  As of yet, I’ve never needed to do such a thing,
> and nearly all the use-cases brought up in the thread can be solved with
> something of the like.
>
> Every “default" is context-dependant.
>
>
> Addressing other parts of the thread:
>
>
>    - I read a new name suggested for the protocol:  “Identity”.
>    Unfortunately, I associate that with the proposed protocol HasIdentity {
>    func === }, not a mathematical identity.
>    - DefaultConstructible could never be a normal protocol that magically
>    gets applied where init() exists.  protocol required inits are just
>    that—`required`.  If a superclass conforms to DefaultConstructible, every
>    subclass must, too!  This would give most every class tree the infinite
>    chain of `init()` that NSObject suffers from.
>    - AnyObject was used to justify compiler magic that could be applied
>    for DefaultConstructible.  I disagree that this is appropriate, as
>    AnyObject most certainly implies semantics.  Every AnyObject is a class,
>    with reference semantics, unsafe-weak-strong references, and more.  I could
>    not see definite semantics evolve for DefaultConstructible throughout the
>    whole discussion.
>
>
> That’s my two cents.  Granted, no one would be hurt by its addition except
> those who try to understand this protocol, but I want to avoid that chaos.
>
>
> _______________________________________________
>
> swift-evolution mailing list
>
> swift-evolution at swift.org
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161227/e123fb2a/attachment.html>