Doc. no. N4206
Date: 2014-10-09
Project: Programming Language C++
Reply to: Ville Voutilainen <ville.voutilainen@gmail.com>

C++ Standard Evolution Active Issues List (Revision R09)

Revised 2014-10-09 at 13:10:07 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.

How to submit an issue

  1. Mail your issue to the author of this list.
  2. Specify a short descriptive title. If you fail to do so, the subject line of your mail will be used as the issue title.
  3. If the "From" on your email is not the name you wish to appear as issue submitter, then specify issue submitter.
  4. Provide a brief discussion of the problem you wish to correct. Refer to the latest working draft or standard using [section.tag] and paragraph numbers where appropriate.
  5. Provide proposed wording. This should indicate exactly how you want the standard to be changed. General solution statements belong in the discussion area. This area contains very clear and specific directions on how to modify the current draft. If you are not sure how to word a solution, you may omit this part. But your chances of a successful issue greatly increase if you attempt wording.
  6. It is not necessary for you to use html markup. However, if you want to, you can <ins>insert text like this</ins> and <del>delete text like this</del>. The only strict requirement is to communicate clearly to the list maintainer exactly how you want your issue to look.
  7. It is not necessary for you to specify other html font/formatting mark-up, but if you do the list maintainer will attempt to respect your formatting wishes (as described by html markup, or other common idioms).
  8. It is not necessary for you to specify open date or last modified date (the date of your mail will be used).
  9. It is not necessary for you to cross reference other issues, but you can if you like. You do not need to form the hyperlinks when you do, the list maintainer will take care of that.
  10. One issue per email is best.
  11. Between the time you submit the issue, and the next mailing deadline (date at the top of the Revision History), you own this issue. You control the content, the stuff that is right, the stuff that is wrong, the format, the misspellings, etc. You can even make the issue disappear if you want. Just let the list maintainer know how you want it to look, and he will try his best to accommodate you. After the issue appears in an official mailing, you no longer enjoy exclusive ownership of it.

Revision History

Issue Status

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.

Active Issues

2. N3387 Overload resolution tiebreakers for integer types

Section: 4.13 [conv.rank] Status: Open Submitter: Jens Maurer Opened: 2012-09-12 Last modified: 2014-07-03

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.

Discussed in Rapperswil 2014. EWG stated that in order to move forward with such a proposal, it would need to provide data about the compatibility/breakage issues, if any.

Wording available:

The paper contains the proposed wording.

4. N3396 Dynamic memory allocation for over-aligned data

Section: 18.6 [support.dynamic] Status: Open Submitter: Clark Nelson Opened: 2012-08-30 Last modified: 2014-07-03

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.

5. N3400 A proposal for eliminating the underscore madness that library writers have to suffer

Section: 16.3 [cpp.replace] Status: New Submitter: Jonathan de Boyne Pollard Opened: 2012-09-21 Last modified: 2014-07-03

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.html

Wording available:

The paper contains the proposed wording.

9. N3601 Implicit template parameters, N3405 Template Tidbits

Section: 14 [temp] Status: Open Submitter: Mike Spertus Opened: 2012-09-22 Last modified: 2014-07-03

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.

10. N3407 Proposal to Add Decimal Floating Point Support to C++

Section: 17 [library] Status: New Submitter: Dietmar Kühl Opened: 2012-09-14 Last modified: 2014-07-03

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.html

Handled by the Numerics Study Group (SG6).

11. N3409 Strict Fork-Join Parallelism

Section: 1.10 [intro.multithread] Status: New Submitter: Pablo Halpern Opened: 2012-09-24 Last modified: 2014-07-03

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.pdf

Handled by the Concurrency Study Group (SG1)

14. N3413 Allowing arbitrary literal types for non-type template parameters

Section: 14.1 [temp.param] Status: Open Submitter: Jens Maurer Opened: 2012-09-19 Last modified: 2014-07-03

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.

15. N3416 Packaging Parameter Packs

Section: 14.1 [temp.param] Status: New Submitter: Mike Spertus Opened: 2012-09-21 Last modified: 2014-07-03

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.

17. N3419 Vector loops and Parallel Loops

Section: 1.10 [intro.multithread] Status: Open Submitter: Robert Geva Opened: 2012-09-21 Last modified: 2014-07-03

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.pdf

Handled by the Concurrency Study Group (SG1).

19. N3429 A C++ Library Solution To Parallelism

Section: 30 [thread] Status: Open Submitter: Artur Laksberg Opened: 2012-09-21 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf

Handled by the Concurrency Study Group (SG1).

Wording available:

The paper contains the proposed wording.

22. N4030, 3745, N3694 Feature-testing recommendations for C++, N3435 Standardized feature-test macros

Section: 18.1 [support.general] Status: Open Submitter: Clark Nelson Opened: 2012-09-18 Last modified: 2014-07-03

View other active issues in [support.general].

View all other issues in [support.general].

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4030.htm

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745.htm

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3694.htm

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htm

Reviewed by EWG in Portland 2012, proceeding in SG10, Feature Test.

