Re: [lmi] [lmi-commits] master c01b9b0 02/22: Improve concinnity

[Greg Chicares]

On 6/16/21 12:09 AM, Vadim Zeitlin wrote:
> On Tue, 15 Jun 2021 23:53:14 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> Here's a counterargument that seems strong to me.
> GC> 
> GC> 'static constexpr' is what the Standard uses, e.g.:
> GC>   [numeric.limits.members/25] (an epsilon, though not a variable)
> GC>   static constexpr T epsilon() noexcept;
> GC>   [numeric.limits.members/36] (a variable, though not an epsilon)
> GC>   static constexpr bool has_infinity;
> 
>  Unfortunately, you have fallen victim to a classic blunder of thinking

Oh. I hate when that happens.

> that "static" means the same thing in C++ programs, instead of having 17.5
> different possible meanings (at the last count, averaging over the
> different language versions, and only slightly exaggerating). The "static"
> here, i.e. for a member variable, is, of course, totally different from
> "static" for a local variable, and must be used as both "epsilon" and
> "has_infinity" are properties of the type and without "static" they would
> become properties of an object, which is definitely not wanted here.

Okay, thanks.

> GC> Do you find that counterargument persuasive?
> 
>  Sorry, no. We should definitely use "static" for class members, but this
> doesn't mean that we should use it for local variables, and I still think
> it should be removed in this case.

Taking a further step back, I'm tempted to say that this shouldn't be a
function-local variable at all, because both decimal_root() and brent_zero()
have a copy. But I don't like this:
    namespace detail { double epsilon = /* verbosity */; }
because "namespace detail" is merely suggestive, whereas the scope of local
variables is enforced.

Tomorrow I'll reconsider the other occurrences of "static constexpr" to
see whether I can find any argument for retaining it anywhere.