[swift-evolution] Default Generic Arguments

[Xiaodi Wu]

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 <abeingessner at apple.com> wrote:

>
> On Jan 26, 2017, at 4:26 PM, Xiaodi Wu <xiaodi.wu at gmail.com> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170127/49ef9e7d/attachment.html>