`wil::reg::try_get_value()` is gated by `_OPTIONAL_` and `__cpp_lib_optional`, but can't be re-included

[fredemmott]

WIL has several features where the features available from <wil/feature.hpp> depend on which headers have already been included; for the majority of these, you can include the header again, but this doesn't work for <wil/registry.h> as the entire file is gated with a traditional include guard for __WIL_REGISTRY_INCLUDED

Concretely, given how other parts of WIL work, I would expect this to work but it does not:

#include <wil/registry.h> // << works if I delete this line
#include <optional>
#include <wil/registry.h>

// ...

auto x = wil::reg::try_get_value<T>(key, name);

This is problematic when other a different header includes <registry.h>.

Suggested fixes:

• use the same pattern you're using in other parts of WIL to allow re-inclusion
• alternatively/additionally, add support for 'tweak headers'

As an example of tweak headers, wil/registry.h could start with:

#if __has_include(<wil-reg.tweaks.h>)
#include <wil-reg.tweaks.h>
#endif

I could then make a wil-reg.tweaks.h be included in my build, and include <optional> in that header.

[dunhor]

This has been a long-standing pet peeve of mine in the WIL headers. I have a plan in the hopefully near term to introduce a heuristic in WIL to determine if it's okay to use the STL and then the WIL headers can pull in whatever dependencies they need. This won't fix 100% of the problem since the STL headers aren't the only ones we have header inclusion checks for, but it should account for most of them. In your case, the registry header would include <optional> when it determines that the STL is safe to use, so your code does not need to worry about including it, nor does it need to worry about include order.