<div dir="ltr"><div>I'm looking into allowing extensions like "extension Array where Element == Int" — 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'd like to run my thoughts by some people who know what they'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> "same-type requirement makes generic parameter %0 non-generic"</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> -> TC::validateDecl case for struct/class/enum</div><div> -> TC::validateGenericTypeSignature</div><div> -> TC::validateGenericSignature</div>
<div> -> TC::checkGenericParamList</div><div><br></div>
<div> - DeclChecker::visitFuncDecl</div><div> -> TC::<span>validateGenericFuncSignature</span></div><div><span> -> TC::</span>checkGenericFuncSignature</div><div> -> TC::checkGenericParamList</div><div><br></div><div> - DeclChecker::visitExtensionDecl</div><div> -> TC::validateExtension</div><div> -> TC::checkExtensionGenericParams</div><div> -> TC::validateGenericSignature</div><div> -> TC::checkGenericParamList</div><div>(Mildly confusing to have both "validate" and "check" variants, but only in some of the cases...?)</div>
<div><br></div><div>It's only in the 3rd case (extensions) that we want to allow the requirements to make the types fully bound/concrete. So here'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 & 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> "constrained extension must be declared on the unspecialized generic type %0 with constraints specified by a 'where' clause"</div><div>It seems natural to want to allow "extension Array<Int>", but I'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>