View/environment modifier, support for both EnvironmentValues and EnvironmentKey (used for custom storage in the environment)

[MiaKoring]

This PR adds:

• EnvironmentValues/with(key:, value:) //equivalent to with(keyPath: newValue:) but for non-builtin values
• view modifiers for both builtin (key path) and not builtin (EnvironmentKey) values

For demonstration and testing purposes I changed GreetingGeneratorExample’s latest greeting display to get its value over an environment key.

The @Environment property wrapper was changed to additionally support EnvironmentKeys.

I did some limited testing which worked like expected. The modifiers just use the EnvironmentModifier View just like we do with most other modifiers.

[stackotter]

Thanks for these changes! They will make working with custom environment values much easier.

While reviewing the PR, I googled stuff about SwiftUI's environment modifiers, and I found that SwiftUI works around the distinction between custom keys and builtin environment properties (keypaths) by instructing users to extend EnvironmentValues with their own custom properties that utilise the environment key. Your implementation doesn't stop users from taking that approach, but I'm wondering whether we should try to push users towards the SwiftUI approach, or instead let them choose.

I was leaning towards letting users choose because it makes defining custom environment values very simple (just define the key). However, I realised that having these two different types of environment properties makes it tricky for libraries to provide methods that are generic over environment properties, because they would need to vend two separate (but very similar) methods for each abstraction.

For that reason, I think that it's probably best to not have the environment key based methods? But I'm open to discussion on that.

[stackotter]

Add a newline after this.

[stackotter]

Add a doc comment along the lines of /// This intermediate view exists to show the usage of custom environment keys. In reality it is not necessary. so that future readers don't get too confused.

[stackotter]

Rename to LatestGreetingKey to make its usage more self-evident.

[stackotter]

Rename to LatestGreetingDisplay for clarity.

[stackotter]

Introduce an enum to encode the requirement that we want one property or the other to be non-nil (not neither, and not both). This enum would just be an internal detail.

enum EnvironmentLocation<Value> {
    case keyPath(KeyPath<EnvironmentValues, Value>)
    case environmentKey(any EnvironmentKey.Type)
}

You can then replace these two properties with a single var location: EnvironmentLocation<Value> property, and then replace the existing if lets with switch statements.

[stackotter]

I've thought about how to avoid this force unwrap a little bit, and it seems like we can make Value a primary associated type of EnvironmentKey, and then update the environmentKey property to have type any EnvironmentKey<Value>.Type. This should make things a bit safer, and appears to be a backwards compatible change (because users of EnvironmentKey aren't forced to use the primary associated type syntax)?

I had to Google the syntax, so I figured I might as well include it here. To make Value a primary associatetype do the following;

protocol EnvironmentKey<Value> {
    associatedtype Value
    ...
}

[stackotter]

Give the parameters each the underscore label to match the keypath variant (and rename value to newValue)

[stackotter]

Remove the parameter labels to match the following method, and rename value to newValue