What about just add a typedef member to the class implementation. So if the creator of the class thinks that it is not relocatable for any reason he just add.typedef not_reloc;Then in your container implementation you can just overload based ob that typedef or just SFINAE it away, or require it by a constraint?Sent from my Galaxy
-------- Original message --------From: Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Date: 10/30/25 6:33 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Thiago Macieira <thiago_at_[hidden]> Subject: Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct On Thursday, 30 October 2025 10:14:56 Pacific Daylight Time Frederick Virchanza Gotham via Std-Proposals wrote:> On Thursday, October 30, 2025, Thiago Macieira via Std-Proposals wrote:> > We're just not going to use the feature. It's not the first time we ignore> > a> > Standard feature because we think we can do something better and will not> > be> > the last.> > I'm dumbfounded that there are some people here who think that invoking an> encryption algorithm is 'trivial'. Utterly dumbfounded.Who said anything about encryption?I'm talking about ignoring the Standard's relocation feature. We'll just keep our own that we've had since 2005. The only change we need, which we have already made, is to mark that polymorphic types on ARM64e are not relocatable. It's not very good because it's not transitive (doesn't apply to contained sub-objects in a larger one), but those are even more uncommon than polymorphic types stored in containers.But at that point, it becomes Oliver's problem: developers will be testing an ARM64e build in parallel to an ARM64 one and notice that the only difference is the target, so they'll complain to the toolchain. It's an incorrect blame, but nevertheless it's what I predict will happen at first, until there are enough StackOverflow answers.If it becomes a severe enough problem, we'll just turn off the ability to opt-in to relocatability and allow only a closed set of Qt types to do it. It'll be slower and use more memory, matching std::any performance.-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.