<div dir="ltr">The proposal has been refactored to include all the things we have discussed here. Thanks everyone for your feedback. If I've missed something, please shout.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 7:35 AM, 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>Hah, did I really do that :( I completely missed the fact that `<span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">let foo: Optional = 42` is supported at the moment. I've been programming in Swift in day zero, but never really used such syntax. </span></div><div><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)"><br></span></div><div><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">I'll update the PR, thanks for your feedback. </span></div><div class="HOEnZb"><div class="h5"><div><br><div class="gmail_quote"><div>ons. 1. feb. 2017 kl. 00.05 skrev Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-1805450830551326941gmail_msg">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 class="m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941gmail_msg">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 class="m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941gmail_msg">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><div class="m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg"></div><div class="gmail_extra m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg"><div class="gmail_quote m_-1805450830551326941gmail_msg">On Tue, Jan 31, 2017 at 3:15 PM, Srđan Rašić <span class="m_-1805450830551326941gmail_msg"><<a href="mailto:srdan.rasic@gmail.com" class="m_-1805450830551326941gmail_msg" target="_blank">srdan.rasic@gmail.com</a>></span> wrote:<br class="m_-1805450830551326941gmail_msg"><blockquote class="gmail_quote m_-1805450830551326941gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-1805450830551326941gmail_msg">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="m_-1805450830551326941m_7952860785986058315HOEnZb m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941m_7952860785986058315h5 m_-1805450830551326941gmail_msg"><div class="gmail_extra m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg"><div class="gmail_quote m_-1805450830551326941gmail_msg">On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu <span class="m_-1805450830551326941gmail_msg"><<a href="mailto:xiaodi.wu@gmail.com" class="m_-1805450830551326941gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br class="m_-1805450830551326941gmail_msg"><blockquote class="gmail_quote m_-1805450830551326941gmail_msg" 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 class="m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg">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_-1805450830551326941m_7952860785986058315m_7865366228512789809HOEnZb m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809h5 m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941gmail_msg"><div class="gmail_quote m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941gmail_msg">On Fri, Jan 27, 2017 at 18:07 Karl Wagner <<a href="mailto:razielim@gmail.com" class="m_-1805450830551326941gmail_msg" target="_blank">razielim@gmail.com</a>> wrote:<br class="m_-1805450830551326941gmail_msg"></div><blockquote class="gmail_quote m_-1805450830551326941gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><blockquote type="cite" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856m_-436689287726750244Apple-interchange-newline m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">Cool, thanks--that makes sense.<br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_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_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div></div><div style="word-wrap:break-word" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_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_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_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_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_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_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_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_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">- X and Y are both {Whatever}LiteralConvertible, and</div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">- X is the default type bound to that parameter, and </div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">- the value was initialised using a {Whatever} literal, where an instance of the parameter was expected</div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_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_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">for example:</div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><font face="Courier" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">struct Something<T=Int64> { let value: T }</font></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><font face="Courier" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">func action(_: Something<Int>) { … } // Expects a specific kind of Something<T></font></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><font face="Courier" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">let myThing = Something(value: 42) // Fix-it: Did you mean ‘Something(value: 42 as Int)’?</font></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><font face="Courier" class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg">action(myThing) // Error: No overload for ‘action’ which takes a Something<Int64>.</font></div></blockquote><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div><div class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"><br class="m_-1805450830551326941m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg m_-1805450830551326941gmail_msg"></div></div></blockquote></div>
</div></div></blockquote></div><br class="m_-1805450830551326941gmail_msg"></div>
</div></div></blockquote></div><br class="m_-1805450830551326941gmail_msg"></div></div></blockquote></div></div></div></div></blockquote></div><br></div>