Draft Minutes for 22–26 January, 2024

MEETING OF ISO/IEC JTC 1/SC 22/WG 14
WG14 / N3227

Dates and Times:

22 January, 2024 09:00 – 12:00 Lunch 13:30 – 16:30
23 January, 2024 09:00 – 12:00 Lunch 13:30 – 16:30
24 January, 2024 09:00 – 12:00 Lunch 13:30 – 16:30
25 January, 2024 09:00 – 12:00 Lunch 13:30 – 16:30

(26 January scheduled but unused.)

Inria
Campus Hôpital Civil, Bâtiment Explora, 67000 Strasbourg
France

Note: first face-to-face/hybrid meeting since 2019.

Seacord: Thanks to Jens for hosting. Welcome to the 69th meeting of WG14. Nice.

|------------------+--------------------------------------+-------------+-------------------------|
| Aaron Bachmann   | Austrian Standards                   | Austria     | Austria NB              |
| Aaron Ballman    | Intel                                | USA         |                         |
| Alex Celeste     | Perforce Software                    | USA         | Scribe                  |
| Chris Anley      | NCC Group                            | USA         |                         |
| Chris Bazley     | ARM                                  | UK          |                         |
| Clive Pygott     | LDRA Technology                      | USA         |                         |
| Corentin Jabot   | Freelance                            | France      | Guest                   |
| Dan Plakosh      | SEI/CERT/CMU                         | USA         |                         |
| Dave Banham      | BlackBerry QNX                       | UK          | MISRA Liaison           |
| David Svoboda    | SEI/CERT/CMU                         | USA         | Undef. Behav. SG Chair  |
| Douglas Teeple   | Plum Hall                            | USA         |                         |
| Elizabeth Andrews| Intel                                | USA         |                         |
| Eskil Steenberg  | Quel Solaar                          | Sweden      | Sweden NB               |
| Fred Tydeman     | Keaton Consulting                    | USA         | INCITS/C Vice Chair     |
| Freek Wiedijk    | Plum Hall                            | USA         | Assistant editor        |
| Henry Kleynhans  | Bloomberg                            | USA         |                         |
| Jacob Navia      | Logiciels/informatique               | France      | Guest                   |
| Jakub Lukasiewicz| Motorola Solutions Systems Polska    | Poland      | Poland NB               |
| JeanHeyd Meneide | NEN                                  | Netherlands | Editor; C++ Comp. SG    |
| Jens Gustedt     | INRIA/ICube                          | France      | France NB               |
| Joseph Myers     | CodeSourcery / Siemens               | UK          | UK NB                   |
| Joshua Crammer   | Intel                                | USA         |                         |
| Marcus Johnson   | Self                                 | USA         | Guest                   |
| Martin Uecker    | Graz University of Technology        | Austria     |                         |
| Ori Bernstein    | PingThings                           | Canada      |                         |
| Paul McKenney    | Meta/Facebook                        | USA         |                         |
| Peter Sewell     | University of Cambridge              | UK          | Memory Model SG Chair   |
| Philipp Krause   | Self                                 | Germany     | Germany NB              |
| Rajan Bhakta     | IBM                                  | USA, Canada | INCITS/C Chair          |
| Robert Seacord   | Woven Planet North America Inc       | USA         |                         |
| Roberto Bagnara  | BUGSENG                              | Italy       | Italy NB, MISRA Liaison |
| Robin Rowe       | Boost Foundation                     | USA         |                         |
| Ted Johnson      | Hewlett Packard Enterprise           | USA         |                         |
|------------------+--------------------------------------+-------------+-------------------------|

Seacord: This is a hybrid meeting, so the rules require that the whole meeting stops if the network connection stops. We will figure out more about how to handle this as we proceed.
A note was later made that future hybrid meetings should try to provide more than one microphone for the room.

We take straw polls, not binding polls. Everyone in the room may vote as an individual. Result is based on consensus.

Bhakta: can we establish what "consensus" is?

Seacord: at this time we have no draft to vote against anyway so we don't need to worry too much. No changes voted for here are final.

Bhakta: I have an algorithm expressed in C we can use.

Note that this meeting is a WG14 meeting only and not a joint meeting with INCITS-C.

Presented to the group. No discussion.

WG14 minutes N3174
Celeste moves to approve. Lukasiewicz seconds. No objections.

SEACORD to submit TS18661-5 for ballot.
RESOLVED as NOT DONE/DEFERRED because the document is still being held back for review.

WG14 Agenda N3202
Bhakta moves to approve, Plakosh seconds. No objections.

Note: a live agenda document was maintained separately through the meeting.

Austria, Canada, France, Netherlands, Poland, Sweden, United Kingdom, United States

