> If you are relying on everybody who reads code that uses your type to have thoroughly scoured all the documentation, you are Doing It Wrong. As fluoridation

> If you are relying on everybody who reads code that uses your type to have thoroughly scoured all the documentation, you are Doing It Wrong. As fluoridation indicated, this is the norm in C programming. By means of example, in the OpenCL C library, bitfields all use the same type. You have to consult a function's documentation to know what you're allowed to pass. [0] I do agree that the 'Ada-style' approach to types is far superior to the 'C-style', but Doing It Wrong seems a bit strong, unless you want to condemn all C code. With the right library you can use the 'Ada-style' in C++. Specifically, using a 'strong typedef' library which prevents implicit conversions, such as [1], but not Boost's strong_typedef which permits implicit conversion back to the underlying type. Unfortunately this kind of thing isn't possible in C. > Programmers understand pointers and pointer semantics: when they see a pointer, they know what is required of them Not really. Should you call free on the pointer once you're done with it? The type alone doesn't tell you. You need to consult the documentation to know how you are meant to use the value, whether or not a pointer type is used. [0] https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_API.html#clCreateCommandQueueWithProperties https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenC... [1] https://github.com/foonathan/type_safe/ https://github.com/foonathan/type_safe/