# Help debugging equal-but-unequal archetypes in SILGen/emitMemberInitializers

**URL:** <https://forums.swift.org/t/help-debugging-equal-but-unequal-archetypes-in-silgen-emitmemberinitializers/1098>\
**Category:** Compiler\
**Created:** [January 17, 2016, 2:44am UTC](https://forums.swift.org/t/help-debugging-equal-but-unequal-archetypes-in-silgen-emitmemberinitializers/1098 "2016-01-17T02:44:10Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jtbandes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jtbandes/32/463_2.png) [@jtbandes](https://forums.swift.org/u/jtbandes)\
**Post date:** [January 17, 2016, 2:44am UTC](https://forums.swift.org/t/help-debugging-equal-but-unequal-archetypes-in-silgen-emitmemberinitializers/1098/1 "2016-01-17T02:44:10Z")

</div>

I started taking a look at SR-493 \<[Issues · apple/swift-issues · GitHub](https://bugs.swift.org/browse/SR-493&gt;),  
which is triggered with this code:

&nbsp;&nbsp;&nbsp;&nbsp;struct Foo\<G\> { var l1: G? }  
&nbsp;&nbsp;&nbsp;&nbsp;extension Foo { init(x: Int) { } }

It turns out that for the init in the extension,  
SILGenFunction::emitSemanticStore is being called with src & dest types  
which \*should\* be the same, but aren't, so it goes down the wrong code path.

This is for the implicit initialization, which looks to be effectively  
"self.l1 = { Optional\<G\>(nilLiteral: ()) }()"

(lldb) p \*rvalue\*  
.getType().getSwiftType()-\>getInOutObjectType()-\>getOptionalObjectType()  
(swift::Type) $191 = {  
&nbsp;&nbsp;Ptr = 0x000000010d0a28d8  
}  
(lldb) p \*dest\*  
.getType().getSwiftType()-\>getInOutObjectType()-\>getOptionalObjectType()  
(swift::Type) $192 = {  
&nbsp;&nbsp;Ptr = 0x000000010b00dd68  
}

But these types "look" the same (they are both the archetype for G):

(lldb) p \*rvalue\*  
.getType().getSwiftType()-\>getInOutObjectType()-\>getOptionalObjectType()-\>getString(PrintOptions::printEverything())  
(std::\_\_1::string) $201 = "G"  
(lldb) p \*dest\*  
.getType().getSwiftType()-\>getInOutObjectType()-\>getOptionalObjectType()-\>getString(PrintOptions::printEverything())  
(std::\_\_1::string) $202 = "G"

Now I'm stuck. This is my first attempt to understand anything in SILGen,  
but I think the problem might trace back to Sema. Why would it end up with  
different Archetypes? Perhaps because the generic params are cloned  
\<[swift/TypeChecker.cpp at c794609d29f85c76c7a6b1aba81b99cd213fd721 · apple/swift · GitHub](https://github.com/apple/swift/blob/c794609d29f85c76c7a6b1aba81b99cd213fd721/lib/Sema/TypeChecker.cpp#L333&gt);  
for  
the extension decl?

Or a better question: is there a more correct way of comparing these types  
for the purpose of emitSemanticStore than simply by pointer equality  
\<[swift/SILType.h at c794609d29f85c76c7a6b1aba81b99cd213fd721 · apple/swift · GitHub](https://github.com/apple/swift/blob/c794609d29f85c76c7a6b1aba81b99cd213fd721/include/swift/SIL/SILType.h#L526&gt);  
?

Thanks,  
Jacob