Re: [lmi] Default values for default arguments

[Greg Chicares]

[quoting the original in full because I only want to add one more
question, and it may be easier to reply only to this message]

On 2017-02-11 10:16, Greg Chicares wrote:
> On 2017-02-10 16:58, Vadim Zeitlin wrote:
>> 
>>  I'd also consider using "Foo{}" instead of "Foo()" for the constructors of
>> temporary objects (although lmi code doesn't use them much, I think),
>> because the former is much more clear as it doesn't look like a function
>> call.
> 
> Discussion of selected `grep 'std::string()'` results:
> 
> datum_sequence.cpp:    return std::string();
> rate_table_test.cpp:        stream_out_.str(std::string());
> rate_table_tool.cpp:        name_map.emplace(num, std::string());
> 
> In those cases, the type 'std::string' must be named, and I think you're
> saying you'd prefer {} to ().
> 
> antediluvian_stubs.cpp:    std::string const empty_string = std::string();
> 
> How about that one? Which of the following...
>   std::string const empty_string = std::string(); // Leave it alone.
>   std::string const empty_string = std::string{}; // Prefer {} to ().
>   std::string const empty_string{}; // Don't even name the type.
> 
> wx_test_paste_census.cpp:    ,std::string const& unexpected = std::string()
> 
> How about this one, which is a defaulted argument? I ask this because
> earlier we had decided to write that exactly as above. But it's okay
> to change our minds; which would you now prefer?
>   ,std::string const& unexpected = std::string()
>   ,std::string const& unexpected = std::string{}
>   ,std::string const& unexpected{}

And how about ctor initializer lists? In HEAD at this moment we have:

struct ValueInterval
{
    ValueInterval();

    double        value_number;
    std::string   value_keyword;
    bool          value_is_keyword;
    int           begin_duration;
    duration_mode begin_mode;
    int           end_duration;
    duration_mode end_mode;
    bool          insane;
};

whose ctor follows my old practice of eliding non-POD members for which
default values are wanted, so std::string 'value_keyword' is omitted here:

ValueInterval::ValueInterval()
    :value_number     (0.0)
    ,value_is_keyword (false)
    ,begin_duration   (0)
    ,begin_mode       (e_duration)
    ,end_duration     (0)
    ,end_mode         (e_duration)
    ,insane           (false)
{}

Today I look at that as a symmetry violation, and I want to add

     :value_number     (0.0)
+    ,value_keyword    WHAT?
     ,value_is_keyword (false)

but how should that be initialized? Options:

    ,value_keyword    (std::string()) // #1
    ,value_keyword    ("") // #2
    ,value_keyword    () // #3
    ,value_keyword    {} // #4

I think #1 is ugly, #2 is poor, and #3 introduces its own asymmetry
if we leave the others as they are:

     :value_number     (0.0)   // parentheses
     ,value_keyword    {}      // braces?
     ,value_is_keyword (false) // parentheses

so should we instead change all the parentheses to braces? I don't
think we want to make that a general rule because we might someday
have a similar case that uses lmi's class glossed_string instead of
std::string, and glossed_string has std::initializer_list ctor, so
the meaning of 'glossed_string{}' changes from C++11 to C++17.

Therefore, I think our general rule here should be #3:
  ,value_keyword    () // datatype is std::string
if we want to write it at all.