<div dir="ltr">Refactoring isn&#39;t near impossible, it&#39;s just hard.  (See most of the talks that Google has given at CppCon for the last few years - there&#39;s massive refactoring mentioned in most or all of &#39;em.)<div><br></div><div>Macros are hard, but not that hard.  Inappropriate/unsupported usage of an API causes far more pain  - you can see stories about that in <a href="https://www.youtube.com/watch?v=u5senBJUkPc">https://www.youtube.com/watch?v=u5senBJUkPc</a> or the rules we&#39;ve had to come up with in Abseil compatibility (<a href="https://abseil.io/about/compatibility">https://abseil.io/about/compatibility</a>) or my proposal at the standards level (<a href="http://wg21.link/p0921">http://wg21.link/p0921</a>).  But the tools we rely upon internally work because we control the build system and toolchain. If an arbitrary project&#39;s build isn&#39;t understandable, tools won&#39;t work. Similarly, if a project is deeply dependent on the quirks of a single compiler and that vendor doesn&#39;t provide refactoring tools, then we (as the committee or as the community) cannot rely on the existence of those tools.</div><div><br></div><div>But all of that is fairly tactical - I&#39;d really like to think about this as a far bigger picture thing. Setting a good long-term mission that gets us all of these shorter-term goals as a side effect is a good way to structure things - if we agree on the long term, then minor chaos in the short term still leads us in the right direction without getting too hung up on people&#39;s differences in priorities for tactical decisions.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 3, 2018 at 2:32 PM Corentin &lt;<a href="mailto:corentin.jabot@gmail.com">corentin.jabot@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I wasn&#39;t at Jacksonville.<div>Were the current issues discussed ? </div><div>Aka what makes refactoring near-impossible today ?</div><div>Of course, I have an answer to that ( macros ) - but it&#39;s probably not the only pain point.</div><div><br></div><div>I don&#39;t believe anything added after 98 made things fundamentally more complicated for tools.<br></div><div>(Exporting-macro modules might...)</div><div><br></div><div>Once we identify the actual pain points it will be easier to work around them.</div><div>Probably by introducing new language constructs - Lots of very smart people tried to make refactoring work over the past 30 years, I don&#39;t believe SG15 can improve on the state of the art without taking a completely new approach.</div><div><br></div><div>So, here is an attempt to reformulate Titus&#39; goal:</div><div><br></div><div>Refactoring tools that people can trust blindly. (either because the tool works 100% of the time or notifies the user about 100% of the failure cases).</div></div><div dir="ltr"><div><br></div><div><br></div><div><br></div><div><br></div><div>Le lun. 2 avr. 2018 à 22:08, Timur Doumler &lt;cpp@timur.audio&gt; a écrit :</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Titus,<div><br></div><div>While I think this is a great long-term mission, I believe this leaves out a big area where SG15 can provide value today, in the more immediate term.</div><div><br></div><div>I believe we should spend some time on questions like:</div><div><br></div><div>- What language features, that WG21 is working on today, make it harder (or easier) to write good tools for?</div><div>- Are there areas where SG15 can provide guidance to WG21? Think about this scenario. New shiny language feature X has two possible design directions, A and B. Both seem to solve the problem similarly well. However, direction A would create a major pain-in-the-butt for tools vendors, whereas direction B wouldn’t. Should we not monitor, detect, and discuss such cases and then feed our insights back into WG21?</div><div>- Are there areas where, instead of adding more stuff to C++, the problem would be more adequately solved with tooling?</div><div>- Are there areas where language features pose significant challenges for tool vendors, and where it could be good for everyone if we had a platform to synchronise on those challenges? (*cough* *cough* modules *cough*)</div><div><br></div><div>Cheers,</div><div>Timur</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div><div><br><blockquote type="cite"><div>On 2 Apr 2018, at 21:08, Titus Winters &lt;<a href="mailto:titus@google.com" target="_blank">titus@google.com</a>&gt; wrote:</div><br class="m_-9107135942804042489m_1114943055471843498Apple-interchange-newline"><div><div dir="ltr">At the recent evening session in Jacksonville, many many things were brought up in the realm of &quot;tooling.&quot; These ranged all across the spectrum of engineering tools, from IDE support, dependency management / discovery, distribution, refactoring, and a host of other things.  <div><br></div><div>On the fly, I tried to cobble those into a coherent goal for SG15 and the committee to aim toward.  It&#39;s currently phrased very much for the committee audience (that&#39;s been part of my delay in re-summarizing here), but as with any good mission statement I think it gets direction and incentive structures aligned with the greater good.  Put another way: it&#39;s phrased selfishly, but hopefully produces great results for the entire community.</div><div><br></div><div>So, here is that proposed mission statement:</div><div><span style="background-color:transparent;font-size:11pt;white-space:pre-wrap;font-family:Arial"><br></span></div><div><span style="background-color:transparent;white-space:pre-wrap;font-family:Arial">In 10 years, the committee should be able to run compiler-informed queries against a significant fraction of the open-source C++ community and use that to inform deployment of refactoring tools to mitigate.</span></div><div><span id="m_-9107135942804042489m_1114943055471843498inbox-inbox-docs-internal-guid-1ae02bc0-87ba-70b5-59a9-f6fbb9377afd"><ul style="margin-top:0pt;margin-bottom:0pt"><li>Consistent build understanding<br></li><li>Consistent package distribution / identification<br></li><li>Provide static analysis and refactoring to help provide users easy upgrades and modernization</li></ul><div><br></div><div>Obviously this would be a huge task that requires support from many chunks of the community - WG21 cannot be solely responsible, and it&#39;s outside of what WG21 is normally great at.  But we can help set direction, plan, prioritize, and lend support to ideas that emerge along these lines.</div><div><br></div><div>So, I&#39;d like to hear from everyone a bit: is this a good direction? Does it capture what we&#39;d like? Can we phrase it less selfishly? </div><div><br></div><div>If we&#39;re happy with holding this up as the long-term goal, we&#39;ll need to break it down into more manageable pieces.  I&#39;ve privately asked a couple people to sketch out what they envision it would take to get from where we are to that proposed future.  I&#39;d like to broaden that call, and we&#39;ll look collectively at those break-downs to try to formulate next steps.  </div><div><br></div><div>Thoughts?</div><div>-Titus</div><div><br></div><div>PS: I&#39;ve also just completed a big round of offloading in my day job, so hopefully I&#39;ll have more cycles to pay attention to discussion on this list.  My apologies for my scattered attention so far.</div></span></div></div>
_______________________________________________<br>Tooling mailing list<br><a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br><a href="http://www.open-std.org/mailman/listinfo/tooling" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div>