Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

"potentially throwing" v.s. "potentially-throwing"

Open Beginner friendly
  • Is something wrong?
#9,350 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@frederick-vs-ja is already working on this.

Since Sep 28, 2026.

  • #9353 by @frederick-vs-ja — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
tex
Domain
documentation

Research direction

Start by searching the draft source for “potentially throwing” and compare each occurrence with the definitions in [except.spec]/1 and 6. Review the listed clauses, including [basic.stc.dynamic.deallocation]/3, [concept.destructible]/2, and the [exec] clauses, then update the inconsistent wording. Done means the cited occurrences use the terminology consistently and no unintended matches are changed.

Written by the indexing model from the issue text.

Description

decision-required

The correct form seems to be "potentially-throwing" (with hyphenation), see [except.spec]/1, 6

The predicate indicating whether a function cannot exit via an exception is called the exception specification of the function. If the predicate is false, the function has a potentially-throwing exception specification, otherwise it has a non-throwing exception specification. ...

An expression E is potentially-throwing if ...

The following lists occurances of "potentially throwing".

  • [basic.stc.dynamic.deallocation]/3

Each deallocation function shall return void. A deallocation function shall not have a potentially throwing exception specification ([except.spec]). ...

  • [except.spec]/4

If a declaration of a function does not have a noexcept-specifier, the declaration has a potentially throwing exception specification unless it is a destructor or a deallocation function or is defaulted on its first declaration, in which cases the exception specification is as specified below and no other declaration for that function shall have a noexcept-specifier. ...

  • [concept.destructible]/2

[Note 1: Unlike the Cpp17Destructible requirements (Table 35), this concept forbids destructors that are potentially throwing, even if a particular invocation of the destructor does not actually throw. — end note]

  • [exec.snd.general]/3, 4

... [Example 1: Let sndr2 be the sender then(sndr, fn). sndr2 has the same set_value completion domain tag as sndr, but if fn's evaluation is potentially throwing, sndr's set_error completion domain tag would be the COMMON-DOMAIN of sndr's value and error completion domain tags, in accordance with the semantics of the then algorithm ([exec.then]). — end example]

[Example 2: Let sndr2 be the sender from the example above. The set_value completion scheduler of sndr2 is the set_value completion scheduler of sndr, if any. But sndr2 can only report a set_error completion scheduler when invocations of fn are not potentially throwing or when sndr has no set_error completions. When fn can throw, sndr2 could complete with set_error either by forwarding an error completion from sndr or by completing with the exception thrown by fn, which would happen on an agent associated with sndr's set_value completion scheduler. — end example]

  • [exec.snd.expos]/22, 32

Remarks: The expression in the noexcept clause is true if the return statement above is not potentially throwing; otherwise, false.

Remarks: The expression in the noexcept clause is true if the return statement is not potentially throwing; otherwise, false.

  • [exec.continues.on]/10

The expression in the noexcept clause of the lambda is true if the construction of the returned state-type object is not potentially throwing; otherwise, false.

Dominant language
TeX
Stars
231
Forks
815
Avg merge
1d 11h
Merged PRs (30d)
8

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cplusplus/draft

All issues in cplusplus/draft

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.