[swift-dev] Allowing extensions of bound generic types

Jacob Bandes-Storch jtbandes at gmail.com
Wed Dec 9 04:00:43 CST 2015


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:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000865.html
)

I'd like to run my thoughts by some people who know what they're talking
about, before diving in too far :-)

The diagnostic in question is
    diag::requires_generic_param_made_equal_to_concrete
    "same-type requirement makes generic parameter %0 non-generic"
which is emitted from ArchetypeBuilder::addSameTypeRequirementToConcrete().

Multiple code paths reach checkGenericParamList() which adds the
requirements:

    - DeclChecker::visitClassDecl
       -> TC::validateDecl case for struct/class/enum
       -> TC::validateGenericTypeSignature
       -> TC::validateGenericSignature
       -> TC::checkGenericParamList

    - DeclChecker::visitFuncDecl
       -> TC::validateGenericFuncSignature
       -> TC::checkGenericFuncSignature
       -> TC::checkGenericParamList

    - DeclChecker::visitExtensionDecl
       -> TC::validateExtension
       -> TC::checkExtensionGenericParams
       -> TC::validateGenericSignature
       -> TC::checkGenericParamList
(Mildly confusing to have both "validate" and "check" variants, but only in
some of the cases...?)

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:

  1. The ArchetypeBuilder needs to know whether this is allowed. So add a
boolean field, called e.g. AllowConcreteRequirements.

  2a. Pass false to the ArchetypeBuilder created in
validateGenericFuncSignature.
  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.

  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).

How does that sound?

Also, is there any desire to remove this restriction?
    diag::extension_specialization
    "constrained extension must be declared on the unspecialized generic
type %0 with constraints specified by a 'where' clause"
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 .

Jacob Bandes-Storch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151209/e0186914/attachment.html>


More information about the swift-dev mailing list