<div dir="ltr"><div dir="ltr"><div>G&#39;day...</div><div><br></div><div>On initial read, P1204R0 sounded good and makes sensible arguments for its reasoning that I couldn&#39;t argue against at the time. So I figured I&#39;d try it out on an existing project, and hit one detail that&#39;s a complete showstopper for me: Prefix lib for includes.</div><div><br></div><div>A consequence of library target folders being named libfoo is that #include must also use &lt;libfoo/...&gt;. That&#39;s a step too far. #include &lt;&gt; implies it&#39;s a public library and thus implies lib - users should not be required to write lib here. It&#39;s not &lt;libboost/...&gt; or &lt;libiostream&gt; or really &lt;libanything&gt; - I&#39;ve never seen prefix lib in public includes, and I don&#39;t want to. Installing a package libfoo gives you &lt;foo/...&gt; - it does not and should not give you &lt;libfoo/...&gt;. No other language does anything similar either.</div><div><br></div><div>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 &lt;foo/&gt;. I realize this would be a potential conflict with headers in bins/foo/ and that the paper has reasons for &quot;&quot;-includes being problematic, but quite frankly any minor risk with &quot;&quot;-style is worth it to avoid prefix &lt;lib/&gt;.</div><div><br></div><div>-- <span style="font-size:12.8px">Tino Didriksen</span><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div>