On 12/02/2026 09:14, Robin Savonen Söderholm via Std-Proposals wrote:
> I like this tag-idea, as it could be used for real time safety and
> probably other guarantees as well.
>
> // Robin

I don't know if you followed the link to the gcc feature request, but
the examples I had there were all in that line. Tag examples were
"irq_disabled", "in_ram", and "got_lock". (You'd use different tag
names for different locks.)

David


>
> On Thu, Feb 12, 2026, 08:46 David Brown via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
>
>
> On 12/02/2026 08:07, Steve Weinrich via Std-Proposals wrote:
> > Many years ago we had a similar issue with threads. We wanted a
> means
> > to keep the data that could be accessed from a thread declaratively
> > distinct from the non-thread data. We ended up declaring a class to
> > represent a thread and used a nested class to represent that threads
> > specific data. I am wondering if a similar approach would work here
> > without any language extension?
> >
>
> I had a related idea for adding "tags" to functions to help control
> which functions are allowed to call which other functions. My interest
> was primarily for embedded systems - so tags would be for things like
> "interrupts disabled" or "in ram" (you don't want your flash
> programming
> code accidentally calling functions that are in flash!). The same
> concept would work just as well for controlling functions that can be
> used with different threads, and for canon/non-canon functions.
>
> I filed it as a feature request for gcc, as a function attribute, but
> nothing came of it:
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88391
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88391>>
>
>
> I had not looked at marking data in any way here - maybe that would be
> necessary, but it is also possible that that could be handled within
> the
> existing type system. But I think a critical point is that if any
> related checking system is added to C++, it would have to be with
> user-defined tags. There is no way the standard is going to add extra
> keywords to support a small niche market (lots of people are
> involved in
> writing games, but very few work in the heart of high-performance game
> engines). But the concept could be widened to be of use to a much
> larger audience by making the tags user-definable.
>
> The core of my feature request was:
>
>
> My suggestions for function attributes are:
>
> 1. __attribute__((tagged("tagname")))
>
> Mark a function as being tagged with "tagname" (or multiple tag names).
>
> 2. __attribute__((caller_tag("tagname")))
>
> Mark a function as only being callable by a function with this tag.
>
> 3. __attribute__((callee_tag("tagname")))
>
> Mark a function as only being allowed to call functions with this tag.
>
> 4. __attribute__((caller_notag("tagname")))
>
> Mark a function as not being callable by a function with this tag.
>
> 5. __attribute__((callee_notag("tagname")))
>
> Mark a function as not being allowed to call functions with this tag.
>
>
> There would also need to be a statement attribute:
>
> __attribute__((tag("tagname")))
>
> Mark the statement as having this tag (and therefore being allowed to
> call matching "caller_tag" functions, and not allowed to call matching
> "caller_notag" functions).
>
>
> mvh.,
>
> David
>