I didn’t backtrack, I just said that the feature is not related to my specific use case. I came up with this in that specific context, but it is not relevant to it.

I’ll try to write a comprehensive example but I’d rather not make this about my particular problem, but about a constexpr std::filesystem api. For it to be something useful beyond my specific use case which people might or might not agree, I’ll have to provide other use cases.

I understand and appreciate all the valid concerns, I agree that , in general, it would create problems, thus it could be a opt-in feature of the language ( like many others) for projects and environemnts where those concerns are not valid.

On Tue, Mar 12, 2024, at 15:57, Jason McKesson via Std-Proposals wrote:
> On Tue, Mar 12, 2024 at 9:53 AM Andrei Grosu via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> If a malicious actor got inside my company and can freely access ‘ide’s and my build system, any hypotetical security considerations are moot.
>>
>> Code can be validated cryptographically, along with the entire build system. Security-aware people have been coming up with design patterns and tools for this.
>>
>> If this is a security risk, which it is, I’m not denying , then maybe the ISO board should wake up and realize it’s 2024 and some security considerations for the language are long overdue. I mean Java baked this into the language a gazillion years ago.
>>
>> Just saying that it’s bad and it should not be used is not very useful.
>
> Here's the thing though. You're the one proposing the feature. You are
> therefore the one who has to justify it. You have to provide reasoning
> as to why it's important for C++ to have this feature.
>
> You started with the use case of a build system, but then you
> backtracked and don't want to talk about that anymore. OK, but now
> your proposal has no motivation. And therefore, it's bad by default.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals