<div dir="ltr">This fits with the approach that "required" will only check that the call to the superclass' implementation is present but not that it is actually called.<div><br></div><div>OTOH should it be required to call the super implementation exactly once no matter what codepath is taken then throwing should be allowed before super's implementation is called.</div><div>It may be helpful though to check a few examples to better evaluate that case.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 8:55 PM, Ian Ynda-Hummel <span dir="ltr"><<a href="mailto:ianynda@gmail.com" target="_blank">ianynda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, I forgot the func. I can type, I swear. :)<div><br></div><div>As for the throws thing, which it doesn't look like has been addressed: method overrides cannot throw unless the overridden method throws, and it seems like in the case that an error is thrown it doesn't matter if it the was the superclass or the subclass as execution of the method is halted anyway. I might be missing something, but I don't currently see a reason that required (or whatever keyword) would exclude throws.</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 2:36 PM Marc Knaup <marc@knaup.koeln> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">PS: Just swap "init()" for "func foo()" and you have the syntax for functions which require super calls in subclasses :)<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 8:34 PM, Marc Knaup <span dir="ltr"><<a href="mailto:marc@knaup.koeln" target="_blank">marc@knaup.koeln</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I assume you just forgot "func".<div><br></div><div>Okay, in the case where the super implementation is not "required" but the subclass starts using "required" you must specify both.</div><div><br></div><div>This is the same as the current behavior for initializers:</div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">class A {</font></div><div><font face="monospace, monospace"><span style="white-space:pre-wrap"> </span>init() {}</font></div><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">class B: A {</font></div><div><font face="monospace, monospace"><span style="white-space:pre-wrap"> </span>required override init() {}</font></div><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">class C: B {</font></div><div><font face="monospace, monospace"><span style="white-space:pre-wrap"> </span>required init() {}</font></div><div><font face="monospace, monospace">}</font></div><div><br></div></div><div><br></div><div>Btw I just noticed that my previous assumption was wrong. Subclasses can always use "override" and "required". For class "C" it would just yield a warning because it's redundant.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 8:29 PM, Ian Ynda-Hummel <span dir="ltr"><<a href="mailto:ianynda@gmail.com" target="_blank">ianynda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Well, consider the following:<div><br></div><div><div><div> class Foo {</div><span><div> func foo() {</div><div> </div><div> }</div><div> }</div><div><br></div><div> class Bar: Foo {</div></span><div> override required foo() {</div><div> </div><div> }</div><div> }</div><div><br></div><div> class Baz: Bar {</div><div> override(?) required foo() {</div><div> </div><div> }</div><div> }</div></div></div><div><br></div><div>The override would be required for Bar. If not it's either making assumptions about the superclass that may not be correct or no subclass can make an overridden method required by its subsequent subclasses. Initializers have the convenience of always being required for the root class.</div><div><br></div><div>Now I think I'm talking myself out of the initializer behavior being correct. I'll just call myself undecided about that for now.</div><div><br></div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 2:22 PM Marc Knaup <marc@knaup.koeln> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">When requiring super's implementation to always be called Swift should not make the assumption that two methods with the same name but different signatures are interchangeable.<div>Only the super method with exactly the same signature - i.e. the overridden one - should be allowed to called. Anything else will likely be complex and confusing.</div><div><br></div><div>@Ian "override" keyword is neither necessary nor allowed when "required" is used since it implies exactly that already.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 8:17 PM, Ian Ynda-Hummel via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@Jordan I might slowly be convincing myself that initialization behavior is correct, though. For example, this feels right:<div><br></div><div><div> class Foo {</div><div> required func foo() {</div><div> </div><div> }</div><div> }</div><div><br></div><div> class Bar: Foo {</div><div> required func foo(bar: Bar) {</div><div> super.foo()</div><div> }</div><div> }</div><div><br></div><div>This, however, feels less right:</div><div><br></div><div> class Foo {</div><div> required func foo(string: String) {</div><div> </div><div> }</div><div><br></div><div> required func foo(url: NSURL) {</div><div> </div><div> }</div><div> }</div><div><br></div><div> class Bar: Foo {</div><div> override required func foo(string: String) {</div><div> super.foo(url: NSURL(string: string)!)</div><div> }</div><div> }</div><div><br></div><div>But regardless, I'm having trouble coming up with a better keyword.</div><div><div><div><p><span>fo</span></p></div></div><div><div><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 2:03 PM T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+1<div><br></div><div>I thought that there must have been some reason not to include it that I hadn't considered when it wasn't in Swift 1.0. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 1:59 PM, Jordan Rose via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>My hesitation about "required" is that required initializers don't have to call the <i>same</i> initializer, which is something that NS_REQUIRES_SUPER <i>does</i> enforce. (In fact, this new attribute could very well apply to required initializers as well: if you implement this initializer, you must chain to the same initializer. I'm not quite sure when that would come up, but it's potentially useful.)</div><div><br></div><div>Jordan</div><br><div><blockquote type="cite"><div><div><div>On Dec 16, 2015, at 10:56 , Ian Ynda-Hummel via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div><div dir="ltr">+1 for this if for nothing else but UIKit classes yelling at me to call super.viewDidLoad().<div><br></div><div>I think using the required keyword makes sense. The one possible caveat is overloading, as my knee jerk reaction is that methods of the same name would behave like initializers. So a method overriding a required method would have to call a required method of the same name on the superclass if one exists. I'm not convinced that's correct, though.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 1:40 PM Marc Knaup via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">"required" also doesn't mean that a subclass has to implement the required initializer since it can be inherited.<div>Your example is an abstract function which should have it's own keyword (if we ever get abstract functions).<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 7:37 PM, Vester Gottfried <span dir="ltr"><<a href="mailto:vester.gottfried@gmail.com" target="_blank">vester.gottfried@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think reusing required would send the wrong message. Required would mean for me something like NSOperation subclasses maybe require to have a main() function, but that doesn't mean you have to call super. On the contrary, the documentation of NSOperation main() explicitly states not to call super. </div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 7:08 PM, Marc Knaup <span dir="ltr"><<a href="mailto:marc@knaup.koeln" target="_blank">marc@knaup.koeln</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What about re-using the "required" keyword in the superclass which already means something similar for initializers?<div>Subclass implementations are required to call super's implementation.<br><div>If a subclass doesn't implemented the required method it could mean that it inherits the behavior from the superclass - just like initializers can be inherited too.</div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 7:02 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>+1 from me. FWIW, the Objective-C one is syntactic.</div><div><br></div><div>Information from Radar: the request for this is <a>rdar://problem/17408107</a> (plus a few duplicates). One of the dups suggests a variation where a subclass method can be declared as "refine" instead of "override" so that you can document that your <i>own</i> method is expected to call super. In this model, "@requires_super" could become something like "imposed". I personally think this doesn't add enough, especially since we wouldn't be publishing refine-vs-override in a library's public interface.</div><span><font color="#888888"><div><br></div><div>Jordan</div></font></span><div><div><br><div><blockquote type="cite"><div>On Dec 16, 2015, at 9:49 , Marc Knaup via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr" 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">Sounds reasonable since even the best flow analysis cannot ensure that all codepaths call the super implementation.<div><br></div><div>Some more edge cases:</div><div><ul><li>Calling super asynchronously by using it in a closure</li><li>Referring to the super implementation by assign it to a variable and call it later (is that really possible? never did that)</li></ul></div></div><div class="gmail_extra" 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"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 6:25 PM, Vester Gottfried<span> </span><span dir="ltr"><<a href="mailto:vester.gottfried@gmail.com" target="_blank">vester.gottfried@gmail.com</a>></span><span> </span>wrote:<br><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="ltr">I would suggest that @requires_super only checks if a call to super is present at all. More detailed behaviour should be part of the functions documentation, because I think all possibilities cannot be checked easily by the compiler. For example a call to super my be required to happen early or late inside the function. But when too early or too late is can probably not been forseen by the compiler.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 5:46 PM, Marc Knaup<span> </span><span dir="ltr"><<a href="mailto:marc@knaup.koeln" target="_blank">marc@knaup.koeln</a>></span><span> </span>wrote:<br><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="ltr">+1 always had such issues with UIViewController's lifecycle methods.<div><br></div><div>But edge cases need to be considered like "throws" for example.</div><div>Do I need to call super before I throw something?</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 5:41 PM, Matthew Johnson via swift-evolution<span> </span><span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span><span> </span>wrote:<br><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">+1 to this. Anything that helps ensure inheritance is thought through carefully and used correctly is a win.<div><br><div><blockquote type="cite"><div><div><div>On Dec 16, 2015, at 10:32 AM, Vester Gottfried via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div><div dir="ltr"><div>Some class based libraries/frameworks expect the consumer to subclass certain classes and override specific method and require that the super implementation of an overridden method is being called.</div><div><br></div><div>Not calling the super implementation is a common source of bugs that may be prevented if the compiler checks if super is called, like it does in some cases of init().</div><div><br></div><div>Example:<br></div><div><br></div><div>class Box {</div><div> @requires_super<br></div><div> <span> </span>func addStuff() { ... }</div><div>}<br></div><div><br></div><div>Overriding class Box's addStuff without calling super.addStuff() should result in an error</div><div><br></div><div>class Chest : Box {</div><div> <span> </span>override addStuff() {<br></div><div> // ERROR: addStuff() requires call to super.addStuff()</div><div> <span> </span>...</div><div> <span> </span>}</div><div>}<br></div><div><br></div><div>Objective-C developers know this as NS_REQUIRES_SUPER and I think its worth thinking about adapting it.</div><div><div><br></div><div>I hope my proposal was clear and thanks for reading,</div><div><br></div></div><div>Gottfried</div></div></div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAfetdXVtelgzCfab-2Fp92fvLNUbxvC5Ukh9mTRYtT7oZ-2BzUDHQ-2FkLVfwWHuXGWvz7iaXCPo1KAcjPGxoZUQTW8DMleErzJnIt-2FRMb1-2FEM1WN-2BscY0xmKk-2BmXO16SS-2BCT9-2B7dgbk1nlmgpvH5cNha2dTvKe3-2FSntENn88F21K4ayGJlZuPediCmd1qI2SGJLz5ZQ-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"><span> </span>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZh6TKQF8BMklGkmbYn3aAkB6MJpxZ0t4CiiE4yQ7c3-2F-2FxDq-2BE2nhnHvAuBkVBkwM6uDXj3Tn9ItDh6xxQ-2FkLlwiu1hYr6F53gyOSlV8vvG2QFLbE8T144o6I89KhIacPLr89IyBgLNJrrpOeDUJRbKLXLQQTW2cBkYK87e4-2B4ZzjRVbIK6-2FolcNdTCYIDUgxlA-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"></div><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSAZmDoVZgkFkAVq9xL32Cvop-2BxtPd01Ewb-2FmOGWtV3hST1BxIiVQiZ-2FcrCTXjW4avvFCWZI7WnIOtzUdNaGu0XflA8Kti-2BK6hq-2Bu6WTBpg-2B9WN9QvbEkBe54EbsctlV-2F2V6Yt8r5Ng1S1HbObIJRP-2BUmB10J2k720LdXFsurTutQ76sLkMDxTfICFGRpWnhEyg-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;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 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> </span>_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span 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 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" 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" target="_blank">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;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" 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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=t5fkNsX-2F7-2FAygTFNPNE08PALgkjkO6I8wpsdssDS0uiI7LPB1fq6j7rtgOPMHdLwcrIdMEjSJ0nk6Vze6ELvsy68CErgPUb5qSAn7NZqpj2PLT9ZrYrPm42arE0mcTZHmGqTMARtKBtsEmsfmD3pESkpx3Q9nZbNLoHEeqzcc9gE5jAQTzQZjHoTZzFMKIEw40wmmGyNhyZYtC97J82dT7LHVvA-2FWd6-2FwkmI9adDNEA-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSBBb3oNNkhYj8GLR3AfuHGTSJpVhOUM62vth8N5WgQr8kCzQdJu9wRCIBG-2BneD1yT-2BNU5Dl07U35YY18F5ry-2BCTtpcOEHnAmNiklcKPSM7ybSSQjvq9gRSWKb46H49UjZqJKFcyjJmHHwoxzZDpKnp-2Bz33-2FB9l44hJy2phh3WXzpiUgUJd2kMDHgxXz-2B5OeeK8-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<span><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=3FGfocPbgxkNkmje7djckg9Iw-2BGYY3X6RxJ1tkUXKCrK7wF7RoEkUT4zkrL8giGUEp6cB0vA1ZhFI-2FkkFSZbhDt6U0MA3pg8vuco0guIejWFCCQ6fnJeBQQlLRCigTofPcHHWdxGwjN3guQO3uk6gUs0nidQ0gb-2Bk2UUDF3NBi2dSn-2B-2BNad0eIZBNaH5B4RnVdGqIXpgtEBVONxNT1JA1Y-2FiVKO8Nu84kmvCjfjbTyI-3D" alt="" width="1" height="1" border="0" style="min-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>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZgZZi4EdFSCPuHxnSIb6m59KEzbc4NDXTZ8R-2BnWmLDkA6uj4JE0-2B5dN4fkE5UvLIibVWj4UZbLQiaduoLTpXaX-2Fp3DrRWvwho2wthEPtUSjfELOBFuYZHvbjpnE9yAMsX-2Bs6UEZ0AmAWP-2Fh2pXzFzgHIswwUeatCtvVrGKeLZs0VtmdNgBtWJhSbli-2B-2BEQ5U6U-3D" alt="" width="1" height="1" border="0" style="min-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">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>