<div dir="ltr">While I'm all for the idea of improving the plugin API, I think that a modest reduction in boilerplate is not sufficiently compelling to foist a new plugin API on people who already have existing code. The funny thing about boilerplate is that it's easy to copy-paste, so it doesn't really impede people from achieving their goals since they can just copy the code that already works. The primary problem of boilerplate is that it has the effect of deterring newbies, and that issue can be easily combated with improved documentation, which avoids breaking every external plugin and tutorial on plugins.<div>
<br></div><div>We really ought to have a preliminary discussion on cfe-dev to map out the directions we want to take the plugin API, and what *compelling*, *enabling* changes we can make to it.</div><div><br></div><div>Among other things, I think that we should explicitly look at at multiple plugins "in the wild" and if possible get feedback from as many plugin authors as possible (preferably, plugin authors that are not also "clang developers"). Also, we should ask plugin authors what functionality, if any, they think needs to be added to the plugin API and what were the biggest difficulties they ran into when developing the plugin.</div>
<div><br></div><div>Also, I think the issue of plugin compatibility (both from a technical and "policy" standpoint) needs to be rehashed since it has been a while since it was discussed.</div><div><br></div><div>
<div style>-- Sean Silva</div></div></div>