<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 27, 2017 at 3:38 PM Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>&gt; wrote:<br></div><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><blockquote type="cite"><div>On Nov 27, 2017, at 4:55 PM, Tony Allevato &lt;<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>&gt; wrote:</div><br class="m_8699833211467251585Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 27, 2017 at 2:39 PM Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Nov 27, 2017, at 4:25 PM, Tony Allevato &lt;<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>&gt; wrote:</div><br class="m_8699833211467251585m_7416921589529674836Apple-interchange-newline"><div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 27, 2017 at 2:19 PM Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Nov 27, 2017, at 3:56 PM, Howard Lovatt via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313Apple-interchange-newline"><div><div dir="auto">Really like Tony’s suggestion, much cleaner than yet another annotation rammed into the signature. Also the idea of a static factory that could accept previously initialized arguments would be very powerful. <br></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>It is syntactically cleaner at the site of the function declaration for sure.  Wouldn’t you agree that it is semantically less clear though?  Both are important, but which is more important?  If not semantics, why not?</div><div><br></div><div>It’s also worth noting that it would be more verbose in at least some use cases (when a declaration such as `defaultConfiguration()` is used in the conditional default expression and is not otherwise necessary).</div></div></div></blockquote><div><br></div><div>(Apologies for the earlier blank reply—why is Cmd+Enter a keyboard shortcut for Send something someone would think is a good idea?)</div><div><br></div><div>That verbosity is kind of a feature of my design, in the sense that it describes exactly what&#39;s going on at the location in code where someone expects to see default values. If anything, the default factory name is an opportunity to add context where normally there might be none.</div><div><br></div><div>It&#39;s also worth noting that this design works well if you have multiple methods that need to share the same defaults. Instead of repeating the same annotations for each method that needs them, you just define the functions once and refer to them everywhere. (Could you do the same with the annotation based method? Probably, if you allow arbitrary expressions within them. But that seems less obvious compared to this approach.)</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>You make a really good point here.  The annotations would need to be applied to every declaration that uses them whereas your proposed syntax would just rely on overload resolution succeeding or failing in a given type context.  The use case I have would benefit in this respect as the conditional defaults would be shared by several declarations.</div><div><br></div><div>Howard’s idea of restricting conditional defaults to only use declarations in the same file seems somewhat arbitrary but it would go a long way towards helping an author understand clearly what the provided defaults are as the rest of the module and imported symbols would not need to be considered.  I wonder if this approach could be refined a bit so it feels less arbitrary.  Users would probably need to rely on tooling to discover defaults but I think I’m ok with that.  I am mostly concerned with the ability of an author to reason locally about the API contract they are publishing.  Do you have any ideas on how to refine Howard&#39;s idea?</div></div></div></blockquote><div><br></div><div>I mentioned earlier in the thread (with a few messed up details) that there are already some restrictions on default arguments that I think already work well here. Declarations referenced in the default value expression of a function today must be accessible within the scope of the declaration being defined, so I&#39;m not sure if we need to go further than that.</div><div><br></div><div>Here&#39;s an example that I&#39;ll admit is completely contrived, but should I be prevented from doing this? Let&#39;s say I define an &quot;Identities&quot; module with this type:<br></div><div><br></div><div>```</div><div>enum Identities {</div><div>  func identity() -&gt; Int { return 0 }  // let&#39;s ignore additive vs. multiplicative for a moment</div><div>  func identity() -&gt; Double { return 0.0 }</div><div>  func identity() -&gt; () { return () }</div><div>  func identity() -&gt; String { return &quot;&quot; }</div><div>  func identity&lt;T&gt;() -&gt; (T) -&gt; Void { return { _ in } }<br></div><div>  // and so on</div><div>}<br></div><div>```</div><div><br></div><div>Then somewhere I want to define a conditional default, using those identities:</div><div><br></div><div>```</div><div>import Identities</div><div><br></div><div>func someWeirdThing&lt;T&gt;( ...contrived args..., defaultValue: T =? Identities.identity()) { ... }</div><div>```</div><div><br></div><div>Swift today already allows this with regular default value expressions, so the problem of tooling being needed to discover defaults already exists and this hypothetical construct doesn&#39;t change that. We *could* restrict such defaults to same file or same module and it seems reasonable to do so, but should we? If the defaults I want happen to live elsewhere, why not let me use them? Or, if it&#39;s a serious concern, why not lock down all default expressions the same way?</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>You make a really good point about the current behavior default value expressions that I hadn’t fully considered.  It is currently possible for a new, more specific declaration to be introduced that would be selected.  It is also currently possible for the symbol that is resolved to be removed while a less specific declaration is available for resolution.  I think the reason I hadn’t considered this is that they always resolve to the same type (possibly a generic T) and a default is always available.  It seems unlikely that a change in overload resolution in this context would be problematic.</div><div><br></div><div>Dave Abrahams summed up my reluctance to embrace your proposed solution very concisely:</div><div><br></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite">This sort of “it compiles if it’s syntactically valid, regardless of declared constraints” thing is deliberately avoided in Swift’s generics design with good reason; it’s possible that in this instance there are no problems, but I’m skeptical. </blockquote></div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>You are effectively proposing that in this very narrow case we perform overload resolution on a symbol in a generic type context *after* the generic type has been replaced with a concrete type.  In every other case Swift has been very intentionally designed to resolve the symbol in a generic type context using the known constraints on the generic type.  Do you agree that this is a good rule in general?  If so, why should we make an exception to it?  If not, why not?</div></div></div></blockquote><div><br></div><div>I totally agree that that&#39;s a good rule in general—I&#39;m not 100% comfortable making an exception to it for this, but I wanted to start a discussion about a different approach than had been considered so far.</div><div><br></div><div>The idea of forcing the user to acknowledge the explicitness of SFINAE with a strawman syntax `=?` instead of `=` was a thought experiment to bridge the wild-west-C++ world of templates and Swift&#39;s stricter generics, but I can definitely understand if even that kind of approach is something that the core team (who are far more familiar with the C++ side of that coin than I am) doesn&#39;t wish to support. As was pointed out, it&#39;s not something Swift supports anywhere else today.</div><div><br></div><div>If we look at it from that point of view, where such a semantic treatment of generics would not be supported, I think it becomes a lot harder to rationalize treating this as &quot;default arguments&quot;. What you really do have (and what writing it as constrained extensions makes clear) is additional overloads, because they only apply to certain subsets of types. If that&#39;s the case, maybe it&#39;s the wrong approach to try to turn overloads into &quot;partial default values&quot;.</div><div><br></div><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><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div><br></div><div>I think the bigger concern is the other one Xiaodi mentioned—we probably don&#39;t want people to be able to retroactively add overloads that would introduce a default where previously there was none. (This wouldn&#39;t be possible for global functions in different modules, but could be for non-private type members.) This might be something that Just Works Out<img goomoji="2122" data-goomoji="2122" style="margin:0 0.2ex;vertical-align:middle;max-height:24px" alt="™" src="cid:2122@goomoji.gmail"> depending on how and when the compiler resolves such expressions—but I don&#39;t know the compiler deeply enough to say for sure without investigating more.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I think impact would be limited to the current module but I am also concerned that “this might be something that Just Works Out<img goomoji="2122" data-goomoji="2122" style="margin:0 0.2ex;vertical-align:middle;max-height:24px" alt="™" src="cid:2122@goomoji.gmail">” isn’t good enough.  IMO, we need to know or sure that it will work out ok in this context before we consider it.</div></div></div></blockquote><div><br></div><div>I think I&#39;m being misunderstood here. Naturally I&#39;m not saying we should just go full-speed into an approach and hope that it &quot;just works out&quot;. What I&#39;m saying is, I think there&#39;s potential with that approach that I don&#39;t have enough knowledge in that area and I&#39;m hoping someone with more knowledge will chime into the discussion. :)</div><div><br></div><div>So to be clear, I&#39;m not suggesting that my proposed approach, unmodified, is the way we should definitely go. My intention is just to pitch something that aims to be closer to how defaults work otherwise in the language, and try to find a way to fit this use case into it, rather than wedging in an @annotation.</div><div><br></div><div> </div><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><div><br></div><div>Please don&#39;t misunderstand - I appreciate the elegant syntax of the design you are proposing.  But I would hate to see it adopted only to have us regret the its semantics afterwards.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="auto"><br><div>-- Howard.</div><div><br>On 26 Nov 2017, at 9:25 am, Tony Allevato via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sat, Nov 25, 2017 at 1:16 PM Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>On Sat, Nov 25, 2017 at 15:06 Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt; wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Nov 25, 2017, at 1:28 PM, Tony Allevato via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419Apple-interchange-newline"><div><div><div class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419markdown-here-wrapper"><p style="margin:1.2em 0px!important">On Fri, Nov 24, 2017 at 7:18 PM Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</p><div style="margin:1.2em 0px!important"><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div><div class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419markdown-here-exclude"><div><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>It&#39;s kludgy, but we could have something like:<div><br></div><div>```</div><div>@defaultArgument(configuration = (), where R.Configuration == Void)</div><div>@defaultArgument(actionHandler = { _ in }, where R.Action == Never)</div><div><span style="font-size:12.800000190734863px">func makeResource(with configuration: R.Configuration, actionHandler: @escaping (R.Action) -&gt; Void) -&gt; R { ... }</span><br></div><div>```<br><div><br></div><div>I don&#39;t like that we&#39;d be setting a default argument on something lexically before even encountering it in the declaration, but it&#39;s serviceable.</div></div></div></blockquote><div><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div></div><div style="margin:1.2em 0px!important"><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div><p style="margin:1.2em 0px!important">What if we could take advantage of the fact that you can have non-constant expressions in default arguments? Overload resolution could already do most of the job—what we need on top of that is a way for the author to say that “if no overload matches, then it’s not an error—just don’t have a default argument in that case”. Something like SFINAE in C++, but more explicit.</p><p style="margin:1.2em 0px!important">I’m imagining something like this:</p><pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419language-swift m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs" style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em;color:rgb(51,51,51);background-color:rgb(248,248,248);display:block!important"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-func"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">func</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(153,0,0);font-weight:bold">defaultConfiguration</span><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-params">()</span> -&gt; <span style="color:rgb(153,0,0);font-weight:bold">Void</span> </span>{
  <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">return</span> ()
}

