Thomas Grapperon

Thanks for the PR @maximkrouk! I'm a little wary about the additional complexity `DependencyKeys` may introduce. A `DependencyKey` can be completely private and defined on the spot before implementing the...

Thanks @maximkrouk! I'm working on some consequent refactor of the library. Basically, the user will have two choices: `ComposableEnvironment` with some `SwiftUI`-like inheritance, and `GlobalEnvironment` with shared global access to...

@maximkrouk I've pushed the `value-type` branch as a first draft, so you can get more precise answers. But yes, if all the dependencies are global, the environment can be empty....

> I liked the option to override dependencies in the ComposableEnvrionment Then you can still use `ComposableEnvironment`! In order to store the eventual overrides mid-chain in a convenient way, *all*...

> I see you pushed DependencyAliases, that fixes my concern from the prev reply, I guess I think so too. It is still recommended to use some top-level definitions, but...

I'll soon push `GlobalDependencies` and aliases on `main`. I've rewritten the README almost totally. There is no example in it because I knew you had a nice one ready to...

Hello @maximkrouk, thanks for the PR. As I understand it, you don't need the method to be public anymore thanks to the overload you're showing for `.recursive` with `LocalEnvironment: ComposableEnvironment`....

Thanks for the PR @dankinsoid! While I agree that the current way to define dependencies is a little verbose, I have some reservations about these changes. There are two proposed...

As a fair amount of the code of this library is unsafe, and at the light of this issue, I wonder if it wouldn't be better to defensively test optimized...

Making one of the enums `indirect` seems to be another workaround.