<div dir="ltr"><div style="font-size:12.800000190734863px"><div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">@doug:</span></div><div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap"><br></span></div><div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>struct X<T = Int> { }</div><div><br></div><div><span style="white-space:pre-wrap">> </span>func f1() -> X<Double> { return X() }</div><div><br></div><div><div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>func f2() -> X<Int> { return X() }</div><div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>func f2() -> X<Double> { return X() }</div><div><br></div><div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>func f3<T>(_: T) -> X<T> { return X() }</div><div><br></div></div><div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>let x1: X = f1() // okay: x1 has type X<Double>?</div><div><br></div><div>Agreed. When type is explicitly defined in the context, that type should override the default type. In this example type is explicitly defined by the return argument so we infer that type instead of using the default one.</div><div><br></div><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>let x2: X = f2() // ambiguous?</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">Uncertain. I might even lean to `X<Int>` because defining a property as `let x1: X` would be considered the same as defining it as `let x1: X<Int>`. In that case I would expect that the correct overload is inferable.</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px"><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>let x3a: X = f3(1.5) // okay: x3a has type X<Double>?</div><div style="font-size:12.800000190734863px"><span class="gmail-m_-6148505620800790337Apple-tab-span" style="white-space:pre-wrap">> </span>let x3b: X = f3(1) // okay: x3a has type X<Int>?</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">Agreed. These two are related to x1. Type is defined in the context (by inferring it from the literal) so it overrides the default argument.</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">I like the parallel with the default behaviour of literals - “if you can’t infer a particular type, fill in a default". We should aim for that.</div><div style="font-size:12.800000190734863px"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 9:18 PM, Srđan Rašić <span dir="ltr"><<a href="mailto:srdan.rasic@gmail.com" target="_blank">srdan.rasic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I too agree that <span style="font-size:12.800000190734863px">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.</span><span class=""><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">> </span><span style="font-size:12.800000190734863px">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.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div></span><div><span style="font-size:12.800000190734863px">I think such cases would be extremely rare and </span><span style="font-size:12.800000190734863px">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 :)</span></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 8:51 PM, Sean Heber <span dir="ltr"><<a href="mailto:sean@fifthace.com" target="_blank">sean@fifthace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree. I don’t think empty angle brackets convey anything useful to the reader.<br>
<br>
l8r<br>
<span class="m_410144728359289927HOEnZb"><font color="#888888">Sean<br>
</font></span><div class="m_410144728359289927HOEnZb"><div class="m_410144728359289927h5"><br>
<br>
> On Jan 23, 2017, at 1:25 PM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
> On Mon, Jan 23, 2017 at 1:41 PM, Trent Nadeau via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> 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.).<br>
><br>
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> Hi Everyone,<br>
>>><br>
>>> I've opened a PR (<a href="https://github.com/apple/swift-evolution/pull/591" rel="noreferrer" target="_blank">https://github.com/apple/swif<wbr>t-evolution/pull/591</a>) proposing default generic arguments which I think would be nice addition to the language. They are also mentioned in "Generic manifesto".<br>
>>><br>
>>> 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.<br>
>><br>
>> The proposal looks fairly straightforward and reasonable. One thing to think about is how it interacts with type inference. For example, consider these examples:<br>
>><br>
>> struct X<T = Int> { }<br>
>><br>
>> func f1() -> X<Double> { return X() }<br>
>><br>
>> func f2() -> X<Int> { return X() }<br>
>> func f2() -> X<Double> { return X() }<br>
>><br>
>> func f3<T>(_: T) -> X<T> { return X() }<br>
>><br>
>> let x1: X = f1() // okay: x1 has type X<Double>?<br>
>> let x2: X = f2() // ambiguous?<br>
>> let x3a: X = f3(1.5) // okay: x3a has type X<Double>?<br>
>> let x3b: X = f3(1) // okay: x3a has type X<Int>?<br>
>><br>
>> 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.<br>
>><br>
>> Thanks for working on this!<br>
><br>
> 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.<br>
><br>
> -Joe<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Trent Nadeau<br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>