I've been thinking about this more, and I think extending generic type params could make sense in the future. For the sake of this PR however, I think it's reasonable to disallow for the time being. There's a lot of implementation and design space to think about for things like extension<T> T and extension<T: ProtoA> T: ProtoB.

Just some initial thoughts, but maybe we could add members of those extensions to name lookup as methods, but lower them as global functions that take a self parameter of T.

extension<T> T {
  // This is treated as a member at the type checker level.
  func abc() {}
}

let x = 3
x.abc() // ok

// T.abc() is lowered as
func abc<T>(_ self: T) {}

This is essentially "sugar", but you couldn't have both the member T.abc() and a global abc<T>(), unless we mangled them differently somehow. I'm sure there's more to design and develop there, but just some random thoughts :)

Rewriting existing conditional conformance syntax to use parameterized extensions breaks ABI. There's an additional A == A1 redundant requirement for something like:

extension<T: Equatable> SomeType: Equatable {}

Could we detect this and remove that redundant requirement to make switching between these two syntaxes ABI compatible? Do we even want that to be ABI compatible?

@slavapestov So, I've started adding test cases for type reconstruction and it seems the demangler can't reconstruct nested types. I've added the following to test/TypeDecoder/extensions.swift:

extension<T> Generic<T?> {
  struct Nested3 {}
}

which results in the following:

Failed to reconstruct type for $s10extensions7GenericVAAqd__SgRszlE7Nested3VyAD_GD
Original type:
(struct_type decl=extensions.(file).Generic extension.Nested3@swift/test/TypeDecoder/extensions.swift:50:10
  (parent=bound_generic_struct_type decl=extensions.(file).Generic@swift/test/TypeDecoder/extensions.swift:17:8
    (bound_generic_enum_type decl=Swift.(file).Optional
      (generic_type_param_type depth=1 index=0))))

I'm unsure if maybe it's mangling the nested type wrongly, or if maybe it's a demangling type issue? When I just demangle the symbol I get:

(extension in extensions):extensions.Generic<Swift.Optional<A1>><A where A == Swift.Optional<A1>>.Nested3

which for the most part looks correct, except the <Swift.Optional<A1>> part I'm a little suspect on because it should just be a plain <A1> no? Any help is greatly appreciated!

@slavapestov Hopefully I can explain this clearly, but the issue was that when we spun up a GSB in ASTDemangler we wouldn't ever add generic parameters that came from the extension. There wasn't enough information in the current mangling to deduce adding generic parameters, so I went ahead and mangled the full signature with parameterized extensions skipping any generic parameters from the nominal and adding the rest to GSB in ASTDemangler.

This is going to require a little bit more work.

struct Generic<T> {}

extension<U> Generic<U?> {
  struct Nested {
    let x: U
  }
}

TypeBase::getTypeOfMember treats x as having the following substitution map:

T -> T
U -> Optional<U>
// rather than
T -> Optional<U>
U -> U

This is due to the fact that U doesn't appear as a generic param in Generic<Optional<U>>.Nested. We could treat this nested type as Generic<Optional<U>>.Nested<U> to achieve the desired result, but I don't know if that's the correct fix.

I've also been thinking about the mangling. Maybe we could introduce a new mangling for extensions with added generic params that way we don't have to mangle the extended type's generic signature as well.

@DougGregor worked on the mangling for extension members most recently. Doug, can you offer some guidance here?

@slavapestov I've been having some difficulty pinpointing exactly where reflection fails for nested types. Is there a specific place or some general area you can recommend me looking into? I've been messing around for a while now in MetadataLookup and Demangle in the runtime, but I still can't seem to figure it out.

@jckarter I saw this little tidbit in MetadataLookup.cpp that you committed a while ago, could you explain what you mean by match up generic arguments? Also, could it be possible to do this without a new mangling? I ask because it would be great to be able to use this feature in older Swift versions, but I guess any runtime changes needed here kind of void that argument no? I actually played with a new mangling, e, but was unsure what to do about ObjC remangling because unconstrained extensions already used that mangling. Right now this just mangles the complete generic signature of the extension.

