<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018 at 5:49 PM Mehdi AMINI via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div>However "good" this change is, I don't really see how it exonerates from what I'm asking: we should think hard about tools/framework to catch mistakes before introducing narrow contracts.</div></div></div></div></div></div></div></blockquote><div><br></div><div>I should apologize, there was a lot of discussion that I didn't read all of, but I should point out that there are many people working hard on ODR violation detection tools. See Richard Trieu's AST hashing stuff. In the long run, this kind of version header skew should be detectable with a tool, and users will still have this macro to get back the old guarantee so they can link anyway with that skew and have things mostly work.</div><div><br></div><div>In the meantime, yes, people with this problem (so far as I'm aware, nobody has indicated that they actually have this use case) may end up debugging some nasty crashes caused by header version skew. But, the cost of the always_inline "solution" for everyone else was too great, and in the last RFC we agreed that it was best to stop providing this guarantee by default. It's not ideal for now, but we can expect to get better tooling here in the future.</div></div></div>