On Sun, Dec 19, 2021 at 2:36 PM Maciej Polanski via Std-Proposals <
std-proposals_at_[hidden]> 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_at_[hidden]
> 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*