I find you're exaggerating what I don't recall has ever been an issue for me when doing C/C++. Having to compute sizes of dynamic objects in memory is just a no

I find you're exaggerating what I don't recall has ever been an issue for me when doing C/C++. Having to compute sizes of dynamic objects in memory is just a normal thing to do. Here is a better practice btw: utf16_output.size()* sizeof utf16_output[0]; This removes the redundant indication of the element type (which can introduce bugs when the type of the array is changed). It gets even better when removing the naming slightly (names indicating types rarely make sense): out.size() * sizeof out[0]; With less magic: plain pointers instead of C++ vector like object, the following is total muscle memory for me: out_count * sizeof *out; I don't see how it is a problem having to do a simple multiplication when what's needed isn't the size that is normally used ("number of elements"), but the size in bytes of the slice. Adding some kind of syntax of library feature to remove this trivial multiplication would add more non-orthogonality, as one would now use sth like out.size_in_bytes() but for custom slices would have to do the calculation manually: n * sizeof out[0]; Note also that in the former case, the need to multiply is removed syntactically, but not at runtime. Personally I don't think there is a worthwhile improvement to have.