On Saturday, 17 February 2024 09:47:47 PST Frederick Virchanza Gotham via Std-
Proposals wrote:
> The second technique is to simply extend the original class. The second
> technique is as follows:
>
> class IDevice {
> public:
> virtual char const *GetName(void) = 0;
> virtual unsigned GetType(void) = 0;
> virtual void *GetInputBuffer(void) = 0;
> virtual void *GetOutputBuffer(void) = 0;
> };
>
> This won't change the size, alignment or layout of an 'IDevice' object --
> it will just extend the vtable by two pointers. This isn't an ABI break.

It is for any class deriving from IDevice that wasn't recompiled with the new
definition. Your original problem had a narrow definition:

> Objects of the type IDevice are only ever created or destroyed inside my
> library

That's a very constraining case. In the general case, you cannot guarantee
that. Having wording to allow for this very particular case and not induce
people into thinking that they are more general valuable is going to be a
major challenge.

Plus, I've seen problems inside of a given module too. We've had reports of
customers compiling applications using static libraries provided by third
parties who can't or won't rebuild their content. That means you can't
reliably even constrain to "inside of a binary" in the real world.

That means your trait is a definite no-go because it's not generally useful in
the real world. It can't know whether the postconditions are going to be
satisfied, exactly because they happen later.

If we remove the trait, we don't need the language change either. That means
you have no change required in the Standard.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering