<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m gonna do my best to explain my thoughts on this, as I just spent an hour reading the whole thread…………<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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…</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol ZeroConstructible { init() }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>extension Int: ZeroConstructible { }</div><div class="">…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…</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol ZeroConstructible { static func constructZero() }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol UnsafeConstructible { static func constructUnsafe() }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol FactoryConstructible { static func constructDefault() } // I’ve never needed to use a factory, myself...</div><div class="">…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.</div><div class=""><br class=""></div><div class="">Every “default" is context-dependant.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Addressing other parts of the thread:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">I read a new name suggested for the protocol: “Identity”. Unfortunately, I associate that with the proposed protocol HasIdentity { func === }, not a mathematical identity.</li><li class="">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.</li><li class="">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.</li></ul><div class=""><br class=""></div></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>