Cool, thanks--that makes sense. 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. On Thu, Jan 26, 2017 at 18:15 Alexis <[email protected]> wrote:
> > On Jan 26, 2017, at 4:26 PM, Xiaodi Wu <[email protected]> wrote: > > Very interesting point, Alexis. So can you reiterate again which of the > four options you outlined earlier support this use case? And if there are > multiple, which would be the most consistent with the rest of the language? > > > Both “prefer user” and “DWIM” are consistent with my desired solution for > this specific problem (they pick Int64). DWIM seems more consistent with > the rest of Swift to me in that it tries harder to find a reasonable > interpretation of your code before giving up. I think it also ends up > having the simplest implementation in the current compiler. You can > potentially just add a new tie-breaker if-statement in this code: > https://github.com/apple/swift/blob/master/lib/Sema/CSRanking.cpp#L1010 > > Something to the affect of “if one of these was recommended by a generic > default, that one’s better”. This of course requires threading that > information through the compiler. > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
