potential issues with default_val call

[phlptp]

In looking at #369. There are a few potential issues with using that function.

It actually evaluates the callback, which works perfectly fine if CLI11 is assigning to a variable or the callback is empty. In that context that is probably the correct thing to do. But if the callback was user specified this could result in very unexpected behavior such as repeat callbacks or oddly timed callbacks if there was user defined dependencies.

I am wondering if there needs to be a flag set up in the option definition that can discriminate between some of the CLI11 defined callbacks and user defined one and the function callback, so those user defined callbacks are not called at unexpected times.

Also wondering if default_val should be a template that can take any type(that can be converted to a string), so if you had an option taking an integer you could do

opt->default_val(5);

[henryiii]

We could add such a flag.

Yes, we could add a template to that function. I originally did not because I thought we were going to add a template to Option at some point; I'm now rather thinking we will not, since by avoiding (public) templated classes we can precompile and same some time.