Seacord: DIS comments are back since Dec 11th. We must process the comments - this is the only truly mandatory thing we have to do.

Our options are: if we accept technical changes, to move to an FDIS step; if we accept editorial changes, there are no more steps but publication takes a little longer; or the project will cancel automatically on the 12th of July, which we will not allow to happen.

We can look at papers for C2y if we finish the DIS review.

No report

PL-C will be meeting with a ballot item on the 5th February.

Seacord has attended; typeof was voted down to great surprise, which upset some WG14 members.
"We should do our jobs even if others don't." Changeable objectives of other committees are outside the control of WG14.

C++ believe that decltype is the better solution and do not have consensus for typeof, although there are more votes for inclusion than against.

The most critical concern remains header compatibility.

The new co-chair is quite active. Ballman continues to attend but does not have time to lead.

Pygott has resigned. Nobody else in the group attends.

After publication of MISRA C:2023 a new document is already underway working on integrating C23 features (and possibly other things) and is expected next year.

Request from WG14 to "please" refer to the C language revision as C23 rather than C24.

No report

No report

No other groups active.

CFP continues work on TS parts 4 and 5, not much time left for these before project expiry. These will be submitted after this meeting unless advised not to by the group.

Continue to welcome issue submissions and have new issues to discuss for C2y.

Need to discuss whether to push TS 6010 forward or not.

This was discussed immediately:

ISO disapproved of Gustedt's changes, unsure of direction to take. Previously the decision was to rewrite per the ISO requirements but then we re-litigated the question of publishing the TS or integrating it immediately.

Seacord, Bhakta and Ballman prefer a TS as this gives better time to implementers; Intel and IBM take a year in advance simply to schedule changes, let alone make them. It is a high risk to fold something unimplemented into the IS, and a very high effort to remove it again after integration if it is not implemented after that. This is the precedent set by CFP. Disagreement on whether a TS really makes a stronger implementation case than a basic N-document, but implementers are adamant that a formally published specification is necessary to commit to work. Acknowledgment that TS are not generally a good end-product as a document for shipping features.

The document has not been updated and the group needs to provide guidance on whether effort to rebase the TS is warranted.
Non-optimizing compile modes should be conforming but it is not yet fully known how divergent optimizing implementations are.

Straw poll (opinion): Would WG14 like to continue with publication of TS 6010?
17 / 0 / 4 (approval)

Straw poll (opinion): Would WG14 like to vote a revision of N3057 with the TS 6010 content into C2y "at some point", subject to positive implementation experience?
20 / 0 / 3

No activity at the moment, resuming on the 1st to discuss provenance.

C++ wants a similar model but is formulating it differently.

The UB examples document [N3155] was published in October and the SG is still interested in any feedback. Meetings continue.

"CRFI" has not progressed yet, will report back when there is movement from within the Community.

This is organized as a study group to address various problems.

The new document system is not finished because the editing work takes priority. Will complete after editing is done. This will speed filing issues up by avoiding the ISO process and allowing a simplified document submission system with a normal login and upload button.

The entire system is a portable Git repository and can be moved between hosts. The primary host will be the WG14 GitLab on GWDG, with a public mirror at GitHub and possibly other public-visible places.

10 June - 14 June virtual meeting. This will be a half-session Zoom meeting the same as most recent meetings have been.

30 September - 04 October in Minneapolis; options remain open for 2025, including Graz; London; somewhere in Spain; somewhere in Japan.

Most changes in this section were applied by unanimous consent.
The majority of comments did not produce technical discussion and are not recorded separately.
Individual detailed resolutions are recorded in N3216.

The editors had already integrated the majority of changes into the working document at the time of discussion, with only a few remaining to address.

UC objected to for ISO comment 006:

Straw poll (opinion): Would WG14 like to accept ISO comment 006?
11 / 2 / 10 (accepted)

ISO comment 025 appears to create a rules conflict. WG14 should have a standing exception.

ISO comment 027 produced discussion of the relative usability impact on the document and on supporting vocabulary documents. Noted that although these are non-normative NOTEs, a NOTE cannot really be removed if it makes an entire entry meaningless.

Straw poll (decision): Does WG14 want to remove all outward references to other Clauses from Clause 3?
3 / 8 / 8 (no consensus)

Interpreted as a qualified rejection: the comment was carefully considered.

Wording for ISO comment 046 was provided on the Reflector in message [24428].

For ISO comment 069 it was noted that stating the existence of a requirement elsewhere does not in itself constitute a requirement.

For ISO comment 087 it was noted that examples are intended to clarify the preceding normative text, so recommended changes should not result in them becoming actively misleading. However it should also ideally be possible to understand all requirements without reading the non-normative examples at all. Observed that the directives are being too blunt here.
Ballman and Bhakta join the editorial review group as a result of this discussion.

ISO comment 107 explicitly rejected in order to avoid publication delays. Could be revisited if an FDIS is opened for other reasons.

ISO comment 129 demonstrates the importance of adopting a stable tagging scheme like the one used in the C++ Standard. Also resolved that some section labels should not be moved even if the content around them changes, such as Annex J.

ISO comment 157 produced more diverging opinions about the ways users interact with the document and which option would produce greater utility in the end product.

Straw poll (opinion): Would WG14 like to accept ISO comment 157, by removing paragraph 7 from the Introduction?
9 / 4 / 6 (editorial direction to remove)

ISO ocmment 178 was also discussed in terms of readability and usability. Consensus settled on a more minimal change as a compromise.

Straw poll (decision): Does WG14 want to alphabetically flatten the list of entries in Clause 3?
(not polled)

Straw poll (decision): Does WG14 want to lift subclauses 3.20.2, 3.20.4, and 3.20.5, to the top level of Clause 3?
12 / 3 / 5 (approved)

ISO comment 182 was observed to ignore an existing guideline. Noted that WG21 received and rejected the same comment. In order to maintain consistency in accordance with the ISO Directives, WG14 rejected this change too. It was also noted that US spellings are considered an acceptable regional variant by the ISO Directives via the inclusion of Webster's as a permitted reference.

ISO comment 188 generated more discussion about usability. The change requested contradicts the spelling in the rest of the document and in the language described, as well as potentially harming clarity by breaking copy and paste for semantically significant values. It is region-specific.

Straw poll (decision): Does WG14 want to resolve ISO comment 188 by rejecting the comment?
16 / 1 / 3 (rejected)

ISO comment 190 was extremely contentious and was interpreted by the group as breaking normative text, as well as violating many decades of precedent.

Straw poll (decision): Does WG14 want to accept all change dispositions to comments as specified in document N3216?
19 / 1 / 0 (accepted)

All DIS comments were resolved!

Gustedt, Bhakta, Myers, Ballman, Kleynhans volunteer to form the editorial review group.

Augmented arithmetic has been moved; type generics have simply been removed following the guidance to avoid introducing identifiers. A software implementation is now available.

Bazley: not convinced any library headers should add un-aliased tag types. _t types do not fit here and should be typedefs. The interface should be minimal and not require tags. Please seriously consider the precedent being set; do not like not having a style guide for the Standard interfaces.

Bhakta: no preference but want to avoid flip-flopping. The tag is there only because we added one struct and it needed some name.

Ballman: unspecified types are good for implementers as they allow exposing existing functionality. _t is notionally reserved for POSIX; no reply from Austin Group when consulted.

Straw poll (decision): Does WG14 want to submit TS-18661 part 4 for publication as-is?
12 / 3 / 5 (approved)

Part 5 applied suggested changes and engages in some small invention by adding Constraints sections to the library. This sets a precedent we can follow elsewhere.

Straw poll (decision): Does WG14 want to submit TS-18661 part 5 for publication as-is?
13 / 0 / 6 (approved)

[note: this section attempts to preserve the original discussion as directly as possible]

Nothing we say here has any impact. There is no text in front of the Committee to approve for inclusion at this time.

Steenberg: our job is harmonization, not design. Whether we change or keep the Charter is is meaningless right now. WG14 should not be a means to force new features through. We have already lost important projects like Linux that ignore the Standard and order vendors around directly. C is not chosen for safety or new features; we should improve the corner cases rather than add more. There is language drift, to the point of a fork; the old language still needs maintenance and users do not feel their needs are being addressed by the WG. Want a deprecation mechanism for the language; want a study group to document the dependable behaviors seen in reality.

Gustedt: disagree with the core assumption. Some things needed adaptation, but things that do not exist do not get adopted; new things do exist in the field and are praxis. Dispute the claim about Community leadership.

Wiedijk: agree with Steenberg on the study group. The threads library vs. adopting pthreads as-is is a good example of invention and the consequences of it.

Celeste: should consider an "epoch" system to guarantee forward stability within set version timeframes.

Bazley: the Charter says "go away" and creates a chilling effect. "Trust the programmer" has also been badly misunderstood and misused for too long.

Meneide: the Committee fails to stick tot he existing practice rule which has become actively harmful. Too much never gets discussed; typeof took 20 years to reach discussion. Vendors have done the experiments and the feedback is not reaching the WG. Statement expressions were brought in 2002 but no progress was made. Implementers are left without clarity for their feature maintenance, dampening the will to develop anything. The Charter is ineffective at moving things forward. There is lots of practice at the moment to adopt, and needed by real code. We have a large pool of existing features to pull from.

