<div>+1 to this approach. I remember I had to create it on my own for my projects. Would be nice to have it out of the box.</div><div><br><div class="gmail_quote"><div>On Mon, 26 Dec 2016 at 8:11 Adam Nemecek via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">Yes, those particular types have initializers that take no arguments. That does not address my question. You merely restated your initial observation that many types in Swift have implemented `init()`.</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></div><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">Right, it&#39;s an empirical argument.</span></div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>&gt; <span style="font-size:12.8px" class="gmail_msg">I didn&#39;t think the value returned by `init()` was regarded as any sort of zero--or even any sort of &quot;default.&quot; In fact, some types in Foundation have a static property called `default` distinct from `init()`.</span><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></div><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">Let&#39;s not talk about those then. This would not apply to every single type in existence, as I&#39;ve stated previously.</span></div></div><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">&gt; </span><span style="font-size:12.8px" class="gmail_msg">It gives you something different every time. How can this be squared with your stated motivation regarding concepts of zero and concepts of equality?</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></div><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">Due to the fact that it&#39;s a resource, not a value. As I&#39;ve stated above, not all of this applies to types that are more resource-like.</span></div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">Or, it&#39;s what you get because that&#39;s the most trivial possible string. Quite simply, I do not think the designer of most types that implement `init()` have paused to wonder whether the value that you get is the identity element associated with the most useful and prominent operation that can be performed on that type. I certainly never have.</span><br class="gmail_msg"></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">This is an appeal to tradition. </span></div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">&gt; </span><span style="font-size:12.8px" class="gmail_msg">The statement I wrote was in JavaScript, so I&#39;m not sure what you mean by returning an optional. `[]</span><span style="font-size:12.8px" class="gmail_msg">.reduce((a, b) =&gt; a + b)` results in an error in JavaScript. In Swift, such a function may also be implemented with a precondition that the array is not empty and would not return an optional.</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">I was talking about their </span><span style="font-size:12.8px" class="gmail_msg">analogous </span><span style="font-size:12.8px" class="gmail_msg">swift implementations.</span></div></div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">Can you give an example of an algorithm dealing with tensors where you would use a `DefaultConstructible` generic over all types that have `init()`, as opposed to working with the existing `Integer`, `FloatingPoint`, and other numerical protocols?</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></div><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">If it&#39;s implemented as either nested collections or numbers. </span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Dec 25, 2016 at 6:00 PM, Xiaodi Wu <span class="gmail_msg">&lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><span class="gmail_msg">On Sun, Dec 25, 2016 at 7:30 PM, Adam Nemecek <span class="gmail_msg">&lt;<a href="mailto:adamnemecek@gmail.com" class="gmail_msg" target="_blank">adamnemecek@gmail.com</a>&gt;</span> wrote:<br class="gmail_msg"></span><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><span class="m_3012462067322088809m_1176161565890972384gmail- gmail_msg"><span style="font-size:12.8px" class="gmail_msg">&gt;  Is it well settled, either in Swift or in C++/Rust/etc., that the value returned by a default initializer/constructor is regarded as an identity element or zero? </span><br class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></span><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">Int() == 0, String() == &quot;&quot; so to some extent by convention, a lot of types have a default value as is.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Yes, those particular types have initializers that take no arguments. That does not address my question. You merely restated your initial observation that many types in Swift have implemented `init()`.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I didn&#39;t think the value returned by `init()` was regarded as any sort of zero--or even any sort of &quot;default.&quot; In fact, some types in Foundation have a static property called `default` distinct from `init()`. In Rust, the Default trait requires a function called `default()`, which is documented as being useful when you want &quot;some kind of default value, and don&#39;t particularly care what it is.&quot;</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I was asking whether there&#39;s some understanding, of which I&#39;ve been unaware, that the result of `init()` (or the equivalent in other languages) is expected to be some sort of zero or an identity element. I&#39;m not aware of any evidence to that effect. Are you?</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><span class="m_3012462067322088809m_1176161565890972384gmail- gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">&gt; Is the thread that I get by writing `let t = Thread()` some kind of zero in any reasonable sense of the word?</span><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></span><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">DefaultConstructibility makes less sense for types that represent some sort of resource but make sense for things that are values. But even in this case, Thread() gives you a default value for example if you are working with a resizable collection of threads.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">It gives you something different every time. How can this be squared with your stated motivation regarding concepts of zero and concepts of equality?</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">A better question is why does thread currently implement a default constructor? </span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">It&#39;s an initializer that takes no arguments, because none are needed for a new thread. How else would you write it?</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><span class="m_3012462067322088809m_1176161565890972384gmail- gmail_msg"><div class="gmail_msg"><div style="font-size:12.8px" class="gmail_msg">&gt; Do you mean to argue that for an integer the additive identity should be considered &quot;more prominent and useful&quot; than the multiplicative identity? I&#39;m not aware of any mathematical justification for such a conclusion.</div></div><div style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></div></span><div style="font-size:12.8px" class="gmail_msg">I do. The justification is that if I call the default constructor of Int currently, I get the value of 0.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">This is backwards. Why do you believe that the value you obtain from `init()` is intended to be an identity element at all, let alone the most important one? (It&#39;s also circular reasoning. Since `init()` only ever gives you one value at a time, by your reasoning it demonstrates that every type must have one &quot;more prominent and useful&quot; identity, which is begging the question.)</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div style="font-size:12.8px" class="gmail_msg">Which means that the binary operation must be addition.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Based on the value of `Int.init()`, you conclude that addition of integers is a &quot;more prominent and useful&quot; operation than multiplication? Again, this is backwards. Rather, we know that each numerical type belongs to multiple ring algebras; there is no basis for reckoning any as &quot;more useful.&quot; Since `init()` can only ever give us one value at a time, we know that `init()` cannot give a value that is a meaningful default with respect to any particular operation.</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div style="font-size:12.8px" class="gmail_msg">If I call String() I get &quot;&quot; which is the identity of the + String operation.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Or, it&#39;s what you get because that&#39;s the most trivial possible string. Quite simply, I do not think the designer of most types that implement `init()` have paused to wonder whether the value that you get is the identity element associated with the most useful and prominent operation that can be performed on that type. I certainly never have.</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><span class="m_3012462067322088809m_1176161565890972384gmail- gmail_msg"><div style="font-size:12.8px" class="gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">Going to your original example, I should add: other languages provide a version of `reduce` that doesn&#39;t require an initial result (for instance, JavaScript). In JavaScript, `[1, 2, 3].reduce((a, b) =&gt; a + b)` uses the element at array index 0 as the initial result, and the accumulator function is invoked starting with the element at array index 1. This is precisely equivalent to having `reduce` use the additive identity as the default initial result when + is the accumulator function and the multiplicative identity when * is the accumulator function (with the accumulator function being invoked starting with the element at array index 0). It does not require a DefaultConstructible protocol. What more ergonomic solution could be implemented using a monoidic wrapper type?</span></div><div style="font-size:12.8px" class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></span><div style="font-size:12.8px" class="gmail_msg">These two will have different signatures. The reduce you describe returns an optional,</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">The statement I wrote was in JavaScript, so I&#39;m not sure what you mean by returning an optional. `[]<span style="font-size:12.800000190734863px" class="gmail_msg">.reduce((a, b) =&gt; a + b)` results in an error in JavaScript. In Swift, such a function may also be implemented with a precondition that the array is not empty and would not return an optional.</span></div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div style="font-size:12.8px" class="gmail_msg">the other one would returns the default value.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">In what scenario would you prefer to propagate a default after reducing a potential empty collection _without supplying an explicit default_ for that operation? This would certainly violate the Swift convention of not defaulting to zero and, I suspect, most users of Swift would not regard that as ergonomic at all.</div><span class="gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div style="font-size:12.8px" class="gmail_msg">Fundamentally the default constructibles are useful in numerical computations e..g. dealing with tensors.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Can you give an example of an algorithm dealing with tensors where you would use a `DefaultConstructible` generic over all types that have `init()`, as opposed to working with the existing `Integer`, `FloatingPoint`, and other numerical protocols? (I should also add, FWIW, I have never seen a generic algorithm written for integers or FP types that has preferred the use of `T()` over `0`.)</div><div class="gmail_msg"><div class="m_3012462067322088809h5 gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="m_3012462067322088809m_1176161565890972384gmail-HOEnZb gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-h5 gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Dec 25, 2016 at 3:30 PM, Xiaodi Wu <span class="gmail_msg">&lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><span class="gmail_msg">On Sun, Dec 25, 2016 at 5:27 PM, Adam Nemecek <span class="gmail_msg">&lt;<a href="mailto:adamnemecek@gmail.com" class="gmail_msg" target="_blank">adamnemecek@gmail.com</a>&gt;</span> wrote:<br class="gmail_msg"></span><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><span class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail- gmail_msg"><div class="gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">*Which* APIs become more ergonomic?</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></span><div class="gmail_msg">I&#39;ll get back to this question in a second if I may. This would be a longer discussion and I first want to make sure that before we get into the details that there is a possibility of this being introduced (I&#39;m asking if violating the no zero defaults is more important than slightly more ergonomic APIs). But to give a broad answer I think that the concept of a zero is closely related to the concept of equality (and all the things that build up on equality such as comparability and negation). </div><span class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail- gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">1) How does this square with Swift’s general philosophy to not default initialize values to “zero”?</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></span><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">I actually wasn&#39;t aware of this philosophy. Despite this philosophy, look at how many types actually currently implement a default constructor.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">(Not a rhetorical question:) Is it well settled, either in Swift or in C++/Rust/etc., that the value returned by a default initializer/constructor is regarded as an identity element or zero? Is the thread that I get by writing `let t = Thread()` some kind of zero in any reasonable sense of the word?</div><span class="gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">Also can I ask what&#39;s the motivation behind this philosophy? </span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">I think that in Swift, default constructibility makes complete sense for (most?) structs, maybe less so for classes. </span></div><span class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail- gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>&gt; <span style="font-size:12.8px" class="gmail_msg">2) To your original example, it isn’t immediately clear to me that reduce should choose a default identity.  Some types (e.g. integers and FP) belong to multiple different ring algebras, and therefore have different identity values that correspond to the relevant binary operations.</span><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div></span><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">This is a good point that I&#39;ve considered as well but felt that for the most part, there is one particular identity and associated operation that is more prominent and useful than others. Furthermore, modeling different algebras isn&#39;t mutually exclusive with writing generic algorithms that rely on this protocol, you can always introduce some monoidic wrapper type that defines the more appropriate default value and operation.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Do you mean to argue that for an integer the additive identity should be considered &quot;more prominent and useful&quot; than the multiplicative identity? I&#39;m not aware of any mathematical justification for such a conclusion.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Going to your original example, I should add: other languages provide a version of `reduce` that doesn&#39;t require an initial result (for instance, JavaScript). In JavaScript, `[1, 2, 3].reduce((a, b) =&gt; a + b)` uses the element at array index 0 as the initial result, and the accumulator function is invoked starting with the element at array index 1. This is precisely equivalent to having `reduce` use the additive identity as the default initial result when + is the accumulator function and the multiplicative identity when * is the accumulator function (with the accumulator function being invoked starting with the element at array index 0). It does not require a DefaultConstructible protocol. What more ergonomic solution could be implemented using a monoidic wrapper type?</div><div class="gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376h5 gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-HOEnZb gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-h5 gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Dec 25, 2016 at 1:24 PM, Chris Lattner <span class="gmail_msg">&lt;<a href="mailto:clattner@apple.com" class="gmail_msg" target="_blank">clattner@apple.com</a>&gt;</span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><span class="gmail_msg">On Dec 25, 2016, at 12:54 PM, Adam Nemecek via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</span><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Does enabling a lot of small improvements that make APIs more ergonomic count as practical?</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Yes, that would count as practical, but Xiaodi’s question is just as important.  *Which* APIs become more ergonomic?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Here are a couple of more questions:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1) How does this square with Swift’s general philosophy to not default initialize values to “zero”?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">2) To your original example, it isn’t immediately clear to me that reduce should choose a default identity.  Some types (e.g. integers and FP) belong to multiple different ring algebras, and therefore have different identity values that correspond to the relevant binary operations.</div><span class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Chris</div></font></span><div class="gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596h5 gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Dec 25, 2016 at 12:19 PM, Xiaodi Wu <span class="gmail_msg">&lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><span class="gmail_msg">On Sun, Dec 25, 2016 at 3:07 PM, Adam Nemecek <span class="gmail_msg">&lt;<a href="mailto:adamnemecek@gmail.com" class="gmail_msg" target="_blank">adamnemecek@gmail.com</a>&gt;</span> wrote:<br class="gmail_msg"></span><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg">There&#39;s a book that provides quite a bit of info on this <div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/032163537X?sa-no-redirect=1" class="gmail_msg" target="_blank">https://smile.amazon.com/Elements-Programming-Alexander-Stepanov/dp/032163537X?sa-no-redirect=1</a><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">They say that DefaultConstructible is one of the essential protocols on which most algorithms rely in one way or another. One of the authors is the designer of the C++ STL and basically the father of modern generics.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This protocol is important for any algebraic structure that deals with the concept of appending or addition (as &quot;zero&quot; is one of the requirements of monoid). There isn&#39;t a good short answer to your question. It&#39;s a building block of algorithms. Think about why a RangeReplaceableCollection can provide you with a default constructor but a Collection can&#39;t. </div><div class="gmail_msg"><span style="color:rgb(80,0,80)" class="gmail_msg"></span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">It&#39;s well and fine that most algorithms rely on the concept in one way or another. Yet the Swift standard library already implements many generic algorithms but has no DefaultConstructible, presumably because there are other protocols that guarantee `init()` and the algorithms being implemented don&#39;t need to be (practically speaking) generic over all DefaultConstructible types. My question is: what practical use cases are there for an explicit DefaultConstructible that are impractical today?</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span style="color:rgb(80,0,80)" class="gmail_msg">On Sun, Dec 25, 2016 at 11:37 AM, Xiaodi Wu </span><span style="color:rgb(80,0,80)" class="gmail_msg">&lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span><span style="color:rgb(80,0,80)" class="gmail_msg"> wrote:</span><br class="gmail_msg"></div></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289HOEnZb gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289h5 gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Can you give some other examples of generic algorithms that would make use of this DefaultConstructible? I&#39;m having trouble coming up with any other than reduce.<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951h5 gmail_msg"><div class="gmail_msg">On Sun, Dec 25, 2016 at 14:23 Adam Nemecek via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></div></div></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951h5 gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">This protocol is present in C++ <a href="http://en.cppreference.com/w/cpp/concept/DefaultConstructible" class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg" target="_blank">http://en.cppreference.com/w/cpp/concept/DefaultConstructible</a> as well as in Rust <a href="https://doc.rust-lang.org/std/default/" class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg" target="_blank">https://doc.rust-lang.org/std/default/</a><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">It&#39;s the identity element/unit of a monoid or a zero.<br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">The Swift implementation is very simple (I&#39;m open to different names)<br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">protocol DefaultConstructible {</div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">    init() </div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">}</div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">A lot of the standard types could then be made to conform to this protocol. These include all the numeric types, collection types (array, set, dict), string, basically at least every type that currently has a constructor without any arguments.</div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">The RangeReplaceableCollection protocol would inherit from this protocol as well. <br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">This protocol would simplify a lot of generic algorithms where you need the concept of a zero (which shows up a lot)</div></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg">Once introduced, Sequence could define an alternative implementation of reduce where the initial result doesn&#39;t need to be provided as it can be default constructed.</div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div><div class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"></div></div></div></div></div><br><br>_______________________________________________<br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br><br>swift-evolution mailing list<br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br><br><a href="mailto:swift-evolution@swift.org" class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="m_3012462067322088809m_1176161565890972384gmail-m_2687622816934730376m_-5821329404718624302gmail-m_3993794689939404596m_-267952324834337685m_8912025549324475289m_699475458640075951m_-6015751673947924360gmail_msg gmail_msg"><br><br></blockquote></div><br><br></blockquote></div><br class="gmail_msg"></div><br><br></div></div></blockquote></span></div><br class="gmail_msg"></div></div><br><br></blockquote></div><br class="gmail_msg"></div><br><br>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div></div></div><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div><br><br></div></div></blockquote></div></div></div><br class="gmail_msg"></div></div><br><br></blockquote></div><br class="gmail_msg"></div><br><br></div></div></blockquote></div></div></div><br class="gmail_msg"></div></div><br><br></blockquote></div><br class="gmail_msg"></div><br><br>_______________________________________________<br class="gmail_msg"><br>swift-evolution mailing list<br class="gmail_msg"><br><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br></blockquote></div></div>