Miss Dada  🏳️‍⚧️

You might still want some destination-passing-argument annotation so the constructor can tell the caller "evaluate your arguments into these addresses", so you can compose the in-place construction

Is that what you meant by "ABI on the callee side"?

Yeah you can add explicit caller syntax to set the pointer if you really want, but the callee's implementation shouldn't have to explicitly care about placement new. We should just optimize it for you. Can add callee syntax to "get" the pointer later if we're bad at optimizing.

More radically: return-ptr get/set should be a "maybe it worked, or maybe it's just a temp buffer we'll copy from at the end, you don't know!", similar to materializeForGet/Set, otherwise you can't ever return in registers. Probably based on a simple heuristic like value size?

I’m biased but you should totally use Swift’s instead. Simpler chunking model, more argument and return registers

And privileging registers for self and Result return tag would probably be a code size win for Rust as well as Swift

yes, I have long whispered into the ears of the compiler devs that ()-> Result<T, U>'s ABI should be (*T, *U) -> bool for large payloads, but alas, they don't have the resources/expertese to work on ABI stuff much