Sorry, I missed that this was added. Curious, given I was one of the folks that brought up the rationale for it 
. I would mention that @unchecked doesn't affect synthesized code, it just indicates that you know what you are doing to suppress an error.
How do you mean? The scenario I was referring to is something like a packed struct. For instance something with the following API:
struct CustomLayout {
let x: Int8
let y: Int16
let z: Int8
}
but a memory layout of 8 bits of x, immediately followed by 16 bits of y, immediately followed by 8 bits of z, resulting in a 32 bit value. I'm pretty sure the Swift compiler would add padding in this case due to memory alignment, but this type should be representable in Swift and be able to participate in structural reflection. I brought up Capnproto because this will be common in binary serialization formats like Capnp and Protobuf. This makes me think that a Structural protocol and a customization point for modifying its behavior is the right balance. On the other hand, I'm realizing that allowing arbitrary customization of this behavior could make it very difficult to optimize the resulting code.
I basically picked it out of a hat. The only thing I wanted to convey was that it was for more than just building conformances.
This bit of the system still feels very awkward and special-cased to me, as it basically gives us another flavor of extension but with new semantics and a different self. If all you need is the builder's product, we could just allow you to get at that with a statement (like my unfortunately-spelt @EquatableConformanceBuilder var comparator: EquatableConformanceBuilder<Self>.Comparator). This would also allow the same semantics to be used outside of synthesizing a conformance (for example, at the top level in a main.swift).