On Tue, Jan 6, 2015 at 2:32 PM, Nelson, Clark <[email protected]> wrote:
> > Finally looking at > > N4258: Cleaning-up noexcept in the Library > > The only thing I can think of that would be helpful is > > __cpp_lib_allocator_is_always_equal > > The really interesting question about this, like > __cpp_lib_nonmember_container_access, is exactly which headers are > supposed to > define it? (I'm almost inclined simply to assume that the answer will be > the > same here, instead of actually investigating it myself.) > > > In my last email I was thinking out loud and maybe it looked chaotic to > me this morning. > > I would like to summarize my favored approaches: > > Thanks so much for this; I was trying to sort out proposals from musings. > :-) > > > N4267 (u8 character literals) > > __cpp_unicode_characters 201411 > > For the time being I am leaving in __cpp_unicode_literals as a possibility; > we'll sort that out when we have a meeting. > > > N4190 (removing old stuff) > > __cpp_lib_remove_auto_ptr 201411 > > __cpp_lib_remove_random_shuffle 201411 > > __cpp_lib_remove_deprecated_functionals 201411 > > __cpp_lib_remove_deprecated_bind 201411 > > These would get date bumps if/when std::not_fun etc. or std::bind is > removed. > > I am slightly annoyed that the fist two don't have _deprecated_ but they > look nice to me as they are. > > Personally, I prefer the first two, and am more annoyed that we seem to > need > to use "deprecated" in the latter two; to me that feels like a cop-out, > whereas it should be redundant with "remove". > > In any event, we definitely need feedback from STL (and probably others) > about > the granularity of the functional stuff. > > My only other comment is that I prefer "removed" to "remove". I have taken > the liberty of entering them that way into the draft SD-6. > > > N4279 - Improved insertion interface for unique-key maps > > __cpp_lib_map_insertion 201411 > > __cpp_lib_unordered_map_insertion 201411 > > Thanks. > > > N4051 Allow typename in a template template parameter > > __cpp_typename_in_template_template_parm 201411 > > This may be too little to mess with. > > This is a really good question. The only way I could see this being used > would be like so: > #if __cpp_typename_in_template_template_parm > #define TTP typename > #else > #define TTP class > #endif > > with template template parameters declared like so: > template<template<...> TTP X> ... > > Obviously, the interesting questions are, what sort of spelling might > actually be used for the name of what I have called "TTP", and would anyone > actually bother to write code like this? It really depends what we think feature test macros are for. Another possible use is this: #if !__cpp_typename_in_template_template_parm #error You need a compiler supporting C++17 to build this code. #endif So, do we only care about feature-test macros that allow a program to use the feature if present and reasonably fall back if not, or do we also care about cases where the only reasonable response to a missing feature is to cause an error (or fail a configure check or similar)? The latter case covers this feature, trigraph removal, digit separators, and probably some others, which should presumably be treated uniformly. > N4268 - Allow constant evaluation for all non-type template arguments > > __cpp_const_eval_of_non_type_template_args > > I have tweaked the spelling of this slightly: > __cpp_const_eval_all_nontype_template_args That seems quite verbose. How about: __cpp_nontype_template_arg_eval Even then, I worry that the "eval" is missing the point. The change removes a syntactic restriction as much as it introduces different semantics. I wonder if simply __cpp_nontype_template_args == 201411 would be acceptable; I think that's my preferred spelling for this. > N4230 - Nested namespace definition > > __cpp_nested_namespace_definitions 201411 > > I like this better than __cpp_nested_namespaces that I had before. > > Thanks. > > > N3922 - New Rules for auto deduction from braced-init-list > > __cpp_auto_deduction 200604 for C++11 > > __cpp_auto_deduction 201411 for C++17 > > This could be an alternate spelling of __cpp_return_type_deduction: > > __cpp_auto_deduction 201304 for C++14 > > I have added this to the table for C++17, but until we've had more > discussion, > I'm not going to do anything to the earlier recommendations. > > Another update attached; only two documents left with no proposed > recommendation. N4259: __cpp_lib_uncaught_exceptions N4089: __cpp_lib_unique_ptr_array_conversions
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
