> On Jul 14, 2023, at 6:11 AM, Jason Thorpe <thor...@me.com> wrote: > >> On Jul 14, 2023, at 2:56 AM, Martin Husemann <mar...@duskware.de> wrote: >> >> The typedef itself buys you nothing but a few charactes less to type, > > No, that’s not correct. For a type that’s meant to be “opaque” (i.e. “users > of the interface should not have to know or care about any of the > implementation details, historical leakage be damned”), the typedef gives you > true opacity… if you’re using “struct kmutex *” rather than “kmutex_t *” then > you’re already eating the forbidden fruit.
I’m not sure I see the benefit of forward declarations being scattered everywhere, which seems to be the focus of the proposed guidelines. Why is that preferable to having a (or multiple) header file(s) with the forward declarations, e.g., foo_fwd.h, which would be included by *.c implementation files that provide definitions (to ensure consistency) and also by other files (*.h or *.c) that just need the forward declarations to use opaque types. This approach defines each identifier in one place, which leads to consistency, and allows files to use either the opaque type (i.e., forward declaration) or the concrete type (i.e., definition) as needed. Perhaps I am not understanding the point of the proposal or am underestimating the problem of files that provide forward declarations to be used elsewhere. The latter are unlikely to change rarely though (i.e., only when types are redefined in ways that affect the forward declaration), so the physical dependencies will not translate into recompilations in practice. Cheers, Brook
