[swift-evolution] Default Generic Arguments

[Srđan Rašić]

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 <sean at fifthace.com> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
> >
> >> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >>
> >>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
> swift-evolution at swift.org> 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
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> >
> >
> > --
> > Trent Nadeau
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170123/f6d1d180/attachment.html>