Jakub Vano

:smile: completely forgot to link it. This one: https://github.com/terhechte/appventure-blog/blob/master/resources/posts/2016-04-04-prevent-accidental-test-code-commits.org

Thanks for the report 👍, will try to look at it.

When sharing instances during multiple resolutions, only types of the arguments are taken into consideration, not their actual values - in your example instances are shared in the default `.graph`...

This should work properly in current implementation of 3.0 API, see [this](https://github.com/Swinject/Swinject/blob/3.0/Tests/3.0%20API/SingletonSpec.swift#L49) and [this](https://github.com/Swinject/Swinject/blob/3.0/Tests/3.0%20API/SingletonSpec.swift#L58) However I'm not sure if it is feasible to backport this into 2.0 API - it...

In what usecase does the language version matter? AFAIK as long as all modules are compiled with the same version of the compiler, swift version should not matter - i.e....

Can you provide some code example of how are you registering / resolving / resetting those objects?

Do some other objects keep references to the webview? `resetObjectScope` does not immediately destroy the object - just throws away the reference that is kept internally in the `Container`.

@AnthonyMillerSF Best approach seems to be to make API methods throwable by default - from that it is easy to do `try? resolve()` or `try! resolve()`. That should seamlessly handle...

Current implementation of the 3.0 API should support all these scenarios: - [optionals resulting in value](https://github.com/Swinject/Swinject/blob/3.0/Tests/3.0%20API/OptionalsSpec.swift#L16) - [optionals resulting in nil](https://github.com/Swinject/Swinject/blob/3.0/Tests/3.0%20API/OptionalsSpec.swift#L22) - [throwing initializers](https://github.com/Swinject/Swinject/blob/3.0/Tests/3.0%20API/InjectionSpec.swift#L32)

You are correct, we should strive for the semantic versioning - breaking the `ServiceKeyOption` was an oversight 😞 Apologies for any inconveniences.