Sorry for all the questions (and mentions), but I've been trying to get this to work for a while now. I would really appreciate any advice that you can give!

The mangling of generic parameters currently relies on the extension having the same generic parameters as the extended type. If you have something like:

struct Foo<T> { struct Bar<U> { } }

extension Foo.Bar { }

then inside the extension context, T is mangled as depth=0 index=0 and U is mangled as depth=1 index=0. With a parameterized extension, you'd want to mangle generic parameters by following the signature declared on the extension, so if you had:

extension <A, B> Foo<B>.Bar<A> { ... }

then A would be depth=0 index=0 and B would be depth=0 index=1. I don't think we can accommodate this without new manglings and new runtime code.

then A would be depth=0 index=0 and B would be depth=0 index=1. I don't think we can accommodate this without new manglings and new runtime code.

These would be mangled as depth 2 no? Because inside the extension context we would still want to support T and U. E.g. <T><U><A, B> where T == A, U == B

You could model it that way, I suppose, but that seems like it adds additional complexity.

@davidungar I recently rebased against master and it appears that part of this is failing now due to AST scope lookup.

protocol SomeProto {}
struct Generic<T> {}
extension<U: SomeProto> Generic<U> {}

unqualified lookup in astscope is failing to resolve SomeProto that's hitting an assertion: could not find startingScope. (I tried with -disable-astscope-lookup and it passes). Any ideas on if I need to change something in astscope to fix this? Thanks!

@davidungar I recently rebased against master and it appears that part of this is failing now due to AST scope lookup.

protocol SomeProto {}
struct Generic<T> {}
extension<U: SomeProto> Generic<U> {}

unqualified lookup in astscope is failing to resolve SomeProto that's hitting an assertion: could not find startingScope. (I tried with -disable-astscope-lookup and it passes). Any ideas on if I need to change something in astscope to fix this? Thanks!

Chiming in: with the recent ASTScope changes, I think name lookup now uses source location ranges to find names in scope. We ran into the same could not find startingScope error with the @differentiable attribute, which can have a where clause: @differentiable(where T: Differentiable), similar to @_specialize attribute.

Our fix was to add ad-hoc ASTScope support for the @differentiable attribute: #27451. Parameterized extensions may need similar ASTScope support.

@dan-zheng thanks so much, will look into this!

I see--I hadn't been aware of this work.
You are trying to get ASTScopes working with a new feature!
I haven't thought about it much. How do you think the scoping ought to work?
Can there be multiple parameters? Is one visible to the previous one?
Can old-style generic parameters after that main parameter see the new parameters?
Happy to discuss it more, probably most productive for me to have a good, concrete description of what the scoping rules should be for this feature.

(Sorry about my initial misapprehension.) I try to always be half-expecting the next bug report:)

I hadn't considered the scoping rules for this admittedly too.

1. Can there be multiple parameters? Yes
2. Is one visible to the previous one? If you mean extension<T, U, V> where T can see U and V, then yes I believe they should be visible to eachother?
3. Can old-style generic parameters after that main parameter see the new parameters?

struct Generic<T> {}
extension<U> Generic<U?> // Is U visible to T? Yes it should be

I hope that I'm understanding this correctly, it's my first time understanding the code around astscoping and thinking about scoping this way.

These generic parameters act the same way generic parameters on a nested type act. E.g.

struct Generic0<T> {
  struct Generic1<U> where T == U? {
    // U can see T and T can see U, 
  }
}

What helps me think about scopes is to take an example and draw boxes around pieces of it, such that if A is visible from B, then B is in a box inside of A. I.e. the local variables of a function body are in a box corresponding to the curly braces, and that box is outside of a structure that the function is in. Hard to put into words, I hope it's clear.
Interestingly a few Swift features are "unboxable". For example a guard statement with a let creates a variable that is in-scope after the guard body, but not inside of it. So a new, "artificial" scope is required for after-a-guard in that case. There is even at least one case where the box topology required for the source-coordinate search cannot be made consistent with the topology required for Swift lookup rules.

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

• How to change the base branch: (Link)
• More detail about the branch update: (Link)

@Azoy Sorry for the ping, I see this is still open to this day; what is the status on this PR? :)