> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
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. When type mismatches occur, the only place to look is the variable definition, because that is where the type is defined. This is such a narrow case that I’m sure we can provide good diagnostics for it. The pattern could be: - A generic parameter mismatch (i.e. trying to use a value of type MyType<X> where type MyType<Y> is expected), and - X and Y are both {Whatever}LiteralConvertible, and - X is the default type bound to that parameter, and - the value was initialised using a {Whatever} literal, where an instance of the parameter was expected In that case, we could introduce a simple fix-it: replacing one of the literal values with "(literal as Y)” for example: struct Something<T=Int64> { let value: T } func action(_: Something<Int>) { … } // Expects a specific kind of Something<T> let myThing = Something(value: 42) // Fix-it: Did you mean ‘Something(value: 42 as Int)’? action(myThing) // Error: No overload for ‘action’ which takes a Something<Int64>.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution