Re: [lmi] Default values for default arguments

[Vadim Zeitlin]

On Fri, 10 Feb 2017 13:24:20 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-02-04 14:59, Vadim Zeitlin wrote:
GC> > On Sat, 4 Feb 2017 04:51:35 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Vadim--Do you see any reason why we should not prefer the uniform
GC> > GC> "{}" syntax to specify default values for default arguments as in
GC> > GC> the following examples? [... e.g. ...]
GC> > GC> -        ,std::string const&              a_default_keyword = ""
GC> > GC> +        ,std::string const&              a_default_keyword = {}
GC> [...]
GC> > [...] just in case it wasn't
GC> > obvious not only to me, this relies on the existence of the ctor from
GC> > std::initializer_list in both std::string and std::vector. IOW, this
GC> > wouldn't work for any class not providing such ctor, so if the question is
GC> > "can we uniformly use {} to specify default values for all classes", then
GC> > the answer is definitely no.
GC> 
GC> Even worse...
GC> 
GC> N3337: C++11 [5.17/9]   "The meaning of x={} is x=T()"
GC> N4618: C++17 [5.18/9.1] "The meaning of x={} is x=T{}"
GC> 
GC> ...the answer was definitely yes, and then they changed it.

 This is the right change, IMO, but it's true that it doesn't help much
during the transition from C++1[14] to C++17 and not at all when we can't
use C++17 yet.

GC> Thus, the only braced-initialization modernization I would propose is
GC> eliminating the brace-initialized C arrays of POD types in cases like:
GC> 
GC> -        static int const n = 101;
GC> -        static double const d[n] =
GC> +        static std::vector<double> const v
GC>             {
GC>             //0     1     2     3     4     5     6     7     8     9
GC>             2.50, 2.50, 2.50, 2.50, 2.50, 2.50, 2.50, 2.50, 2.50, 2.50, // 
00
GC> [...]
GC>             1.00                                                        // 
100
GC>             };
GC> -        static std::vector<double> const v(d, d + n);

 This seems totally unobjectionable.

 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.

 Regards,
VZ