The fact that it has a default generic argument means that it has a "knob" to turn based on changes in needs of the code. For example, if you had a struct that used a T (defaulted to Int) for a field, and that field's range should become a Double in your use case, you know that there's something you can change to get that behavior, while just X might look like you'd need to create your own type.
On Mon, Jan 23, 2017 at 2:41 PM, Michael Ilseman <[email protected]> wrote: > > On Jan 23, 2017, at 10:41 AM, Trent Nadeau via swift-evolution < > [email protected]> wrote: > > The proposal looks good to me with one possible concern. I'm leaning > toward types that use the defaults should still require the angle brackets, > X<>. This makes it clear that you're using a generic type. > > > What are the perceived benefits by making it explicit that you’re using a > defaulted-or-inferred generic type? What important pieces of information > would the presence of an explicit “<>” communicate to future > readers/maintainers of the code? > > That leads me to think that the examples Doug gave should be an error as > the explicit types on the `let`s should either be omitted completely or > fully specified (as X<>, X<Double>, X<Int>, etc.). > > On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution < > [email protected]> wrote: > >> >> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution < >> [email protected]> wrote: >> >> >> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution < >> [email protected]> wrote: >> >> Hi Everyone, >> >> I've opened a PR (https://github.com/apple/swift-evolution/pull/591 >> ) proposing default generic arguments which I think would be nice >> addition to the language. They are also mentioned in "Generic manifesto". >> >> The proposal is focusing around generic types. Generic functions are not >> coved by the proposal and I don't think that we need default generic >> arguments in generic functions as all the types are always part of the >> function signature so the compiler can always infer them. One corner case >> might be if using default argument values in which case support for default >> generic arguments in functions might be useful. >> >> >> The proposal looks fairly straightforward and reasonable. One thing to >> think about is how it interacts with type inference. For example, consider >> these examples: >> >> struct X<T = Int> { } >> >> func f1() -> X<Double> { return X() } >> >> func f2() -> X<Int> { return X() } >> func f2() -> X<Double> { return X() } >> >> func f3<T>(_: T) -> X<T> { return X() } >> >> let x1: X = f1() // okay: x1 has type X<Double>? >> let x2: X = f2() // ambiguous? >> let x3a: X = f3(1.5) // okay: x3a has type X<Double>? >> let x3b: X = f3(1) // okay: x3a has type X<Int>? >> >> The type checker already has some notion of “if you can’t infer a >> particular type, fill in a default” that is used for literals. That rule >> could be used here… or we could do something else. This should be discussed >> in the proposal. >> >> Thanks for working on this! >> >> >> There's an interesting parallel to the default behavior of literals. The >> type of a number or string literal is inferred from type context, or falls >> back to a default type like Int or String if that doesn't come up with an >> answer. You could think of that of saying the 'Self' type of the protocol >> constraint has a default (and maybe that's how we'd generalize the "default >> type for a protocol" feature if we wanted to.) It makes sense to me to >> follow a similar model for generic parameter defaults; that way, there's >> one consistent rule that applies. >> >> -Joe >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > > -- > Trent Nadeau > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- Trent Nadeau
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
