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