Similar and from an example of usage,

*Safer Range Access*
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2955r1.html

How about 2 attributes?
[[safe]]
[[unsafe(reason=["range", "dangling_reference", "reference_invalidation"],
alternatives=["function signature", "function signature"])]]

The problem with the NO arguments of linters and static analysis apart from
the language is that there are NO standard separate linters and static
analyzer tools.

So what is being asked for is for the standard to standardize attributes
that could be used by non standard tools.

2nd: For the standard to consider adding separate or [later] built into
compiler these tools. There is a tools study group.

The purpose of this is for *auditing*, *documentation *and *specification *
purposes.

A tool, if provided, wherever provided, would output a report in a standard
easily parsable format such as JSON providing information such as the
following:
1) #lines of code before include
2) #lines of code after include
3) how many functions unattributed
4) number of safe calls
5) number of unsafe calls per reason

In short:

This proposal is 0 overhead and doesn't break backwards compatibility
because no assembly is generated.
The first phase could be quickly done because how long does it take to
standardize 2 documentation attributes.

...
...
...

Other attributes could also be standardized for auditing, documentation and
specification purposes at little cost to the current standardization
effort. Using the information could come later.

Reference checking
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2878r5.html





On Sun, Nov 5, 2023 at 8:48 AM Yexuan Xiao via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> It is possible to vote on whether to mark a feature as discouraged. C++
> didn't invent nullptr to coexist with NULL. If users continue to use old
> algorithms instead of constrained algorithms year after year, why is the
> standards committee working on this? linter is also part of the c++
> ecosystem, and the committee should respond. C++ has long been plagued by
> security problems, print is a safe alternative to printf, and continuing to
> use printf is hastening the death of C++.
>
> ------------------------------
> *From:* Jonathan Wakely <cxx_at_[hidden]>
> *Sent:* Sunday, November 5, 2023 21:05
> *To:* C++ Proposals <std-proposals_at_[hidden]>
> *Cc:* Yexuan Xiao <bizwen_at_[hidden]>
> *Subject:* Re: [std-proposals] Keeping C++ Young: Migrating to Modern C++
>
>
>
> On Sun, 5 Nov 2023, 12:56 Yexuan Xiao via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
> Facilities like printf were meaningless after prinf was added to the
> standard, but since printf is widely used, deprecateing them is harmful
> to C++. new is vital to C++, we need its placement version, and deprecateing
> it harms C++'s ability. NULL, rand, qsort that should not continue to be
> used, but they should not be removed either.
>
>
>
> Again, this is something better handled by a linter or code analysis tool.
>
> My project might want to replace all uses of rand() but keep using printf.
> With a third party tool I can select which suggestions to enable/disable
> for a given project.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>