<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 2:41 PM, Michael Ilseman <span dir="ltr"><<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 23, 2017, at 10:41 AM, Trent Nadeau via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-6875159637355054327Apple-interchange-newline"><div><div dir="ltr">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. </div></div></blockquote><div><br></div></span><div>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?</div><div><div class="h5"><br><blockquote type="cite"><div><div dir="ltr">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.).</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>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:</div><br class="m_-6875159637355054327m_2740357066933401872Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>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:</div><br class="m_-6875159637355054327m_2740357066933401872Apple-interchange-newline"><div><div dir="ltr">Hi Everyone,<div><br></div><div>I've opened a PR (<a href="https://github.com/apple/swift-evolution/pull/591" target="_blank">https://github.com/apple/swif<wbr>t-evolution/pull/591</a>) proposin<wbr>g default generic arguments which I think would be nice addition to the language. They are also mentioned in "Generic manifesto". </div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>The proposal looks fairly straightforward and reasonable. One thing to think about is how it interacts with type inference. For example, consider these examples:</div><div><br></div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>struct X<T = Int> { }</div><div><br></div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>func f1() -> X<Double> { return X() }</div><div><br></div><div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>func f2() -> X<Int> { return X() }</div><div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>func f2() -> X<Double> { return X() }</div></div><div><br></div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>func f3<T>(_: T) -> X<T> { return X() }</div><div><br></div></div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>let x1: X = f1() // okay: x1 has type X<Double>?</div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>let x2: X = f2() // ambiguous?</div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>let x3a: X = f3(1.5) // okay: x3a has type X<Double>?</div><div><div><span class="m_-6875159637355054327m_2740357066933401872Apple-tab-span" style="white-space:pre-wrap"> </span>let x3b: X = f3(1) // okay: x3a has type X<Int>?</div><div><br></div>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.</div><div><br></div><div>Thanks for working on this!</div></div></div></blockquote><br></div></span><div>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.</div><div><br></div><div>-Joe</div><br></div><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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-6875159637355054327gmail_signature" data-smartmail="gmail_signature">Trent Nadeau</div>
</div>
______________________________<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" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div></div></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Trent Nadeau</div>
</div>