<div dir="ltr">&gt; <span style="font-size:12.8px">Array already has init(repeating:count:) that puts the responsibility of choosing the default value at the call site. If someone were writing a generic algorithm around this, then why not just propagate that responsibility out to its call site as well? That way, the algorithm isn&#39;t making any assumptions about what the &quot;default&quot; value is or even if one exists,</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Because encapsulation. There&#39;s a reason NSObject has a default initializer.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 26, 2016 at 12:10 PM, Tony Allevato via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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 class="">On Mon, Dec 26, 2016 at 11:57 AM David Sweeris via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="m_7676584481830758401gmail_msg"><div class="m_7676584481830758401gmail_msg"><br class="m_7676584481830758401gmail_msg"></div><div class="m_7676584481830758401gmail_msg">On Dec 26, 2016, at 11:35, Tony Allevato &lt;<a href="mailto:allevato@google.com" class="m_7676584481830758401gmail_msg" target="_blank">allevato@google.com</a>&gt; wrote:<br class="m_7676584481830758401gmail_msg"><br class="m_7676584481830758401gmail_msg"></div><blockquote type="cite" class="m_7676584481830758401gmail_msg"><div class="m_7676584481830758401gmail_msg">Mathematically, identities are associated with (type, operation) pairs, not types alone.<br class="m_7676584481830758401gmail_msg"><br class="m_7676584481830758401gmail_msg">This conversation has put me in the column of &quot;numeric types shouldn&#39;t have default initializers at all&quot;, personally.
</div></blockquote><br class="m_7676584481830758401gmail_msg"></div><div dir="auto" class="m_7676584481830758401gmail_msg"><div class="m_7676584481830758401gmail_msg">I&#39;d agree, except sometimes you need a T, <i class="m_7676584481830758401gmail_msg">any</i> T, for when you want to create a &quot;pre-sized&quot; array for stuffing results into by index:</div><div class="m_7676584481830758401gmail_msg">for i in ... {</div><div class="m_7676584481830758401gmail_msg">    a[i] = ...</div><div class="m_7676584481830758401gmail_msg">}</div><div class="m_7676584481830758401gmail_msg">Simply saying &quot;var a =[T](); a.reserveCapacity()&quot; doesn&#39;t cut it because it&#39;ll still crash if you try to store anything in a[i] without somehow putting at least i+1 elements in the array first.</div></div></blockquote><div><br></div></span><div>Array already has init(repeating:count:) that puts the responsibility of choosing the default value at the call site. If someone were writing a generic algorithm around this, then why not just propagate that responsibility out to its call site as well? That way, the algorithm isn&#39;t making any assumptions about what the &quot;default&quot; value is or even if one exists, and it doesn&#39;t impose additional requirements on the element type. For example, the user could get the default from a static factory method, an instance method on another object, or something else entirely.</div><span class=""><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="auto" class="m_7676584481830758401gmail_msg"><div class="m_7676584481830758401gmail_msg"><br class="m_7676584481830758401gmail_msg"></div><div class="m_7676584481830758401gmail_msg">- Dave Sweeris</div></div>______________________________<wbr>_________________<br class="m_7676584481830758401gmail_msg">
swift-evolution mailing list<br class="m_7676584481830758401gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_7676584481830758401gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_7676584481830758401gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_7676584481830758401gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="m_7676584481830758401gmail_msg">
</blockquote></span></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>