Refactoring isn't near impossible, it's just hard. (See most of the talks
that Google has given at CppCon for the last few years - there's massive
refactoring mentioned in most or all of 'em.)

Macros are hard, but not that hard. Inappropriate/unsupported usage of an
API causes far more pain - you can see stories about that in
https://www.youtube.com/watch?v=u5senBJUkPc or the rules we've had to come
up with in Abseil compatibility (https://abseil.io/about/compatibility) or
my proposal at the standards level (http://wg21.link/p0921). But the tools
we rely upon internally work because we control the build system and
toolchain. If an arbitrary project's build isn't understandable, tools
won't work. Similarly, if a project is deeply dependent on the quirks of a
single compiler and that vendor doesn't provide refactoring tools, then we
(as the committee or as the community) cannot rely on the existence of
those tools.

But all of that is fairly tactical - I'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's differences in priorities for tactical decisions.

On Tue, Apr 3, 2018 at 2:32 PM Corentin <corentin.jabot_at_[hidden]> wrote:

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