[swift-evolution] Default Generic Arguments

[T.J. Usiyan]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170123/2382ef27/attachment.html>