On Sun, Dec 19, 2021 at 2:36 PM Maciej Polanski via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Hello,

So, let's just allow use of a types and static constants from
not-instantiation-ed template class (if possible):

   template<typename T>
   struct Foo{
       constexpr static int bar = 0x01;
   };
   int i = Foo::bar;                      // Doesn't compile now, but could
   int j = Foo<class Nonexisting>::bar;   // Ugly hack but works


This improvement should make template configuration behave similar to
class usages.
Classes frequently uses internal class constants, e.g.
"std::cout.setf(std::ios::hex, std::ios::basefield)".

So this change would allow to include constants and types used to
configure template, inside it.
Ideally, those should be visible inside template-initialization-list
without scope operators.

HelloWorld example:
---
#include <iostream>

// T needed for some functionality not listed here
template <typename T, int flags>
struct HelloWorld
{
     static constexpr int Hello = 0x1;
     static constexpr int World = 0x2;
     static constexpr int Exclamation = 0x4;

     void work(){
         if (flags & Hello)         // <- no code for this line
             std::cout << "Hello ";
         if (flags & World)         // <- no code for this line
             std::cout << "World";
         if (flags & Exclamation)   // <- no code for this line
             std::cout << "!\n";
     }
};

int main()
{
     HelloWorld<int, Hello | World | Exclamation>{}.work(); // Prints
"Hello World!"
     return 0;
}
---

Currently types and constants have to be defined before template,
polluting higher scope. Or ugly hack used:

   HelloWorld<int, HelloWorld<void*, 0>::Hello |
HelloWorld<std::iostream, -1>::World | HelloWorld<class Nonexisting,
3141592>::Exclamation>{}.work();

You can see this yourself in Compiler Explorer:
https://godbolt.org/z/s6MP7sqz5


Regards,
Maciej




--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

The standard workaround for the OP's use case is to move the constants into a non-template public base class like std::ios_base. Any proposal for a new language feature will need to explain why the current workarounds are inadequate (e.g., too much code duplication). I personally can't see much wrong with the status quo.

--
Brian Bi