On 01/01/2015 09:31 PM, Richard Smith wrote:
On Mon, Dec 29, 2014 at 5:45 PM, Nelson, Clark <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
[email protected]
http://www.open-std.org/mailman/listinfo/features
_______________________________________________
Features mailing list
[email protected]
http://www.open-std.org/mailman/listinfo/features
