2 complement arithmetic is not a good comparison, since it is clearly observable from the source code semantics. Wever it affects any lower level or machine semantics is or how it should be implemented is also irrelevant. And again, the only concern of the standard is the source code semantics of the signed arithmetic. It was not normalized because most machines work this way, though this is what made it feasible. It was normalize because the bitwise signed arithmetic model has no predictable behavior in a *strictly conforming program* (ie, a program that does not rely on unspecified or implementation defined behavior). For instance, (non overflowing) bitwise shift of a negative had just no portable uses; bitwise logic was well defined (I think) but you'd have to know the details of how sign is implemented to be able to interpret the result.

The addition of 2 complement arithmetic was added specifically to have a simpler semantic model for signed arithmetic at the source code level. This closed a gap between a hole lot of code base that would rely on it already, and that would break if they ran on non 2 complement machines.

Now, in contrast, adding specification for translated translation units, or restricting, or prohibiting, or keeping status quo does not change behavior of conforming programs, and does not simply the mental model of the source code. In the opposite, now the specification will need to take into account entities other than TUs, that means a combinatorial number of clauses that mentions TU in the standard will need to be analysed to see how it can potentially interact with those new kinds of physical program fragments.

So, what kind of problems are we interested in solving anyways with this?.



On June 25, 2023 5:25:35 p.m. EDT, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Sunday, 25 June 2023 12:13:59 PDT Julien Villemure-Fréchette via Std-
>Proposals wrote:
>> This proposal is most related to ABI, and I think this would be out of scope
>> for the specification of C++ language; the specification is strictly
>> concerned about language level semantics (the _abstract machine_) and
>> specifies no more requirements on implementation details than is necessary
>> to permit concrete implementations achieve a maximum level of semantic
>> consistency (portability) of the *source code* (with a strong emphasis),
>> while keeping it possible to implement in an efficient way. See section 4.1
>> [intro.compliance]; it defines the scope of the C++ standard. Any formal
>> specification clearly indicates its scope, thereby limiting how it can
>> eventually evolve. Such a distinction is important to make the
>> specification evolve in a direction which is consistent with the original
>> intents and objectives of it.
>
>I disagree with such a limiting definition. The standard can still concern
>itself with the abstract machine, but it wouldn't hurt the language to
>standardise what every compiler needs to implement today in one of two well-
>known extensions We should face reality and accept that libraries do exist and
>seek to make them easier to deal with, at least from inside the language.
>
>That said, there are a lot of pitfalls to be addressed. This proposal doesn't
>even begin to looking into thinking of scratching the surface of the problem.
>It's more of a statement of intent. Libraries, should we decide to explore
>them, would probably require a full Study Group.
>
>> The current working draft makes no normative statement on the concrete
>> entities that represents translated TUs (the so called object filed), how
>> they are organized (both internally and externally) or how they interact
>> (ie how they communicate). Hence, adding specific requirements that would
>> only affect the nature or morphology of translated TUs, is just immaterial
>> as it has no observable interaction with the rest of the standard. Unless
>> the abstract concept of "shared library" is defined in section 5 [lex] and
>> referred to elsewhere in the standard, such an entity name is no more
>> special than other external name other than being marked as such. Hence, a
>> conforming implementation could as well just get this entity from an object
>> file statically as there is no material difference (yet) between obtaining
>> the entity from a static lib, a shared lib, or even anywhere the build tool
>> might have chosen. That's unless you further propose an actual *formal
>> specification* of what's a shared lib (and also what's library at all).
>> Your definition will need to cope with the possibility that an
>> implementation might not have a dynamic linker (ie, a loader), or even a
>> linker at all. What about freestanding implementations, or an
>> implementation that is a C++ interpreter (which is not precluded, as it can
>> legitimately implement the semantics of the "abstract machine" which is the
>> subject of the formal specification), etc.
>
>All true and all completely irrelevant, because all of the above needs to
>still be possible after adding some language to support the existence of
>libraries. In other words, whatever language gets added can't remove the
>freedoms that implementations may still need. Implementations without files or
>freestanding or what have you can fit into one of the possibilities allowed by
>the standard. What matters is that *if* you have one of those libraries, the
>behaviour is what the standard specified.
>
>Note I said "may still need". The standard hasn't recently shied away from
>removing freedoms that were deemed unnecessary, like non-complement-of-2
>conversion.
>
>> The standard doesn't go into the details of how "separate compilation", and
>> goes no further than translation units as the fundamental structure of
>> program fragment, as there would be a countably infinite number of equally
>> legitimate ways to implement a (conforming) program so as to observe
>> mandated behavior.
>
>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals