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.
On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu <[email protected]> wrote: > 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. > > 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? > > > On Fri, Jan 27, 2017 at 18:07 Karl Wagner <[email protected]> wrote: > >> >> On 27 Jan 2017, at 01:30, Xiaodi Wu via swift-evolution < >> [email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