Bhakta: agree by disagreeing; implementations matter, for instance usage of __auto_type was minimal to the point of seeming inventive. The rule about not picking one version comes from ISO as our role is to build consensus and not crown an industry-winner. In practice "no invention" is ignored, and outside the WG nobody complains about it. Users like stability and restricted invention; do agree with choosing existing practice, but it needs someone to bring something forward. Users need to bring things they like forward.

Myers: interoperability is not in the Charter, but should be. Need a space for non-observable behavior, for linking, for linking to other languages; C is important as a glue or communication language, and this should be a core feature, including the ABI level. We should not leave it to implementations, and should define it up-front. Risk associated with new features is contextual, building on well-understood features is safer than building on new things; depends on the complexity and the interactions. Not enough people are contributing detailed technical review of other submitters' papers and we have issues with accurate integration into the draft. Diffs against the working draft should be a required part of a proposal. We should consider what we need and what suits C's style - bit operations, packed structures, vectors, versioning; safety and security needs work to make it easier for users to do the right thing.

Jabot: agree about value in interoperation and as a underlying language. Don't think it's fair to make vendors lead experimentation; it's no longer true and users expect portability, not extensions. The Committee must set an implementation direction.

Ballman: no two of us agree on what "invention" is anyway. Extensions have rough edges; we learn and correct their mistakes. We do not want perverse incentives for vendors. We need room for corrections to vendor decisions.

Seacord: we like C. It is not going away. The Charter is for the WG, not for the language; we are caretakers or stewards. We want to promote and champion our work. It's not controversial that C will never be safe; but we can improve it without "fixing" it.
Do we want C to evolve unguided or to have a roadmap? C11 had a plan and did not follow it. A volunteer organization can only do limited things. What gets done is what the volunteers want to work on.

Bhakta: strongly support Myers's points. We need review, to put in things that are solid and not a broken basis. Vectors and SIMD and so on are good but we need volunteers. We had a TS and it died.
Interop should be between languages and also between C versions, forming a common link.

Bachmann: Seemingly easy things are not easy. It took 22 years just to fix bool. Having more, smaller papers should make review simpler. Want a direction - C99 adds VLAs, C11 pulls them back; it is no good to reverse directions like this. Want a clear distinction between core and library the core has the higher burden. I would have liked _BitInt to be non-core.

Steenberg: Linux is only just approving declaration-in-for - there is not much movement. We should consider having a reference implementation of the Standard Library. We don't break compatibility by changing code; prose is the long way. Agree that intention is needed to harmonize. Skittishness around large features results in paring-down, which results in them becoming useless. We should start a study group for vectors etc. in order to force a schedule.

Uecker: Agree with Myers - interop should be in the Charter. New requirements do not allow us to stand still. Vendors should be involved and able to do the real invention in a better process.

Wiedijk: "why not Rust" - I like C, it is simple. Adding to it makes it less attractive. Features are off-putting, prefer stability. Lack of type-safety is not true with better analysis.

Bernstein: Don't standardize malpractice. Not obvious up-front what all features and dependencies are. We do need to invent, but also need to know we caught everything. Involve the vendors more actively, to get directional experience. Consider the Austral language: completely understanding a small set allows intuiting a large set; cannot intuit in C. We want the guard rails but cannot get a big language without them becoming disastrous.

Meneide: It is not a given that vendors will play along. GCC already refuses to comply. Clang must see a Standard proposal before admitting any patches. There is no more room to do stuff. Vendors aren't actually interested in pre-Standard things. When Intel lost interest in Cilk, that killed it. There is a contrast between vendors in their willingness to experiment.

Bazley: Agree that vendors do not care about this. It is a problem with the whole model. We have a chicken/egg problem where vendors defer to the Standard which defers to the implementations.

Kleynhans: Agree that safety and trust require work on the public image. C++ did a lot of PR work a while back. We should copy it. Also want SIMD. Agree with Myers about review.

Ballman: Clang can provide guidance on the extension process. It's both easy and hard. Users love some things, like #embed.
Nobody cares any more about C++ compatibility and it is no longer in our best interest. WG14 is given all the responsibility for it already.

No straw polls.

Introduction and justification of the feature; discussion of usability and the impact of teaching pointers to new users; the impact of qualification and correctness of the program design; whether a wholly original API would be a better addition; impact on freestanding and extended signatures; whether this is already implicitly required by the platform; naming scheme considerations; impact on shared libraries being forced to add wrapper APIs without this feature; discussion of the best signature for the APIs; what do other languages allow in their equivalent APIs?; how does this fit with multi-process DLLs in environments like Windows?

Straw poll (opinion): Would WG14 like to see something along the lines of N2948 added to C2y?
11 / 9 / 3

