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

[Greg Chicares]

On 6/7/21 2:37 PM, Vadim Zeitlin wrote:
> On Sun,  6 Jun 2021 21:37:59 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...commit trimmed to show only the relevant part...]
> GC> commit c01b9b0ad03a823691fa39e7727a31efe1104f88
> GC>     Improve concinnity
> GC> +    static constexpr double epsilon   
> {std::numeric_limits<double>::epsilon()};
> GC> -    static double const epsilon = std::numeric_limits<double>::epsilon();

I seek a terse alias for a known constant--a modern analogue of:
  #define epsilon DBL_EPSILON
Most of all, I want to choose one strategy for all cases like this,
and apply it without thinking the next time a similar case arises.

As the "Improve concinnity" line suggests, I searched for other
places where we'd done something similar, and copied that.

But if 'static constexpr' isn't the ideal idiom, then let's choose
another idiom and use it everywhere applicable.

>  I believe that after replacing "const" with "constexpr", "static" has
> become at least redundant and maybe even somewhat harmful, as it forces the
> compiler to create the "epsilon" variable in the program, while without it
> it could avoid doing this and just use it at compile time.

Let me paraphrase that, so you can say whether I've understood your
line of thought. 'constexpr' alone suggests that the compiler treat
this as a compile-time value, so that it might optimize away the
variable and just use the known constant value directly. However,
'static' seems to specify that a genuine variable is wanted, which
suggests to the compiler that it shouldn't be optimized away. Have
I understood correctly?

If so, I'd say maybe that's true, but maybe it's not--the Standard
AFAICT doesn't give us enough definite premises to formulate a
syllogism either way. And there's always the "as-if" rule, which in
this case seems to mean that it can optimize away a 'static constexpr'
whenever (as in this case) it can deduce that it's all right to do so.

>  So I think it should be just removed here -- but please let me know if you
> see some reason to keep it.

Here's a counterargument that seems strong to me.

'static constexpr' is what the Standard uses, e.g.:
  [numeric.limits.members/25] (an epsilon, though not a variable)
  static constexpr T epsilon() noexcept;
  [numeric.limits.members/36] (a variable, though not an epsilon)
  static constexpr bool has_infinity;

Therefore, I figured that
  static constexpr double epsilon {...verbose-initializer...};
was the most natural way to write the commit above. Wouldn't a
compiler optimize that in the same way as the std::numeric_limits
members above?

If (as I suspect) the Standard doesn't prescribe whether or not
'static constexpr' can be optimized as well as 'constexpr' alone,
then wouldn't examples like std::numeric_limits (and quite a few
others in the Standard) lead compiler authors to choose to
optimize it, at least where the "as-if" rule allows?

If we were to propose modifying the Standard as follows (e.g.):

-  static constexpr bool has_infinity;
+  constexpr bool has_infinity;

then what would we realistically expect the Committee to say?
(I believe that proposal would be dismissed out of hand.)

I think the guiding principle here should be to do what the
Standard does unless there's a definite reason not to. I can't
find such a definite reason--I believe the Standard is vague on
this matter.

Do you find that counterargument persuasive?