On Thu, Aug 29, 2024, at 17:50, Thiago Macieira via Std-Proposals wrote:
> On Thursday 29 August 2024 14:59:31 GMT-7 Tiago Freire via Std-Proposals
> wrote:
>> I'm unconvinced that the "bad cases" are not just a product of bad build
>> architecture, if done properly a compiler should never be presented with
>> multiple alternatives of the same file. And putting such requirements on
>> compilers puts an unnecessary burden on developers to support a scenario
>> that it is that is arguably bad practice.
>
> They may be, but they exist. I'll agree that the majority of the bad cases are
> bad architecture, but I cannot guarantee they ALL are.
>
> The last time this discussion happened, I mentioned another argument: the
> problem that when this problem happens, it happens to the person who is
> compiling, not the person who wrote the code. Very often, the person building
> the code has much less knowledge about the intricacies of the language, has
> little time to debug it, and often has no power over the build environment.
> That means we transfer the problem from the developer of the content to the
> user of the content and/or the compiler.
>

To add to that, bad environments are a product of IT and so the person compiling has no control.

thourh I have found it use useful to install the same header to several paths. My package manager can then enforce rules of what different classeses of downstream can use. Works great until a dowstream project is multiple classes.

for the above reasons (and more) file based pragma once needs to come with a rule that third party libraries must not use it. Of course the standard currently doesn't have that concept and so now we add pages to formally define it.

i think I can live with the downsides of binary identical if the performance is acceptable. Most of the examples make me think IOCCC not something I would allow in the real world, but I'm open to an example where it is the best answer.