On Sat, Apr 13, 2024 at 2:13 AM Thiago Macieira wrote:
>
> Assume it is and write your proposal. The implementations will either confirm
> that it is and implement it in the proper way, or they will tell the committee
> it is impossible.


There are 3 reasons why I preoccupy myself with implementation and why
I supply a 'possible implementation' for Linux/Microsoft/Apple with my
papers (much to the dismay of a lot of people here):

    (1) It gives the paper a little more impact if the reader can see
it alive and kicking
    (2) It shows the compiler vendor that what I'm proposing is
possible (just in case they thought it wasn't possible)
    (3) It shows the compiler vendor that what I'm proposing is
possible (just in case they don't want to implement it and are lying
about what's possible)

Now look, I'm not going to say that I know more about the Microsoft
compiler than the guys working at Microsoft, but sometimes a
reverse-engineer can discover something that the original engineer
didn't notice. For example, just as a hypothetical, let's say that the
guys at Microsoft had put a link from the _RTTILocator object to the
type_info struct, but not vice versa. So they might tell the
committee, "This isn't possible on the Microsoft compiler without an
ABI break because we can't get an _RTTILocator from a type_info". But
then a reverse-engineer comes along and discovers something. . . maybe
the reverse-engineer discovers that the Microsoft compiler always puts
the _RTTILocator at a lower address than the type_info struct, that
the two objects are always in the same page of memory, and that there
is a mathematical relationship between their two addresses which is
consistent in every EXE and DLL file produced by the compiler.

So anyway long story short, I'm going to continue to provide
implementations for Linux/Microsoft/Apple in my papers, even though 9
times out of 10, the compiler vendor will probably do a better job of
it than me.