It is an anti-pattern to rely on an implicit default constructor in a
publicly exported class in a library. There are (at least) three good
reasons to avoid this:
1. The default constructor will have no API docs
2. You could end up with a public constructor in a class where you don't
want a publicly visible constructor, for example a class with factory
methods.
3. In a class where you do intend a public constructor, if you later add
another constructor with an argument, it will have the effect of
removing the default one, which is an incompatible API change.
-- Kevin
On 9/16/2020 11:53 PM, Peter Hull wrote:
Just for my curiosity, what issues can arise relying on default
constructors? I couldn't find anything with google (apart from links
back to these messages!)
Thanks,
Peter
