G'day...

On initial read, P1204R0 sounded good and makes sensible arguments for its
reasoning that I couldn't argue against at the time. So I figured I'd try
it out on an existing project, and hit one detail that's a complete
showstopper for me: Prefix lib for includes.

A consequence of library target folders being named libfoo is that #include
must also use <libfoo/...>. That's a step too far. #include <> implies it's
a public library and thus implies lib - users should not be required to
write lib here. It's not <libboost/...> or <libiostream> or really
<libanything> - I've never seen prefix lib in public includes, and I don't
want to. Installing a package libfoo gives you <foo/...> - it does not and
should not give you <libfoo/...>. No other language does anything similar
either.

One possible resolution is to have folders at least for target types.
Something like libs/ and bins/ so that we can have libs/foo/ leading to
#include <foo/>. I realize this would be a potential conflict with headers
in bins/foo/ and that the paper has reasons for ""-includes being
problematic, but quite frankly any minor risk with ""-style is worth it to
avoid prefix <lib/>.

-- Tino Didriksen