I don't get your question.
You are calling operator() on the return value of min()/lowest()/max() (see
the double parenthesis?).

This won't work for actual numerics, generally:
<source>:12:36: error: expression cannot be used as a function
   12 | std::numeric_limits<int>::min()();
      | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
<source>:13:39: error: expression cannot be used as a function
   13 | std::numeric_limits<int>::lowest()();
      | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
<source>:14:36: error: expression cannot be used as a function
   14 | std::numeric_limits<int>::max()();
      | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~

If you omit one of the parentheses, nothing is printed (as expected)
https://godbolt.org/z/o7z6M7qje

Could you please clarify?

Am Sa., 11. Jan. 2025 um 21:59 Uhr schrieb Ivan Matek via Std-Proposals <
std-proposals_at_[hidden]>:

> I presume people here know about this, but for those not familiar:
> int main() {
> using hello = decltype([](){std::print("hello");});
> using space = decltype([](){std::print(" ");});
> using world = decltype([](){std::print("world");});
> std::numeric_limits<hello>::min()();
> std::numeric_limits<space>::lowest()();
> std::numeric_limits<world>::max()();
> }
> prints out hello world <https://godbolt.org/z/4fTWWoE4E>, because for
> "unrecognized" types default implementation just returns default
> constructed value.
> I presume this primary template specified in standard
> https://eel.is/c++draft/numeric.limits
> is specified as it is so that specializations can inherit members that
> they do not want to modify, but
> this still looks to me as less than an ideal solution.
>
> While it is possible to use
> static_assert(std::numeric_limits<T>::is_specialized) or verify
> assumptions in generic code, in practice, such precautions seem uncommon.
> This can lead to subtle bugs where generic code unintentionally relies on
> default values for unsupported types, potentially causing incorrect
> behavior without an immediate compile-time error.
>
> I wonder if anybody ever considered fixing this in the standard(assuming
> this problem actually exists and I did not misunderstood something).
> I understand that backward compatibility may constrain changes to this
> design, but it is library code so in theory std::limits or some other name
> could be used for improved version without breaking any existing code.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>