You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently don't offer a good way to indicate that constructor binding should be used on a class that isn't under the users own control. See #18919 (comment) for details.
The text was updated successfully, but these errors were encountered:
We've discussed changing the logic again so that a @ConstructorBinding on a type indicates that any nested bind is also a candidate for constructor binding. To offer an escape hatch where constructor binding should not be used we could offer an exclude attribute.
It's not clear when someone would want to use exclude. Adding exclude would more often than not mean that setter binding should be attempted in which case a default constructor is required. Once there's a default constructor along with a parameterized constructor, constructor binding is automatically skipped because it checks for the presence of exactly one constructor that is parameterized. The exclude then does not provide any additional benefit. For this reason, we've decided not to rush into adding the exclude attribute till there is a solid use-case for it.
We currently don't offer a good way to indicate that constructor binding should be used on a class that isn't under the users own control. See #18919 (comment) for details.
The text was updated successfully, but these errors were encountered: