@rkruppe the PR ucg#220 only provides the guarantee for tuples, tuple structs and arrays
resolving ucg#36 as this guarantee not being provided for structs
I personally would prefer to just say something like:
All homogeneous aggregates of the same
reprand length share the same layout.
I see nothing about tuple structs in that diff
Tuples are defined as tuple structs in libcore IIRC
They are not, but that doesn't relate to what I said anyway
The diff only provides a guarantee for tuples, not for tuple structs
an anonymous tuple type
(T1..Tn)of arity N is laid out "as if" there were a corresponding tuple struct declared in libcore
Oh that's what you mean
But still, the diff only provides a guarantee for tuples, not tuple structs in general
So if the layout of arrays and anonymous tuples match, so does the layout of arrays and tuple structs
otherwise, anonymous tuples cannot be laid out as tuple structs anymore
That might mean your diff is contradictory as is but it still doesn't say anything about tuple structs
I could add "homogeneous tuples and homogeneous tuple structs" to make that clearer
My diff doesn't say anything about tuple structs because it doesn't have to
We have already specified that the layout of anonymous tuples and tuple structs is exactly the same
Or at least, that's how I understood that sentence.
Maybe that wasn't the intent, and two identically defined tuple structs are allowed to have different layouts? No idea.
It says tuples are like particular tuple structs, but tuple struct layout is still generally not defined, so structurally identical tuple structs can have different layout
But none of what you propose has any consensus anyway
Then I think we should just say something about homogeneous aggregates in general, because if I say something about tuple structs, then I'm also saying something about structs.
(tuple structs are just structs with fields named after the integers)
I really don't want to open that controversial discussion again. It's not even the current active topic and I don't expect we'd get consensus this time around
What is the controversy in #36 ?
The main arguments against guaranteeing the layout of homogeneous aggregates was PGO or raising the alignment, but it was proposed that doing that could be done using specific repr attributes (e.g.
repr(opt)) or similar, which IMO makes sense.
With all due respect for your personal preferences, we've had plenty of comments explicitly not being convinced by that proposal since it was made
And fwiw we also haven't made layout of other structs "deterministic w.r.t. field types"/structural because of the exact same concerns.
The only concerns I see broken by the definition are:
Are there any others ?
There are others but what you've listed is already plenty
By that I mean there is absolutely no basis for nailing down their layout atm, it will require more consensus building, and IMO this is absolutely not a good use of anyone's time at the moment
Using PGO to avoid false-sharing is horrible, defining what homogeneous means is trivial, and for there to be a possible performance gap between homogeneous and heterogeneous aggregates somebody would need to mention an optimization that would be possible for heterogeneous aggregates that wouldn't be possible for homogeneous ones.
The only one that has been mentioned is field-reordering.
That's not true (just off the top of my head there's field randomization and raising alignment) but more importantly, as I said before, if we let things like hypothetical possibility of PGO stop us from nailing down layout of general structs further (and that's the status quo, like it or not!) then it should also stop us from nailing down layout of homogeneous structs specifically, because there's no reason PGO would apply any less to those structs.
I've replied to the issue with a summary
If we guarantee the field order for these types, then code that relies on that is correct, so I wasn't sure what the point of field randomization would be (it would break correct code).
Raising the alignment up to the size is allowed. Raising the alignment beyond the size has the consequence of increasing the size of the aggregate.
That might be worth it in some cases, but can be done with
#[repr(align())], and instead of doing this silently, e.g., with PGO, we could just tell the user "If you want faster code add
Field re-ordering due to PGO still sounds to me like the best reason for not doing this, and I get the point that if it is not worth it for homogeneous struct, why would it be worth it for heterogeneous ones?
Jesus, are you still at it? I would like more layout guarantees too but why the hell dig this specific thing up now? Either nobody bites and we don't get discussion and consensus, in which case all of this is a waste of time, or there's a huge discussion again and that is really not what UCG time should be spent on when even the current active topic (validity) is in limbo. Even assuming we end up with consensus.
I would like more layout guarantees too but why the hell dig this specific thing up now?
I was looking into safe transmutes, and ran into transmuting anonymous tuples into anything is unsound.
I think it's sufficient for tuples to be unspecified because anyone who cares can make a struct with repr(C) on it
That explains how the topic got your attention again, but not why it should be pursued so aggressively now. Nothing about any safe transmute design hinges on tuples specifically, some trait impls get added if/when tuple layout is defined and not having those impls affects nothing except the ability to transmute tuples (which is also impossible to do unsafely for lack of layout guarantees, so it's not a safe-transmute-specific problem)
hypothetical possibility of PGO stop us from nailing down layout of general structs further (and that's the status quo, like it or not!) then it should also stop us from nailing down layout of homogeneous structs specifically, because there's no reason PGO would apply any less to those structs.
Beyond PGO, the layout of heterogeneous aggregates is also blocked on things like variadics, e.g., do we want to support slicing &(A, B, C) into &(A, b) and &(B, C) )? Since that limits whether we can re-order the fields to reduce padding or not.
I'm opting out now (and muting this thread so I stick to it), I think I've made clear that I consider spending any time on this topic at this time is ill-advised and I've spent entirely too much time on it already