Description
As discussed in places like #884 (comment), some users want to avoid relying on the optimizer to produce optimal code. Quoting from that comment:
Doing extra work and then throwing it away is antithetical to good embedded software design. Not only are methods that return more than two pointers a risk for code size bloat (even with inlining), but splitting currently introduces a panic path. The optimizer has an extremely hard job, and it is ideal to limit how much it needs to consider in order to produce optimal results, especially compared to the original C.
Currently, zerocopy's internal software organization prioritizes software architecture over performance, especially in the name of reducing the use of unsafe and providing stronger assurances of correctness and soundness. Since correctness and soundness are our most important goals (we would rather produce correct-and-slow code over incorrect-and-fast code), we don't intend to change this state of affairs.
This implies that we need to do some thinking about how to support these don't-trust-the-optimizer use cases. Currently, we have some options such as the one described in #884 (comment), but we did not explicitly design these APIs with this goal in mind.
This issue tracks the task of coming up with a unified strategy for providing APIs which provide stronger guarantees about what code is emitted and rely less on the optimizer to produce optimal code.