> I think you're proposing that inline functions should have a single definition? This breaks header-only libraries, and also gets sticky with shared libs; whos

> I think you're proposing that inline functions should have a single definition? This breaks header-only libraries, and also gets sticky with shared libs; whose symbol wins? You can have the definition in as many translation units as you like, it's just that only one of the definitions can have extern linkage. This works right now, today, both with header-only libraries and across shared library boundaries. If you take the address of an inline function defined this way, you just get the address of the extern linkage definition. The C compiler will do the right thing, as long as you keep in mind the limitations: - Anything static will get duplicated in each translation unit. (Regardless of whether something is inline--the "inline" keyword isn't relevant here.) - No two translation units have an extern definition for the same symbol. (Again, regardless of whether the symbol is an inline function.) All "inline" lets you do is two things: - You can define a function without creating an extern linkage symbol. - Static inline functions do not cause warnings if not used. So, with your shared library, you have to pick one translation unit in one library which gets the extern definition. This is the same restriction you have with non-inline functions--if you are linking a static library into two different shared libraries, and then combining these shared libraries, you will run into problems regardless of "inline". Or put another way... none of these issues are related to the "inline" keyword in C. The "inline" keyword does not create any new problems.