C++ Logo


Advanced search

Re: [SG10] Updates to SD-6

From: Richard Smith <richard_at_[hidden]>
Date: Thu, 1 Jan 2015 18:31:13 -0800
On Mon, Dec 29, 2014 at 5:45 PM, Nelson, Clark <clark.nelson_at_[hidden]>

> I notice that Richard is behind quite a few of the new features, for almost
> none of which is any feature-test macro mentioned in the document. [shaking
> head] Richard, Richard. :-)

It's official, I'm a terrible person. Apologies.

On Tue, Dec 30, 2014 at 9:54 AM, Nelson, Clark <clark.nelson_at_[hidden]>
> wrote:
> 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.)

Strongly agreed. This is a poster child for why we have version numbers on
our feature macros.

> 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.

I don't think we need or want a new macro name here. If I had a time
machine, I'd say:

__cpp_unicode_literals == 200704 means "unicode character literals"
__cpp_unicode_literals == 200710 means "unicode character and string
__cpp_unicode_literals == 201411 means "unicode character and string
literals including u8 char literals"

This slightly changes a previously-published recommendation, in that simply
testing whether __cpp_unicode_literals is defined would no longer suffice
to detect unicode string literal support, so I'm happy to drop the first
line. (I don't expect any vendor will ever ship an implementation that sets
__cpp_unicode_literals to 200704, so it seems academic, and I'm not too
worried about including it.)

> 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?

The paper had its name before we had decided on the name of the grammar
term and the heading of the subclause in the standard. In the title,
"folding" is being used as a verb rather than an adjective (think "a paper
on folding expressions over an arbitrary binary operator"). The feature is
called "fold expressions" within the standard text; I think
__cpp_fold_expressions is the best name here.

(If I had my time machine, I'd probably remove the "ing" from the title, at
least in the wording paper, for clarity.)

> 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).

I like both new macros. I don't think we need to change the value of
__cpp_has_attribute(deprecated) unless we're worried that an implementation
might ship the syntax support for namespace attributes and enumerator
attributes but not allow the [[deprecated]] attribute to appertain to them.

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?

Yes, I think so. I would imagine every implementation does this in practice
by using a helper header, so I think we'd be frustrating both our users and
our implementors if we didn't make the provision of macros and declarations
line up.

Received on 2015-01-02 03:31:16