On Thu, 12 Sep 2019 at 14:17, Rene Rivera via SG14 <sg14@lists.isocpp.org> wrote:
On Thu, Sep 12, 2019 at 7:05 AM Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:

1. If I understand correctly, as soon as you add `layout:` in a class definition, you _must_ list all non-static member objects. Correct?

No..

* Members listed would come first in the class member layout.
* Members not listed would follow with the existing layout rules.
 

I see, makes sense.
 
2. I infer that two classes with the same name in the same namespace with the same members but different layouts leads to a compilation error.
Am I correct?

Ah.. Wouldn't you get duplicate definition error currently? Or at least link errors if they happen to be compiled in different TUs?
 

If the layout part is part of the definition, then I believe that would be like that but it was not clear from the proposal.
For example:

struct X
{
public:
    int a;
    int b;
};

struct X
{
    int a;
    int b;
};

struct X
{
private:
public:
    int a;
private:
public:
    int b;
};

My current understanding is that these 3 definitions do not break ODR if defined once in 3 separate cpp files of the same program (no link error, defined behavior).
If I am correct, then it is not clear to me if `layout:` participate to the definition or not.
I do expect it to do participate to the definition and different layout breaks ODR, as expected, it's just not stated as such.
  
5. How would that impact classes with virtual function members? Should the implementation of the virtual calls (through v-table usually)_ be ignored and be implementation-defined? Or should it be visible in the layout section?

This is for layout of the data members only. I.e. it would be an error to specify functions in the layout section. Not sure how it applies to the vtable. Can you elaborate?


Sure:
I am basically asking for a clarification in the paper that the feature only affects order of data members (and alignment if it's ok) and does not affect other unspecified implementation details like how virtual functions are implemented (where the v-table pointer is placed, if the implementation uses the v-table technique).

A. Joël Lamotte