[swift-evolution] Default Generic Arguments

[Trent Nadeau]

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 <milseman at apple.com> wrote:

>
> On Jan 23, 2017, at 10:41 AM, 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.
>
>
> 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 <
> 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
>
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170123/5c3bd301/attachment.html>