I too agree that empty angle brackets are redundant because the information they convey is not useful enough to justify the syntax clutter. I would value clean syntax in this case more than explicitness and I think that would go along with Swift's philosophy. I would compare this to Swift's type inference where one can omit type information that's already known to the compiler in order to increase readability.
> 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. I think such cases would be extremely rare and one would have to be very ignorant about the types he/she works with. Additionally, that syntax is useful only for types with one generic argument. Say we have `Promise<T, E = Error>` and declare property as `let p: Promise<Int>`. How would you convey the information that there is a second argument that could be changed? Keeping the comma would be very ugly :) On Mon, Jan 23, 2017 at 8:51 PM, Sean Heber <[email protected]> wrote: > 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
