<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Another potential reason to hold off on this proposal is that hygienic macros have been mentioned by the core team enough times that it's reasonable to think they will likely be a part of Swift in the future. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">If that does happen it may be possible to implement something like this as a macro. That would allow the community to experiment with ideas and gain some experience before a commitment is made to add something to the standard library. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I've never worked in a language with a good macro system so I'm hoping others can chime in on the feasibility of implementing this in a macro. It seems likely to be possible but I'm not an expert in this area.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Dec 7, 2015, at 12:32 AM, "<a href="mailto:thorsten@portableinnovations.de">thorsten@portableinnovations.de</a>" <<a href="mailto:thorsten@portableinnovations.de">thorsten@portableinnovations.de</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>I'm against adding this.</div><div><br></div><div>Let me try to explain why:</div><div>- the proposal creates several ambiguities (as pointed out by Michael Fortin) which make the code difficult to read and can even introduce errors. </div><div>- Disambiguating with "self" does not work IMHO because this is ambiguous with the "self" from the enclosing context and easily confused. To disambiguate outer self references you would have to use e.g. "outer" to reference the outer self which adds even more clutter.</div><div>- the alternative proposed for solving these problems which requires leading dots for self-references decreases readability because the dots ar easily missed, especially because they may appear anywhere within each line as demonstrated by rhe example in the proposal</div><div>- the alternatives proposed by Jacob Bandes-Storch (defining a convenience init) and David Waite (using a simple closure) both do not need a language extension and solve the problems cited just as easily or even better: the closure even looks almost like the proposal except for the in-clause but does not suffer from the ambiguity problems or the potential of introducing errors or readability problems.</div><div><br></div><div>-Thorsten </div><div><br>Am 07.12.2015 um 04:27 schrieb Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Could you take a peek please at my updated writeup for a potential proposal here: <a href="https://gist.github.com/erica/eb32feb22ba99629285a" class="">https://gist.github.com/erica/eb32feb22ba99629285a</a></div><div class=""><br class=""></div><div class="">Thanks, -- E</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 8:12 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Palatino-Roman; font-size: 14px; 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="">Thanks for the links Erica. I appreciate your sharing them.</span><div class="" style="font-family: Palatino-Roman; font-size: 14px; 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="" style="font-family: Palatino-Roman; font-size: 14px; 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;">A lot of the examples in these articles are variations on the initialization problem (which I believe is better solved in other ways). </div><div class="" style="font-family: Palatino-Roman; font-size: 14px; 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="" style="font-family: Palatino-Roman; font-size: 14px; 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;">The other major use case appears to be DSLs (I consider the graphics code examples to be effectively a DSL for hard-coding graphics data). If one of the major use cases for method cascades is to create DSLs I think part of the discussion needs to address the question of whether or not this is the best tool to use to create DSLs in Swift (or at least certain classes of DSL). If the answer is yes then I it becomes pretty easy for this feature to demonstrate its merit. If Swift has (or can have) better tools for creating DSLs (hygienic macros?) then I think we need to look to other use cases to justify method cascades.<div class=""><br class=""></div><div class="">There were a few examples that don’t really fall into either of the two categories. There is no doubt that this feature would reduce syntactic clutter in some code that could not be eliminated by any other feature. Maybe they are pervasive enough to warrant language support and maybe not. I haven’t seen enough real-world examples to convince me yet, but am keeping my mind open and looking forward to seeing more.<div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 8:45 PM, Erica Sadun 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="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Please note that the updated topic is no longer setup closures, which I have been convinced is the less compelling of the two related concepts, but method cascading.</div><div class=""><br class=""></div><div class="">Rather than re-invent the wheel, let me offer this reading list:</div><div class=""><br class=""></div><div class=""><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box;"><a href="https://docs.google.com/document/d/1U0PeHtVQHMQ8usy7xI5Luo01W5LuWR1acN5odgu_Mtw/edit?pli=1#heading=h.7yzml1vnq8eu" class="" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none;"><u class="">Dart language feature request: method cascades</u></a></li><li class="" style="box-sizing: border-box;"><a href="http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html" class="" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none;"><u class="">Method Cascades in Dart</u></a></li><li class="" style="box-sizing: border-box;"><a href="http://radar.oreilly.com/2013/05/8-dart-features-those-fat-cats-dont-want-you-to-know.html" class="" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none;"><u class="">8 Dart Features / Fluent APIs</u></a></li><li class="" style="box-sizing: border-box;"><a href="https://mail.python.org/pipermail//python-ideas/2013-November/024124.html" class="" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); outline: 0px;">Dart-like method cascading operator in Python</a></li><li class="" style="box-sizing: border-box;"><a href="http://devblog.avdi.org/2011/09/26/sbpp-4-method-cascades/" class="" style="box-sizing: border-box; background-color: transparent; color: rgb(64, 120, 192); text-decoration: none;"><u class="">Method Cascades (in Smalltalk)</u></a></li></ul><div class=""><br class=""></div></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 7:04 PM, 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=""><span class="" style="background-color: rgba(255, 255, 255, 0);">I do agree that current approaches are a bit ugly, that they are common in Cocoa code, and that the proposal cleans this up. I would even enjoy the cleaner syntax in my own code if the feature was adopted.</span></div><div class=""><br class=""></div><div class="">However, I share Jacob's thought that focusing on improving initialization flexibility is where we should focus. I think it is a better use of our time, effort and language feature "budget". This might be a more complex problem to solve, but the payoff is much larger in the end.</div><div class=""><br class=""></div><div class="">Ideally instances should be fully configured for their intended use when initialization completes. I view the *need* for post-initialization setup as a deficiency in the language, the interface of the type, or both (even if a type must expose members that are mutated by users during the lifetime of an instance it should still be possible to fully configure an instance for its initial use during initialization). </div><div class=""><br class=""></div><div class="">If we can remove the aforementioned deficiency we will not need "setup closures". Doing this will require a language feature as well as a way to take advantage of the new feature when using Cocoa (probably through the Objective-C API import mechanism).</div><div class=""><br class=""></div><div class="">We obviously need to begin with the language feature so that is where I'm focusing right now. I plan to write a first draft of a proposal soon.</div><div class=""><br class=""></div><div class="">All of this aside, I am still interest in hearing about additional use cases for the "method cascade" idea. If it is more broadly applicable I might find it more worthwhile.<br class=""><br class=""><div class="">Sent from my iPhone</div></div><div class=""><br class="">On Dec 6, 2015, at 3:13 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">It seems like setting properties just after init is the main use case here.<div class=""><br class=""></div><div class="">I'm not against this idea, but I want to point out that this doesn't *need* to be solved by a change to the language. You can easily define a<span class="Apple-converted-space"> </span><font face="monospace, monospace" class="">convenience init</font><span class="Apple-converted-space"> </span>for UILabel that takes textAlignment, font, text, and numberOfLines as parameters. They could have default values so you can specify just the ones you need.</div><div class=""><br class=""></div><div class="">I like the idea of being able to do configure objects/values conveniently, but I'm not sure how to justify a language change for it. Perhaps we just need better autogeneration of initializers during Obj-C header import.</div><div class=""><div class=""><br class=""></div></div><div class="gmail_extra"><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class="">Jacob Bandes-Storch<br class=""></div></div></div></div><br class=""><div class="gmail_quote">On Sun, Dec 6, 2015 at 1:06 PM, Erica Sadun via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</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 class="" style="word-wrap: break-word;">Do you want me to tweak that? Or remove it entirely? Also, I think I forgot to name-drop you slightly earlier as well<div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 2:04 PM, David Waite <<a href="mailto:david@alkaline-solutions.com" target="_blank" class="">david@alkaline-solutions.com</a>> wrote:</div><br class=""><div class=""><div class="" style="word-wrap: break-word;">I’m leaning away from “self in” style syntax - I think there are too many cases where you still want to be able to bind and access the self of the object your closure was declared within.<div class=""><br class=""></div><div class="">I’m not sure you have to establish a new “self” however - have the type of object given to with is known, so the methods/functions available to it can be exposed as lexical scope. </div><div class=""><br class=""></div><div class="">To keep code clarity, use of methods/functions which shadow something in higher lexical scope should likely result in compiler errors.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 1:48 PM, ilya 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 class="" 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; word-spacing: 0px; white-space: pre-wrap;">I applaud honest description of drawbacks in the proposal :) <br class=""><br class="">There examples given, I think, demonstrate that using self without any special access leads to unresolvable ambiguities. <br class=""><br class="">If one wants to work "inside" the configured object, this seems like a good job for a private initializer. All of the ambiguities will be resolved, because extracting the init away removes its ability to capture names from the local context. <br class=""><br class="">Alternatively, I think it makes sense to continue working on configuration syntax, with "default" access to local context and "explicit" access to the object. Let's just replace $0 with something else. <br class=""><br class="">Hopefully I don't sounds too pessimistic. Erica's proposal looks going in the right direction to me. <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; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div dir="ltr" class="">On Sun, Dec 6, 2015 at 23:30 Erica Sadun 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-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class="">It's probably better at this point for me to collect my thoughts and summarize where I am at.</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/erica/eb32feb22ba99629285a" target="_blank" class="">https://gist.github.com/erica/eb32feb22ba99629285a</a></div><div class=""><br class=""></div><div class="">Please feel free to comment on-list about this proposal (github does not forward comment alerts) and</div><div class="">then I will start a new list thread as a Proposal rather than as a Request for Discussion.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">-- E</div></div><div class="" style="word-wrap: break-word;"><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 12:45 PM, ilya <<a href="mailto:ilya.nikokoshev@gmail.com" target="_blank" class="">ilya.nikokoshev@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Sorry, did I misunderstand the question? <div class=""><br class=""></div><div class="">Did you asked whether my definition will work for immutable value types? </div><div class="">If that's the question, the answer is still yes, the link has an example :) </div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 6, 2015 at 10:43 PM, Erica Sadun<span class=""> </span><span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.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 class="" style="word-wrap: break-word;"><div class="">I was specifically referring to value types. I apologize for not being clearer.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- E</div></font></span><div class=""><div class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 12:42 PM, ilya <<a href="mailto:ilya.nikokoshev@gmail.com" target="_blank" class="">ilya.nikokoshev@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Yes, it works for immutable objects with the correct definition, see the playground contents at<span class=""> </span><a href="https://github.com/ilyannn/iOS-Swift-Materials/blob/master/Playgrounds/Configure.playground/Contents.swift" target="_blank" class="">https://github.com/ilyannn/iOS-Swift-Materials/blob/master/Playgrounds/Configure.playground/Contents.swift</a></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 6, 2015 at 8:10 PM, Erica Sadun<span class=""> </span><span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.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 class="" style="word-wrap: break-word;"><div class="">I have developed something similar as well (<a href="http://ericasadun.com/2015/11/15/speeding-up-swift-playgrounds-with-closure-initialization-swiftlang/" target="_blank" class="">http://ericasadun.com/2015/11/15/speeding-up-swift-playgrounds-with-closure-initialization-swiftlang/</a>).</div><div class=""><br class=""></div><div class="">Is yours capable of handling enums and structs that would otherwise be let after declaration because mine is not.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""></font></span><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On Dec 5, 2015, at 5:16 PM, ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div dir="ltr" class="">> PROBLEM: With many Apple-supplied classes, typical initializers fail to fully set up an instance for use. Here's one example: ...<div class=""><br class=""></div><div class="">FWIW, I created a configuration operator more then a year ago, and use it in all of my Swift projects:</div><div class=""><br class=""></div><div class=""><div class="">let task = NSTask() +=+ {</div><div class=""> <span class=""> </span>$0.launchPath = "/usr/bin/mdfind"</div><div class=""> <span class=""> </span>$0.arguments = ["kMDItemDisplayName == *.playground"]</div><div class=""> <span class=""> </span>$0.standardOutput = pipe</div><div class="">}</div><div class=""><br class=""></div><div class="">Note you can also use the configured object in the rhs:</div><div class=""><br class=""></div><div class=""><div class="">let questionLabel = UILabel() +=+ {</div><div class=""> <span class=""> </span>$0.textAlignment = .Center</div><div class=""> <span class=""> </span>$0.font = UIFont(name:"DnealianManuscript", size: 72)</div><div class=""> <span class=""> </span>$0.text = currentQuestion.questionText</div><div class=""> <span class=""> </span>$0.numberOfLines = 0</div></div><div class=""> <span class=""> </span>view.addSubview($0)</div><div class="">}</div><div class=""><br class=""></div></div><div class="">This $0. certainly looks ugly and it would be great to be able to simplify this. I don't llike the following much though (dot-syntax can be ambiguos here, and using simply a method name is even worse):</div><div class=""><br class=""></div><div class=""><div class="">let questionLabel = UILabel() +=+ {</div><div class=""> <span class=""> </span>.textAlignment = .Center</div><div class=""> <span class=""> </span>.font = UIFont(name:"DnealianManuscript", size: 72)</div><div class=""> <span class=""> </span>.text = currentQuestion.questionText</div><div class=""> <span class=""> </span>.numberOfLines = 0</div><div class=""> <span class=""> </span>view.addSubview($0)</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Actually I would be happy with something like</div><div class=""><br class=""></div><div class=""><div class="">let questionLabel = UILabel() .{</div><div class=""> <span class=""> </span>..textAlignment = .Center</div><div class=""> <span class=""> </span>..font = UIFont(name:"DnealianManuscript", size: 72)</div><div class=""> <span class=""> </span>..text = currentQuestion.questionText</div><div class=""> <span class=""> </span>..numberOfLines = 0</div><div class=""> <span class=""> </span>view.addSubview($0)</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Other thoughts?</div><div class=""><br class=""></div><div class=""> </div></div></div></div><span class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=r5jpKsi6nat7oa43lpCLi5GRGm2utDkbDscuFklXZ2cxud9iRxsZ36zHq7XlPj9-2BOixzAQAUIKv817EfMPap26bUo4Vp7fmXyVAk3kGoXDFbxviOOjJN4IhLbXEbLBgeaEWnLntESKUKKtxs15npR33Hf0fzcj0YKh4IB-2BoUKA5SrRpArMzvl2386L5kt-2Bch5TR24-2FB9K3KdjUboRdcES55hY7En6zqMtl7SJ055yJM-3D" alt="" width="1" height="1" border="0" class="" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"><span class=""> </span>_______________________________________________<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><br class=""></span></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1p9Jer2O6jVE9KWvo-2B9iUaEyN8slp4IizyiLwsfp54OfRrvQaqd2xia8dG1-2BVn5WvM90J86tG6uUixundnyEMfUtDUgGlwaoXJ3b4SU4pyN-2FYJjmL-2FT-2Fm-2FUmCeb7arT-2FR4XQQxQEDhEwRxoWqKm69s7-2Byob8G79LYwjtqS6jpJDkVaVEMlrwU1wge1pKq9o4iE3Qef7C-2FLE4kqEFVlmN1zIgU-2FAfQxUqPRdHufxHmH0-3D" alt="" width="1" height="1" border="0" class="" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"></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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43vFcOQoCM-2FU-2BigXPSqPoICKZiPHTExqP3k3nt-2B3uLJqisLQJvNovjHZ0AwJ35OLdvX-2Bkv-2BY88Nwx-2BjvaJmMYDEw6artbn-2F8umz-2FBCTOZgsro8F-2Fne6ICTBsp-2FcUHAws5AXZViXfIQSJLUFAEZoj71BItILAr3dVXTmfcwsLD-2Fh967lOYIIcLn4pbiG-2FvXEg-2F-2BMdB8qwpG0Jwfcgo4aXhOLo-3D" alt="" width="1" height="1" border="0" class="" 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; min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"><span class="" 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; float: none; display: inline !important;"><span class=""> </span>_______________________________________________</span><br class="" 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;"><span class="" 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; float: none; display: inline !important;">swift-evolution mailing list</span><br class="" 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;"><a href="mailto:swift-evolution@swift.org" target="_blank" class="" 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;">swift-evolution@swift.org</a><br class="" 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;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="" 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;">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=P-2BsYbBZHRBuLDBJaL4DIKDNfkkjpROowTyRAObV11qz8oXUypfOB-2FRrULe8CypmZgLwiPJm71qi4IQos-2FMCZVUsAMqAcm6LTK6wgUTq7B9xPtPc9evxiOlshzRTo7q19Z2LRtaVL5gTAT4bvu-2FffsG-2FS410U-2BWTidjuY3tjy6ZLGIv6YnFENwj-2BcGdNqVHyHubwixKU-2B4rLCzSotMePqXq8hX-2Bn6LJ2I-2Fuzdb8g4KDQ-3D" alt="" width="1" height="1" border="0" class="" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"></div></div></div><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" 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><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAd0xNI-2BT0rtfArTF3Z-2FoMLn-2FrwaLQd1G7ph2SyENufkvqLP-2F26GyiI8ScijUExbZHTkSgkXQ5rUPX8VkUHfF5R9mHUCEdXoiZHS2u0-2B4ikr95pv6C49z6Eeocod4qDdLxrGlSXiF5o35eNobM-2BNlBb4pN341TYhXmqM0Fw44JiNBGA1xXuznekbdA2ZXZqy1ms-3D" alt="" width="1" height="1" border="0" class="" style="height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"></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 href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAdPWbt-2FnaTO-2Fv2o24txZNQAvNWT5eyIWMut2JHFP85rEbWTtym1a7cP7S4WLH-2BZd-2BZVqEzDEf2sTgOg6kWW5zyDsiPsfouAdECSixyu5ltCw3r9skSMOWSExPrLuXzaSiyjUW8INEqjLeEQGEBwYlEIR32nV-2FT-2BeYO8Kl2mI5aqNw1Il63R-2BxLCYu9qDuVzvMs-3D" alt="" width="1" height="1" border="0" class="" style="height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></div></div></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Z0lfE0AvBRKWSDAcltP5-2FwA6tH7CtZqjBw6KQdxzh8UeEAuMESPncyStoaIO7wH-2B3Bwz-2FKo4ZpNom62n4xy18J-2B6XL1-2F-2BkgIWDX5tuMMxovF1EX7ucM-2BmeEp7jY-2FWs0Br9tZrwCe8DPmFG26yoBB0rX1TjOTed-2FsktABfHxdFcOVPrnP4pa7USyQn4-2FqE3sZo9JwQDwGbLr93YvdgSQuAHbxNOCQr82hs2AccDD-2BuJO7B6OiTc6c41pkiWm86Bnb" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></body></html>