Good catch.
Under the RFC it's probably possible to ensure values
both of compile-time known and compile-time unknown sizes
are always laid out in the same order on stack
regardless of which execution path through its code an fn takes.
This indeed means the "final" callee can shift values up the stack trivially
and no complex rules are needed to ensure the objects it returns
are laid out on stack in the same order in which pointers to them are returned.
But
Are there reasons - apart from this CC - not to permit code as in my example?
E.g. are there other reasons for the RFC not to change?
Not to become a little more permissive?
And would that not be a good change to the RFC?
And
fn f1() -> (dyn Trait, dyn Trait) {
let a = ConcreteType1{...}
let b = ConcreteType2{...}
// this fn knows the relative ordering of a, b
// on the stack and can shift them trivially
return (a, b);
}
fn f2() -> (dyn Trait, dyn Trait) {
let (a, b) = f1();
// this fn no longer trivially know if a or b come
// first on the stack and cannot shift them trivially
return (a, b);
}