<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Tony,<div class=""><br class=""></div><div class="">So if my understanding is correct, the basic proposal is the following:</div><div class=""><br class=""></div><div class="">func id&lt;T&gt;(t: T ?= T.defaultValue) { return t }</div><div class=""><br class=""></div><div class="">extension Int { static var defaultValue = 0 }</div><div class=""><br class=""></div><div class="">extension String { static var defaultValue = “” }</div><div class=""><br class=""></div><div class="">id() as Int // returns 0</div><div class=""><div>id() as String // returns “”</div><div>id() as SomeRandomType // fails to type check — no default argument</div><div><br class=""></div><div>I don’t understand what would happen if the caller is itself generic though, for example:</div><div><br class=""></div><div>callsID&lt;T&gt;(_ t: T) {</div><div>&nbsp; _ = id() as T</div><div>}</div><div><br class=""></div><div>It appears that body of callsID() itself cannot type check without knowledge of the concrete T that will be used with this function.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 27, 2017, at 4:10 PM, Tony Allevato via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I totally agree that that's a good rule in general—I'm not 100% comfortable making an exception to it for this, but I wanted to start a discussion about a different approach than had been considered so far.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The idea of forcing the user to acknowledge the explicitness of SFINAE with a strawman syntax `=?` instead of `=` was a thought experiment to bridge the wild-west-C++ world of templates and Swift's stricter generics, but I can definitely understand if even that kind of approach is something that the core team (who are far more familiar with the C++ side of that coin than I am) doesn't wish to support. As was pointed out, it's not something Swift supports anywhere else today.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If we look at it from that point of view, where such a semantic treatment of generics would not be supported, I think it becomes a lot harder to rationalize treating this as "default arguments". What you really do have (and what writing it as constrained extensions makes clear) is additional overloads, because they only apply to certain subsets of types. If that's the case, maybe it's the wrong approach to try to turn overloads into "partial default values".</div></div></blockquote></div><br class=""></div></body></html>