<div dir="ltr"><div>I&#39;m looking into allowing extensions like &quot;extension Array where Element == Int&quot; — relaxing the restriction that prevents generic function/type definitions from having concrete types specified. (Slava mentioned that this is a favorable language change without need for the evolution process: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000865.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000865.html</a>)</div><div><br></div><div>I&#39;d like to run my thoughts by some people who know what they&#39;re talking about, before diving in too far :-)</div><div><br></div><div>The diagnostic in question is</div><div>    diag::requires_generic_param_made_equal_to_concrete</div><div>    &quot;same-type requirement makes generic parameter %0 non-generic&quot;</div><div>which is emitted from ArchetypeBuilder::addSameTypeRequirementToConcrete().</div><div><br></div><div>Multiple code paths reach checkGenericParamList() which adds the requirements:</div><div><br></div><div>    - DeclChecker::visitClassDecl</div><div>       -&gt; TC::validateDecl case for struct/class/enum</div><div>       -&gt; TC::validateGenericTypeSignature</div><div>       -&gt; TC::validateGenericSignature</div>







<div>       -&gt; TC::checkGenericParamList</div><div><br></div>







<div>    - DeclChecker::visitFuncDecl</div><div>       -&gt; TC::<span>validateGenericFuncSignature</span></div><div><span>       -&gt; TC::</span>checkGenericFuncSignature</div><div>       -&gt; TC::checkGenericParamList</div><div><br></div><div>    - DeclChecker::visitExtensionDecl</div><div>       -&gt; TC::validateExtension</div><div>       -&gt; TC::checkExtensionGenericParams</div><div>       -&gt; TC::validateGenericSignature</div><div>       -&gt; TC::checkGenericParamList</div><div>(Mildly confusing to have both &quot;validate&quot; and &quot;check&quot; variants, but only in some of the cases...?)</div>























































































<div><br></div><div>It&#39;s only in the 3rd case (extensions) that we want to allow the requirements to make the types fully bound/concrete. So here&#39;s what I propose doing:</div><div><br></div><div>  1. The ArchetypeBuilder needs to know whether this is allowed. So add a boolean field, called e.g. AllowConcreteRequirements.</div><div><br></div><div>  2a. Pass false to the ArchetypeBuilder created in validateGenericFuncSignature.</div><div>  2b. Pass the boolean through as a param to validateGenericSignature, where the ArchetypeBuilder is created. (validateGenericSignature is used in both class &amp; extension cases). In particular, pass true from checkExtensionGenericParams and false from validateGenericTypeSignature.</div><div><br></div><div>  3. Skip the error if AllowConcreteRequirements was true. Instead allow the requirement to be added (and fix any fallout issues from this change, add tests, yadda yadda).</div><div><br></div><div>How does that sound?</div><div><br></div><div>Also, is there any desire to remove this restriction?</div><div><span>    diag</span><span>::</span><span>extension_specialization</span></div><div>    &quot;constrained extension must be declared on the unspecialized generic type %0 with constraints specified by a &#39;where&#39; clause&quot;</div><div>It seems natural to want to allow &quot;extension Array&lt;Int&gt;&quot;, but I&#39;m afraid it may complicate things significantly, especially if we only wanted to allow this syntax in the case of .</div><br clear="all"><div><div><div dir="ltr"><div>Jacob Bandes-Storch<br></div></div></div></div>
</div>