Core motivation to remove a UB that is out of user control; providing definitions even when the error condition is hit; testing against implementations; comparing impact of different strategies; discussion that removing the UB is possible without over-specifying; reuse existing wording as far as possible while respecting diverse floating representations; reduce reliance on errno; relation to the strto* family and sharing error handling; continuing to eliminate the existence of "trap" representations implicitly; consider that devs will not jump through hoops, making values unspecified invalidates existing code; regularity of the library is important; developers cannot be relied upon to use Valgrind or ASan because they do not expect UB; values should still be usable without special handlers to improve usability.

Straw poll (opinion): Would WG14 like to see changes along the lines of those proposed in N3183 in C2y, using the listed preferred answers to questions 2-6?
17 / 0 / 6

Not polled: preference for saturation-based approach.

Slides presented were originally created for an internal ARM presentation. The slides were later made available as N3222.
Topic introduced via presentation of slides and N3089.

Discussion: what about void * with the new &* pseudo-operator; how teachable was this?, how checkable was this?, what did ARM think?; resistance from the same people who never adopted const; code with qualifiers is at least never less correct than without qualifiers; qualifiers are not forced to be used outside of using new APIs; should old APIs add this qualifier?; despite the superficial simplicity, nonnull is harder to implement usefully or migrate to; "pain" of migration is evidence that qualifiers do actually help (!), and anyway they can always be cast-off; more consistent with original declaration syntax than Clang's feature, can be typedef-ed etc; this behaves like a type system qualifier like the rest of the language, unlike nonnull which behaves differently; discussion of what a qualifier actually is, about accesses and not the value; const can also be stripped from an already-correct program; contrast _Mandatory would be less useful against common expectation of validity and doesn't work with implicit conversion; a new pseudo operator is a better solution than casts for communicating intent and automatically only stripping the qualifier; already deployed in ARM and checked by static analysis; easy to migrate using low impact starting solutions like an empty macro; Clang are not keen on this and chose nonnull because it believed value-conversion was more important.

Several expressions of delight at the proposal within the room. Explicit thanks and encouragement to the author for bringing this and for the diligent preparation.

Straw poll (opinion): Would WG14 like to add something along the lines of _Optional as specified in N3089 to C2y?
15 / 0 / 6

Introduction and justification: normally scalars would have printing too; there is a problem with running out of characters; great variance of types means copying integers is not possible but can fix to just IEEE types; 4095 characters is often not enough; lack of distinction between language and library types made implementation in musl difficult; avoid overpowered printf if possible; need more feature test macros; should try to be consistent between printing and scanning; possible argument for tossing out format strings entirely (!); to_string is also an option; don't want to force support for dynamic big-ints or huge objects.

Straw poll (opinion): Would WG14 like to add something along the lines of N3184 to C2y?
12 / 0 / 9

Straw poll (opinion): Would WG14 like to raise the 4095-character limit on format-specified printable values in C2y?
9 / 2 / 10

Discussion of how this is always possible but often tedious; call_once and similar are not great for solving dependency between TUs; GCC has a numbering scheme; this could work as a library-evolution feature but does rely on compiler magic for the ordering; god for optionally-used library components; is the library issue out of scope for the Standard? established that inter-dependency is an issue for static linkage as well; there is no magic across the static library boundary, just implementation name mangling.

Straw poll (opinion): Would WG14 like to add something along the lines of N3185 to C2y?
8 / 5 / 7 (no consensus)

Discussion that the Standard needs to separate its terms better between syntax and semantics, and between processing phases; not proposing a normative change to the definition of multi-byte character constants; recurring question of the definition of "character", inviting a subsequent proposal to resolve it; confusion between "character" and "byte", "character" and UTF-8, etc; this work was already done for C++ so no need to diverge.

Straw poll (opinion): Would WG14 like to adopt changes along the lines of those specified in N3189 in C2y?
24 / 0 / 0

Introduction and justification as a request for direction, while also having the goal of factoring out preprocessing into a separate language-independent specification. Collecting more extensions is the start of this process, and direction is needed for how big the specification should become.

Discussion: __COUNTER__ makes evaluation order and caching observable, with divergent test cases between major vendors; many implementable features are just better as builtins anyway, especially when the preprocessor already knows how by definition; implementability is a non-issue; some original features but building on the same base; does C++ even care about the preprocessor any more? though ideas like __VA_OPT__ did originate in C++; consistency remains paramount; not many likely users from other languages, although there is some existing practice; also aiming to reduce "cleverness" and the amount of boilerplate needed like for NARGS, simplifying Boost et al.; weigh the cost of moving effort between user and implementer; some resistance to the idea that the preprocessor should be allowed to become a programming language in its own right; strong support for letting the implementation just use builtins where it has to have the information anyway; there is demand for many of these in the Clang community but need feature-focus.

