C++ Logo

sg10

Advanced search

Re: [SG10] Updates to SD-6

From: Nelson, Clark <clark.nelson_at_[hidden]>
Date: Tue, 30 Dec 2014 17:54:09 +0000
> For N3928 Extending static_assert why not just bump up the date on __cpp_static_assert?

Yeah, that's definitely worth considering. The change is a pretty minor
tweak. (The recommendations I included for this were the ones provided
in N3928 -- thanks, Walter.)

> Related to this I'm assuming an implementation is allowed to bump up the date on a macro if they implement updates over several iterations of a feature.
> Users could be encouraged to check __cpp_feature >= <some_min_date> for example.

You seem to be talking here about implementation dates. That's allowed, of
course -- SD-6 contains only recommendations, after all -- but it would
not actually constitute following the recommendations. It certainly
wouldn't help with portability between implementations, which is our
primary goal.

> We could bump the date on __cpp_unicode_literals for - Scartch that - that's for strings.
> Just __cpp_utf8_char_literals I think.

Noted, thanks.

> N4295 - Folding expressions: __cpp_parameter_pack_sorcery, __cpp_fold_expressions is probably better.

Interesting. Richard, for my curiosity, can you explain why the title of
the document doesn't match the terminology used in the document?

> N4266 - Attributes for namespaces and enumerators.  They really are sort of two different things:

> __cpp_namespace_attributes 201411
> __cpp_enumerator_attributes 201411

Hmm. It could be argued that each attribute that can appertain to a
namespace or enumerator is a distinct thing. Today there is only one such
attribute: deprecated. We could even consider bumping the value of
__cpp_has_attribute(deprecated).

> Safe conversions in unique_ptr<T[]> -

Did you mean to say something about this?

> A proposal to add invoke function template - __cpp_lib_invoke 201411.

I think we want to be very careful about introducing a macro name that
short. It wouldn't be consistent with our other macros, but maybe we should
consider something like __cpp_lib_functional_invoke.

> N4280 - Non-member size() and more: __cpp_lib_nonmember_container_access 201411.

OK. I have another question about this one. It mentions that the new
declarations are available by including any of an even dozen headers. Does
that mean that our recommendations should specify this macro as being
defined by all of those headers?

Clark

Received on 2014-12-30 18:54:24