Date: Fri, 14 Nov 2025 12:11:37 -0800
Again, please provide a specification, not an implementation.
This isn’t a case of being facetious: I literally do not know what this proposal is for.
Even something as simple as that API and the expected output.
A type_trait implies a compile time behavior of the type, not an object query, yet this thread seems to imply a per object specification.
I know that there are plenty of cases where an object is placed in something like ROM (or functionally ROM), I have done so, but that’s a property of the object, not the type itself.
*If* this is intended to be a runtime state query it should not be in type_traits - as it is not a type trait - but a general “is this memory guaranteed to be immutable” query is not de facto unreasonable. There are such interfaces on darwin which are used to provide security guarantees (e.g pages that once they are mapped are never able to be writable again within the process - not even by the kernel).
But because you haven’t included anything in your proposal about what it actually is - you say you’ve provided an implementation but this time we don’t know anything at all about what the API is meant to do. I can provide an implementation of a function (in JS because huzzah!):
function this_is_why_god_has_abandoned_us(of) {
var let = of;
for (let of of let) {
let.delete(of)
let.add(of)
}
}
Beyond answering an important question, we have no idea what this function does (I mean in principle we do because *tada* it is completely specified and well defined. You’re welcome. Even the syntax highlighter struggles :D).
—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
This isn’t a case of being facetious: I literally do not know what this proposal is for.
Even something as simple as that API and the expected output.
A type_trait implies a compile time behavior of the type, not an object query, yet this thread seems to imply a per object specification.
I know that there are plenty of cases where an object is placed in something like ROM (or functionally ROM), I have done so, but that’s a property of the object, not the type itself.
*If* this is intended to be a runtime state query it should not be in type_traits - as it is not a type trait - but a general “is this memory guaranteed to be immutable” query is not de facto unreasonable. There are such interfaces on darwin which are used to provide security guarantees (e.g pages that once they are mapped are never able to be writable again within the process - not even by the kernel).
But because you haven’t included anything in your proposal about what it actually is - you say you’ve provided an implementation but this time we don’t know anything at all about what the API is meant to do. I can provide an implementation of a function (in JS because huzzah!):
function this_is_why_god_has_abandoned_us(of) {
var let = of;
for (let of of let) {
let.delete(of)
let.add(of)
}
}
Beyond answering an important question, we have no idea what this function does (I mean in principle we do because *tada* it is completely specified and well defined. You’re welcome. Even the syntax highlighter struggles :D).
—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
Received on 2025-11-14 20:11:46
