I wasn't at Jacksonville.
Were the current issues discussed ?
Aka what makes refactoring near-impossible today ?
Of course, I have an answer to that ( macros ) - but it's probably not the
only pain point.

I don't believe anything added after 98 made things fundamentally more
complicated for tools.
(Exporting-macro modules might...)

Once we identify the actual pain points it will be easier to work around
them.
Probably by introducing new language constructs - Lots of very smart people
tried to make refactoring work over the past 30 years, I don't believe SG15
can improve on the state of the art without taking a completely new
approach.

So, here is an attempt to reformulate Titus' goal:

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).




Le lun. 2 avr. 2018 à 22:08, Timur Doumler <cpp_at_[hidden]> a écrit :

> 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
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>