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@lists.isocpp.org> 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.