<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><br><div class="gmail_quote"><div>ons. 1. feb. 2017 kl. 00.05 skrev Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">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="gmail_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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_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="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Tue, Jan 31, 2017 at 3:15 PM, Srđan Rašić <span class="gmail_msg"><<a href="mailto:srdan.rasic@gmail.com" class="gmail_msg" target="_blank">srdan.rasic@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_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_7952860785986058315HOEnZb gmail_msg"><div class="m_7952860785986058315h5 gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu <span class="gmail_msg"><<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_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="gmail_msg"><br class="gmail_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_7952860785986058315m_7865366228512789809HOEnZb gmail_msg"><div class="m_7952860785986058315m_7865366228512789809h5 gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Fri, Jan 27, 2017 at 18:07 Karl Wagner <<a href="mailto:razielim@gmail.com" class="gmail_msg" target="_blank">razielim@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><blockquote type="cite" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856m_-436689287726750244Apple-interchange-newline m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">Cool, thanks--that makes sense.<br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_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_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div></div><div style="word-wrap:break-word" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_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_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_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_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_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_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_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_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">- X and Y are both {Whatever}LiteralConvertible, and</div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">- X is the default type bound to that parameter, and </div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">- the value was initialised using a {Whatever} literal, where an instance of the parameter was expected</div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_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_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">for example:</div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><font face="Courier" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">struct Something<T=Int64> { let value: T }</font></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><font face="Courier" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">func action(_: Something<Int>) { … } // Expects a specific kind of Something<T></font></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><font face="Courier" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">let myThing = Something(value: 42) // Fix-it: Did you mean ‘Something(value: 42 as Int)’?</font></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><font face="Courier" class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg">action(myThing) // Error: No overload for ‘action’ which takes a Something<Int64>.</font></div></blockquote><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div><div class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"><br class="m_7952860785986058315m_7865366228512789809m_-4396941602112105856gmail_msg gmail_msg"></div></div></blockquote></div>
</div></div></blockquote></div><br class="gmail_msg"></div>
</div></div></blockquote></div><br class="gmail_msg"></div></div></blockquote></div></div>