<div>I can totally agree that it&#39;s not something to deal with Zero concept.</div><div><br></div><div>Though discussion was completely lost for another use case of _generic factories_.</div><div><br></div><div>Also, the interesting part is that discussion brought us to the question if Bool.init(), Int.init() and alike should be removed. I&#39;m 100% positive here as it brings a lot of uncertainty.</div><div><br></div><div>In general, I think if we remove inits described above, DefaultConstructable will be more appealing. I don&#39;t see it as a Zero, but rather as a default factory.</div><div><br></div><div>Best,</div><div>Daniel</div><div><br><div class="gmail_quote"><div>On Tue, 27 Dec 2016 at 3:30 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">Huh? You just said that one usage scenario was the allocation of buffers of known size. If you&#39;re unsatisfied with the API for that, you&#39;re welcome to propose better ones. The point is that this is not a convincing use case, as you claim, for `DefaultConstructible`, but rather for better buffer APIs.</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">I&#39;ve brought up several situation where I&#39;d use these. I don&#39;t want a better buffer API, I want a way of expressing myself in a way that seems natural to me.</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">There is no nexus between comparability and &quot;some sort of origin or zero&quot; from which to measure absolute distance, as you state.</span><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">There is. Elements are equal if the distance between them is zero. Why does Comparability also require Equatability?</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">Ooh boy. There is no worldview in music that &quot;doesn&#39;t say anything about intervals,&quot; I can assure you of that.</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"><a href="https://github.com/midiguchi/midiguchi" class="gmail_msg" target="_blank">https://github.com/midiguchi/midiguchi</a></span><br class="gmail_msg"></div><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">Do you see the zip operation? Could you tell me what it does? Note that I have no relationship to this project. I can find more if I really try. So now there is a precedence, so what&#39;s next? Are you going to tell me that this doesn&#39;t count? Why not?  I was aware of this library even before this discussion btw.</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">No, I mean that you are incorrect.</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">Well if you say so it must be true. Lol. </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">What closure property? My question was, why are you not using `Strideable`? You are describing its semantics. I&#39;m not sure what closure you are referring to.</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">Algebraic closure.</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">&gt; <span style="font-size:12.8px" class="gmail_msg">As I explained earlier, your argument _is_ circular. But it&#39;s clear now you will not accept that being point out to you by multiple people independently.</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">It&#39;s not circular, it&#39;s I use data point to point out that this is a common pattern.</span></div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Dec 26, 2016 at 1:43 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">On Mon, Dec 26, 2016 at 4:28 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"><div class="gmail_extra gmail_msg"><div class="gmail_quote 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"><div class="gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">`ManagedBuffer` is the standard library base class that offers facilities for managing buffers. If there&#39;s a concrete use case that isn&#39;t served, then the argument would be to improve `ManagedBuffer` or to design other types or protocols for that use case, not to add a protocol to conform every type that implements `init()`.</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&#39;d prefer not to deal with raw storage unless necessary. </span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Huh? You just said that one usage scenario was the allocation of buffers of known size. If you&#39;re unsatisfied with the API for that, you&#39;re welcome to propose better ones. The point is that this is not a convincing use case, as you claim, for `DefaultConstructible`, but rather for better buffer APIs.</div><div class="gmail_msg"> </div><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">&gt; <span style="font-size:12.8px" class="gmail_msg">The distance between two values of type T does not itself need to be of type T,</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">Never said otherwise.</span></div><span 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">Moreover, one can have distances being strideable opaque types that can&#39;t even be initialized</span><span style="font-size:12.8px" 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">You sure can. Doesn&#39;t disprove any of my points.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Sure it does. You asserted that where a type is comparable, it &quot;generally&quot; makes sense to measure distance from &quot;some sort of origin or zero.&quot; And I&#39;m showing you why it does not generally make sense at all. There is no nexus between comparability and &quot;some sort of origin or zero&quot; from which to measure absolute distance, as you state.</div><div class="gmail_msg"><br class="gmail_msg"></div><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"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">&gt; </span><span style="font-size:12.8px" class="gmail_msg">This example does not make sense, computationally or musically.</span><span style="font-size:12.8px" 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">You mean that it does not make any sense to you.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">No, I mean that you are incorrect.</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">I have two midi streams (and they are midi) and I want to use one midi note to transpose the other.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There is no such concept in music theory as &quot;using one note to transpose the other.&quot; Sorry.</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">I&#39;m pretty sure that I can find a machine that does this in hardware if I really try. Does the fact that such machine might exist imbue the concept of midi addition with any meaning? </span></div><span 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">You are describing a `Strideable` type. That is already in the stdlib. If you want to use `+` to denote `advanced(by:)`, that&#39;s easy to add by extension. I&#39;m not sure why you decided to reinvent it and call it `Addable`.</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 don&#39;t always need the closure property. </span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What closure property? My question was, why are you not using `Strideable`? You are describing its semantics. I&#39;m not sure what closure you are referring to.</div><div class="gmail_msg"><br class="gmail_msg"></div><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"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">&gt; </span><span style="font-size:12.8px" class="gmail_msg">Doubling the frequency shifts the pitch of a note by an octave; tripling the frequency gets you an octave + a perfect fifth. If you work through the mathematics behind this, you&#39;ll understand the issues behind equal temperament and well temperament.</span></div><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">You are not multiplying pitch by pitch but pitch by number. Pitch + Pitch makes complete sense if you accept the midi worldview which doesn&#39;t say anything about intervals</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Ooh boy. There is no worldview in music that &quot;doesn&#39;t say anything about intervals,&quot; I can assure you of that.</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg">and you realize that the computational distinction between the two is tenuous at best. But this discussion is neither here, nor there. </div></div><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240HOEnZb gmail_msg"><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240h5 gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Dec 26, 2016 at 1:09 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 Mon, Dec 26, 2016 at 1:50 PM, Adam Nemecek via swift-evolution <span class="gmail_msg">&lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</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_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail- gmail_msg">&gt; <span style="font-size:12.8px" class="gmail_msg">Equatable is *very* different.  It has a whole page of semantics. </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">DefaultConstructible comes in handy when you want to write an algorithm that works with a constant sized buffer and you need to initialize the buffer to some default values that will be replaced once you have actual data. Or some objects can initialize themselves from static data (e.g. each object has a sequential id and uses a counter that it increments in init). But in all cases, you want to make sure that the array is statically sized.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">`ManagedBuffer` is the standard library base class that offers facilities for managing buffers. If there&#39;s a concrete use case that isn&#39;t served, then the argument would be to improve `ManagedBuffer` or to design other types or protocols for that use case, not to add a protocol to conform every type that implements `init()`.</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">For me, it also has some implicit meaning of a zero which I agree might be a stretch in general but this is more explicit in cases where types are comparable. Order theory requires a bottom or zero for a reason. Fundamentally, if two elements are comparable, it makes sense to ask what is the distance between them. And the magnitude of these elements is generally measured as a distance from some sort of origin or zero. </span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Careful, total ordering does not require a notion of an origin; not at all. The distance between two values of type T does not itself need to be of type T, and there need be no value of type T that represents any sort of &quot;zero.&quot; Moreover, one can have distances being strideable opaque types that can&#39;t even be initialized (i.e. distances can be of a type U such that two values can have a relative distance between them, but `U.init()` isn&#39;t public).</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"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">&gt; </span><span style="font-size:12.8px" class="gmail_msg">Protocols (a.k.a. concepts) are not just bags of syntax; unless you can</span><br class="gmail_msg"></div><span style="font-size:12.8px" class="gmail_msg">attach semantics to the operations,  </span><span style="font-size:12.8px" class="gmail_msg">you can&#39;t write useful generic </span><span style="font-size:12.8px" class="gmail_msg">algorithms against them.  So we shouldn&#39;t have DefaultConstructible for</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">the same reason we shouldn&#39;t have “Plusable” to represent something that</span><br style="font-size:12.8px" class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">lets you write x + x.</span><br style="font-size:12.8px" class="gmail_msg"><div style="font-size:12.8px" class="gmail_msg"><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-m_-2797573570486692712gmail-m_7134921280786854437gmail-adm gmail_msg"><div id="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-m_-2797573570486692712gmail-m_7134921280786854437gmail-q_15939685645a0044_2" class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-m_-2797573570486692712gmail-m_7134921280786854437gmail-ajR m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-m_-2797573570486692712gmail-m_7134921280786854437gmail-h4 gmail_msg"></div></div></div><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">Haha, I totally have an Addable protocol. Out of curiosity why is it bad? My use case is for example a struct that&#39;s fundamentally a wrapper around some numerical value (int) and not all numerical operations make sense but e.g. addition makes total sense. E.g. a midi note event where addition gives you a transposition but multiplication doesn&#39;t make sense.</span></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">This example does not make sense, computationally or musically. Firstly, transposition is the shifting of pitch by an _interval_; if `Self` is a MIDI note (as you imply below), transposition cannot be by addition of type `Self` but rather of `Self.Stride`. Secondly, you can absolutely multiply a note by an integer factor. Doubling the frequency shifts the pitch of a note by an octave; tripling the frequency gets you an octave + a perfect fifth. If you work through the mathematics behind this, you&#39;ll understand the issues behind equal temperament and well temperament.</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"><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">In this case the default value (zero) is the value that results in no transposition. And if I extend this, what if I have two equally sized arrays of midi events where one represents a transposition and the other represents the notes I&#39;m transposing and I want to combine them to produce the transposed notes, I can write this algorithm as </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><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg">extension Collection where Iterator.Element: Addable {</p><br><br><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg"><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span>        func transpose(_ other: Self) -&gt; [Iterator.Element] {</p><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg"></p><br><br><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg"><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span>            assert(count == other.count)</p><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg"></p><br><br><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg"><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span>            return zip(self, other).map { $0 + $1 }</p><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg"></p><br><br><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg"><span class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-Apple-tab-span gmail_msg"></span>    }</p><br><br><p class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-p1 gmail_msg">}</p></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">I&#39;m not sure if this example is too concrete and specific to my needs but I&#39;ve been trying to use Swift as a language for making these little algebras with a pretty good degree of success but some things like this would be pretty helpful I think. </span></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">You are describing a `Strideable` type. That is already in the stdlib. If you want to use `+` to denote `advanced(by:)`, that&#39;s easy to add by extension. I&#39;m not sure why you decided to reinvent it and call it `Addable`.</div><div class="gmail_msg"><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537h5 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"><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-h5 gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Dec 26, 2016 at 9:29 AM, Dave Abrahams via swift-evolution <span class="gmail_msg">&lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</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"><span class="gmail_msg"><br class="gmail_msg"><br><br>on Mon Dec 26 2016, Jonathan Hull &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br>&gt; Just because something is simple, doesn’t mean it isn’t important.  You can do a lot with ‘return<br class="gmail_msg"><br><br>&gt; T()’ that you can’t do without it (namely make a T).<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br></span>Sure, but the question remains: *should* you make a T in those<br class="gmail_msg"><br><br>circumstances?  Maybe you<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br>With DefaultConstructible, you don&#39;t know anything about the value of<br class="gmail_msg"><br><br>this T.  There is nothing you can do with it, reliably.  If the default<br class="gmail_msg"><br><br>constructability requirement is part of some larger protocol like<br class="gmail_msg"><br><br>RangeReplaceableCollection, then you can say things like, “this makes an<br class="gmail_msg"><br><br>empty collection,” and “a default-constructed instance is equivalent to an<br class="gmail_msg"><br><br>instance on which you&#39;ve called removeAll.”  That doesn&#39;t argue for<br class="gmail_msg"><br><br>factoring the init() out into its own protocol.  It argues for including<br class="gmail_msg"><br><br>the init() requirement in every protocol where it forms an important<br class="gmail_msg"><br><br>part of the protocol&#39;s semantic basis operations.<br class="gmail_msg"><br><br><span class="gmail_msg"><br class="gmail_msg"><br><br>&gt; Equatable is similar.  Semantically, it just lets you ask if two instances of the same type are<br class="gmail_msg"><br><br>&gt; equal.<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br></span>Equatable is *very* different.  It has a whole page of semantics.  Read<br class="gmail_msg"><br><br>from “Equality implies substitutability” to the end of the page at<br class="gmail_msg"><br><br><a href="http://swiftdoc.org/v3.0/protocol/Equatable/" rel="noreferrer" class="gmail_msg" target="_blank">http://swiftdoc.org/v3.0/protocol/Equatable/</a>.<br class="gmail_msg"><br><br><span class="gmail_msg"><br class="gmail_msg"><br><br>&gt; The fact that it only does one thing doesn’t mean it isn’t useful or<br class="gmail_msg"><br><br>&gt; necessary as a small part of a lot of different algorithms.<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt; I find I use T() most often in factory or builder patterns, but any creational pattern may need it.<br class="gmail_msg"><br><br>&gt; It is also often used together with other protocols.  The code is all pretty boring…<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt;       func hasOptionalParam( a: T = T() ) {} //The caller can pass in<br class="gmail_msg"><br><br>&gt; a specific thing, or just leave out the parameter to use a vanilla one<br class="gmail_msg"><br><br>&gt; or<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt;       var t = T()<br class="gmail_msg"><br><br>&gt;       t.somethingFancy() //Provided by unrelated protocol<br class="gmail_msg"><br><br>&gt;       t.moreFancy()<br class="gmail_msg"><br><br>&gt;       return t<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt; or<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt;       var t = T()<br class="gmail_msg"><br><br>&gt;       if t is SomeOtherProtocol {<br class="gmail_msg"><br><br>&gt;               //Do something fancy<br class="gmail_msg"><br><br>&gt;       }<br class="gmail_msg"><br><br>&gt;       if t is YetAnotherProtocol {<br class="gmail_msg"><br><br>&gt;               //Do something else fancy<br class="gmail_msg"><br><br>&gt;       }<br class="gmail_msg"><br><br>&gt;       return t<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt; All of the “fancy stuff” will be done by conforming to other protocols, but those protocols may have<br class="gmail_msg"><br><br>&gt; nothing to do with creation (nor should they).  There is nothing wrong with requiring conformance to<br class="gmail_msg"><br><br>&gt; multiple protocols...<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br></span>No, there isn&#39;t.  There *is* something wrong with slicing meaningful<br class="gmail_msg"><br><br>protocols up into bits that have only syntactic value, though.  I<br class="gmail_msg"><br><br>suspect that&#39;s what&#39;s going on here.<br class="gmail_msg"><br><br><span class="gmail_msg"><br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt; Thanks,<br class="gmail_msg"><br><br>&gt; Jon<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt;&gt; On Dec 26, 2016, at 7:10 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt; The question still remains unanswered, what generic algorithms are<br class="gmail_msg"><br><br>&gt;&gt; enabled by having such a protocol? After a long chain, the answer so<br class="gmail_msg"><br><br>&gt;&gt; far is `return T()`. Indeed, afaict, the semantics you are proposing<br class="gmail_msg"><br><br>&gt;&gt; would explicitly limit us to that.<br class="gmail_msg"><br><br>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt; On Mon, Dec 26, 2016 at 09:32 Jonathan Hull<br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt; &lt;<a href="mailto:jhull@gbis.com" class="gmail_msg" target="_blank">jhull@gbis.com</a> &lt;mailto:<a href="mailto:jhull@gbis.com" class="gmail_msg" target="_blank">jhull@gbis.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt; My two cents:<br class="gmail_msg"><br><br>&gt;&gt; 1) T() should NOT have anything to do with zero or even<br class="gmail_msg"><br><br>&gt;&gt; “default&quot;. (If we need semantic zero, create a protocol with a .zero<br class="gmail_msg"><br><br>&gt;&gt; static func/var)<br class="gmail_msg"><br><br>&gt;&gt; 2) This comes up enough in my programming, and is such a fundamental<br class="gmail_msg"><br><br>&gt;&gt; concept, that T() probably DOES deserve special treatment in the<br class="gmail_msg"><br><br>&gt;&gt; form of a protocol<br class="gmail_msg"><br><br>&gt;&gt; 3) The semantics of that protocol would be “Things which can be<br class="gmail_msg"><br><br>&gt;&gt; created without any additional information beyond their Type”<br class="gmail_msg"><br><br>&gt;&gt; 4) We should keep working on the name<br class="gmail_msg"><br><br>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt; As to whether the protocol needs to be implicit… I am unsure.  It<br class="gmail_msg"><br><br>&gt;&gt; may be enough to have the standard library + cocoa types conform<br class="gmail_msg"><br><br>&gt;&gt; where appropriate.  On the other hand, I can’t think of any type<br class="gmail_msg"><br><br>&gt;&gt; having T() which would not fit the above semantics… and I would<br class="gmail_msg"><br><br>&gt;&gt; guess around 85~90% of types have it, so it may be worth the trouble<br class="gmail_msg"><br><br>&gt;&gt; to make it implicit in this specific case.  I am on the fence, but<br class="gmail_msg"><br><br>&gt;&gt; would probably lean against making it implicit.<br class="gmail_msg"><br><br>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt; Thanks,<br class="gmail_msg"><br><br>&gt;&gt; Jon<br class="gmail_msg"><br><br>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Dec 25, 2016, at 11:28 PM, Daniel Leping via swift-evolution<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;&gt;<br class="gmail_msg"><br><br><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; It&#39;s not a matter of probability, but rather of certainty. Please.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, 26 Dec 2016 at 12:56 Xiaodi Wu<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt;&gt; &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, Dec 26, 2016 at 2:19 AM, Daniel Leping<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a>&gt;&gt;<br class="gmail_msg"><br><br><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; I totally agree Swift is an opinionated language and it&#39;s good.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Also I have been thinking of DefaultConstructable vs reflection for<br class="gmail_msg"><br><br>&gt;&gt;&gt; generic factories and I would prefer to stick to the protocol as it<br class="gmail_msg"><br><br>&gt;&gt;&gt; gives compile time type safety check. With reflection the only way<br class="gmail_msg"><br><br>&gt;&gt;&gt; is to through an exception if there is no init. So again +1 pro to<br class="gmail_msg"><br><br>&gt;&gt;&gt; DefaultConstructable.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Well, you can&#39;t argue both ways. Either so many types implement<br class="gmail_msg"><br><br>&gt;&gt;&gt; `init()` that it is unusually onerous to type, in which case you<br class="gmail_msg"><br><br>&gt;&gt;&gt; will gain nearly nothing from compile-time checks, or not so many<br class="gmail_msg"><br><br>&gt;&gt;&gt; types implement `init()`, and you can conform those types to a<br class="gmail_msg"><br><br>&gt;&gt;&gt; protocol by yourself :)<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, 26 Dec 2016 at 12:32 Xiaodi Wu<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt;&gt; &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, Dec 26, 2016 at 1:48 AM, Daniel Leping<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a>&gt;&gt;<br class="gmail_msg"><br><br><div class="gmail_msg"><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-m_-2797573570486692712h5 gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; Well, AnyObject exists on Linux with no bridging. Still it&#39;s IMPLICITELY conformed by all classes.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; What you say is just another approach to the same issue and we can<br class="gmail_msg"><br><br>&gt;&gt;&gt; argue for eternity. However, I am very positive with syntactic<br class="gmail_msg"><br><br>&gt;&gt;&gt; sugar and this one falls exactly to sugar category. Make people<br class="gmail_msg"><br><br>&gt;&gt;&gt; lifes easier ;)<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Moreover it will never ever do any harm.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Adding an easy way to get another set of frameworks/approaches/etc<br class="gmail_msg"><br><br>&gt;&gt;&gt; (proven by time, btw) on board sounds very appealing to me. I wish<br class="gmail_msg"><br><br>&gt;&gt;&gt; to see Swift a very diverse ecosystem and this Pitch serves exactly<br class="gmail_msg"><br><br>&gt;&gt;&gt; this goal.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Yes, we should let others chime in on this issue. I will just end<br class="gmail_msg"><br><br>&gt;&gt;&gt; by saying that I&#39;ve always appreciated how the core team has been<br class="gmail_msg"><br><br>&gt;&gt;&gt; very careful and thoughtful about certain precepts, and how they&#39;ve<br class="gmail_msg"><br><br>&gt;&gt;&gt; stuck to the idea that Swift is an _opinionated_ language.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; In particular, I appreciate that there&#39;s a huge amount of thought<br class="gmail_msg"><br><br>&gt;&gt;&gt; put into semantic meaning. The notion that protocols should carry<br class="gmail_msg"><br><br>&gt;&gt;&gt; semantics has been adhered to very strictly. This is why I think<br class="gmail_msg"><br><br>&gt;&gt;&gt; this proposal does do harm, because it explicitly rejects that very<br class="gmail_msg"><br><br>&gt;&gt;&gt; important idea, one that can only be upheld by people and not<br class="gmail_msg"><br><br>&gt;&gt;&gt; compilers.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; (Another semantic distinction observed in Swift is that a boolean<br class="gmail_msg"><br><br>&gt;&gt;&gt; value has semantic meaning and is not just a bit; this is why, for<br class="gmail_msg"><br><br>&gt;&gt;&gt; instance, the FloatingPoint protocols define an `enum<br class="gmail_msg"><br><br>&gt;&gt;&gt; FloatingPointSign { case plus, minus }`--because floating point<br class="gmail_msg"><br><br>&gt;&gt;&gt; sign has different _semantics_ from a Bool.)<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Let&#39;s just see if it gets any more positive votes.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, 26 Dec 2016 at 12:10 Xiaodi Wu<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg"><br><br></div></div><span class="gmail_msg">&gt;&gt;&gt; &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, Dec 26, 2016 at 1:21 AM, Daniel Leping<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a>&gt;&gt;<br class="gmail_msg"><br><br><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; I believe you&#39;re confusing in-class factory methods with factory pattern.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Factories can be separate objects and it&#39;s a very different situation.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Fair, but I understand both to fall under the umbrella of &quot;any<br class="gmail_msg"><br><br>&gt;&gt;&gt; factory pattern&quot; and just wanted to point out that at least some of<br class="gmail_msg"><br><br>&gt;&gt;&gt; those patterns seem to be discouraged :)<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; In any case, I think it&#39;s fair to say that the question &quot;does this<br class="gmail_msg"><br><br>&gt;&gt;&gt; type implement `init()`?&quot; is properly a reflection question and not<br class="gmail_msg"><br><br>&gt;&gt;&gt; a protocol conformance question: the answer provides no semantic<br class="gmail_msg"><br><br>&gt;&gt;&gt; guarantees whatsoever about the value that you get from `init()`,<br class="gmail_msg"><br><br>&gt;&gt;&gt; and in your use case you do not care and simply want to invoke the<br class="gmail_msg"><br><br>&gt;&gt;&gt; initializer and return what you get from it. Now, in a perfect<br class="gmail_msg"><br><br>&gt;&gt;&gt; world where the reflection facilities that Swift provided were<br class="gmail_msg"><br><br>&gt;&gt;&gt; essentially free of performance cost, would you object to that<br class="gmail_msg"><br><br>&gt;&gt;&gt; characterization?<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; You&#39;re certainly right that `AnyObject` has magic. It&#39;s rather<br class="gmail_msg"><br><br>&gt;&gt;&gt; obvious that Obj-C bridging is non-negotiable for Swift, and of<br class="gmail_msg"><br><br>&gt;&gt;&gt; course a bridged type is all sorts of different under the hood from<br class="gmail_msg"><br><br>&gt;&gt;&gt; a native type. I&#39;m going to take a wild guess that no other use<br class="gmail_msg"><br><br>&gt;&gt;&gt; case would pass that high bar for magic.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, 26 Dec 2016 at 11:46 Xiaodi Wu<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt;&gt; &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, Dec 26, 2016 at 1:10 AM, Daniel Leping<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a>&gt;&gt;<br class="gmail_msg"><br><br><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; I&#39;m giving a wider range, which is about ANY factory pattern<br class="gmail_msg"><br><br>&gt;&gt;&gt; related stuff. Doesn&#39;t look to be narrow to me.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; I thought factory methods were regarded as undesirable in Swift?<br class="gmail_msg"><br><br>&gt;&gt;&gt; One of the stated reasons for failable initializers was: &quot;Failable<br class="gmail_msg"><br><br>&gt;&gt;&gt; initializers eliminate the most common reason for factory methods<br class="gmail_msg"><br><br>&gt;&gt;&gt; in Swift... Using the failable initializer allows greater use of<br class="gmail_msg"><br><br>&gt;&gt;&gt; Swift’s uniform construction syntax, which simplifies the language<br class="gmail_msg"><br><br>&gt;&gt;&gt; by eliminating the confusion and duplication between initializers<br class="gmail_msg"><br><br>&gt;&gt;&gt; and factory methods.&quot;<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="https://developer.apple.com/swift/blog/?id=17" rel="noreferrer" class="gmail_msg" target="_blank">https://developer.apple.com/swift/blog/?id=17</a><br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="https://developer.apple.com/swift/blog/?id=17" rel="noreferrer" class="gmail_msg" target="_blank">https://developer.apple.com/swift/blog/?id=17</a>&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, 26 Dec 2016 at 11:38 Xiaodi Wu<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt;&gt; &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, Dec 26, 2016 at 12:58 AM, Daniel Leping<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a>&gt;&gt;<br class="gmail_msg"><br><br><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; Well, reflection is a huge performance drop. Protocol conformance is way better.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; I&#39;m not sure how huge it would be in the grand scheme of things; in<br class="gmail_msg"><br><br>&gt;&gt;&gt; your example, you are still evaluating a train of protocol<br class="gmail_msg"><br><br>&gt;&gt;&gt; conformances and casting at runtime. Of course, compiler magic can<br class="gmail_msg"><br><br>&gt;&gt;&gt; be fast, but I still don&#39;t see how this is a &quot;very common use case&quot;<br class="gmail_msg"><br><br>&gt;&gt;&gt; (as you write) that would justify magic equivalent to that for<br class="gmail_msg"><br><br>&gt;&gt;&gt; Objective-C bridging, which is what you&#39;re saying it should be. If<br class="gmail_msg"><br><br>&gt;&gt;&gt; `DefaultConstructible` is useful only when it&#39;s magic and the<br class="gmail_msg"><br><br>&gt;&gt;&gt; specific use case is dependency injection/inversion of control,<br class="gmail_msg"><br><br>&gt;&gt;&gt; then we&#39;re getting very specialized here.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, 26 Dec 2016 at 11:26 Xiaodi Wu<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt;&gt; &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, Dec 26, 2016 at 12:50 AM, Daniel Leping<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:daniel@crossroadlabs.xyz" class="gmail_msg" target="_blank">daniel@crossroadlabs.xyz</a>&gt;&gt;<br class="gmail_msg"><br><br><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; I&#39;m not arguing for implicit conformance in general, but I&#39;m<br class="gmail_msg"><br><br>&gt;&gt;&gt; telling that DefaultConstructable is the same basic level as<br class="gmail_msg"><br><br>&gt;&gt;&gt; AnyObject, which is conformed implicitly.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Shortly, I&#39;m against implicit conformance in general. I&#39;m positive<br class="gmail_msg"><br><br>&gt;&gt;&gt; with &quot;automatic compiler magic&quot; conformance to DefaultConstructable<br class="gmail_msg"><br><br>&gt;&gt;&gt; for any object having a default constructor as it really is a very<br class="gmail_msg"><br><br>&gt;&gt;&gt; basic stuff. Otherwise you will have to add explicit conformance to<br class="gmail_msg"><br><br>&gt;&gt;&gt; it in almost every class of yours (annoying).<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Well, this sounds very different from Adam&#39;s proposal, where he<br class="gmail_msg"><br><br>&gt;&gt;&gt; proposes semantic meaning for `init()` that, as he described, means<br class="gmail_msg"><br><br>&gt;&gt;&gt; that it cannot apply to every type that implements<br class="gmail_msg"><br><br>&gt;&gt;&gt; `init()`. However, he also just said that he thinks that all types<br class="gmail_msg"><br><br>&gt;&gt;&gt; with `init()` should conform, so I guess I&#39;m confused which way<br class="gmail_msg"><br><br>&gt;&gt;&gt; that is.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; At base, you want a way of knowing if a type has `init()`. That<br class="gmail_msg"><br><br>&gt;&gt;&gt; sounds like reflection to me, not protocol conformance. For the<br class="gmail_msg"><br><br>&gt;&gt;&gt; record, I look forward to the day when AnyObject magic is removed;<br class="gmail_msg"><br><br>&gt;&gt;&gt; I assume it is coming eventually.<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, 26 Dec 2016 at 11:14 Xiaodi Wu<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt;&gt; &lt;mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; On Mon, Dec 26, 2016 at 12:43 AM, Daniel Leping via swift-evolution<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;&gt;<br class="gmail_msg"><br><br><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;&gt;&gt; Thank you, Adam!<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br>&gt;&gt;&gt; Wait, are you arguing for implicit conformance or not?<br class="gmail_msg"><br><br>&gt;&gt;&gt;<br class="gmail_msg"><br><br></span><span class="gmail_msg">&gt;&gt;&gt; On Mon, 26 Dec 2016 at 11:12 Adam Nemecek via swift-evolution<br class="gmail_msg"><br><br>&gt;&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><br></span>&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;&gt;<br class="gmail_msg"><br><br><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-m_-2797573570486692712HOEnZb gmail_msg"><div class="m_-7430498941410128175m_-4507405587073185514m_4937724216879982240m_-1279035214527698537m_1036267489738941891gmail-m_4919129153461230770gmail-m_-2797573570486692712h5 gmail_msg"><span class="gmail_msg">&gt;&gt;&gt; wrote:<br class="gmail_msg"><br><br>&gt;<br class="gmail_msg"><br><br>&gt; _______________________________________________<br class="gmail_msg"><br><br>&gt; swift-evolution mailing list<br class="gmail_msg"><br><br>&gt; <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><br>&gt; <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><br>&gt;<br class="gmail_msg"><br><br><br class="gmail_msg"></span><span class="m_-7430498941410128175m_-4507405587073185514HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><br><br>--<br class="gmail_msg"><br><br>-Dave</font></span><span class="gmail_msg"><br class="gmail_msg"><br><br><br class="gmail_msg"><br><br>_______________________________________________<br class="gmail_msg"><br><br>swift-evolution mailing list<br class="gmail_msg"><br><br><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><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><br></span></div></div></blockquote></div><br class="gmail_msg"></div></div></div></div><span class="gmail_msg"><br><br><br class="gmail_msg">_______________________________________________<br class="gmail_msg"><br><br>swift-evolution mailing list<br class="gmail_msg"><br><br><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><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><br><br class="gmail_msg"></span></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><br class="gmail_msg"></div></div><br><br></blockquote></div><br class="gmail_msg"></div></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>