<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-func"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">func</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(153,0,0);font-weight:bold">defaultActionHandler</span><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-params">()</span> -&gt; <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-params">(Never)</span> -&gt; <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(153,0,0);font-weight:bold">Void</span> </span>{
  <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">return</span> { <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-number" style="color:rgb(0,128,128)">_</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">in</span> }
}

<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-class"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">struct</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(68,85,136);font-weight:bold">ResourceDescription</span>&lt;<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(68,85,136);font-weight:bold">R</span>: <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(68,85,136);font-weight:bold">Resource</span>&gt; </span>{
  <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-func"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">func</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(153,0,0);font-weight:bold">makeResource</span><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-params">(
    with configuration: R.Configuration <b>=?</b> defaultConfiguration<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-params">()</span>,
    actionHandler: @escaping <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-params">(R.Action)</span> -&gt; Void <b>=?</b> defaultActionHandler<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-params">()</span>
  )</span> -&gt; <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-title" style="color:rgb(153,0,0);font-weight:bold">R</span> </span>{
    <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-comment" style="color:rgb(153,153,136);font-style:italic">// create a resource using the provided configuration</span>
    <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-comment" style="color:rgb(153,153,136);font-style:italic">// connect the action handler</span>
    <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419hljs-comment" style="color:rgb(153,153,136);font-style:italic">// return the resource</span>
  }
}
</code></pre><p style="margin:1.2em 0px!important">The main difference here is the strawman<span class="m_8699833211467251585Apple-converted-space"> </span><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">=?</code><span class="m_8699833211467251585Apple-converted-space"> </span>syntax, which would indicate that “the default argument exists if there is a way the RHS can be satisfied for some instances of the generic arguments; otherwise, there is no default”, instead of today’s behavior where it would be an error. There could be multiple overloads of<span class="m_8699833211467251585Apple-converted-space"> </span><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">defaultConfiguration</code><span class="m_8699833211467251585Apple-converted-space"> </span>and<span class="m_8699833211467251585Apple-converted-space"> </span><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">defaultActionHandler</code><span class="m_8699833211467251585Apple-converted-space"> </span>(even ones that are themselves generic) and it would do the right thing when there are matches and when there aren’t.</p><p style="margin:1.2em 0px!important">I like this approach because it mostly takes advantage of existing language features and is fairly lightweight in terms of how it’s expressed in code compared to regular default arguments—we’d just need to design the new operator and type-checker logic around it.</p></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>This is an interesting approach.  One advantage to something in this direction is that it could support defining different defaults for the same argument under different constraints by overloading the default argument factories on their return type.</div><div><br></div><div>One concern I have is that it doesn’t allows us to clearly define under which constraints a default argument is available.  I suspect this might be problematic especially for public interfaces where source compatibility is a concern.  </div><div></div></div></div></blockquote><div dir="auto"><br></div></div></div><div><div class="gmail_quote"><div dir="auto">It&#39;s certainly an interesting idea but it would suggest that the constraints under which a default argument is available can change at runtime. I&#39;m concerned, like you, that this is difficult to reason about. It is still unclear to me how widespread the underlying issue is that requires conditional default arguments, but the conversation thus far has been about compile-time constraints and Tony&#39;s design seems to envision much more than that.</div></div></div></blockquote><div><br></div><div></div><div></div><div class="m_8699833211467251585m_7416921589529674836m_8605667992933255313markdown-here-wrapper"><p style="margin:1.2em 0px!important">This runtime/reasoning problem<span class="m_8699833211467251585Apple-converted-space"> </span><b>already exists</b><span class="m_8699833211467251585Apple-converted-space"> </span>today with default arguments, because you can write something like this:</p><pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs m_8699833211467251585m_7416921589529674836m_8605667992933255313language-swift" style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em;color:rgb(51,51,51);background-color:rgb(248,248,248);display:block!important"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-class"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">struct</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-title" style="color:rgb(68,85,136);font-weight:bold">Foo</span> </span>{
  <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">static</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">var</span> defaultExponent = <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-number" style="color:rgb(0,128,128)">2.0</span>

  <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-func"><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">func</span> <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-title" style="color:rgb(153,0,0);font-weight:bold">raise</span><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-params">(<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-number" style="color:rgb(0,128,128)">_</span> x: Double, to exponent: Double = defaultExponent)</span> </span>{
    <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-built_in" style="color:rgb(0,134,179)">print</span>(pow(x, exponent))
  }
}

