On 01/01/2015 09:31 PM, Richard Smith wrote:
On Mon, Dec 29, 2014 at 5:45 PM, Nelson, Clark <clark.nelson@intel.com> wrote:
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@intel.com> 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 literals"
__cpp_unicode_literals == 201411 means "unicode character and string literals including u8 char literals"

I like this idea a lot. 
We could implement this and just have
__cpp_unicode_literals == 200704
be synonymous with
__cpp_unicode_characters == 200704
The column in the SD-6 document would just have both both options listed.  We could put in a note to that effect.
It seems ironic that our feature testing system has issues bit I guess it's to be expected. ;-)

Alternatively we could have:

__cpp_unicode_characters == 200704 means "unicode character literals u'a' and U'a'"
__cpp_unicode_literals == 200710 means unicode string literals u"", U"", u8""
Then go back to __cpp_unicode_characters with
__cpp_unicode_characters == 201411 means "unicode character literals u'a' and U'a' and u8'a'"
This would separate character literals and string literals (as we have already started) but we wouldn't have a feature with two synonymous macros.  And it's logically defensible too.

We would not be adding a new macro in either case.

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.


_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features