On 12/30/2014 12:54 PM, Nelson, Clark 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.) > >> 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). I guess i was thinking this paper introduces 3 things: 1. namespace attributes 2. enumerator attributes 3. application of attribute deprecated allowed for the former attribute contexts. The first two are 'new' (though implementations have shipped with these). I figure the syntax and semantics of attribute deprecated haven't changed - just the use cases. > >> 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? On second reading I'm not actually sure whether these things go into std:: or std::experimental::... So should they be pulled into <vector> or <experimental/vector>? > > Clark > _______________________________________________ > 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
