<div dir="ltr">I have concerns about these revisions. It seems you've entirely rejected all the options that Alexis has laid out very clearly, and instead you've come up with your own rules which are backwards-incompatible with Swift 3.<div><br></div><div>For instance, the rule "No type inference will happen in type declarations" 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's very clear analysis and then adopt one of the options he laid out, i.e., either "prefer user" or "do what I mean." Alternatively, if you like none of his options, I believe that requiring `<>` to be appended for entirely default arguments would avoid the issue altogether. Or, if you don'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"><<a href="mailto:srdan.rasic@gmail.com" target="_blank">srdan.rasic@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 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"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh, it's precisely my confidence that a good error message can be devised which makes me ponder whether "prefer user" is the ideal rule. Having a stricter rule isn't necessarily bad if the error message makes it easy to remedy.<br><br>In your example, "prefer user" 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's in scope and propose remote fix-its at the declaration site based on how it's later used. Now what happens if there's an action() that takes only Something<Int> arguments and an action2() that takes only Something<Int64> arguments? Will you have an alternating cycle of fix-its that don'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 <<a href="mailto:razielim@gmail.com" target="_blank">razielim@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 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 <<a href="mailto:swift-evolution@swift.org" class="m_7865366228512789809m_-4396941602112105856gmail_msg" target="_blank">swift-evolution@swift.org</a>> 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 "adding a default to an existing type parameter should be a strict source-breaking change," then "prefer user" 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 "gets it" 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<X> where type MyType<Y> 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 "(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<T=Int64> { let value: T }</font></div><div class="m_7865366228512789809m_-4396941602112105856gmail_msg"><font face="Courier" class="m_7865366228512789809m_-4396941602112105856gmail_msg">func action(_: Something<Int>) { … } // Expects a specific kind of Something<T></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<Int64>.</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>