Not polled.

For context, this also referred back to N2014, reviewing user understanding of what they can do with buffers. Users believe that this is already allowed. Application developers already rely on this behavior. The Standard is free to move a UB that users rely on into being well-defined.

Discussion: this also appears to be consistent with all praxis because compilers do not exploit this UB; would finally make implementing malloc possible; discussion of the impact on the Effective Type; comparison with C++ which provides new instead of allowing this; consider that not all architectures allow all types in all address spaces, including main memory on small targets or the GPU mapping; address spaces are not well-served by C anyway at the moment; allowance for embedded locks already causes huge problems; no intent to change any existing behavior; strong support from implementers in the room; noted that this does not imply octets or change the definition of bytes; do atomics need a special exception for implementability?; not substantially worse than malloc.

Straw poll (opinion): Would WG14 like to add something along the lines of N3197 to C2y?
18 / 2 / 2

Introduced with justification of making effective types easier for users to control. This allows communicating new object identities to the compiler. Much like previous paper, this only aims to allow what is already accepted praxis.

Discussion of the API design and UX ramifications; discussion of wanting to control optimization of calls and providing guarantees of state, not efficiency; which expectation is the common case?; avoiding surprises vs. consistency with current language design; discussion of correct intended usage, not fully understood by all members; discussion of the boundaries across address spaces; dependency on previous papers; discussion of the implementation that also provided in-language namespacing; strong support for the fact that the provided implementation works out of the box.

Straw poll (opinion): Would WG14 like to add something along the lines of N3186 to C2y?
1 / 7 / 14 (no consensus)

Introduction and justification: attempt to simplify user understanding of when effects occur. Seemingly unrelated expressions depending on each other for evaluation creates dependencies that are hard to get right.

Discussion of: consistency; that side effects are confusing in general, except when clearly intended; nesting complicated features is confusing in general, possibly this should be the jurisdiction of Guidelines documents; whether evaluation is forced is not consistent as-is; this may invalidate a lot of documents without fixing the underlying problem; the feature in general surprises users and maybe warrants a warning; we should at least aim to remove any UB.

Straw poll (opinion): Would WG14 like to add something along the lines of N3187 to C2y?
13 / 2 / 7

Introduced with the justification that there are many use cases for adding sugar to the query for a previously-established state. If state exists, the user should be able to access it; the abstract machine state is reified in the case of VLAs.

Discussion of syntax, whether the dot is good UX, whether the declaration needs to match; must not change the meaning of any existing code; should avoid conflicting with member namespace; the different use cases have varying importance and implications; should limit to the well-developed parts; discussion of how this is actually implementable for all proposed uses.

Straw poll (opinion): Would WG14 like to add something along the lines of N3188 to C2y?
10 / 3 / 5

This was discussed thoroughly before. Forward declarations are justified as being less convenient but having the most unambiguous semantics.

Discussion: additional use cases for arbitrary objects?; C++ compatibility is irrelevant here; should there be more error conditions or constraints?; comparison to attribute approach in Clang with a delayed parsing approach; concerns about usability and mis-usability; reminder that the appearance is existing practice; noted that forward declaration is a core C principle; noted that this is a solution to a problem that WG14 created and then solicited solutions for.

Straw poll (opinion): Would WG14 like to add something along the lines of N3207 to C2y?
10 / 3 / 6

Straw poll (opinion): Does WG14 want to allow forward declarations for names other than parameter objects?
7 / 6 / 5 (not consensus, but directional)

Observed that there are no known conflicts with this proposal. Only encoding identified is from the 1960s USSR and never saw widespread adoption. Noted that we cannot fix the character set above 'h'.

Polling for deferred-immediate addition to C2y.

Straw poll (opinion): Would WG14 like to add N3192 to a Standing Document for addition to the draft of C2y when it becomes available?
19 / 0 / 1

ACTION: SEACORD to add N3192 to a Standing Document for addition to the working draft of C2y.

Discussion that this may conflict with file permissions convention; that printf and the preprocessor are not completely consistent with the base language; that escape sequences should prefer delimiters as seen in C++; that this is a common pitfall but we also cannot change the meaning of existing code; deprecation does not have to imply removal or a change in existing meaning; that an alternative is needed for the current valid usages; that this is a good use case for obsolescence because it forces warnings to be emitted early.

Straw poll (opinion): Would WG14 like to add something along the lines of N3193 to C2y?
18 / 1 / 1

Straw poll (opinion): Would WG14 prefer to immediately obsolesce the original octal literal syntax?
11 / 4 / 4

Discussion over the merits of named control structures vs. simply using goto, with a division of opinion with some strong support for only allowing goto; location of the label is potentially confusing, but convention is already firmly established out-of-language; comparison with conventions of other languages; consider that this could allow arbitrary breakout and whether we intend that.

Straw poll (opinion): Would WG14 like to add something along the lines of N3195 in C2y?
12 / 6 / 3

Discussion about the precise use of punctuation and the impact on downstream languages; that using :: as an operator causes major problems for C++, and namespaces if they are added in future; that GCC's syntax does actually work in the field; that using unbalanced bracketing is a non-starter; whether we need the right-open range at all.

Straw poll (opinion): Would WG14 like to add something along the lines of N3194 in C2y?
19 / 1 / 2

Straw poll (opinion): Would WG14 like to add something along the lines of the right-open range operator suggested in N3194 to C2y?
6 / 8 / 8 (no consensus to add this)

Strong positive reception from the room; questions about scope of the declaration and noted that it should match exactly the scope in the equivalent C++ construct; currently no user experience but noted that implementation is trivial; noted that the syntax definition in the grammar is highly confusing, which is an artifact of trying to copy C++ too exactly; noted that this has nothing to do with "assignment in if", which is just an expression; assignment is common and this would reduce that vulnerability; we can extend to allow multiple-declarations if really wanted; multi declarator syntax already works.

Straw poll (opinion): Would WG14 like to add something along the lines of N3196 to C2y?
15 / 0 / 7

Discussion of how other languages do or don't specify this; impact on for loops and side effects against the same object becoming well-defined; noted that no portable code breaks because of this; argument that UB in some of the existing examples is a good thing because it makes diagnostics easier without relying on secondary rules; counterarguments that dropping UB is good, actually; questions of how useful the existing behavior really is; noted that semantic ordering may be better than strict left-to-right in some cases; noted that applying the change to initializers may have significant optimization impact as currently specified; requests for more data; noted that C++ originally proposed the complete change but pulled back only at the last moment, without contradictory data. Argument that we should avoid repeating the mistakes of C++.

Positive reception to the direction but concerns over how intrusive the implementation would be.

Straw poll (opinion): Would WG14 like to add something along the lines of N3203 in C2y?
15 / 4 / 2

Discussion points: those who don't want overloads at all think this is a better approach than the C++ mechanism; that while constrained this approach would be more verbose and potentially messy to read; that the division between approaches can be drawn in many places; implementer experience with both approaches notes that implicit conversion can make reasoning difficult; that we have an opportunity to define where conversions and promotions happen; that this composes better with generics; that a solution for "best match" is needed less in C than in C++ but still needed; experience from LCC that implicit conversions were not difficult to allow; experience from Clang (and QAC) [[overloadable]] that resolution is possible; Clang finds [[overloadable]] is widely used in practice and a strongly supported feature.

Not polled.

No new content discussed, only procedural updates. The TS had not yet been assigned a number and the title is not the agreed one.

Brief discussion of future directions; the two features do not compose and this needs resolution. Also needs to consider the following feature.

Not polled.

Noted that this was previously voted to proceed to a TS.

Improvements and changes introduced: now substantially more concrete, resolved conflicts with lambdas and other proposed new features; significant review of praxis especially in the Linux kernel; completely removed all runtime aspects, fixing mistakes introduced by Go; noted that current version does not imply storage or exception awareness or require unwinding to work; discussion of usability in comparison to other approaches; discussion of feature implications in comparison to different features like try/finally in other languages; noted that the proposal exactly corresponds to C++ destructor semantics; debate over the relative UX merits of defer vs destructors and __finally and where they place operations; argument made that defer is specifically a better solution for C and for C code compared to other solutions suiting other languages; noted that this is a blocker for tail-calls; noted that this doesn't include a panic/recover scoped-error mechanism, which was in the first version of the feature; concerns about the validity of the examples but strong positive reception from users (ARM stated support for the record); most concerns about implementation appear to have been resolved; discussion about the best UX for conditional-cleanup and whether this enables that vs. approaches that hide state.

Noted that the TS was originally proposed and approved for a much more complicated version of the feature and that this proposal may no longer warrant it. However, given a TS, implementers are still more inclined to ship this before C2y, probably not without one. A TS can still be ready by end-of-year.

Straw poll (opinion): Would WG14 like to develop something along the lines of N3199 as a TS?
14 / 2 / 5

Straw poll (opinion): Would WG14 like to add something along the lines of N3199 in C2y?
11 / 5 / 5

National Bodies voting to support and review a TS:
United States, United Kingdom, Canada, Netherlands, Poland, France

ACTION: SEACORD to submit a NWIP to SC22 for the defer TS.

