<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><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_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_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>