On 12/02/2026 10:48, Jonathan Wakely wrote:
>
>
> On Thu, 12 Feb 2026 at 07:47, 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>>
>
>
> This is function colouring:
> https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ <https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/>

It could be worse: <https://en.wikipedia.org/wiki/ColorForth>

> Naming the attribute "colour" instead of the highly generic "tag" would
> be an improvement IMHO, although we'd probably have to settle for "color".
>

As long as any future "units" library is metric only, I won't complain
about US spelling :-)

I don't know if "colour" is a good choice of terms here, but I'm happy
to agree that "tag" is a poor choice.


> 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
> <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++/
> <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.
>

Yes, I remember that article, and was thinking about it when I made my
feature request, and when posting here. The use of "volatile" can be
deceptive (it does not do what some people think it does, especially on
big modern cpus), and it also leads to less efficient code generation.
But it /does/ give a certain control about what methods can be called
for which objects. A feature that could similar control, but with
user-defined naming, would be a big help.


An alternative solution would be if there were support in C++ for truly
zero-overhead tag types. A "tag type" is a class type that contains no
data, generally has no methods, and is used primarily for distinguishing
overloads. My "tagged" functions could be handled making a tag type
such as "irq_disabled" with a non-public constructor - you only get to
create one with the type's friend "disable_interrupts()" function.
Functions that should only be called with the interrupts disabled, will
then take an "irq_disabled" parameter.

This would not help for marking functions as not callable when you have
a particular tag. And they are not zero overhead - they still take a
parameter slot in the function call (which is particularly costly in the
disaster that is the 32-bit ARM EABI, designed for 1980's C rather than
2020's C++). Ideally it should also be possible to restrict them from
being stored in anything other than local variables. In practice, such
tag types are the best we can do at the moment in C++, but there is
potential for improvement.


(I don't quite agree with your declaration that "volatile" is not useful
in threads. If you are talking about multi-core processors and "big"
host OS's, then "volatile" is neither necessary nor sufficient - atomics
are the way to go. But for RTOS's on a single core system, "volatile"
is without doubt an important tool in the context of threads. Standard
C++ or C atomics, on the other hand, should be avoided, at least with
gcc - the libatomic implementation is totally broken for such systems.)