<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=""><div class="">Definitely, agree that expr-statements &nbsp;would affect a lot in the language. I encourage people to look at the Swift grammar section for switch statements and then look at the ternary operator grammar. There is a clear distinction made between these two concepts in the existing language.&nbsp;</div><div class=""><br class=""></div><div class="">Expressions are mathematical concepts where there are inputs and one return value. Statement blocks are lists of commands without any such guaranteed output or side effects. Functional programming uses expressions to avoid much of the state and side effects that are common with imperative programming. It is very likely it would encourage a bunch of imperative programming side effect code based code, if statements become expressions. &nbsp;It will muddy the concept of expressions in people’s minds, trying to explain this to a student would be harder if the concepts are combined. I will say, I am not a huge fan of this idea, even if it is possible (although will try to keep an open mind).</div><div class=""><br class=""></div><div class="">Swift straddles the worlds of functional and imperative programming and a lot of functional programmers are drawn to the language because of it, keeping these concepts separate by having expressions and statements would help to keep the approaches separate in people’s minds. If you want to do the imperative approach use the statement, if you want to do the functional approach use the expressions. If they are combined then code that was written functionally might start getting imperative changes made by other developers on the team.&nbsp;</div><div class=""><br class=""></div><div class=""><div class=""><a href="https://en.wikipedia.org/wiki/Functional_programming" class="">https://en.wikipedia.org/wiki/Functional_programming</a>&nbsp;</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 13, 2015, at 11:45 AM, J. Cheyo Jimenez via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span 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; float: none; display: inline !important;" class="">Coming up with a&nbsp;special way to&nbsp;return from closures/blocks is being discussed in the remove forEach thread. It may even need its own thread since it would affect so much of the language.&nbsp;</span><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=""><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=""><span 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; float: none; display: inline !important;" class="">On Sunday, December 13, 2015, Andrew Brown via swift-evolution &lt;</span><a href="mailto:swift-evolution@swift.org" 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="">swift-evolution@swift.org</a><span 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; float: none; display: inline !important;" class="">&gt; wrote:</span><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=""><blockquote 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; 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 dir="auto" class=""><div class="">I agree, but there seems to be a lot of support for statements as expressions for some reason. That's not something I'd be keen to move towards quickly but if we need to go there, how about a more general solution.</div><div class=""><br class=""></div><div class="">Let's give every statement a builtin 'return' variable - I'll use _ in the example below but I don't think it's really appropriate.&nbsp;</div><div class=""><br class=""></div><div class="">let x = if condition {</div><div class="">&nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>_ = value1</div><div class="">&nbsp;<span class="Apple-converted-space">&nbsp;</span>} else {</div><div class="">&nbsp; &nbsp;<span class="Apple-converted-space">&nbsp;</span>_ = value2</div><div class="">&nbsp;<span class="Apple-converted-space">&nbsp;</span>}</div><div class=""><br class=""></div><div class="">let width = if condition {_ = 1920} else {_ = 640}</div><div class=""><br class=""></div><div class="">With a default assumption that _ = void if the default, if no assignments are used, we can ensure type checking and catch cases where not all paths correctly assign to _</div><div class=""><br class=""></div><div class="">ABR.</div><div class=""><br class="">On 13 Dec 2015, at 18:37, Marc Knaup via swift-evolution &lt;<a target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Replacing constructs like<div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">let x = condition ? 0 : 1</font></div><div class=""><br class=""></div><div class="">with</div><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">let x = if condition { 0 } else { 1 }</font></div><div class=""><br class=""></div><div class="">is very unlikely to make working with Swift any easier.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko<span class="Apple-converted-space">&nbsp;</span><span dir="ltr" class="">&lt;<a target="_blank" class="">dennis.s.lysenko@gmail.com</a>&gt;</span><span class="Apple-converted-space">&nbsp;</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;"><p dir="ltr" class="">Just wanted to add, in regards to the argument of "why use 'then' rather than keeping 'if condition { A } else { B }'?": besides my personal opinion that inline braces look out-of-place, braces behave specially in xcode and are notorious for screwing up indentation. For example, since swift was released, multiple non-trailing closure arguments to a single function call (e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the second closure one indentation level higher than the first. More generally/summarily, braces carry special indentation rules that do not necessarily suit expressions.<span class="Apple-converted-space">&nbsp;</span></p><div class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Dec 13, 2015, 12:17 PM&nbsp;Paul Ossenbruggen via swift-evolution &lt;<a target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<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=""><blockquote type="cite" class=""><div class="">On Dec 13, 2015, at 6:11 AM, Marc Knaup &lt;<a target="_blank" class="">marc@knaup.koeln</a>&gt; wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">I also have no preference yet so I'll just throw in some thoughts.</div><div class=""><br class=""></div><div class="">** Existing Code **</div>The removal of the ternary operator would likely affect a lot of existing code.<div class="">A quick search for " ? " (with spaces) over a large app of our team yields 304 results.</div><div class=""><br class=""></div><div class="">Two simpler examples:</div><div class=""><br class=""></div><div class=""><div class=""><font face="monospace, monospace" class="">[</font></div><div class=""><font face="monospace, monospace" class=""><span style="white-space: pre-wrap;" class="">&nbsp;   </span>"With Conditions": &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;hasReport ? "yes" : "no",</font></div><div class=""><span style="font-family: monospace, monospace; white-space: pre-wrap;" class="">&nbsp;   </span><font face="monospace, monospace" class="">"With Image": &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; hasImage ? "yes" : "no",</font></div><div class=""><span style="font-family: monospace, monospace; white-space: pre-wrap;" class="">&nbsp;   </span><font face="monospace, monospace" class="">"With Message": &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; hasMessage ? "yes" : "no",</font></div><div class=""><span style="font-family: monospace, monospace; white-space: pre-wrap;" class="">&nbsp;   </span><font face="monospace, monospace" class="">"Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",</font></div><div class=""><span style="font-family: monospace, monospace; white-space: pre-wrap;" class="">&nbsp;   </span><font face="monospace, monospace" class="">"Shared in Facebook Group": &nbsp; sharedOnFacebookGroup ? "yes" : "no",</font></div><div class=""><span style="font-family: monospace, monospace; white-space: pre-wrap;" class="">&nbsp;   </span><font face="monospace, monospace" class="">"Shared on Facebook Page": &nbsp; &nbsp;sharedOnFacebookPage ? "yes" : "no"</font></div><div class=""><font face="monospace, monospace" class="">]</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class="">view1.alpha = editing ? 1 : 0</font></div><div class=""><font face="monospace, monospace" class="">view2.alpha = editing ? 1 : 0</font></div><div class=""><font face="monospace, monospace" class="">view3.alpha = editing ? 0 : 1</font></div><div class=""><font face="monospace, monospace" class="">view4.alpha = editing ? 1 : 0</font></div></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class="">I am not sure using<span class="Apple-converted-space">&nbsp;</span><font face="monospace, monospace" class="">if…then…else</font><span class="Apple-converted-space">&nbsp;</span>would make this better to read &amp; understand or worse.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">there seems to be a lot of people who dislike ternary operators. Other languages also are similar in dumping ternary.&nbsp;</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">** Keyword<span class="Apple-converted-space">&nbsp;</span><font face="monospace, monospace" class="">then</font><span class="Apple-converted-space">&nbsp;</span>**</div><div class="">Making then a keyword would also cost us another word so that change needs to be carefully considered.</div><div class="">In our large app I found just a single instance where<span class="Apple-converted-space">&nbsp;</span><font face="monospace, monospace" class="">then</font><span class="Apple-converted-space">&nbsp;</span>was used for a variable's name:</div><div class=""><span class=""><br class=""></span></div><div class=""><font face="monospace, monospace" class=""><span class="">func</span><span class=""><span class="Apple-converted-space">&nbsp;</span>reloadConfigurationAndThen(then:<span class="Apple-converted-space">&nbsp;</span></span><span class="">() -&gt; Void</span><span class="">) { … }</span></font><br class=""></div><div class=""><p class="">Promises use the word<span class="Apple-converted-space">&nbsp;</span><font face="monospace, monospace" class="">then</font><span class="Apple-converted-space">&nbsp;</span>rather extensively:<span class="Apple-converted-space">&nbsp;</span><a href="https://promisesaplus.com/" target="_blank" class="">https://promisesaplus.com</a></p></div></div><div class="gmail_extra"><br class=""></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class="">Good point. Will think about it.</div></div><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution<span class="Apple-converted-space">&nbsp;</span><span dir="ltr" class="">&lt;<a target="_blank" class="">swift-evolution@swift.org</a>&gt;</span><span class="Apple-converted-space">&nbsp;</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 dir="auto" class=""><div class="">I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.</div><div class=""><br class=""></div><div class="">I would like to see "else if" included in whatever we adopt as the final solution.&nbsp; Is there a reason this is omitted from this proposal?&nbsp; I apologize if that was discussed in the thread.&nbsp; I haven't followed every post.&nbsp;</div><div class=""><br class="">Sent from my iPad</div><div class=""><div class=""><div class=""><br class="">On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution &lt;<a target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Hello All,&nbsp;</div><div class=""><br class=""></div><div class="">Been sick in bed all day, but decided to try to be productive…</div><div class=""><br class=""></div>I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, &nbsp;only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,<div class=""><br class=""></div><div class=""><a href="https://github.com/possen/swift-evolution/blob/master/0020.md" target="_blank" class="">https://github.com/possen/swift-evolution/blob/master/0020.md</a></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- Paul</div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen &lt;<a target="_blank" class="">possen@gmail.com</a>&gt; wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class="">Implied in using the &nbsp;“then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This &nbsp;will help to make the difference between statements and expressions clear.<div class=""><br class=""></div><div class="">let x = If cond then X else Y</div><div class=""><br class=""></div><div class="">is the full form, where “else" can not be omitted.&nbsp;</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen &lt;<a target="_blank" class="">possen@gmail.com</a>&gt; wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution &lt;<a target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><div class="">1. I would really hate to explain to someone when<span class="Apple-converted-space">&nbsp;</span><b class="">if</b><span class="Apple-converted-space">&nbsp;</span>needs a<span class="Apple-converted-space">&nbsp;</span><b class="">then</b><span class="Apple-converted-space">&nbsp;</span>and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.</div></div></div></blockquote><div class=""><br class=""></div><div class="">agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later.&nbsp;</div></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word;" class=""><div class="">3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (<b class="">if</b><span class="Apple-converted-space">&nbsp;</span>A<span class="Apple-converted-space">&nbsp;</span><b class="">then</b><span class="Apple-converted-space">&nbsp;</span>B<span class="Apple-converted-space">&nbsp;</span><b class="">else</b><span class="Apple-converted-space">&nbsp;</span>C).</div></div></div></blockquote><div class=""><br class=""></div>Yes that would be great.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?</div></div></div></blockquote><div class=""><br class=""></div><div class="">The biggest problem statement is you don’t need to exhaustively specify every outcome:</div><div class=""><br class=""></div><div class="">if cond {</div><div class=""><span style="white-space: pre-wrap;" class="">        </span>print(“hello”)</div><div class="">}</div><div class=""><br class=""></div><div class="">whereas in an expression you have to specify what happens in the else.</div><div class=""><br class=""></div><div class="">let say = if cond then “hello” else “goodbye"</div></div><div class=""><br class=""></div><div class="">unless you go seriously off the deep end:</div><div class=""><br class=""></div><div class="">let say = if cond then “hello”&nbsp;</div><div class=""><br class=""></div><div class="">&nbsp;“say" then becomes an optional, *shudder*</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAdaxSAa57vVHzgOaGS3OJDr3kBSrQQ4LUow9XMreNnGSkOltVnJB1w7eSPQnCmAvsg-2FfCzxFcek37a-2BVd36PwEHGh5EqvhIo948Lr1lsgWaCdBXwEZxt6-2BFwdHf7roCv-2F1jb2h2r9BYeyHnOlSA-2BxOALuCbwUKtpnI70jPXFQaFh8-2Bwfx46L-2FVM8zbpCeQa-2FtE-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div></blockquote></div></div><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><span class=""><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></span></div></blockquote><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZgyGF-2BKGEpH8nn4D8Nw9i1XMnAD61AsGp8lQXFbag-2B6f7gZMz4Y125guAxWdpK4sebTv2UR83D2z3MoDfJqPgYYLT8PQro5mflcoUeHIfCy9gmPG7uWpAeZrG9bFFYa-2BoA4Ym7T0eS7LN3So9yrU8aM-2BTGW4cClyytnOzkfreJ-2BFmO62uZeJ2asIjEBfH6rhFg-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a 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=""><br class=""></blockquote></div><br class=""></div></div></blockquote></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=8CZIdLciSFC-2BO5jF-2FiP8qN7dBFsgCUZ50wdTsolcRPcBc4gRDCcGfh5bX5mRukUKvcoWY6YCxLBdsTP5BnJleKjRCFBhLs6nzUoN5ZhF8g-2BcEJr9Apac5RTzgcnMnHW4CwJC4iXK98zkBCJ6LSlDICvEq3dOPAVhPvNib-2B1z4BksKD8CVRm4OU1Jx45m-2BrI2PrVDbcbqwL74FCx8lCxW7QGWd82fc4pajPbEc3Aal3k-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a 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=""></blockquote></div></div></div></blockquote></div><br class=""></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=XyCJWhfMItFjSNmahITOc-2BaLdcEkFSkNIDwJ912yGxF3UiiG2e5CDyS6l-2B-2Btc2MfUJIhAxmOdR9doYGOV6GVDOFBi9Sjdyvoam8MfkkuWg2xkqFegM1-2F7QI1PL1fwrMu7jfrCO-2BVNNr7DcKFEc6FeaMBL94i7yF3i7jcHWygMutkKhNutLrEYDcbDL6FFhV6BjR1bd662HkF4DhO-2FXQVtQ-3D-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=OWK4tSasaK2n-2FQIIcS9Ug-2FuFXG-2BJ3z6cFMLgm306hDfGn49KPBKcNGf6n-2F3V4F56OWswzH7AFgGNAihH1-2FyxLe8noJbVDe02N6OUwf-2B8baKui9F8GgNn6HSxPGrVxobf-2BLuo5RuHVOQCMbFD078NMM5Ghc9rUK6UnpXLmoH2dBoyHExZ4i79Ve06JUH-2BPtUOcahqJAXJnmXBr87Ph2NVt1RpbyS3IvjNS1OGYBkwpsM-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div></blockquote><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=emrIhnP1hIf76Foxxv4NNJQX-2FWhcznESwKBSwD1MEwzEa1QfzwuTa5Tw5okdVcUGLQKORguBGncFW0CEEMeM8qoIP-2FVk6xjPNB14RBU2edagIjJXdYIJ9rKMB3Izh78doasUgbEjcPgUpFPLchfEK4RSp6BIeVt-2F6-2FZemtMhwut9kEkwzen0i-2BfuyJ6F0PBatBhd4BsMLqLCojR9Keqr9r57wymXzpueGLNCjUapZmw-3D" alt="" width="1" height="1" border="0" 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; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span 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; float: none; display: inline !important;" class=""><span class="Apple-converted-space">&nbsp;</span>_______________________________________________</span><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=""><span 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; float: none; display: inline !important;" class="">swift-evolution mailing list</span><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=""><a href="mailto:swift-evolution@swift.org" 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="">swift-evolution@swift.org</a><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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" 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="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>