Vicente BOTET <vicente.botet <at> wanadoo.fr> writes: ...
template <> default_value { static example apply() { return example(3); } };
quite bothersome as I know I really do not have to. In the original wacky design the fallback and the default were synonyms. Now you are introducing an additional piece of machinery/code that is needed to deploy a class with conversion and I have to provide the default and the fallback. With that in mind I am not sure I am personally warming up for default_value concept yet.
I was not talking here of the fallback.
Note that you don't need to do that for the classes having a default constructor, which are most of them.
Vicente, If I were proposing something for a potentially wide user-base, then I'd personally be probably cautious with "most of them" statements. The classes you happen to write/come across might indeed have default constructors. My projects do not. In fact, only a small fraction of (relatively low-level) classes will have default constructors. Our classes happen to be quite complex and require parameters to be created. Those classes cannot be instantiated with default constructors. One could argue that the default constructor *could* be still provided for those classes by creating invalid instances. I argue that that's a bad idea as from the design perspectives that code pollution to work around limitations of some other library. Even simple classes do not often have default constructors. Take the example from my 'convert' documentation -- the direction class with up and dn values. What do you consider the default constructor would do? Or you'd suggest introducing another 'not-defined' state just to be user in the default constructor? Then, it'll have far-reaching ripples through all the code as now I never know if my direction object is valid or not and, therefore, have to always write error-prone "if (dir != undefined) proceed". V.