Alternative implementation of StaticStructural

[shabalind]

This PR proposes an alternative implementation of StaticStructural from #9:

• We add KeyPaths and BaseType to the structural representations.
• StaticStructural is implemented as a regular structural of a zero value.
• Additionally, as an example we show how implement allKeyPaths on top of it.

In contrast to #9 this approach does not require duplication of the API to provide new representation types for static counterparts.

[shabalind]

Runtime performance is degraded up to 10x in some cases due to addition of KeyPaths. It's unclear how much effort will it take to bring it back down while preserving KeyPaths in the API.

[shabalind]

Due to the fact that we don't hide property wrapper types, unlike KeyPaths we need to have 2 type parameters for value: one for wrapped and another for unwrapped value. This has unfortunate an unpleasant complexity cost.

[shabalind]

/cc @dabrahams

[shabalind]

It looks like we can't get name out of KeyPath in a portable manner (there is a macOS-only solution that relies on NSExpression). This is intended because KeyPaths can express arbitrary multi-step field accesses.

What's even more unsettling is that we use StructuralProperty for both StructuralStruct properties and StructuralEnum associated values. Associated values don't work with KeyPaths at all, so if we unify this even further by removing name, we'll have to add yet another structural representation type StructuralAssociatedValue which is nearly identical to StructuralProperty, only with a name instead of keyPath.

[saeta]

Nice work here @shabalind ! Thanks for this PR. I think this is really good, and probably better than having a doubling of the API surface. That said, some of the more interactions with KeyPaths (in particular WrappedValue) are quite unfortunate.

[saeta]

Why is type Optional<BaseType.Type> and not simply BaseType.Type? (Note: I realize this was the case before your change too.)

[shabalind]

If you look at implementation of Zero we need to be able to create an instance StructuralStruct based on known type parameters only.

[saeta]

But don't we now have BaseType? Couldn't we do something like:

extension StructuralStruct: Zero where Properties: Zero {
    public static var zero: Self {
        return StructuralStruct(type: BaseType.self, Properties.zero)
    }
}

[saeta]

Please document Value vs WrappedValue. (I only understood the distinction when looking through the examples and seeing one using property wrappers.)

Agreed that this is some unfortunate complexity. :-(

[shabalind]

Added comment in b20fb72

[saeta]

What about:

Suggested change

	func collectKeyPaths(into keyPaths: inout [AnyKeyPath])
	func collectKeyPaths(into keyPaths: inout [PartialKeyPath<Self>])

or:

Suggested change

	func collectKeyPaths(into keyPaths: inout [AnyKeyPath])
	associatedtype BaseType
	func collectKeyPaths(into keyPaths: inout [PartialKeyPath<BaseType>])

?

[shabalind]

This complicated implementation of _CollectKeyPath because we don't have BaseType for StructuralCons and StructuralEmpty. Adding them just for this use case seems like a massive overkill.

[saeta]

Agreed that adding BaseType to StructuralCons doesn't make sense (although it can likely be conditionally inferred with the "BaseTypeProtocol" I've used in related PRs), and StructuralEmpty of course "should" be Never which neatly solves that problem.

I say "should" because I'm not sure how I feel about it yet. While it has some aspect of feeling more regular, I'm not sure it substantially simplifies use of SGP in practice. But this is only a weak prior.

[saeta]

Note: seems like we've fallen off an optimizer performance cliff. :-(

[shabalind]

This has been an interesting experiment, but we decided to postpone this for now. We might revisit it later.