Handled by SG10 to the first desired outcome in Chicago2013, no need for further EWG follow-up.

Discussed again in Rapperswil 2014.

Straw poll, has_cpp_attribute as a function-style macro:

SF 7, WF 9, N 4, WA 0, SA 0.

EWG's guidance was for the function-style macro.

23. N3437 Type Name Strings For C++

Section: 20.9 [meta] Status: Open Submitter: Axel Naumann Opened: 2012-09-24 Last modified: 2014-07-03

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.pdf

Not reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).

In Chicago 2013, EWG decided to let SG7 handle this.

24. N3441 Call Stack Utilities and std::exception Extension Proposal

Section: 18.8 [support.exception] Status: New Submitter: Aurelian Melinte Opened: 2012-09-20 Last modified: 2014-07-03

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.html

26. N3538, N3445 Pass by Const Reference or Value

Section: 8.3.5 [dcl.fct] Status: New Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2014-07-03

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.

28. N3449 Open and Efficient Type Switch for C++

Section: 5.2.7 [expr.dynamic.cast] Status: New Submitter: Bjarne Stroustrup Opened: 2012-09-23 Last modified: 2014-07-03

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.

29. N3329 Proposal: static if declaration

Section: 20.9 [meta] Status: Open Submitter: Herb Sutter Opened: 2012-01-10 Last modified: 2014-07-03

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.pdf

Reviewed 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.

30. [tiny] Efficient/Flexible Access to Argument Packs

Section: 14.5.3 [temp.variadic] Status: Open Submitter: Dave Abrahams Opened: 2012-10-16 Last modified: 2014-07-23

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.

Discussed in Rapperswil 2014. Vandevoorde expressed desire to write a paper.

The work done by George Makrydakis at https://github.com/irrequietus/atpp is related.

34. [tiny] Defining hash functions for composite user-defined types is annoying

Section: 17.6.3.4 [hash.requirements] Status: Open Submitter: Matt Austern Opened: 2012-10-23 Last modified: 2014-07-03

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.

35. [tiny] Some concise way to generate a unique, unused variable name

Section: 3.4 [basic.lookup] Status: Open Submitter: Jeffrey Yasskin Opened: 2012-10-24 Last modified: 2014-07-03

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?

Discussed in Rapperswil 2014. Still encouraging a paper, Dennett to contact Yasskin about it.

41. [tiny] In-class explicit specializations forbidden but not partial specializations

Section: 14.7.3 [temp.expl.spec] Status: Open Submitter: Faisal Vali Opened: 2012-10-27 Last modified: 2014-07-03

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.

43. [tiny] simultaneous iteration with new-style for syntax

Section: 6.5.4 [stmt.ranged] Status: Open Submitter: Gabriel Dos Reis Opened: 2013-01-12 Last modified: 2014-07-03

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.

Discussed in Rapperswil 2014. The author is still encouraged to submit a paper. Vandevoorde to contact Dos Reis and Lavavej about it.

48. N3867, N3730 Specializations and namespaces (was "Specializing templates in different namespaces" before the paper)

Section: 14.7.3 [temp.expl.spec] Status: Open Submitter: Mike Spertus Opened: 2013-03-06 Last modified: 2014-07-03

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.

Discussed in Rapperswil 2014.

Gregor and Vandevoorde expressed concern about changing name lookup, and thought that the problem space needs the help of Core experts. Dos Reis expressed concern about expanding the need to do more tentative parsing to resolve ambiguities. Stroustrup requested further study in order to explore the possibilities to find a solution that doesn't cause issues with lookup, and Spertus agreed that further exploration seems wise.

EWG encouraged working further on the problem, looking at alternative solutions.

49. N3463 Portable Program Source Files

Section: 2.2 [lex.phases] Status: New Submitter: Beman Dawes Opened: 2012-11-02 Last modified: 2014-07-03

View other active issues in [lex.phases].

View all other issues in [lex.phases].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3463.html

50. N3466 More Perfect Forwarding

Section: 18.1 [support.general] Status: New Submitter: Mike Spertus Opened: 2012-11-03 Last modified: 2014-07-03

View other active issues in [support.general].

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.html

51. N3490 ADL Control for C++

Section: 3.4.2 [basic.lookup.argdep] Status: New Submitter: Dave Abrahams Opened: 2012-10-31 Last modified: 2014-07-03

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.html

52. N3741, N3515 Toward Opaque Typedefs for C++1Y

Section: 7.1.3 [dcl.typedef] Status: Open Submitter: Walter Brown Opened: 2013-01-11 Last modified: 2014-07-03

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.

56. N3583 Exploring constexpr at Runtime

Section: 5.19 [expr.const] Status: Open Submitter: Scott Schurr Opened: 2013-03-13 Last modified: 2014-07-03

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.

57. N3587 For Loop Exit Strategies

Section: 6.5 [stmt.iter] Status: Open Submitter: Alan Talbot Opened: 2013-03-17 Last modified: 2014-07-03

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.

58. N3595 Simplifying Argument-Dependent Lookup Rules

Section: 3.4.2 [basic.lookup.argdep] Status: Open Submitter: Peter Gottschling Opened: 2013-03-15 Last modified: 2014-07-03

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.

59. N3596 Code Reuse in Class Template Specialization

Section: 3.4.2 [basic.lookup.argdep] Status: New Submitter: Peter Gottschling Opened: 2013-03-15 Last modified: 2014-07-03

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

60. N3602 Template parameter deduction for constructors

Section: 14.8.2 [temp.deduct] Status: Open Submitter: Mike Spertus Opened: 2013-03-14 Last modified: 2014-07-03

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.

63. N3614 unwinding_exception

Section: 15.5 [except.special] Status: Open Submitter: Herb Sutter Opened: 2013-03-11 Last modified: 2014-07-03

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.

65. N3617 Lifting overload sets into function objects

Section: 20.8.2 [func.require] Status: New Submitter: Philipp Juschka Opened: 2013-03-14 Last modified: 2014-07-03

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm

66. N3599 Literal operator templates for strings

Section: 2.14.8 [lex.ext] Status: Open Submitter: Richard Smith Opened: 2013-03-13 Last modified: 2014-07-03

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.

71. N3627 Relaxed switch statement

Section: 6.4.2 [stmt.switch] Status: Open Submitter: Zhihao Yuan Opened: 2013-02-02 Last modified: 2014-07-03

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.

72. N3988 Towards restrict-like aliasing semantics for C++ N3635 Towards restrict-like semantics for C++

Section: 8.3.1 [dcl.ptr] Status: Open Submitter: Hal Finker, Hubert Tong, M. Wong, R. Silvera, R. Mak, C. Cambly, et al. Opened: 2013-04-29 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3988.pdf

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.

Discussed further in Rapperswil 2014.

Straw poll: Encourage continued work?

SF 11, WF 9, N 3, WA 0, SA 0.

Carruth enumerated the following questions, which were encouraged to be answered: should it be ill-formed if this expression has side-effects? Is it an evaluated expression? That changes whether it odr-uses things, whether we have to emit code? Can it be allowed to instantiate templates, and is so what is the point of instantiation?

74. N3723 Extend operator-> to support rvalues

Section: 13.5.6 [over.ref] Status: Open Submitter: Pascal Costanza Opened: 2013-08-23 Last modified: 2014-07-03

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.

75. N3744 Proposing [[pure]]

Section: 7.6.1 [dcl.attr.grammar] Status: Open Submitter: Walter Brown Opened: 2013-08-30 Last modified: 2014-07-03

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.

76. N4035, N3748 Implicit Evaluation of "auto" Variables and Arguments

Section: 7.1.6.4 [dcl.spec.auto] Status: Open Submitter: Peter Gottschling Opened: 2013-08-30 Last modified: 2014-07-03

View all other issues in [dcl.spec.auto].

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4035.pdf

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.

Discussed in Rapperswil 2014.

Straw poll: On the proposal as is:

SF 0 - WF 1 - N 8 - WA 13 - SA 2

Stroustrup said his reading of this is that we agree there's a problem, but we don't think that this is the solution.

Straw poll: See a new proposal based on this one, but with "using auto" only applying to variable and data member initializers:

SF 2 - WF 8 - N 8 - WA 1 - SA 3

Carruth suggested writing a new paper with more rationale/explanation of the tradeoffs, decisions, etc., and Dennett agreed.

78. N3820 Working Draft, Technical Specification -- Array Extensions, N3810 Alternatives for Array Extensions

Section: 3.9 [basic.types] Status: New Submitter: Lawrence Crowl, Bjarne Stroustrup Opened: 2013-10-10 Last modified: 2014-07-03

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

See also issue 125.

79. [tiny] Core issues with extension status

Section: 1 [intro] Status: New Submitter: Ville Voutilainen Opened: 2014-01-16 Last modified: 2014-07-03

View other active issues in [intro].

View all other issues in [intro].

View all issues with New status.

Discussion:

203 Type of address-of-member expression -> new EWG issue, 89. The EWG issue is NAD, too late for a breaking change, instruct CWG to also close as NAD.

476 Determining the buffer size for placement new -> new EWG issue, 90. The EWG issue is NAD -> clarification from CWG requested.

622 Relational comparisons of arbitrary pointers -> new EWG issue, 91. The issue is NAD -> instruct CWG to do the same.

687 template keyword with unqualified-ids -> new EWG issue, 92. -> instruct CWG to reopen, Vandevoorde working on wording.

728 Restrictions on local classes -> new EWG issue, 93.

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. -> issue is NAD, suggest CWG also closes as NAD.

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.

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. -> issue is NAD, suggest CWG closes as NAD.

1272 Implicit definition of static data member of const literal type -> new EWG issue, 100. -> issue is NAD, suggest CWG closes as NAD.

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.

1463 extern "C" alias templates -> new EWG issue, 106, see above about 13.

1469 Omitted bound in array new-expression

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. -> issue is NAD, suggest CWG closes as NAD as well.

1577 Unnecessary restrictions on partial specializations -> new EWG issue, 110. -> issue is NAD, suggest CWG closes as NAD as well.

1582 Template default arguments and deduction failure -> new EWG issue, 111. -> EWG wishes to send this back to CWG for drafting Spicer's suggestion.

1586 Naming a destructor via decltype -> new EWG issue, 112. -> issue is NAD, suggest CWG closes as NAD as well.

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]].

1754 Declaration of partial specialization of static data member template -> new EWG issue, 132 (NAD, lack of motivation for the change)

1798 exception-specifications of template arguments -> new EWG issue, 133 (NAD, insufficient motivation for a change, no desire to have exception specifications in the type system, paper requested if there's desire to reopen)

1826 const floating-point in constant expressions

Straw poll, Rapperswil 2014:

To make it consistent by allowing "const float f = 2.0" to allow use of f in constexpr evaluation:

SF 4 - WF 12 - N 1 - WA 0 - SA 0

-> instruct CWG to reopen and resolve so that const floating point is allowed in constant expressions.

1833 friend declarations naming implicitly-declared member functions

Straw poll, Rapperswil 2014, NAD?

SF 3 - WF 7 - N 7 - WA 2 - SA 0

-> instruct CWG to close as NAD, EWG didn't find sufficient motivation for the extension suggested.

1790 Ellipsis following function parameter pack

1864 List-initialization of array objects

1871 Non-identifier characters in ud-suffix

1876 Preventing explicit specialization

1912 exception-specification of defaulted function

1914 Duplicate standard attributes

1915 Potentially-invoked destructors in non-throwing constructors

1923 Lvalues of type void

1931 Default-constructible and copy-assignable closure types

1934 Relaxing exception-specification compatibility requirements (no link yet)

80. N3846 Extending static_assert

Section: 7 [dcl.dcl] Status: Ready Submitter: Walter E. Brown Opened: 2014-01-01 Last modified: 2014-07-03

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.

81. N3994, N3853 Range-Based For-Loops: The Next Generation

Section: 6.5 [stmt.iter] Status: Ready Submitter: Stephan T. Lavavej Opened: 2014-01-17 Last modified: 2014-07-03

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/n3994.htm

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.

82. N3919, N3859, N3718 Transactional Memory Support for C++

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-07-03

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/n3919.pdf

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.

83. N3863 Private Extension Methods

Section: 9.3 [class.mfct] Status: New Submitter: Matthew Fioravante Opened: 2013-12-08 Last modified: 2014-07-03

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3863.html

84. N3875 Run-time bound array data members

Section: 9.2 [class.mem] Status: Open Submitter: J. D. Garcia, X. Li Opened: 2014-01-16 Last modified: 2014-07-03

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.

86. N3880 Improving the Verification of C++ Programs

Section: 1 [intro] Status: Open Submitter: Michael Price Opened: 2014-01-16 Last modified: 2014-07-03

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.

88. [tiny] Uniform handling of operator[] and operator().

Section: 13.5 [over.oper] Status: Open Submitter: Gabriel Dos Reis Opened: 2014-02-14 Last modified: 2014-07-03

View all other issues in [over.oper].

View all issues with Open 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.

Discussed in Rapperswil 2014. EWG points out that there are more issues to consider here, in terms of other operators, motivations, connections with captureless lambdas, who knows what else, so an analysis paper is requested.

92. [tiny] Core issue 687, template keyword with unqualified-ids

Section: 5.1.1 [expr.prim.general] Status: Open Submitter: Mihai Rusu Opened: 2008-02-27 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

See Core issue 687.

Discussed in Rapperswil 2014. EWG thinks the use of a template keyword in such cases should be allowed. Vandevoorde to write the wording for CWG review.

93. [tiny] Core issue 728, Restrictions on local classes

Section: 14 [temp] Status: New Submitter: Faisal Vali Opened: 2008-10-05 Last modified: 2014-07-03

View other active issues in [temp].

View all other issues in [temp].

View all issues with New status.

Discussion:

See Core issue 728.

94. [tiny] Core issue 794, Base-derived conversion in member type of pointer-to-member conversion

Section: 4.11 [conv.mem] Status: New Submitter: CH, Detlef Vollman Opened: 2009-03-03 Last modified: 2014-07-03

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.

96. [tiny] Core issue 914, Value-initialization of array types, Core issue 1300, T() for array types, Core issue 1326, Deducing an array bound from an initializer-list

Section: 5.2.3 [expr.type.conv] Status: Open Submitter: Gabriel Dos Reis Opened: 2009-06-10 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

See Core issue 914, Core issue 1300 and Core issue 1326.

Discussed in Rapperswil 2014. Dos Reis and Krügler encouraged to write a paper.

98. [tiny] Core issue 1008, Querying the alignment of an object

Section: 5.3.6 [expr.alignof] Status: Open Submitter: Steve Clamage Opened: 2009-11-27 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

See Core issue 1008.

Discussed in Rapperswil 2014. Vandevoorde to write a paper.

101. [tiny] Core issue 1331, const mismatch with defaulted copy constructor

Section: 12.8 [class.copy] Status: Open Submitter: Daniel Krügler Opened: 2011-03-18 Last modified: 2014-07-03

View all other issues in [class.copy].

View all issues with Open status.

Discussion:

See Core issue 1331.

Needs analysis and implementation vendor feedback.

Discussed in Rapperswil 2014. Krügler encouraged to write a paper, including motivating examples.

102. [tiny] Core issue 1393, Pack expansions in using-declarations

Section: 14.5.3 [temp.variadic] Status: Open Submitter: Daniel Krügler Opened: 2011-09-10 Last modified: 2014-07-03

View other active issues in [temp.variadic].

View all other issues in [temp.variadic].

View all issues with Open status.

Discussion:

See Core issue 1393.

There are other related extension almost-proposals that should be considered in addition to the case in point.

Vandevoorde to write a paper and bring it back to EWG. The guidance is to allow multiple names in using-declarations, and also allowing a pack.

106. [tiny] Core issue 1463, extern "C" alias templates, Core issue 13, extern "C" for Parameters of Function Templates

Section: 14 [temp] Status: Open Submitter: Daveed Vandevoorde Opened: 2011-08-19 Last modified: 2014-07-03

View other active issues in [temp].

View all other issues in [temp].

View all issues with Open status.

Discussion:

See Core issue 1463 and Core issue 13.

Discussed in Rapperswil 2014. Vandevoorde to write a paper.

108. [tiny] Core issue 1561, Aggregates with empty base classes

Section: 8.5.1 [dcl.init.aggr] Status: Open Submitter: Gabriel Dos Reis Opened: 2012-09-29 Last modified: 2014-07-03

View all other issues in [dcl.init.aggr].

View all issues with Open status.

Discussion:

See Core issue 1561.

Discussed in Rapperswil 2014. Daryle Walker has an unpublished paper aiming to solve this here. EWG suggests that Dos Reis works with Walker to get the paper on EWG's plate.

111. [tiny] Core issue 1582, Template default arguments and deduction failure

Section: 14.8.2 [temp.deduct] Status: Ready Submitter: John Spicer Opened: 2012-10-31 Last modified: 2014-07-03

View other active issues in [temp.deduct].

View all other issues in [temp.deduct].

View all issues with Ready status.

Discussion:

See Core issue 1582.

Discussed in Rapperswil 2014. EWG wishes CWG to handle this, and to draft to implement Spicer's suggestion.

113. [tiny] Core issue 1657, Attributes for namespaces and enumerators

Section: 7.3.1 [namespace.def] Status: Open Submitter: Richard Smith Opened: 2013-08-26 Last modified: 2014-07-03

View all issues with Open 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]].

Discussed in Rapperswil 2014. Smith is encouraged to write a proposal for EWG review, EWG expects to send it towards CWG without much ado.

114. N4074 Let return {expr} Be Explicit, Revision 2, N4094 Response To: Let return {expr} Be Explicit, N4029 Let return Be Direct and explicit, N3452 (unpublished) Let {x,y,z} => explicit

Section: 6.6.3 [stmt.return] Status: Open Submitter: Herb Sutter Opened: 2014-04-09 Last modified: 2014-10-09

View all other issues in [stmt.return].

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4074.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4094.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4029.pdf

See unpublished paper N3452.

Portland 2012:

Straw polls:

return as in the proposal: SF: 3 F: 2 N: 2 A: 4 SA: 5

arguments as in the proposal: SF: 2 F: 2 N: 1 A: 4 SA: 7

= {} vs. {} as in the proposal: SF: 2 F: 0 N: 4 A: 4 SA: 5

The author interprets these as dead, and does not plan to pursue this further.

Sutter reopened the issue in [c++std-ext-14770], Lavavej and Voutilainen reiterated reasons why the proposal was originally rejected. Sutter has indicated that he wishes to create a revised paper focusing on the return part, this issue is for him to reference in the paper.

Hinnant pointed to his response writeup in [c++std-ext-14883], and it was noted that [c++std-lib-34985] is also related, and mentions a paper by Krügler that would solve some of the library issues without introducing the problems Hinnant writes about.

Dimov presented a different incarnation of some of these problems in [c++std-lib-36408] "map<K,V>::emplace and explicit V constructors", and Krügler pointed out his paper solves that issue as well.

The Library issue related to Dimov's issue report is LWG 2397

Discussed in Rapperswil 2014.

Vandevoorde pointed out that he doesn't like returning an integer value and having that automatically convert to a vector. Vandevoorde said that the same arguments apply as with Josuttis's paper, because there's a difference between conversions and initializations, and that there are differences with auto. Sutter and Stroustrup suggested that the function author should know the return type of their function, so the argument that the return type isn't known doesn't hold water.

Voutilainen pointed out that there is a difference between initializations of local variables and returns, since the former allows deciding whether conversions are allowed, whereas this proposal would remove the ability to make that decision for returns.

Dennett thought that the diagnostic is not problematic because the worst kind of diagnostic is a missing diagnostic, especially ones that change a compiler error to a runtime error. Dennett asked what happens if a function vector f() {return {42};} has new semantics, and Vandevoorde warned that it seems like this would be a breaking change.

Voutilainen emphasized that this will turn compile-time errors into run-time errors, and warned about doing that lightly. Vandevoorde thought that this proposal makes code easier to write but not easier to read. Stroustrup disagreed with that point.

Voutilainen emphasized that in his opinion ownership transfer needs to stand out. Bos asked whether a compromise like return auto(2); would work. Dennett reported he has a wrap_unique() in internal use that solves the problem of having to repeat the type. Vandevoorde explained the difference between returning a value and returning a value constructed (possibly via conversion) from another value. Naumann pointed out the problems in refactoring code that returns a value but is changed to return eg. a vector, the status quo currently diagnoses those, but with this proposal, that wouldn't be the case.

Straw polls:

Proposal:

SF: 2 F: 5 N: 4 A: 3 SA: 5

Like the proposal, but just when braces are used:

SF: 3 F: 8 N: 3 A: 0 SA: 4

Sutter continued revising the proposal aiming for a solution that kicks in when braces are used. The current expectation is that the discussion will continue in Urbana, and there will be more papers related to this area.

N4094 contains a response to this proposal by Hinnant and Voutilainen.

115. N3899 Nested Allocation

Section: 3.8 [basic.life] Status: New Submitter: Lawrence Crowl Opened: 2014-01-20 Last modified: 2014-07-03

View all issues with New status.

Discussion:

See http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3899.html.

116. N4114, N3950 Defaulted comparison operators

Section: 8.4.2 [dcl.fct.def.default] Status: Open Submitter: Oleg Smolsky Opened: 2014-02-19 Last modified: 2014-10-09

View all other issues in [dcl.fct.def.default].

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4114.htm

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3950.html

Discussed in Rapperswil 2014.

Straw polls:

Proposal + the ability to default as global

SF: 10 F: 9 N: 2 A: 1 SA: 0

Proposal + the ability to default as global + the generation of negated operators

SF: 5 F: 9 N: 3 A: 1 SA: 2

Terse syntaxes only

SF: 7 F: 2 N: 4 A: 8 SA: 1

Terse syntaxes in addition

SF: 6 F: 6 N: 5 A: 4 SA: 1

Library solution

SF: 0 F: 0 N: 1 A: 12 SA: 7

Mutable members are not special (participate in the comparisons)

SF: 2 F: 6 N: 2 A: 5 SA: 6

Mutable members make defaulting ill-formed

SF: 3 F: 7 N: 6 A: 3 SA: 1

Mutable members do not participate in generated comparisons

SF: 7 F: 3 N: 0 A: 7 SA: 4

Proposal + the ability to default as global + mutables ill-formed

SF: 12 F: 7 N: 0 A: 1 SA: 2

The guidance of the vote is not very clear, but what seems clear is that EWG more or less encouraged the paper author to come up with a revised proposal.

Wording available:

The paper contains the proposed wording.

118. [tiny] Allow conversion from pointer to array of known bound to pointer to array of unknown bound

Section: 4 [conv] Status: Open Submitter: Richard Smith Opened: 2014-02-15 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

With core issue 393, we're allowing function parameters to have type 'T (*)[]' or 'T (&)[]'. This has always been allowed for variables, and is useful in practice: 

// guaranteed to be passed an actual array, not just a pointer, but the array can be of any size.
void f(int n, int (&a)[]) {
  ... do stuff with first n elements of a ...
}

extern int arr[];
void g() { f(100, arr); }
void h(int *p) { f(100, p); } // error, not an array!

// elsewhere
int arr[100]; // ok, no problem
void i() { f(100, arr); } // error!

Note that if you actually know the bound of 'arr', you *cannot* pass it to f, because you can't pass 'int [100]' glvalues to a 'int (&)[]' parameter.

So, I'd like EWG to consider this extension:

We should allow "array of N T" glvalues to convert to "array of unknown bound of T", and likewise we should allow "cv pointer to array of N T" prvalues to convert to "cv pointer to array of unknown bound of T" prvalues.

Discussed in Rapperswil 2014. EWG wishes to encourage Smith to write a paper for EWG review, EWG expects to send it forwards to CWG without much ado.

119. [tiny] Why no u8 character literals?

Section: 2.14.3 [lex.ccon] Status: Ready Submitter: Richard Smith Opened: 2014-04-14 Last modified: 2014-07-03

View all issues with Ready status.

Discussion:

The discussion thread started at [c++std-ext-14798].

We have five encoding-prefixes for string-literals (none, L, u8, u, U) but only four for character literals -- the missing one is u8 for character literals.

This matters for implementations where the narrow execution character set is not ASCII. In such a case, u8 character literals would provide an ideal way to write character literals with guaranteed ASCII encoding (the single-code-unit u8 encodings are exactly ASCII), but... we don't provide them. Instead, the best one can do is something like this: 

  char x_ascii = { u'x' };
... where we'll get a narrowing error if the codepoint doesn't fit in a 'char'. (Note that this is not quite the same as u8'x', which would give us an error if the codepoint was not representable as a single code unit in UTF-8.)

Is there a good reason for omitting this (useful and natural) functionality?

Discussed in Rapperswil 2014. EWG considers this to be an improvement, and encourages the author to take a proposal with wording to CWG. It's expected that Smith can do so without a separate EWG review.

120. [tiny] CWG 900 and 1498

Section: 12.2 [class.temporary] Status: Open Submitter: Geoffrey Romer Opened: 2014-05-31 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

The discussion thread started at [c++std-core-25298]

The core issues are CWG 900 and CWG 1498

Romer wrote:

The current resolutions of CWG 900 and 1498 don't seem right to me. The NAD rationale for CWG 900 appears to be saying that there is no problem, because the lifetime of _expression_ is extended by being bound to a reference. However, that applies only to the value of _expression_ itself; the lifetimes of any proper sub-expressions of _expression_ are not so extended. CWG 900 may be a little ambiguous about which temporaries it's referring to, but CWG 1498 is not; it's quite explicitly concerned with sub-expression temporaries, so the rationale for CWG 900 definitely does not apply.

To make this concrete, consider the following example, taken from https://svn.boost.org/trac/boost/ticket/7630: 


 std::vector<int> vec;
 for (int val : vec | boost::adaptors::reversed
                    | boost::adaptors::uniqued) {
   // Do stuff with val
 }

The behavior of this code is undefined, because the temporary returned by the subexpression (vec | boost::adaptors::reversed) is destroyed before the loop body is entered, leaving __range's referent holding a dangling reference to it. The adaptors can mostly fix the issue by overloading on rvalue references, but at the cost of a substantial increase in code complexity.

Smith suggested handling this as an EWG issue.

Discussed in Rapperswil 2014. EWG wants a solution, and welcomes a paper tackling the issue. Vandevoorde raised concerns introducing any new lifetime models. Stroustrup pointed out that the end-of-full-expression rule came about to reduce memory footprint compared to the end-of-block rule, and is good for RAII uses. Is it possible to solve the issue by just modifying the specification of a range-for loop?

121. N4086, N3981 Removing trigraphs??!

Section: 2.2 [lex.phases] Status: Ready Submitter: Richard Smith Opened: 2014-05-06 Last modified: 2014-10-09

View other active issues in [lex.phases].

View all other issues in [lex.phases].

View all issues with Ready status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4086.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3981.html

Wording available:

The paper contains the proposed wording.

Discussed in Rapperswil 2014. IBM continues to oppose.

Straw poll:

SF 9, WF 6, N 6, WA 3, SA 2.

Another poll, no neutral option:

SF 10, WF 9, WA 3, SA 3.

Deprecate/Remove/Status Quo, three-way poll:

5/16/6. Removal is still by far the strongest.

The proposal goes forward to CWG. CWG has already reviewed it and designated it ready for voting in Urbana.

122. N3986 Adding Standard support to avoid padding within structures

Section: 9.6 [class.bit] Status: Open Submitter: S. Davalle, D. Gutson, A. Bustamante Opened: 2014-05-06 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3986.pdf

Wording available:

The paper contains the proposed wording.

Discussed in Rapperswil 2014. Not polled yet.

Garcia thought attributes should be explored as a solution rather than using a bitfield of negative width. Stroustrup asked why the facility is per-field rather than per-class. Gutson explained that he doesn't always want pack whole structures, and Stroustrup and Tomazos pointed out that splitting a larger class into smaller ones should solve the problem.

Vandevoorde pointed out implementation issues and asked what happens if a target architecture doesn't support the resulting padding (or the lack of it). It was suggested that the current standard may allow implementations to diagnose such cases anyway.

Naumann made the point that he thinks code should be portable but that object layout cannot be specified in such a strict manner due to architecture differences. Smolsky asked whether there are plans to impose endianness requirements on the representation of built-in types, and voiced concern about a performance impact.

Wong expressed doubt whether a standard solution is necessary, since every vendor has a solution. Vandevoorde replied that that sounds like a good reason to provide a standard solution.

Bos asked why there needs to be this support in classes rather than manipulating bits with a function. Dennett pointed out that this proposal turns things that aren't bitfields into bitfield-like things, because what looks like an int cannot be treated as an int.

Vandevoorde pointed out that alignas is almost a solution, but it doesn't apply to bitfields, and suggested using arrays instead of plain ints for the data that needs to be packed. Stroustrup recommended doing a survey of existing practice.

125. N4025 Exploring classes of runtime size

Section: 3.9.2 [basic.compound] Status: Open Submitter: J. Snyder, R. Smith Opened: 2014-05-23 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4025.pdf

Discussed in Rapperswil 2014, with a fairly long discussion that didn't yield very concrete conclusions.

Straw polls:

Array of runtime bounds:

SF: 2 F: 2 N: 6 A: 11 SA: 2

Objects of dynamic size:

SF: 1 F: 7 N: 7 A: 6 SA: 2

Magic allocation outside of a type:

SF: 0 F: 11 N: 9 A: 1 SA: 0

Nothing:

SF: 2 F: 10 N: 6 A: 4 SA: 0

The group found it difficult to interpret the results, and where to go from here.

Carruth pointed out that it doesn't seem we can agree on an evolution path to take, and perhaps that should be our message to the full committee, and if someone disagrees, they should come up with a better evolution path. Voutilainen pointed out that this is not the first time we have failed to find real consensus about dynamic arrays. Smith said having nothing is the status quo of the C++ standard, and ARBs are what the TS proposes, and there would be a possibility to keep ARBs in a TS without integrating them to the main standard.

126. N4116 Nested Namespace Definition (rev 1), N4026 Nested namespace definition

Section: 3.3.6 [basic.scope.namespace] Status: Open Submitter: Robert Kawulak Opened: 2014-05-23 Last modified: 2014-10-09

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4116.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4026.html

Discussed in Rapperswil 2014.

Straw poll, the full facility (JUST the basic syntactic sugar, no attributes, no aliases, no inline):

SF: 11 F: 5 N: 3 A: 0 SA: 0

The guidance is to provide only the basic syntactic sugar, no attributes, no aliases. Initial wording is necessary before this can proceed to Core. It is expected that EWG will review a revised paper before CWG will review the wording.

127. N4028 Defining a Portable C++ ABI

Section: 3.5 [basic.link] Status: Open Submitter: Herb Sutter Opened: 2014-05-23 Last modified: 2014-07-03

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf

Discussed in Rapperswil 2014

Straw poll: should we encourage Sutter to go ahead:

SF 10 F 8 N 3 A 3 SA 3

Sutter asked the reason for the votes against, Gregor expressed doubt on whether the approach is feasible with regards to the amount of work, Carruth expressed doubt on having two slightly different standard libraries.

Stra poll: language ABI:

SF 12 F 14 N 0 A 1 SA 0

Wong said something like this would be ideal for a Study Group. Wong and Sutter expressed interest in continuing to work on the idea.

128. N4043 Dynarray Allocation Context

Section: 23.3 [sequences] Status: New Submitter: Lawrence Crowl Opened: 2014-05-22 Last modified: 2014-07-03

View other active issues in [sequences].

View all other issues in [sequences].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4043.html

129. N4049 0-overhead-principle violations in exception handling

Section: 15 [except] Status: New Submitter: D. Gutson, A. Bustamante, P. Oliva, M. Diaz Opened: 2014-05-27 Last modified: 2014-07-03

View other active issues in [except].

View all other issues in [except].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4049.pdf

130. N4050 Dynarray Semi-Editorial Issues

Section: 23.3 [sequences] Status: New Submitter: Lawrence Crowl Opened: 2014-05-26 Last modified: 2014-07-03

View other active issues in [sequences].

View all other issues in [sequences].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4050.html

131. N4051 Allow typename in a template template parameter

Section: 14.1 [temp.param] Status: Ready Submitter: Richard Smith Opened: 2014-05-26 Last modified: 2014-07-03

View other active issues in [temp.param].

View all other issues in [temp.param].

View all issues with Ready status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4051.html

Discussed in Rapperswil 2014, approved by acclamation, ready to go to CWG. CWG already reviewed it and designated it ready for voting in Urbana.

135. [tiny] Mutable is part of a lambda-declarator, so when a lambda is mutable, the parentheses aren't optional

Section: 5.1.2 [expr.prim.lambda] Status: New Submitter: Herb Sutter Opened: 2014-07-02 Last modified: 2014-07-03

View all other issues in [expr.prim.lambda].

View all issues with New status.

Discussion:

It has been reported that various people have noticed that it's possible to write


auto lambda = []{};

but not


auto lambda2 = [] mutable {};

In the mutable case, parentheses are required, thus: 


auto lambda3 = []() mutable {};

The proposed consistency fix is to change the grammar to allow omitting the parentheses for mutable lambdas as well.

An additional question EWG needs to decide is whether the empty parentheses could be omitted for other cases besides mutable, such as


[] -> float {return 42;};
[] noexcept {foo();};

136. N4072 Fixed Size Parameter Packs

Section: 14.3 [temp.arg] Status: Open Submitter: Maurice Bos Opened: 2014-05-26 Last modified: 2014-10-09

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4072.html

Discussed in Rapperswil 2014.

Vote: encourage the author to come back with a more complete proposal for ...[N]: SF 8 - WF 9 - N 5 - WA 1 - SA 0.

137. N4110 Exploring the design space of contract specifications for C++

Section: 15 [except] Status: New Submitter: J. Daniel Garcia Opened: 2014-07-06 Last modified: 2014-10-09

View other active issues in [except].

View all other issues in [except].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4110.pdf

138. N4120 Null Coalescing Conditional Operator

Section: 5.16 [expr.cond] Status: New Submitter: Alexander Bock Opened: 2014-07-02 Last modified: 2014-10-09

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4120.pdf

139. N4121 Compile-Time String: std::string_literal<n>

Section: 18.1 [support.general] Status: New Submitter: Andrew Tomazos Opened: 2014-07-04 Last modified: 2014-10-09

View other active issues in [support.general].

View all other issues in [support.general].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4121.pdf