| Doc. no. | N3957 |
| Date: | 2014-02-28 |
| Project: | Programming Language C++ |
| Reply to: | Ville Voutilainen <[email protected]> |
Revised 2014-02-28 at 17:02:16 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, and proposed extensions to it.
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 Completed Issues List for issues considered completed (adopted) and Evolution Closed Issues List for issues considered closed (rejected).
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 issue's 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 issues which are defects in or accepted extensions to the Standard move to the formal ISO DR status.
Section: 4.13 [conv.rank] Status: Open Submitter: Jens Maurer Opened: 2012-09-12 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3387.html
Deemed post-C++14 material in Chicago 2013.
Wording available:
The paper contains the proposed wording.
Section: 18.6 [support.dynamic] Status: Open Submitter: Clark Nelson Opened: 2012-08-30 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm
Reviewed by EWG in Portland, author encouraged to revise.
Deemed post-C++14 material in Chicago 2013. Has an associated NB comment, FI 16, although the comment is rejected for C++14.
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: 2014-01-16
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: 18 [language.support] Status: New Submitter: Mike Spertus Opened: 2012-09-22 Last modified: 2014-01-16
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3403.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3492.pdf
Not 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: 2014-01-16
View other active issues in [temp].
View all other issues in [temp].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3405.html
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3601.html
EWG review started, not completed yet. Likely needs a follow-up paper.
Bristol 2013: Encouraged to pursue further. Template parameter deduction for constructors has been split into EWG Issue 60.
Section: 17 [library] Status: New Submitter: Dietmar K�hl Opened: 2012-09-14 Last modified: 2014-01-16
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 (SG6).
Section: 1.10 [intro.multithread] Status: New Submitter: Pablo Halpern Opened: 2012-09-24 Last modified: 2014-01-16
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: 14.1 [temp.param] Status: Open Submitter: Jens Maurer Opened: 2012-09-19 Last modified: 2014-01-16
View other active issues in [temp.param].
View all other issues in [temp.param].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html
Bristol 2013: Maurer expressed surprise at the paper being under discussion, and explained that he doesn't think it can be made to work under current linker environments, and further explained that user-defined equality operators cause confusion and surprises. Maurer said that he'd want Stroustrup to clarify which parts of the paper he would want.
Two-way Straw polls:
Rules for agument expressions:
F: 5 A: 0
Structs without operator==
F: 0 A: 0
Structs with operator==
F: 1 A: 3
The issue is not pushed at this time.
Deemed post-C++14 material in Chicago 2013, Stroustrup expressed interest in writing papers about the subject targeting C++17.
Wording available:
The paper contains the proposed wording.Section: 14.1 [temp.param] Status: New Submitter: Mike Spertus Opened: 2012-09-21 Last modified: 2014-02-28
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.html
There is a closed (extension status) Core issue for this, see Core issue 1643.
Section: 1.10 [intro.multithread] Status: Open Submitter: Robert Geva Opened: 2012-09-21 Last modified: 2014-01-16
View other active issues in [intro.multithread].
View all other issues in [intro.multithread].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3419.pdfHandled by the Concurrency Study Group (SG1).
Section: 30 [thread] Status: Open Submitter: Artur Laksberg Opened: 2012-09-21 Last modified: 2014-01-16
View all issues with Open 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: 20.9 [meta] Status: Open Submitter: Axel Naumann Opened: 2012-09-24 Last modified: 2014-01-16
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/n3437.pdfNot reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).
In Chicago 2013, EWG decided to let SG7 handle this.
Section: 18.8 [support.exception] Status: New Submitter: Aurelian Melinte Opened: 2012-09-20 Last modified: 2014-01-16
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.htmlSection: 8.3.5 [dcl.fct] Status: New Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2014-01-16
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3445.html
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html
Deemed post-C++14 material in Chicago 2013.
Section: 5.2.7 [expr.dynamic.cast] Status: New Submitter: Bjarne Stroustrup Opened: 2012-09-23 Last modified: 2014-01-16
View all issues with New status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf
Deemed post-C++14 material in Chicago 2013.
Section: 20.9 [meta] Status: Open Submitter: Herb Sutter Opened: 2012-01-10 Last modified: 2014-01-16
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, deemed to be handled by the Concepts Study Group (SG8).
Deemed post-C++14 material in Chicago 2013. SG8 isn't including it in their scope for the near future. Voutilainen is planning to write a simplified proposal for C++17.
Section: 14.5.3 [temp.variadic] Status: Open Submitter: Dave Abrahams Opened: 2012-10-16 Last modified: 2014-01-16
View other active issues in [temp.variadic].
View all other issues in [temp.variadic].
View all issues with Open 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.
In Bristol 2013: N3493 may solve parts of the problem. The submitter is encouraged to write a paper, and practical examples are desirable.
N3761 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3761.html seems related.
Section: 17.6.3.4 [hash.requirements] Status: Open Submitter: Matt Austern Opened: 2012-10-23 Last modified: 2014-01-16
View all issues with Open 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.
Bristol 2013: Austern explained that he didn't envision syntax to automate the generation of hash operations but thought that this could potentially be solved by a library. Stroustrup and Austern thought that reflection would be another way to solve this. Van Winkel thought that for the generation of such things, it's perhaps desirable that they aren't generated by default but can be generated on demand when a user-defined type requests such generation. The guidance of the EWG is to propose a solution that handles equality operators and other such things in a more general manner.
EWG expressed long-term interest in this idea in Chicago 2013 for post-C++14. Papers welcome.
Section: 3.4 [basic.lookup] Status: Open Submitter: Jeffrey Yasskin Opened: 2012-10-24 Last modified: 2014-01-16
View all issues with Open 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.Bristol 2013: Stroustrup wondered how unique the name needs to be, and wondered whether parallel builds would have problems ensuring the uniqueness. Naumann pointed out that having an unnamed variable is useful also for cases where you don't want the variable's address to be taken etc. Stroustrup and Van Winkel said this is not tiny, and a proper paper is necessary for this issue.
Chicago 2013: Deemed not as C++14 material, Yasskin or someone else invited to write a paper, straw polls in favor of the feature. Things to consider in the paper: Consider double underscore "__". Can it be used only in local scope? For class members? For globals?
Section: 23.3.6 [vector] Status: Ready Submitter: Nevin Liber Opened: 2012-11-27 Last modified: 2014-01-16
View all issues with Ready 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.
Bristol 2013: Designated for LEWG.
Section: 14.7.3 [temp.expl.spec] Status: Open Submitter: Faisal Vali Opened: 2012-10-27 Last modified: 2014-01-16
View other active issues in [temp.expl.spec].
View all other issues in [temp.expl.spec].
View all issues with Open 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.
Bristol 2013: Defer to Core, with the guidance to reopen the DR mentioned and remove the restriction.
Before this can go over to Core, it needs wording. It's likely that it needs a paper. Vali should create either the wording or the paper.
Section: 21.4.2 [string.cons] Status: Ready Submitter: Nevin Liber Opened: 2012-12-19 Last modified: 2014-01-16
View all issues with Ready 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.
Bristol 2013: Defer to LEWG.
Wording available:
Requires: n < npos and either s shall not be a null pointer or n == 0.
Section: 6.5.4 [stmt.ranged] Status: Open Submitter: Gabriel Dos Reis Opened: 2013-01-12 Last modified: 2014-01-16
View all issues with Open 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;
}
Bristol 2013: Submitter is encouraged to write a paper.
EWG expressed reiterated interest in Chicago 2013 for this idea, deeming it post-C++14 material.
Section: 20.8.9 [bind] Status: Ready Submitter: Chris Jefferson Opened: 2013-01-25 Last modified: 2014-01-16
View all issues with Ready 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!
Bristol 2013: Defer to LEWG.
Section: 20.9.4.3 [meta.unary.prop] Status: Ready Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2014-01-16
View other active issues in [meta.unary.prop].
View all other issues in [meta.unary.prop].
View all issues with Ready 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).
Bristol 2013: Submitter is encouraged to proceed and present to LWG. Apparently LEWG doesn't handle these.
Section: 20.9.4.3 [meta.unary.prop] Status: Ready Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2014-01-16
View other active issues in [meta.unary.prop].
View all other issues in [meta.unary.prop].
View all issues with Ready 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.
Bristol 2013: Submitter is encouraged to proceed and present to LWG. Apparently LEWG doesn't handle these.
Section: 14.7.3 [temp.expl.spec] Status: Open Submitter: Mike Spertus Opened: 2013-03-06 Last modified: 2014-02-28
View other active issues in [temp.expl.spec].
View all other issues in [temp.expl.spec].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3867.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3730.html
There is a closed (extension status) Core issue for this, see Core issue 1077.
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
}
}
Bristol 2013: Stroustrup expressed concern about unqualified name lookup in the specializations, and Voutilainen thought that that just might be the reason why the current rules don't allow it. Gottschling voiced concern about the implementation impact, and Voutilainen suggested asking for a quick review of the overall idea from Spicer. Austern thought that this could be palatable if it's expressed as a set of rewrite rules. Spertus asked about an alternative which is to be able to open another namespace without having to exit the current namespace. This alternative didn't gain success. Spertus to write a paper.
In Chicago 2013, EWG guidance was to work based on the current proposal N3730 without the facility of specializing a namespace-scoped template from inside a class.
Section: 2.2 [lex.phases] Status: New Submitter: Beman Dawes Opened: 2012-11-02 Last modified: 2014-01-16
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3463.htmlSection: 18.1 [support.general] Status: New Submitter: Mike Spertus Opened: 2012-11-03 Last modified: 2014-01-16
View all other issues in [support.general].
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3466.htmlSection: 3.4.2 [basic.lookup.argdep] Status: New Submitter: Dave Abrahams Opened: 2012-10-31 Last modified: 2014-01-16
View other active issues in [basic.lookup.argdep].
View all other issues in [basic.lookup.argdep].
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.htmlSection: 7.1.3 [dcl.typedef] Status: Open Submitter: Walter Brown Opened: 2013-01-11 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3741.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3515.pdf
Reviewed in Chicago 2013, author encouraged to pursue the idea further with revised papers.
Section: 5.19 [expr.const] Status: Open Submitter: Scott Schurr Opened: 2013-03-13 Last modified: 2014-01-16
View all other issues in [expr.const].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3583.pdf
Bristol 2013: We won't move forward with this at this time, but we might want to see a followup paper focusing on the trait.
Section: 6.5 [stmt.iter] Status: Open Submitter: Alan Talbot Opened: 2013-03-17 Last modified: 2014-01-16
View other active issues in [stmt.iter].
View all other issues in [stmt.iter].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3587.pdf
Bristol 2013: Van Winkel pointed out that this allows jumping out of nested loops. Naumann expressed doubt over whether the problem is so big that we need such a big extension to solve it. Van Winkel and Spertus thought that this would likely be a popular feature. Voutilainen thought that it would be beneficial to revisit a lambda solution. Talbot expressed doubt whether that's a suitable solution, syntax-wise and performance-wise. Austern thought that this seems to be in flux, and thought we aren't necessarily ready to choose between the various options. Gottschling thought Vandevoorde's option is nice, since it's still structured. Spertus said he likes the idea of having a control structure be an expression. Austern recommended looking closely at Clause 5 in the follow-up paper.
The author is encouraged to write a follow-up paper.
Section: 3.4.2 [basic.lookup.argdep] Status: Open Submitter: Peter Gottschling Opened: 2013-03-15 Last modified: 2014-01-16
View other active issues in [basic.lookup.argdep].
View all other issues in [basic.lookup.argdep].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3595.pdf
Bristol 2013: Looked at briefly, the EWG thinks this should be considered alongside other ADL proposals.
Section: 3.4.2 [basic.lookup.argdep] Status: New Submitter: Peter Gottschling Opened: 2013-03-15 Last modified: 2014-01-16
View other active issues in [basic.lookup.argdep].
View all other issues in [basic.lookup.argdep].
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3596.pdf
Section: 14.8.2 [temp.deduct] Status: Open Submitter: Mike Spertus Opened: 2013-03-14 Last modified: 2014-01-16
View other active issues in [temp.deduct].
View all other issues in [temp.deduct].
View all issues with Open status.
Discussion:
This issue is split from EWG Issue 9.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html
Bristol 2013: Reviewed and accepted by EWG, needs redrafting before ready for core.
Core pointed out problems in Bristol. Gregor summarized in Chicago 2013 that The primary template might not be the right place to pick constructors from. (Partial) specializations might have completely different constructors. Stroustrup thought that there's only two ways: all specializations have to be in scope, and you look at all of those, or look only at the primary and give an error if that doesn't work. Spertus is encouraged to write a follow-up paper.
Section: 15.5 [except.special] Status: Open Submitter: Herb Sutter Opened: 2013-03-11 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf
Bristol 2013: Voutilainen pointed out that there are previous proposals on similar facilities (http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.html), and that there's existing practice that is different from this proposal (existing practice returns an int, not a bool). Stroustrup thought that he would need convincing examples about the int, and thought that the facility in general needs better motivation. Voutilainen said that it would be best to create a revisions/synthesis paper that covers the existing practice and the previous proposals and improves the motivational examples.
Author is encouraged to revise.
In Chicago 2013, Voutilainen said he plans to work on this issue and create a follow-up paper for C++17.
Section: 20.8.2 [func.require] Status: New Submitter: Philipp Juschka Opened: 2013-03-14 Last modified: 2014-01-16
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm
Section: 2.14.8 [lex.ext] Status: Open Submitter: Richard Smith Opened: 2013-03-13 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3599.html
Bristol 2013:
Straw Poll: Adopt N3599, send to core: SF:2 WF:1 N:6 WA:4 SA:1
No consensus for moving forward as is.
Straw Poll: Revise with additional machinery for compile time string processing
SF: 10 WF: 2 N: 0 WA: 0 SA: 0
Encouragement for Smith and Vandevoorde to revise.
Section: 20.4.1 [tuple.general] Status: New Submitter: Nevin Liber Opened: 2013-03-19 Last modified: 2014-01-16
View all issues with New status.
Discussion:
In 20.4.1p2, the unspecialized std::tuple_size is undefined. It would be a lot more useful if it were defined as an empty struct; that way, it can be used with enable_if for determining whether or not it is valid to use tuple_size, tuple_element and get on the corresponding data structure.
This should go to LEWG.
Section: 5.2 [expr.post] Status: New Submitter: Herb Sutter Opened: 2013-06-06 Last modified: 2014-01-16
View all issues with New status.
Discussion:
Example:
#include <string>
using namespace std;
int main() {
const string{ "Hello" }; // 1: error
"xyzzy" + const string{"Hello"}; // 2: error
typedef const string const_string;
const_string{"Hello"}; // 3: ok
"xyzzy" + const_string{"Hello"}; // 4: ok
unsigned long{0}; // 5: error
42ul + unsigned long{0}; // 6: error
typedef unsigned long unsigned_long;
unsigned_long{0}; // 7: ok
42ul + unsigned_long{0}; // 8: ok
}
Sutter says:
The issue is "lines 1 to 8 below should all work." That they don't is just because of the reason Nikolay pointed out using line 1 below as an example:
> The error is purely syntactic: 'const string' is not a simple-type-specifier
Richard Smith points out the following:
I can't comment on what was noticed in the abstract, but I was certainly aware of all the above cases. And the rules make sense to me: function-style casts are supposed to be function-style, and the above error cases doesn't look like a function call (and not just because you've put the paren next to the type in the function-call-like cases, and added an extra space in the other cases!).
I'm not sure exactly what rules you're proposing, but I hope we don't make this valid:
struct A { int n; }; // ok, struct definition
struct A { 0 }; // might now be an expression?
Regarding using a parenthesized type as a work-around, Sutter explained:
I think it needs to be an open EWG issue after all, because as Johannes pointed out the workaround doesn't work because it can't call multi-argument constructors, such as that
(const vector<int>)( 1, 2 )
drops the 1 on the floor and creates a vector containing two zeroes.
And that it doesn't work for list initializations, such as that
(unsigned int){ 1, 2, 3, 4 } // C compound literal(?!)
doesn't work.
Deemed post-C++14 material in Chicago 2013. A paper is needed.
Section: 6.4.2 [stmt.switch] Status: Open Submitter: Zhihao Yuan Opened: 2013-02-02 Last modified: 2014-01-16
View other active issues in [stmt.switch].
View all other issues in [stmt.switch].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html
Reviewed in Chicago 2013, author is encouraged to pursue this further.
Section: 8.3.1 [dcl.ptr] Status: Open Submitter: M. Wong, R. Silvera, R. Mak, C. Cambly, et al. Opened: 2013-04-29 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3635.pdf
See also issue 26.
According to Wong, this paper was reviewed on the last day in EWG in Chicago 2013, although with no recorder. The summary was that many people liked the 1st solution (AliasGrouping), and authors are encouraged to develop it further.
Section: 13.5.6 [over.ref] Status: Open Submitter: Pascal Costanza Opened: 2013-08-23 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3723.html
Discussed in Chicago 2013: Return object that overloads -> to point to subobject. Wrapper that points into itself. Boost "iterator facade" that uses curiously recursive template pattern that does this. It's a pain. What other motivating use cases demonstrate this is a general problem? Has to be a relation to operator. that we've tried to invent a few times. Extra integer looks odd, more so than hack for operator++. We're not yet convinced problem is general enough to require a language change. Not opposed to change, but feels like it's tail end of bigger problem. Didn't quite like the syntax.
Section: 7.6.1 [dcl.attr.grammar] Status: Open Submitter: Walter Brown Opened: 2013-08-30 Last modified: 2014-01-16
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3744.pdf
Discussed in Chicago 2013:
Poll 4: Conservative approach. SF 3 - 2 - 5 - 0 - 0 SA
Poll 5: Aggressive approach: SF 6 - 1 - 3 - 0 - 0 SA
Poll 6: Support both, with different attributes. SF 4 - 2 - 3 - 1 - 0 SA
Vandevoorde expressed that he likes the idea of having two attributes, one for memoizing and the other for non-side-effecting. Stroustrup and Spertus expressed concern about multiple attributes being confusing. Stroustrup gave his guidance to have a two-part proposal with both the "aggressive" mode and the more conservative mode. Vandevoorde promised his assistance for writing the wording.
Section: 7.1.6.4 [dcl.spec.auto] Status: Open Submitter: Peter Gottschling Opened: 2013-08-30 Last modified: 2014-01-16
View other active issues in [dcl.spec.auto].
View all other issues in [dcl.spec.auto].
View all issues with Open status.
Discussion:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf
Reviewed in Chicago 2013. Stroustrup recommended looking into Vandevoorde's solution of doing a type manipulation instead of running code in a conversion since there doesn't seem to a palatable reason for running code, and thought that the solution should be simplified, and it should be much better than what you can hack today. The author is encouraged to pursue the idea further.
Section: 5.3 [expr.unary] Status: New Submitter: David Rodr�guez Ibeas Opened: 2013-09-05 Last modified: 2014-01-16
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3772.pdf
Section: 3.9 [basic.types] Status: New Submitter: Lawrence Crowl, Bjarne Stroustrup Opened: 2013-10-10 Last modified: 2014-01-16
View all other issues in [basic.types].
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3810.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3820.html
Section: 1 [intro] Status: New Submitter: Ville Voutilainen Opened: 2014-01-16 Last modified: 2014-02-28
View other active issues in [intro].
View all other issues in [intro].
View all issues with New status.
Discussion:
13 extern "C" for Parameters of Function Templates -> request Core to close as NAD, Daveed says aliases with linkage are the solution. 1463 will be opened as an EWG issue to solve this.
92 Should exception-specifications be part of the type system? -> Instruct Core to close 92 as NAD. Maurer points out that he's going to be dealing with the area with TM. The rationale for closing is that EWG doesn't agree that being able to overload on noexcept is worth the trouble, nor does EWG think being able to have pointers-to-functions being different parameter types if they have different noexcept-specifications.
203 Type of address-of-member expression -> new EWG issue, 89.
230 Calls to pure virtual functions -> Instruct Core to close 230 as NAD. Pure virtual functions can be called by non-virtual calls only, and it is by design that virtual calls should never resolve to the definition of a pure virtual function. The behaviour is undefined because implementations aren't required to prevent ending up in the pure virtual function definition. That is also by design.
476 Determining the buffer size for placement new -> new EWG issue, 90.
622 Relational comparisons of arbitrary pointers -> new EWG issue, 91.
623 Use of pointers to deallocated storage -> Instruct Core to close 623 as WP. The behavior is implementation-defined rather than undefined in the current working draft, and thus the requirements are no longer draconian. 312, which was resolved as DRWP points to 623, so also close 623 as DRWP.
687 template keyword with unqualified-ids -> new EWG issue, 92.
728 Restrictions on local classes -> new EWG issue, 93.
755 Generalized lambda-captures -> Instruct Core to close 755 as WP. Generalized lambda-captures are in C++14.
794 Base-derived conversion in member type of pointer-to-member conversion -> Open an EWG issue for 794, 94. Snyder reports he is interested in authoring a paper.
822 Additional contexts for template aliases -> new EWG issue, 95.
914 Value-initialization of array types -> Open an EWG issue for 914 and 1300, 96. Instruct Core to close either (probably 914)as a DUP. Instruct Core not to think EWG has looked at 1300, because EWG hasn't. Include 1326 in the EWG issue, leave that open in Core as well.
947 Deducing type template arguments from default function arguments -> Open an EWG issue, 97, for 947, immediately close as NAD, explaining that the group doesn't think it's generally implementable. Leave the door open (but not the issue :)) for a restricted implementation.
1008 Querying the alignment of an object -> new EWG issue, 98.
1048 auto deduction and lambda return type deduction. -> Instruct Core to reopen 1048 and clarify the issue, since there is implementation divergence. Ask Merrill whether he has implemented what he thought was right. clang seems to be consistent. decltype(f()) is const A in gcc, decltype(b()) is A in gcc. in clang, both are const A.
1077 Explicit specializations in non-containing namespaces -> EWG has an issue for 1077. Link to the core issue from that (done), and vice versa if CWG chair so chooses.
1259 Deleting a POD via a pointer to base -> new EWG issue, 99.
1272 Implicit definition of static data member of const literal type -> new EWG issue, 100.
1300 T() for array types -> Open an EWG issue for 914 and 1300, 96. Instruct Core to close either (probably 914)as a DUP. Instruct Core not to think EWG has looked at 1300, because EWG hasn't. Include 1326 in the EWG issue, leave that open in Core as well.
1326 Deducing an array bound from an initializer-list -> see above
1331 const mismatch with defaulted copy constructor -> Open an EWG issue for 1331, 101. Needs analysis and implementation vendor feedback.
1393 Pack expansions in using-declarations -> Open an EWG issue for 1393, 102. There are other related extension almost-proposals that should be considered in addition to the case in point.
1426 Allowing additional parameter types in defaulted functions -> new EWG issue, 103.
1433 trailing-return-type and point of declaration -> new EWG issue, 104.
1451 Objects with no linkage in non-type template arguments -> new EWG issue, 105.
1461 Narrowing conversions to bit-fields -> Instruct Core to close 1461 as NAD. It would break existing code and EWG doesn't consider the breakage to be worth it. Vandevoorde pointed out valid existing code that initializes bitfields (even with one bit) with -1.
1463 extern "C" alias templates -> new EWG issue, 106, see above about 13.
1469 Omitted bound in array new-expression
1474 User-defined literals and <inttypes.h> format macros -> Instruct Core to close 1474 as NAD. The fix would be to remove UDLs.
1519 Conflicting default and variadic constructors -> Open an EWG issue for 1519, 107. Mark as NAD, there is a work-around and Concepts Lite will make the work-around much easier.
1555 Language linkage and function type compatibility -> Instruct SG12 to handle 1555. (done, SG12 chair has been notified)
1561 Aggregates with empty base classes -> new EWG issue, 108.
1564 Template argument deduction from an initializer list -> new EWG issue, 109.
1577 Unnecessary restrictions on partial specializations -> new EWG issue, 110.
1582 Template default arguments and deduction failure -> new EWG issue, 111.
1586 Naming a destructor via decltype -> new EWG issue, 112.
1643 Default arguments for template parameter packs -> Link 1643 to EWG issue 15 (done) and vice versa.
1657 Attributes for namespaces and enumerators -> Open an EWG issue for 1657, 113. Remember to consider inline namespaces and anon namespaces. Rationale for both namespaces and enumerators is [[deprecated]].
Section: 7 [dcl.dcl] Status: Ready Submitter: Walter E. Brown Opened: 2014-01-01 Last modified: 2014-02-28
View all issues with Ready status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3846.pdf
Issaquah 2014: EWG discussed the paper, and found preference towards option 3, which allows implementations to use useful messages, but doesn't force them to document what they provide, so it was seen superior to the other alternatives. The proposal is expected to go forward to Core, and it has wording already.
Wording available:
The paper contains the proposed wording.Section: 6.5 [stmt.iter] Status: Ready Submitter: Stephan T. Lavavej Opened: 2014-01-17 Last modified: 2014-02-28
View other active issues in [stmt.iter].
View all other issues in [stmt.iter].
View all issues with Ready status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3853.htm
Issaquah 2014: EWG discussed the paper, and found consensus to move the proposal forward to Core, and it has wording already.
Wording available:
The paper contains the proposed wording.Section: 1.10 [intro.multithread] Status: Open Submitter: M. Wong, V. Luchangco, J. Maurer, M. Moir, et al. Opened: 2014-01-20 Last modified: 2014-02-28
View other active issues in [intro.multithread].
View all other issues in [intro.multithread].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3859.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3718.pdf
Issaquah 2014: EWG discussed the paper, and found consensus to move the proposal forward to a Technical Specification.
Section: 9.3 [class.mfct] Status: New Submitter: Matthew Fioravante Opened: 2013-12-08 Last modified: 2014-02-28
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3863.html
Section: 9.2 [class.mem] Status: Open Submitter: J. D. Garcia, X. Li Opened: 2014-01-16 Last modified: 2014-02-28
View all other issues in [class.mem].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3875.pdf
Issaquah 2014: EWG discussed the paper, and the author was present and received feedback to do further work on the paper.
Section: 6.4.2 [stmt.switch] Status: New Submitter: Andrew Tomazos Opened: 2014-01-16 Last modified: 2014-02-28
View other active issues in [stmt.switch].
View all other issues in [stmt.switch].
View all issues with New status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3879.pdf
Section: 1 [intro] Status: Open Submitter: Michael Price Opened: 2014-01-16 Last modified: 2014-02-28
View other active issues in [intro].
View all other issues in [intro].
View all issues with Open status.
Discussion:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3880.html
Issaquah 2014: The paper was presented to EWG, and the author was encouraged to continue working on the idea and to come up with concrete proposals for EWG to vote on.
Section: 13.5 [over.oper] Status: New Submitter: Gabriel Dos Reis Opened: 2014-02-14 Last modified: 2014-02-28
View all other issues in [over.oper].
View all issues with New status.
Discussion:
In c++std-core-14770, Dos Reis suggests that operator[] and operator() should both be allowed to be static. In addition to that, he suggests that both should allow multiple parameters. It's well known that there's a possibility that this breaks existing code (foo[1,2] is valid, the thing in brackets is a comma-expression) but there are possibilities to fix such cases (by requiring parens if a comma-expression is desired). EWG should discuss whether such unification is to be strived for.
Section: 5.3.1 [expr.unary.op] Status: New Submitter: Lisa Lippincott Opened: 2000-02-08 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 203.
Section: 5.3.4 [expr.new] Status: New Submitter: Ben Hutchings Opened: 2004-09-14 Last modified: 2014-02-28
View all other issues in [expr.new].
View all issues with New status.
Discussion:
See Core issue 476.
Section: 5.9 [expr.rel] Status: New Submitter: Herb Sutter Opened: 2007-02-26 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 622.
Section: 5.1.1 [expr.prim.general] Status: New Submitter: Mihai Rusu Opened: 2008-02-27 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 687.
Section: 14 [temp] Status: New Submitter: Faisal Vali Opened: 2008-10-05 Last modified: 2014-02-28
View other active issues in [temp].
View all other issues in [temp].
View all issues with New status.
Discussion:
See Core issue 728.
Section: 4.11 [conv.mem] Status: New Submitter: CH, Detlef Vollman Opened: 2009-03-03 Last modified: 2014-02-28
View other active issues in [conv.mem].
View all other issues in [conv.mem].
View all issues with New status.
Discussion:
See Core issue 794. Jeff Snyder reports he is interested in authoring a paper.
Section: 4.11 [conv.mem] Status: New Submitter: UK Opened: 2009-03-03 Last modified: 2014-02-28
View other active issues in [conv.mem].
View all other issues in [conv.mem].
View all issues with New status.
Discussion:
See Core issue 822.
Section: 5.2.3 [expr.type.conv] Status: New Submitter: Gabriel Dos Reis Opened: 2009-06-10 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 914, Core issue 1300 and Core issue 1326.
Section: 5.3.6 [expr.alignof] Status: New Submitter: Steve Clamage Opened: 2009-11-27 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1008.
Section: 5.3.5 [expr.delete] Status: New Submitter: Herb Sutter Opened: 2010-03-10 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1259.
See also the discussion thread starting at https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9PxiUu0Tr1k/3gextFEMi8sJ.
Section: 9.4.2 [class.static.data] Status: New Submitter: Nikolay Ivchenkov Opened: 2011-03-18 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1272.
Section: 12.8 [class.copy] Status: New Submitter: Daniel Kr�gler Opened: 2011-03-18 Last modified: 2014-02-28
View all other issues in [class.copy].
View all issues with New status.
Discussion:
See Core issue 1331.
Needs analysis and implementation vendor feedback.
Section: 14.5.3 [temp.variadic] Status: New Submitter: Daniel Kr�gler Opened: 2011-09-10 Last modified: 2014-02-28
View other active issues in [temp.variadic].
View all other issues in [temp.variadic].
View all issues with New status.
Discussion:
See Core issue 1393.
There are other related extension almost-proposals that should be considered in addition to the case in point.
Section: 8.4.2 [dcl.fct.def.default] Status: New Submitter: Nikolay Ivchenkov Opened: 2011-12-08 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1426.
Section: 3.3.2 [basic.scope.pdecl] Status: New Submitter: Jason Merrill Opened: 2011-12-20 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1433.
Section: 14.3.2 [temp.arg.nontype] Status: New Submitter: Daniel Kr�gler Opened: 2012-02-01 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1451.
Section: 14 [temp] Status: New Submitter: Daveed Vandevoorde Opened: 2011-08-19 Last modified: 2014-02-28
View other active issues in [temp].
View all other issues in [temp].
View all issues with New status.
Discussion:
See Core issue 1463 and Core issue 13.
Section: 8.5.1 [dcl.init.aggr] Status: New Submitter: Gabriel Dos Reis Opened: 2012-09-29 Last modified: 2014-02-28
View all other issues in [dcl.init.aggr].
View all issues with New status.
Discussion:
See Core issue 1561.
Section: 7.1.6.4 [dcl.spec.auto] Status: New Submitter: Faisal Vali Opened: 2012-10-09 Last modified: 2014-02-28
View other active issues in [dcl.spec.auto].
View all other issues in [dcl.spec.auto].
View all issues with New status.
Discussion:
See Core issue 1564.
Section: 14.5.5 [temp.class.spec] Status: New Submitter: Jeremiah Willcock Opened: 2012-10-19 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1577.
Section: 14.8.2 [temp.deduct] Status: New Submitter: John Spicer Opened: 2012-10-31 Last modified: 2014-02-28
View other active issues in [temp.deduct].
View all other issues in [temp.deduct].
View all issues with New status.
Discussion:
See Core issue 1582.
Section: 12.4 [class.dtor] Status: New Submitter: Steve Clamage Opened: 2012-11-14 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1586.
Section: 7.3.1 [namespace.def] Status: New Submitter: Richard Smith Opened: 2013-08-26 Last modified: 2014-02-28
View all issues with New status.
Discussion:
See Core issue 1657.
Issaquah 2014: EWG wants to point out that it's important to remember to consider inline namespaces and anonymous namespaces, and that the rationale for both namespaces and enumerators is [[deprecated]].