I agree with your conclusion.

A question came up recently about whether nested inline namespaces (P1094R2) needed a feature test macro.   In the CWG discussion Alisdair said there was intentionally no feature test macro.

It might be helpful for proposals to that do not have a feature test macro to say so explicitly so that we know whether it was by design or an oversight.

John.

> On Jan 11, 2019, at 10:31 AM, Jonathan Wakely <cxx@kayari.org> wrote:
>
> A colleague queried the absence of a feature-test macro for
> https://wg21.link/p0458 "Checking for Existence of an Element in
> Associative Containers".
>
> I couldn't find any record of discussion in LWG review or on this
> mailing list to indicate whether the omission was intentional or an
> oversight.
>
> IMHO there's not much need for a macro, based on the "if you have to
> write the alternative code anyway, you might as well just do that"
> principle. i.e. the macro allows you to write:
>
> #if __cpp_lib_assoc_contains
>  if (cont.contains(key))
> #else
>  if (cont.find(key) != cont.end())
> #endif
>  {
>    // ...
>  }
>
> But the performance characteristics of the two forms are identical, so
> checking the macro just obfuscates the code. If you need to support
> old compilers, just write the code the old way.
>
> The new contains member is more efficient than a badly-written check
> for multimaps and multisets that uses "count":
>
> #if __cpp_lib_assoc_contains
>  if (cont.contains(key))
> #else
>  if (cont.count(key) != 0)
> #endif
>  {
>    // ...
>  }
>
> But this code should be fixed anyway.
>
> Does SG10 agree that we don't need a macro for p0458?
> _______________________________________________
> Features mailing list
> Features@isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/features