<div dir="ltr">On Mon, Dec 26, 2016 at 12:15 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"><span style="font-size:12.8px" class="gmail_msg">> The all-zero bit pattern represents the integer zero—that's not the same as whether it represents the best "default" value for an integer as a higher-level concept, or whether such a default should exist in the first place.</span><br class="gmail_msg"><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">It represents a sensible value to initialize an int to when I want to initialize an array of ints to a certain size. There is a reason why you zero out memory but you don't "one out" memory. </span></div></div></blockquote><div><br></div><div>It was previously mentioned in this thread, but Swift explicitly made the choice to *not* initialize values to zero by default. If you want to initialize an array of ints, you can just as easily pass the default in that you want. If you want to do this more generically, you can still push the responsibility to the caller, which is arguably better because it doesn't restrict your algorithm to only those data types that conform to a particular protocol.</div><div><br></div><div>The fact that certain bit-patterns correspond to zero and that zero has been a default in other languages is an artifact of their hardware representation, but not necessarily one that should motivate higher level design.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg" style="font-size:12.8px">> </span><span class="gmail_msg" style="font-size:12.8px">That doesn't explain why the additive identity is more special than the multiplicative one. It just argues that it's more convenient for a particular use case.</span><br></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">Because the identity associated with the default initializer as is is the additive identity which means the default operation is addition. </div></div></blockquote><div><br></div><div>I should have phrased more carefully: it doesn't explain why the additive identity *should be* more special.</div><div><br></div><div>There is no "default operation" over integers. The fact that the additive identity also happens to be the all zero bit-pattern which also happens to be the default initialized state isn't an argument for why it *should* be that way—it's just explaining what the current state of things is. It's a circular argument to use that as a reason for why default constructibility should exist as a consequence of that.</div><div><br></div><div>> <span style="font-size:12.800000190734863px">Because encapsulation. There's a reason NSObject has a default initializer.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">That's not an encapsulation that works everywhere. Consider this: there exist types that might have reasonable "default" values but for which the default initializer isn't an appropriate or possible way to express it. (One example: an ORM where objects have to be associated with an originating "context"; either the type needs to have an initializer that takes a context, or the context is a factory that returns instances.) By writing an algorithm that relies on DefaultConstructible, you prohibit those types from being used there. If the algorithm pushes the responsibility to the caller, as Array(repeating:count:) does, then it can work for both types. It's *more* general and more powerful than the DefaultConstructible version.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">The reason NSObject has a default initializer is because every object inherits from it and it must have a sensible default initializer to end the call chain, and there's nothing meaningful that needs to be parameterized for NSObject. If you call [[NSObject alloc] init] by itself, you get back an object that doesn't really do much. But I'm not sure what that has to do with generic algorithms—what about all the types that extend NSObject that don't have default initializers?</span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><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 11:57 AM, 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"><span class="gmail_msg">On Mon, Dec 26, 2016 at 11:43 AM 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"></span><div class="gmail_quote gmail_msg"><span 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="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">> </span><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">For integers, 0 is an additive identity. Is there a reason it should be given special treatment over 1, the multiplicative identity?</span><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"> </span></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></span></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">E.g. for statistical reasons. When I have a collection of users with age etc it makes sense to ask what is the combined age of the collection? What is the semantic meaning of multiplying their ages? </span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">That doesn't explain why the additive identity is more special than the multiplicative one. It just argues that it's more convenient for a particular use case.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I would turn your example around—if you're interested enough in thorough type design that you feel that a DefaultConstructible protocol would be useful here, then I offer that a better and safer design would be to create an "Age" value type (or, more generally, measurement types with concepts of units) if you want compile-time safety and limiting the supported operations to only those that are sensical. "Int" is arguably too wide a type to represent an age in a public API because it would allow two ages to be multiplied together, as you said.</div><span class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><span style="font-size:12.8px" class="gmail_msg">> Mathematically, identities are associated with (type, operation) pairs, not types alone.</span><br class="gmail_msg"></div></span><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></span></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><span style="font-size:12.8px" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">Correct, however we aren't talking about mathematics, we are talking about the implementation of a language that runs on very concrete architectures where very concrete bit patterns mean very concrete things that are unlikely to change any time soon.</span></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">The all-zero bit pattern represents the integer zero—that's not the same as whether it represents the best "default" value for an integer as a higher-level concept, or whether such a default should exist in the first place.</div><span class="gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="gmail_quote m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">On Mon, Dec 26, 2016 at 11:35 AM, Tony Allevato <span dir="ltr" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><<a href="mailto:allevato@google.com" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">allevato@google.com</a>></span> wrote:<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><blockquote class="gmail_quote m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For integers, 0 is an additive identity. Is there a reason it should be given special treatment over 1, the multiplicative identity? Historically the only reason is because it has the all-clear bit pattern.<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">Mathematically, identities are associated with (type, operation) pairs, not types alone.<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">This conversation has put me in the column of "numeric types shouldn't have default initializers at all", personally.<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="gmail_quote m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840h5 m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div dir="ltr" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">On Mon, Dec 26, 2016 at 11:27 AM Adam Nemecek via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div></div></div><blockquote class="gmail_quote m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840h5 m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div dir="ltr" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">The elements already have an Identity, the one that you get when you invoke the default constructor. It's 0 for Int, "" for String. </div><div class="gmail_extra m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="gmail_quote m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">On Mon, Dec 26, 2016 at 11:24 AM, David Sweeris <span dir="ltr" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><<a href="mailto:davesweeris@mac.com" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">davesweeris@mac.com</a>></span> wrote:<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><blockquote class="gmail_quote m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663m_7699876098764341631h5 m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">On Dec 26, 2016, at 11:12, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div><blockquote type="cite" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">There is an older discussion that is somewhat linked to this topic:<div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">"Removing the empty initialiser requirement from RangeReplaceableCollection"<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023642.html" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023642.html</a></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">Imho "DefaultConstructible" types can be very handy, but so far, it seems no one has presented a single use case that is important enough to justify the inclusion in the stdlib.</div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">On the other hand, I'm quite sure that there's much functionality in the stdlib that many people consider as superfluous…</div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">I guess adding the protocol wouldn't have a big impact on size, so for for me, the question is "Does this protocol confuse users of Swift?", which I'd answer with "yes, possibly" (unless someone comes up with a name that is more intuitive).</div></div></blockquote><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">"Identity", but, at least for many numeric types, you'd need a mechanism for specifying which one you mean.</div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div><div class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">- Dave Sweeris</div></div></blockquote></div><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div></div></div><span class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
_______________________________________________<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
swift-evolution mailing list<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777m_2296093129005653840m_-5389545831853979663gmail_msg m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
</span></blockquote></div>
</blockquote></div><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg"></div>
_______________________________________________<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
swift-evolution mailing list<br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="m_-423595227469622890m_-3715892300944431720m_2612789894267735777gmail_msg gmail_msg">
</blockquote></span></div></div>
</blockquote></div><br class="gmail_msg"></div></div></blockquote></div></div>