Generally I agree, but have one big disagreement with those statements. >> It's much simpler to just mark fields as private with some convention. If callers wa

Generally I agree, but have one big disagreement with those statements. >> It's much simpler to just mark fields as private with some convention. If callers want to muck with your struct, they will. Agreed, and people mucking with my struct is usually the least of my worries. If a user wants to do that, I say go to town. The "ask for the size first" approach has one major advantage compared to shipping the full struct: 1) You can hide all the random-ass internal structs you use, which can greatly reduce the amount of header code you have to ship. I like shipping a single header w/ a static lib and this can be a huge win for that use case. Note that I don't want to hide the internal stuff because I think users are incompetent and will ruin both our days by doing something dumb. I want to hide noise that they would literally never care about, and don't need definitions for. That all said, packaging an API is pretty tricky to get right and depends a lot on the actual functionality. Maybe we work on different subject matter, and therefore have different views.