I agree. I don’t think empty angle brackets convey anything useful to the reader.
l8r Sean > On Jan 23, 2017, at 1:25 PM, T.J. Usiyan via swift-evolution > <[email protected]> wrote: > > I am against requiring empty angle brackets. I could live with it either way, > but I think that one reason to provide default types is to hide the detail > that there is a type parameter until such a time as it is needed. Empty > angle brackets call attention to the feature in a manner that discards any > possible gains on this front. Empty angle brackets would be confusing to > explain to someone new to the language and–more importantly–shouldn't be > necessary to explain in the "falling back to defaults" case. > > On Mon, Jan 23, 2017 at 1:41 PM, 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. 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 > > > _______________________________________________ > 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
