<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 Dec 31, 2015, at 9:47 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="Apple-interchange-newline">On Dec 31, 2015, at 11:18 AM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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 type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Dec 31, 2015, at 9:01 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Dec 31, 2015, at 10:09 AM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><div class="">-Dave</div></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 31, 2015, at 7:33 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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 type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Dec 31, 2015, at 5:04 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">I don’t want this thread to get distracted with memberwise initialization<br class=""></blockquote>Makes sense in general, but Kotlin solves those problems as a whole, and the major benefit of their approach is that everything fits together really fine.<br class="">But I'll skip everything that is not related to forwarding.<br class=""><br class=""><blockquote type="cite" class="">One approach I considered would look like this:<br class=""><br class="">class Forwarder: P {<br class=""> // I didn’t like `implements` but didn’t have a better idea before I abandoned this approach<br class=""> var forwardee: Forwardee implements P<span class="Apple-converted-space"> </span><br class="">}<br class=""></blockquote>Honestly, I'm can't see the value this discarded variant has for this discussion… you have to pit your proposal against Kotlin if you really want to convince anyone of its superiority.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">With the memberwise initialization proposal you also have the initializer synthesized automatically. The only thing it doesn’t do that your Kotlin example does is automatically declare conformance. This was an intentional design decision because it allows for additional expressivity. This is addressed in the alternatives considered section of the proposal. <br class=""></blockquote>Can you be more precise? Kotlin clearly states what a class is doing in its first line, with all expressivity that is necessary by practical means.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">What I mean is this. In the example you gave and the syntax Kotlin uses:</div><div class=""><br class=""></div><div class="">classs Forwarder(forwardee: Forwardee):<span class="Apple-converted-space"> </span><b class="">P by forwardee</b><span class="Apple-converted-space"> </span>{}</div><div class=""><br class=""></div><div class="">Forwarding is coupled to protocol conformance. This means I cannot use forwarding without conforming to the protocol that is forwarded. </div><div class=""><br class=""></div><div class="">Here is a quick example using the syntax of my proposal to demonstrate the difference:</div><div class=""><br class=""></div><div class="">class Forwarder {</div><div class=""> let forwardee: Forwardee</div><div class=""> forward P to forwardee</div><div class="">}</div><div class=""><br class=""></div><div class="">vs</div><div class=""><br class=""></div><div class=""><div class="">class Forwarder: P {</div><div class=""> let forwardee: Forwardee</div><div class=""> forward P to forwardee</div><div class="">}</div></div><div class=""><br class=""></div><div class="">In the first example Forwarder does not conform to P. Forwarding is only used to synthesize the members of P. I am greatly expanding the motivation section of the proposal and will have examples showing where this is what you want. The lazy collections section I posted last night includes the first examples where this is the case.</div><div class=""><br class=""></div><div class="">In the second example here Forwarder does conform to P. The author of Forwarder has the flexibility to specify whether conformance is desired or not.</div></div></div></blockquote><div class=""><br class=""></div>There are ways to handle that, including factoring the APIs of interest out of P and into a private protocol Q, then declaring the Forwardee’s conformance to Q. Now, there’s an expressivity problem with our current access control system that you can’t use an internal or private protocol to provide public API, but that should be fixed separately.</div></div></blockquote><div class=""><br class=""></div>I'm not sure where Q comes into play in this specific example. The idea here is that forwarding implementations of all members of P are synthesized by the forward declaration. It is left up to Forwarder to decide whether or not to declare actual conformance to P. I am also confused by "<span class="" style="background-color: rgba(255, 255, 255, 0);">then declaring the Forwardee’s conformance to Q" because we are discussing<span class="Apple-converted-space"> </span><b class="">Forwarder's </b>conformance here, not <b class="">Forwardee’s.</b></span></div></div></blockquote><div class=""><br class=""></div>Presumably both ends of the forwarding arrangement would have to conform to the same protocol, no?</div></div></blockquote><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="">No. This is addressed in the proposal and the lazy collections motivating example I replied with last night. I don’t think it’s a good idea to require this.</div><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="">The forwardee needs to implement the members of the protocol but does not need to conform. The forwarder will receive forwarding implementations of the members, but again does not need to declare conformance. Forwarding is orthogonal to conformance, just as it is today when you manually write forwarding members today.</div><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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 type="cite" class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">What do you have in mind when you mention using a private or internal protocol to provide public API? It sounds like that might be interesting but I'm having trouble imagining what the syntax would look like and exactly how it would work. Is this something that is planned? </div></div></div></blockquote><div class=""><br class=""></div>Not planned, but desired.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">What might it look like?</div></div></div></blockquote><div class=""><br class=""></div>Details need to be worked out. One thing we were doing for a while in the stdlib, before the rules got tightened and made it impossible, was</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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;">struct X : PublicProtocol, PrivateProtocol {</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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="">extension PublicProtocol where Self : PrivateProtocol {</div><div class=""> // API that uses only PublicProtocol in its implementation here</div><div class="">}</div></div></div></blockquote><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="">Presumably you implement public API here where members of PrivateProtocol can be accessed? This would address the problem of leaking implementation details when adding default forwarding implementations so it is definitely better than current state.</div><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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 type="cite" class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">In any case, I don't see why that is related to requiring a Forwarder to conform to the forwarded protocol. There doesn't appear to me to be a good reason to require that and there are reasons not to require it. Protocols enable and drive the forwarding member synthesis mechanism but that mechanism doesn't need to require or provide conformance. It is a third major way to use protocols in addition to generic constraints and existential types.</div></div></div></blockquote><div class=""><br class=""></div>Of course I could be wrong, but my instincts tell me that is an unneeded dimension of complexity, which is why I am resisting it. The generic/existential duality is already problematic in some ways, IMO.</div></div></blockquote><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="">I don’t really understand what is complex about it. Can you elaborate on why you think it introduces complexity? The idea seems pretty simple to me - if you can write a forwarding implementation that compiles and works the compiler should be able to synthesize it for you. I don’t see any reason to disallow that. </div><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="">Is your concern that we may not be able to support forwarding of every protocol someone might come up with and there would be confusion around what protocols are eligible for forwarding and which aren’t (similar to the current confusion around which protocols can be used as existentials and which can’t)?</div></div></blockquote><div><br class=""></div>No, it just feels like an ad-hoc use of protocols to use their APIs as constraints without creating a conformance.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="">Isn’t the primary problem with generic / existential the fact that existentials are pretty limited currently? This is an unfortunate limitation and my understanding is that there is a desire to lift at least some parts of this limitation eventually, whether that starts to happen in Swift 3 or is a feature that comes later.<span class="Apple-converted-space"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002850.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002850.html</a></div></div></blockquote><div><br class=""></div>Yes, there are plans to address this (and I’m looking forward to that!), but I think the difference is still going to be there and when to use one or the other is still going to remain a point of confusion.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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="">One specific problem with requiring conformance is that forwarding to existentials would not be straightforward because they do not conform to their protocol. Obviously this is a limitation that should be lifted eventually but it isn’t clear when that might happen.</div><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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 type="cite" class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: 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=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">Another difference that is maybe subtle but I think important is that with the approach I considered forwarding is declared in the body of a type or extension which emphasizes the fact that forwarding is an implementation detail, not something users of the type should be concerned with.<br class=""></blockquote>But what is the benefit of this emphasis? No solution requires to make the details visible in the public interface, and the ability to bury an important thing like protocol conformance somewhere in the class implementation is no advantage for me.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Protocol conformance is not buried in the implementation in my solution. I hope the previous example makes that clear. What<span class="Apple-converted-space"> </span><b class="">is</b> buried in the implementation is the forwarding declaration which causes the compiler to synthesize forwarding member implementations. This synthesis is an implementation detail and should<span class="Apple-converted-space"> </span><b class="">not</b> be visible outside the implementation.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">This approach was abandoned as it leads to problems in expressivity and clarity. Please see alternatives considered for an elaboration of that. This is especially true with the new approach to handling Self values that Brent suggested. That approach requires additional syntax around the forwarding declaration, but adds both clarity and expressiveness.<br class=""></blockquote>I think there is little need to worry about expressiveness for a feature that most potential users will probably never utilize in real code — and I don't think options like not conforming to a protocol that is forwarded is a big win here. It looks to me like you are optimizing for very uncommon cases, and sacrificing ease of use in the situations that are the most common by far.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Like I stated, I am working on adding several examples of how this feature can be used in real code. Please have a look at the lazy collections example I shared last night. This example, as well as at least one other coming examples take advantage of the ability to use forwarding without requiring conformance.</div><div class=""><br class=""></div><div class="">As with the memberwise initialization proposal, the syntax you would like to see can easily be added as syntactic sugar on top of the current proposal. I would not support that as I do not like the syntax Kotlin uses for reasons already stated, but that shouldn’t stop you from pursuing a proposal for it. Maybe a lot of people would agree with you and it would be accepted.</div><div class=""><br class=""></div><div class="">Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">It appears to me that you value conciseness very highly. I do value conciseness but I also value safety, clarity, and expressiveness. <br class=""></blockquote>No, I value elegance and simplicity — they often lead to clarity and safety.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Why not simply make this feature syntactic sugar and just auto-generate the forwarding methods?<br class=""></blockquote><br class="">That is exactly what this proposal does. Why do you feel it is not doing that?<br class=""></blockquote>you're right, guess I mixed up the proposal with something else; so at least we agree on how it should work ;-)<br class=""><br class="">I'm not saying Swift has to copy another language, but I doubt that anyone who knows Kotlin would actually consider to drop their solution in favor of what is currently discussed...<br class=""><br class="">Tino<br class=""><br class=""></div></div></blockquote></div><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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;"><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=JfMPa-2F7wwZPzsZ3QKA8NjtONIYX4SjbWuUxtpfsTY2jc73j3MLQkAv6HwzbAdik0iwLTTmL7so7Q2VgA-2B5CYwXXQ2iMcbHrhe71klOSbLwbBJQrEqzBoEd0ez-2FQRFJ3tZfNVx-2FYIsHEN3Q28AGznhpuMDhjO-2BP76umICzJX0uNq3rMCwM92VLkDUCEyAPgdC0BOpBBPLthrf2-2BfeMt6uCMMluHR79Fk5R6w7S3Zfvf4-3D" alt="" width="1" height="1" border="0" class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"><span class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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; float: none; display: inline !important;"><span class="Apple-converted-space"> </span></span><span class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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; float: none; display: inline !important;">_______________________________________________</span><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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;"><span class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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; float: none; display: inline !important;">swift-evolution mailing list</span><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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;"><a href="mailto:swift-evolution@swift.org" class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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;">swift-evolution@swift.org</a><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: 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;">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></blockquote></div></div></div></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: 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;">-Dave</div></div></blockquote></div></blockquote></div><br class=""><div class="">
-Dave
</div>
<br class=""></body></html>