<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-type" style="color:rgb(68,85,136);font-weight:bold">Foo</span>().raise(<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-number" style="color:rgb(0,128,128)">4</span>)  <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-comment" style="color:rgb(153,153,136);font-style:italic">// &quot;16.0&quot;</span>
<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-type" style="color:rgb(68,85,136);font-weight:bold">Foo</span>.defaultExponent = <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-number" style="color:rgb(0,128,128)">3.0</span>
<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-type" style="color:rgb(68,85,136);font-weight:bold">Foo</span>().raise(<span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-number" style="color:rgb(0,128,128)">4</span>)  <span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313hljs-comment" style="color:rgb(153,153,136);font-style:italic">// &quot;64.0&quot;</span>
</code></pre><p style="margin:1.2em 0px!important">Swift lets you write a default value expression that references static (but not instance) vars of the enclosing type, as well as anything else that’s visible from that expression’s scope. Should people do this? Probably not, for the reasons that you described.</p><p style="margin:1.2em 0px!important">But the point is that my example is no more harmful or difficult to reason about than default arguments in the language today. My proposed solution<span class="m_8699833211467251585Apple-converted-space"> </span><b>in no way</b> changes the runtime behavior of default argument expressions. I’m not envisioning anything more than what default arguments can already do except for adding a way to choose different default factories (or choose none without error) based on the<span class="m_8699833211467251585Apple-converted-space"> </span><em>static</em><span class="m_8699833211467251585Apple-converted-space"> </span>types of the generic arguments that are bound at a particular call site.</p><div title="MDH:PGRpdj5UaGlzIHJlYXNvbmluZyBwcm9ibGVtIGFscmVhZHkgZXhpc3RzIHRvZGF5IHdpdGggZGVm
YXVsdCBhcmd1bWVudHMsIGJlY2F1c2UgeW91IGNhbiB3cml0ZSBzb21ldGhpbmcgbGlrZSB0aGlz
OjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+YGBgc3dpZnQ8L2Rpdj48ZGl2PjxkaXYgc3R5bGU9
ImNvbG9yOiByZ2IoMjQ4LCAyNDgsIDI0OCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyMCwgMjAs
IDIwKTsgZm9udC1mYW1pbHk6ICZxdW90O0RlamFWdSBTYW5zIE1vbm8gZm9yIFBvd2VybGluZSZx
dW90OywgTWVubG8sIE1vbmFjbywgJnF1b3Q7Q291cmllciBOZXcmcXVvdDssIG1vbm9zcGFjZTsg
Zm9udC1zaXplOiAxM3B4OyBsaW5lLWhlaWdodDogMjBweDsgd2hpdGUtc3BhY2U6IHByZTsiPjxk
aXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij5zdHJ1Y3Q8L3NwYW4+
IEZvbyB7PC9kaXY+PGRpdj4gIDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIwNSwgMTY4LCAxMDUp
OyI+c3RhdGljPC9zcGFuPiA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMDUsIDE2OCwgMTA1KTsi
PnZhcjwvc3Bhbj4gZGVmYXVsdEV4cG9uZW50IDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIwNSwg
MTY4LCAxMDUpOyI+PTwvc3Bhbj4gPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA3LCAxMDYsIDc2
KTsiPjIuMDwvc3Bhbj48L2Rpdj48YnI+PGRpdj4gIDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIw
NSwgMTY4LCAxMDUpOyI+ZnVuYzwvc3Bhbj4gPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjE4LCAy
MDgsIDEzMyk7Ij5yYWlzZTwvc3Bhbj4oXyA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxNzIsIDEz
NiwgOTEpOyI+eDwvc3Bhbj46IERvdWJsZTxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDk1LCA5MCwg
OTYpOyBmb250LXN0eWxlOiBpdGFsaWM7Ij4sPC9zcGFuPiB0byA8c3BhbiBzdHlsZT0iY29sb3I6
IHJnYigxNzIsIDEzNiwgOTEpOyI+ZXhwb25lbnQ8L3NwYW4+OiBEb3VibGUgPHNwYW4gc3R5bGU9
ImNvbG9yOiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij49PC9zcGFuPiBkZWZhdWx0RXhwb25lbnQpIHs8
L2Rpdj48ZGl2PiAgICA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIwOCwgMTMzKTsiPnBy
aW50PC9zcGFuPig8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIwOCwgMTMzKTsiPnBvdzwv
c3Bhbj4oeDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDk1LCA5MCwgOTYpOyBmb250LXN0eWxlOiBp
dGFsaWM7Ij4sPC9zcGFuPiBleHBvbmVudCkpPC9kaXY+PGRpdj4gIH08L2Rpdj48ZGl2Pn08L2Rp
dj48YnI+PGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIwOCwgMTMzKTsiPkZvbzwv
c3Bhbj4oKS48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIwOCwgMTMzKTsiPnJhaXNlPC9z
cGFuPig8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMDcsIDEwNiwgNzYpOyI+NDwvc3Bhbj4pICA8
c3BhbiBzdHlsZT0iY29sb3I6IHJnYig5NSwgOTAsIDk2KTsgZm9udC1zdHlsZTogaXRhbGljOyI+
Ly8gIjE2LjAiPC9zcGFuPjwvZGl2PjxkaXY+Rm9vLjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIw
NywgMTA2LCA3Nik7Ij5kZWZhdWx0RXhwb25lbnQ8L3NwYW4+IDxzcGFuIHN0eWxlPSJjb2xvcjog
cmdiKDIwNSwgMTY4LCAxMDUpOyI+PTwvc3Bhbj4gPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA3
LCAxMDYsIDc2KTsiPjMuMDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDIxOCwgMjA4LCAxMzMpOyI+Rm9vPC9zcGFuPigpLjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIx
OCwgMjA4LCAxMzMpOyI+cmFpc2U8L3NwYW4+KDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIwNywg
MTA2LCA3Nik7Ij40PC9zcGFuPikgIDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDk1LCA5MCwgOTYp
OyBmb250LXN0eWxlOiBpdGFsaWM7Ij4vLyAiNjQuMCI8L3NwYW4+PC9kaXY+PC9kaXY+PC9kaXY+
PGRpdj5gYGA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlN3aWZ0IGV2ZW4gbGV0cyB5b3Ugd3Jp
dGUgYSBkZWZhdWx0IHZhbHVlIGV4cHJlc3Npb24gdGhhdCByZWZlcmVuY2VzIHN0YXRpYyAoYnV0
IG5vdCBpbnN0YW5jZSkgdmFycyBvZiB0aGUgZW5jbG9zaW5nIHR5cGUsIGFzIHdlbGwgYXMgYW55
dGhpbmcgZWxzZSB0aGF0J3MgdmlzaWJsZSBmcm9tIHRoYXQgZXhwcmVzc2lvbidzIHNjb3BlLiBT
aG91bGQgcGVvcGxlIGRvIHRoaXM/IFByb2JhYmx5IG5vdCwgZm9yIHRoZSByZWFzb25zIHRoYXQg
eW91IGRlc2NyaWJlZC4gQnV0IHRoZSBjYXBhYmlsaXR5IGlzIHRoZXJlLjwvZGl2PjxkaXY+PGJy
PjwvZGl2PjxkaXY+QnV0IHRoZSBwb2ludCBpcyB0aGF0IG15IGV4YW1wbGUgaXMgbm8gbW9yZSBo
YXJtZnVsIG9yIGRpZmZpY3VsdCB0byByZWFzb24gYWJvdXQgdGhhbiBkZWZhdWx0IGFyZ3VtZW50
cyBpbiB0aGUgbGFuZ3VhZ2UgdG9kYXkuIEknbSBub3QgZW52aXNpb25pbmcgYW55dGhpbmcgbW9y
ZSB0aGFuIHdoYXQgZGVmYXVsdCBhcmd1bWVudHMgY2FuIGFscmVhZHkgZG8gZXhjZXB0IGZvciBh
ZGRpbmcgYSB3YXkgdG8gY2hvb3NlIGRpZmZlcmVudCBkZWZhdWx0IGZhY3RvcmllcyAob3IgY2hv
b3NlIG5vbmUgd2l0aG91dCBlcnJvcikgYmFzZWQgb24gdGhlICpzdGF0aWMqIHR5cGVzIG9mIHRo
ZSBnZW5lcmljIGFyZ3VtZW50cyB0aGF0IGFyZSBib3VuZC48L2Rpdj48ZGl2PjwvZGl2PjxkaXY+
PC9kaXY+" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto">I think I prefer Xiaodi’s suggestion for that reason.  His approach could also support multiple defaults for the same parameter as long as the constraints are not allowed to overlap (overlapping constraints would result in ambiguity similar to ambiguous overload resolution) or an explicit argument is required if they do.<br></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div><div class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419markdown-here-wrapper"><p style="margin:1.2em 0px!important"><br></p><div style="margin:1.2em 0px!important"><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div><div class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419markdown-here-exclude"><div><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 24, 2017 at 8:36 PM, T.J. Usiyan via swift-evolution<span class="m_8699833211467251585Apple-converted-space"> </span><span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span><span class="m_8699833211467251585Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>I am all for this. are many types where there is an obvious &#39;zero&#39; or &#39;default&#39; value and the ability to express &quot;use that when possible&quot; without an overload is welcome.<div><br></div><div><br></div><div>The best thing that I can think of right now, in terms of syntax, is actually using @overload</div><div><br></div><div>```</div><div><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419m_2686493406202021523m_7361162569456919605gmail-"><div style="font-size:12.800000190734863px">struct ResourceDescription&lt;R: Resource&gt; {</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px"> <span class="m_8699833211467251585Apple-converted-space"> </span>func makeResource(with configuration: R.Configuration, actionHandler: @escaping (R.Action) -&gt; Void) -&gt; R </div></span><div style="font-size:12.800000190734863px"> @overload(R.Configuration == Void) func makeResource(actionHandler: @escaping (R.Action) -&gt; Void) -&gt; R</div><div style="font-size:12.800000190734863px">@overload(R.Action == Never)  func makeResource(with configuration: R.Configuration) -&gt; R</div><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419m_2686493406202021523m_7361162569456919605gmail-"><div style="font-size:12.800000190734863px">{</div><div style="font-size:12.800000190734863px">   <span class="m_8699833211467251585Apple-converted-space"> </span>// create a resource using the provided configuration</div><div style="font-size:12.800000190734863px">   <span class="m_8699833211467251585Apple-converted-space"> </span>// connect the action handler</div><div style="font-size:12.800000190734863px">   <span class="m_8699833211467251585Apple-converted-space"> </span>// return the resource</div><div style="font-size:12.800000190734863px"> <span class="m_8699833211467251585Apple-converted-space"> </span>}</div><div style="font-size:12.800000190734863px">}</div></span></div><div>```</div><div><br></div><div><br></div><div>This isn&#39;t great though…</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419m_2686493406202021523m_7361162569456919605gmail-h5">On Fri, Nov 24, 2017 at 6:11 PM, Matthew Johnson via swift-evolution<span class="m_8699833211467251585Apple-converted-space"> </span><span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span><span class="m_8699833211467251585Apple-converted-space"> </span>wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419m_2686493406202021523m_7361162569456919605gmail-h5"><div style="word-wrap:break-word"><div>As mentioned in my prior message, I currently have a PR open to update the generics manifesto (<a href="https://github.com/apple/swift/pull/13012" target="_blank">https://github.com/apple/swift/pull/13012</a>).  I removed one topic from that update at Doug Gregor’s request that it be discussed on the list first.  </div><div><br></div><div>The idea is to add the ability to make default arguments conditional (i.e. depend on generic constraints).  It is currently possible to emulate conditional default arguments using an overload set.  This is verbose, especially when several arguments are involved.  Here is an example use case using the overload method to emulate this feature:</div><div><br></div><div>```swift</div><div>protocol Resource {</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>associatedtype Configuration</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>associatedtype Action</div><div>}</div><div>struct ResourceDescription&lt;R: Resource&gt; {</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>func makeResource(with configuration: R.Configuration, actionHandler: @escaping (R.Action) -&gt; Void) -&gt; R {</div><div>   <span class="m_8699833211467251585Apple-converted-space"> </span>// create a resource using the provided configuration</div><div>   <span class="m_8699833211467251585Apple-converted-space"> </span>// connect the action handler</div><div>   <span class="m_8699833211467251585Apple-converted-space"> </span>// return the resource</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>}</div><div>}</div><div><br></div><div>extension ResourceDescription where R.Configuration == Void {</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>func makeResource(actionHandler: @escaping (R.Action) -&gt; Void) -&gt; R {</div><div>   <span class="m_8699833211467251585Apple-converted-space"> </span>return makeResource(with: (), actionHandler: actionHandler)</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>}</div><div>}</div><div><br></div><div>extension ResourceDescription where R.Action == Never {</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>func makeResource(with configuration: R.Configuration) -&gt; R {</div><div>   <span class="m_8699833211467251585Apple-converted-space"> </span>return makeResource(with: configuration, actionHandler: { _ in })</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>}</div><div>}</div><div><br></div><div>extension ResourceDescription where R.Configuration == Void, R.Action == Never {</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>func makeResource() -&gt; R {</div><div>   <span class="m_8699833211467251585Apple-converted-space"> </span>return makeResource(with: (), actionHandler: { _ in })</div><div> <span class="m_8699833211467251585Apple-converted-space"> </span>}</div><div>}</div><div><br></div><div>```</div><div><br></div><div>Adding language support for defining these more directly would eliminate a lot of boilerplate and reduce the need for overloads.  Doug mentioned that it may also help simplify associated type inference (<a href="https://github.com/apple/swift/pull/13012#discussion_r152124535" target="_blank">https://github.com/apple/swift/pull/13012#discussion_r152124535</a>).</div><div><br></div><div>The reason that I call this a pre-pitch and one reason Doug requested it be discussed on list is that I haven’t thought of a good way to express this syntactically.  I am interested in hearing general feedback on the idea.  I am also looking for syntax suggestions.</div><span class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419m_2686493406202021523m_7361162569456919605gmail-m_-7331325194590092274HOEnZb"><font color="#888888"><div><br></div><div>Matthew</div></font></span></div><br></div></div>_______________________________________________<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><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></div>_______________________________________________<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><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div></div><div style="margin:1.2em 0px!important"><br class="m_8699833211467251585m_7416921589529674836m_8605667992933255313m_-6940704932475576458m_-1505466801171777419webkit-block-placeholder"></div><div title="MDH:T24gRnJpLCBOb3YgMjQsIDIwMTcgYXQgNzoxOCBQTSBYaWFvZGkgV3UgdmlhIHN3aWZ0LWV2b2x1
dGlvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN3aWZ0LWV2b2x1dGlvbkBzd2lmdC5vcmciIHRhcmdl
dD0iX2JsYW5rIj5zd2lmdC1ldm9sdXRpb25Ac3dpZnQub3JnPC9hPiZndDsgd3JvdGU6PGJyPjxk
aXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0i
Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj
YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj5JdCdzIGtsdWRneSwgYnV0
IHdlIGNvdWxkIGhhdmUgc29tZXRoaW5nIGxpa2U6PGRpdj48YnI+PC9kaXY+PGRpdj5gYGA8L2Rp
dj48ZGl2PkBkZWZhdWx0QXJndW1lbnQoY29uZmlndXJhdGlvbiA9ICgpLCB3aGVyZSBSLkNvbmZp
Z3VyYXRpb24gPT0gVm9pZCk8L2Rpdj48ZGl2PkBkZWZhdWx0QXJndW1lbnQoYWN0aW9uSGFuZGxl
ciA9IHsgXyBpbiB9LCB3aGVyZSBSLkFjdGlvbiA9PSBOZXZlcik8L2Rpdj48ZGl2PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuODAwMDAwMTkwNzM0ODYzcHgiPmZ1bmMgbWFrZVJlc291cmNlKHdp
dGggY29uZmlndXJhdGlvbjogUi5Db25maWd1cmF0aW9uLCBhY3Rpb25IYW5kbGVyOiBAZXNjYXBp
bmcgKFIuQWN0aW9uKSAtJmd0OyBWb2lkKSAtJmd0OyBSIHsgLi4uIH08L3NwYW4+PGJyPjwvZGl2
PjxkaXY+YGBgPGJyPjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBkb24ndCBsaWtlIHRoYXQgd2UnZCBi
ZSBzZXR0aW5nIGEgZGVmYXVsdCBhcmd1bWVudCBvbiBzb21ldGhpbmcgbGV4aWNhbGx5IGJlZm9y
ZSBldmVuIGVuY291bnRlcmluZyBpdCBpbiB0aGUgZGVjbGFyYXRpb24sIGJ1dCBpdCdzIHNlcnZp
Y2VhYmxlLjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48L2Rp
dj48L2Rpdj48ZGl2IGRpcj0ibHRyIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdj5XaGF0
IGlmIHdlIGNvdWxkIHRha2UgYWR2YW50YWdlIG9mIHRoZSBmYWN0IHRoYXQgeW91IGNhbiBoYXZl
IG5vbi1jb25zdGFudCBleHByZXNzaW9ucyBpbiBkZWZhdWx0IGFyZ3VtZW50cz8gT3ZlcmxvYWQg
cmVzb2x1dGlvbiBjb3VsZCBhbHJlYWR5IGRvIG1vc3Qgb2YgdGhlIGpvYuKAlHdoYXQgd2UgbmVl
ZCBvbiB0b3Agb2YgdGhhdCBpcyBhIHdheSBmb3IgdGhlIGF1dGhvciB0byBzYXkgdGhhdCAiaWYg
bm8gb3ZlcmxvYWQgbWF0Y2hlcywgdGhlbiBpdCdzIG5vdCBhbiBlcnJvcuKAlGp1c3QgZG9uJ3Qg
aGF2ZSBhIGRlZmF1bHQgYXJndW1lbnQgaW4gdGhhdCBjYXNlIi4gU29tZXRoaW5nIGxpa2UgU0ZJ
TkFFIGluIEMrKywgYnV0IG1vcmUgZXhwbGljaXQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5J
J20gaW1hZ2luaW5nIHNvbWV0aGluZyBsaWtlIHRoaXM6PC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBk
aXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXY+PGJyPjwvZGl2PjxkaXY+YGBg
c3dpZnQ8L2Rpdj48ZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMjQ4LCAyNDgsIDI0OCk7IGJh
Y2tncm91bmQtY29sb3I6IHJnYigyMCwgMjAsIDIwKTsgZm9udC1mYW1pbHk6ICZxdW90O0RlamFW
dSBTYW5zIE1vbm8gZm9yIFBvd2VybGluZSZxdW90OywgTWVubG8sIE1vbmFjbywgJnF1b3Q7Q291
cmllciBOZXcmcXVvdDssIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxM3B4OyBsaW5lLWhlaWdodDog
MjBweDsgd2hpdGUtc3BhY2U6IHByZTsiPjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA1
LCAxNjgsIDEwNSk7Ij5mdW5jPC9zcGFuPiA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIw
OCwgMTMzKTsiPmRlZmF1bHRDb25maWd1cmF0aW9uPC9zcGFuPigpIDxzcGFuIHN0eWxlPSJjb2xv
cjogcmdiKDIwNSwgMTY4LCAxMDUpOyI+LSZndDs8L3NwYW4+ICgpIHs8L2Rpdj48ZGl2PiAgPHNw
YW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij5yZXR1cm48L3NwYW4+ICgpPC9k
aXY+PGRpdj59PC9kaXY+PGJyPjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA1LCAxNjgs
IDEwNSk7Ij5mdW5jPC9zcGFuPiA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIwOCwgMTMz
KTsiPmRlZmF1bHRBY3Rpb25IYW5kbGVyPC9zcGFuPigpIDxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDIwNSwgMTY4LCAxMDUpOyI+LSZndDs8L3NwYW4+IChOZXZlcikgPHNwYW4gc3R5bGU9ImNvbG9y
OiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij4tJmd0Ozwvc3Bhbj4gVm9pZCB7PC9kaXY+PGRpdj4gIDxz
cGFuIHN0eWxlPSJjb2xvcjogcmdiKDIwNSwgMTY4LCAxMDUpOyI+cmV0dXJuPC9zcGFuPiB7IF8g
PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij5pbjwvc3Bhbj4gfTwvZGl2
PjxkaXY+fTwvZGl2Pjxicj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIwNSwgMTY4LCAx
MDUpOyI+c3RydWN0PC9zcGFuPiBSZXNvdXJjZURlc2NyaXB0aW9uPHNwYW4gc3R5bGU9ImNvbG9y
OiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij4mbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDE3MiwgMTM2LCA5MSk7Ij5SPC9zcGFuPjogUmVzb3VyY2U8c3BhbiBzdHlsZT0iY29sb3I6IHJn
YigyMDUsIDE2OCwgMTA1KTsiPiZndDs8L3NwYW4+IHs8L2Rpdj48ZGl2PiAgPHNwYW4gc3R5bGU9
ImNvbG9yOiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij5mdW5jPC9zcGFuPiA8c3BhbiBzdHlsZT0iY29s
b3I6IHJnYigyMTgsIDIwOCwgMTMzKTsiPm1ha2VSZXNvdXJjZTwvc3Bhbj4oPC9kaXY+PGRpdj4g
ICAgd2l0aCA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxNzIsIDEzNiwgOTEpOyI+Y29uZmlndXJh
dGlvbjwvc3Bhbj46IFIuPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA3LCAxMDYsIDc2KTsiPkNv
bmZpZ3VyYXRpb248L3NwYW4+IDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIwNSwgMTY4LCAxMDUp
OyI+PT88L3NwYW4+IDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIxOCwgMjA4LCAxMzMpOyI+ZGVm
YXVsdENvbmZpZ3VyYXRpb248L3NwYW4+KCk8c3BhbiBzdHlsZT0iY29sb3I6IHJnYig5NSwgOTAs
IDk2KTsgZm9udC1zdHlsZTogaXRhbGljOyI+LDwvc3Bhbj48L2Rpdj48ZGl2PiAgICA8c3BhbiBz
dHlsZT0iY29sb3I6IHJnYigxNzIsIDEzNiwgOTEpOyI+YWN0aW9uSGFuZGxlcjwvc3Bhbj46IEA8
c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIwOCwgMTMzKTsiPmVzY2FwaW5nPC9zcGFuPiAo
Ui48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMDcsIDEwNiwgNzYpOyI+QWN0aW9uPC9zcGFuPikg
PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA1LCAxNjgsIDEwNSk7Ij4tJmd0Ozwvc3Bhbj4gVm9p
ZCA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyMDUsIDE2OCwgMTA1KTsiPj0/PC9zcGFuPiA8c3Bh
biBzdHlsZT0iY29sb3I6IHJnYigyMTgsIDIwOCwgMTMzKTsiPmRlZmF1bHRBY3Rpb25IYW5kbGVy
PC9zcGFuPigpPC9kaXY+PGRpdj4gICkgPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjA1LCAxNjgs
IDEwNSk7Ij4tJmd0Ozwvc3Bhbj4gUiB7PC9kaXY+PGRpdj4gICAgPHNwYW4gc3R5bGU9ImNvbG9y
OiByZ2IoOTUsIDkwLCA5Nik7IGZvbnQtc3R5bGU6IGl0YWxpYzsiPi8vIGNyZWF0ZSBhIHJlc291
cmNlIHVzaW5nIHRoZSBwcm92aWRlZCBjb25maWd1cmF0aW9uPC9zcGFuPjwvZGl2PjxkaXY+ICAg
IDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDk1LCA5MCwgOTYpOyBmb250LXN0eWxlOiBpdGFsaWM7
Ij4vLyBjb25uZWN0IHRoZSBhY3Rpb24gaGFuZGxlcjwvc3Bhbj48L2Rpdj48ZGl2PiAgICA8c3Bh
biBzdHlsZT0iY29sb3I6IHJnYig5NSwgOTAsIDk2KTsgZm9udC1zdHlsZTogaXRhbGljOyI+Ly8g
cmV0dXJuIHRoZSByZXNvdXJjZTwvc3Bhbj48L2Rpdj48ZGl2PiAgfTwvZGl2PjxkaXY+fTwvZGl2
PjwvZGl2PjwvZGl2PjxkaXY+YGBgPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbWFpbiBk
aWZmZXJlbmNlIGhlcmUgaXMgdGhlIHN0cmF3bWFuIGA9P2Agc3ludGF4LCB3aGljaCB3b3VsZCBp
bmRpY2F0ZSB0aGF0ICJ0aGUgZGVmYXVsdCBhcmd1bWVudCBleGlzdHMgaWYgdGhlcmUgaXMgYSB3
YXkgdGhlIFJIUyBjYW4gYmUgc2F0aXNmaWVkIGZvciBzb21lIGluc3RhbmNlcyBvZiB0aGUgZ2Vu
ZXJpYyBhcmd1bWVudHM7IG90aGVyd2lzZSwgdGhlcmUgaXMgbm8gZGVmYXVsdCIsIGluc3RlYWQg
b2YgdG9kYXkncyBiZWhhdmlvciB3aGVyZSBpdCB3b3VsZCBiZSBhbiBlcnJvci4gVGhlcmUgY291
bGQgYmUgbXVsdGlwbGUgb3ZlcmxvYWRzIG9mIGBkZWZhdWx0Q29uZmlndXJhdGlvbmAgYW5kIGBk
ZWZhdWx0QWN0aW9uSGFuZGxlcmAgKGV2ZW4gb25lcyB0aGF0IGFyZSB0aGVtc2VsdmVzIGdlbmVy
aWMpIGFuZCBpdCB3b3VsZCBkbyB0aGUgcmlnaHQgdGhpbmcgd2hlbiB0aGVyZSBhcmUgbWF0Y2hl
cyBhbmQgd2hlbiB0aGVyZSBhcmVuJ3QuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGxpa2Ug
dGhpcyBhcHByb2FjaCBiZWNhdXNlIGl0IG1vc3RseSB0YWtlcyBhZHZhbnRhZ2Ugb2YgZXhpc3Rp
bmcgbGFuZ3VhZ2UgZmVhdHVyZXMgYW5kIGlzIGZhaXJseSBsaWdodHdlaWdodCBpbiB0ZXJtcyBv
ZiBob3cgaXQncyBleHByZXNzZWQgaW4gY29kZSBjb21wYXJlZCB0byByZWd1bGFyIGRlZmF1bHQg
YXJndW1lbnRz4oCUd2UnZCBqdXN0IG5lZWQgdG8gZGVzaWduIHRoZSBuZXcgb3BlcmF0b3IgYW5k
IHR5cGUtY2hlY2tlZCBsb2dpYyBhcm91bmQgaXQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48
YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg
MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRp
diBkaXI9Imx0ciI+PGRpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4
dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTm92IDI0LCAyMDE3IGF0
IDg6MzYgUE0sIFQuSi4gVXNpeWFuIHZpYSBzd2lmdC1ldm9sdXRpb24gPHNwYW4gZGlyPSJsdHIi
PiZsdDs8YSBocmVmPSJtYWlsdG86c3dpZnQtZXZvbHV0aW9uQHN3aWZ0Lm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPnN3aWZ0LWV2b2x1dGlvbkBzd2lmdC5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy
PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBw
eCAwLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7Ym9y
ZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRp
cj0ibHRyIj5JIGFtIGFsbCBmb3IgdGhpcy4gYXJlIG1hbnkgdHlwZXMgd2hlcmUgdGhlcmUgaXMg
YW4gb2J2aW91cyAnemVybycgb3IgJ2RlZmF1bHQnIHZhbHVlIGFuZCB0aGUgYWJpbGl0eSB0byBl
eHByZXNzICJ1c2UgdGhhdCB3aGVuIHBvc3NpYmxlIiB3aXRob3V0IGFuIG92ZXJsb2FkIGlzIHdl
bGNvbWUuPGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgYmVzdCB0aGluZyB0
aGF0IEkgY2FuIHRoaW5rIG9mIHJpZ2h0IG5vdywgaW4gdGVybXMgb2Ygc3ludGF4LCBpcyBhY3R1
YWxseSB1c2luZyBAb3ZlcmxvYWQ8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmBgYDwvZGl2Pjxk
aXY+PHNwYW4gY2xhc3M9Im1fMjY4NjQ5MzQwNjIwMjAyMTUyM21fNzM2MTE2MjU2OTQ1NjkxOTYw
NWdtYWlsLSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDg2M3B4Ij5zdHJ1
Y3QgUmVzb3VyY2VEZXNjcmlwdGlvbiZsdDtSOiBSZXNvdXJjZSZndDsgezwvZGl2PjxkaXYgc3R5
bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ4NjNweCI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9
ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ4NjNweCI+Jm5ic3A7IGZ1bmMgbWFrZVJlc291cmNl
KHdpdGggY29uZmlndXJhdGlvbjogUi5Db25maWd1cmF0aW9uLCBhY3Rpb25IYW5kbGVyOiBAZXNj
YXBpbmcgKFIuQWN0aW9uKSAtJmd0OyBWb2lkKSAtJmd0OyBSJm5ic3A7PC9kaXY+PC9zcGFuPjxk
aXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ4NjNweCI+Jm5ic3A7QG92ZXJsb2Fk
KFIuQ29uZmlndXJhdGlvbiA9PSBWb2lkKSBmdW5jIG1ha2VSZXNvdXJjZShhY3Rpb25IYW5kbGVy
OiBAZXNjYXBpbmcgKFIuQWN0aW9uKSAtJmd0OyBWb2lkKSAtJmd0OyBSPC9kaXY+PGRpdiBzdHls
ZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDg2M3B4Ij5Ab3ZlcmxvYWQoUi5BY3Rpb24gPT0g
TmV2ZXIpICZuYnNwO2Z1bmMgbWFrZVJlc291cmNlKHdpdGggY29uZmlndXJhdGlvbjogUi5Db25m
aWd1cmF0aW9uKSAtJmd0OyBSPC9kaXY+PHNwYW4gY2xhc3M9Im1fMjY4NjQ5MzQwNjIwMjAyMTUy
M21fNzM2MTE2MjU2OTQ1NjkxOTYwNWdtYWlsLSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjgw
MDAwMDE5MDczNDg2M3B4Ij57PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5
MDczNDg2M3B4Ij4mbmJzcDsgJm5ic3A7IC8vIGNyZWF0ZSBhIHJlc291cmNlIHVzaW5nIHRoZSBw
cm92aWRlZCBjb25maWd1cmF0aW9uPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAw
MDE5MDczNDg2M3B4Ij4mbmJzcDsgJm5ic3A7IC8vIGNvbm5lY3QgdGhlIGFjdGlvbiBoYW5kbGVy
PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDg2M3B4Ij4mbmJzcDsg
Jm5ic3A7IC8vIHJldHVybiB0aGUgcmVzb3VyY2U8L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6
MTIuODAwMDAwMTkwNzM0ODYzcHgiPiZuYnNwOyB9PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXpl
OjEyLjgwMDAwMDE5MDczNDg2M3B4Ij59PC9kaXY+PC9zcGFuPjwvZGl2PjxkaXY+YGBgPC9kaXY+
PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGlzIGlzbid0IGdyZWF0IHRob3Vn
aOKApjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0i
Z21haWxfcXVvdGUiPjxkaXY+PGRpdiBjbGFzcz0ibV8yNjg2NDkzNDA2MjAyMDIxNTIzbV83MzYx
MTYyNTY5NDU2OTE5NjA1Z21haWwtaDUiPk9uIEZyaSwgTm92IDI0LCAyMDE3IGF0IDY6MTEgUE0s
IE1hdHRoZXcgSm9obnNvbiB2aWEgc3dpZnQtZXZvbHV0aW9uIDxzcGFuIGRpcj0ibHRyIj4mbHQ7
PGEgaHJlZj0ibWFpbHRvOnN3aWZ0LWV2b2x1dGlvbkBzd2lmdC5vcmciIHRhcmdldD0iX2JsYW5r
Ij5zd2lmdC1ldm9sdXRpb25Ac3dpZnQub3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48L2Rp
dj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4
IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LXN0eWxlOnNv
bGlkO2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+
PGRpdj48ZGl2IGNsYXNzPSJtXzI2ODY0OTM0MDYyMDIwMjE1MjNtXzczNjExNjI1Njk0NTY5MTk2
MDVnbWFpbC1oNSI+PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPjxkaXY+QXMgbWVu
dGlvbmVkIGluIG15IHByaW9yIG1lc3NhZ2UsIEkgY3VycmVudGx5IGhhdmUgYSBQUiBvcGVuIHRv
IHVwZGF0ZSB0aGUgZ2VuZXJpY3MgbWFuaWZlc3RvICg8YSBocmVmPSJodHRwczovL2dpdGh1Yi5j
b20vYXBwbGUvc3dpZnQvcHVsbC8xMzAxMiIgdGFyZ2V0PSJfYmxhbmsiIGRhdGEtc2FmZXJlZGly
ZWN0dXJsPSJodHRwczovL3d3dy5nb29nbGUuY29tL3VybD9xPWh0dHBzOi8vZ2l0aHViLmNvbS9h
cHBsZS9zd2lmdC9wdWxsLzEzMDEyJmFtcDtzb3VyY2U9Z21haWwmYW1wO3VzdD0xNTExNzIzMjgz
NTczMDAwJmFtcDt1c2c9QUZRakNOR1ZkNHZNQmJyVnVjSkNBY0lHUG1PMWU3bm9wdyI+aHR0cHM6
Ly9naXRodWIuY29tL2FwcGxlLzx3YnI+c3dpZnQvcHVsbC8xMzAxMjwvYT4pLiZuYnNwOyBJIHJl
bW92ZWQgb25lIHRvcGljIGZyb20gdGhhdCB1cGRhdGUgYXQgRG91ZyBHcmVnb3LigJlzIHJlcXVl
c3QgdGhhdCBpdCBiZSBkaXNjdXNzZWQgb24gdGhlIGxpc3QgZmlyc3QuICZuYnNwOzwvZGl2Pjxk
aXY+PGJyPjwvZGl2PjxkaXY+VGhlIGlkZWEgaXMgdG8gYWRkIHRoZSBhYmlsaXR5IHRvIG1ha2Ug
ZGVmYXVsdCBhcmd1bWVudHMgY29uZGl0aW9uYWwgKGkuZS4gZGVwZW5kIG9uIGdlbmVyaWMgY29u
c3RyYWludHMpLiZuYnNwOyBJdCBpcyBjdXJyZW50bHkgcG9zc2libGUgdG8gZW11bGF0ZSBjb25k
aXRpb25hbCBkZWZhdWx0IGFyZ3VtZW50cyB1c2luZyBhbiBvdmVybG9hZCBzZXQuJm5ic3A7IFRo
aXMgaXMgdmVyYm9zZSwgZXNwZWNpYWxseSB3aGVuIHNldmVyYWwgYXJndW1lbnRzIGFyZSBpbnZv
bHZlZC4mbmJzcDsgSGVyZSBpcyBhbiBleGFtcGxlIHVzZSBjYXNlIHVzaW5nIHRoZSBvdmVybG9h
ZCBtZXRob2QgdG8gZW11bGF0ZSB0aGlzIGZlYXR1cmU6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp
dj5gYGBzd2lmdDwvZGl2PjxkaXY+cHJvdG9jb2wgUmVzb3VyY2UgezwvZGl2PjxkaXY+Jm5ic3A7
IGFzc29jaWF0ZWR0eXBlIENvbmZpZ3VyYXRpb248L2Rpdj48ZGl2PiZuYnNwOyBhc3NvY2lhdGVk
dHlwZSBBY3Rpb248L2Rpdj48ZGl2Pn08L2Rpdj48ZGl2PnN0cnVjdCBSZXNvdXJjZURlc2NyaXB0
aW9uJmx0O1I6IFJlc291cmNlJmd0OyB7PC9kaXY+PGRpdj4mbmJzcDsgZnVuYyBtYWtlUmVzb3Vy
Y2Uod2l0aCBjb25maWd1cmF0aW9uOiBSLkNvbmZpZ3VyYXRpb24sIGFjdGlvbkhhbmRsZXI6IEBl
c2NhcGluZyAoUi5BY3Rpb24pIC0mZ3Q7IFZvaWQpIC0mZ3Q7IFIgezwvZGl2PjxkaXY+Jm5ic3A7
ICZuYnNwOyAvLyBjcmVhdGUgYSByZXNvdXJjZSB1c2luZyB0aGUgcHJvdmlkZWQgY29uZmlndXJh
dGlvbjwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAvLyBjb25uZWN0IHRoZSBhY3Rpb24gaGFuZGxl
cjwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAvLyByZXR1cm4gdGhlIHJlc291cmNlPC9kaXY+PGRp
dj4mbmJzcDsgfTwvZGl2PjxkaXY+fTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ZXh0ZW5zaW9u
IFJlc291cmNlRGVzY3JpcHRpb24gd2hlcmUgUi5Db25maWd1cmF0aW9uID09IFZvaWQgezwvZGl2
PjxkaXY+Jm5ic3A7IGZ1bmMgbWFrZVJlc291cmNlKGFjdGlvbkhhbmRsZXI6IEBlc2NhcGluZyAo
Ui5BY3Rpb24pIC0mZ3Q7IFZvaWQpIC0mZ3Q7IFIgezwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyBy
ZXR1cm4gbWFrZVJlc291cmNlKHdpdGg6ICgpLCBhY3Rpb25IYW5kbGVyOiBhY3Rpb25IYW5kbGVy
KTwvZGl2PjxkaXY+Jm5ic3A7IH08L2Rpdj48ZGl2Pn08L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2
PmV4dGVuc2lvbiBSZXNvdXJjZURlc2NyaXB0aW9uIHdoZXJlIFIuQWN0aW9uID09IE5ldmVyIHs8
L2Rpdj48ZGl2PiZuYnNwOyBmdW5jIG1ha2VSZXNvdXJjZSh3aXRoIGNvbmZpZ3VyYXRpb246IFIu
Q29uZmlndXJhdGlvbikgLSZndDsgUiB7PC9kaXY+PGRpdj4mbmJzcDsgJm5ic3A7IHJldHVybiBt
YWtlUmVzb3VyY2Uod2l0aDogY29uZmlndXJhdGlvbiwgYWN0aW9uSGFuZGxlcjogeyBfIGluIH0p
PC9kaXY+PGRpdj4mbmJzcDsgfTwvZGl2PjxkaXY+fTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+
ZXh0ZW5zaW9uIFJlc291cmNlRGVzY3JpcHRpb24gd2hlcmUgUi5Db25maWd1cmF0aW9uID09IFZv
aWQsIFIuQWN0aW9uID09IE5ldmVyIHs8L2Rpdj48ZGl2PiZuYnNwOyBmdW5jIG1ha2VSZXNvdXJj
ZSgpIC0mZ3Q7IFIgezwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyByZXR1cm4gbWFrZVJlc291cmNl
KHdpdGg6ICgpLCBhY3Rpb25IYW5kbGVyOiB7IF8gaW4gfSk8L2Rpdj48ZGl2PiZuYnNwOyB9PC9k
aXY+PGRpdj59PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5gYGA8L2Rpdj48ZGl2Pjxicj48L2Rp
dj48ZGl2PkFkZGluZyBsYW5ndWFnZSBzdXBwb3J0IGZvciBkZWZpbmluZyB0aGVzZSBtb3JlIGRp
cmVjdGx5IHdvdWxkIGVsaW1pbmF0ZSBhIGxvdCBvZiBib2lsZXJwbGF0ZSBhbmQgcmVkdWNlIHRo
ZSBuZWVkIGZvciBvdmVybG9hZHMuJm5ic3A7IERvdWcgbWVudGlvbmVkIHRoYXQgaXQgbWF5IGFs
c28gaGVscCBzaW1wbGlmeSBhc3NvY2lhdGVkIHR5cGUgaW5mZXJlbmNlICg8YSBocmVmPSJodHRw
czovL2dpdGh1Yi5jb20vYXBwbGUvc3dpZnQvcHVsbC8xMzAxMiNkaXNjdXNzaW9uX3IxNTIxMjQ1
MzUiIHRhcmdldD0iX2JsYW5rIiBkYXRhLXNhZmVyZWRpcmVjdHVybD0iaHR0cHM6Ly93d3cuZ29v
Z2xlLmNvbS91cmw/cT1odHRwczovL2dpdGh1Yi5jb20vYXBwbGUvc3dpZnQvcHVsbC8xMzAxMiUy
M2Rpc2N1c3Npb25fcjE1MjEyNDUzNSZhbXA7c291cmNlPWdtYWlsJmFtcDt1c3Q9MTUxMTcyMzI4
MzU3MzAwMCZhbXA7dXNnPUFGUWpDTkVFN3lLTG9GVVZiajBGY1lSY0FEcUFJWTVseWciPmh0dHBz
Oi8vZ2l0aHViLmNvbS9hcHBsZS88d2JyPnN3aWZ0L3B1bGwvMTMwMTIjZGlzY3Vzc2lvbl88d2Jy
PnIxNTIxMjQ1MzU8L2E+KS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSByZWFzb24gdGhh
dCBJIGNhbGwgdGhpcyBhIHByZS1waXRjaCBhbmQgb25lIHJlYXNvbiBEb3VnIHJlcXVlc3RlZCBp
dCBiZSBkaXNjdXNzZWQgb24gbGlzdCBpcyB0aGF0IEkgaGF2ZW7igJl0IHRob3VnaHQgb2YgYSBn
b29kIHdheSB0byBleHByZXNzIHRoaXMgc3ludGFjdGljYWxseS4mbmJzcDsgSSBhbSBpbnRlcmVz
dGVkIGluIGhlYXJpbmcgZ2VuZXJhbCBmZWVkYmFjayBvbiB0aGUgaWRlYS4mbmJzcDsgSSBhbSBh
bHNvIGxvb2tpbmcgZm9yIHN5bnRheCBzdWdnZXN0aW9ucy48L2Rpdj48c3BhbiBjbGFzcz0ibV8y
Njg2NDkzNDA2MjAyMDIxNTIzbV83MzYxMTYyNTY5NDU2OTE5NjA1Z21haWwtbV8tNzMzMTMyNTE5
NDU5MDA5MjI3NEhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxkaXY+PGJyPjwvZGl2Pjxk
aXY+TWF0dGhldzwvZGl2PjwvZm9udD48L3NwYW4+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+CnN3aWZ0
LWV2b2x1dGlvbiBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpzd2lmdC1ldm9sdXRp
b25Ac3dpZnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3dpZnQtZXZvbHV0aW9uQHN3aWZ0Lm9yZzwv
YT48YnI+CjxhIGhyZWY9Imh0dHBzOi8vbGlzdHMuc3dpZnQub3JnL21haWxtYW4vbGlzdGluZm8v
c3dpZnQtZXZvbHV0aW9uIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBkYXRhLXNh
ZmVyZWRpcmVjdHVybD0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL2xpc3Rz
LnN3aWZ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N3aWZ0LWV2b2x1dGlvbiZhbXA7c291cmNlPWdt
YWlsJmFtcDt1c3Q9MTUxMTcyMzI4MzU3MzAwMCZhbXA7dXNnPUFGUWpDTkZEQWFONUJjYnhyS1l5
RW9Nb1NLUGdjSlBrTHciPmh0dHBzOi8vbGlzdHMuc3dpZnQub3JnLzx3YnI+bWFpbG1hbi9saXN0
aW5mby9zd2lmdC08d2JyPmV2b2x1dGlvbjwvYT48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+
PGJyPjwvZGl2Pgo8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19f
X19fX19fX19fXzxicj4Kc3dpZnQtZXZvbHV0aW9uIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0i
bWFpbHRvOnN3aWZ0LWV2b2x1dGlvbkBzd2lmdC5vcmciIHRhcmdldD0iX2JsYW5rIj5zd2lmdC1l
dm9sdXRpb25Ac3dpZnQub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly9saXN0cy5zd2lmdC5v
cmcvbWFpbG1hbi9saXN0aW5mby9zd2lmdC1ldm9sdXRpb24iIHJlbD0ibm9yZWZlcnJlciIgdGFy
Z2V0PSJfYmxhbmsiIGRhdGEtc2FmZXJlZGlyZWN0dXJsPSJodHRwczovL3d3dy5nb29nbGUuY29t
L3VybD9xPWh0dHBzOi8vbGlzdHMuc3dpZnQub3JnL21haWxtYW4vbGlzdGluZm8vc3dpZnQtZXZv
bHV0aW9uJmFtcDtzb3VyY2U9Z21haWwmYW1wO3VzdD0xNTExNzIzMjgzNTczMDAwJmFtcDt1c2c9
QUZRakNORkRBYU41QmNieHJLWXlFb01vU0tQZ2NKUGtMdyI+aHR0cHM6Ly9saXN0cy5zd2lmdC5v
cmcvPHdicj5tYWlsbWFuL2xpc3RpbmZvL3N3aWZ0LTx3YnI+ZXZvbHV0aW9uPC9hPjxicj4KPGJy
PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+Cl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+CnN3aWZ0LWV2
b2x1dGlvbiBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpzd2lmdC1ldm9sdXRpb25A
c3dpZnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3dpZnQtZXZvbHV0aW9uQHN3aWZ0Lm9yZzwvYT48
YnI+CjxhIGhyZWY9Imh0dHBzOi8vbGlzdHMuc3dpZnQub3JnL21haWxtYW4vbGlzdGluZm8vc3dp
ZnQtZXZvbHV0aW9uIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBkYXRhLXNhZmVy
ZWRpcmVjdHVybD0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL2xpc3RzLnN3
aWZ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N3aWZ0LWV2b2x1dGlvbiZhbXA7c291cmNlPWdtYWls
JmFtcDt1c3Q9MTUxMTcyMzI4MzU3MzAwMCZhbXA7dXNnPUFGUWpDTkZEQWFONUJjYnhyS1l5RW9N
b1NLUGdjSlBrTHciPmh0dHBzOi8vbGlzdHMuc3dpZnQub3JnLzx3YnI+bWFpbG1hbi9saXN0aW5m
by9zd2lmdC08d2JyPmV2b2x1dGlvbjwvYT48YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj4=" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></div></div></div>_______________________________________________<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></div></blockquote></div></div></blockquote></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div>_______________________________________________<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></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div>