<div dir="ltr"><span style="font-size:12.8px">> The all-zero bit pattern represents the integer zero—that's not the same as whether it represents the best "default" value for an integer as a higher-level concept, or whether such a default should exist in the first place.</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It represents a sensible value to initialize an int to when I want to initialize an array of ints to a certain size. There is a reason why you zero out memory but you don't "one out" memory. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">That doesn't explain why the additive identity is more special than the multiplicative one. It just argues that it's more convenient for a particular use case.</span></div><div><span style="font-size:12.8px"><br></span></div><div>Because the identity associated with the default initializer as is is the additive identity which means the default operation is addition. </div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 26, 2016 at 11:57 AM, Tony Allevato <span dir="ltr"><<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On Mon, Dec 26, 2016 at 11:43 AM Adam Nemecek via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></span><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg">> </span><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg">For integers, 0 is an additive identity. Is there a reason it should be given special treatment over 1, the multiplicative identity?</span><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg"> </span></div><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777gmail_msg"></span></div><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg">E.g. for statistical reasons. When I have a collection of users with age etc it makes sense to ask what is the combined age of the collection? What is the semantic meaning of multiplying their ages? </span></div></div></blockquote><div><br></div></span><div>That doesn't explain why the additive identity is more special than the multiplicative one. It just argues that it's more convenient for a particular use case.</div><div><br></div><div>I would turn your example around—if you're interested enough in thorough type design that you feel that a DefaultConstructible protocol would be useful here, then I offer that a better and safer design would be to create an "Age" value type (or, more generally, measurement types with concepts of units) if you want compile-time safety and limiting the supported operations to only those that are sensical. "Int" is arguably too wide a type to represent an age in a public API because it would allow two ages to be multiplied together, as you said.</div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-3715892300944431720m_2612789894267735777gmail_msg"><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><span style="font-size:12.8px">> Mathematically, identities are associated with (type, operation) pairs, not types alone.</span><br></div></span><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777gmail_msg"></span></div><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><span style="font-size:12.8px" class="m_-3715892300944431720m_2612789894267735777gmail_msg">Correct, however we aren't talking about mathematics, we are talking about the implementation of a language that runs on very concrete architectures where very concrete bit patterns mean very concrete things that are unlikely to change any time soon.</span></div></div></blockquote><div><br></div></span><div>The all-zero bit pattern represents the integer zero—that's not the same as whether it represents the best "default" value for an integer as a higher-level concept, or whether such a default should exist in the first place.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="gmail_quote m_-3715892300944431720m_2612789894267735777gmail_msg">On Mon, Dec 26, 2016 at 11:35 AM, Tony Allevato <span dir="ltr" class="m_-3715892300944431720m_2612789894267735777gmail_msg"><<a href="mailto:allevato@google.com" class="m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">allevato@google.com</a>></span> wrote:<br class="m_-3715892300944431720m_2612789894267735777gmail_msg"><blockquote class="gmail_quote m_-3715892300944431720m_2612789894267735777gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For integers, 0 is an additive identity. Is there a reason it should be given special treatment over 1, the multiplicative identity? Historically the only reason is because it has the all-clear bit pattern.<br class="m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777gmail_msg">Mathematically, identities are associated with (type, operation) pairs, not types alone.<br class="m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777gmail_msg">This conversation has put me in the column of "numeric types shouldn't have default initializers at all", personally.<br class="m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="gmail_quote m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840h5 m_-3715892300944431720m_2612789894267735777gmail_msg"><div dir="ltr" class="m_-3715892300944431720m_2612789894267735777gmail_msg">On Mon, Dec 26, 2016 at 11:27 AM Adam Nemecek via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_-3715892300944431720m_2612789894267735777gmail_msg"></div></div></div><blockquote class="gmail_quote m_-3715892300944431720m_2612789894267735777gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840h5 m_-3715892300944431720m_2612789894267735777gmail_msg"><div dir="ltr" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">The elements already have an Identity, the one that you get when you invoke the default constructor. It's 0 for Int, "" for String. </div><div class="gmail_extra m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="gmail_quote m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">On Mon, Dec 26, 2016 at 11:24 AM, David Sweeris <span dir="ltr" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><<a href="mailto:davesweeris@mac.com" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">davesweeris@mac.com</a>></span> wrote:<br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><blockquote class="gmail_quote m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663m_7699876098764341631h5 m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"></div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">On Dec 26, 2016, at 11:12, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"></div><blockquote type="cite" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">There is an older discussion that is somewhat linked to this topic:<div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">"Removing the empty initialiser requirement from RangeReplaceableCollection"<br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023642.html" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">https://lists.swift.org/piperm<wbr>ail/swift-evolution/Week-of-<wbr>Mon-20160704/023642.html</a></div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"></div></div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">Imho "DefaultConstructible" types can be very handy, but so far, it seems no one has presented a single use case that is important enough to justify the inclusion in the stdlib.</div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">On the other hand, I'm quite sure that there's much functionality in the stdlib that many people consider as superfluous…</div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"></div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">I guess adding the protocol wouldn't have a big impact on size, so for for me, the question is "Does this protocol confuse users of Swift?", which I'd answer with "yes, possibly" (unless someone comes up with a name that is more intuitive).</div></div></blockquote><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"></div></div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">"Identity", but, at least for many numeric types, you'd need a mechanism for specifying which one you mean.</div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"></div><div class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">- Dave Sweeris</div></div></blockquote></div><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg"></div></div></div><span class="m_-3715892300944431720m_2612789894267735777gmail_msg">
______________________________<wbr>_________________<br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">
swift-evolution mailing list<br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br class="m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-3715892300944431720m_2612789894267735777gmail_msg">
</span></blockquote></div>
</blockquote></div><br class="m_-3715892300944431720m_2612789894267735777gmail_msg"></div>
______________________________<wbr>_________________<br class="m_-3715892300944431720m_2612789894267735777gmail_msg">
swift-evolution mailing list<br class="m_-3715892300944431720m_2612789894267735777gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-3715892300944431720m_2612789894267735777gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_-3715892300944431720m_2612789894267735777gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br class="m_-3715892300944431720m_2612789894267735777gmail_msg">
</blockquote></span></div></div>
</blockquote></div><br></div></div>