<div dir="ltr">Painful +1.<div><br></div><div>I use the first one a whole lot in a project and it is going to get ugly.  That said… I can see how it is tricky in a way that doesn&#39;t really pay off for most people. Removing the first feature might even be necessary for what I hope will ease the ugly. I don&#39;t see &quot;Default generic arguments&quot; being easy to reason about alongside the first feature.</div><div><br></div><div>TJ</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 11, 2016 at 9:30 PM, Robert Widmann via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1.  I don&#39;t use this feature at all and (by extension) don&#39;t think there are many situations where it&#39;s useful.<br>
<br>
~Robert Widmann<br>
<br>
2016/10/11 18:03、Slava Pestov via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; のメッセージ:<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; I could if there’s interest. Since we intend on maintaining source compatibility, it will not result in a simpler implementation, though, since we’ll need to keep the old code path around for Swift 3 mode. Still worth it?<br>
&gt;<br>
&gt; Slava<br>
&gt;<br>
&gt;&gt; On Oct 11, 2016, at 1:58 PM, Pyry Jahkola &lt;<a href="mailto:pyry.jahkola@iki.fi">pyry.jahkola@iki.fi</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I was reminded of this proposal which seems like an obvious win in clarity. Still planning to submit it, Slava?<br>
&gt;&gt;<br>
&gt;&gt; ― Pyry<br>
&gt;&gt;<br>
&gt;&gt;&gt; On 28 Jun 2016, at 21:13, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; on Thu Jun 23 2016, Slava Pestov &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Simpler interpretation of a reference to a generic type with no<br>
&gt;&gt;&gt;&gt; arguments<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Proposal: SE-9999<br>
&gt;&gt;&gt;&gt; &lt;<a href="https://github.com/slavapestov/swift-evolution/blob/silly-proposals/proposals/9999-simplify-unbound-generic-type.md" rel="noreferrer" target="_blank">https://github.com/<wbr>slavapestov/swift-evolution/<wbr>blob/silly-proposals/<wbr>proposals/9999-simplify-<wbr>unbound-generic-type.md</a>&gt;<br>
&gt;&gt;&gt;&gt; Author: Slava Pestov &lt;<a href="https://github.com/slavapestov" rel="noreferrer" target="_blank">https://github.com/<wbr>slavapestov</a>&gt;<br>
&gt;&gt;&gt;&gt; Status: Awaiting review<br>
&gt;&gt;&gt;&gt; Review manager: TBD<br>
&gt;&gt;&gt;&gt; &lt;<a href="https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#introduction" rel="noreferrer" target="_blank">https://github.com/<wbr>slavapestov/swift-evolution/<wbr>tree/silly-proposals/<wbr>proposals#introduction</a>&gt;<wbr>Introduction<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This proposal cleans up the semantics of a reference to a generic type<br>
&gt;&gt;&gt;&gt; when no generic arguments are applied.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Swift-evolution thread: Discussion thread topic for that proposal<br>
&gt;&gt;&gt;&gt; &lt;<a href="http://news.gmane.org/gmane.comp.lang.swift.evolution" rel="noreferrer" target="_blank">http://news.gmane.org/gmane.<wbr>comp.lang.swift.evolution</a>&gt;<br>
&gt;&gt;&gt;&gt; &lt;<a href="https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#motivation" rel="noreferrer" target="_blank">https://github.com/<wbr>slavapestov/swift-evolution/<wbr>tree/silly-proposals/<wbr>proposals#motivation</a>&gt;<wbr>Motivation<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Right now, we allow a generic type to be referenced with no generic<br>
&gt;&gt;&gt;&gt; arguments applied in a handful of special cases. The two primary rules<br>
&gt;&gt;&gt;&gt; here are the following:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; If the scope from which the reference is made is nested inside the<br>
&gt;&gt;&gt;&gt; definition of the type or an extension thereof, omitting generic<br>
&gt;&gt;&gt;&gt; arguments just means to implicitly apply the arguments from context.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; For example,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; struct GenericBox&lt;Contents&gt; {<br>
&gt;&gt;&gt;&gt; let contents: Contents<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; // Equivalent to: func clone() -&gt; GenericBox&lt;Contents&gt;<br>
&gt;&gt;&gt;&gt; func clone() -&gt; GenericBox {<br>
&gt;&gt;&gt;&gt;  return GenericBox(contents: contents)<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; extension GenericBox {<br>
&gt;&gt;&gt;&gt; func print() {<br>
&gt;&gt;&gt;&gt;  // Equivalent to: let cloned: GenericBox&lt;Contents&gt;<br>
&gt;&gt;&gt;&gt;  let cloned: GenericBox = clone()<br>
&gt;&gt;&gt;&gt;  print(cloned.contents)<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt; If the type is referenced from an unrelated scope, we attempt to infer<br>
&gt;&gt;&gt;&gt; the generic parameters.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; For example,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; func makeABox() -&gt; GenericBox&lt;Int&gt; {<br>
&gt;&gt;&gt;&gt; // Equivalent to: GenericBox&lt;Int&gt;(contents: 123)<br>
&gt;&gt;&gt;&gt; return GenericBox(contents: 123)<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt; The problem appears when the user expects the second behavior, but<br>
&gt;&gt;&gt;&gt; instead encounters the first. For example, the following does not type<br>
&gt;&gt;&gt;&gt; check:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; extension GenericBox {<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; func transform&lt;T&gt;(f: Contents -&gt; T) -&gt; GenericBox&lt;T&gt; {<br>
&gt;&gt;&gt;&gt;  // We resolve &#39;GenericBox&#39; as &#39;GenericBox&lt;Contents&gt;&#39;, rather than<br>
&gt;&gt;&gt;&gt;  // inferring the type parameter<br>
&gt;&gt;&gt;&gt;  return GenericBox(contents: f(contents))<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt; &lt;<a href="https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#proposed-solution" rel="noreferrer" target="_blank">https://github.com/<wbr>slavapestov/swift-evolution/<wbr>tree/silly-proposals/<wbr>proposals#proposed-solution</a>&gt;<wbr>Proposed<br>
&gt;&gt;&gt;&gt; solution<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The proposed solution is to remove the first rule altogether. If the<br>
&gt;&gt;&gt;&gt; generic parameters cannot be inferred from context, they must be<br>
&gt;&gt;&gt;&gt; specified explicitly with the usual Type&lt;Args...&gt; syntax.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; SGTM.  I&#39;ve always found this shorthand to be somewhat surprising,<br>
&gt;&gt;&gt; including in C++ where (IIUC) it originated.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; Dave<br>
&gt;&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>