Hi Titus,

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.

I believe we should spend some time on questions like:

- What language features, that WG21 is working on today, make it harder (or easier) to write good tools for?
- 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?
- Are there areas where, instead of adding more stuff to C++, the problem would be more adequately solved with tooling?
- 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*)

Cheers,
Timur


> On 2 Apr 2018, at 21:08, Titus Winters <titus_at_[hidden]> wrote:
>
> At the recent evening session in Jacksonville, many many things were brought up in the realm of "tooling." These ranged all across the spectrum of engineering tools, from IDE support, dependency management / discovery, distribution, refactoring, and a host of other things.
>
> On the fly, I tried to cobble those into a coherent goal for SG15 and the committee to aim toward. It's currently phrased very much for the committee audience (that'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's phrased selfishly, but hopefully produces great results for the entire community.
>
> So, here is that proposed mission statement:
>
> 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.
> Consistent build understanding
> Consistent package distribution / identification
> Provide static analysis and refactoring to help provide users easy upgrades and modernization
>
> Obviously this would be a huge task that requires support from many chunks of the community - WG21 cannot be solely responsible, and it'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.
>
> So, I'd like to hear from everyone a bit: is this a good direction? Does it capture what we'd like? Can we phrase it less selfishly?
>
> If we're happy with holding this up as the long-term goal, we'll need to break it down into more manageable pieces. I'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'd like to broaden that call, and we'll look collectively at those break-downs to try to formulate next steps.
>
> Thoughts?
> -Titus
>
> PS: I've also just completed a big round of offloading in my day job, so hopefully I'll have more cycles to pay attention to discussion on this list. My apologies for my scattered attention so far.
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling