1. Executive summary
We have not met in-person since the February 2020 meeting in Prague because of the global pandemic. Weâre instead holding weekly teleconferences, as detailed in [P2145R1]. We focus on providing non-final guidance, and will use electronic straw polls as detailed in [P2195R0] to move papers and issues forward in a asynchronous manner.
Our main achievements have been:
-
Issue processing: most of the 50 language evolution issues have proposed resolutions, and a large number of them have been voted on through electronic polling.
-
C++23: weâve started work on papers for C++23 and later.
-
Incubation: weâve acted as EWG-I and "incubated" some early papers by providing early feedback to authors.
This paper outlines:
-
The work achieved in §âŻ7 Teleconferences;
-
Lists the §âŻ5 Poll for the August 2021 polling period and explain the §âŻ6 Polling Process (see [P1018r9] for the results of the February 2021 polling period and [P1018r11] for the results of the May 2021 polling period);
-
Lists the remaining outstanding issues in §âŻ8 Remaining Open Issues, some are still open while others are waiting for polling;
2. Paper of note
-
[P1000R4] C++ IS schedule
-
[P0592R4] To boldly suggest an overall plan for C++23
-
[P1999R0] Process: double-check evolutionary material via a Tentatively Ready status
-
[P2195R0] Electronic Straw Polls
-
[P2145R1] Evolving C++ Remotely
3. Tentatively ready papers
Following our process in [P1999R0], we usually mark papers as tentatively ready for CWG. We would usually take a brief look at the next meeting, and if nothing particular concerns anyone, send them to CWG. However, given the pandemic, weâve decided to provide guidance only in virtual teleconferences, and have an asynchronous polling mechanism to officially send papers to CWG or other groups as detailed in [P2195R0].
You can follow the lists of papers on GitHub:
4. Issue Processing
Weâve reviewed 50 Language Evolution issues at the Core groups' request, and have tentative resolutions for most. We donât want to poll all of these at the same time, and therefore only poll a subset in each polling period, reserving other issues for later polling periods. Weâve therefore only poll the "tentatively ready" issues (since theyâre tied to papers, and polled with said papers, as outlined below), as well as the "resolved" issues since telecon attendees believe that prior work has already addressed the issues.
§âŻ8 Remaining Open Issues contains a list of issues which arenât being voted on in this polling period.
5. Poll
The results of the polls which EWG took in the August 2021 polling period are:
5.1. P2138r4 Rules of Design <=>
Wording engagement
-
Highlight: process description of how proposal reviews should work between Language Evolution and Core, as well as between Library Evolution and Library.
-
đł Poll: For the next plenary, put up the following joint Language and Library Evolution motion: P2138r4 "Rules of Design
Wording engagement" as the official process of the C++ Evolution groups.<=>
Poll votes:
SF | F | N | A | SA |
6 | 15 | 3 | 3 | 6 |
Poll outcome: â no consensus. LEWG electronic poll results are similarly distributed.
Salient comments:
- Strongly favor: This is the golden standard for process and a good description of the current process.
- Strongly favor: Formalizing the process weâve agreed to will make it easier to object when we try to rush.
- Strongly favor: We need a checklist and a description for how proposals flow through the committee; itâs unreasonable to continue to do that in an ad-hoc manner.
- Neutral: Not sure evolving processes during covid time is a good idea
- Neutral:Iâm torn on this paper. It gives a clear description of the process of digesting a proposal and the rationale behind it. Iâm all for clear process descriptions - thereâs even an ISO norm for that. But I canât see how it helps adressing bullet point 1 in the list of problems. The scarce ressource of "wordsmiths" is unavoidably tapped in the design cycle (!), effectively sucking the people involved there into a gatekeeping function in the design process, asking them for doing work outside of their group, and possibly eventually stalling the process there. In other words, the former specification review -> design feedback cycle is now embedded into the new design cycle. Looking at the whole process description I can see an almost certain slow-down of the pipeline, an improved quality of the process itself, and the hope for higher quality proposals forwarded to plenary. Unfortunately, improving process quality isnât correlated with improvements in quality of the processed items.
- Against: The problems this process aims to address are plainly real: lots of our limited wording-group bandwidth is consumed by reviewing wording that is unusably incomplete, and disagreements about the design intent of papers approved by design groups have been very problematic. Also, distinguishing papers with approved designs but no wording is simply good process engineering, since they canât be reviewed yet. However, it is not clear that the design groups can reliably evaluate whether wording implements the design intent without duplicating the wording groupâs work. Also, wordsmiths' time is also limited, and while thereâs no requirement that they agree with a proposal to review its initial wording, the natural tendency would be to spend their limited time on those that they favor. It doesnât seem right to subject proposals to that sort of pocket veto. A wording review group would of course be well within its rights to suspect that a paperâs wording might not be ready and deputize one of its members to ascertain that fact and communicate it to the author (who would be just as capable of securing help with it as they would be under this proposal). While the paper discusses means of accelerating urgent proposals, it is nonetheless plain that this process would in general extend the review process. Thatâs not intrinsically undesirable, but lengthening the process by fiat (rather than, say, because implementation concerns have been raised) is of questionable value. Itâs a little unreasonable to require a notional author of one paper to attend every in-person meeting (when those are happening) for years in case one of the many reviews for it occurs at one of them. In particular, having a "park for further design feedback" stage in addition to a "Tentatively Wording" stage seems gratuitous.
- Against: Iâm not a fan of the requirement that wording must exist to advance out of (L)EWG. My experience suggests that this actively causes harm. What weâve seen is that authors now see that they need wording, so they spend time writing wording. The problem is, the wording is often bad anyway -- so you end up with a paper with potentially pages of wording that doesnât really help explain the design because the authors spent time writing bad wording that could have been spent writing clearer motivation, examples, prose, etc. Or the author knows that they canât write wording, so they go try to get wording review for a paper that may just not be a good design, which ends up not being a good use of the wordsmithâs time either. Even when the wording is fine, itâs just actively distracting from the discussion - which should be at this point about the design. So you get comments about wording issues that are, frankly, completely irrelevant and wholly unproductive. I think the best thing you could say about requiring wording is that itâs simply a waste of time in that the author had to spend their time producing wording earlier than necessary. The presented problem (papers show up to CWG/LWG with poor wording) can be solved by just requiring that papers show up to CWG/LWG with good wording - requiring EWG/LEWG to see it seems like a completely needless extra step in the process.
- Against: The proposed approach further complicates already complicated committee workflow without solving the real issue in the committee. People who used to ignore the rules will continue ignore the rules.
- Abstain: I donât care. The proposal would change nothing in practice
- Strongly against: This paper: does not make any distinction between tiny improvements and huge feature changes; does not acknowledge the need for quicker turn-around on National Body comments during the Committe Draft review stage; incorrectly assumes that the perceived quality issues with recent proposals relates to a lack of formalized process rather than a failure on the part of experienced WG21 participants to actively help to improve proposals; introduces unhelpful gatekeeping and obscured hurdles for new WG21 participants to jump through. Not convinced this will improve processes and am concerned it will cause contributor burnout. This proposal will have the following effects if adopted by LEWG: 1. It will cement a complex and baroque process even further into WG21. 2. It will increase the already high gatekeeper discrimination of proposals. 3. It will allow LWG to discriminate against LEWG by discounting their consensus findings. 4. It will place unbounded decision power on individuals with undefined credentials. Hence it is unconscionable of me to vote anything but strongly against.
- Strongly against: We should not optimize our process against small papers or against new participants.
- Strongly against: This paper bloats the process with unnecessary checks and abdicates the responsibility of actually vetting the design from the initial design groups to people later in the stage. The time to check for deployment experience and implementation experience is in the incubator and design groups, not before plenary when things are ALMOST ready to head out the door. The proposal also adds mandatory waiting times, rather than leaving it discretionary-by-default, and requires chairs and other individuals to lodge special exceptions in more cases (not less) to move a paper forward. Nothing about this paper improves the process in a material or tangible way that benefits the proposal process, and all it does is add in more places for a proposal to fail and be sent all the way back to the beginning of the process. As a person who ahd to carry a few proposals that suffered from that, this paper is perhaps the worst possible path forward I can imagine for the evolution of C++.
- Strongly against: This paper will have disastrous consequences on WG21 that the committee, its members, and proposal writers are wholly unprepared to deal with. If the idea is that, instead of an open process, we should endeavor to make improving C++ so difficult that it makes COBOLâs submission process look easy or similar by comparison, then I suppose this paper is "working as intended". If this paper moves through to plenary and is adopted I can see several people simply not participating in C++ anymore. But then again, making the process less accessible may be the point?
5.2. P2266r1 Simpler implicit move
-
Highlight: In C++20,
statements can implicitly move from local variables of rvalue reference type; but a defect in the wording means that implicit move fails to apply to functions that return references. C++20âs implicit move is specified via a complicated process involving two overload resolutions, which is hard to implement, causing implementation divergence. We fix the defect and simplify the spec by saying that a returned move-eligible id-expression is always an xvalue.return -
đł Poll: Forward P2266r1 "Simpler implicit move" to Core for C++23.
Poll votes:
SF | F | N | A | SA |
11 | 14 | 5 | 2 | 2 |
Poll outcome: â consensus. However, the against votes are from implementors, and bring relevant new information. This topic needs to be re-discussed, and might fail a plenary vote.
Salient comments:
- Strongly Favor: This is a bugfix that unifies handling. Should have been the case from the beginning.
- Strongly Favor: This makes the language much more pleasant to use, and fixes a decades-old problem of returning references to locals.
- Strongly Favor: This is a sensible improvement for the rules on implicit move.
- Strongly Favor: Fixing these kind of corner cases makes the language more consistent and easier to use and teach.
- Strongly Favor: The great talk on C++Now 2021 explained everything.
- Favor: The
case is unfortunate but overall itâs a simpler rule.decltype ( auto ) - Neutral: I am in favor of most of this proposal, however the interactions with decltype(auto) have me slightly concerned it will cause more surprising behavior. I cannot decide either way.
- Neutral: Iâm in two minds about this: on the one hand, the proposal seems useful and matches what some users expect, on the other hand, this is adding even more magic to a part of the language thatâs already full of implicit rules that are increasingly hard to keep in mind, and this will change what some other users expect.
- Against: The rule change appears reasonable, but Arthurâs implementation did reveal breaks in real code, and the implementation experience has not been discussed in committee. I do not believe this is ready to move to core.
- Against: I was in favor of this until we started getting implementation experience with it. The implementation work done in Clang exposed issues in the MSVC STL headers (among others) where code stopped compiling. I donât think this goes far enough to keep working code working, as this turned out to be a disruptive change.
- Strongly Against: This has, as far as I understand, not been implemented nor tested. Yet it changes the meaning of currently-valid code. Until we have reasonable evidence that it has been implemented this should not move forward.
- Strongly Against: The implementation in clang ended up causing a ton of failures in existing code, particularly in the MSVC headers. Weâve been dealing with the fallout from the clang-implementation for about a week and a half now, and it is really painful so far.
5.3. P2128r5 Multidimensional subscript operator
-
Highlight: user-defined types can define a subscript operator with multiple arguments to better support multi-dimensional containers and views, for example
.template < class ... IndexType > constexpr reference operator []( IndexType ...); -
đł Poll: Forward P2128r5 "Multidimensional subscript operator" to Core for C++23.
Poll votes:
SF | F | N | A | SA |
20 | 11 | 1 | 2 | 1 |
Poll outcome: â consensus.
Salient comments:
- Strongly Favor: The language allows expressing a difference between invocation and indexing for single-element forms but not for multi-element forms; with this proposal, that inconsistency is fixed, and programmers who want to make the difference clear can do so, going forward.
- Strongly Favor: This is why we deprecated comma inside the subscript expression. Given the small number of cases where this is used that have so far been reported I see no problem with moving ahead with this for C++23.
- Strongly Favor: Avoids hijacking the function call operator for subscription.
- Strongly Favor: We would adopt this as soon as possible if/when made available.
- Favor: This is natural extension of the syntax, however I am not convinced with repurposing syntax, before making it ill-formed for at least one standard.
- Favor: This is one of those questions that comes up again and again, and the status quo is made worse by the existence of comma expressions, which give the illusion that we already support this feature. The comma expression behavior is unintuitive and surprising (and deprecated since C++20 in order to make room for this feature). Letâs fix that.
- Against: Iâm not comfortable with the fact that both a[1, 2, 3] and a(1, 2, 3) might be valid at the same time, but mean totally different things. I would like to see restrictions against a type having both operator() and operator[], or at least a discussion of this issue
- Against: Iâm not sold on the motivation and value of this change. While true, the question is pretty common, but so is the answer and where it emerged the programmer could pick one of 3 ways, each straightforward. Strange, that the 3 are not the same we see in the paper, the baseline, that is to use a named finxtion is not even mentioned. And the code that uses .At(x, y, z) may have a few extra characters but is simple to read and write. Has less gotchas than the other 2 ways -- using other operator like () or using an indexing object. It also solves the "generic code" problem. Unfortunate that our standard lib did not follow the guidelines of the era and only introduced a .at() function with a different contract. If the language had this, I probably could find a use somewhere but remain skeptic it would take over in general due to the many existing libraries. Weâd just have the N+1 problem for long time. And keep writing shims for generics. My gut tells me that if the paper did have the non-member op[] with demonstration that I could use it with the old libs and make my code switch to a single [] syntax, that might switch me to F. But canât tell without looking at all the fallout.
- Strongly Against: This doesnât actually add significant capability, but it does add confusion.
5.4. P2036r2 Changing scope for lambda trailing-return-type
-
Highlight: the way that name lookup works in lambdas is surprising: it behaves differently in the trailing-return-type than it does in the lambda body. The current behavior is surprising and error-prone. The proposed change treats the trailing-return-type like the function body rather than treating it like a function parameter.
-
đł Poll: Forward P2036r2 "Changing scope for lambda trailing-return-type" to Core for C++23. Treat it as a Defect Report.
Poll votes:
SF | F | N | A | SA |
19 | 11 | 0 | 0 | 1 |
Poll outcome: â consensus.
Salient comments:
- Strongly Favor: Names in a lambda should be looked up with a consistent set of rules
- Strongly Favor: Colleagues expect the behavior this paper proposes rather than the behavior without.
- Strongly Against: This has, as far as I understand, not been implemented nor tested. Yet it changes the meaning of currently valid code.
5.5. P2334r1 Add support for preprocessing directives elifdef
and elifndef
-
Highlight: the
and#ifdef
preprocessing directives exist today as shorthand for#ifndef
and#if defined(identifier)
, respectively. However, no analogous shorthand preprocessing directives exist for#if !defined(identifier)
and#elif defined(identifier)
. Add two new preprocessing directives#elif !defined(identifier)
and#elifdef
that exactly parallel the functionality supplied in the existing#elifndef
and#ifdef
directives.#ifndef -
đł Poll: Forward P2334r1 "Add support for preprocessing directives
andelifdef
" to Core for C++23.elifndef
Poll votes:
SF | F | N | A | SA |
11 | 13 | 9 | 3 | 2 |
Poll outcome: â consensus.
Salient comments:
- Strongly Favor: Compatibility with the C preprocessor is important. I have had colleagues asking why this is missing in previous versions of C/C++
- Strongly Favor: Even though not strictly necessary, the gap closed by this proposal looks so obvious in hindsight that I canât find a good reason to object to that.
- Strongly Favor: Speaking for myself, Iâve wanted this feature for nearly as long as Iâve been programming in C++. Given that C is adopting this change to the preprocessor, I donât see how we could reasonably refuse to adopt it.
- Strongly Favor: It fills a hole that people have been complaining about for 40 years; WG14 already adopted the feature and a diverging preprocessor would be Very Bad.
- Favor: While tweaks to the preprocessor arenât the best extensions we could spend our time on, this seems reasonable.
- Favor: We would prefer the preprocessor be, as closely as possible, the same between C and C++.
- Favor: In a vacuum, optimizing conditional compilations when we should try to have less of it is a waste of time. But WG14 is forcing our hand, the work was done, users like it, ship it.
- Favor: Compatibility with C is important, changes in that should be adopted unless there is a good reason not to. Here we have no reason. If it was not coming up from C, Iâd vote SA as the motivation is moot and the change not necessary for anything.
- Favor: C compat.
- Favor: This proposal is trivial; it might not be worth the bother, but alignment with C makes it plainly desirable.
- Favor: Given WG14âs interest in this, too, this seems helpful.
- Favor: Keeps C++ aligned with upcoming changes in C. Aligns with user expectations. Seems like thereâs some good and no harm here at all.
- Favor: Iâm not thrilled by adding features to the preprocessor, but this seems to be liked by WG14, making this a C23 compatibility issue.
- Favor: A simple and useful facility.
- Favor: We should minimize preprocessor usage, but this seems straightforward
- Neutral: Folks have asked for this for years, but this is just a compatibility thing. I care neither way.
- Against: Let us not extend the preprocessor any further. It is okay for PP code to be ugly as hell, this way we will get proper alternatives faster.
- Against: It is worrying that on implementations without this feature, uses of these directives can still compile but not do what you want: #if 0 ... #elifdef Y ... #endif is valid today and simply preprocesses to nothing without checking Y.
- Against: This does not bring new functionality to the language, does not solve real world problem. It does not worth committee time.
- Strongly Against: As far as I understand this has not been implemented or tested. This creates bifurcation in the preprocessor (between C and C++, between new and old), in an area that is specifically used to deal with different compiler versions... but this feature cannot be used that way since it doesnât exist in current and older versions.
- Strongly Against: Completely redundant useless feature, adds unnecessary complexity to preprocessor. Adding it to C was a mistake which we shouldnât repeat.
5.6. P2066r7 Suggested draft TS for C++ Extensions for Transaction Memory Light
-
See [P1875r2] for discussion.
-
Current TS [N4514]: ISO/IEC TS 19841:2015 Technical Specification for C++ Extensions for Transactional Memory.
-
Highlight: transactions can be expressed with atomic statements of the form
.atomic do { /* work goes here */ } -
đł Poll: Forward P2066r7 "Suggested draft TS for C++ Extensions for Transaction Memory Light" to Core to become the Transactional Memory TS v2.
Poll votes:
SF | F | N | A | SA |
6 | 12 | 3 | 0 | 1 |
Poll outcome: â consensus.
Salient comments:
- Strongly Favor: Looks like good MVP for TS.
- Strongly Favor: Our last hope to see transactional memory TS actually implemented.
- Strongly Favor: The UK NB is happy to see this. Thereâs useful section âquestions for TS deploymentâ explaining what is hoped for from the TS process.
- Favor: This feature helps users writing safer code without the need of understanding all of the possibly non-obvious interactions of atomics. In particular when thereâs more than one atomic involved.
- Favor: This looks like an marked improvement over the first TS, and hopefully will permit gathering some experience with transactional memory use in C++.
- Favor: Not sure what the goal here is, but sure. Worth noting that we have a Reflection TS that nobody has implemented.
- Favor: Recent reflector discussions seem to have established that this proposal has the correct degree of maturity to become a Technical Specification; the implementation experience one hopes to derive via that process will be valuable.
- Neutral: The paper lacks motivation and implementers of compiler and chips do not seem super enthusiastic about it. Only ARM seems to have the hardware support.
- Strongly Against: It is a huge mistake to re-use "atomic", which we have already been shipping as a templated type for over a decade. It may limit future design choices. Once this TS is out there, the bar for changing this contextual keyword is much, much higher. This isnât even one of the questions being asked of the TS deployment. A word that isnât quite so common would be far better.
5.7. P2360r0 Extend init-statement to allow alias-declaration
-
Highlight: This is currently valid
but this isnâtfor ( typedef int T ; T e : v ) /* something */ ;
. Make the later one valid.for ( using T = int ; T e : v ) /* something */ ; -
đł Poll: Forward P2360r0 "Extend init-statement to allow alias-declaration" to Core for C++23.
Poll votes:
SF | F | N | A | SA |
13 | 12 | 7 | 2 | 0 |
Poll outcome: â consensus.
Salient comments:
- Strongly Favor: An obvious fix with no side effects
- Strongly Favor: Itâs surprising that it doesnât work already; removing discrepancies between typedef and using here is a good thing
- Favor: Once again, not strictly a necessary feature thatâs proposed here. But a feature that fixes an inconsistency, that is allegedly easy to implement, and that breathes "modern" is a good thing.
- Neutral: On one side I agree that it is an inconsistency and overlook, I see no practical reason for any client to notice the difference. Accepting the change improves the language but I canât evaluate the implementation cost. If itâs provably low, then I vote F. If itâs adopted it should be a DR to close the incosistency gap for good. And that rises the bar even more. If restricted to just for C++23 onwards I more lean to A.
- Against: This paper offers to fix an inconsistency to a grammar that we donât know make sense and the code it allows to write is unlikely to pass many code reviews.
- Against: This needs an implementation and testing.
5.8. P2246r1 Character encoding of diagnostic text
-
Highlight: the standard provides a few mechanisms that suggest an implementation issues a diagnostic based on text written in the source code. However, the standard does not uniformly address what should happen if the execution character set of the compiler cannot represent the text in the source character set. Because the display of diagnostic messages should be merely a matter of Quality of Implementation, the proposal is to place no character set related requirements on the diagnostic output with the understanding that implementations will do what makes the most sense for their situation when issuing diagnostics in terms of which characters need to be escaped or otherwise handled in a special way.
-
đł Poll: Forward P2246r1 "Character encoding of diagnostic text" to Core for C++23.
Poll votes:
SF | F | N | A | SA |
12 | 19 | 1 | 0 | 0 |
Poll outcome: â consensus.
Salient comments:
5.9. P2314r2 Character sets and encodings
-
Highlight: switch C++ to a modified "model C" approach for universal-character-names as described in the C99 Rationale v5.10, section 5.2.1. Introduce the term "literal encoding". For purposes of the C++ specification, the actual set of characters is not relevant, but the sequence of code units (i.e. the encoding) specified by a given character or string literal are.
-
đł Poll: Forward P2314r2 "Character sets and encodings" to Core for C++23.
Poll votes:
SF | F | N | A | SA |
14 | 12 | 2 | 0 | 0 |
Poll outcome: â consensus.
Salient comments:
5.10. P2316r1 Consistent character literal encoding
-
Highlight: character literals in preprocessor conditional are changed to behave the same way as they do in C++ expressions. For example,
is not currently guaranteed to behave the same in a preprocessor condition as it is in a C++ expression.'A' == '\x41' -
đł Poll: Forward P2316r1 "Consistent character literal encoding" to Core for C++23. Treat it as a Defect Report.
Poll votes:
SF | F | N | A | SA |
16 | 15 | 0 | 1 | 0 |
Poll outcome: â consensus.
Salient comments:
6. Polling Process
For each poll, participants are asked to vote one of:
-
Strongly in favor
-
In favor
-
Neutral
-
Against
-
Strongly against
Participants also have the option to abstain from voting on a particular poll. They are asked to comment on each poll. This comment is mandatory, as it helps the chair determine consensus.
7. Teleconferences
Here are the minutes for the virtual discussions that were held since the Prague meeting in February 2020:
- 2020-04-09 Issue Processing
- 2020-04-15 Issue Processing
- 2020-04-23 Issue Processing
- 2020-04-29 Issue Processing
- 2020-05-07 Issue Processing
- 2020-05-13 Issue Processing
- 2020-05-21 A General Property Customization Mechanismâ[P1393R0] (P1393 tracking issue)
- 2020-06-10 Reviewing Deprecated Facilities of C++20 for C++23â[P2139R1] (P2139 tracking issue)
- 2020-06-18 C++ Identifier Syntax using Unicode Standard Annex 31â[P1949R4] (P1949 tracking issue)
- 2020-06-24 Extended floating-point types and standard namesâ[P1467R4] (P1467 tracking issue)
- 2020-07-02 Allow Duplicate Attributes, Attributes on Lambda-Expressionsâ[P2156R0] (P2156 tracking issue) and [P2173R0] (P2173 tracking issue)
- 2020-07-08 Pointer lifetime-end zap and provenance, tooâ[P1726R3] (P1726 tracking issue)
- 2020-07-16 Guaranteed copy elision for return variablesâ[P2025R1] (P2025 tracking issue)
- 2020-07-30 Reviewing Deprecated Facilities of C++20 for C++23, Removing Garbage Collection Supportâ[P2139R2] (P2139 tracking issue) and [P2186R0] (P2186 tracking issue)
- 2020-08-05 Transactional Memory Lite Support in C++â[P1875R0] (P1875 tracking issue)
- 2020-08-19 Freestanding Language: Optional
, Mixed string literal concatenationâ[P2013R2] (P2013 tracking issue) and [P2201R0] (P2201 tracking issue):: operator new - 2020-08-27 Exhaustiveness Checking for Pattern Matchingâ[P1371R3] (P1371 tracking issue)
- 2020-09-02
- a simple, scannable preprocessor-based resource acquisition methodâ[P1967R2] (P1967 tracking issue)#embed - 2020-09-10 A pipeline-rewrite operatorâ[P2011R1] (P2011 tracking issue)
- 2020-09-16 Pattern matching: inspect is always an expressionâ[P1371R3] (P1371 tracking issue)
- 2020-09-24 C++ Identifier Syntax using Unicode Standard Annex 31, Member Templates for Local Classesâ[P1949R6] (P1949 tracking issue) and [P2044R0] (P2044 tracking issue)
- 2020-09-30 Narrowing contextual conversions to bool, Generalized pack declaration and usageâ[P1401R3] (P1401 tracking issue) and [P1858R2] (P1858 tracking issue)
- 2020-10-08 Compound Literals,
â[P2174R0] (P2174 tracking issue) and [P1938R1] (P1938 tracking issue)if consteval - 2020-10-14 Inline Namespaces: Fragility Bites, Trimming whitespaces before line splicingâ[P1701R1] (P1701 tracking issue) and [P2223R0] (P2223 tracking issue)
- 2020-10-22 Issues Processing
- 2020-10-28 Issues Processing
- 2020-11-05 Deducing
âP0847R5 (P0847 tracking issue)this - 2020-11-19
in pattern matchinggoto - 2020-12-03
: decay-copy in the languageâP0849R5 (P0849 tracking issue)auto ( x ) - 2021-01-14 Polls
- 2021-01-20 Final polls preparation
- 2021-01-28 P2012 Fix the rangeâbased for loop
- 2021-02-03 P2280 Using unknown references in constant expressions
- 2021-02-11 P1974 Non-transient constexpr allocation using
propconst - 2021-02-17 P2242 Non-literal variables (and labels and
s) ingoto
functionsconstexpr - 2021-02-25 P1371 pattern matching: implementation experience pattern matching now has fairly capable prototype implementation and in this session it will be both demonstrated and described. Bruno, the core implementer, will also field any implementation related questions surrounding the proposal. See the Godbolt demo.
- 2021-03-02 P2279R0 We need a language mechanism for customization points joint EWG+LEWG session
- 2021-03-11 P2285 Are default function arguments in the immediate context?
- 2021-03-17 P2266 Simpler implicit move
- 2021-03-25 P2128 Multidimensional subscript operator
- 2021-03-31 P2036 Changing scope for lambda trailing-return-type, and P2287 Designated-initializers for base classes
- 2021-04-08 Pattern matching identifier patterns syntax:
vslet
vs none Introducing bindings inside pattern matching: Unqualified identifier within pattern matching must have well defined meaning. Published version of the paper (P1371R4) proposed using case keyword to disambiguate names between identifier expressions and introducing named binding. This direction raised some concerns within committee and authors want to propose another way of resolving the ambiguity. After the presentation authors would like to have a poll to secure committee approval on the proposed direction.auto - 2021-04-22 P2334 Add support for preprocessing directives
andelifdef
, and P2246 Character encoding of diagnostic textelifndef - 2021-04-28 Final discussion of the polls, and P2066 Suggested draft TS for C++ Extensions for Minimal Transactional Memory
- 2021-05-06 P2314 Character sets and encodings, and quick review of r2 for P2280 Using unknown references in constant expressions
- 2021-05-12 P2255 A type trait to detect reference binding to temporary
- 2021-05-20 P2025 Guaranteed copy elision for named return objects
- 2021-05-26 P2041 Deleting variable templates
- 2021-06-03 P1967
â a simple, scannable preprocessor-based resource acquisition method#embed - 2021-06-14 Joint session with LEWG on P2138 Rules of Design
Specification engagement<=> - 2021-06-23 P1701 Inline Namespaces: Fragility Bites
- 2021-07-01 P2360R0 Extend init-statement to allow alias-declaration, and P2290 Delimited escape sequences, and P2316 Consistent character literal encoding
- 2021-07-07 P2392R0 Pattern matching using
andis as - 2021-07-21 P2350 constexpr class
- 2021-07-29 P1169
static operator () - 2021-08-04 P2347 Argument type deduction for non-trailing parameter packs
- 2021-08-12 P2355 Postfix fold expressions
- 2021-08-26 P2295 Support for UTF-8 as a portable source file encoding and P2362 Remove non-encodable wide character literals and multicharacter wide character literals
- 2021-09-01 P2414R1 Pointer lifetime-end zap proposed solutions
8. Remaining Open Issues
The following table lists all remaining open issues referred to EWG by Core or Library. Some of them are ready to be polled but are held back from the polling periods to limit the number of polls in this round.
From |
# |
Title |
Notes |
Resolution |
Core |
Explicit instantiation of in-class |
A Note 2020-04-29 Tentative agreement: This should be well-formed. SF 1 F 10 N 2 A 1 SA 0Â JF emailed EWG / Core about this. Davis: the current name lookup approach which Core is taking in p1787 would disallow this. Supporting this is possible, it would be inconsistent, but would also be a feature. Notes 2020-10-22: wait until p1787 is voted into the working draft, because itâs making this behavior intentional. At that point, we can vote on marking the issue as Not a Defect. No objection to unanimous consent. |
â»ïž | |
Core |
Non- |
[Detailed description pending.] Hubert: question over the role of the For A userâs desire for wanting to suppress implicit instantiation can arise for different reasons: To reduce space in object files, executables, etc. and similarly to reduce the number of input symbols to the linker To reduce compile time in performing semantic analysis for instantiations whose definitions are provided elsewhere To control point-of-instantiation, avoiding contexts where the requisite declarations are not declared The special rule around inline functions allows Consider the following as a translation unit:
Marking the template definition The issue initially points out that this use of the I am not sure if CWG is asking EWG a specific question other than the general "we do not believe this is a wording or obvious consistency issue; is this an issue in terms of design?" Meeting: Hubert forked the thread on the reflector. Might want the education SG to take a look, or might want a paper. Meeting 2020-10-28: Inbal will try to put together the wording, to prove / disprove whether this is a defect. |
â»ïž | |
Lib |
initializer_list assignability |
std::initializer_list::operator= [support.initlist] is horribly broken and it needs deprecation: std::initializer_list<foo> a = {{1}, {2}, {3}}; a = {{4}, {5}, {6}}; // New sequence is already destroyed. Assignability of initializer_list isnât explicitly specified, but most implementations supply a default assignment operator. Iâm not sure what [description] says, but it probably doesnât matter. Proposed resolution: Edit [support.initlist] p1, class template initializer_list synopsis, as indicated: namespace std {   template<class E> class initializer_list {   public:     [âŠ]     constexpr initializer_list() noexcept;     initializer_list(const initializer_list&) = default;     initializer_list(initializer_list&&) = default;     initializer_list& operator=(const initializer_list&) = delete;     initializer_list& operator=(initializer_list&&) = delete;     constexpr size_t size() const noexcept;     [âŠ]   };   [âŠ] } LWG telecon appears to want a language change to disallow assigning a braced-init-list to an std::initializer_list but still permit move assignment of std::initializer_list objects. That is, auto il1 = {1,2,3}; auto il2 = {4,5,6}; il1 = {7,8,9}; // currently well-formed but dangles immediately; should be ill-formed il1 = std::move(il2); // currently well-formed and should remain so Meeting: Proposed resolution:
SF F N A SA 0 3 12 0 0 JF emailed LEWG, to see if they have an opinion, no feedback. Asked LEWG chairs to schedule for a telecon. LWG discussed priority. |
â»ïž | |
Lib |
std::function should not return dangling references |
If a std::function has a reference as a return type, and that reference binds to a prvalue returned by the callable that it wraps, then the reference is always dangling. Because any use of such a reference results in undefined behaviour, the std::function should not be allowed to be initialized with such a callable. Instead, the program should be ill-formed. A minimal example of well-formed code under the current standard that exhibits this issue: int main()Â { Â Â std::function<const int&()> F([]{ return 42; }); Â Â int x = F(); // oops! } Proposed resolution: Add a second paragraph to the remarks section of 20.14.16.2.1 [func.wrap.func.con]: template<class F> function(F f); -7- Requires: F shall be CopyConstructible. -8- Remarks: This constructor template shall not participate in overload resolution unless
[âŠ] Tim: LWG in Batavia 2018 would like a way to detect when the initialization of a reference would bind it to a temporary. This requires compiler support, since thereâs no known way in the current language to do so reliably in the presence of user-defined conversions (see thread starting at https://lists.isocpp.org/lib/2017/07/3256.php). Meeting: Tim wrote p2255 to address this. Ville thinks there should be an analysis of alternative approaches. Also see P0932. |
â»ïž | |
Core |
Base-derived conversion in member type of pointer-to-member conversion |
Related to CWG 170, drafting by Clark seems unlikely. This is section 2.1 of Jeff Snyderâs P0149R0, which was approved by EWG, 4 years ago, waiting for wording. JF reached out to Jeff. Did wording with Jens, main blocker is lack of implementation. Meeting: (notes) Suggest closing as Not A Defect because we have implementation uncertainties, but weâll explore the design space in P0149. ABI group will discuss. All in favor. |
NAD | |
Core |
Lifetime of temporaries in range-based for |
// some function   std::vector<int> foo();   // correct usage   auto v = foo();   for( auto i : reverse(v) ) { std::cout << i << std::endl; }   // problematic usage   for( auto i : reverse(foo()) ) { std::cout << i << std::endl; } Meeting: (notes, also discussed in Rapperswil 2014) Suggest closing as Not A Defect because itâs a change which might have effects on existing code (might cause bugs), and might need to change more than just range-based loops. See p0614, p0577, p0936, p1179. Weâll explore the design space in a separate paper, Herb circled back with Nico on this, might write a paper. All in favor. |
NAD | |
Core |
Querying the alignment of an object |
Quick example using âautoâ illustrates why we might want this capability for objects as well as types. Principle of least astonishment suggests it is surprising for sizeof and alignof to behave differently in this regard. Recommend shipping this straight to core as soon as we can find a wording champion. We need to discuss with WG14. Questions for EWG to answer before forwarding:
This needs a design paper rather than going straight to core. https://godbolt.org/z/TeVA9T GCC seems to report the alignment of the object not just of decltype(object). Meeting: (notes, also discussed in Rapperswil 2014) Suggest closing as Not A Defect, the design is complex especially around alignment of object versus type. Invite a paper, Inbal will pitch in, Alidair can collaborate. All in favor. Inbalâs paper: P2152R0 |
NAD | |
Core |
Explicit specializations in non-containing namespaces |
The current wording of 9.8.1.2 [namespace.memdef] and 13.9.3 [temp.expl.spec] requires that an explicit specialization be declared either in the same namespace as the template or in an enclosing namespace. It would be convenient to relax that requirement and allow the specialization to be declared in a non-enclosing namespace to which one or more if the template arguments belongs. Additional note, April, 2015: See EWG issue 48. Might allow us to revert DR2061 and all the horribleness that created and described in p1701. The problem 1077 addresses is the motivating factor in dr2061. Also see CWG 2370. Meeting: (notes) Suggest closing as Not A Defect. See p0665, minutes. Continue under p0665 or a forked version of it. All in favor. |
NAD | |
Core |
trailing-return-type and point of declaration |
template <class T> T list(T x);     template <class H, class ...T>     auto list(H h, T ...args) -> decltype(list(args...)); // list isnât in scope in its own trailing-return-type     auto list3 = list(1, 2, 3); Meeting: (notes, also discussed in Rapperswil 2014) there might be compiler divergence according to Daveed. Suggest closing as Not A Defect, it would be tricky to change behavior without ambiguity. "Fixing" this would break existing code that relies on seeing only previous declarations. No objection to unanimous consent. |
NAD | |
Core |
Omitted bound in array new-expression |
The syntax for noptr-new-declarator in 7.6.2.7 [expr.new] paragraph 1 requires an expression, even though the bound could be inferred from a braced-init-list initializer. It is not clear whether 9.4.1 [dcl.init.aggr] paragraph 4, An array of unknown size initialized with a brace-enclosed initializer-list containing n initializer-clauses, where n shall be greater than zero, is defined as having n elements (9.3.3.4 [dcl.array]). should be considered to apply to the new-type-id variant, e.g., Â Â new (int[]){1, 2, 3} This was addressed by p1009 Meeting: (notes) Suggest closing as Not A Defect. Addressed by P1009. No objection to unanimous consent. |
NAD | |
Core |
Language linkage and function type compatibility |
Currently function types with different language linkage are not compatible, and 7.6.1.2 [expr.call] paragraph 1 makes it undefined behavior to call a function via a type with a different language linkage. These features are generally not enforced by most current implementations (although some do) between functions with C and C++ language linkage. Should these restrictions be relaxed, perhaps as conditionally-supported behavior? Somewhat related to CWG1463. Meeting: (notes) no strong consensus at the moment, Erich Keane brought this up with SG12 Undefined Behavior. Long discussion, will need to revisit, need a paper. Meeting Oct 22nd 2020: will need a volunteer to write a paper, but the wording in the standard is unambiguous, and we have existence proof of platforms which use different calling conventions between C and C++. However many major compilers have chosen to ignore this. Not a defect, but we welcome a paper to change the status quo. No objection to unanimous consent. |
NAD | |
Core |
Default arguments for template parameter packs |
Although 13.2 [temp.param] paragraph 9 forbids default arguments for template parameter packs, allowing them would make some program patterns easier to write. Should this restriction be removed? Meeting: (notes) Suggest closing as Not A Defect. Interesting design space, but needs a paper, see N3416. No objection to unanimous consent. |
NAD | |
Core |
List-initialization of array objects |
The resolution of issue 1467 now allows for initialization of aggregate classes from an object of the same type. Similar treatment should be afforded to array aggregates. See recent discussion on allowing 'auto x[] = {1, 2, 3};' -- this topic came up there. The two questions can be answered independently, but some consider them to be related. Meeting: (notes) Suggest closing as Not A Defect. Fixing anything in this space would require a paper which considers the entire design space, Timur might be interested in this. No objection to unanimous consent. |
NAD | |
Core |
Non-identifier characters in ud-suffix |
JF forwarded to SG16 Unicode given their work on TR31. Tracked on GitHub. SG16 reviewed D1949R3, still needs wording changes. Discussed at the April 22nd SG16 telecon. SG16 Poll: Is there any objection to unanimous consent for recommending rejection of this proposal? No objection to unanimous consent. EWG Meeting: (notes 2020-04-15, notes 2020-05-07) Suggest closing as Not A Defect. No objection to unanimous consent. |
NAD | |
Core |
Preventing explicit specialization |
A desire has been expressed for a mechanism to prevent explicitly specializing a given class template, in particular std::initializer_list and perhaps some others in the standard library. It is not clear whether simply adding a prohibition to the description of the templates in the library clauses would be sufficient or whether a core language mechanism is required. Meeting: (notes) Suggest closing as Not A Defect. No objection to unanimous consent. This could be a language feature, would need library usecase examples. Poll: we are interested in such a paper SF 2 F 13 N 6 A 1 SA 0 |
NAD | |
Core |
Potentially-invoked destructors in non-throwing constructors |
Since the base class constructor is non-throwing, the deleted base class destructor need not be referenced. Thereâs a typo in the issues list here: it should say "Since the derived class constructor is non-throwing, the deleted base class destructor need not be referenced." Meeting: (notes 2020-04-23) the proposed wording changes the implementation leeway in two-phase unwinding, which breaks some existing ABIs. We would need a paper to explore this further. Suggest closing as Not A Defect. No objection to unanimous consent. |
NAD | |
Core |
Lvalues of type void |
There does not seem to be any significant technical obstacle to allowing a void* pointer to be dereferenced, and that would avoid having to use weighty circumlocutions when casting to a reference to an object designated by such a pointer. Might consider this a duplicate of the discussion on "regular void". JF reached out to Matt. He has an implementation in clang. Needs to update the paper. Might need a volunteer to present. Daveed would be interested in presenting. Meeting: (notes 2020-04-23) Suggest closing as Not A Defect. Explore under the âregular voidâ umbrella. No objection to unanimous consent. |
NAD | |
Core |
Relaxing exception-specification compatibility requirements |
According to 14.5 [except.spec] paragraph 4, If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification. This seems excessive for explicit specializations, considering that paragraph 6 applies a looser requirement for virtual functions: If a virtual function has an exception-specification, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function. The rule in paragraph 3 is also problematic in regard to explicit specializations of destructors and defaulted special member functions, as the implicit exception-specification of the template member function cannot be determined. There is also a related problem with defaulted special member functions and exception-specifications. According to 9.5.2 [dcl.fct.def.default] paragraph 3, If a function that is explicitly defaulted has an explicit exception-specification that is not compatible (14.5 [except.spec]) with the exception-specification on the implicit declaration, then
This rule precludes defaulting a virtual base class destructor or copy/move functions if the derived class function will throw an exception not allowed by the implicit base class member function. Meeting: (notes 2020-04-23) JF will work with Mike to update wording to C++20. Will revisit. From Mike: This issue is NAD since we eliminated typed exception-specifications. The current wording, dealing only with noexcept(true) and noexcept(false), does not have this issue. Will remove âextensionâ status. Meeting: no objection to CWG taking it back, and marking it as NAD. |
NAD | |
Core |
decltype(auto) with direct-list-initialization |
Paper N3922 changed the rules for deduction from a braced-init-list containing a single expression in a direct-initialization context. Should a corresponding change be made for decltype(auto)? E.g.,   auto x8a = { 1 };      // decltype(x8a) is std::initializer_list<int>   decltype(auto) x8d = { 1 }; // ill-formed, a braced-init-list is not an expression   auto x9a{ 1 };       // decltype(x9a) is int   decltype(auto) x9d{ 1 };  // decltype(x9d) is int See also issue 1467, which also effectively ignores braces around a single expression, this change would be parallel to that one, even though the primary motivation for delctype(auto) is in the return type of a forwarding function, where direct-initialization does not apply. Meeting: (notes 2020-04-23) Suggest closing as Not A Defect. This would be a language change, itâs unclear that we want to make such a change. It would require a paper. Mike Spertus is writing a paper with some overlap, will cover this as well. No objection to unanimous consent. |
NAD | |
Core |
Array temporaries in reference binding |
The current wording of the Standard appears to permit code like
creating a temporary array of ten elements and binding the parameter reference to it. This is controversial and should be reconsidered. (See issues 1058 and 1232.) Meeting: (notes 2020-04-23) JF digging more, talking to Richard about this. Somewhat related to P2174 compound literals. Would be very strange if  ... were invalid but ...   ... were both OK. Maybe either we should allow the trailing elements to be zeroed in general (the status quo), or not (a major breaking change). Which means we should reject the issue on consistency grounds. The general rule is that if  T &&r = init; ... canât bind directly, we create a temporary initialized as if with  T r = init; ... and bind to that. (And similarly for const references.) Another question: Do we want to support (T){inits} as a synonym for T{inits}? Meeting Oct 22nd 2020: Note that the issue itself is defective, and CWG2352 references p1358, and was resolved, leading us to believe that this is now mainstream and not controversial. Not a defect. No objection to unanimous consent. |
NAD | |
Core |
Copy elision and comma operator |
Currently, _N4750_.15.8 [class.copy] paragraphs 31-32 apply only to the name of a local variable in determining whether a return expression is a candidate for copy elision or move construction. Would it make sense to extend that to include the right operand of a comma operator? X f() { Â Â X x; Â Â return (0, x); } Meeting: (notes 2020-04-23) Consider expanding to other places that expand bit-field-ness such as return b ? throw : x;. Suggest closing as Not A Defect. Will need a paper to address, no current volunteer for this. No objection to unanimous consent. |
NAD | |
Core |
Deprecated default generated copy constructors |
EWG has indicated that they are not currently in favor of removing the implicitly declared defaulted copy constructors and assignment operators that are eprecated in _N4750_.15.8 [class.copy] paragraphs 7 and 18. Should this deprecation be removed? Related: discussing under p2139 deprecations. Meeting: (note 2020-04-29) Suggest closing as Not A Defect. No objection to unanimous consent. We either want to remove entirely, or un-deprecate. This will need a paper, Ville will talk with Alisdair about forking the topic from p2139. |
NAD | |
Core |
Value-initialization of array types |
Although value-initialization is defined for array types and the () initializer is permitted in a mem-initializer naming an array member of a class, the syntax T() (where is an array type) is explicitly forbidden by 7.6.1.3 [expr.type.conv] paragraph 2. This is inconsistent and the syntax should be permitted. Rationale (July, 2009): The CWG was not convinced of the utility of this extension, especially in light of questions about handling the lifetime of temporary arrays. This suggestion needs a proposal and analysis by the EWG before it can be considered by the CWG. This has become a more severe inconsistency after we adopted Villeâs P0960 for C++20. Now itâs not only () that has this weird special-case restriction, itâs (a, b, c) too: using X = int[]; X x{1, 2, 3}; // ok, int[3] X y(1, 2, 3); // ok, int[3] f(X{1, 2, 3}); // ok, int[3] temporary f(X(1, 2, 3)); // error Meeting: (notes) it is a defect, need a paper. David Stone trying to find a volunteer to write said paper. All in favor. |
Paper needed | |
Core |
extern "C" alias templates |
Currently 13 [temp] paragraph 4 forbids any template from having C linkage. Should alias templates be exempt from this prohibition, since they do not have any linkage? Additional note, April, 2013: It was suggested (see messages 23364 through 23367) that relaxing this restriction for alias templates could provide a way of addressing the long-standing lack of a way of specifying a language linkage for a dependent function type (see issue 13). The priority was deleted to allow CWG to consider the implications of that potential application of the facility. We should either have some way to express a dependent function type with C language linkage (and should accept 1555 below) or we should remove the notion that C language linkage (or not) is part of the function type at all. (Apparently some targets used it; are they still in use? EDG probably knows.) Actively discussed on CWG reflector. Davisâ interpretation of CWG discussion: I donât speak for Core, of course, but my (Evolutionary) thoughts are those given (last) in the message to which you replied: neither the wording nor the apparent intent of [temp.pre]/6âs restrictions on C linkage for templates make any sense. Since templates (and explicit specializations) canât have C linkage of the name-mangling variety (which the standard calls language linkage of a (function) name) but can have C linkage of the calling-convention variety (which the standard calls language linkage of a (function) type), extern "C" should grant them the latter and not the former with no error. This has certain obvious applications involving C APIs with callbacks. (Put differently, CWG13 shouldnât have been rejected; it appears to have gotten bogged down in questions of syntax, but we have an adequate syntactic workaround that we merely have to permit.) CWG1463 asks for a (very) proper subset of the above: merely that extern "C" be allowed to apply to alias templates (claiming incorrectly that they have no name with linkage at all). I consider it more relevant (and more productive) to talk about whether entities have names with language linkage than with the ordinary kind. The Core reflector discussion (which seems to have finished for the moment) also touched on the case where "the same" function template is declared with two different language linkages for its type, but the only relevant Evolution input there would be a decision to go the opposite way and forbid function templates from having types with C language linkage entirely. (They currently can, but itâs mostly or entirely useless.) If (for CWG1555, also on your list) the rules about language linkage of (function) types are sufficiently relaxed, then CWG1463 may be moot (and my extension of it with it), but that seems unlikely given Hubertâs recent identification of a case where they matter. Meeting: (notes 2020-04-15, notes 2020-10-22, also discussed in Rapperswil 2014) We agree that this is an issue. extern âCâ on a template should only affect calling convention, and not the mangling. Davis and Hubert volunteer to write a paper. Unanimous consent. |
Paper needed | |
Core |
Ellipsis following function parameter pack |
Although the current wording permits an ellipsis to immediately follow a function parameter pack, it is not clear that the <cstdarg> facilities permit access to the ellipsis arguments. The problem here (which is not explained in the issue) is: how do you supply the name of the last parameter before the ellipsis to va_start? You canât put the name of a pack there (it wouldnât be expanded) and thereâs no way to name the last element of the pack (nor to deal with the case where the pack is empty). Meeting: (notes) 3 options: fix wording around âlast parameterâ, remove facility entirely (either va_start or function declarator), try to invent a language facility. JF emailed EWG to see if anyone has a strong preference, or if we should send back to CWG to fix wording, long discussion. Michael Spertus: I am willing to commit to including and analysis on this in an upcoming paper on parameter packs. JF followed up with Michael and Barry, no response. |
Paper needed | |
Core |
Type of __func__ |
Two questions have arisen regarding the treatment of the type of the __func__ built-in variable. First, some implementations accept   void f() {     typedef decltype(__func__) T;     T x = __func__;   } even though T is specified to be an array type. In a related question, it was noted that __func__ is implicitly required to be unique in each function, and that not only the value but the type of __func__ are implementation-defined; e.g., in something like   inline auto f() { return &__func__; } the function type is implementation-specific. These concerns could be addressed by making the value a prvalue of type const char* instead of an array lvalue. Rationale (November, 2018): See also issue 2362, which asks for the ability to use __func__ in a constexpr function. These two goals are incompatible. The deep question here is about __func__ and the ODR. Does EWG want implementations to somehow behave as if __func__ is the same in all copies of an inline function (in which case it can have an array type and be usable in constant expressions, but the demangling algorithm used to construct it becomes part of the ABI), or does EWG want implementations to behave as if __func__ may differ between copies, so is in effect not known until runtime (in which case it must have either pointer or incomplete array type, and its value is not usable in constant expressions -- but its address could still be usable). Note: C++20 has std::source_location::function_name. Meeting: (notes 2020-04-23) We should discuss this with WG14. This is indeed a language issue. No objection to unanimous consent. Weâll need a paper, potentially considering what Reflection could do, JF brought it up on the mailing list. We probably need a paper to disentangle this. |
Paper needed | |
Core |
Ambiguity resolution for cast to function type |
C++ has a blanket disambiguation rule that says if a sequence of tokens can be interpreted as either a type-name or an expression, the type-name interpretation is chosen. This is unhelpful in cases like     (T())+3 where the current rules make "(T())" a cast to the type "function with no parameters returning T" rather than a parenthesized value-initialization of a temporary of type T. The former interpretation is always ill-formed - you canât cast to a function type - while the latter could be useful. Richardâs proposed resolution, cited above, is to avoid the ambiguity by changing the grammar so that cases like "(T())" cannot be parsed as a cast. The wording in the proposal applies that change to a number of different contexts where the ambiguity can come into play. There are two contexts where the change is _not_ applied, however: 1) the operand of typeid, and 2) a template-argument. During our discussion yesterday, there was some support for the idea of applying the change to typeid, as well, although that would be a breaking change for any programs that rely on the current disambiguation to get type information for such function types. There was general agreement, however, to exclude template arguments, since they are used for things like std::function. CWG would, therefore, like some guidance from EWG on two questions. First, should we apply the new syntax to the operand of typeid, even though itâs a breaking change? More generally, the question was raised whether we should make this change at all. Although resolving the ambiguity in the other direction would arguably be more convenient in many cases, there is a tension between that convenience and the complexity of the language. In particular, we would be creating a situation where the exact same sequence of tokens would mean two different things, depending on the context in which they appear. Is the convenience worth the cost in complexity? Meeting: (note 2020-04-29, notes 2020-03-23, note from Core summer 2020, notes from Core Prague 2020, notes from Core 2019-01-07, notes from Core Kona 2019, notes from Core Cologne 2019) This is an issue, weâd like to change the standard to resolve it: SF 0 F 6 N 4 A 3 SA 2 Davis emailed EWG reflector. Long discussion. |
Paper needed | |
Core |
Are default argument instantiation failures in the âimmediate contextâ? |
Example 1: template <typename T, typename U = T> void fun(T v, U u = U()) {} void fun(...) {} struct X { Â Â Â Â X(int) {} // no default ctor }; int main()Â {Â fun (X(1)); } Consider the following example (taken from issue 3 of paper P0348R0): Example 2: Â Â template <typename U> void fun(U u = U()); Â Â struct X { Â Â Â Â X(int) {} Â Â }; Â Â template <class T> decltype(fun<T>()) g(int) { } Â Â template <class> void g(long) { } Â Â int main() { g<X>(0); } When is the substitution into the return type done? The current specification makes this example ill-formed because the failure to instantiate the default argument in the decltype operand is not in the immediate context of the substitution, although a plausible argument for making this a SFINAE case can be made. Meeting:Â (notes 2020-05-07) The first example under issue 3 of paper P0348R0 should become well-formed. SF F N A SA 0 1 4 3 6 The second example under issue 3 of paper P0348R0 should become well-formed. SF F N A SA 1 5 7 3 0 This is an issue. Weâd like to see a paper addressing it. It should explore what âImmediate contextâ means. No objection to unanimous consent. Daveed / Hubert might entertain writing a paper explaining this. Ville emailed EWG about this. JF contacted Andrzej to see if heâs interested in addressing this. Not sure he is. Meeting 2020-10-28: Tomasz will write a paper which exposes the issue and what he thinks should be done (but not resolving wording itself). Hubert remembers an email about this, will find it and sync with JF. Meeting 2021-01-14: Andrzej wrote a paper for this (emailed 2021-01-12 to EWG). |
Paper needed | |
Core |
__func__ should be constexpr |
The definition of __func__ in 9.5.1 [dcl.fct.def.general] paragraph 8 is:   static const char __func__[] = "function-name"; This prohibits its use in constant expressions, e.g.,   int main () {     // error: the value of __func__ is not usable in a constant expression     constexpr char c = __func__[0];   } Rationale (November, 2018): See also issue 1962, which asks that the type of __func__ be const char*. These two goals are incompatible. Meeting: handle with 1962. |
Paper needed |
9. Near-future EWG plans
We will continue to work on issue resolution and C++23, prioritizing according to [P0592R4].