That does not comport with the definition of "default." I would disagree with that treatment. Nor does it seem consistent with current syntax. If I have a type Foo<T>, then inference works when someone writes `let a: Foo = ...`. If I add a default to my type Foo<T=Bar>, this should be a resilient change for my users. On Tue, Jan 24, 2017 at 16:28 T.J. Usiyan via swift-evolution < [email protected]> wrote:
> I like this approach as a first pass. It leaves room for other, more > forgiving strategies later and is relatively easy to explain. > > On Tue, Jan 24, 2017 at 4:16 PM, David Sweeris via swift-evolution < > [email protected]> wrote: > > > On Jan 24, 2017, at 11:41, Alexis via swift-evolution < > [email protected]> wrote: > > It’s worth noting that the question of “how do these defaults interact > with other defaults” is an issue that has left this feature dead in the > water in the Rust language despite being accepted for inclusion two years > ago. See > https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496 > for > some discussion of the issues at hand. > > For those who don’t want to click that link, or are having trouble > translating the syntax/terms to Swift. The heart of Niko’s post is the > following (note: functions are used here for expedience; you can imagine > these are `inits` for a generic type if you wish): > > // Example 1: user supplied default is IntegerLiteralConvertible > > func foo<T=Int64>(t: T) { ... } > > foo<_>(22) > // ^ > // | > // What type gets inferred here? > > > > // Example 2: user supplied default isn't IntegerLiteralConvertible > > func bar<T=Character>(t: T) { ... } > > bar<_>(22) > // ^ > // | > // What type gets inferred here? > > > There are 4 strategies: > > (Note: I use “integer literal” here for simplicity; in general it's “any > kind of literal, and its associated LiteralType”. So this reasoning also > applies to FloatLiteralType, StringLiteralType, BooleanLiteralType, etc.) > > * Unify all: always unify the variables with all defaults. This is the > conservative choice in that it gives an error if there is any doubt. > > * Prefer literal: always prefer IntegerLiteralType (Int). This is the > maximally backwards compatible choice, but I think it leads to very > surprising outcomes. > > * Prefer user: always the user-defined choice. This is simple from one > point of view, but does lead to a potentially counterintuitive result for > example 2. > > * Do What I Mean (DWIM): Prefer the user-defined default, except in the > case where the variable is unified with an integer literal *and* the > user-defined default isn't IntegerLiteralConvertible. This is complex to > say but leads to sensible results on both examples. (Basically: prefer > user, but fallback to IntegerLiteralType if the user default doesn’t > actually make sense) > > | Strategy | Example 1 | Example 2 | > | -------------- | --------- | --------- | > | Unify all | Error | Error | > | Prefer literal | Int | Int | > | Prefer user | Int64 | Error | > | DWIM | Int64 | Int | > > > Personally, I’ve always favoured DWIM. Especially in Swift where > IntegerLiteralType inference is so frequently used (you don’t want adding a > default to cause code to stop compiling!). In practice I don’t expect there > to be many cases where this ambiguity actually kicks in, as it requires the > user-specified default to be a LiteralConvertible type that isn't the > relevant LiteralType, and for the type variable to affect an actual > Literal. So <T=String>(x: T) never causes problems, but <T=StaticString>(x: > T) does. > > As for the matter of “what if I want the other one” — you clearly know the > actual type you want; just name it explicitly. > > > We could just remove that parameter from the type inference system... if > the default value is Int and the user passes in a String, that'd be an > error, unless the user also sets that parameter to String. > > I'd envisioned using default parameters as more "compile-time > configuration options" than something for the type system to actually have > deal with. IIRC, I was trying to come up with a way to write just one > arbitrary-sized integer struct where I *could* specify the width of its > internal calculations, but would usually just use a default value. > > - Dave Sweeris > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
