<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 18, 2016, at 4:01 PM, Nicola Salmoria <<a href="mailto:nicola.salmoria@gmail.com" class="">nicola.salmoria@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, May 18, 2016 at 10:36 PM, Matthew Johnson<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><div class=""><div class="h5"><blockquote type="cite" class=""><div class="">On May 18, 2016, at 3:14 PM, Nicola Salmoria <<a href="mailto:nicola.salmoria@gmail.com" target="_blank" class="">nicola.salmoria@gmail.com</a>> wrote:</div><br class=""><div class=""><br class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">On Wed, May 18, 2016 at 10:03 PM, Matthew Johnson<span class=""> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On May 18, 2016, at 3:00 PM, Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, May 18, 2016 at 8:03 PM, Tony Allevato<span class=""> </span><span dir="ltr" class=""><<a href="mailto:allevato@google.com" target="_blank" class="">allevato@google.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" 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=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, May 18, 2016 at 10:02 AM Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" 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;">> * What is your evaluation of the proposal?<br class=""><br class="">I'm generally in strong support, having long been a proponent of removing<br class="">operators from protocols (the first occurrence was in this thread:<br class=""><a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/7935" rel="noreferrer" target="_blank" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/7935</a>)<br class=""><br class="">I have several comments about the details of the proposal, however.<br class=""><br class="">1) At the beginning, in the "Proposed solution" section, the proposal says<br class="">"This document does not propose that the current way of defining operators<br class="">be removed or changed at this time. Rather, we describe an addition that<br class="">specifically provides improvements for protocol operator requirements."<br class=""><br class="">Later, however, there is a "Deprecation of non-static protocol operators"<br class="">section which suggest to do exactly that, and this is reiterated in the<br class="">"Impact on existing code" section.<br class=""><br class="">Since I think that the deprecation of global operator overloads is the<br class="">crucial point of the proposal, I assume that the former is an oversight.<br class=""></blockquote><div class=""><br class=""></div></div><div dir="ltr" class=""><div class="gmail_quote"><div class="">I could probably do a better job of clarifying the wording here. The proposal does *not* deprecate *all* global operator overloads. Global operators can still be implemented as they have been in Swift. So if you have a concrete type like `struct Matrix`, you can still define at the global level `func +(lhs: Matrix, rhs: Matrix) -> Matrix`.</div><div class=""><br class=""></div><div class="">What's being deprecated is the current syntax used to define operator requirements inside protocols (by making the functions static) and the manner by which subtypes conform (ditto, through static methods instead of global functions).</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">OK, I guess the unclear part is when you talk about "an addition that specifically provides improvements for protocol operator requirements." This is not just an addition; it's intended to completely replace the protocol operator syntax.<br class=""></div><blockquote class="gmail_quote" 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=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" 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;"><br class="">2) The method signatures in the examples are not up to date with the current<br class="">Swift 3 syntax. For example:<br class=""><br class="">protocol Equatable {<br class=""> <span class=""> </span>static func ==(lhs: Self, rhs: Self) -> Bool<br class="">}<br class=""><br class="">should be:<br class=""><br class="">protocol Equatable {<br class=""> <span class=""> </span>static func ==(_ lhs: Self, _ rhs: Self) -> Bool<br class="">}<br class=""></blockquote><div class=""><br class=""></div><div class="">Unless I'm mistaken, from looking at the Swift 3 branch of stdlib, the syntax changes don't appear to apply to operator functions. Since they are a special case that don't have argument labels, it wouldn't make sense to require them (or rather, the placeholders) here.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't agree with this.<br class=""><br class=""></div><div class="">Operators are called like this:<br class=""><br class=""></div><div class="">x = y + z<br class=""><br class=""></div><div class="">Of course it doesn't make sense to have parameter labels there.<br class=""></div><div class=""><br class=""></div><div class="">But the ones inside the protocol are not operators. They are methods, and are called like methods. They happen to have funny names, but they are still methods, and are called like this:<br class=""><br class=""></div><div class="">x = T.+(y, z)<br class=""><br class=""></div><div class="">In this case not only it makes sense for the parameters to have labels, but making them behave differently from normal methods would be inconsistent, and a step backwards from all the progress that has been made in Swift 3 on that front.<br class=""> <br class=""></div><blockquote class="gmail_quote" 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=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" 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;"><br class="">3) As has already been noted by many others, the suggested syntax for<br class="">prefix/postfix operators is overcomplicated. The proposal is:<br class=""><br class="">// These are deprecated, of course, but used here just to serve as an<br class="">// example.<br class="">static prefix func ++(_ value: inout Self) -> Self<br class="">static postfix func ++(_ value: inout Self) -> Self<br class=""><br class="">We don't need that. Since the 'operators' declared inside protocols are<br class="">effectively just normal methods (apart from their names), we just need to<br class="">name the parameters accordingly:<br class=""><br class="">static func ++(prefix value: inout Self) -> Self<br class="">static func ++(postfix value: inout Self) -> Self<br class=""><br class="">4) I don't agree with the request to limit to static methods for the<br class="">operator implementations.<br class="">I support this for symmetrical binary operators like +, but there are other<br class="">operators like += that seem to work better with members. That is, the<br class="">proposed declaration:<br class=""><br class="">static func +=(_ lhs: inout Self, _ rhs: Self)<br class=""><br class="">is more similar to the global += operator definition, but is less clear than:<br class=""><br class="">mutating func +=(_ rhs: Self)<br class=""><br class="">this is apparent also at the call site. With the proposed syntax, one would<br class="">need to do:<br class=""><br class="">func +=<T: Foo>(_ lhs: inout T, _ rhs: T) {<br class=""> <span class=""> </span>T.+=(lhs, rhs)<br class="">}<br class=""><br class="">while with a member function this would read more naturally as:<br class=""><br class="">func +=<T: Foo>(_ lhs: inout T, _ rhs: T) {<br class=""> <span class=""> </span>lhs.+=(rhs)<br class="">}<br class=""></blockquote><div class=""><br class=""></div><div class="">I considered this, but eventually settled on "everything is static" for consistency. As you mention, there's a stronger argument to be made for assignment operators to have "left hand side is the receiver" semantics than there are for standard infix operators, but from a consistency point of view (and ease of learning), I think having everything static and the signatures of the static operators matching those of the global operators is preferable.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I think this would better be left as a choice to the author of the protocol. There doesn't seem to be any technical reason to place this restriction.<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">The problem with this is that people will make different choices. This may result in boilerplate where a type has to provide both static *and* instance methods to conform to different protocols. Better to avoid that possibility.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Do you have a specific example in mind?<br class=""></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">No, it’s not possible today so there is no existing code to reference. However, if you give people a choice some people will inevitably make a different choice than other people.</div></div></div></blockquote><div class=""><br class=""></div><div class="">You mentioned needing to add boilerplate to make a type conform to different protocols. In which scenario could that happen?<br class=""></div></div></div></blockquote><div><br class=""></div><div>Not to make it conform. To actually use the operator on your type.</div><div><br class=""></div><div>Imagine this:</div><div><br class=""></div><div>protocol P { <br class=""> static func ++++(lhs: Self, rhs: Self) -> Self<div class="">}</div><div class=""><br class=""></div><div class="">protocol Q { <br class=""> func ++++(rhs: Self) -> Self<br class="">}</div><div class=""><br class=""></div><div class="">struct S: P, Q {</div><div class=""> static func ++++(lhs: Self, rhs: Self) -> Self {</div><div class=""> // ...</div><div class=""> }</div><div class=""> func ++++(rhs: Self) -> Self {</div><div class=""> // ...</div><div class=""> }</div><div class="">}</div></div><div><br class=""></div><div>I’m required to implement the same operator twice if I want to conform to both protocols. Allowing this possibility would be a flaw in the language IMO.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Once you take out the standard operators which will be taken care of by the stdlib, I can't readily think of an example of an operator which could be defined by two different protocols.<br class=""></div></div></blockquote><div><br class=""></div><div>I can’t readily think of an example either, but I would prefer to rule out the possibility of the same operator being declared by two protocols in two different ways.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Also, this isn't a problem specific to operators; the same kind of incompatibility can happen with normal methods. We lease freedom with normal methods, so why should operators be more limited?<br class=""></div></div></blockquote><div><br class=""></div><div>This isn’t a problem with normal methods because they don’t typically use top-level trampolines as part of their implementation.</div><div><br class=""></div><div>An alternative would be allowing the operator declaration itself to specify whether it should be implemented as a static or instance operator.</div><div><br class=""></div><div>My primary concern is that there should only be one way to specify a protocol requirement for an individual operator. </div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class=""><br class="">I expect the stdlib to illustrate what idiomatic Swift is expected to be, and people to follow suit for the standard operators.<br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That is exactly what this proposal is attempting to do, and in a way that the language enforces the decision. </div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">What benefit do you perceive in allowing operator instance methods?</div></div></div></blockquote><div class=""><br class=""></div><div class="">The fact that operators like += are more naturally implemented as an instance method than as a static method is already a clear benefit to me.<br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Are you specifically thinking of assignment operators? If so, I wouldn’t have a problem if the proposal specified assignment operators as instance methods and all other operators as static methods. As long as there is only one way to define a specific operator requirement I will be happy.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class=""><br class=""></div><div class="">But in general, there aren't only the standard operators; people will define custom operators and will have different needs depending on their semantics. If there isn't a technical limitation, I don't see a reason to add arbitrary restrictions.<br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">There is no difference in capability here so I’m not sure what you mean by having different “needs”.</div></div></div></blockquote><div class=""><br class=""></div><div class="">By needs I mean choosing the representation that better fits the semantics of the operator.<br class=""></div><div class="">For symmetrical binary operators, a static method is probably the best choice, but for other kinds of operators it might not be.</div></div></div></blockquote><div><br class=""></div><div>Sure. But if you want to go in that direction maybe it’s worthwhile to try and define general classes of operators for which each syntax fits better and require that syntax to be used. I can see a case for doing this, but a lot of people will argue against it on grounds that it is inconsistent.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""> <br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="h5"><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" 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=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">(Which is also why, as I mentioned in a previous reply, I would be open to dropping the prefix/postfix keyword and making it an argument label instead, in both contexts.)</div><div class=""> </div><blockquote class="gmail_quote" 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;"><br class="">5) the proposal mentions the open question of ambiguities between the dot<br class="">syntax to access methods and operators whose name starts with a dot.<br class="">This seems to be a real issue: I don't think<br class=""><br class="">return T....(minimum, maximum)<br class=""><br class="">looks any good, even if the compiler was able to parse it.<br class=""><br class="">However, this just means that the methods used to implement operators with<br class="">problematic names would need to use different names. Arguably, the only<br class="">cases where one would really want to use methods with operator names is for<br class="">arithmetical operators. Custom operators like ... are better expressed as<br class="">methods with more significant names.<br class=""></blockquote><div class=""><br class=""></div><div class="">If there is a strong case where an operator is better implemented as a global operator and a named method, this proposal still allows that, since it's not deprecating all global operator definitions. A protocol could certainly have a requirement that is a named method, and provide a global generic operator that calls it.</div><div class=""><span style="line-height: 1.5;" class=""> </span><br class=""></div><blockquote class="gmail_quote" 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;"><br class="">6) It seems somewhat arbitrary to restrict method names to match an<br class="">operator, nor to put requirements on the function signature. I'd say there<br class="">are two cases, either the compiler can handle a method name that uses<br class="">special characters, or it can't. If it can't, matching an operator name<br class="">won't help. If it can, why put limits? There could be other creative uses of<br class="">such names, which we would be ruling out for no particular reason. This is<br class="">something that seems better left to the author of the protocol.<br class=""></blockquote><div class=""><br class=""></div><div class="">IMO, to reduce potential confusion, I would argue that a function whose name is the same as a defined operator should conform to the requirements (such as argument count) of that operator. It's certainly worth discussion, though! With that being said, it may be easier on users to "rule something out" now and open it up later if need be, rather than to leave it open for people to use and decide it needs to be closed later.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This doesn't seem different to me from having multiple functions with the same name and different signature, which Swift allows without problems. Again, I think this is a choice that the author of the protocol should make, and there doesn't seem to be any technical reason to require otherwise.<br class=""></div><div class=""> </div><blockquote class="gmail_quote" 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=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" 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;"><br class="">7) Automatic generation of trampoline functions is out of scope so I'm not<br class="">going to talk much about it, I only want to mention that it would make sense<br class="">to consider making such a feature as general as possible, instead of<br class="">focusing exclusively on operators.<br class=""><br class="">For example, think of the common mathematical functions like sin, cos, etc.<br class="">It could make sense to give them the same treatment as operators, declaring<br class="">them as part of the FloatingPoint protocol but preserving the global<br class="">functions too.<br class="">It might even make sense to be able to create trampolines not only from<br class="">global space to a type, but also from one type to another type, or even for<br class="">all methods of a type (e.g. when boxing a value inside another type).<br class=""><br class="">> * Is the problem being addressed significant enough to warrant a change to<br class="">Swift?<br class=""><br class="">Absolutely. The handling of operators in protocols has been one of the worst<br class="">pain points in my use of Swift.<br class=""><br class="">> * Does this proposal fit well with the feel and direction of Swift?<br class=""><br class="">Yes; it significantly increases clarity and consistency.<br class=""><br class="">> * If you have used other languages or libraries with a similar feature,<br class="">how do you feel that this proposal compares to those?<br class=""><br class="">I only have experience with C++ operator overloading, which is much less<br class="">advanced.<br class=""><br class="">> * How much effort did you put into your review? A glance, a quick reading,<br class="">or an in-depth study?<br class=""><br class="">An in-depth study of the proposal, and I read all the relevant threads on<br class="">the mailing list.<span class=""><font color="#888888" class=""><br class=""><br class="">--<br class="">Nicola<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></font></span></blockquote></div></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></blockquote></div></div></blockquote></div><br class=""></body></html>