<div dir="ltr">I have concerns about these revisions. It seems you&#39;ve entirely rejected all the options that Alexis has laid out very clearly, and instead you&#39;ve come up with your own rules which are backwards-incompatible with Swift 3.<div><br></div><div>For instance, the rule &quot;No type inference will happen in type declarations&quot; is source-breaking, because type inference currently happens in type declarations. You would break every instance of `let foo: Optional = 42`.</div><div><br></div><div>I would urge you to incorporate Alexis&#39;s very clear analysis and then adopt one of the options he laid out, i.e., either &quot;prefer user&quot; or &quot;do what I mean.&quot; Alternatively, if you like none of his options, I believe that requiring `&lt;&gt;` to be appended for entirely default arguments would avoid the issue altogether. Or, if you don&#39;t even want to require that, you can push the whole problem down the road by specifying that, for now, the first generic type cannot have a default. We can then relax the rules later.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 31, 2017 at 3:15 PM, Srđan Rašić <span dir="ltr">&lt;<a href="mailto:srdan.rasic@gmail.com" target="_blank">srdan.rasic@gmail.com</a>&gt;</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 updated the proposal with the things we discussed so far. Have to do some more polishing, but feel free to throw your critique of what I have so far.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh, it&#39;s precisely my confidence that a good error message can be devised which makes me ponder whether &quot;prefer user&quot; is the ideal rule. Having a stricter rule isn&#39;t necessarily bad if the error message makes it easy to remedy.<br><br>In your example, &quot;prefer user&quot; would object at the line where you make your Something. I think that makes for a much cleaner error. By contrast, DWIM necessitates the acrobatics you show above, where the compiler will have to keep track of a defaulted type for each variable as long as it&#39;s in scope and propose remote fix-its at the declaration site based on how it&#39;s later used. Now what happens if there&#39;s an action() that takes only Something&lt;Int&gt; arguments and an action2() that takes only Something&lt;Int64&gt; arguments? Will you have an alternating cycle of fix-its that don&#39;t fix the problem?<div class="m_7865366228512789809HOEnZb"><div class="m_7865366228512789809h5"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 27, 2017 at 18:07 Karl Wagner &lt;<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.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" class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><blockquote type="cite" class="m_7865366228512789809m_-4396941602112105856gmail_msg"><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="m_7865366228512789809m_-4396941602112105856gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_7865366228512789809m_-4396941602112105856m_-436689287726750244Apple-interchange-newline m_7865366228512789809m_-4396941602112105856gmail_msg"><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">Cool, thanks--that makes sense.<br class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg">Personally, although DWIM is appealing, I think if we are to go all-out on your stance that &quot;adding a default to an existing type parameter should be a strict source-breaking change,&quot; then &quot;prefer user&quot; is the one rule that maximally clarifies the scenario. With that rule, in the evolution scenarios that I brought up, either the user-specified default and the inferred literal type line up perfectly or it is guaranteed to be source-breaking. IMO, that consistency would bring more clarity than DWIM, which might prompt a user to be confused why sometimes the compiler &quot;gets it&quot; and other times it doesn’t.</div></blockquote><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div></div><div style="word-wrap:break-word" class="m_7865366228512789809m_-4396941602112105856gmail_msg"><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">I’m not sure, I think it will be easy enough for users to figure out where the problem is because it will create a type-mismatch.</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">When type mismatches occur, the only place to look is the variable definition, because that is where the type is defined.</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">This is such a narrow case that I’m sure we can provide good diagnostics for it. The pattern could be:</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">- A generic parameter mismatch (i.e. trying to use a value of type MyType&lt;X&gt; where type MyType&lt;Y&gt; is expected), and</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">- X and Y are both {Whatever}LiteralConvertible, and</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">- X is the default type bound to that parameter, and </div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">- the value was initialised using a {Whatever} literal, where an instance of the parameter was expected</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">In that case, we could introduce a simple fix-it: replacing one of the literal values with &quot;(literal as Y)”</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg">for example:</div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="m_7865366228512789809m_-4396941602112105856gmail_msg"><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><font face="Courier" class="m_7865366228512789809m_-4396941602112105856gmail_msg">struct Something&lt;T=Int64&gt; { let value: T }</font></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><font face="Courier" class="m_7865366228512789809m_-4396941602112105856gmail_msg">func action(_: Something&lt;Int&gt;) { … } // Expects a specific kind of Something&lt;T&gt;</font></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><font face="Courier" class="m_7865366228512789809m_-4396941602112105856gmail_msg">let myThing = Something(value: 42) // Fix-it: Did you mean ‘Something(value: 42 as Int)’?</font></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><font face="Courier" class="m_7865366228512789809m_-4396941602112105856gmail_msg">action(myThing)                    // Error: No overload for ‘action’ which takes a Something&lt;Int64&gt;.</font></div></blockquote><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><br class="m_7865366228512789809m_-4396941602112105856gmail_msg"></div></div></blockquote></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>