"The data pointer is going to modify the struct" is not the only information that is useful. Again, it is true in every language that there are some basic patt

"The data pointer is going to modify the struct" is not the only information that is useful. Again, it is true in every language that there are some basic patterns to what interfaces look like. That doesn't tell you anything about what the application-specific logic implementing those interfaces is intended to do. For that, it is useful to name things such that they describe what they represent in the domain of the application or library. If it is a generic function, there are good names for that as well (for instance, some kind of copy function would still have meaningful names like "from" and "to"). But the example given by the author here was not that, it specifically acted on transactions. In that case, the input bytes were meant to represent a "raw transaction" and the output struct is meant to represent a "transaction".