On Thu, 12 Feb 2026 at 07:47, David Brown via Std-Proposals <
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>
>

This is function colouring:
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
Naming the attribute "colour" instead of the highly generic "tag" would be
an improvement IMHO, although we'd probably have to settle for "color".

25 years ago Alexandrescu wrote about (mis)using 'volatile' on member
functions for that purpose in multithreaded code:
https://erdani.org/publications/cuj-02-2001.php.html
N.B. what he says about the intended usage of 'volatile' on primitive types
was mostly wrong in 2001 and is entirely wrong since 2011, as
https://isvolatileusefulwiththreads.in/c++/ says. The part that's relevant
here is using the otherwise not very useful 'volatile' qualifier as a way
to colour some functions as thread-safe so that you can only call functions
of that colour from other functions of that colour. Your proposed GCC
attribute would give you extensible user-defined colours, instead of being
limited to just volatile and non-volatile colours.