C++ Logo

sg10

Advanced search

Re: [SG10] [isocpp-lib] [isocpp-core] Missing feature-test macros

From: Richard Smith <richardsmith_at_[hidden]>
Date: Fri, 4 Oct 2019 11:51:15 -0700
On Fri, Oct 4, 2019 at 6:56 AM David Vandevoorde via Lib <
lib_at_[hidden]> wrote:

> Thanks for that work, Barry!
>

+1, this is great.


> I don’t disagree with any of your recommendations, and wholeheartedly
> agree with your constexpr changes.
>
> While going through it I found myself really not liking the name
> “__cpp_familiar_template_lambda”: I find it quite opaque. Is there is an
> opportunity to rename it to “__cpp_expl_lambda_template_parameters” or
> something like that?
>

I'd prefer that we just bump the value of __cpp_generic_lambdas for this
rather than adding a new macro.

__cpp_impl_constexpr_members_defined : not a huge fan of the name, but if
it's likely only going to be used in the stdlib implementation, maybe
that's fine.

__cpp_lib_remove_cvref : does this need a macro? It seems like code wishing
to support old compilers could define it themselves or unconditionally use
remove_reference + remove_cv (I think this fails the "you lose nothing by
always behaving like the feature is not present" test, unless I've
overlooked a use case). I'm wondering the same thing
for __cpp_lib_starts_ends_with. I'd imagine a typical usage of that macro
would be something like this (possibly factored out into a helper function):

#if __cpp_lib_starts_ends_with
  if (s.starts_with("foo"))
#else
  if (s.size() >= 3 && s.compare(0, 3, "foo"))
#endif

I don't think that's worthwhile when you could instead write:

  // TODO(c++20): replace with s.starts_with("foo")
  if (s.size() >= 3 && s.compare(0, 3, "foo"))

Same thought for: __cpp_lib_type_identity, __cpp_lib_unwrap_ref (small
convenience functionality that you can write yourself with no loss of
functionality if you need it and can't depend on it being in the library).

__cpp_lib_constexpr_complex, __cpp_lib_constexpr_array_comparisons,
__cpp_lib_constexpr_pointer_traits
: I seem to recall a discussion in L(E?)WG about moving away from
fine-grained constexpr feature test macros for the stdlib towards
periodically bumping __cpp_lib_constexpr. How do these fit into that?

Regarding the new set of constexpr macros (__cpp_constexpr_virtual,
try_catch, ...): do those benefit any implementation? (Clang at least has
already released some of these features without the additional macros, so
they're no help there for the previous release, and now implements the full
set of these, so the fine-grained macros are no help for the next release
either.) I think we need to be careful about adding too many macros -- each
feature test macro we add introduces a small amount of overhead to every
compilation, and that adds up. (Incidentally this is why the original
proposal was for a single __has_feature(x) mechanism: that avoids the need
to pre-populate all the feature test macros in the macro table. But that
ship has sailed.) I think it's preferable for users to just have a value
that means "you get to use the C++20 constexpr rules" if no-one is going to
ship a compiler that has only part of the rules (apart from dynamic
allocation, which has its own macro).

For __cpp_nodiscard_reason: I'm opposed to adding this macro in isolation.
Either we need to accept that version numbers for feature test macros don't
work (the magic numbers are too magical) and completely rethink our
approach, or we do not have adequate rationale for this.

Daveed
>
> On Oct 3, 2019, at 11:56 PM, Barry Revzin via Core <core_at_[hidden]>
> wrote:
>
> Hey SG10, CWG, and LWG,
>
> I went through the past few years of straw polls and put together a
> suggestion of what feature-test macros are missing: I'm proposing that
> about two dozen need to be added. The draft can be found here:
> https://brevzin.github.io/sd6/papers/d1902r0.html.
>
> I included every paper on the straw polls pages, so if anybody has
> motivation for a macro for one of the papers I listed as "no macro
> necessary," please let me know. Also, if you disagree with any of my
> recommendations, also let me know. I already pruned an earlier list with
> some help, and I'd like to get this right.
>
> I wanted to get this out earlier than the weekend before the deadline,
> but... that didn't happen.
>
> Barry
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2019/10/7332.php
>
>
> _______________________________________________
> Lib mailing list
> Lib_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
> Link to this post: http://lists.isocpp.org/lib/2019/10/13732.php
>

Received on 2019-10-04 20:51:27