Doc. no. | N3566 |
Date: | 2013-03-12 |
Project: | Programming Language C++ |
Reply to: | Ville Voutilainen <ville.voutilainen@gmail.com> |
Revised 2013-03-12 at 15:03:58 UTC
Reference ISO/IEC IS 14882:2003(E)
Also see:
The purpose of this document is to record the status of issues which have come before the Evolution Working Group (EWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC IS 14882:2003(E) document.
This document contains only evolution issues which are actively being considered by the Evolution Working Group, i.e., issues which have a status of New, Open, Ready, or Review. See Evolution Defect Reports List for issues considered defects and Evolution Closed Issues List for issues considered closed.
The issues in these lists are not necessarily formal ISO Defect Reports (DR's). While some issues will eventually be elevated to official Defect Report status, other issues will be disposed of in other ways. See Issue Status.
This document includes [bracketed italicized notes] as a reminder to the EWG of current progress on issues. Such notes are strictly unofficial and should be read with caution as they may be incomplete or incorrect. Be aware that EWG support for a particular resolution can quickly change if new viewpoints or killer examples are presented in subsequent discussions.
For the most current official version of this document see http://www.open-std.org/jtc1/sc22/wg21/. Requests for further information about this document should include the document number above, reference ISO/IEC 14882:2003(E), and be submitted to Information Technology Industry Council (ITI), 1250 Eye Street NW, Washington, DC 20005.
Public information as to how to obtain a copy of the C++ Standard, join the standards committee, submit an issue, or comment on an issue can be found in the comp.std.c++ FAQ.
New - The issue has not yet been reviewed by the EWG. Any Wording available is purely a suggestion from the issue submitter, and should not be construed as the view of EWG.
Open - The EWG has discussed the issue but is not yet ready to move the issue forward. There are several possible reasons for open status:
A Wording available for an open issue is still not be construed as the view of EWG. Comments on the current state of discussions are often given at the end of open issues in an italic font. Such comments are for information only and should not be given undue importance.
Deferred - The EWG has discussed the issue, is not yet ready to move the issue forward, but neither does it deem the issue significant enough to delay publishing a standard or Technical Report. A typical deferred issue would be seeking to clarify wording that might be technically correct, but easily mis-read.
A Wording available for a deferred issue is still not be construed as the view of EWG. Comments on the current state of discussions are often given at the end of open issues in an italic font. Such comments are for information only and should not be given undue importance.
Dup - The EWG has reached consensus that the issue is a duplicate of another issue, and will not be further dealt with. A Rationale identifies the duplicated issue's issue number.
NAD - The EWG has reached consensus that the issue is not a defect in the Standard nor is it an extension the EWG deems acceptable.
Review - Exact resolution is now available for review on an issue for which the EWG previously reached informal consensus.
Ready - The EWG has reached consensus that the issue is an extension that can go forward to Core, Library, or a Study Group for further processing.
Resolved - The EWG has reached consensus that the issue is a defect in or an acceptable extension to the Standard, but the resolution adopted to resolve the issue came via some other mechanism than this issue in the list - typically by applying a formal paper, occasionally as a side effect of consolidating several interacting issue resolutions into a single issue.
DR - (Defect Report) - It's not expected that the EWG would handle Defect Reports.
WP - (Working Paper) - The proposed resolution has not been accepted as a Technical Corrigendum, but the full WG21/PL22.16 committee has voted to apply the Defect Report's Proposed Resolution to the working paper.
Tentatively - This is a status qualifier. The issue has been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed for the qualified status. Tentatively qualified issues may be moved to the unqualified status and forwarded to full committee (if Ready) within the same meeting. Unlike Ready issues, Tentatively Ready issues will be reviewed in subcommittee prior to forwarding to full committee. When a status is qualified with Tentatively, the issue is still considered active.
Pending - This is a status qualifier. When prepended to a status this indicates the issue has been processed by the committee, and a decision has been made to move the issue to the associated unqualified status. However for logistical reasons the indicated outcome of the issue has not yet appeared in the latest working paper.
Issues are always given the status of New when they first appear on the issues list. They may progress to Open or Review while the EWG is actively working on them. When the EWG has reached consensus on the disposition of an issue, the status will then change to Dup, NAD, or Ready as appropriate. Once the full J16 committee votes to forward Ready issues to the Project Editor, they are given the status of Defect Report ( DR). These in turn may become the basis for Technical Corrigenda (TC1), or are closed without action other than a Record of Response (Resolved ). The intent of this EWG process is that only issues which are truly defects in the Standard move to the formal ISO DR status.
Section: 7.1.6.4 [dcl.spec.auto] Status: Ready Submitter: Jason Merrill Opened: 2012-03-27 Last modified: 2013-03-09
View all issues with Ready status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3386.htmlReviewed by EWG in Portland 2012, proceeding to CWG.
Wording available:
The paper contains the proposed wording.
Section: 4.13 [conv.rank] Status: New Submitter: Jens Maurer Opened: 2012-09-12 Last modified: 2013-03-09
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3387.htmlWording available:
The paper contains the proposed wording.
Section: 7.6 [dcl.attr] Status: Ready Submitter: Alberto Ganesh Barbati Opened: 2012-06-12 Last modified: 2013-03-09
View all issues with Ready status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.htmlReviewed by EWG in Portland 2012, proceeding to CWG.
Wording available:
The paper contains the proposed wording.
Section: 18.6 [support.dynamic] Status: Open Submitter: Clark Nelson Opened: 2012-08-30 Last modified: 2013-03-09
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htmReviewed by EWG in Portland, author encouraged to revise.
Wording available:
The paper contains the proposed wording that is to be revised.
Section: 16.3 [cpp.replace] Status: New Submitter: Jonathan de Boyne Pollard Opened: 2012-09-21 Last modified: 2013-03-09
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.htmlWording available:
The paper contains the proposed wording.
Section: 12.8 [class.copy] Status: Ready Submitter: Ville Voutilainen Opened: 2012-09-21 Last modified: 2013-03-09
View all issues with Ready status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3401.htmlReviewed by EWG in Portland 2012, proceeding to CWG.
Wording available:
The related Core issue contains the proposed wording.
Section: 20.1 [utilities.general] Status: Ready Submitter: Peter Sommerlad Opened: 2012-09-08 Last modified: 2013-03-09
View all issues with Ready status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3402.pdfReviewed by EWG in Portland 2012, binary literals to be added into the core language, the rest of the paper is on LWG's plate. The binary literals are proceeding to CWG.
Wording available:
The paper contains the Library wording, Dennett has written the Core wording for binary literals.
Section: 18 [language.support] Status: New Submitter: Mike Spertus Opened: 2012-09-22 Last modified: 2013-03-09
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3403.pdfNot reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).
Section: 14 [temp] Status: Open Submitter: Mike Spertus Opened: 2012-09-22 Last modified: 2013-03-09
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3405.htmlEWG review started, not completed yet. Likely needs a follow-up paper.
Section: 17 [library] Status: New Submitter: Dietmar Kühl Opened: 2012-09-14 Last modified: 2013-03-09
View other active issues in [library].
View all other issues in [library].
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.htmlHandled by the Numerics Study Group (SG5).
Section: 1.10 [intro.multithread] Status: New Submitter: Pablo Halpern Opened: 2012-09-24 Last modified: 2013-03-09
View other active issues in [intro.multithread].
View all other issues in [intro.multithread].
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3409.pdfHandled by the Concurrency Study Group (SG1)
Section: 20.9 [meta] Status: New Submitter: Dean Michael Berris Opened: 2012-09-18 Last modified: 2013-03-09
View other active issues in [meta].
View all other issues in [meta].
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3410.pdfTo be handled by the Reflection Study Group (SG7).
Section: 3.9 [basic.types] Status: Ready Submitter: Jens Maurer Opened: 2012-09-19 Last modified: 2013-03-09
View all issues with Ready status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3412.htmlReviewed by EWG in Portland 2012, proceeding to CWG. The library part is N2648 C++ Dynamic Arrays, and that part is proceeding to LWG.
Wording available:
The paper contains the proposed wording, as does the Library counterpart.Section: 14.1 [temp.param] Status: New Submitter: Jens Maurer Opened: 2012-09-19 Last modified: 2013-03-09
View other active issues in [temp.param].
View all other issues in [temp.param].
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.htmlWording available:
The paper contains the proposed wording.Section: 14.1 [temp.param] Status: New Submitter: Mike Spertus Opened: 2012-09-21 Last modified: 2013-03-09
View other active issues in [temp.param].
View all other issues in [temp.param].
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3416.htmlSection: 5.1.2 [expr.prim.lambda] Status: Open Submitter: Faisal Vali Opened: 2012-09-21 Last modified: 2013-03-09
View other active issues in [expr.prim.lambda].
View all other issues in [expr.prim.lambda].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdfReviewed by EWG in Portland 2012, proceeding with a follow-up paper.
Section: 1.10 [intro.multithread] Status: New Submitter: Robert Geva Opened: 2012-09-21 Last modified: 2013-03-09
View other active issues in [intro.multithread].
View all other issues in [intro.multithread].
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3419.pdfHandled by the Concurrency Study Group (SG1).
Section: 5.1.2 [expr.prim.lambda] Status: Open Submitter: Herb Sutter Opened: 2012-09-23 Last modified: 2013-03-09
View other active issues in [expr.prim.lambda].
View all other issues in [expr.prim.lambda].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3424.pdfReviewed by EWG in Portland 2012, proceeding with a follow-up paper. Changes to const captures rejected, capturing of 'this' and members encouraged to continue with a follow-up paper.
Section: 30 [thread] Status: New Submitter: Artur Laksberg Opened: 2012-09-21 Last modified: 2013-03-09
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdfHandled by the Concurrency Study Group (SG1).
Wording available:
The paper contains the proposed wording.
Section: 3.7.4 [basic.stc.dynamic] Status: Ready Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2013-03-09
View other active issues in [basic.stc.dynamic].
View all other issues in [basic.stc.dynamic].
View all issues with Ready status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3432.htmlReviewed by EWG in Portland 2012, proceeding to CWG.
Wording available:
The paper contains the proposed wording.
Section: 3.7.4 [basic.stc.dynamic] Status: Open Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2013-03-09
View other active issues in [basic.stc.dynamic].
View all other issues in [basic.stc.dynamic].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.htmlReviewed by EWG in Portland 2012, proceeding with a follow-up paper.
Wording available:
The paper contains the proposed wording.
Section: 18.1 [support.general] Status: Open Submitter: Clark Nelson Opened: 2012-09-18 Last modified: 2013-03-09
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htmReviewed by EWG in Portland 2012, proceeding in SG10, Feature Test.
Section: 20.9 [meta] Status: New Submitter: Axel Naumann Opened: 2012-09-24 Last modified: 2013-03-09
View other active issues in [meta].
View all other issues in [meta].
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3437.pdfNot reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).
Section: 18.8 [support.exception] Status: New Submitter: Aurelian Melinte Opened: 2012-09-20 Last modified: 2013-03-09
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.htmlSection: 5.19 [expr.const] Status: Open Submitter: Richard Smith Opened: 2012-09-21 Last modified: 2013-03-09
View other active issues in [expr.const].
View all other issues in [expr.const].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3444.htmlReviewed by EWG in Portland 2012, proceeding with a follow-up paper.
Section: 8.3.5 [dcl.fct] Status: New Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2013-03-09
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3445.htmlSection: 2.10 [lex.ppnumber] Status: Open Submitter: Daveed Vandevoorde Opened: 2012-09-21 Last modified: 2013-03-09
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3448.pdfReviewed by EWG in Portland 2012, proceeding with a follow-up paper.
Wording available:
The paper contains the proposed wording.
Section: 5.2.7 [expr.dynamic.cast] Status: New Submitter: Bjarne Stroustrup Opened: 2012-09-23 Last modified: 2013-03-09
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdfSection: 20.9 [meta] Status: Open Submitter: Herb Sutter Opened: 2012-01-10 Last modified: 2013-03-09
View other active issues in [meta].
View all other issues in [meta].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdfReviewed by EWG in Portland 2012, to be handled by the Concepts Study Group (SG8).
Section: 14.5.3 [temp.variadic] Status: New Submitter: Dave Abrahams Opened: 2012-10-16 Last modified: 2013-03-09
View all issues with New status.
Discussion:
There are lots of very basic manipulations that are either really hard or impossible to do with argument packs unless you use something that causes a big recursive template instantiation, which is expensive at compile-time and can cause bad error messages. I want to be able to index argument packs with integral constant expressions, "take" or "drop" the first N elements of the pack, etc.
Section: 5.19 [expr.const] Status: New Submitter: Dave Abrahams Opened: 2012-10-16 Last modified: 2013-03-09
View other active issues in [expr.const].
View all other issues in [expr.const].
View all issues with New status.
Discussion:
constexpr functions are crippled by the fact that they have to be valid at runtime. Things that are tantalizingly close but you can't quite do include returning a type that depends on the /value/ of a function parameter:
constexpr auto ptr_array(int N) -> int(*)[N] { ... }If we would allow for constexpr functions that can only be evaluated at compile time, we'd be able to do compile-time computation in a much less template-heavy way.
Section: 13 [over] Status: New Submitter: Nevin Liber Opened: 2012-10-19 Last modified: 2013-03-09
View all issues with New status.
Discussion:
struct Silly { template<class... Ts> Silly(Ts&&...) {} }; int main() { Silly s; Silly t(s); // Silly::Silly(Ts &&...) [Ts = <Silly &>] const Silly u; Silly v(u); // calls Silly::Silly(Silly const&) }The problem is that users expect the copy constructor to be called in both situations. Note: you do not need variadics for this; it made the example smaller. Also, this issue existed in C++03, but rarely happened in practice because templated parameters were usually declared const T&.
Section: 7.2 [dcl.enum] Status: New Submitter: Jeffrey Yasskin Opened: 2012-10-20 Last modified: 2013-03-09
View all issues with New status.
Discussion:
In Beman's filesystem code, I found the following problem, which he didn't see because he's been building with MSVC 10: A scoped enum defined at
is used likeif (opts & copy_options::skip_existing) ++ct;
athttps://github.com/Beman/filesystem-proposal/blob/master/src/operations.cpp#L773.
This causes an error like:../../../libs/filesystem/src/operations.cpp:773:9: error: value of type 'boost::filesystem::copy_options' is not contextually convertible to 'bool'
I believe it makes sense to define a contextual conversion to bool for certain scoped enumerations, but I don't see a way to do it. I do see a way to overload & to return bool, but that seems to prevent using & to remove bits from a value, which shouldn't always be prevented.Section: 17.6.3.4 [hash.requirements] Status: New Submitter: Matt Austern Opened: 2012-10-23 Last modified: 2013-03-09
View all issues with New status.
Discussion:
We have a hash function for built-in types and for some standard library types, but we don't have automatically generated hash<> specializations for user-defined types like
struct my_type { int x; std::string y; vector<int> z; };Defining a good and efficient hash function for composite types takes a fair amount of work. One consequence is that there are a lot of user-defined types with bad hash functions floating around. One possibility is automatically generating hash<> specializations, but that's tricky. A simpler possibility is providing tools that make it easier for users to do the right thing.
Section: 3.4 [basic.lookup] Status: New Submitter: Jeffrey Yasskin Opened: 2012-10-24 Last modified: 2013-03-09
View all issues with New status.
Discussion:
Sometimes we want to define a variable that's unused except for its constructor and destructor. lock_guard<mutex> and ScopeGuard are decent examples of this. In C++11, we have to manually name the variable something unique. Sometimes we use _some_name_##__LINE__ (suitably wrapped so the concatenation happens after expanding __LINE__) to try to generate unique names automatically, and gcc/clang have an extension _some_name_##__COUNTER__
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Common-Predefined-Macros.html
to allow multiple such variables on the same line. These are pretty verbose and not convenient for casual use. Haskell allows _ (underscore) to stand in for a variable that's not going to be used. Googlemock defines testing::_ to mean "don't care" as an argument, which is similar but not identical.Section: 12.3 [class.conv] Status: New Submitter: Jeffrey Yasskin Opened: 2012-10-24 Last modified: 2013-03-09
View all issues with New status.
Discussion:
If a type has two implicit conversions, and I call a function with overloads for both target types, there's no way to disambiguate short of writing the conversion explicitly or adding another overload. It would be nice to be able to extend the partial order on conversions.
Section: 5 [expr] Status: New Submitter: Alisdair Meredith Opened: 2012-10-28 Last modified: 2013-03-09
View all issues with New status.
Discussion:
I have a low-priority issue for adding the (neglected) logical-xor operator, ^^. This has traditionally been dismissed as un-necessary, as it is equivalent to boolean operator!=, and there is no short-circuiting benefit to justify adding it. However, contextual conversions to 'bool' are handled specially for logical operators, and in that context it would be completing a hole in the language. I wish I had a better example, but pulling from the standard library:
function<void()> a; function<void()> b; assert(a != b); // does not compile assert(a ^^ b); // would compile, and assert!
Section: 5.17 [expr.ass] Status: New Submitter: Mike Miller Opened: 2012-11-02 Last modified: 2013-03-09
View all issues with New status.
Discussion:
In Portland, CWG categorized a number of issues as "extension," which I presume you will automatically look at for potential EWG involvement once the new revision of the issues list is out. I did want to mention one issue for which we will be resolving part and referring the other part to EWG: issue 1542 raises the question of whether the narrowing rules make sense for a compound assignment, e.g.,
char c; c += {1};CWG addressed a similar issue (1078) for an ordinary assignment and decided that, although the narrowing error was annoying in that case, it wasn't worth the effort to change the language because the workaround was simply to add a cast. In this case, however, there's no way to avoid the error (no place to put the cast). I think we'd be happy with a revision of the narrowing rules that addressed both this case and the one in 1078; maybe the answer is just "why would you use the { } form in a case like this anyway?" The Core issue link here.
Section: 23.3.6 [vector] Status: New Submitter: Nevin Liber Opened: 2012-11-27 Last modified: 2013-03-09
View all issues with New status.
Discussion:
I'd like it to be possible to use the small object optimization (embedding up to a fixed number of objects inside the allocator itself) inside a vector.
Section: 14.7.3 [temp.expl.spec] Status: New Submitter: Faisal Vali Opened: 2012-10-27 Last modified: 2013-03-09
View other active issues in [temp.expl.spec].
View all other issues in [temp.expl.spec].
View all issues with New status.
Discussion:
I had submitted a DR (727) about this in October 2008 - and it was classified as an extension - I wonder if Spertus' DR (1077) that was also classified as an extension should be considered along with this one. 14.7.3 [temp.expl.spec] paragraph 2 requires that explicit specializations of member templates be declared in namespace scope, not in the class definition. This restriction does not apply to partial specializations of member templates; that is,
struct A { template<class T> struct B; template <class T> struct B<T*> { }; // well-formed template <> struct B<int*> { }; // ill-formed };There does not seem to be a good reason for this inconsistency.
Section: 21.4.2 [string.cons] Status: New Submitter: Nevin Liber Opened: 2012-12-19 Last modified: 2013-03-09
View all issues with New status.
Discussion:
In n3485 21.4.2p6 (basic_string constructors and assignment operators), we have:
basic_string(const charT* s, size_type n, const Allocator& a = Allocator()); Requires: s shall not be a null pointer and n < npos.That requires clause is too restrictive; s can be a null pointer when n==0. A (simplified) use case I have seen:
std::string StringFromVector(std::vector<char> const& vc) { return std::string(vc.data(), vc.size()); }Since a conforming implementation can return a null pointer for vc.data() when vc.size() == 0. I don't see any reason to disallow this construct, especially since it takes a Standards expert to see that this is possibly illegal, but not std::string(vc.data(), vc.data() + vc.size()). This is likely to go onto the LEWG's plate.
Wording available:
Requires: n < npos and either s shall not be a null pointer or n == 0.
Section: 6.5.4 [stmt.ranged] Status: New Submitter: Gabriel Dos Reis Opened: 2013-01-12 Last modified: 2013-03-09
View all issues with New status.
Discussion:
The new-style 'for' syntax allows us to dispense with administrative iterator declarations when iterating over a single seuqence. The burden and noise remain, however, when iterating over two or more sequences simultaenously. We should extend the syntax to allow that. E.g. one should be able to write:
for (auto& x : v; auto& y : w) a = combine(v, w, a);instead of the noisier
auto p1 = v.begin(); auto q1 = v.end(); auto p2 = w.begin(); auto q2 = w.end(); while (p1 < q1 and p2 < q2) { a = combine(*p1, *p2, a); ++p1; ++p2; }
Section: 20.8.9 [bind] Status: New Submitter: Chris Jefferson Opened: 2013-01-25 Last modified: 2013-03-09
View all issues with New status.
Discussion:
As more variadic functions work their way into my C++ code, I'm getting increasingly annoyed that there isn't a variadic bind. There is a tiny bit of annoyance on exactly what to use. There seems to me to be 2 sensible choices (other people may have others)
1) _args : Use all otherwise unnamed arguments. 2) _3onwards : All arguments from the 3rd onwards.I haven't personally found a need for multiple ranges of variadic arguments, or more complicated chopping (such as getting the last few arguments), and I'd want to hopefully keep this simple if possible!
Section: 20.9.4.3 [meta.unary.prop] Status: New Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-03-09
View other active issues in [meta.unary.prop].
View all other issues in [meta.unary.prop].
View all issues with New status.
Discussion:
I'd like to have an is_range<T, R = void> type trait, which derives from true_type if and only if T can be used in range-based for, and *__begin is convertible to R (where R == void means don't bother checking this condition).
Section: 20.9.4.3 [meta.unary.prop] Status: New Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-03-09
View other active issues in [meta.unary.prop].
View all other issues in [meta.unary.prop].
View all issues with New status.
Discussion:
I'd like to have an is_final<T> type trait, which is true if and only if T is a final type.
Section: 17 [library] Status: New Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-03-09
View other active issues in [library].
View all other issues in [library].
View all issues with New status.
Discussion:
In C++11, all the containers, pair, tuple, etc. always have the relation operators defined for them (==, !=, <, >, <=, >=), even if the contained type does not have them; they just fail to compile if one tries to invoke them. It would be better if those operators were SFINAEed out, so that generic code can then detect it and apply alternate strategies.
A use case I've have for this is when holding stateless objects that don't normally have the relation operators defined for them.
Section: 14.7.3 [temp.expl.spec] Status: New Submitter: Mike Spertus Opened: 2013-03-06 Last modified: 2013-03-09
View other active issues in [temp.expl.spec].
View all other issues in [temp.expl.spec].
View all issues with New status.
Discussion:
This is a proposal to allow specializing templates from within a different namespace. The motivation is that when we declare a new class, it is natural to want to provide associated template specializations. For example, it is really painful that whenever I declare a class, I need to leave my namespace and enter namespace std just to specialize std::less as shown below
namespace A { namespace B { class C {...}; } } namespace std { template <> struct less<C> : binary_function <C, C, bool> { bool operator() (const C & x, const C & y) const {...} }; } namespace A { namespace B { ... // Continue working in A::B } }Instead, I should be able to specialize std::less without having to break out of my namespace:
namespace A { namespace B { class C {...}; template <> struct ::std::less<C> : binary_function <C, C, bool> { bool operator() (const C & x, const C & y) const {...} }; ... // Continue working in A::B } }