Justification that if defer is introduced, users probably expect it to unwind. Some experience from C++ destructors; less supported by existing longjmp mechanism. This proposes to define the specific amount of unwinding that does or does not occur, in a way compatible with C++ mechanisms. A new section would be added if defer is added.

Noted that signals introduce many more scenarios, async etc., needing additional qordings for the equivalent states the program can be in; concerns that this may make defer less attractive to implementers by raising the complexity burden; noted that the real issue is divergent practice and that this needs to clarify, not add - this is not a part of the defer feature; concerns that this is an inherently flawed approach because the unwind may originate in a non-C translation unit; noted that by adding this as a toplevel TS clause, vendors would be free to discard it; concern about various levels of conditional recoverability that need specification; noted that the original Committee deeply regretted adding signal and raise in the first place, not portably useful; question over which part of the implementation is responsible for this, does the compiler make it work or let it work; preference expressed for non-unwinding specification; noted that unwinding can result in cascading error conditions.

Straw poll (opinion): Would WG14 like to add something along the lines of N3198 to the defer TS?
2 / 13 / 5 (no consensus)

(note: this does not prevent the authors adding a separate Clause, but the Committee is not asking them to spend any more time on this)

Introduced as "typedef but for functions". Some background on comparison with existing asm-label approaches and how this enables seamless ABI changes.

Questions about how this necessarily solves the underlying problem, vs using a macro; noted that this doesn't support dlopen; apart from the & operator, auto constexpr already provides 95% of the proposal; removing the "suppression rule" would break large amounts of code; ABI breakage is more often about types, and not internal to single libraries but requires passthrough across translation units, so cannot be fixed just in one place or purely inside the language.

Straw poll (opinion): Would WG14 like to add something along the lines of N3200 to C2y?
7 / 5 / 9 (not clear consensus)

Introduced with valuable additional context from CFP. The imaginary operations change domain differently and have slightly different results, but these are also unsupported in practice. One known implementation (HP) that does not appear to be maintained or up-to-date.

Discussion around the UX of the proposed suffix; whether users/customers actually want or ask for this; comparison to Chapel language, where the feature is being newly added, and Fortran, where it can have mixed-precision; noted that users complain about the feature macro because they don't use the feature; note that this requires collusion between compiler and library implementers, who may be different; discussion over the practical utility of the type in general.

Straw poll (opinion): Would WG14 like to remove imaginary types from the C standard for C2y?
11 / 2 / 10 (consensus to remove)

The previous queue of clarification requests has been processed.

Introduced with the justification that the best option is to give users the tools to express themselves within the language, rather than relying on builtins. Use case examples including new number and vector types, fat pointers, and others.

Discussion of the dependencies - does this imply hidden allocation? (no); what other language features does this pull in, e.g. C++ references, RAII for allocations; some user-side use cases may want unconstrained allocation, there are potential solutions to this, including user-side GC; objections raised to searchability, readability, and general UX of operators; noted that the proposal allows overloads of many more operators than the basic set; concerns over complexity of call resolution; concerns from members who do want operator overloading that it should not follow these lookup rules; agreement that C cannot be made "small" by just moving everything interesting to Annexes; operators do allow more work to be done by library developers; _BitInt is an example of limitations of baking the feature into the compiler resulting in non-portability; concerns about the proposal focus on free functions instead of type relations to existing operators; concerns about the role of implicit conversions; concerned that this has not been designed to suit C even though the resolution rules are simplified from C++.

Straw poll (opinion): Would WG14 like to pursue operator overloading for C2y, in any form? 5 / 11 / 7 (not consensus to proceed)

(note 1: the Committee will not prevent future proposals being submitted on this topic)

(note 2: N3201 was not discussed because the author was not available, but it was acknowledged that the timing of the vote was potentially unfair and they will not be prevented from resubmitting)

Does WG14 want to remove all outward references to other Clauses from Clause 3?
3 / 8 / 8 (no consensus)

Does WG14 want to lift subclauses 3.20.2, 3.20.4, and 3.20.5, to the top level of Clause 3?
12 / 3 / 5

Does WG14 want to resolve ISO comment 188 by rejecting the comment?
16 / 1 / 3

Does WG14 want to accept all change dispositions to comments as specified in document N3216?
19 / 1 / 0

Does WG14 want to submit TS-18661 part 4 for publication as-is?
12 / 3 / 5

Does WG14 want to submit TS-18661 part 5 for publication as-is?
13 / 0 / 6

SEACORD to submit the drafts of TS-18661 part 4 and part 5 to SC22.

SEACORD to add N3192 to a Standing Document for addition to the working draft of C2y.

SEACORD to submit a NWIP to SC22 for the defer TS.

WG14 motion: Bhakta moves to adjourn. Wiedijk seconds. No objections.

Adjourned.