Frederick (I know this is not your name, and you need to start using your name as listed in the iso member registry, I won’t initiate that but you need to)

I’m still not sure what this feature actually is - the “proposal" still does not have any kind of specification so this discussion is extremely unclear because no one actually knows the intended behavior. Again, this is why you need to actually provide a specification, not implementations or APIs, an actual specification: the motivation and actual use cases, the interface, the intended semantics of the proposed feature, the API itself, and how that API relates to the specified behavior of the proposal.

Because you have not provided this information there’s a lot of argumentation on this thread that is due entirely to the fact that everyone is having to guess about what you actually want or mean in this proposal. Everyone has different ideas of the intended behavior because we are literally having to guess what you mean.

While I have said previously I want fully considered specifications from you, this thread has literally no information about what is meant to happen, so at this point I would accept _anything_. Not providing this bare minimum means this thread is wasting people’s time because we’re trying to discuss semantics and behavior with no way of knowing what they even are.

I and other people on this list have explained at length why implementations are secondary to the specification, but this case is even more useless than usual. The only thing you have provided is an implementation, but that implementation is not covered by the ISO IP agreements so many people on this list cannot look at it. So even if we did consider such an implementation to be a reasonable substitute for a specification we cannot look at it, so we have literally no way of knowing what this proposal is.

—Oliver

> On Nov 14, 2025, at 6:38 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Microcontrollers have a single address space for non-volatile and
> volatile memory.
>
> 0x0 - 0x2000 might be the non-volatile Flash
> 0x2000 - 0x8000 might be the volatile SRAM
>
> At runtime, the flash can be toggled writable or read-only.
>
> Similarly on desktop PC's, a page of memory can be toggled from
> writable to read-only.
>
> If we store a 'const' object in a section of memory that later gets
> set read-only, we need to be sure that it is really a const object --
> i.e. it can't contain mutable members.
>
> So I've implemented "std::contains_mutable". Here's my compiler patch
> for GNU g++:
>
> https://github.com/healytpk/gcc-thomas-healy/commit/tag_contains_mutable
>
> And here it is tested up on GodBolt:
>
> https://godbolt.org/z/KosvqTETo
>
> Looking over the recent papers on reflection . . . I think this would
> be done in reflection as follows:
>
> https://godbolt.org/z/4ezv58zxx
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals