This looks like an 'alternative'; is it possible for downstream customers to be agnostic about this setting?

See https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#do-not-use-features-to-implement-alternatives

It's a good question. I think the idea was to follow the abseil pattern here (maybe they're following something else which came before it).

There's definite trickiness around this setting and consuming the library - the header files of this library generally need to be built with a c++ standard identical to the static library linked against. I'm not sure what alternatives exist here

It's a good question. I think the idea was to follow the abseil pattern here (maybe they're following something else which came before it).

Abseil does not follow such a pattern though, because they namespace all their polyfills. That is, customer code can be written always naming absl::stuff and it will work regardless of this setting.

There's definite trickiness around this setting and consuming the library - the header files of this library generally need to be built with a c++ standard identical to the static library linked against. I'm not sure what alternatives exist here

That's also something abseil doesn't do; there is a feature there but it bakes the 'polyfills or not' setting directly into the bits so that downstream C++ version need not agree.

In general we do not expect a given program to only ever be built with a consistent C++ version.

I think the correct think to do here is thus to turn on the setting and say "vcpkg's bde says you are using c++17+; if you want something else you must use overlays".

Thanks for the explanation - and time taken so far to consider this PR! 🙂. I might be misunderstanding your description since I haven't used abseil, but I think bde is in a similar situation wrt to polyfills - everything is namespaced.

In general we do not expect a given program to only ever be built with a consistent C++ version.
Makes sense, although as I'm sure you've realised - bde does expect that ~all usages of it's header files are linked against a version of the library which has been built with the same C++ standard version.

I think your suggestion is workable but could make it difficult to change the standard in future. I'll need to discuss internally to figure out what's feasible.

See the exception we carved out specifically for what abseil was doing:

https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#a-feature-may-replace-polyfills-with-aliases-provided-that-replacement-is-baked-into-the-installed-tree

In particular, the requirement to bake the feature answer into the resulting installed tree. bde[core] needs to use the polyfills even if downstream someone uses a C++17 compiler.

Unfortunately the C++ ecosystem writ large does not choose a consistent language version at any given time, so we require things indexed in our curated registry to deal with that situation.