I think the issue arises from the condition if (rvalue->getType() == destTL.getLoweredType()) inside SILGenFunction::emitSemanticStore(). When the member (destination) in question is of a generic parameter type, this returns false, even though the types "should" be the same (I think—because their getString() returns the same string, such as $*Optional<Value>).

cc @slavapestov who might have some chance at fixing this. I think checkExtensionGenericParams may need to be modified so that the extension uses the same archetype(s) as its extended type, but I'm not sure how to do that.

Extensions have different archetypes than the extended type. I think the problem is that the archetype from the context of the type should not be showing up in the SIL at all. I'll take a look.

We cannot just re-use original archetypes in the extension, because it might have a different set of generic parameters, eg 'extension SomeClass where T.AssocType == Int'.

The pattern initializer expression is always written in terms of the original archetypes, and SILGen just blindly emits it into the constructor, even if the constructor is in a different context.

What we need to do is emit each initializer into its own SIL function, with a new kind of SILDeclRef to refer to pattern initializer functions. Extension initializers will then call these functions instead of directly emitting the expression in the initializer.

This function will have a generic signature and interface type, and re-use the original archetypes from the containing declaration. When called from an extension, the right substitutions will be used.

My knowledge of this is limited, but shouldn't the extension have awareness of the extended type's archetypes too? Shouldn't it be possible to simply enumerate the members that are being initialized, and emit the initializers with correct knowledge of the type of the member (which, as you said, may be less constrained than the extension's own archetypes)?

Joe also mentioned there's an orthogonal issue – we need Sema diagnostics to ban extensions from adding designated initializers outright, if any of these are true:

• if the extension is in a different file than the original type and the original type has private members

• if the extension is in a different module than the original type and the original type has internal members

• if the extension is in a different module than the original type is resilient

Archetypes are specific to a given scope (more precisely, a DeclContext). a SILFunction's body can only use archetypes from that context, because SIL and IRGen rely extensively on the pointer identity of archetypes making sense.

The problem is that initializers are arbitrary Exprs, so unless we rework all of SILGen to remap types arbitrarily, it won't work in the general case.

Putting initializers in their own function makes sense for other reasons too. We've had bugs in the past with closures and such crashing in initializer expressions because of bits of SILGen not being set up to emit Exprs more than once.

Emitting the initializer expression once in its own function associated with the original type is the sanest fix.

An analogous situation exists with default argument initializers – take a look at how we emit those, and how they're handled in type lowering and SILDeclRefs, etc.

Jacob, if you wanted to take this on, I'd be happy to help in any way I can! 🙂

Fixed in #3949